LimaCharlie is lucky enough to be working with some of the most competent information security professionals in the business. We thought our users might be interested in reading their thoughts on the current state of infosec and how they manage their security operations. To this end we recently interview Soteria- Security Solutions & Advisory.
Introduce yourself and your company.
type: embedded-entry-inline id: 21Bpbux14lpM6D3hPpwwFB
My name is Brandon Poole. I am Soteria’s senior detection and response engineer, focusing on building out our Managed Detection and Response (MDR) and Incident Response capabilities.
Soteria is a cybersecurity advisory and managed services company serving that, among other things, provides an EDR-driven MDR service to customers who wish to improve their detection capabilities. Our MDR team is composed of experts across multiple areas of expertise including but not limited to incident responders, forensic examiners, detection engineers, threat intelligence analyst, and security engineers. This team with diverse backgrounds is responsible for creating our detection logic and our response capabilities.
What do you see as the biggest challenges facing the information security community over the next few years?
I think the biggest challenge is not really one thing but the combination of multiple smaller issues. I believe that the COVID-19 pandemic has forced many companies to adopt a remote workforce, rendering many IT solutions and security controls built on the assumption of a workforce working from the corporate network, useless. This has also led to the massive adoption of SaaS offerings and the utilization of newer cloud technologies like Kubernetes and serverless functions. This creates an interesting challenge because many of these solutions lack strong visibility to what is occurring and the attack surface is not as well researched. When you combine this with increasingly aggressive and well-funded adversaries, our ability to detect and prevent incidents becomes much more problematic.
Another big challenge is the rapidly increasing use of .NET in tooling and tradecraft. The use of Powershell in attacks is still relatively high. Still, it has quickly been dropping off due to more organizations leveraging constrained language mode, Powershell logging, Just Enough Admin, and the use of security tools leveraging AMSI. Many researchers and red teams have started building tooling in .NET, which offers the same capabilities as Powershell but with nowhere near the visibility and controls to prevent its abuse. Tools such as Seatbelt, Safetykatz, and SharpSploit are rising both with adversarial groups and red teams.
Without giving away any secret sauce, what kind of mitigation strategies do you think are the best way to handle these challenges?
As for the first challenge, I don’t think there is really mitigation at this time. SaaS platforms will add better logging as they are exploited and abused (case in point, Microsoft is working on better logging in Azure after the Golden SAML attack recently). LimaCharlie added the ability to run in containers last year to gain visibility. There are also many new products using eBPF filters to generate fantastic telemetry with containers and Kubernetes environments. When we get to serverless functions, you will have to build logging in or rely on application performance monitoring. I would not be surprised to see runtime application self-protection (RASP) products make a strong comeback in the serverless space, either.
As for .NET tradecraft, the languages using .NET, mainly C#, are all intermediate languages, meaning they get compiled to bytecode much like Java and then make use of the Common Language Runtime (CLR) to execute. We have started to research and fingerprint applications loading the CLR dll and combined that with execution proxies found in the .NET post-exploitation frameworks (e.g., mshta) and have found that to offer a decent capability for detection so far.
How did you first hear about LimaCharlie and what was your initial reaction to the concept of Security Infrastructure as a Service?
We first heard about LimaCharlie when it was an open source project. We had heard very positive reviews about the tool in the infosec community, and had planned to spend some time tinkering with it to see if it would help solve some of our clients’ issues. Eventually, we decided to start a Managed Detection and Response (MDR) offering, and discovered that LimaCharlie had launched into a company, and we were immediately interested in exploring what they had to offer. _ _
You recently wrote a brilliant white paper on ‘ Detectors as Code’ that advocates for a continuous integration (CI) style approach to detections - was there a particular moment when this approach became apparent or has it been an evolving concept?
Detection engineering is a relatively new discipline that has come about due to the rapid expansion of customizable detection tools and platforms. Malicious actors and offensive security professionals can use research and open-source/low-cost tooling to rapidly deploy and evade preventive controls. We knew that in building out our own detection engineering program to support the MDR service, we would need to provide detection capability in an equally rapid fashion while ensuring we had a way to quickly update and test as the threat landscape continued to evolve. When we started to analyze how to accomplish this, we noticed a massive crossover with software engineering, specifically DevOps. We adopted what made sense and could be applied to the discipline of detection engineering, and in doing so, we were able to accomplish amazing things. We were able to use version control to track a detector's evolution and quickly roll back to an older version if a change caused issues, use a CI/CD pipeline to perform continuous testing of rules that are tuned to ensure we aren't causing new false negatives or increasing false positives, and adopting the philosophy of multiple small pushes so we could have detection coverage to our clients sooner. This has been a major key in our success so far as a MDR provider.
You have incorporated LimaCharlie’s endpoint agent and API as part of your Lexico MDR offering. Can you tell us about this service and what kind of role LimaCharlie’s technology plays in it?
In today’s climate, log data doesn’t cut it for detecting most attacks. If you were to map the techniques in MITRE’s ATT&CK framework to data types, roughly 80% require process creation and command line data. Modern EDR solutions provide this data plus other data types while also providing a ton more context than what can be extracted from most logs and SIEM tools. When you pair this with the response capabilities available from a console, EDR reigns king. The problem is that even with the rich telemetry and capabilities offered by modern EDR solutions, organizations struggle to extract value. It takes highly trained experts to understand the nuances of different processes and operating systems and understand normal behavior. When you pair the training, cost of the team, cost of the tool, and current demand with the fact that there is a shortage of folks with this knowledge and skill with EDR solutions, the ROI is low.
Our MDR service is built around providing an EDR solution and personnel to extract that value but doing so in a scalable way. We use LimaCharlie to create an abstraction layer for our customers, allowing us to group related detections into a single incident and present it to the user along with our analysis and recommended next steps. This allows them to quickly get the information they need from both Soteria and LimaCharlie without logging into multiple platforms or having to understand how to interpret EDR telemetry. For the highly technical customers who wish to have direct access to the LimaCharlie interface, we can easily provide that as well. In these situations, LimaCharlie allows us to provide direct access to the interface safely while preventing disruption of our workflows.
We also leverage LimaCharlie’s APIs heavily as we find they have a ton of capability to automate tasks and scale in such a way to offer an even better ROI. The API was a big part in implementing our Detector as Code methodology and has been huge during our incident response engagements, as this allows us to automate many of our incident response activities in a way that scales with the victim’s environment.
The Soteria team has built and sells a product in the LimaCharlie Marketplace - Tell us a bit about the product and why you think others can benefit from using it?
Soteria believes the strength and critical differentiation of its MDR offering are our team’s expertise and our detectors’ quality. While we have been able to build a detection engineering practice from scratch, many others cannot create such a program. It is a new discipline, making it difficult to leverage all of the powerful capabilities that LimaCharlie offers. In talking with the LimaCharlie team, we found that many customers were interested in LimaCharlie, but did not want to hire a full-service MDR provider to build their detection capabilities. Soteria partnered with LimaCharlie to offer a subscription-based service that provides access to Soteria’s behavioral detectors to fill this gap. These are the same rules we use in our MDR service and incident response engagements. There are currently over 450 rules, providing coverage across multiple operating systems and MITRE ATT&CK techniques. Our ruleset is created using a detection strategy and methodology that allows for one of the most robust rulesets out there.
Our detection strategy is based on a few different concepts. The first concept is related to David Bianco’s excellent Pyramid of Pain article. Far too many in the industry focus on detection capabilities around the bottom half of the Pyramid of Pain, leading to brittle detection capabilities that are easy to bypass. We focus on behavior-based detectors at the top half of the pyramid, specifically on tactics, techniques, and procedures (TTPs). While this does lead to an increase in false-positive rates, it allows for more robust detection logic and makes successful attacks much more expensive for attackers to carry out.
Our second concept is breaking up our detectors on TTPs used throughout the attack lifecycle. One of the biggest myths that still permeates in the industry is that defenders have to get everything right all the time to succeed, while an attacker just has to be right once to succeed. We understand all attackers are after some objective. Whether that objective is ransoming an environment or disrupting a service for hacktivism, specific steps have to be accomplished to carry out the mission. Each step provides a detection opportunity meaning attackers have to blindly choose the right tactic every phase of the attack life cycle to avoid creating an alarm and be expelled from the environment.
The last concept is breaking down detectors into small overlapping parts. As we stated in the first concept, we embrace false positives to achieve a less brittle detection capability. By breaking down our detectors so that they are narrowly focused and overlap with other detectors, we can aggressively tune without introducing too many false negatives. An example of this is the use of Powershell. Powershell post-exploitation frameworks, such as Empire and Nishang, are super popular due to Powershell’s outstanding capabilities and the lack of security controls implemented around Powershell. Making an alert to detect any Powershell activity would generate too many false positives, so we hone in on more specific uses on Powershell like harnesses and cradles. Even this can be broken down into different parts. You might choose to make one detector to fire if a URL appears in the command line, another that focuses on the creation of a Net.Webclient or COM object, and the last detector may focus on the use of the Invoke-Expression alias, IEX. Each of these parts is found in any harness or cradle, but by breaking it apart, we can tune each rule independently without fear of overturning and missing a detection event.
This offering allows LimaCharlie users to quickly leverage the platform’s EDR capabilities without hiring a team of detection engineers and spending months or years building, testing and deploying detection logic while leveraging our expertise and detection methodology. The outcome we hope to achieve is to reduce the information security poverty line and allow organizations to detect more attacks earlier that may have otherwise led to a massive incident.
Do you have any advice for smaller MSSP’s out there trying to navigate e ever changing landscape of security tools and techniques?
My advice would be to focus on areas where you can provide the greatest value to your client. It is common for smaller businesses to try to be everything for their clients, but this can lead to them overextending in areas and providing a false sense of security to their customers.
Top comments (0)