Hey CISOs and security folks,

For years now, our security operations have essentially been driven by "looking through a rearview mirror." We’ve been stuck playing catch-up, building our defenses based almost entirely on past TTPs and known incidents. I recently came across a really interesting methodology that tries to break this cycle: "Future-Back Threat Modeling" (arXiv:2511.16088v3).

They propose a reverse approach: mapping out future threat scenarios first (like novel supply chain vectors or AI-driven logic attacks), then working backward to the present to "stress-test" the safety assumptions our current architecture relies on. The goal is to proactively hunt for "Unknown Unknowns."

On paper, the mindset is fantastic. But looking closely, this methodology heavily leans into Strategic CTI and military-style planning. It demands an elite team—people who are deeply technical but also possess the macro-intelligence mindset needed to conceptualize threats that don't even exist yet.

I’d love to get some boots-on-the-ground perspectives from those of you directly managing budgets and headcount:

1. In a landscape where talent is thin and just keeping a basic SOC afloat is a struggle, does a heavy, talent-demanding model like this have any real-world viability?
2. Is there a realistic way to "scale down" the core of this approach for average enterprises? For instance, instead of needing a dedicated Strategic CTI team, could we distill this "Future-Back" mindset into our quarterly Tabletop Exercises (TTX) or use it to generate periodic Threat Hunting hypotheses?

Would love to hear your thoughts!

Hi everybody. today I had a call with some Swedish fintech company and their cybersecurity team. I planned a meeting with a senior analytic who was in touch with me with a request for staff augmentation for their internal cybersecurity team. We arranged a time and day, so it's all good.

Over some time he started to send invites to his colleagues and we had CISO, Head of Cybersecurity, Head of SOC and a few senior analytics on the call. Given the fact that's our 1st meeting and basically a discovery call, I asked them about why they want to augment, what's the reason behind that, what tech stack do they use, etc. So basically to dive deeper into their situation and find the best possible solution for them because it's a quite common thing when people come to me with their view how to fix things and discovery helps us understand that there might be much better and more cost effective way to fix their need.

Once I asked them what's their definition of success and what main criteria of choosing the right vendor I've got harmful, but honest response: "I think we are looking for someone who's going to be a good security partner for us because the scope is massive. This is mdr, like this is extended soc, extended offset augmentation and vulnerability management. We are not doing a tick in the box activity here and unfortunately this meeting seems very unprepared for when you have a head of offset ahead of security engineering and head of SOC and a CISO in a meeting. I expect my suppliers to be better prepared than this. So I'm unfortunately going to say that, you know, culturally this is not going to work out. So we should save our time and you know, end this meeting now. Thank you."

And he just left the meeting.

So my question is, did I do something wrong during the discovery? As a group full of CISO, I thought maybe you can explain what happened here.

Went through our actual usage numbers this week and it is a little embarrassing. KEV drives real decisions, all the time, no question there. One of our paid vulnerability threat intelligence feeds occasionally surfaces something useful before it even hits KEV, which is worth the money when it happens. The other two feeds we pay for mostly just confirm things we already knew, or flag stuff that never turns into anything.

So what is the real signal to noise ratio for everyone else? How many feeds are you paying for versus how many have actually changed a prioritization decision you would not have made otherwise. Trying to figure out if we cut two subscriptions or if we are just bad at using what we already have.

Our AI-assisted code output has grown a lot this year and it's changed the shape of what shows up in security review. It's not necessarily worse code, but the patterns are different, more repetition of certain anti-patterns, more code that's technically correct but ignores context the model didn't have access to, like our actual network topology or existing compensating controls.

Our review process was built around human-written code and human review habits, and I don't think it's adapted yet. Curious how other teams have changed their SAST tuning, review checklists, or triage process specifically because of the AI-code volume increase, rather than just doing more of what worked before.

Been looking at adaptive simulations for cyber crisis readiness and honestly the old tabletop format feels too scripted for what we need. Curious if anyone's using them to keep incident response teams sharp, thanks!

Trying to build real world detection validation that does not collapse into a powerpoint demo or a false positive festival is turning into my full time hobby (tragic). What workflows are people using that do not make the SOC hate me? thanks!

We are considering a split model where high-value, high-volume telemetry is centralized for continuous detections, correlation, and retention, while lower-frequency or difficult-to-onboard sources remain in their original systems until an investigation requires them.

The appeal is reducing the ingestion backlog and long-term storage burden without losing the ability to access the data. The risks are inconsistent schemas, uneven retention, fragmented access controls, query limits, and analysts having to work differently depending on the source.

What did you centralize, what did you leave at the source, and how did you make cross-source investigations reliable enough for incident response and audit requirements?

Random question, but I’m curious what people think. As a CISO, do you think it’s important to know about fashion, dress well, and generally maintain a polished appearance?

Does the way a CISO looks and presents themselves have any impact on how people perceive their personality, leadership, credibility, or authority? Or is appearance basically irrelevant as long as they’re good at their job?

Hi, quick question for people actually running AI incident response tabletop exercises in anger.

We switched a bunch of our old powerpoint tabletop sessions over to simulated AI driven scenarios this year. It’s cool that we can spin up phishing plus ransomware plus comms chaos in minutes, but I’m kinda struggling with the workflow side… eg who owns prompts, how we track injects, when we freeze to debrief vs let the AI facilitator keep pushing.

If you’ve made this work for a small IR team plus a few execs, how do you structure the runbook for these so it doesn’t turn into chaos or theater again? Any hints?

The realistic question is probably not whether enterprises will replace their workforce IdP, PAM, IGA, cloud IAM, and SaaS access controls. Most organizations will operate those systems for years. The question is whether they can gain consistent policy, visibility, and audit evidence for agents without creating another disconnected identity silo.

Treating agents as generic service accounts keeps the architecture familiar, but it does not naturally represent agent ownership, delegated authority, task limits, tool boundaries, or autonomous action. A separate agent-security layer may improve those controls but can introduce duplicate inventories and conflicting policies.

For CISOs planning production agent use, what requirements would make the current IAM architecture insufficient? Is the deciding factor authorization, discovery, auditability, lifecycle management, incident response, or integration with existing identity systems?

Second year running the program, this cycle the auditor added AI to scope, which, fair.

They asked for the AI acceptable use policy. We have one, it's a lovely PDF. Then they asked how we evidence it's enforced, and the wheels came off. I can show them the policy. I cannot show them who used which tool with what data over the period, because we capture that precisely nowhere.

Writing 'we have a policy' and praying they don't push isn't a plan, specially with ISO 42001 creeping into every questionnaire now.

Whoever's had AI land in their audit, what did you hand over as evidence. Not the policy. The proof it does a single thing.

our alert backlog and investigation times have both crept up, and we're starting to miss things we shouldn’t, so i've been taking vendor calls more seriously this quarter. six demos in and slide five is always some version of the same before-and-after chart mentioning "faster investigations," "AI-powered detection." at some point the pitches look all the same.

i know the underlying problem is real. what i don't know is how I can differentiate real value from fluff and empty promises from a good deck in a 30 min call. So, for the CISOs here who've gone through a real evaluation process, did you find a specific question that helps you understand whether a vendor can back up their claims, versus one that just repeated the same talking points when pushed?

any advice would help a lot.

finding problems was never the hard part for us. deciding what to fix first with a small team is.

what's changed things for us is having full discovery and mapping feed directly into prioritization, so the tool tells you which of the hundred findings actually raises your risk instead of handing you a flat list. has anyone gotten real prioritization value out of a platform like that, or are you still triaging manually after the scan runs?

A Tale of Two SOCs: Insights From Two Red Team Assessments is a must read report for your technical teams that CISA just released. It analyzes two simultaneous red team assessments conducted on organizations to evaluate their threat detection and response capabilities.

Both entities suffered full domain compromise and the red team was able to pivot from on-prem to Azure. However organization B successfully isolated initial threats, forcing the red team to adopt an assume breach model while organization A failed to identify the intrusion due to untuned detection tools and organizational silos.

The top three lessons shared that we can learn from:

• Untuned detection tools lead to missed threats. Without well-defined baselines and alert filtering, false positives and routine alerts overwhelm network defenders.
• Organizational silos and bureaucratic hurdles prevent effective incident response. Detection tools are only as effective as the people, processes, and procedures supporting them; fragmented communication, unclear responsibilities, and limited defender authority hinder effective incident response.
• Cloud environments are often an underestimated risk. Organizations often lack security controls for cloud environments and processes for responding to a cloud compromise.

Our alert backlog and investigation times have both crept up, and we're starting to miss things we shouldn't, so I've been taking vendor calls more seriously this quarter.

Six demos in, and slide five is always some version of the same before and after chart mentioning faster investigations" and "AI-powered detection. At some point, all the pitches start to look the same.

I know the underlying problem is real. What I don't know is how to differentiate real value from fluff and empty promises disguised as a good deck in a 30 minute call.

So for the CISOs here who've gone through a real evaluation process, did you find a specific question that helps you understand whether a vendor can actually back up their claims? How do you tell apart the ones who deliver versus the ones who just repeat the same talking points when pushed? Any advice would be really helpful.

Are you looked at as "the Department of no" in your organization?

Hey all,

I saw another post here recently from a startup looking for a CISO advisor and thought we’d ask as well.

We’re a startup in SF building around a problem I’m guessing more teams are starting to run into: employees want AI tools like Claude, ChatGPT, Cursor, etc. to actually do things in company systems, while security needs some control/visibility over what those agents can access and do.

We’ve built quite a bit around this problem, but there’s a big difference between “we think our security model makes sense” and having someone who has actually been responsible for approving this stuff tell us where it falls apart.

So I’m looking for a CISO, current or former, who’d be open to advising us from time to time. Finance/fintech or SaaS would be especially helpful.

A lot of what I want help with is pretty straightforward: What are we overlooking? What would kill this in a security review? What would you need visibility into? Where would you draw hard lines around what an AI agent can and can’t do?

Not looking for someone to rubber stamp what we’ve built. Quite the opposite.

If advising sounds interesting, feel free to DM me.

Otherwise, I’d be really curious what people about below:

If an employee wanted to let an AI agent access and take actions in Sharepoint, Google Workspace, Jira, Slack, Salesforce, or other company systems, what would you need in place before approving it?

Hey everyone,

I am actively seeking full-time job opportunities as a Senior Application Security Engineer, Product Security Lead, or VAPT Lead (Open to Remote / Hybrid / On-site opportunities).

Certifications: OSCP, OSWP, CEH, Microsoft Azure Fundamentals. 

Notice Period - 1 Month

Experience - 8 Years+

what do you think is stopping AI agent adoption in the healthcare software space?

outsiders POV : I'm thinking security but how would u guys solve this from inside the industry?

So, to give some background. I lead the threat intelligence program of a major bank. Now we receive tons of IOCs/CVEs and brand abuse/impersonation cases and we do take action on them accordingly.

But whenever we create a presentation, it's always numbers

- no. Of IOCs we received, sources (regulator/commercials)

- social media/brand abuse/impersonation/rogue apps count & takedown status.

But execs don't understand these numbers. How can I present the data such that they are assured that we are safe from any kind of threat & prepared for what's coming in the future.

Been researching lots of things but didn't quite get anything. Would really appreciate your views and guidance here.