3 ms·

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 like

• 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.
    • cookiengineer 3y ago
      In regards to the suggested collector approach: Currently, the peer nodes can deploy themselves to other surrounding nodes, and there's also a "discovery" strategy that tries to find out as much as possible about surrounding systems in the network. This usually leads to running the binary on the other system, collecting the information, and removing the binary and the report from /tmp afterwards. Initially I wanted to push this as a pentesting approach, and simulating actual exploits inside the network to see "how far" someone could go, where the critical hops are etc. Maybe I am seeing this a little wrong, but would such an approach work for organizations where multiple teams share an ownership of a system? Maybe on a scheduled basis so it doesn't conflict with high network load times? This way there would be basically a collector that re-routes the S/N/SaaSBOM reports back to the dashboard where the cyber security team would operate in. Inside the program, it's already implemented an basically just a different action that's running. In that case it would be the "tholian-guard <collect>" action vs the EDR-mode "tholian-guard protect" action. Thanks much, this is very valueable feedback I need to think more about, and also the way I'm communicating/designing the dashboard workflows for this scenario.
• muttled 3y ago
  > 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. I hear this one. I can't count the amount of times some salesperson has managed to get the ear of a decision-maker and try to insist that we need to solve some new urgent problem category that the vendor's sales department has invented. The solution always promises to solve all our "newly discovered" problems but the solution requires us to dedicate someone 20-40 hours a week to just working their platform. Another fun one is they advertise that it's "automated" but the setup is so long and arduous with required organizational process changes that break workflows that it sits there doing 5% of the advertised capabilities like a gym membership you don't use often, but feel like you've admitted defeat if you cancel it.