In recent articles I've talked a lot about DevOps, and specifically addressed and expanded on the role information security has to play in the NoOps methodology - but today I'm going to dive into discussing how you should be leveraging the cloud to get you closer a state of NoOps in quest to deploy faster with less risk.
First a quick refresher - NoOps does not actually mean "No Ops" as in "no operations" ... that would be silly ... instead NoOps focuses heavily on the extreme levels of automation and workstream optimization to achieve new speeds in rapid deployment. NoOps' focus is on leveraging automation, from development through deployment and beyond, to increase the speed at which applications can be brought through the release loop. Organizations are finding efficiencies that can provide them enhanced levels of speed from several releases a year to several releases a week, potentially all while finding innovative ways to reduce risk to the application.
Keep in mind that reduced risk isn't simply talking about 'security' here. Risk can come from a failed deployment due to a configuration error or deployment environment inconsistency. Risk can come from a successful attack due to an exposed security issues which went unchecked. Risk can come from poor performance under general or special conditions... again an issue which went unchecked through the SDLC loop. The risk to the application is just as great from a failed deployment script as it is from a successful SQL Injection attack - either way the application suffers a catastrophic failure. An application that cannot be deployed to meet customer requirements is on some levels just as much a failure as losing data through database exfiltration using SQL Injection - either way your customer will lose trust in your ability to deploy resilient and operational code.
NoOps sounds like a great idea in theory, and many organizations I'm working with today fancy it something they would eventually like to get to but it's still an unreachable state given today's conditions in development. Many of these organizations don't have the automation, the knowledge, or the understanding of risk to get them to a state where they're rapidly releasing code that is risk averse.
So what is the single most valuable piece of technology that can push a development closer towards a NoOps methodology? I believe it's the adoption of cloud computing. While many of the security folks who read this blog are probably shaking their heads right about now, read on and let me convince you.
From a Security Angle
From a security angle, adopting cloud services - or compute as a service - initially sounds dangerous. There's nothing quite like giving up that control you have over your environment right now to some vendor or 3rd party where you can't actively touch or change security settings. This would be totally true if that control I'm referring to wasn't a complete illusion security professionals have deluted themselves into believing. Be honest with yourself - how much direct control do you have over your environment right now?
For security organizations who have already started making the shift from a control-based to a governance-based security methodology having a level of trust in a 3rd party service is easier than those who are still stuck thinking they ever had control of their own dominion in the first place. Let's pretend that you can no longer execute the security policy of the various environments your applications get deployed to - what's left? What if you could simply dictate that policy, and govern its execution through real-time telemetry? Is your Infrastructure-as-a-Service (IaaS) provider doing their job delivering a low-risk environment? You can easily validate policies as 'enforced/not-enforced' without having the ability to make changes or perform changes yourself... and it may even be more valuable to have someone else make the actual technical security changes while you provide the business context and govern the policy.
Furthermore, think about the huge benefits to overall risk reduction you can make when you can fully automate the deployment of virtual machines for development, testing, and production systems - all from base images which were built with security from the ground up. This is a radical new approach to development where the developers and operations engineers get to deploy quickly while having security "infused" throughout the release process from requirements, to development, to build and deploy and post-release monitoring... without having to have someone from the security team constantly showing up at the last minute slowing down the release process.
From the Developer/Operations Angle
Lower risk is all about not having to change too much from a functional state. This can easily mean that if you've got a working and stable, scripted and configured development environment you need to be able to transport that to the build/test environment and then onto production in a hurry without having to spend time manually making configuration changes and scripting new bits. Ultimately we want choice, consistency and confidence (the 3 C's) in the available environment to get from start to finish and back to start again with minimal pain and manual tweaking.
As an example, HP's Converged Cloud story supports this line of thinking exactly. Being based on OpenStack - how's Converged Cloud delivers choice and consistency whether you're deploying a private cloud in-house, a public cloud, or a hybrid cloud environment. Having all of these delivery options for you be consistent works for towards the goal of deploying faster. Furthermore, having standardized on OpenStack the customer has choice to move from one vendor to another, and even to/from the HP Cloud Service (HPCloud.com) if necessary or required. Confidence comes from having the ability to build security and resiliency into the compute services that will be leveraged to enable more rapid delivery of less risky applications.
Developers have the ability to code and package an application once and deploy to various incantations of the cloud service, whether it's private, public or hybrid - by abstracting the model from the technical implementation it becomes more simple to create successful deployments from development, to test, and ultimately to release and back again.
Why do I feel that a Converged Cloud strategy is one of the most important factors in enabling NoOps? If you believe that NoOps is about automation, not the eliminations of operations functions, then you must believe that automation through a consistent, elastic environment is a key component to success... and less risk.