In “Developers don’t care about (data) security!” I dive into why that title isn’t necessarily accurate, but what is true is that developers don’t care about compliance—and by extension privacy regulations. Not because they don’t care about the underlying issues, but because the rules are murky and confusing.
Developers are very pragmatic. They want to understand why they have to do something and need a definitive answer about what they can or can not do. That is the opposite of compliance and privacy, where answers are often less clear-cut and can differ by region or industry. I’ve never seen more opposite people than developers and legal teams. I know it may be seen as an excessively dark picture, but get your engineering team talking and you will arrive at the same conclusion.
On the contrary, data security is all about technical implementation. It’s about code, about what can or can’t be done at a technical level—something that engineers understand well.
CISOs are stuck playing liason
Security leadership, especially in software-centric organizations, is at the crossroads of data security and data privacy. Because of how much sensitive data their engineering teams manage, and the complexity of getting any visibility over it, compliance teams have little choice but to knock on security’s door.
I would argue that a good data security program should provide the foundation to implement a proper data privacy program. It starts with visibility and allows the compliance team to do their work without the constant back and forth with engineering teams through the security office.
How do we classify data, and why does its governance matter?
The starting point for classifying sensitive data is obviously to determine which regulations apply at both the macro and micro level. Then, with your stakeholders in mind, you can apply a risk-based approach.
Focusing on what really matters is a great foundation. It will ensure that you mitigate risks more aggressively where they are highest, and good practices tend to flow down to the lower risk cases as well. Develop and apply very robust policies where they are vital, and you have an operational—and cultural—blueprint which can be applied elsewhere.
This is why data classification is such an essential first step to ensure focus and a risk-based approach. It is also the foundation of sound data governance, something that should be front of mind in a world where data is likely to be among your most precious assets (if not the very most).
We don’t secure data, we secure systems
Most people I’ve talked to don’t understand what data security means, and often mistake it for data privacy. There is a good reason for that. Data security doesn’t mean anything. We justify its meaning, but that’s just to make it easier to understand.
Information security is about securing systems. Hardware, networks, servers, containers, and applications. Data is a weird concept in that mix. We don’t secure data itself—encryption aside—but we secure where data flows, the systems.
In many regards, data security is just security. We add the “data” to emphasize that in today’s software ecosystem, data is the most important asset. By focusing on the data, we can better scrutinize these systems—because they are putting sensitive data at risk in ways that the systems on their own may not be.
Security in its modern state is still quite a new practice and an extremely difficult one from a technical and organizational perspective. Today, security teams suffer from an overload of solutions and alerts. Security alerts are provided at every layer of the stack, often without the knowledge of one another. Since sensitive data is flowing between these layers, identifying which alerts pose the greatest need is a challenge.
Alert fatigue is real and can cause oversights. But worse, it becomes very difficult to prioritize what matters. When everything is an emergency, the most vital threats aren’t fixed in time.
Data is one of the most important assets we need to protect, but none of today’s solutions treat it as such. How can we fix that?
A data-first approach
What’s the solution to this firehose of alerts? How about a system where all your security alerts are prioritized by sensitive data impact? We can’t afford to add more noise and more work to overburdened teams, but by prioritizing alerts by data impact we can decide what’s worth the effort to remediate. It’s still a list of tasks, but now it’s in the order of greatest impact.
Everything today is about data security, but at the same time, nothing is about it. Data security as a new product category is just a mirage. It’s still security. Let’s evolve our current practices and solutions toward a data-aware or data-first approach, allowing teams to be more effective at the ultimate objective—protecting sensitive data.
