The Building Security in Maturity Model (BSIMM), Version 4 of which was released in September, is a powerful, data-driven approach to achieving real-world software security. Data Driven because it incorporates years of industry experience in making complex software applications more secure.
But the one thing the BSIMM 4 does not do is explain itself, especially in language that executives without a technical background can readily come to grips with.
Which is why security expert Gary McGraw has done a big favor for everyone concerned with software security. He has set forth Ten Commandments of Software Security that encapsulate the essential findings and philosophy of BSIMM 4. Here, minus the Old Testament language, is our short take:
-
Set up a Software Security Initiative (SSI), with a Software Security Group (SSG) tasked to make it happen.
-
Rely on the BSIMM, not "top ten" lists that leave vulnerability #11 unfixed.
-
Communicate with executives, showing them how the SSI provides business value.
-
Create and adopt a Secure Software Development Lifecycle that integrates security controls with people who understand how to use them.
-
Do not limit the software security cycle to purely technical processes, especially not just penetration testing. Software security is not just narrowly technical.
-
Develop and nurture security professionals for the SSG. You need all the talent you can build.
-
Pay attention to business experience, and gather working intelligence from incidents. Security is a process, not a product.
-
Track your data and make sure you know where it lives – even in the cloud. It is your data, and you are responsible for it, not a cloud provider.
-
Do not rely only on dedicated security features and functions. Security is a product of the entire architecture, not something tacked on.
-
Fix the bugs and flaws in your software. Fix all of them. "Minor" flaws can add up to a serious vulnerability.
To these wise commandments we might add an eleventh: Act on them, and live by them. Having a nice SSG line on the organizational chart is not enough. Because security really is a process, not a product.
