2.1 Choosing a Security Model

The first step is to understand what types of models are available. The more aware of different models you are, the easier it will be to choose the model that best matches the needs of your company.

The focus of this chapter will be on the OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) model. OCTAVE was, and continues to be, developed by the Computer Emergency Response Team at Carnegie Mellon University, better known as CERT/CC (CERT Coordination Center).

The CERT/CC was created in 1988 by the Defense Advanced Research Projects Agency (DARPA) to deal with computer- related security emergencies. The CERT/CC grew quickly, and today it disseminates information about potential security problems throughout the Internet.

OCTAVE was chosen as an example model because it was designed to integrate with any existing security model. Because network security has to be a subset of a larger security model, you will need a model that makes this type of integration seamless, and painless.

OCTAVE is not the only security model that integrates well with other models; in fact, there are many others. However, the fact that it is maintained by CERT/CC lends a lot of weight to its completeness and the quality of its design.

Before reviewing the benefits of OCTAVE, it is a good idea to review some of the other options available.

2.1.1 RFC 2196: The Site Security Handbook

The Internet Engineering Task Force (IETF) has developed a handbook for creating site security policies. This handbook called, conveniently enough, the Site Security Handbook , also known as RFC 2196, details the process by which administrators ^[2] can develop security policies and procedures.

^[2] The authors of this RFC use the term administrators to refer to network and system administrators, as well as middle management, or decision makers .

One of the major appeals of the Site Security Handbook is that it is designed with flexibility in mind. This model can be applied to large and small companies, with many different types of network infrastructures .

The Site Security Handbook approaches the process of developing a security policy through a five-step process:

1. Identify what you are trying to protect.

2. Determine what you are trying to protect it from.

3. Determine how likely the threats are.

4. Implement measures which will protect your assets in a cost-effective manner.

5. Review the process continuously and make improvements each time a weakness is found.

This five-step model is fairly commonplace, and was originally documented in Control and Security of Computer Information Systems (Fites, Kratz, and Brebner, 1989).

The Site Security Handbook is nice because it provides readers with concrete examples of security policies that are commonly implemented. These examples provide guidance when first developing a plan by giving you a base of information to work from. The downside is that the Site Security Handbook was written in 1997. There are several holes in the advice provided, such as no discussion of VLANs or other methods of switch security, and no discussion of Border Gateway Protocol (BGP) security.

As with any good security model, the Site Security Handbook allows for these omissions by encouraging readers to keep policies flexible. While Step 4 is arguably the most time consuming, Step 5 is undoubtedly the most important. If administrators do not stay abreast of current security problems, then the security policy will eventually become useless.

The Site Security Handbook does not recommend developing policies for specific hardware; instead, policies should be developed for device classes: web servers, routers, workstations, and protocols: RIP (Router Information Protocol) Version 2.0, Open Shortest Path First (OSPF), DNS, and so on.

Finally, the Site Security Handbook helps users document the process for identifying, handling, and reporting a security incident. It also helps you develop a policy for the aftermath of a security incident.

NOTE

Find out more about IETF 2196 on the IETF website: www.ietf.org/rfc/rfc2196.txt

2.1.2 Cisco SAFE

Cisco has developed a security model specifically designed for networks. SAFE is not a stand-alone security model. In fact, the designers assume that users have their own security model in place; SAFE acts as an addendum specifically for network security.

The SAFE model has six security goals, listed in order of importance:

1. Security and attack mitigation based on policy

2. Security implementation throughout the infrastructure

3. Secure management and reporting

4. Authentication and authorization of users and administrators to critical network resources

5. Intrusion detection for critical resources and subnets

6. Support for emerging networked applications

At the core of the SAFE model is a layered approach to security. This is true with most network security models, but that layered approach is not often explicitly stated. In this case, layered security is the second listed goal of SAFE.

Another advantage of the SAFE model is that it uses a modular design. SAFE actually uses a two-tiered modular approach to security. The first group of modules contains broad network divisions, while the second group contains divisions within the larger modules.

There are two different SAFE models, the first covering the needs of enterprise organizations, the second covering the needs of small businesses. The module design for both models is the same (see Figure 2.1).

Figure 2.1. SAFE modules

Within each module there are smaller ones that cover important network design areas. For instance, the Network Edge module has smaller modules for the gateway routers, VPN access, and public services (e.g., web, FTP, or DNS servers).

This type of modularity allows the SAFE model to be slowly integrated into a business. By implementing one or two of the second- tier modules at a time, rather than trying to convert an entire network, network administrators can easily keep track of what has been done, and what has yet to be completed.

The downside is that the modules may not reflect your network design. SAFE allows for this by not forcing you to use all available modules to develop your security policy. However, you may run into problems when even the equipment within a module does not match the your network infrastructure.

SAFE excels at describing detailed ways to secure routers and switches. The network security aspect of this model is exceptional; it provides a lot of practical advice that is not platform specific. The advice SAFE offers for server security is not as detailed. This is undoubtedly because servers are not viewed as a network device unfortunately , the reality is that attempting to separate public servers from the network is next to impossible , and oftentimes a network security team is very active in developing security policies for public servers.

NOTE

Cisco has detailed documentation for SAFE on its website: www.cisco.com/go/safe/

2.1.3 Common Criteria/ISO 15048

The Common Criteria for Information Technology Security Evaluation was released in May of 1998. The International Organization for Standardization (ISO), used Common Criteria as the basis for its security model, ISO 15048, released in June 1999. The most current version of Common Criteria is 2.1, which is ISO 15048 compliant.

Common Criteria is unique in that it evaluates systems and specific products. If an organization adopts Common Criteria as a security model, there are already products that are ISO 15048 certified which should integrate seamlessly into the organization.

Common Criteria refers to the system that is being evaluated as a target of evaluation (TOE). The TOE is evaluated for three types of failures: unauthorized disclosure, unauthorized modification, and availability.

Common Criteria focuses on IT security threats that involve human interaction, regardless of whether or not these threats are intentional or accidental. While this is adequate, it exposes two limitations with this model: It does not address other types of security issues, and it does not take into account non-IT security issues.

While Common Criteria can certainly integrate with other security models, it is easier to follow a single model throughout the entire security process. Having a separate security model for IT issues can only cause confusion.

Common Criteria breaks its audience down into three different groups:

1. Consumers The group or person setting the requirements for the security level of a product or system. Consumers dictate what level of security is important, using a protection profile developed using Common Criteria.

2. Developers Developers can use the Common Criteria method to certify their product before releasing it to the public. By following a standardized, or well-accepted, methodology in designing the security for a product or system, developers can indicate they are ISO 15048 certified.

3. Evaluators Common Criteria provides evaluators with guidelines that can be used when a new product or system is being tested . Using these standard guidelines for evaluation can simplify the evaluation process.

The Common Criteria method is divided into three different parts. Each of the previously mentioned groups has different responsibilities within the different parts. The three parts of the Common Criteria model are:

1. Introduction and overview This part presents the Common Criteria model and defines the process involved in evaluating the security of IT products. It also reviews the process and language involved in writing security requirements for IT products.

2. Security functional requirements This part is used to build the catalog of security requirements for a specific TOE. Evaluators use this catalog to test a TOE.

3. Security assurance requirements This part of the evaluation process uses predefined Common Criteria assurance levels to rate a TOE.

Common Criteria certification requires that each group complete all three steps in this process.

NOTE

More information about Common Criteria/ISO 15048 is available on the Common Criteria website: www.commoncriteria.nl/