As with any IT project, there must be a demonstrable need for the technology before its acquisition and implementation. Unfortunately, many organizations succumb to the temptation of caving in to the wish list of their IT staff and purchasing equipment without performing the required needs analysis. Many IT professionals can speak to the experience of being asked to architect a need to fit the technology rather than the other way around—architecting the technology to fit the need ... the preferred approach. There is a basic lesson to be learned here for both IT staff and their management. Without a needs analysis, followed by a gap analysis and finally a proper methodology in place for the implementation of the technology, a network security project is doomed to fail. Vendors such as Cisco usually have their own methodology for these facets of a secure network project. Because Cisco’s customers often look to Cisco sales engineers for direction in their technology projects, it makes good business sense that Cisco should have their own system development life cycle for secure networks. This approach is certain to help sell equipment and also (but less cynically) to ensure that the customer is satisfied with the solution. We examine this cycle in the context of both operational security principles and disaster recovery planning and business continuity planning.
Cisco System Development Life Cycle (SDLC) for secure networks recommends a five-phase approach for security projects. When performed in order, these five steps help organize the workflows that need to coincide throughout the life cycle of a network. Figure 2.1 illustrates these phases.
Table 2.1 contains the steps defined in Figure 2.1, as well as a breakdown of the separate elements within each step.
TABLE 2.1 Secure Network Life Cycle Matrix
INFOSEC professionals need to be aware of a few overarching principles to ensure secure operations. Some of the principles are as follows:
Separation of Duties (sometimes Segregation of Duties)
Rotation of Duties
Trusted Recovery
Change and Configuration Controls
Table 2.2 summarizes the elements within each principle.
Note
Here are the separate controls that comprise SoD:
Two-Man Control.Multiple individuals audit and approve each other’s work. This is an example of an administrative control.
Dual Operator Control.Two individuals are required to complete a single task. An example might be a safe deposit box that requires the use of both the customer’s and the bank’s keys to open. This is an example of a technical control.
There are a number of utilities and other tools that you can use to assess your network’s security from the perspective of a potential attacker. Don’t forget that networks should be resilient against attack both from internal and external threats. Also, the vulnerabilities discovered must be measured against their relative likelihood (that is, risk) and, in a practical sense, whether the cost of the corrective controls employed might outweigh the benefit of their implementation. According to Cisco, this is why we implement security controls:
Create a baseline for corrective action.
Define ways to mitigate discovered vulnerabilities.
Create a baseline of an organization’s current security measures.
Measure an organization’s progress in fulfilling security policy.
Analyze the relative cost vs. benefit of security improvements.
Support the steps of the Security SDLC.
Network security testing tools can be grouped into different types. See if you can determine whether the following test the network’s or system’s confidentiality, integrity, or availability? (The answers appear in the note at the end of this section.)
Network scanning
Vulnerability detection
Log analysis
Integrity checkers
Virus detection
War dialing
War driving (802.11 or wireless LAN testing)
Penetration testing
Here is a list of some common security testing tools, along with the organization behind them:
Network Mapper (Nmap).Open Source from Insecure.org.
Nessus.Tenable Network Security Inc.
GFI LANGuard.GFI Software Inc.
SuperScan.Foundstone (division of McAfee Inc.).
Metasploit.Metasploit LLC.
Tripwire.Tripwire Inc.
The following is a more detailed explanation of some of the more important testing tools from this list.
Exam Alert
Scanners are testing utilities that probe a network for specific vulnerabilities. There is a fine line between scanning a network and hacking a network because often the same tools are used; the difference is the degree to which they are employed. For example, Tenable Security Corporation’s Nessus product is a scanner that, when carelessly employed, can create a denial of service (DoS) on a vulnerable network or end system if dangerous plug-ins are enabled. In Chapter 8, “Network Security Using Cisco IOS IPS,” we examine the role of intrusion detection systems (IDS) and intrusion protection systems (IPS). These are also known as sensors. Scanners probe networks, and carefully tuned sensors can detect such probes.
In short:
Scanners (like Nessus, Nmap, and SuperScan) probe a network for vulnerabilities and can even simulate an attack when certain plug-ins are enabled.
Sensors monitor a network for signs of probes and attacks. IDSs and IPSs are sensors.
Nmap is a popular scanner, running on Windows, Unix, and Linux systems, and an example of an excellent Open Source tool.
Some features of Nmap include the following:
Low-level scanner, because it will probe for vulnerabilities in layer 3 and 4 of the OSI model but no higher.
Often employed as a general-purpose scanning tool, often by hackers, to perform the initial reconnaissance of a network.
Both ping sweeping and stealth port scanning functionality to make it difficult for IPSs to detect.
OS footprinting (explained in Chapter 1, “Network Insecurity”).
Figure 2.2 shows an example of Nmap using its new GUI, Zenmap.
SuperScan is another example of a scanner. Here are some of SuperScan’s features according to Foundstone:
Superior scanning speed
Support for unlimited IP ranges
Improved host detection using multiple ICMP methods
TCP SYN scanning
IP address import supporting ranges and CIDR formats
Simple HTML report generation
Source port scanning
Fast hostname resolving
Extensive banner grabbing
Massive built-in port list description database
IP and port scan order randomization
A selection of useful tools (ping, traceroute, Whois, and so on)
Extensive Windows host enumeration capability
Figure 2.3 illustrates the main screen of SuperScan. Interestingly, the scan against the network node at IP address 192.168.99.130 returned no results. This could indicate that an intermediate device such as a firewall (discussed in Chapter 5, “Using Cisco IOS Firewalls to Implement a Network Security Policy”) has detected the scan as an attack and has employed countermeasures to hide the scanned host, at least temporarily.
As indicated previously in the discussion of the Trusted Recovery as a principle of Operations Security, you must both expect and plan for a disaster. Although it is impossible and also impractical to plan for every eventuality and contingency, plans must be put into place for the events that are the most likely to occur. For example, it makes no sense to have a recovery procedure in place in case of an earthquake disaster in an area where the risk is minimal, but where risk of loss due to military action or civil unrest is the most likely.
In chronological order, the three phases that disaster recovery procedures (DRP) and business continuity planning (BCP) cover are as follows:
-
Emergency response
-
Recovery
-
Return to normal operation
Let’s look at the differences between disaster recovery and business continuity planning separately in the context of these three phases.
Business continuity planning focuses on the short- to medium-term requirements essential to continuing an organization’s operations with the following objectives:
Relocation.Relocation of elements critical to an organization’s operations to a remote or mirror site, while faults at the original site are remedied. An example of this might be a federal government department relocating operations temporarily to a mirror site and using data recovered from backup at the moment of the disaster (emergency response and recovery).
Alternate Communication Channels.Use of alternate communication channels with suppliers, customers, shareholders, knowledge workers, and so on, until primary channels can be phased back in when the disaster is remedied (recovery).
Disaster recovery procedures are concerned with the actions that are taken to deal with the disaster immediately after it has occurred. In this sense, they are a subset of business continuity planning. It is the process of restoring access to systems, data, software, and hardware critical to business operations. It deals with the second phase in the three phases of DRP and BCP.
Here are some key objectives of disaster recovery procedures:
Minimize the requirement for on-scene decision-making during the emergency by setting out specific procedures.
Ensure the safety of workers as well as their ability to return to work quickly.
Ensure that data integrity is not compromised during the emergency.
Ensure that key business functions are not impaired and can return to normal as quickly as possible.
As we saw in the section “Cisco System Development Life Cycle for Secure Networks,” the initiation phase is used to categorize the risks and to do an initial risk assessment. Not all disruptions are the same magnitude. Here’s a list of disruption categories:
Nondisaster.A business process is disrupted for a finite period of time.
Disaster.A facility is unusable for an entire day or more.
Catastrophe.The entire facility is destroyed.
Redundancy is the key to dealing with destruction. There are three types of backup, as follows:
Replacement with a redundant component.A failed or destroyed component is replaced with an equivalent component.
Service-Level Agreements (SLAs) with vendors.When a service is disrupted, it is replaced with another service and/or restitution is made to an insured value stipulated in the agreement.
Complete off-site backup facilities.Production can be moved to the following:
Hot sites (or mirror sites).Redundant site with real-time copies of data from the primary site. The site is maintained in operational readiness with data synchronized from the primary site. When a disaster occurs, only the very last, incremental changes in data need to be restored for the site to be fully operational.
Warm sites.Redundant sites without real-time copies of data and software. The disaster recovery team needs to pay a physical site visit to restore data to the site for it to become fully operational.
Cold sites.Redundant sites that have the minimum power, environmental controls, and network links but no equipment. During disaster recovery, equipment would have to be sourced and installed and backups restored before full functionality can be recovered.
Note
Here are the answers to the exercise from the “Types of Testing Techniques” section. You were asked to determine whether the following test confidentiality, integrity, or availability. The suggested answers appear in parentheses beside the item: C = confidentiality; I = integrity; A = availability.
Network scanning (A)
Vulnerability detection (C, I, A)
Password cracking (C, I)
Log analysis (I, A)
Integrity checkers (I)
Virus detection (I)
War dialing (C, I)
War driving (802.11 or wireless LAN testing) (C, I)
Penetration testing (C, I)
A comprehensive network security policy is a contract amongst all the stakeholders in an organization. It spells out clear rules for how to protect an organization’s people, information systems, and network devices both from external and internal threats. According to Request for Comment (RFC) 2196, “The Site Security Handbook,” a security policy is:
“...a formal statement of the rules by which people who are given access to an organization’s technology and information assets must abide.”
Also, according to the same RFC:
“The main purpose of a security policy is to inform users, staff, and managers of their obligatory requirements for protecting technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Another purpose is to provide a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the policy.
Therefore, an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.”
According to Cisco’s Security SDLC, we must first determine whether we have anything of value to protect. Whether our assets are intellectual property, an inventory of items, people, or precious commodities, the assets must be defined and valuated at the outset of the Initiation phase. This demonstrates the need for a network security policy, risk assessment, and the ongoing maintenance of the secure network. These are detailed in this section. Understanding these principles teach you valuable context in which to remember the details. This is important for the exam and also for that real world that we work in!
Note
RFC 2196, “The Site Security Handbook,” is referenced in Appendix B, “Need to Know More?” It is an excellent, plainly written, and common-sense approach that can be used as a template to network security policy planning and implementation.
We’ve seen the attackers in Chapter 1, “Network Insecurity.” We know their motivations. We can infer from this that whatever the type of organization, there is something there that an attacker wants. It might not have any monetary value to the attacker, but an organization always has assets that it needs to protect from access and DoS attacks. Figure out what you are protecting. The first step in developing a comprehensive security policy is to define an organization’s assets. What constitutes an asset?
Anything that others might want.
Processes, systems, and data that is critical to an organization’s operations.
Anything that, if compromised, would stop an organization from conducting its affairs.
Placing value on these assets is a separate exercise, as we see in the “Risk Management” subsection later.
Remember the axiom, “Security is a process, not a product”? No surprise then, that a security policy, which defines the objectives and rules for that process, is never finished. It is a living document, a contract between all the stakeholders in an organization to constantly revisit and evolve an organization’s security posture in the face of new threats and technology.
Why do we need a security policy? Here are three reasons. Security policies serve to do the following:
Inform stakeholders (users, staff, and managers) of their respective responsibilities.
Specify security controls/mechanisms (administrative, technical, and physical).
Create a baseline from which to improve security.
What do security policies do? Comprehensive security policies contain high-level statements that set out and outline management’s position with respect to protecting an organization’s people and data and how these goals might be accomplished. Specifically, the security policy defines rules for the following:
Protection.Provides confidentiality, integrity, and availability protection for people and information.
Expected Behavior.Defines the rules for expected behavior (see the Exam Alert).
Consequences.Specifies the consequence of security violations.
Investigation.Authorizes staff to investigate security violations.
Monitoring.Authorizes and designates staff to monitor and log system activity.
Exam Alert
The Acceptable Use Policy (AUP) is the component of the security policy most visible to users and the most common. The AUP sets out very specific rules as to what constitutes allowed versus not allowed behavior to prevent misinterpretation. For example, an AUP might list the specific websites and types of websites that users are prohibited from visiting. Not coincidentally, an effective AUP can help promote productive Internet use.
Groan ... not policies, standards, guidelines, and procedures! This sounds like a lot of writing, meetings with people who love legalese, and people with big sticks making sure that the policies are enforced. Many texts do not do a good job on differentiating this important terminology. Essentially, there is a hierarchy here:
Policies do specify overall statements of direction, management position on security issues, organization goals in the context of security, definitions of roles, and so on.
Policies do not stipulate the details of day-to-day implementation.
Standards, guidelines, and procedures are derived from policies. These stipulate the details of day-to-day implementation per the last bulleted point. Policies do not answer “how,” but they do variously answer “who, what, when, where, and why.” See if you can determine in the following list which of “who, what, when, where, and why” the policy type answers.
There are three types of policies, as follows:
Governing policy
Technical policies
End-user policies
Figure 2.4 shows how these policies relate, and the following section describes them in more detail.
Note that there is only one governing policy because it is the over-arching, high-level policy that describes security concepts that are important to the organization as a whole. The audience is management and technical custodians.
These policies are more detailed than the governing policy. The audience is technical custodians. They detail the security responsibilities required to address specific systems or issues. For example, a technical policy might specify the policies for site-to-site confidentiality of data and physical access controls, but not how it might be accomplished. Examples of technical policies include the following:
General policies
Email policies
Remote-access policies
Telephony policies
Application policies
Network policies
Wireless communication policies
Now that the policies are in place, let’s develop a plan for their actual implementation and enforcement. Policies are too general. Standards, guidelines, and procedures detail the specific “how” the policies are implemented. While agreeing that they are related, what is the difference between standards, guidelines, and procedures? Here are some definitions.
A security policy is compared against standards. Standards can be differentiated from other security policy elements in these ways:
They define the measuring stick against which the efficacy of security controls is judged.
Standards result in consistent, uniform application of specific technologies.
Standards are usually mandatory.
Security policies also include a number of guidelines. Guidelines can be differentiated from other security policy elements in these ways:
Guidelines are similar to standards but not usually mandatory.
Guidelines create a general envelope of rule application that remains more flexible than standards.
Guidelines can aid in standards development. Guidelines can be tightened up to standards if they prove effective.
Guidelines are used to ensure adherence to more general security policies.
Some widely-accepted guidelines include the following:
NIST Computer Security Resource Center
NSA Security Configuration Guides
The Common Criteria “standard”
Rainbow Series
The arms and legs of a security policy are found in its procedures, as follows:
Procedures are usually required.
Procedures are the most granular—the lowest level of all.
Procedures contain detailed steps to accomplish certain tasks.
Procedures contain step-by-step tasks to implement policies, standards, and guidelines.
Procedures are sometimes known as practices.
Generally speaking, there are three main groups of stakeholders responsible for the security policy: senior management (or owners), security staff, and users.
Senior Management. Ultimately responsible for the whole security policy, its operation, and implementation.
Security Staff:
Senior Security/IT management (CSO, CIO, CISO).Responsible for the security policy.
Senior Security/IT Staff.Have input on the security policy, possibly drafting parts of it.
Security / IT Staff.Responsible for implementing the security policy. These are the “foot soldiers.”
End Users.Responsible for complying to the security policy.
As was seen in the section “Defining Operations Security Needs,” the first part of the “Cisco System Development Life Cycle for Secure Networks” was the Initiation Phase, where security categorization and a preliminary risk assessment occurred. Refer to Figure 2.1.
Risk management has two components, as follows:
Threat Identification.This is the process of identifying the threats faced by a system or network. This is sometimes called threat modeling.
Risk Analysis.This is the process of estimating the probability and threats that a system faces. Two principles are adhered to:
An estimate of potential loss can be calculated for each risk.
Strive for worst- and best-case estimates.
The main purpose of risk analysis is to try to quantify the possible impact or loss of a threat. There are two categories of risk analysis:
Quantitative.Using asset value as a starting point, develop a mathematical model to come up with a monetary figure of expected losses.
Qualitative.This is a scenario-based model. This is particularly useful for countries, large cities, and states where it is impractical to list all assets (the starting point for quantitative risk analysis).
Because quantitative risk analysis assumes that risk can be determined mathematically, it stands to reason that there should be a Quantitative Risk Analysis Formula. Figure 2.5 illustrates the formula and the variables that can be plugged into the formula.
It’s fun to plug numbers into the formula and see what pops out, but in the end, it’s only a bit better than guessing. In most organizations, the risk assessment teams use a combination of quantitative and qualitative methods to determine the risk factor of a specific threat. For example, who determines whether the exposure factor (EF) of a tornado is 75% destruction of a place of business for any single occurrence? It might be easier to estimate the annualized rate of occurrence (ARO) based on weather data, but what value is an annualized loss expectancy (ALE), which is itself a product (literally) of three estimates? The best that can be hoped for is to provide some measure of the relative risks of specific threats. The numbers generated also help justify the expense of implementing a comprehensive security policy and focusing costs where they can be of the most benefit.
Here is an example of applying the Quantitative Risk Analysis Formula. What is the Annualized Loss Expectancy (ALE) of a knowledge worker carrying a new laptop through airports in a given year?
AV of a laptop = $1,500
EF of carrying the laptop through airports is estimated at .25% based on industry data.
ARO of carrying the laptop is estimated at 48 occurrences because the knowledge worker will take 24 trips abroad in a year, and each visit will require the worker to go through an airport twice.
Answer: ALE = $1,500 * .25 * 48 = 18,000
This number means nothing by itself, but when comparing relative risks of other threats, it can help an organization prioritize risks and develop a more effective implementation strategy for its security policy.
Why do we have to manage risk in the first place? Can’t we eliminate it entirely? There are two, complimentary schools of thought about risk. These are outlined below. You can either manage risk or run away from it:
Risk Management.Reduces risks to levels deemed acceptable by the system’s stakeholders.
Risk Avoidance.Eliminates risk by avoiding threats entirely. This is not a practical option in the business world where some risk = profits. Even in the public sector this makes no sense. For example, cutting access to an important website such as a weather information portal may in itself increase the risk to the very stakeholders the site is meant to serve.
What are some ways to reduce risk to acceptable levels? Table 2.3 covers some sample threats and possible procedures (remember them?) to counter their risk.
The first principle of secure network design is to understand that the finished product, a secure system, is never truly finished.
The traditional approach is to develop a security policy, taking into account business needs and risk analysis, as well as industry best practices, as depicted in Figure 2.6. This security policy is implemented, leading to a secure system. Ongoing security operations are carried out by security staff (see “Figure 2.6), as well as the overarching security policy. Similarly, organizations should constantly educate themselves using industry best practices to improve the secure system in real-time, as well as to incorporate this knowledge in the security policy (arrow “B” in Figure 2.6). This requires some flexibility in the security guidelines. As long as the standards dictated by the security policy are met or exceeded, this shouldn’t present a problem.
Note
Referring to Figure 2.6, Security Ops include incident response, monitoring, maintenance, and auditing the system for compliance on an ongoing basis.
History has proved that many security controls are breached simply because the secure network design was based on incorrect assumptions about the vulnerabilities, risks, and threats that might target the system. Unfortunately, one key wrong assumption may have a ripple effect in impacting other related systems. A good secure system design will have built-in resilience against its own design flaws and will be modular enough in design that when flaws are discovered, they can be corrected without rethinking the whole architecture. Designing a system without single points of failure would be one principle to achieve this goal. You have heard Murphy’s Law before: “Anything that can go wrong, will.” A good network design assumes that it is impossible to anticipate everything that can go wrong, but nevertheless we should be prepared for everything that can go wrong to key systems.
Here is a summary of design factors that follow the realistic assumptions principle:
Failure Scenarios.What if an element fails? Is the security impact isolated? Does it affect other systems?
When an Element Fails.Adopt a fail-open or fail-closed approach for the failure of key components of your network, subject to the security policy.
Attack Possibility.Identify vulnerabilities and try to identify possible attacks that can be leveraged against them.
Attack Probability.Evaluate a realistic probability that the system might be compromised. Don’t assume that because a technology is new and that an attack has not yet been invented to compromise it, that it won’t happen.
Evolving Technology.Keep up to date on the latest technological advances and factor them both into your security policy, the secure network, and operations.
Human Element.Assume people will make mistakes leading to an unintentional system compromise.
Review.Subject your assumptions to peer review.
The concept of least privilege is no element (users, programs, hosts, and so on) should have more than the minimum privileges necessary to perform a task. Because not every repercussion of a compromise can be planned for or even seen, following the concept of least privilege minimizes the possibility that an unanticipated compromise may have system-wide consequences. This might be the single most important principle of secure network design. Here are two examples of the concept of least privilege:
Example 1.If a user has no system administrative level of authority, it is much less likely that a compromise of this account will lead to a privilege escalation.
Example 2.A compromised web server in a DMZ is less likely to be used to attack an internal network if the router that establishes the DMZ is configured to allow only Network Time Protocol (NTP) to be initiated to an inside network from the DMZ.
It has often been said that, “Complexity is the worst enemy of security.” A military corollary is, “No plan survives first contact with the enemy.” So, these sayings mean that designing a network security architecture is doomed to failure? Not at all! Simply put, complexity can lead to unintended interactions with other systems when a network is under attack. The simpler a design and implementation is, the easier it will be to 1) anticipate; and 2) deal with feature interaction. The not-inconsequential side benefit to a simple system is that it is more likely to be embraced by the users as it is likely also simple to understand. Users not only need to be educated in the system; they have to believe in the system as well. How can they embrace the security goals of a security policy and its procedures if they don’t understand the system that implements them?
All the stakeholders (senior management, security staff, and users) require awareness, education, and training. Keeping up on industry best practices, technological innovations, and the operation of your own secure network are essential to maintaining the living security policy and the resultant secure system.
Several trends in network security point out the need for a flexible, resilient, and fast-acting defensive strategy. Both evolving threats and the blurring of the network perimeter serve to underline this need. In Cisco’s model of the Self-Defending Network, every network device has a part to play in a cooperative, homogeneous network security strategy. It is still useful to know the answers to questions such as these:
Where the threats are coming from (both internal and external to an organization)?
Across what parts of the network are these threats traveling?
In which direction are these threats flowing?
Although these questions are open-ended and can only be answered in the course of an organization’s risk assessment, one central question needs to be answered, and that is, “Where Is the Network Perimeter?” This will be examined (if not totally answered!) in the next subsection.
Before examining which devices to deploy in a secure network architecture, it would be useful to determine where the trusted network boundaries or perimeters are. Here is a simple definition of a network perimeter:
Network perimeters are established by firewalls. A network perimeter is a logical boundary between parts of the network with differing levels of trust.
For now, per the (unfair?) stereotype of a politician, we will evade directly answering the question of where the perimeter is. Instead, the next few thoughts and examples aid you in determining where your network perimeters are in your network. Once you have established a definition of a perimeter that works for your network, stick with it, as your network security philosophy will be built around it.
Some network security experts have opined that the network perimeter is extinct. Most would disagree, at least in part, while agreeing that determining where the perimeter is has become somewhat blurred. For example, firewalls have traditionally established the perimeter by establishing security zones of various levels of trust and using technical controls such as ACLs to control traffic across it. This also made it fairly simple to define ingress and egress flows of traffic because ingress (or inbound) would be defined as traffic that flows from a less-trusted to a more-trusted security zone. Egress (or outbound) traffic would be the opposite direction. Although the definition of ingress versus egress has not changed, what has changed is the location of the perimeter itself in some cases. Here are two examples of cases where the location of the perimeter is somewhat blurred:
Example 1: Perimeter on an application server.If TCP port 80 (HTTP) traffic is allowed in through a firewall, and that firewall is only analyzing traffic to OSI layer 4 (the transport layer), it can be argued that the firewall is no longer creating perimeter security for that protocol. The perimeter might actually be established on the web server itself, using whatever application layer firewall capabilities that may or may not be deployed on that device. The security of the entire network may hinge on the razor edge of patch management and proper configuration of the web server. Clearly, an application layer firewall will be needed in order to inspect the traffic for protocol compliance, as well as for malicious intent such as Instant Messaging (IM), Peer-to-Peer (P2P), file sharing, embedded code, and so on. A good security policy defines protocols that are absolutely not allowed on a network, but how is this policy enforced?
Example 2: Moving Perimeter.At one of your training facilities, one of the employee-students brings in a wireless access point and connects it to a wired Ethernet jack in the classroom, creating a wireless network without encryption in the classroom. On the face of this, it seems OK—if the individual connects to the data jack, they are inside the perimeter, and this is allowed by your security policy; then you realize that one of your competitors, who has offices in the floor above you, has access to your corporate network. Where is your perimeter now? Has it moved? Are internal systems at risk?
Note
Security practitioners are often heard saying things like, “After we establish the perimeter...” or “That attack is trying to breach our perimeter...” or such. The word “perimeter” will always remain a source of disagreement and anxiety unless the network security policy defines it in a consistent way. Cisco used to offer a simple definition (simple is good, right?) that went something like this, “A firewall is a device that establishes a trusted network boundary (perimeter) and then manages traffic across that boundary.” We examine firewalls in detail in Chapter 5.
The Cisco Self-Defending Network recognizes that all network elements—whether switch, router, security appliance, firewall, or application server—have a role to play in creating a secure networking environment.
The Cisco Self-Defending Network is a unified approach to identify, prevent, and adapt to threats. There are three key principles in Cisco’s Self-Defending Network. A network should be the following:
Integrated.Every network element is part of both defense and policy enforcement.
Collaborative.Devices and services collaborate to prevent attacks.
Adaptive.Threats are automatically prevented through proactive security technologies.
Cisco specifies four systems that leverage on the three just-defined principles of the Cisco Self-Defending Network ( integration, collaboration, and adaptation) to prevent attacks. The word “system” in this context defines a logical grouping or type of Cisco network device or software. The following are these four systems:
Policy Management.Cisco Security Management.
Threat Management.Cisco Security MARS.
Endpoint Security.Cisco NAC Appliance and Cisco Security Agent.
Network Infrastructure.Cisco IPS Sensor Software, Cisco IOS Software, and Cisco ASA Adaptive Security Appliances.
There are more details on some of these Cisco Self-Defending Network solutions in the following section.
The components of a Cisco Self-Defending Network are three technical controls and one administrative control. This ties in with the terms physical, administrative, and technical controls found in Chapter 1. Here are the terms:
Secure Network Platform.Use devices where security is an integral, fundamental network feature. This is a technical control.
Threat Control and Containment.Employ advanced technologies that mitigate the effects of outbreaks and ensure employee productivity in a constantly-evolving threat environment. This is a technical control.
Secure Communications.Configure devices to ensure the confidentiality and integrity of data, voice, and wireless communication. This is a technical control.
Operational Control and Policy Management.Deploy a suite of controls that creates a framework for operational control and policy management to ensure end-to-end security. This is an administrative control.
A secure network platform will be the subject of discussion in subsequent chapters including Chapter 3, “Security at the Network Perimeter.” Let’s examine the last three of the four elements in Cisco’s Self-Defending Network separately: threat control and containment, secure communications, and operational control and policy management.
The Cisco solution for threat control and containment contains three elements: threat control for endpoints, infrastructure, and email. Table 2.4 summarizes these threat control and containment elements and lists the Cisco products used.
Secure communications leverages on advanced technologies such as VPN services (both IPsec and SSL), as well as secure voice and wireless, to maintain confidentiality while increasing flexibility and in a cost-effective manner.
Note
Cisco really emphasizes secure communications in not only the traditional “triple play” of data, voice, and video, but also in wireless. This is also a constant thread in this Exam Cram. Cisco’s secure communications solutions use encryption to ensure confidentiality.
For example, Cisco’s IPsec VPN portfolio can be relied on to provide secure communications for both remote access and site-to-site connections. This would be very useful, for example, if an organization wanted to protect the communication path between a sales executive sipping coffee at a local designer coffee shop and the head office, while simultaneously wirelessly connected to the Internet.
Employs network management solutions that aid in the speed and accuracy of policy deployment and provides visibility throughout the network to monitor end-to-end. The controls also help in enforcement of the security policy and manage workflows.
Let’s briefly look at two products in the Cisco Self-Defending Network product portfolio: Cisco Security Manager and Cisco Security MARS.
Cisco Security Manager is a solution that provides for the central provisioning of all aspects of device configuration for the Cisco family of security products. It scales from networks with fewer than 10 devices to truly enormous networks with thousands of devices. Here are some of Cisco Security Manager’s benefits:
Provisions IOS router platforms, which use the Cisco IOS Security image, as well as ASA 5500 Series Adaptive Security Appliances, Cisco PIX 500 series Security Appliances, Cisco 4200 Series Sensors, and the Advanced and Prevention Security Services Module (AIP-SSM) on the Catalyst 6500 Series and ASA 5500 Series Security Appliances.
Centrally managed policies with multiple views, including the ability to graphically represent the entire network.
Graphical user interface.
Integrates with Cisco Security MARS (see the next section) for event correlation with firewall rules.
Integrates with Cisco Secure Access Control Server (ACS) to create detailed role-based access control (RBAC) to multiple devices and management functions.
Integrates into change management and change control by assigning tasks for deploying policies.
The Cisco Security Monitoring and Reporting System monitors network security devices made not only by Cisco, but also by other companies. It has the following benefits:
False positives are reduced by an end-to-end network view.
Its understanding of the network topology and configuration promotes effective attack mitigation.
NetFlow network behavior analysis helps detect environmental anomalies.
MARS has over 150 built-in (but customizable) reports, which aid in audit compliance.
Visual tools, such as detailed topological graphs, aid in identifying threat sources, and making specific recommendations for threat remediation through layer 2 to 7 of the OSI model.
Cisco offers a portfolio of products, both hardware and software, to implement the Self-Defending Network. Its modular nature enables you to progressively layer on security features to an existing core IP network.
Figure 2.7 illustrates the following:
-
An organization starts with an existing core IP network (depicted as a star).
-
The core IP network can be enhanced with Cisco’s portfolio of Security Point Services (depicted as a circle wrapping the core IP network’s star).
-
The network can further evolve as Advanced Technologies and Services are integrated into the solution.
Because no one product can offer all the security services required to secure network infrastructure, Cisco has a broad portfolio of integrated security products. Here is a sampling of some of those products:
Cisco IOS platforms with integrated IPS, VPN, and stateful firewall technologies.
Cisco ASA 5500 Series Adaptive Security Appliances with integrated VPN services to enforce perimeter security and access control and IPS (with the AIP-SSM card).
Cisco PIX 500 Series Security Appliances with integrated VPN services to enforce perimeter security and access control.
IDS and IPS appliances (blade servers) and integrated IDS and IPS for Cisco IOS routers, Cisco PIX Security Appliances, and Cisco ASA Adaptive Security Appliances.
Cisco Security Agent endpoint protection software, which protects servers and workstations from known and also unknown threats.
Security modules (VPN, firewall services) for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers.
Security Management products for single devices (Cisco Router and Security Device Manager, Cisco Adaptive Security Device Manager) and multiple devices (Cisco Security Manager, Cisco Security MARS).
Note
Arguably, the Cisco Integrated Services Routers (ISRs) with a security IOS is the single device that integrates the majority of these features. It integrates secure voice, data, and video services. Some ISRs also offer secure wireless connectivity, either as an integrated feature or with add-on modules. If you have picked up this Exam Cram, you probably already possess the necessary skills, as stated in the course goals for ICND2, “to install, operate, and troubleshoot a medium-sized network, including connecting to a WAN and implementing network security.”
ICND2 is the second of the two courses that comprise the CCNA material. The CCNA curriculum is based on IOS routers; therefore, it’s no mystery that the IOS router is used to demonstrate these technologies in subsequent chapters.