The following checklist, available as a softcopy in the Security Templates folder in the book’s companion content, is a minimum set of items a tester should ask herself as she is testing the product. Consider this document to be completed as a sign-off requirement for the application design phase.
Check |
Category |
Chapter |
---|---|---|
o |
List of attack points derived from threat model decomposition process |
4 |
o |
Comprehensive data mutation tests in place |
19 |
o |
Comprehensive SQL and XSS tests in place |
12, 19 |
o |
Application tested with SafeDllSearchMode registry setting set to 2 on Windows XP or tested on the default install of Microsoft Windows .NET Server 2003 |
11 |
o |
Competitor’s vulnerabilities analyzed to determine whether the issues exist in this product |
3 |
o |
Past vulnerabilities in previous versions of product analyzed for root cause |
3 |
o |
If the application is not an administrative tool, test that it runs correctly when user has no administrative rights |
7 |
o |
If the application is an administrative tool, test that it fails gracefully and early if the user is not an admin |
7 |
o |
Application attack surface is as small as possible |
3 |
o |
Default install is as secure as possible |
3 |
o |
Tested all Safe-for-scripting ActiveX controls methods, properties, and events to verify that all such interfaces are indeed safe to call from script |
16 |
o |
Sample code tested for security issues |
23 |
If you learn only one thing from this book, it should be this:
There is simply no substitute for applications that employ secure defaults.
This means building secure, quality software that operates with least privilege, has multiple layers of defense, and has the smallest possible attack surface. You must build software this way because you cannot predict how future attacks will occur.
Do not rely on administrators applying security patches or turning off unused features. They will not do it, or they do not know they have to do it, or, often, they are so overworked that they have no time to do it. As for home users, they usually don’t know how to apply patches or turn off features.
Ignore this advice if you want to stay in "security-update hell."
Finally, you cannot abdicate the security of your product to anyone else. Long gone are the days when security was an art understood by a few; it is now part of everyone’s job to deliver secure software. You can no longer stick your head in the sand.
Ignore this advice at your peril.
18.189.188.238