This chapter is from the book
This chapter is from the book
This chapter is from the book
Completing the Picture
I'm starting this section with some questions: How do we capture the configuration information of our network and processes and do it in a way that enables us to share that information with other professionals? How do we gather all this process control information and represent it in a meaningful way? I suppose we have to start by asking this: What does our network look like?
Some people subscribe to an organic analogy and say that the network is a living organism. Others think that the network is better envisioned as a biosphere. I suppose people are comfortable with organic analogies because it's easier to identify with something that you're familiar with. We're organic, so why shouldn't our view of all things be an organic one? The short answer: because the random nature and boundless complexity of life simply doesn't exist in our networks. Our networks are designed by humans, built by humans, used by humans, and abused by humans. It stands to reason that humans should be able to understand and document them in a reasonable fashion.
Because I'm an engineer, I approach this from an engineer's perspective. Simply put, our networks are really just bits of electronic technology connected by electronic technology into larger and larger islands of electronic technology. The problem is that the islands have gotten so large that it's difficult, if not impossible, for the biological humans who manage them to visualize them.
Another problem is that to properly describe our problem, we need to be able to visualize it so that we can discuss it and share our thoughts with others. Therein lies another problem: Security people have no common nomenclature or iconology to describe our problem. Sure, we have firewalls and IDSs, but how do you draw a picture of it? Even the networking folks resort to drawing pictures of switches. Each vendor has their own clip art libraries that work with programs such as Visio that allow engineers to render network diagrams in great detail. However, no standard set of schematic representations exists.
In our world, if you put 5 people in front of a white board and tell them to draw a picture of a 22-user network that has a firewall, a DMZ, and 25 endpoints of which 20 are user systems, 3 are servers, and 2 are the firewall and switch, you'll get 5 different drawings! We've all been there, in a meeting, and someone draws a firewall as a box with some cross-hatching in it to represent the bricks. Or, they draw a wall and draw flames over it to signify a firewall. Then come the boxes and the notes that are supposed to add clarity to it. When you come back to the white board the next day, you have to spend some time reinterpreting the drawing. What if you get it wrong? "Was that 25 users and 22 endpoints, or was it 25 endpoints and 22 user systems?"
What I'm proposing is that we begin by defining some basic terms and icons so that we can talk about the process from a high level and drill down into more detail as needed. I'll start by saying that there are two basic kinds of endpoints: sources of data and sinks for data. This isn't an uncommon notion. If you have DSL, you probably have aDSL, which is Asynchronous Digital Subscriber Line. The aDSL protocol provides for faster download speed than upload speed because the assumption is that you're going to be sending things such as URLs and requests for email while receiving lots of data in Web pages and your now-abundant email.
Now that we have a basic endpoint definition, we need to add some control. Routers and switches essentially provide data routing services, whether that service occurs at Layer 2 or Layer 3. We also need a security gateway, a device that compartmentalizes the network into two or more trust domains. A firewall is a good example of this type of device. Let's add some networking icons. Figure 3-4 shows how we can start.
)
Figure 3-4 Basic security and networking diagram icons. Note that a source of data points toward the network; a sink of data points away. Sources and sinks of data can combine as gateways or peer connections.
Occam's razor principle states that simple is better, that the simple answer is probably the correct one. In our security world, things start to fail when they get overly complex, so the goal is to keep our nomenclature and iconology simple. But, having a workable set of icons is only half the problem. We need a way to connect them that helps us differentiate between the different paths of information and control. Looking at Figure 3-5, we see that we need three basic types of traffic: network, infrastructure, and process. So, now we have the basic elements that we need to be able to draw a network. Putting it all together, our 22-user network would look like our drawing in Figure 3-6. You can see that we added one additional icon: a diamond that represents the number of users on the network. (Some people have suggested to me that users should be represented by a rock, but I think a diamond is more appropriate because it signifies the creative potential that many users truly represent.)
)
Figure 3-5 Path designations allow us to tell the difference between our network data, the infrastructure management data, and our control path data.
)
Figure 3-6 A complete schematic drawing of our 22 users, 23 endpoints, firewall, switch, and the Internet. Note that the DMZ network is empty.
Now that we have the basic network elements, we need to add the process control modes to our lexicon. I selected the icons in Figure 3-7 because I believe that they quickly and easily represent their function. The up arrow in the integration function shows the accumulation of error; the horizontal arrow depicts a stable set-point. Just to confuse things a bit, the device that performs the derivative function is also referred to as a differentiator (and thus the downward arrow as depicted in Figure 3-7). A bang-bang control is pretty much on or off, so I thought a simple switch would do nicely.
)
Figure 3-7 Icons for the four basic control modes. A differentiator provides the derivative data, and the integrator provides integral data for the summation function.
We have some good schematic icons, but we still haven't identified the summation or correlation points. I think that the icons in Figure 3-8 will work well because they visually represent their function. Okay, maybe the bull's eye is a reach for the correlation function, but I think it still works.
)
Figure 3-8 Summation and correlation functions. Summation adds the PID signals to produce an output, whereas correlation provides either integral or derivative signal outputs.
Note that correlation and summation are not the same process. Correlation examines data looking for trends; summation adds control inputs in an attempt to provide a master control.
Now that we have some basic tools, let's look at a couple of drawings that pull it all together.
Examining our climate control problem and using the schematic icons outlined in this section, a drawing of our climate control system looks like Figure 3-9. Notice that the room is depicted as a sink and that it's between the thermostat and the control process.
)
Figure 3-9 A graphic depiction of our climate control system using process control icons P, D, I, and S.
We need to discuss one more process control element: gain. Gain is the multiplier that acts to increase or decrease the impact of our control inputs. Think of it as leverage in the system. In this case, the gain of the system is fixed by the size of the room. If the heater capacity remains the same, and we increase the size of the room, it will take longer for the heater to move the temperature to the desired set-point. The implication here is that the gain of the system has been reduced.
So, now that we have a method and some nomenclature for depicting our control process, let's apply it to our network. Adding to the 25-user network we defined in the early paragraphs of this chapter, we can make some basic assumptions about our network:
- We have a system for probing our network for vulnerabilities.
- We have some way of identifying intrusion attempts.
- Gain is going to be controlled by how many systems we have.
Looking at Figure 3-10, we can see that our network has the following:
- 25 registered users
- 28 endpoints in total
- 3 server endpoints
- 22 user endpoints
- 1 firewall
- 1 probe system
- 1 security information manager
- 1 IDS
- 1 switch (infrastructure)
- 1 connection to the Internet
)
Figure 3-10 A process control depiction of our fictitious network. Note that the control outputs terminate at a summation point that has no input back into the system.
Looking at this in light of our control nomenclature, we have the following:
- 24 sinks (user endpoints, IDS, SIM)
- 4 sources (servers and probe)
- 1 integrator (IDS)
- 1 differentiator (probe)
- 1 correlator (SIM)
- 1 bang-bang (firewall)
- 1 control device
It becomes pretty obvious that we're missing a few critical components. The control outputs from the probe, the IDS, and the SIM go to a summation function, which isn't defined! We need to understand what this missing mystery function is. It's clearly not the SIM, because the SIM is yet another provider of feedback into the system. The SIM doesn't affect the security set-point of the system, and the purpose of the summation process is to provide a control input. However, a great deal of valuable endpoint-related information gets sent to the SIM. Perhaps some of this information, in conjunction with something new, can help us identify this missing summation process.