To start with, I covered a few aspects from field experience (more recent and otherwise) on DevSecOps and Shift+Left approach. If you’re keen on reading these, see the following articles: DevSecOps – Making Sense of it and Let’s Talk about Shift+Left!
It’s no exception that my posts have been focused on DevOps with hints (correction – loads!) of security tinges to them!! In this post I would like to discuss the key characteristics and the changes I’ve witnessed as an evangelist in the field of Secure DevOps. None of these would be unknowns to people who are practitioners and do engage at ground level with the whole DevOps tool-chain and intricacies of navigating through the trenches while delivering customer usable code (otherwise known as Apps)
Let’s look at some of the most common yet, not very well understood concepts pertinent to DevOps, leading into the realm of Secure DevOps.
1. DevOps is a cultural change – Every organization whether born in cloud or coming from legacy roots faces the grave challenge of shifting focus from product or solution to customer requirements. And, that has been an issue since the Good Ol’ Days, focusing on ‘things’ to sell or push customers to adopt them; rather than looking at customer needs and adjusting the pace of workforce to deliver a cohesive customer experience. Now, coming back to the original point, organizations do run into issue of imagining DevOps as a big deal and breaking the silos. The right manner of thought would be – consider DevOps as a positive cultural change; from monolithic to modular thought process leading into better customer experience hence, resulting into sticky customers. Change as we know is inevitable and thus, adopting the culture shift to DevOps is a healthy and a strategic move for any mid to large enterprise.
2. Automation everywhere – By definition of automation – well, many would think of loosing their job or being re-purposed or re-aligned. That’s not true at all, in fact with automation at back/front-end new skills are required for developing more and more automation scripts and setup a regime for self sustaining workflows (technical and business) and move on to next project. No two projects are alike thus, no two automation needs are alike. Automation need not be turnkey however, the concept of bringing in automation for known variables across apps and other enterprise services is really practical.
3. Build a consistent DevSecOps Tool chain – While your organization is on a mission to implement and reap the benefits of DevOps in cloud or on premise (or Hybrid), it is key to understand that there’s a business goal to be achieved and a revenue forecast to be hit. Engaging in app development wouldn’t mean anything if the velocity of (or agility) developing and releasing apps isn’t up to mark as the business would desire. Hence, building a sustainable DevSecOps tool chain with the right set of tools (very important) that are well understood by all developers and operations teams is crucial. A tool / software that is not well known or the team hasn’t been trained on, is only going to delay the outcomes. A hidden gem here is – a tool chain that has security tools (e.g. SonarQube, reshift etc.) baked into the workflow.
4. Stick with a set deployment strategy – It is seen that DevOps teams keep swinging between different deployment strategies. While this may work for smaller setups with only a few apps, this doesn’t scale for larger enterprises with a fridge load of apps (app fridge anyone!). With the agility that businesses demand, it is good to plan in advance and have strategy set out well in terms of the deployment approach. While some organizations would want to go big bang; and there’s nothing wrong with it unless they’re not sure of what they’re rolling out – it is best to have a formal risk assessment of the app and it’s possible exposure to vulnerabilities leading to a risk averse vs. risk accepting approach. In other words – going Canary vs. Blue Green (or any other deployment strategy as deemed right). Changing deployment strategy on an app by app basis increases risk of exposure manifold.
5. On-board Information Security and Network Security teams – As a developer, one is always perplexed with security terms. While we are talking about agility, what happens to PII, PHI (and so on) if the data at rest or in motion isn’t secure and has high degree of exposure? No business would want short term gains at cost of security. With security budgets only going up YoY basis, there’s a reason behind all the hustle! It is best to have a cohort across developers, operations, and InfoSec + Network security teams. And the earlier, the better. This way, security isn’t left out and there aren’t any last second surprises on compliance or regulations – let apart, an app being blocked by security because it was too easy on TCP/UDP ports being open. Security should be seen as a positive contributor than a disruptor.
Well then, these are a few things which I personally and professionally have seen that go well with the overall construct of DevOps ~ leading to DevSecOps. It’s a Win-Win for everyone if the higher management drives the programs sensibly and has realistic time frames for apps to be released on GA basis. Not all problems can be solved by one person however, when like minds collaborate, problems give way to opportunities.