Your questions and my answers: Incident response

Imagine Fort Knox. Imagine the massive walls made of granite lined concrete, reinforced with tons and tons of steel and the guards watching over it, day and night.

Now, imagine a swiss cheese. Picture the block of yellow matter with all its holes, ready to be devoured. Feel free not to imagine the smell of the cheese. Fortunately, that will not be necessary in this case.

Now that you have a clear image in mind of both Fort Knox and a swiss cheese – and perhaps you have already guessed where I am going with this analogy – I dare presume that you prefer the security vault as the metaphorical goal of your cyber security.

Fort Knox, however, does not come cheap. So, unless your business is sitting on almost unlimited resources, then you will benefit from striving for a level of security somewhere in between the fortified vault in Kentucky and the transparent, plain sailing cheese.

But how do you do this?

In my webinar, which I so daringly entitled 5 Shortcuts to Your Worst Security Nightmare, I dove into the pertinent topic of incident response. A vital topic when it comes to establishing your cyber security as either a vault or a cheese.

In this blog, I have taken the liberty of gathering all of the excellent questions from the webinar participants and my (hopefully) somewhat excellent answers. I hope they will be of use to you and your incident response.

How would you determine whether the attacker is a state actor or a ransomware crew?

This is a question about attribution: who is behind an attack? How do we determine this?

Almost all attackers, without exception, have a certain modus operandi (MO). Why do they always have the same MO? Because it is simple. If I break into houses, I will use one, two, or three different ways of breaking in, because that is just what works for me. And if I manage to break into enough houses, I have no incentive to change my MO. The same goes for attackers: they have an MO, and they use certain tools, and they continue to use these tools simply because they work.

For us at NCC Group, it is important to understand, for instance, that a particular APT uses certain tools: usually registers the domain as a CNC about two weeks out and has one domain per victim. Assessments like this help us determine who the attacker is. At NCC Group, we have collected threat intelligence for over 15 years. This is information about threat actors. During incidents, we can use it to determine who is behind an attack. Although in general, state actors tend to use more home-made tools, which makes them somewhat easier to identify than financial crews who generally use more standard tools available to anyone.

Some ransomware will intensify when network connections to the command server are blocked. What is your general advice on what to do: block connections or not?

I would say that depends a little bit on the group. And it is not always easy to predict. My advice for individual systems is that if you need to do anything, do not switch it off, but disconnect it instead. That way, you at least keep all of the traces. You can also keep it running and call your outside incident response provider for more specific advice.

The way we normally go about investigating an incident is that ideally - and this is tough - we want to make sure that we know the scope of compromise; whether we are talking about a ransomware crew, or whether we are talking about a state actor who is carrying out espionage. Where is the attacker? Which systems were touched? Which systems were infected? Is the attacker still around? Once we know that and what they are after, we can provide well founded advice on what to do: block the network connections or not. But, when an attack is still ongoing, there is always tension between gathering more information and making hard decisions. This is inherent in large incidents.

What is different in terms of incident response when you are relying on cloud and IoT?

I would say the biggest difference is your ability to get logs. For example, with Business Email Compromise, when it is Office 365 environments or GSuite for that matter, all the logs are in the cloud and you cannot easily get them.

We have scripts that basically extract all the logs. We need no other client involvement than getting access, and then we can collect the logs directly ourselves and analyze them. So, the main difference is basically whether you can get your hands on enough logs; and that will depend on the provider or the SAAS solution.

Who should be in charge in times of crisis? Somebody within business or somebody in IT?

In my opinion, the gorilla – that is what I like to call the person at the head of the table - cannot be someone from IT. It cannot be someone within business either. I know, in reality - and I think that is probably fair and makes a lot of sense - the interests of the business very often trump the interests of IT. But the gorilla should be someone that oversees all interests, and who can balance the interests of business versus those of IT.

In effect, you will be looking for the gorilla higher up in the leadership chain. However, the most important thing is that it is someone who has the mandate and the role of balancing different interests. So, if it does happen to be someone from IT or business, their role should not be to only look after those specific interests.

What are the most important log sources to be able to do an effective forensics analysis?

I would say domain controllers are super, super important. Domain controllers are obvious, but what is not so obvious is that you need to offload those logs, because otherwise they rotate really quickly. If you have a big infrastructure and busy domain controllers, you may end up with logs that are really short, with very short timespans. Therefore, you need to offload them.

Another really useful piece of logging information is your workstations, and the client logs are interesting because they usually go back very far, even if you pick them up from the workstations themselves. Very often, they help us understand lateral movement: how does an attacker move through your infrastructure?

Then there are firewall logs, authentication logs from your VPN or your remote desktop, everything that logs people coming in. And let’s not forget AV logs; these usually contain something that was detected but that no-one looked at.

How would you tackle a breach at for example a scale-up with only 8 employees, but whose technology is used at and by large corporations? So, while the company is small, the impact can be huge.

There is an interesting nugget in this question which is important: you are as interesting as your partners and your customers. Not necessarily for ransomware crews, but this is especially important for espionage. If you have partners or customers that are interesting for a Russian or a Chinese crew then you will be interesting for the Russian or the Chinese crew. Consequently, even if you are a small company, you might have lots of interesting information and that is what this question is about.

I would say that if you are only 8 employees, you have no choice but to make sure that you sign a contract with one or two incident response providers that can help you out when things go south. There is no other way. I would say that during the incident itself, you might be challenged in managing the crisis, because with only 8 people, you are going to be strapped for resources. But in terms of the breach and the investigation, you should not even try to do that yourself, that is out of the question.