Managing Third Party Security Risk in the Critical Infrastructure

There’s no shortage of challenges when it comes to securing the critical infrastructure. These are very complex, interconnected systems, and highly motivated, potentially well-trained and funded adversaries target them. And should critical infrastructure systems become unavailable, whether electrical, financial, or communications systems – every public sector organization and private enterprise that relies on them is also in danger of being severely hampered, or even shut down.

Yet, in many ways that interdependency, while not always to the same fundamental level, is true of all businesses. We all depend on contractors, service providers, and other businesses large and small to get the work done that we need completed. That was my takeaway when reading the Framework for Improving Critical Infrastructure Cybersecurity [.pdf] released last month.

The designers of the framework certainly were aware of third party security risk, and took special care to integrate this throughout the guidance.

From a high level, the steps of the framework are straightforward, and apply equally to any organization whether or not they are in one of the critical infrastructure industries:

1. Describe your current cybersecurity posture;
2. Describe your desired target state for cybersecurity;
3. Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process;
4. Assess progress toward the target state;
5. Communicate among internal and external stakeholders about cybersecurity risk.

The framework core (a ‘core’ set of activities) is organized in six categories, or functions: Identify, Protect, Detect, Respond, Recover - and the need to monitor and be aware of third party security posture permeates throughout the guidance.

Section 3.3, Communicating Cybersecurity Requirements with Stakeholders, describes how the framework provides a common way for third party stakeholders within the delivery chain of essential critical infrastructure services to communicate cybersecurity requirements to each other.

Examples provided by the framework include:

• An organization may utilize a Target Profile [the ideal security posture] to express cybersecurity risk management requirements to an external service provider (e.g., a cloud provider to which it is exporting data).
• An organization may express its cybersecurity state through a Current Profile [current security posture] to report results or to compare with acquisition requirements.
• A critical infrastructure owner/operator, having identified an external partner on whom that infrastructure depends, may use a Target Profile to convey required Categories and Subcategories.
• A critical infrastructure sector may establish a Target Profile that can be used among its constituents as an initial baseline Profile to build their tailored Target Profiles.

And in each of the applicable framework security functions, the framework points to guidance that highlights the importance of third party security.

In the Identify function enterprises are asked to first quantify their existing security risks to their systems, assets, data, and capabilities and then prioritize based on business risk. An important part of this is asset management, which is covered in subcategory 6, Asset Management (ID.AM). Here, the framework calls for cybersecurity roles and responsibilities for the entire workforce as well as third party stakeholders (suppliers, customers, partners) to be established.

In the Protect function organizations are asked to develop and implement safeguards that will ensure the delivery of their services. The idea here is to mitigate the potential impact of security breaches. According to the framework, the Protect Function “supports the ability to limit or contain the impact of a potential cybersecurity event. Examples of outcome Categories within this Function include: Access Control; Awareness and Training; Data Security; Information Protection Processes and Procedures; Maintenance; and Protective Technology.”

And the activities aren’t just for in-house, this also includes awareness and training (category PR.AT) for the organization’s personnel and partners so that they all are adequately prepared to execute on their information security functions in accordance with security policy and contractual agreements.

Within the Detect Function, the framework calls for organizations to implement ways to identify potential security events. “The Detect Function enables timely discovery of cybersecurity events. Examples of outcome Categories within this Function include: Anomalies and Events; Security Continuous Monitoring; and Detection Processes,” the report says.

And, once again, partners come into play: subcategory DE.CM-6 suggests that external service provider activity be monitored to detect potential cybersecurity events.

Finally, in the Respond Function, the Framework for Improving Critical Infrastructure Cybersecurity suggests enterprises implement ways to respond and take mitigating action when cybersecurity events are detected.

This includes response and communications with all relevant stakeholders, including customers, partners, and suppliers. The framework says that voluntary information sharing among external stakeholders helps to achieve “broader cybersecurity situational awareness.”

It’s tough to argue with logic like that. And it’s good guidance for everyone: the more organizations know about their own security posture - and the posture of those that they depend upon – the more secure and resilient they become.