Identifying the incident

At some point, your business is likely to have to deal with an incident.  When this happens, being able to accurately identify and classify the incident is key to responding effectively with the minimum impact to your BAU operations. Yesterday, we discussed how proper planning will help you get a robust incident response framework in place.  Today, we are going to look at the sorts of questions you need to ask yourselves in order to be able to identify and classify an incident, and hence tailor your response.

If you are in the position of initiating an incident response, it is a fair bet that you have identified one or more indicators of compromise.  At this stage, you will be dealing with a suspected incident.  You may have evidence from one or more of the following:

• Unusual activity detected by proactive monitoring of critical systems or processes
• Unusual activity detected during reactive audits or reporting
• User reports of unusual observations, or social engineering events
• Detection of secondary consequences (e.g., unusual increase in network traffic, or power usage)
• Outside notification from, for example, law enforcement
• Compromised data located in the wild

Once you have a suspected incident, you need to confirm whether an incident has, in fact, occurred, and identify the nature of the incident to the best of your ability.

Sometimes, you will have very clear and unambiguous indicators which point to an information security incident.  Compromised data in the wild, for example, is entirely clear; you can confirm that an incident has occurred immediately.  Unusual CPU and network usage on a server, however, may have multiple potential causes, many of which are not information security incidents.  In these cases, further investigation is called for.

Review the information sources that you have available to you immediately.  When your potential compromise involves a sensitive data store, or a specific system, it’s often helpful to work outwards logically from the data location as you review information, identifying your relevant information sources as you go:

You will want to examine as much evidence as you can rapidly.  Ask yourselves, do the information sources we currently have access to support our suspicion that an information security incident has occurred?  What other possible explanations are there?  Can you correlate suspicious events across multiple information sources?

• If the IDS detects a brute force attack against the website, do web logs support this having occurred?
• If a user reports a suspected phishing attack, has this email been received by other users, and did the user click on links or open documents?
• Are the affected suspect systems behaving in any sort of unusual manner?

You also need to think about answering questions about the nature of the incident.  Is it a generic malware infection, or an active system hack?  Is there an intentional denial of service in progress?  Is this an incident of deliberate insider action?

If the incident still cannot be confirmed because you don’t have the information to verify it, further information is required. 

• Are the systems thought to be affected critical to the business?  If so, the suspected incident may need to be treated as a confirmed incident even where no corroboration can be found during initial review.
• Do the systems or users affected have access to critical systems or data?  If so, the suspected incident may need to be treated as a confirmed incident even where no corroboration can be found during initial review.
• Can additional monitoring be deployed to suspect systems to identify any further information?
  • What resources are available to provide additional monitoring of system activities?  Is deployment of these resources appropriate?
• Is a precautionary re-build of affected systems as a ‘just-in-case’ measure a proportionate response?

It’s worth considering that an advanced attacker may have covered their tracks well; lack of confirming evidence is not necessarily evidence that a compromise did not occur.

Extended monitoring of suspect systems over time may confirm that an incident has occurred, or conversely, confirm that no incident has actually occurred.  You will need to decide whether this is something you have the capability to put in place, and whether you have the resources and expertise to monitor the situation effectively.

In some cases, the potential damage to your business of the suspected compromise is so severe that every suspected incident must be fully investigated and treated as a confirmed incident.  This should be determined during your preparation phase, and informed by your Business Impact Analysis.

Once the incident is confirmed, or you wish to treat it as confirmed, you need to understand as much about what you are dealing with as you can.  With all the information at your disposal, you need to think about the following questions, and see whether you can answer them with confidence:

• Who has attacked us?
• How was the attack introduced?
• When did the attack occur?
• What data or systems have been compromised?
• Is the attack still ongoing?
• Why were we the target of the attack?

Your goal is to try and understand the methodology and the extent of the attack as fully as possible.

Incident response cannot be a static process; every incident evolves as the investigation proceeds and you are unlikely to have a complete picture initially.  Every time you unearth a new piece of information about the incident, you need to critically review this in the context of what you already know and see whether it changes your perception of what has occurred and how you need to respond.

Monday: The Five P's

Tuesday: Identifying The Incident

Wednesday: Defining Your Objectives

Thursday: Enacting Your Response

Friday: After The Storm