In one way or another, nearly every major company is now a software company. Line-of-business teams all have scores of developers who use agile methodologies to push out code changes in attempts to find the next innovation on a weekly, if not hourly, basis. This rate of change is baked into their DNA, with the philosophy that most ideas are bad, so the best way to find a good one is to try a lot of ideas.
Old-school IT sees change as a risky endeavor fraught with potential to introduce security issues, pushing against the rate of change. But that’s backward. Innovation rules the day, and mandating quarterly software release frequencies are the best way to push a business team to find their own resources outside IT, in the public cloud—where those same old-school IT folks get even less control over what goes on.
Who is the biggest IT security threat in your organization? It’s whoever stands in the way of the rate of change that the modern software developer demands.
The trick for those concerned with security is to give the line-of-business teams the ability to provision self-service, on-demand resources, but to do so in a way that has the necessary security and monitoring built in via automation.
A common way to accomplish this is with a cloud management platform that enables an application developer to create an abstraction of an application out of reusable pieces that are defined, in part, by the security architect.
Here is a blueprint for a three-tier Java web application where a developer has used NGNX as a local load balancer, a pair of Tomcat servers as an application tier, and a MySQL database to store data. The pieces themselves are defined by a central governance organization so that, for example, only ports 443 and 80 are open for the Tomcat servers, and all components have malware detection installed on them automatically.
By making tools such as this available to business teams, developers are free to construct applications from a predefined set of components that continuous integration tools such as Jenkins can then populate with different builds of code whenever they become available. This enables a development team to release iterations at will, but through the component automation, each iteration already has sanctioned security built in.
Modern software development relies on a rapid rate of change. Whereas business teams once had only their internal IT team to turn to for computing resources, the public cloud has given internal IT competition not seen previously.
To not provide a mechanism that supports this fast pace is to essentially invite development teams to swipe a credit card on a public cloud where they would be free to procure whatever self-service, on-demand resources they like, but without any baked-in security safeguards an internal automated process would provide. To assure security, examine your own practices first.
