Best practices to incorporate DevOps in enterprise security

It’s impossible to make an organization 100% impenetrable. You may have all the right security policies and tools. But, no matter how quickly you shore up your defenses, cybercriminals just keep getting faster.

To avoid becoming the next victim of a cyber attack, you just need to outrun the guy next to you. That’s what Forrester quipped in a recent blog post when commenting on the recent spate of ransomware attacks.

Your security posture isn’t only about you, but also your posture relative to other organizations. Because cybercriminals look for the most vulnerable targets, you need to be more secure than others, making you a less appealing target.

To be the best on the block, you need to look across your organization to see where the security gaps are. You must check security consistency across functions, business units, geographies, and applications. If some teams are following corporate security policies but others aren’t, you’ve left a window for a cybercriminal to enter.

Not bringing DevOps into the security fold means that application development is protected by only a loose patchwork of security practices

A dream target area for cybercriminals, one that cannot be overlooked in an enterprise security strategy, is DevOps. Running the risk of not bringing DevOps into the security fold means that application development will be protected by only a loose patchwork of untrackable, unenforceable security practices. Cybercriminals thrive in loose patchworks.

In this blog post, you’ll learn common DevOps processes that invite cyber attacks, and best practices to reduce DevOps security risk with Privileged Access Management (PAM).

What makes DevOps a cybersecurity target?

DevOps (short for development operations) is defined as a set of practices that automates processes between software development and IT teams so they can build, test, and release software faster and more reliably.

Industries including Retail and eCommerce, Software, Manufacturing, Financial Services, Healthcare, Telecommunications, and Transportation all leverage DevOps. According to Forrester Research, more than 50% of organizations, like Uber, Starbucks, Verizon, Amazon, BMW, Netflix, and CapitalOne, rely on DevOps techniques.

The speed and scale of DevOps requires security to keep pace

DevOps has a particularly risky attack surface that includes code, scripts, and tools. DevOps relies on automation, continuous improvement, and utilizing a microservice-based architecture to increase the speed of development. As a result, it involves a lot of non-human assets, application-to-application communication, and interactions with databases. The speed and scale of DevOps require security to keep pace: secrets must be created instantly, tracked incessantly, and retained securely, while also remaining available to the humans and machines that need them.

These requirements don’t always play well with corporate security policies.

DevOps often involves bad cyber habits

DevOps has unique needs, which often strain security goals. To increase the speed of development, DevOps organizations have adopted many bad habits. DevOps teams have learned how to sidestep security policies, specifically password and privilege management.

Centrify’s Tony Goulding has an insightful take on this evolution: “The Sec (Security) in DevSecOps is typically forced into the mix due to corporate policy or industry regulations. Most DevOps teams, however, consider PAM a blot on the landscape because it gets in the way. PAM aims, in part, to simplify and centralize credential management (often referred to as Application-to-Application Password Management or AAPM). DevOps perceives that (PAM) doesn’t fit the DevOps model that strives for speed and agility through automation.”

50% of developers don’t have enough time to spend on security

Recent surveys have confirmed what insiders already know: 50% of developers don’t have enough time to spend on security, and 53% of them believe that infosec policies and teams slow their work down. Rather than take the time to implement a security-forward approach to password management, they rely on manual methods which are impossible to scale.

DevOps groups may take shortcuts, such as:

• Hard-coded credentials. Without a tool to automatically generate credentials on demand, DevOps teams may manually generate them, then hardcode them into an app. While this solves the immediate need of granting access, it leaves behind a gaping security hole.
  
  
• Insecure storage of credentials. No centralized password management or central password vault leads to credentials being stored in third-party repositories and spreadsheets (stored in the cloud or locally, and usually not password protected). Recent security breaches, such as Uber accidentally exposing AWS credentials on GitHub, have taught us the danger of relying on unprotected repositories.
  
  
• Pairing autoscaling servers and services with secret management that can’t keep pace. The beauty of hosted applications is that as more capacity is needed, the applications can be set to scale up automatically. But, if autoscaling is paired with secret management that can’t scale up at the same rate, then either password management becomes the bottleneck, or the integrity of the system fails.
  
  
• Lack of encryption. Encryption can often slow down development as it requires advanced cryptographic engineering knowledge not all developers have. It’s also difficult for enterprises to test and confirm that encryption is implemented properly.
  
  
• Secrets management tailored to DevOps, but not tied into a centralized IT system. Secrets management works best when it’s universally applied, but some DevOps teams prefer to have their own system in place, one which is finely tuned to their needs, but often incompatible with what IT is using in the rest of the organization if IT is even aware the other system even exists.
  
  
• Ignoring security in the early stages of the dev lifecycle. Security needs to be considered throughout the software development lifecycle, from early requirements, through initial prototypes and beta releases. Bolting it on after the fact often leads to unintended gaps which sophisticated cybercriminals are only too ready to exploit.

Bottom line: PAM is often shunned because it’s complicated to deploy and manage, non-intuitive for modern workflows, and requires lots of manual care and feeding.

Use PAM for DevOps to turn a no-no into a yes-yes

Modern application security requires taking full ownership of all aspects of code, whether you wrote it or not.

IT must balance giving employees and contractors the autonomy to be productive while also implementing and enforcing consistent security policies. IT must retain overall oversight while still accommodating DevOps’ need to access disparate resources and develop new applications in a way that fosters collaboration, encourages speed and continuous delivery yet doesn’t sacrifice security.

Integrating automated security solutions into DevOps can have an immediate impact. According to CyberEdge Group’s 2021 Cyberthreat Defense Report, which surveyed over 1,200 DevSecOps practitioners:

• 45.8% deploy applications more quickly
• 47.2% deploy updates more quickly
• 38.5% reduce costs
• 38.3% reduce app security vulnerabilities

DevOps security solutions centralize and automate access controls to developer toolchains and underlying infrastructure, enhance application security, and enable logging and auditing of privileged activity.

When thoughtfully implemented, PAM for DevOps helps:

• Establish identity assurance. You can consolidate identities to minimize the attack surface, apply multi-factor authentication everywhere and control access through risk-based factors.
  
  
• Limit lateral movement. Security teams can establish access zones, grant access based on the use of trusted endpoints, apply conditional access controls, and minimize VPN access.
  
  
• Grant least, just-in-time privilege. In the same way as controlling broad access, you can automate the request for privilege elevation, grant just enough privilege, and move towards just-in-time privilege.
  
  
• Assure automation and agility. It’s critical to avoid manually establishing service accounts for each application. Automated secret management reduces friction in the DevOps workflow, automatically interacting with platforms and tools such as Jenkins, Kubernetes, Azure DevOps, Puppet, Terraform, CHEF, Ansible, AWS, Azure, and Google Cloud Platform.
  
  
• Pair high-velocity vault with autoscaling services. A high-velocity secrets management vault can support just-in-time access to resources, including toolchain support, integration with code, artifacts, applications, and other essential components. As detailed in the Kuppinger Cole Leadership Compass Report, you can use a DevOps vault to replace hard-coded credentials in apps to access other apps, databases, services, DevOps tools, and robotic process automation. It also supports the critical tasks of just-in-time provisioning and decommissioning.
  
  
• High availability (HA). The system you put in place is only effective if it’s up and running. Ensure it can be configured for high availability and be able to support server and service scalability.
  
  
• Audit everything. Monitor privileged sessions and analyze the risk of access requests in real-time. Receive alerts and notifications on abnormal user access behavior. Use ongoing audits and reporting to ensure compliance with service account governance.

Over 50% of organizations using DevOps will adopt PAM-based ‘secrets management’ products by 2021, rising rapidly from less than 10% in 2018, according to Gartner Research.