One of the ways we work with our partner community is by providing managed services to end users. And as is the case with just about any deployment scenario, every environment has its own set of configurations, requirements—and sometimes even challenges. With that in mind, we thought we’d cover a few of the common challenges we’ve come across in an effort to hopefully help you along your way.
But first, let’s take a look at the list of challenges below. Are any of these issues something you recognize in your Security Operations Center (SOC) today?
- High cost of ownership: this involves the cost of Security Information and Event Management (SIEM) use case creation and maintenance staff attrition in tier-1 and tier-2 analyst roles with constant rehiring and training that all leads to increased costs
- Security inefficiencies: difficulty gaining 100% log and use case coverage either due to log-ingestion costs, technical and operational challenges or a limited ability to perform forensic analysis of an incident progression
- Alert fatigue: the logs or traditional signature-based systems are generating too many alerts, too many false-positives or both, and / or difficulty discovering and understanding the context of the alerts
If you answered yes to any of the challenges, you’re in the right place.
The SOC 1.0
The SOC 1.0, or the SIEM SOC was the first evolution in building a security monitoring capability in an organization. The idea with SOC 1.0 is simply to collect all the logs from the firewalls, proxies, authentication servers, applications and workstations—basically from anything that will allow it. Once that is done, you aggregate them in a SIEM platform, where the data can be easily queried and correlated, and further ingest indicators of compromise (IoC)s or threat intel that can be matched against the log data.
This is when the fun starts and you would begin to embark on a journey of building queries or use cases to find malicious or risky actions within all the data. Typically, you would start thinking about how to create alerts when certain events, combinations of events or thresholds are exceeded, so that analysts are able to respond to the alerts and use the SIEM along with other tools and resources to investigate the events. This would ideally be set up in a siloed fashion—meaning they have to go from console to console, tool to tool to try and manually triangulate the alerts to figure out what is happening. In general, this approach has a lot of merits and is seen today as the de facto standard and foundational capability in many SOCs—for both large and small organizations, however, there are some fundamental problems.
The common scenario in many SOC 1.0 environments, includes:
- Adequate logs are not available
- Logs don’t contain enough data to perform adequate threat detection
- It is costly to build and maintain the use cases or rules for detection
- The cost to store logs in a SIEM is becoming a major issue for customers
- The query rule and statistical analysis based approach isn’t powerful enough to detect stealthy attackers
- The SOC gets overloaded with alerts, most of them being false-positive detections
- The SOC analysts have a hard time gaining enough information about the context of the alert, and the alert triaging requires a lot of manual work to investigate
Consequently, there is large number of job openings for cyber analysts, developers and incident responders due to the high volume of work in SOCs as well as the fact that the job itself in SOC 1.0 is sometimes mundane and unrewarding—resulting in a high churn of resources. The costs in running a 1.0 SOC is creeping up, while the attack surface that needs to be protected against is steadily growing in the post COVID-19 reality. At the same time, cybercrime is on the rise, attackers are becoming more sophisticated, attacks are very specific, stealthy and customized to the target organization.
Introducing SOC 2.0
Due to the challenges with the SOC 1.0 approach, many organizations are transforming their SOC operations to SOC 2.0. The SOC 2.0 approach is more affordable to run, less reliant on large numbers of people, detects attacks faster, introduces automation along with new analytical techniques, and is ready for the battle against never-before-seen attacks.
The key changes in transforming the SOC operations are highlighted, here:
So, does this mean SIEM is becoming obsolete? No, SIEM and log-based analytics are still a key tenant. The shift to SOC 2.0 uses SIEM for what it is best suited for—detecting known risks that can easily be articulated in query rules. An example of this could be the impossible travel, where we are matching geographical distance between log in locations within a time frame. This is a scenario where a use case can readily be created and authentication server logs are readily available. In SOC 2.0, the SIEM is assuming the role of a single-pane-of-glass that is fed with pre-analyzed score detections from endpoint detection and response (EDR), network detection and response (NDR) and user and entity behavior analytics (UEBA) sources.
For detection objectives, where the log coverage is clearly not in place and more related to recognizing the nuanced patterns in user and application behavior, SOC 2.0 leverages machine learning along with network and end point data. Imagine trying to create a traditional software program or rule to distinguish and sort pictures. This is not really feasible, however, with a basic machine learning model, the pattern recognition becomes a trivial activity. The same goes for analyzing attacker patterns in the network, cloud, SaaS or for applications. Machine Learning models can be trained to distinguish the malicious patterns from the benign application and network traffic. The beauty of machine learning is that once the model is created, the algorithm trains itself to start performing the detection work—this means that machine learning solutions require little or no tuning and customization to start performing tasks.
With SOC 2.0, the AI algorithms are enriching the context of the detections, while correlating and scoring the detections. The role of the SOC analyst is elevated to work on the prioritized incidents, where they can quickly apply knowledge and experience, as well as forensic skills to build a timeline and case for triaging specific noticed behaviors while providing guidance to the response team to take action. All of this allows the organization to rethink what to ingest since all detections are not log based. Additionally, EDR and NDR solutions will provide the prioritized alert detections to the SIEM rather than just raw data.
The SOC 2.0 doesn’t rely on IDS systems any longer—threat intel data (IPs, Domains) are analyzed in the NDR solution. Firewalls are applying rules in flight. Antivirus and email protection takes care of applying signatures to files and payloads. Attackers tend to encrypt their data in transit, so applying signatures on network traffic makes less and less sense. Lastly, as automation is applied to the incident response and when a threat detection is either automatically or manually deemed to be true and serious—security orchestration, automation and response (SOAR) platforms can take over to perform the actions needed to stop the progression of attacks according to set play books.
Looking ahead
While SOC 1.0 is still the norm in many organizations—more and more are embracing the SOC 2.0 approach. Vectra plays a key role in the SOC visibility triad as the data from the new network consisting of IaaS, SaaS and on-prem services doesn’t lie. Machine learning and AI greatly enhance the automation level and speeds up the organization’s ability to stop attacks before they become breaches.
See how Vectra can help you elevate your SOC visibility or start by scheduling a demo.