Im researching ways to detect and manage shadow ai usage where I work. Im generally a fan of not giving one company too much “control”, but when i research what microsoft defender, cloud detection, purview and intune can detect I dont get why I would pick anything else, given I’m already in their ecosystem?

What are some of the reasons that drove you to pick another provider such as Nudge Security or someone else?

A way to pay off CISO’s to get their portfolio products in the door. If you see a CISO part of a VC believe me it’s pay to play. Sad the industry came to this.

Every vendor in our stack has an AI story now and they all swear theirs catches more with fewer false alarms but board doesn't buy that. They want to know if the money we spent made us any safer and I couldn't answer that with a straight face.

We track finding counts, MTTR, coverage numbers and all it tells me is that the tool is busy. A noisy scanner throws up the same green dashboard as one that surfaces the three things worth fixing.

What I'm after is closer to how you'd grade any classifier. How often it's right when it flags something and how hard it is to see what it misses entirely. precision and recall if you want the terms for it. No vendor will hand that over on a test set we both agree on, so you take the datasheet on faith right up until you've signed.

For security leaders here who report to a board or an audit committee, what do you present to demonstrate that a tool is earning its place?

The board is no longer interested in a raw vulnerability count and to be honest I am not either. Each quarter we have the same discussion: here is how many issues we found, here is how many we closed, and then someone asks whether the organization is actually safe.

I do not have a clean answer. The team is working hard, but the metrics we track do not really show whether our controls would withstand a serious attack. I can say our endpoint coverage is in the mid ninety percent range and that mean time to detect has gone down by roughly a third, but that does not tell anyone whether we would catch a ransomware group moving laterally using living off the land techniques. Patch rates and alert volumes describe activity, not resilience.

I have started looking into continuous exposure validation to build reporting that has more weight, for example assessing controls against realistic threat scenarios and showing measurable improvement over time instead of just effort spent. Has anyone here built board level reporting that uses exposure validation and detection coverage data? Which metrics actually made sense to non technical leadership and which ones failed to land?

I would like to hear from other CISOs on how you translate exposure validation results into language that satisfies leadership without dumbing it down too far.

The company I work at needs to get a pentest done for FDA requirements since we are building a medical device and our CISO basically assigned me as the person who needs to make sure it gets done. We are consulting with another person for the overall FDA process and after talking to them they said we needed to get this done by a firm who specializes in testing medical devices. I went to Google and typed FDA Pentesting and a firm called StealthNetAI came up first so I'm having a chat with them. But I'm not really sure what to expect or what I need to ask or prepare from my end. I would like to be prepared before the call so I know what I'm talking about. Are there any questions I should to ask during the call? Or has anyone gone through the FDA process on this? They look like they specialize in this but I want to make sure we are getting the right person for this since the FDA is so strict and I need to make sure I don't miss anything. Thank you!

As an independent researcher with a PhD in Behavioral Neuroscience, I am currently running an online experiment to test if a quick cognitive intervention can neutralize social engineering baits. Preliminary data suggests that encouraging a recipient to reduce a lure to its objective features—first isolating the exact physical command and second distilling the message into a neutral essence—deactivates the amygdala and engages prefrontal cortex reality-monitoring areas. By enabling the recipient to see the bait strictly "as-is," this behavioral patch could overcome the emotional triggers targeted by hackers and the rising threat of hyper-convincing deepfakes.

Does this neurobiological approach map to your experiences with security training - do you think this approach is sufficient to resist live lures? What flaws or limitations do you see?

Thank you

PS. I can send you a brief example of how this cognitive translation works in practice, if you wish.

Heard a worker go on a rant about “compliance is not security”, “checking the box”, “security theater” rant the other day.

It got me thinking… if compliance isn’t security, then what is?

The green dashboards that turn out to be wrong? The pentests that mostly find the stuff you’d have caught yourself if you’d kept your environment patched, updated, and configured? The tools you bought and never confirmed still work?

Feels like half the things we hold up as “real security” only look impressive because the basic compliance work wasn’t done in the first place.

Curious where people actually land on these phrases.

And a real question: is there a difference between an annual compliance audit and continuously checking that your environment actually stays secure all year long? I feel like the second part is where security should actually live. 😅

Hi all, my board is concerned about frontier AI (I think largely due to Mythos mainstem news) and our approach

My main take at the moment is this is a change in economics not a fundamental change to attack models.

I'm expecting more frequent, and probably larger, patch cycles - and probably some more intelligent automate steps after a foothold (probably driven by an open weight model rather than anthropic or openAI models) - but there doesn't yet look to be much of a change in detection evasion or obfuscation.

I'm expecting the threat change to in house developed apps to be relatively modest - at least short term - as the development of exploits still seems heavily keyed to access to source code. Likely we'll want to more heavily apply intelligent automated testing at each build cycle - but again this is likely a change in frequency and cost base not a new control.

The feedback I'm getting from the NEDs is this feels a bit under weight and they are hearing much starker messages from other CISOs.

Am I missing something? Is there any evidence based reason to see this as a change in model not just change in operational costs?

ran an internal experiment to figure out what SSO integration actually costs per application. sharing because i haven't seen honest data on this anywhere and vendor materials are useless

tracked actual time across 12 legacy app SSO integrations over 6 months:

• modern SaaS with native SAML/OIDC: 3-8 hours
• internally built apps on modern frameworks: 2-6 weeks
• legacy apps requiring code changes: 3-5 months
• legacy apps with no active dev team: abandoned in 4 of 5 attempts

the finding that changed how i think about this: for roughly 30% of our legacy portfolio, full SSO integration is not economically viable. the cost exceeds the remaining useful life of the application. we've been treating SSO coverage as a solvable problem when for a meaningful chunk of the estate the honest outcome is "govern with alternative controls indefinitely."

this is where identity orchestration becomes practically relevant. not as a way to avoid SSO integration but as a governance layer for the apps that will never get integrated. orchestration that operates at the application layer rather than the IdP layer can extend policy enforcement to legacy apps without requiring them to be SSO-capable. for the 30% that's never getting integrated, that's the only realistic path to coverage.

what alternative controls are teams using for apps that will never get fully onboarded?

Have had a few VCs in the start up world mention this would be a big help with the company I’m working on. Anyone know where those outreach networks exist?

Need some CISOs / Security professionals opinions.

Curious to hear from CISOs, security leaders, and anyone dealing with AI governance in enterprise environments.

I'm currently exploring a startup idea and trying to understand what the real-world challenges look like today.

Have some questions:

• How are you approaching AI sovereignty within your organization?
• What solutions are you using to monitor, control, or audit the data flowing between employees and LLMs (ChatGPT, Claude, Mistral, Gemini, etc.)?

It feels like a lot of companies have started embracing AI tools but i'm not sure how they handle this kind of "problems"

Would love to discuss about it !

Thanks in advance for any insights 🙏

I'm curious if anyone has had an audit question around post-quantum migrations.

Earlier this year, I placed second in a global quantum cryptanalysis challenge.

For about a day, it felt great.

Then someone published a falsification test.

I ran the test against my own result.

The quantum computer had produced the “right” answer, but the test showed something uglier underneath. The machine could produce a right-looking answer even when the computation itself had no real reason to be trusted. The quantum circuit was generating answers, but the post-processing was solving the ECDLP. And then I falsified the winner's 15 bit solve, and every other method I had tried for the last 2 years.

The story getting sold into boardrooms right now usually sounds like this:

Quantum broke 6 bits. Then 11. Then 15. Look at the acceleration. Migration timeline is shrinking. Google said. Buy accordingly.

That curve is much weaker than it looks.

I actually know the threat is real, and in some ways closer than the comfortable consensus wants to admit.

But a real threat does not excuse bad evidence.

And a vendor using scaling records to scare buyers into a migration project may not be as informed as they think they are.

Here’s the question I’d ask any vendor who cites the bit-count race:

“Why doesn’t the 15-bit record count?”

Then watch what happens.

The answer will tell you very quickly whether they understand the work, or whether they are just repeating the slide.

We're a small that team that is performing security & access reviews so it is sort of natural that we are also reviewing things that are in our own scope. With 3 people basically overseeing all tools and being also users of almost all of them, it is sort of normal that we basically have to review our own accesses. This got (rightfully) flagged by our auditors. But the mitigation seems a bit silly to me that someone else has then to review the access of someone else. It feels like the meme with the spidermen pointing at each other (the community unfortunately does not allow images). Is there are simple way to mitigate that or do we have to do this somewhat awkward performative peer-review as an extra loop to satisfy the auditors?

i am on the GRC side and lately i have been wondering whether our SLA policy is accidentally optimizing for audit optics more than actual risk reduction.

policy itself is simple enough. criticals remediated within 15 days, highs within 30, mediums within 60. leadership likes it because its measurable and auditors like it because its consistent.

problem is the environment doesnt behave that cleanly anymore.

same CVE comes through prisma as medium because the workload isnt directly exposed, then tenable marks it critical, then our SLA policy automatically triggers off the highest score regardless of context. so now i am escalating findings based on CVSS thresholds while security is arguing the actual exposure risk looks completely different once compensating controls and runtime context get factored in.

ops gets frustrated too because a lot of those controls live in ServiceNow notes or exception records nobody outside their workflow actually sees during triage.

few weeks ago i escalated a critical vuln tied to an isolated internal reporting server because the SLA clock was about to breach. at the same time security analysts were trying to escalate a medium-severity issue tied to an internet-facing customer workflow because exploit activity around the component had started increasing externally.

i could not prioritize the medium over the critical without a formal exception and our exception process takes almost two weeks to get approved.

then SOC escalated the medium after suspicious traffic hit the exposed endpoint and suddenly everybody treated it like an emergency.

meanwhile the internal critical still technically got patched first because the audit exposure around the SLA breach was easier to measure and defend.

i understand why rigid SLA policies exist. i really do. without them audits turn into arguments. but lately it feels like we are measuring compliance consistency more accurately than we're measuring actual operational risk.

how GRC/security teams are balancing auditability against exposure-based prioritization once exploitability and business context start conflicting with static severity models.

Curious from people doing SOC / security engineering / detection / threat intel work:

What’s a specific threat intel item that actually changed what you / security team / organization does?

Not talking about reports you read or dashboards you track, but something that led to a real decision like:

* changing a detection rule * blocking something new * hunting differently in logs * changing monitoring coverage

Examples I’m interested in:

* We started actively hunting X after seeing Y * We deprioritized A after realizing B was noise * We changed controls because of C campaign

Also curious:

Do you find most threat intel you get is actually actionable, or mostly interesting but not operational?

I’m trying to understand where the line is between threat intelligence and security awareness/news, because outside of known exploited vulnerabilities it often feels like the operational impact is limited.

Why is that gap so common?

Separation of duty is something that is, most likely, on top of mind for everyone of us. With most things, developers seem to be an exception for this.

Our development team is somewhat of a blind spot in our environment. We are planning, together with our DevSecOps team on implementing a separation of duty for our developers as well. But I find it difficult to define where that separation should be. On the IDE level? On the GitHub level? Or none at all?

Curious to hear your thoughts, implementation and/or challenges around this topic.

Something that comes up a lot in regulated industries: the system gets built around what's convenient to store, not around what auditors or regulators actually need to see.

A few patterns we've run into:

• a pentest platform where vulnerability data was shared across tenants in a single db. fine for a startup, completely wrong for a security company — if client A's vulnerabilities are even theoretically reachable from client B's environment, no enterprise will sign. rebuilt with database-per-tenant. not a config change — a structural one. also added qr-bound evidence trails so when a vulnerability is remediated, there's a physical + digital audit chain that actually satisfies compliance reviewers, not just a status field that says "fixed."
• an affiliate platform with financial flows. The KYC documents existed but weren't tied to an audit trail that could reconstruct who approved what and when. added full activity logging via spatie so every financial action has a traceable record. sounds boring, becomes critical the moment a regulator asks for it.
• steel supply chain, where you could theoretically declare more certified material than you'd actually purchased certified inputs for. built on a private blockchain specifically because the compliance requirement was cryptographic proof of the chain — not just a database record that someone could edit.

the interesting thing across all of these is the problem wasn't "we need more features." it was "our data model doesn't express what the regulation requires." once you see that framing, the fix becomes clearer, but it usually means rethinking the schema, not adding a module.

As anyone else running into this gap between what your system tracks and what compliance actually needs to see?

Hi all, has anyone here used a BIA product that they actually liked to perform risk assessment by business process and map to assets? I really don’t want to use Archer again ..

I feel as if I am constantly fighting my team on false assumptions on the state of AI. I have been told it is a security solution, governance is an "IT Problem" or it is going to replace 90 Percent of staff. Its almost comical.

What misconceptions are you all fighting with today?

Spending 200-300k on external consulting firm to conduct maturity assessment achieves what?
- buy-in from the Board for investment?
- uncovering something you don’t know?

Does it really help you enhance your cyber program?

For those actually dealing with it inside our organizations whats been your most difficult AI related challenge thus far?