Coding Standard

I’m repro-ing this from the OWASP Top 10 mail list. I would like to hear folks’ thoughts about what I have included, taking into account that this is designed to be a standard, and not just a guide.

The OWASP Top 10 Coding Standard

I’ve been working on this on and off (mostly off) ever since getting a few comments back in 2005 that the Guide was too big. The big idea is that it’s short and every single item is actionable. If it’s not actionable, it’s not in there. It doesn’t try to fix everything, just the 80-90% of things that really bite folks. Looking through the breach chronology, I think if folks had to stick to this list, they would have been safe, or at least a lot better off.

My goals are

* Scalable – works from a single open source developer through to major enterprises through to huge ISVs
* Applicable – nothing in here is because I wear tin foil underwear, but because it’s essential for a secure app – the omission of that one item will create insecurity
* Easy to apply for new code – the proper way should be the fastest, easiest way to do it right without causing performance issues
* Not hard for old code – the controls in here are going to be a stretch for the billions of lines of existing (crap) code. We can’t ask all that millions and millions of lines of COBOL or Java or C# or VBScript or PHP to be secure overnight. It’s not possible.

To make it scalable, I propose a self-rating system, where single developers and small groups can state up front that they’ve complied with the small group version, with the sole exception of framework authors, who would have to comply with all relevant sections. I’m sick of frameworks being insecure because they can’t be bothered or believe (wrongly) that it’s not their problem. If you’re a framework / library author, such behavior / attitudes are criminally negligent as far as I’m concerned (Jack Slocum – I mean you! http://extjs.com/forum/showthread.php?p=68097#post68097 ). Large ISVs and enterprises have no excuses as they can generally afford this stuff; it’s just as cheap to do it the right way as the wrong way. Just pick those controls that are essential for the risk level and do them.

My current outline is:

1. Secure Development Lifecycle Best Practices
– Discussion about SDLCs and ensure that folks have one
– Development methodology – mandatory. Just pick one, add security as necessary
– Code repository – mandatory. I never seen secure code without one
– Defect tracker – mandatory. I never seen secure code without one
– Peer review of checkins and break the build check in policy – nice to have
– SCA tools – nice to have
– Way to report security bugs – nice to have (although required by some RFCs)

2. Secure Architecture and Design
– Apply Security Principles to your design
– Apply Risk Management to your design
– Picking and implementing the correct controls for your app
– Architecture Reference Model for Initiator / Approver / Receiver transactions
– Architecture Reference Model for privileged CSR, admin features / apps
– Documentation – mandatory. Secure apps have documentation

3. Authentication
– Evidence of identity
– UML Sequence diagrams for common login and credential management scenarios for two factor, trx signing and SMS authentication
– UML Sequence diagrams for low value login and credential management scenarios using passwords. This has in-built countermeasures for brute forcing, etc
– Prohibition against questions and answers (this is how Sarah Palin was attacked. I’ve been railing against them since at least 2004 – see the Guide 2.0 drafts and final text)
– Prohibition against CAPTCHA if disabled access is required (usually is)

4. Access Control
– Create an access control matrix for each secured function and secured resource
– Deny all by default
– Principle of Least privilege
– Fail closed
– Environment Access Control
– Controller / Business Logic Access Control
– Data Access Control
– Access Reference Maps
– Presentation Access Control

5. Validation and Encoding
– Validate from all sources (trust boundaries, where and how much to validate at that layer)
– Canocalization
– Input validation methods (positive validation only, how to validate text fields, fail safe, etc)
– Output encoding (ESAPI like – encodeForJavaScript, encodeForXml() etc)

6. Data Protection
– Define a Collection and Retention of Sensitive Data Policy. Stick to it
– Protect Data at rest (what to encrypt and where, backups)
– In transit (SSL, IPsec, etc)

7. Securely Accessing Services
– Ajax and JSON
– REST
– Web Services (WS-Security)
– Operating System
– Databases (use only safe mechanisms, low privilege access)
– Directories
– Message queues and reliable messaging mechanisms
– Mainframes

8. Accountability
– Error handling (fail safe / closed, etc)
– Logging
– Auditing

9. Debugging, Testing and Maintenance
– Do not deploy test or debug code into production
– How to fix security bugs once and properly
– How to write security tests for fixes
– Prohibition against Easter eggs and magic modes

10. Testing and Assurance
– How to build up assurance
– Doing your own security tests every build
– When to get a SME involved
– SCA tools – nice to have
– Dynamic tools and services – nice to have

Obviously, this is starting to look like the Developer Guide 3.0. I’m not sure that it can be done in any less volume, but we should try, especially as the non-control stuff in the Developer Guide 3.0 is going to the ADSR, the Testing Guide and the Code Review Guide.

Thoughts?