A while back I wrote a blog post explaining the difference between NoOps and DevOps - with a slant from the Information Security perspective.
If you haven't checked it out yet, I encourage you to do so as a primer to this post, and to get a more grounded understanding of where my head's at when it comes to addressing the NoOps movement.
The most important thing to remember is that I'm centering the idea of NoOps not around the disappearance of the operations team, but rather on the extreme level of automation that is required in a NoOps type of approach to application lifecycle management.
I'm actually quite excited about the notion of NoOps and what it could mean for the security posture of applications... but I'm not delusional and also understand there are plenty of opportunities to get it just as wrong as we are now across the board. Automation is never a bad thing, since it minimizes the error rates introduces by humans.
Any time we can remove additional opportunities for error is a good thing for security, you have to admit. On that premise alone we can start to at least be a teencie bit happy knowing automation could take care of some of the common issues we have with human beings missing patches, configuration issues, and introducing bugs as a result of oversight.
Automation is all well and good though, but you have to ask yourself how much automation you can introduce into a system like a software development and release cycle before you hit the limits of automation. Security tends to be one of those areas where we hit that automation glass ceiling relatively quickly and while technology continues to mature - we're still going to need manual labor in the equation to get security right.
More to my point - you can't test your code secure (without human interaction), even with the best automation in the known universe.
What can we expect from a NoOps-based approach to software development and release, when it comes to security? Let's look at the areas where I think Information Security can continue to have an impact, and what I think the resultant processes will be.
- pre-development - Before code is written generally there is some sort of formal requirement gathering loop which is different depending on the type of development methodology used, but always has some sort of starting point. Security should absolutely continue to influence and be visible in this stage of software development, through tools that enable the pull-along of security-based best-practice, requirements, and components.
- development - Without thinking twice I can surely tell you that information security has a dual role to play in the development stages of a NoOps strategy. In this type of release methodology, odds are you're following some sort of rapid-release cycle which means that development windows are relatively small compared to the standard waterfall approach... going from months or weeks to days or hours. If information security has any hope of reducing the number of net-new introduced security-based defects in this very critical stage we need a dual approach - education and automation. You'll need to have developers baseline educated in at least high-level security issue identification and remediation - and then you're going to have to equip those developers with amazing tools that integrate into their workstreams so they can get the code written with as few bugs as possible. I really feel that it is in this type of high-pressure, short-timeline environment that massively parallel scan farms will provide tremendous value, cutting scan times of code down from hours to possibly minutes. The feedback loop back to the developer has to be pin-point precise too, giving as little false-positive information as possible while providing tested and verified advice on where, how, and when to fix the issues identified.
- build/deploy- Without a doubt this stage is at the hear of NoOps, and security here is critical. Utilizing a modern mix of white box tools, tight build integration with the existing environment, and the power of the cloud (think PaaS environments pre-built with security templates!) the developer has a snowball's chance of getting code into the pre-production stages with minimal net-new risk introduced! Perhaps I'll expand on this in a future post...
- testing - While there may or may not be a formal step in the NoOps cycle for actual testing - some organizations let their users be their guinnea pigs, after all - there is always an opportunity to perform some security testing. You have two options here, depending on your situation. If your organization is utilizing a dev/test > production environment separation using something like a cloud platform (private or public cloud) then security testing has a chance to be run in the dev/test environment during any type of regular testing, time permitting. Even if there is no time, the beauty of cloud computing allows us to clone off an entire application for security testing in a non-volatile, non-critical environment that is disposable once we're done testing. In the second option you can even leverage hybrid testing to gain additional insight into the application's defects and source code connections.
- monitoring - Lest we forget, the release cycle doesn't end after that application or piece of code goes live. Even if you've simply managed to improve a search function, moved a text box, or added some new AJAX calls... you're going to want to make sure you monitor that release to make sure that you're not running up against environmental constraints, hitting bugs in the code, or getting attacked/hacked. Utilizing strong monitoring with hooks built directly into the application and advanced logging we can track attacks from network, to security appliance, to application server to database where the SQL Injection was executed... and potentially stop it before it leaves the network!
All in all, the NoOps approach to software release provides a fantastic opportunity to tightly integrate security principles and best-practices... but we've got to get it right. If you're in a position to implement security during one of these cycles, spend time analyzing how the workstreams will flow, and what tools will be used to standardize and automate - then hook into those as best you can.
Leverage cloud computing environments and pre-defined, pre-secured 'templated' (or as we say "Cloud mapped") PaaS environments where the developer is presented with a pre-configured virtual system every time which has been set up for minimal risk and exposure through the build process and the security team's involvement.
Leverage tools and automation, coupled with policy to make sure you're tightly integrated with the developer's IDE, build processes, and deployment tools/scripts - otherwise we'll be right back to where we started, on the outside looking in and trying to bolt security on.
I think once every few years we have a defined shift in the way technology delivers business value. I believe right now is one of those times as cloud computing pulls along things like the DevOps and NoOps movements through extreme levels of tool and process maturity and automation/standardization. Let's take a deep breath, and roll up our sleeves.
Less complaining about how poor the state of information security is in the applications being deployed, and more working with the right people to make sure we're making security as automated, standardized, and workstream-integrated as possible.
Cross-posted from Following the White Rabbit