DevOps security privacy and compliance

The series so far:

A DevOps approach to application delivery offers a number of advantages over traditional methodologies, most notably faster and more efficient deployments, yet there’s nothing inherent in DevOps that promises more secure delivery or better protection for the applications and their data. In fact, DevOps can potentially lead to greater risks if security is not integrated into the development process right from the start. In today’s word of escalating cyberattacks and increased privacy regulations, security should be as much a part of application delivery as continuous testing and ongoing integration. Anything less could put your entire organization at risk.

DevOps Security Challenges

Cyberattacks are on the rise, and they’re becoming more sophisticated every day. If data is compromised, the consequences can have far-reaching implications, not only to the bottom line, but also to an organization’s long-term reputation.

Hackers know where to find security holes, how to exploit them, and what rewards they might be able to reap. They also recognize the opportunities that can result from accelerating software delivery without taking special care to protect applications and their data. Development teams that implement DevOps methodologies need to be particularly vigilant to guard against the many security challenges that come with delivering applications at a high velocity.

One of the biggest hurdles to security in a DevOps environment is the failure to factor in security right from the start—when planning and designing the application. Instead, security is treated as an afterthought, a clean-up operation, a reactive process separate from the primary development effort, resulting in slower application delivery or applications being released before they’ve been fully vetted.

Part of the reason for this disconnect is that traditional methods for ensuring application and data security do not fit easily within DevOps processes and, in fact, can inhibit operations. In addition, development and security teams often assume that, even with DevOps, it’s business as usual when it came to security, with the two teams operating independently of each other, often without coordinating efforts. The DevOps team will deliver the application, and the security team will identify and address any security issues, kicking the application back to the developers if it becomes necessary.

Unlike development and operations, where efforts merge together in a more organic fashion, development efforts can often seem at odds with the time-consuming processes that come with ensuring application security. On some DevOps teams, there can be a cultural resistance to security for fear it will slow down application delivery, an attitude often coupled with a general resistance to changing the way security is traditionally handled.

At the same time, DevOps teams are under incredible pressure to deliver application updates as fast and as frequently as possible, with upper management demanding that nothing slow down operations. Many believe that addressing security issues early in the development process will throw a roadblock in the way of their efforts.

In some organizations, there’s also uncertainty around who’s responsible for which aspects of security, especially if there’s no established security team. At the same time, some DevOps team members might lack adequate training in security, leaving them ill-equipped to deal with today’s increasingly sophisticated threats.

On top of everything else, a team might utilize risky application technologies without fully addressing potential risks. For example, developers might incorporate newly released open-source code, expose application programming interfaces (APIs) that are not fully secure, or deploy containers without proper controls. They might also introduce risks into the code through poor practices or human error. Without formal security checks in place, those risks can go unnoticed until well into the development process or until the deployed application comes under attack.

Compliance and privacy

Discussions around application security must inevitably include issues related to compliance and privacy. Stricter regulations, increased liabilities, and heightened public awareness mean that protecting personally identifiable information (PII) is no longer a luxury, but rather a requirement and priority. If your application lacks the security necessary to protect PII, your organization risks steep fines, costly litigation, and a violation of public trust, from which you might never recover.

To make matters worse, regulations can vary significantly from one region to the next, adding to the complexity of ensuring compliance throughout the data’s lifetime. And some of those regulations can have far reaching implications. For example, the General Data Protection Regulation (GDPR) went into effect in the European Union (EU) in May 2018, and one year later, the industry is only now starting to feel its full impact.

In that time, there’s been a massive increase in the number of reported data breaches. Prior to that, the EU had no single mechanism to support notifications, and it’s believed that many breaches went unacknowledged. But much has changed with the GDPR, which requires organizations to report breaches within 72 hours of being discovered. In addition, the regulation more clearly defines what constitutes protected data, provides individual users with greater control over their data, and regulates how organizations can use that data.

Organizations that fail to comply with the GDPR can face stiff penalties—up to €20 million or 4% of their worldwide annual revenue of the prior financial year, whichever is higher. Google, for example, was fined €50 million in January 2019 for GDPR violations, representing the majority of fines collected in the first year of GDPR enactment.

Compliance laws, particularly the GDPR, can also cause a butterfly effect, which refers to the law’s wider impact across the globe. One way this is being felt is in the enactment of other regional laws that take their cue from the GDPR in defining user protections and corporate responsibilities. The GDPR can also impact organizations outside the EU that do business either directly or indirectly with the EU, affecting their operations, workloads, and data protection strategies, wherever that data resides.

Organizations that face compliance laws in multiple regions might choose to adhere to the strictest requirements for all their data in order to ensure compliance, so if the GDPR represents the severest of the laws, the organization might follow those standards for all PII, wherever it resides. For development teams, this means ensuring that data is protected during all phases of the DevOps process, and the best way to do that is to build security into the application delivery pipeline right from the start.

Incorporating security into DevOps

A secure DevOps environment incorporates the tools and processes necessary to protect the application and its data at every stage of the operation. Security starts with the planning and design phases and continues through the entire application lifecycle, baked into the continuous integration and delivery processes. In this sense, security merges with development and operations to create a cohesive three-pronged approach to application delivery, as shown in Figure 1.

DevOps Security, Privacy, and Compliance

Figure 1. Incorporating security into the DevOps process

Secure DevOps calls for a shift left in thinking that pushes security to the beginning of the application delivery pipeline, rather than dangling it out at the end, where it can be the most disruptive to application delivery. Instead, security is built into the planning, development, testing, deployment, and operation phases.

As with other DevOps processes, the goal is to automate security wherever possible, using testing and monitoring to ensure the proper implementation of comprehensive protection policies. In this way, potential risks can be better identified and mitigated early in the development process, while ensuring the continued velocity of the DevOps process.

Implementing secure DevOps starts with a change in mindset toward security and its role in application delivery. Critical to this attitude are support and buy-in from upper management and other stakeholders. Secure DevOps calls for open collaboration, greater transparency, and a shared set of objectives, along with the appropriate use of automation, proper tooling, and advanced application technologies such as infrastructure-as-code.

Secure DevOps, sometimes referred to as DevSecOps, is as much a process as a philosophy, one that sees security as a shared responsibility by everyone involved in application delivery. DevSecOps bridges the gap between development and security teams, helping to reduce the contention that can sometimes occur with traditional approaches to security.

By embedding security processes directly into the application delivery pipeline, DevSecOps offers early and continuous risk management through testing and monitoring, which provide in-depth insights into possible vulnerabilities.

Secure DevOps can also promote a culture of security, encouraging team members to be mindful of the importance of data and application protection at all times. With DevSecOps, developers are more likely to consider security when planning and building applications, QA professionals are more likely to take security risks into account when testing applications, and operation specialists are more likely to adhere to security best practices when deploying application infrastructures.

DevSecOps also leads to more secure and compliant applications because continuous testing and monitoring are integrated into the pipeline at a granular level, making the process more efficient at identifying and limiting threats and compliance violations. With DevSecOps, security becomes a natural part of the application design and fully integrated into the entire delivery process.

Secure DevOps can also make application delivery faster and, as a result, cheaper. Security flaws identified early in the design and development cycles can be addressed much more efficiently than if identified later in the process. As with any bugs, the sooner you find security issues, the quicker and easier they are to fix.

The DevSecOps approach also makes it possible for teams to respond more quickly to changing requirements and circumstances because security is baked in from the start, rather than ladled on top of the application at the end. This integration can also translate to a better user experience, in part because of security is built in, but also because feature updates and application fixes get to users faster.

Implementing secure DevOps

The logistics of integrating security in DevOps will vary from one team to the next, but most teams will follow several basic practices, some of which they might have already incorporated into their infrastructures. For example, in a DevSecOps environment, all source code should be stored in a secure version control repository, leveraging such technologies as encryption and digital signing.

The secure DevOps team should also practice the principle of least privilege so that only authorized individuals can access system resources, with access specific to their job roles. In addition, developers should work with code in small chunks so it’s easier to identify vulnerabilities, and all code should undergo peer reviews, including any scripts used to build infrastructure or deploy applications. The code reviews should look specifically for security risks, compliance violations, and adherence to best security practices.

As with DevOps itself, automation is key to successfully implementing DevSecOps, which requires tools that can seamlessly integrate into the continuous integration and delivery processes. For example, an organization might use Puppet for its automation framework and use Splunk in conjunction with Puppet to provide the analysis necessary to determine when a configuration goes out of compliance. To provide masked copies of databases for development and testing, organizations might use an automated solution like SQL Provision.

An organization might also use a monitoring tool such as WhiteSource, which detects open source components in the code and alerts team members to security risks and software bugs. There are plenty of other tools out there as well, which can help address security throughout all phases of application delivery—and more tools are emerging every day.

Continuous testing is a critical component of automating security, and there are many types of tests that can be performed. For example, DevOps teams might use static application security testing (SAST) to automatically analyze code for security vulnerabilities, without running the application. They might also use dynamic application security testing (DAST) to analyze the application for vulnerabilities when it’s running. Teams might also utilize penetration tests, threat investigations, vulnerability assessments, data flow analytics, and numerous other strategies to help ensure security and compliance.

Just as important as testing is continuous monitoring, which automatically tracks security-related metrics throughout the application delivery lifecycle. The collected information should reflect a wide range of information for identifying security issues. It should also include a system for alerting team members when issues are discovered, such as when code fails a compliance test. In addition, the monitoring solution should offer systemwide information that provides team members with a security overview as well as specifics that might be required for a security or compliance audit.