The Value of a "Left of Breach" Posture
Being breached is a bad thing, I think we can all agree on that. At Nuix, we’ve defined that condition as being “right of breach.” How do you define the value of focusing on a “left of breach” attitude toward cybersecurity?
The cybersecurity community has said for some time that data breaches are inevitable. It won’t be very long before the news cycle gives us the next “shining example” organization that has been breached and suffered significantly as a result.
As the stories of these breaches emerge, we continue to see organizations remaining right of breach for too long; that is, in pure reactive mode, panicking and scrambling to collect information that may no longer exist days, weeks, or even months after the breach occurred. What does this look like in practice?
Living Right of Breach
The first step to understanding the difference is learning what to expect if you choose to remain right of breach.
Panic and Pandemonium
When you learn that your organization was breached, even if the details are not yet public, you panic. There’s no plan in place for what to do, nor who is responsible for doing it. You have to identify resources and assets. Very often, you can’t find the data you need to inform legal counsel and senior executive decisions due to inadequate incident preparation. Combine the lack of planning with a lack of experience and the overwhelming requirement to report to compliance and regulatory bodies, and the result is panic.
The end result is that a breach becomes wildly expensive. Publicly available information regarding recent breaches illustrates this; in addition to response and cleanup costs, there are costs associated with notification (doing so and not doing so) along with lawsuits, reputational damage, and more.
Reporting and Notification
Ah, yes … compliance requirements established and enforced by regulatory bodies. When you become aware that a breach occurred, you very likely have to report something to someone. How does that conversation go?
You: “We were breached …”
Customer: “What happened? When did it happen? What data was exposed?”
What’re the answers to those questions? Well, at first, you don’t know. So, the next logical thing to do is start investigating. Who’s going to do that? Who within your organization has the skills and experience to conduct a data breach investigation, possibly perpetrated by a dedicated adversary, or even a nation-state actor?
I’ve worked a good number of data breach response engagements and with every one I’ve seen that without instrumentation to provide the necessary visibility into the adversary’s activities, there are no definitive answers.
Oh, the costs. Breach notification is never a planned event, is it? It’s not as if you start a fiscal year knowing if you’re going to be breached, how many breaches you’re going to have, or what the total cost will be. Breaches happen and there’s a sudden, significant expense. There are direct expenses that can add up quickly, such as hiring a consulting firm to help you learn about your own infrastructure. There are also indirect costs such as a loss of productivity as staff members focus more on recovery than their normal jobs.
Turning Attention to the Left
Now that we understand a little more about the costs of being breached, let’s turn our attention to the benefits of staying in that ideal left of breach posture, and some ways to remain there.
Programmable Costs and Overall Cost Reduction
If you plan for incidents to occur, if you live left of breach, you can budget for the costs of planning and implementing your security program. Yes, there are one-time startup costs and annual maintenance costs, but all of these can become part of the budgeting process because you know about and fully understand them ahead of time.
By taking this approach, you can detect breaches much earlier in the adversary’s cycle. This obviates a great deal of the costs resulting from a breach. By detecting and stopping the adversary before they can access sensitive data, you avoid the costs of notification and the legal fees for subsequent lawsuits.
More importantly, if you’re only responding to a breach months after it occurred, it can very hard to say definitively which data was accessed. Detecting and halting the breach before the attacker can access sensitive data means you won’t have to deal with notification costs.
When you instrument your infrastructure for visibility, you naturally learn a fair bit about what’s going on inside your virtual walls. You begin seeing a great deal of the activity that’s occurring on your systems, both long-running and short-lived processes. As you begin monitoring your systems, even the most basic filters for process activity will illustrate suspicious activity:
“Wait, who is this user running commands to query the system hostname, and why is the command processor running as a child process of the web server?”
This sort of visibility, particularly when coupled with system hardening and audit configuration, inherently leads you to detect suspicious activity, as well as outright breaches, much earlier. Rather than learning from an external third party that you’ve been breached, months after the actual breach occurred, and weeks after sensitive data was exposed, you find out about the breach before the attacker can access sensitive data.
Endpoint visibility and monitoring allow you to detect the presence of malicious actors sooner in their breach cycle—which ties into my point above—and you can identify their entry point and respond with a planned approach before they develop a foothold within your infrastructure.
How Do You Get “Left of Breach”?
Getting left of breach means configuring your systems appropriately for your infrastructure and then instrumenting them for visibility.
When I say configuring your systems, ask yourself questions like:
- Why is our DNS or DHCP server running a web server and Terminal Services?
- Should both of those be accessible from the internet?
- Are our systems configured to provide only the necessary and defined services, and are those systems and services patched appropriately?
The purpose of system configuration is to reduce your attack surface, making it harder for an adversary to gain access to systems by forcing them to change the methods they use.
Simply put, don’t make it easy for them.
By instrumenting your systems, I’m referring to endpoint visibility and monitoring, along with the appropriate application of threat intelligence. Many times, dedicated adversaries access systems for only a brief period of time, and through processes that are extremely short lived. Endpoint instrumentation allows you to capture a complete record of those processes, which then gives you the ability to quickly filter through massive amounts of data to focus on just those activities in which you’re interested. The same is true for insider threats as well as a wide range of security issues.
It comes down to the adage “An ounce of prevention is worth a pound of cure.” Of course, you can justify spending large sums of money and time by waiting for a breach to occur. Once that happens, what choice do you have? But isn’t it better to take the time, money, and energy to focus on staying left of breach as long as possible?