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

Retooling Cyber Ranges

Cloud-based Cyber Ranges Will Change the Future of Training and Certifying Security and DevOps Professionals

A half-decade ago, with much fanfare, cyber ranges were touted as a revolutionary pivot for cybersecurity professionals’ training. Many promises and investments were made, yet the revolution has been slow coming. What may have been a slow start appears to be picking up speed and, with the accelerated adoption of work-from-home business practices, may finally come of age.

The educational premise behind almost all cyber range training platforms is largely unchanged from decades-old war-gaming and capture the flag—nothing beats hands-on practice in refining attack and defense strategies or building responder muscle memory. Carefully scripted threat scenarios guide the training program—often gamifying the experience with mission scores and leaderboards. Many of the interfaces and scenario scene-setting often appear like they came from the imagination of developers who grew up on a diet of 1990’s video games like Command & Conquer; the militaristic adversary overtone is strong yet adds positively to the immersive experience for users.

For many years, gamified security training has required significant infrastructure investment by the provider—investments capable of replicating the complex environments of their customers and the apparatus to generate realistic network traffic. Like the customers that subscribe, cyber-range platforms are undergoing their own digital transformation and moving to the cloud—ephemeral virtual environments, dynamic scaling to the number of participants, global anytime delivery, etc., are all obvious advantages to building and running cyber ranges within the public cloud.

What may be less obvious is how cloud-based cyber ranges will change the future of training and certifying security and DevOps professionals.

Some of the changes underway (and maybe a couple years down the road for mainstream availability) that excite me include:

• At-home cyber-range training and hands-on mastery of operational security tasks and roles. Past cyber-range infrastructure investments necessitated classroom-based training or regional traveling roadshows. Cloud-based cyber ranges can remove the physical classroom and scheduling constraints—offering greater flexibility for employees to advance practical skills at their own pace and balance time investments against other professional and personal commitments. I’m particularly encouraged with the prospect of delivering a level field for growing and assessing the practical skills and operational experiences of security professionals coming from more diverse backgrounds.
• Train against destructive scenarios within your own business environment. As businesses run more of their critical systems within the cloud, it becomes much easier to temporarily spin up a clone, mirror, or duplicate of that environment and use it as the basis for potentially destructive training scenarios. Cyber ranges that apply threat scenarios and gamify the training regime for users across the replicated workloads of their customers significantly increase the learning value and response applicability to the business.
• Shift-left for security mastery within DevOps. Cyber range environments and the scenarios they originally embraced focused on security incident responders and SOC operators—the traditional Blue Team members. With security becoming a distributed responsibility, there is a clear need to advance from security awareness to hands-on experience and confidence for a broader range of cyber-professional. Just as SIEM operations have been a staple of cyber ranges, a new generation of cyber-range platforms will “shift left” to replicate the complex CI/CD environments of their customers—enabling DevOps teams to practice responding to zero-day bugs in their own code and cascading service interruptions, for example.

It will be interesting to see how enterprise SOC leaders will embrace SecOps teams that trained and certified via cyber ranges at home. I’m sure many CISOs will miss the ability to escort senior executives, investors, and business partners around a room filled with security professionals diligently staring at screens of graphs and logs, and a wall of door-sized screens showing global pew-pew animated traffic flows. 

There is a difference between a knowledge certificate and the confidence that comes with hands-on experience—and that confidence applies not only to the employee, but to their chain of command.

The coming of age for cyber ranges is both important and impactful. It is important that we can arm a greater proportion and more diverse range of cyber-professionals with the hands-on practical experience to tackle real business threats. It is impactful because cyber-range scenarios provide real insights into an organization’s capabilities and resilience against threats, along with the confidence to tackle them when they occur.

-- Gunter Ollmann

First Published: SecurityWeek - March 31, 2020

Advancing DevSecOps Into the Future

If DevOps represents the union of people, process, and technology to continually provide value to customers, then DevSecOps represents the fusion of value and security provided to those same customers. The philosophy of integrating security practices within DevOps is obviously sensible (and necessary), but by attaching a different label perhaps we are likely admitting that, despite best efforts, this “fusion” is more of an emulsification.

DevSecOps incorporates discrete security elements and capabilities throughout the development process; “security as code” is the hymn recited by development and security operations teams alike. But when you look closer, the security elements of DevSecOps are discrete, like the tiny immiscible spheres of oil suspended within a tasty vinaigrette — incorporated rather than invisibly entwined within the fabric of DevOps.

Today’s DevSecOps can largely be divided into two core functions: the automated checking and gated prevention of known and potential security flaws throughout the continual integration and continual deployment (CI/CD) workflow, and the operational monitoring and response to security-imbued telemetry generated by the deployment and surrounding protection technologies.

Rightly, we cocoon the applications that flow from our CI/CD workflows with further layers of discrete security tooling to monitor, alert, and ideally protect against broad categories of threats — threats that may be more economically and reliably prevented from outside than within the workflows. Those layers of security almost always operate independently from the application they are defending. This needs to change if we’re to “level up” security and roll DevSecOps back into DevOps.

Although security operations (SecOps) teams are becoming vastly more efficient at managing and responding to the alerts generated by their perimeter, server, and behavioral defense systems, there is a need to incorporate this same telemetry, response workflows, and decision-making into both the CI/CD workflow and the application itself if businesses are to successfully battle advancing threats such as Adversarial AI, data lake tainting, and behavioral poisoning. 

Too many DevSecOps workflows depend upon humans being in them. They’re the “bump in the wire,” and when adversaries switch to newer automated or AI-enabled attack and exploitation modes, system compromise and data breaches will (repeatedly) occur before fixes can be created, defenses tweaked, and patches applied.

The future lies in moving beyond the independent operations of “secure the code” and “protect the app,” and into the realm of self-defending applications.

It sounds grandiose, but there are some core elements and opportunities to progress toward applications that can defend themselves.

• Telemetry from the security technologies that cocoon the application need to be available and consumable to the application and the CI/CD workflow.
• Applications must know when external security tools and monitors suspect or alert when attacked and be capable of responding if advantageous to do so. For example, an application may be capable of natively securely parsing a fund transfer request, but by knowing that a WAF had identified and blocked the previous 12 HTTP POST submissions due to malicious SQL injection payloads for the same session in the past 500 milliseconds, it could leverage the information in handling this 13th transfer and user session — perhaps by deceiving the attacker with a fake and evidentiary traceable response.
• Security technologies need to standardize on nomenclatures, severity, and impact for both threats and behaviors. The new generation of cloud-based SIEM, through normalization of data connectors and telemetry, is capable of providing a degree of (vendor-specific) standardization and is primed for being the source of real-time security telemetry for CI/CD and application consumption. Application development frameworks need to understand this nomenclature and, ideally, come pre-armed with libraries and functions to respond with best practices.
• Increased AI adoption and fusion within the CI/CD workflow can accelerate the pace at which workflows can respond to security telemetry. For example, a server-based security agent identifies a memory overflow and subsequent unwanted process startup, while the SIEM is able to reconstruct the session sequence to highlight the transaction string (0-day exploit). An intelligent and automated CI/CD process should be able to use that information to identify the vulnerable code and correct the logic flaw or bug, and proceed with an update to the live application with a fix — without developer involvement.

Security responsibility must, and will continue to, “shift left.” To enable that, security telemetry needs to be both accessible and incorporated into the application and the DevOps workflow, and the developers themselves must be comfortable and knowledgeable in integrating the information. Better developer tooling — such as secure coding languages and frameworks, accessible best-practice libraries and functions, and smart in-line developer guidance and correctors — will help close the gap.

Rapid advancement of AI and ML technologies and incorporation into the CI/CD workstream will be able to increase the pace of security integration and secure deployment. There is still much work to be done, and subsequently there are great opportunities for innovative companies to add significant value to the process. 

In the meantime, CISOs and DevOps leaders should press hard on technologies and processes that remove the human speed bumps from the CI/CD workflow. Adversaries are advancing at a fast pace in their development of fully automated and autonomous attack engines. Soon, defense and response will be measured in milliseconds, not in days and weeks as it is now.

-- Gunter Ollmann

First Published: SecurityWeek - March 3, 2020

Changing the Disclosure Shame Culture

For Cyber-defense to Progress, We Must Break Through the Cultural Barrier of Breach Disclosure Shame

Although we repeatedly hear that cyber adversaries have an upper hand due to the sharing and rapid dissemination of tools, techniques, and intelligence among like-minded attackers, the hard-earned lessons gained by defenders are tightly closeted — most often under a shroud of shame and reluctantly disclosed, if ever. For cyber-defense to progress, we must break through the cultural barrier of disclosure shame.

Despite most enterprises adopting an “assumed breach” approach to securing their business, the successes and investments that lead to uncovering breaches are too often thoroughly undermined by the perception of having failed to preemptively protect the environment.

Multiple longstanding movements aid the sharing of selective artifacts of an attack – most often those that were successfully thwarted or captured using generic blocking technologies. These artifacts (e.g. malware and phishing samples) and their associated telemetry (e.g. detonation logs) are useful from a threat intelligence perspective and are increasingly consumed with greater agility by both investigative and blocking protection systems, but they can’t communicate the important dimensions needed to help prevent the next novel threat or attack vector. Missing is the technical biopsy of the entire chain of events that resulted in a system compromise – in particular, what defensive or detection apparatus worked and what didn’t.

Security teams gain snippets of insight from defensive failures through public breach disclosures or the investigative reporting that follows large-scale and brand-name hacks. The stigma of past public disclosures causes most companies to go dark when a breach is detected and to resurface months later only after satisfying themselves that similar weaknesses have been internally dealt with – through technology or leadership change. That shroud of darkness is arguably a critical time in which disseminating details is the most valuable to other defenders around the globe.

In closed-door, invite-only forums, there is more willingness to share additional information about security failures – in more detail and in a timelier manner – but they are infrequent and highly localized. In fact, there are many parallels with how TV portrays an Alcoholics Anonymous meeting – e.g., “My name is Beth and I’ve been breached for 6 months …” – with an aura of shame, acknowledgement of past missteps, and hope for future well-being.

New scoring systems coming to market make it easier for organizations to both understand and monitor changes in their own enterprise security ecosystem. At the moment there are as many defense scoring systems as there are vendors that include them, but I believe that they’ll consolidate rapidly this year – most likely following the lead of the largest public cloud providers. It is exciting to meet with CISOs and other security leaders, openly comparing their scores and sharing tips on how they’re looking to improve them. I had not realized that gamification could be such a blessing to defenders.

Although defense scoring lowers the barrier to sharing defensive success insights, it does not yet address the insights gained from learning from others’ failures and the stigma of a breach.

Upon “going dark” after a breach detection, the security products vendors used within the compromised environment are similarly shut out – at precisely the time they can potentially add the most value to both the victim and the wider defensive ecosystem. It is in vendors’ best interest to leverage both their engineering and security research teams to promptly dissect and understand failures in their detection apparatus or missed capabilities in defending any chained or sequenced attack – and CISOs should leverage that deep expertise to complement their internal efforts as soon as they can.

With today’s complex and rapidly changing ecosystem of layered defenses, suite integrations, data connectors, automated response orchestration, policy configurations, and hybrid environments, breach response to a new threat or attack technique is rarely distilled down to adding a new detection signature or firewall rule. 

I thoroughly recommend a war room approach, with technical representatives from the vendors of the security products the organization deployed and had anticipated would directly or indirectly discover and protect against the overall threat. Those vendors should be charged with both optimizing existing product capabilities (that may have been misconfigured, new, or poorly understood) within the compromised environment and, if needed, the coordination and acceleration of engineered updates or feature capabilities to prevent any repeated and related attack. Leverage the R&D expertise of your security vendors – you’ve probably already paid for it!

It should not be a blame game (unless product inadequacies really are to blame!) – rather, the collective team should identify optimal routes to earlier detection and prevention, both short term and long term.

Bringing trusted vendors into the breach equation early on should accelerate a stable and robust threat response. 

The stigma of a breach can be shared with vendors and any associated public shame lessens with rapid threat response. The story of how a CISO and her vendors collectively and dynamically responded to a new threat, and how that knowledge was timely shared and incorporated into their products for all to benefit, is an incredibly strong one.

-- Gunter Ollmann

First Published: SecurityWeek - February 4, 2020

The Changing Face of Cloud Threat Intelligence

As public cloud providers continue to elevate their platforms’ default enterprise protection and compliance capabilities to close gaps in their portfolio or suites of in-house integrated security products, CISOs are increasingly looking to the use and integration of threat intelligence as the next differentiator within cloud security platforms.

Whether thinking in terms of proactive or retroactive security, the incorporation (and production) of timely and trusted threat intelligence has been a core tenant of information security strategy for multiple decades — and is finally undergoing its own transformation for the cloud.

What began as lists of shared intelligence covering infectious domains, phishing URLs, organized crime IP blocks, malware CRCs and site classifications, etc., has broadened and become much richer —  encompassing inputs such as streaming telemetry and trained detection classifiers, through to contributing communities of detection signatures and incident response playbooks. 

Cloud-native security suites from the major public cloud providers are striving to use threat intelligence in ways that have been elusive to traditional security product regimes. Although the cloud can, has and will continue to collect and make sense out of this growing sea of raw and semi-processed threat intelligence, newer advances lie in the progression and application of actionable intelligence. 

The elastic nature of public cloud obviously provides huge advancements in terms of handling “internet-scale” datasets — making short work of correlation between all the industry-standard intelligence feeds and lists as they are streamed. For example, identifying new phishing sites without any user being the first victim, by correlating streams of new domain name registrations (from domain registrars) with authoritative DNS queries (from global DNS providers), together with IP reputation lists, past link and malware detonation logs, and continuous search engine crawler logs, in near real time.

Although the cloud facilitates the speed in which correlation can be made and the degree of confidence placed in each intelligence nugget, differentiation lies in the ability to take action. CISOs have grown to expect the mechanics of enterprise security products to guarantee protection against known and previously reported threats. Going forward, those same CISOs anticipate cloud providers to differentiate their protection capabilities through their ability to turn “actionable” into “actioned” and, preferably, into “preemptively protected and remedied.”

Some of the more innovative ways in which “threat intelligence” is materializing and being transformed for cloud protection include:

• Fully integrated protection suites. In many ways the term “suite” has become archaic as the loose binding of vendor-branded and discrete threat-specific products has transformed into tightly coupled and interdependent protection engines that span the entire spectrum of both threats and user interaction — continually communicating and sharing metadata — to arrive at shared protection decisions through a collective intelligence platform.
• Conditional controls. Through an understanding of historical threat vectors, detailed attack sequencing and anomaly statistics, new cloud protection systems continually calculate the probability that an observed sequence of nonhostile user and machine interactions is potentially an attack and automatically direct actions across the protection platform to determine intent. As confidence of intent grows, the platform takes conditional and disruptive steps to thwart the attack without disrupting the ongoing workflow of the targeted user, application or system. 
• Step back from threat normalization. Almost all traditional protection technologies and security management and reporting tools require threat data to be highly structured through normalization (i.e., enforcing a data structure typically restricted to the most common labeled attributes). By dropping the harsh confines of threat data normalization, richer context and conclusions can be drawn from the data — enabling deep learning systems to identify and classify new threats within the environments they may watch over.
• Multidimensional reputations. Blacklists and whitelists may have been the original reputational sources for threat determination, but the newest systems not only determine the relative reputational score of any potential device or connection, they may also predict the nature and timing of threat potential in the near future — preemptively enabling time-sensitive switching of context and protection actions.
• Threat actor asset tracking. Correlating between hundreds or thousands of continually updated datasets and combined with years of historical insight, new systems allow security analysts to track the digital assets of known threat actors in near real time — labeling dangerous corners of the internet and preemptively disarming crime sites.

With the immense pressure to move from detection to protection and into the realm of preemptive response, threat intelligence is fast becoming a differentiator for cloud operators — but one that doesn’t naturally fit previous sharing models — as they become built-in capabilities of the cloud protection platforms themselves.

As the mechanics of threat protection continue to be commoditized, higher value is being placed on standards such as timeliness of response and economics of disruption. In a compute world where each action can be viewed and each compute cycle is billed in fractions of a cent, CISOs are increasingly cognizant of the value deep integration of threat intelligence can bring to cloud protection platforms and bottom-line operational budgets.

-- Gunter Ollmann

First Published: SecurityWeek - January 14, 2020

How Commercial Bug Hunting Changed the Boutique Security Consultancy Landscape

It’s been almost a decade since the first commercial “for-profit” bug bounty companies launched leveraging crowdsourced intelligence to uncover security vulnerabilities and simultaneously creating uncertainty for boutique security companies around the globe.

Not only could crowdsourced bug hunting drive down their consulting rates or result in their best bug hunters turning solo, it raised ethics questions, such as should a consultant previously engaged on a customer security assessment also pursue out-of-hours bug hunting against that same customer. What if she held back findings from the day-job to claim bounties at night?

With years of bug bounty programs now behind us, it is interesting to see how the information security sector transformed – or didn’t.

The fears of the boutique security consultancies – particularly those offering penetration testing and reverse engineering expertise – were proven unfounded. A handful of consultants did slip away and adopt full-time bug bounty pursuit lifestyles, but most didn’t. Nor did those companies feel a pinch on their hourly consulting rates. Instead, a few other things happened.

First, the boutiques upped the ante by repositioning their attack-based services – defining aggressive “red team” methodologies and doubling down on the value of combining black-box with white-box testing (or reverse engineering combined with code reviews) to uncover product and application bugs in a more efficient manner. Customers were (and are) encouraged to use bug bounties as a “first-pass filter” for finding common vulnerabilities – and then turn to dedicated experts to uncover (and help remediate) the truly nasty bugs.

Second, they began using bug bounty leaderboard tables as a recruitment vehicle for junior consultants. It was a subtle, but meaningful change. Previously, a lot of recruitment had been based off evaluating in-bound resumes by how many public disclosures or CVEs a security researcher or would-be consultant had made in the past. By leveraging the public leaderboards, suddenly there was a target list of candidates to go after. An interesting and obvious ramification was (and continues to be) that newly rising stars on public bug bounty leaderboards often disappear as they get hired as full-time consultants.

Third, bug bounty companies struggled with their business model. Taking a slice of the vendors payments to crowdsourced bug hunters sounded easier and less resource intensive than it turned out. The process of triaging the thousands of bug submissions – removing duplicates, validating proof-of-concept code, classifying criticality, and resolving disparities in hunter expectations – is tough work. It’s also something that tends to require a high degree of security research experience and costly expertise that doesn’t scale as rapidly as a crowdsource community can. The net result is that many of the bug bounty crowdsource vendors were forced to outsource sizable chunks of the triage work to boutique consultancies – as many in-house bug bounty programs also do.

A fourth (but not final) effect was that some consulting teams found contributing to public bug bounty programs an ideal way of cashing in on consulting “bench time” when a consultant is not directly engaged on a commercial project. Contributing to bug bounties has proven a nice supplement to what was previously lost productivity.

Over the last few years I’ve seen some pentesting companies also turn third-party bug bounty research and contribution into in-house training regimes, marketing campaigns, and an engagement model to secure new customers, e.g., find and submit bugs through the bug bounty program and then reach out directly to the customer with a bag full of more critical bugs.

Given the commercial pressures of on third-party bug bounty companies, it was not unexpected that they would seek to stretch their business model towards higher premium offerings, such as options for customers to engage with their best and most trusted bug hunters before opening up to the public or offering more traditional report-based “assessments” of the company’s product or website. More recently, some bug bounty vendors have expanded offerings to encompass community managed penetration testing and red team services.

The lines continue to blur between the boutique security consultancies and crowdsourcing bug bounty providers. It’ll be interesting to see what the landscape looks like in another decade. While there is a lot to be said and gained from crowdsourced security services, I must admit that the commercial realities of operating businesses that profit from managing or middle-manning their output strikes me as a difficult proposition in the long run.

I think the crowdsourcing of security research will continue to hold value for the businesses owning the product or web application, and I encourage businesses to take advantage of the public resource. But I would balance that with the reliability from engaging a dedicated consultancy for the tougher stuff.

-- Gunter Ollmann

First Published: SecurityWeek - December 11, 2019