Talking about the technology industry today can feel like giving your toddler a set of wooden blocks with different abbreviated words on them, and telling them to arrange them in a way that looks like it makes sense to them. They don’t really know what it means but it’s a fun game to play.
Unless you were living under a rock for the past three years, DevOps has been the goal for organizations developing applications to become more efficient, breaking down the walls between development and operations in the hopes of improving visibility which can enable faster releases. Part and parcel of this Agile methodology is the concept of frequent trial and error. Developers create a basic product and then test the stuffing out of it with regular feedback loops to catch issues early before they become more difficult to fix later in the process when more of the product has been built on faulty code.
In their excitement over DevOp’s ability to swiftly and efficiently move products through the various stages of development and production, organizations appear to have woken up in the past year or so with the realization that they forgot to include security in this process, leaving many of their products insecure.
The push to incorporate security into your DevOps workflow has led to the DevSecOps generation, a concept that is starting to take off as companies begin to understand that by implementing automated security tools and retraining your developers on how to think about secure practices for building their products, and including security pros throughout the development lifecycle they can cover most of the necessary ground to attain meaningful security.
While most of the newfangled terms have focused around the development side of the loop, there have been calls for a focus on the on how to make the operations side more secure without losing out on the efficiency factor.
A branch of the Agile movement, SecOps aims to break down the walls between your IT security and operations teams in a manner that bakes security into your workflow without being an impediment to productivity.
The thinking here comes from the revelation that these departments simply do not understand how to get their job done without causing troubles for the other. Part of the challenge here is cultural, with both security and operations see their priorities as absolutes and even if they understand that the other has value, they are loath to cede ground if they run into conflict.
For their part, security wants to make sure that all processes are carried out well, securely. This means using the latest testing tools, putting up strong barriers to attackers like WAF, and ensuring that they do not end up with egg on their faces from someone misconfiguring an S3 bucket, leaving data like passwords in plain text, or one of the other mistakes that can lead to their hacking becoming the punchline of one of the many weekly security news roundup emails.
At the same time, security needs to understand that if operations become too stifled by restrictions, then they will never be able to ship a product and the company will essentially shut down. A basic fact of the security vs dev/ops debate that is often lost is that if no product is going out, then there is going to be nothing worth protecting because there won’t be a company left.
In practice, this means that security teams need to find ways to carry out security actions without creating disruptions in operations and service.
On the other side, operations folks have grown accustomed to speed. Having finally come together with the developers to push software through the CI/CD pipeline faster, they have no intention of slowing down now. Add to this the fact that the scale of their own workload has increased considerably. Just as alerts have risen for developers to tackle over the past few years, operations have their fair share to deal with as well, keeping them on their toes just to keep their servers and product online.
So how do we close this gap?
One of the first tips that we would suggest is a carryover from our experience in implementing DevSecOps. Security, when it is done right, should be viewed as everyone’s baby. A sense of ownership is essential for baking security into regular practices.
Understandably, even if your operations and developers do put a value on security, they are not security people by training and it has not been on their own internal checklists. Change this. Educate them on SecOps best practices and encourage them to think about how they incorporate it into their work.
The least painful way to stay secure without getting stuck is to throw in security at the earliest stages. Shift-left as much of your security activities as possible so that your team won’t get hobbled by vulnerabilities or other issues later before a release when they are going to be significantly harder to handle.
Embrace automation for as many of the security functions as possible. While regular human operated pen testing will remain a necessity for the foreseeable future, automated tools can run continuously to catch much of the low hanging fruit which would otherwise take up valuable human hours. These tools should also be able to monitor your deployed products to alert on new issues as they arise in the wild.
As more elements of operations move to the cloud, we are going to have to engage with a changing ecosystem of tools and techniques. These technologies will all evolve faster than the humans operating them, but we will have to adapt as best we can to make sure that our teams are ready and aligned to deal with them as best they can.
SecOps is an important part of the DevSecOps puzzle for organizations that are developing and of course deploying software products. If your company is already making the shift to DevOps, leaving Waterfall in your past, then we suggest incorporating security from the earliest stages to avoid accruing unnecessary technical debt.
Hopefully, by adopting the right tools and embracing automation, this journey will be easier and the benefits appreciated across your teams.