I am a Senior Security Architect and have been tasked by senior management to create a unified presentation deck (combining two distinct security products) with a peer.
My challenge: I’ve built a specific, high-fidelity architectural strategy for my accounts that I need to maintain control over. My manager’s goal is a simplified sales narrative for stakeholders, but I am concerned that this collaboration will lead to "credit capture" or allow my peer to draft off my technical work without actually understanding the underlying blueprints.
I want to fulfill the management directive to provide the unified deck without diluting the technical integrity of my work or compromising my ownership of the strategy.
Has anyone navigated a "forced collaboration" on a high-stakes deliverable? How do you maintain a "hard target" professional perimeter in joint working sessions while still delivering exactly what management asked for?

Hi,

We currently have:

• Managed SOC service provided by a third party
• XDR solution that includes IR support, with a capped number of IR hours
• Approved Cybersecurity Incident Response Plan

We now need to develop an IR Testing Plan document including testing scenarios. We never did the testing.

I would appreciate guidance from the community on:

what sections and level of detail should it include?

which scenarios should we prioritize for example Table top discussion on scenarios or technical simulation

who should moderate the exercise?

how many scenarios should be included in the first testing

Thanks in advance

The certificate gets you through the first door.
The follow-up questions are where the real security conversation starts.

I am an MSc researcher studying Network Intrusion Detection System (NIDS) selection for resource-constrained financial institutions and looking for cybersecurity practitioners with 5+ years of experience to complete a short survey. Happy to share findings upon request.

Survey link: https://forms.gle/tyxsFA44HXZ5VaMY7

Thanks You.

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 trying to get more proactive around a handful of high-priority external assets and are looking for a platform that can continuously validate exposure on those systems.

Most of what I've seen seems geared toward running scans on a monthly basis, which feels too infrequent. Ideally we'd be able to focus on a specific set of assets and run testing much more regularly.

Has anyone found a solution they're happy with? Curious what's working well in practice.

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?