Sometimes a tweet can catch your attention in interesting ways.
Robert's use of the term 'defensible' to describe ICS networks got me thinking about what makes an environment defensible, as well as about the difference between 'defensible' and 'defended.' It helps that we were both sitting at the
EnergySec conference when he sent this tweet, so my brain space was already occupied with the myriad challenges of securing an mixed IT/OT environment.
Why is this idea of defensibility important? In information security,
whether IT or OT, we're often focused on the immediate problems we have to solve, the project in front of us, or the much feared 'sophisticated attacker.' Taking a step back to consider how the architecture of the environment lends itself to defense alters the perspective from a particular problem to a broader problem space.
My working hypothesis for what will be two blog posts is that this shift in perspective can deliver an environment in which currently unknown attacks can be more easily thwarted in the future.
Characteristics of Defensibility
In order to have a useful discussion around defensibility and how it affects an organization's ability to defend against unknown threats, we have to start with an understanding of what defensibility means. What are the characteristics of defensibility?
The concept of attack surface isn't
new, and it isn't possible to completely eliminate the attack surface of any environment. The size of the attack surface is relevant to defensibility in two ways. The first, and most obvious, is that a larger attack surface gives an attacker more opportunity. The more devices, applications, services and users that you have running, the more avenues for exploit exist.
The second way in which attack surface size is relevant isn't always so obvious, but it's just as relevant. A larger attack surface is harder to monitor. Just as more devices, etc. provide attackers with more opportunity, fewer devices, applications, services and users provides fewer events and changes to monitor for suspicious behavior.
It's highly probably that you are currently reading this post on a device that can do many, many other things. In fact, it's improbable that there's a device out there that's designed solely for reading the State of Security. Fit-for-purpose isn't a binary criteria, but a spectrum, and where a system falls on that spectrum has a direct impact on how it might be exploited or abused. A general purpose operating system does so many things that it's not a stretch to make it do something unintended. The more fit-for-purpose a device or system is, the harder it is to force into an action for which it wasn't intended.
Defense isn't all about preventing compromise, but also about responding to activity. A flat environment, with little access control, provides few mechanisms for isolating activity. An overly segmented environment, on the opposite side of the spectrum, is so complicated that taking an effective action to isolate activity is only possible in theory, but practically un-executable.
An ideal environment, then, is a balance between the two, including sufficient control points at relevant logical locations to effectively control network traffic and access. As a side note, I use the term ‘control points’ rather than access control or firewalls because it encompasses a larger breadth of technology, from
data diodes through to application-level filtering.
Another old, but still important, concept is that of least privilege. The fewer individuals who can access and change an environment, the easier it is to identify the source of any changes. I’d distinguish this from Control Points generally; Least Privilege Access is a specific implementation of one type of control point.
- Operational Predictability
This is a less intuitive aspect of defensibility, but is vitally important. Environments where activity during normal operations is fairly consistent make identifying anomalies much easier, and hiding activity much harder. An environment where network traffic varies greatly, or device resources vary greatly, presents a larger, amorphous haystack in which a needle is harder to find.
Consider a failure condition, regardless of cause. It could be the result of an actual attack, of human error or simply hardware failure. Regardless, the speed and cost of restoring service for that failed component has a direct bearing on the defensibility of an environment.
How OT Environments Stack Up on Defensibility
Having defined the attributes of defensibility, we can now move on to actually evaluating different environments. Let's start with a table for comparison of these attributes between OT and IT environments. By definition, I'm generalizing here. It's certainly possible to configure one environment or the other in a more or less defensible way (and more on that later).
Attack Surface is a key difference on which to spend a little time because it gets to the heart of how these environments are differently defensible. IT is, by its nature, designed to be broad, heterogeneous and extensible. The rate at which systems are updated and replaced in most IT environments drives a high rate of change.
These characteristics result in an expansive attack surface, providing many potential points of entry to attackers, and requiring many defensive strategies to protect. By contrast, OT environments tend towards the opposite: narrow, homogenous and static. These characteristics lower the number and variety of entry points for attackers.
Fit-for-purpose is a good description of many Industrial Control Systems. While there's reason to discuss how OT environments are shifting to make more and more use of general purpose systems, the fact remains that IT environments have very few fit-for-purpose devices compared to OT.
Both environments get a mixed report on
control points. While OT environments tend to have fewer, more manageable control points, there's certainly a well-known problem with putting SCADA and other control systems directly on the Internet. IT environments can excel at deploying access control, from network through to applications. The downside of that capability is the increased complexity and increased target surface; the access control becomes a means of exploit.
Likewise, both environments are a mixed bag on
least privilege access. OT environments are plagued with shared and default credentials. IT environments are ripe with complexity, mistakenly accrued account privileges and overly complex systems for managing users and groups.
Operational Predictability is another key difference between OT and IT environments. OT environments, because of their tendency towards
fit-for-purpose and limited scope, lean toward a much more predictable operational profile. IT environments simply support more, and more flexible, applications. An illustrative example is DNS.
Monitoring DNS in an OT environment should be relatively quiet, with very few external requests being sent. Monitoring DNS in an IT environment will be noisy, with the multitude of requests generated by web pages, ads in web pages, systems and applications looking for updates, Facebook, IM apps, etc. Identifying anomalous DNS traffic will be a very different activity in these two environments. Credit should go to
@chrissistrunk for this example, slide 38 in this
deck.
Resiliency is directly related to requirements for reliability. Most OT environments were built with high reliability as a requirement. These are environments where a failure means that people can't turn on the lights, or cars don't roll off the assembly line, or some other very material consequence occurs. While reliability and resiliency aren't the same, a requirement for reliability drives resiliency in the design.
IT environments are mixed on this attribute. Virtualization and the cloud have given IT incredible new opportunities for resiliency. In those cases, IT is far more resilient than OT, but much of IT environments are still made up of physical servers, desktops, and applications. These elements are fairly low on the resiliency scale, in part because they don't have high reliability requirements, and in part because it's simply hard or expensive to deliver.
Where Does That Leave Us?
It's worth a reminder, if you've made it this far, that defensible is not the same as defended. The question on the table is really about how defensible OT environments are compared to IT environments. In that context, OT provides a set of characteristics,
in general, that are better suited to developing defensive strategies.
Most of this conclusion hinges on attributes that simplify the problem space: a smaller attack surface, less complexity in establishing control points and least privilege access, more effective monitoring through operational predictability.
That sounds nice, doesn't it. The reality is that ICS and OT environments, while more defensible, are not more defended. The relative investment in basic information security best practices between OT and IT is dramatically unbalanced. IT simply spends more time and money deploying information security tools and processes.
To explore that further, we'll cover how we move from defensible to defended in the next post.
Title image courtesy of ShutterStock
