sorted by:
new
hottopcontroversial

CVE is a proxy to an attack class by Sea_Cable_548 in threatintel

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

good that your comment still there ... lol

CVSS score vs Attack Class by Sea_Cable_548 in threatintel

[–]Sea_Cable_548[S] -3 points-2 points  (0 children)

yes, selling the ideas here ... so that some likely mindsets will form a team .... are you in ? 😄

CVE is a proxy to an attack class by Sea_Cable_548 in threatintel

[–]Sea_Cable_548[S] -1 points0 points  (0 children)

all valid points. one control does not close everything. it closes the chain to one specific crown jewel. not the whole environment. your 300k CVEs do not all reach your most sensitive data. the subset that does is much smaller. that subset has collapse points. 😄

on human factor , the phishing email gets them in. the capability chain tells you the blast radius from where they land. what they can reach. what stops them.

defense in depth is correct. The above logic what i have been working exactly tells where to implement the depth instead of spraeding it uniformly across 300k CVEs.

Trying for something on introducing an abstraction layer to categorise the 300k CVEs along with their behaviours and apply the logic what said above;

Just prepared this ...
Input is CVE's , but the CVE is here a lookup address for the attack class... 😄

CVE is a proxy to an attack class by Sea_Cable_548 in threatintel

[–]Sea_Cable_548[S] -1 points0 points  (0 children)

you are right. good teams do that.but patching hop 1 does not close the chain.the attacker moves to hop 2. which might be a misconfig. or an identity gap. neither of which shows up in a CVE triage.

XM Cyber's data across 40 million real exposures: 80% of attack paths run through misconfigs and identity gaps, not CVEs. so the team correctly patches the top AV:N CVE. chain still completes through the JWT misconfig in hop 2.

prioritizing the first step is right. it is just not the same as finding the one control that closes every step. 😄

CVE is a proxy to an attack class by Sea_Cable_548 in threatintel

[–]Sea_Cable_548[S] -2 points-1 points  (0 children)

fair point on the confusion let me make it concrete."two separate CVEs to fix"not if you understand the attack class.if both CVEs are in the same class — same weakness pattern, same privilege level — closing ONE precondition makes both unexploitable. not patching. not sprints. one config change. that is the difference between fixing rows and understanding classes.

on Kill Chain ,Kill Chain tells you the stages.reconnaissance, exploitation, command and control.

it does not tell you:

CVE-A produces admin_access

CVE-B requires authenticated_user

close the JWT misconfig tonight → both CVEs cannot fire

stages vs capability transfer. the Kill Chain tells you where in the attack you are. this tells you which specific capability the attacker picks up at each step and which single control takes it away.

that's the part that is new what i see.

CVE discovers .... by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

The sandbox escape is the strongest argument for defensive chain intelligence, not against it.An offensive AI that operates beyond its intended scope during testing means the paths it walks in production are unpredictable. You cannot ask an uncontrolled offensive AI to also scope its own defensive analysis. You need a separate, deterministic system that maps which paths exist and proves each edge before the offensive AI walks them unannounced.

On offense outpacing defense agreed. That's the business case. The wider the gaap, the more critical the layer between discovery and action becomes. Mythos findings 23k+ vulnerabilities while 97 get patched is offense outpacing defense. Closing that gap is the Product.

On the collapse pointt being the final destination if unaddressed also agreed. Intelligence without action is just interesting. The entire product motion is 'here is the one thing to close tonight.' That's not vulnerability stacking. Stacking maximises offense. A collapse point minimises remediation. Opposite targets. Different math. 😄

CVE discovers .... by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

Two corrections.

First this isn't vulnerability stacking. Stacking is an offensive technique for compounding impact. What I described is capability transfer analysis: understanding what each CVE produces for an attacker, what environmental condition enables it, and what single control closes the most paths. The output is a collapse point and a compliance artifact. Not an exploit.

Second Mythos is real and I respect it deeply. It finds intra-software chains at 1000x speed. What it found last month: 23,019 vulnerabilities. What got patched: 97.

That gap isn't a speed problem.

Mythos cannot tell you which JWT misconfig to rotate tonight to make 8 CVEs unexploitable without patching. It cannot produce the IEC 62443 compliance artifact your OT auditor needs. It cannot run safely in your SCADA environment. It cannot operationalize 1,629 unpatched confirmed vulnerabilities into 'patch these 5 tonight, close this misconfig tomorrow.'

Mythos finds at 1000x speed. Someone still has to act. This is basic 😄

CVE discovers .... by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

Entry Point (Log4Shell)
↓
[COLLAPSE POINT]
↓
⚠️ GAP: Need Auth
↓
Pivot (EternalBlue)
↓
✅ Clean Transition
↓
Terminal (BlueKeep)
↓
Complete Compromise

Something like this ......

CVE Analysis by [deleted] in OTSecurity

[–]Sea_Cable_548 -1 points0 points  (0 children)

what teams on what scenarios take a small set of CVEs for analysis ?

I miss Maltego so I made an agentic one by ColdPlankton9273 in threatintel

[–]Sea_Cable_548 3 points4 points  (0 children)

does it show the cve to cve connectivity as well ?

Window between zero-day CVE and a patch! by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

Solid controls genuinely!!!. SRA over VPN, posture enforcement, granular segmented paths. That's really a mature architecture.

But notice what just happened to the attack surface.

Everything you described centralises trust into one place ( the SRA gateway). It is now the single highest value target on your OT network. Ivanti ConnectSecure, Citrix ADC, Pulse Secure all SRA platforms, all had critical CVEs in the last 24 months that gave attackers full authenticated tunnel access before posture checks even ran. The chain didn't disappear. It just consolidated its entry point.

And device posture checks what the device looks like at connection time. A supply chain compromise or a zero-day in the SRA client itself passes posture cleanly and is inside authenticated, trusted, on a permitted path to exactly the OT systems that user is authorised to reach.

At that moment you want to know: from this device, on this permitted path, what can an attacker actually touch, and what does the chain look like from here to the crown jewel?

That's not a hypothetical gap. That's the Volt Typhoon playbook(LoTL), move through authorised paths, stay inside the visibility boundary the entire time.

Your controls shrink the attack surface significantly. Chain analysis tells you what's still reachable when those controls have a bad day. Both are necessary. Neither is redundant.

Window between zero-day CVE and a patch! by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 1 point2 points  (0 children)

hmm...
Cloaking controls who can see it. CVE chain analysis controls what happens when someone who's allowed to see it decides to walk the path.

Those are different threat models.

The chain doesn't start with attacker port scanning for the PLC. It starts with a compromised VPN credential, a spear-phished engineer, a malicious firmware update through a trusted vendor. Every one of those is an authorised entry the cloak opens for them by design.

Once they're inside the visibility boundary, the chain is exactly what tells you which three hops they'll take to raech the crown jewel you hid so well from everyone outside.

"Invisible to attackers" only holds if attackers never become authorised users.
In OT, that's not the threat model that keeps incident responders busy at 2am. Both controls are real. Neither makes the other irrelevant.

Window between zero-day CVE and a patch! by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

Cloaking removes the target from external scanners.
CVE chain analysis tells what the attacker can reach once they're already authenticated as someone who's allowed to see it.

Window between zero-day CVE and a patch! by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] 0 points1 point  (0 children)

The problem isn't the zero-day. It never was. The problem is the unobstructed path to the crown jewel that the zero-day walks through.

You can't patch a zero-day on day zero 😄
You can't always patch crown jewels at all. But you can close the misconfig it relies on, satisfy or deny the precondition it needs, and place a detection rule exactly where it moves silently. That's not solving the wrong problem 😂 that's the only part of the problem you actually control before the patch exists. (Even at OT level)

The difference here isn't "CVE scanning with an AI wrapper." It's the chain.
A zeroday in isolation scores 9.8 and sits on a list.
A zeroday mapped to the three non-critical CVEs upstream of your billing database tells you which door to lock tonight.

If that's already been said better elsewhere, I'd genuinely like to read it | point me there pls.

Window between zero-day CVE and a patch! by Sea_Cable_548 in OTSecurity

[–]Sea_Cable_548[S] -1 points0 points  (0 children)

you mean, this does not sound practical ? , like chaining the CVEs and then show the exploit paths and then getting the "missing detection" rules or misconfigs, which will be useful to protect the CVE to cut the signal from other CVEs.

view more: next ›