[Esapi-user] Mike's Top 5 Web Application Security Countermeasures

Boberski, Michael [USA] boberski_michael at bah.com
Fri Jan 29 11:04:32 EST 2010


Hi,

I have been thinking deep thoughts as I have been taking ESAPI to development teams, and I think the planet needs a top x list or two (given their undeniable success in the application security space) that focus specifically on making fixes, to promote awareness of how to get started eating the elephant, once it has been decided (however it was decided) to start using security controls (either proactively or to retrofit for fixes).

How do my thoughts above and below square with yours? Note that the list below is intended to have an OWASP spin to it, specifically ESAPI and ASVS. If there's sufficient interest in developing/refining/referencing this list, I'll pretty it up and post it to a wiki page somewhere, linked to the ESAPI project page.


Mike's Top 5 Web Application Security Countermeasures

1. Add a security guy or gal who has a software development background to your application's software development team.

2. Turn SSL/TLS on for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions.

3. Build an Enterprise Security API (a.k.a. an ESAPI, e.g. OWASP's several different ESAPI toolkits) that is specific to your solution stack and minimally provides input validation controls that use whitelists, output encoding/escaping controls (optionally use parameterized interfaces for SQL), and authentication controls. Build your ESAPI to target a specific level of overall security when all of your security controls are viewed as a whole (e.g. an OWASP Application Security Verification Standard (ASVS) level).

4. Write a programming manual (i.e. a secure coding standard that is specific to your solution stack that is organized by vulnerability type or security requirement with before and after code snippets, e.g. a cookbook that provides before and after code snippets and links to API documentation) that contains step-by-step instructions for using your ESAPI to both proactively guard against vulnerabilities, and to act as a quick reference when the time comes to make fixes.

5. Gate releases of your ESAPI library (e.g. if it is being packaged in a wrapper for subsequent use by other developers throughout the application) with security functional tests that include sufficient negative test cases to demonstrate the security controls are working using data that is specific to your application. Gate releases of your application (ideally gate source control checkins) with security-focused code reviews of all new or updated application code produced during the release (looking out for where new or updated security controls/security control configuration updates are needed).

To further explain the idea overall: next top x list along these lines might then be e.g. a top x list for establishing program-level support (i.e. other lists along the lines of: stop talking about the problem and start fixing).

Best,

Mike B.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100129/cf2a1893/attachment.html 


More information about the Esapi-user mailing list