Why You Need a Concrete Incident Response Plan (Not Strategy)

Image

Recently, I had the privilege to be part of a four-person discussion panel at a security event in London where the topic was about incident response. The panel was hosted by another security professional, and over 50 professionals from the industry were present in the audience. I've worked in information security for 15 years, and I've played a part in resolving many security incidents over that time. I learnt quite a few things in the process and understood where technology played an important part. It should be clear that an organization needs a concrete incident response “plan,” not a strategy. Incident response is a very real thing, and having just a strategy is not sufficient. The general consensus of the panel implied that any organization, no matter what the size, should have an incident response plan in place – one which should be practiced regularly. It’s no good to write a plan and then not rehearse it. When a real incident takes place, the last thing the organization needs is everyone not knowing what to do next. I experienced this once when I was asked to step in and help with an incident response for a client I was seconded to many years ago. A breach had occurred, and I went to a war room that had been set up. There was no clear leadership, and everyone was trying to tell each other their take and opinion on what happened and what to do next. I took charge, identified the relevant stakeholders in the room and on the call to ensure we had the right people and asked for the facts. As the incident unfolded, it then became clear what needed to be done and who needed to do it, but up to that point, it had been chaos! This was a good example of an incident response plan poorly implemented. “If breaches are inevitable, should we care?” What an incredibly dangerous statement to make. This question caused the panelists to stir on their seats somewhat, as it's most likely a statement they have heard one too many times. I met a CISO a number of years ago of a small business who had that very attitude. But it wasn’t just him saying “should we care”; it was also “it’ll never happen to us – we are too small.” Never assume a breach won’t happen. Chances are, you may already have been breached and you just don’t know about it yet. Insider threats, such as disgruntled employees or someone misconfiguring a system, also play an important part in breaches. Of course we should care! Every organization should care about protecting their systems, customer data and confidential information. We should make it hard for hackers to compromise a system by reducing the attack surface. A member of the audience asked the panel, “How do I know if I have already been breached?” What a great question. I responded to the audience member, and talked about the MITRE ATT&CK Framework.

"MITRE ATT&CK is a globally-accessible knowledge base of adversary tactics and techniques based on re-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community." – Source: https://attack.mitre.org

Another panel member also agreed that the framework is a good starting place to help identify if any systems have been left compromised or weakened by an attacker for further future exploitation. To learn more about the MITRE ATT&CK framework, read this series from Travis Smith.

How does technology help with Incident Management?

When an incident occurs, one of the first objectives is to ascertain facts and work out what evidence is available to investigate effectively. The first port of call is usually looking through log files. But if you don’t know what you are looking for, this could be an onerous task. We have all heard the usual comments come back “logging wasn’t turned on,” “don’t have logs that go back that far,” “what am I looking for in the log” and the famous “enabling logs can slow the system down.” It’s vital that logging is enabled on your applications, operating systems and network devices and that logs are transmitted to a central log aggregator tool. By applying correlation rules (intelligence) to logs, a system administrator can identify how the breach in question occurred and look for patterns that occurred before and during the breach such as a high number of failed logins. By contrast, imagine how great it would be if the information security manager spoke up during the call and said: “Fileservers alpha, bravo and delta were impacted. A number of critical operating system DLLs were altered last night at 04:10 on all three servers, which caused app-service-a and app-service-b to stop functioning at 04:12. One of the altered DLLs tested positive as malicious software. Oh, and by the way, I know the name of the user who made these changes.” But without the proper logs available, how does the security manager know this information? The answer is from a solution that can identify changes to files and systems, as well as pinpoint the user who made those modifications – a malicious employee could have hit the servers. Through integration with threat intelligence providers, the solution should be able to validate the change by querying the provider if the file is a known threat or malicious and be able to submit the sample to the provider for analysis if unknown. Also, through integration with ticketing systems, changes can be validated to see if they occurred within change control. In summary, from the conference, it was evident that most organizations present had a security incident response plan in place, but some of them admitted that it had never been tested and that they were unsure who to engage if an incident did occur. It’s paramount that if you have invested in an incident response program that your employees know how they engage the process.