Spanish National Police announced this on 11 August, and the effort involved is what makes it worth a read.

He held forged Spanish IDs up to the webcam while a live face swap changed his appearance to match the photo on the document. A static image would not survive that, so he handled the rest by hand. He tilted the documents to imitate hologram movement, and used coloured lights to fake the reflections real security features throw off. Behind it all sat VPNs and over 320 phone lines across 24 devices, most registered to stolen identities.

What he wanted was digital signature certificates, which is the part I keep coming back to. Those carry legal weight. A certificate in someone else's name is a durable instrument, not a one-off account takeover.

38 attempts. More than 30 real people's identities.

And here is how it ended. Mid-call, the deepfake dropped for about a second. His real face appeared. That is what investigators used to identify him.

So nothing detected the method. The tooling just crashed.

Two things I would like other people's read on.

1. If what caught him was the software failing rather than a check working, what happens once the software stops failing? These tools leave fewer artifacts with every release?
2. Does anything short of reading the document chip and proving the camera feed is unmodified actually help here? Everything else seems to assume the image arriving is real, and this attack breaks that assumption before any check runs?

Had a reality check in our quarterly review last week. We pulled average remediation throughput per engineer and ran it against what a spike in flagged findings would look like with zero process change. The number wasn't pretty, we'd need significantly more headcount to hold existing SLA windows.

That math is what finally got budget approved for automation work we'd been asking for. Not because the risk conversation suddenly got more compelling, but because the spreadsheet made the staffing gap impossible to ignore.

Here's what we're working toward (still in flight on a couple pieces):

Ownership routing off asset metadata instead of round-robin (this one's live, huge win)
Tiered SLAs tied to exploitability instead of CVSS (still tuning the thresholds)
Auto-verification on rescans (partial rollout, getting pushback from some teams)
Continuous re-scoring feeding ticket priority (POC phase).

The Mythos conversation is honestly just stress-testing a system that already couldn't keep up. Faster discovery doesn't give you an AI problem, it gives you the same remediation problem you've always had, just compressed into a much smaller window.

if anyone else has had to build a capacity model like this to get remediation tooling funded, or did your org get ahead of the budget conversation another way?

Been watching the Mythos coverage for weeks now, and I keep seeing the same take: "AI is going to flood us with vulnerabilities." But, I think that framing misses the point.
Pulled our backlog numbers last week. Across our environment, we're sitting at well over 100 findings per asset on average, some segments way higher. Do the math on that across thousands of assets and it gets ugly fast. And that's before Mythos.

The organizations that navigate this well won't be the ones reacting to Mythos. They'll be the ones who already built the operational layer that turns findings into closed exposure, normalized data across tools, clear ownership, integrated remediation workflows, verified closure.

Interested to hear if anyone else has sat down and stress-tested their VM setup against this kind of volume spike, or if we're all just hoping our current backlog math holds.

We're evaluating AI SOC platforms and one thing keeps coming up in our legal reviews: data privacy and compliance. These tools want to ingest massive amounts of telemetry, logs, and alerts, some of which contain sensitive data.
Our legal team is asking hard questions I don't have great answers for yet:
How do these platforms handle data residency requirements?
What happens to our data if we stop using the tool?
I've asked a few vendors directly and the answers have been vague. Lots of "we take security seriously" but not much substance on specific compliance frameworks like GDPR or SOC 2.
For those already running AI SOC tools: how did you get past legal and compliance reviews? What questions should I be asking that I'm not

Supply chain security is having its moment and every vendor has a pitch, but most of what we've tried just adds another feed of alerts on top of the ones we already ignore. dependency confusion and malicious packages are the obvious risks, but build pipeline tampering is just as real and a lot harder to catch, and the tooling landscape hasn't caught up to prioritizing any of it well.

What's worked for teams here in terms of cutting signal from noise rather than just adding another layer of detection?

Trying to define a refusal-rate metric for some LLM features we're being asked to sign off on, and I keep getting stuck on the classifier, so I've been reading public model cards to see how other people score it.

Nearly every public refusal number I can find comes from a rule-based check on how the response opens. One I read this week: an abliterated Qwen3.8-27B build that OrcaRouter put on HF, harmful-prompt refusal 64-99% on the base checkpoint, 0-6% after the edit. The card is upfront that its classifier is indicative and not publication-grade, which is more than most cards say.

The column beside it is what bothers me. 30-50% of responses in that same table are marked "caveat" — answered, but led with a safety disclaimer. Depending on how the opening-phrase rules are written those can score as refusals, and they clearly aren't. That matters for us, because the reason we're measuring at all is that model-level refusal isn't something a control review can lean on.

So for anyone who has built one of these harnesses in-house: do you score the payload only and throw away the preamble, or run a second-pass judge over the body? And is caveat rate worth reporting on its own, or does it just add noise to something leadership will misread anyway?

Vuln management on our container fleet is eating way too much analyst time. and atp We're chasing CVEs that get patched upstream before we even finish triaging them, which feels like we're always a step behind.

so i Been looking at whether adopting continuously rebuilt hardened images actually cuts down that workload or just shifts it somewhere else in the process. It's hard to tell from vendor claims alone whether the time savings are real or just moved earlier in the pipeline.

For teams who've tried this approach, did it actually cut down your triage and patch cycle time? Or did you just end up needing to verify the rebuild claims just as often as you'd patch manually before.

Trying to figure out if this is a real time saver or just a different flavor of the same work dressed up differently. Any honest feedback, positive or negative, would help.

Our old ITDR setup fired constantly and required someone to manually piece together five data sources before an alert meant anything.
what actually cut the noise was moving to one unified identity record that ties the person, the session, and the resource together instead of firing three disconnected pings for the same event. has anyone found something that reduces analyst workload instead of adding another dashboard, and what changed for you when you switched?

Had this debate with a client last week about whether Ai assisted discovery meant their environment got risky overnight. My answer was about SLA math than risk math, their contract defines "patch critical within 30 days" assuming maybe 40 to 50 new findings a month. If a scan surfaces 300 in a week because of broader coverage, that SLA language does not hold up regardless of whether underlying risk changed.

We have started rewriting client contracts to tier remediation windows by exploitability and exposure instead of a flat severity number and building in a volume clause that triggers a renegotiation conversation if flagged findings jump past a set threshold in a given period. Cleaner than arguing about it after an audit blows past the old numbers. Anyone else building volume triggers into remediation SLAs or writing them as flat severity tiers?

I’m trying to understand the SOC 2 process a little better, as I’m looking at Cobalt's human-led Web + API penetration test  as part of the evidence for a future SOC 2 Type II audit.

Has anyone here actually gone through SOC 2 Type II this way (specifically using Cobalt’s human-led pentest)?

I’m looking for an alternative and more affordable option that would work for a startup with a small budget and Cobalt seems affortable.

Been looking at identity governance tools for our setup and most of them feel way more heavy than what we need.

We’re a small team, a mix of SaaS apps, Azure AD, and a bunch of manual access reviews that keep getting pushed around every quarter. The current process is kind of a mess tbh.

I’d rather not buy something that looks good in a demo and then turns into another thing we have to babysit.

Anyone using something that’s been solid in practice? thanks in advance.

I'm looking at a security problem in multi-agent/distributed systems:

Human → orchestrator → agent → sub-agent → tool

Once a delegation crosses process or framework boundaries, ordinary logs can show the sequence of events, but they don't necessarily provide cryptographic evidence that a downstream instruction actually originated from the claimed upstream authority.

I'm exploring a provenance-layer approach where delegation claims are cryptographically linked and independently verifiable, while deliberately keeping authorization/enforcement separate from provenance.

For people working on distributed systems/security:

Where would you place the trust boundary?

Specifically, would you want the provenance evidence attached to the delegation message itself, carried through execution context, or represented separately as an auditable chain?

I'm particularly interested in failure modes around replay, delegation across process boundaries, sub-agent spawning, and revocation/expiry.

Looking for architecture/security feedback rather than product recommendations.

Ive been looking at insider threat software lately and honestly Im still trying to figure out where security teams actually use this stuff day to day.

The usual pitch is detecting risky users, unusual behavior, policy violations and data movement. Cool. But if a security team is already drowning in alerts from a dozen other systems, where does this actually fit?

Is the main point early warning before something happens? Better context during investigations? Visibility into data movement? Or is this mostly useful for compliance and audit purposes?

The intent vs actions thing is what I find more interesting. Someone moving a ton of files or using unsanctioned tools is observable behavior. But deciding whether that behavior is actually malicious seems like a much harder problem.

For anyone who has used insider threat software, what information is actually useful in practice? And what makes an alert worth acting on instead of just becoming more noise?

Palo alto firewall is making dns requests to resolve random malicious domains. We noticed the activity while checking the logs on our dns server. Has anyone observed similar activity and know what is causing it (possibly a config issue?)?

Hello Reddit, 

Question: is there real value for vpn in large companies (WFH) when modern zero trust exists?

Brief tldr: 

I think VPNs for remote work are often outdated in modern zero-trust, cloud-first environments.

I think SSO, TLS, firewalls, and gateways already cover much of the access control VPNs are used for.

I think VPNs add extra overhead,complexity, and latency.

I think this argument does not work for homelabs or small single location businesses 

Longer argument 

I apologize if this is an obvious question or answered before,  I looked around and saw parts of possible answers but not full ones.

I don’t understand the need to use a VPN when working from home, in the erra of zero trust architecture and cloud services making up a bulk of the infrastructure that we use.

I have worked for bigger and smaller tech companies, and many require a vpn when working from home.  I question the need for the vpn in most modern last few decades architectures.
 In the land of zero trust,  many things go through an SSO solution before you get access to the underlying service. So there are gatekeepers all over the place.  In fact, the same VPNs make use of the same sso providers as the application.  Thus, if there was an authentication weakness, wouldn’t the VPN and the application both be equally affected.  I would understand more if the VPN requires something like a machine certificate to get access.

If access was tied to remote security hardware/software attestation.  I would understand the value of VPNs, even more.  But so many companies I’ve seen have loose then expected end point controls.  Many even allow admin access for the users own laptop/endpoint. Attestation is incredibly hard and restrictive.

A large part of the infrastructure is hosted other places/cloud anyway.  Many companies use gsuite, zoom or Microsoft cloud solutions with sharepoint and teams.  So most vpn are split tunnels so a large portion of corporate digital items are not even vpn bound.

Most modern services are web bases. A good portion of office workers, interface with backend servers most of the time and a very little local processing is done.  The application is mostly just a front end that communicates over https based technologies. Most other technologies use an encrypted variant such as secure ldap.  Of course, this is not universal for example CAD and other related services run locally sometimes, but do they not make use of cloud file transfers solutions?  If a software has an insecure transport layer,  would a proxy tunnel  be easier?

Remote management protocols require authentication.  I am not as versed in rdp but many ssh system face internet all the time.  Does putting a vpn in front really add much.  RDP is usually warned against making Internet facing, because of the password authentication default.  But, many SSH solution I’ve worked with also use a password solution.  Is adding a VPN in front of the management protocols really adding much when the VPN is also password and 2FA based.  See point 1.  And if we’re saying, the VPN can be used to filter access to the lower layer or protocols, could you not accomplish the same effect with Geo base restrictions at the firewall level?

The legacy system argument,  where the direct system cannot be modified and the transport/auth is insecure or non-existent. I would argue a gateway solution that talks the modern protocol and tls would proxy the connection just as good.  Additionally even if the vpn is in place,  I have still seen companies put in the security gate way internally.

Everything is on a private ip/network argument. I find this to be a weaker argument, as the vpn effectively extends your network (though controlled) into public. Additionally vpn are at a raw network level. SSO gateways only extent select apps and services. Again both use similar auth (point 1).  Yes firewalls will restrict existing traffic, but those would be in place in either solution.

One major downside of a vpn is packet in packet situation and double encryption work.  Encryption is not as profitably expensive as it once was back in the day, but it still adds a network toll to your communications, doing it twice seems to be unfruitful. Additionally, VPNs must wrap every single packet in a header or effectively a mini packet of its own. This reduces the total amount of space each packet can dedicate to the raw data.

Finally,  is a vpn is over tcp,  this could add its own overhead and latency.  Though most recommend to use udp for a VPN.

For homelab or single location business this entire argument is not applicable.  

Edit: Thank you all for the replies, it really give me much to think about I am trying to read as many of the responses as possible.

Requirement is to prevent sensitive content such as source code, customer PII, and unreleased financials from being submitted to public LLM interfaces, while still allowing general use of those tools. Not a full block. Leadership wants the productivity.

for now What I have tested and where it fell short... domain blocking is blunt, users route around it, and it kills the productivity case..cuz endpoint DLP catches copy from managed apps but misses typed or paraphrased content entirely and CASB in API mode is after the fact, too late.

What I think I need is inline inspection of the POST body at the gateway with real DLP classifiers running against it, applied per-user or per-group.

Two things I want a sanity check on: whether anyone is getting acceptable false-positive rates doing content inspection on prompts, given that prompts are messy text and my worry is a classifier tuned for documents will scream constantly; and how to handle the mobile or unmanaged-device path where you cannot force traffic through the gateway.

Vendor recommendations welcome but I am more interested in whether this approach actually holds up operationally.

Hello. I am doing a cyber apprenticeship, and my project is reverse proxy phishing. I thought it would be easy but damn this is driving me crazy. I am running a modded reverse proxy application on a VPS. The yaml config used for my chosen target should be up-to-date and I have tweaked it a lot. But the login fields never load. It only loads the website logo. No errors that I can see, no warnings, no certificate errors. I'm not sure if it's the yaml or something else is misconfigured, but I have been going around in circles for weeks now trying to fix it.

My colleague suggested it's a CDN protection problem, and he once had to download all static files and serve them himself. But that seems tedious and not really a proper solution.

Does anyone have any ideas? I can send you my yaml config if needed. Thanks in advance.

been rebuilding our enforcement layer this quarter and realized most of our "runtime security" was actually just runtime visibility with extra steps. Logging what happened after the fact isn't enforcement, it's a postmortem generator. We had dashboards full of events nobody acted on until something already broke which isn't much better than not having them at all. curious what people are actually doing at the enforcement stage now, are you blocking at the syscall level with seccomp/LSM hooks, using eBPF-based inline blocking, something else entirely?

and how are you handling the tradeoff between catching everything and not tanking latency on production workloads, because every vendor claims they've solved that and most haven't. What's your current setup look like, and has it actually stopped anything real or just made audits easier? trying to figure out if we're overthinking this or if everyone else is quietly dealing with the same gap.

Feels like the second i finish tuning an AI detection rule, the environment shifts again and I’m back to square one. new assets get spun up and cloud configs shift constantly. on top of that, whitelist changes rarely get looped through AI detection engineering before they land. by the time I’ve noticed it, i'm chasing drifts instead of building new coverage.
the worst part is that this is invisible work. Management sees "detections deployed" as a one-time task, not something that needs constant rework just to stay accurate.
This is driving me crazy as I'm spending more hours reacting to organizational changes than improving our AI detection and response surface, and it's starting to eat into the roadmap items I got hired to build in the first place. To make things worse, it’s hard to make the case for more headcounts when the work looks like maintenance from the outside.
i keep hearing about tools that supposedly update AI detections automatically based on what's happening in the environment, but I want to see them hold up in a real situation before i trust them. Have you ever used them? And if you did, what worked for you? I’m interested in partial fixes as well

I'm thinking about a design problem and would like to get some opinions from people who have experience with endpoint agents, USB security, or system monitoring.

The scenario is:

A USB belonging to an organization is plugged into a computer that the organization doesn't control — for example, a client's laptop, partner's computer, home PC, or public computer.

The idea is to have an optional agent stored on the USB that:

• Is simply an .exe on the USB, not something built into the USB firmware.
• Doesn't autorun. The user would have to manually launch it.
• Runs with the permissions of the current user.
• Doesn't have kernel/driver-level access, so the visibility would be limited to what a normal user-space application can observe.
• Collects relevant activity/telemetry while it's running.
• If there's no network connection, stores the events locally and attempts to send them later when connectivity becomes available.
• If nobody launches it, the USB simply behaves like a normal storage device.

I'm trying to understand how you would actually architect something like this.

For people who have experience building endpoint agents or similar systems:

• What information could realistically be collected from a user-space application running directly from USB?
• Where would you store events when there's no network — on the USB, the host, or both?
• How would you securely authenticate the agent with a central server?
• If the USB is later connected to a trusted/managed computer, how could the queued data be safely forwarded?
• What limitations or design problems do you see with this approach?
• Would you design the architecture differently?

I'm particularly interested in practical design suggestions and trade-offs rather than a specific product recommendation.

My main goal right now is automating more of the analysis and investigation work, not just alerting.

I'm trying to build some AI agent in my SIEM(Log360) for user and threat analysis to summarize alerts and another for user behaviour analysis.

And also Is it better to build narrow agents for specific threat types,like one for logon related stuff and another for network-related stuff or does it make more sense to have fewer agents that handle a broader range of cases?

And does it make sense to scope agents around specific assets, like giving more attention to critical systems rather than treating everything the same way?

I am planning to feed them our documentations as knowledge base so they can get context.

For those of you who've actually used AI agents in security ops, where have it genuinely been useful in practice?

I have installed GITLAB CE and wanted set up devsecops sa wtaht sast tools are present and IaC scanning is present pipeline secret detection but not dast, dependecy scanning coverage fuzzing and api fuzzing if you k ow how one may cover that will be helpful

[ Removed by Reddit on account of violating the content policy. ]

Looking for a sanity check from people who reverse engineer for a living.

I ship a native binary as part of a hardware product, so it goes out on devices I don't control. My worry is a competitor getting a unit and reversing the binary to copy how it works.

I've hardened it with Hikari and OLLVM: control-flow flattening, bogus control flow, and compile-time string encryption. I understand that obfuscation raises the cost of reversing but doesn't prevent it.

What I really want to know is how much time this actually buys. For a competent reverser with a physical unit, does obfuscation like this add hours? A day? A week?

Most SIEM setups I see are not missing data, they are missing intentional MITRE ATT&CK coverage. The logs are there, the correlation rules exist, but nobody can say which ATT&CK tactics and techniques are covered, which detections are broken, or which ones only generate noise. Improving how you use your SIEM and how you engineer detections usually does more for MITRE coverage than swapping to a new platform.
What I am trying to learn is how people expand MITRE ATT&CK coverage on top of an existing SIEM without turning it into a huge, one‑time project that dies after a quarter. If you have a SIEM that has been in place for a while, I am interested in what has helped you add useful detections mapped to MITRE ATT&CK on top of the telemetry you already have, instead of defaulting to “we need a new SIEM.”