Is Your Cybersecurity Answering the Right Question?
I am a big fan of Doctor Who, the British science fiction TV series. So much so, that I didn’t just watch the show, I read most of the books that were available when I was in high school. A scene from one of these books stands out in my memory: Doctor and his friend Sarah are trapped in a maze. In thinking his way out of the conundrum, The Doctor states something to the effect of: “Every question has an answer. It’s just a matter of asking the right question.” This is a lesson that’s stuck with me all my life and I constantly ask myself (and those around me): “What problem are we trying to solve?”
Technology is a consequence of a problem. That’s why explaining the technology by itself doesn’t really paint the entire picture. To clarify the value (or lack thereof) inherent in a technology, it’s very helpful to start with some basic problem statements to understand and solidify you’re really getting what you pay for when it comes to cybersecurity.
Defining the problem
I was fortunate enough to be around since the inception of our Zero Trust Analytics Platform (ZTAP). This platform underpins the value of our Managed Detection and Response (MDR) service. We had specific questions that guided us down the technology path we are currently on:
- How can we resolve every single alert by a limited set of security systems?
- If we were to build this platform, how can we ensure it delivers the quickest time-to-value to our customers?
- How can we make sure whatever we do is incredibly transparent to our customers?
While there were many, many other discussions that took place around ZTAP and our MDR service, it was these three questions that continued to guide our technical decisions. The way we applied these questions can be found in defining what a security system actually is: It’s a system that has intelligence, either centrally or in a distributed fashion, that takes a look at multiple security events and alerts and notifies the user based on predefined criteria. It can be either due to something as simple as watchlists or a higher order implementation using AI/ML technologies.
Based on this common understanding of what a security system is, we fundamentally believe that customers don’t have a lack of alerts problem, they have a resolution of alerts problem.
As a consequence of our problem definition, our ZTAP platform is built to:
- Ingest alerts generated by security systems.
- Investigate every single alert, supervised by a human.
- Ensure that day 1 our customers get value from all the previous work.
Defining the terminology
We support a fair number of best of breed partners in our platform. So, it’s probably helpful to define some terms here:
- Security Event – Something that happened on an endpoint, network, or firewall that is of interest to investigate further.
- Alert – An alert is a construct which is provided by most security systems. An alert is typically a consequence of one or more security events.
The magic of ZTAP
Let’s be clear here: There is no magic! Whether we or our customers investigate alerts, the cost per alert investigated is approximately the same. What differentiates us is that our knowledge is aggregated across all our customers allowing us to deliver on a decision we made early-on to investigate every alert exactly once.
What we believe is that there is a fairly common set of alerts that are consistent across multiple customers, and we can gain efficiency of scale using that commonality. What we found is somewhere around 80% of alerts across customers are common. There are 10% of alerts that are less common across all customers, but common across the customer industry/verticals. The final 10% left over is truly unique to that specific customer. This holds true even today based on our data set of about 6 billion+ security alerts.
We built our technology stack based on the problems and data outlined above, with most of our technology stack in Python and AWS. How it is architected was definitely a deliberate decision that can be broken into several parts.
The commonality of alerts
An example of the 80% category is CVE-2013-3906, available at https://nvd.nist.gov/vuln/detail/CVE-2013-3906.
The investigation/decision tree is fairly obvious when looking at the CVE and the Microsoft Security Bulletin: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-096
We support ingesting data into our platform through multiple mechanisms. The mechanism of ingestion is primarily driven by the system we are ingesting data from. This (and only this) part of our system is similar to a Security Information and Event Management (SIEM) system that may ingest the data for compliance or other purposes.
We ingest data using Syslog, Web-hooks, Polling, and various forms of queues. The primary difference, however, is the content of what we are ingesting. A SIEM or other system stops at ingesting data, but we are ingesting information. By the time something gets to our system, the sender (Carbon Black Response, Cylance, Microsoft Defender for Endpoint, Azure Sentinel, etc.) has already determined this data to be noteworthy and something that needs to be acted upon.
Assuming this alert is something we’ve never seen before and is entirely new, it’s going to be presented to our SOC analyst just exactly the same way that the sender would present the alert.
ZTAP is what our SOC analysts use to conduct investigations of an alert. In practice, this means any security event that is part of the alert is investigated. (Remember, the alert is a consequence of one or more events.) Due to our decision to investigate every single alert that is generated by a security system, we had to ensure:
- The events/alerts in ZTAP are “as similar as possible” to the original. We tend to keep this as-is for the most part, with as little “normalization” as possible.
- Since most of these alerts tend to generate questions in the analyst’s minds, we had to find a way to get answers to these questions quickly.
ZTAP provides something we call Threat Analytics Plugins (TAPs), which allow us to ask questions of the security system. In case of EDR, this may be as simple as “What is the Parent Process?” or “What are the network connections established by the process generating this alert?” or something similar.
Investigate from anywhere
Thanks to MOBILESOC, you can investigate alerts, receive updates from CRITICALSTART SOC analysts on their investigation and remediation efforts, and take direct action all from an app on your mobile device.
This is possible because of our decision to normalize the output of SIEM instead of normalizing the input as is most often done with these tools.
As part of investigation, the analyst has gone through a series of steps such as asking questions of the security system or a third-party system (Ex: VirusTotal). A very simplistic example of this could be something like:
- Is the instigating process Microsoft Word?
- Are all the network connections made by this instigating process going to “*.microsoft.com”; would this be considered normal?
- If yes, this is a perfectly safe, but previously unknown behavior of Microsoft Word.
The analyst captures these simple steps in what we call a Categorizing Playbook. These Playbooks are reviewed (two-person integrity) and applied. Once applied, these are forever run by ZTAP during event ingestion. They are also run historically for any alerts that are still “open” in the system.
And this is what we call the Trusted Behavior Registry.
All these Playbooks are audited for every change made from the beginning and are 100% transparent to our customers (which answers one of our founding questions above). They can see who and why a Playbook was created, as well as understand how many of their recent events are categorized.
Over a period of many years, and processing 6 Billion+ alerts, we have 70,000+ Trusted Behaviors in our system. Every single event passes through this system and well over 98% are categorized automatically. We continue to add to this 24x7x365. Remember another of our founding questions: How can we resolve every single alert by a limited set of security systems? Now, through this process, we have the right answer to the right question.
Time to value
And remember the question about time-to-value? This is what we’ve observed:
This technology stack leads to a brand-new customer receiving 80%+ of their events being investigated and resolved on day 1.
A new customer onboarding with us is now gaining a much deeper understanding of the specifics in their environment, including their critical assets, their domain administrators and more. We use Playbooks for this as well.
All the technology outlined above runs in the cloud. From a customer’s perspective this makes it incredibly easy to consume — delivering value on the first day. It’s not without its challenges, be it availability, integration testing, or throughput. We’ve been early adopters of DevOps practices, going back to 0.5.x of Terraform and early adopters of Docker as well. But this effort is well worth the investment, as when you start asking the right questions, and you build a platform around those questions, then the answer becomes a highly secure environment that evolves to match any new threat it faces.
- Are you considering a Managed Detection and Response Service as part of your overall security infrastructure? Learn how to deploy an MDR platform that can protect any business in the guide to Managed Detection and Response.
- Dive into Infosec Reborn, a new playbook to understand, adapt, and overcome in the hyper-sophisticated threat environment of today’s world.
- Looking for a career change? Join the revolution, CRITICALSTART is reinventing cybersecurity.
You may also be interested in…
- Consumer Education(40)
- Consumer Stories(2)
- Cybersecurity Consulting(7)
- Data Breaches(15)
- Data Privacy(43)
- Incident Response(2)
- MDR Services(70)
- Press Release(64)
- Research Report(10)
- Security Assessments(4)
- Thought Leadership(18)
- Threat Hunting(3)
- Vulnerability Disclosure(1)