{{announcement.body}}
{{announcement.title}}

How to Establish Enterprise Requirements for DevOps

DZone 's Guide to

How to Establish Enterprise Requirements for DevOps

Sell your DevOps team on the idea of continuous security practices by ingraining it within their functioning DevOps process.

· DevOps Zone ·
Free Resource


Editor's Note: Part 3 of a 5 Part series providing practical guidance and insights to security leaders for securing DevOps environments. This series is based on insights from Global 1000 CISOs. This installment covers how to establish enterprise requirements for securing credentials and secrets in DevOps and cloud environments.


Privileged account and credential compromise is at the root of virtually every major cyber attack today. While most security teams have established enterprise requirements for securing privileged credentials in traditional IT systems such as Windows for human identities and applications, securing DevOps and cloud-based environments too often lags behind. As organizations accelerate digital transformation initiatives, these requirements must extend to DevOps, cloud, and non-human identities. The challenge becomes determining how the security team can help make this happen?

Developer and DevOps cultures are very different from security culture. To make security best practices a reality, enterprise security requirements must align with DevOps culture. If developers feel that the security requirements are slowing them down, expect them to resist adopting new measures to protect privileged accounts, credential, and secrets. So, make it easy for developers to adopt secure practices. If there is pushback on adding steps to existing processes, emphasize the operational efficiencies that can be achieved. For example, manually managing privileged credentials takes a lot of effort and puts the responsibility on the developer — offloading this work from the DevOps teams will free up their valuable time.

In this chapter of our CISO View Insights blog series, we'll explore four best practices for establishing enterprise requirements for securing credentials in modern environments with strong privileged access security. These recommendations are based on the real-world experiences of CISOs from Global 1000 organizations.

  1. Mandate centralized secrets management for DevOps and cloud. Implement a centralized secrets management system that acts as an intermediary between users (both human and non-human/machine identities) and the databases, resources and other tools and critical systems that need to be accessed. This helps keep your secrets secret, since users don’t ever see the actual credentials. For example, if a developer needs access to the cloud console, they authenticate to the secrets management system. The system verifies that they are authorized and provides access to the console without revealing the privileged credentials.

This centralized system should store all the secrets and credentials used by the developers and DevOps administrators, tools and applications in a tamper-proof vault. It should also provide strong, multi-layered security — from encryption and regular credential rotation to integration with multi-factor authentication (MFA). Additionally, monitoring and logging credential usage helps to instill user accountability. To help detect anomalies quickly, establish a baseline for normal usage patterns and provide each machine its own unique identity to more easily audit and monitor its access to secrets.

  1. Extend enterprise-level capabilities for auditing and monitoring. It is really important to have a complete picture of who has access to what, and to be able to audit and monitor access across your entire environment. You need to be able to answer questions like:
  • What are all the things "Sam" has access to across the enterprise?
  • Where are all the privileged credentials with access to the customer database? Who can access these credentials?
  • Which applications have access to the customer database? Why is Application X on the list?
  • "Mary" recently left the company. Have any of her credentials been used since then?
  • Are DevOps practitioners re-using privileged Windows passwords for other purposes?
  • This machine category typically accesses these three services (a, b, c), so why did it just interact with service "g"?

The centralized secrets management solution should be integrated with a core system of trust, for instance, using an LDAP server/Active Directory for authentication. Additionally, you need to have situational awareness when it comes to vulnerabilities, cyber threats and cybersecurity posture integration with controls assurance and analytics solutions like Security Information and Event Management (SIEM) and User and Entity Behavior Analytics (UEBA).

  1. Eliminate privileged credentials from DevOps tools and applications. It’s vital that you remove secrets from all DevOps tools, configuration files, scripts, and code and require that these secrets be retrieved, instead, from a secure vault. Make this a key priority and best practice. Because it will likely take time, this essential objective may need to be completed in stages. For instance, you could begin by requiring development of all new applications to adhere to this best practice.

Inadvertently including access keys and credentials in code committed to a repository is a common slip up, but it has led to multiple breaches and cryptocurrency mining exploits by attackers. To help ensure that developers cannot inadvertently commit code, configuration files or scripts with secrets to a code repository, secrets, cloud access keys and other sensitive credentials should never be included in code. These standards should be set for both code developed in-house and third-party code.

  1. Develop reusable code modules to provision secrets to applications. Security teams should collaborate closely with their DevOps counterparts to determine how secrets will be provisioned to applications based on application requirements and developer preference. Some may prefer API calls, where an application makes an API call to a secrets vault, which returns a secret to the application. Others may prefer secrets injection, where an intermediary program retrieves secrets and injects them into the application environment. To limit exposure and risk, it’s important to make sure that, when secrets are outside the vault, they are frequently rotated, ephemeral and not persistent. For example, with a memory-mapped file, the secret should be inaccessible when the process exits.

For more insights on bringing DevOps and security teams into alignment, download the full CISO View report, Protecting Privileged Access in DevOps and Cloud Environments, watch a short highlights video or tune into our on-demand webinar for a deeper dive. You can also visit our first blog post of the series for an overview.

Topics:
devops ,devops security ,enterprise security ,monitoring and auditing ,credentialing

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}