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.

Welcome to the first SAFECode blog posting, which happens to be my first attempt at blogging so bear with me.  We decided to create a blog so we could keep you up-to-date on SAFECode activities and hot topics in software assurance.

At SAFECode, we bring very smart people together to work on some tough problems around software assurance.   Every few months we release some of our findings and share it so that our work may benefit others.  However, I am often asked what we are up to in between paper releases.  Hopefully through this blog I can keep you updated on our work as it progresses.