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