As stated in the previous article, "5 Critical Steps To Take After Being Phished," it is acknowledged that, despite the efforts of the architects, engineers and defenders in the cybersecurity department within an organization, something will make it through. Reiterating that pragmatically, defensive security is more difficult than the offensive counterpart. Cyber defenders need to be right via prevention almost every time. What happens when their preventative measures fail? This is where the term 'Incident Response' comes into play.
By definition, an incident is an adverse event. An event is anything that happens in an information system (computer). Incident Response is the technical steps in response to adverse events. Another related term is 'Incident Handling,' which is the broad steps taken by an organization to identify the root cause of an incident and work to correct the cause of the adverse events. This article will touch on aspects of both Incident Response and Incident Handling.
There are numerous fairly obvious considerations that a business can take and several more that are less obvious to those outside of cybersecurity. Even to some in cybersecurity, some considerations or measures are foreign. It is only natural for most, if not all, of this to be absolutely foreign to business decision-makers. While IT and cybersecurity are supposed to enable the business to be more efficient and capable, sometimes they complicate the business. That does not always have to be the case.
Obtain Legal Counsel
Before you do anything else, get a lawyer, whether on staff or on retainer that understands cybersecurity and the dilemmas faced in cybersecurity. Sometimes the legal requirements and what makes sense to technology and cybersecurity professionals do not align, having legal counsel will help protect you. They will need to buy in on policies, procedures, public statements and any notifications to clients, partners, vendors or government regulators.
Establish Your Incident Response Plan Early and Revise Often
Oftentimes, organizations lack proper Incident Response planning, if they have any at all. After an incident occurs is NOT the time to develop a plan. When an incident occurs, life can rapidly become chaotic. Executives that remain hands-off with IT and cybersecurity will want briefings. If the incident affects the public, the media and/or law enforcement may have an interest in the incident as well. In the absence of an in-depth conversation about the plan itself, the plan should minimally address the following:
- What constitutes an incident
- Who to notify in the event of an incident and how
- Who is in charge (by name or role)
- Priorities (forensics versus restoration)
- Law Enforcement involvement
- PR strategy
- What incidents to expect for the business given the industry, geographic location and threat model
Prior to being in this situation, organizations should document what they plan to occur, what needs to happen in response to this, and who will be doing what. Best practices dictate that Incident Response planning occur very early in the lifecycle for an organization as well as for each information system (i.e. production, development, user acceptance testing, finance or data center). This is not a one and done project. As the threat landscape of an organization changes, the IR plan should as well. The same goes for the evolution and capabilities of systems used. What was a threat based on yesterday's technologies used yesterday may not be applicable to the technologies being used today. In the absence of actual incidents, tabletop exercises are a great way to measure the efficiency and outcomes associated with an organization's IR plan.
Tabletop Exercises Are Your Friends
Tabletop exercises typically involve an unbiased outside party that will facilitate the exercises. These exercises require that players in the IR and Incident Handling (IH) process assemble together to simulate their actions for (typically pre-approved) incident scenarios. The facilitator will read the scenario and members of the team will simulate their actions. The facilitator can also provide injections, which are variables that will test the team based on the unpredictable nature of incidents. In my experience, injections are also used if the exercises rely too heavily on one team member as well, since the whole team should be familiar with their primary duties as well as being secondary for the duties of other team members in the event that they are incapacitated or unavailable.
These exercises can be disruptive in terms of taking people away from their normal jobs to participate but they should not cause any interruptions to the business itself. When doing tabletop exercises, it is beneficial to present participants with things they may see during an incident: log data, screens or alerts, emails, social media posts, phone calls or other props. When working through the process, participants (as realistically as possible) simulate taking their actions, whether it is calling someone, writing a press release (but not releasing it), writing a Powershell or Python script or making changes to a router. For the technical simulations, the ability to write the script based on evidence provided would be sufficient.
Establish Relevant Incident Response Playbooks
Something that would be immensely useful in tabletop exercises, as well as actual incidents, is playbooks. Like the sports analogy they come from, these are predefined actions to take based on a scenario. This has the capability of integrating into the organization's business continuity and disaster recovery plans (if the organization has any defined).
Within the playbooks, I prefer to have a general actions section with directions to follow that are uniform to the organization. Beyond this, each incident type should have criteria for classifying the nature and priority of the incident as well as notifications, actions, considerations and decision points unique to this incident type beyond the general actions for all incidents.
Determine The Forensic Response
Digital Forensics go hand-in-hand with Incident Response, hence the common DFIR acronym. Not every company has forensic capabilities. Forensics can be expensive with underutilization if managed internally, depending on the size of the organization. Determining whether to insource a digital forensics team or to maintain an external team on retainer is a decision unique to each organization based on regulatory requirements, budget, size and maturity of the organization, recovery objectives and public involvement.
Having a determined forensic response, even if the decision is to not respond forensically, will drive the actions that users and the cybersecurity staff should take should something go wrong. If a decision to forego forensics is what the executives decide, the guidance of actions to take should likely not include sending the system to sleep or hibernating. Conversely, if a forensic action is expected, understanding the policies, procedures and capabilities associated with performing digital forensics and
Defining Recovery Objectives
Once it is determined if you plan on a forensic response, you need to determine how much time a system or set of systems can spend offline. Forensics can be an infinite loop of analysis. As an organization, it is prudent to collaborate with the team that handles disaster recovery (DR) to see if certain objectives are defined. If not, this is a good segue to getting a DR program in motion as well. Specific objectives to consider are:
- Recovery Point Objective (RPO): This is the point (in time) that needs to be recoverable. This is a hard line in backups based on events.
- Recovery Time Objective (RTO): This is the amount of time that it is acceptable for a recovery to take before unacceptable or irreversible consequences occur.
- Maximum Tolerable Downtime (MTD): This is the amount of time that a system can be down before unacceptable or irreversible consequences occur.
Once these are ascertained, then forensic response and processes should be revisited and revised to stay in line with the organization's objectives.
Determine What Reporting Needs To Occur
Depending on the nature of the breach and the public impact as well as input from legal counsel, reporting may need to occur. Reporting definitely needs to occur internally. As for external reporting, this may be in the form of press releases or formal notification to regulating bodies (i.e. PCI Council or the EU for GDPR). It is best to have a template ready where the details can be input and vetted by the legal team before transmission.
Communications, whether good or bad, can affect the business as we've seen with Yahoo, Target, Uber and Equifax. The means and transparency of their reporting can sway public opinion and compound exponentially beyond anything the actual incident caused. Bad PR is not the desired outcome. Organizations must find a way, within the confines of the law and their own liability, to admit wrongdoing and be transparent about their steps to prevent this incident, and others, from happening again. Staying silent, being combative or being overly secretive will only attract more attention and diminish public sentiment.
Train Your Users And The Cybersecurity Team
As stated in the previous article, "5 Critical Steps To Take After Being Phished," having the steps for users, executives, IT and cybersecurity ahead of time from both the technical and non-technical lenses is paramount. Referring back to the statement at the beginning of this article, during an incident is not the time to define actions and roles. Users do not need to know every single action for every team member, but they should be aware of what constitutes suspicious, how to report it and what they should do to enable the team to solve the problem in the most expeditious manner possible. Philosophically, employees having this knowledge coupled with a non-punitive policy where they may fear being sanctioned or terminated is the most ideal situation for fostering this culture.
Implement Sound Cybersecurity Fundamentals
At the end of the day, we would rather avoid having incidents altogether. Implementing a cybersecurity framework like the Center for Internet Security Critical Security Controls© or NIST Cybersecurity Framework will help guide the cybersecurity team towards achieving a more robust and effective cybersecurity program that is able to minimize or prevent events from becoming incidents. Many vendors seek to solve this problem, but without the fundamentals, these efforts are in vain. Using the Critical Security Controls© as an example, implementing the first five will immensely improve an organization's security posture. These five are:
- Inventory and Control of Hardware Assets
- Inventory and Control of Software Assets
- Continuous Vulnerability Management
- Controlled Use of Administrative Privileges
- Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers
Conclusion
In conclusion, incident response is not easy and it doesn't have to be complicated. An ounce of forethought is worth a ton of reaction. Taking steps to improve the organization's cybersecurity posture before an incident while concurrently seeking to implement and improve their ability to respond to an incident and resume normal operations is paramount.
