It’s the way software used to be purchased, and often still is.
A CEO, or GM, or line-of-business owner calls into IT, and the security and compliance teams, to let them know that they are purchasing a new piece of software to drive innovation in how they deliver their products or services. Because the software needs to be customised, integrated and controlled in the company’s on-prem or cloud environment, the IT team needs to deploy it and the security team needs to secure it.
The problem is that IT, security, and compliance are already behind. As the “Defenders” of the business, they must now apply multiple other third-party products to that application in order to to gain fine-grained control over who accesses it and what data they can access. While a growing body of regulations state that security and privacy must be implemented “by design,” they didn’t design the application that the “Builders” delivered. At this point, everything they do is fundamentally an afterthought.
The conundrum of the defender
The job of the Defender is a difficult one, because security and privacy as an afterthought creates both complexity and vulnerability. The complexity comes especially from security products needing to be customised in order to function in lockstep with the application whose data they are protecting. The larger and more complex the application to protect, the more you have to invest to configure and maintain the products that secure it.
Vulnerabilities arise because between the application and the security products meant to protect it, there are seams—gaps in communication, coordination, and capability that occur naturally when two systems that are constantly evolving occupy two different infrastructure spaces. It is those seams that endlessly produce new exposure every day.
More vulnerabilities lead to more security products, which lead to more complexity, and you can see where this is going. Large enterprises own an average of between 50-70 security products, and lack the personnel and resources to marshal those products to deal with the sometimes hundreds of thousands of open vulnerabilities that have been created by the patchwork.
Where this is reflected in the business is that spending on cybersecurity increases every year, but that spending appears to be doing nothing to stem the tide of data breaches and privacy exposures, which are expanding at an even faster rate.
Enter the builders
The perspective of the developer, the Builders of applications, has changed. More and more, requirements around managing performance, reliability, and scalability have migrated into development processes as dev-ops and cloud infrastructure have gone mainstream. Security has followed suit, as progressive developers and dev-ops teams have adopted the mantra that the secret to fighting this battle is to get more involved in security upfront.
The initial steps in this movement have been focused on decreasing the coding of vulnerabilities, meaning that tools have been introduced into the application assembly line that analyse code for security weaknesses and prompt developers to address those weaknesses before applications get released.
This is a huge step, as those code vulnerabilities, if not caught ahead of time, are what lead to the dreaded “security patch.” Patches are software afterthoughts which IT often finds very painful to apply, as it can mean taking a system down for maintenance or other contortions that are highly disruptive to the business.
It makes sense to write more secure code, because coding is what developers do. But many developers are doing more. Now tools are becoming available that developers can embed into applications that give security, compliance, and risk-management visibility into and control over the flows of data.
These tools are not an afterthought, they are part of the application—a forethought. Most of the complexity that an IT-delivered security product introduces is avoided because the utility of the application is delivered along with security, and everything is on the same page and in the same context.
More powerfully, the seams between the application and its security products which fuel the runaway train of vulnerabilities disappear. We see at ALTR that when an application developed using the programmable model is delivered, it has tools to manage data in a changing world of security, compliance, and risk delivered along with it. Data security and governance has been “programmed in”.
Programmable as cloud-native
With the ability to monitor data access, govern it, and selectively protect data even from developers themselves wired into applications, there is another door that swings wide open: application portability.
Many companies, from traditional manufacturing all the way to software companies themselves, are looking for ways to leverage the economics and flexibility of cloud infrastructure. For most of these companies, the number 1 and number 2 concerns as to going to infrastructure that they don’t control are security and compliance.
But when a development team wires in tools to allow for the control of data regardless of where the application is deployed, the business is free to determine the best infrastructure for the application in question based on performance, cost, reliability and other IT priorities. Cloud options from platform-as-a-service all the way to serverless architecture, where IT doesn’t have to maintain any of the infrastructure stack, are all on the table.
Through this lens the economic benefits of programmable data security come completely into focus. Adopting this approach, by way of example, ALTR has been able to help a business optimise its digital footprint based on delivery of technology services, not on the security of them. Also, there are some additional savings that these organisations realise in the consolidation of security products, because many existing products are tied to the infrastructure in which they are deployed, from physical network appliances to cloud-provider-specific tools. – Read more