Welcome to our third and final blog post on the Secure Connectivity Principles for Operational Technology (OT) guidance. If you havenât already, make sure to get up to speed on parts one and two. In today's blog, weâre going to look at the remaining four principles from the guidance, what they mean for OT system owners, and how runZero can help.
The remaining principles (numbers five through eight) in the guidance detail how OT system owners can set themselves up for success against adversaries, including recommendations for preventing breaches and detecting them if they occur. The final four principles are pivotal for system owners to get right.
Principle 5: Harden your OT boundary #
Many OT systems are difficult to update or replace, increasing the prevalence of obsolete assets and weak security controls. Because of this inability to modernize, oftentimes the primary defense against external threats to OT systems is their network boundary. As such, organizations should invest in modern, modular, and easily replaceable boundary protections. Additionally, the guidance suggests a robust checklist of actions to help harden your OT boundary:
- Change default passwords
Default credentials provide an easy-to-fix and easy-to-exploit avenue for attackers to gain initial access.
- Enforce the principle of least privilege
Human-to-machine and machine-to-machine connectivity should follow the concept of least privilege, following joiners, movers, leavers (JML) processes to ensure proper access rights throughout user lifecycles.
- Restrict unused services and ports
Only required ports and protocols should be exposed on assets.
- Implement phishing-resistant multi-factor authentication (MFA) for external services
Phish-resistant MFA should be implemented where possible for human-to-machine connectivity.
- Use context-aware access
Where possible, controls should be enabled that enforce connectivity based on attributes of the connection, like device location, time of access, or OS version.
- Enforce security requirements on third parties
Controls should be applied to third-party connections into the OT environment. NCSCâs previous guidance provides more details about this in principle five.
Enforce unidirectional traffic flows
Where possible, organizations should use Cross Domain Solutions and Data Diodes to help facilitate secure data transfers between untrusted and trusted domains.
As the convergence between OT and IT progresses, implementing principle five is critical for OT system owners in order to define and harden the boundary between OT and IT in their environments.
Principle 6: Limit the impact of compromise #
There is a saying that goes, âYou should be prepared for WHEN you get breached, not IF.â Organizations should take steps to limit the impact of a breach before it happens. OT systems owners need to focus on two risks:
- Contamination
Contamination refers to malicious or insecure code that makes its way into a trusted environment, often through the abuse of weak configurations, bad implementation, or vulnerable products.
- Lateral movement
Lateral movement describes how attackers expand their reach to neighboring nodes after initial access. Lateral movement can involve scanning, compromising hosts with stolen credentials, escalating privileges to gain access to systems, and more. Lateral movement should be seen as a threat both from external attackers and from insider and third-party threats.
Strategies for OT (and all) system owners to protect their environments include:
- Segmentation
Organizations should segment their networks behind firewalls or network architecture, dividing the network into smaller, functionally isolated networks, to reduce risk.
Microsegmentation: Microsegmentation applies controls on a much more granular level, usually at the host level, to restrict services, protocols, or specific clients from communicating.
Separation of duties: Separation of duties ensures that no one person has the âkeys to the kingdomâ. If you divide the responsibilities of individuals or systems within the environment, it limits exposure in the event of a breach or an insider threat.
- The browse down principle
The browse down principle states that you should trust the device on which administrative work is done as much as, or more than, the system you are managing. In essence, you don't want to manage a trusted system with an untrusted device.
- Boundary controls
- Principle five discusses ways for organizations to harden their boundary, and principle six provides additional recommendations:
Host-based Controls
Static network controls
Dynamic network controls
Threat detection and response.
- Principle five discusses ways for organizations to harden their boundary, and principle six provides additional recommendations:
The best time for OT system owners to plan for a breach was yesterday, and the second-best time is today. OT system owners need to take proper precautions now to ensure that when, not if, a breach occurs, they are ready.
Principle 7: Ensure all connectivity is logged and monitored #
While it's important to take all possible steps to prevent a breach, the last line of defense organizations have is their alerting and logging implementation. The ideal implementation of a good collection and alerting system is to empower system owners to expediently detect, contain, or prevent a breach, rather than simply collect logs.
There are at least four considerations OT system owners should look to address when a log collection and analysis program is implemented:
- Unauthorized activity
Any change in an OT (or IT) environment should come through strict change management procedures. Having a strong change management program, along with the ability to monitor for and alert on unauthorized changes, should be a major consideration.
- Anomaly detection
There should be detection of traffic patterns that deviate from the norm, or baseline, of known-good network traffic. Anomaly-based detection should not replace actual controls designed to prevent undesired traffic.
- Break-glass
Break-glass or use only in case of emergency access should be used only in emergency situations. Any use thereof should trigger an alarm of the highest criticality to the Security Operations Center (SOC). Break-glass account abuse is often how bad actors try to gain access to an environment through legitimate means.
- Data flow monitoring
Continuously monitoring data both within and across network segments and the OT boundary enables early detection of compromise.
NCSC has extensive guidance on proper log implementation, but principle seven serves as a brief reminder that logging for the sake of logging is not enough. Logs should be actionable within an organization to detect a breach and, if possible, prevent it from spreading.
Principle 8: Establish an isolation plan #
There may be times when it's necessary to isolate OT environments from external influences, for example, if there is a compromise in connected IT systems or an increased threat from adversaries. OT systems should be designed, where possible, to still provide critical functions while isolated. It's essential that an isolation plan is designed and tested to ensure that critical functions remain operational while preventing unforeseen or unintended consequences during isolation.
There are three primary isolation strategies that an organization could consider:
- Site isolation
Site isolation works well in flat networks or networks without sophisticated security measures. Site isolation primarily involves removing or terminating external connections, either physically (e.g., cable disconnect) or via software (e.g., firewall configuration)
- Application or service-specific isolation
If an organization has successfully implemented the secure connectivity controls outlined in the guidance, application isolation might be more effective than site isolation. Application isolation enables an organization to isolate affected services or assets using the controls outlined in the guidance, such as microsegmentation.
- Site isolation with hardware-enforced trusted communications
This isolation plan allows organizations that have used either data diodes, a CDS, or other hardware-based traffic enforcement to isolate their network while keeping the hardware enforced data flows open. This allows isolating the trusted network from the untrusted network while still enabling secure data transfer.
Isolation plans, just like breach contingency plans, should be built and tested before they are needed. Ideally, isolation plans will never be needed, but with the evolving threat landscape, organizations should take action now to be prepared in the event isolation is needed.
How runZero can help #
In our previous blog on this guidance, we mentioned five ways we help organizations protect and secure their OT systems. Those features of runZero also apply to principles five through eight, but there are more ways that runZero can help secure OT environments:
- Default password checks
runZero can run default password checks to discover assets and software that have not changed their default settings.
- Discover gaps in coverage
runZero can surface hidden assets, assets missing security controls, and assets that are bridging networks they shouldn't.
- Alerting on unauthorized changes
runZero provides a comprehensive asset inventory and can detect and alert when assets are added or removed from a network, or when asset changes occur.
- Edge device detection
Many organizations think they know where their edge lies, but runZero can expose assets with network connections you didnât know existed.
If you stuck with us through all three blog posts, thanks for being here! These werenât short posts, but neither was the guidance. If you need help protecting your OT assets, runZero is here to help. Try us out for free, or get in touch with us today.
