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