Phase II: Document

Once you have determined what you must protect, what it's worth, and who might want to attack it, then it's time to document all of this along with some clear information about who manages the system, who they might work for, and what the system does. The primary reason for documenting these sorts of details is to take a snapshot in time of the enterprise and to protect your organization against loss of this knowledge should people leave the organization. In our experience, formal office documents for this sort of documentation might be necessary for legal and regulatory purposes. There are new federal laws that require companies to fully document their internal controls and for the senior management to literally sign off on the integrity of those controls. Imagine if you were held personally liable for the security of your entire company. You might want it in writing as well.

However, an electronic version of this information shouldn't conflict with this requirement, and we have found that having this information available to authorized parties through a web interface can be invaluable during a crisis. If your data changes frequently, you might consider using a wiki (www.wiki.org) or some other Content Management System (CMS) to help manage the dynamic flow of information into these documents. Finally, when you are constructing this documentation, online collaboration tools can really pay off. In a large multi-state or multi-national organization, it can be difficult to exchange documents with colleagues in different time zones. By making the documentation process as easy and accessible as possible, with the appropriate security controls of course, you can reduce the level of effort required to document systems and system changes. We believe that when creating these documents, it's helpful to keep the process as dynamic and flexible as possible. Formal controls on the documentation process can be put into place after you have collected the information you need to create the formal documentation.

There are three sub-phases within this phase:

1. Create your plan

2. Create a security policy

3. Create security procedures

Create Your Plan

To secure an organization you need to create a plan. To start off with the plan, you need to consider the security models and approaches that are appropriate for your networks. There is a whole range of security models that are appropriate for one set of threats over another, and it is beyond the scope of this book to go into much detail on security models.

As to security approaches, there are currently two effective approaches to building the security plan: the classic and time proven method, Defense in Depth (DID), and the relatively new Holistic approach. We will explain these in detail here, but we consider the Holistic approach to really be a natural extension of the DID approach into the entire enterprise and always recommend the Holistic approach over classic DID.

Defense in Depth

Figure 2.1. An example of a simple network applying the Defense-in-Depth principle.

Defense in Depth relies upon layers of security procedures, technologies, and policies to compensate for breaches to any one or more layers before it as part of a perimeter-based security model. Like an onion, this security approach is implemented by building in layer after layer of counter measures for each identified threat or class of threats around an asset or assets to be protected. For instance a very simplistic layering might look like this: firewalls Layer 1, Intrusion Detection Systems (IDS) Layer 2, systems hardening Layer 3, Host-based Intrusion Detection (HIDS) Layer 4, Kernel-based Intrusion Detection Systems/Kernel-based Intrusion Prevention Systems (KIDS/KIPS) Layer 5, systems backups Layer 6, and insurance Layer 7.

Again, this is just a simplistic example of layered security, which excludes many other elements of the model and assumes that only one technology might make up a layer. Defense in Depth is typically built backwards from a designated perimeter towards an asset or set of assets. This complicates matters tremendously when you start opening up your firewall to allow services into your networks and/or start connecting your networks with other organizations' networks; the perimeter essentially disappears.

In those cases, which are becoming the norm as opposed to the exception, it is very difficult to define what the perimeter is or even where it is. The class DID model is left wanting because the perimeter can, in essence, be bypassed. It's still a good model to keep in the back of your mind, building in layers to fall back on one another, but as a concept it isn't even remotely as effective as it once was. The network perimeter has almost disappeared with the introduction of wireless assets, laptops, VPNs, ASPs, virtual servers, shared hosting, and other technologies. It is our contention that the perimeter is really down at every desktop and server, and in some cases, it's down to the very applications themselves.

This leads to the holistic approach, which is essentially akin to pushing those perimeters straight down to each server and in some cases into each application. In short, it's like living in a world without firewalls, where the bad guys can communicate with every system and program in your network. In many cases, this is precisely the world that we live in now. None of this is to say that firewalls are not useful; that is far from the case. You don't want to get rid of your firewalls and other perimeter security devices, and you certainly don't want to stop creating security perimeters around an asset or set of assets. The point is to realize that this approach is not as effective as it might seem in most cases.

Holistic

The holistic approach makes risk management an integrated part of the organization's standard operating practices. As opposed to looking at risk management and its subset, security, as a perimeter issue or by securing assets via an after-the-fact approach, the holistic approach recognizes that perimeters generally do not exist in modern networks or are difficult to create and that an after-the-fact approach to security is not effective. For any risk management program to succeed, it has to be built into the way the organization functions in as seamless a manner as possible, where security is built into every system and application with the realities of modern computing firmly in mind.

This approach to information security is touted by some as a "new" approach. We disagree. It might be new in the sense that more organizations should be doing it and are not, but it's not new in the sense that it's an approach that the security community is just warming up to. The holistic approach is a logical extension of good risk management approaches. You cannot expect to understand the inter-relationships of your risks and exposures without looking at the whole picture.

This brings us to the issue of looking beyond just IT security. For any risk management program to be effective, all the organization's risks must be evaluated, from physical security, personnel issues, and IT security to legal liability, regulatory issues, and so on. It must all be integrated into the plan. The good news is that life is all about risk management already, so there is nothing unusual about this approach. It comes naturally when you start practicing it. Security has to be part of the whole process, not an after-thought or focused on an isolated element. As the old saying goes, you're only as strong as your weakest link.

Within the holistic approach, there are typically three critical elements to the risk management plan, which are protection, detection, and reaction, defined as follows:

• Protection: Counter measure that includes risk assessments, vulnerability assessments, threat analysis, policies, procedures, and technical controls to defend against all threats to the assets being protected.

• Detection: Elements that monitor for potential and real breakdowns in protections that could result in security breaches.

• Reaction: Those responsive mechanisms that will thwart attacks before damage can be done.

A holistic approach is incomplete and ineffective without all these elements. For instance, if the organization can only detect after the fact that a break-in has occurred, via a non-reactionary IDS for instance, then it lacks a try reaction capacity. Try to create a plan that is as fail safe as possible. Humans are always slower than computers, and any security plan that depends on a person to react to an attack is doomed to fail. You'll never win that race.

After you have settled on the security approach and model, document your plan and how you intend to approach securing your assets.

Create a Security Policy

Surprisingly, many organizations have security policies, which is a step in the right direction. Unfortunately, they tend to either be developed in a vacuum or are woefully out of date with the current technologies being used in an organization. One agency we worked with had a policy of virus scanning all floppy disks that physically came into their offices. This was a great ideabefore laptops, modems, and the Internet and had little practical effect when it came to protecting their network and computers from viruses. Users simply took their laptops home and came back with a virus. The point here is that after you create a set of rules to define what is acceptable behavior on your networks and what personnel controls you will depend on to help control the security posture of your enterprise (such as shredding documents), it's important that the policy be kept up to date. An out of date policy is a liability. Users will recognize that the policy is out of date and will begin to disregard other rules that might still be useful and valid in the mistaken belief that those rules are also no longer pertinent.

Create Security Procedures

Security procedures are briefly defined as those documented steps and methods your organization will undertake as part of its normal operational procedures to manage the security posture of your enterprise. Some examples would be procedures for monitoring firewalls, installing patches, or deploying new systems. These are basically your cookbooks for securing your enterprise. Instead of requiring each member of the organization to work out the methods of implementing the policies and managing their security posture, the procedures break it down into that level of detail needed for that audience. In some cases, this might require significant automation; for instance, a good procedure for securing a Windows workstation, while valuable, might be far more time-consuming than creating a set of scripts that accomplish the same thing. It's still a good idea to document the script, but with a useful tool there is no need to produce a step-by-step guide for the end user.