FW: How Can You Tell It Is Written Securely?

[herman.stevens at astyran.be (Herman Stevens)]

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
Herman.Stevens at astyran.be
http://www.astyran.be


From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] 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