This one stood out amongst all of the posts proclaiming the need for agentic AI on the defender's side, due to how these agents were currently being employed on the attacker side. We hear things like "autonomous agents" being able to bring speed and scale to attacks.
I will say that in my experience, defenders are always going to face complexity, but by it's very nature, I would be very reticent to call it "unprecedented". The reason for this is that cybersecurity is usually a bolted-on afterthought, one where the infrastructure already exists with a management culture that is completely against any sort of consolidated effort at overall "control".
Most often, there's no single guiding policy or vision statement, specifically regarding cybersecurity. Many organizations and/or departments may not even fully understand their assets; what endpoints, both physical and virtual, are within their purview? How about applications running on those endpoints? And which of those assets are exposed to the public Internet, or even to access within the infrastructure itself, that don't need to be, or shouldn't be?
For example, some applications, such as backup or accounting solutions, will install MSSQL "under the hood". Is your IT team aware of this, and if so, have they taken steps to secure this installation? From experience, most don't...the answer to both questions is a resounding "IDK".
Default installations of MSSQL will send login failure attempts to the Application Event Log, but not successful logins. That only really matters if you're monitoring your logs in some way; many aren't, and even with SIEM solutions, these events are sometimes not included in monitoring. I've seen endpoints with upwards of 45K (yes, you read that right...) failed login attempts to MSSQL recorded in the Application Event Log, but this is most often on systems where the application doesn't rely on the MSSQL installation having hard-coded account credentials.
The point is that basic IT hygiene starts with an accurate asset inventory, and is followed with attack surface reduction. Once you know what systems you have, and what applications should/need to be running on those systems, you can begin to address such things as logging configurations, monitoring (SIEM, EDR, etc.), etc. Attack surface reduction adds to increasing the efficacy of your controls, and to minimizing noise from false positives. Not only does this ensure that you're alerted when a security incident does occur, but it also provides for context, *and* it furthers your ability to quickly determine the nature, scope, and origin of the incident. I've seen organizations who are using SIEM, but the Security Event Log on many of their Windows endpoints are not logging either successful logins, nor failed login attempts.
This is going to be something of a hot take for many readers, but right now, AI (and specifically agentic AI) is a distraction for defenders. Yes, based on what we're seeing through social media, agentic AI may be furthering threat actors by facilitating faster attacks, at scale, but when it comes right down to it, it's all about the speed and volume; exposure of vulnerable systems remains the same. It's the finding and exploiting the vulnerable systems that's gotten faster.
The fact is that for the attacks to be successful, even with speed and scale, vulnerable systems need to be exposed to the Internet, and as such, accessed via some means. Yes, even endpoints not directly exposed to the Internet can be compromised via attacks such as phishing, SEO poisoning, or some other means that tricks the user into installing something that reaches out, but even some of these attacks can be inhibited or even obviated by some simple, free modifications to the endpoint itself.
No comments:
Post a Comment