Principle A4: Supply chain

Description

You understand and effectively manage the security and information governance risks associated with suppliers supporting the operation of your essential function(s).

Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.

As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).

The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation's outcomes are effectively achieved.

Suggested approach to testing – Partially achieved

1. Supplier risks - ascertain how the organisation identifies and documents risks posed by suppliers to its essential functions. (PA#1)

2. Knowledge of supply chain - verify that the organisation has understood and documented all suppliers who support its essential functions. For suppliers who would have the biggest impact on the organisation’s essential functions if compromised, the organisation should have made proportionate efforts to identify sub-contractors involved in the supplier’s services. (PA#2)

3. Appropriate and proportionate levels of cyber security – ascertain what assurances the organisation obtains from suppliers to ensure they have appropriate and proportionate levels of cyber security within the context of common threats. (PA#3, PA#7)

4. Supplier contracts - obtain a sample of the organisation’s supplier contracts. Verify that:

1. Appropriate cyber security and data protection obligations have been included. (PA#4, PA#7, A#6)
2. The data being shared by the organisation is clearly documented and understood by both parties. (PA#4, PA#7)

5. Third-party connections - obtain evidence that the organisation has documented all third-party connections to its networks. Verify what assurance the organisation has in place that each third-party connection and the vendor it belongs to meets the organisation’s cyber security and information governance requirements. Where connections can’t be reasonably individually assured for practical reasons, such as in the case of members of the public connecting to the organisation’s public website, verify that the organisation has alternative controls in place to prevent such access having adverse effects. (PA#5)

6. Incident management – discuss the incident management process and assess whether third-party incidents are considered. Verify that the organisation has agreed specific measures in their process to aid their response to incidents involving third parties. (PA#6, PA#7)

7. International data transfers - verify that the organisation understands and documents all countries where data is being processed as part of its supplier-offered services. Obtain evidence that there are either adequacy decisions in place for these countries, or where there is no adequacy decision the organisation has appropriate legal mechanisms in place to facilitate the data transfer. (PA#8, A#11)

Additional approach to testing – Achieved

1. Detailed supplier risks - verify that the organisation has identified its most important suppliers which warrant in-depth checks. Obtain evidence that the organisation has identified and documented risks posed by these suppliers to a deep level of detail, including matters such as information and cyber risks arising from the suppliers’ sub-contractors, geographic location, concentration risk, over-reliance on individual providers, and documented any gaps in visibility or assurance together with the associated risks and mitigating actions. (A#1)

2. Procurement lifecycle processes and purchasing decisions - obtain evidence that the organisation has a structured supplier risk assessment and due diligence process which it uses before suppliers are selected or contracted with. Verify that the process requires proportionate consideration of information governance, cyber security, subcontractors and other corporate and operational factors relevant to supplier risk. Where information was incomplete or assurance was limited, verify that the gap was recorded, the associated risk was assessed, and mitigating controls were identified where possible.

3. Capable and well-resourced threat actors - assess whether the organisation uses an appropriate threat modelling technique to examine how capable and well-resourced threat actors could compromise critical suppliers, their services, systems or supply chains in a way that would adversely impact the organisation’s essential functions. As part of threat modelling exercises, verify that the organisation:

1. anticipates probable attack methods and techniques, targets and objectives, and develops plausible supply chain compromise scenarios for suppliers whose services are most impactful to its essential functions (A#3)
2. considers whether the measures their supplier has in place are appropriate and proportionate to protect their information in such scenarios (A#4, A#5)

4. Proactive approach to contract management - verify whether the organisation has a proactive approach to contract management, which may include a contract management plan for relevant contracts. Obtain evidence that supplier risk, information governance, cyber security and other factors considered during procurement are reviewed on a scheduled basis rather than only at the point of supplier selection. (A#7)

5. Roles and responsibilities - obtain the list of supplier contracts and obtain a sample. Verify that the customer or supplier ownership of responsibilities are laid out in those contracts. (A#8)

6. Third-party connections and data sharing – in addition to step 5 of 'partially achieved', assess the procedures the organisation has in place for ensuring that the necessity of proportionality of its third-party connections are re-evaluated over time. Verify that equivalent checks are in place for the organisation’s data sharing. (A#9)

7. Resolution of incidents - obtain and inspect the organisation’s incident management process and assess whether suppliers’ roles and responsibilities during incidents are documented. Assess whether the organisation understands the incident response support available from specific suppliers and has incorporated this into its response planning. (A#10)

Suggested documentation – Partially achieved

Suggested documentation includes:

• risk assessments and risk registers 
• documentation identifying suppliers supporting essential functions
• lists of critical suppliers and relevant subcontractors
• supplier contracts
• data sharing agreements and data processing agreements
• approval procedures and registers for third-party network connections
• incident management processes covering supplier and third-party incidents
• record of processing activities (ROPA) or equivalent documenting international data transfers associated with supplier services

Additional documentation – Achieved

Additional documentation includes:

• detailed supplier risk assessments
• supplier due diligence procedures and completed assessments
• threat modelling methodology and outputs relating to supply chain compromise scenarios 
• contract management plans and supplier review records
• evidence of scheduled reviews for third-party connections and data sharing
• supplier incident response arrangements and support commitments

Description

You actively maximise the use of secure and supported software, whether developed internally or sourced externally, within systems and networks supporting the operation of your essential function(s).

Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.

As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF). 

The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation’s outcomes are effectively achieved.

Suggested approach to testing – Partially achieved

1. Secure software development and support – either through obtaining evidence of the organisation’s assurance mechanisms where they are using software developed by external suppliers, or through obtaining evidence relevant to the organisation’s own development of software, verify how the organisation ensures that:

1. software is developed using secure development principles and practices (PA#1)
2. there is at least a limited understanding of the composition and provenance of the software (PA#2)
3. the security of the development, test and production environments for the software has been considered and is appropriate and proportionate to common threats (PA#3)
4. software has been subject to a testing regime which includes a range of testing approaches, such as static analysis, dynamic analysis, unit testing, integration testing and point-in-time security assessments, covering both functional and non-functional testing (PA#4)
5. arrangements are in place for the software to receive timely security updates, patches and notifications (PA#5)
6. secure channels are used for the software to be securely distributed, updated and patched (PA#6)
7. processes are in place for security vulnerabilities associated with the software to be identified, reported and mitigated (PA#7)
8. arrangements are in place for significant events associated with the software to be communicated to users (PA#8)
9. where open-source software is used, appropriate and proportionate steps have been taken to establish and maintain sufficient confidence in its security for use (PA#9)
10. appropriate support and maintenance arrangements are in place for the software (PA#10)

Additional approach to testing – Achieved

1. Established secure software development framework – verify how the organisation assures that the software it uses has been developed using an established secure software development framework such as NIST Secure Software Development Framework (SSDF) or Microsoft Secure Development Lifecycle (SDL):

1. where software has been procured from third-party suppliers, obtain evidence that the organisation has conducted appropriate due diligence and obtained assurance regarding the supplier’s secure software development practices, for example through NCSC’s assurance principles and claims assessment (A#1) 
2. where software has been developed in-house, assess how the organisation ensures that secure software development requirements are consistently applied throughout the software development lifecycle and aligned to an established secure development framework (A#1)

2. Composition and provenance of software – verify how the organisation assures itself that the developer of its software has a detailed understanding of its composition and provenance, including any third-party components used in the development of that software, and that those components are monitored for new vulnerabilities:

1. where software has been procured from third-party suppliers, verify how the organisation has gained assurance about the software's composition and provenance, for example through NCSC’s assurance principles and claims assessment (A#2)
2. where software has been developed in-house, assess how the organisation identifies, documents and maintains visibility of software components, dependencies and code provenance. Verify that processes are in place to monitor those components for newly discovered vulnerabilities and take appropriate remedial action (A#2) 

3. Security of software development environments – verify how the organisation assures itself that the environments used to develop, test, build and deploy software are protected against threats from capable and well-resourced threat actors:

1. where software has been procured from third-party suppliers, verify that the organisation has obtained assurance that the supplier operates appropriately secure development environments, for example through NCSC’s assurance principles and claims assessment (A#3)
2. where software has been developed in-house, assess whether the organisation has conducted threat modelling with its software development, test and production environments in mind and implemented appropriate controls (A#3)

4. Threat-informed software development – verify how the organisation assures itself that software development activities are informed by a detailed and current understanding of threat, and that appropriate techniques are used to identify and manage vulnerabilities and attack vectors throughout the software development lifecycle:

1. where software has been procured from third-party suppliers, verify how the organisation has gained assurance that the supplier incorporates threat modelling or equivalent techniques to identify and assess potential attack paths and security weaknesses for the software, for example through NCSC’s assurance principles and claims assessment (A#4)
2. where software has been developed in-house, assess how the organisation incorporates threat intelligence, threat modelling and vulnerability analysis into its software development lifecycle (A#4)

5. Authenticity and integrity of software – verify how the organisation assures itself that software, including updates and patches, is authentic, has not been tampered with, and can be trusted before deployment into its environment:

1. where software has been procured from third-party suppliers, verify how the organisation has gained assurance regarding the authenticity and integrity of software, for example through NCSC’s assurance principles and claims assessment (A#5)
2. where software has been developed in-house, assess how the organisation ensures the authenticity and integrity of software throughout the build, testing, release and deployment process. Verify that appropriate controls are in place to prevent unauthorised modification of code, software packages and deployment artefacts, and to validate the integrity of software releases before implementation (A#5)

Suggested documentation – Partially achieved

Suggested documentation includes:

• evidence of software suppliers’ completion of assurance mechanisms tied to the software security code of practice, for example, cyber security charter for suppliers to the NHS, relevant DSPT assessment for large IT suppliers, and Digital Technology Assessment Criteria (DTAC)
• secure software development policies, standards and procedures
• documentation describing the composition and provenance of software, including known third-party components where available
• evidence of security controls applied to software development, test and production environments
• software testing policies, procedures and testing results
• records of security updates, patches and software notifications
• procedures for distributing and deploying software updates through secure channels
• vulnerability management procedures and records of identified and remediated software vulnerabilities
• procedures for communicating significant software-related security events
• open-source software registers, assessments or approval records
• software support and maintenance agreements

Additional documentation – Achieved

Additional documentation includes:

• evidence of in-depth due diligence procedures for software suppliers, for example, through use of NCSC’s assurance principles and claims assessment 
• software bills of materials (SBOMs), component inventories or equivalent provenance records
• records demonstrating ongoing monitoring of third-party components and dependencies for newly disclosed vulnerabilities
• security assessments and controls for development, test, build and production environments
• threat modelling outputs relating to software development 
• vulnerability disclosure, reporting and remediation processes
• evidence of validation of software authenticity and integrity prior to deployment