Defense-in-depth is not a new concept in cybersecurity. Borrowed from military terminology, it was created by the National Security Agency to safeguard systems against various attacks, using multiple independent protective methods. Yet even though it's widely used in many organizations, the concept still requires adaptation when aimed at protecting against new types of attacks, targets, and methods.
Data security is another not-so-new idea in cybersecurity — it feels like it's been around for centuries. But when we talk about keeping data safe in the cloud, things get more complex. With more organizations adopting the cloud for data storage, sensitive information is likely to be stored on a host of technologies with different control mechanisms and is used for a variety of purposes by numerous teams within the organization. The result is that data can be compromised in different ways, so new protection methods are important.
Risk Reduction vs. Threat Detection
An often-oversimplified part of defense-in-depth is the choice to be made between risk reduction and threat detection. Risk reduction is all about minimizing the attack surface. When it comes to data security, this includes reducing the amount of unnecessary sensitive data being processed and stored, limiting access to sensitive information, making sure it's not publicly exposed, and so on. On the flip side, threat detection is focused on identifying the actual malicious behavior, such as data being exfiltrated from its location or ransomware activity. While defense-in-depth needs both, it's when you put them together that you get the best outcomes.
This brings up two questions:
Why not pick just one?
What makes data security unique when it comes to defense-in-depth?
To answer these questions, let's break down an extreme version of each approach.
When it comes to data, you can try to reduce risk to zero, but this would usually involve limiting the business from storing sensitive data or preventing access to data at a level that might cripple it from driving innovation. If no one can use the data, how can it help with customer support, training new machine learning (ML) models, or gathering insights? Zero risk usually doesn't work well in real-world business situations.
A team that focuses solely on threat detection will find itself drowning in alerts and not being able to adjust to the ever-changing data environments. Alert fatigue is already a big issue, so why pile on alerts about suspicious access to data you no longer need? Or handle data exposure incidents on redundant or legacy repositories, instead of removing them in the first place?
Combining risk reduction and threat detection brings the best of both approaches to organizations. Start by decreasing risk to an acceptable level — meaning a level that lets the business operate without assuming unnecessary risk. This would include deleting inactive data stores, removing unneeded access, limiting external access, and validating encryption and backup policies. However, even if you're not taking unnecessary risks, there's still some risk that requires monitoring: legitimately granted permissions can be abused by compromising credentials or with insider threats, data previously being relevant becomes obsolete, and so on.
Creating guardrails in which to operate is key, but keeping a close eye on what happens within those measures is equally important.
It's not just about reducing risk and then identifying threats. Having an understanding of where the risk is minimal and where bigger risks had to be taken allows organizations to focus their efforts on preventing threats more effectively. This might involve deploying additional products or choosing which alerts to investigate first to be more effective. If an organization was able to reduce risk by removing sensitive data from a specific location, it becomes necessary to monitor this location for exfiltration or leakage of sensitive data. If the data team is located in a specific geography, then alerting for suspicious data access from elsewhere becomes that much more important. This naturally requires a continuous and accurate understanding of the risk the organization has assumed (both knowingly or unknowingly), so the focus can shift to threats that can occur within that scope.
Here are a couple of examples that illustrate this:
If you decide to remove sensitive data, such as SSNs, from non-essential services like test environments or a data science team, make sure to implement continuous classification and alert if any data leaks occur outside of approved locations.
When defining access policies based on the principle of least privilege, create distinct access policies for different types of data. For example, remove EU data from US repositories.
A good data security approach can't focus only on analyzing static configurations and controls around how data is currently being secured, and it can't only try to identify a data leak as it occurs. It must combine the two approaches and build them in a way that allows them to complement each other.