I may be one of the few people that gets excited about regulations, controls, and guidance. But I suspect that there are many cyber security leaders that are excited and encouraged by the newly released PAS754:2014.
This document provides a general framework for addressing cyber security and can also be used in conjunction with other standards, such as ISO 27001 and ISO/IEC 15288. As stated in the document, “the aim of this PAS, sponsored by the UK Trustworthy Software Initiative (TSI), is to provide a specification for software trustworthiness.” Trustworthiness is defined in the guidance as, “appropriately addresses safety, reliability, availability, resilience and security issues.” What is most encouraging about this document is that it addresses an area that many enterprises have not scrutinized: the security of the software supply chain. In the publication of this
"It is unacceptable to customers, users, shareholders and taxpayers that major programmes have been delayed and, in many cases, have failed because of serious defects in software."~ Sir Edmund Burton
guidance, Minister of State for Universities and Science David Willetts MP stated that “This [guidance] will help UK companies select the most secure, dependable and reliable software for their needs as well as providing them with the skills to use it effectively.” Past efforts in providing general frameworks have not focused specifically on the purchasing of secure software. The guidance itself includes the Procedural Control 22.214.171.124 - Perform supplier management. Specifically calling for enterprises and governmental agencies to understand the supply chain of software so that “trustworthiness can be specified and verified.” Further, in techniques for delivery of PAS754 requirements, four specific techniques are recommended:
- Supply chain identification – identify the supply chain
- Veracode POV: While this may sound obvious, tracing the exact source of purchased software, outsourced software, and open source components can be onerous for large enterprises. We believe the best way to get started is to analyze the software your development team is currently producing to see what open source components are currently being leveraged, and working with the procurement team to determine with which software suppliers your organization currently engages.
- Supply chain requirements – establish supply chain quality, security and integrity requirements
- Veracode POV: While looking to understand your supply chain, you should also create a third-party security policy. We encourage enterprises to leverage the same security policy as used for internal development. For open source components, all components with known vulnerabilities cannot be used within the enterprise. If this is not addressed already in the internal development security policy it should be updated.
- Veracode POV: Contracts and legal agreements between your enterprise or agency and software suppliers or outsources should be updated to include the third-party security policy as part of the acceptance criteria of the software that is being purchased. At the time of purchase is when a buyer has the most leverage, so be sure that this is incorporated.
- Supply chain assurance – establish supply chain quality security integrity assurance
- Supplier verification – supplier independent verification
- Veracode POV: Enterprises and agencies cannot simply trust that a supplier has met the requirements for trustworthiness. Independent verification is required in order to ensure that these standards have been met and the software being leveraged meets the acceptance criteria. Binary static analysis is an industry standard recommended by the FS-ISAC for this independent verification as it requires no source code from the software supplier in order to get a “snapshot in time of vulnerability density” within the third-party software.
When the PAS754 was released, Sir Edmund Burton, TSI President said “it is unacceptable to customers, users, shareholders and taxpayers that major programmes have been delayed and, in many cases, have failed because of serious defects in software” I couldn’t agree more, but this must include all software: both internally developed software and purchased software.