9.7 Architectural Considerations

9.7 Architectural Considerations

In developing our security architecture, we need to evaluate potential security mechanisms, where they may apply within the network, as well as the sets of internal and external relationships for this component architecture

9.7.1 Evaluation of Security Mechanisms

At this point, we should have requirements, goals, type of environment, and architectural model(s), so we are ready to evaluate potential security mechanisms. As with each component architecture, when evaluating mechanisms for an architecture, we should start simple and work toward more complex solutions only when necessary.

Where a security mechanism will apply in a given network will depend primarily on where security requirements are located throughout the network and what the security requirements are based on the results of the requirements analysis and the security and privacy plan.

The architectural models presented in Chapter 5 can help determine where security mechanisms can be applied in the network. For example, the access/distribution/ core architectural model, which separates a network based on function, can be used as a starting point for applying security mechanisms. Using this model, we can increase security at each level, from access network to distribution networks to core networks, by either adding security mechanisms or enhancing the amount of security provided by each mechanism. This is shown in Figure 9.12.

Figure 9.12: Access/distribution/core architectural model as a starting point for security.

In Figure 9.12, security is increased from access to distribution to core areas, either by adding security mechanisms at each area or by increasing the level of security (i.e., enhancing security) at each level. For this architectural model, most traffic flows are sourced/sinked at access networks and travel across distribution and core networks. Through the addition of mechanisms or enhancement of mechanisms at each level, a traffic flow will encounter higher levels of security as it moves from access to distribution to core networks.

In Figure 9.12, traffic flows from User A to User C travel across both access and distribution networks and would encounter two levels of security, level 1 and level 2 firewalls, where level 2 would be a greater level of security than level 1. A level 2 firewall may have a more complete ACL, stricter rules for filtering traffic, or greater logging and detection capability.

Traffic flows from User C to User A travel across access, distribution, and core networks. As traffic moves from User C to the core network, it would encounter multiple security mechanisms (intrusion detection, firewalls, encryption/decryption, and packet filters), with security increasing from access to distribution to core. In addition, as traffic moves from the core network to User A, it will encounter three levels of firewalls. In a similar fashion, the service-provider and intranet/extranet architectural models can also be used to develop a framework for security in a network.

As mentioned in Chapter 8, security perimeters (i.e., security zones or cells) can be developed within a network to accommodate multiple different levels of security requirements. Two common methods of developing security zones are to increase security as you move deeper into the network (an example of this is shown in Figure 9.12) or to develop zones wherever they are needed in the network, regardless of topology.

When security zones are developed to increase security as you move deeper into a network, they become imbedded within each other, as shown in Figure 9.13. In a sense the security levels look like the layers of an onion, with the innermost layers having the highest level of security.

Figure 9.13: Security zones embedded within each other.

Security zones are based on the various security requirements determined during the requirements analysis process and should be described in the security and privacy plan. There may be requirements for different levels of security, coupled to groups of users, their applications, their devices, or devices that are shared among users. Security zones developed to meet such requirements may be scattered throughout the network and may even overlap one another. An example of this is presented in Figure 9.14.

Figure 9.14: Developing security zones throughout a network.

In Figure 9.14, five security zones are shown, based on different security requirements. The first zone (security level 1) covers the entire network and is intended to provide a general level of security for all users, applications, and devices. This may include intrusion detection and logging. The second zone (security level 2) provides a higher level of security between this network and all external networks. This may include NAT and firewalls.

The third zone (security level 3) provides another level of security for an entire group of users, applications, and/or devices (Group D), whose security requirements are different from the rest of the network. For example, this group may handle financial and/or proprietary information for the company. The fourth zone (security level 4) provides security for a subset of users, applications, and/or devices from multiple groups (Groups A and B). These are select users, applications, and/or devices whose security needs are different from others in their groups. For example, they may be working on company-classified projects, producing data that need to be protected from the rest of the groups. The third and fourth zones may apply mechanisms to protect their data, such as encryption/decryption, and may have access protection via firewalls and/or packet filtering. The fifth zone (security level 5) is security for devices that are used by multiple users, such as servers. This zone may employ monitoring, logging, and authentication to verify user access.

Figures 9.12, 9.13, and 9.14 show how security mechanisms may be applied in a network to achieve multiple different security levels or zones.

9.7.2 Internal Relationships

Interactions within the security architecture include trade-offs, dependencies, and constraints between each of the security mechanisms for your network. Some examples are presented here.

Interactions between Encryption/Decryption and Other Security Mechanisms

Some security mechanisms require the ability to look at, add to, or modify various information fields within the packet. For example, NAT changes IP address information between public and private address domains. Encryption/decryption mechanisms may encrypt information fields, making them unreadable to other mechanisms.

9.7.3 External Relationships

External relationships are trade-offs, dependencies, and constraints between the security architecture and each of the other component architectures (addressing/routing, network management, performance, and any other component architectures you may develop).

There are common external relationships between security and each of the other component architectures, some of which are presented in the following sections.

Interactions between Security and Addressing/Routing

NAT is an addressing mechanism that is often used to enhance security. Therefore, when it is applied for security, it will also impact addressing for the network. In addition, dynamic addressing can interfere with address-specific protective measures and logging. It is more difficult to determine what is going on when IP addresses are changed frequently.

Interactions between Security and Network Management

Security depends on network management to configure, monitor, manage, and verify security levels throughout the network. In addition, there is a need for maintenance access even during attacks where in-band access to network devices is not available. For example, when devices are not at the same location, using dial-up for out-of-band access is a potential fallback position to take.

Interactions between Security and Performance

Security and performance are often at odds, as security mechanisms can affect network performance. The security zones described earlier in this chapter can constrain performance within the areas described by the zones. When security is a high priority, security mechanisms that impact traffic flows may restrict performance mechanisms to operate within security zones or result in performance being minimized for that zone (Figure 9.15).

Figure 9.15: Security mechanisms may restrict or preclude performance within each zone.

When performance is high priority, particularly when there is a need to provision end-to-end performance between select users, applications, or devices, performance mechanisms may preclude the use of intrusive security mechanisms in those areas of the network.