What Does this Risk Mean to Me?

Author: Peyton Engel

May 2007

Part I of II: The Relationship Between Vulnerabilities and the Context in Which they Are Found

This article is the first of two essays based on a talk from the 2007 OISC conference regarding new thoughts on the subtleties of prioritizing vulnerability information. In this episode, we’ll explore ways in which the importance of a single vulnerability might vary drastically depending on where it crops up. The sequel will discuss techniques for discovering hidden areas of importance and quantifying the impact of a security flaw.

Before we dig deeply into the question of prioritization, we need to be clear about what constitutes a vulnerability. Specifically, a system has a vulnerability if the following three conditions are fulfilled:

1. There is a flaw in the system (this can be a problem with design, the way the design has been implemented, the way the system is administered, etc.)
2. The flaw involves security (i.e., the confidentiality, integrity, or availability of some aspect of the system or its contents)
3. It is possible to trigger that flaw (the flaw is exposed in some way such that its consequences can be felt)

With out any one of these ingredients—if the system had no bugs, or of the bugs didn’t relate to security, or if the bugs weren’t exploitable—there would no real vulnerability. Note, however, that there might well be many vulnerabilities that remain as yet unknown. In practice, this is obviously the case: virtually every patch, hotfix, or update released by our various vendors represents a cure for some problem about which most of us had no prior information.

Let us turn to the familiar endeavor to quantify risk in terms of cost. Typically, this figure is presented in dollars per year, and generally at least two factors are involved: Single Loss Expectancy (i.e., the cost, in dollars, of a single incident), and the Annual Rate of Occurrence (i.e., the number of incidents that take place over a year). If we multiply these two basic numbers together, we’ll get some figure, in dollars per year, ostensibly representing what we expect to spend dealing with security incidents.

One possible—albeit broad—definition of a security incident might be, “a circumstance wherein the presence of a vulnerability in a system precipitates a cost.” At this point, we’re finally ready to consider how a single vulnerability may vary in importance, depending on context.

Take, for example, an organization whose business involves a manufacturing process. Businesses such as these typically maintain two more or less parallel environments, which may be interconnected. First, there is the office network, with traditional file and print services, productivity applications, and the like. In addition, there’s the process control network, consisting of I/O devices (sensors, drives, robotic components), programmable logic controllers (PLCs), process historians, and the other ancillary components that run the manufacturing line.

The first important thing to note is that these two environments have different priorities. In most IT shops, regulatory compliance emphasizes the integrity and the confidentiality of information. For a production network, in contrast, availability is the key metric of success: outages translate directly into missed production of goods, and therefore lost revenue. Obviously, availability is important to IT networks (especially for  technologies like IP Telephony); likewise integrity and confidentiality have a place in process control, but the emphasis differs.

A more concrete difference lies in the way these two environments use the network. In a production environment, communications are generally conducted via the Common Industrial Protocol (CIP). CIP was designed with two main goals in mind:

• To provide a standard framework within which production components from various manufacturers could interoperate (e.g., Rockwell controllers can accept input from Siemens sensors and signal KUKA robots)
• To provide a means of delivering messages to multiple endpoints simultaneously (e.g., all the drives running a conveyor belt must start and stop together)

Over the past decade, there has been a push to implement CIP over commodity networking topologies, most notably Ethernet. The theory behind this direction is that a single suite of networking hardware will be cheaper both to acquire and administer than two diverse families, and that an independent communications infrastructure will also make the creation of manufacturing equipment and production networks both simpler and easier.

This intuition is misleading, however, because office automation systems and production systems often use their networks in different ways. Specifically, even though both environments may communicate using TCP/IP over Ethernet, in order to facilitate the simultaneous delivery of information to multiple endpoints, production networks make heavy use of broadcast and multicast traffic. In traditional office networks, most traffic is unicast. In fact, it was the dominance of unicast traffic that motivated the move to switched Ethernet: not all ports need to see all packets. Production networks swim against this tide, and in some cases they actually negate the benefits provided by high-capacity switch backplanes because their usage of the network is the exact opposite of the one for which the switch is optimized.

There are other important differences as well. Generally speaking, in an office network, the most valuable assets (say, the corporate ERP, major databases, or back-end processing systems) reside in centralized, highly reliable data centers. More or less expendable systems—printers, desktops, and the like—populate the network edge. The production network is the exact opposite: centralized systems (e.g., a process historian) are not critical to the operation of the production line itself. Rather, it is the edge systems (robots, sensors, PLCs, etc.) that actually control the manufacturing process, and are therefore most essential to the network’s mission.

Let us consider, then, the effect of a worm that exploits a hypothetical vulnerability affecting Windows XP. On the office network, the affected systems are generally workstations—the process of disinfecting them is tedious, but feasible—and the main impact is probably network brownouts for areas where un-patched systems reside. On the production network, however, the PLC systems are running Windows XP, they cannot be patched for a variety of technical and regulatory reasons, and saturation of the network with worm traffic halts the assembly line.

The same vulnerability, therefore, might turn out to be critical or inconsequential, depending on where it occurs. We can run vulnerability scanners, and gather information about which systems exhibit certain flaws, but important questions remain:

• How do we prioritize the findings from our vulnerability assessments, so that they accurately reflect risk to the environments?
• What steps can we take to minimize the risk posed by vulnerabilities that are as yet undiscovered, and which our tools therefore cannot find?

Stay tuned for the next thrilling installment, where we’ll look at some techniques for answering these questions.

Berbee, drawing on strategic partnerships with Cisco, IBM and Microsoft and the far-reaching experience of its hundreds of engineers, has assisted clients with a full range of technology solutions. For more information, please visit www.berbee.com or call John Uchaker at (513) 677-4119.