Why we’re supporting the next generation of cybersecurity professionals with (ISC)²

The RSA security conference halls at Moscone Center were abuzz last week with conversations ranging from nation-state attacks to speculation about which household brand will be breached next.

But one conversation stood out like an ominous black cloud on the horizon—the cybersecurity skills gap.

At Respond Software we believe the talent shortage has gone far beyond something people alone have the capacity to tackle. The solution of the future is one that augments human capabilities with Robotic Decision Automation (RDA), which complements the security analyst’s skillsets and expands their ability to do more. Raising the bar for security expertise is our aim and we understand that the need for higher-skilled cybersecurity experts is more critical than ever before.

This year at RSA we decided to take a slightly different approach by giving back to help expand our cybersecurity community. Starting at RSA and events throughout 2019, in lieu of giving away hundreds of coffee mugs, pens, or other swag that ends up in landfills, Respond Software will instead route a portion of our promotional budget to (ISC)² Cybersecurity Scholarships programs. Attendees at several hand-picked Respond Software events throughout the year will have the option to add their name to our donation roster.

To kick this off, last week 90% of the attendees at our sponsored RSA ISE VIP Luncheon agreed to support this effort! Today we will send our first donation check, in the amount of $2,000, to (ISC)2. We are aiming to donate upwards of $10,000 throughout the course of 2019 to support the valuable work the scholarship program does and to give back to our industry.

About ISC² CyberSecurity Scholarship
Each year, (ISC)², the world’s leading cybersecurity and IT security professional organization, and the Center for Cyber Safety and Education, partner to offer scholarships to students around the world.

The Respond Analyst
Last year, the Respond Analyst, our flagship product pre-built with decision-making skills, was able to expand the capacity of security teams by adding the equivalent of 14 ‘human’ analysts to every team which shines a light on how quickly automation can help close the skills gap.

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!

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.