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

Navigating the Rapid Digital Shift: Ticket on the Bus, Not the Whole Bus

Global Companies’ Evaluation of Cybersecurity Solutions Selection Has Been Steadily Changing 

If it wasn’t already obvious to cybersecurity sales teams, there’s been a sea change for large organizations evaluating and buying new security products to protect their businesses. Responding to COVID-19, transformation plans that enable “work from home” such as Zero Trust identity and access management have been greatly accelerated, while technology refreshes and other capital-intensive plans are being pushed back.

Now, several months into this new operations paradigm, there may be added credence to the adage “in for a penny, in for a pound.” 

Many large companies have successfully navigated the digital shift to most of their workforce working remotely, finding the transition less difficult than first envisaged and achieving higher productivity than anticipated. Because such companies have resolved long-held internal conflicts over the security and integrity of cloud-based business operations, many of those postponed capital-intensive projects are being reviewed with a cloud-enabled, subscription-based lens.

This has several ramifications for cybersecurity vendors—particularly the specialized boutiques and innovative startups looking to quickly capitalize on new security opportunities.

Global companies’ evaluation of cybersecurity solutions selection has been steadily changing over the past couple years. The rapid digital shift of recent months has reinforced the need for change. 

I’d like to offer advice to vendors attempting to reach out and position their new cybersecurity products.

1. “I’ll buy a ticket, not the whole bus.” For decades, startups have looked to the largest companies as the Golden Goose and focused great energies in selling into them. The premise being that by solving a critical problem for them at a very high premium, that will cover the costs of developing an actual solution that can be sold broadly—e.g., the sale will fund my company’s product development. Although there may be a few cases where only a custom-tuned solution is required, many large businesses now prefer to buy a close-enough solution off the rack and work with the vendor as an advisor—not an investor. CISOs are looking at the sustainable list price of the solution and will purchase at a discounted level proportional to their deployment’s scale.
2. “Cost projection is critical.” Although highly versatile and scalable, cloud-based services billing can be difficult to predict—especially if the cybersecurity solution requires multiple third-party and cloud-provider SaaS dependencies. Security owners and budget holders are requiring vendors to provide accurate billing forecast and tiered discount models for the complete solution—models that include all dependent service costs (e.g., log storage analytics, container management). Vendors need to remove as much calculus from the pricing as possible and be prepared for billed services to be pared back if overly optimistic projections exceed the planned budget. Cost discussions have replaced those about cloud solutions prices.
3. “Features must be pre-integrated.” If the product is a feature (which, let’s face it, almost all new startup products are!), recognize it as a feature and don’t position it as a partial solution. As a feature product, integration with the solutions businesses already use is a prerequisite, and sales representatives should lead with the integration and interoperability first. CISOs are looking to shrink their attack surface and simplify the portfolio of products and vendors they rely on, and are increasingly reluctant to take on the task of brokering partnership between vendors as a prerequisite for extracting new protection value. Feature products benefit greatly by being enabled from within a solution provider’s product or marketplace.

On a related note, with the surge to execute day-to-day business operations remotely with a diverse and globally distributed workforce, cybersecurity buying decisions will increasingly factor accessibility, usability, and inclusiveness in solution design and operability. Vendors will be steered toward cloud-standardized accessibility interfaces—enabling visually impaired employees to use screen readers or dexterity-limited users to employ voice-to-text controls—to perform their analysis.

These changes are not unique to the largest enterprise businesses and are trickling down to other educated cybersecurity buyers feeling the same buying pain. Forewarned is forearmed.

-- Gunter Ollmann

First Published: SecurityWeek - June 9, 2020

Tackling the SDLC With Machine Learning

Businesses’ digital transformations continue to show that being relative and competitive are directly tied to the ability to develop and harness software. As the CEO of Microsoft, Satya Nadella, oft says—“every company is now a software company.”

Software flaws that lead to unintentional data leakage, cause breaches, or jeopardize public health or the environment are not only costly but may be terminal to a company’s future. Integrity and security of the software and the development processes behind them have therefore become a critical component of every organization’s success. It is a core reason CISOs are increasingly partnering with DevOps leaders and vigilantly modernizing secure development lifecycle (SDLC) processes to embrace new machine learning (ML) approaches. 

Automated application security testing is a key component of modern SDLC practices and can economically uncover many bugs and potential security flaws with relative ease. Application security testing embraces a broad range of complementary techniques and tooling—such as static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), and runtime application self-protection (RASP). Current best practice security advice recommends a mix of tools from this alphabet soup to mechanically flag bugs and vulnerabilities to mitigate the consequences of unresolved bugs that make it to production systems.

A troublesome consequence of this approach lies with the volume of identified software flaws and the development team’s ability to corroborate the flaw’s risk (and subsequent prioritization). It’s also a problem manifest in organizations that operate bug bounty programs and need to triage bug researchers’ voluminous submissions. Even mature, well-oiled SDLC businesses battle automated triage and prioritization of bugs that flow from application security testing workflows—for example, Microsoft’s 47,000 developers generate nearly 30,000 bugs a month.

To better label and prioritize bugs at scale, new ML approaches are being applied and the results have been very promising. In Microsoft’s case, data scientists developed a process and ML model that correctly distinguishes between security and non security bugs 99 percent of the time and accurately identifies critical, high-priority security bugs 97 percent of the time.

For bugs and vulnerabilities outside automated application security testing apparatus and SDLC processes—such as customer- or researcher-reported bugs—additional difficulties in using content-rich submissions for training ML classifier systems can include reports with passwords, personally identifiable information (PII), or other types of sensitive data. A recent publication “Identifying Security Bug Reports Based Solely on Report Titles and Noisy Data” highlights that appropriately trained ML classifiers can be highly accurate even when preserving confidential information and restricted to using only the title of the bug report.

CISOs should stay informed of innovations in this area. According to Coralogix, an average developer creates 70 bugs per 1,000 lines of code and fixing a bug takes 30 times longer than writing a line of code. 

By correctly identifying security bugs from what is increasingly an overwhelming pile of bugs generated by automated application testing tools and customer-reported flaws, businesses can properly prioritize their development teams’ fix workflow and further reduce application risks to their organization, customers, and partners.

Although much research and innovation are underway in training ML classifier systems to triage security bugs and improve processes encapsulated in modern SDLC, it will be a while before organizations can purchase off-the-shelf, integrated solutions. 

CISOs and DevOps security leaders should be alert to new research publications and what “state of the art” is, and press their automated application software testing tool suppliers to advance their solutions to intelligently and correctly label security bugs apart from the daily chaff.

-- Gunter Ollmann

First Published: SecurityWeek - May 5, 2020