#RSAC | 2016 Is the Year of Developer-Driven Security

In the past 10 years or so, the security industry has gone through a number of paradigm changes, most of which were propelled by fundamental shifts in infrastructure or application-related technologies—think cloud or mobile.

By Chenxi Wang

One such shift that is rapidly changing the way companies are approaching security involves the increasing power of developers and how application infrastructure is being approached today.

In the past, everyone used to develop software for “boxed” products, where developers had no or little knowledge of what the runtime environment would be; this was true even for software developed in-house.

Similarly, security was largely developed to secure “boxed” applications. As such, the industry primarily focused on infrastructure-level protection like perimeter defenses, which treated the application very much like a black box.

There is a certain elegance to this model—except it didn’t work. Despite the tremendous amount of investment in network and infrastructure-level protection, many have failed to protect customer data and critical information.

When “cloud” came along, developing for “SaaS” was a different experience that required very different software design and security practices.

For starters, it was no longer sufficient to have a few major releases per year for cloud applications. Daily, or sometimes even more frequent updates were required. This, in turn, required a more agile software lifecycle management approach, which ultimately led to the methodology of Continuous Delivery and Continuous Integration (see Figure 1).

Figure 1: Software development practice change

To achieve continuous delivery, you simply can’t have monolithic applications because no one can afford a complete overhaul of the application for each update. As a result, application architecture gradually migrated toward a collection of inter-linked software components, known as micro-services (see Figure 2). Each micro-service can be updated or replaced independently of others, which not only enabled Continuous Delivery, but also help to promote portability and standards-based development.

Figure 2: Software architecture change

This fundamentally changed the economy of scale for software development, the speed of delivery and ultimately, the pace of innovation.

This creates a new environment that requires fundamental shifts in the way we approach today.

First, you now have tons of new bits being dropped continuously into production, without IT Security or Ops being able to review them a priori—what typically happened with “boxed” software. This means you either become a naysayer, or relent to giving developers carte blanche for deploying anything they want to production.

Neither sounds like a very attractive choice.

On top of that, you begin to realize that your relied-upon infrastructure-level security is failing, because the controls lack the visibility and granularity that you need to effect continuous integration-style deployments.

To get around this, Security and Operations need to adopt a developer-driven mentality.

What is developer-driven? When boxed software becomes API rich, it signifies a developer-friendly environment. Being developer-driven takes it to the next level; an environment qualifies as developer-driven when developers get to determine (or play an active role in determining) runtime dependencies and stipulate operational policies. A concrete example of a developer-driven environment is container-based infrastructure, where developers construct container images and encode runtime dependencies within the image and push them directly, possibly continuously, into production environments.

To enable and function in such an environment, security needs to become developer-driven. A developer-driven security model has these characteristics:

a) The fundamental properties of the model are stipulated in development time,

b) The implementation comes together automatically and dynamically in runtime, and

c) It provides a verifiable level of security

Before that becomes a reality, a few things need to happen.

• Stardardization of security abstractions: Certain security functions need to be abstracted into plug-and-play yet programmable components to support a developer-driven model. Very much like how NFV abstracts networking functions, we should see security functions like firewall filtering, low-level intrusion detection, authentication, etc., become abstractions. That way, developers can specify “what” to do in terms of security, rather than “how” to do it in runtime.
• Augmentation of the DevOps process: The current DevOps process and the orchestration layer that launch software packages into production are essentially a black box to Ops and Security. Tools are needed to augment these processes to allow lightweight inspection and verification that the processes do follow standard policies.
• Real-time visibility and feedback loop: As security becomes developer driven, it’s especially important for the system to have real-time visibility and a feedback loop for dynamic controls. Just as application functions are being continuously deployed into the production environment, security will become a constantly-adjusting lever as new functions are being introduced into the system and new threats arise on the horizon.

If 2008 was the year of mobile security, and 2010 was the year of cloud security going mainstream, 2016 will be the year of developer-driven security, regardless the location of your infrastructure and the types of devices deployed.