Hello Jim, I tend to disagree with your statement that security requirements should be part of contractual agreements or added to a purchase order. In the Real World (™ ☺) this does not work. Once signed, contracts are never looked at again, unless the shit hits the fan and someone must be blamed for something that went wrong. Development teams (which is a lot broader than the term developers) _never_ read contracts or look at purchase orders.
In itself, security statements in a paper nobody reads but the corporate lawyers will not make any application more secure. Lawyers will go over contracts and purchase orders and I shudder to what will happen if they disagree on a technical term in your ‘security requirements’. Please define (in legal terms) “configuration file”, “user data”, “regular expression”, “form nonce” …. Note that none of the business people responsible for the ‘security’ of the application/business process will understand anything of this, although they are ultimately responsible … IMHO all this (detailed technical requirements in contracts) is part of the security theater and does not aid in making applications more secure (whatever that term – ‘secure’ - means), it just aids in creating auditor checklists that can be completed by junior auditors that don’t know anything about application development. Or let the process control people create a CMM dashboard with a green light. The most you can expect from a contract is very high level statements, and once they are high-level, will they aid in the objective o have secure software? In my experience, once a contract is signed, the development team will create the functional requirements (or whatever this document is called in their methodology), and this document will result in a functional specification document, that requires sign-off by the customer before one line of code is written (don’t get me started on ‘agile’ development). If it is not in this specification, it will not be part of the code nor the tests afterwards nor the acceptance tests of the customers. The most important thing to notice here is that the trick to make the application more ‘secure’ (or at least abide to what people call here ‘secure development best practices’ – who decides what is ‘best practice’ anyway...) is to have the security requirements part of the standard documentation used in their methodology. Train the person who creates the requirements document to rewrite statements as ‘click –a- to do something’ in ‘click –a- to do something and ignore all other inputs”. There is of course a lot more to this, but this email is already getting too long. ☺ Recommendation: Do not create a separate ‘security requirements’ document because it will not be used (real life example: “yes there is always a statement in our functional requirements that we must include the requirements of the security policy/requirements document but we never look at those documents, because we are already developing for many years so we should be OK …”. Important remark: most security people will tell that you must do ‘security testing’ but completely fail to understand how bigger development shops work. All tests are created from the functional specification document! Need better input validation? Rewrite the functional specs! Note that there are a lot of standard methodologies to create tests from a functional spec document – all unknown to most security people - and that many big development shops completely outsource this part of the development process. Note that the above in itself is not enough, some other design/architecture/implementation/test ‘controls’ (I hate this word) are necessary. But start with the basics: secure development starts with having a good writer – not a coder, tester, architect, designer - with a common knowledge of security for your functional requirements/specification document. Do not 'add' a security layer on top of something, but 'include' security. Please note that all opinions are my own and that I’m not aware of any independent – and unbiased - studies that proof or disproof anything in mine or your email. ☺ Unfortunately the Information Security Profession has not reached the maturity to look and study what really matters in an objective way. So you are stuck with my biased opinion for now. But this opinion is based on a career as developer, security consultant, auditor and security manager so I hope it gives valuable insights or start a discussion so I can learn, maybe change my insights and better serve my customers. Sincerely, Herman Stevens [EMAIL PROTECTED] http://www.astyran.be From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Manico Sent: donderdag 27 november 2008 22:38 To: Mark Rockman Cc: Secure Mailing List Subject: Re: [SC-L] How Can You Tell It Is Written Securely? > OK. So you decide to outsource your programming assignment to Asia and >demand that they deliver code that is so locked down that it cannot >misbehave. How can you tell that what they deliver is truly locked down? >Will you wait until it gets hacked? What simple yet thorough inspection >process is there that'll do the job? Doesn't exist, does it? This most important thing you can do is provide very specific security requirements as part of your vendor contract BEFORE you hire a vendor - and the process of building these security requirements might call for bringing in a security consultant if you do not have the expertise in-shop. Requirements that allow a vendor to actually provide security are line items like (assuming its a web app): "Provide input validation for every piece of user data. Do so by mapping every unique piece of user data to a regular expression that is placed inside a configuration file." "Provide CSRF protection by creating and enforcing a form nonce for every user session" After you build this list for your company, it should provide you with a core list of security requirements that you can add to any PO. - Jim _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
