BSIMM4 was released in September 2012 with much press fanfare, including a detailed case study featuring Intel and Fidelity. I make a big deal out of the BSIMM because it is the only data-driven model that can be used as a measuring stick for software security initiatives. The BSIMM is filled with facts and provides a detailed description of the state of software security.
What the BSIMM does not provide is direct advice about what your firm should do when it comes to software security. I recognize that a vast majority of firms are just getting started with software security and that they might benefit from actionable guidance derived from hundreds of (collective) years of direct experience.
Based on many years of experience in the field and an interpretation of four years of BSIMM data, I present the ten commandments for software security.
The ten commandments for software security: Prescriptive guidance
0. Thou shalt lead thy software security initiative (SSI) with a software security group (SSG).
1. Thou shalt rely on risk management and objective measurement using the BSIMM-not “top ten lists†and vulnerability counts-to define SSI success.
2. Thou shalt communicate with executives, directly linking SSI success to business value and comparing thy firm against its peers.
3. Thou shalt create and adopt an SSDL methodology like the Microsoft SDL or the Cigital Touchpoints that integrates security controls (including architecture risk analysis, code review, and penetration testing) and people smarter about software security than the tools they run.
4. Thou shalt not limit software security activity to only technical SDLC activities and especially not to penetration testing alone.
5. Thou shalt grow and nurture software security professionals for thy SSG (since there are not enough qualified people to go around).
6. Thou shalt consume direction from the business and intelligence from operations and incident response staff, and adjust SSI controls accordingly.
7. Thou shalt track thy data carefully and know where the data live regardless of how cloudy thy architecture gets.
8. Thou shalt not rely solely on security features and functions to build secure software as security is an emergent property of the entire system and thus relies on building and integrating all parts properly.
9. Thou shalt fix thy identified software defects: both bugs and flaws.
Ten commandments explained
Some explanation of and justification for each of the ten commandments for software security is in order.
Lead your software security initiative (SSI) with a software security group (SSG). Each of the 51 firms in the BSIMM has an active SSG. Building a thriving SSI without standing up an SSG is very unlikely (and has never been observed in the field to date), so create an SSG before you start working to adopt software security activities. SSGs come in a variety of shapes and sizes. All good SSGs appear to include both people with deep coding experience and people with architectural chops. Code review is a very important best practice, and to perform code review you must actually understand code (not to mention the huge piles of security bugs). However, the best code reviewers sometimes make very poor software architects, and asking them to perform an Architecture Risk Analysis will only result in blank stares. Make sure you cover architectural capabilities in your SSG as well as you do code. Same goes for penetration testing, where a knack for breaking things in clever ways really helps (but does not often come with deep coding skills). Finally, the SSG will be asked to mentor, train, and work directly with hundreds of developers. Communications skills, teaching capability, and good consulting horse sense are mustâ€"haves for at least a portion of the SSG staff. For more about this issue, see the article You Really Need an SSG.
Ultimately, you need to define or adopt a prescriptive SSDL methodology of your own and then use a descriptive measurement system to track progress.
Rely on risk management and objective measurement using the BSIMM-not “Top Ten Lists†and vulnerability counts-to define SSI success. Too many software security professionals treat software security as a whack-a-mole bug hunt. Realize that finding defects alone does not create secure software nor does it communicate risk to management in an actionable way. In fact, there is nothing more discouraging to upper management than being presented with an ever-expanding list of security problems. If you spend all of your time finding bugs and flaws and none of your time fixing them, you're not really helping. Similarly, if you are fixing your security defects, but finding the same defects over and over, you're still not improving. Fortunately, the BSIMM provides a superb measuring stick for an SSI. You can compare the activities you undertake in your SSI with your peers to determine whether you are leading the pack, are in the middle of the pack, or are the slowest zebra. (Hint: do not be the slowest zebra.) A BSIMM measurement provides a detailed snapshot of an SSI that is easy to consume by upper management. Some leading firms use BSIMM measurements over time to track progress and provide real data for setting SSI strategy. How much software security is enough for your firm? Good question. Fortunately, some of your peers may know.
Communicate with executives, directly linking SSI success to business value and comparing your firm against its peers. As I said above, if you come bearing an ever-expanding list of security problems and you're not doing anything to fix them, you may well be seen as part of the problem. Executives want to see some “key performance indicators†that include all aspects of your SSI. How is training coming along? Are your developers learning what they need to know to avoid creating bugs in the first place? What is your defect density ratio? That is, is your firm creating fewer bugs per square inch than they were six months ago? Is there a huge spike in security bugs every time your development teams integrate a new technology stack? When you find and fix architectural flaws or broken requirements, do you show how much headache and money that will save you down the line? Are you finding fewer problems through late lifecycle penetration testing than you were last year? (You should be.) Finally, because an SSI has multiple moving parts, a BSIMM measurement is the most robust way to measure yourself. Senior executives love the BSIMM and immediately grasp its utility.
Create and adopt an SSDL methodology like the Microsoft SDL or the Cigital Touchpoints that integrates security controls (including architecture risk analysis, code review, and penetration testing) and people smarter about software security than the tools they run. There are as many different SSDLs as there are firms doing software security. Not all firms have a formalized SSDL; but they should. Do some reading. Borrow ideas from my book Software Security and from Microsoft's SDL. Throw in some OWASP and SAFEcode ideas as well while you're at it. Read the BSIMM and see what other firms are doing. The main thing to realize is that we do know how to do software security these days. The field has matured. At the very least, you need to adopt code review (preferrably using a tool) to find bugs, architecture risk analysis to find flaws, and penetration testing to look for vulnerabilities that sometimes slip through the cracks. Make sure that when you adopt tools, you don't just blindly use them (or worse yet throw them over the wall to developers with no clue how they work). Remember this: if all your developers could directly consume the output of security tools and fix security defects without assistance, they likely wouldn't have created the defect in the first place! The upshot is that you'll need at least one security professional on your staff who is smarter than the tools. Really. If you need help defining and building an SSDL, get some. There are plenty of consultants out there who do this kind of thing for a living.
No amount of traditional security knowledge can overcome software cluelessness. It is OK to start with seedlings and nurture them into trees.
Do not limit software security activity to only technical SDLC activities and especially not to penetration testing alone. Of course you should take advantage of penetration testing, but you need to understand its limits. The main limit is economical: Â when you find a security problem in a fielded system (or a system that is just about to ship), it is exceptionally expensive to fix the problem. You are going to fix what you find, right? The main thing to realize here is that software security is not simply a technical issue filled only with arcane defects and metal-faced hacker boys. To be sure, there are plenty of technical activities to do and do properly, but never forget to link your activities directly to business impact and the management of risks. Are you fixing your development machine so that developers create fewer security defects in the first place? Are you building secure middleware solutions that your developers and architects can leverage? Are you measuring things and publishing the results internally? You should be. This is the reason that BSIMM covers much more than just what architects, developers, and testers do. We asked firms for data on everything that contributes to specifying, creating, and deploying secure software. We recorded the answers and the superset became the BSIMM. Our continuing work with dozens of firms (including software vendors) of various sizes and across multiple verticals, shows that a software security program encompassing policy, risk, compliance, governance, metrics, operations, SLAs, and related items-in addition to the all-important and crucial efforts in design, coding, and testing-reflects their belief that it is the sum of these business processes and the culture and environment they produce that is critical to producing and maintaining secure software.
Grow and nurture software security professionals for your SSG (since there are not enough qualified people to go around). The best SSG members are software security people, but software security people are often impossible to find. If you must create software security types from scratch, start with developers and teach them about security. Do not attempt to start with network security people and teach them about software, compilers, SDLCs, bug tracking, and everything else in the software universe. No amount of traditional security knowledge can overcome software cluelessness. It is OK to start with seedlings and nurture them into trees. While you're at it, try to create “Swiss Army knife†types instead of minutely-focused specialists. I always look for someone who can review code, do some penetration testing, and actually fix security problems.
Consume direction from the business and intelligence from operations and incident response staff, and adjust SSI controls accordingly. Security is a process and not a product. Software security even more so. You can build the best code in the world with a supremely bulletproof architecture, but problems will still happen in operations. Guaranteed. Use the security attacks that you experience (and that your peer group experiences) to improve your approach to software security and tune it to what your business considers important. Close the knowledge loop and know your enemy.
Track your data carefully and know where the data live regardless of how cloudy thy architecture gets. The cloud is coming and your data are going to be in it. Understand clearly that you cannot outsource software security responsibility to your cloud provider. Your customers are counting on you to protect their data and in some cases the government is regulating that responsibility. The Achilles' Heel of the cloud is the applications that run on it and over it. Build them properly now and rest easier tomorrow.
Do not rely solely on security features and functions to build secure software as security is an emergent property of the entire system and thus relies on building and integrating all parts properly. No matter how many times we say this, developers, architects and builders are going to treat security as a thing. There are simply too many years of training to think of systems as collections of features and functions to overcome. Don't fall into the “magic crypto fairy dust†trap. Sure crypto is useful and many of your systems will need to have some, but security is a systemwide property. Smart attackers rarely go after crypto, they go after defects in other obscure parts of your system. Make sure you spend at least as much time trying to eradicate bugs and flaws as you do picking and implementing security features. Software with good crypto, robust authentication, granular authorization, mind-bending CAPTCHAs, and many other fine security features coded perfectly well gets broken into every day. These features typically stop authorized users from doing known, undesirable things. They rarely prevent unauthorized users from doing unknown undesirable things. You need an SSI to build secure software effectively and efficiently across an entire portfolio.
Thou shalt fix thy identified software defects: both bugs and flaws. It's sad, but software security often looks like this in practice. You hire some reformed hackers to do a penetration test. You know they're reformed because they told you they are. They find six scurity defects in the week that you give them to probe your system from the outside. They tell you about five of them. You fix two of them that seem fixable and declare victory. But what about the other four defects? Simply put, if you spend all of your energy finding problems in your software through architecture risk analysis, code review, and penetration testing, and you spend no time fixing whay you find, your software is no more secure than it was when you started. Fix the dang software! Of course, fixing defects is a risk management activity and no firm has infinite money. Therefore, there must be prioritization based on impact, cost, and other factors important to the business. However, collective memory is short and very few firms keep track of every security bug not fixed. Do 10 low-severity bugs collectively become a medium? What about 100? 1000? In addition, very few firms correlate findings from multiple testing methods and instead make decisions in a vacuum after each testing exercise. Might the low-severity bug from the architecture assessment, the low from static analysis, the low from fuzzing, and the low found in penetration testing combine to make a critical? I don't know either, but someone should think about it. It may be easier just to fix the dang software.
Prescriptive Advice about Descriptive Models
Ultimately, you need to define or adopt a prescriptive SSDL methodology of your own and then use a descriptive measurement system to track progress. Our advice is to use BSIMM to measure the current state of your software security initiative and determine other software security activities you should probably start doing. If your organization determines that one of the areas requiring investment matches one of the practices in the SDL (for example), you would be silly not to take advantage of Microsoft's wisdom for that activity.
Because we have been measuring real software security initiatives in 51 firms over multiple years, we can state with confidence that if your SSI is not improving every year then your firm is falling behind. We know that every SSI is unique, just like every other SSI. Yours will be too. Fortunately, no matter what prescriptive approach you take to software security, the BSIMM can serve as a measuring stick, a source of inspiration, and an objective measurement of progress.
Acknowledgements
The ten commandments for software security were developed jointly with the Cigital Principals, including Paco Hope, Scott Matsumoto, Sammy Migues, and John Steven. Some explanatory description is adopted with permission from the BSIMM4 document.
About the author:Â
Gary McGraw, Ph.D., is CTO of Cigital Inc. a software security consulting firm. He is a globally recognized authority on software security and the author of eight best selling books on this topic. Send feedback on this column to editor@searchsecurity.com
New AT&T SYN248â„¢ Phone System
Recently Microsoft made a decision to have “do not track†automatically turned on, in its new Internet Explorer browser and the online advertising community is angry, reports, BtoB Online. (Read the Full Article Here) Understandably angry.
The 2012 Small Business Influencer Awards have been a resounding success, thanks to our sponsors, media partners, and everyone who participated and helped spread the word.
Adrian's Network is a business networking community comprised of business owners and professional services providers that are joined together to help one another to make contacts and connections that lead to business opportunities. The group meets virtually and in person. Â Founder Adrian Miller shares a little about herself and her company:
Ask The Business Lawyer helps women business owners escape “self-employed slavery†by teaching them how to build multimillion dollar companies for scale or sale. The company, run by Nina Kaufman, helps women business owners who are ready to catapult to the next step in their professional lives:
Jill Salzman created The Founding Moms in an effort to find likeminded female entrepreneurs in her area. What started locally is now a collective of offline meetups and online resources for mom entrepreneurs in 30+ cities around the globe.  The website offers tools, tips & tricks to help women grow their businesses and get down to business:
Nope, Google Docs isn't dead. This is not another Googleocalypse. Instead of eliminating something (like it regrettably did with Google Desktop), the search mammoth has hit one out of the ballpark with a change that gives you multiple advantages, all in a new product called Google Drive.