What to Consider When Building an Autonomous SOC

Today’s threat landscape demands more from IT and security professionals than ever before. Schools are being forced to shut down due to ransomware attacks, major brands are falling victim to reputation-harming data breaches, and an explosion of connected devices has broadened the attack surface. At the same time, cyber-criminals are getting smarter and savvier, developing new ways to evade detection software and make money.

As cyber-criminals are getting more creative, the cybersecurity industry is improving and developing innovative solutions to protect businesses. Earlier this year, the FBI revealed it had turned the tables on the notorious Hive ransomware gang by secretly hacking the group’s systems, saving $130 million in ransomware demands for more than 300 victims. Despite our best efforts, there are still elements holding us back as an industry and continuing to make organizations vulnerable to cyber-attacks. Prevention, monitoring, and mitigation all happen in the Security Operations Center (SOC), and, right now, SOCs are facing the perfect storm for cyber-crime: lack of visibility into complex operating environments, inability to analyze cloud-scale volumes of data, and an industry-wide shortage of cybersecurity talent. As a result, security professionals are experiencing widespread burnout and unrealistic workloads, which lowers their productivity and creates higher security risks.

Autonomous SOC: Building Yours Right

A lot of the burnout security practitioners face is caused by alert fatigue. When alerts about potential cyber-attacks come in at a rate faster than SOC analysts can handle, analysts work longer hours and still miss important threats. To cut through the noise and focus on the attacks that matter most, SOCs need to take a cue from cyber-criminals and adapt to the current threat landscape: They need to start their journey to the autonomous SOC.

Understanding the Autonomous SOC

An autonomous SOC (ASOC) is composed of an artificial intelligence (AI) and/or machine learning (ML) system that receives all of the data points coming in and assists with cybersecurity monitoring and mitigation. An ASOC is ideal for threat investigation since it can automatically detect suspicious activity, learn and correlate everything about the attack quickly, and provide analysts with the context they need to detect, isolate, and neutralize the attack easily and efficiently. The ASOC also filters out false negatives, allowing analysts to direct their focus on real threats and take immediate action.

The ASOC helps alleviate many of the issues organizations face with their security posture — limited resources, overwhelmed analysts, and repetitive, monotonous tasks. AI and ML’s ability to identify patterns and outliers boosts analysts with an actionable plan of prevention and mediation. An ASOC running in the background provides a much-needed extra layer of coverage to protect organizations, especially those dealing with understaffed SOCs due to recent layoffs throughout the tech industry.

There are a lot of questions around autonomy and the SOC. Namely, will ASOCs replace human analysts? The short answer is no. Human and machine collaboration is necessary for success, especially regarding cybersecurity. ASOCs constantly evolve as they ingest data and assess new threats, which is why they will always need human analysts to create guardrails and provide feedback. ASOCs are designed to make analysts’ jobs easier, not to steal them.

What Organizations Should Consider Before Investing

The ASOC is not a passing trend. It’s where our industry is headed. IDC predicts that by 2026, 30 percent of large enterprise organizations will migrate to ASOCs for faster remediation, incident management, and response. Still, many executives misguidedly view the SOC as a department that exclusively costs the company money and does little — if anything — to drive revenue. As such, the shift to an ASOC may seem daunting or unrealistic to some organizations. Proponents of plans to build an ASOC might face pushback from others in the organization and need to justify the investment costs. The bottom line of an ASOC is to get more value out of the tools and workflows at the SOC’s disposal. In the short-term, this means SOC analysts who are less burnt out, more engaged, and stay at the company longer. In the long-term, investments in cybersecurity save the company money in terms of reputational damage and customer loss if an attack or breach occurs.

Another aspect to consider is timing. Ask yourself, “Is my organization ready for this transition?” Assess the maturity of the SOC and bring SOC analysts and leaders into the conversation. It’s also important to note that moving to an ASOC doesn’t have to be all or nothing; it’s a journey.

Keeping these elements in mind will help you to seamlessly transition to an automated SOC, the future of cybersecurity.

-- Gunter Ollmann

First Published: Solutions Review - March 30, 2023

It’s Time for Security Analytics to Embrace the Age of Science Over Art

Security analytics has traditionally been approached with a “hunt and peck” mentality, which has made the process of uncovering and responding to cyberthreats more art than science. A human analyst has an idea of what they are looking for when they begin to hunt across the available data, performing that task based on their own experience. They’ve been taught to celebrate when they find something, and that the trickier and more obscure the discovery, the greater the celebration of their skills.

This situation is, I believe, an “art” because the results will always differ between analysts — the day of the week, what they had for breakfast, or how their weekend went — and there are too many outside factors that can affect the individual doing the hunting. The situation has only been perpetuated by an industry that has for too long touted the value of this “art.”

We’re no longer working with a simple canvas

We’ve all heard it before and will continue to hear it — data volumes and the enterprise landscape have been growing exponentially and that’s not going to stop. This was put into hyperdrive with the rapid adoption of cloud computing, which challenges organizations to collect and analyze complete data from multiple sources, including new cloud data as well as from legacy, on-premises infrastructures. This has resulted in limited visibility that ultimately compromises overall security.

What we’re not hearing enough is that applying to this challenge the long-held belief in the “art” of hunt-and-peck doesn’t scale and isn’t a reliable or repeatable process that can come close to meeting the needs of modern enterprise environments.

Managing haystacks of needles

We all know the saying “finding a needle in a haystack.” But in today’s threat landscape, given the data volumes with which analysts are burdened, it’s more like finding the sharpest needle in a haystack of needles. Following the decades-old mantra of “assume breach,” we need to turn our focus to the threats that matter most — the sharpest needles. This requires operationalizing the hunt, triage, investigation and response by removing humans from being “artistic” speed bumps and instead empowering them with the science of protection embedded in security analytics.

Adopting the science of security analytics that leverages automation built on machine learning and AI enables repeatable, reliable streaming investigations of threats across all the data, at all times. Applying this method will reveal orders of magnitude more threats and incidents — across a broad spectrum of risk — occurring continuously within the enterprise. We’ve reached the tipping point where threat volumes have far exceeded what any number of human analysts could reasonably hunt/triage, let alone respond to. This means enterprise security teams must increasingly apply AI and ML to the management of the threats they find (i.e., managing those stacks of needles) as well as the mitigations and responses.

Reprieve begins with automation

Building processes that are autonomous is the critical element to embracing a scientific approach to protection. While past security solutions focused on automation, they were largely unsuccessful due to inflexibility and reliance upon humans to choose the right automation steps in advance of applying them for every exception. This is not the role people should be playing when it comes to successfully implementing autonomous solutions, and it doesn’t do anything to lighten their load. Instead, autonomous solutions should deploy system “smartness” to fill in the blanks and know to ask for human guidance when it’s actually needed.

If we continue with the mantra of “assume breach,” and operationalize security as described above, we also must completely rethink the human-focused SOC solution of filtering alerts. With people having been swamped to the point of (and beyond) alert fatigue, the solution has been to drastically manage the funnel of events and alerts, thus reducing the aperture of enterprise threat visibility and response — none of which sounds like a solution to me.

It begs the question: Why bother collecting alerts and events in the first place if you’re only going to do something with 1% of the top 1% most critical alerts? My response: Filtering is the worst way to manage security.

Instead, let’s do this:

With modern AI and autonomous hunting and triaging solutions, the system can look at every event and alert as it streams by and correlate, question and enrich them all in real time — all the time. The more data collected the more accurate and useful the autonomous system becomes, improving its ability to identify the collective stories and present them to the business and the analysts. To take it a step further, the autonomous system can then, in most cases, perform autonomous responses to the threats being found.

Human and machine harmony

Anytime automation in security is discussed it brings up the fear of automating away the analyst. But with a science-first approach, they aren’t going anywhere. The human analyst role is transforming, which will be a huge benefit to the people who work in SOCs. By adopting a scientific method for security analytics, the analyst will influence and guide the autonomous system to ensure it delivers business impact and value:

• For exceptions when the AI doesn’t have enough information or confidence to provide an autonomous response, it watches and learns how the human analyst does or did it, thus building and establishing a scientific methodology.
• At the cloud-SaaS level, those learnings may come from hundreds of enterprise SOC teams and thousands of expert security analysts, from which the AI systems can take collective intelligence and apply those learnings and methodology refinements back into the hands of the individual analyst.

The final result? The loop gets closed. The analyst is augmented.

The autonomous system deals with the daily grind, identifies the gaps that require human expertise, learns by watching how humans fill in the methodology gaps, and reapplies those learnings collectively. For instance, assume that a security team is capable of performing 100 manual investigations per day. An autonomous system could ask millions of forensic questions in a day. Time to resolution is shortened by augmenting the work the analyst does. The autonomous system performs repetitive, data-intensive work, it can quickly go back in time and ask an infinite number of questions, and the efficiency benefits just go on and on.

Leading with science will equip security analysts with actionable data across use cases ranging from threat detection, threat investigation, and threat hunting to ransomware investigation and incident response. It helps security teams work smarter and respond faster while boosting productivity and strengthening security.

-- Gunter Ollmann

First Published: Medium - September 8, 2022

Why the SOC Needs to Learn from the Aviation Industry

The cybersecurity industry has spent a lot of time talking about improving the analyst experience while not making significant improvements, as much of the efforts have been too focused on finding a silver bullet solution. Combine that with a global pandemic and now things are just getting worse. A recent study published by Devo, the 2021 SOC Performance Report, found that on a 10-point scale, where 10 indicates SOC staff have a “very painful” experience performing their jobs, 72% of respondents rated the pain of SOC analysts at a 7 or above.

Instead of thinking about the aforementioned silver bullet to alleviating SOC pain, I wanted to focus on one of the top sources, alert fatigue, and how the cybersecurity industry might be able to take a page out of another field to find a solution.

In the SOC Performance Report, a whopping 61% said a cause of SOC pain was that there are too many alerts to chase. I think it’s safe to draw the connection that “alert fatigue” will expand to “posture fatigue” and “policy fatigue,” as it adversely affects both recruitment and all too critical retention of experienced SOC professionals.

Alert fatigue may exit the aircraft

So, if we can’t figure out within the security industry, let’s learn from others. There are many non-cyber industries and professions that suffer similarly with alert fatigue, and perhaps the cybersecurity industry can reapply some of those learnings. Across these compatriots of alert fatigue, if we ask the question “how do alarms, warnings, and alerts differ?” I think we’ll find much similarity and overlap in answers — in both the theory and practice of how human operators are supposed to respond and how they do so in reality.

For the purpose of this article, I want to take a look at the aviation industry as our example to the SOC. They have navigated many of the problems SOC operators face today and have made the most progress in governing and managing the ergonomics of sensory overload and automation. Picture this: the inside of an airplane cockpit with all its knobs, buttons, lights, and alerts isn’t too dissimilar to the combined dashboards SOC analysts have to navigate when triaging, investigating, and responding to threats.

In 1988, The Washington Post reported on a “glass cockpit” syndrome in the aviation industry, that reads eerily similar to what many say or think about the SOC today. Researchers from the American Psychological Association noted that pilots would “fall victim to information overload and ignore the many bits of data pouring from myriad technical systems,” and that in airline crashes they studied it was found that “black box recordings showed that the crews talked about ‘how the systems sure were screwed up’ but did not verify what was wrong. In both cases, the systems worked but crews failed to check the information and crashed.”

Similarly, research published in 2001 by the Royal Institute of Technology examined “the alarm problem” in aviation, meaning, “in the most critical situations with the highest cognitive load for the pilots, the technology lets you down.” The reports noted that “the warning system of the modern cockpits are not always easy to use and understand. The tendency is to overload the display with warnings, cautions and inoperative system information accompanied by various audio warnings.” It went on to identify one of the main problems as a result of this overload as “a cognitive problem of understanding and evaluating from the displayed information which is the original fault and which are the consecutive faults.” Sound familiar? You would likely hear something extremely similar from someone working in today’s SOC.

In the decades that followed, aircraft cockpit design has progressively applied new learnings and automation to dynamically manage alert volume and the attention of the pilot to priorities. In the Royal Institute of Technology’s report, researchers identified accident simulation as an effective tool for improving cockpit alert systems, finding more associable ways to present alerts such as differentiating sounds and the introduction of context, which would allow pilots to “immediately understand what part or function of the aircraft is suffering a malfunction.” More context would also include guidance on what to do next. In its conclusion the study noted:

Such simulations would hopefully result in less cognitive stress on behalf of the pilots: they would know that they have started to solve the right problem. They would not have to worry that they have entered the checklist at the wrong place. With a less stressful situation even during malfunctions there is greater hope for correct actions being taken, leading to increased flight safety.

SOC systems need to embrace and apply many of these same learnings that have spanned decades for aviation. The majority of the cybersecurity industry seems to have only gotten as far as color coding alert and warning significance, leaving the analyst faced with a hundred flashing red priorities, even after triaging it. It’s no surprise that they’re both overwhelmed and unable to respond to complex threats across a broadening attack surface.

Beware of Autopilot

When it comes to solving the issue of alert fatigue, automation is typically one of the first things to come to mind. The same went for aviation in 1988, where the previously mentioned Washington Post report quoted researchers saying what could have been taken right from a security trade publication in 2022:

Research is badly needed to understand just how much automation to introduce — and when to introduce it — in situations where the ultimate control and responsibility must rest with human operators, said psychologist Richard Pew, manager of the experimental psychology department at BBN Systems and Technologies Corp. in Cambridge, Mass.

“Everywhere we look we see the increasing use of technology,” Pew said. “In those situations where the operator has to remain in control, I think that we have to be very careful about how much automation we add.”

The growing use of high-tech devices in the cockpit or on ships can have two seemingly contradictory effects. One response is to lull crew members into a false sense of security. They “regard the computer’s recommendation as more authoritative than is warranted,” Pew said. “They tend to rely on the system and take a less active role in control.” Sometimes crews are so mesmerized by technological hardware that they are lulled into what University of Texas psychologist Robert Helmreich calls “automation complacency.”

And while automation of course has an important part to play in incident response and investigation — just as it does in modern aircraft cockpit design — it comes with some key warnings:

1. Situational awareness is lost. Automation is often brittle, unable to operate outside of the situations it is programmed for, and subject to inappropriate performance due to faulty sensors or limited knowledge about a situation.
2. Automation creates high workload spikes (such as when routine changes or a problem occurs) and long periods of boredom (in which attention wavers and response to exceptions may be missed). If you’re staffing for automation-level activities, how do you manage capacity for spikes?

The SOC Earns its Wings

As an industry we have to take a page from the aircraft handbook and avoid increasing cognitive demands, workload and distractions, and make tasks easier to perform. But we must also understand how to manage automation failure and exceptions better.

• Embrace AI and autocomplete: Like the more advanced sentence autocomplete functions appearing in email and word processing applications, SOC analysts are still in charge of managing an incident, but there is an opportunity to further guide and preemptively enrich a threat investigation, thereby increasing the speed and robustness of response.
• Distill and prioritize at the incident level, not the alert level: It’s not about filtering/correlating/aggregating alerts, it’s about contextualizing both events and alerts in the background and only articulating an incident in plain single-sentence language. Analysts can double-click down from there.
• Leverage a community of experts: As attack surfaces increase and vertical technology specialization becomes tougher for in-house SOCs to cover (particularly in times of competing incident prioritization), it becomes increasingly important to be able to “phone-a-friend” and access an on-demand global pool of expert talent. It’s like having several Boeing engineers sitting in the cockpit with the pilot to troubleshoot a problem with the plane.

-- Gunter Ollmann

First Published: Medium - March 29, 2022

You May Not Have Asked, But The SOC Evolution Answered Anyways

Let’s get the obvious out of the way: The attack surface is growing exponentially and diversely.

Bigger shark, same small boat

The environments, platforms, services, regions and time zones that constitute modern enterprise operations and drive digital transformation for business continue to require increasing specialization and expertise beyond current in-house capabilities. Through a security lens, enterprise attack surfaces are expanding beyond the business’ ability to protect.

Meanwhile, global hiring and retention of security expertise continues to be a weak spot, and direct access to specialized security knowledge and experience is becoming increasingly difficult and costly. And while all that is going on, the volume, duration, pace and sophistication of attacks continues to increase and require significant acceleration in SOC response times and durability — and subsequent autonomous response systems.

Saying we’re in a conundrum is vastly understating things.

The security industry is at the gate of a forced SOC evolution, and as you can see, pressure is coming from all directions to drive that change.

The more things change, the more they stay the same

Plenty has happened that has tried to look like an evolution. For the last decade the security industry that powers SOCs has fixated on automation as the key to alleviating some of the pressures. But after a decade, have things really changed?

SOAR was a brief shining light that has come and mostly gone, having been absorbed back into SIEM, as the legacy SIEM vendors acquired dedicated SOAR vendors to make up for their shortcomings in human workflow automation. This didn’t solve much, as analysts were more or less left in the lurch. They faced the same automation integration challenges, only now they’re locked into a single vendor (where previously an “independent” SOAR offered the prospect of multi-vendor connectors and flexibility to operate independently of SIEM lock-in).

And that’s not the end of our automation woes, either. Automation, on its best day, is still too playbook-oriented. To get things done, experts have to essentially write scripts for each new system, connector and application in an enterprise. If we had set out to create librarians out of analysts, that’s an area our industry could say it had actually achieved success in.

But in all seriousness, we’re caught in a linear script development cycle and automation hasn’t yielded the reduction in analyst workloads that we so desperately need.

I’d like to get off the ride, please

So how do we break the cycle? I can identify two major breakthroughs that will move the needle forward for the SOC evolution.

First, the successful implementation and use of AI “smart” orchestration systems within the SOC.

I’m sure many SOC analysts and CISO’s are jaded from past promises, but the reality is that AI and ML approaches have matured significantly over the last year, and have reached the inflection point of their “hockey stick” usefulness trajectory and the value they can bring. I think as an industry it’s time we start to move past our fear of turning on automated response and protection capabilities that are powered by this new generation of AI and ML. By embracing it, SOCs will become much more effective at detection, which will lead to a reduction in the number of distinct alerts and false positives (put that in the win column for reducing analyst workloads).

Second breakthrough: The ability to tap a global community of contributors via marketplace ecosystems, or more simply put, sharing is caring.

Detection-as-code, policy-as-code, blah-as-code has redefined content development and vendor-proprietary product-dependent content. Platform-independent content (ranging from alerts, threat detection, playbooks, etc.) is rapidly and readily available from a global array of sources, and availability will continue to increase. The ability to tap a global pool of expertise is more prevalent than ever and it feels like the gig economy is finally coming to the security world via the SOC. I think this would have surprised many people just a few years ago, but in the wise words of one Jim Carrey — “desperation is a necessary ingredient to learning anything.”

I don’t care how, I want it now

Well, you can’t have it…yet. But you can start. Both “smart” machine-intelligence and content marketplaces directly address the pressure points previously mentioned, but the industry is still in early stages of the SOC evolution. Right now organizations have to take a look at their SOC and decide how they’re going to reorganize and prioritize to discover and implement the people, tools and partners they’ll need to usher in the evolution.

There are some philosophical hurdles to be overcome, but I believe business needs will drive the pace of change. It used to be the case that penetration testing was in-house only, then extended to trusted vendors managed under restrictive agreements, and on to industry-accredited providers, and now businesses can tap broad communities of bug-bounty-based individual contractors and cloud-based automated attack simulators. If we managed those industry changes, I’m pretty sure we can manage the same for incident response and investigation.

-- Gunter Ollmann

First Published: Medium - December 9, 2021

The Rise of Continuous Attack Surface Management

In the merry-go-round world of InfoSec technologies and “what’s old is new again,” this year we should include Attack Surface Management with a dash of Continuous.

Twenty years ago, the first commercial “ethical hacking” training courses taught defenders the mystic arts and methodologies of targeted intrusion. Back then, a lengthy opening chapter would cover the ethics of hacking and the legal consequences of employing the skills students were about to learn. It wasn’t until chapter two that students got to roll up their sleeves and learn through doing — beginning with passive information gathering and enumerating the attack surface of a target (typically the student’s own employer).

Any technical CISO and greying SecOps professional worth their salt can recollect their first ethical hacking experience and foray into mapping the attack surface of their business and being both excited and shocked at the long list of security-related findings they had uncovered with their own hands.

Two decades later, as businesses expand upon their digital transformation investments, their internet-exposed surface has grown exponentially and with it so too have the vectors for attack. In an increasingly cloudified world, identifying what business systems are publicly accessible and what confidential insights or vulnerabilities they may expose has risen to critical importance. Ad hoc point-in-time enumerations of an organization’s external attack surface are being superseded by continuous attack surface management (CASM).

Although CASM is a new label, there’s already a mix of several dozen old and new startup companies focused on external attack surface enumeration and public asset attribution — with an array of integration options into existing threat intelligence platforms (TIP), vulnerability assessment management (VAM) systems, cloud security posture management (CSPM) and SIEM solutions. Although diverse in their offerings, vendors can be roughly divided into three value propositions.

1. “Traditional” external attack security enumerators that focus on cyclically mapping and inventorying the entire internet, often with limited attribution or asset ownership insights. Their data tends to be most useful and consumable from a TIP perspective.
2. Digital Risk Protection services that fuse attack surface information with other intelligence sources (e.g., dark web monitoring) to provide customers with enterprise risk insights. Often delivered as part of brand protection and fraud campaign detection services.
3. Continuous automated external testing of an enterprise’s (known) assets for an outside-in and attacker’s perspective for the prioritization of vulnerability and asset remediation (often as part of VAM).

Enumerating and understanding an organization’s outside-in security posture and attack surface through continuous scanning and probing, although clearly a valuable component of modern enterprise security and risk management, is yet another noisy alert generator that contributes enormously to SOC alert fatigue if not well integrated into more advanced workflows. 

Impactful operational security benefits of CASM typically come from deep (single pane of glass) integration with continuous vulnerability assessment and security posture management solutions. 

Internet-spanning scanning, basic asset discovery and service enumeration, and ownership attribution are solved problems and represent a low technology threshold for those choosing to build their own CASM solutions, which helps explain why so many startups incorporate them. 

The mix of low cost of market entry, increasing customer alert fatigue, competitive service pricing pressure, and classification as a feature rather than a standalone solution will likely result in churn of single-solution and dedicated CASM vendors over the coming year. A lucky few CASM startups will inevitably be acquired along the way — but probably at much lower valuations than expected, despite the value of the risks they help customers identify.

Enterprise security teams are hungry for the visibility CASM offers them and are pushing their larger and preferred security vendors to incorporate outside-in attack surface intelligence into their more expansive security suites as a feature. CISOs should anticipate that CASM will quickly become a check-box feature in existing enterprise-grade security solutions and plan accordingly.

-- Gunter Ollmann

First Published: SecurityWeek - May 25, 2021

The Cusp of a Virtual Analyst Revolution

Security Analytics and Threat Investigation Are in the Midst of a Sea Change

Once live stomping around vendor-packed expo halls at security conferences returns, it is highly probable that “Virtual Analyst” will play a starring role in buzzword bingo. Today, the loosely defined term represents an aspiration for security vendors and managed service providers but may be perceived as a threat by internal day-to-day security operations and threat hunting teams.

For context, security analytics and threat investigation are in the midst of a sea change. Cloud log analytics platforms now enable efficient and timely analysis of ever-increasing swathes of enterprise logs, events, and alerts dating back years. Threat Intelligence platforms are deeply integrated into cloud SIEM solutions—enabling both reactive and proactive threat hunting and automated incident investigation—and are entwined with a growing stack of sophisticated AI and ML capabilities. However, smart event correlation and alert fusion engines automatically triage the daily deluge of suspiciousness down to a manageable stack of high-priority incidents—replete with kill-chain reassembly and data enrichment.

In many environments the traditional tier-one security analyst responsibilities for triaging events (removing false positives and “don’t care” noise) and maintaining operational health of scale-limiting SOC systems (e.g., device connectors, log retention and storage parameters, ticket response management) have already been subsumed by modern SIEM solutions. Meanwhile, platform-native no-code/low-code-powered orchestration and automation capabilities, along with growing libraries of community-sourced investigation and response playbooks, have greatly accelerated incident response and efficacy for tier-two analysts—alleviating time-consuming repetitive tasks and increasing focus on new and novel incidents.

Arguably, the Virtual Analyst is already here—captured within the intelligent automation and efficiencies of modern cloud SIEM— and I believe the journey has just begun.

The near future evolution of the Virtual Analyst is being driven by two competing and intwined motions —the growing need for real-time threat response, and the inaccessibility of deep security knowledge and expertise.

Real-time threat response has long been thought an achievable target for in-house security operations teams and has underpinned many historic CISO security purchasing decisions. As the enterprise attack surface has grown, adversaries (external and internal) have increased the breadth and pace of attack, and in response businesses continue to invest heavily in instrumenting their environments with an “assume breach” mindset—widening the visibility aperture and exponentially increasing the volume and timeliness of threat-relatable data. Advanced log analytics capabilities and AI-powered event fusion processes are identifying more incidents earlier along the kill-chain and consequently providing more opportunities to conditionally mitigate a budding threat or disrupt a sequence of suspicious events. 

To successfully capitalize on that shrinking window of opportunity, responses need to occur at super-human speeds. The speed bump introduced by requiring a human in that response loop will increasingly materialize as the difference between having been attacked versus being breached. In this context, the Virtual Analyst represents the super-human capabilities AND responsibilities for real-time threat identification AND trusted automated mitigation of a live incident.

Although that Virtual Analyst capability will be tightly bound to a product (e.g., Cloud SIEM, SOC-as-a-Service), the second Virtual Analyst motion centers around access to deep security expertise.

If a product-bound Virtual Analyst can be considered a quick-learning high-speed generalist, the second motion can be thought of as a flexible “on-call” specialist—augmenting the security operations team’s investigative and response capabilities as needed—and may be conceptually akin to the on-demand specialist services provided by traditional managed security service and incident response providers. 

The differentiated value of cloud-based Virtual Analyst solutions will lie in leveraging broader internet-spanning datasets for threat detection and attribution, and powerful, rapid, ad hoc forensic-level investigation of incidents and response. For example, the in-house SOC team may engage the Virtual Analyst to augment an ongoing investigation by temporarily connecting it to their on-premises SIEM, and receive targeted direction for capturing and collecting incident-relevant non-SIEM data (e.g., PCAPs, VM images, storage snapshots, configuration files) that are uploaded and automatically investigated by the virtual analyst as well as incorporated for real-time instruction on system recovery and attack mitigation.

It’s tempting to think that on-premises security analysts’ days are numbered. Virtual analyst advancements will indeed increase the speed, fidelity, and efficacy of threat detection and incident response within the enterprise—replacing almost all repeated and repeatable analyst tasks. But AI-powered virtual analyst solutions will do so with little knowledge or context about the business and its priorities. 

With the day-to-day noise and incident investigation drudgery removed, security operations teams may evolve into specialist business advisors—partnering with business teams, articulating technology risks, and providing contextual security guidance.

-- Gunter Ollmann

First Published: SecurityWeek - March 23, 2021

Reinventing Managed Security Services’ Detection and Response

Managed security services are undergoing a timely and significant transformation, armed with new hyper-scalable technology stacks, hybrid enterprise and cross-cloud protection complexities, and a demand to evolve from 24/7 eyes-on-glass into hands-on customer-integrated early warning and response. If it wasn’t a tired industry cliché we’d probably be adding “next-generation” or NG prefixes to many of these newly transformed managed services.

That transformation of traditional managed security services provider (MSSP) offerings, combined with an explosion of software product vendors and consulting services providers entering the fray with their newly hybridized managed detection and response solutions, is confusing to many. Whether from an MSSP, security product vendor or a consulting services provider pitch, the same vocabulary and acronyms increasingly mean different things.

Endpoint protection platforms (EPP) have evolved over the past decade from alert-generating megaphones into standalone, powerful endpoint detection and response (EDR) solutions. Key to that evolution is the incorporation of progressively advanced machine learning threat detection capabilities and automated remediation. Although EDR continues to grow smarter and more capable, a diverse portfolio of managed services is being welded to them to enhance threat protection and remedy capabilities.

As such, in broad strokes EDR solutions (and the market in general) is evolving into managed detection and response (MDR). 

For product vendors, MDR is tied to advanced manageability and proprietary services almost exclusively built around enhancing their own stand-alone EDR product (and may extend to data ingestion and analytics of integrated partnered products). For MSSPs and consulting services providers, MDR typically refers to the addition of human-led detection and response capabilities provided 24/7 and layered upon EDR suites from one or more vendors.

Recently the term XDR (extended detection and response) has become a catch-all for combined endpoint, network, and cloud-based detection and response. MSSPs tend to imply that “XDR” is a managed service and often a component of an outsourced and managed SOC (security operations center) offering. 

Tight product integrations and security ecosystem fusions with automation have made it exponentially easier to provide managed detection and response across a broader range of security products and technologies — and easier for service providers to offer highly scalable and managed XDR (or EDR, NDR or MDR) detection and response solutions. 

Meanwhile, some software and SaaS vendors have launched stand-alone XDR products that aggregate detection alerts and automate response across multivendor EDR, NDR (Network Detection and Response) and CSPP (Cloud Security Protection Platform) products — enabling third-party human specialists to transform their XDR product into a managed service. 

It can feel like a Monty Python sketch when speaking with a product vendor: XDR and managed XDR (MXDR) are different solutions, but EDR and MDR may mean the same thing because vendor-provided management is often part of the product purchase subscription. For an MSSP, managed EDR is different from MDR, but MDR and XDR may be the same thing. 

The inclusion and advancement of machine learning is the key ingredient to modern managed detection and response solutions. For example, supervised and deep learning methods play such a fundamental role in bulky detection triage processes that they’ve effectively eliminated the traditional mind-numbing tier-one security analyst role. Meanwhile, Natural Language Processing (NLP) and anomaly clustering, along with no-code playbook automation, is simplifying threat hunting and response — removing the daily grind tier-two analysts tend to face. “Virtual analyst” is the term we’ll hear with growing regularity.

MSSPs and EDR vendors may have commenced their detection and response journeys from different starting points, but they are converging to roughly the same solution and reinventing the managed security services market along the way. Virtual analyst technology (and the advances in ML and AI that lay behind its efficacy) will assuredly drive further innovation in managed services, with the next click-stop on this journey likely being autonomous SOC (or SOC-as-a-Service).

-- Gunter Ollmann

First Published: SecurityWeek - Feb 9th, 2021

Attesting to the Security of Data-in-Use

The pace at which new confidential computing solutions are penetrating enterprise security architectures and data protection strategies appears to be catching security leaders off balance. COVID-19-accelerated digital transformation saw years’ worth of cloud migration, “zero trust” management and online collaboration tool rollouts squeezed into a few short months. Solutions engineering and security teams that thought they’d have a couple years to learn and master the next set of security- and privacy-preserving technologies are suddenly playing catch-up in the newly “cloudified” enterprise.

Having already mastered and commodified “data-at-rest” and “data-in-transit” security, security leaders are under pressure to support companies’ adoption of confidential computing technologies and newly enabled trusted execution enclave (TEE) services. If 2020 represented a step function for digital transformation and cloud adoption for businesses, 2021 will be the year of rapid, measurable “data-in-use” security and privacy. 

As the list of new and pending TEE-enabled products and services from major public cloud providers grows, where should CISOs and security architects begin? For most organizations, the two most influential confidential computing building blocks will be enclave attestation and enclave-enabled relational databases.

Whether the organization is planning on utilizing in-house or cloud computing builds atop Intel SGX or AMD SEV chip architectures (or Arm, NVIDA, etc. in the future), attestation lays at the heart of confidential computing trust. Enclave provisioning and trust will quickly become as fundamental to enterprise security as identity management, certificate management and key management.

Enclave attestation services are designed to verify and validate that the confidential computing workload is provisioned and executed securely in a TEE environment. Remote attestation services will necessarily vary in environmental specifics, but they generally validate the integrity — the root of trust, hardware status, firmware status, security patch status, etc. — of the TEE (hardware or virtualized) before releasing sensitive data into the enclave. It is therefore the attestation service’s responsibility to cryptographically ensure that the underlying hardware and firmware is not in a vulnerable state before use, that the workload assigned to the enclave is transferred securely and, upon execution, that the enclave remains secure and the workload’s computing functions and output were not tampered with in any way. In essence, confidential computing attestation tells you if the results that your code generated within the TEE are trustworthy.

It won’t be long before CISSP study materials include attestation mechanics with an “Alice and Bob” explanation, like those used to teach data flows that constitute asymmetric cryptography and key exchange mechanics. For most InfoSec professionals, a basic understanding of enclave attestation will be adequate for traffic routing and troubleshooting. A deeper understanding will be required for architects and DevOps teams tasked with deploying and trusting new confidential compute workloads.

In parallel to incorporating enclave attestation service design into new business application architectures, security and privacy leaders will need to leverage enclave-enabled relational databases — especially if they’re to meet toughening regulatory requirements linked to customer data privacy. 

In the database world, balancing privacy and “data-at-rest” encryption with data utility and business application performance has been a delicate, often compromising, affair. Encrypted column data (for example, customer names, addresses and blood types) logically makes it more difficult to perform searches and match records. The use of deterministic encryption techniques (for instance, encryption that always generates the same encrypted value for any plain text value) is vulnerable to some predictive attack vectors. However, randomized encryption techniques are more secure but make most common query types impossible.

To protect sensitive data from malware and high privileged unauthorized users of the database server, traditional non-TEE data encryption processes protect the data by encrypting it on the client side. This means disallowing the data or corresponding cryptographic keys from appearing in plaintext inside the database engine. When deterministic encryption is used, the only operations the database engine can perform are equity comparisons. All other operations, including cryptographic operations (initial data encryption or key rotation) or rich computations (for example, pattern matching), are not supported inside the database. Users need to move their data outside the database to perform these operations on the client side. These actions are completed as a secure software agent to transport encrypted column data to a remote host or system to decrypt and perform query actions upon the data, then re-encrypt data that needs to be written back to the protected column.

For operations teams tasked with regulatory data discovery, labeling and protection throughout the enterprise, the mechanics of securing client agents and shuffling encrypted data between systems —temporarily duplicating data in the process — is inefficient and burdensome. TEE-enabled database services ensure the encrypted data remains within the system, allowing computations on plaintext data inside the secure enclave with no way to view data or code inside the enclave from the outside (even with a debugger). In addition, rich computations, such as operations on encrypted columns, are possible, and cryptographic operations on sensitive data, like initial data encryption or rotating a column encryption key, are performed within the enclave and do not require moving the data outside the database.

As confidential compute services become ubiquitous, enclave attestation and enclave-enabled relational database technologies will be fundamental building blocks for post-COVID-19 business application design and delivery. CISOs and their security teams need to quickly master these technologies if they’re to successfully partner with in-house development teams and secure “data-in-use.”

-- Gunter Ollmann

First Published: SecurityWeek - December 22, 2020