5 ms·
Ask HN: Cyber Security folks – what are your biggest pain points?
I'm building a startup which focusses on automated cyber defense and tries to build products which can adapt to changing situations in the network landscape as well as network behaviours or process behaviours (EDR/XDR/whatever BS term).
In my case I'm building everything from the ground up, and the MVP is trying to start with a better inventory of everything; whereas the inventory focusses on the network-scale rather than the "per single machine scale" that other solutions offer (if they even offer anything like it, which in practice they actually don't for the most parts).
My journey started with log4j's log4shell1/2, after realizing that most blueteams (my one included) don't actually have a full, reliable and correctly indexed inventory. If you ask around in other blueteams something simple like "How many machines you got?" you'll always get responses like "well, one software says 30.000, the other one 24.000 and our SNMP sensors say around 38.000..." which is kinda ridiculous to start with. If you then ask whether or not they use log4j in any of their software they either shrug or say "nope" with a panicking voice, because they don't really know for sure.
Anyways, my solution currently is a peer-to-peer approach where the systems themselves decide to mitigate issues, propagate patches (or even vaccines for zero-days) and also share incidents that look suspicious, so the surrounding nodes can start to quarantine themselves off, for example, when something really bad happened. For this to be a reliable product I decided to ditch the whole Windows "hooks are kinda useless" shitshow, and went for Linux/BSD/Unizes in general first, while leveraging a mixture of golang for userspace and eBPF for kernelspace.
But I wouldn't be a good founder if I ignored my customers, right?
So my questions are now somewhat to all the cyber security professionals out there:
- What are your biggest pain points? Do you use yet another Elastic Search dashboard that's painful to use in practice?
- Do you have a reliable software inventory / SBOM?
- Do you have a reliable network inventory / NBOM / SaaSBOM?
- Do you have an SBOM for all third-party software that's only available via binaries, where you don't have the source code available?
- Does your anti-virus / EDR solution still require signatures or is it behaviour driven?
- What about golang malware (aka malware that doesn't need to call hooked APIs in the kernel and can instead just use something like purego to generate shellcode directly)?
- How confident are you that your CVE/NVD vulnerability database is correctly tagged? (hint: I think it's not reliable for more than 80% of entries)
- Do you use Linux in your infrastructure? If so, which distributions?
- genmud 3y agoI have worked in cyber for 20 years, here are some of my greatest hits: - being able to translate vendor BS to "if you don't do $X, $Y will happen with $Z likelihood" - getting things to play nicely with each other, specifically in a SOAR or SIEM context (integrations suck, they are buggy, have varying levels of completeness, etc) - knowing whether a tool is deployed, working and healthy - having so. many. agents. My biggest recommendation for selling/pitching/positioning anything in cyber is to solve problems I already am dealing with. Do not go to a customer with a flashlight that points out new, unknown issues and requires additional resources to fix... it's fine to point out problems, so long as you have an easy button I can smash to fix it, without having to pull in someone to deal with it.
- cookiengineer 3y ago> - being able to translate vendor BS to "if you don't do $X, $Y will happen with $Z likelihood" This kind of makes sense to me, having worked the last year a lot together with our industrial CERT teams and others. Most cyber security teams, due to lack of human resources and human time/skills/even more time, seem to have adopted this perspective to stay sane in the ocean of noise alerts. I want to iterate on that thought a little further: Is this an effect that was caused by shitty tooling? In an alternative product that would tell you "there's 0% risk of affecting the running apache2 service with these package upgrades which would fix 1234 different issues altogether, so we automatically updated it for you" ... wouldn't that fix the risk assessment management problems, too? With the peer-to-peer approach of our Agent, we can mitigate most of the critical issues automatically, and the deployment and rollout/update strategies are also measured in whether or not they affected the health status if a running web service (e.g. did the web traffic drop? were there a lot of segfaults after it? etc)... so this also leads to a better risk assessment because the data of whether it was successful as a mitigation strategy is shared among the peers in the same network(s).
- genmud 3y ago> I want to iterate on that thought a little further: Is this an effect that was caused by shitty tooling? Not shitty tooling per se, but ineffective communication, which can limit the actionability or requires context switches on the operators side. MITREs ATT&CK framework is helping solve some of these symptoms by tying things back to tactics/techniques and a common taxonomy, but there is still a long way to go. > With the peer-to-peer approach of our Agent, we can mitigate most of the critical issues automatically, and the deployment and rollout/update strategies are also measured in whether or not they affected the health status Most companies are trying to have less agents on their boxes, not add more. Tools that are agentless tend to have much greater chances of success, even if that means having a more complex architecture. eBPF + SSH configuration of for example a local log system or even pushing a collector/broker can be your best bet. You want to avoid an agent when selling to security people for 2 big reasons: 1) most of the time, security teams will not own the systems they want to put agents on, they have to get permission from the app/service owners and many times there is significant pushback. Many, if not most orgs have been burned by "just deploy this agent, there isn't a performance impact". 2) when you don't own the systems, you can increase the sales cycle and complexity of the sale, since you now are effectively requiring multiple groups to agree on something and agree that this is a priority. If there is disagreement, you can get vetoed by a group that wouldn't even be responsible for it. I am 100% not telling you that agents are impossible, but in most enterprises, it will be more difficult than you think to get it deployed. It might take what is normally a 3 month proof of concept to something that is 6 or 12 months, or could kill it before even starting.