The vast majority of security assessments I’ve worked on have used “best practice” to define the security requirements of the application under test. Clients are content to rely on security assessment firms to decide what should and shouldn’t be tested, and this is usually OK for bug hunting. But apart from the well known bugs which constitute security vulnerabilities there is an often overlooked class of security issues: lack of, or poorly implemented security features, such as:
- No protection from brute force attacks against the login credentials
- a lack of cache-controls to prevent caching of sensitive content
- a failure in the access controls to prevent unauthorised users from viewing sensitive data
- etc.
These are not bugs as such, but they do pose a risk to the security of the application - and they are completely preventable, if they had simply been defined as requirements right at the start of the project! The closest definition there is to a generic set of security requirements for web applications is the
OWASP Guide to Building Secure Web Applications, and it’s a good basis to start
defining your own set of security standards. Because one size definitely does not fit all. Security requirements should define both how your application should behave (security use cases) and also how it should not behave (
abuse cases). Since these will be protecting the business from risk, they should be considered first class business requirements. Now, instead of shooting in the dark, the architects and developers will have a clear idea of how the application should behave from a security perspective. When it comes to the testing phase, testing of the security features can be a part of the normal unit, integration and acceptance testing. This means that the traditional penetration test performed at the end of the project should uncover fewer surprises - and importantly fewer security issues which require major application redesign. Additionally, the penetration testers should be using the security requirements as the standard by which to judge the application. Want even more bang for you buck? How about inserting the security requirements document as a standard part of agreements with third party developers and other software suppliers? These can be bound to legal contracts and SLAs so that you don’t end up footing the bill for someone else’s poor security!
January 12, 2008 | Filed Under
Design |
Leave a Comment