By: scott suhy

Category: Cyber Security for Businesses

Example of a Simple Incident Response Plan

In the light of the New York State Department of Financial Services Regulation 23 NYCRR 500 found here specifically calling out the need for organizations to create an Incident Response Plan (IRP) we put together a simple example.

Here is the NYCRR 500 Section 500.16 language as of 3/14/2017

(a) As part of its cybersecurity program, each Covered Entity shall establish a written incident response plan designed to promptly respond to, and recover from, any Cybersecurity Event materially affecting the confidentiality, integrity or availability of the Covered Entity’s Information Systems or the continuing functionality of any aspect of the Covered Entity’s business or operations. (b) Such incident response plan shall address the following areas: (1) the internal processes for responding to a Cybersecurity Event;  (2) the goals of the incident response plan; (3) the definition of clear roles, responsibilities and levels of decision-making authority; (4) external and internal communications and information sharing; (5) identification of requirements for the remediation of any identified weaknesses in Information Systems and associated controls; (6) documentation and reporting regarding Cybersecurity Events and related incident response activities; and (7) the evaluation and revision as necessary of the incident response plan following a Cybersecurity Event.

This is only an example and every organization will be different.  This example is  meant to put you into the right frame of mind as you begin to craft your own IRP.  Notice that there are requirements called out in NYCRR 500 Section 500.16 that are not called out below that will need to be in your IRP.

Your organization (no matter the size) should have a contact matrix similar to this one filled out, communicated and ready to go so you are ready to responds to a security breach.

The person who discovers the incident will call the HELPDESK contact.

HELPDESK WILL RECORD

1. What type of incident is this? Example: virus, worm, intrusion, abuse, damage.
2. Is the equipment affected business critical?
3. What data or property is threatened and how critical is it?
4. What is the impact on the business should the attack succeed? Minimal, serious, or critical?
5. Name of system being targeted, along with operating system, IP address, and location.  Essentially any information about the origin of the attack.
6. Is the incident real or perceived?
7. Is the incident still in progress?
8. Can the incident be quickly contained?
9. Will the response alert the attacker and do we care?
10. The name of the caller.
11. Time of the call.
12. Contact information about the caller.
13. What equipment or persons were involved?
14. How the incident was detected.
15. When the event was first noticed that supported the idea that the incident occurred.

If the issue IS or COULD BE real (versus perceived) and the business impact is serious or critical then HELPDESK will call the INCIDENT RESPONSE COORDINATOR.

All security issues should be reported to INCIDENT RESPONSE COORDINATOR once per day by HELPDESK for review.  Note that you need to provide guidance to your HELPDESK on how to determine if an issue could be real and how to determine if it has business impact

INCIDENT RESPONSE COORDINATOR Contacts the following people to respond to issue. This is the INCIDENT RESPONSE TEAM:

1. PERSON RESPONSIBLE FOR ORGANIZATIONS TECHNICAL SECURITY
2. PERSON RESPONSIBLE FOR ORGANIZATIONS NETWORK, SERVERS and ENDPOINTS

INCIDENT RESPONSE TEAM:

1. gathers and reviews server logs
2. gather and review firewall logs
3. gathers and reviews intrusion detection logs
4. gather and review SIEM logs
5. gather and review endpoint logs
6. gather and review email logs (if Phishing was involved)
7. gather and review secure web gateway logs
8. begins to interview witnesses and the incident victim to determine how the incident was caused.

INCIDENT RESPONSE TEAM determines the nature of the attack (this might be different than the initial assessment suggests).

1. Determine the attack point of origin.
2. Determine the intent of the attack. Was the attack specifically directed at your organization to acquire specific information, or was it random?
3. Identify the systems that have been compromised.
4. Identify the files that have been accessed and determine the sensitivity of those files.
5. Determine whether unauthorized hardware has been attached to the network or whether there are any signs of unauthorized access through the compromise of physical security controls.
6. Examine key groups (domain administrators, administrators, and so on) for unauthorized entries.
7. Search for security assessment or exploitation software. Cracking utilities are often found on compromised systems during evidence gathering.
8. Look for unauthorized processes or applications currently running or set to run using the startup folders or registry entries.
9. Search for gaps in, or the absence of, system logs.
10. Review intrusion detection system logs for signs of intrusion, which systems might have been affected, methods of attack, time and length of attack, and the overall extent of potential damage.
11. Examine other log files for unusual connections; security audit failures; unusual security audit successes; failed logon attempts; attempts to log on to default accounts; activity during nonworking hours; file, directory, and share permission changes; and elevated or changed user permissions.
12. Compare systems to previously conducted file/system integrity checks. This enables you to identify additions, deletions, modifications, and permission and control modifications to the file system and registry. You can save a lot of time when responding to incidents if you identify exactly what has been compromised and what areas need to be recovered.
13. Search for sensitive data, such as credit card numbers and employee or customer data, that might have been moved or hidden for future retrieval or modifications. You might also have to check systems for non-business data, illegal copies of software, and e-mail or other records that might assist in an investigation. If there is a possibility of violating privacy or other laws by searching on a system for investigative purposes, you should contact your legal department before you proceed.
14. Match the performance of suspected systems against their baseline performance levels. This of course presupposes that baselines have been created and properly updated.

INCIDENT RESPONSE TEAM categorizes issue into the highest applicable level of one of the following categories:

1. Category one – A threat to public safety or life.
2. Category two – A threat to sensitive data
3. Category three – A threat to computer systems
4. Category four – A disruption of services

If Category one or two then INCIDENT RESPONSE COORDINATOR Contacts CXO CONTACT and MANAGEMENT CONTACT and adds them to the INCIDENT RESPONSE TEAM

If Category three or four then INCIDENT RESPONSE COORDINATOR Contacts MANAGEMENT CONTACT and adds the to the INCIDENT RESPONSE TEAM

If Category one or two then INCIDENT RESPONSE COORDINATOR Contacts Forensics, Legal and Insurance contacts (note that it is the judgement call of the INCIDENT RESPONSE TEAM if a Category three or four would require Legal and Insurance to be contacted):

1. CYBER ORGANIZATION CONTACT
2. CYBER INSURANCE CONTACT
3. CYBER FORENSICS CONTACT

If Category one or two, once Legal and Insurance have provided guidance the INCIDENT RESPONSE TEAM should contact the FBI CONTACT and POLICE CONTACT.

INCIDENT RESPONSE TEAM does Evidence Preservation—make copies of logs, email, and other communication. Keep lists of witnesses. Keep evidence as long as necessary to complete prosecution and beyond in case of an appeal.

If Category one or two, once FBI and POLICE have been contacted and provide guidance

1. Segregateall hardware devices suspected of being compromised (if possible) from other business critical devices.
2. Quarantineinstead of deleting.
3. RestrictInternet traffic to only business critical servers and ports
4. Disableremote access capability and wireless access points
5. Follow direction of CYBER FORENSICE CONTACT, CYBER INSURANCE CONTACT and CYBER ORGANIZATION CONTACT
6. Create and Execute Communication Plan

Note:   Try to avoid letting attackers know that you are aware of their activities. This can be difficult, because some essential responses might alert attackers.

Compare the cost of taking the compromised and related systems offline against the risk of continuing operations. In the vast majority of cases, you should immediately take the system off the network. However, you might have service agreements in place that require keeping systems available even with the possibility of further damage occurring. Under these circumstances, you can choose to keep a system online with limited connectivity in order to gather additional evidence during an ongoing attack.

In some cases, the damage and scope of an incident might be so extensive that you might have to take action that invokes the penalty clauses specified in your service level agreements. In any case, it is very important that the actions that you will take in the event of an incident are discussed in advance and outlined in this response plan so that immediate action can be taken when an attack occurs.

If Category three / four, team members will restore the affected system(s) to the uninfected state. They may do any or more of the following:

1. Re-install the affected system(s) from scratch and restore data from backups if necessary. Preserve evidence before doing this.
2. Make users change passwords if necessary
3. Ensure the systems are fully patched
4. Create and Execute Communication Plan

INCIDENT RESPONSE TEAM Assess damage and cost—assess the damage to the organization and estimate both the damage cost and the cost of the containment efforts.

1. Costs due to the loss of competitive edge from the release of proprietary or sensitive information
2. Legal costs
3. Labor costs to analyze the breaches, reinstall software, and recover data
4. Costs relating to system downtime (for example, lost employee productivity, lost sales, replacement of hardware, software, and other property)
5. Costs relating to repairing and possibly updating damaged or ineffective physical security measures (locks, walls, cages, and so on)
6. Other consequential damages such as loss of reputation or customer trust

INCIDENT RESPONSE TEAM recommends (documents) changes to prevent the occurrence from happening again. Upon management approval, the changes will be implemented.

INCIDENT RESPONSE TEAM reviews response and update policies—plan and take preventative steps so the intrusion can’t happen again.

1. Consider whether an additional policy could have prevented the intrusion.
2. Consider whether a procedure or policy was not followed which allowed the intrusion, and then consider what could be changed to ensure that the procedure or policy is followed in the future.
3. Was the incident response appropriate? How could it be improved?
4. Was every appropriate party informed in a timely manner?
5. Were the incident-response procedures detailed and did they cover the entire situation? How can they be improved?
6. Have changes been made to prevent a re-infection? Have all systems been patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?
7. Have changes been made to prevent a new and similar infection?
8. Should any security policies be updated?
9. What lessons have been learned from this experience?
10. Was the incident handled in a timely manner