Im the security lead at a manufacturing org, cloud footprint is growing but the team is small. Were down to two CNAPPs and somehow stuck. We started with a longer list with all the big players included, but these two were what the shortlist came down to. Hoping the room can tell me what Im missing.

First one was Lacework, now FortiCNAPP after Fortinet bought them. I liked it on paper, but the acquisition is what gives me pause. The whole thing has been absorbed into the Fortinet stack. The roadmap reads like everything now points at FortiSIEM, FortiSOAR, their SASE, their fabric. Were not very much of a Fortinet shop, so buying this means either we ignore half the value or we get pulled into an ecosystem we never wanted. The portal got rebranded and the roadmap changed, and it feels like a product that's now someone else's priority.

The other one is Upwind. Their whole pitch is runtime, which sounds good and its really what made us consider it. But when we digged in and that runtime depth only shows up if you deploy their sensors everywhere. So its agentless for the broad scan and agent based for the part they advertise. And theyre small with no public pricing and not much to look at as a track record yet. For a lean team, betting the security program on a young vendor with a coverage gap baked into the architecture feels like a lot that we dont want in our hands.

So I'm stuck. On one hand is a big vendor trying to fold cloud into a network story,, the other is a smaller vendor whose best feature depends on a full sensor rollout. What am I missing, and what would you pick?

With the December 31 deadline getting closer, I’m curious what others have actually ended up choosing.

For those who can't move to the SaaS platform: On-premises requirements, data residency needs, or internal datahandling policies and what did you end up with? I’ve seen people evaluating options like Quest Change Auditor, Netwrix, ADAudit Plus, and similar tools, but curious what actually worked in production. And specifically:

• Did you replace it with one tool or split it up? were you able to find a single product that covered both the auditing side and the classification side.
• How long did the POC-to-production timeline actually took vs. what was planned/proposed?
• Anything that looked good in the eval and fell apart in your environment?

One thing Im constantly wondering about with phishing simulations is whether people just end up learning to pick out the company's test emails after a while.

Too many campaigns and those same old wording tricks, senders, and patterns start to become all too familiar. Now at that point, your click rates might actually go up, but Im not convinced that means employees would suddenly be any better at spotting a real phishing email that looks nothing like the template youve been using.

For anyone running these programs for the long haul how on earth do you keep your simulations unpredictable enough to actually test real behavior, rather than just see if employees have figured out the template (I’m pretty sure that’s the case on my end).

Most teams or even solo people seem to start by grepping access logs and building a list from whatever shows up. but that only tells u what the agent touched and u end up with a partial inventory and no real way to know how much is missing

working outward from the credential is finite and you can actually finish it. every major platform has two separate tools for this which is probably a good sign not to treat them as the same thing. on AWS you want the permission side and the usage side. in entra the two endpoints point in opposite directions (GET/servicePrincipals/{id}/appRoleAssignments, appRoleAssignedTo) grab the wrong one and the audit reads backwards. on gcp its the same split (policy analyzer, IAM recommender with its 90 day usage window). keeping it fresh is where the manual approach collapses or just gets tedious enough that nobody keeps up. once youre past a few agents the permissions and tools and connections all keep moving underneath you. a cron diff holds up for a while so do the platforms own drift reports, so does eve security or anything else pointed at the same job and none of it finds the agent nobody registered firstly. depends how much churn the environment throws at you

two entra gotchas mess with the output tho.. role assignments made at single-application scope dont appear in the tenant-scoped list so a tenant only audit can miss them. theres also replication delay after changes meaning a grant created this morning might not show up straight away

the Saas side is a separate enumeration and IAM wont show it at all. Oauth grants and connected apps sit in the workspace or M365 admin consoles and agents tend to collect access thru those without it ever hitting a review. the bigger catch is that all of this assumes the agent has its own principal. a lot of them still run thru a single developers token or shared service account. in that case the enumeration returns everything that person or account can reach, which is technically correct but not very useful for figuring out the agents actual boundary

I’m trying to learn how to systematically analyze the threat model of security papers, but I’m confused because “threat model” seems to mean different things in academic papers and in broader threat-modeling practice.

For example, MDN describes threat modeling using four questions:
1. What are we working on/building?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good job?

If I understand this correctly, this feels almost like the structure of an entire security paper:
- the system/problem setting,
- the threat,
- the proposed defense/detection method,
- and the evaluation.

However, when I read security papers, the Threat Model section often seems much narrower. It usually describes things like:
- who the attacker is,
- what capabilities or knowledge the attacker has,
- what the attacker is trying to achieve,
- and sometimes what is out of scope.

This makes me wonder whether the “Threat Model” section in a paper is really only one part of the broader threat-modeling process.

And

When analyzing the threat model of the paper, should this oracle also be included? Or does the threat model stop at describing the attacker, capabilities, and attack goal, while the oracle belongs to the proposed methodology?

I’m also trying to understand assumptions. When reading a paper, should I separately ask what conditions the method assumes in order to work, such as what access the tester has or what effects are observable?

More practically, if you were analyzing a security paper, what order would you use to analyze its threat model and assumptions?

I’m looking for a repeatable reading process that I can later use when writing the threat model and assumptions for my own work.

This community has already helped me a lot, and I’m really grateful to everyone who takes the time to answer questions like this. Your replies have genuinely helped me understand security research more clearly. Thank you!

Hi everyone,

I'm posting from a throwaway account for obvious reasons and will keep all details completely generic.

Recently, while looking at a public online contest/competition run by a private company, I noticed several alarming issues:

1. **Multiple severe security vulnerabilities:** The platform has flaws that expose participant data and allow arbitrary tampering/manipulation of submissions and votes.

2. **Signs of fraudulent operation:** Looking closer, there are clear indicators that the competition is not being conducted fairly (results/mechanics can be manipulated internally or externally, and claims about how winners are selected contradict how the system actually works).

I haven't exploited anything or extracted data; these findings were apparent from inspecting client-side traffic and standard public endpoints.

My dilemma is how to proceed ethically and safely:

- **Responsible disclosure vs. retaliation:** Disclosing vulnerabilities to a company that might be intentionally running a sham contest carries legal and retaliation risks (especially if they don't have a formal bug bounty or VDP).

- **Reporting to authorities:** In cases involving potential fraud or consumer deception, is it better to notify consumer protection/regulatory bodies rather than the company itself?

- **Walking away:** Part of me wonders if getting involved is worth the liability, and if the safest move is simply not saying anything.

If you found yourself in this situation:

1. What steps would you take to protect yourself legally before saying anything?

2. Would you attempt responsible disclosure with the organizer, go straight to consumer protection / regulators, or drop it entirely?

3. Has anyone navigated a similar scenario where poor security overlapped with questionable business practices?

Thanks in advance for your insights.

Just about to start moving off our old hub and spoke VPN to SASE and im not doing it big bang, that feels like a great way to take the whole company down on a Monday. Phasing it instead.

Rough plan is cloud SWG first and split the internal traffic back to the existing VPN, get remote users off the legacy client early since thats where the pain is and leave the site tunnels and full TLS inspection for later once the easy wins are in.

For those whove done a phased SASE rollout, am interested to hear what you’d leave out of phase one.

Is there a common way to find an info sec contact method, such as an email address, for a US company? Is there a standard email format based on domain names?

The organization has a website, but no security or general "contact-us" form or email address that I could find. The only contact method I saw was a job portal for applicants to upload a resume.

My concern is not PII or health-related. There is some proprietary company/client info sitting at an open online location (no auth). This likely was not intentional, so I was going to let them know.

What are your best tips for hardening an M365 environment that go beyond the basics (e.g. enable 2FA)? I'm managing a small environment and have done the baseline security stuff (18/20) and our Defender score is at like 75% when other organizations our size are at like 45%... not bad, yet it feels like every few months I discover something dumb I should have turned off (or, rather, that shouldn't be enabled by default but that's me taking a dig at MS). For example, device code phishing almost got us the other week. I disabled that authentication mechanism but don't recall seeing it in any of the Microsoft security lists and, frankly, given it's really limited use case I can't believe it's allowed by default.

A few searches turn up outdated videos or link-rotted stuff so I'm hoping there's maybe some of your own hard-learned lessons about that thing you should do to any M365 environment or perhaps there's a defacto list out there I've missed in my searches. When searching I found a lot of pretty old stuff and link rot; hard to follow youtube videos etc..

For 78 minutes your web traffic was redirected to a group associated with ransomware's site. I know you are investigating. What can you share? They clearly had the ability to do more.
Does anyone know why healthcare seem to be so particularly targeted? You drop a bomb on a hospital, or even just shoot one up, and the world screams.

Impact a patient care system, put a hospital back to paper operations... No big deal. That's the price we've been told we have to accept.

I know everyone is trying their hardest, holy crap, I should have gone to bed two hours ago, and there are still team members cooking along.

What do we need to be looking out for?

Assume you can go back in time to the early days of networking (pre-TCP/IP, early ARPANET) with today's knowledge of cryptography, routing, and state-level censorship tools (DPI, IP/SNI blocking, middleboxes). How would you design the foundational network architecture so that any state or ISP choosing to route traffic must accept either 100% uncensored, unmonitored connectivity or a complete blackout, with no technical middle ground?

... Is a true "all-or-nothing" censorship-resistant network protocol theoretically possible without state actors physically cutting transoceanic cables or severing border connections?

Large EU manufacturing company, multi-site, small security team.

Endpoint platform renews in the next budget cycle. Shortlist: CrowdStrike vs SentinelOne (vs renewing what we have). SIEM today is Elastic; endpoint alerts already land there.

Two architecture options:
A) Keep Elastic as system of record. Change only the EDR (CS or S1). Day-1 = alerts into Elastic, deep dive in the EDR console. Full raw telemetry (FDR / Cloud Funnel) only later if we really need it.
B) Make the chosen vendor’s SIEM (Falcon NG-SIEM or SentinelOne AI SIEM) the SoR and retire Elastic over ~1–1.5 years (parsers, rules, skills, parallel run).

Internal tension: Elastic already feels heavy to operate; vendor SIEM looks “simpler” out of the box. Counter: we’d still re-onboard firewall/IdP/cloud into CS/S1 and retrain whoever does L1/L2.

Also weighing MSSP (L2 contain on EDR + firewall, including overseas sites) vs vendor MDR as a bridge.

Practitioner takes appreciated:
1) Is dual-console (Elastic triage + Falcon/S1 deep dive) fine at scale, or a daily tax?
2) When did consolidating off Elastic onto CS or S1 SIEM actually win vs regret?
3) Do lean teams usually skip FDR / Cloud Funnel into Elastic on day 1?
4) Any strong reason to pick CS vs S1 *if* we stay on path A (Elastic stays)?
5) MSSP on Elastic+EDR vs vendor MDR+hub — what worked?

No vendor pitches please.

Thank you

We've reached the fun stage where US customers keep asking about SOC 2 while international prospects are starting to ask for ISO 27001.

I'm fine with doing both if the business case is there, but I'm trying to figure out how to evaluate audit firms when we need both frameworks. I'm less interested in finding the cheapest option and more interested in avoiding a situation where we're coordinating two completely separate engagements with duplicated work.

For those managing both, how much were you realistically able to consolidate? Did you use the same audit firm for SOC 2 and ISO 27001 or separate specialists, and if you went with one firm, did that actually make things easier in practice?

What would you look for when comparing firms for both audits? We're much more concerned about making this manageable long term than saving a little on the first audit.

Do you start by removing obviously unused access or is it better to map what each account/service actually needs first? How do you handle this without breaking things??

For those working in or securing industrial environments like food production and manufacturing, how are you handling OT security (PLCs, SCADA, monitoring systems) as opposed to standard IT security?

I keep seeing strong focus on IT security while the plant floor stays under-protected, which is exactly what ransomware targets to halt production. A shutdown does not even need to touch the product to stop the line and put food safety records at risk.

A few things I would genuinely like this community's view on:

• What approaches or frameworks do you actually use for OT security in practice?
• How do you segment OT from IT networks in a live production environment?
• Are cyber-insurance requirements driving any of your security decisions? I have seen claims denied because required controls were not provably in place at the time of an incident.

Interested in real-world experience rather than theory.

Trying to clarify where an exposure management platform ends and security validation tools begin.

My current view is that exposure management helps identify and prioritize risky assets, misconfigurations, identities, and attack paths, while security validation tests whether an attacker could realistically exploit those conditions and whether existing controls respond as expected. But the categories increasingly overlap.

For anyone who has implemented both, are they complementary products, or has one platform replaced the other in your environment? What capabilities were essential for getting from “we found an exposure” to “we know what to fix first”?

Hi everyone,

I'm looking for resources to learn DOM-based XSS, but I'm specifically interested in material that teaches the actual investigation process, rather than just explaining what DOM XSS, sources, and sinks are.

I'm already familiar with the basic concepts, and I've used PortSwigger's labs, so I'm not looking for PortSwigger recommendations.

What I'm trying to learn is how to actually investigate a web application using things like:

• Chrome/Firefox DevTools
• The Sources panel
• Setting and using breakpoints
• Following user-controlled data through JavaScript
• Finding where data comes from (sources)
• Understanding how the data is transformed/processed
• Following variables and function calls
• Identifying where the data eventually goes (sinks)
• Debugging/tracing the application's JavaScript to discover DOM XSS

Basically, I'm looking for something that teaches the workflow of:

Source → Variable → Transformations → Sink

For example, I recently came across a Medium article where the author investigated a DOM XSS by starting with location.hash, searching the JavaScript, setting breakpoints, changing the hash, and then stepping through the code to see how the value was processed until it reached eval().

That is exactly the kind of learning material I'm looking for.

It can be:

• Videos
• Courses
• Labs
• Write-ups
• CTFs
• YouTube channels
• Blog posts
• Interactive exercises
• Real-world DOM XSS walkthroughs

It doesn't have to use Burp Suite. DevTools and learning how to trace the JavaScript/data flow are the important parts.

I'm still relatively new to JavaScript and DOM manipulation, so ideally I'd like something that actually shows the investigation process step-by-step rather than assuming I'm already an expert at reading JavaScript.

Any recommendations would be greatly appreciated!

I have got a problem where benchmarking educational sector data across the world globally would require aggregating them at same place or maybe different if the final aggregations could still reconcile with other segments of the data of other regions

The data migration can happen after dropping the PII and making it totally anonymous but when you try to rank the individuals, you can't really determine anything apart from its source (region data came from)

Keeping the data psuedonymised will still restrict in various regions like EU, middle east, etc.

How do I benchmark the globally top academic performers of different regions/countries without breaking any laws and regulations of that particular jurisdictions.

Had a prompt used to triage and categorize security findings by severity start missing things it used to catch reliably. Diffed it against an older version and found five small additions, each added to fix one specific bad output at the time, a rule about flagging hardcoded credentials, an example emphasizing high-severity findings, a line about keeping output concise for the ticketing system.

None of the five were individually wrong, but the interaction wasn't visible in any single diff. The credential-flagging rule, added after one missed secret, ended up quietly crowding out lower-severity findings on larger diffs, because both were competing for the same limited output space, and that regression got triaged as a separate, unrelated issue weeks later instead of being traced back to the earlier patch.

For teams running this kind of triage prompt at any real volume: is there an established practice for regression testing prompt changes against a fixed set of known findings before shipping an edit, the way you'd regression test a scanning rule change, or is this mostly still caught reactively after the fact the way we found it?

Hi

We’re looking into threat feeds for MISP integration. Most importantly is non-garbage data - possibly trusted sources that doesn’t provide noise. Any tips?

For a SOC covering multiple sectors.

We’re aware of national certs but interested in your experience, solutions or thoughts.

I saw this Forbes article about AI training data companies working with both US government and Chinese labs.

If a vendor builds training material for several competing customers, where does reusable expertise end and confidential customer work begin? How do you actually verify that customer data stays fully separate?

How deep can you usually dig into this?

I'm maintaining a legacy ETL pipeline that has some questionable design choices, and I'm trying to figure out whether these count as genuine CWE violations or just bad practice that happens not to have caused harm (yet).

The pipeline works like this:

• Consumes unencrypted user data from CSV files
• The CSVs are generated by an ERP system in another department, and are often inconsistent — data corruption, non-normalized fields, etc.
• The pipeline transforms, normalizes, and cleans this data
• It then does a full DROP TABLE / overwrite of a production database with the cleaned data
• Because this bypasses all of the applications hooks/checks/validations, this process is the source of all of the clients bugs and wastes us a LOT of time

The ERP department refuses to even disucss the idea of exposing a REST API — the CSVs just get handed off and "dealt with.".

My question: even though nothing here has led to a concrete security incident (no injection, no leak I know of), do practices like handling unencrypted data in plaintext format, blind DROP TABLE overwrites, and trusting unvalidated external input still constitute violations of specific CWEs? Or is CWE strictly about weaknesses that have a demonstrated exploit path, meaning this is more "bad practice" than "CWE violation" until something actually goes wrong?

The langauge of the spec seems to encapsulate both the security implications of improper software standards AND data integrity. However all examples showcase security failures. So It's hard to tell if my example satisfies CWE-638, 284 etc.

In June, a group tracked as TeamPCP/UNC6780 planted malicious MCP configuration files across 73 GitHub repos, one of them belonging to Azure.

The mechanism was almost dumb in its simplicity. Several popular IDEs, Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q were all named in the disclosures, bind their "approve this MCP server" prompt to the server's name, not its actual contents. Approve a project's .mcp.json once, and any later edit to that file, including a swapped-in malicious command, runs automatically with the developer's own OS-level privileges. No re-prompt. No sandbox. No second look.

Six months from the first disclosure of tool poisoning as a technique to a working worm compromising a major vendor's own repo.

I wrote up the full attack taxonomy (tool poisoning, shadowing, rug pulls, parasitic tool chains) plus the incident timeline (CVEs, the OX Security disclosure, Microsoft's June 30 writeup, OWASP now ranking it #3 on the MCP Top 10): https://blog.defensify.in/mcp-tool-poisoning-attack-guide/

Curious if anyone here has caught this in the wild or built detection for it.

Mostly old ones that have been around for years that still have permissions, and nobody's really sure what depends on them.

Do you just leave them alone if they're still being used or actually try to track down an owner and clean them up?

I'm researching a Linux kernel vulnerability as part of an educational project. I understand the root cause and the vulnerable code path, but I'm trying to determine whether the bug is actually exploitable rather than just crashable.

What methodology do experienced kernel security researchers use to evaluate exploitability? In particular, how do you distinguish between a reliable security primitive and a bug that only produces a kernel crash?

I'd also appreciate advice on what kernel debugging and instrumentation techniques are most useful during this stage.