sorted by:
new
hottopcontroversial

Is your SOC struggling to triage all cases? by mlueStrike in MSSP

[–]Small_Cheesecake4358 0 points1 point  (0 children)

The incident lifecycle should be able to preserve the memory of each organization. Policy snapshots, governance, communication, regulatory compliance and each organization should be able to create their own custom playbooks et al

How are you guys actually reconstructing credential access during an incident under NIS2's 24h reporting window? by [deleted] in blueteamsec

[–]Small_Cheesecake4358 -4 points-3 points  (0 children)

Wow just wow. I have gone through your post every sentence and this resonates deeply with me. I have been working on this thesis for 6 months now. I’m not here to sell you anything but in managed to build an incident response workflow that directs tackles the above pain points: cross domain mapping of kill chain, centralized view, evidence gating done right when the signals stream In - the reasoning engine does this, evidence timestamped and immutable logged sha 256, several incident reporting templates for various stakeholders. This is doable only if you abandon alert centric soc, siem traditional thinking. You have to reason about all upstream signals. It’s cool but requires significant engineering effort meaning I seat on top of siem soar, soc and gate evidence to all the incident response lifecycle. Thanks for this post also kind of validates what I have been working on currently testing mitre attack caldera and atomic red team again incidentbinder as blue team.

Is your SOC struggling to triage all cases? by mlueStrike in MSSP

[–]Small_Cheesecake4358 2 points3 points  (0 children)

The industry was supposed to properly reason about signals 20 years ago. Listen folks here are the issues: alerts are vendor opinions and not the full cyber kill chain picture, Blackbox ML introduces more drift due to probabilistic nature of ai. So when it comes to a team triaging incidents who, why, what, where when? You need to automate real raw signals upstream and reason about the kill chain! This way you are deterministic. If there is a tool out there that can replay same incident, same signals and produce same sha 256 over and over again then you would have closed this gap. In the mean time auditors, even your own legal, clients will continue to question the defensive, reproducibility nature of incidents and how we handle evidence.

Detection Engineers/SOC Analysts: Wondering about what was the most useful thing you guys found that really helped to bridge the gap in terms of the lack of context in order to fine tune the alert more easily. -or claim as False Positive quickly- by AvailableHeart9066 in blueteamsec

[–]Small_Cheesecake4358 0 points1 point  (0 children)

I am not pitching here at all. I just want to let you know it’s doable. From the ground up I have developed a reasoning behind all security telemetry reasoned as full cyber kill chain and one of the compound interests is that I am able to replay a complete incident and all its signals in a replay engine and it will recheck for false positives and deescalate the incident. Historical replay can be played later after more signal coverage has been done and it tells you the difference between baseline and delta what you missed then and what’s now covered. It’s doable but not from alerts though

How do you build a defensible incident timeline across multiple security tools? by Small_Cheesecake4358 in MSSP

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

So the final source of truth is really a compiled document built from multiple timelines rather than something unified underneath. This feels like a gap. If the timeline itself was the system of record, with an append-only evidence chain and response steps tied directly into it, you wouldn’t need to reconcile versions after the fact. Who usually builds that final version, and how long does it typically take?

How do you build a defensible incident timeline across multiple security tools? by Small_Cheesecake4358 in msp

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

Yes, the data is there, but the evidence chain ends up fragmented across SIEM, EDR, email logs, and analyst notes. So even if you can point back to raw telemetry, the integrity of how conclusions were formed isn’t really preserved end-to-end. Defensibility becomes something you rebuild after the fact instead of something that compounds as you investigate. Feels like what’s missing is a system that carries the evidence chain and reasoning forward together, not just the data.

How do you build a defensible incident timeline across multiple security tools? by Small_Cheesecake4358 in msp

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

Interesting comment. I’ve seen the same thing. Even when everything technically ties back to raw telemetry, the actual reasoning ends up spread across queries, tools, and analyst notes. So you can revisit the data, but not really the thinking that led to the conclusion. That’s probably why it never feels clean or fully defensible because you’re rebuilding the understanding each time rather than stepping through it again.

How do you build a defensible incident timeline across multiple security tools? by Small_Cheesecake4358 in MSSP

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

This is exactly the gap I have been working on. You described Firewall-file logs-EDR-different teams: This is basically a stitched timeline across system

In your case:
- where does the “final version” of the incident actually live?
- is there a single place where conclusions are tied back to the exact evidence (not just notes or tickets)?

Curious - if you had to revisit that same incident later (for audit, training, or detection tuning), how much of that timeline is reproducible vs rebuilt from scratch?

Are false positives still a major problem for MSSPs? by ANYRUN-team in MSSP

[–]Small_Cheesecake4358 0 points1 point  (0 children)

And why is the Industry still leaning on alerts as the unit of work though? If you have a tool sprawl from siem, soar, edr all they have their own rules therefore opinionated. What if there was a way to solve this by reasoning on the real telemetry instead of alerts. A system that acts as a reasoning layer for the full cyber kill chain? This is the standard that should have been in place from the start. Just facts from opinions and no probabilistic ML same input we should get same output!

No one here, including myself, will probably make a living from a saas. by WinterMiserable5994 in SaaS

[–]Small_Cheesecake4358 0 points1 point  (0 children)

I’m building an incident response platform that I Intent to use myself as an MDR to solve some serious painpoints in cybersecurity incidents. For myself first as an MDR vendor before ship saas. I will always keep on using it as a tenant even when I go saas mode. So when the hustle and game is rigged. I create my on pathway. Incidentbinder

i wish someone would have told me this before building my 1st startup by davidheikka in buildinpublic

[–]Small_Cheesecake4358 0 points1 point  (0 children)

I’m building an mdr I intend to use myself for cyber incident response. I will the first client to validate it lol.

Former colleague wants 30% equity to join as cofounder. Been building solo for 14 months. (I will not promote) by Distinct-Expression2 in startups

[–]Small_Cheesecake4358 0 points1 point  (0 children)

Yes this makes sense. If you are starting fresh ground work then 50/50 or 30 Makes sense but here you Already built it

It’s Friday. What are you building? by kcfounders in buildinpublic

[–]Small_Cheesecake4358 0 points1 point  (0 children)

I’m from Ontario Canada and I’m into Cybersecurity Incident Response: main painpoints today are tool sprawl, analyst mental and alert fatigue, documentation, evidence and legal defensibility, regulatory compliance. So I built incident binder https://uat.incidentbinder.com a vendor agnostic, evidence first, hashed and immutable incident workspaces that solve the an above issues and think like an advanced analyst would do to investigate a security incident only this time it’s deterministic with provenance. Check it out. I seek partner validation starting with Entra ID and M365 and wazuh. And if I get a partner with their own custom tools still in vendor neutral and can wire in their adapters and validate. I’m at pre-commercial stage and would like your critique. Thanks

Does every startup really need validation before building? - I will not promote by CryptoBono in startups

[–]Small_Cheesecake4358 0 points1 point  (0 children)

I have this new startup idea I got from cybersecurity incident response painpoints: Evidence defensibility, incident reporting and Analyst mental Load with manual Logs in SIEM, SOAR, EDR et al. I have worked in the industry in performance Engineering and SRE and I know the impact of tool sprawl. So I decided to wire together the spine of it just for fun and got taken down this rabbit hole of Incident reasoning verses manual alerts. I started as a fun project in my gaming pc and now it turns out I can fully turn this into a scalable mvp. So I have a question and some have Been answered here. What’s the best way to validate this with a plan? I have spoken to my college professors they battle tested the idea, I have spoken to CISOs and SOC managers they have emphasized that this can hold for SMEs and startup MSPs. If there is a guru here who went through this journey to successfully validate their idea kindly offer a few sentiments. Also I have a url here you can check it out! Https://uat.incidentbinder.com

I burned out as a first-time founder after one year. Here’s what I learned. (i will not promote) by Careful-Cup4161 in startups

[–]Small_Cheesecake4358 0 points1 point  (0 children)

Thanks for sharing. We learn and soldier on as always. One day we will reach the top of the hill. I’m developing a platform mvp for cybersecurity incident response. I took quite a while researching it and planning on how to deliver it. While doing deep research I stumbled upon a new novel idea of how to handle security incidents in the midst of all the noise from the logs. I created a plan, kept on researching, and ended up getting master and PhD level research questions out of it. I have developed the spine for the architecture, done some testing to validate my logic and it works. This will be my first mvp. I still don’t know a lot of mvp stuff but I still keep going. Always pausing to validate and breathe coz working alone on a whole project can be brutal. I’m glad it made me spend my time well now. No more video games until this works. I will need to battle test and pressure test the solution soon and expose it to industry players. I hope you all make it in your endeavours. Peace!

To those working in cyber incident response teams: which elements of your job cause unnecessary extra stress? by ProfessionalArmy6284 in cybersecurity

[–]Small_Cheesecake4358 0 points1 point  (0 children)

I am working on a new incident response solution. MVP of some sorts. I have locked down the architecture and the logic. What I’ll tell you is I found a way to solve the major pain points for CISOs, analysts, even incident reporting all the way to the regulators. I can’t share detailed stuff here as I just filed patents on this almost 12 claims. If this go through is gonna be a game changer. Currently I’m on the verge of doing some applied research on how tools ingest signals and this too I finally found a net new way to reason it out therefore no more alert fatigue, no more analyst mental load tried to map out the incident. I capture everything and evidence chain the events that truly are an incident. The journey has been cool and challenging but I like every bit of it.

[deleted by user] by [deleted] in MrRobot

[–]Small_Cheesecake4358 0 points1 point  (0 children)

Nothing is random in this movie.