A defined method is followed to identify cybersecurity requirements and implement associated controls that protect against the risks arising from suppliers and other third parties
Context and Guidance: Cybersecurity requirements should be identified according to a defined methodology that is effective and clear. The requirements should include the controls needed to secure the products and services to address cybersecurity risks arising from suppliers and other third parties identified in the RISK domain.. Additional consideration should be given to third parties that are considered by the organisation as high priority (THIRD-PARTIES-1c) because they supply, maintain, or operate critical software components that are essential to the operation of the function. The definition of a critical software component may vary widely depending on industry or critical infrastructure sector and may be informed by commonly used frameworks or control sets. For example, NIST provides a definition of critical software under Executive Order 14028 that some organisations may be required to adopt Cybersecurity controls should be implemented that reduce the risk that could stem from suppliers and other third parties. The organisation may implement operational controls that restrict individuals from a third party such as a maintenance or janitorial service from accessing designed areas of a facility without escort. Technical controls may be necessary for third parties that supply a service like remote maintenance of an asset. The organisation may also consider management controls like acquisitions strategies that obscure the end use of an asset. The following are examples of the types of requirements to consider: • controls and procedures for granting access to third parties • specifications for the governance, protection, and destruction of data • whether the supplier will be developing software, and if so what secure coding practices must be used • the knowledge and skills needed to perform the responsibilities assigned to third parties • cybersecurity training that may be necessary prior to granting access to third parties • logging, log retention, and monitoring • incident and vulnerability notification, mitigation, and response coordination including timelines and thresholds • incident response and information sharing • controls governing connections to organisation systems by third parties • whether a diversity of software, assets, and suppliers is necessary to lower the risk of broad exploitation of specific vulnerabilities Sources of information for the development of cybersecurity requirements for suppliers include analysis of previous cyber events (internal, external and "near miss"), brainstorming with internal stakeholders, interviews with cybersecurity experts, industry threat alerts, vulnerability announcements, the results of internal control reviews, vulnerability assessments, penetration tests, and other research.
Related Practices • Input From: Implementing ARCHITECTURE-1f and ARCHITECTURE-1g provides input that may be useful for implementing this practice. • Progression: This practice is part of multiple practice progressions. Practice progressions are groups of related practices that represent increasingly complete or more advanced implementations of an activity. The practices in the first progression include: THIRD-PARTIES-2c, THIRD-PARTIES-2e. • The practices in the second progression include: THIRD-PARTIES-2c, THIRD-PARTIES-2f, THIRD-PARTIES-2g, THIRD-PARTIES-2h.