Some Efficiencies in the O-TTPS Accreditation Program

One of the nice things about working with the OTTF and The Open Group TM in developing their O-TTPS Accreditation Program has been the emphasis that the forum members placed on efficiency within the program.

One of the major gripes in the IT assurance community is that we seem to do the same things over and over again.

That costs us precious resources, people, money and time and was pointed out by many of the members of the OTTF.

Mary Ann Davidson of Oracle, as usual, expressed the problem very well: "Doing the same thing twice or more unintentionally usually ends up with worse security as we use scarce resources on duplicative measures."

For developers, how many times do they really have to get their processes checked to see if, for example, they use an automated configuration management system, and that they have implemented access control for it. Such checks are made over and over again if they need to certify products under a variety of assessment programs.

For some of our customers, we have checked this close to a hundred times over the last decade.

Using the above example, the checks are made if a product from the developer needs FIPS 140-2, Common Criteria, O-TTPS assessment, etc., etc. It's both inefficient and expensive for the developers.
These overlaps are prevalent and extend to many of the organizations' processes, not just to configuration management.

Similarly, for mature IA assessment companies like atsec, we find that all of the various programs that we are involved with demand that we have certified management systems. The problem is that there are a variety of standards and a variety of certification programs to choose from.

In atsec's case, this has meant that we have to, across our small company of less than 100 people, to manage, endure and pay for many management system audits; It is a cost of our doing business, but a real pain in the... .

We have:

• ISO/IEC 17025: 2 for NVLAP (don't ask!), BSI, FMV, and by ISCCC;
• Technical competence audits: CMVP, NIAP, GSA, BSI, CSEC, O-TTPS;
• PCI SSC: (not based on international standard);
• ISO 9001 (Customer demand);
• ISO/IEC 27001  (Customer demand);
• and soon to ISO/IEC 17020.

None of the our auditors are allowed to accept the results from the others. Granted, each scheme requires a different technical competence, but our document and record control, HR, training, resource management, corrective and preventive actions, internal audit, calibration, etc. are the same for all of the programs to which we belong.

atsec customers can be assured that our management system is well audited!

.. back to the O-TTPS Accreditation Program: 

The forum saw the chance to try and address this issue: The notion of carefully reusing existing assurance was one of the factors we considered during each stage of developing the new O-TTPS Accreditation Program.

Here are some of the efficiencies that we identified and that the Accreditation Program has implemented:

• The ability for O-TTPS assessors to reuse existing audit reports presented by the developer. These might include, where relevant, ISO 9001, security audits, Common Criteria site visits, etc.
  Note that there are some careful provisions, which are detailed in the Assessment Procedures.
• Currently under development: The provision of mappings, allowing the work done for existing product certifications, such as Common Criteria, to be more easily mapped to the O-TTPS requirements.
• For prospective Recognized Assessor companies and assessors, the ability to accept a variety of existing certifications of management systems and assessor qualifications that address the core skills needed as information assurance (IA) professionals. This allows The Open Group to concentrate only on the additional specialised skills needed for the O-TTPS accreditation program.

Although simple policies, they allow the program to be more efficient, reducing the overhead of unnecessary duplication, meaning that the costs of accreditation are not overburdened. These reduce the costs of assessment, to all parties involved: The Accreditation Authority, the Recognized Assessors and to the Organizations undergoing accreditation.

Not only that, but we can concentrate more on the important issue of integrity in the COTS ICT Supply Chains.

Thank you to the OTTF for living in the real world! :)

~ Fiona Pattinson

- "The Open Group" is a trademark of The Open Group

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.

White Paper: Untrusted Developers - Code Integrity in a Distributed Development Environment

by Courtney Cavness, Helmut Kurth and Stephan Mueller.

It is becoming commonplace for organizations to use third-parties to develop or test their source code (including using third party libraries) for business reasons, such as reducing development costs. But when the code is developed or modified by unknown and untrusted developers, how can an organization have confidence that the third-party code used in their product is not malicious and does not inadvertently introduce vulnerabilities? The authors analyzed the intent of the personnel and physical security requirements for the development environment in the Common Criteria (CC) standard and propose a solution for this scenario, which is for vetted employee(s) of the organization to perform an acceptance procedure of the code. The acceptance procedure must include a manual review to look for malicious code, unintentional vulnerabilities, and back doors, and otherwise attempt to ensure that the third-party code performs the expected — and only the expected — functionality before it is integrated into the product. The CC should be updated to include the specification and definition of an acceptance procedure to reflect the growing trend of organizations that routinely receive source code development and/or test services on components included in their products.

You can download the White Paper "Untrusted Developers" from our website.