21 maart 2013
21 maart 2013
Likewise if a software project is delivered and no one has looked at security, can it be said to be secure?
When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands (I need it to do X and also Y and Z… oh and can I get A?). And maybe some thoughts have been given to performance metrics, but security? Well… it “needs to be secure”.
It is said, conveniently enough mostly by software engineers, that building software is perhaps one of the most complex activities that humans have ever undertaken. Looking at some of the questions one might ask an engineer on secure coding, you get the idea that these software engineers may have a point:
I would say ‘etcetera’ here, but it doesn’t quite cover how many questions one can ask of engineers when they build an application. To help our engineers we currently do the following:
But even with that, I have a saying:
Repeat after me: “If it hasn’t been tested, it doesn’t work.” And: “If it hasn’t been documented it doesn’t exist” — relaxnow (@relaxnow) February 2, 2010
Remember all those questions we asked the engineer on secure coding? Turns out engineers don’t have a fixed set of questions they ask themselves. Team Leads don’t have a specific set of questions they ask their engineers. Customers hire security auditors (like us) and they all have their own set of questions. In order to help organisations come to an agreement on what should be the ‘minimal’ required set of questions to ask, several people got together and created the Application Security Verification Standard (ASVS) project and donated it to the Open Web Application Security Project (OWASP). From the introduction:
The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications.
ASVS gives the customer, and us, a negiotable ‘Security Minimum’ that can be verified. It defines 4 levels of rigor:
And 14 chapters:
Every chapter defines it’s own set of rules and the levels pick and chose from these (level 1 will only pick the first simple requirements from each chapter, while level 4 will require them all). At Ibuildings we pick a level with the customer at the start of a project. So far, we haven’t seen too many medical or life-critical projects, so they tend to be level 1 or 2. And we make sure to verify that the project complies before the final go-live. Now let me make this clear, as an engineer myself, we don’t look at a requirement like:
V5.7 Verify that all input validation failures are logged.
and say “Well, that’s a 2B requirement that is. This project is Level 1 only, so no logging for this app!". Where feasible, engineers will always hold themselves to the highest standards. But we certainly won’t rewrite a third party application to support this rule, unless the customer explicitly wants us too.
While ASVS is a wonderful addition, it has it’s issues:
The first and second issue are rather big issue for us. We’re commercial company making software for other (mostly) commercial companies. Budget is always an issue. Fortunately this is where automation and a bit of templating can come in quite handy! It’s still early, but you can find a sneak peak of what we’re doing with ASVS at our GitHub repo: ibuildingsnl/ibuildings-owasp-asvs-report-generator (warning, still very alpha). More on that later! As for the third issue, ASVS 2.0 is in progress and looking for volunteers!
Security is hard. We’re constantly improving, we already:
And now we’ve added OWASPs ASVS, which is pretty cool, check it out! Let us know how you’ve embedded Software Security in your Software Development LifeCycle in the comments below or on the PHP Security Technical Group.