What kind of security practices does O-TTPS ask IT providers to adopt?
O-TTPS sets forth several required "best practices" and recommendations related to the entire product lifecycle that ranges from design, sourcing, build, fulfillment, distribution, sustainment and disposal. Among the security-related requirements listed in Section 4 of O-TTPS can be found:
- Full documentation of the engineering process, configuration and components and tracking and, if need be, any that "are proven to be targets of tainting or counterfeiting as they progress through the lifecycle."
- Established quality testing procedures, and security update and defect management processes.
- Threat analysis and mitigation to assess potential attacks, plus vulnerability analysis, patching and remediation.
- Secure coding practices and regular training of secure engineering, plus monitoring changes to the "threat landscape."
- Risk-based physical security procures that are well-documented.
- Access controls established for all product-relevant intellectual property and assets, subject to audit.
- Background checks on employees and contractors "whose activities are directly related to sensitive product supply chain activities (within reason given local customs and according to local law)."
- Recommending O-TTPS to "relevant business partners."
- Secure transmission and handling controls related to IT assets, plus physical security. Methods of verifying authenticity and integrity of products after delivery should be available.
- To keep malware out of components received from suppliers or in products delivered to customers and integrators, commercial malware detection tools need to be deployed as part of the code acceptance and development process, and before delivery.
There are specific requirements and recommendations related to use of open-source software components. What are they?
Open source assets and components have to be identified "as derived from well-understood component lineage." For these components, ongoing support and patching "shall be clearly understood." This means that there needs to be a tight rein on open source so that it's treated like any other type of software under the O-TTPS guidelines.
Sign up for Computerworld eNewsletters.