ICS Hard Knocks: Mitigations to Scenarios Found in ICS/OT Backdoors & Breaches
Hello, my name is Brian Ireland. I currently have over 14 years of experience in support of Energy Sector utility, NERC, CIP, and ICS protections. I spent those 14 years dealing with physical protections from door locks, cameras, and card readers, as well as cybersecurity design and implementation of network IDS, network isolation policy, SEIM, SOAR and AV deployment. Experienced in utilizing best practices and adhering closely to the Purdue Enterprise Reference Architecture (PERA), I was part of a small team that was able to create defensible, defense-in-depth OT/ICS (Operational Technologies/Industrial Control Systems) environments from 2009 to current.
This blog will be referencing the ICS/OT Backdoors & Breaches expansion deck created by BHIS and Dragos. We will be reviewing the ICS-focused Initial Compromise cards that are used to simulate a cyber incident and suggest potential mitigations to what is presented.
Some Key Takeaways to a Successful ICS Security Program
- OT/ICS operations inclusion: Cybersecurity has traditionally been an IT operations concern. OT/ICS operations are very production focused, and security is normally a bolt-on solution. ICS vendors traditionally will not offer security-based solutions unless asked for, so make sure security is baked into any project. Make sure you’re consulting with your ICS administrators and operators, as they are working with these systems on a daily basis and can be your best eyes and ears to learn about potential issues.
- OT/ICS technologies predate modern IT cyber software and devices; it’s not uncommon to see an RTU/PLC/HMI* that is 10+ years old. Hardware and software devices within the ICS environments may be implemented and remain untouched from the upgrade/update perspective for several years, whether due to updates being unavailable or unsupported by the vendor.
- Isolation via secured enclaves will greatly reduce the impact and prevent scope creep. If you place your operational ICS environments at your greatest trust level and only allow outbound traffic, this will greatly aid in reducing threat vectors. The control plane should be contained within your highest trust level networks. You should never control access to your ICS network from a less trusted network, like corporate lan, for example.
- Adding cyber and physical security will have an impact on daily operations; the key is to work with OT to minimize impact and ensure there is mutual understanding of the benefits to securing these operations. If an ICS system is compromised, there may not be an operation to be performed until the threat is mitigated.
- Regulatory requirements should be the entry level to a good security program. A good security program will be compliant with most governing bodies; inversely, a good compliance program may NOT be very secure. As an example: NERC CIP-005 v3 R1.5 requires adherence to CIP-007 v3 R4 required antivirus on Electronic Security Perimeter (ESP) access control point devices (a layer3 boundary device would have to have AV solution installed) by strict adherence to the regulations, all ICS edge devices would have to allow AV software to be installed. Thus, excluding best of breed network edge devices in lieu of more vulnerable software-based devices or file for technical feasibility exception to requirement and list the compensating measures.
- Leadership buy-in: Without support from upper management affecting long standing OT/ICS operation process’ or developing a solid security practice will be next to impossible. There is little-to-no incentive to implement secure practices within ICS unless regulatory, or if leadership requires implementation.
Ref: Introduction to ICS Security Part 2 | SANS Institute ; Standards (nerc.com)
Potential Mitigations to Address Some ICS/OT B&B Initial Compromise Cards
Data Historian Compromise:
- Isolation: ensure the historian or data that is required to be accessible outside of the ICS environment is isolated from that environment. This reference data should not be stored and accessible only outside of the ICS environment if non-operational parties need access to this data. If data is required to be accessible, a push of this historical data to a non-ICS repository.
- Ensure that there is no return path from the isolated historian to the ICS environment.
- ICS should never be related to or accessible from a hostile environment, i.e. open corp business networks. Leverage a layered approach where AAA boundary with MFA is leveraged to enter the ICS network that is controlled within the ICS boundary.
Dirty USB:
- Add a GPO to your ICS network to disable the use of USB storage.
- Administrative Policy directing operators acceptable use policy of removable media. Ideally, no removable media is allowed, only by exception and never from unknown sources to control networks.
- Separate devices for acceptable non-ICS operations should be leveraged for acceptable use, these devices should be isolated from the control networks. Things like email, documents, timesheets, etc.
- Leveraging an intermediate device used for scanning and ensuring software and files do not contain unknown code. This device should be used for all media that is brought into the ICS environment, and reasonable checks should be performed to ensure that software/code was not tampered with.
Infected Authorized Vendor Laptop:
- Acceptable use policy where vendor laptop may be used and what they can access from the external non-ICS device. Much like the Dirty USB mitigations, new devices’ software/code should go through a vetting process to ensure that threats are evaluated prior to accessing the ICS control plane.
- Use of a secure portal gateway to evaluate software to be introduced to the environment.
- Require external devices go through an evaluation process to ensure it does not contain unwanted malware or PUP programs.
Vendor Portal:
- Ingress/Egress filtering: Only allow known listening services access from external networks. If required, inbound traffic should be limited to only required normal operations. If an emergency operation needs to be performed, only allow traffic when necessary or implement various alerts to the improper or unscheduled use of any non-normal operating events.
- Review firewall (FW) allowed/denied traffic, create alerts upon unknown traffic patterns. Review blocked and allowed traffic logs to ensure what expected traffic looks like and if there is any unknown traffic present.
- Audit FW Access Control Lists (ACLs) routinely, evaluate ports allowed, and cleanup unused ports. It seems this is a very common practice to add new services as new projects update or requirements change, but cleaning up the old doesn’t always ensure there is a look back process to clean up unwanted ports at the edge.
- Require MFA when able to ensure identity management. Add this additional layer to prevent unintentional access to the ICS environment.
Dual-Homed Device:
- Non-ICS networks should not be accessible from an HMI (Human Machine Interface) or other related devices — these forms of communication need to be bridged over a boundary device. The boundary device should restrict access to only approved ports/services and only for required operations.
- If a device operation requires dual homing steps to provide authentication, ensure minimum privilege and only the required expected operations are available. This will create a bridge, and both sides of the device will have to maintain the same trust level, thus becoming an additional boundary device.
IT Compromised with Shared Domain Trust:
- Domain trust boundaries need to be carefully evaluated.
- Trust levels in ICS need to be at highest level, i.e. trust level in the ICS should be greater than corp or other ephemeral environments. Hostile environments should not be able to access or control access to or from an ICS environment.
- One-way non-transitive trusts if required to share resources should be maintained, leveraging this trust to share a resource outside of ICS with the ICS network should be directed from a request internal to the outside resource. External access to the ICS network should not be allowed. A 2-way transitive trust will invalidate trust zones.
- ICS should be able to push down a trust to corporate or other shared but non-ICS should not be able to reach into ICS environments.
Hopefully, these initial mitigation thoughts regarding the scenarios presented by some of the ICS/OT Backdoors & Breaches Initial Compromise cards are helpful. You may have picked up a theme of isolation — even though each organization and operation will require exceptions to fully isolating ICS environments, all reasonable steps to maintain a solid perimeter should be taken to reduce the threat landscape. Where operational exceptions have to be made, accommodations of AAA with MFA and strong monitoring/alerting principles will greatly assist in the detection and alerting of abnormal conditions.
This comes down to knowing what should be allowed; watch for what is normal and review any changes. Practice answering the 5 W’s anytime you are alerted to anything that looks unusual: Who did it? What was done? When did it occur? Why was it performed? If you are able to answer those questions, you should be able to safely defend your Industrial Control Systems, quickly address issues, and greatly improve your ability to find the unknown occurring within your environment.
Thank you for taking the time to read through these potential mitigations. Please feel free to reach out to [email protected] with any questions or requests for additional content.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
