Subscribe now

Stefano Pasotti, CISO and ICT Manager at DN Automotive Italy, brings a pragmatic perspective to cybersecurity shaped by years of experience across software development, IT leadership, manufacturing, and logistics. In his role, he oversees cybersecurity, infrastructure, and digitalization initiatives across European operations, where technologies ranging from WMS and production planning to EDI and IoT must work securely and reliably.

For Pasotti, effective security is ultimately about making better business decisions. His approach emphasizes measurable risk reduction over flashy tools, practical incident readiness over compliance theater, and clear communication that translates technical risk into business consequences such as production downtime. In this edition of CISO Tips, he shares his principles for evaluating security investments, preparing teams for incidents, working with vendors, and leading security programs with discipline and reflection.

Complete this sentence: “Before you buy any new security tool, first...”

...I ask myself how much it actually reduces our risk percentage, how much it really makes us safer. Is it a necessary move, or just a ‘cool tool’?

What’s one rule you enforce on your team that other teams would find strict?

Document everything. An experience that isn’t written down is an experience lost.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

Training before tools, always. It only takes one wrong click to waste a thousand technology solutions.

What’s one line that works when asking the board or CFO for a budget?

I put risk on the table, not the tool. How much risk is the company willing to take? How much downtime can we afford, and how likely is it to actually happen?

What should a CISO cut from their program tomorrow with zero regret?

Some certifications that only exist for the plaque on the wall. If they change nothing in practice, they’re just time spent — not security.

What’s your 60-second test for whether a vendor pitch is worth your time?

“If they throw around technical jargon at random, or bombard me with overly detailed questions that make no sense at this stage, I know right away they haven’t listened. Same if they show no interest in understanding who we are and what we do before pitching us something: they’re not selling a solution, they’re selling a script.”

What’s one meeting, report, or process you eliminated, and what replaced it?

I rarely eliminate; I prefer to rebuild. The latest case: incident response policies and runbooks that only existed on paper — I rewrote them to be truly operational, not just a compliance exercise.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Stopping to think. Speed is critical, so the temptation is to act immediately — but acting without a moment’s reflection can cause more damage than the incident itself.

What’s one question every CISO should ask their team this week?

If it happened right now, would we actually know what to do, or would we be improvising?”

What’s a phrase or framing you use to translate a technical risk for executives?

I translate everything into production downtime. Once the risk is clear to everyone, then we talk solutions.

What’s your best tip for surviving the CISO role in exactly five words?

Stop, reflect, then take action.

Subscribe now

Subscribe now

Ask a security team to name the least governed system in the enterprise and few will say “the developer laptop.” They should. It changes daily. Extensions, packages, plugins, and AI tooling get assembled on the fly, rarely pass through review, and remain largely invisible to endpoint detection. Bloom Security‘s latest research turns that abstraction into a measurable exposure across roughly half a million downloads and more than 750 extension packs.

The vulnerability is called Extension Resurrection, and it affected both Open VSX and the Visual Studio Code Marketplace. What makes it worth a board-level conversation is not the exploit chain. It is the trust model the exploit chain borrows.

One Install Decision, Ten Unreviewed Consequences

When a developer installs an extension pack, they are not installing one tool. They are accepting a curated list of dependencies, every one of them granted deep access to the filesystem, running processes, and the network.

The pack was reviewed. Its contents were not. Bloom Security identifies that gap between what a user trusts and what actually gets installed as precisely where the attack lives.

Extension packs therefore behave as a risk multiplier. A single approval quietly expands the attack surface by five, ten, or more components that nobody explicitly evaluated. The research is unambiguous about the required posture change: treat extension packs within the same threat model as direct extension installs, and review the bundle manifest rather than the pack name.

Volume Is Working Against Defenders

Scale deserves attention here. In the first six months of 2026, the VS Code Marketplace nearly doubled in size. Between the two marketplaces, roughly 1,400 new extensions ship every single day. AI tooling has let teams move faster than before, and the output is an explosion of new software landing continuously.

Every developer runs at least one extension outside the defaults of their chosen IDE. That baseline was never the interesting part. The interesting part is that the catalog defenders would need to vet is growing faster than any manual review process can absorb.

What the Attack Actually Required

The technical prerequisites were modest, which is the point.

Both marketplaces permitted packs to reference extensions that did not exist. Bloom Security calls those dangling references Shadow Dependencies, and they arise either when a pack is mirrored to Open VSX without one of its bundled components, or when an extension referenced by a live pack is deleted.

Extensions are identified by publisher or namespace paired with an extension ID, so hijacking one means claiming the original publisher or namespace rather than just an available name. Both platforms allowed open registration of those names, including names that published software actively referenced.

Bloom Security’s scan quantified the field. Open VSX: 94 of 321 packs carried a shadow dependency with an unregistered namespace. VS Code Marketplace: 677 of 4,179 packs carried a shadow dependency, 60 of them under an unregistered publisher. Two of those were used for a live proof: prettify-json under mohsen1 on Open VSX, and control-snippets under svipas on the VS Code Marketplace.

Open VSX initially rejected an exact version match because it already held a ghost record from a mirrored manifest. Incrementing the version resolved that instantly, since packs reference bundled extensions by ID without pinning versions.

The Part That Should Worry Risk Owners

Installation was never the only vector. Auto-update configuration for bundled extensions is inherited from the pack, and the default is enabled. Anyone who installed an affected pack in the past, under default settings, could receive attacker-controlled code on a routine update.

Extensions run with Node.js host access. They read and write files, spawn child processes, and reach the network. Bloom Security’s assessment is that an extension is not sandboxed in any meaningful sense with respect to code execution, so a malicious install is functionally remote code execution on the machine.

That machine belongs to a software developer. Source repositories, cloud credentials, deployment pipelines, internal tooling. Applying a deliberately conservative estimate that half of the affected downloads had auto-update on, the research arrives at roughly a quarter of a million compromised developer endpoints within a day.

The Control Set Being Recommended

Bloom Security lists three capabilities security teams need, and none of them are novel. The difficulty is that most organizations lack all three for this surface.

The first is inventory of installed extensions and packs across the organization. The second is visibility into IDE configuration, specifically whether auto-update is enabled and for which extensions, plus whether policy limits installs to a pre-approved list. The third is extension scanning that audits capabilities, security posture, and risk for each installed extension, treated as a continuous process covering every new version rather than a one-time exercise.

For developers, the guidance is narrower. Auto-updated extension packs behave like auto-updates for every extension they bundle. Install once does not mean static forever. Periodically review what the IDE has actually installed, not just what was chosen.

Vendor Response as a Governance Signal

Bloom Security reported to the Eclipse Foundation on February 5, 2026, and to Microsoft via MSRC on February 17, 2026.

Eclipse assigned all at-risk namespaces to the open-vsx account within hours, then implemented a pre-publication check now blocking packs with non-existent bundled extensions and extensions with non-existent dependencies. Triage also surfaced that extension dependencies were vulnerable to the same technique. Bloom Security describes the experience as very positive and points to Open VSX as a model for marketplace response.

Microsoft’s path was longer. MSRC’s first assessment was Moderate severity on the basis that the Visual Studio Marketplace already had publisher resurrection prevention in place. Bloom Security disputed that with video evidence and additional examples of re-registering removed publishers, and the case was reopened. Engineering subsequently confirmed a partial fix from October and stated that prevention had covered admin actions since October and user actions only as of that month. The two stages landed in October 2025 and June 2026 respectively, documented at github.com/microsoft/vsmarketplace/discussions/1708. Microsoft acknowledged the completion arrived after the report. The eight-month interval between stages left real exposure for user-action resurrection, which Bloom Security demonstrated.

The broader lesson does not stop at extensions. The endpoint attack surface expands constantly through installs, updates, configuration drift, and AI tools pulling in fresh dependencies. Bloom Security’s argument is that everything running there needs to be continuously known, vetted, and governed as an ongoing process rather than a periodic audit. Organizations without that visibility, the research concludes, sit a few clicks away from an incident.

Subscribe now

Subscribe now

Cybersecurity leadership is rarely about having the most tools or the most elaborate security program. For Jörg Scheiblhofer, Chief Information Security Officer at ORF, effective security starts with understanding the organization’s requirements, processes, and actual risk before deciding which technologies or controls are needed. His approach emphasizes analytical thinking, consistency, and a clear understanding of the potential impact of security decisions.

In this edition of CISO Tips, Scheiblhofer shares his perspective on making better decisions under pressure, communicating cyber risk to executives through relatable analogies, and avoiding assumptions during critical incidents. From assessing the real situation in the first minutes of an attack to tailoring risk discussions for the board, his advice reflects a practical philosophy: strong cybersecurity requires sound analysis, clear communication, and a human approach.

Complete this sentence: “Before you buy any new security tool, first…”

…you have to think about process and your requirements “

What’s one rule you enforce on your team that other teams would find strict?

There are no exceptions on suspicion without an analytical basis and certainly no general exceptions.

What’s one line that works when asking the board or CFO for a budget?

It is not a single sentence; rather, it is a presentation, tailored to the target audience, of the risks that exist or may arise if measures are not implemented.

What’s your 60-second test for whether a vendor pitch is worth your time?

Has he dealt with his potential customer?

What’s one meeting, report, or process you eliminated, and what replaced it? -

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Accurately assessing the actual situation. In the heat of the moment, this is often overlooked. What’s one question every CISO should ask their team this week?

What’s a phrase or framing you use to translate a technical risk for executives?

I like to use the creation of analogies from everyday life. In a way, a language in pictures, so that management can imagine something better.

What’s your best tip for surviving the CISO role in exactly five words?

1.) remain consistent 2.) adopt an analytical approach 3.) tailor communication to the target audience 4.) assess the risk and potential damage 5.) remain human

More tips from the series:

• CISO Tips: Maurizio Imperadore on Resilience, Identity and Cutting Security Noise

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

Subscribe now

Subscribe now

Cybersecurity companies often reach an inflection point when technology validation gives way to the harder task of building a repeatable commercial engine. For Reclaim Security, that stage is arriving as the company seeks to expand adoption of its approach to automated exposure remediation.

The company has appointed Stephen Wadsworth as Vice President of Sales, giving the veteran cybersecurity sales executive responsibility for Reclaim’s U.S. go-to-market operation. Based in Boston, Wadsworth brings nearly two decades of experience building sales organizations at security companies, including several that were later acquired.

His career includes an early sales leadership role at Luminate Security, which was acquired by Symantec, and most recently leading sales at Entitle through its acquisition by BeyondTrust. He has also held leadership positions at Threat Stack, Banyan Security and Cyolo.

For Reclaim, the move comes at a time when the company is seeking to capitalize on enterprise demand for technologies that can do more than identify security problems.

The Remediation Gap

The security industry has become increasingly effective at finding exposures. The resulting challenge is that security teams can be left with large inventories of issues requiring attention, even as the tools generating those findings continue to improve.

Reclaim has built its platform around addressing that gap. Its AI Security Engineer continuously discovers exposures across endpoint, email, identity, browser and cloud environments, then plans business-aware fixes and executes them.

The company describes its approach as preemptive exposure remediation, with the technology designed to operate across an organization’s existing security stack. Instead of adding another dashboard, Reclaim aims to make the security tools enterprises already own more effective by helping turn findings into implemented fixes.

Wadsworth sees that distinction as increasingly important to security leaders.

“I’ve spent my career skating to where the puck is going,” said Wadsworth. “CISOs don’t need more security tools, they need more value from what they already pay for. Every CISO I’ve spoken to in the last 6–12 months is tired of being told they have more problems to fix. The market is hungry for outcomes. As adversaries increasingly abuse frontier models at scale, continuous, real-time prevention needs to be the focus — and Reclaim is built to turn findings into implemented fixes without disruption.”

Why Wadsworth’s Background Matters

The new sales chief arrives with a résumé closely tied to emerging cybersecurity companies moving toward larger strategic outcomes.

At Luminate Security, Wadsworth was an early sales leader before the company was acquired by Symantec. At Entitle, he most recently led sales before its acquisition by BeyondTrust. His experience also spans Threat Stack, Banyan Security and Cyolo.

That background is relevant to Reclaim as it builds its U.S. revenue operation. The company is not simply adding a sales executive to an established business; it is looking to scale commercial momentum around a category it believes is becoming increasingly important to enterprise security teams.

“Stephen has built the sales organizations behind some of the most consequential security companies of the last decade,” said Barak Klinghofer, co-founder and CEO of Reclaim Security. “The industry has spent ten years getting better at finding and prioritizing exposures and barely moved on fixing them. Visibility without remediation is noise. With Stephen leading sales, we’re scaling the team that fixes what everyone else only finds.”

Reclaim’s Next Growth Phase

The appointment follows a period of funding and customer momentum for Reclaim. In March 2026, the company announced a $20 million Series A led by Acrew Capital, with participation from QP Ventures and Ibex Investors, bringing its total funding to $26 million.

Reclaim has also published customer results involving Telit Cinterion, Pine Gate Renewables, Competitive Power Ventures and Aqua Security, among others. The company says its customers use the platform to turn lists of findings into implemented fixes, typically demonstrating value within a 10-day proof of value.

That customer proposition sits at the center of Reclaim’s growth strategy. Rather than asking enterprises to add another layer of security visibility, the company is positioning remediation as the outcome that matters.

Wadsworth’s appointment gives Reclaim an executive whose previous experience includes building sales organizations during pivotal moments for security companies. His immediate task will be to translate that experience into growth for a company betting that the next evolution of exposure management will be measured less by what security teams discover and more by what they successfully eliminate.

Subscribe now

Subscribe now

Maurizio Imperadore, Head of the Cybersecurity Team at Connect S.p.A., brings a network engineering background to the CISO role, with experience spanning telecommunications, network design, Cisco and HP systems, and Session Initiation Protocol (SIP). His approach to cybersecurity is grounded in operational resilience: making the most of existing security investments, maintaining strong identity controls, and ensuring security decisions are tied to business continuity.

In this edition of CISO Tips, Imperadore shares practical lessons on where security teams should focus their time and resources. From enforcing zero exceptions on MFA to replacing lengthy risk reports with a single-page executive dashboard, his advice centers on reducing noise, communicating risk in financial terms, and building a security program that protects the operations the business depends on most.

Before you buy any new security tool, first…

Ensure you are fully utilizing the native security capabilities of your existing stack.

What’s one rule you enforce on your team that other teams would find strict?

Zero exceptions on MFA and identity verification, even for emergency admin actions.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

The 80/20 rule: 80% on core operational resilience and visibility, 20% on new security innovation.

What’s one line that works when asking the board or CFO for a budget?

“This isn’t an operational expense; it’s the cost of keeping our core revenue streams online.”

What should a CISO cut from their program tomorrow with zero regret?

Outdated annual compliance training that tick boxes without changing user behavior.

What’s your 60-second test for whether a vendor pitch is worth your time?

If they can’t clearly articulate the specific problem they solve without using buzzwords in the first minute.

What’s one meeting, report, or process you eliminated, and what replaced it?

Eliminated lengthy monthly risk slide decks and replaced them with a dynamic single-page executive dashboard.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Pausing to establish clear incident roles and dedicated communication channels before touching systems.

What’s one question every CISO should ask their team this week?

“Which alert or process is generating the most noise and wasting your time?”

What’s a phrase or framing you use to translate a technical risk for executives?

Translating technical vulnerabilities directly into financial downtime: “If X fails, core operations stop for Y hours at a cost of $Z.”

What’s your best tip for surviving the CISO role in exactly five words?

Prioritize relentlessly, delegate, rest daily.

More tips from the series:

• CISO Tips: Jigar Shah on Buying Fewer Tools, Building More Trust

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

Subscribe now

Subscribe now

For many security leaders, the biggest challenge isn’t keeping up with the latest threats; it’s ensuring cybersecurity remains aligned with business priorities. Jigar Shah, Chief Information Security Officer at Medusind, believes the most effective CISOs are those who focus less on accumulating security technologies and more on solving real business problems. Drawing on more than two decades of leadership across healthcare, financial services, banking, retail, and consulting, Shah has built his career around connecting cybersecurity, technology, business strategy, and governance.

In this edition of CISO Tips, Shah shares the principles that shape his leadership approach, from evaluating vendors based on business outcomes rather than product features to eliminating “security theater” that adds complexity without reducing risk. He also explains why trust, not technology, is the foundation of every successful security program, and why CISOs should spend far more time preventing tomorrow’s incidents than reacting to today’s.

Complete this sentence: “Before you buy any new security tool, first...”

“...understand the business problem you’re trying to solve.”

Technology should never drive strategy. If you can’t explain the business outcome in one sentence, you probably don’t need another security tool.

“Buy fewer tools. Solve more problems.”

What’s one rule you enforce on your team that other teams would find strict?

“Never bring me a security problem without at least one business-focused solution.”

I don’t want my team to be known for just identifying risks. I want them to be known for enabling the business safely.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

I follow a simple rule: 80% enabling the business, 20% fighting fires.

If I’m spending more time reacting than enabling, we’re investing in symptoms instead of resilience. Spend 80% preventing tomorrow’s incidents or issues that can become an incident and 20% responding to today’s.

What’s one line that works when asking the board or CFO for a budget?

I’m not asking you to fund cybersecurity; I’m asking you to protect the business strategy you’ve already approved. That changes the conversation from cost to business enablement.

What should a CISO cut from their program tomorrow with zero regret?

Security theater. Anything that looks impressive but doesn’t measurably reduce risk or improve resilience. Examples include reports nobody reads, meetings without decisions, and controls that create more friction than value.

“If it only checks a box, cut it.”

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask three questions:

1. What business problem do you solve?

2. Can you prove measurable outcomes? Give an example of how you turned things around for your customers?

3. Why are you different from the ten vendors I met this month?

If they answer with features instead of outcomes, the meeting is probably over.

“Features sell products. Outcomes earn meetings.”

What’s one meeting, report, or process you eliminated, and what replaced it?

I eliminated long weekly status meetings. We replaced them with a live dashboard and a 15-minute decision meeting. The goal isn’t to exchange information. The goal is to make decisions and have an action plan with outcomes.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Defining who’s making decisions. Everyone starts investigating. Very few establish clear incident command. Without decision ownership, technical excellence becomes organizational chaos.

What’s one question every CISO should ask their team this week?

“If you were attacking us tomorrow, where would you start?” It changes the conversation from compliance to adversarial thinking.

Alternative: “What are we doing today simply because we’ve always done it?”

What’s a phrase or framing you use to translate a technical risk for executives?

I rarely talk about vulnerabilities. I ask: “What happens to revenue, customers, operations, or reputation if this control fails?” Executives don’t invest in CVEs. They invest in protecting business outcomes. I frame it in business results, risks, and revenue.

What’s your best tip for surviving the CISO role in exactly five words?

“Build trust before a crisis happens.” Because that’s really the essence of the CISO role. Technology changes. Threats evolve. But the ability to build trust with executives, employees, customers, regulators, and your team is what ultimately determines your success.

More tips from the series:

• CISO Tips: Andy Curtis on Turning Cybersecurity Into Business Risk Decisions

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

Subscribe now

Subscribe now

The software supply chain has become one of cybersecurity’s most attractive targets, largely because attackers no longer need to compromise thousands of organizations individually. Instead, infiltrating a single trusted dependency can create a ripple effect across countless development environments. That scenario played out this week when Upwind became the first to publicly report a malicious release of the widely used npm package Keyv, warning developers that the compromise had the potential to impact a massive portion of the JavaScript ecosystem.

The discovery centered on keyv@6.0.0, a malicious version of one of npm’s most heavily used packages. With approximately 154 million weekly downloads, Keyv serves as a core dependency for thousands of JavaScript applications, making any compromise particularly significant. Upwind’s findings prompted immediate guidance for organizations to remove the affected version and investigate whether sensitive credentials had been exposed.

A Malicious Update Hidden Inside a Trusted Package

According to Upwind, the compromised release introduced a previously unseen preinstall hook that executed automatically during installation. Rather than changing the package’s expected functionality, the attackers inserted an obfuscated loader designed to run before developers ever began using the library.

The loader downloaded the Bun runtime from GitHub Releases before launching a bundled payload capable of harvesting credentials from developer workstations and CI/CD environments. Among the targeted secrets were AWS credentials, GitHub tokens, npm authentication tokens, and HashiCorp Vault credentials, giving attackers a potential pathway into both development infrastructure and cloud environments.

“What makes this incident particularly significant is the package’s reach,” Upwind wrote in its public disclosure. “With approximately 154 million weekly downloads, keyv is a foundational dependency used across thousands of JavaScript projects, dramatically increasing the potential blast radius of the compromise.”

That reach transformed what could have been an isolated package compromise into an incident with ecosystem-wide implications.

The Attack Expanded Beyond Keyv

As researchers continued analyzing the incident, evidence emerged that the campaign had spread beyond the original Keyv release. Multiple malicious package versions were identified across the npm ecosystem, suggesting that stolen publishing credentials enabled attackers to distribute poisoned releases through additional packages.

Because package versions and “latest” tags changed rapidly as maintainers responded, security experts advised organizations to inspect their resolved dependency versions, lockfiles, and software bills of materials rather than relying solely on package registry listings.

The malware reportedly went well beyond credential theft. Analysis indicated it could collect authentication tokens, cloud credentials, private keys, and other sensitive information from developer machines and CI/CD runners. Some reports also described functionality capable of republishing compromised packages using stolen npm publishing access, increasing the possibility of automated propagation throughout the ecosystem.

Although the total number of affected packages continued evolving throughout the response, the campaign demonstrated how quickly attackers can leverage trusted software distribution channels once publisher credentials are compromised.

Trust Alone Is No Longer a Security Strategy

One of the more concerning aspects of the incident is that the compromised package reportedly passed through legitimate software release workflows.

Modern software supply chain protections, including provenance and build attestations, can verify how software is built, but they cannot always determine whether malicious code entered the development pipeline before those trusted processes began. As a result, organizations increasingly need visibility into dependency behavior—not just whether software was signed or built correctly.

The incident also reflects a broader shift in attacker strategy. Instead of focusing exclusively on exploiting deployed applications, threat actors are increasingly targeting developer tools, package managers, and build environments where a single successful compromise can reach thousands of downstream users.

A Reminder That Popular Packages Are Valuable Targets

For organizations using Keyv, Upwind urged immediate action: remove keyv@6.0.0, pin dependencies to a verified clean version, rotate credentials if the malicious release was installed, and review CI/CD pipelines, lockfiles, and SBOMs for exposure.

“This incident is another reminder that highly trusted, high-volume dependencies remain prime targets for supply-chain attackers-and that a single malicious release can have ecosystem-wide consequences,” Upwind said.

The discovery serves as another reminder that software supply chain security extends beyond vulnerability management. Even trusted, widely adopted open-source components can become attack vectors when release pipelines or publisher credentials are compromised. By identifying the malicious Keyv release early, Upwind’s disclosure highlighted both the speed at which these campaigns can unfold and the importance of continuously monitoring the behavior of software dependencies, not just the software itself.

Subscribe now

Subscribe now

Andy Curtis is an experienced cybersecurity leader and CISO with a background in information security implementation, architecture, and strategic security programs across government, finance, and enterprise environments. As CISO at Gadget Access, he has worked across frameworks including ISO 27001, NIST, and Essential Eight, helping organizations strengthen their security posture while aligning cyber initiatives with broader business priorities. His approach combines hands-on technical expertise with a strong understanding of risk, governance, compliance, and the realities of operating security programs at scale.

In this edition of CISO Tips, Curtis shares a practical perspective on making cybersecurity more effective by connecting technical decisions to measurable business outcomes. From avoiding unnecessary security-tool sprawl and translating vulnerabilities into executive-level risk, to testing incident response plans and proving that backups can actually support recovery, his advice centers on one core principle: security teams should focus less on collecting tools and metrics and more on reducing material risk. For Curtis, that means learning to communicate in the language of business, making informed trade-offs, and ensuring that cybersecurity decisions ultimately support the organization’s ability to operate and recover.

Complete this sentence: “Before you buy any new security tool, first...”

...prove it will reduce a material risk—and prove you can operate it.

The license fee is only the admission price. The real cost includes implementation, integration, data ingestion, training, tuning, support, additional infrastructure, operational headcount and the time required to investigate whatever the new dashboard turns red.

I am a supporter of best-of-breed technology when an organization can afford best-of-breed integration and operations. Otherwise, you can end up with several excellent products collaborating mainly through their invoices.

Sometimes a well-integrated platform delivers a better overall outcome than a collection of individually superior tools with gaps between them. Equally, consolidating everything onto one platform simply because the vendor has an attractive bundle can introduce lock-in and concentration risk. The right answer depends on coverage, interoperability, operational maturity and the risk being treated—not which logo appears highest on an analyst diagram.

A vendor-sponsored 2025 survey of 1,000 executives found that participating organizations were using an average of 83 security solutions from 29 vendors. That does not prove platforms are always better, but it does confirm that integration overhead is not something CISOs have collectively imagined after too much coffee.

The CISO’s job is not to assemble the most impressive security-tool collection. It is to achieve the greatest sustainable reduction in risk for the money available.

What’s one rule you enforce on your team that other teams would find strict?

Everyone in the security team must be able to explain their work in business, executive, and risk language.

I do not expect every analyst or engineer to become a miniature CFO. I do expect them to understand the business service they are protecting, the risk scenario they are changing, the consequence of doing nothing, and the decision required from management.

“We have 4,700 vulnerabilities” is information.

“Three internet-facing vulnerabilities create a credible path into the customer payments environment, and the remediation owner needs an approved outage before Friday” is decision support.

A technical finding without business context is unfinished work.

This is not about dumbing down the technical truth. It is about expressing that truth in the operating language of the audience. Executives generally think in terms of objectives, exposure, obligations, trade-offs, money, customers and accountability. Security professionals should be able to move between those concepts and the technical detail without losing accuracy in either direction.

Current ASD guidance explicitly treats business acumen, communication and relationship-building as core CISO capabilities, and expects cyber reporting to translate security issues into operational, financial and legal risk. I apply that expectation across the team rather than reserving it for whoever attends the board meeting.

CVSS 9.8 may be technically correct. It is rarely a complete executive sentence.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

My starting ratio is 50:50.

Roughly half of the program should be driven top-down by material business risks: critical services, crown-jewel data, regulatory obligations, credible threat scenarios and the consequences the organization genuinely cannot tolerate.

The other half should be driven bottom-up by operational reality: unsupported systems, excessive privileges, weak configurations, failing backups, poor asset visibility, incomplete logging and all the low-hanging fruit that has somehow remained on the tree for six budget cycles.

The top-down half prevents the security team from becoming extremely efficient at fixing the wrong things. The bottom-up half prevents the enterprise risk register from becoming a beautifully formatted description of controls that do not actually work.

NIST CSF 2.0 reinforces this linkage: practitioners implement and measure risk treatment activities, while executives integrate cyber risk information with the organization’s wider enterprise risk decisions. Both views are necessary because neither strategy nor telemetry is sufficient by itself.

I use industry spending benchmarks and breach-cost studies as reasonableness checks, not as allocation formulas. “Our peers spend 12 percent” does not tell me whether our identity architecture is sound, whether our backups restore or whether half the estate is running on something last patched during the Howard government.

The ratio is a compass, not a religion. It should move as risks, maturity and business priorities change. Incidents, in particular, have very little respect for resource-allocation models.

What’s one line that works when asking the board or CFO for a budget?

“It is cheaper than one material breach every five years.”

That line gets attention. It does not, by itself, earn approval.

The next slide needs to contain the arithmetic: the credible scenario, the business services affected, the potential outage, the likely response and recovery cost, the customer and regulatory consequences, and how much the proposed investment will reduce either the likelihood or the impact.

The argument should not be, “Cyber incidents are expensive, therefore approve everything in my spreadsheet.” It should be, “Here is a plausible loss scenario, here are the available treatment options, here is what each option costs, and here is the residual exposure under each choice.”

IBM’s 2025 study reported a global average breach cost of US$4.4 million across the organizations studied. That is useful context, but a generic worldwide average is not a substitute for understanding your own economics. A CFO should see the potential interruption to your services, your revenue, your customers and your obligations—not an impressive-looking number borrowed from somebody else’s breach.

Fear may secure a meeting. Credible options, quantified assumptions and transparent trade-offs secure a budget.

What should a CISO cut from their program tomorrow with zero regret?

Raw technical reporting to executives who cannot reasonably act on it.

I would immediately cut the 40-page reports filled with vulnerability counts, firewall events, malware detections, phishing statistics, and screenshots from security products. That information may be valuable to security operators, engineers and control owners. It is usually not useful in its raw form to a board or executive committee.

Executive reporting should answer a smaller set of harder questions:

What important business service is exposed? What is the credible scenario? Is the exposure increasing or decreasing? Are the relevant controls working? Who owns the treatment? What decision or intervention is required, and by when?

The underlying technical evidence should still exist. It should simply be presented at the level where someone can use it.

AICD guidance recommends that board reporting go beyond isolated technical measures and traffic lights to include risk outcomes, relevant threats and trend information. ASD guidance similarly expects reporting to be structured around business functions and to cover risk profiles, key systems, uplift activity, incidents and expected returns on security investment.

A board pack is not a SIEM export wearing a tie.

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask one question:

“In one minute, explain the problem you believe we have, the measurable outcome you will improve, and what we can stop doing if your product works.”

A good vendor will have asked enough questions to understand the environment, the existing controls, the operating model, the constraints and the outcome we are trying to achieve.

They will also be able to discuss implementation effort, dependencies, staffing requirements, data quality, integration limitations and where their product is not the answer.

A weak vendor will respond with the company origin story, three analyst quotations, the phrase “single pane of glass” and an urgent announcement that artificial intelligence has changed everything since Tuesday.

I am also interested in whether the proposed solution replaces or simplifies anything. Adding one more console, agent, data lake, workflow and set of alerts is not necessarily an improvement simply because the demonstration contains a colorful attack graph.

Current ASD procurement guidance emphasizes supplier transparency, security track record, lifecycle considerations and clear allocation of responsibilities between customer and supplier. Those are much better indicators of a sustainable relationship than the smoothness of the demonstration environment.

Any vendor can demonstrate a dashboard. The grown-up conversation is about the operating model.

What’s one meeting, report, or process you eliminated, and what replaced it?

I eliminated the vulnerability meeting that consisted of security reading scanner results aloud to people who were quietly reconsidering their career choices.

It was an activity meeting rather than a risk meeting. We could spend an hour discussing thousands of findings without answering the most important question: which weaknesses create a credible path to material business impact?

I replaced it with an application and business-service risk review.

Instead of beginning with vulnerability volume, we begin with business criticality, internet exposure, sensitive data, identity and privilege pathways, known exploitation, exploit probability, compensating controls, remediation ownership, and trend. The scanner results still provide evidence, but they no longer dictate the agenda.

This matters because no single technical score represents organizational risk. FIRST’s EPSS estimates the probability that a vulnerability will be exploited, but explicitly warns that it is not a complete risk score. Asset purpose, value, accessibility, controls and potential impact must still be considered.

We use RAG reporting because it gives executives a rapid view of hotspots and creates some healthy competition between teams. But RAG is navigation, not analysis. Green is not a control, and red is not a diagnosis. A red customer-payment platform and a red internal test server are not equivalent merely because PowerPoint has assigned them the same shade.

The new discussion is not, “Who has the most vulnerabilities?”

It is, “Which application is most likely to hurt us, who owns the response, and is the exposure moving in the right direction?”

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Activating the business response, rather than only the technical response.

Technical teams quite reasonably begin containing the threat, collecting evidence and working out what happened. But a significant incident also needs an incident commander, a decision log, a reliable communications channel and early engagement from the people responsible for legal, communications, business continuity, critical services and executive decisions.

Someone should also be given explicit responsibility for protecting and validating the recovery path. That does not mean immediately restoring systems or connecting backup infrastructure to a potentially compromised environment. It means establishing whether the backups are isolated, current and likely to be usable; whether the associated credentials may be compromised; and whether there is a clean recovery path available when it is needed.

Backups are frequently treated as a magic incantation: somebody says, “We have backups,” and everyone feels better. The useful question is whether we can restore the right services, from trustworthy data, within a timeframe the business can survive.

ASD guidance emphasizes enacting the incident response plan once an incident is identified, while its continuity guidance highlights the need to maintain communications and critical business functions when normal systems are unavailable.

The SOC can contain malware. It cannot, by itself, authorize customer communications, decide whether payroll outranks email for recovery, or explain the situation to the regulator.

What’s one question every CISO should ask their team this week?

“When did we last prove, in practice, that our incident response and business continuity plans work together?”

Not when were they last reviewed.

Not when did somebody update the document footer.

When were they last road-tested under realistic conditions, involving the people, suppliers and decision-makers who would actually be required during an incident?

A meaningful exercise should test decision authority, escalation paths, out-of-band communications, executive availability, legal and regulatory thresholds, supplier contacts, manual business workarounds, backup restoration, service-recovery priorities and the assumptions behind recovery time and recovery point objectives.

It should also expose awkward practical details. Are the emergency contact details stored somewhere accessible when email is down? Can the crisis team collaborate without using the potentially compromised corporate environment? Does the person named as incident commander still work here? Can the backup be restored, or has the organization merely been paying to store it very carefully?

Current ASD guidance requires incident management policies and associated response plans to be exercised at least annually, and separately expects boards or executive committees to participate in planning and exercises for major cyber incidents. For a critical or rapidly changing environment, annual testing should be treated as a floor rather than an aspiration.

A tabletop exercise that ends with everyone congratulating themselves is often just a meeting with a plot.

What’s a phrase or framing you use to translate a technical risk for executives?

I use a structure like this:

“This creates a credible pathway to [critical service] being unavailable or compromised for [period], affecting [customers, operations or data], with a plausible financial impact of [$X–$Y]. We can reduce the likelihood or duration through [action] at a cost of [$Z]. The decision required is [choice].”

That framing translates the technical condition without hiding it. It connects the weakness to a business promise, explains the plausible scenario, acknowledges uncertainty, quantifies the potential consequence and makes the decision explicit.

I also try to make “reputational damage” less abstract. Reputation is not a mysterious cloud that descends after an incident. It can appear as customer attrition, reduced conversion, lost bids, delayed sales, increased support demand, regulatory scrutiny, partner concern or prolonged executive distraction. Where possible, I connect reputation to those observable commercial and operational effects.

The use of ranges is important. Cyber quantification should improve decision-making, not manufacture false precision. Saying the impact is plausibly between $3 million and $8 million, based on stated assumptions, is often more credible than claiming the answer is exactly $5,421,763 because a spreadsheet contains several decimal places.

Both ASD and NIST expect cyber risk information to support broader organizational risk and investment decisions rather than remain isolated in specialist terminology.

Executives do not need a guided tour of the CVE. They need to know which promise to customers it could break.

What’s your best tip for surviving the CISO role in exactly five words?

Learn to talk executive risk.

More tips from the series:

• CISO Tips: Carlos García Batista on Turning Cybersecurity Into Operational Resilience

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

Subscribe now

Subscribe now

For Carlos García Batista, cybersecurity is ultimately about protecting the continuity of essential services. As CISO and Information Security Officer for the Directorate General of Emergencies within the Gobierno de Canarias, he operates at the intersection of critical infrastructure protection, emergency response, operational resilience, and regulatory compliance. His responsibilities include coordinating cybersecurity across technical and operational environments, working with authorities on incident management, and helping ensure that essential services remain secure and available when they are needed most.

That perspective shapes a pragmatic approach to security leadership, one grounded in ownership, accountability, and resilience rather than simply accumulating more tools and controls. From questioning whether a security investment actually reduces operational risk to establishing clear command structures during incidents, García Batista emphasizes the importance of turning cybersecurity into actionable decisions. In this edition of CISO Tips, he shares practical guidance on everything from evaluating vendors and securing privileged access to communicating risk with executives and knowing which security activities are no longer worth the effort.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first define the operational risk you are trying to reduce, who will own the tool, who will operate it, and what decision it will help you make.

A tool without ownership becomes another unmanaged asset.

What’s one rule you enforce on your team that other teams would find strict?

No privileged access without a clear purpose, a named owner, traceability, and a review date.

Access should never be granted just because “it may be useful someday.” In security, convenience without control becomes risk very quickly.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

I try to keep a practical balance between prevention, detection, response, and resilience.

If most of the effort goes only into buying preventive controls, the organization may look protected but still be unable to detect, respond, or recover properly. For critical services, resilience deserves budget, time, and executive attention.

What’s one line that works when asking the board or CFO for a budget?

“This is not only a cybersecurity investment; it is an operational continuity investment.”

That framing usually works because it connects security to service availability, institutional responsibility, and business or public-service impact.

What should a CISO cut from their program tomorrow with zero regret?

Security activities that generate reports but do not generate decisions.

If a report, meeting, metric, or control does not help reduce risk, improve visibility, assign responsibility, or support a decision, it should be simplified, automated, merged, or removed.

What’s your 60-second test for whether a vendor pitch is worth your time?

I ask three questions:

What specific risk does this reduce?

How will it integrate with what we already have?

Who in my team will operate it on a bad day?

If the answer is vague, the pitch is not mature enough.

What’s one meeting, report, or process you eliminated, and what replaced it?

I try to eliminate meetings that only exist to exchange information that could have been documented beforehand.

They should be replaced by short, evidence-based operational reviews: what changed, what risk increased, what decision is needed, who owns the next action, and by when.

Security governance should create clarity, not ceremony.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

They often skip defining the incident commander and the decision-making channel.

Many teams start investigating immediately, but without clear coordination, roles, and communication discipline. In an incident, technical work matters, but command structure matters just as much.

What’s one question every CISO should ask their team this week?

“What are we currently accepting as normal that is actually a risk?”

That question usually reveals technical debt, informal exceptions, undocumented dependencies, weak ownership, or processes that only work because one person knows how to keep them alive.

What’s a phrase or framing you use to translate a technical risk for executives?

I translate technical risk into operational consequence.

Instead of saying, “We have a vulnerability in this system,” I prefer to say, “If this fails or is compromised, this service may be unavailable, this decision may be delayed, or this operational capability may be affected.”

Executives need to understand impact, not just threat language.

What’s your best tip for surviving the CISO role in exactly five words?

Govern calmly, document, prioritize, breathe.

More tips from the series:

• CISO Tips: Sergey Tairyan on Thinking Like an Attacker and Leading Through Cyber Risk

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

Subscribe now

Subscribe now

The traditional corporate endpoint was built around a simple premise: organizations knew which devices employees used and could largely control the software installed on them. That model is becoming harder to maintain as AI agents, browser extensions, MCP servers and code packages become embedded in daily work.

Bloom Security is launching with the goal of addressing that growing complexity. The Tel Aviv-based company has emerged from stealth with a $20 million seed round led by Glilot Capital Partners, with participation from Ten Eleven Ventures (1011vc), Okta Ventures, and Runtime Ventures. Axios first reported about the company’s launch and funding.

The funding also includes prominent angel investors, including the founders of Dig Security, Demisto, Snyk and Talon. Bloom said its platform is already deployed at dozens of large enterprises across the United States and Europe, giving the startup an early foothold as companies look for ways to manage the security implications of rapid AI adoption.

The New Software Perimeter

The challenge Bloom is targeting goes beyond the traditional definition of endpoint security. Employees are increasingly assembling their own software environments through AI tools, extensions and other applications, while browsers, IDEs and AI agents introduce marketplaces that can expand the number of tools operating on a corporate device.

For security teams, the issue is not necessarily that these tools are malicious. Instead, legitimate software can become a source of risk because of how it is configured, what permissions it receives or how it interacts with other systems and data.

“In the AI era, the employee device is no longer just a managed endpoint,” said Itay Keren, Co-Founder and CEO of Bloom Security. “Every endpoint is now running software no one reviewed, connecting to services no one provisioned.”

Bloom points to a range of potential risks, including AI agents with incorrect configurations, plugins that have excessive data permissions, screen recorders operating on executive devices and code libraries that pull from untrusted sources. These scenarios can create attack paths that traditional endpoint detection and response products may not have been designed to identify or manage.

“As AI adoption accelerated, it became clear that existing endpoint controls were not designed for this new reality,” Keren added. “Security teams need a way to understand, govern, and control modern tools without disrupting how employees work.”

Understanding Risk in Context

Bloom Security’s platform is designed to give organizations a broad inventory of what is running across their endpoints, including software, tools, extensions and code. It also examines how those components interact with data and systems and analyzes supply-chain risk, configurations and permissions.

The company is taking a contextual approach to determining exposure. Its premise is that the risk associated with a particular application can vary significantly depending on the employee using it and the environment in which it operates.

“The same tool can be completely acceptable on one endpoint and high-risk on another,” said Ofir Balassiano, Co-Founder and Chief Product Officer at Bloom Security. “Risk depends on context: the user’s role, their access to sensitive data, the other tools operating on that endpoint, their configurations, and how everything interacts. Bloom Security was designed to evaluate that context in real time.”

The platform is also designed to let security teams take action based on those assessments. Bloom says organizations can block risky installations before they reach employee devices, enforce secure configurations and remediate risks without manual approval workflows.

That combination of visibility and enforcement is central to the company’s positioning as it targets large enterprises navigating AI adoption at scale.

Building From Enterprise Security Experience

Bloom’s leadership team has backgrounds at several established cybersecurity companies. CEO Itay Keren previously held engineering and sales engineering leadership roles at Palo Alto Networks, Dig Security and Demisto. Chief Product Officer Ofir Balassiano led the Cortex Cloud Posture Security research group at Palo Alto Networks and previously worked at Dig Security and XM Cyber.

Chief Technology Officer Itay Frishman built AISPM and DSPM solutions at Palo Alto Networks and Dig Security, alongside earlier cybersecurity research and development experience. Bloom currently has 30 employees, many of whom previously worked together at Dig Security.

“While this is technically our first company as founders, our team has built and integrated category-defining products before,” said Itay Frishman, Co-Founder and CTO. “We understand how enterprise security environments operate, and we built Bloom Security specifically for the reality of how endpoints are used today.”

Bloom’s investors see the changing endpoint as an emerging category in enterprise security. Kobi Samboursky, Founder and Managing Partner at Glilot Capital, said the company’s early traction reflects the urgency of the problem.

“AI has changed the enterprise endpoint in ways the security industry is still catching up to. Agents, MCP servers, browser extensions, and code packages now run on every employee’s machine, entirely outside the reach of traditional controls,” said Kobi Samboursky, Founder and Managing Partner at Glilot Capital. “Bloom identified this gap before the market did, and the business traction we’ve seen in their first months is unprecedented for a company at this stage. A team this experienced with a problem this urgent and momentum this strong is what category-defining companies look like from day one.

With $20 million in seed funding and deployments at dozens of large enterprises, Bloom is now focused on a security perimeter that is changing alongside the workplace itself. Its bet is that protecting the AI-native endpoint will require organizations to understand not only what is running on employee devices, but also the context in which that software operates and the access it has to corporate resources.

Subscribe now

Subscribe now

Black Hat USA 2026 takes place August 1 through 6 at the Mandalay Bay Convention Center in Las Vegas, with expert trainings, summits, and main conference briefings covering the technologies and challenges shaping modern cybersecurity. Organizations are contending with AI-driven threats, expanding attack surfaces, cloud complexity, and growing volumes of security data. Vendors are answering with new approaches to detection, response, exposure management, and resilience. What follows is a company-by-company reference to 12 firms worth attention, drawn from the CISO Whisperer watch list.

Upwind

Cloud and AI security handled from the runtime layer. Upwind connects cloud inventory, posture, network topology, applications, and identities, then blends real-time and agentless signals to produce a live view of infrastructure, networks, APIs, and data flows. Faster threat response is the outcome it sells. Placed in the Super Tier.

Cloudflare

A global network for building, securing, and scaling applications, AI agents, and workforces without managing the infrastructure underneath. Cloudflare pushes security, connectivity, and code execution toward users and data. The network spans more than 335 cities and reaches 95% of the world’s population within 50 milliseconds. The company says its network powers 42% of the Fortune 500, which reflects its broad role in the modern internet ecosystem. Super Tier.

Illumio

Breach containment across hybrid and multi-cloud environments. Illumio combines Zero Trust principles, AI-powered insights, and segmentation to detect threats, restrict lateral movement, and contain attacks before they spread. Super Tier.

Arctic Wolf

The Aurora Superintelligence Platform, positioned as a foundation for more automated security operations. Arctic Wolf uses AI agents to help organizations operate at machine speed. Built-in trust controls and human oversight provide validation, governance, and the expertise needed to manage complex security decisions. Super Tier.

Cohesity

Data protection and cyber resilience on one platform. The Cohesity Data Cloud brings data protection, security, recovery, and AI readiness together for hybrid cloud and SaaS workloads, strengthening threat detection, automating cyber recovery, reducing compliance risk, and making enterprise data more useful for AI initiatives. Super Tier.

Veracode

Application risk management across the software development lifecycle. Veracode pairs visibility across code, dependencies, containers, and runtime signals with remediation guidance and AI-driven fixes. The aim is reduced security debt at maintained development speed. Featured Tier.

ThreatLocker

Zero Trust enforcement built on a deny-by-default model. ThreatLocker permits only authorized applications, scripts, and processes to run across endpoints, cloud, and networks. Granular control is applied to prevent ransomware, reduce privilege abuse, limit lateral movement, and make data exfiltration more difficult. Featured Tier.

SafeBreach

Adversarial exposure validation for teams that want proof rather than assumption. SafeBreach tests whether defenses can withstand real-world attack techniques. The SafeBreach Helm platform combines exposure validation, AI orchestration, and existing security technologies to support continuous threat exposure management and measurable risk reduction. Featured Tier.

Mate Security

An agentic SOC designed for the speed and scale of modern threats. Mate Security uses a security context graph to give AI agents a tailored understanding of an organization’s environment, enabling support for detection building, triage, investigations, response, and threat hunting in a continuous cycle. Emerging Tier.

Daylight Security

Managed Agentic Security Services, or MASS, combining AI agents with experienced security professionals. Daylight Security covers managed detection and response, threat hunting, and phishing investigation and response. Its experts help customize detections, build integrations, and improve the context powering its AI systems. Emerging Tier.

Reclaim Security

An AI Security Engineer built to close the distance between identifying exposures and fixing them. Reclaim Security analyzes findings across security tools, understands business context, creates remediation strategies, and can deploy fixes through automated or approval-based workflows. Emerging Tier.

Zero Networks

Automated, identity-driven microsegmentation aimed at containing attacks and limiting lateral movement. Zero Networks applies segmentation to networks, identities, AI agents, and non-human accounts while helping organizations govern AI identities and restrict unauthorized activity. Emerging Tier.

Reading the Roster

Twelve entries, five in the Super Tier, three Featured, four Emerging. Read as a set, the list shows how far the industry has moved toward automation in the space of a single conference cycle. Four of the twelve describe AI agents as part of the product rather than as a roadmap item. Three extend their coverage to non-human identities. Black Hat USA 2026 arrives as AI reshapes both cybersecurity defense and the threat landscape, and the gathering of security leaders, researchers, practitioners, and vendors in Las Vegas will offer a view of how the industry is preparing for machine-speed attacks, autonomous systems, and increasingly complex digital environments.

Subscribe now

Subscribe now

In cybersecurity, effective leadership requires more than deploying the right tools or responding quickly to incidents. It requires a mindset built around continuous learning, attacker thinking, and the ability to translate technical risk into business impact. Sergey Tairyan, Chief Information Security Officer at the Technology Management Center of Yerevan City and founder of OmniSec and Oky.ai, brings more than 15 years of experience building and transforming security programs across industries. His expertise spans security operations, SOC leadership, SIEM and DLP, IAM and PAM, endpoint protection, incident response, and emerging areas such as steganography and post-quantum cryptography.

Known for combining hands-on ethical hacking with long-term security strategy, Sergey approaches cybersecurity with a focus on reducing real-world risk while keeping organizations resilient and operational. His advice reflects that philosophy, from researching a vendor before buying its tools and measuring security decisions in business numbers to prioritizing daily learning and clear leadership during a crisis. In this edition of CISO Tips, Sergey shares the principles, habits, and practical approaches that shape how he thinks about security leadership in an increasingly complex threat landscape.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first do OSINT on the company behind it.

What’s one rule you enforce on your team that other teams would find strict?

Two non-negotiable rules:

• All team members must maintain 24/7/365 availability, including weekends, holidays, vacations, and days off.

• Every team member spends one hour daily on learning and research.

In cybersecurity, threats don’t rest and neither does learning.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

65% prevention, 15% detection and response, 20% innovation and research.

AI has shifted the balance toward innovation, but the ratio should continuously adapt to business risk, technology, and the evolving threat landscape.

What’s one line that works when asking the board or CFO for a budget?

The board and CFO understand numbers, not technical details. So, I don’t ask for a security budget; I present a business risk calculation, showing the potential financial impact of an incident, its likelihood, and the cost of reducing that risk.

What should a CISO cut from their program tomorrow with zero regret?

With AI and mature open-source solutions, many enterprise security tools (such as SIEM, security scanners, and password managers) can now be deployed faster, customized, and operated at a fraction of the cost.

What’s your 60-second test for whether a vendor pitch is worth your time?

I present the vendor with 2-3 real security challenges and watch how they respond.

I’m looking for honesty, technical depth, and a problem-solving mindset - not marketing. If they ask the right questions and acknowledge limitations, they’ve earned more of my time.

What’s one meeting, report, or process you eliminated, and what replaced it?

I eliminated meetings focused on what we did and replaced them with discussions on what we learned.

Instead of status updates, we focus on new threats, lessons learned, and opportunities to improve our security posture.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Teams often skip establishing clear leadership.

In a major cyber incident, the CISO becomes the incident commander, directing the CIO, CTO, and other teams to coordinate the response.

What’s one question every CISO should ask their team this week?

What else can we automate to improve our resilience?

What’s a phrase or framing you use to translate a technical risk for executives?

Let’s talk in numbers.

What’s your best tip for surviving the CISO role in exactly five words?

- Learn. Test. Hack. Repeat.

More tips from the series:

• CISO Tips: Kristin Lowery on Turning Security Activity Into Measurable Risk Reduction

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

• CISO Tips: Nikolas Oelkrug-Alders on Why Strong Security Starts With the Fundamentals

Subscribe now

Subscribe now

The rise of artificial intelligence is forcing enterprises to reconsider nearly every aspect of cybersecurity. Security teams are no longer dealing only with larger volumes of alerts; they are preparing for attacks that can evolve at machine speed while evaluating AI-generated recommendations that must be accurate enough to trust. For many organizations, that has created demand for security platforms designed specifically for the AI era rather than adapted from legacy architectures.

Mate Security is one of the companies betting on that shift. Reported first by Axios, the startup has announced a $35 million Series A funding round, bringing its total funding to more than $50 million less than a year after leaving stealth mode. The round was led by Canaan Partners and included participation from Insight Partners, Team8, and M12, Microsoft’s Venture Fund.

The investment comes as the company reports increasing adoption among Fortune 500 organizations and says its business has grown by more than 500% since the third quarter of 2025.

Moving Beyond Traditional Security Operations

As organizations introduce AI into security workflows, one challenge has become increasingly apparent: speed alone is not enough. Security analysts still need confidence that AI-generated findings accurately reflect what is happening inside their environments before they can take action.

Mate’s platform is designed around that principle. Rather than focusing exclusively on automation, the company has built what it describes as an open, agentic security operations platform powered by a patent-pending context layer. The goal is to provide AI agents with an understanding of the customer’s business so they can make more precise security decisions.

That contextual awareness extends beyond technical signals. According to the company, its platform evaluates operational information alongside security events, allowing AI agents to determine whether activity is expected business behavior or an incident that requires investigation.

For instance, if multiple login attempts trigger an alert, the platform can recognize whether the activity coincides with planned security testing. Similarly, if an employee accesses sensitive files, the system considers organizational context, including personnel changes and document classifications, before determining whether the activity poses a legitimate threat.

Building an AI Foundation Instead of Another Tool

Mate says the platform serves as a centralized foundation where organizational knowledge is collected, maintained, and governed through a Security Context Graph. AI agents operate using that shared knowledge base, allowing both Mate-developed agents and customer-built agents to work from consistent information while maintaining controls around permissions, auditability, and response.

The company also says its AI architecture includes persistent memory that improves over time through investigations, structured communication between specialized agents, and least-agency principles that restrict each agent to only the context and permissions required for its specific task.

“When we started Mate, we knew we had to invest in the foundation: context and trust, and build them deeply into our product,” said Asaf Wiener, CEO and Co-Founder of Mate Security. “We brought in some of the best AI builders and security experts, and I’m excited to see how well this approach is being received by the market. We will continue moving fast and stay laser-focused on our customers, as we expand into new markets and categories to build the Open Security Operations foundation of the future.”

Investors See Strong Enterprise Momentum

The latest financing follows Mate’s $15.5 million Seed round announced eight months ago, with all previous investors returning for the Series A.

Backers say the company’s approach stands apart because it focuses on enabling AI systems to understand organizational context rather than simply accelerating existing workflows.

“AI is forcing a fundamental rethink of security operations. What stood out to us about Mate wasn’t simply its use of AI; it was the team’s conviction that trustworthy AI requires a deep understanding of how an organization operates,” said Joydeep Bhattacharyya, General Partner at Canaan. “By building a shared context layer that gives AI agents that understanding, Mate has taken a fundamentally different approach to security operations. The customer feedback and success we’ve seen in competitive evaluations reinforce our belief that the team is solving an important problem in a differentiated way.”

Insight Partners highlighted the company’s ability to combine advanced AI capabilities with practical security operations.

“Security operations was not built for the speed or scale of modern AI-driven attacks,” said Teddie Wardi, Managing Director at Insight Partners. “Mate is doing something few security companies have managed: combining genuine AI depth with operational trust to rebuild security operations for the AI era. We are proud to support a team that consistently outexecutes.”

Team8 and M12 likewise pointed to the company’s execution, hiring, and commercial growth as indicators of its momentum in the emerging market for AI-native security operations.

Showcasing at Black Hat USA

The funding announcement comes just before Black Hat USA 2026, where Mate Security will exhibit at Booth 4717 from August 3 to August 6.

As enterprises continue adapting their security strategies for AI-driven threats, the company is positioning its platform around a central belief: that successful AI security operations require more than powerful models; they require AI systems that understand the business they are protecting.

Subscribe now

Subscribe now

There is a quiet market shift underway in managed security, and Daylight’s latest release is a useful signal of where it is heading. Daylight Security, the managed agentic security services company, today announced Detection Program Visibility, a capability that gives customers a measurable view of their entire detection program, including the parts a managed provider would traditionally keep hidden.

The strategic logic is straightforward. MDR providers have historically competed on outcomes and response times while keeping their detection content proprietary. Daylight is competing on something different: the customer’s ability to see, measure, and improve the program itself.

The Market Problem

Every security organization of reasonable size now runs a stack of tools, a SIEM full of accumulated content, and often a managed detection service on top. Each layer generates its own detections. Security tools expose theirs. MDR providers typically operate theirs as a black box.

The result, as Daylight describes it, is fragmentation across multiple systems. Customers cannot easily determine what is actually being detected, where coverage overlaps, and where the blind spots are. In a market where organizations are under pressure to justify every line of security spend, that opacity is becoming harder to defend.

What Daylight Is Shipping

Detection Program Visibility consolidates every detection a customer has into one place. That covers three sources: detections from security tools, SIEM content, and the detections Daylight operates on the customer’s behalf. Daylight organizes all of it into a shared model mapped to MITRE ATT&CK.

The differentiating layer is operational context. Each detection carries data on alert volume, case outcomes, verdict statistics, overlap, and coverage gaps. This is where the capability moves past inventory and into measurement.

The Competitive Angle

Standalone detection visibility tools exist. Daylight’s counter is that visibility without investigation is a dead end. Because Daylight investigates the activity these detections generate, every investigation produces feedback on detection quality: which detections find meaningful threats, which create noise, which overlap, and where coverage is missing.

That feedback loop is the product’s core claim. It converts detection engineering from a static collection of rules into a measurable, continuously improving program. A pure visibility vendor cannot close that loop. An opaque MDR will not.

Hagai Shapira, CEO and co-founder of Daylight Security, made the positioning explicit. “Security leaders know how many alerts they receive, but they rarely know whether their detection program is actually improving,” he said. “For years, MDRs have asked customers to trust what happens behind the curtain. We believe customers should be able to see the detection program protecting them, understand how it’s performing, and continuously improve it with us. Detection Program Visibility is another step toward making managed security transparent instead of opaque.”

What Buyers Should Take From This

For security leaders evaluating managed detection, the release sharpens a question worth asking of any provider: can you show me the detection program you run on my behalf, with performance data attached? Providers built on the black box model will struggle to answer. Daylight has now built its answer into the product.

The release also reframes what improvement means in an MDR relationship. Alert counts and response metrics measure activity. Detection quality metrics measure whether the program is getting better at its actual job. Those are different things. Daylight is arguing that customers should be able to see both.

Availability and Outlook

Detection Program Visibility is available now for Daylight Managed Agentic MDR customers.

Transparency plays are only as good as the data behind them, and the market will judge this one on whether the measurement holds up in practice. But the direction is notable. If customers begin to expect visibility into managed detection programs as a baseline, providers that built their businesses behind the curtain will face an uncomfortable choice: open up or explain why they will not. Daylight has made its choice and turned it into a feature.

Subscribe now

Subscribe now

Identity and access management has become a central pillar of enterprise cybersecurity, but deploying identity systems across large organizations remains a persistent challenge. Companies can invest heavily in IAM platforms only to face years of implementation work, high consulting costs and complex operational requirements.

As reported by Axios, Insight Partners and Glilot Capital are co-leading a $20 million investment in Way Security, a company founded by former security leaders Yossi Barishev and Yonatan Rosenberg. The company is building an AI-powered, agentic execution platform designed to automate the operational work traditionally required to deploy and manage IAM systems.

Rather than asking enterprises to replace their existing identity infrastructure, Way Security is focused on helping organizations get more value from the platforms they already own. Its approach targets the gap between purchasing IAM software and successfully operationalizing it across complex enterprise environments.

The Services Problem Behind IAM

According to Way Security, enterprise IAM programs can routinely run years past schedule and reach seven- or eight-digit cost figures while still delivering less than originally promised. Implementation, customization and ongoing operational services can cost organizations three to five times more than the software itself, creating a services ecosystem that has grown larger than the IAM software market it supports.

The company believes this represents a multi-billion-dollar opportunity to change how identity programs are delivered. Its platform uses AI-driven automation and agentic workflows to execute tasks that have historically depended on consultants, system integrators and internal engineering resources.

“IAM is the only space in cyber where overspending and under-delivering is an acceptable reality,” said Barishev, co-founder and CEO of Way Security. “The more time we spent doing IAM, the more we realized how the industry normalized mediocrity and has almost given up trying to solve some of its biggest challenges.”

Automating The Operational Layer

Way Security’s platform is designed to automate activities associated with identity lifecycle management, access governance, authentication and policy enforcement. The company says organizations can apply identity controls across different types of identities and systems without custom integrations, manual workflows or ongoing dependence on application owners.

The platform also addresses applications that can be difficult to incorporate into conventional identity programs, including legacy, homegrown and custom applications that do not support standard federation protocols. Way Security connects these applications to the IGA, IdP and authentication controls organizations already own.

“Most IAM teams aren’t looking to replace the platforms they’ve already invested in,” said Rosenberg, co-founder and CTO. “They’re looking to finally get the return on investment they were promised. We built Way Security to automate the work that has traditionally stood between buying an IAM platform and actually realizing its value.”

Experience From Inside Enterprise Security

Way Security’s founders bring firsthand experience with the challenges they are trying to address. Barishev and Rosenberg spent years helping large enterprises navigate identity, governance and security initiatives, advising Fortune 500 organizations and leading enterprise security teams from within.

The pair also spent years leading incident response efforts for organizations facing major cyber incidents, repeatedly seeing weak identity controls become a root cause or critical enabler of successful attacks. Rosenberg additionally served as an officer in Israel’s Unit 8200, bringing an offensive security perspective to the company’s identity and security expertise.

“The issue isn’t that enterprises lack the right tools,” said Barishev. “It’s that those tools are incredibly expensive and complex to operationalize. We built Way Security to remove that friction.”

Investors Target A Larger IAM Opportunity

The $20 million investment reflects the belief from Insight Partners and Glilot Capital that the operational challenges surrounding IAM represent an opportunity beyond the traditional identity software market.

“Identity is one of the most critical layers of enterprise security, yet organizations still struggle to operationalize their investments efficiently,” said Jeff Horing, Co-Founder and Managing Director at Insight Partners. “Way Security is addressing a large and persistent gap between IAM software and real-world execution.”

Nofar Amikam, Managing Partner at Glilot Capital, pointed to the combination of the founders, market opportunity and the company’s approach. “As investors, we’re constantly looking for the rare combination of an exceptional team, a massive market opportunity, and a differentiated approach, said Nofar Amikam, Managing Partner at Glilot Capital. “With Yossi and Yonatan, all three were evident from our very first meeting. They possess a deep understanding of the identity challenges facing large enterprises because they’ve lived them firsthand, and they’ve built a fundamentally better way to solve them. Identity has become the foundation of modern security, and we believe this team has the vision, talent, and determination to build the company that will define how the next generation of enterprises manages and secures it.”

Expanding The Identity Operations Market

Way Security says it is already working with Fortune 500 companies, global healthcare organizations and financial institutions to accelerate IAM deployments, reduce manual implementation work and expand identity coverage across complex environments.

The company plans to use the new investment to aggressively expand its U.S. presence while continuing to invest in its identity operations platform. Its broader goal is to establish identity operations as a distinct category focused on making existing IAM technology easier to deploy and operate.

“We’re at a pivotal moment in the market,” said Rosenberg. “Identity has become the foundation of enterprise security, yet organizations still struggle to operationalize it effectively. Our priority now is to move quickly, expand our platform, grow our presence in the U.S., and establish Way Security as the category leader in identity operations before the market catches up.”

Subscribe now

Subscribe now

As cybersecurity leaders face growing pressure to reduce risk while proving business value, the role of the CISO is increasingly defined by the ability to connect security decisions to measurable outcomes. Kristin Lowery, Field Chief Information Security Officer at Optiv, brings extensive experience leading information technology and cybersecurity initiatives across Fortune 500 enterprises. Her background spans cybersecurity controls, cloud computing, vulnerability management, data protection, governance, business continuity, and large-scale technology transformations, with a focus on helping organizations reduce threats while supporting resilience and sustainable growth.

Throughout her career, Lowery has worked closely with senior executives and cross-functional teams to develop security strategies, strengthen governance, improve operational efficiency, and align technology investments with business priorities. In this edition of CISO Tips, she shares a practical perspective on making security programs more effective, from evaluating the real problem before buying another tool and cutting unnecessary complexity to translating technical vulnerabilities into business exposure and establishing clear decision ownership during an incident. Her advice centers on a simple principle: security teams should focus less on activity for its own sake and more on measurable risk reduction, business impact, and the resilience to keep moving forward.

Complete this sentence: “Before you buy any new security tool, first...”

Before you buy any new security tool, first get clear on the problem you’re trying to solve. Too often, teams add technology before confirming whether they already own a tool that can do the job—or whether the real issue is process, ownership, or adoption. I also think it’s important to regularly review your existing technology footprint, because many organizations are not getting full value from the solutions they already have. One recent conversation that stuck with me was with a CISO who asked his team to review their top tools and validate actual usage, especially as new AI capabilities continue to emerge.

What’s one rule you enforce on your team that other teams would find strict?

If we can’t connect a recommendation to risk reduction or a business outcome, we need to rethink it. Security teams can generate a lot of activity, but activity is not the same as progress. To me, progress means measurable operational risk reduction or an increase in business capability.

What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

I pay close attention to the balance between effort and actual risk reduction. If something takes significant time, creates operational drag, and does not meaningfully reduce risk, that is usually a signal to simplify it. I also believe key performance indicators and risk appetite should be reviewed at least annually so they remain relevant and useful.

What’s one line that works when asking the board or CFO for a budget?

“This is not about buying another security tool. It is about reducing the likelihood and impact of an event that could disrupt the business, affect customers, or slow recovery.” CFOs and other leaders do not want to hear about the latest shiny tool. They want to understand impact, value, and how the investment fits into the broader environment.

What should a CISO cut from their program tomorrow with zero regret?

I would cut anything that creates noise without improving decision-making. That might include duplicate tools, reports no one uses, or processes people follow simply because “we’ve always done it that way.”

What’s your 60-second test for whether a vendor pitch is worth your time?

I want to quickly understand what risk they reduce, where they fit in the environment, what problem they solve better than what I already have, and how I would know the solution is working. If they can’t explain that clearly, it’s probably not the right conversation.

What’s one meeting, report, or process you eliminated, and what replaced it?

I’m a big believer in replacing status-for-status-sake meetings with decision-focused conversations. Instead of walking through dashboards, I’d rather ask: What changed? What matters? What decision do we need? Who owns the next step? I’m also comfortable canceling meetings that are no longer needed or ending them early. Staying connected with leaders and teams matters, but the agenda should support that purpose.

In the first 10 minutes of an incident, what’s the one action teams most often skip?

Teams understandably jump into technical triage, but they often skip defining business impact and decision ownership. Early on, someone needs to clarify what is affected, who needs to know, and who is empowered to make decisions.

What’s one question every CISO should ask their team this week?

“Where are we making security harder than it needs to be?” That question usually opens an honest conversation about complexity, ownership, and whether our controls are working the way we think they are.

What’s a phrase or framing you use to translate a technical risk for executives?

I try to shift the conversation from “technical vulnerability” to “business exposure.” For example: “This is not just a system issue; it could affect operations, customer trust, recovery time, or our ability to meet business commitments.”

What’s your best tip for surviving the CISO role in exactly five words?

Stay curious, practical, and resilient. Keep moving forward—don’t spend too much time looking backward, because that’s not where you’re going.

More tips from the series:

• CISO Tips: Paul Blahusch on Business Success Coming First

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

• CISO Tips: Nikolas Oelkrug-Alders on Why Strong Security Starts With the Fundamentals

• CISO Tips: Rocco Barra on Never Taking Anything for Granted

Subscribe now

Subscribe now

Cybersecurity conferences are built around meetings, product demonstrations and vendor pitches, but Daylight Security is using Black Hat to make a different statement. Instead of setting up a traditional booth, the company introduced the “CISO Genie,” a private concierge service designed to help security leaders with the practical demands of attending the event.

The initiative has also become a social media campaign. Two videos shared on LinkedIn by Hagai Shapira, Co-Founder and CEO of Daylight, use humor to portray the CISO Genie as a behind-the-scenes problem solver for security executives. The videos have generated significant engagement on LinkedIn while presenting a less conventional take on the relationship between cybersecurity vendors and their customers.

The campaign’s central message appears in Shapira’s post accompanying the first video: “A Black Hat booth costs about the same as taking care of 150 CISOs for an entire week. We chose the CISOs.” The decision reflects Daylight’s broader positioning around providing security leaders with a different kind of experience, rather than simply competing for their attention on the conference floor.

From Airport Pickups To Ransomware Negotiations

The first video introduces the CISO Genie through a series of requests that blend everyday conference frustrations with cybersecurity humor. His responsibilities include investigating incidents, calming executives and keeping security teams together, while his list of services extends to quiet meeting rooms, fresh shirts, dinner reservations, private airport pickups and personal barbers.

“I grant wishes for CISOs. I investigate incidents, calm down executives, and convince security teams not to quit,” the character says. The joke continues when the genie explains that CISOs no longer have just three wishes: “Used to be three. Then someone hacked the lamp. Changed it to unlimited.”

The second video builds on the same concept with a new set of demands, including finding a faster route across Mandalay Bay and securing a table for eight at Carbone. The latter proves particularly difficult for the fictional concierge. “I’ve handled ransomware negotiations. This was harder,” he says.

A Campaign Built Around The CISO Experience

The videos also poke fun at the language and trends surrounding cybersecurity. In the second episode, the genie is asked how he keeps up with everything and responds with an exaggerated routine: “We’re agentic! We’re agentic! We’re AI-native agentic! Again! More disruptive! Agentic! Every morning.”

Another scene introduces what the video calls “the most important room at Black Hat”: a quiet room for CISOs. When asked why everyone is whispering, the answer is simple: “CISOs are recovering.” Shapira’s accompanying post reinforces the campaign’s deliberately lighthearted approach: “No thought leadership today. Just press play.”

Beneath the humor is a broader message about how Daylight views its role in the security industry. The company’s first LinkedIn post says, “We built Daylight because we think security services should feel different. Less noise. Less friction. Better outcomes. More accountability.” By putting the CISO Genie at the center of its Black Hat presence—and turning the concept into a widely shared social campaign—Daylight is using humor to communicate that philosophy while giving security leaders something other than another vendor pitch to think about.

Subscribe now

Subscribe now

Paul Blahusch is the founder and president of B&A Cybersecurity Consulting. He is a former federal cabinet agency Chief Information Security Officer (CISO) with over 25 years of experience in cybersecurity leadership, specializing in safeguarding information systems and data. He has a proven ability to enhance organizational efficiency while managing substantial budgets and ensuring compliance with regulatory standards. Paul has expertise in developing and implementing comprehensive cybersecurity strategies, including zero trust frameworks and risk management initiatives. He is committed to fostering a culture of security awareness and readiness and is passionate about leveraging technology and best practices to protect critical assets and support organizational missions.

In addition to his work with B&A Cybersecurity Consulting, he is the Cybersecurity Advisor for the Consortium of Universities of the Washington Metropolitan Area, a Mission Critical Fellow, and a frequent speaker at cybersecurity conferences.

1. Complete this sentence: “Before you buy any new security tool, first...”

Determine if it makes you better and, if so, how you can afford it.

2. What’s one rule you enforce on your team that other teams would find strict?

I stressed scrupulous adherence by the cyber team to all organizational policies: budget, procurement, HR, physical security, and more. If we expected organization personnel to follow our cybersecurity policies, the cyber team should lead by example across the board.

3. What’s a number or ratio that guides how you allocate budget, headcount, or your own time?

I’ll go with my own time. There is an ongoing mental calculation. Whatever is urgent and important gets attention. Generally, that ends up being what is most important at the moment to help protect and ensure business success.

4. What’s one line that works when asking the board or CFO for a budget?

Here is how this will pay for itself, through efficiencies, reducing or eliminating duplicative solutions, lower insurance premiums, and other savings.

5. What should a CISO cut from their program tomorrow with zero regret?

Do this exercise. Ask your team to tell you what activities they do that don’t appear to have value, and to estimate how much time they spend on each. For example, this could be a long-standing report they prepare that no one up the org chart ever comments on. Evaluate the results. Eliminate based on least value and highest cost. No regret.

6. What’s your 60-second test for whether a vendor pitch is worth your time?

Tell me what problem I have that this helps solve, or how this makes me better, more secure, more efficient. Why would I want this? And tell me how I can have this within my current budget, whether by replacing or reducing something else, lowering cost elsewhere, or another option. How can I afford this?

7. What’s one meeting, report, or process you eliminated, and what replaced it?

I killed maintaining the five-year cybersecurity strategic plan document. It was a bloated, time-consuming, never-referenced, obsolete-as-soon-as-it-was-published, costly product. We replaced it with annual tangible and trackable goals, combined with shorter “sprint” objectives throughout the year.

8. In the first 10 minutes of an incident, what’s the one action teams most often skip?

Using the playbook. They often get so quickly engrossed in the technical details of the incident, determining the where and how, that they forget to open the playbook. This can lead them to miss important steps defined in the playbook, like preserving evidence, documenting a record of the incident, and establishing secure communications.

9. What’s one question every CISO should ask their team this week?

How can I best help you be successful? Is that by being a sounding board, getting you needed resources, providing top cover for an initiative, or providing a decision or approval?

10. What’s a phrase or framing you use to translate a technical risk for executives?

Executives are familiar with evaluating risks of all types. Frame technical, or cyber, risk through a similar lens. Namely, how it will impact the business.

11. What’s your best tip for surviving the CISO role in exactly five words?

Remember, business success comes first. As a C-Suite executive, my role isn’t to provide cybersecurity. Rather, it is to make sure the business is successful. The primary way I, as CISO, contribute to that success is by directing a cybersecurity program that keeps cyber risk at an acceptable level to the business.

Get more tips from CISOs working in various industries:

• CISO Tips: Diyar Akhmedov on Prioritizing Risk Over Hype

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

• CISO Tips: Nikolas Oelkrug-Alders on Why Strong Security Starts With the Fundamentals

• CISO Tips: Rocco Barra on Never Taking Anything for Granted

• CISO Tips: Barak Blima on Building Trust Before Needing It

Subscribe now

Subscribe now

Security operations teams are expected to respond quickly as new threats emerge, but the infrastructure behind that response is changing just as rapidly. New data sources are introduced, cloud services evolve, detections are added, and automations become part of increasingly interconnected workflows.

The challenge is that security infrastructure does not operate in isolation. A change in one part of the environment can affect another, potentially disrupting detection pipelines without immediately alerting the teams responsible for protecting the organization.

Fig is addressing that challenge by expanding its platform across what it describes as the complete SecOps engineering lifecycle. The company says its approach brings a CI/CD model to Security Operations (SecOps), allowing engineers to build, ship, and observe changes while maintaining greater confidence in the systems responsible for detection and response.

The move reflects a broader shift in security operations: as the technology stack becomes more complex, managing change itself is becoming a critical part of security engineering.

Treating Detection Changes Like Software

At its core, Fig is giving SecOps something it has never had: a complete engineering lifecycle for detections and configurations.

The workflow begins with the change an engineer wants to make. Rather than manually connecting systems and configuring infrastructure, the engineer describes the desired detection or configuration, and Fig analyzes the live environment to propose an implementation.

Before deployment, the proposed change is simulated and tested to evaluate its expected impact. Approved changes can then be deployed with version control and rollback capabilities, while continuous observability monitors detection flows after deployment.

The approach brings concepts that have become standard in software engineering into security operations. Testing and validation happen before production, changes can be rolled back, and ongoing monitoring continues after deployment.

For SecOps teams, the result is intended to be a more structured way to manage the infrastructure supporting detection and response.

The Role of Security Data Lineage

Fig’s platform is built on a deterministic graph of security data lineage that maps detections, data sources, and their connections throughout the SecOps environment.

The company views this lineage as the foundation for understanding how changes move through the infrastructure. By mapping the relationships between different components, Fig can evaluate proposed changes with greater context and assess how they might affect the broader detection pipeline.

That context becomes particularly important when changes originate outside the immediate control of the security team. Upstream or downstream systems can evolve independently, potentially creating problems that are difficult to identify until detection coverage has already been affected.

Continuous verification is designed to provide ongoing visibility into those relationships and help ensure detection flows continue working as intended.

Turning Security Work Into an Engineering Workflow

The platform is also intended to shorten the time required for several common SecOps activities.

Fig says security teams can turn threat reports into detections and queries more quickly, allowing them to address emerging threats without waiting through lengthy engineering processes. SIEM migrations can also be completed in weeks rather than months, according to the company, while organizations remain fully operational throughout the transition.

The platform’s data plane capabilities give teams greater control over data ingestion and storage spending without affecting live detections.

These capabilities point to a common objective: reducing the amount of manual infrastructure work required to keep security operations running, while allowing engineers to concentrate on detection logic and improving coverage.

Confidence Becomes Part of the Deployment Process

For Fig, speed is only one measure of an effective security engineering workflow. The company is equally focused on whether teams can trust the changes they make.

Jayme Hancock, Head of Security Operations and Engineering at AppLovin, said, “With Fig we build and ship accurate detection changes in minutes instead of weeks, without the endless plumbing.” He added, “My team builds with a confidence we’ve never had, and yeah, we’ve even started ‘vibe parsing.’”

The customer perspective reinforces the company’s argument that reducing the engineering effort around changes can also improve confidence in the resulting environment.

A Broader Bet on Security Operations Resilience

Fig’s platform expansion builds on its focus on Security Operations Resilience. The company has raised $38 million from Team8, Ten Eleven Ventures, and Crosspoint Capital, was named a finalist in the RSAC Innovation Sandbox, and says its technology has been deployed across dozens of Fortune 500 companies.

Founded by veterans of Google SecOps and Siemplify, Fig says its platform is informed by experience with large and complex security operations environments where changes can create unexpected failures.

Gal Shafir, Co-Founder and CEO of Fig, said the company wants to remove the perceived choice between speed and reliability. “Security teams shouldn’t have to choose between moving quickly and maintaining confidence in their SecOps Infrastructure,” he said. “Fig gives SecOps Engineers the same modern engineering workflow that software developers have long relied on. They can design changes with complete context, prove those changes work before deployment, and continuously verify that their security operations remain resilient as their environments evolve.”

As SecOps infrastructure becomes more interconnected, Fig’s approach suggests that resilience may increasingly depend on how organizations engineer change—not simply on how many security tools they deploy.

Subscribe now

Subscribe now

With more than 20 years of experience across banking, financial services, government, and critical infrastructure, Diyar Akhmedov has built his career around helping organizations make practical, risk-based security decisions. His background spans cyber risk management, security strategy, governance, regulatory compliance, security architecture, and building security programs that align with business objectives rather than industry trends.

In this edition of CISO Tips, Akhmedov shares why every security investment should begin with a clear understanding of the problem it solves, why proof-of-concept testing matters more than polished vendor presentations, and how CISOs can communicate technical risks in business terms. His advice emphasizes disciplined prioritization, operational effectiveness, and focusing security efforts on measurable outcomes instead of the latest buzzwords.

1. Complete the sentence: “Before buying any new security tool, first…”

…make sure you clearly understand the problem you are trying to solve.

In practice, this is not always as obvious as it sounds. Sometimes a solution looks attractive because the market is talking about it, other companies are using it, or the vendor gave a strong presentation. Before making a decision, I try to answer a few basic questions: Which risk are we reducing? What will actually change after implementation? And how will we know whether the product is working?

For critical solutions, I prefer to run a PoC first. Over the years, I have seen products look excellent during a demo and then struggle with basic integration once the PoC started.

2. What is one rule you enforce on your team that other teams might consider too strict?

We do not make major security decisions based only on a vendor presentation, an analyst rating, or a product’s reputation in the market.

I need to see how the solution performs in our own environment. A strong presentation does not guarantee a successful implementation. During a PoC, you may discover issues with integration, performance, support quality, or day-to-day operations.

I have seen well-known products with strong brands create more manual work for the security team than real value. I have also seen less prominent solutions perform very well simply because they were a better fit for the organization’s actual processes.

3. What metric or ratio guides how you allocate budget, headcount, or your own time?

I do not use one fixed formula for every situation.

I normally look at the level of risk, the expected risk reduction, the cost, and the complexity of implementation. A low-cost initiative is not always the highest priority, and an expensive one is not automatically excessive. It depends on the potential business impact of the risk.

I apply the same approach to my own time. I try not to become involved in every technical detail when the team can resolve the issue independently. My time should be focused on areas where prioritization, a management decision, or communication with the business is required.

4. What is the best phrase to use when asking the board or the CFO for the budget?

I try not to start a conversation with a product name.

Instead of saying, “We need to buy a new system,” I explain the current risk, how it may affect the business, and what will change if the investment is approved.

The board does not necessarily need to understand every technical difference between EDR and SIEM solutions. It does need to understand whether the current situation could lead to the disruption of a critical service, financial loss, regulatory consequences, or damage to customer trust.

Once the conversation starts with business risk, the budget discussion becomes much more practical.

5. What should every CISO remove from their program tomorrow without regret?

Projects that exist only because they are currently popular or because “everyone else is doing them.”

The information security industry is highly influenced by trends. Every year brings new technologies, approaches, and impressive terminology. But if an initiative is not connected to a specific risk or business need, it can quickly become an expensive project without a clear outcome.

I would rather have a shorter, realistic security program than a large roadmap that cannot be delivered properly. It is better to address five important risks than to launch fifteen fashionable projects and fail to make any of them operational.

6. How do you decide within 60 seconds whether a vendor presentation is worth your time?

I normally ask three questions:

What problem does your product solve? How difficult is the integration? How will we measure the result after implementation?

I do not expect a complete technical answer in one minute. I want to understand whether the vendor can speak about real-world operations rather than only product capabilities.

If the answer immediately turns into a discussion about artificial intelligence, unique algorithms, and attractive dashboards, but says nothing about integration, operational workload, or success criteria, I usually take that as a warning sign.

7. What meeting, report, or process did you eliminate, and what replaced it?

I try to reduce meetings where participants simply repeat information that is already available in reports.

If the status of a project can be shown on one page or in a short dashboard, there is no reason to bring ten people together for an hour. A meeting is useful when a decision needs to be made, a blocker needs to be removed, or ownership needs to be clarified.

The same applies to reports. If a report is produced every week but no one uses it to make a decision, I question why the team is still spending time on it.

We should not measure effectiveness by the number of meetings or documents. What matters is how quickly decisions are made, and real problems are resolved.

8. What do incident response teams most often miss in the first ten minutes?

The first instinct is understandable: stop the attack as quickly as possible.

But in doing so, teams sometimes start shutting down systems, terminating processes, or changing configurations before collecting the necessary data. As a result, logs, memory contents, and other important evidence may be lost.

I am not saying that evidence preservation is always more important than containment. If there is an immediate threat to the business, it must be stopped. But the team should act consciously and understand which actions may destroy evidence and which data must be preserved first.

Good incident response is a balance between speed, damage control, and the ability to reconstruct what actually happened afterward.

9. What question should every CISO ask their team this week?

“Which security control do we believe is working even though we have not tested it recently?”

It could be backup and recovery, MFA, EDR, PAM, security monitoring, or the incident response plan.

In information security, it is very easy to confuse the existence of a control with its effectiveness. A system may be installed, the licence may be active, and the dashboard may show a green status, yet the control may still fail when it is actually needed.

That is why I trust test results more than confident assumptions.

10. What phrase do you use to explain technical risk to executives?

I usually say: “This is a business risk caused by a technical issue.”

That wording helps move the discussion from a purely technical level to a management level.

Executives do not always need the details of a vulnerability, configuration issue, or attack scenario. They need to understand what may happen, how likely it is, what the potential impact is, and which options are available.

My role is not to overwhelm them with technical language. It is to provide enough information for an informed decision.

11. What is your best survival advice for a CISO role in exactly five words?

Prioritize risks. Build trust. Explain.

Get more tips from CISOs working in various industries:

• CISO Tips: Peter Egyed on Why Consistency and Prioritization Strengthen Cybersecurity

• CISO Tips: Nikolas Oelkrug-Alders on Why Strong Security Starts With the Fundamentals

• CISO Tips: Rocco Barra on Never Taking Anything for Granted

• CISO Tips: Barak Blima on Building Trust Before Needing It

• CISO Tips: Fred Streefland on Managing Risk So the Business Can Do Business

Subscribe now