Transcript net324d-ch6
Security Management Process
1
six-stage security operations model
2
In large networks, the
potential for attacks
exists at multiple
points. It is
suggested that you
develop a
multifaceted defence
approach. This led
Cisco to develop a
six-stage security
operations model, as
shown in Figure 162.
3
Preparation
4
Preparation for attacks includes a set of policies that
define who is allowed to do what in the network.
From an accounting and performance perspective,
preparation means having the right device
instrumentation and management applications in
place.
Preparation
5
One technique to spot the possibility that an attack is
occurring is to compare the current network
performance figures with the expected ones.
Preparation
6
In summary, the following steps are a good
preparation for a network administrator to protect
the network in advance:
Defining policy
Activate accounting and performance management features at
the network elements
Analyzing flow records
NBAR is the tool of choice for network protocol discovery up to
the application level
IP SLA is the final function to verify network, server, and
application response time
Deploying security management applications
Defining policy
7
Define a policy that describes which protocols,
applications, transactions, and connections are
permitted and denied in the network.
Activate accounting and
performance management features
8
Activate accounting and performance management
features at the network elements, such as the
following:
- Full NetFlow should be enabled at the edge of the
network. It can be combined with Sampled NetFlow
at the core network.
- SNMP read access should be configured at all
network elements. Trap destinations are required as
well. From a security perspective, leveraging SNMP
version 3 is the best approach.
Analyzing flow records
9
Analyze flow records for abnormalities to identify
reconnaissance, especially ping sweeps and port
scans. Advanced attacks do not use sequential
scanning; they take a randomized approach or a list
of ports. By tracking flow records and correlating
them, you can identify these scanning activities;
however, this is not as simple as detecting a massive
DoS attack.
NBAR
10
NBAR is the tool of choice for network protocol
discovery up to the application level. However,
because of the CPU impact, it should be used with
care and only if alternatives such as SNMP, NetFlow,
and BGP PA do not provide sufficient details.
Hardware-based NBAR implementations address
these performance implications effectively.
IP SLA
11
IP SLA is the final function to verify network, server,
and application response time. Using IP SLA to
assess the network before, during, and after an
attack is a great way to measure the impact of an
attack and document how long the remedy took.
Deploying security management
applications
12
Deploying security management applications that
collect, store, aggregate, correlate, and present
potential threats is the final step during the
Preparation stage.
13
Identification
14
The next logical step is to detect and identify an attack.
Some attacks are easy to detect, especially if their
goal is to paralyze the users completely.
Attacks that try to snoop for passwords or business
knowledge are much harder to detect, because they
do not leave massive footprints.
Identification
15
Constantly analyzing the flows is the first step toward
identifying an abnormal situation.
For example, a sudden increase in the total number of
flows, or a large number of flows with the same
destination IP address and port number, combined
with few or no payloads, can be an attack signal.
Identification
16
Source IP
Address
10.1.1.69
Destination Input
IP Address I/F
10.44.4.245 29
Output Source Destination Packets Bytes Port
I/F
Port
Port
49
1308
77
1
40
6
10.1.1.222
10.44.4.245
29
49
1774
1243
1
40
6
10.1.1.108
10.44.4.245
29
49
1869
1076
1
40
6
10.1.1.159
10.44.4.245
29
49
1050
903
1
40
6
10.1.1.54
10.44.4.245
29
49
2018
730
1
40
6
10.1.1.136
10.44.4.245
29
49
1821
559
1
40
6
10.1.1.216
10.44.4.245
29
49
1516
383
1
40
6
10.1.1.111
10.44.4.245
29
49
1894
45
1
40
6
10.1.1.29
10.44.4.245
29
49
1600
1209
1
40
6
10.1.1.24
10.44.4.245
29
49
1120
1034
1
40
6
10.1.1.39
10.44.4.245
29
49
1459
868
1
40
6
10.1.1.249
10.44.4.245
29
49
1967
692
1
40
6
10.1.1.57
10.44.4.245
29
49
1044
521
1
40
6
...
...
...
...
...
...
...
...
...
honeypot
17
An alternative approach to collecting accounting data
for security purposes is to set up a "honeypot." This
is a router or computer that is installed by the
security operator merely for surveillance and security
analysis, but to the outside world it appears to be
part of the network.
https://www.blacksintechnology.net/an-overview-of-honeypots/
Identification
18
For intrusion detection, monitoring logging messages is a
key to success. The following list of event logs can serve
as a starting point:
• Failed login attempts at the network element result in
Syslog messages and SNMP traps.
• High number of ACL violations.
• High number of uRFP drops. Unicast Reverse Path
Forwarding (uRPF) is a feature that drops packets with
malformed or spoofed IP source addresses. The router
examines all received packets to verify that the source
address and interface appear in the routing table and
match the interface on which the packet was received.
19
Classification
20
After identifying an abnormal situation in the network,
classifying the kind of attack comes next. It is tricky to
block an attack without a clear understanding of the
attack's characteristics.
You need answers to questions such as these:
• Is this an attack against the network, or the servers, or the
services?
• Is it a security threat or a denial of service, such as one
caused by a worm?
• Is the attack distributed, or is a single source causing it?
Intelligent device instrumentation features can decrease
the time for classifying a threat's kind and scope.
21
Trace Back
22
After identifying and classifying the attack, you need to
trace back the source(s) of the attack and isolate
them. For this task, you need answers to questions
such as these:
• Did the attack come from inside or outside the
network?
• Did a special segment of the network initiate the
attack, or did it come from all over the network?
• Did servers or client PCs distribute, such as
notebooks that were infected outside of the network?
• Are the source IP addresses real or spoofed?
IP spoofing attack
23
An IP spoofing attack occurs when an attacker outside
of your network pretends to be a trusted computer.
This can be done by using an IP address that is
within the range of your network's IP addresses. Or
someone could use an authorized external IP address
you trust and to which you want to grant access to
specified resources on your network. Detecting
whether a specific IP address is spoofed is not an
easy task.
Locating source IP address
24
Different mechanisms are available to locate the
source IP address:
Search the routing table(s).
Check the Internet Routing Registry (IRR).
Use NetFlow to trace the packet flow through the
network.
Identify the upstream ISP if the source is outside of
your network. From there, the upstream ISP needs to
continue tracing to block the source.
25
Reaction
26
As soon as the attack's characteristics and sources have
been identified, a remedy can be initiated. Possible
solutions range from configuring an ACL up to
leveraging sophisticated security management
applications.
Defining an ACL
27
After you identify the source of an attack, a simple way
to block all traffic from the attack toward the victim
is to define an ACL at a router, next to either the
attacker or the victim.
Propagating BGP drop information
28
If only a limited number of hosts are targets of the
attack, an alternative is to propagate BGP drop
information to all routers in the network. If you set
the next hop of the target IP addresses to the Null
interface, all packets destined for the victims are
dropped into the so-called "black hole."
Blocking traffic from nonexistent
sources.
29
An alternative to dropping traffic from a source or
toward a destination is to block only traffic from
nonexistent sources.
Using QoS features
30
Instead of blocking or verifying all traffic, you can use
QoS features such as rate-limiting packets. The
committed access rate (CAR) feature can define a
limit for certain traffic types. For instance, if a high
rate of FTP traffic overutilizes the network capacity,
a rate limit can be applied.
31
Postmortem
32
The postmortem examines the situation to identify
why the network was vulnerable and what lessons
can be learned from the situation.
Start the process by reconstructing the attack as
precisely as possible to establish a "footprint" for the
attack.
Postmortem
33
The different steps are related to the different stages of the Cisco sixstage security operations model:
The first place to inspect is fault management reporting. several
conclusions can be drawn from the reported notifications. The
baselining information that was initiated during the Preparation
stage is useful, as well as the data gathered during the Identification
stage.
Check log files, such as Syslog messages from the network elements
and application logs from the servers. They are gathered during the
Identification stage.
Performance monitoring and accounting records should provide an
idea about the attack's path through the network. This is related to
the Trace Back stage.
Analyze configuration changes at network elements before, during,
and after the attack. Distinguish between configuration changes
resulting from the Reaction stage and other configuration changes.
Back to the preparation stage
34
Remember, as soon as the postmortem is complete,
the Preparation stage for the next attack should start.
Preparation stage for the next attack
35
The following questions can serve as a link between the analysis of the
previous security threat and the Preparation stage for the future:
What worked well during and after the attack?
What needs to be improved? How can it be improved?
Who discovered the attack(s)—a user, the operator, or a management tool?
How long did it take to identify, classify, and trace back the attack?
How long did it take to block the attack?
Did the existing tools help support the operators?
Were the tools used at all? In which of the six stages of the process were
tools used? What was their contribution to solving the issue?
How well did the different teams, such as network operators, data center
administrators, and the security group, cooperate? How can the
cooperation be improved?
What additional resources, processes, training, or tools are required?
Did you find a single point of failure in the network?
What is the most important lesson learned?
What will you do differently next time