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

Securing Data-in-Use With Confidential Computing

Confidential Computing Capabilities and Services Will be a Competitive Differentiator for Cloud Providers

Most organizations should have mastered by now the first two pillars of data protection – securing data-at-rest and data-in-transit – across their hybrid enterprise environments. The third data protection pillar – securing data-in-use (i.e., protecting and encrypting data in use while in memory and during computation) – has been elusive, but is in the process of being addressed through the transformational motion commonly referred to as confidential computing. 

Technology business leaders are ideally pursuing transformation plans that assume ubiquitous confidential computing availability and data-in-use security will be a cloud-native default within five years.

For many organizations, completing their digital transformation journey has been conditional on being able to categorically ensure that absolutely no one – not a trusted system administrator, the OS developer, the cloud provider, law enforcement, malicious insiders, or an attacker armed with powerful zero-day exploits – can ever secretly access or manipulate the data and intellectual property they entrust to the cloud. Consequently, as the third pillar of data security, confidential computing will increasingly be a prerequisite for any cloud-deployed business application.

The technologies, platforms, and architectures that enable confidential computing have evolved at an astounding pace – especially when compared with the decades it has taken for data-at-rest encryption to evolve from password-protected ZIP files in the early 1990s to today’s enabled-by-default hardware-based encryption locked to the physical compute system, or the continued effort to transition data-in-transit defaults from HTTP to secure HTTPS (preferably using TLS v1.3).

The global pandemic has not held back public cloud advancements and new service offerings in confidential computing. Virtualization infrastructure for confidential computing built atop hardware-based trusted execution environments (TEEs) on servers that implement Intel Software Guard Extensions (Intel SGX) are generally available along with previews of confidential VMs using hardware-based TEE on servers supporting AMD’s secure encrypted virtualization (AMD SEV) extension. In parallel, confidential computing options have begun extending across cloud services to embrace Kubernetes confidential nodes, always encrypted SQL databases, confidential machine learning interfaces, HSM key management, and IoT edge compute.

It can be difficult for security leaders to keep pace with underlying hardware advances and their applicability. For example, the memory integrity protection features of Intel SGX are well suited for highly security-sensitive but small workloads, while AMD SEV is useful for “lift and shift” of existing complex or legacy applications and services without necessarily refactoring existing code. Meanwhile, Intel’s trust domain extensions (Intel TDX) will enable hardware isolated virtual machines (called trust domains), AMD’s secure encrypted virtualization-encrypted state (SEV-ES) will help ensure that guest VMs are encrypted and attestable once they stop running, and many more hardware advances from Intel, AMD, Arm, NVIDIA, etc. that help mitigate new and potentially intrusive memory, compute, and attestation threats will become available via the major cloud providers in the coming year or two.

Clearly, confidential computing is in a transitional period as these new hardware-enabled solutions get adopted and deployed by major cloud providers and their most advanced customers. 

While it is easy to get lost in the hardware-based security feature advances the silicon providers are delivering, the long-term assumption security leaders should be planning for is that the physical infrastructure will verifiably guarantee that enclaved processes, memory, and the data they hold or manipulate will be secure from any and all prying eyes – in particular, the cloud and software stack providers – and that all cloud services (from leading public cloud providers) will operate in a secure data-in-use mode by default. It is reasonable to assume that within five years the term “confidential compute” will become superfluous and an assumed native component of all cloud services.

In the meantime, confidential computing capabilities and services will be a competitive differentiator for the large cloud providers. 

As the underlying hardware advances and public cloud providers extend data-in-use security, integrity, and attestation capabilities across their customer-available services, business technology leaders will need to assess each cloud service individually and assume some short period of cloud-specific lock-in for the custom applications their own business will engineer.

Opportunities ranging from anti-money-laundering to customer analytics within the financial services industries, privacy-preserving collaborative disease diagnostics and drug development within healthcare services, joint intelligence analysis and anti-corruption across government agencies, etc., are a snippet of newly achievable privacy and confidentiality-preserving solutions from organizations adopting cutting edge confidential computing-enabled cloud solutions.

Some enterprises may be content to wait until data-in-use security becomes ubiquitous to complete their digital transformation. While confidential compute capabilities are expanding and new secure cloud services are “fluid” in their evolution, there is a clear window for technology-agile businesses to innovate and partner with their cloud provider to bring new categories of secure products to market ahead of both competitors and regulators.

-- Gunter Ollmann

First Published: SecurityWeek - November 3, 2020

Enterprise Threat Visibility Versus Real-World Operational Constraints

The phrase “assume breach” has been transformational to enterprise security investment and defensive strategy for a few years but may now be close to retirement. 

When the vast majority of information security expenditure was focused on impermeable perimeter defenses and reactive response to evidence-based compromise, it served as a valuable rallying cry for organizations to tool their enterprise for insider-threat detection, adopt zero-trust network segmentation, and pursue widespread deployment of multifactor authentication systems and conditional access controls.

Sizable investments in enterprise-wide visibility should have reversed the much older adage “a defender needs to be right all the time, while the attacker needs to be right only once” into something like “an attacker needs to be invisible all the time, while the defender needs them to slip up only once.” Unfortunately, security operations and threat-hunting teams have found that instead of automatically spotting needles in a haystack, they must now manage haystacks of needles—if they’re properly equipped. For under-resourced security teams (which appears the majority), advances in enterprise-wide visibility have in the best case added hundreds of daily alerts to their never-completed to-do lists.

As security budgets have morphed, a higher percentage of spend has been allocated to increasing visibility on the premise that more threats will be preemptively detected, blocked, and mitigated.

An appropriate analogy for the situation would be installing dozens of video cameras in and around your home with overlapping fields of view and relying on that as the primary alerting mechanism for preventing break-ins. The primary assumption is that someone will be continually monitoring all those video feeds, will recognize the build up and execution of the break-in, and can initiate a response to stop the thief. 

The consequences of such a strategy (by way of continuing the analogy) are pretty obvious:

1. Because 24/7 monitoring is expensive, automated detection is required. Automatic detection comes at the cost of high false-positive rates and baseline tuning; in home CCTV terms, ignoring the rabbits, golf balls, and delivery men that cross a field of vision, while desensitizing movement thresholds and setting up hot zones for alerting. Even rarish false positive events such as lighting strikes during a storm or the shadow of a passing airplane are unfortunately enough to fill an inbox or message tray and result in wariness delays and wasted investigative cycles. To counter the problem, use at least two disparate and independent detection technologies to detect and confirm the threat (for example, CCTV movement zones and a break-glass sensor).
2. Automatic detection without an automatic response limits value to post-break-in cleanup and triage—not prevention. Because of potential false positives, automatic responses also need to be reversible throughout the period of alert response. If CCTV movement and break-glass sensors are triggered, perhaps an automatic request for a patrol car visit is initiated. Meanwhile the original alert recipient can review footage and cancel the callout if it was clearly a false positive (e.g., the neighbor’s kids kicked a ball over the fence and broke a window).
3. Balance between detection and prevention is critical and will change over time. 24/7 CCTV monitoring may serve as a key detection capability, but locking all external doors with deadbolts shouldn’t be neglected. Deadbolted doors won’t stop the future threat of a $50 miniature drone flying down the chimney and retrieving the spare front-door key laying on the kitchen table. Prevention investments tend to be threat reactive, while modern detection technologies tend to be increasingly successful in identifying behavioral anomalies.

“Assume breach” served its purpose in changing the ways organizations thought about and invested in their security technologies (and operational programs). As with many well-intentioned initiatives, the security pendulum may have swung a little too far and now needs a balanced redressing.

Although I think cloud-SIEM and the advanced machine intelligence platforms being wedded to it will eventually meet most organizations’ 24/7 visibility and detection needs, SecOps teams will continue to battle against both alert fatigue and posture fatigue. The phrase I’d like to see the industry focus on for the next five years is “automatically mitigated.”

-- Gunter Ollmann

First Published: SecurityWeek - September 17, 2020

Security Posture Fatigue

As SecOps Teams Increasingly Take on Proactive Risk Reduction, Posture Fatigue Will Grow 

Security operations teams are once again feeling overwhelmed and under pressure. Although advances in cloud SIEM and the fusion of AI alerts, events, and logs has enabled SecOps teams to finally get ahead of common threats and automate much of the day-to-day repetitive investigative work, the rapidly expanding footprint of the digital enterprise has opened the door to a new headache—security posture fatigue.

Many high-performing SecOps teams will inform you that their threat hunting has evolved from searching for a needle in a haystack to managing haystacks of needles. Consequently, the desire to add yet another threat detection tool to an environment that generates yet another alert that needs to be investigated and actioned isn’t high on their product purchase wish list. Organizations are driving hard to consolidate threat detection and protection capabilities by reducing the number of vendors and products and pursuing integrated suite solutions where they can—reducing overall alert noise and triage time.

Although threat detection and response are being tamed, SecOps teams continue to battle enterprise sprawl. Business units and departments are adding new workloads in an increasingly diverse range of environments—public cloud, private cloud, corporate WAN, third-party SaaS platforms, manufacturing floors, CI/CD pipelines, etc.—each of which require a mix of tailored and ad hoc security configuration management, posture monitoring, and policy configuration. As a result, it has become increasingly difficult for SecOps teams and CISO organizations to answer basic questions such as “where are all my assets?” “are we compliant?” and “are we vulnerable to last week’s headline attack?”

To tackle this problem, security policy compliance and posture management is increasingly becoming a centralized function. 

Each environment an enterprise operates and does business in requires tooling for security posture management and risk reduction, and for the past decade, the number of tools that can provide posture metadata, risk assessments, and security policy lapses has grown.

The broad mix of work environments, a wide variety of security posture management products (some of which are decades old), and fragmented tool capabilities has not only resulted in an inundation of security posture alerts but added new dimensions and complexity to risk-reduction orchestration and policy enforcement—causing posture fatigue as SecOps teams are overwhelmed with new and disparate datasets.

More modern work environments have proved to have more capable tools for security configuration management and remedy orchestration. For example, Cloud Security Posture Management (CSPM) has become the poster child for what is possible when managing modern enterprise production environments—and showcases what is technically possible in day-to-day security posture and risk management.

There is increased pressure on vendors to modernize many of the products used in older (but still critical) enterprise environments. Integrated Risk Management (IRM), Enterprise Risk Management (ERM), Vulnerability Assessment Management (VAM), Security Configuration Management (SCM), Application Performance Management (APM), etc., are product categories ripe for consolidation across workload environments as the requirement to “sort the wheat from the chaff” of posture lapses grows.

There is a lot to be learned from how CSPM has advanced the visibility and manageability of security posture management and business risk reduction of enterprise workloads within public cloud environments. The challenge ahead is to gain similar capabilities across the full estate of enterprise operating environments.

As SecOps teams increasingly take on proactive risk reduction, their vocabulary expands from security threats to include posture lapses, and posture fatigue will grow.

-- Gunter Ollmann

First Published: SecurityWeek - July 21, 2020