Incident Response
Five Common Mistakes of Computer Security Incident Response
With the wide array of viruses, malware, and internal threats seen on the security horizon today, the odds are good that every company will have to deal with some kind of computer security incident this year. While it's not uncommon for companies to have little or no security monitoring, detection, or prevention, every company must respond quickly once it has become a target of an attack.
This paper describes five common mistakes made during a computer security incident response effort:
Problem #1: Being ill-prepared for the eventual security incident.
The first and biggest mistake of computer security incident response is not being prepared for an incident before it takes place. There is usually a great deal of confusion and panic at the onset of an incident. An incident response plan detailing procedures, methodology, key personnel and responsibilities will help mitigate this panic and direct the key people to appropriately initiate the response.
An incident response plan permits you to focus on a checklist of critical items, contain the damage, and curb your losses. If you are ill-prepared for the eventual security incident, you won't be able to respond appropriately.
Problem #2: Failing to increase monitoring after the incident has occurred.
Unsurprisingly, before an incident occurs, many companies do not have sufficient monitoring and surveillance measures in place. However, the second common post-incident mistake is to fail to increase monitoring capabilities throughout the company. Even though some companies cannot afford 24/7 security monitoring, at the very least you should enable all AAA (Authentication, Authorization, Accounting) logging capabilities for all affected infrastructure.
This fairly simple act might make all the difference by providing evidence to identify the root cause of the incident and help to resolve it. You must ensure, however, that you have ample space to keep sufficient security log data. If not, you might find that the data that you thought was accessible was rotated away, deleted, or removed.
Problem #3: Not recognizing that the incident could end up in court.
Every security incident should be investigated as if its eventual destination was a courtroom. It's critical that the evidence collected is of high forensic quality and that an established chain of custody of all evidence is maintained throughout the investigation.
Even if on the face, the incident appears to be minor, there is always a chance that it will end up in court. For example, a simple case of inappropriate web access of an employee could become a case of child pornography.
Following a high standard of investigative quality in your incident response procedure, keeping in mind that it may eventually be reviewed in court, helps to ensure that the evidence will be reliable.
Problem #4: Restoring the system but not addressing the root cause of the incident.
The fourth mistake of incident response can occur if there is significant pressure to restore functionality to the affected systems. The desire to restore system functionality post-incident is certainly understandable but failing to determine the incident's root cause will lead to further incidents.
For example, if the root cause of the incident is an unpatched system, and the system is rebuilt from the original OS media but not patched, it is very likely that another incident will occur. As well, the same incident will likely occur to other systems within the organization.
While it is of primary importance to restore operational functionality, it is also important to determine why the incident occurred, and to prevent it from happening again.
Problem #5: Not learning from previous incidents.
The final problem seems very simple, but in fact is quite common. After the incident has been declared "all clear", it is important that the investigation be reviewed. A review will help refine the incident response procedures, identify weaknesses, and permit lessons to be drawn from it.
To help facilitate this review, the incident should be fully documented throughout. A "Root Cause Analysis" meeting should be held post-incident, including all involved parties, including specific resource owners and IT staff.
Over time, the organization will be able to build an incident response knowledge base, permitting the methodology and procedures to evolve as attacks change.
With the use of our proprietary network sensors, eSentire helps their customers proactively address and mitigate security incidents.
“The number of compromised computers jumped to more than two million last year, with 25 per cent of all malicious attacks linked to botnet activity,new figures show.”
(SC Magazine Jan 2007)
|
