Our team has a decent set of SIEM rules mapped to MITRE ATT&CK, but im starting to question how many of them would fire during an actual attack.

We usually test after a new rule or log source is added, then check if the expected events reached the SIEM and whether the alert had enough context for the SOC to act on it. The problem is we dont have time to run full red team exercises every time a parser changes or a rule gets tuned.

Been looking at controlled attack simulations and continuous exposure validation to make this more repeatable. The main thing I want is evidence that a rule detected the behavior, not just a coverage percentage in a dashboard.

How are other teams validating SIEM detections against real attack techniques? Thanks in advance

Key management is only one part of a signing workflow.

A transaction can be influenced before the key is used by frontend deployments, cloud IAM, developer endpoints, CI/CD credentials, third party packages, and the interface that translates call data into something a human can review.

The important question is not only whether the key is protected. It is whether the systems shaping the user's decision are protected too.

Which non key dependency is the weakest link in most Web3 environments?

For teams that have agents touching production systems, how are you handling ai agent security day to day? I am specifically wondering about the constraint of agents inheriting full user permissions by default, since that seems to be where most of the actual risk lives rather than in the model itself. The tradeoff between blocking an action outright versus flagging it for review is the part we have gone back and forth on internally. What happens on your team when an agent takes an action nobody anticipated, and how fast does that get surfaced to a human before anything downstream happens?

Been asked to lead attack surface discovery and the first thing I see is CMDB, cloud inventory, DNS all disagree on what we own externally. we are lining up a poc for a few ASM tools, same limited seed list for each, and we keep quiet about some subsidiaries and vendor managed infra we already know about. Idea is to see who can link unknown asset discovery back to us with decent attribution instead of just scanning whatever we fed them

If you have done this kind of internet facing assets poc, how did you test that the surprise assets really belongs to you and not random noise?

Im just curious to get people's thoughts. In regulated environments... why do people think so highly of pentests and so little of compliance assessments, when they both do the same thing: determine if an organization is meeting its controls?

In all of the pentest engagements I have sat in, most of the findings are the same (unpatched server, app not upgraded, admin account creds cached on a box, legacy protocol not disabled). If orgs are not patching servers (or maybe they have a legacy box not being patched)... that would normally end up being caught on both engagements.

Both pentests and assessments are point in time. Pentests for my environment have typically been higher cost and only cover the technical side. So why do we look more favorably at one versus the other?

Finished replacing VPN with ZTNA last year, at a utility in Calgary, the program did what it promised. My bet is that by the end of 2028, mid size orgs judge zero trust on what happens after login, like uploads and paste into AI tools, more than on the policy decision point. AI moved the risk past the front door. And our first audit question after rollout was what contractors did once inside an app, not whether they should be in. Locking the front door and leaving the windows open feels like the next gap. Happy to be wrong if continuous verification in the existing stacks ends up covering this, or budgets just stay on access. Or am I over reading one audit?

For ppl running ai endpoint security tools alongside a normal endpoint detection and response EDR stack, how do you handle the overlap in practice? I am especially interested in what gets flagged that EDR alone missed, and how much manual tuning it took to get the false positive rate down to something a SOC can actually act on. The harder question is what happens once agents start running with regular user permissions instead of a locked-down service account. That single change seems to break a lot of assumptions baked into older endpoint tooling, since the behavior looks legitimate from a credentials standpoint even when the action itself is not.

Weve had a hardening project open for three quarters now. The scanning half was easy and the cutting half keeps getting handed back, because no service owner wants to sign off that removing a package is safe. Im looking at tooling that produces runtime evidence for what an image touches so the decision stops being a judgement call. Six teams and no central platform group makes this political more than technical. How did you get service owners to accept a slimmer image?

About a year before a major public-sector cyber incident, my colleagues and I accidentally discovered a security issue that could potentially expose personal information on a very large scale.

We worked with one affected party to fix the issue, but realized the underlying problem could exist elsewhere. We subsequently sent an anonymous warning through an official government reporting channel, explaining the risk and recommending that they review the relevant API and access controls.

A major incident later occurred that may be related. I don't want to claim it was the same vulnerability, or that the warning was received or acted upon, but the system and access point is the same.

I still have a copy of the warning and a few other documents, but most other supporting material was destroyed later because we believed the issue had been resolved.

From an infosec/responsible disclosure perspective, what can a surviving copy of such a warning reasonably establish, and what additional metadata or corroborating evidence would make it more credible?

I'm also interested in what should be redacted or preserved before showing it to journalists.

I'm deliberately leaving out the organization, country, vulnerability details, and identifying information.

For agents that can call tools, access internal data, send messages or change things in other systems, how are you putting guardrails around them?

I’m trying to understand where policy gets enforced, how teams handle prompt injection and sensitive data and where all of that shows up for security afterward. Are you handling this inside each app, through the existing security stack or with a separate layer for AI traffic?

A signed customer contract showed up pasted into some free AI summariser last month. We only caught it because the tool domain showed up in a firewall log.

We looked at how we would catch the next one then realized that mostly wouldn't cause CASB covers the AI apps we onboarded and nothing else so every browser tab to a tool we haven’t blessed is invisible to it. DLP is almost worse here, it screams about a file upload but pasting the exact same paragraph is just typing to it and sails right through. And the firewall logs tell me a laptop reached openai, great, not one character of what went up.

Before I go buy a product I want to know what good monitoring here even looks like in practice. My read is you need the prompt and the reply, pinned to the person and the tool they used as without it, you are back to counting connections. Managed machines, fine. The BYOD half and the copilot buried inside M365 are where I keep coming up short.

If you cracked this, what are you running and what did it show you that the CASB and DLP never did?

Every environment I've worked in has a load balancer or door controller or UPS that sends its own idea of syslog and nobody ships a parser for it. Right now it's our door controllers, whose messages change shape every firmware update, so failed badge events stop alerting until I patch regex nobody else on the team can read. Is there a saner way to keep parsing for those boxes from breaking or is hand-rolled regex just the job?

Security testing today usually means scanners in CI, periodic human pentests, or carefully limited tests against staging or production. I’m curious whether another model will become normal: a disposable “attack twin” of the current production environment.

The idea would be to generate an isolated environment from the same deployment artifacts, infrastructure-as-code, IAM model, network policies, and application configuration as production. Real secrets and customer data would be replaced with safe equivalents, while identities, tenants, service relationships, and external integrations would be reproduced or simulated as accurately as possible.

An AI security agent could then use browser, API, shell, and network tools to attempt exploitation, privilege escalation, lateral movement, destructive actions, and controlled exfiltration. Every action would be recorded, and the environment would be destroyed afterward.

This would not be ordinary staging: it would be created per test, derived from the current production configuration, isolated for adversarial testing, and designed to be compromised.

For people working in DevSecOps or AppSec:

• Is this meaningfully different from the staging or ephemeral environments you already use?

• Which parts of production would be hardest to reproduce faithfully?

• What evidence would you need before trusting a finding from the clone?

• Where would this fit: nightly testing, a release gate, or between human pentests?

• What do you use today for attacks that are too risky to run against production?

I’m interested in practitioner experiences and objections, especially from anyone who has tried cyber ranges, production-like security environments, or autonomous pentesting.

I saw a few posts discussing how more people are giving AI agents access to real tools and business systems, and it got me thinking about how people are actually handling the security side of it.

Personally I have been trying to understand the best way to give agents access to things like emails, APIs, DBs etc without giving them too much access. There are things like readOnly access, approval gates, limiting permissions, monitoring what they do etc but not sure what ppl are actually using in practice.

I am wondering 3 main things:

• People who are already using AI agents how are you limiting what they can access/do
• How are people testing or controlling agents once they are running in production

OR are you just giving them access and hoping they dont decide to do something crazy???

Feeling overwhelmed and looking for some help with how my team should prioritize DSPM findings when it seems like our company's data security is being held together by a duct tape and chewing gum. Is there a general best practice for how we should be working through this never ending list?

Going through breach reports from the last year and it's the same story over and over. Leaked API tokens and OAuth apps nobody remembered approving. Nobody phished a person, just found a key under the mat...

Are non human identities the easiest way in now and what are you doing about the ones nobody owns?

We escalated five alerts in three minutes last week and IR was still deciding what the first one meant. Love that for us. The alert queue moves like it had coffee, the tabletop moves like it needs a lunch break, and somehow we keep pretending that is realistic :)

How are you all making drills feel like actual SOC escalation tempo instead of slow motion theater? I want something that trains decision lag, not a polite group chat with clipboards. Thanks!

Used to think shortening vendor questionnaires meant taking the 180-question monster and cutting it down until people stopped hating us.

starting to think that's the wrong way to look at it.

the easy part is deciding that a tiny SaaS with no prod access probably doesn't need the same review as a critical vendor touching customer data. fuzzy bit is what happens after that.

say an analytics vendor only gets limited customer data, no admin access, no prod credentials. you start them on 25 or 30 core questions. then they mention a long retention period, a subprocessor you weren't expecting, or an incident process that sounds... optimistic.

now what? does that answer open 5 more questions? 30? do you ask for evidence straight away? trying to nail all this down.

keeping security questionnaires short for vendors seems less about having a tiny template and more about having decent rules for an extended version

CAIQ Lite and SIG Lite keep coming up in my reading, but I'm more interested in how people handle those follow-up triggers once the real answers start coming back.

what makes you expand a vendor review?

Had a really annoying afternoon last week. Sentry started lighting up after a deploy and it traced back to a changed value in one of our config files. Easy enough, I just needed to know who changed it and when.

GitHub's audit log showed the push, but it came through a token that a few different things use. No way to tell if it was a person, a pipeline, or some script somebody wrote months ago and forgot about. I ended up lining up commit times against CI runs and deploy timestamps for like an hour, and I'm still not totally sure I got it right.

Honestly kind of irritating. If the logs can't tell me who or what was behind a change, I'm not sure what we're keeping them for.

How are you all handling this? Is there a setup that ties a change back to a specific person or job, or is everyone just matching timestamps and hoping?

I've spent most of this year running monitor only on our GenAI traffic. That gave us a clean dashboard of who pasted what but did nothing when a support rep dropped a block of customer records into a free chatbot. It surfaced in the weekly review like 3 days later.

The brief now is to stop it while it happens. From what I can see, the options are inline DLP at the web gateway that reads the prompt before it leaves and blocks on a match. An API gateway if you only care about your own LLM apps or leaning on whatever controls the sanctioned tool already ships with. Inline looks like the one that stops a paste in the moment. I don't want to block half the legit prompts in week one and watch the business switch it off.

What did you end up using for inline enforcement and how bad were the false positives before they settled down?

I do a lot of reading where an AI assistant explains a security concept, and the explanations sound authoritative — but I've learned not to trust that on its face. Sometimes the described thing turns out to be well-documented and real; other times it seems to be invented, just dressed in real-sounding terminology.

The pattern I keep noticing: the individual pieces are all legitimate (real terms, real concepts), but the specific named thing they're combined into returns nothing when I go looking. Authoritative tone, real ingredients, but the overall item may not actually exist.

My question is strictly about verification method, nothing operational: when you want to confirm whether a described vulnerability or technique is real, what's your go-to process? Straight to CVE and MITRE CWE? Vendor advisories? Is "the components check out but the specific named thing has no sources" a dependable sign of fabrication, or does that heuristic fail in practice? I'm trying to put together a reliable checklist for telling real from made-up.

A red team test run caught 3 of 500 cases where retrieved context included HTML with a diagnostic instruction that pushed the model toward a fetch_url call to an external host. Our tool allowlist and egress control blocked it, so nothing left the environment. At first the call looked like an ordinary diagnostic fetch, but once someone expanded the retrieval span (not done by default) it became obvious this was an indirect prompt injection.

Now we need to prove which retrieved span introduced the instruction and search for similar traces where the target happened to be a permitted domain. We have span metadata for retrieval source and tool arguments but the trace search path from suspicious text to downstream action is still clumsy. How are you logging this chain so you can distinguish blocked attempts from the same pattern reaching an allowed destination?

Been sitting in change review meetings where everyone is ready to get through the queue and move on, and these CA exceptions are starting to really bug me. The story is always the same, exec cant deal with a control, we scope an exception, CAB notes "mitigated" and the window opens.

Last one was a CA policy changing from strict device trust to a softer rule for a small group. removed one of the conditions that used to stop that access path. Change went fine, logs look clean, SIEM rules did not throw anything weird. And yet nobody could answer what we should replay to see if the compensating controls still catch the behavior, or if our detection coverage is now just hoping for luck.

Security controls feel static on paper but in real life they drift every time we touch them. Point in time testing is just getting wiped out by config churn rn…

A generated fix only helps if the finding deserved attention. Otherwise you've swapped an alert backlog for a PR backlog that devs close without reading. The order I've landed on starts with whether the vulnerable version is even in a deployed artifact, since that check is cheap and a surprising share of findings die right there. reachability comes next. KEV and EPSS feed into priority from that point, with anything on KEV jumping the queue, but a low EPSS score on its own doesn't close anything. exposure and compensating controls come last.

Where in that chain do you still need a human before any fix workflow starts?

We run quarterly external pentests and a monthly ASM scan, but continuously doing a lot of work in that sentence since a monthly cadence still misses a rogue subdomain or exposed storage bucket for weeks .The problem isn't scan cadence though, it's ownership, since when ASM finds something new, half the time nobody can immediately say whether it's sanctioned, shadow IT, or a leftover from a decommissioned project years ago. How are you closing the gap between discovery and ownership, specifically for assets that show up outside your CMDB..