1.1 Objectives

The Open Trusted Technology Provider Standard (O-TTPS) is a set of guidelines, requirements, and recommendations that, when practically applied, create a business benefit in terms of reduced risk of acquiring maliciously tainted or counterfeit products for the technology acquirer. Documenting best practices that have been taken from the experience of mature industry providers, rigorously reviewed through a consensus process, and established as requirements and recommendations in this Standard, can provide significant advantage in establishing a basis to reduce risk. A commitment by technology providers, large and small, suppliers of hardware and software components, and integrators to adopt this Standard is a commitment to using specific methodologies to assure the integrity of their hardware or software Commercial Off-the-Shelf (COTS) Information and Communication Technology (ICT) products. This Standard is detailed and prescriptive enough to be useful in raising the bar for all providers and lends itself to an accreditation process to provide assurance that it is being followed in a meaningful and repeatable manner.

1.2 Overview

This Standard (O-TTPS) is a set of guidelines, requirements, and recommendations that address specific threats to the integrity of hardware and software COTS ICT products throughout the product life cycle. This initial release of the Standard addresses threats related to maliciously tainted and counterfeit products. The provider's product life cycle includes the work it does designing and developing products, as well as the supply chain aspects of that life cycle, collectively extending through the following phases: design, sourcing, build, fulfillment, distribution, sustainment, and disposal. While this Standard cannot fully address threats that originate wholly outside any span of control of the provider – for example, a counterfeiter producing a fake printed circuit board assembly that has no original linkage to the Original Equipment Manufacturer (OEM) – the practices detailed in the Standard will provide some level of mitigation. An example of such a practice would be the use of security labeling techniques in legitimate products. The two major threats that acquirers face today in their COTS ICT procurements, as addressed in this Standard, are defined as: 1. 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. 2. 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. Note: All instances, within this standard, of the use of the words: taint, tainted, tainting, refer to maliciously taint, maliciously tainted, and maliciously tainting, respectively. Trusted Technology Providers manage their product life cycle, including their extended supply chains, through the application of defined, monitored, and validated best practices. The product's integrity is strengthened when providers and suppliers follow the requirements and recommendations specified in this Standard. The industry consensus reflected here and in the Open Trusted Technology Provider Framework (O-TTPF) draws from the following areas that are integral to product integrity: product development/engineering, secure development/engineering, and supply chain security. Additionally, product integrity and supply chain security are enhanced by following practices among suppliers, trading partners, providers, and, when appropriate, acquiring customers to preserve the product's intended configuration. This Standard is focused on the security of the supply chain versus the business management aspects of the supply chain. This Standard takes a comprehensive view about what providers should do in order to be considered a Trusted Technology Provider that "builds with integrity". This includes practices that providers incorporate in their own internal product life cycle processes, that portion of product development that is "in-house" and over which they have more direct operational control. Additionally, it includes the provider's supply chain security practices that need to be followed when incorporating third-party hardware or software components, or when depending on external manufacturing and delivery or supportive services. The Standard makes a distinction between provider and supplier. Suppliers are those upstream vendors who supply components or solutions (software or hardware) to providers or integrators. Providers are those vendors who supply COTS ICT products directly to the downstream integrator or acquirer. Ideally, the guidelines, requirements, and recommendations included in this Standard will be widely adopted by providers and their suppliers regardless of size and will provide benefits throughout the industry. For this version of the Standard, the following elements are considered out of scope

• This Standard does not focus on guidelines, requirements, and recommendations for the acquirer. The Forum is considering addressing this area in subsequent versions of the Standard. In the meantime, an acquirer does have a role to play in assuring that the products and components they procure are built with integrity. One of the ways that the acquirer can do that is to require their providers, suppliers, and integrators to be Trusted Technology Providers. Another way is to not knowingly support the "grey market", realizing that if an acquirer elects to receive hardware or software support from grey market suppliers, it is at their own risk and generally outside of the influence of the legitimate provider
• This Standard is not meant to be comprehensive as to all practices that a provider should follow when building software or hardware. For a more comprehensive set of foundational best practices that a provider could implement to produce good quality products, readers can refer to the O-TTPF White Paper
• This version of the Standard does not apply to the operation or hosting infrastructure of on-line services, but can apply to COTS ICT products in as far as they are utilized by those services.

This Standard complements existing standards covering product security functionality and product information assurance, such as ISO/IEC 15408 (Common Criteria)

1.3 Conformance

The OTTF intends to develop conformance criteria and create an Accreditation Policy and Program for the Open Trusted Technology Provider Standard (O-TTPS) as a useful tool for all constituents with an interest in supply chain security. Without the associated conformance criteria and an Accreditation Program, there is no assurance that an organization has implemented practices according to the O-TTPS. Accreditation will provide formal recognition of conformance to the O-TTPS, which allows

• Providers and practitioners to make and substantiate clear claims of conformance to the Standard
• Acquirers to specify and successfully procure from providers who conform to the Standard Conformance assessment is the act of determining the conformance of an implementation to a specification, or the adherence of a business operation to a best practice or process definition. There are many techniques for assessing such conformance, including the use of a standardized test method, quality assessment by industry experts or third-party test laboratories, and vendors' claims of conformance made within a defined legal framework.

The O-TTPS accreditation process, conformance criteria, conformance assessment, policies, parties, and their roles will be defined and approved after the publication of Version 1.0 of this Standard

1.4 Terminology

This section provides a set of terms and their definitions, which should be used when describing and interpreting the Standard requirements and recommendations specified in Chapter 4 of this Standard. These terms are aligned with ISO/IEC Directives, Part 2 (Annex H). Shall

• Indicates an absolute, mandatory requirement of the Standard that has to be implemented in order to conform to the Standard and from which no deviation is permitted. Do not use "must" as an alternative for "shall". (This will avoid any confusion between the requirements of a document and external statutory obligations.) Shall not
• Indicates an absolute preclusion of the Standard, and if implemented would represent a non-conformity with the Standard. Do not use "may not" instead of "shall not" to express a prohibition. Should
• Indicates a recommendation among several possibilities that is particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required. Should not
• Indicates a practice explicitly recommended not to be implemented, or that a certain possibility or course of action is deprecated but not prohibited. To conform to the Standard, an acceptable justification must be presented if the requirement is implemented. May
• Indicates an optional requirement to be implemented at the discretion of the practitioner. Do not use "can" instead of "may" in this context. Can
• Used for statements of possibility and capability, whether material, physical, or causal

1.5 Future Directions

The OTTF intends to address possible additional threats and risks with best practice requirements and recommendations in future Standard releases. The OTTF also intends to provide conformance criteria and an O-TTPS Accreditation Program.