Most people don’t think about security when it comes to DevOps, but the process involves many vulnerabilities. Data at rest and in flight is left unencrypted in many cases. Moreover, role-based security is often tossed out the window to allow for faster production.
In this article, I’ll explore the critical issues with DevOps security. You’ll learn how to understand your potential vulnerabilities, how to eliminate them from your security operations (SecOps) processes and automation solutions, and how to improve the security of the resulting applications.
Put security in DevOps first
These days, we are building applications with continuous everything: continuous integration, continuous testing, continuous deployment — the list goes on, continuously. Of course, we’re looking to deploy applications and data using continuous operations, which comes with continuous security.
We’ve looked at security as an add-on for the last 20 years, so the SecOps aspect of DevOps is often an afterthought. However, in order for “continuous applications” to provide the right level of security, the security approaches and technologies must be systemic to the applications and the applications’ data.
Thus, we need to do two things: First is to protect applications and data within the DevOps automation chain. Development environments are often targeted these days because our guard tends to be down until we move into production. Second is to build security into the application.
What needs to change? The core questions are: What are the fundamental changes to our approach as we add DevOps to our corporate capabilities? How does the answer to the previous question affect our approaches to SecOps, as well as compliance and corporate governance? A few key points to focus on:
Security within DevOps needs to be systemic and a part of each automated step as we move from development to testing and finally into operations. We have to keep security in mind at each step as we build and operate the applications, and not just at production — continuous security.
One focus should be on identity access management (IAM) for DevOps and production systems. There are so many players and components, including developers, integration servers, staging systems, and production systems, that tracking all of the people and tools using traditional security approaches is impossible.
Find your vulnerabilities
Finding security vulnerabilities during the DevOps automation process is pretty easy. You just provide an infosec audit of the process, tools, systems, and players. Questions to ask include:
- Does the developer have the proper rights to access the application code and the data?
- Are all copies of the application, application code, and application data that are made during the DevOps process tracked and maintained with the same degree of security?
- Are identities tracked at a fine-grained level, including microservices and data storage objects?
- Is security centralized so that all components in DevOps and production are tracked using the same database or repository?
Most DevOps shops have many security vulnerabilities that are easy to spot by auditors. However, it’s the vulnerabilities that are not as well known that will provide the foundations for a breach within the DevOps systems.
Many argue that DevOps should limit security to allow developers the freedom to quickly build and deploy the software. But if DevOps is to truly provide agility and speed-to-market for the business by automating most development activities, then, logically, security should be automated as well.
Invest in security solutions for DevOps
We’ve focused on IAM for DevOps as we moved to more distributed and heterogeneous systems, which is exactly what DevOps and production servers are. Moreover, as security and compliance issues begin to become the number one priority for DevOps, the investment in IAM is being made both within the enterprise and within public and private cloud-based systems.
This provides several advantages, including the ability to:
- Have common identity validation for systems both inside and outside the DevOps process, no matter where DevOps automation components are hosted
- Centrally and automatically solve problems, such as identifying and neutralizing security problems
- Spend less on enterprise security by relying on the centralized trust model to deal with identity management across DevOps and production systems
- Provide IAM services down to the microservices and data object layers
The IAM market will be worth about $12 billion by 2018, if the current rate of adoption continues. Most of this growth is driven by interest in cloud computing and DevOps. This is a fundamental shift in how we think about security. Most enterprises will update their security systems by next year.
This means that IAM systems are starting to show stronger sales, including brand names such as Oracle and CA, as well as relatively new names such as Ping Identity, and even cloud providers such as Amazon Web Services (AWS).
For example, AWS IAM, is a full-blown identity management and security system that allows you to control access to AWS services, including database services such as RDS and DynamoDBNoSQL Cloud Database Service. The AWS identity management offering is a solid cloud-based IAM solution that allows you to create and manage AWS users and user groups via permissions that allow and disallow access to data. The AWS IAM is systemic to the entire AWS cloud, including their DevOps tools, and can integrate with existing enterprise on-premises security, or a widely distributed DevOps process.
The use of IAM within DevOps and production will certainly backfill into enterprises as they modernize their security approaches and technologies to align with the use of public clouds and DevOps. In many instances, the IAM will be provided as a service, back into the enterprise. This leads to the concept of the cloud-delivered IAM, which quickly leads to the concept of centralized identity management, which should be the foundation for DevOps security.
Test DevOps security
Once you recognize the need for security that is systemic to your DevOps systems and implemented the technology that has the potential to get you there, how do you ensure that it’s working correctly?
Auditing, as mentioned earlier, is one way. Another is to do penetration testing on the DevOps and production systems.
Penetration testing for DevOps servers and tools is much more complex to execute than it is for production application and data storage, because you’re simulating attacks on multiple targets. The good news is that you can apply any automated testing tools that you’ve leveraged for system penetration testing in the past.
Play the long game
Creating a long-term strategy for DevOps security is more about people and processes than it is about technology. I suggest the following steps:
- Arm your developers with the knowledge they need to become security-aware. This usually diverges from how they previously handled security, and the focus should be on securing the DevOps automation systems, as well as the production application. Make security systemic to everything they build.
- Make sure your developers have the tools they need to build secure systems, as well as keep your DevOps systems secure. While the tool section process is a book unto itself, security approaches and security technology should be limited to identity-based systems that span most of the systems under management. This is not just about securing DevOps, else the resulting security solution would still be vulnerable.
- Set up monitoring and metrics to determine the effectiveness of your DevOps security. This means proactively looking for threats and responding accordingly.
- Test the security several times a year to ensure that items were not missed. Developers should participate in this process and actively manage DevOps security.
Developers are key
DevOps and the cloud are changing the game as to what business can expect from IT. Where applications once took months — sometimes years — to build, they can now take days or hours.
As with any movement to a technology that provides better services to the business, there is a tendency to forget about services inside and around these systems that will provide the security levels these modern distributed systems require. Security must be considered along with all things that make up our DevOps solution.
Moving forward, enterprises need to work more closely with developers, since they are becoming the single point where security can be addressed. Developers hold the most power to fix issues with security, in both production and DevOps systems. This has to come with a great deal of training, as well as support from the IT leadership. Indeed, now is the time to splurge on both training and investing in DevOps technology.
Security can no longer be an afterthought. Consider the importance of locking down data and applications for the Global 2000 and government systems. Bolt-on solutions are a thing of the past. Security is something you build, not something you do. If everyone takes their share of responsibility for security, you will be prepared.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
