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