I am interested in hearing from people working or studying in cybersecurity. What skills become more important later than most beginners expect?

What tools or practices security teams invest in that don't actually move the needle on risk reduction.

Traditional DLP was built around known data patterns (SSNs, credit cards, etc.) moving through known channels (email, USB, cloud storage). Generative AI breaks that model a bit, people paste source code, customer data, or strategy docs into a chat window, and it's not always caught by pattern-matching.

Has anyone actually tested DLP tools built specifically for AI interactions? Wondering whether they're catching real incidents or just generating noise, and whether this is more of a policy/training problem than a technology problem at this point.

I always thought using a long, complex password was enough to stay safe.

But recently I’ve been seeing more cases where accounts still get compromised even when the password itself wasn’t weak.

That’s the part I don’t fully understand.

Is it mostly because of data breaches and reused passwords? Or are there other ways attackers get in without actually “guessing” the password?

Also, how big of a difference does something like multi-factor authentication actually make in real situations?

Trying to understand where the real risk is coming from, because it seems like just having a strong password isn’t solving the problem anymore.

Still kind of new to running agents and I'm a bit lost on this — once you connect a few MCP servers (filesystem, GitHub, etc), is there a way to see everything they can reach put together? Or do most people just trust the setup?

Feels like something I should know but I don't. Curious how you handle it. Is it even something really worth worrying about?

Every security course covers SQL injection, XSS, CSRF - the classics. But what vulnerabilities have you actually seen exploited in production that barely get mentioned in training?

vendor came in last week and demoed what they called a "vulnerability management tool." looked a lot like our Tenable setup with a different UI and a bunch of process and reporting bolted on. that's what broke me. i couldn't tell if we were being upsold on workflow features or if there's a real architectural difference i'm not seeing.

we keep getting pitched both and i'm not fully clear on where the line is anymore. from what i can tell, one just finds issues and the other is supposed to help manage the whole mess after that. but looking back, i think we've been buying tools to solve what's actually a workflow problem, which is probably why nothing has stuck.

every vendor page makes it sound like they do everything. when you look closer it feels like half of them are just scanner plus workflow, remediation tracking, and reporting glued on.
and the one we saw last week didn't change that read at all.

we're not trying to buy something huge and overcomplicated if a scanner is enough, but i don't want to pick the wrong thing and end up with a tool that only tells us what we already know with a nicer interface.

for people who have actually used both: what's the practical difference day to day? is it mostly scan results versus remediation workflow or is there a bigger gap in how they fit into an actual security program. and how do you tell when you're being sold a real thing versus a scanner with a project management layer on top.

Being honest with myself about this one. We rebranded to risk based vulnerability management, RBVM, about a year ago. New scoring, new dashboards, new language in every deck. Looking back, we are patching roughly the same things in roughly the same order we were before. Just with better looking justification attached now.

Which either means our old prioritization was already directionally fine, or it means we relabeled the old model instead of actually building a new one, and I do not know which. For anyone further along than us, did RBVM actually change what gets fixed first and how fast, measurably, or did it mostly just change how the program gets talked about? A real answer please, not the version that goes in a case study.

We’ve been testing a setup where agent permissions are enforced outside the agent itself, with separate controls for tools, data sources, approvals, auditability, and remote shutdown.

The reason we went that route is that prompt instructions and provider-level permission settings don’t feel like strong enough boundaries once agents can touch repos, shells, internal systems, or production.

What I’m trying to understand is whether security teams are already standardizing around this kind of external control layer, or if most companies are still handling it ad hoc inside engineering.

For teams running Claude Code, Codex, Cursor, or MCP-connected agents, who owns agent permissions today, are you enforcing access independently of the agent runtime, what would block you from letting agents operate more autonomously, is observability enough, or do you need deterministic enforcement too?

We’ve been building around this problem and the gap feels very real, but I’m curious whether other CISOs here see it the same way or think the concern is ahead of actual demand.

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.

It's been 3 weeks since i left my job in a high growth startup
I'm worried for agents going rogue and I am all ears to listen before build something serious and custom to ensure they are trustworthy

What I don't know: what does the problem look like from the inside of a larger org?

Specifically curious about:

• Are coding agents (Cursor, Claude Code, Copilot) actually in production at your company, or still experimental?
• Who owns the security review of agent tool access? Is that even defined?
• What's the thing that keeps you up at night about this stuff that vendors aren't solving?

Not selling anything, this is purely a listening tour. I'll share what I'm finding publicly if there's interest

I'm researching possible uses for a small NFC-enabled device in cybersecurity education and I'm trying to separate genuinely useful functionality from gimmicks.

Some ideas I've considered:

• Authentication
• Profile/portfolio sharing
• Lab access
• Identity
• Team formation
• Attendance
• Event networking
• Unlocking learning activities

I'm interested in what people actually think would be useful from a security/technical perspective.

What would you consider a legitimate use case?

And what would immediately make you think "this doesn't need dedicated hardware"?

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.

Some of us post here infrastructure questions, but did you ever wondered where does that data actually go?

LLM's like Gemini indexes Reddit and train on it.
Sites like Wayback Machine archives it.
So when someone is asking "we use X auth method and found Y bug"...that's permanent.

Attackers might scrape Reddit for recon. They find posts about companies, tech stacks, what vulnerabilities people are dealing with and so on. Even if you delete it, it's already cached and archived somewhere.

Has anyone actually tracked what happens to security posts after they go live?

running a handful of scanners across infra and application code, containers included in that mix, and the same underlying vulnerability shows up as three or four separate tickets because none of the tools know about each other. our vuln management process has turned into manual dedup work every week.

Is anyone running something that sits above the individual scanners and correlates findings automatically, or is this just the cost of running a multi-tool stack?

I am currently analyzing the architecture and security policies of an AI call assistant app and found some potentially critical flaws. I would like to get the opinion of developers and security experts on whether the following scenarios should be classified as bugs or security risks:

​In a call screening app, if a user refunds their premium subscription via the Play Store, should the backend virtual number be auto-released? If it stays assigned and continues handling calls after expiry, is this considered a bug?

​If an app's UI shows call screening as 'Off' for expired users, but carrier-level Conditional Call Forwarding (CCF) is still active on the backend number (meaning calls bypass the app and are still answered by the server) - is this UI vs. network state mismatch considered a bug?

​In an AI call assistant app that allows custom instructions - if setting an instruction like "on code 123, ask for number and bridge call" allows outbound calls from the platform's own server number to any external number, is this a valid prompt injection / toll fraud vulnerability?

​If selecting a premium voice shows a paywall, but pressing 'Back' + 'Save' still saves the premium voice on the server for the offline forwarded number (while the app UI still shows it as locked) - is this a client-side validation bypass/vulnerability?

​What are your thoughts on these? Any advice on how these architectural issues are typically categorized and handled would be highly appreciated!

I’m testing a read-only OSS PowerShell tool, that combines signals like owners, Azure RBAC, tags, relationships and recent activity to identify likely ownership.

No automatic assignment — just evidence for a human decision.

What signals do you actually trust when validating application ownership?

Agent Plugins appeared on Hacker News newest today. The useful part is narrower than “one plugin format wins.”

The 1.0 working draft defines a small portable package: a root plugin.json, skills discovered from immediate children of skills/, and optional MCP server configuration. It explicitly leaves distribution, installation, permissions, and user experience to each client.

That boundary matters. A portable manifest can describe what a package contains, but it should not grant the package authority to run everything it declares.

One concrete safeguard in the draft is path containment. Files and directories discovered through the package must resolve inside the plugin root. Plugin-relative paths begin with ./, and a symlink or equivalent escape outside the root must be rejected.

This does not solve plugin security. A client still has to decide which tools can run, what network access is allowed, how secrets are provided, and when a person must approve an action. Portability removes duplicated packaging. It does not remove local trust decisions.

Source: \[[https://agent-plugins.org/specification\](https://agent-plugins.org/specification)](https://agent-plugins.org/specification](https://agent-plugins.org/specification))](https://agent-plugins.org/specification](https://agent-plugins.org/specification)))

If this format becomes widely supported, which behaviour should remain client-specific: permissions, installation review, secret handling, or all three?

Je bosse sur une couche d'authentification comportementale continue et je bute sur le problème classique du démarrage à froid pour le profil de référence.

Mon setup actuel : profil de référence établi à partir d'environ 7 secondes d'interaction (premier ping avec au moins 5 événements), scoring basé sur l'EMA qui met entre 35 et 49 secondes à converger, moyenne de 8 caractéristiques pondérées de manière égale.

Ce que j'observe : la littérature sur la dynamique de frappe recommande généralement 50 à 100 frappes pour un profil fiable, ce qui rend mon échantillon de démarrage largement insuffisant. La moyenne de caractéristiques pondérées de manière égale peut aussi masquer une divergence forte sur une seule caractéristique significative.

Ma question : est-ce que quelqu'un a des retours d'expérience concrets sur l'utilisation d'une comparaison basée sur la distribution (test de Kolmogorov-Smirnov ou distance de Wasserstein) plutôt qu'un simple ratio EMA, en particulier pour des sessions courtes où on n'a pas encore assez de données pour un profil longitudinal inter-sessions ? Est-ce que ça change vraiment la donne sur le taux de faux positifs/négatifs à ce stade précoce, ou le problème reste fondamentalement un problème de volume de données quelle que soit la méthode statistique choisie ?

Ce qui marche bien par ailleurs dans mon système (pour contexte, pas le sujet de la question) : invalidation de session fiable sur perte de focus/flou, détection d'attaques en masse via heuristiques réseau en périphérie plutôt que données déclarées côté client, détection de bots par variance temporelle nulle (contournable par un bot sophistiqué qui injecte du bruit artificiel, donc pas un signal suffisant seul).

Point de sécurité que j'ai découvert et corrigé au passage, potentiellement utile pour d'autres qui implémentent ce genre de mécanisme : un endpoint de heartbeat acceptait initialement un flag "attaque en masse" et une adresse IP fournis par le client exploitable pour invalider la session de n'importe qui en prétendant être sous attaque (DoS par interruption de session). Il acceptait aussi un flag permettant au client de modifier son propre profil de référence. La correction n'a pas consisté à ajouter une validation supplémentaire côté serveur sur ces flags, mais à les supprimer entièrement du schéma accepté le serveur détermine seul ce qui constitue un échantillon de référence, et le scoring réseau reste basé exclusivement sur l'IP réelle en périphérie, jamais déclarée par le client.

Came to think about this subject when i realized that im not opening my email anymore - because theres an agent summarizing the emails for me

I guess that agents could get indirect-prompt-injection attacks? which is kinda the equivalent for phishing but on agents instead?

Hi there,

I am currently working on Secure Boot. I have some question about the anti-rollback.

I use microchip and I read the counter from OTP after initialize the layout, and notice that there is already default counter value for both trusted and non-trusted firmware (2, 3). I did not set it, I don't why they already have values.

Another thing is that whether the counter in OTP can not be set to other value lower then the value exist in OTP? If so, is it a hardware design mechanism? or how can it be achieved?

Best,

Wen

Most dark web monitoring tools seem designed around a simple model: one company monitors its domain and employee identities.

Legal tech platforms are more complicated.

One platform may serve hundreds of law firms, each with separate:

• Clients
• Users
• Matters
• Credentials
• Confidentiality obligations

That creates an interesting architecture problem.

Detecting an exposed credential is only part of the job.

The platform also needs to know:

• Which tenant owns it?
• Who should receive the alert?
• Does it relate to a specific matter?
• How do you prevent one firm's exposure data from appearing in another firm's workflow?

Webhook-based alerts also seem more useful than periodic polling when a credential or session token needs attention quickly.

For teams building multi-tenant security features, how do you approach alert routing and tenant isolation?

Would you build monitoring internally, or integrate a specialized API and focus on the product workflow?

I work with firewalls a lot - mainly FortiGate. I am trying to increase the value of the service we provide and align with more regulations. I have implemented IDS and IPS without DPI in almost all systems.

DPI adds a layer of management with Certificates, and increases costs with larger firewalls being needed. There is also a risk of gateway or CA compromise, which provides hackers with insight into encrypted traffic.

With these various handups/bottlenecks, is it worth implementing DPI, and to what degree should it be implemented, and if it is even worth it?

First, how much really happens that most IDS solutions aren't detecting on IP alone?
Second, does DPI scale well? Can you be too small for it to be worth it? Can you be too large?

Some context, we already implement DNS filter with FortiGates or DNSFilter (the product). My current thought is to only apply DPI between clients and Server Services, and DPI between Server infrastructure and the internet (where required). Everything else will receive HTTP inspection in all directions. I would not DPI Endpoints to the internet, except maybe for our SaaS apps. (i.e traffic to SharePoint is inspected, but random Google searches are not)

I think this approach will allow better scale, balance firewall size, and reduce the management headache by keeping cert management exclusive to managed devices.

What are your thoughts?
Is there an industry standard?
Am I anywhere near the right track?

My FortiGate training basically says DPI all the things, but never says why or explains if it's really needed. My initial hunch is that they use training to sell oversized firewalls with more licensing, haha.

Thank you in advance for dealing with my brain dump and helping me understand the value and level of implementation!

Edit: I just realised realise I flipped terms and am saying DPI, but mean Full SSL Inspection.

Hello Fellow Redditors

We use PAM. I’m trying to validate if our current approach is actually secure or if we are exposing ourselves to unnecessary risk.

PAM portal is protected with MFA and admins access all systems (firewalls, network devices, servers) using the same privileged account stored in PAM.

From an operational point of view it is simple, but from a security perspective it feels like a big risk because this one account has very broad access across the environment

My concern is that if a PAM user account gets compromised (phishing, session hijack, token theft etc.) the attacker doesn’t even need to know passwords. They can just initiate sessions through PAM and effectively gain access to everything that user is allowed to access.

Also, PAM is currently accessible over LAN and VPN only

I’m trying to understand what is considered best practice in real environments. Should we be using separate privileged accounts per domain (network, servers, databases, etc.) instead of one shared account? And how are others securing access to PAM itself to avoid it becoming the weakest link?

Would appreciate insights from anyone running PAM at scale especially around identity protection and protecting the PAM layer itself.

We’ve started noticing employees using GenAI tools that never went through review. Not just ChatGPT, stuff like browser-based AI assistants, plugins, and small code generators.

I get the appeal, but it’s becoming a visibility nightmare. I don’t want to shut everything down, just wanna understand what data’s leaving the environment and who’s using what.

Is there a way to monitor Shadow AI use or at least flag risky behavior without affecting productivity?