In today's broad, collaborative corporate networks, an incident may be classified as an action on an IT system which involves activities such as theft of intellectual property, cyber harassment, unlawful access, modification to code with intent to harm, and so on. However, every company has its own definition of an incident. Listed below are a few procedures to follow during
Detection of incidents: While going about security incident handling, the primary step is incident detection. Detection of incidents is dependent on the controls that your company has put in place. A detection system is usually a combination of technology (intrusion detection system (IDS) or intrusion prevention system (IPS), security information and event management (SIEM), along with human reporting such as help desk, end user, and system administrators.) However, few corporate entities have adequate detection systems in place. At the end of the day, it does not matter how you detect the incident. What is important is to record certain details such as:
- Time and date
- Who (or what) reported the incident
- Nature of the incident
- When the incident occurred
- Hardware or software involved
- Points of contact for involved personnel
Initial response: The next step in security incident handling is initial response. Typically, initial response involves not touching the affected system(s). Data is collected reviewing network-based as well as other evidence. This phase involves:
- Interviewing system administrators who might have insights into the technical details of an incident
- Interviewing business unit personnel who might have insights into business events that may provide a context for the incident
- Reviewing intrusion detection reports and network-based logs to identify data that support occurrence of an incident
- Reviewing network topology and access control lists to determine if any avenues of further attack can be ruled out
Devising a response strategy: Response to an incident is dependent on its severity. While, going aboutsecurity incident handling, one will also need answers to the following questions:
- How critical are the affected systems?
- Is it affecting business as usual (BaU)?
- Is there a scope that intellectual property has been compromised on?
- Is there an insider threat?
- What is the revenue loss?
- How much downtime is needed to investigate and mitigate the incident?
Incidents vary widely, from virus outbreaks to theft of customers' credit card information. For example, a typical virus outbreak generally results in downtime and lost productivity; or the theft of customers' credit card information could put a fledgling dot-com operation out of business. Response strategy for each event will accordingly differ.
Evaluating the responses and taking action: Once an incident has been identified and initial investigation conducted, the next step to follow during security incident handling is evaluating the options. It is essential to evaluate the options of responses. But time is also of essence.
Additionally, during security incident handling, the response team needs to weigh in all the pros and cons before implementing any strategy. For example, some amount of downtime is needed to fix a defaced website. This downtime may get extended while the system is being imaged for forensic investigations. If it is an external attack, you might have to involve law enforcement agencies, while unauthorized access may simply involve rewriting the access control list.
Hence the response strategy options for security incident handling should be quantified to the following:
- Estimated dollar loss
- Network downtime and its impact on operations
- User downtime and its impact to operations
- Whether or not your organization is legally compelled to take certain actions (is your industry regulated?)
- Public disclosure of the incident and its impact to the organization's reputation and business
- Theft of intellectual property and its potential economic impact
Post incident analysis: Finally, as a conclusion to the process of security incident handling, the entire response cycle should be well documented and analyzed post resolution. Policies and technologies should be changed (if needed), as an outcome of the analysis.
About the author: Bhavuk Arora is an information security and cybercrime specialist. He is the founding director of Blue Box Networks Ltd.
(As told to Anuradha Ramamirtham)
This was first published in July 2010