Tag Archives: supply chain risk framework

Improving Signal-to-Noise in Risk Management

By Jack Jones, CXOWARE

One of the most important responsibilities of the information security professional (or any IT professional, for that matter) is to help management make well-informed decisions. Unfortunately, this has been an illusive objective when it comes to risk. Although we’re great at identifying control deficiencies, and we can talk all day long about the various threats we face, we have historically had a poor track record when it comes to risk. There are a number of reasons for this, but in this article I’ll focus on just one — definition.

You’ve probably heard the old adage, “You can’t manage what you can’t measure.”  Well, I’d add to that by saying, “You can’t measure what you haven’t defined.” The unfortunate fact is that the information security profession has been inconsistent in how it defines and uses the term “risk.” Ask a number of professionals to define the term, and you will get a variety of definitions.

Besides inconsistency, another problem regarding the term “risk” is that many of the common definitions don’t fit the information security problem space or simply aren’t practical. For example, the ISO27000 standard defines risk as, “the effect of uncertainty on objectives.” What does that mean? Fortunately (or perhaps unfortunately), I must not be the only one with that reaction because the ISO standard goes on to define “effect,” “uncertainty,” and “objectives,” as follows:

  • Effect: A deviation from the expected — positive and/or negative
  • Uncertainty: The state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence or likelihood
  • Objectives: Can have different aspects (such as financial, health and safety, information security, and environmental goals) and can apply at different levels (such as strategic, organization-wide, project, product and process)

NOTE: Their definition for ”objectives” doesn’t appear to be a definition at all, but rather an example. 

Although I understand, conceptually, the point this definition is getting at, my first concern is practical in nature. As a Chief Information Security Officer (CISO), I invariably have more to do than I have resources to apply. Therefore, I must prioritize and prioritization requires comparison and comparison requires measurement. It isn’t clear to me how “uncertainty regarding deviation from the expected (positive and/or negative) that might affect my organization’s objectives” can be applied to measure, and thus compare and prioritize, the issues I’m responsible for dealing with.

This is just an example though, and I don’t mean to pick on ISO because much of their work is stellar. I could have chosen any of several definitions in our industry and expressed varied concerns.

In my experience, information security is about managing how often loss takes place, and how much loss will be realized when/if it occurs. That is our profession’s value proposition, and it’s what management cares about. Consequently, whatever definition we use needs to align with this purpose.

The Open Group’s Risk Taxonomy (shown below), based on Factor Analysis of Information Risk (FAIR), helps to solve this problem by providing a clear and practical definition for risk. In this taxonomy, Risk is defined as, “the probable frequency and probable magnitude of future loss.”

Taxonomy image

The elements below risk in the taxonomy form a Bayesian network that models risk factors and acts as a framework for critically evaluating risk. This framework has been evolving for more than a decade now and is helping information security professionals across many industries understand, measure, communicate and manage risk more effectively.

In the communications context, you have to have a very clear understanding of what constitutes signal before you can effectively and reliably filter it out from noise. The Open Group’s Risk Taxonomy gives us an important foundation for achieving a much clearer signal.

I will be discussing this topic in more detail next week at The Open Group Conference in Newport Beach. For more information on my session or the conference, visit: http://www.opengroup.org/newportbeach2013.

Jack Jones HeadshotJack Jones has been employed in technology for the past twenty-nine years, and has specialized in information security and risk management for twenty-two years.  During this time, he’s worked in the United States military, government intelligence, consulting, as well as the financial and insurance industries.  Jack has over nine years of experience as a CISO, with five of those years at a Fortune 100 financial services company.  His work there was recognized in 2006 when he received the 2006 ISSA Excellence in the Field of Security Practices award at that year’s RSA conference.  In 2007, he was selected as a finalist for the Information Security Executive of the Year, Central United States, and in 2012 was honored with the CSO Compass award for leadership in risk management.  He is also the author and creator of the Factor Analysis of Information Risk (FAIR) framework.

1 Comment

Filed under Cybersecurity

OTTF – Providing a Level of “Surety”

By Joshua Brickman, CA Technologies

A couple of weeks ago while the Supreme Court heard testimony about the constitutionality of “Obamacare,” I was glued to my computer watching the House of Representatives Sub-Committee on Energy and Commerce hear a very different but no less important type of testimony. The topic was supply chain integrity and security.    Two panels appeared before the committee – one containing U.S. government agencies; and the other focused on industry’s response to the issue. Representing industry was Dave Lounsbury from The Open Group.  While it seemed to me that the focus of the committee was the lack of preparedness some agencies had for supply chain attacks, Lounsbury admirably represented how industry is responding to the burgeoning topic with a public/private partnership and a consensus-driven process.

The process he referred to is the Open Trusted Technology Provider Standard (O-TTPS) for which the Open Trusted Technology Forum (OTTF) published a snapshot of this past February. In full disclosure, I represent a founding member of OTTF. You might say I have a vested interest in the O-TTPS becoming the de-facto standard for supply chain integrity and security, and you would be right. But that’s not just because I worked on the creation of this document. It’s because, as Lounsbury emphasized to the House, I believe the right way to ensure the integrity and security for the supply chains of acquirers or purchasers of technology is to build a consensus driven standard that focuses on the best practices needed to ensure the integrity of the product being produced.  This would allow acquirers to buy products with confidence. With this “snapshot” release, we’ve focused on the two most prevalent threats

  1. Tainted product – the product is produced by the provider and is acquired through reputable channels but has been tampered with maliciously.
  2. Counterfeit product – the product is produced other than by, or for, the provider, or is supplied by other than a reputable channel, and is presented as being legitimate.[1]

For the first time, industry has come together and put together a comprehensive set of best practices that, when followed, can help to protect the supply chain for Information and Communication Technology (ICT) products  starting with sourcing, through manufacturing, and ending with delivery to the customer.

But the work is not done. Now that we have a snapshot, the team is working hard to define conformance criteria as well as an accreditation program. The next quarterly meeting at the upcoming Open Group Cannes conference will have some great opportunities for people to hear more about OTTF.

  • Andras Szakal, Chief Technology Officer, IBM U.S. Federal, will present as a part of the Open Trusted Technology Track a talk entitled, “The Global Supply Chain: Presentation and Discussion on The Open Group Trusted Technology Forum and the Challenges of Protecting Products Against Counterfeit and Tampering”
  • Sally Long, Director, The Open Group Trusted Technology Forum, U.S., will follow with “The Global Supply Chain: Presentation and Discussion on The Open Group Trusted Identifying Trusted Technology Providers – What are the Conformance Criteria that Technology Providers and their Component Suppliers need to Meet to be Considered Trusted Technology Providers?”

When Rep. Terry from Nebraska asked Lounsbury if additional definition (regulations) was needed for ensuring the integrity of the supply chain, Lounsbury answered perfectly when he said: “Ultimately the use of COTs implies that an agency purchases from a commercial marketplace. The question is what are the standards that your supplier uses to demonstrate that they can be trusted? Part of that would be the processes they have for themselves throughout their product development and fulfillment lifecycle but also are they imposing those standards on their suppliers as well.”

Rep. Terry followed up:  “Do you think that is sufficient? How do they have a level of surety that somethings not being compromised way down the assembly line?”

Lounsbury:  “In the commercial world typically we look to some sort of a conformance program in which a supplier would submit evidence either through a third party lab and certainly to an independent certification authority to make sure in fact that they have some evidence of those best practices before they are recognized as a trusted partner.”

It’s clear that government is concerned about this issue. The OTTF is building a standard that customers can point to and ask suppliers about. When the OTTF finishes its conformance criteria, rolls out the accreditation program and vendors become accredited, that will help provide a level of “surety” that Rep. Terry and others on the committee want.

Joshua Brickman, project management professional, runs CA Technologies Federal Certifications Program. He has led CA through the successful evaluation of sixteen products through the Common Criteria over the last five years (in both the U.S. and Canada). Brickman has given talks at the last four International Common Criteria Conferences. Most recently, he has been a Steering Committee member on the Open Group consortium focused on Supply Chain Integrity and Security, The Trusted Technology Forum. He also runs CA Technologies Accessibility Program. 

[1] Open Trusted Technology Provider Standard (O-TTPS), Catalog number S121, Feb 2012, p1-2

Comments Off

Filed under Conference, O-TTF, OTTF, Standards, Supply chain risk

A First Step in Securing the Global Technology Supply Chain: Introducing The Open Group Trusted Technology Provider Framework Whitepaper

By Andras Szakal, IBM

Nearly two months ago, we announced the formation of The Open Group Trusted Technology Forum (OTTF), a global standards initiative among technology companies, customers, government and supplier organizations to create and promote guidelines for manufacturing, sourcing, and integrating trusted, secure technologies. The OTTF’s purpose is to shape global procurement strategies and best practices to help reduce threats and vulnerabilities in the global supply chain. I’m proud to say that we have just completed our first deliverable towards achieving our goal: The Open Trusted Technology Provider Framework (O-TTPF) whitepaper.

The framework outlines industry best practices that contribute to the secure and trusted development, manufacture, delivery and ongoing operation of commercial software and hardware products. Even though the OTTF has only recently been announced to the public, the framework and the work that led to this whitepaper have been in development for more than a year: first as a project of the Acquisition Cybersecurity Initiative, a collaborative effort facilitated by The Open Group between government and industry verticals under the sponsorship of the U.S. Department of Defense (OUSD (AT&L)/DDR&E). The framework is intended to benefit technology buyers and providers across all industries and across the globe concerned with secure development practices and supply chain management.

More than 15 member organizations joined efforts to form the OTTF as a proactive response to the changing cybersecurity threat landscape, which has forced governments and larger enterprises to take a more comprehensive view of risk management and product assurance. Current members of the OTTF include Atsec, Boeing, Carnegie Mellon SEI, CA Technologies, Cisco Systems, EMC, Hewlett-Packard, IBM, IDA, Kingdee, Microsoft, MITRE, NASA, Oracle, and the U.S. Department of Defense (OUSD(AT&L)/DDR&E), with the Forum operating under the stewardship and guidance of The Open Group.

Over the past year, OTTF member organizations have been hard at work collaborating, sharing and identifying secure engineering and supply chain integrity best practices that currently exist.  These best practices have been compiled from a number of sources throughout the industry including cues taken from industry associations, coalitions, traditional standards bodies and through existing vendor practices. OTTF member representatives have also shared best practices from within their own organizations.

From there, the OTTF created a common set of best practices distilled into categories and eventually categorized into the O-TTPF whitepaper. All this was done with a goal of ensuring that the practices are practical, outcome-based, aren’t unnecessarily prescriptive and don’t favor any particular vendor.

The Framework

The diagram below outlines the structure of the framework divided into categories that outline a hierarchy of how the OTTF arrived at the best practices it created.

Trusted Technology Provider Categories

Best practices were grouped by category because the types of technology development, manufacturing or integration activities conducted by a supplier are usually tailored to suit the type of product being produced, whether it is hardware, firmware, or software-based. Categories may also be aligned by manufacturing or development phase so that, for example, a supplier can implement a Secure Engineering/Development Method if necessary.

Provider categories outlined in the framework include:

  • Product Engineering/Development Method
  • Secure Engineering/Development Method
  • Supply Chain Integrity Method
  • Product Evaluation Method

Establishing Conformance and Determining Accreditation

In order for the best practices set forth in the O-TTPF to have a long-lasting effect on securing product development and the supply chain, the OTTF will define an accreditation process. Without an accreditation process, there can be no assurance that a practitioner has implemented practices according to the approved framework.

After the framework is formally adopted as a specification, The Open Group will establish conformance criteria and design an accreditation program for the O-TTPF. The Open Group currently manages multiple industry certification and accreditation programs, operating some independently and some in conjunction with third party validation labs. The Open Group is uniquely positioned to provide the foundation for creating standards and accreditation programs. Since trusted technology providers could be either software or hardware vendors, conformance will be applicable to each technology supplier based on the appropriate product architecture.

At this point, the OTTF envisions a multi-tiered accreditation scheme, which would allow for many levels of accreditation including enterprise-wide accreditations or a specific division. An accreditation program of this nature could provide alternative routes to claim conformity to the O-TTPF.

Over the long-term, the OTTF is expected to evolve the framework to make sure its industry best practices continue to ensure the integrity of the global supply chain. Since the O-TTPF is a framework, the authors fully expect that it will evolve to help augment existing manufacturing processes rather than replace existing organizational practices or policies.

There is much left to do, but we’re already well on the way to ensuring the technology supply chain stays safe and secure. If you’re interested in shaping the Trusted Technology Provider Framework best practices and accreditation program, please join us in the OTTF.

Download the O-TTPF, or visit read the OTTPF in full here.

Andras Szakal is an IBM Distinguished Engineer and Director of IBM’s Federal Software Architecture team. Andras is an Open Group Distinguished Certified IT Architect, IBM Certified SOA Solution Designer and a Certified Secure Software Lifecycle Professional (CSSLP). His responsibilities include developing e-Government software architectures using IBM middleware and leading the IBM U.S. Federal Software IT Architect Team. His team is responsible for designing solutions to enable smarter government by applying innovative approaches to secure service based computing and mission critical systems. He holds undergraduate degrees in Biology and Computer Science and a Masters Degree in Computer Science from James Madison University. Andras has been a driving force behind IBM’s adoption of federal government IT standards as a member of the IBM Software Group Government Standards Strategy Team and the IBM Corporate Security Executive Board focused on secure development and cybersecurity. Andras represents the IBM Software Group on the Board of Directors of The Open Group and currently holds the Chair of the IT Architect Profession Certification Standard (ITAC). More recently he was appointed chair of The Open Trusted Technology Forum.

4 Comments

Filed under Cybersecurity, Supply chain risk

The Trusted Technology Forum: Best practices for securing the global technology supply chain

By Mary Ann Davidson, Oracle

Hello, I am Mary Ann Davidson. I am the Chief Security Officer for Oracle and I want to talk about The Open Group Trusted Technology Provider Frameworkhardware (O-TTPF). What, you may ask, is that? The Trusted Technology Forum (OTTF) is an effort within The Open Group to develop a body of practices related to software and hardware manufacturing — the O-TTPF — that will address procurers’ supply chain risk management concerns.

That’s a mouthful, isn’t it? Putting it in layman’s terms, if you are an entity purchasing hardware and software for mission-critical systems, you want to know that your supplier has reasonable practices as to how they build and maintain their products that addresses specific (and I would argue narrow, more on which below) supply chain risks. The supplier ought to be doing “reasonable and prudent” practices to mitigate those risks and to be able to tell their buyers, “here is what I did.” Better industry practices related to supply chain risks with more transparency to buyers are both, in general, good things.

Real-world solutions

One of the things I particularly appreciate is that the O-TTPF is being developed by, among others, actual builders of software and hardware. So many of the “supply chain risk frameworks” I’ve seen to date appear to have been developed by people who have no actual software development and/or hardware manufacturing expertise. I think we all know that even well-intended and smart people without direct subject matter experience who want to “solve a problem” will often not solve the right problem, or will mandate remedies that may be ineffective, expensive and lack the always-needed dose of “real world pragmatism.”  In my opinion, an ounce of “pragmatic and implementable” beats a pound of “in a perfect world with perfect information and unlimited resources” any day of the week.

I know this from my own program management office in software assurance. When my team develops good ideas to improve software, we always vet them by our security leads in development, to try to achieve consensus and buy-in in some key areas:

  • Are our ideas good?
  • Can they be implemented?  Specifically, is our proposal the best way to solve the stated problem?
  • Given the differences in development organizations and differences in technology, is there a body of good practices that development can draw from rather than require a single practice for everyone?

That last point is a key one. There is almost never a single “best practice” that everybody on the planet should adhere in almost any area of life. The reality is that there are often a number of ways to get to a positive outcome, and the nature of business – particularly, the competitiveness and innovation that enables business – depends on flexibility.  The OTTF is outcomes-focused and “body of practice” oriented, because there is no single best way to build hardware and software and there is no single, monolithic supply chain risk management practice that will work for everybody or is appropriate for everybody.

BakingIt’s perhaps a stretch, but consider baking a pie. There is – last time I checked – no International Organization for Standardization (ISO) standard for how to bake a cherry pie (and God forbid there ever is one). Some people cream butter and sugar together before adding flour. Other people dump everything in a food processor. (I buy pre-made piecrusts and skip this step.) Some people add a little liqueur to the cherries for a kick, other people just open a can of cherries and dump it in the piecrust. There are no standards organization smack downs over two-crust vs. one-crust pies, and whether to use a crumble on the top or a pastry crust to constitute a “standards-compliant cherry pie.” Pie consumers want to know that the baker used reasonable ingredients – piecrust and cherries – that none of the ingredients were bad and that the baker didn’t allow any errant flies to wander into the dough or the filling. But the buyer should not be specifying exactly how the baker makes the pie or exactly how they keep flies out of the pie (or they can bake it themselves). The only thing that prescribing a single “best” way to bake a cherry pie will lead to is a chronic shortage of really good cherry pies and a glut of tasteless and mediocre ones.

Building on standards

Another positive aspect of the O-TTPF is that it is intended to build upon and incorporate existing standards – such as the international Common Criteria – rather than replace them. Incorporating and referring to existing standards is important because supply chain risk is not the same thing as software assurance — though they are related. For example, many companies evaluate ­one or more products, but not all products they produce. Therefore, even to the extent their CC evaluations incorporate a validation of the “security of the software development environment,” it is related to a product, and not necessarily to the overall corporate development environment. More importantly, one of the best things about the Common Criteria is that it is an existing ISO standard (ISO/IEC 15408:2005) and, thanks to the Common Criteria recognition arrangement (CCRA), a vendor can do a single evaluation accepted in many countries. Having to reevaluate the same product in multiple locations – or having to do a “supply chain certification” that covers the same sorts of areas that the CC covers – would be wasteful and expensive. The O-TTPF builds on but does not replace existing standards.

Another positive: The focus I see on “solving the right problems.” Too many supply chain risk discussions fail to define “supply chain risk” and in particular define every possible concern with a product as a supply chain risk. (If I buy a car that turns out to be a lemon, is it a supply chain risk problem? Or just a “lemon?”) For example, consider a system integrator who took a bunch of components and glued them together without delivering the resultant system in a locked down configuration. The weak configuration is not, per se, a supply chain risk; though arguably it is poor security practice and I’d also say it’s a weak software assurance practice. With regard to OTTF, we defined “supply chain attack” as (paraphrased) an attempt to deliberately subvert the manufacturing process rather than exploiting defects that happened to be in the product. Every product has defects, some are security defects, and some of those are caused by coding errors. That’s a lot different – and profoundly different — from someone putting a back door in code. The former is a software assurance problem and the second is a supply chain attack.

Why does this matter? Because supply chain risk – real supply chain risk, not every single concern either a vendor or a customer could have aboutManufacturing a product – needs focus to be able to address the concern. As has been said about priorities, if everything is priority number one, then nothing is.  In particular, if everything is “a supply chain risk,” then we can’t focus our efforts, and hone in on a reasonable, achievable, practical and implementable set  – “set” meaning “multiple avenues that lead to positive outcomes” – of practices that can lead to better supply chain practices for all, and a higher degree of confidence among purchasers.

Consider the nature of the challenges that OTTF is trying to address, and the nature of the challenges our industry faces, I am pleased that Oracle is participating in the OTTF. I look forward to working with peers – and consumers of technology – to help improve everyone’s supply chain risk management practices and the confidence of consumers of our technologies.

Mary Ann DavidsonMary Ann Davidson is the Chief Security Officer at Oracle Corporation, responsible for Oracle product security, as well as security evaluations, assessments and incident handling. She had been named one of Information Security’s top five “Women of Vision,” is a Fed100 award recipient from Federal Computer Week and was recently named to the Information Systems Security Association Hall of Fame. She has testified on the issue of cybersecurity multiple times to the US Congress. Ms. Davidson has a B.S.M.E. from the University of Virginia and a M.B.A. from the Wharton School of the University of Pennsylvania. She has also served as a commissioned officer in the U.S. Navy Civil Engineer Corps. She is active in The Open Group Trusted Technology Forum and writes a blog at Oracle.

6 Comments

Filed under Cybersecurity, Supply chain risk