If your organization has a hard time pinning down data security, it's not alone. Many companies that build software applications give lip service to the idea that it is everyone's job to keep data secure. Yet this often means that no single team is given real responsibility, much less empowerment, to carry out that mission.
Data security falls between the cracks, not quite at home under the CTO, the CIO, the CISO, or within business units. Based on the ALTR team's extensive field experience, this white paper lays out the only truly effective way forward — putting data security firmly in the hands of those who develop the apps.
Implementing data protection is an ambiguous area of responsibility for too many organizations, and well-meaning truisms like “Security is everybody’s job” do not help the situation. Long experience in the field across different industries confirms this, whether the businesses in question create software for external customers or only for internal use.
Given the lack of clarity about who is ultimately responsible for data protection, it is no wonder that so few organizations empower a specific functional team to effectively address this issue. The result is that data security and governance too often fall between the cracks, not truly belonging under the CTO, the CIO, business units, or even the CISO or the compliance team.
There is an answer to this dilemma: put the responsibility for data protection in the hands of the application owners who create or manage the applications that use the data, and empower them — and the development teams that work with them — accordingly. That empowerment implies removing organizational roadblocks and using appropriate technology to handle the burdens of data protection. Clarity and empowerment on this issue will lead to not only firmly-grounded data security and compliance, but also to improved organizational performance in terms of innovation and competitiveness.
1. Most organizations suffer from both technical and operational shortcomings that hamper their efforts at data protection. To address this situation, responsibility for implementing data security and governance should belong with those who own the applications that use the data.
2. Organizations should empower application owners and the development teams that support them with solutions that enable them to quickly incorporate security and compliance at the same time. Crucially, given the nature of today’s increasingly virtualized computing environments, this must be achieved through security at the code level.
3. This approach builds enterprise value because it not only protects the organization from data breaches and compliance failures, but also enables personnel across many functions to improve innovation and competitiveness.
Ask a company which role or team is ultimately responsible for ensuring data protection or data security, and they often cannot give a single, clear answer. Even if it has a Chief Data Officer or formally designated data protection officers, responsibility is typically distributed across various functions under the CTO, the CIO, the risk or compliance team, and the CISO, with input from business units, data scientists, business analysts, product developers, and marketers. Rather than fostering an efficient, collaborative process, this scenario commonly results in an ambiguous, inefficient mess.
The tensions created by this situation may be most obvious if the company is a software vendor: the CTO wants software that makes the company and its IP portfolio more valuable, product and marketing teams want apps that are better and cheaper, the CISO wants the product to be more secure, and so on. Application owners and the developers who work with them are often caught in the middle, pulled in different directions as they try to create and manage highly functional apps so the company can thrive. In this setting, data protection — including both security and governance aspects — can easily fall by the wayside.
The same situation prevails in other large companies as well. Even if they do not make software as their primary business, virtually every enterprise today is a software business, in the sense of using and even creating applications to improve processes via logic and innovation. Examples abound: Insurance companies build mobile apps so policyholders can file claims on the go and adjusters can fill out damage reports in the field. Big retailers and transport companies write enormous logistical programs to manage complex supply chains. Many types of companies create their own software for processing financials and making forecasts. And almost every enterprise tasks solution architects or other application owners with implementing major third-party packages for a diverse array of corporate function.
All of these organizations rely heavily on the data that flows into and out of their enterprise applications. The good news is that these apps function as superhighways for the flow of data, bringing real benefits in terms of productivity — and, indeed, forming a foundation for value creation in today’s high-speed business environment.
However, these benefits also come with substantial risks. Business apps exist to take in data, process or store it in various ways, and then return it back. Now more than ever, they can do that with any kind of data, from anywhere, at any time, for any user with the right credentials. A staggering 53% of organizations leave 1,000 or more files with sensitive data open to all employees, regardless if they actually need it1. Giving so many people access to so much data creates many potential hazards, as even a glance over the past decade of headlines about corporate data breaches makes obvious.
Of course, many steps have been taken to protect sensitive data.Companies have turned to a variety of technologies, from firewalls to data loss prevention (DLP) systems to endpoint security software and everything in between. Security teams remind end users to choose strong passwords and change them frequently. Many companies preach to their employees that it is everyone’s job to keep data secure. And the entire discipline of identity access management (IAM) has become standard for every application. But how are you controlling data access once a credentialed user is verified?
And yet when asked who is truly accountable for owning and implementing data protection for the organization, many companies do not have a straightforward answer. The duties are fragmented, meaning that no single team is given real responsibility, much less empowerment, to carry out the task. The result? Data security falls between the cracks.
Data protection so often fails in this way because it is inherently a cross-functional problem. As already suggested, different parts of the organization are focused on different priorities, and rightly so. Business units and marketers that are busy selling software, or end users who are busy using it, cannot solve underlying data security issues in the software’s design. Product designers can lay out the functionality of the software, but for the most part they have limited insight into the code-level specifics of how the software interacts with data. Data analysts, data engineers, and data scientists are heavy users and even administrators of data-intensive software and have their own ideas about how it should work, but they are typically not the ones to implement data security within it. Compliance experts can lay out how data should be treated, but again they have little input into what happens inside the software.
Even CISOs will admit that they do not really know what is happening under the hood in a given piece of software — how much data it uses, or exactly how the data comes and goes. Meanwhile, security teams are usually loaded up with other duties, responsible for implementing and maintaining a variety of protective measures at the network level and elsewhere. Beyond that, they typically lack the specific expertise to embed security at the code level of applications. Although their work is vital, for all of these reasons they are not well situated to solve the cross-functional problem of data protection.
One role, though, is well positioned to solve this problem: application owners These professionals, who often bear titles such as enterprise architect or solution architect, have no choice but to deal with the cross-functional nature of data handling as a natural part of implementing an app, whether it is bought from a vendor or built in-house. Positioned as they are at the crossroads of technical and business concerns, they are the ones to manage tradeoffs among the competing interests of different groups across the organization as they deliver software for customers, whether internal or external.
Inevitably, they must also balance risk mitigation versus value delivery for the business. How they — and the developers who work with them — address data protection within an app determines how secure the app and its data are, how well the app fosters compliance with data regulations, and ultimately how much value the app creates for the organization.
Because application owners are responsible for how data is actually handled within enterprise apps, organizations must empower them specifically when it comes to data protection. By all means, application owners should take guidance from the other business functions that have a stake in data protection.But implementing strong data security finally falls to application owners.
If application owners and the developers who support them are to implement apps with strong data protection, they must address a key problem in today’s software. Existing methods for maintaining data security and compliance fall down because of a critical technical gap — the gap between the end users and database “users” of an application.
Consider this common scenario: An app might have ten million end users who can log in, ask questions, and perform tasks, but the application database itself will be accessed by only a very small number of service accounts, often only one or two, each of which produces a firehose of queries against the database. The app shuttles the query results to end users, but the database itself never sees those end users. From the perspective of the database server, it simply looks like the app itself is making endless requests.
This is an efficient way to build an app, but it creates problems for protecting data because current security measures usually reside at the network level and at the database server, but not in between, which is precisely where end users interact with the app, for better and worse.
Security teams must try to straddle that gap. Yet the nature of the problem means that they do not have adequate context for data access happening within the app. They see access from the database server’s perspective, so they cannot know which end user is accessing (or attempting to access) which data. This situation typically makes it difficult for them to formulate specific, granular security policies.
The need to address this gap is another reason that application owners must be responsible for implementing data protection. Yes, the code in the apps should reflect best practices laid out by compliance specialists, and the efforts of app owners and developers alike should harmonize with classic cybersecurity measures undertaken by the CISO’s team. But ultimately it is application owners, and the developers supporting them, who possess the context needed to close the gap outlined here. The best place to close that gap is at the source of the request within the application, where both the user and the reason for the request are known. This is the perspective from which to make the most informed decision about the appropriateness of the size and scope of a given query.
For the reasons just given, the security gap needs to be bridged by data protection that exists within the application itself. Any application-level solution to the problem requires at least three elements:
Code-level security is all the more important given the increasingly virtualized environments that enterprises use today. While traditional security measures are highly refined for defending on-premises environments, many of them are not nearly as relevant or effective once a given IT element is moved to the cloud. The more a company shifts computing tasks outside of its own security perimeter, the less it can rely on traditional network security tools such as firewalls and proxies.
Considering the extreme advantages of cost and performance created by cloud-based technologies, the movement toward virtualization will only grow more pronounced going forward. Increasingly, there will be no other place besides the code level to embed security. This trend can already be seen, for example, in the growing popularity of serverless computing. In sum, to be secure in the cloud, an organization must secure its code.
Unfortunately, this evolution often runs afoul of the current practices of security teams, many of which find themselves locked into specific technologies and vendors just to accomplish the basic tasks of their difficult jobs. As they work to protect the organization, security pros in this situation can sometimes unwittingly turn into “business prevention teams,” slowing down both specific applications and broader business processes as they force traditional constraints on developers who are eager to embrace new technologies. In many cases, organizations are not able to benefit from moving particular business functions to new equipment, new versions of software, or the cloud itself because the company’s cybersecurity posture is so rigidly tied to the specific configuration of its legacy IT environment. In fact, 44% of IT and Security Executives believe the complexities brought on by the cloud are the top barrier to improving data security.
In this setting, security teams often must resort to fragile workarounds that create friction and delays at just the moment an organization would like to migrate to better technologies. It is little surprise that security teams, and sometimes compliance teams as well, can come to regard data as a liability — a ripe field for breaches and regulatory fines — rather than a key asset supporting competitiveness and growth. Given this context, code-level security must be adopted in a way that enables better work by application owners and developers at the same time it meets security requirements.
Considering the centrality of internally developed software for enterprises of all types, it is important to give application owners and developers what they need to create powerful, efficient apps that deliver business value while improving data protection.
In the case of code-level security, it would be counterproductive to tell the developers who work with application owners that they must build embedded security functionality on top of all their other work. Good software engineers do respect the importance of security, but they typically regard security measures as a necessary evil; for the most part, they do not enjoy working on them or even possess the skills necessary to implement them. As a rule, they are far more interested in adding new features and improving performance. The enterprise benefits from this focus, given how central the functionality and performance of an app are to its value for the business.
Development teams must therefore use technology that enables them to address the crucial gap in security explained above within the flow of their typical work. Otherwise, they would need to expend significant effort on coding these functions from the ground up, and even more effort to test them thoroughly. That amounts to a bad investment of time and energy for the application owner and their team.
The solution to this problem is to deploy outsourced data protection technology that integrates immediately with an application’s existing code. This concept is already highly familiar for developers, who routinely turn to well-vetted third-party code libraries to handle key functions within their apps. In the data-security setting, companies do something similar any time they implement a third-party tool such as Okta orActive Directory to handle user authentication.
To borrow an apt analogy from another engineering context, consider how car manufacturers take advantage of third parties for safety-oriented parts such as seatbelts, antilock brakes, and airbags. Rather than wasting effort redesigning those technologies from scratch, auto makers focus their attention on high-value new designs for car bodies and engines, sensibly leaving most safety equipment to the expertise of specialty vendors. Besides saving money, this approach heightens safety for passengers at the same time it ensures that car makers remain compliant with safety regulations.
Similarly, app owners and developers should turn to a standardized outsourced service to complete the process of closing the gap for data protection. It is important to note that this goes beyond IAM. It is not enough to verify a user's identity when they enter the network or log into an app; there must also be a way to control what they can access in a granular way, down to the level of individual columns and cells of data. Therefore, this service must handle two key facets of data access at the user level:
The first point is critically important for maintaining data security in that gap between the network level and the database server. The second point is vital for both security forensics and for compliance with today’s tougher data standards such as GDPR and CCPA. In short, this approach makes life easier for application owners and developers by allowing them to implement better data security and compliance all at once — in a standardized way and with minimal extra effort.
The approach explained here creates clear advantages for any enterprise that adopts it. First, it solves the problem captured in the title of this paper. Rather than allowing the implementation of data protection to be left to chance by calling it everyone’s job, this method centralizes it with application owners, backed by their development teams, so that the entire organization can rest assured that data protection is being handled effectively.
For obvious reasons, this is a positive outcome for both security and compliance functions. Security is specifically improved by catching abuses or breaches in real time and tracked for diagnostic and enforcement purposes. Rulesets governing the flow of data are easily implemented, and bad traffic can be isolated granularly. Meanwhile, the security team benefits from having a new tool — one they need not build or maintain — that helps them fulfill their mandate in a fast, efficient way. At the same time, this approach keeps security from acting as a bottleneck inhibiting the productivity of application owners and development teams. It also makes life better for security teams because it helps them escape vendor lock-in as it creates protection at the code level rather than being limited to the network level.
Beyond that, safe, compliant, efficient apps benefit all aspects of the business; this approach addresses concerns of the CTO, product and marketing teams, and heavy data users such as data analysts and data scientists, who are often tasked with monitoring and governing data once an application is up and running. It also removes other critical points of technical and operational friction so that the application owner can deliver better value for the whole organization.
Because this type of data protection is delivered as a third-party service, it allows developers to work smarter and faster by taking advantage of knowledge created by outside experts — just as in the case of code libraries for building apps, or the third-party safety equipment installed in cars. Application owners and developers thus have more control over what each app is doing, but without needing to create new areas of code from scratch.
This approach also keeps developers happy and motivated as they do what they most enjoy: adding features and improving performance. That makes them more likely to use their talents well, remain in their jobs longer, and recommend the organization as a place to work for their talented friends. And it makes the work of the application owner that much easier.
Finally, this approach is good for an enterprise’s future.Besides the advantages already mentioned, it allows the organization to treat data as an asset rather than a liability — a new source of value to be tapped to foster business growth. It frees up personnel across many functions, starting with application owners and developers but radiating out from there, to give more of their attention to innovation so they can more quickly bring new ideas and new offerings to the market. All of this only increases the competitiveness of the business — something that really is everyone’s job.