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.