By Euan Henderson
Cyber Technologist Apprentice
In February the NCSC published guidance on what both developers and consumers of software should focus on when implementing or buying a new product. It has produced a checklist for products to show they are resistant to elevated threats.
This Blog focuses on the high level assurance principles, set out by the NCSC to guide design and development.
The NCSC recommends:
- Products should be sourced from trusted suppliers with proven high threat domain knowledge. This means that the supplier should show that they are aware of the current capabilities of threat actors and have implemented resistance to existing and future capabilities.
- Developers’ processes should demonstrably meet all accepted good practice. They should be able to provide evidence of the best practice they have followed and meet industry best practice such as through the NCSC Build Standard.
- Products should have clearly defined, specific security functionality, with limitations identified. The developers of the product should be able to clearly define and document security functionality, identifying where the product cannot defend against the capabilities of threat actors so the risk owner is able to plan accordingly.
- Products should support systematic, independent and evidence-based assessment of claimed security functionality. The product should be easily tested such as implementing a coding language that does not conceal functionality. This must be built in to the products design and development and the results should be repeatable to ensure security can be validated throughout the lifecycle.
- Products should always operate as intended and be able to resist errors in implementation and usage, interference and failures. It should also be ensured that if a threat path is identified, then resilience is implemented to defend against the threat. This applies to both engineering practice and the operation/design of the device.
- Products should always be in a trusted state. This means the device should always be able validate the integrity of its hardware, software and internal data to an accepted root of trust. If not the case, this should be detected by internal or external monitoring of the software.
For more information on the points above please visit:
https://www.ncsc.gov.uk/guidance/design-guidelines-for-high-assurance-products
/-3.5042587517567103,%2054.70635734010168,15.5/300X450@2X?access_token=pk.eyJ1Ijoid29tYmF0Y2hyaXMiLCJhIjoiY2pqaGEyd2lzMDQ3ZDN2bWQ4OTBsa2pmayJ9.ksVq6arM13qYhr76pco33w)