Cybersecurity Incident Response Management: Before, During and After

Global IT provider, Eze Castle Integration, has been running an educational program for October’s ‘Cyber Security month’ and on Thursday, October 18th, hosted a webinar entitled ‘Cybersecurity Incident Response Management: Before, During and After’. AlphaWeek is publishing edited transcripts of these webinars. The speakers are Matt Donahue, Business Continuity and Data Privacy Consultant, and Jeremy Ross, Senior Product Manager, Eze Castle Integration, and the webinar was moderated by Olivia Munro, Senior Marketing Specialist, Eze Castle Integration.

The key terminology in cybersecurity incident response

Jeremy Ross: A cybersecurity incident is defined by three things; the difference between an event, an incident, and a breach. An event is an observable occurrence in a system or a network; it can include a user connecting to a file share, a server receiving a request for a webpage, or a user sending an email and then a firewall blocking the connection attempt. An incident is a violation or an imminent threat of a violation to the computer security policy, like a security event that compromises the integrity, confidentiality, or availability of any information that you have. A breach is an incident that results in the confirmed exposure of data to an unauthorised party. The difference between something that is confirmed as being lost and being breached versus an incident that is something that may have compromised integrity is important to know.

The National Institute of Standards of Technology produces an incident response life cycle. They put out standards and guidance for firms to follow, from incident response to business continuity and disaster recovery. It has four separate parts: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. It's an ever evolving, continuous process that you need to be aware of. Incident response methodology typically emphasises preparation. Not only does this mean establishing incident response capabilities so that your organisation is ready to respond, but it also means working to prevent incidents to ensure that systems, networks, and applications are sufficiently secure.

Preparation

It's not if you'll be breached, it's when. This is a common saying within the cybersecurity industry; 58% of firms have experienced a compromise or breach in the past year, according to a Forrester Report.  Your key stakeholders, clients, and other observers expect you to take reasonable measures in the first place, but when that does inevitably fail, you want to be able to respond quickly and appropriately. Having an effective incident response management program is key and essential to that.

Incident response is a complex undertaking. Establishing a successful incident response capability requires a lot of planning and resources that need to be aligned. Breaches happen, and so you're going to want to be able to have the capability to respond in the appropriate manner. In order to do that properly, you're going to need a team of dedicated individuals who will be able to respond. Along those lines, many organisations create what is called a computer incident response team, also known as a CIRT, which is a specialised group tasked with responding to these incidents. At its core, it’s a cross-functional team of internal and external experts tasked with responding to a breach, but they must also facilitate communication amongst themselves, notify regulatory agencies, and implement policies and procedures around incident response so that situations are handled according to best practices.

Not every individual in the organisation is supposed to be or going to be on the incident response team. Additionally, you should always consider outside help. There are numerous external vendors and partners you can engage with, from handling all of incident response, or just breach notification, or legal. You should consider engaging those external partners, rather than just building them in-house.

Departments involved in the CIRT

IT: IT staff mainly consists of network administrators to help with investigations when you have an incident. They'll be key to find out who owns and manages the system, who has the furnished skills, and who has administrator access. Without IT, it would be impossible for your CIRT to gain access to the system.

Corporate communications: You may want a key member from that department who is going to speak for the company and deliver the message the company wants to present to customers and business partners. During an incident this is key because you don't want multiple messages going out. You want one clear, single, unified message that's going to tell your key parties exactly what's going on in the incident.

Legal: You need to know who to contact when investigations can show criminal activity. You may have to report to the appropriate regulatory bodies, however you're going to want to engage legal staff before that to provide guidance on the legality of potential breaches, and the requirements of evidence collection and breach notification.

Information Security: You want involved those individuals who are responsible for handling the details of the investigation itself, for example looking at the logs, figuring out exactly what happened, and then digging deeper with a forensic analysis. That's where information security staff are going to play a bigger role. You might hire some consultants to deal with this aspect of it.

Business representatives: Without having the line of business representative, it would be impossible to figure out how the incident impacts a specific product or product line. IT teams need to partner with the business unit data owners to understand the data implications if an incident did occur to that data. You want that to be done prior to an incident occurring.

Still in the ‘preparation’ phase, we have data classification protection. This is a key part of incident response because if you don't know what you must protect and where it is then you can't properly protect it. At a base level, all firms need to protect PII, which is personally identifiable information, PHI, which is protected health information, and non-public information, also known as NPI.

Knowing that, there are also some considerations for data protection, which is where the data resides. Is it in some random HR database? Is it in an Excel file online, in the cloud, is it just a file share on your network? Answering those questions and considering where it is allows you to understand what changes need to be made and aligned with best practices. You're going to know who has access to that data, but everyone shouldn't have access to all the data. If someone from finance or another department has access to a payroll database, for example, that may be a risk and you're going to want to investigate who has access to your critical databases. Having an asset inventory of your systems and networks gives you visibility, which is critical to incident response. By locating and knowing the critical assets that you or your firm simply can't lose – those that will put you in an end-game, out of business situation - then you will better position yourself to prepare and respond to the threats that you face.

Finally, the importance of training and testing, at least on a biannual or annual basis, can’t be emphasised enough. Train employees on their roles and responsibilities during incident response. If an employee doesn't know their role and responsibility during an incident, they're going to be stuck in a tense, stressful situation without a clear action plan. If you develop plans, follow-up and train on those policies and plans, when an actual incident occurs, you're not going to have to overthink everything. You're just going to follow the prescriptive steps that are necessary in the plan, and work with the team to achieve your goal. When you develop plans based on the scenarios of specific events, make sure your team knows exactly how to respond in that situation. Therefore, they're going to know exactly how to walk through it because it has been simulated before. We always encourage a lot of table-top procedures and simulations throughout the year.

Detection and analysis        

During the detection phase we see identification from various sources. Some of these things can be internal alerts that will show you the data. These are like trip wires; alerts will notify you that there is some discrepancy. You might get something externally from vendors, you might receive something from information sharing networks, you might get an email from the FBI saying there is malicious activities.

Matt Donahue: If there is malicious activity coming out, IP's in your domain. There's a lot of different ways that these things can come in, but once you detect it and you can do initial analysis, then you need to figure out how you're going respond to this. Typically, better practices lie in having a core group of people that can take that initial information and size it correctly. It's not all about getting everybody on the phone, or bringing everybody in the room, because that can take a lot of time. You want to have a core group of people that are trained to get the message out and get the process going.

You're going to want to call in your subject matter experts, whether that be internal staff or third parties that you might have that are going to assist you in various ways; cyber security specialists, incident specialists, general counsel, outside council. Bring the people in based on the planning that you've done.

In the ‘boom’ phase, that's what you're doing. Early on, a lot of people get confused. You want to stick to the plan. There are certain times when delineations are necessary but for any type of delineation, I would always recommend documenting those and showing the reasoning to why you would do so. Any delineation from the plan could be looked at negatively by insurers or regulators unless you have good reason to do so. Make sure that you stick to the plan as much as you can.

Once you know that there's a breach you want to communicate internally as well as externally to make sure that there's a consistent message being spread. You want to be proactively giving messages, or keeping a consistent type of message, so that all parties are made aware of what the situation is, or that you'll be giving them updates on some type of cadence that they're going to be familiar with. They'll then be looking for it, minimising the risk of letting them invent their own messaging.

Containment, eradication and discovery

There are various options for containment; you quarantine the breach, you are segregating it, shutting it down. Exactly what you do is going to be based upon your knowledge of what that resource is and what the impact of doing certain things are. You're only going to do that by better understanding the various plans you're going to plug into.

What would help you to make that decision would be to refer to your continuity plan. If you need that resource to continue running, quarantine it. If it’s not business critical, shut it down. If it's not going to have a major impact, take it offline, fix it or restore it, and bring it back. Or maybe your issue is within tolerable levels. Deciding what is okay and what isn't okay, in terms of tolerance, can only be done if you know what you have and how critical it is to your business and business processes.

In terms of eradication, you're going to be gathering the evidence but you're also going to be removing things. Make sure that there are going to be no additional problems, and that anything that's had an impact, for example malware, is going to be removed, because you want to have your system clean.

Recovery

The last phase would be recovery. When you have all these different types of systems or assets, they're going to be brought back online into their normal operating procedure, or at least, at acceptable levels. Analysing what is acceptable and what isn't indicates that you're in the recovery phase. Critically, none of this can happen until you completed the previous two phases.

How the different types of plans work together

Matt Donahue: In terms of the various types of plans, we first have your written information security plan. It documents what you currently have for your information security systems and the various controls; what's critical and what's not in terms of security. It might encompass an incident response, it might not, but it takes that lens of security and builds up what's currently going on in your infrastructure, what's important, and where should people be looking at in terms of incidence. Let's say a drive X has different types of customer data, but drive Y has the marketing materials. If X goes down, that's a problem with Y. Knowing some of those specifics is helpful, and that's some of the information you want to put in that information security plan.

As discussed, disaster recovery plans address issues from a technical standpoint. Something's going down, something's not working, so it’s having that ability to get back into regular business types of operations at a regular time.

Business continuity plans focus on criticality; if this is the system that's impacted by this type of cyber threat, how critical is this to our business? Without doing that type of analysis, or that investigation that you would do during a business continuity plan, that information might not be known. It's important to be able to have some of these different things done, as they do touch.

We've been talking about incident response so depending upon what the incident might be, you're probably going to look at most, if not all, of these plans during that incident response planning. Let's say there's an incident going on right now and you're not sure what it is. First, identify what the issues are, and then you can look at the business continuity plan and the written information security plan to say, ‘all right, based on this, this is critical’. You figure out what the problem might be and how it impacts your business. These plans all work together to inform each other, as well as helping to evaluate what your options might be.

Matt Donahue: The final step is the post activity types of things. Once everything is close to resumption of normal activities, you might want to look at some external assistance, as we mentioned earlier. If there's going to be an impact, or if you're going to be doing something in terms of using your insurance to help pay for some of the costs that have been associated with this disaster, some of the teams that you have identified might be pulled in. A lot can be paid for through insurance, but you want to make sure everything's documented. You want to do some forensic analysis, so you can show that you did what you could, but this is what the issue was.

If there's a potential regulatory impact, again, you're going to want to have that proof of investigation, you're going to want to have those digital forensics to make sure you did what you were supposed to do, you followed along with your best practices and didn't delineate from your plans. Or, on the legal side, if people are going to be potentially filing investigation work, it's good to have evidence, especially if it's the kind of incident where there's going to be a lot of eyes on your company as your firm. External counsel and independent search teams can come in and help support you within this process. Again, this is a nuanced type of activity that not a lot of people can necessarily be masters of, or experts, when they're doing a lot of other things from a typical business standpoint.

Another important thing to do is to have a postmortem. It's going to show you where there were areas for opportunity, things that went well, and things that were modified or potentially could change down the road. A lot of times the value of going to that ‘lessons learned’ discussion is that you can take things that went well, or that didn't work well, and reapply that to the preparation state. You can then modify your plans, add new or different caveats, put in things that will be helpful for the next time. That's an important part of the process.

Real life examples of cyber security incidents

Matt Donahue: Using ransomware for example, users are going to have something pop up on their screen. Someone's going to have to forward something, whether to IT, to the help desk, or whoever it might be in the CIRT. Notification should be an efficient process, but it must also ensure that the notification is going to involve the right people.

Then you're going to want to get the playbook out. Get specifics of the scenario that you think is happening. In this instance it is clearly a ransomware, so go to that specific type of cue card. Analyse what the issue is and then get specific.

When you do get specific, you want to look to say, ‘okay, now we know that it's a ransomware situation. Who else needs to join in this conversation?’ and then get them involved. Then follow the steps. Everybody knows what they should be doing and what they should be concerned about because it's almost like everybody has their own role to play here. This specifically is a case of ransomware and what you really need to do is isolate it to limit its spread. Look at logs to see what people have, look at what was the potential way that it was delivered, and seeing what you do to minimise that, isolate it, segregate it, and keep it from continuing to spread.

Once that's done, you're going to want to look at some of the plans that we have discussed. A lot of times, with ransomware, you're going to want either restore it through a disaster recovery process or do some type of resumption through your regular types of continuity procedures. You can't shut down everything, but you must know what the impact was, what you had to do to handle it and how you can recover and respond. So bringing back those two plans can help you figure out, especially with ransomware, what you can potentially do right now.

With ransomware, don't be afraid to bring in outside assistance. Sometimes you can save a lot of money by being able to take care of it yourself but at the end of the day, what the hackers are going to say is ‘we have X amount of information that we have encrypted, and we're going to destroy it if you don't pay us X amount of money’, so are you really going to try remediate this yourself, or are you going to pay, or maybe a little bit of both? Either way, you’re paying for it. If you're going to pay, it's usually cryptocurrency, so if that's ever going to be in the realm of how you're going to respond to ransomware, it might be good to have that set up initially because it's not always an easy thing to have those resources already prepped. Many people say that you shouldn’t pay ransomware, but that's really going to be up to you to decide at the time. If it's only a little bit of money, or, based on the value of the asset at the time that or what the destruction of the data is going to cost, maybe it's sometimes worth doing it.

There are a lot of decisions that must be made. As you can see here, this is a high-level summary of an incident, but how a lot of these different steps come together will help you out. And then, at the end of the day, it comes to the decisions which must be made, specifically for a ransomware scenario because it's usually a timetable versus an infection. But you can see here how a lot of these things come together, and so the pre-planning work that you can do ahead of time will help.

Jeremy Ross: The second sample incident we're going to cover is a phishing email. Phishing or spear phishing attacks are very common. Let's say IT is alerted to an event where an employee entered credentials into what looked like a platform typically used for work, and then the employee became suspicious as the link, which was spoofed and sent from what looked like a colleague's email, brought them to a portal which was a strange landing page.

First, you're going to want to determine the potential extent of the issue. If they're targeting or attacking one portal, you're going to want to keep a close eye on that portal and start with re-setting the account access and passwords for those users. The next step would be to run scans and pull logs to determine if there's any further impact. If there are any lateral or horizontal moves being done by the attacker, you want to see them. Visibility into your network is key; that preparation and understanding of what you have is going to really help when you get an incident like this that could bloom into something bigger. So seeing those moves, running those scans and logs when you need them is going to be very critical.

Also, make this is a learning lesson. For phishing, you're going to want to know exactly how to report suspicious emails. That's a very key thing that people don't do enough of in my experience. It's good to report, because by reporting, you're helping to protect others in your firm. IT is going to log it and make sure that other people will have it blocked in their inboxes, thereby eliminating the risk of anyone clicking on it or downloading any images or malware. The second part of making it a learning lesson is learning phishing framing simulations to identify phishing emails. When you start to identify two or three phishing emails you greatly reduce the risk of you actually clicking on the legitimate attack phishing email by more than 70 percent. Running a phishing training simulation with your employees is a great way to reduce the likelihood of a phishing email impacting your firm. Often it only takes one weak link, and this type of incident can be a bad one to have to go through if you let it go too far.

Lastly, there are a few technical things you should do like updating email filters and checking your other logs, such as a mail server, your firewall or proxy servers, or even your sim, for any other indicators of intrusions or attacks surrounding the phishing email that was initially received.

Final thoughts

Matt Donahue: At a high level, we've been emphasising throughout this discussion the importance of getting the right people together. That might be internal, that might be external, but just start the discussion. Start to talk about how you are going to handle this, and then go through the different scenarios. But make it specific; certain industries only have various types of threats, or the threats they do face are more prevalent. Know what those are and use that as your template. If you can make it a living and breathing thing that has a lot of people working together, you're going to be more successful, because everybody's going to buy in.

In terms of planning smarter, it's good to bring people in to go through that. Not all this stuff can be solved internally, and you don’t have to spend millions of dollars to do it. Look at what the important things within your environment are and then you can make better decisions. Another thing a lot of people miss the ball on is the metrics that matter for a lot of these decisions. Review what you're spending or what you currently have in place for things like preventative measures. What are the controls that you currently have? Do you have everything that you need to? If not, then perhaps you need only patch a couple of holes versus trying to swallow a huge pill that might be hard for your organisation. Look at the risks specific to your size, your complexity, the industry that you're in, your location, the employees that you have. Look at your liabilities from a legal and contractual standpoint. Look to see what the worst-case scenario would be. That way you can hyper focus on what's important to protect and what you should be putting in place to defend it.

On the reputational side, if there is an incident at your firm, how is that going to represent your reputation internally to employees and externally to investors? Consider how you want to see your reputation in the public eye.

Finally, test and train. That's critical to the success of your program, as well as your response. Make sure people are aware of what their responsibilities are and go through a test. This is one of the things we really want people to walk away with; get to those next steps where you are doing the testing and training and get the right people in to discuss this properly.

**********

Matt Donahue and Jeremy Ross were talking to Oliva Munro, Senior Marketing Specialist, Eze Castle Integration.

***

The views expressed in this article are those of the author and do not necessarily reflect the views of AlphaWeek or its publisher, The Sortino Group