Cyber Security folks – what are your biggest pain points?

I 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.

> while leveraging a mixture of golang for userspace and eBPF for kernelspace

This severely limits your market share. Most on-Prem customers are still using pre 5.0 Linux kernels, and most cloud first customers are already using Lacework, Aqua, Orca, or Wiz for cloud based asset inventory, monitoring, and even enforcement. Plus SentinelOne and other existing security companies are entering the market (not necessarily a bad thing, but would be difficult to compete without a compelling vision and GTM).

In my experience, the asset inventory problem is mostly seen in large Hybrid environments where asset ownership is split across multiple teams (a CMDB team, cloud platform team, application team, security team, networking team). This along with an SBOM story is very hot right now, but you will need to find a way to differentiate yourself from the list of competitors above, along with the hesitancy to manage yet another agent.

The bigger issue is that while this does sound like a cool feature, it would be a massive lift to make it defensible against companies with an existing Rolodex and also to manage the sales motion.

Also, customers hate installing and managing agents.

As a internal security person (now a consultant for third parties): your approach is interesting, but still fails where all security tools do, who is going to install the agent on every box. The reason why every asset tracking solution is incomplete is because they are trying to correlate agent data and platform data. This is exacerbated by cloud computing since resources are much more transient and new servers lack gating by a governance org.

Complex AV tools are cool but they are so far down the chain of actually exploited vulns, they are not super useful most of the time. Usually the vulns used are old and just unpatched (check the latest DBIR data to see average age of exploited vuln). So a lot of time and effort goes into cajoling teams to update packages and having them say "we don't even call the vulnerable function."

My biggest issues: -Asset inventory (SANS Top 20 #1)

-Software inventory (SANS Top 20 #2)

-Tagging of ownership (what does this box do and who do I call if it goes bump in the night)

To answer your other questions: -Yes, but that is because we created it

-Yes, but only because we have tooling to do it across cloud envs

-No, we only look at deployed bins

-Signature based

-Getting useful code deployed to a box is hard enough, unless there a RCE this is so far down the list of threats on our threat model

-No idea, I assume pretty good since we use MITRE references, but making sure those are accurate to what we find is tough

-Yes, all of them (Fedora, Ubuntu, Arch, Alpine)

> the MVP is trying to start with a better inventory of everything

That's a logical place to start and it definitely seems like a common weak point. It's also hard to justify spending in this area since it's not emphasized in compliance and it's hard to explain why it's important in a blurb.

> Do you have a reliable ... inventory

As you allude to, it seems pretty common to have multiple existing inventory sources and no way to integrate them. To me, the most intractable part of the problem was, ironically, workstations and servers. They are managed by different people using different tools and neither of these groups want additional security agents on their systems. Also, these types of agents tend to be prohibitively expensive when you have thousands of endpoints.

> systems themselves decide to mitigate issues, propagate patches

This seems problematic. I really don't want the security system breaking things without staff intervention. Security already gets blamed for any unexplained problems that desktop, servers, networking, and development have.

Most security tools are noise generators. Figure out how to separate the alerts that need attention from the rest.

Been in the space about a decade. Hope this helps.

1. Pain points: most corps already have tons of agents running everywhere, usually with one or more inventory management systems already. You would have to add a ton of new value to warrant another agent install. More agents = more ways in, which can weaken the system’s security. Discovering “unknown” network assets is also a constant struggle (qualys, rumble). Plenty of vendor apps and quite a few elastic search dashboards. Agent-based asset management is a very crowded space already.

- SBOMs: rarely see it, never seen it in third parties

- antivirus: rarely see it on linux servers outside of perhaps clamav scanning user uploads. You call monitoring systems for servers “IDS” intrusion detection systems. These are different from virus scanning and usually allow for runtime detection and alerting of anomalous behaviors.

- golang malware: all malware (shellcode included) must make syscalls to use system resources from userland. Your IDS should monitors syscalls. There’s no issue here.

- every medium to huge company I’ve been at has run Linux servers for everything, with AD boxes being the rare exception when the company uses windows clients.

Dealing with people running automated scanners that do nothing but spam you about nonsense.

Background: 25 years of information security in very big text companies, from IT to CISO.

People deploy whatever they think is useful, do not maintain it and then a vulnerability arises. Nobody knows where the implementations are.

Business pressures for availability, but did not want to sign off that they accept their systems to be insecure. You have a weak CISO and disaster strikes.

Reluctance to use cloud based systems because of a weird belief that local teams will do better.

Politics and who-has-the-biggest-one contests.

Lack of knowledge about what data actually matters in the company, and once it is known lack of will to invest in protecting it.

When crisis strikes legal is everywhere and teams waste time with useless feedback.

ISO certified companies where it is dangerous to sneeze because the whole system will fall apart. The whole ISO obsession is maddening. I have never seen a hacker hacking the certification to get in.

Generally speaking, a burnout because of the blocks cybersecurity gets, until there is a hack and then it is all their fault.

Finally, a small hack here and there helps to raise awareness.

Ah, and dreadful asset management.

Background: 25 years of information security in very big text companies, from IT to CISO.

People deploy whatever they think is useful, do not maintain it and then a vulnerability arises. Nobody knows where the implementations are.

Business pressures for availability, but did not want to sign off that they accept their systems to be insecure. You have a weak CISO and disaster strikes.

Reluctance to use cloud based systems because of a weird belief that local teams will do better.

Politics and who-has-the-biggest-one contests.

Lack of knowledge about what data actually matters in the company, and once it is known lack of will to invest in protecting it.

When crisis strikes legal is everywhere and teams waste time with useless feedback.

ISO certified companies where it is dangerous to sneeze because the whole system will fall apart. The whole ISO obsession is maddening. I have never seen a hacker hacking the certification to get in.

Generally speaking, a burnout because of the blocks cybersecurity gets, until there is a hack and then it is all their fault.

Finally, a small hack here and there helps to raise awareness.

Not sure if biggest pain point, but SBOM tools seem to be a wild mess. A tool that can generate a reliably complete SBOM in a heterogeneous landscape, considering the source as well as the end products (like containers) would be helpful.

The only tool that seems to get this even partly right is syft but it is still far from being an acceptable solution.

My biggest pain point is translating the internal compliance/security requirements into technical measures and monitoring them in real time. Not only infrastructure but also application security. In addition templating solutions and make them easily integratable.

A common trend with vendors is they can provide you all the data in the world that you want, but few condense it into actions to be done. The better ones do and even they only do surface level actions like one action for each detected issue. A smart person worth their salary takes in the data and turns it into a plan, these 500 issues get fixed with this action. If you want to lead in the automation state, do that. Go beyond simple detections and turn it into actions. Use data to infer states about systems you haven't scanned. Feed that into a tracking tool to showcase progress to make your customers look like they are moving goalposts.

The biggest pain points I have cannot be solved by Software. They can only be solved by a culture change, which I'm convinced is never going to happen. I want decision makers in my company to listen to me when I tell them to implement something _now_ be it update windows at once, restart the server, get rid of windows XP, patch your vulnerable dependency now, implement this security control. Rarely is any of this sane advice followed because it is considered to be disruptive, expensive or blocks the delivery of "real features" (meaning security is not a feature).

Hard to fix

25 years in IT, 8 of those in security, mostly as a Red Teamer and Red Team manager, mostly internal to very large orgs.

It's identifying owners, both for infrastructure and apps. When you're rampaging through a network and you find the Very Scary Thing that should be handled immediately and all you have is the VIP address of the load balancer in front of it, and the configuration manager has a system owner for the load balancer who left the company two years ago, things start to feel a little dicey.

How about MDM that doesn't slow every employee's laptop to a crawl? That's the real white whale of cyber sec.

Navy Research had funding for adaptive networks like you’re describing a couple years back. Should probably dig up the RFPs and see how that’s going

I don't work on security, but I have worked with security.

The [lack of] operational maturity of security software and skills required to administrate it, particularly at scale, and particularly administration of the data stores are almost certainly one of security's larger pain points.

Security often keeps itself separate-ish from production itself, so "who administrates the data stores for security systems, the data store expert overloaded with dealing with making the website function, or the security expert who knows a lot about security and not very much about data stores or operations?"

Another major pain point is controlling the signal to noise ratio and therefore determining the risk to toil (sisyphusian manual labor) ratio.

> 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

Are we talking production machines or employee machines? If you are referring to the former, I will yell at you. I have gotten people fired for doing that type of thing cowboy style. It's one thing to flag a machine as requiring administration by the people who understand it, it's another to administrate someone else's machines, particularly when they are on call for it.

What does mitigate, patch, or propagate mean in terms of actual example of administrative action? For that matter what does peer to peer mean?

> 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.

How do you intend to run analytics on a single node? A modern EDR needs a lot of processing power to analyze logs. You are going to have to push down potentially sensitive analytics to endpoints, and have the potentially compromised endpoint decide what to share. How is this scenario accounted for?

Is market research allowed on HN

While not titled as a cyber-security professional, I am a System Admin/Engineer who has worn that hat a few times when there was no one else available.

In my experience, it seems like vendor disclosures, and measures that might impact correcting vulnerable components are insufficient, and slow, if they happen at all.

The larger brands are getting pretty good about disclosing in a timely manner but you always have cost cutting happening unbenowst to you organizationally where inventory as you said isn't accounted for, and then those devices may or may not have disclosed vulnerabilities or had a fix within a reasonable time after public disclosure. Not vetted hardware but consumer, or semi-professonal brands that are much smaller.

I've run into areas where mitigations also were extremely costly because some simple circumstance was overlooked.

As an example, almost 8 years ago I was brought in to help a client who had suffered a ransomware attack where their previous IT staff were non-responsive and they were desperate.

They had Mcafee's DLP deployed organization wide, and the local DLP server that generated the unlock codes was among several other assets that had been encrypted but not documented or inventoried (so that didn't have a backup). The software product true to their word prevented even authorized system administrators from being able to make any mitigative changes without that unlock code which was not possible, their support for resolution was ineffective and useless. Even in safe mode, everything was locked down, and after exhausting all other options even accessing the system physically from a Linux live disk failed, the HDD would hang after trying to access certain parts of the disk (at an extremely low level). We were never able to figure out exactly what caused the hangs, but it happened regularly for long-running processes and we verified SMART passed. We had a guess that they were doing something funky with NTFS where separate files under a certain size get conglomerated into the same sector block which wasn't supported by Linux at the time, but we were never able to confirm definitively.

What could have been a few hour turnaround ended up turning into a week of downtime (where everyone was shut down, 10 days). Fortunately it was during the holidays which was their slowest time when they normally shut down for a week but it could have been much worse.

After exhausting options, we ended up having migrate data, wipe and reimage with almost a completely new infrastructure. We corrected a number of additional issues (misconfigurations) we found during the process but there was a good portion of time where we were just spinning our wheels with the vendor who was useless.

We went to contingency and stood up new infrastructure after we hit a certain threshold on man hours trying to work with them without any progress.