Implementing Countermeasures to a Security Incident

Once the cause of the incident has been identified, you should close off any entry vector the attacker has utilized. In essence, you have identified a specific threat through risk analysis and you should now mitigate that risk. This simple description applies regardless of whether the threat is a denial-of-service condition, a malicious attacker who has installed Trojan horse applications on a server, a curious employee viewing files to which he should not have access, or any of the other myriad security risks networks face today. Although the response will differ depending on the threat, the goal is to eliminate the risk and continue with normal operations.

When implementing countermeasures to an attack, you must consider the benefit produced by the countermeasure and the effects on business continuity. For example, the decision to disconnect an organization s connection to the Internet or its network connection to a business partner might cause the company loss of productivity, but if the alternative promises to cost more than this disruption, the alternative is not preferable. Such decisions should be made only by senior-level management. Other types of countermeasures have less drastic business consequences and can be more easily implemented.

For example, if upon reflection, you realize that a firewall was configured in a manner that is too permissive, the application of stricter settings is needed. If the method of attack exploits a known vulnerability for which a security update exists, you should test and apply the security update to all computers that have not yet had the update applied. If a user s password was compromised, that password should be changed immediately and all of that user s sessions should be terminated. If an account with administrative credentials has been compromised, all passwords throughout the organization might need to be reset.

Assessing the Scope of an Attack

The risk assessment for the particular attack will dictate the specific countermeasures required. If you cannot discern the full scope of an intrusion, more drastic measures might need to be taken than if you had noticed the attack early and are aware of its full scope. Given the nature of computer security, it is much more likely that the former will be the case. That said, a more conservative response is typically preferable to one that is permissive. This is because implementing a solution that lacks the necessary protections is no better than performing no countermeasures at all.

This is most clearly illustrated by a system-level compromise one in which an attacker has gained high levels of privilege on one or more systems and might have utilized those privileges. Because an administrative user can do anything on the systems over which she has authority, an attacker who raises his privileges to that level can do the same. The attacker could add accounts to the system or domain, add privileges to existing accounts, add accounts to privileged groups, replace system files with Trojan horse applications, modify the core of the OS to mask his continued presence, or perform any other task that an administrator can.

The industry consensus on the best practice for recovering from such a situation is to rebuild any system that has endured a system-level compromise, unless you are 100 percent certain that no additional damage has been done. Even restoring the system from backup might not resolve the issues created by the attacker because you might not have detected the attack until after the backup in question took place. The only way to be certain that the system has been restored is to rebuild it by using trusted media that employs secure build processes that protect the system from compromise until it has been secured.

Building a system on an isolated network can protect the computer from being compromised by viruses or attackers that have penetrated the network before the system is secured.

Weighing Tradeoffs

As you implement countermeasures, be cognizant of the tradeoffs that might be involved. For example, by disconnecting a computer from the network to preserve its state for further examination, you could alert the attacker to the fact that you have discovered his presence. This could result in the attacker attempting to compromise other computers on your network that have not yet been comprised, or it could result in the attacker immediately initiating destructive methods on other computers he has already compromised to prevent you from collecting evidence that might be used to track him. However, allowing the attacker to continue unimpeded can cause further damage to your organization s network or computers. Consider the possible reactions an attacker might have to the countermeasures you put in place before you deploy them.

The implementation of countermeasures is more complex when the intruder is internal. In such situations, the incident response team must be careful not to alert the intruder that the team is aware of his activities so that further damage can be prevented. This situation is made even worse if the attacker is a trusted member of the response team. As a response team member, he will be aware of many or all details of the investigation and could change his attack posture to defeat the efforts of the response team. Or the attacker could go dormant to make it appear that attacks have ceased, in order to protect himself from being discovered.

If you believe that the intruder is an employee of your organization, you should involve the HR department as soon as possible to avoid violating the employee rights of the suspect.