This is a weekly post where we address questions of interest to the Application Information Security Community. To that end, we’d love to hear your questions! Please Tweet us with the hashtag #ThinkAppSec or leave us a comment below.

Open Group O-TTPS – Identifying Trusted Providers of Hardware and Software Components

How do you know if the vendor providing hardware or software can be trusted? How do you know if their processes can be trusted to supply your organization with hardware and software that has not been maliciously tainted?

The Open Group, “a global consortium that enables the achievement of business objectives through IT standards,” began to work on these questions “in 2009 with a meeting of government and industry representatives, said Sally Long, director of [The Open Group’s Trusted Technology Forum]. “Government came to us and asked, ‘How do we know what businesses can be trusted?’” The Open Group consortium includes many vendors, IBM is one, but strives to be vendor neutral. The Open Group mission is to help companies with reliable and secure global interoperability not to recommend a single vendor or product.

To address the issue of technology trust, the Open Group established The Trusted Technology Forum, which published the Open Trusted Technology Provider Framework (O-TTPF) in February 2011.  The Framework sets forth best practices identified by a cross-industry forum which, if used by a technology vendor, may allow a government or commercial enterprise customer to consider the vendor’s products as more secure and trusted.

The best practices address, among other things, Product Development and Secure Engineering. Specific best practices in those categories include (but are not limited to):

Secure Engineering:

  • Threat modeling
  • Secure code design reviews
  • Risk assessments
  • Tooling to minimize risk
  • Static code analysis

Product Development:

  • Well documented processed and practices
  • Formally managed requirements, design, etc
  • Quality test management

The O-TTPF is complemented by the Open Trusted Technology Provider™ Standard (O-TTPS), Version 1.0 (April 2013) which contains a set of organizational guidelines, requirements, and recommendations for integrators, providers, and component suppliers to enhance the security of the global supply chain and the integrity of Commercial Off The Shelf (COTS) Information and Communication Technology (ICT). The standard encompasses the entire COTS ICT Lifecycle through: design, sourcing, build, fulfillment, distribution, sustainment, and disposal.

On February 3, 2014 The Open Group announced the launch of the Open Trusted Technology Provider™ Standard (O-TTPS) Accreditation Program to help companies assure the integrity of COTS ICT products and safeguard the global supply chain from Cybersecurity attacks. To be accredited, organizations must demonstrate that they conform to the O-TTPS requirements and have compliant processes and procedures in place that secure in-house development across the entire COTS ICT lifecycle.

When accredited, organization can identify themselves as Open Trusted Technology Providers™ and are included in the Open Group’s public registry of trusted providers. Completing accreditation means that an organization has followed O-TTPS to ensure that they “Build with Integrity” so their customers can “Buy with Confidence”. In January 2014, IBM received O-TTPS accreditation for the Application Infrastructure and Middleware (AIM) Software Business Division.

Andras Szakal, Vice President, Chief Technology Officer, IBM U.S. Federal IMT: said: “Secure by Design is a key tenant of the IBM secure engineering process. The Open Trusted Technology Provider™ Standard and Accreditation Program will help guide and recognize trusted technology vendors like IBM that value Secure by Design best practices.”

If you buy or build software or hardware for your organization, please take a closer look at the standard and guidance from The Open Trusted Technology Provider™ Standard and Accreditation Program.


And then, please let us know your thoughts on the program. Will this program help your organization “Buy with Confidence?” Why or why not?

How do you know if the vendor providing hardware or software can be trusted? How do you know if their processes can be trusted to supply your organization with hardware and software that has not been maliciously tainted?

What is the importance of software security in supply chain management?

Who Should be Responsible for Application Security Testing?

Can “generated code” be tested?

How do we secure application vulnerabilities and code development, particularly for mobile and social applications that are built by business units or reside on the cloud?

As a CISO, how can I control my organization’s testing methodologies, change management and deployment processes, without compromising on quality and project timelines?
How Can I Secure Apps in the Cloud?

Will the legal landscape change if software vendors can be sued without damages or loss being proven?
The Legal Landscape: Can vendors be sued without damages? What the heck is PII?

What is PII – How much can the definition expand?
Mobile Apps: Which are More Secure Android or iOS?

Does IoT (Internet of Things) “change everything” for Application Security?

What is the difference between PCI DSS and PA DSS?

How can we foster cooperation to help our Development and Security Teams work together?

How do I know my Cloud Service Provider (CSP) Applications are secure?

What can I do to help eradicate SQLi or at least reduce the incidence of SQLi vulns in our production applications?

Submit your questions via Twitter using #ThinkAppSec


More from Software Vulnerabilities

Analysis of a Remote Code Execution (RCE) Vulnerability in Cobalt Strike 4.7.1

Command & Control (C2) frameworks are a very sensitive component of Red Team operations. Often, a Red Team will be in a highly privileged position on a target’s network, and a compromise of the C2 framework could lead to a compromise of both the red team operator’s system and control over beacons established on a target’s systems. As such, vulnerabilities in C2 frameworks are high priority targets for threat actors and Counterintelligence (CI) operations. On September 20, 2022, HelpSystems published…

Controlling the Source: Abusing Source Code Management Systems

For full details on this research, see the X-Force Red whitepaper “Controlling the Source: Abusing Source Code Management Systems”. This material is also being presented at Black Hat USA 2022. Source Code Management (SCM) systems play a vital role within organizations and have been an afterthought in terms of defenses compared to other critical enterprise systems such as Active Directory. SCM systems are used in the majority of organizations to manage source code and integrate with other systems within the…

X-Force Research Update: Top 10 Cybersecurity Vulnerabilities of 2021

From 2020 to 2021, there was a 33% increase in the number of reported incidents caused by vulnerability exploitation, according to the 2022 X-Force Threat Intelligence Index. A large percentage of these exploited vulnerabilities were newly discovered; in fact, four out of the top five vulnerabilities in 2021 were newer vulnerabilities. Vulnerability exploitation was the second most common initial infection vector observed by IBM Security X-Force in 2021, falling closely behind phishing. Cybercriminals are finding new ways of bypassing security…

How Log4j Vulnerability Could Impact You

MITIGATION UPDATE: New vulnerability in 2.17 — CVE-2021-44832 Upgrade to 2.17.1 to mitigate this vulnerability Do NOT enable JNDI in any versions Follow: If you hadn’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing your daily activities into a notebook. That notebook is Log4j. Developers and programmers use it to take notes about what’s happening on applications and servers.…