The Science of Detection Part 2: The Role of Integrated Reasoning in Security Analysis Software

Today’s blog is part two in my science of detection series, and we’ll look at how integrated reasoning in security analysis software leads to better decisions. Be sure to check back in the coming weeks to see the next blogs in our series. In part three, I’ll be taking an in-depth look at the signal quality of detectors, such as signatures, anomalies, behaviors, and logs.

If you’ve been reading our blogs lately, you’ve seen the term “integrated reasoning” used before, so it’s time to give you a deeper explanation of what it means. Integrated reasoning combines multiple sensors and sensor types for analysis and better detection. Before making a security decision, you must take into account a large number of different factors simultaneously.

What Is Integrated Reasoning?

Interestingly, when we started using the term, Julie from our marketing team Googled it and pointed out that it was the name of a new test section introduced in the Graduate Management Admission Test (GMAT) in 2012. What the GMAT section is designed to test in potential MBA candidates is exactly what we mean when we refer to integrated reasoning. It consists of the following skills:

  • Two-part analysis: The ability to identify multiple answers as most correct.
  • Multi-source reasoning: The ability to reason from multiple sources and types of information.
  • Graphic interpretation: The ability to interpret statistical distributions and other graphical information.
  • Table analysis: The ability to interpret tabular information such as patterns or historical data and to understand how useful distinct information is to a given decision.

All of these skills provide a combination of perspectives that allow you to reason and reach a well thought out and accurate conclusion. The same reason we are evaluating our potential MBA candidates against this standard is why we would design to this standard for security analysis software, or if you will, a “virtual” security analyst.

What is an MBA graduate but a decision maker? Fortunately, we are training our future business leaders on integrated reasoning skills, but when the number of factors to be considered increases, humans get worse at making decisions — especially when they need to be made rapidly. Whether from lack of attention, lack of time, bias or a myriad of other reasons, people don’t make rational decisions most of the time.

However, when you’re reasoning and using all of the available information in a systematic manner, you have a much greater chance of identifying the best answer. To put this within a security analysis frame of reference, let’s consider some of the information available to us to make effective security decisions.

What Information Should We Consider?

The most effective security analysis software uses anything that is observable within the environment and reduces the uncertainty that any one event should be investigated.

To achieve integrated reasoning, the software should utilize a combination of detectors, including:

  • Signature-based alerts
  • Detection analytics
  • Behaviors
  • Patterns
  • History
  • Threat intelligence
  • Additional contextual information

In order to make the right decisions, security analysis software should take into account three important factors: sensors, perspective and context. When you combine different forms of security telemetry, like network security sensors and host-based sensors, you have a greater chance of detecting maliciousness. Then, if you deliberately overlap that diverse suite of sensors, you now have a form of logical triangulation. Then add context, and you can understand the importance of each alert. Boom, a good decision!

Like our theoretical MBA candidate, security analysts have to hold hundreds of relevant factors in their minds simultaneously and are charged with making a number of critical decisions every hour. A tall order for a mere mortal, indeed.

Imagine this: A user receives a phishing email, clicks on the link a week later and is infected by malware. The system anti-virus reports “cleaned” but only found 1 of 4 pieces of malware installed. The remaining malware communicates to a command-and-control server and is used as an internal waypoint for lateral exploration very low and slow. This generates thousands of events over a period of weeks or months, but all of them have varying levels of fidelity. More likely, this is the backstory that an incident responder would eventually assemble potentially months — or years — after the fact to explain a breach.

Integrated Reasoning is a must for making sound decisions when it comes to deciding which security alerts to escalate for further examination. But with the amount of incoming data increasing by the minute, security teams are having a hard time keeping up. Your best bet is to choose security analysis software, like the Respond Analyst, that has built-in integrated reasoning capabilities to help with decision-making, so teams can focus on highly likely security incidents.

Curious to see how the Respond Analyst’s integrated reasoning capabilities can help your security team make better decisions? Request a demo today.

The Science of Detection Part 1: 5 Essential Elements of a Data Source

I’m passionate about the science of detection. It used to be a black art, like long distance high-frequency radio communication, but with modern cybersecurity technology, we’re putting the science back in. With that in mind, I plan to write a series of blogs about the science of detection with an aim to enable more effective and rapid identification of “maliciousness” in our enterprise technology.

In today’s blog, we’ll look at the key elements of a data source to ensure effective detection. Be sure to check back in the coming weeks to see the next blogs in the series. In parts two and three, I’ll be taking an in-depth look at how integrated reasoning will fundamentally change detection technology and the signal quality of detectors, such as signatures, anomalies, behaviors and logs.

In operational security, we monitor various pieces of technology in our network for hackers and malware. We look at logs and specialized security sensors, and we use context and intelligence to try to identify the “bad guys” from the noise. Often, a lot of this work is “best effort” since we’re collecting data from other technology teams who are only using it to troubleshoot performance, capacity and availability issues — not security. It can be a challenge to configure these sources to make them specific to the needs of security, and this greatly complicates our success rate.

When we look at the data sources or telemetries that we monitor, there are five elements that are important for their effectiveness in detecting malicious activity.

1. Visibility

Visibility is one of the most important elements of a data source. What can you see? Is this a network sensor? Are you decrypting traffic so that you can see the patterns or signatures of an attack? Or is this a system log source where stealthy user or administrator behaviors can be captured? When you’re considering visibility, there are two things that are key: the location of the sensor and the tuning of the events, alerts or logs that it generates. For signature-based data sources, it’s tremendously important that you keep them up to date consistently and tuned for maximum signal.

2. Signal Quality

We look at signal quality to help determine the likelihood that any given signature or alarm will reliably indicate the presence of malicious activity. When you consider network intrusion detection and prevention sensors, things get really complicated. I have seen the same IDS signature alarm between different hosts in one day where one instance was a false-positive, and the other instance was malicious. How are we supposed to separate those two out? Not without deep analysis that considers many additional factors.

3. Architecture

With the advent of autonomous analysis and integrated reasoning, the architecture of your sensor grid can provide significant advantages. The most important is sensor overlap, which means different types of sensors should be implemented in the infrastructure so that attackers must get past more than one detection point.

A good example would be host-based endpoint protection agents in a user environment. By forcing users to then transit a network intrusion detection sensor and maybe even a URL filter in order to conduct business on the internet, you end up with three perspectives and three chances to recognize systems that are behaving maliciously. This means it’s important to deploy internal (East – West) network sensors to corroborate your other sensing platforms in order to reduce false positives and produce high fidelity incidents. You can fool me once, but fooling me twice or a third time gets much harder.

4. Data Management

All of our sensors should be easy to aggregate into a single data platform using common log transport methods. This can be a SIEM or a big data platform. It’s also tremendously important to capture all of the fields that can help us contextualize and understand the alerts we’ve observed. This data platform becomes the incident response and forensic repository for root cause analysis and is a good hunting ground for a hunt team.

5. Event Alignment

Given the complex nature of the modern enterprise, it’s possible for a user’s laptop to have 10 or 15 different IP addresses in any given day. We need to be able to reassemble that information to find the host that’s infected. A good example would be to collect hostname rather than just IP address,where it’s available. Proxies, firewalls and NAT devices can all effectively blind you when looking for malicious internal hosts. In fact, one Security Operations Center I built could not locate 50% of known compromised assets due to a combination of network design and geography.

A combination of perspectives provides the most effective sensor grid. Leveraging multiple forms of visibility, improving the signal quality of your sources, architecting for sensor overlap and key detection chokepoints, and streaming all of this data into an effective big data management system where it can be analyzed and leveraged across the operational security lifecycle can provide a far more effective security operations capability.

How the Respond Analyst Can Help You

The Respond Analyst is able to understand these telemetries and contextual data sources and considers all factors in real-time. This frees you from monitoring a console of alerts, which allows you to focus on higher-value work. It also frees your detection programs from the volume limitations of human monitoring. Putting all of these elements together provides a massive improvement in your ability to detect intruders before they can do major damage to your enterprise technology. We’re putting machines in front of alerts so that humans can focus on situations.

Mid-sized Enterprises: Want Robust, Sustainable SecOps? Remember 3 C’s

Cybersecurity is tricky business for the mid-sized enterprise.

Attacks targeting mid-sized companies are on the rise, but their security teams are generally resource constrained and have a tough time covering all the potential threats.

There are solutions that provide sustainable security infrastructures but the vendor landscape is confusing and difficult to navigate. With smaller teams and more than 1,200 cybersecurity vendors in the market, it’s no wonder mid-sized enterprise IT departments often stick with “status quo” solutions that provide bare-minimum coverage. The IT leaders I talk to, secretly tell me they know bare-bones security is a calculated risk but often executive support for resources is just not there.  These are tradeoffs that smaller security teams should not have to make.

Here’s the good news.  Building a solid enterprise-scale security program without tradeoffs is possible. To get started IT leaders should consider the 3 C’s of a sustainable security infrastructure: Coverage, Context, and Cost.

In part 1 of this 3-part blog series, we will deep-dive into the first “C”: Coverage.

When thinking about coverage, there are two challenges to overcome. The first challenge is to achieve broad visibility into your sensors. There is a wide array of security sensors and it’s easy to get overwhelmed by the avalanche of data they generate. Customers often ask me: Do we have to monitor everything? Where do I begin? Are certain sensor alerts better indications of compromise than others?

Take the first step: Achieve visibility with appropriate sensor coverage

To minimize blind spots, start by achieving basic 24 x 7 coverage with continuous monitoring of Network Intrusion Detection & Prevention (NIDS/NIPS) and Endpoint Protection Platform (EPP) activity. NIDS/NIPS solutions leverage signatures to detect a wide variety of threats within your network, alerting on unauthorized inbound, lateral, and outbound network communications. Vendors like Palo Alto Networks, TrendMicro and Cisco have solid solutions. Suricata and Snort are two popular open-source alternatives. EPP solutions (Symantec, McAfee, Microsoft) also leverage signatures to detect a variety of threats (e.g. Trojans, Ransomware, Spyware, etc) and their alerts are strong indicators of known malware infections.

Both NIDS/NIPS and EPP technologies use signatures to detect threats and provide broad coverage of a variety of attacks, however, they do not cover everything.  To learn more on this topic read our eBook: 5 Ingredients to Help your Security Team Perform at Enterprise-Scale

To gain deeper visibility IT departments can eventually start to pursue advanced coverage.

With advanced coverage, IT teams can augment basic 24 x 7 data sensor coverage by monitoring web proxy, URL filtering, and/or endpoint detection and response (EDR). These augmented data sources offer opportunities to gain deeper visibility into previously unknown attacks because they report on raw activity and do not rely on attack signatures like NIDS/NIPS and EPP. Web proxy and URL filtering solutions log all internal web browsing activity, and as a result, provides in-depth visibility into one of the most commonly exploited channels that attackers use to compromise internal systems. In addition, EDR solutions act as a DVR on the system, recording every operation performed by the operating system—including all operations initiated by adversaries or malware. Of course, the hurdle to overcome with these advanced coverage solutions is managing the vast amounts of data they produce.

This leads to the second coverage challenge to overcome—obtaining the required expertise and capacity necessary to analyze the mountains of data generated.

As sensor coverage grows, more data is generated with each sensor type, creating data with unique challenges. Some sensors are extremely noisy and generate massive amounts of data. Others generate less data but are highly specialized and require a great deal more skill to analyze. To deal with the volume of data, common approaches are to ‘tune down’ sensors (which literally filters out potentially valuable data). This type of filtering is tempting since it essentially reduces the workload of a security team to a more manageable level. In doing so, however, clues to potential threats stay hidden in the data.

Take the second step: Consider security automation to improve coverage with resource-constrained teams.

Automation effectively offers smaller security teams the same capability that a full-scale Security Operations Center (SOC) team provides a larger organization, at a fraction of the investment and hassle.

Automation improves the status quo and stops the tradeoffs that IT organizations make every day. Smaller teams benefit with advanced security operations. Manual monitoring stops. Teams can keep up with the volume of data and can ensure that the analysis of each and every event is thorough and consistent. Security automation also provides continuous and effective network security monitoring and reduces time to respond. Alert collection, analysis, prioritization, and event escalation decisions can be fully or partially automated.

So to close, more Coverage for smaller security teams is, in fact, possible: First, find the right tools to gain more visibility across the network and endpoints. Second, start to think about solutions that automate the expert analysis of the data that increased visibility produces.

But, remember, ‘Coverage’ is just 1 part of this 3-part puzzle. Be sure to check back next month for part 2 of my 3 C’s (Coverage, Context, Cost) blog series. My blog on “Context” will provide a deeper dive into automation and will demonstrate how mid-sized enterprise organizations can gain more insights from their security data—ultimately finding more credible threats.

In the meantime, please reach out if you’d like to talk to one of our Security Architect to discuss coverage in your environment.

Algorithmic Stealth and the Security Arms Race

I recently visited Norwich University, the oldest private military college in America and an NSA & DHS Center of Academic Excellence for Cyber Defense. I had the opportunity to speak with some of the students in their Computer Security and Information Assurance program, and I was asked a question by Keely Eubank about the ability of attackers to leverage stealth techniques to hide from algorithms. It was a very insightful question and it got me thinking about the topic of “Algorithmic Stealth.”

Information Security has always been an arms race. Getting around more advanced cyber-defenses has always required stealth techniques. For example, I remember the days when almost every attack happened on Friday afternoon around 3:00pm before a 3-day weekend because the system administration team was having Friday beers and wouldn’t be back to work before Tuesday. Plenty of time to break in, steal what you were after and then clean up before they got back to work. My pager (yeah that’s old school) went off every 3-day weekend for years.

Eventually the bad guys took a statistics course and realized that defenders had a real challenge with volume, so they switched their loudest attacks to Wednesday at 10:00am. That is weekly peak network traffic and they realized it was easier to hide in all that noise than the quiet of the weekend. Once we were able to suppress some of the noise they moved to a “living off the land” model so that they looked like regular administrators and used tools that were natural to the environment. Tools like TeamViewer and Powershell were particular favorites. They were both hiding in the noise AND not introducing new binaries into the environment, so they were that much harder to detect.

Now that advanced math and algorithms are becoming the detection methods of choice, there is an inevitable progression for attackers to research techniques for “algorithmic stealth.” Luckily for us there are lots of approaches to math-based detection being developed at the moment. Each of these would need to be specifically defeated and thus a combination of them would be incredibly difficult to completely circumvent. When machines do security monitoring human behavior, bias and decision making can no longer be the main thrust of stealth technique development. They have to hide from the algorithms.

This means a couple of things for us defenders. Basic anomaly detection is the weakest of the modern approaches as it suffers from the same signal-to-noise ratio problem that traditional signature detection methods do. The modern enterprise is full of anomalies due to the complex and poorly coordinated way our enterprise technology is cobbled together. However, signatures and anomalies can both reduce uncertainty by some amount and that is still valuable. The optimal detection operation will “see“ simultaneously in multiple telemetries; use the analogy of visible light, infrared, thermal, radio wave, etc… AND leverage diverse mathematical methods that provide a Venn diagram of opportunities to recognize malicious activity. All phases of an attack can be targeted for detection differently. At Respond Software we call this Integrated Reasoning.

I’d like to thank Norwich University’s Applied Research Institute (NUARI) and the Norwich faculty for the chance to learn something cool from their amazing students. As we develop new tools and techniques to defend our organizations, I am reminded that our very depth of experience (in the status quo) can blind us to new approaches and listening closely to the questions of the next generation of defenders can open new avenues of defensive research. Understanding and defeating algorithmic stealth is a new frontier for security research and active defense. Welcome to AI in Security, I think you knew it wouldn’t be all fun.

How Automating Long Tail Analysis Helps Security Incident Response

Today’s modern cybersecurity solutions must scale to unparalleled levels due to constantly expanding attack surfaces resulting in enormous volumes of diverse data to be processed. Scale issues have migrated from just the sheer volume of traffic, such as IOT led DDoS attacks and the traffic from multiple devices, to the need for absolute speed in identifying and catching the bad guys.

Long tail analysis is narrowed down to looking for very weak signals from attackers who are technologically savvy enough to stay under your radar and remain undetected.

But, what’s the most efficient and best way to accomplish what can be a time-consuming and a highly repetitive tasks?

What is Long Tail Analysis?

You might be wondering what the theory is behind long tail analysis, even though you’re familiar with the term and could already be performing these actions frequently in your security environment.  The term Long Tail first emerged in 2004 and was created by Wired editor-in-chief, Chris Anderson to describe “the new marketplace.” His theory is that our culture and economy is increasingly shifting away from a focus on a relatively small number of “hits” (mainstream products and markets) at the head of the demand curve and toward a huge number of niches in the tail.

In a nutshell and from a visual standpoint, this is how we explain long tail analysis in cybersecurity:  You’re threat hunting for those least common events that will be the most useful in understanding anomalous behaviour in your environments.

Finding Needles in Stacks of Needles

Consider the mountains of data generated from all your security sources. It’s extremely challenging to extract weak signals while avoiding all the false positives. Our attempt to resolve this challenge is to provide analysts with banks of monitors displaying different dashboards they need to be familiar with in order to detect malicious patterns.  As you know, this doesn’t scale.  We cannot expect a person to react to these dashboards consistently.  Nor do we expect them to “do all the things”.

Instead, experienced analysts enjoy digging into the data.  They’ll pivot into one of the many security solutions used to combat cybersecurity threats such as log management solutions, packet analysis platforms, and even some endpoint agents all designed to record and playback a historical record.  We break down common behaviours looking for those outliers.  We zero in on these ‘niche’ activities and understand them one at a time. Unfortunately, we can’t always get to each permutation and they are left unresolved.

Four Long Steps of Long Tail Analysis in the SOC

If you are unfamiliar with long tail analysis, here are 4 steps of how a typical analyst will work through it:

Step 1: First, you identify events of interest like a user authentication or web site connections.  Then, you determine how to aggregate the events in a way that provides enough meaning for analysis. Example:  Graph user account by the number of authentication events or web domains by the number of connections.

Step 2: Once the aggregated data is grouped together, the distribution might be skewed in a particular direction with a long tail either to the left or right.  You might be particularly interested in the objects that fall within that long tail.  These are the objects that are extracted, in table format, for further analysis.

Step 3: For each object, you investigate as required. For authentications, you would look at the account owner, the number of authentication events, the purpose of the account.  All with the intended goal of understanding why that specific behaviour is occurring.

Step 4: You then decide what actions to take and move on to the next object.  Typically, the next steps include working with incident responders or your IT team.  Alternatively, you might decide to simply ignore the event and repeat Step 3 with the next object.

Is There a Better Solution?

At Respond Software, we’re confident that long tail analysis can be automated to make your team more efficient at threat hunting. As we continue to build Respond Analyst modules, we move closer to delivering on that promise — and dramatically improve your ability to defend your business.

4 Reasons Your MSSP Might Not Be Providing Dependable Security Monitoring

Unless your goal with your Managed Security Service Provider to simply check your audit requirement box, you are likely not getting the dependable security monitoring you are looking for.

Reason #1 – One Size Doesn’t Fit All
The first reason is the general “one size fits all/most” model that MSSP’s are forced to work in so they can make a profit. My introduction to the one size fits all/most model goes back to when I started in cybersecurity and worked for a large Tier-1 MSSP. We applied “recommended signature sets” to provide higher fidelity alerting as somewhat of a self-serving tale told by MSSPs to justify the event funnel where events are filtered out and never presented to an analyst for analysis. While this helps keep super noisy signatures from coming to the console (who would have the time to weed thru them to find the needle in that haystack?) it also creates a significant visibility gap. The event funnel also helped keep our SIEM from tipping over.

Filtering is something we as an industry have unfortunately come to accept as the solution to address the exponential problem of data growth and lack of skilled analysts. This is mainly due to technology and human limitations. This is where expert systems, AI and ML can be a big help.

Reason #2 – False Positive Headaches
How many times have you been woken up at 2:00 AM by your MSSP for an escalation that turned out to be a false positive? Consider how many hours you have spent chasing down an escalation that was nothing. When an escalation comes in from your MSSP do you jump right up knowing there is a very high probability this escalation is malicious and actionable, or do you finish your lunch believing it will likely be another waste of time? Chasing down false positives is not only a drain on time and resources, but they are also an emotional drain for the security Incident Responders. People want to do work that adds value; expending cycles and finding out it was a waste of time is disappointing. I have yet to come across any organization that is ok with the level of false escalations from their MSSP.

Reason #3 – Generic Analysis
The third reason your MSSP might not be providing the value you need is because the MSSP analysts are not focused solely on your business. With a typical MSSP, you get a general set of SIEM intrusion detection content (e.g. correlation rules, queries) that is built to address a very generalized set of use cases that can apply to most, if not all, customers. If you want custom detection content, your only option has generally been to pay for a managed SIEM dedicated to you. You may be sending logs from a set of data sources to your MSSP, but do they have the proper detection content to evaluate those logs? In my years of SOC consulting, I have had an insider view of some of the detection content being used MSSP’s – my impression was that the content was generalized and basic. There was no cross-telemetry correlation to speak of, and very little content that could be considered advanced or line of business focused. Without this level of visibility, I question how dependable the analysis results will be.

Reason #4 – Tribal Knowledge
The challenge of knowing all the subtle nuances of your enterprise is something an MSSP will never achieve. Understanding account types and which assets are more critical than others is unique to each enterprise. And this information changes overtime. How is an outsider that may have dozens or even several hundred other customers supposed to know the nuances of your users, systems, or specific business practices, etc? There is a myriad of unwritten knowledge that is necessary to be able to effectively monitor and accurately decide which security events are worthy of escalating for response, and MSSPs often times do not have the company context to make good decisions for their customers.

If you are outsourcing your security monitoring or considering it to reduce cost or add capacity, take a look at Respond Analyst. You can manage your own Security Monitoring and Triage program with our pre-built expert decision system – no staffing required. Respond Analyst is like having your own team of Security Analysts working for you, 24×7 regardless of your company size or maturity.

Ripping off the Bandage: How AI is Changing the SOC Maturity Model

The introduction of virtual analysts, artificial intelligence and other advanced technologies into the Security Operations Center (SOC) is changing how we should think about maturity models. AI is replacing traditional human tasks, and when those tasks are automated the code effectively becomes the procedure. Is that a -1 or a +10 for security operations? Let’s discuss that.

To see the big picture here, we should review what a maturity model is and why we are using them for formal security operations. A maturity model is a process methodology that drives good documentation, repeatability, metrics and continuous improvement. The assumption being that these are a proxy for effectiveness and efficiency. The most common model used in Security Operations is a variant of the Carnegie Mellon, Capability Maturity Model for Integration (CMMI). Many process methods focus on defect management, this is even more evident in the CMMI since it originated in the software industry.

In the early 2000’s, we started using CMMI at IBM, Big Blue insisted that we couldn’t offer a commercial service that wasn’t on a maturity path and they had adopted CMMI across the entire company at that point. We had, at that time, what seemed like a never-ending series of failures in our security monitoring services, and for each failure a new “bandage” in the form of a process or procedure was applied. After a few years we had an enormous list of processes and procedures, each connected to the other in a PERT chart of SOC formality. Most of these “bandages” were intended to provide guidance and support to analysts as they conducted security monitoring and to prevent predictable failures, so we could offer a consistent and repeatable service across shifts and customers.

To understand this better, let’s look at the 5 levels of the CMMI model:

  1. Initial (ad hoc)
  2. Managed (can be repeated)
  3. Defined (is repeated)
  4. Measured (is appropriately measured)
  5. Self-optimizing (measurements leads to improvements)

This well-defined approach seemed to be perfect. It allowed us to take junior analysts and empower them to have a consistent level of service delivery. We could repeat ourselves across customers. We might not deliver the most effective results, but we could at least be reasonably consistent. As it turns out, people don’t like working in such structured roles because there’s little room for creativity or curiosity. Not surprisingly, this gave rise to the 18-24 month security analyst turn-over phenomenon. Many early analysts came from help desk positions and were escaping “call resolution” metrics in the first place.

Our application of SOC maturity morphed over the years from solving consistency problems into consistently repeating the wrong things because they could be easily measured. When failures happened, we were now in the habit of applying the same “bandages” over and over.  Meanwhile, the bad guys had moved on to new and better attack techniques. I have seen security operations teams follow maturity guidelines right down a black hole, when for example, a minor SIEM content change can take months, not the few hours it should take.

According to the HPE Security Operations Maturity report, the industry median maturity score is 1.4, or slightly better than ad-hoc. I’m only aware of 2 SOCs in the world that are CMMI 3.0.  So, while across the industry we are measuring our repeatability and hoping that it equates to effectiveness and efficiency, we are still highly immature, and this is reflected in the almost daily breaches being reported. You can also see this in the multi-year sine wave of SOC capability many organizations experience; it goes something like this:

  1. Breach
  2. Response
  3. New SOC or SOC rebuild
  4. Delivery challenges
  5. Maturity program
  6. Difficulty articulating ROI
  7. Cost reductions
  8. Outsourcing
  9. Breach
  10. Repeat

With a virtual analyst, your SOC can now leap to CMMI level 5 for what was traditionally a human-only task. An AI-based virtual analyst, like the Respond Analyst, conducts deep analysis in a consistent fashion and learns rationally from experience. This approach provides effective monitoring in real time and puts EVERY SINGLE security-relevant event under scrutiny. Not only that, you liberate your people from rigorous process control, and allow them to hunt for novel or persistent attackers using their creativity and curiosity.

This will tip the balance towards the defender and we need all the help we can get!

When Currency is Time, Spend it Threat Hunting

“Time is what we want most, but what we use worst.”
– William Penn

How many valuable cybersecurity tasks have you put aside due to the pressures of time? Time is currency and we spend it every moment we’re protecting our enterprises.

When we are constantly tuning, supporting and maintaining our security controls or chasing down an alert from an MSSP, only to discover it’s yet another false positive, we spend precious currency. When we create new correlation logic in our SIEM or decide which signatures to tune down to lower the volume of events to make it more manageable for our security team, we spend precious currency. When we analyze events from a SIEM to determine if they’re malicious and actionable or if a SIEM rule needs additional refinement, we spend precious currency. When we hire and train new analysts to cover churn, then watch them leave for a new opportunity – we waste currency and the investment hurts.

You can spend your “currency” doing pretty much anything, which is a blessing and a curse. We can (and do) waste an inordinate amount of time going down rabbit holes chasing false positives. We are forced to make choices: do we push back a request while we investigate the MSSP escalations or do we delay an investigation to provide the service agility the enterprise requires?

Both options are important, and both need addressing; forcing us to make a choice. In our gut we think the escalation is another false positive, but as cybersecurity professionals; we wait for the sword of Damocles to fall. It’s only a matter of time before one of these escalations is related to the thing we worry about most in our environments. Either way, something gets delayed…. hopefully just lunch.

Basing decisions on what we can neglect is reactive and unsustainable. It’s a matter of time until we choose to postpone the wrong thing.

We need to use our time more wisely.

Organizations need to spend precious “currency” focusing on higher value tasks, like threat hunting, that motivate their talent and provide value to the organization. But also need to maintain two hands on the wheel of lower value tasks that still need attention.

Organizations should implement automation tools to focus on the lower-value, repetitive tasks such as high-volume network security monitoring. Generating and receiving alerts from your security controls is easy, making sense and determining if they’re malicious and actionable is a different story. The decision to escalate events is typically inconsistent and heavily relies on the analyst making the decision. Factor in the amount of time required to gather supporting evidence and then make a decision, while doing this an additional 75 times an hour. As a defender, you don’t have enough “currency of time” to make consistent, highly-accurate decisions. Security analysts tasked with monitoring high-noise, low-signal event feeds is a misallocation of time that only leads to a lack of job satisfaction and burnout.

There is another way.

Employing Respond Analyst is like adding a virtual team of expert, superhuman analysts and will allow your team to, bring their talent and expertise to threat hunting. Adding Respond Analyst allows your talent to focus on higher value tasks and more engaging work so you can combat analyst burnout, training drains, and churn.

As Security Analysts, Instead of Threat Hunting We’ve Become Ticket Monkeys

We’ve heard repeatedly from security analysts (like those interviewed in Cyentia’s Voice of the Analyst Survey) that event monitoring is time-consuming, boring, and repetitive, that security analysts feel like ticket monkeys interfacing with IT, and only occasionally do they get to do the fun work of threat hunting.

But did you know that EPPs (Endpoint Protection Platforms, commonly called Next-Gen Antivirus, NGAV or AV) are a foundational data source in security operations but can also be a time sink for security analysts to evaluate and act.

Generally, EPPs generate high-fidelity alerts; the system is likely infected with malware. Given this alert, a security analyst must decide if:

1. the infected system presents a serious threat to the organization and an incident response procedure is

required

2. the system is in fact infected but the threat is not that serious and can be safely mitigated by creating a

ticket for IT or simply reimaging the machine

3. the alert can be dismissed because it is not a threat and no action is required at this time

And how does a skilled security analyst come to an accurate and appropriate decision?

Context. Context. Context.

A security analyst must understand the importance of the involved systems and accounts. Is this a server or a workstation? Is this the CEO’s laptop? Do the systems have any vulnerabilities?

Security Expertise.

Not all malware is created equally.  A security analyst must understand the type of malware, its function, potential harm, and ability to spread.  Analysts gain expertise on the job, through research, or arduous certifications (of which they need to keep maintained).

Experience.

Good security analysts won’t assume that the action taken by the endpoint agent (aka EPP) will fully remediate the issue, they will look for other indicators and evidence.   For example, corroborating and relevant network IPS alerts.  Experienced analysts know that when one malware is observed, likely more are lurking.

Awareness.

Of course, the security analyst must qualify if this threat is even relevant to their environment. Conversely, the threat could be part of something ongoing within their organization or an external campaign.

A thorough analysis of the situation and making the appropriate decision takes time.

On top of that, interfacing with IT and generating tickets to remove commodity malware from a workstation may not be meeting the expectations of hungry analysts eager to be hunting for bad guys.

It’s no surprise SOC teams are falling behind their unrelenting event loads and 1 in 4 security analysts express dissatisfaction with the current job.

But wait…

There is a solution besides wringing hands or hiring more analysts. Turns out, we created a Virtual Security Analyst to expertly analyze malware events and recommend a course of action. And get this, our virtual security analyst is fast, scalable, and 100% (yes, that’s right) 100% consistent in performing dozens of checks while evaluating every event.  On top of that, Respond Analyst integrates with most ticketing and case management solutions, elevating your analysts from time-consuming ticket creation processes.

Don’t you just want to learn more why we were named one of Gartner’s Cool Vendors?

Please reach out to learn how to augment your team with the Respond Analyst today.

You Don’t Have SOC Analysts, You Have SOC Synthesists

For all my nearly 20 years in the Security Operations field being a “SOC Analyst”, building and helping with SOC design, evolving SOCs and everything in between, I’ve been calling my team members by the wrong title. Worse yet, none of my colleagues ever corrected me, mostly because they didn’t know. Hard to believe, but I suspect it’s because we all never really thought much about what the “SOC Analyst” really does for a living.

The word “analyst” means a person who conducts an analysis. “Analysis” has its roots in the Greek word “analyein” which translates “to break up”. This implies breaking the problem into pieces.

It begins…

“SOC Analysts” typically come into work at the start of their long shifts and sit down in front of a console to look at alerts of some kind.  These alerts have data points from a single security product telemetry like an IDS sensor. These alerts do not usually have enough information alone to make a decision on whether they are dealing with a security incident or threat.

Now what?

The “SOC Analyst” would then want to know more information so they go collect data points from other sources to piece together (combine corroborating pieces of evidence) to form an as complete a picture as possible regarding what is going on in their environment, and what is the likelihood it is malicious.

Then what?

Now it’s decision time.  Does the picture paint a portrait of something nefarious going on and we need to get Security Incident Responders engaged or is it just a misconfigured company application running amok and should they need to notify a server admin?

Finally.

The decision is made and it’s on to the next alert.  Wash, rinse, repeat for the next 11+ hours.

What we just walked through was an individual taking one piece of evidence and trying to add more evidence to create a whole picture.  So let’s look at the definition of “analysis” below from dictionary.com:

Analysis

noun, plural a·nal·y·ses [uhnaluh-seez].

1. The separating of any material or abstract entity into its constituent elements (as opposed to synthesis).

2. This process as a method of studying the nature of something or of determining its essential features and their relations.

“The separating”?  Wait, what now? We just walked through how a Security Analysts is combining things, not breaking them apart!

Now let’s look at the definition of the word Synthesis, again from dictionary.com:

Synthesis

noun, plural syn·the·ses [sin-thuh-seez].

1. The combining of the constituent elements of separate material or abstract entities into a single or unified entity (opposed to analysis).

2. A complex whole formed by combining.

This definition fits what our “SOC Analysts” do every day much better than analysis now doesn’t it?

Wouldn’t it be great if your “SOC Analysts” had the time to synthesize all the contextual evidence they could collect around an initial alert to formulate a hypothesis?  THEN had even more time to turn around and breakdown all the possible permutations of the evidence to test the hypothesis and reaffirm or change their mind on each decision they made?  Yes, that would be awesome to have the time to do both!

Wouldn’t you rather synthesize AND analyze before making a decision to alert your incident responders, or just let them sleep another hour……

 

 

Join our growing community! Subscribe to our newsletter, the "First Responder Notebook," delivered straight to your inbox.