Industrial Process Control Systems
Mandiant recently held the webinar From the Front Lines: The Industrial Evolution - Transforming Security for Critical Infrastructure, which focused on threats to Industrial Control System (ICS) and the challenges organizations are facing to secure these gaps and vulnerabilities. I caught-up with one of the presenters, Dan Scali, Manager, Industrial Control Systems, to further discuss ICS Security and what can be done to mitigate the risk to these systems.
[JB] What is ICS Security?
[DS] Industrial Control Systems (ICS) allow operators to monitor and control industrial processes, including those in the oil and gas, nuclear, power transmission and distribution, manufacturing, chemical, and other industries. You can find ICS in lots of different places - from running the power grid, to regulating energy use in a building or managing the process of brewing beer.
Some security researchers and reporters use the term "SCADA" to describe these systems, but that's not quite technically accurate. We prefer the catch-all term ICS to encompass a diverse set of technologies including Supervisory Control and Data Acquisition (SCADA), Distributed Control Systems (DCS), Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), and any other type of technology specific to running an industrial operation.
When I talk about ICS security, I'm talking about keeping these specific systems secure, which in contrast to other information security disciplines, is less about securing data and more about keeping things up and running and about ensuring that the picture displayed on the control room screen matches what's actually happening on the plant floor.
[JB] What's your philosophy on ICS Security?
[DS] I believe that a successful ICS security strategy combines prevention and response. This contrasts with most of the work being done today in ICS security which is very focused on prevention and compliance. Using history as our guide: If PCI-compliant retailers can be breached and millions of credit card records stolen, what makes us think that NERC CIP-compliant or ISA99-conformant asset owners will avoid the same fate?
I also feel that network security monitoring (NSM) is particularly well-suited to ICS due to its passive nature. If it's too hard or too costly to make changes to control systems, you ought to at least keep a very close eye on them. You can't hope to understand if your ICS is compromised without appropriate visibility and instrumentation to look for indications of compromise.
[JB] What are some of the limitations of NSM? What about attacks that require physical access or exploit insecure ICS design? For example: USB-delivered malware or uploading malicious ladder logic to a PLC.
[DS] Common challenges in NSM are encrypted traffic, extreme traffic volume (and cost of storage), and privacy concerns. All of these are actually easier to overcome in ICS than in IT. ICS networks are rarely encrypted, ICS networks have lower bandwidth and generate less traffic, and communications are largely machine-to-machine.
Of course, a limitation of network security monitoring in ICS is that it only considers the data that can be collected. If an attacker were to communicate or plug-in directly to an ICS device and update its logic or configuration, it would be hard to detect on the network unless the device later attempted communicate with a command and control channel. In the enterprise space, we use host-based data to complete the picture. We can get some but not all host-based data for ICS. Software agents are valuable but are particularly challenging in ICS- they often require approval or testing from the ICS vendor and don't often support uncommon platforms like Real-time Operating Systems. Additionally, not all ICS devices generate useful logs. However, this is changing as some newer devices support syslog. Windows-based systems generate Windows Event Logs that can be a very useful source of data - errors, logins, CPU consumption, etc.
Despite these challenges, we find that if you put in the time to analyze what data is available in the environment, you can get a pretty good sense of the security posture of your ICS.
[JB] Is NSM possible in small organizations?
[DS] This strategy works for both small and large organizations! It may be easier in a big organization where some of the capabilities or infrastructure (for example, a Security Operations Center) already exist. In smaller organizations, IT and Operational Technology (OT) teams necessarily have to wear many hats. Congratulations, you're now responsible for ICS security!
[JB] What's the difference between IT and OT? Are there security issues that are specific to ICS other than high resistance to change?
[DS] It's best to think of ICS technology as being slower to evolve because of business constraints in the industrial space - for example, razor-thin margins and lack of internet-level scale - drive certain mindsets and behaviors: system lifecycles measured in decades instead of years, lower staffing levels, and heavy dependence on vendors or system integrators. So while we all understand that security is important, the business constraints and the technology ecosystem tend to keep us in a vicious cycle of poor security decisions.
There certainly is a cultural element as well. The high availability requirements of ICS are often cited as a reason for why they can't be updated - "If it's working, don't touch it!" However, these same systems often lack a backup or failover. If Facebook went down for a few hours the world might revolt - yet Facebook's engineers push new code twice a day. In truly mission-critical ICS systems, forward-thinking engineers need to advocate for a DevOps-like culture that allows the system to be quickly changed but also stay up-and-running.
It's also a common misconception that ICS attacks must exploit ICS-specific vulnerabilities - rather, they are just ICS-targeted. For example, the Stuxnet worm took advantage of both Windows zero days and a few software vulnerabilities in the Siemens control systems software that could be easily mapped to the vulnerability categories in the OWASP Top 10 or CWE/SANS Top 25 Most Dangerous Software Errors.