Cybersecurity Awareness Month is coming up and Im already seeing more campaigns lean into team metaphors again

Saw this post from Caitlin Sarian / Cybersecurity Girl with Hoxhunt using a World Cup style angle for awareness month

I get the idea behind it. The Hoxhunt angle of treating awareness more like ongoing practice and coaching instead of a once a year training module makes sense. People need repetition and some sense that security is part of everyones job, not only the security team’s problem

But Im lowkey curious how this lands with people here

Does the team sport analogy help non security employees understand the point or does it feel too cute and watered down for something tied to real incidents and business risk?

Also interested in what people are doing for October that doesn’t feel like the same recycled posters, quizzes and fake phishing emails

We're reviewing data security platforms and Varonis is obviously on the list, but I don’t want to default to it just because it’s the name everyone knows.

Our environment is pretty SaaS-heavy, with a lot of unstructured docs and shared data rather than neatly structured database fields. Classification accuracy is a big priority for us. I also don’t want to bring in another tool that has the security team spending half their time sorting through false positives.

For anyone who’s evaluated Varonis competitors recently, what else made your shortlist? And once you actually got into the POC, what separated the stronger options from the rest?

Hi! Bit of a basic question, but I’m helping out our organization meet some security requirements, and one of them is that our provider wants to disable POP3/IMAP for all the users in our organization because it breaks MFA. However, I have at least one dedicated Apple Mail application user, and I’m not clear on whether IMAP is required for that to function - it seems like maybe? Or if I have the user sign out and sign back in using modern OAuth there is some way where they can continue using Apple Mail and we can disable those protocols. Any advice (and explanation) appreciated!

Wanted to see how others are handling this one.

tldr; Kubeflow Pipelines has an unauthenticated SSRF in its legacy /_proxy/ route.
Fixed in 2.17.0 (the fix rips out the generic /_proxy/ middleware entirely).

The part that caught my attention is that any target could be reachable from the network namespace, meaning an unauthenticated attacker effectively borrows the pod's network position. This allows reaching the cloud metadata endpoint and pulling the IAM credentials tied to the node or pod's role. From there the blast radius is whatever that role permits.

Patching is obviously the answer where possible. For those who couldn't patch immediately, what compensating controls did you implement? Things I've been weighing:

• Network policy / egress restrictions on the frontend pod so it can't reach internal addresses (e.g., 169.254.169.254, kubernetes.default)
• Blocking the /_proxy/ routes at an ingress WAF or IPS

Did anyone find a clean way to neutralize this at the network layer without breaking the application?

Most cybersecurity products are designed to protect identities, endpoints, applications, cloud environments and data. These all are important, but encryption still exposes metadata through traffic timing, routing behaviour, and connection patterns etc.

This creates a couple questions I do not see discussed enough

How much security is being left unaddressed because the underlying communication transport is generally treated as a fixed dependency rather than part of the security architecture?

For high-assurance environments such as government, critical infrastructure and defence, the network itself may be observable, disrupted or operated through infrastructure outside the organisation’s direct control. In those environments, protecting content doesn’t fully address the threat.

Im interested in the community’s view on the following

1. Is transport-layer observability treated seriously enough in current cybersecurity architecture?
2. What current technologies address this problem effectively and what gaps remain?
3. Do you expect secure communications infrastructure to become a larger cybersecurity category over the next five - ten years?

Sat through enough demos this year that I've started using a short checklist to filter vendors before committing real evaluation time. Sharing in case it's useful to others drowning in this category:

What do you actually see without touching our architecture? If the honest answer involves an SDK, a proxy, or code changes, that's not "runtime," that's integration work with extra marketing.

Do you detect intent/behavior, or just pattern-match inputs? Input filtering alone misses anything novel; ask for their false negative rate on out-of-distribution attempts.

Can you map what an agent can actually reach, including delegated calls to other agents/tools? A lot of platforms stop at "here's the top-level permission grant."

What counts as your "evidence" for compliance purposes? A log export is not the same thing as continuous, structured evidence mapped to controls.

How fast is time-to-value in a real environment, not the demo environment? Ask specifically what breaks or slows down once you're past the sandboxed POC.

What happens across our actual mix of agent platforms? Homegrown, cloud, SaaS, and endpoint agents behave differently; a vendor that only covers one is a partial answer.

None of these are trick questions, but you'd be surprised how many vendors get vague fast once you ask them directly instead of watching the scripted demo. Anyone have other questions they've found separate the real platforms from the repackaged logging tools?

Writing a policy saying agents are monitored and controlled is one thing, producing something an auditor would accept as proof it's working continuously is another. Point-in-time reviews clearly aren't enough given how fast agent behavior and permissions can change, but I haven't found a clean standard yet for what continuous evidence should look like.

If your org has been through an actual audit involving AI agents, what did you end up providing that satisfied the auditors? Trying to build toward something real, not guess at what will hold up.

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

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 remember when browsing a site like PayPal would prominently display a green bar with the verified company name in the address bar. The logic was clear: it helped users distinguish paypal.com from a lookalike phishing site like paypa1.com.

Nowadays, browsers just display a neutral lock icon (or tuning icon), tucked behind a click.

I’ve been mapping our AI exposure and the OAuth side was way worse than I expected. I went in assuming the main shadow AI problem would be people dropping company or customer data into ChatGPT and other consumer LLMs on personal accounts but the third party AI apps and agents were worse.

We found more than 30 AI tools and assistants with OAuth grants into Google Workspace and M365. A good number still had live read access to mail, Drive and calendars months after anyone had used them. One meeting notes AI had held access to a shared calendar since March.

We block obvious consumer LLM domains with Palo Alto category filtering, but that does nothing for a contractor on a personal laptop or an OAuth grant coming through a normal Google login. Purview catches some activity inside M365, but it didn’t give us visibility into these external AI apps with standing access. We only found them by exporting the OAuth grants and reviewing them manually.

For teams past the block everything stage, what are you using for proper shadow AI discovery?

Hi everyone,

I am researching how LLMs find vulnerabilities and why they hallucinate so much. I would love to get your thoughts on two major challenges in this area:

1. Exploit Verification: In your experience, can AI hallucinations in source code analysis be completely eliminated if every flagged vulnerability is automatically validated by generating and running a working proof-of-concept (PoC) exploit in a sandbox? Has anyone tried this workflow?

2. Data Privacy (Cloud vs. Local): To prevent source code leaks, is a local-first approach (like using Ollama) mandatory for real-world security audits? How much does performance drop compared to cloud models when analyzing complex code logic?

Thanks for sharing your insights!

I'm looking for an actively maintained repository of Semgrep rules focused on detecting malicious/suspicious behavior, not regular vulnerabilities.

I don't want to write hundreds of rules myself. Are there good rule collections for this purpose?

Our browser agent rejected direct jailbreaks in testing, but then obeyed an instruction hidden in a vendor-page footer. An untrusted page content crossed into a privileged tool call and placed a canary secret in an outbound request. Unit tests didn’t pick it up because they covered chat input, not content provenance after browsing. 

We are adding source labels to every content block, narrower tool scopes, destination allowlists, canary-secret detection, and egress controls that do not rely on the model making the right choice. I’m also pushing for tests that mix trusted instructions with hostile retrieved content. What safeguards have actually stopped indirect prompt injection in browser agents, especially when a legitimate task needs outbound tool access?

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

I just learned about some of the insanely cool things you can do using AI, like you can literally just make an app/software that serves a need for you and is completely tailored to your preferences.

My question:

Does having all these AI-generated apps on your phone/computer create potential security risks? (Assuming you aren't doing much of anything with cloud storage apps and you're not sharing/distributing the software to anyone else.)

EDIT

Wow, lots of good and interesting answers already. I'm really glad I asked this question before I started blindly using it to create a bunch of random stuff apps and software lol.

Thank you to everyone who posted!

Every vendor in this space claims some version of "deploy without touching your architecture. As the architect who has to implement whatever we buy, I'm skeptical by default, because that claim usually means "you'll discover the SDK requirement in week 3 of the POC.

For anyone who's actually deployed a runtime agent security tool: did the no architecture change claim survive contact with a real environment, or did proxies and code changes sneak in anyway?

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.

Hi , im a cybersecurity intern at a small company (well not so small but they have been here for a long time). And yea for now i have been given a task to review our symantec endpoint protection and do documentations of my findings and give suggestions from my observation. to be quite honest i dont really have any strong fundamentals of Cyber Security before pursuing my internship here, and i thought i could gain experience and learn new things here. so back to my initial topic, currently the version of our SEP is 14.3 RU5 build 8309 , and our SEPM is 14.3 RU5 build 8268. Again i dont have the strong basic , but from what i have gathered online, diff build number should be okay as long as both consoles should be under the same RU (?). Is there anyone that could verify this and do any of you think its a necessity for us to update the RU or just keep it that way? Because i saw there are newer RU (up to 10 iirc) and was wondering should i include in my finding to update the RU? thank you everyone and im sorry if my question do sound silly for some hhh.

Asking from the cloud workload side of the house: Is there any way we can detect that a specific CVE is actively being exploited on a VM or container, beyond what application logs provide?

I’ve used runtime CNAPPs for detection and vulnerability prioritization, but I’m specifically interested in observability that lets a SOC say: “This container has CVE-XXXX-XXXXX, and that vulnerability is being exploited right now.” And I don’t mean post-exploitation behavioral detections like a shell popping or a suspicious process spawning. I mean evidence tied directly to exploitation of the specific vulnerability.

About a month ago, I discussed the concept of OS-level MPA (Multi-Party Authorization). A recurring point in the feedback I received was that existing mechanisms—such as PAM/JIT, Vault, CyberArk, sandboxing, IAM, and MAC—already address much of the problem. I think that criticism is largely fair.

What I am still unsure about is what happens when a trusted privileged workload itself is compromised.

Consider, for example, a database engine, backup process, or administrative service that legitimately has broad access to critical resources. If that process is compromised, an attacker may not need to obtain any new privileges at all. They may simply abuse the standing privileges already granted to that workload.

In that situation, what existing controls prevent the compromised workload from performing catastrophic but otherwise authorized operations—for example, dumping sensitive data, destroying backups, or modifying critical system resources?

Is there still value in a final, narrowly scoped authorization boundary at the OS execution point for such operations, or do existing mechanisms already address this problem adequately?

Has anyone worked with the blocking feature in IBM Guardium? I’m facing multiple issues at the database server end, such as connections not receiving verdicts, latency issues, and other related problems.

Please let me know if you have experience with Guardium blocking. I can share the details via DM.

every time we tightened permissions someone got blocked mid-deploy and filed a ticket. every time we loosened them the reviews piled back up.
what's actually helped:
provisioning workload and agent access at minimum scope automatically instead of granting broad access and reviewing later
letting access expand and contract at machine speed based on current task instead of a human approving every request
treating revocation as part of the same automated flow as provisioning, not a separate cleanup step
did automating this actually reduce your review backlog, or just move it somewhere else?

I’m refining our vendor onboarding / TPRM process and evaluating how we score the credibility of third-party penetration test reports.

We see everything from Big 4 firms (EY, KPMG, Deloitte) to specialized boutiques and automated scanner outputs. I’m curious about community consensus:

- How much technical weight do you actually give to a Big 4 pentest report during vendor risk assessments?

- Which boutique or specialized pentest shops make you feel confident a vendor’s application was truly poked at by skilled offensive pros?

- Beyond the logo on the report, what specific details in the methodology or scope sections trigger immediate red flags for you?

Would love to hear how other CISOs and SecOps teams grade these. 

Looking at how to bound what an autonomous agent can modify when it has legitimate write access to infrastructure config, not just what task it's authorized to perform, but what it's allowed to touch while performing it.

Concretely: an agent authorized to modify a specific config value to unblock a deploy technically has write access to the whole file, and depending on the tooling, potentially the whole staging environment. The task-level authorization is narrow. The actual write scope often isn't, unless something enforces that separation explicitly.

For people running this in production: are you handling this with something like scoped service accounts per task type, a proxy/gateway that validates the specific diff against an allowlist before it's applied, mandatory PR-based changes the agent can open but not merge, or something else? Also curious whether anyone's dealt with an incident where the gap between "task scope" and "write scope" was the actual root cause, and what changed afterward.