19. Secured DevOps (SecDevOps) – Privileged Attack Vectors: Building Effective Cyber-Defense Strategies to Protect Organizations

© Morey J. Haber 2020
M. J. HaberPrivileged Attack Vectorshttps://doi.org/10.1007/978-1-4842-5914-6_19

19. Secured DevOps (SecDevOps)

Morey J. Haber1 
(1)
Heathrow, FL, USA
 
DevOps is a blending of software development and operations, and a set of automated practices to condense release cycles across the life cycle of software development. SecDevOps (also referred to as SDevOps or DevSecOps) extends the methodology by integrating security best practices into the development, quality assurance, and deployment of software in this life cycle. DevOps automation tools use privileged credentials like any application-to-application solution, but security is, unfortunately, too often an afterthought. Consider the following DevOps security risks:
  • Malicious insiders can leverage excessive privileges or shared secrets to compromise code.

  • Vulnerabilities, misconfigurations, and other weaknesses in containers can open the door to security compromises.

  • Insecure code, hard-coded passwords, and other privilege exposures can lead to external attacks.

  • Scripts or vulnerabilities in CI (continuous integration) and CD (continuous deliver or continuous deployment) tools, such as Ansible, Chef, or Puppet, could deploy malware or sabotage code.

  • Automation to move and test code requires credentials to cross network zones—a compromise in the process can be leveraged for lateral movement by a threat actor.

While it is clear that security needs to be built into DevOps, how do you do so without hampering speed, agility, and becoming a victim of the observer effect? As organizations continue to adopt more Agile development methodologies that require extensive integration and automation across operational tools, they often find that it becomes very difficult to effectively and securely manage the credentials required to support these end-to-end processes. A typical DevOps process to automate, QA, and deploy code builds may include the following:
  • Operate with service accounts that run various services (TFS, Builds, SQL).

  • Scheduled tasks and automation (custom scripts, Git and GitHub, Jenkins, Puppet, and others).

  • Leverage third-party services (SMTP, cloud services, SSH, etc.) to provide status, notifications, and move software.

  • Interact with certificates for SSL websites, automated code signing, and other processes that have security wrappers.

All these technologies that integrate and automate application development and deployment into a more streamlined process require credentials and have no identities since they are automated. In some cases, these credentials may be stored and shared in scripts, code, and configuration files. The risks of storing, sharing, and infrequently changing credentials used to automate the DevOps processes make them susceptible to hacking and misuse, especially if they are clear text. This entire DevOps life cycle, secured with PAM, is illustrated in Figure 19-1.
Figure 19-1

Typical SecDevOps (DevOps) Life Cycle with Privileged Access Management

To reduce these risks, organizations should look to expand their privileged access management initiatives and implement phases that include the following:
  1. 1.

    Eliminating hard-coded credentials in code (compiled), scripts, and service accounts. Most enterprise password management and secret storage vendors include service account and password APIs that can be implemented to address these items.

     
  2. 2.

    Implement a remote access solution with session monitoring to control when developers can access production servers. DevOps methodologies often require the pushing of code, compilation, and integration of postcompile workflows. The goal is to have developers safely and easily execute critical workflows, but without having direct access to the systems themselves. Implementing a jump host based on remote access technology makes this possible by controlling the secure connection into your environment by administrators, automation jobs, or developers.

     
  3. 3.

    Implementing the concept of least privilege across the application environment. Do the developers, development tools, or development processes need to have administrator or root access to the systems and databases supporting the application environment? A process should be developed so they should not. Implementing least privilege would ensure that these developers and processes only have the privileges that they need to support their workflow in the end-to-end DevOps process. In addition, augmenting least privilege enforcement with session recording and keystroke logging would also help to identify compromised account activity and risks associated with privilege abuse and misuse.

     
  4. 4.

    Introduce application control into the DevOps process. This can be done by digital signature, source location, or other reputation services. The goal is to ensure that only authorized scripts and binaries are executed in the DevOps process and the malicious injection of malware will be denied execution due to the lack of reputational confidence for the program (whitelisting).

     
  5. 5.

    To reduce the complexity of creating and managing local accounts across non-Windows systems in a dynamic cloud environment, designers should investigate methods to consolidate and centralize accounts or dynamic secrets and manage them using a secure secret store. Storage, retrieval, and processing is then available via a secure API for DevOps automation.

     

Finally, organizations should examine solutions to proactively protect containers and microservices associated with enterprise applications. This becomes a high priority when implementing a new zero trust architecture with DevOps (covered in Chapter 22). And, as organizations transform their traditional applications to the cloud, they should consider how to mature the security basics by embracing SecDevOps over DevOps to make security an equal process in the workflow. Finally, embrace vulnerability scanning and configuration hardening assessments to continuously prove the workflow is secure and free from potential exploitation. This should literally be just another automated step in your SecDevOps process.

Moving all your development and applications to the cloud can be scary. Automating compilation, QA testing, and even deployment can be even scarier if there is no visibility or security in the process. Many of the controls that security professionals take for granted have alternative approaches when embracing DevOps and should not be ignored. The key to making this work for your organization is privileged access management and making it a foundation to protect the entire automation process!