Bridging the Divide: Flexibility and Security

What do you do when you need two things, but ‘everyone knows’ that the two are mutually exclusive?

There’s been a long-standing myth within the networking and security communities: secure software architectures are inflexible, and agile-delivered software is less secure.  But hold on – is there any evidence to support that software developed using an iterative model is inherently less secure? If there is, my ‘research’ (read: Googling) hasn’t really found it.   

Indeed, you can make a credible argument that a faster delivery cycle and an automated, streamlined release process reduces risk by reducing the overall vulnerability exposure time.    

So, is there really a divide between flexibility and security? Sadly, I’d still say that yes, there is. 

However, I’m not convinced that an agile software lifecycle introduces any more inherent code vulnerabilities (although some of the new platforms – like container management systems certainly introduce new surfaces to attack), as the application code is only part of the overall security posture of an organization.

Recognizing that all software contains defects, IT technology stacks also contain security controls external to the application code such as network firewalls, intrusion detection systems, and web application firewalls. Many of these systems need to track application behavior and respond to newly discovered threats in frameworks or operating systems. Ideally these systems need to be as agile as the software delivery lifecycle. Because if they’re not then one of two things will happen – either the security controls are seen as impacting delivery velocity and time to value, or they won’t be providing the protection they were put in place for. Neither of these things are exactly optimal.  

The obvious solution is to move the security control model to one closer to the software delivery lifecycle model, and indeed the DevSecOps movement is beginning to apply software engineering and DevOps practices to delivering security controls and to sharing the responsibility for security with everyone in a team, even if the deep expertise stays with a highly experienced, specialized team of practitioners.

Matching this cultural transformation is a technological evolution, where the implementation of security controls, becomes integrated into the software delivery pipeline. Where the security controls accompany each new software iteration through test, staging and deployment, not just bolted on at the end. Where telemetry and trackability elements are injected and traced across multiple points in the stack. Where new metrics that help identify, track, and report on adversaries can be quickly gathered and analyzed. 

To make this possible, your technology stack needs to collaborate as much as your teams. That’s one of the most interesting possibilities in a future F5 + NGINX organization. With a portfolio that goes from network firewall to application server, and across all the layers in between, the possibilities for a more agile, more integrated, and more informative set of security controls are huge. The promise of enterprise-class security and visibility injected with lightweight agility has the potential to give everyone on the team the tools, information, and (relative) peace of mind they are looking for.

For more about the advantages of bringing F5 and NGINX together, check out a post from F5’s CEO introducing the ‘Bridging the Divide’ blog series.