The Security Wheel

The security wheel is a figure symbolizing the iterative process of network security. At the heart of the process is the Network Security Policy. The security wheel is shown in Figure 4.1.

Figure 4.1. The security wheel.

You might see the entire process visualized in the security wheel described in other Cisco documents or Cisco Press books as a Security Posture Assessment, or SPA. Regardless of which term is used, the idea is the same: It is an iterative process to improve the security of a network. For the CSI Exam, you will probably not see the term SPA , but you might see a reference to the security wheel.

Everything you do in the process of securing, monitoring, testing, and improving security occurs with reference to the network security policy. Because it is an iterative process, we could start anywhere , but for convenience we'll take it from the top.

Secure

This is the stage where many things can change: It could also be called the implementation stage. At this stage of security, the technologies are actually applied to the network. The Secure stage can be done in pieces of varying size, depending on the needs being addressed and the comfort level of those who are responsible for making it happen (which could be IT management or even corporate management).

The SAFE Blueprint uses a modular approach when tackling the implementation of security on a network. Handling things in this way has two advantages. First, each module's security needs can be developed and implemented independently of what happens in other modules, keeping a problem to a reasonable size in both management and cost. Second, the architecture can focus on the relationship between any two modules. If you see a multidevice simulation problem on the exam, you should follow the same approach: Tackle it in pieces.

In the Secure stage, hardware is deployed in the form of firewalls, VPN concentrators , more switches and/or routers to isolate problem traffic, and so forth. Simultaneously, configurations on existing devices usually must be changed. Access controls are refined (or added), AAA is implemented, unused ports are disabled, routing update authentication can be implemented, and so on. The endpoint of this stage comes when the secured network is operational: Testing and troubleshooting are complete (in terms of the additions and modifications made).

Monitor

It is always possible to collect so much data about the network's behavior that it is not all read. However, some data is more important than other data, and the point of the Monitor stage is to observe the data that indicates the behavior of the security devices and processes.

SAFE assumes that you monitor the critical ingress and egress points on your network, as well as the security measures placed on interior significant assets. This is the stage in which you look for weaknesses that you did not know existed or possibly chose not to repair, whether for technical or financial reasons, and watch to see if others attempt to exploit them.

Part of the Monitor stage involves responding when you detect a problem. This interaction with the security policy will probably lead to revisions and improvements after every major incident (which, hopefully, will be both few and seldom). Depending on your specific IDS and its settings, you might have automatic responses for an incident or access attempt. In that case, an important part of the Monitor stage involves validating that the response happened as it should. That might require you to compare data from perimeter device logs against IDS logs. During any investigation, of course, you will be comparing entries from numerous logs and cross-checking what happened where and when.

During the Monitor stage, as you compare data from multiple devices, it is very important that the devices have synchronized clocks. A subtle attacker might change the system time on a device to help hide his trail in the log analysis, something we'll talk about again in Chapter 5, "Management Protocols and Functions." You should know what it takes to be sure of the accuracy of the time stamps in your monitored data.

Test

This stage of the security wheel is one that you might have to explain to management because it is different from the way that most business operates. The speed of change varies among industries, but the IT sector has a very rapid rate of change. Those who try to advance their careers are acutely aware of this, of course, as the volume of material to know seems to grow more rapidly than the time available in which to learn it.

However, this is even more true when it comes to security. Many hackers who develop attacks are the most knowledgeable people about how systems work. Hackers have been known to explain to developers exactly what happens in various operations of the developers' own software. Although these hackers are numerically rare, the tools that they develop are often widely available and frequently are copied and used by a large community, some of whom craft improvements or refinements that they, too, make available.

In most product development, managers would love to have this kind of virtuous circle effect. The result for security, however, is that some of the fastest product development takes place on the other sidenew vulnerabilities are constantly uncovered and are often exploited within days, at the most. That makes the testing stage an unsung hero in protecting the network.

The testing stage is not about testing what you have against the threats that you designed against (the existing product competition). It's about testing against the new threats as they emerge (the next generation of competition). What's more, you test the network as it exists at the moment, which is not necessarily as it was when the last audit was conducted . That matters because networks as well as threats evolve : New hosts are added, new applications are deployed, patches are added, hardware is upgraded, existing software is moved to different hosts , and so on. In other words, the testing stage is about knowing where you stand against the competition's latest and greatest options, the ones most likely to wreak havoc. Unfortunately, too many people are unprepared.

Improve

In this stage, you determine the changes needed, as identified during testing. Cisco understands that this is often a hard sell to management: You must justify the cost in terms of something not happening, without being able to guarantee that it absolutely would happen if you don't make the changes. Nonetheless, unless you make the improvements, security will stall at one level of protection while the threat evolves to another. This stage, of course, morphs into the first stage (secure) as you actually get the new improvements into place.