Everyday the threat landscape evolves, and your organization has to adapt or die. Preparing for the onslaught of attacks that occur on a daily basis is fundamental to that adaptation. A well thought out, rehearsed plan allows your organization to counter new technologies and methodologies in the hands of hackers. This plan is formally called a Computer Security Incident Response Plan (CSIRP), and every company must have one. In fact, if your organization does business with the government, such as working for the DoD, it is a legal requirement.
Part of a Process
A CSIRP does not exist in isolation. It is predicated on an Incident Response Policy. The Incident Response Policy consists of procedures that explain precisely how to respond to the most probable security threat vectors and associated incidents. For your reference, NIST SP 800-61 Revision 2 lists ways to handle common security incidents in great detail. Part of handling these incidents includes preparation to attempt to prevent them from occurring in the first place. Preparation is included in the procedures and is the first step in an actual Incident Response Process.
Lessons Learned
The Incident Response Process includes the creation of the Incident Response Policy and the Incident Response Plan. It’s in the process all the time, every day, every hour, every minute. Security professionals must implement security controls to prevent incidents in the first place, but they must also be prepared to identify, contain and eradicate threats when a breach happens. After the threat is gone, all systems are returned to normal operation and the incident is reviewed for lessons learned. These lessons inform the next revision of Incident Response Policies and Plans.
The CSIRP Process
This cycle of learning and revision is part of the creation and modification of the CSIRP. Your organization must learn as quickly as new threats are found to survive. Your CSIRP will be unique to your organization, but in general, the approach will be the same no matter who you are or what you do.
Scope It
Prior to drafting a CSIRP, you will need to determine the scope of your plan. The scope can cover one service, one department, or a whole organization. Obviously, the larger the scope, the greater the complexity of the task, so if this is your first go at it, it may be best to start with the area/s of greatest risk and greatest impact on your organization. These are your critical services. They are the essential functions of your organization that you need to maintain in order not to suffer permanent damage to your reputation, the physical components of your systems, or the health and safety of customers and employees.
Once you have the scope set, you should determine who has a stake in your plan. Whom would it affect if this/these critical service/s you have scoped your document to cease to function? Most likely, it would affect management, critical service owners, IT if not already implicated as the owners of the service/s, maybe your legal department, and if you’re a large organization, it would affect your board of directors. Clearly, your customers would be affected, anyone coming to the aid of physical damage to your building or persons therein, vendors you have contracted with for services in the event of a disaster, and your ISP and VoIP providers.
Download Our Cybersecurity Checklist
RTOs, RPOs, and SLAs
You want to do this with the approval of senior management, as well, because you want to be clear what an acceptable approach to creating the CSIRP is according to them before you start. It is helpful at this stage to define RTOs and RPOs in accordance with your business’ abilities and SLAs you may have with customers and providers. And there are of course regulatory compliance issues you must consider that dictate incident reporting requirements, such as with the California Data Breach Notification Law or GDPR for European citizens which requires you to report an incident involving a data breach with data subject PII within 72 hours!
Someone must be held accountable for implementing the CSIRP. You must determine who will be in charge during an incident. Who will be making executive decisions? Who will handle communication with your employees and to the public? Who will be in charge of emergency preparedness by creating drills and reviews for affected staff? How often will you practice these procedures? Etc. Besides those very basic questions, there is the issue of funding. There should be adequate resources for committing to the development and implementation of the plan. You will have to pay for staff, perhaps new components and applications and any third-party vendors who provide back-ups or off-location hosting sites.
Overview
The structure of the CSIRP will be the same regardless of the nature of your organization. The approach to the response must be organized, methodical and coordinated. It should contain processes and explicit procedures that are clear and easy to understand. It is critically important that the plan is formalized within the organization and that it abides by the scope determined during the preparation phase. An organization-wide response will take into account the nature of your business, its size, structure, and functions. A good CSIRP will specify the resources required to implement the plan backed by management support complete with signatures..
Step 1: Everyone Aboard!
You have to convey the urgency of this task to your senior management to allocate funds and gain approval for the CSIRP in the first place according to the CRR Supplemental Resource Guide Vol. 5, Incident Management, Revision 1.1. If the CSIRP will cover only one service, then it may only be necessary to gain approval from the manager of that service. Hopefully, you have already gotten approval BEFORE you committed time and resources to do this. Regardless, someone has to get the ball rolling. More information on organizing a CSIRP can be found in the NIST Special Publication 800-61 Revision 2.
Step 2: Event Planning
In order to respond to a security incident, you have to know one occurred. To that end, you must have a system for capturing and logging information to be analyzed that could indicate an incident. This type of resource should have been designed into your systems at the onset of their implementation. If not, you will have to make sure you have this functionality now.
You will have to define what a security incident is to you like a malware infection on a machine on your network, a DDoS attack that brings a server down, or simply a user accessing files they are not supposed to have access to. In general, anything that affects the service/s defined in the scope can be considered a security event. You can make it as big or small as you like. Just remember that if it involves data covered by some regulation or contract, you will have to comply with their requirements.
There are thresholds for event reporting that you will need to determine based on the types of security components you have on your network. Hopefully, you will be able to define these in your security components (like your firewall or IPS) and institute automatic alerts and monitoring. If not, you will have to establish a schedule for monitoring logs yourself.
Documentation regarding the types of incidents and responses should be contained in a knowledge base somewhere. This documentation should indicate the priority in responding to events based on their criticality. For example, a phishing scam ranks lower than a server attack. Documentation should include who resolved the incident and how it was resolved as well for future reference.
Step 3: Priorities
You need to determine an order of operations in the event that many security incidents coexist simultaneously. This can be likened to triaging injuries in an emergency room. You need to determine your most critical patients and treat them first. The person with the broken arm, though in pain, can wait. In terms of your system’s services and components this means that you need to determine those that are most critical to your business functions and those you can live without — for a little while.
An easy way to categorize security events is by their severity, for example, “Critical,” “High,” “Medium,” or “Low.” But you can use other criteria as well, as long as it helps you to respond in order of most important to least important incidents. You will also need to determine a method of analyzing an incident to see if other co-occurring incidents are related by the same root cause. This should be part of a procedure.
Once you have identified what is going on, what is causing it, and you have reviewed your knowledge base or otherwise determined how to solve it, it’s time to determine how to go about addressing each of the issues implicated in the resolution. This is where it is important to know the order of importance of your systems depending on how critical they are to your functions. Part of the criteria for determining this will also include the amount of time you can afford for these components to be down before irreparable harm is caused.
Determine how often you should be recording events based on how critical the affected component/service is to your organization. Review compliance requirements to determine how to identify evidence so that you are able to preserve the appropriate chain of custody. Make sure you document this process and train the responsible individuals in it.
Step 4: Call It
There are probably established protocols in your organization already for determining when to call a disaster a disaster and when to implement your DRP and BCP. But who is to determine when a security incident becomes an issue. Sometimes, as with a malware infection on a single computer, the IT department can handle it by just unplugging the computer from the network. It’s unlikely that this type of incident would command the attention of senior management. But at some point, like when the DNS server is under attack, and you can’t get out to the Internet, it becomes a problem for everyone. The point is you are going to have to determine what qualifies as a security incident.
Some things to consider are whether or not someone may be injured or die; how much of your organization is affected; what kind of cybersecurity incident it is, such as a minor violation of access policy, loss of CIA, or major Dos or DDoS attacks; what systems are affected, i.e., whether or not they are business-critical; and what types of incidents you might consider automatically escalatable, such as a major data breach.
Once you establish your criteria for escalation to senior management, it’s time to determine how you will respond. A response plan should include who and how you will analyze the evidence of the incident. It should also include the software and other tools you will use to evaluate the occurrence, and the appropriate employees should be trained in the analysis procedure. You should include the evaluation and correlation to other possible incidents to determine common causes or weaknesses and vulnerabilities in your system. All data and procedures should be documented in an incident report that is reflected in the knowledge base.
Step 5: Response and Recovery
Hopefully, your organization already has a Business Continuity Plan and a Disaster Recovery Plan. In the event that a security event qualifies as a disaster, you will want to have these procedures in place. Once you elevate a security incident up to senior management, it will be their decision as to whether to implement an organizational response. Regardless of the magnitude of the incident, the person/s responsible for fielding the security event will need to have a plan to deal with it.
To create a plan for response and recovery you will need to consider the kinds of things that can go wrong just like in your BCP and DRP. In fact, you might borrow some of the information from those documents to inform your own procedures. Types of incidents you should consider can be as bad as a worldwide pandemic or something confined to your building like a fire. Your plan should include references to the BCP and DRP, which should include methods for the dissemination of information internally and externally and medical response and first responder plans.
Your department should have a template for an incident report to make documentation consistent, easy to read and understand, and easy to correlate with other incident documentation. If you don’t already have an Emergency Operations Center, your plan will need to describe one. It should also include those things you must do for damage control and to ensure the continued functioning of critical services. It should also include the tools, knowledge, and skills required to resolve the incident. And it should include the entities, both internal and external, required to coordinate recovery efforts.
You must also consider how you will restore your organization back to full functionality or normal operations once the incident has passed. There will likely be an order to the restoration of services based on their priority as determined in a BCP or DRP. This extends beyond but also includes your IT department and its services. This recovery order should be included in your own plan. Make sure to include a method of reporting your resolution status to all stakeholders so they are kept in the loop and know how long an incident may last. This could be once an hour or every 15 minutes depending on the nature of the incident.
Step 6: Communications
As stated before, it is super important that you communicate what is going on with all stakeholders. You must assign people ahead of time to do this and give them the procedures for doing it. The incident response team should have a plan in place for how to communicate through each phase of the incident response in a timely manner. Those phrases should include determining an event that has taken place, escalating the response to management, prioritizing your response, analyzing the incident post facto, and recovery to normal operations. The tendency is to not want to communicate when something is seriously wrong, but it is imperative that you keep all stakeholders informed throughout the entire recovery process.
Step 7: Post Mortem Review
A final review of what happened and how it happened will inform your next revision of your incident response plan as well as immediate steps to address any vulnerabilities in your systems, policies, or procedures. It’s important to get at the root cause of what happened, not just describe a superficial series of events. That way you can continuously improve on your detection and protection processes. Your incident management process may need revising, as well. You should also identify what went right with your plan and process.
Step 8: Roles and Responsibilities
At this stage, it is time to evaluate who is responsible for what again. It may well serve you to include a description of incident response responsibilities in the responders’ job descriptions. Here you must make it clear who is accountable for detecting incidents and who is responsible for resolving incidents as well as how events get escalated. This is the time to reevaluate who is in the best position to do this and make sure you are explicit in naming names.
Expert Compliance
RSI Security is an expert at evaluating your current security posture, including your plans and procedures, and can advise you on the creation of documentation. We are highly qualified to make sure you meet any regulations or compliance requirements and have over 10 years of experience in the Cybersecurity industry. We make it easy for your organization to prepare for any kind of attack. Contact RSI Security today for a free consultation on how we can help.