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.

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!

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.

Q: What is your role at Adobe?
I manage two teams. One is the Adobe Secure Software Engineering Team, or ASSET. The other is the Product Security Incident Response Team, or PSIRT. The ASSET group coaches and evangelizes software security principles with development teams to make sure that security is most properly incorporated into software development to mitigate the risk of any security problems. Whenever a potential problem does make it into a product, our incident response team coordinates with other folks in the security community and begins working with our engineering teams on triaging the issue and getting a patch out the door.

Q: Can you tell us a little about Adobe’s software development programs?
We have thousands of software developers located around the world. And, at any time, we have hundreds of projects under development. Both Adobe Flash Player and Adobe Reader have some of the widest reach of any software product. For example, Flash Player is on close to 99 percent of all Internet connected devices. So we have a massive install base for our software.

The code that we write gets deployed on pretty much every platform—whether it’s Windows, Mac, Linux or others. We’ve built desktop products, mobile products, server products and services.  To meet these diverse requirements, we use a combination of agile processes and formal methods.  We also build platforms that other people write code for, which means that we’re thinking not only about how to make our own software secure, but also how to help other developers make their software secure.

Thus, the secure development processes that we use have to be effective across a wide range of environments, methods and product types.

Q: Why did Adobe join SAFECode?
We take software security very seriously and are always looking to build upon what we’ve been able to accomplish so far.  We have a mature software security process and have developed a lot of experience in this area that we feel we can share in an effort to help the industry advance software assurance practices. We’re also looking forward to learning from the other SAFECode members and sharing some lessons that we’ve learned with them. In addition, there are some specific industry-wide initiatives that we’re looking to help drive through SAFECode, such as effective patch management across platforms.

Q: Are there any challenges in software assurance that Adobe is looking forward to working on with SAFECode?
A big challenge is how fast the threat landscape changes. An example is that 10-15 years ago, buffer overflow attacks were largely theoretical. Now they are common, and we’re seeing some pretty exotic kinds of attacks. The flip side is that companies are shipping code that, in some cases, might be as old as 10-15 years. We need to go back and improve the security of that code without decreasing the functionality of the programs. How do we efficiently improve code that was developed under different circumstances so that it meets today’s security challenges?  As a company and an industry, we’ve made a lot of progress in this area, but there is still work to do and we feel SAFECode provides a great platform for continuing these efforts and addressing these kinds of challenges.

—–
Brad Arkin is director of Product Security and Privacy at Adobe Systems Incorporated. He is responsible for the Adobe Secure Software Engineering Team (ASSET) and Product Security Incident Response Team (PSIRT), as well as cross-company coordination and initiatives related to security and privacy. Arkin has worked in software security for more than 12 years. He served as a Technical Director for @Stake’s New York office and as a Senior Manager at Symantec. Earlier, Arkin worked at Cigital, where he co-founded the company’s software security group. Arkin holds a BS in computer science from the College of William and Mary, a MS in computer science from George Washington University, and MBA degrees from Columbia University and London Business School.

Software assurance is most frequently discussed in the context of ensuring that code itself is more secure through the repeatable application of secure software development practices.  These practices, however, only represent one aspect of software assurance.

SAFECode defines software assurance as “confidence that software, hardware and services are free from intentional and unintentional vulnerabilities and that the software functions as intended.”  To achieve software assurance, suppliers take action in three key areas:

•    Security: Security threats are anticipated and addressed in the software’s design, development and testing.
•    Authenticity: The software is not counterfeit and customers are able to confirm that they have the real thing.
•    Integrity: The processes for sourcing, creating and delivering software contain controls to enhance confidence that the software functions as the supplier intended.

SAFECode’s recent paper on software supply chain integrity provides a framework for analyzing and describing the efforts of vendors to ensure software integrity. I think of the difference between secure development practices and software integrity practices this way: Secure development practices address the security characteristics of the code itself, while software integrity practices address the security of the process used to source, build, test and deliver the code.

Software integrity practices complement secure development practices by minimizing the risk of malicious code being intentionally inserted in the global software supply chain.  They represent one leg of the software assurance tripod.  Software integrity, authenticity and security together form a sound basis for confidence that software is free from intentional and unintentional vulnerabilities and that the software functions as intended.

Next time: We’ll take a closer look how software integrity practices relate to the global software supply chain.

As the software industry has become increasingly globalized, questions have been raised about what additional product security and brand risks are introduced by the increased distribution of software development activities, how these risks should be assessed, and what proactive measures can minimize their occurrence.  These questions are of interest to both customers and suppliers and have been aggregated under the label “software supply chain integrity.”

The challenge we faced when we started this project was that the concept of “software supply chain integrity” and its key components of “software supply chain” and “software integrity” were not commonly understood.  As such, we felt that there was great value in developing a framework and common taxonomy that would serve as the foundation for our subsequent work aimed at identifying and analyzing software integrity best practices.  Releasing the framework publicly provides us with an opportunity to solicit feedback on our approach, helping to ensure that our future papers are as useful and relevant as possible.

However, the development of this framework is just the first step in our effort to address software supply chain integrity.  Our members are working together to identify the threats, assess the risks, share current practices for mitigating those risks, and develop process guidelines that other software companies should consider adopting to protect the integrity of the software they produce through the global supply chain.  SAFECode will be publishing our findings later this year to extend these practices across the industry and provide customers with additional insight into how to view and evaluate the processes by which software integrity is achieved.

Though experts have concluded that the software supply chain is not the most likely attack vector, the fact that a risk does exist requires preventative action. Further, the interdependencies of the IT ecosystem require software suppliers to not only be able to demonstrate the security of the products they produce, but also evaluate the integrity of products they acquire and use.  For these reasons, we believe that every software supplier has a significant stake in the identification, communication and evaluation of best practices for ensuring software integrity.

I will be highlighting key elements of our framework in a series of blog entries.  Next up: what is software integrity and how does it relate to software assurance?

I’ve seen many people claim that agile methods and security are mutually exclusive, as ‘agile’ is interpreted as ‘laissez-faire’.  I don’t buy this as Scrum is actually quite strict.  There’s a better argument, though: As every Scrum sprint is different, mandating a specific security engineering activity in every sprint is counterproductive to agility.  This is probably true.

The key observation was therefore to distinguish between actual engineering activities, such as those listed in the SAFECode Fundamental Practices for Secure Software Development paper, and security risk management, which is all about meeting an acceptable level of business risk.  Scrum is a management model, and therefore, we really ought to be concerned about how risk management fits Scrum.

And after all, in Scrum, an enormous amount of trust is placed on the team. They should know best how to do the actual engineering, and to make sure they do, providing all sorts of software security training and support is necessary.

So, a scheme is required where the traditional security business risk management practices can be built into the management practices in Scrum. First, you need to identify the threats; second, you need to decide on the controls (which may be engineering practices as well, not just design decisions or features). What you’ll have left is residual risk - the part of the risks that haven’t been fully mitigated or terminated - and that has to be acceptable to the business owner.

As it happens, Scrum readily gives a lot of structure where these risk management practices can be implemented. The most complex one of these was the threat analysis part, which, when done properly, is a bit too large of an effort to squeeze into the sprint planning session.  At the moment, the best proposal I’ve seen is that sprint planning only identifies the largest risks - typically those having most impact in terms of engineering - and the detailed threat analysis would be done by the team as they see fit, most likely early in the sprint.

Deciding on the controls would be done by the end of the sprint, depending on how the team organises their work. The team has three options for each identified threat: either they add new sprint backlog items and address them during the current sprint, or they postpone the work by adding product backlog items, or they make a first-level risk acceptance decision by choosing to do nothing.

The third phase, approving the residual risk, fits the sprint review. The team makes the lowest level business decision by determining whether they feel they’re ‘done’ with the sprint backlog given all the threats they’ve found, and the controls they’ve implemented. If they agree, the residual risk can then be approved by the product owner, who is also the business owner. If a product is comprised of the outputs of several Scrum teams, residual risk acceptance for particularly hard decisions can still percolate higher up if necessary.

This model has some very nice properties: if the team feels that they cannot accept a risk but they still don’t have enough time to mitigate it during the current sprint, producing a product backlog item will automatically escalate this to the product owner, and require the product owner to prioritise it for later sprints. In addition, flagging a sprint backlog item ‘not done’ in the sprint review gives the Scrum team power to voice their concerns over open security risks.

For this to work, the Scrum team does need to be acutely aware of security engineering and software security issues, and especially the threat analysis part needs to be prudently done. Security specialists should be on call. Luckily, an ideal Scrum team is also an ideal mentoring environment for security, but that will probably be a topic of another post later.

I commend them for asking this question because I believe that sharing this information is critical to the advancement of secure development practices.  But since I spent most of my career in public relations, I understand that sometimes a lack of a response to a request like this is often an issue of timing or simply a mix-up, so I am hesitant to agree outright with the conclusion that a company’s inability to respond to one survey is directly attributable to an unwillingness to share information, or as is also proposed in the article, a sign that maybe they do not have something good to talk about.

However, the article does raise an important issue.   There is a desire for more clarity on the methods that software vendors use to help ensure the security of the software they produce – and until recently this information was hard to find.  In fact, this was big part of the reason SAFECode was formed.  Our members recognized that while individual companies have implemented effective methods for developing and delivering more secure and reliable software, there was no coordinated, industry-led effort to share this positive work and build upon it to advance software assurance more broadly.

And while there is still more work to be done, I think we have made strong progress in this area as SAFECode continues in its second year.  All of our members – EMC, Juniper Networks, Microsoft, Nokia, SAP and Symantec – have actively participated in an open exchange of information about their software assurance programs.  We have released much of the information they have provided in three freely available papers – each of which is based on a detailed analysis of the methods used by our individual member companies to help ensure the security of the software they produce:

•    Software Assurance: An Overview of Current Industry Best Practices: This paper identifies and explains the high-level security best practices and controls that are currently in use by SAFECode members.
•    Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today: This paper outlines a core set of secure development practices that can be applied across diverse development environments to improve software security.  Its recommendations are based on an analysis of the individual software assurance practices used by SAFECode members.
•    Security Engineering Training: A Framework for Corporate Training Programs on the Principles of Secure Software Development:  This paper outlines the fundamentals of a security engineering training program based on an analysis of the shared experiences of SAFECode members.

As the SD Times articles states, perhaps not every software company is as ready to share, but I did want to take this opportunity to point out that SAFECode is a place you can go to find this open exchange of information.  And as our industry continues to mature, we hope that others will join us in our effort to foster productive information sharing and collaboration on secure development practices.

Another highlight of the conference was our panel discussion around our paper on Fundamental Practices for Secure Development.  We had a expert group of speakers representing some of our member companies: Steve Lipner, Microsoft; Reeny Sondhi, EMC; Wesley Higaki, Symantec; Gunter Bitz, SAP; and Paul Kurtz, our executive director who moderated the discussion.  And while the panelists were great, it was really the audience feedback that made the experience so rewarding.

After the discussion, members of the audience thanked us for the paper and presentation and let us know that they had started implementing our recommendations in their own efforts. This feedback from actual practitioners meant a lot because it demonstrates that we are having the impact we hope to achieve with this work.   Our members are sharing the lessons they have learned from their own secure development efforts so that we can help others in the industry start or refine their own internal software assurance programs.  Hearing first hand that others are finding practical value from these efforts further strengthens our commitment to sharing our experiences and continuing to refine and update our development practices paper.

In fact, in an effort to keep the paper as relevant and useful as possible, we are currently accepting feedback on its recommendations via an online comment process.  If you have worked to implement some of our methods or have ideas of your own, we’d love to hear from you.

We have brought our members together for a board meeting at the RSA Conference to hammer out some details on our current projects, plan our future efforts and meet with some members of our International Board of Advisers.  It should be a good day of brainstorming, idea-sharing and networking.

We are also issuing a call for public comments on our paper “Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today.” Based on an analysis of the individual software assurance efforts of SAFECode members, this paper outlines a core set of secure development practices that can be applied across diverse development environments to improve software security.

We’ll be updating the paper in late 2009 and would like to give software security experts outside of our membership a chance to provide comments.  This will not only expand our frame of reference, but will also give those who have put some of the paper’s recommendations into action a chance to provide feedback.  Based on the feedback we have received, we really think this paper has the potential to help others in the industry with their own secure development efforts, as well as shed some light for customers on the practical steps leading software companies are taking to help ensure software security.  We believe opening up the paper to experts outside the membership will only make it stronger and we look forward to the seeing the feedback.

So we encourage you to submit your comments – we’ll be accepting them until July 31.  And, if you are at the RSA Conference and would like to learn more about this paper, we’ll be giving an overview in a panel discussion on Wednesday.

We also just released a paper outlining a framework for building a corporate training program on secure software development.  We have found that all of our members have internally developed training programs to support their software assurance programs, so we wanted to see what these programs had in common.  While it is clear that training programs are most effective when they are customized to corporate needs, we were able to uncover a number of fundamental principles that all of our members’ programs share and we hope that providing this insight is useful to anyone who might be thinking about starting their own training initiatives.

I will be at the RSA Conference all week, along with many of our SAFECode members.  Any of us would be happy to answer any questions on SAFECode, so let me know if you want to meet up.