Dana Gardner's BriefingsDirect: Explore the role and impact of the Open Trusted Technology Forum to help ensure secure IT products in global supply chains

Friday, February 18, 2011

Explore the role and impact of the Open Trusted Technology Forum to help ensure secure IT products in global supply chains

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Get the free white paper. Sponsor: The Open Group.

Join a panel discussion that examines The Open Group’s new Open Trusted Technology Forum (OTTF), established in December to find ways to safely conduct global procurement and supply-chain commerce among and between technology acquirers and buyers.

The forum is tasked with providing transparency, collaboration, innovation, and more trust on the partners and market participants in a IT supplier environment. The goal is for the OTTF to lead to improved business risk for global supply activities in the IT field. [Get the new free OTTF white paper.]

Presented in conjunction with The Open Group Conference held in San Diego, the week of Feb. 7, the panel of experts examines how the OTTF will function, what its new framework will be charged with providing, and ways that participants in the global IT commerce ecosystem can become involved with and perhaps use the OTTF’s work to their advantage.

Here with us to delve into the mandate and impact of the Open Trusted Technology Forum is the panel: Dave Lounsbury, Chief Technology Officer for The Open Group; Steve Lipner, Senior Director of Security Engineering Strategy in Microsoft’s Trustworthy Computing Group; Andras Szakal, Chief Architect in IBM’s Federal Software Group and an IBM distinguished engineer, and Carrie Gates, Vice President and Research Staff Member at CA Labs. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Lounsbury: The OTTF is a group that came together under the umbrella of The Open Group to identify and develop standards and best practices for trusting supply chains. It's about how one consumer in a supply chain could trust their partners and how they will be able to indicate their use of best practices in the market, so that people who are buying from the supply chain or buying from a specific vendor will be able to know that they can procure this with a high level of confidence.

This actually started a while ago at The Open Group by a question from the U.S. Department of Defense (DoD), which faced the challenge of buying commercial off-the-shelf product. Obviously, they wanted to take advantage of the economies of scale and the pace of technology in the commercial supply chain, but realized that means they're not going to get purpose-built equipment, that they are going to buy things from a global supply chain.

If you pick up any piece of technology, for example, it will be designed in the US, assembled in Mexico, and built in China. So we need that international and global dimension in production of this set of standards as well.

They asked, "What would we look for in these things that we are buying to know that people have used good engineering practices and good supply chain management practices? Do they have a good software development methodology? What would be those indicators?"

Now, that was a question from the DoD, but everybody is on somebody’s supply chain. People buy components. The big vendors buy components from smaller vendors. Integrators bring multiple systems together.

So, this is a really broad question in the industry. Because of that, we felt the best way to address this was bring together a broad spectrum of industry to come in, identify the practices that they have been using -- your real, practical experience -- and bring that together within a framework to create a standard for how we would do that.

Szakal: In today’s environment, we're seeing a bit of a paradigm shift. We're seeing technology move out of the traditional enterprise infrastructure. We're seeing these very complex value chains be created. We're seeing cloud computing.

Smarter infrastructures

We're actually working to create smarter infrastructures that are becoming more intelligent, automated, and instrumented, and they are very much becoming open-loop systems.

As technology becomes more pervasive and gets integrated into these environments, into the critical infrastructure, we have to consider whether they are vulnerable and how the components that have gone into these solutions are trustworthy.

Governments worldwide are asking that question. They're worried about critical infrastructure and the risk of using commercial, off-the-shelf technology -- software and hardware -- in a myriad of ways, as it gets integrated into these more complex solutions.

Part of our focus here is to help our constituents, government customers and critical infrastructure customers, understand how the commercial technology manufacturers, the software development manufactures, go about engineering and managing their supply chain integrity.

[The OTTF] is about all types of technology. Software obviously is a particularly important focus, because it’s at the center of most technology anyway. Even if you're developing a chip, a chip has some sort of firmware, which is ultimately software. So that perception is valid to a certain extent, but no, not just software, hardware as well.

Our vision is that we want to leverage some of the capability that's already out there. Most of us go through common criteria evaluations and that is actually listed as a best practice for a validating security function and products.

Where we are focused, from a [forthcoming] accreditation point of view, affects more than just security products. That's important to know. However, we definitely believe that the community of assessment labs that exists out there that already conducts security evaluations, whether they be country-specific or that they be common criteria, needs to be leveraged. We'll endeavor to do that and integrate them into both the membership and the thinking of the accreditation process.

Lounsbury: The Open Group provides the framework under which both buyers and suppliers at any scale could come together to solve a common problem -- in this case, the question of providing trusted technology best practices and standards. We operate a set of proven processes that ensure that everyone has a voice and that all these standards go forward in an orderly manner.

The new OTTF white paper actually lays out the framework. The work of forum is to turn that framework into an Open Group standard and populate it. That will provide the standards and best practice foundation for this conformance program. [Get the new free OTTF white paper.]

We're just getting started on the vision for a conformance program. One of the challenges here is that first, not only do we have to come up with the standard and then come up with the criteria by which people would submit evidence, but you also have to deal with the problem of scale.

If we really want to address this problem of global supply chains, we're talking about a very large number of companies around the world. It’s a part of the challenge that the forum faces.

Accrediting vendors

Part of the work that they’ve embarked on is, in fact, to figure out how we wouldn't necessarily do that kind of conformance one on one, but how we would accredit either vendors themselves who have their own duty of quality processes as a big vendor would or third parties who can do assessments and then help provide the evidence for that conformance.

We're getting ahead of ourselves here, but there would be a certification authority that would verify that all the evidence is correct and grant some certificate that says that they have met some or all of the standards.
The white paper actually lays out the framework. The work of forum is to turn that framework into an Open Group standard and populate it.

We provide infrastructure for doing that ... The Open Group operates industry-based conformance programs, the certification programs, that allow someone who is not a member to come in and indicate their conformance standard and give evidence that they're using the best practices there.

Lipner: Build with integrity really means that the developer who is building a technology product, whether it be hardware or software, applies best practices and understood techniques to pr event the inclusion of security problems, holes, bugs, in the product -- whether those problems arise from some malicious act in the supply chain or whether they arise from inadvertent errors. With the complexity of modern software, it’s likely that security vulnerabilities can creep in.

So, what build with integrity really means is that the developer applies best practices to reduce the likelihood of security problems arising, as much as commercially feasible.

And not only that, but any given supplier has processes for convincing himself that upstream suppliers, component suppliers, and people or organizations that he relies on, do the same, so that ultimately he delivers as secure a product as possible.

Creating a discipline

One of the things we think that the forum can contribute is a discipline that governments and potentially other customers can use to say, "What is my supplier actually doing? What assurance do I have? What confidence do I have?"

To the extent that the process is successful, why then customers will really value the certification? And will that open markets or create preferences in markets for organizations that have sought and achieved the certification?

Obviously, there will be effort involved in achieving [pending OTTF] certification, but that will be related to real value, more trust, more security, and the ability of customers to buy with confidence.

The challenge that we'll face as a forum going forward is to make the processes deterministic and cost-effective. I can understand what I have to do. I can understand what it will cost me. I won't get surprised in the certification process and I can understand that value equation. Here's what I'm going to have to do and then here are the markets and the customer sets, and the supply chains it's going to open up to me.

International trust

Gates: This all helps tremendously in improving trust internationally. We're looking at developing a framework that can be applied regardless of which country you're coming from. So, it is not a US-centric framework that we'll be using and adhering to.

We're looking for a framework so that each country, regardless of its government, regardless of the consumers within that country, all of them have confidence in what it is that we're building, that we're building with integrity, that we are concerned about both malicious acts or inadvertent errors.

And each country has its own bad guy, and so by adhering to international standard we can say we're looking for bad guys for every country and ensuring that what we provide is the best possible software.

If you refer to our white paper, we start to address that there. We were looking at a number of different metrics across the board. For example, what do you have for documentation practices? Do you do code reviews? There are a number of different best practices that are already in the field that people are using. Anyone who wants to be a certified, can go and look at this document and say, "Yes, we are following these best practices" or "No, we are missing this. Is it something that we really need to add? What kind of benefit it will provide to us beyond the certification?"

Lounsbury: The white paper’s name, "The Open Trusted Technology Provider Framework" was quite deliberately chosen. There are a lot of practices out there that talk about how you would establish specific security criteria or specific security practices for products. The Open Trusted Technology Provider Forum wants to take a step up and not look at the products, but actually look at the practices that the providers employ to do that. So it's bringing together those best practices.

Now, good technology providers will use good practices, when they're looking at their products, but we want to make sure that they're doing all of the necessary standards and best practices across the spectrum, not just, "Oh, I did this in this product."

Again, I refer everybody to the white paper, which is available on The Open Group website. You'll see there in the categories that we've divided these kinds of best practice into four broad categories: product engineering and development methods, secure engineering development methods, supply chain integrity methods and the product evaluation methods.

Under there those are the categories, we'll be looking at the attributes that are necessary to each of those categories and then identifying the underlying standards or bits of evidence, so people can submit to indicate their conformance.

I want to underscore this point about the question of the cost to a vendor. The objective here is to raise best practices across the industry and make the best practice commonplace. One of the great things about an industry-based conformance program is that it gives you the opportunity to take the standards and those categories that we've talked about as they are developed by OTTF and incorporate those in your engineering and development processes.
Within secure engineering, for example, one of the attributes is threat assessment and threat modeling.

So you're baking in the quality as you go along, and not trying to have an expensive thing going on at the end.

Szakal: [To attain such quality and lowered risk] we have three broad categories here and we've broken each of the categories into a set of principles, what we call best practice attributes. One of those is secure engineering. Within secure engineering, for example, one of the attributes is threat assessment and threat modeling. Another would be to focus on lineage of open-source. So, these are some of the attributes that go into these large-grained categories.

Unpublished best practices

Steve and I have talked a lot about this. We've worked on his secure engineering initiative, his SDLC initiative within Microsoft. I worked on and was co-author of the IBM Secure Engineering Framework. So, these are living examples that have been published, but are proprietary, for some of the best practices out there. There are others, and in many cases, most companies have addressed this internally, as part of their practices without having to publish them.

Part of the challenge that we are seeing, and part of the reason that Microsoft and IBM went to the length of publishing there is that government customers and critical infrastructure were asking what is the industry practice and what were the best practices.

What we've done here is taken the best practices in the industry and bringing them together in a way that's a non-vendor specific. So you're not looking to IBM, you're not having to look at the other vendors' methods of implementing these practices, and it gives you a non-specific way of addressing them based on outcome.

We believe that this is going to actually help vendors mature in these specific areas. Governments recognize that, to a certain degree, the industry is not a little drunk and disorderly and we do actually have a view on what it means to develop product in a secure engineering manner and that we have supply chain integrity initiatives out there. So, those are very important.

We're not simply focused on a bunch of security controls here. This is industry continuity and practices for supply chain integrity, as well as our internal manufacturing practices around the actual practice and process of engineering or software development, as well as supply chain integrity practices.

That's a very important point to be made. This is not a traditional security standard, insomuch as that we've got a hundred security controls that you should always go out and implement. You're going to have certain practices that make sense in certain situations, depending on the context of the product you're manufacturing.

Gates: In terms of getting started, the white paper is an excellent resource to get started and understand how the OTTF is thinking about the problem. How we are sort of structuring things? What are the high-level attributes that we are looking at? Then, digging down further and saying, "How are we actually addressing the problem?"

We had mentioned threat modeling, which for some -- if you're not security-focused -- might be a new thing to think about, as an example, in terms of your supply chain. What are the threats to your supply chain? Who might be interested, if you're looking at malicious attack, in inserting something into your code? Who are your customers and who might be interested in potentially compromising them? How might you go about protecting them?

The security mindset is a little bit different, in that you tend to be thinking about who is it that would be interested in doing harm and how do you prevent that.

It's not a normal way of thinking about problems. Usually, people have a problem, they want to solve it, and security is an add-on afterward. We're asking that they start that thinking as part of their process now and then start including that as part of their process.

Lipner: We talk about security assurance, and assurance is really what the OTTF is about, providing developers and suppliers with ways to achieve that assurance in providing their customers ways to know that they have done that. This is really not about adding some security band-aid onto a technology or a product. It's really about the fundamental attributes or assurance of the product or technology that’s being produced.