An Attack Response Model for a Network Compromise

balaji
By balaji

February 17, 2010

An Attack Response Model for a Network Compromise

An Incident, in the context of this article can be defined as an adverse event that endangers the security of computing systems or networks. Examples of incidents could include activities such as repeated attempts to gain unauthorized access to a system or its data, unwanted disruption or denial of service, changing system Hardware or Software characteristics without the owner's knowledge or consent.

attack-response-model.jpg

An Incident, in the context of this article can be defined as an adverse event that endangers the security of computing systems or networks. Examples of incidents could include activities such as repeated attempts to gain unauthorized access to a system or its data, unwanted disruption or denial of service, changing system Hardware or Software characteristics without the owner's knowledge or consent.

In order to be able to respond to an incident, it is required to have a planned approach. The "Attack Response Model" includes best practices for dealing with incident management on your network, which is a set pattern of actions that can be taken to resolve the incident. The Attack Response Model includes the following steps:

  • Identification
  • Control
  • Recovery
  • Anticipation

We will analyze these steps at the network level in detail in this article.

IDENTIFICATION

First, identify the traffic to recognize whether it poses a threat to your network. This can be done in the following ways:

  • BANDWIDTH: A sudden increase in overall bandwidth. This may just mean that your web site has been mentioned on a very famous news site, or it may mean that someone is up to no good.
  • FIREWALL RULE LOGS: Large numbers of packets caught by your router or firewall's egress filters. We know that egress filters prevent spoofed packets from leaving your network, so if your filter is catching them you need to identify their source, because that's a clear sign that machines on your network has been compromised. Increase in port scan activity. If your logs show an increase in scan activity, find out if the scans are linked to a general attack or it points to a targeted attack.
  • IDS ALERTS: By comparing the IDS alerts with the network attack graph which provides all possible sequences of exploits that an intruder may use to penetrate the system; this can be used to identify all the attacks.

CONTAINMENT

This determines how far the problem has spread and discusses steps that can be taken to prevent further damage.

  • First of all identify if you have the skill to manage an incident. If not please do not hesitate to call in someone who does.
  • Start with isolating the attack and determining how it was executed. Create an Attack Profile: It must enumerate all possible attacks on the network. Keep the following points in mind before an Attack Profile is created:
    1. Enumerate entire infrastructure
    2. Understand entry points:  We can use some of the following to identify the entry points: Network Device Logs, OS Event Logs, Web Logs, Database Logs, FTP Logs and IDS Logs.
    3.  Create threats for each entry point
  • Identify all network services that need to be running on the affected host and note those down.
  • Identify all hosts that need access to each of these services.
  • Create and apply stringent access control lists on Firewalls and Routers based on the result of the previous point. Identify countries from where there is no network traffic and consider blocking those ranges off on your firewall.
  • Configure VLAN's on the switch to which the affected server was connected and restrict inter VLAN traffic.
  • If we have identified the exploit that was used, configure Intrusion Detection Systems (IDSs) to alert the administrators when a specific exploit is attempted.

RECOVERY

The next challenge is to restore a network to its working state after a compromise. Provide all the relevant logs as well as a copy of all relevant infected data to your team which is handling the Incident and start the following steps to go live in parallel:

  1. Determining which backup to use for a restore can be difficult because it may not be possible to pinpoint the exact time of the compromise. As a result, you must guess which backup is not compromised and then reevaluate it after the restoration is done. If the compromise is still evident after the restore, you must use an even earlier backup.
  2. Back the memory and disk of the system(s) that are compromised on to an external hard disk or a clean system on the network.
  3. Prepare system(s) exactly similar to the compromised system(s). Harden these systems as per the organization’s hardening policy.
  4. Apply all vendor released security patches on these new systems.
  5. Apply all the principles discussed in the containment section to the new systems so they are isolated in case they are compromised again.
  6. Once the new system is ready format the old system and restore from a clean backup.
  7. Once your systems are up live again - monitor them closely to ensure that you're prepared in the event of another incident.

ANTICIPATION

In spite of our best efforts to secure networks, incidents will nevertheless arise. You should be prepared for that eventuality. Following are few things that you can do to follow the evergreen adage "Prevention is better than Cure"

  1. Ensure that you know "Who manages what" in your organization so you know where to go in case of an incident.
  2. Make sure that DNS data is accurate and up to date. Use that as an opportunity to document all systems - what is it? What is it used for? Who is using it? Where is it? What IP number? What MAC address? Which switch port?
  3. Network devices can generate massive logs. It's easy to be overwhelmed with all the information; be clear on what all you need to log and have the necessary tools in place to analyze the logs and reduce false positives.
  4. Audit your firewall rulebase from time to time and make it as restrictive as possible.
  5. Finally, define network security architecture for your network and document it. It helps you think clearly and helps you immensely when there is another attack.

It's very important to have an "Attack Response Model" in place before your network is compromised. When you realize you've been attacked, make sure you identify your objectives in resolving the situation and deciding how to react to an attack is tricky, at best. The actions you take (or don't take) can have a huge impact on your organization.

Controlling the situation at the network level and isolating systems can make things less chaotic and start you down the right path to get things back on track.


Tags: Best Practices

About

balaji