Congratulations! We have made it to the top of our Zero Trust stack. Today I am going to cover the steps you can take to investigate and remediate threats via Zero Trust.

Throughout this series of blog posts we have been examining how to implement Zero Trust principles across all the layers in our security architecture. (You can read the most recent post here. If you want to see all the posts, go to our website and type “Zero Trust” into the search box.) You might think that we’re done; all good!

You would be mistaken. Why?

• At each security layer, we have established methods to generate and communicate alerts about suspicious behavior. We must take action to respond to those security alerts. Why generate these security alerts if we are just going to ignore them? This reminds me of an old cartoon where the main character complains, “Look at all these dirty dishes! Hand me that dish cloth!” In the next cartoon panel, we see that the character has tied the dish cloth around his head so that he can’t see the dirty dishes.
• Remember that a guiding principle of Zero Trust is “assume breach.” If we are going to presume that bad things might be happening in our systems, we will want to pay attention when we receive an alert about a possible threat. We want to proactively investigate and remediate threats. We cannot do that if we are not paying attention to them.

So, we are signing up to monitor the threat alerts we receive. Unless we go about this in a smart way, what happens next is that we are inundated with alerts and we cannot drain the alert queue quickly enough. So, we throw up our hands and give up. Hand me that dish cloth, would you?

Clearly, we need some tools.

Time to Establish Threat Visibility

The first thing we can do to eventually investigate and remediate threats is to make the threat alerts visible. We do this by turning on audit logging. I learned long ago (ever hear of Call Detail Recording?) that logging events consumes a lot of resources. So, logging is often disabled by default.

Enable audit logging, for whatever period the system will allow (say, three months). At the end of the period, download and store the audit logs somewhere. We will use this to establish a baseline: what events tend to happen? How often? Driven by what? Yes, we are making a leap of faith to think that the period we select is a “normal” one. If you believe the period has some unusual things going on (for instance, migrating an application) then you should pick a different period.

Now we are collecting alerts. And the alert streams are coming in from a lot of places. We need a tool to collect and maybe even begin analyzing the alert data. This is where a SIEM—Security Incident and Event Manager—comes in handy. Look at products like Azure Sentinel or Splunk. Some products will be standalone. Others will offer the capability as part of a broader security offering. A SIEM will help you cut through the alert noise and focus on the events that seem out of the ordinary.

Automate. Orchestrate. But…

With audit logging and (at least cursory) analysis in place, we can begin to investigate and remediate threats. This is a great first step. Let us move forward from there.

The steps we have taken to create visibility around threats has allowed us to better manage security in a reactive manner. Our goal has been to shorten the time between the start of an attack and when we can begin to remediate the threat.

However, the threats do not arrive in an orderly manner. When we investigate and remediate threats at this stage, we feel like the goalie in hockey who warms up by having the entire team fire pucks her way. We would like a tool that can automatically investigate and remediate threats. We need a SOAR—Security Orchestration, Automation and Response—tool.

A SOAR tool will use machine learning to identify patterns of threat behavior across a large dataset (ideally, across the service providers’ entire customer base). When the tool learns a pattern, it can then be configured to remediate the threat.

Here is an example. A malware program copies itself into the Operating System, turns off antivirus checking, creates a PDF with its code embedded in a figure, and emails the PDF to all users it finds in the system. When the malware finds a financial application, it attempts to create and present fake invoices with instructions to wire the payment to an account the hacker owns.

If a SOAR tool has seen this behavior before, it might automatically disable the network segment containing the financial system from accepting any requests. It might isolate the computer with the malware, disconnect it from the network, and alert security staff to wipe the machine and reinstall the Operating System using a known-good copy.

Here is one piece of good news. The SIEM product you are considering may already provide SOAR functions. The market space is changing rapidly, and vendors are realizing that SIEM and SOAR are two complementary capabilities.

… Proceed with Caution.

Security automation and orchestration is still in its infancy. Until there is some Nirvana where you can investigate and remediate threats by setting up some rules, you would be wise to heed the “learning” part of machine learning. There is a strong chance that the algorithm will throw a lot of “false positive” alerts. Depending on what the tool allows, you should plan on tuning the algorithm to show you only the alerts that are true positives. If a malware file behaves in substantially the same way across hundreds of instances, then you can feel safe to automate the response. Even here, you will want to monitor and ensure that you only investigate and remediate threats that are real.

It is an exciting time for security and data geeks. Some of the security algorithms are a bit clumsy, but I can see them learning and improving. Set up the visibility so you can be quick to investigate and remediate threats. Explore opportunities to automate some of your threat discovery and response. Prepare for the opportunity to turn the tools hackers are using against you back on the hackers.