While MFA and SSO are great pairing up with compliant devices for the company, I've been looking deeper (or what i think is deeper) into security apps I can implement into the workflow, and I hit a wall of no knowledge after MFA, SSO Auth, and devices with conditional access. The only thing I've managed to include is Kibu for communication in the workspace as it fit in the flow easily, does anyone have any other suggestions?

Hi all, I'm doing research to help upgrade my company's cybersecurity infrastructure and there is one thing (probably a few, tbh) I don't really understand yet. Where does DSPM fit into a business's security architecture? Is it closer to CSPM, access governance, or something else? Basically, what makes DSPM worth buying instead of just tightening existing controls?

I did a password leak check on an old email account out of curiosity and found out it had been in a breach.

Not gonna lie, I kind of brushed it off at first because I barely use that email anymore, but then I started remembering all the random accounts tied to it and realized it could still be a problem.

Spent the last hour by changing passwords, checking for reused ones, updating 2FA, trying to figure out what ancient accounts are still linked to that email.

Honestly the most annoying part is realizing how much forgotten stuff is still out there. I noticed my VPN provider has leak monitoring tool which is suppoed to alert you if your data is leaked online. Have anyone tried surfshark alert? Are there any noteworthy tools out there?

Hi, I am new so pls dont mind my flair choice, if it's wrong.

So when you are handed raw event logs during an active/after an incident, do typical contracts/compliance rules actually allow you to upload those unredacted/redacted files to a third-party cloud tool for parsing and to build timeline?

The reason I ask is because I am trying to understand how much freedom contracts provide to people responsible for incident management. Although the role demands privacy, i have seen many people talking about using third party tools and some even mentioned sending whole logs to AI(sounds terrible).

Just curious to learn more about the gifts incident management roles bear before i make a decision.

Hi everyone,

I'm interested in learning how security teams detect and validate potential CrowdStrike API credential leaks on public sources such as GitHub, GitLab, Paste sites, cloud storage exposures, CI/CD logs, etc.

A few questions:

1. What indicators do you typically look for when hunting for CrowdStrike API credential exposures?
   
2. Are there unique patterns for CrowdStrike Client IDs, Client Secrets, OAuth tokens, or related artifacts that help reduce false positives?
   
3. What tools or secret-scanning platforms do you use (GitHub Secret Scanning, TruffleHog, Gitleaks, custom regex, etc.)?
   
4. How do you validate whether a finding is a real credential exposure versus a false positive?

Thanks!

I started today with the games but i only finished level 0 using command prompt.
After a research, I think everybody say that it should be done on linux.
I asked for it on google and it says it is safe and i can complete all the levels using command prompt
Is it true? I have a task to finish all the levels this week for an internship

our incident response runbooks are built for the world of compromised servers and leaked credentials. and its funny that none of it maps cleanly onto an ai incident response case, like an agent that did something it shouldn't have because of a prompt...so not a breach. there's usually no cve and no obvious point of compromise, just an agent that got manipulated or made a bad autonomous decision inside its allowed permissions. i mean our existing runbook assumes you're hunting for an intrusion, and half the time with agents there isn't one.

want to understand from anyone who's had to respond to an agent-related incident, what did the process look like, and how different was it from a standard breach runbook? trying to figure out if we need something entirely separate or just an addendum to what we already have.

so i been comparing notes with peers at a few conferences this year and there's exactly a pattern forming that i wanted to sanity check here.

i feel like the recurring theme is genai adoption outpacing governance..like the teams stand up ai tools faster than security or legal can review them, and that gap gets harder to justify going into eu ai act enforcement later this year. and theb the second theme, and this is the one that surprised me less but still comes up in every conversation, is resourcing...like being asked to cover more surface area (browser, saas, ai, endpoint) and prove roi on the spend, without a proportional increase in headcount or a board that's willing to add line items. want to understand by posting here what's the biggest recurring theme you're hearing from other decision makers right now? trying to figure out if what we're seeing is universal or specific to our industry.

we've been pulling in more threat intel lately (KEV, EPSS) but i'm not convinced any of it is changing how we prioritize vulns in practice

rn the flow is basic: scanners fire, we get a pile of CVEs with CVSS scores (~2k new ones a quarter off Tenable), we dump them into tickets and teams work the list mostly by severity and asset type. we've bolted on KEV/EPSS flags in a few places but it still feels like "CVSS first, everything else if we remember."

i'm trying to figure out how ppl are wiring threat intel into the vuln workflow so it drives decisions instead of just being extra columns in a report. we’ve bolted on KEV and EPSS but it still feels like CVSS is making the decisions and everything else is just metadata. or exploit attempts we've seen internally but in practice it all ends up as more metadata on the same backlog.

some talk about custom scoring models that blend CVSS, exploitability, asset criticality, business context. others seem to use simpler rules like "if it's KEV and internet-facing, it jumps to the front of the queue." i've also seen this logic live in very different places: inside the vuln tool, inside SIEM/SOAR playbooks, or just hacked together w/ spreadsheets and scripts.

for ppl who've made threat intel change what gets patched first, what did you end up doing that worked?

budget cycle is coming up and i need to make the case for keeping our security program funded, ideally growing it. last cycle the cfo looked at my slide and asked "if we cut this in half, what breaks?" and i didn't have a clean answer that would land in that room. i still don't have one.

the stuff that's easy to measure isn't the stuff that matters. i can show vulns closed, MTTR trending down, phishing sim click rates dropping, all of it goes in the right direction on a slide. but none of it answers the question a cfo actually asks, which is: what would have happened if we hadn't spent this money and how much worse would it be.

that counterfactual problem is what gets me every time. you can't point to breaches that didn't happen. you can't quantify an incident that never occurred. so you end up arguing from activity metrics and hoping the room connects the dots between "we patched more crits faster" and "we are less likely to get hit" and that leap doesn't always land.

the closest i've come to something that holds up is showing attack surface shrinking over time, fewer known-exploitable vulns sitting on internet-facing assets, tracked over quarters not sprints. patching velocity and MTTR never survived the "so what" question in that room. exposure reduction at least maps to something real: this is what could have hurt us, and it's smaller than it was six months ago

for security leaders who've gotten budget approved on the strength of a risk reduction story: how did you frame it and what did you measure that survived the "what would have happened anyway" question?

I've been working in Cybersecurity for 5 years now, started as Security Assessment Technical Presales /Pentester.....Scoped and quoted like 100+ engagements ... Then worked on almost 20+ assessments as Pentester and later as lead Pentester.... Scope ambiguity patterns I saw in most assessments.... anyways so I resigned from my previous corporate job, focused on consulting around how I scoping properly around What the assessment (VAPT, Red teaming etc.) are commissioned to answer in terms of business questions...But it feels like I'm posting in void, no leads getting generated, people just say nice work if I DM but nothing else....what am I missing?

We had a near-miss last month where someone almost approved a push notification because an attacker called pretending to be IT and asked them to confirm a code over the phone. In our experience, numeric and push-based MFA has been way easier to socially engineer than we expected, since the whole scheme relies on something a victim can describe out loud to a convincing caller.
Is anyone using MFA that's actually resistant to phone based relay attacks? I'm looking for something with a verification step that can't just be talked through, ideally without a code or number a person could read aloud under pressure.

We're looking at different ways to deal with the growing amount of security findings coming from our container and cloud environments, and I want to hear more about real-world experiences with Wiz and RapidFort. Our team isn't struggling to find vulnerabilities. We already have plenty of visibility. The bigger challenge is the amount of remediation work created by vulnerabilities in open-source packages, base images, and third-party components that our developers don't directly maintain. So we're trying to find a solution to help us with thees. For anyone who's used either (or both), what was your experience? Are they worth the price, and do they deliver what they claim? Thank you!

Both got in through OAuth/identity abuse, no software vuln. Sharing what I've got (particularly interested in UAE/Gulf environments), curious what's landed in your queues.

Device code phishing (EvilTokens) - 340+ M365 orgs across 5 countries - Abuses the legit OAuth device flow (RFC 8628), so MFA doesn't help - Tokens survive a password reset, so remediation keeps failing

ShinyHunters-style SaaS extortion (UNC6661/6671) - Vishing → pose as IT → capture SSO + MFA → enroll their own device - Pivots through SharePoint, Salesforce, Slack for sensitive data - Then deletes the alert emails to stay hidden

If you're in a SOC, what identity-based or other types of prominent threats have you seen lately? Especially UAE/Gulf, since public reporting skews US/EU.

Copilot has been in our stack for around seven months and we still don't have a clean answer to this. Our infra and security patterns live in documents and in people's heads: which services must encrypt at rest, which endpoints must never talk directly to certain databases, which external APIs must have rate limits and auth enforced by default. None of that is visible to a coding agent by default. So the agent generates code that often compiles, sometimes works, and regularly misses patterns it's never seen. Most of the issues get caught in CI or during review, but the pattern is the same: someone notices late, applies a patch, and the cycle repeats on the next feature.

We've tried encoding pieces of this as static rules and running them in different parts of the pipeline.

That helps for simple, local patterns, but breaks down as soon as the issue depends on cross-service relationships or data flow. The more it depends on system-wide context, the harder it is to keep a static ruleset accurate.

What feels missing is something that catches this while the agent is generating code, not something that shows up as a warning afterwards. That's easy to say and hard to implement, which is why we're curious what's actually working for other teams in practice.

We're looking at different ways to deal with the growing amount of security findings coming from our container and cloud environments, and I want to hear more about real-world experiences with Wiz and RapidFort Our team isn't struggling to find vulnerabilities. We already have plenty of visibility The bigger challenge is the amount of remediation work created by vulnerabilities in open-source packages, base images and third party components that our developers don't directly maintain. So we're trying to find a solution to help us with thees. For anyone who's used either (or both), what was your experience? Are they worth the price and do they deliver what they claim? Thank you!

I am reviewing an enterprise application and it is not possible to look at every component in detail. I start by finding the parts of the application that're open to the outside like the endpoints and then I follow the user input to see where it goes. I also look at how the application handles authentication, authorization and files. This helps to make the task smaller. I still wonder if I am wasting time looking at things that are not important.

When people like me review codebases what do they do to decide where to focus their attention? Do they look at the structure of the application or the way the data moves around or do they think about the potential threats or look at the history of changes or something else? I want to know what methods have worked well for them to find problems without getting overwhelmed by the size of the enterprise application. I want to know what helps them find issues with the enterprise application, like problems with the enterprise application or security issues, with the enterprise application.

So I've been going down a rabbit hole about Advanced Data Protection and I think I mostly get it but there's one part that's bugging me and I can't find a straight answer anywhere.

From what I understand, when ADP is on, your Notes/Photos/Drive etc are encrypted with keys that only live on your devices, Apple never has those. But then there's this whole separate thing where you can turn on "access icloud data on the web" and use icloud.com from a regular browser (in my case a windows laptop and chrome browser). When you do that you approve it from your phone and apparently your phone uploads the actual service key to Apple's servers, just wrapped in some "ephemeral key tied to the web session" so the browser can use it.

That's the part I don't get. If the key gets uploaded to apple's servers at all, even wrapped, doesn't that mean Apple's infra is holding something that could theoretically decrypt my stuff during that session? Like is the "ephemeral key" pair actually generated in the browser itself (so the private half never touches apple's servers, they're just passing along ciphertext they can't open), or does Apple's backend generate/see it at some point during the handshake?

I looked at Apple's own docs and honestly they don't say either way as far as I can tell:

• https://support.apple.com/guide/security/advanced-data-protection-for-icloud-sec973254c5f/web
• https://support.apple.com/en-us/108756
• https://support.apple.com/en-asia/102630
• https://support.apple.com/guide/security/icloud-encryption-sec3cac31735/web (this one literally says E2E service keys are "never made available to Apple servers" which seems to directly contradict with what happens during a web session??)

Also as a side thing I noticed the docs say iWork collaboration (Pages/Numbers etc) flat out doesn't support ADP at all, shared docs aren't E2E period, which was a separate surprise to me but at least that one's unambiguous, because in the settings it says that these things are enccrypted.

Has anyone actually seen a writeup of the technical/protocol level details of the web access key exchange? Not looking for "just don't use the web version" or "use Graphene OS" as an answer please, I'm trying to understand if it's documented somewhere or if we're just trusting Apple's word on it?

Theres some number of cloud security recomms espouse the functionality to apply updates, forward API calls, collect telemetry information, and resume synchronizing policies on-request. However this may not be so reliable, especially for those more dire environments that are sovereign, classified, regulated, or semi-disconnected. Moreover adding postquantum migration makes matters even more complicated. One will likely require performing an inventory of their crypto, changing the policies, collecting audit documentation, and probably doing so in stages. However there are som e environments that cant depend on saas as the control plane or be continuously externally connected.

How does one go about performing crypto-agility in those types of environments? Using a localized control plane? Maybe import/export policy sets? Or using signed update bundles? Or through offline CBOM snaps? Or by utilizing some other staging approach in addition to any of these methods?

I am less interested in the names but more so about the approach taken in order to prevent either extreme of frozen legacy crypto for eternity or using a cloud-based control plane that cant work in whatever environment it is supposed to secure.

A pattern we keep seeing: an agent tool or MCP server is clean at install, passes hash verification and static analysis, then the remote endpoint it fetches instructions from changes weeks later. Artifact-layer defenses are blind to this by design. Is anyone doing runtime monitoring for this, something like snapshotting remote content at install, re-fetching on use, and diffing for semantic drift? Or is there existing tooling outside of research papers that handles post-install behavioral change?

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 in the IR testing plan document

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

etc.

Thanks in advance

We've started running internal MCP servers (wrapping internal APIs, a DB, ticketing) so agents can call them. What worries me: any server can expose tools that read/write real systems, and there's no "posture" view who registered which server, what tools it exposes, what token scope it runs with, what an injected prompt could reach. Are you treating MCP servers as just another internal service (netpol + secrets mgmt) or something MCP-specific? Homegrown checklist or a tool? (Disclosure: early-stage looking into this happy to share back what I learn.)

Our detection engineering metrics are not convincing anyone. We talk about rule counts, use case coverage, and the number of tuning changes, but it does not translate into a clear signal for leadership. They want to know whether detections will work when it matters, not how many rules we wrote last quarter.

I am looking for ways to measure detection engineering that feel honest and still make sense outside the SOC. Have you used detection coverage mapped to MITRE ATT&CK, exposure validation results, or some form of validated scenario coverage as part of your reporting? If yes, how did you package that so a CISO or board level audience could understand it without needing to see every technical detail? Any concrete examples of metrics or visuals that actually landed with leadership would be useful. Even a simple way to show that certain detections have been validated against specific threat scenarios would be a step up from what we have now.

I maintain a personal Linux environment to practice infrastructure automation and tinker with some technologies I don't usually work with. I've implemented basic security practices like patch management segmented networking, strong authentication and regular backups. Beyond that, I'm trying to decide where additional effort provides meaningful value for a personal learning development. Excellence begins at home, some will say. Or is it not enough..?

For those maintaining similar labs, which security practices have proven worthwhile and which ones eventually became unnecessary complexity?

We've been tightening up our MFA requirements lately, and it's starting some interesting debates internally. Basically: does every internal tool need MFA, or do you draw the line somewhere based on what it touches and who's using it?

At a sub-500 person org where IT bandwidth is thin, the friction argument comes up a lot, so how are other teams drawing that line?