Close this search box.

Introducing “Swipe Left” Security

You may have heard about the idea of shifting left in security: as developers move more to the cloud, security professionals are looking more upstream – or left – toward where the development processes are initiated. As you progress from Development to Q/A and then Production (moving right), there is more underlying thinking about end-to-end security.

Let’s take this idea one step further and talk about something new – “swipe left” security.

At the highest level, the security industry is struggling to solve two key problems in parallel:

  • collecting the right data
  • evaluating it quickly

The first problem is related to the growing theme around “security analytics” – the breadcrumbs that help us understand if there are actual security incidents that need our time and attention. The attack surface of any enterprise today is bigger than ever. You have to look at network traffic at the packet level; you have to look at server, application and user logs; and you have to look at commands and processes that have been initiated. You also must cover all the environments: bare metal on premises, virtualized, containers and public cloud.

The second problem is that even if you see the right data or security analytics, how do you quickly assess the value of the alert? Most security teams today will tell you that they are overwhelmed with data, have too many false positives, and are chasing too many low-level alerts. With a traditional SIEM, you might have 3,000 alerts a day, and responding to that many becomes a human scaling problem.

I like to think of security analytics as sifting through a haystack full of needles, and ideally, you want to get better and better at sifting through that haystack. Any product that allows you to tighten your security posture every day is something you want. This capability doesn’t come from just machine learning or the hyped impact of “AI,” it comes by looking across all the alerts and asking, “are any of these related?”

Let’s take a simple example, say Steve logs into a server at 4am (and I have never logged in at that time before), and my IP address is from Thailand, but I am based in San Francisco, and the app I launched is not an app I have launched before. These individual alerts might be perceived as noise, but when looked at together, you see a pattern that builds a strong case that there is a breach underway!

So how do you collect more and more data without increasing the already too-high volume of security alerts? To gain insights into every environment I noted above, you would need to combine the industry’s broadest security data collection engine with automated techniques for enriching data collection and correlating seemingly noisy, low-level alerts and showing that they are in fact related.

How do you help security analysts scale through automation, so they are presented with a simple “red” or “green” highlight, and they simply swipe left to reject an alert, or swipe right to accept it and look deeper into the issue? Ideally, a security analyst would not have to examine 3,000 alerts a day, but three, so that investigating and triggering automated responses can be programmed as policies.

This type of thinking is what more and more people are calling managed detection and response service – MDR-as-a-Service. Leveraging automation to help your team scale and offer your customers forward looking value.