The Ultimate CCNA Security Study Package

Chris Bryant, CCIE #12933

http://www.thebryantadvantage.com
Back To Index

Security Approaches And Solutions

Overview
The SDLC
Hot, Warm, And Cold Disaster Recovery Sites
Quantitative vs. Qualitative Analysis
Cisco Self-Defending Network
ASA 5500 Adaptive Security Appliance
Cisco Security Management Suite
IronPort
Cisco Security Agent
Cisco ACS
"Hot Spots And Gotchas"

Whether you're studying for a certification exam, troubleshooting

a printer, or developing security policies and procedures for your
network, you've got to have a structured approach.
Developing such an approach for security procedures can be
particularly difficult without such an approach, since you're going
to be answer many pointed questions...
"Do we REALLY need this?"
"If we haven't been attacked yet, why do we need this?"
"How much is this going to cost?"
"This prepares us for today, but what about tomorrow?"

You must have answers to these questions, or your project is

never going to get off the ground. A structured approach
enables to you anticipate these questions - and to have answers
ready before you're asked!
The System Development Life Cycle is a great help in creating a
proposal for a security rollout (though it's hardly limited to that),
and to answering the tough questions before they're asked.
The SDLC is most often thought of as a model for software
development, but as you'll see in this section, it's also an
effective model for security policy creation and deployment.
Technically, there are several different SDLC models, but the
one you'll use most often in the field - and therefore, the one
we're going to use here - is the waterfall model. In a waterfall
model, the result of one stage becomes the input for the next
stage.

You can read five different books that discuss SDLC models and
see five slightly different ways to name the following phases. As
our friends at Wikipedia put it so well:
"There is no definitively correct SDLC model ..."
Cisco's SDLC recommendations for secure networks are quite
different from any SDLC you may have seen before, so keep
that in mind as we walk through a hypothetical SDLC plan. In
this case, we've got a brand-new e-commerce server...

... and we're concerned about its current security. Let's walk
through the SDLC steps and determine what needs to be asked
and answered at each level.
Phase 1: Initiation
In this phase, we'll perform both a security characterization and a
preliminary risk assessment.
The security characterization involves answering an interesting
question:
"Compared to the other devices in our network, how important is
this new server?"
The first answer that comes to mind is "Well, all of our network
devices are equally important!" (That's the answer I'd give at a
department meeting, too.) Truth is, all of our network devices
are important - but some are more important than others.
An ecommerce server's security is very high, since we can be
shut down economically if that server goes down, and not to
mention lawsuits from customers if their data is compromised.
Having decided that the level of security needed is very high, we
move on to the preliminary risk assessment...
"What are the overall risks to this server?"
We're not getting too specific with risk analysis yet, but we do
need to identify the overall risks.
Phase 2: Acquisition And Development
"A&D" sounds like a separate department in your organization,
but it's actually the next step in our SDLC process. So what
exactly are we "acquiring and developing"? In a nutshell, we're
fleshing out details from our Phase 1 risk assessment to create a
more-detailed risk analysis plan. There's a lot going on in this
phase, including:
Detailed risk assessment. What exactly are we concerned
with? What attack types are we most concerned with, both from
the inside and the outside of our network? (Remember, not all
the bad guys are coming in from the outside!)

Cost. Yes, you and I both know good security is priceless, but
someone in your company has to write a check for everything
we need to secure that server - and they're going to want to
know how much this is going to cost!
Two requirements analysis (RA) - security functional and
security assurance. The security functional RA basically says
"Here's what we need to do in order to protect the server"; the
security assurance RA basically says "Here's the proof that the
server will be protected". Obviously, both of these steps require
a great deal of planning and testing - especially testing!
Testing - It's not possible to do too much testing! Cisco's
terminology for this step is "developmental security test and
evaluation". I like to call it "test, evaluate, and repeat".
Report creation - Cisco documentation refers to these steps as
"security planning" and "security control development". These
two steps both involve creating reports that detail exactly what
we're doing to protect the server and how we're going to
implement it on the production network.
And sure, I know creating any report isn't #1 on the Network
Admin Fun Parade, but it's gotta be done for us to move to the
next phase - Implementation.
Phase 3: Implementation
Sounds self-explanatory, but there's a bit more going on that just
implementing the solution here. Cisco documentation lists the
following four steps to this phase:
Inspection and Acceptance, where the "acceptance" is a fancy
way of saying "we verified this and it works"
System Integration, another way of saying "it didn't screw up
anything else we already had running"
Security Certification, another way of saying "everything we
planned in Phase 2 worked"
Security Accreditation, where the overall operation is given
approval and the secured devices are put into operation
The next phase, Operations and Maintenance, is a two-part
phase:
Configuration Management is exactly what it sounds like, and it's
actually one of the most important parts of the entire Cisco

SDLC process.
Ever sat down at a router, entered a simple configuration,
applied it, and then watched as something you didn't even think
about comes crashing down? For example, you might have
created an ACL or two for a specific purpose, applied it to an
interface, and then watched one console message after another
mention that you just brought OSPF down. Or BGP. Or
something else.
Preventing that kind of thing from happening to your network
security is the entire point of Configuration Management. In one
way or another, CM requires other admins to examine the impact
of your configuration change to the network operations they're
responsible from, and to give approval before a configuration
change is accepted.
The other part of the Operations and Maintenance phase,
Continuous Monitoring, is self-explanatory.
The final Cisco SDLC phase is Disposition, a nice way of saying
"How are we going to get rid of this stuff when it's outdated
and/or replaced with other hardware and software?"
If you've ever seen a news report about hard drives being stolen
out of computers that were not properly disposed of, you know
how important this phase is.
Another way to find out how important this phase - lawsuits from
people whose personal information was accessed on improperly
disposed-of servers. Since that's an expensive way to learn, let's
take a closer look at the three parts of the Disposition phase.
Information Preservation - It's not necessarily legal to dispose of
data simply because you're done working with it. For example,
some government agencies require a business to retain their
records for up to seven years, even if they're closing the
business. And obviously, we can't just delete such sensitive
information as medical records. To protect yourself legally, this
kind of information must be preserved.
Media Sanitation - a formal way of saying "if you're deleting data,
you better REALLY delete it". Contrary to what the average end
user thinks, hitting the "delete" key does not make that deleted
data irretrievable. Do a quick Google search on "recover deleted
data" and you'll see what I mean. If you're planning to dispose
of any data, make sure it's not data that needs to be preserved and then really delete it.

Disposing of data correctly isn't our only concern; we have to

dispose of hardware and software correctly as well. Tossing an
old server into a landfill is not the way to go. Create a
structured approach for both hardware and software disposal, as
this has two benefits:
Having a written policy for this disposal ensures that your
company follows the same procedure for this every time
It helps protect your company on a legal basis when you
can show the procedures that are followed for this disposal.

Hot Sites, Warm Sites, and Cold Sites

Implementing security plans is obviously important, but we also
have to be prepared for worst-case scenarios. Here's a question
none of us like to think about, but it needs to be considered:
"If your main network room was destroyed tonight, how would
your network operate tomorrow?"
Having an answer to that question before such a disaster strikes
is what disaster recovery is all about. When I say "disaster", I
don't mean a drive going down - I mean a true disaster such as a
hurricane or tornado. If the entire building your network servers
are in disappeared tonight, how would you recover?
If you have offsite backups, at least you'd have a starting point.
It's just not enough to have backups that are stored onsite.
Backup sites are categorized as hot, warm, or cold. Let's take a
look at each:
Hot sites contain everything a company would need to get right
back into full operation.
Hot sites are maintained by
commercial companies for their customers, and these sites
include everything from the office space itself all the way through
telephone and computer equipment. The servers at the hot site
will be mirrors of the servers at the primary location.
Cold sites will have the physical devices necessary to get up and
running again, but they're not configured or mirrored from the
primary site. This is much cheaper than maintaining a hot site,
but obviously a lot of work needs to be done before work can
continue after a disaster, and this is time that no company can
really afford to lose.

There is a middle ground, the appropriately named warm site.

Warm sites are going to have all the physical equipment needed
along with some of the servers configured and maintained.
Disaster recovery using a warm site will still take longer than if a
hot site were maintained, but basic communications are back in
place much more quickly than if a cold site were used. The
"mission critical" servers will be ready to go, but secondary
servers will need to be brought up to date through data restores
from backups.
So if hot sites are so great, why doesn't everyone have them?
Cost. Just from the description of a hot site, you can see that it's
going to cost much more to set up and maintain a hot site than a
cold or warm site. However, that cost is more than made up for
by the speed at which a hot site can be up and running compared
to the days or weeks it can take to get a cold site into operation.

Quantitative vs. Qualitative Analysis

I've mentioned risk analysis throughout this section, and we can
take one of two approaches to this analysis - quantitative and
qualitative. We've all taken enough exams to know that when
two terms sound alike but don't quite do the same thing, it's a bit
of a red flag, so let's draw a clear line between these two terms.
The term quantitative analysis is not exclusive to network
security. The website investorwords.com defines the term as:
"The process of determining the value of a security by examining
its numerical, measurable characteristics such as revenues,
earnings, margins, and market share."
They're talking about a financial security, not network security.
Not quite the definition we want. What do our friends at
Wikipedia have to say about this term?
"In chemistry, quantitative analysis is the determination of the
absolute or relative abundance of one, several, or all particular
substances present in a sample."
Those two definitions are referring to totally different worlds finance and chemistry - but the definitions are somewhat similar.
Both refer to the analysis and determining the "relative
abundance" of a factor.

When it comes to network security, that's what we're doing with a

quantitative analysis as well. We're performing risk analysis and
determining the relative abundance of two factors, risk probability
and risk severity.
According to Cisco documentation, here are the formulas used to
perform quantitative analysis for network security:
AV * EF * ARO = ALE
AV * EF = SLE
The ALE is the Annualized Loss Expectancy, a formal way of
saying "here's how much money we're gonna lose over a year if
we don't eliminate these risks".
The SLE is the Single Loss Expectancy, a formal way of saying
"here's how much money we're gonna lose every single time this
happens if we don't eliminate these risks".
The three values used to determine the ALE:
The Asset Value (AV) is just what it sounds like - the overall cost
of purchase and maintenance of an asset.
The Exposure Factor (EF) is actually a percentage - the loss
percentage experienced by the asset if the risk becomes an
actual threat.
The Annualized Rate of Occurrence (ARO) is simply the
projected number of times the asset will be affected by the threat
in question.
Exciting stuff, right? ;) These are important values for both the
CCNA Security exam and working with risk assessment in the
real world, though, so know them by heart!
Qualitative analysis has some differing definitions as well. From
Wikipedia, here's their definition:
"Qualitative research is a field of inquiry that crosscuts disciplines
and subject matters. Qualitative researchers aim to gather an indepth understanding of human behavior and the reasons that
govern human behavior."
Hey, that sounds like what we network admins do every day! :)
(Insert your own end user remark here.) However, it doesn't
relate to network security particularly well. In the world of
network security, qualitative analysis refers to the scope of the

assessment.
If you have an enterprise network, it's going to be difficult to
perform one giant risk analysis that encompasses the entire
network. Rather, you could use the qualitative analysis
approach, where lab environments are used to perform the risk
analysis.

The Cisco Self-Defending Network

That name does bring up two immediate questions:
"Is it really self-defending?"
"If it's really self-defending, why do we need network admins
who are also security specialists?"
I'll answer the second question first: Believe me, the demand for
security-certified network admins is only going to increase in the
years ahead!
What Cisco means by "self-defending" is.... well, let's let their
own documentation speak for itself!
"The Cisco Self-Defending Network combines best-of-breed
technologies to address emerging threats, a systems approach
built on Cisco's industry-leading product portfolio to
autonomously respond to pervasive threats, and Cisco's
differentiating security services portfolio to help make the
solutions approach a reality."
Translation: The Self-Defending Network delivers a highly
secure, dynamically protected network platform.
From that same document, Cisco lists the characteristics of their
network security solutions:
Integrated - Security is embedded into the network
Adaptive - Cisco security devices can monitor devices and
systems and then adapt their defenses against perceived
network threats, resulting in a constantly evolving, dynamic
security policy.
Collaborative - Here, Cisco's referring to collaboration "among
diverse network components", allowing different Cisco products
and systems to work interactively to tighten network security.

I don't usually list URLs since they can change, but this particular
doc is recommended reading for the CCNA Security exam and
your real-world knowledge as well. The URL is particularly long,
so just enter the phrase "The Cisco Self-Defending Network
combines best-of-breed" into Google and it'll be the first or
second match. It's a PDF well worth reading!
The Cisco ASA 5500 Adaptive Security Appliance
I don't mean to sound like sales propaganda, but the ASA 5500
really "does it all". According to the Wikipedia entry for the ASA,
the 5500 actually succeeded three Cisco products:

PIX (Cisco's famous firewall and NAT device)

IDP 4200 (Intrusion Detection)
VPN 3000 (VPNs, obviously)

The ASA 5500 also offers several "antis', including antivirus,

antiphishing, and antispyware / antimalware protection. No
wonder Cisco's website refers to the ASA 5500 as "a key
component of the Cisco Self-Defending Network".
Okay, now I really sound like a sales brochure, so we'll stop
there. For the CCNA Security exam, it's good to know the
basics of the ASA that we've discussed here; for much more
information including some free video content, visit Cisco's
dedicated ASA website:
http://www.cisco.com/en/US/products/ps6120/#

The Cisco Security Management Suite

We'll wrap this section up with a quick look at the components of
the Cisco Security Management Suite:

Cisco Security Manager (CSM)

Cisco Security MARS

From the CSM homepage:

"Cisco Security Manager is an enterprise-class management
application designed to configure firewall, VPN, and intrusion
prevention (IPS) security services on Cisco network and security
devices."
Scalability is always a concern, and a major benefit of CSM is
that it can run on any size network, from small to enterprise.

Here's the CSM homepage - there's an excellent video on this

page with an introduction to CSM.
http://www.cisco.com/en/US/products/ps6498/index.html#

CSM works in tandem with Cisco Security MARS - Monitoring,

Analysis, and Response System. Here's a quote from the
MARS homepage:
"Cisco Security Monitoring, Analysis, and Response System
(MARS) provides security monitoring for network devices and
host applications supporting both Cisco and other vendors."
That "other vendors" is always good to hear, since we don't
always have 100% Cisco equipment in our networks. (I know blasphemy!)
Here's the MARS homepage - an excellent introductory video
can be found on this page as well:
http://www.cisco.com/en/US/products/ps6241/index.html

It's not necessary to read every single doc on both of those

pages to be ready for the CCNA Security exam, but I would
watch the videos and be familiar with the roles both CSM and
MARS play in the overall Cisco Security Management Suite.
IronPort
Cisco purchased IronPort for $830 million dollars on June 25,
2007. This combination email/web security appliance will be a
major factor in Cisco's security solutions in the years ahead, so
you'd be well served to spend some time at www.ironport.com
once you pass the CCNA Security exam - or even beforehand!
Let's take a quick look at just a few IronPort features and
capabilities.
IronPort uses the Dynamic Vectoring and Streaming (DVS)
engine, which allows for high-speed, signature-based spyware
filtering. (Another example of signature-based threat detection!)
IronPort's SenderBase (www.senderbase.org) is the largest
email traffic monitoring service in the world, handling well over 4
BILLION queries each day. (Some sources say it's over 5
billion.) From the SenderBase website:
"With data on more than 25 percent of the world's Internet traffic,
IronPort's SenderBase network provides an unprecedented real-

time view into security threats from around the world."

Be sure to spend some time on the SenderBase website once
you're done with your CCNA Security exam - they have plenty of
free PDFs and some videos on the website as well.
The Cisco Security Agent
Cisco describes CSA as follows:
"Cisco Security Agent is the first endpoint security solution that
combines zero-update attack protection, data loss prevention,
and signature-based antivirus in a single agent. This unique
blend of capabilities defends servers and desktops against
sophisticated day-zero attacks, and enforces acceptable-use and
compliance policies within a single management infrastructure."
That's quite an agent! Quite a few agents as well - CSA gives
new meaning to the term scalable, since a single central console
can support up to 100,000 agents. That central console is the
cleverly-named Management Center for Cisco Security Agents,
and that center and the CSA itself form the overall solution.
Communication between a host running CSA and
Management Center can be protected via HTTPS or SSL.

the

The entire process is "almost" transparent to the end hosts

running the CSA. If CSA detects unusual and/or potentially
malicious activity, the host may show a prompt to the end user,
or perhaps a message balloon similar to that you see when
Microsoft wants to install updates.
And how is that malicious activity detected, you ask? Through
the use of Cisco Security Agent Interceptors. Past versions of
CSA have run three SA Interceptors, but the current version runs
four:
File System Interceptor is in charge of allowing and denying file
access, both RO and RW requests.
Configuration Interceptor also approves or denies RW requests,
but these requests are critical - they're requests to rewrite the
Windows Registry and/or rc files on Unix. (rc is the command
line interpreter for Unix.)
Network Interceptor performs SYN flooding protection as well as
protection against port scans. This interceptor also limits the
number of active connections in an attempt to stop DoS attacks.

Earlier in the course, I mentioned that the Cisco Security Agent

helps to prevent buffer overflow attacks. The Execution Space
Interceptor handles that protection by proactively detecting
attempts to write to memory not assigned to the offending
application, and denying access to that memory. This prevents
buffer overflow attacks before they happen.
Perhaps the most impressive feature of CSA is the zero-update
intrusion detection. This feature actually detects and blocks
attacks without using signatures, which in itself has two positive
effects:
There is no window of opportunity for attackers between the time
the attack is first unleashed and the time signatures to stop them
are created.
You and I as network security admins have one less thing to
keep up with, since we don't have to check for and install the
latest signatures.
The actual "signature-free" operation of CSA is beyond the
scope of the CCNA Security exam, but you should take the time
to learn more about CSA's features once you pass the exam.
Cisco has an excellent introduction to CSA in PDF format that
you can find quickly by searching on the term "cisco security
agent nimda" in Google. Good reading for your exam and your
career!
The Cisco ACS
With all of these "latest and greatest" Cisco appliances, it's easy
to forget one that's been around for a while - the Cisco Secure
ACS.
The ACS is really in the "middle ground" between the CLI and
the GUIs we'll see elsewhere in this course. The ACS
application presents the user with a maze of drop-down boxes
and "fill-in-the-blank"-type prompts that will help you configure
everything from VPNs to firewalls.
Having used the ACS many times, I can tell you from experience
that's it's not quite as intuitive as SDM, but it's close. There's an
excellent online user guide you may want to refer to for further
studies and real-world ACS configuration - just put "cisco secure
acs" in your favorite search engine and you'll find the Cisco ACS
documentation quickly.
ACS does offer one service that other protocols we've looked at
does not - you can perform router command authorization with

ACS, via the ACS Shell Command Authorization set. Here, you
can set full or restricted access to commands as you see fit.
In the online documentation for the ACS Shell Command
Authorization set, several references are made to TACACS+,
which should not surprise you. (TACACS+ has command
authorization capabilities, but RADIUS does not.)
Here's a link to a Cisco PDF that I do recommend you take a
look at, and it'll show you exactly how the ACS interface appears
to the user.
http://www.cisco.com/application/pdf/paws/99361/acs_shell_auth.pdf

I would not spend hours and hours studying that doc, but to save
yourself some frustration in the real world (and possible the
exam room!), note that we can set a Shell Command
Authorization Set at both the User Setup and Group Setup
levels, and that user-level settings override group-level settings.
(Those screen shots are near the end of the document.)
In-Band Management vs. Out-Of-Band (OOB)
Regardless of the network monitoring software you choose,
you're going to have management traffic as a result. That's a
good thing - if you don't have management traffic, you don't
have management - but there are two schools of thought on how
to handle that traffic:
in-band, where management traffic shares a network with the
"regular" data
out-of-band (OOB), where management traffic uses a separate
network
In a perfect world, we'd always use OOB, since mixing the
production data and management data increases the likelihood
of sensitive network management data falling into the wrong
hands. However, sometimes it's just not practical to use OOB,
and some management tools do not work properly if the
management traffic's on a separate network.
For ideal, perfect-world situations like those we only see on
certification exams :), it's a good idea to know the difference
between these two approaches. It's also a Cisco best-practice
to use OOB. For real-world application of OOB, be sure to do
plenty of research for the particular network monitor you're using
and the potential impact on performance if the network
management traffic is segregated from the production data

traffic.
Hot Spots And Gotchas
The Cisco ASA 5500 Adaptive Security Appliance really does it
all in network security - VPN, IPS, antispyware, antivirus, and
more!
The Cisco Self-Defending Network's "big three" selling points:
Integrated - Security is embedded into the network and not
treated as an afterthought
Collaborative - Services and devices work together to
thwart attacks on the network
Adaptive - Security techniques and approaches evolve as
attack techniques advance
IronPort is Cisco's email / web security appliance. IronPort uses
SenderBase as its email monitoring service and the Dynamic
Vectoring and Streaming (DVS) engine for signature-based
spyware filtering.
The Cisco Security Agent Interceptors and their purpose:
File System, allows/denies RO and RW file access requests
Configuration, allows/denies writes to the Windows Registry and
the rc files in Unix
Network, works to prevent SYN flooding attacks and port scans
Execution Space, prevents buffer overflows.
Copyright 2008 The Bryant Advantage. All Rights Reserved.