Today SAFECode published Interpreting the BSIMM: A SAFECode Perspective on Leveraging Descriptive Software Security Initiatives. The goal of the paper is to provide SAFECode’s perspectives on the BSIMM and address the questions that we often get about how our guidance relates to the data released through the BSIMM effort.  It expands on my recent blog post that discussed the differences between descriptive and prescriptive software security guidance.

While I encourage you to read the paper, and won’t attempt to summarize it here, I will highlight a few key points we think are worth remembering when you review the BSIMM data.

First, the BSIMM covers much more than secure engineering practices, and in many ways is weighted toward operational security and compliance activities.  This is a point often lost in conversations around the BSIMM data and something worth strongly considering if you plan to use the data to review your software security efforts.  In fact, a strict adoption of the practices that the BSIMM reports as most prevalent would not address what SAFECode considers the root cause of the problem: poor secure coding practices. Thus, while many SAFECode members participate in and support the BSIMM, none of them uses it as an arbiter of proper secure development practice.

Another point not often discussed is that being a “snapshot in time” of current observed practices, the BSIMM will not capture emerging practices in software security. Thus, those looking to use the BSIMM should consider supplementing its data with more prescriptive guidance, which tends to highlight these trends and put more emphasis on such shifts. The BSIMM will eventually capture these changes, but recognition of such changes can only be achieved using historical data.

For more details on these issues and additional SAFECode observations, I encourage you to read the short paper.  I’d also like to emphasize that while SAFECode thought it was important and appropriate to provide its perspective on the BSIMM as part of its ongoing efforts to provide software security guidance to technology providers, our goal is not to minimize its value or significance.

In fact, the BSIMM provides real value when interpreted correctly.  It is perhaps the only source of real-world, quantitative data on the software security programs across a broad range of organizations.  The BSIMM provides the software security practitioner with a non-judgmental lens into a broad spectrum of security activities whose scope extends beyond secure software development.

And, while there are some important differences between the guidance SAFECode provides and the BSIMM initiative, we are all working toward a common goal - to improve the state of software security. And that is something we should all support.

This week, Gary McGraw and his team released the third version of the Building Security In Maturity Model (BSIMM3).  On behalf of SAFECode, I’d like to congratulate the entire team on another successful release of what has become a great resource for the security community.

With the BSIMM’s third release, comes another wave of questions regarding SAFECode and the BSIMM and how the two efforts fit together.  In fact, I have gotten enough questions about this that SAFECode will take a closer look at the BSIMM in a longer form document we hope to release later this fall.

In the meantime, though, I’ll try to answer the basic question on the differences between the BSIMM and SAFECode.  It is more than just the number of firms who participate; rather, it is the difference between descriptive and prescriptive guidance on improving software security.

The BSIMM is about collecting data that describes the things firms across a broad set of verticals do today.  It does not - and this is important - describe what they should do. As a descriptive model, it doesn’t make judgments. The BSIMM won’t tell you what to do or how to do it, and it doesn’t weigh which practices are more effective in some verticals or which practices might be more effective in others.  Its authors’ intention is to observe and report on the frequency of use of particular security practices within a set of IT organizations - and thus allow the reader to form their own conclusions about what constitutes effective security development practice.

SAFECode is supportive of the BSIMM work and we are pleased with the success of its third release.  In fact, nearly all of our members have joined in the effort because we all share a common goal - to improve software security. But, at SAFECode, we are taking a different path to that goal.

SAFECode members represent one vertical.  It is composed of commercial software providers and our recommendations and efforts speak from that perspective.  It is SAFECode’s belief that large commercial software providers have a unique set of software security requirements, and thus, our efforts focus on the needs of these organizations and their customers.

Perhaps more important, SAFECode has chosen a prescriptive approach that emphasizes the use of security practices and techniques that have proven to be effective at each of the SAFECode member organizations.  It makes deliberate value judgments regarding security practices and prioritizes those that were recognized by SAFECode experts as having the most impact - regardless of organizational size, resource pools or computing platform.  In this spirit, it is important to note that SAFECode is primarily focused on engineering best practices.

While the BSIMM’s open ended “here’s what everybody else is doing” approach may help organizations identify blank spots in their development security landscape, or assist them in picking activities, SAFECode offers detailed advice for developers on recommended practices for design, coding and testing.  This is an important distinction that we’ll dive into further in our upcoming paper.

In sum, SAFECode’s commercial software-focused, prescriptive approach offers software security practitioners a blueprint for secure engineering best practices based on what we judge to be most effective as a result of our collective, real-world experiences. The BSIMM’s descriptive approach provides the software security practitioner with a non-judgmental lens into software security activities across a broad spectrum of organizations.

Strong industry collaboration can only have a positive impact on the state of software security.  The two approaches, either in concert or independently, can be used by any organization to review and improve their software security program.  Further, when viewed together, we believe SAFECode and the BSIMM are a powerful combination in the broader industry effort to advance software security.  Thus, we encourage you to take a look at the new data the BSIMM3 offers.

Today we have a guest blogger -  Chris Fagan, Senior Director, Trustworthy Computing, Microsoft. Chris discusses IT supply chain risk assessment.

The assessment of supply chain risks in information technology systems is an area of increasing interest. NIST has recently released an internal report for public comment, IR7622 “Piloting Supply Chain Risk Management for Federal Information Systems.” This report takes an expansive view of IT supply chain risks and this presents cyber security professionals with challenges. One challenge is to identify the potential vulnerabilities that need to be threat modeled and integrated into current risk assessment practices. To identify potential vulnerabilities, a broad-brush approach is required.

An IT system harbors vulnerabilities originating from different sources. These sources range from the practices used to operate the system, the “path” IT elements take before being incorporated into the system, the IT elements themselves that comprise the system, and finally changes that occur during the system’s lifetime.

The plethora of potential vulnerabilities associated with the practices used to operate an IT system and its elements can be organized into a number of buckets based on their source:

a. End User Practices: Poor end-user practices, e.g. no or weak passwords; trawling the web; opening suspect emails.

b. IT System Operating Practices: Poor system operating practices, e.g. not updating patches; the broad use of system accounts.

c. IT System Configuration: Miss-configuration of otherwise sound IT elements, e.g. open ports; insufficient security between elements.

d. Counterfeit Elements: Counterfeit hardware or a counterfeit component within an element, e.g. purchased through a grey market; switched somewhere between supplier and integrator.

e. Element Weaknesses: An unintentional weakness in the fabric of the material of a genuine IT element or component, e.g. hardware errors, coding errors, fatigued code (code which met best practices when developed, but has since become vulnerable as attack techniques improve).

f. Tampering: A genuine IT element is intentionally altered during development, transport, maintenance or during operation, e.g. malware inserted, Hardware and Software Integrity.

These buckets assist risk professionals in three ways. First, they provide a checklist to ensure that common sources of vulnerabilities have been considered. Second, risk reduction activities can be focused on each bucket. And third, the improved measurement enabled by these buckets helps when calculating the return on investments made to mitigate risks.

These buckets are populated with potential vulnerabilities that originate during a system’s lifetime. This lifetime is punctuated by two milestone events – system commissioning and system retirement. These milestones segment a system’s lifetime into three phases – integration, operation and disposal. Potential vulnerabilities can be identified in each phase. Say for example, the threat being considered is that a counterfeit hardware component contains a potential vulnerability. One can ask in which phase a component is incorporated into the IT system, for instance, is it incorporated prior to the system being commissioned or is it introduced as a replacement part 10 years into the system’s life? Controls against the different threats that could introduce a counterfeit component need to be applied in the appropriate phase.

One can also ask about the “path” by which a component or element arrives in a system. An IT system’s supply chain is the collection of supply chains for each of the system’s elements. Broadly interpreted, an IT element can be hardware, software, or even services since the operation and maintenance of an IT system is a service that may be outsourced. For example, if a control, designed to mitigate the threat posed by a counterfeit component, was to purchase an additional genuine component during the integration phase and store it until needed, then access to storage needs to be secured. Thus storage is one location in the component’s supply chain and potential vulnerabilities associated with that presumably secure storage need to be identified.

The buckets listed above provide a framework that assists security professionals in making informed supply chain risk assessments. The examples provide a flavor for how vulnerabilities are identified by considering where in an IT system vulnerabilities manifest themselves, the phases in an IT system’s lifetime, and the path components and elements take prior to arriving in the IT system.

Feedback Wanted

Today has been an exciting day for SAFECode.  We are very pleased to release our latest report: “Software Integrity Controls: An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain.”

For the past year, we’ve been bringing together subject matter experts from all of our member companies to identify and analyze the controls they use to minimize the risk that insecure processes, or a motivated attacker, could undermine the security of a software product as it moves through the links in the global supply chain.  This paper represents the best of those discussions.  Using the real-world experiences of SAFECode members, we were able to develop a set of actionable recommendations for others in the industry looking to reduce the risk of vulnerabilities being inserted into a software product during its sourcing, development and distribution, which we refer to as “software integrity controls.”

It is worth noting that the paper builds upon our previously released “Software Supply Chain Integrity Framework,” which defines a taxonomy for describing supply chain security in the context of software assurance.  We had never planned to develop the framework paper, hoping instead to jump into discussions of controls and practices (SAFECode members are a technical bunch, after all).  However, as soon as we embarked on the project, it became immediately clear that we needed a common language to discuss software integrity issues, and more broadly, software supply chain security.  So I recommend that you take a look at look at that paper as well, since it adds useful context to this discussion.

SAFECode believes that broad industry adoption of software integrity practices can greatly improve customer confidence in IT systems.  And, while we are proud of the fact that this report represents the first industry-led effort on software integrity, we also recognize that this in an emerging area. As such, we encourage public comment on this paper and ideas for future software integrity projects.  We look forward to continuing the conversation!

PS- You can now find us on Facebook and Twitter!

I am frequently asked about SAFECode’s opinion of the Building Security In Maturity Model (BSIMM) and how it differs from our own efforts. So, with the release of BSIMM2 today, I thought it might be a good time to talk a little about BSIMM and how it relates to our work at SAFECode.

It should go without saying that SAFECode is extremely supportive of the BSIMM work and we are thrilled with the success of BSIMM2.  In fact, if you take a look at its participants, you will note that nearly all of our members have joined in the effort or are planning to join.  Further, a number of our members are represented on the newly announced BSIMM Advisory Board.

So why do these companies dedicate time to both SAFECode and BSIMM?

As Gary McGraw will tell you, BSIMM is about science. It is a descriptive model for software security and provides a way to assess the state of an organization in relation to its peers. As a descriptive model, it doesn’t make judgments. It won’t tell you what to do or how to do it, and it doesn’t weigh which practices are more effective than others – it simply offers data on what is currently being done.

Actually the use of the word “simply” is a bad choice. The truth is that a tremendous amount of work went into to collecting and analyzing this data. The latest release, BSIMM2, triples the size of the original study from nine organizations to 30, across a range of seven overlapping verticals including: financial services (12), independent software vendors (7), technology firms (7), healthcare (2), insurance (2), energy (2) and media (2). BSIMM2 now reports the collective expertise of 635 people in firms with 130 years of collective experience.

This is an impressive amount of industry participation, especially when one considers the detail and scope of BSIMM2, which now offers clear descriptions of 109 software security activities in use today. The combination of broad industry participation and a hardworking BSIMM team has resulted in an extremely valuable set of data and a helpful taxonomy for describing software security practices. The question for SAFECode is how do we leverage this work to make ourselves better? And that is precisely where the two efforts come together.

At SAFECode, we also share practices amongst our members and with the industry at large.  But our goal is not to be descriptive. Rather, we are working to improve on the current state-of-the-art in software assurance. SAFECode members come together to work on answers to tough questions. For instance, how can we measure which of these practices are most effective?  How can our internal software security teams verify that each of our chosen practices is being done to our internal standards?  How can we leverage our software assurance programs to positively impact the security of the larger IT system supply chain? How can we get better at training our teams?  How can we get better at communicating with our customers?

SAFECode believes that finding answers to these questions relies in part on an objective understanding of what is being done today – and this is exactly what BSIMM offers. In this way, BSIMM2 provides not only an excellent yardstick for corporate software security programs, but also a foundation for future industry work to make us all better.

Thus when viewed together, we believe SAFECode and BSIMM are a powerful combination in the industry’s efforts to advance software security.  We congratulate the BSIMM team on its successful release of BSIMM2 and we are excited about the opportunity to work with the new data.

And, of course, we invite you to join us.