CompTIA Security_ Deluxe Study Guide_ SY0-201 - Emmett Dulaney [107]
Step Two: Investigating the Incident
The process of investigating an incident involves searching logs, files, and any other sources of data about the nature and scope of the incident. If possible, you should determine whether this is part of a larger attack, a random event, or a false positive. False positives are common in an IDS environment and may be the result of unusual traffic in the network. It may be that your network is being pinged by a class of computer security students to demonstrate the return times, or it may be that an automated tool is launching an attack.
It is sad but true: One reason administrators don’t put as much security on networks as they could is because they do not want to have to deal with the false positives. While this is a poor excuse, it is still often used by administrators. As a security administrator, you must seek a balance between being overwhelmed with too much unneeded information and knowing when something out of the ordinary is occurring. It is an elusive balance that is easier to talk about than find, but it’s one you must strive for.
You might find that the incident doesn’t require a response if it can’t be successful. Your investigation might conclude that a change in policies is required to deal with a new type of threat. These types of decisions should be documented, and if necessary, reconfigurations should be made to deal with the change.
Real World Scenario
What If the Intrusion Is Now?
Suppose a junior administrator rushes into your office and reports that an alert just notified him that the guest user account has logged in remotely. A suspected attack is occurring this very moment. What should you do?
You should respond to an attack that’s occurring at this moment the same way you would respond to one that happened before you knew about it. You need to determine what the account is doing and try to figure out who they are and where they’re coming from. As you collect any information, you should treat it as evidence and keep careful watch over it.
Although collecting as much information as possible is important, no one can be blamed for trying to protect their data. Damage and loss control are critical; while it may be admirable to catch a crook deleting your data, if you can keep the data from being deleted, you will stand a much better chance of still being employed tomorrow. As soon as it becomes apparent that data is at risk, you should disconnect the user. Catching a bad guy is a noble task, but the security of the data should be considered paramount.
Real World Scenario
The E-Mail Incident
You’re the administrator of a small network. This network has an old mail server that is used for internal and external e-mail. You periodically investigate log and audit files to determine the status of your systems and servers. Recently, you noticed that your e-mail log file has been reporting a large number of undeliverable or bounced e-mails. The addresses appear to be random. Upon examining the e-mail system, you notice that the outbound mail folder seems to be sending mail every second. A large number of files are being sent. After inspecting the workstations in the business, you determine that several of them have out-of-date antivirus software. How should you handle this situation?
For starters, you may have one or more viruses or worms in your system. This type of virus sounds like a Simple Mail Transfer Protocol (SMTP) virus. Outlook and Outlook Express are the most popular virus spreaders in use today. A virus like Klez32 can gain access to the address directory and propagate itself using SMTP.
You should investigate why the antivirus software is out-of-date, upgrade these systems as appropriate, and add server-based and mail-server virus-protection capabilities to your network.
Step Three: Repairing the Damage
One of your first considerations after an incident is to determine