atsec and supply chain security

Supply chain assurance: mitigate the threats of counterfeit and tainted products, globally. Quite a challenge!

To do that we'd need some of the best subject matter experts in the world.

Build a new industry-led open standard and an assessment program that can demonstrate to integrators and acquirers of COTS ICT products that their providers are Trusted Technology ProvidersTM and who can demonstrate that they follow industry best practices in mitigating the threats of counterfeit and maliciously tainted products.

Yes! We need some experts...

atsec has been working closely with The Open Group Trusted Technology Forum (OTTF) since it began in late 2010. For the last three years we've been dedicating a great many hours, alongside our OTTF colleagues with representatives from providers, acquirers and assessors, all working together to progress an  industry vision for an open voluntary standard and an associated accreditation program for trusted technology in relation to supply chain security.

Together, the OTTF have worked very hard.

We developed and published a white paper, a snapshot of the standard, and the O-TTPS standard itself. We have collaborated, presented and harmonized.

We have looked for and found consensus amongst many key organizations. It took blood, sweat and tears!

• We worked with some of the major names in the I.T. industry for security assurance, including many of the major global players in the industry.
• We worked with governments around the world. 
• We worked amongst a time of change within (U.S.) government agencies.

Believe me, finding consensus in such a diverse and knowledgeable set of people was never going to be an easy task!

Finally, we have been working hard on an Accreditation Program and piloting the model in real world assessments. This way we had the chance to iron out some of the wrinkles before the accreditation program became public.

Well, the launch of the assessment program is finally here: February 3rd, 2014; three years after we began work. A short eternity perhaps, but an era that has demonstrated a great achievement.

As atsec worked with the pilots for the accreditation program we had the experience of training and qualifying our assessor teams in. We drew from those with experience in testing,evaluating and of course assessing. Here is a quote from Courtney Cavness, one of our process assessment experts:
"Working as an Assessor on this pilot was a tremendous learning experience. I enjoyed applying my previous audit/evaluation experience to this new standard to help refine and enhance both the standard and the accreditation program."

Another of our senior assessors, King Ables, said  that: 

"This important new standard fills a gap in the spectrum of assurance measures available to product developers and end users. As an early Recognized Assessor, atsec participated in a pilot assessment to "test drive" the standard. This pilot allowed us to gain practical experience with O-TTPS as well as to provide suggestions for improvements based on our other security assessment experience."

The new Accreditation Program, which has been running in pilot mode since last year, already has  one completed accreditation under its belt. An achievement not to be sneezed at!

atsec thanks IBM for the opportunity to participate in the pilot phase and for assigning some of their senior experts in the field to the project which helped the project go very smoothly. 

For a list of  completed and approved accreditations, and their scope's see The Open Group's accreditation register.

Well known and global Trusted Technology Providers have placed enough credence in the program to actively participate; and two respected assessor companies in the field of information assurance also invested in helping to develop and test the program and are the first "Recognized Assessors" working with The Open Group's O-TTPS independent Accreditation Authority to help providers "Build with Integrity" which then allows their acquirer and integrator customers to "Buy with Confidence."

With wide across-the-board participation in the OTTF, we heard a very important message: resources available for providing assurance are scarce and nobody wants to do or pay more than once for the same thing. I believe that the Accreditation Program has incorporated this requirement. It allows for appropriate re-use of assurance already gained.

The OTTF are continuing to work hard on this topic, forging appropriate alliances in the field of information security and information assurance.

Of course it remains to be seen if the program will engender enough trust and confidence to be useful assurance for those eager to have it, but so far all the indications are that it will.

Fiona Pattinson

O-TTPS Consensus!

It's always a heartening moment when the consensus of leading industry experts is reached. Achieving consensus is a process that can sometimes take years. A period in which world-class experts thought and "fought,"  researched, discussed, and drank a lot of coffee. Sometimes it seemed that consensus might never be achieved as the application of collective expertise and coordination of the many different "agendas" associated with a difficult and developing subject area were brought together to synthesize  a new industry norm.

We did it !

 

Thanks to the members of The Open Group Trusted Technology Forum (OTTF), the Open Trusted Technology Provider Standard  (O-TTPS)  has been published. A set of guidelines, requirements, and recommendations that address specific threats to the integrity of hardware and software Commercial Off The Shelf (COTS) Information and Communication Technology (ICT) products throughout the product life cycle.
Public News Release:

Threats of counterfeit and maliciously tainted products

After consulting with several key users of COTS ICT products it was apparent that the initial release of O-TTPS should address the worrying threats of maliciously tainted and counterfeit products. These two threats are identified as key threats to users of COTS ICT products which are often deployed in the world's critical infrastructures.

It is important to understand the O-TTPS definitions of these two terms as they are key to understanding the entire standard:

• Maliciously tainted product - the product is produced by the provider and is acquired through a provider’s authorized channel, but has been tampered with maliciously.
• Counterfeit product - the product is produced other than by, or for, the provider, or is supplied to the provider by other than a provider’s authorized channel and is presented as being legitimate even though it is not.

How does O-TTPS fit into a complete real-world supply chain?

Before you throw up your hands in horror at the observation that O-TTPS does not address everything to do with a complete real-world supply chain you should consider that no single standard can expect to address everything at once. The OTTF has and continues to work very closely with other organizations that focus on different views of the supply chain. The topic is large, complex and dynamic. To be successful, coordination from many viewpoints is extremely important. What is included in O-TTPS is coverage of the essential interfaces to both upstream and downstream entities which will allow for a chain of assurance to be built.

For example, downstream from the O-TTPS:

• NIST is drafting a special publication, NIST Special Publication 800-161, Supply Chain Practices for Federal Information Systems, which plans to address supply chain issues from the government acquirers viewpoint and relating it to the end-user viewpoint. The latter is already addressed in Special Publication 800-53, Revision 4, Security and Privacy Controls for Federal information Systems and Organizations, and the supporting documents.
• ISO is working on related standards including ISO/IEC 27036, Information Security for Supplier Relationships, which will be a multi-part standard including sections titled Overview and Concepts, Common Requirements, Guidelines for ICT Supply Chain Security and Guidelines for Security of Outsourcing; all of which are currently under development in ISO's IT security techniques sub-committee (27).

Upstream from O-TTPS are a plethora of standards, both published and in the process of being drafted, which are appropriate to the gamut of industry segments, from aerospace to utilities. These are often very specialized and focused on particular technologies. As a single example, the NASPO standard addresses supply chain security issues related to security documents, such as passports, tamper labels, credit cards, money, and so on. 

The OTTF also identified and worked on the relationship to product and component certifications, such as Common Criteria, FIPS 140-2, and others. These product security assurance standards already address some of the requirements identified in the O-TTPS and the OTTF has been working hard to discover where such existing assurance may be meaningfully reused.

O-TTPS does not promise total freedom from the existence of counterfeit or maliciously tainted products

Of course it would be ridiculous to think that it could! What O-TTPS does promise is that an organization which implements the requirements of O-TTPS will have reduced the risks associated with the threats of counterfeiting and maliciously tainted products or components.
The OTTF's trademarked tagline says it all:

"Build with integrity buy with confidence"TM

However, even with the development of standards and guidelines addressing this topic, the principle of "caveat emptor" must still apply.

About the O-TTPS

I'm not going to reproduce the standard here. It is freely available direct from The Open Group. Here I will give a very high level overview of what is included. Perhaps it will be enough to whet your appetite and encourage you to find out more about the O-TTPS.

The first sections introduce the standard, provide context and overview, precisely define the terms that are used, as well as describe the specific threats that the standard addresses. These are always the most important sections of a standard to read if you really expect to have a full understanding of how the standard is expected to work.

Next, the O-TTPS builds a framework upon which the various best practices for supply chain security (known as "requirements") are organized. All of the requirements given in the O-TTPS have been considered as contributing to countering the risks associated with the above threats.

The diagram below shows the O-TTPS defined Framework Model:

In the following diagram you can see how the requirements are identified and presented in O-TTPS framework.

What is next?

Currently the O-TTF is working on a proposed accreditation program for the standard. Such a program will allow organizations to demonstrate that they conform to the  requirements of the standard, and hence build products with integrity and as a consequence provide an opportunity for acquirers to buy with confidence.

Already some forward thinking acquirers have recommended the O-TTPS to their suppliers. This is a good sign for the future.

Impressions from the 12th International Common Criteria Conference

by Courtney Cavness

atsec had several presenters and attendees at the 12th annual ICCC in Kuala Lumpur, Malaysia.

As a presenter, I can say it was an honor to speak at the conference, and have the extended opportunity to exchange ideas with other experts in the security industry. The host of the event, CyberSecurity Malaysia, graciously shared with us a taste of their country's culture and cuisine, which includes Malay, Chinese, and Indian cultures, and to a lesser extent Persian, Arabic, and British influences. Their theme, "One Malaysia," was the perfect embodiment of the CC itself; several different interests and cultures coming together in harmony to create a unique and diverse environment. It was a wonderful and beneficial experience to be there.

I attended many presentations in each of the three different track sessions: CC formalities, technical use of the CC, and aspects of CC application. The sessions varied from many interesting topics such as how SCAP can be used with the CC, industry-stated issues with supply chain security, and updates from the schemes of various countries. Also of interest to me personally were talks on foreseen problems with cloud computing, attribute similarities between the CC and FIPS 140-2 evaluations, and different countries' experiences with implementing CC training in unique and different ways.

Above and beyond the presentations, the conference offered the invaluable opportunity to put a name to a face. Many attendees were able to meet with vendors, lab representatives, and country delegates and get an understanding of what they need the CC to do. The task now is to take that input and help ensure that everyone who has a stake in the CC is being heard and appropriate updates are made.

What was surprising to me was that there was a vast majority of agreement between schemes, vendors, and delegates as to what the issues are with the CC. The conference gave us a platform to share these ideas, as well as our individual successes in working with the CC -- a global standard meant to meet global security needs.

My personal take-away from this conference is that having a standard that is accepted and successfully implemented by product vendors requires a balance between process and common sense. If you eliminate the steps required in a standard for the sake of expediency, you could easily lose some evidence of due diligence. By the same token, if too many checklists are in place, then certification could risk becoming a series of hoops to jump through for reasons that may be lost on the parties involved.

How then is balance best achieved? When many and diverse stakeholders have a voice in enforcing and updating the standard. This is another benefit of attending the ICCC conference.

atsec is invested in seeing the CC thrive and remain a vital part of the security industry, and will continue to attend these conferences and do our part to help raise security awareness, contribute to meaningful updates of the CC, and be a part of the CC community to strengthen and empower all of its constituents.

You can find atsec’s presentations from the ICCC on our website.

The supply chain and re-use of software and hardware

by Courtney Cavness

In many prominent IT security standards, there are no specific guidelines defining what constitutes an acceptance procedure when an organization incorporates 3rd-party code into their product.

Perhaps because there are no standard specifications, many IT companies undergoing security evaluation are not implementing a manual review of this 3rd-party code, especially on large, open source material such as kernels and libraries. If IT companies that are seeking security certification for their product are not performing such reviews, it must be reflective of the real-world practice of the vast majority of all IT companies. It saves money to re-use code. Unfortunately, code developed/modified by someone outside your organization is inherently untrusted. And the practice of including this untrusted code has led to the introduction of many vulnerabilities, as discussed in a recent report issued by Veracode.

The following report outlines some statistics on the types of vulnerabilities that can be traced back to the inclusion of 3rd-party code in a product, and highlights the fact that use of 3rd-party code is so commonplace that some organizations don't recognize that components originated outside their development environment. In fact, third party code was found to be a major source of application vulnerabilities - and to be ubiquitous. Between 30% and 70 of applications submitted to Veracode as "internally developed" were found to contain code from third party suppliers, according to Chris Eng, Senior Director of Security Research at Veracode. Report: Reused, Third Party Code Major Sources of Insecurity

The following white paper discusses specific features of what could constitute acceptance procedures for the Common Criteria security standard at evaluation assurance levels EAL3 and EAL4. Untrusted Developers- Code Integrity in a Distributed Development Environment.

And according to the following article featured in Scientific American, this problem can also affect hardware, especially integrated circuits, because of the inherent business model of chip design that incorporates circuits designed in multiple world-wide locations by various firms. As the article points out, the very nature of physical hardware attacks makes them difficult to test for and to correct once identified (unlike software that can be wiped clean from a system). The Hacker in Your Hardware.

In the end, there are no shortcuts to security. Although it may save money, time, and development effort to re-use code, an IT organization that incorporates malicious or vulnerable code in its products doesn't really save much at all when they pass along that code to their end users.