Wednesday, December 25, 2024

Fix the developers vs. security conflict by shifting further…

Share


Prolonged tension between developers and security teams can undermine the efficacy of cloud security. Security teams resent it when developers ignore their guidelines, forcing them to patch vulnerabilities after apps are in production. Developers want security teams to plug gaps and stay off their backs — they have frequent deadlines to meet. Collaboration between them suffers. Not surprisingly, getting these teams to operate from the same playbook is easier said than done.

CISOs and developers know this all too well. Nearly two in three CISOs and developers agree that “a lack of communication and collaboration between their teams is a problem when it comes to implementing better software supply chain security,” according to a software security study by Chainguard and the Harris Poll. The December 2023 study also found that tooling is another source of tension between these teams: “73% of developers agree that the work/tools their security team requires them to use interfere with their productivity and innovation.”‍

Yet, defusing the tension between these teams doesn’t require a federal mediator. The turning point begins when platform teams remove one of the biggest obstacles: conflicting toolchains that cause inefficiencies and introduce vulnerabilities that result in costly errors. A lack of automation also hinders organizations from managing their cloud resources efficiently.

Getting dev and sec to work cleanly together demands tooling changes associated with cloud migration, including automation for scale and provisioning dynamic infrastructure. Unfortunately, many toolchains (especially in cybersecurity) were built for the static, on-prem era of infrastructure. Lacking automation, platform teams can’t easily switch from “static” infrastructure to “dynamic” infrastructure with these outdated toolsets.

Platform teams play an important, if underappreciated, role in solving this impasse. This post recommends field-tested tools and products that establish a secure, golden developer path — reducing friction and satisfying both teams’ objectives.

»Your “shift-left” needs a platform

“Maybe they don’t want to think about infosec. They’re worried about their software architecture. They don’t want to think about CMDB [a configuration management database]. Patching compliance, forget it. They just want to go fast.”

— Chad Prey, “Terraform for the Rest of Us: A Petco Ops Case Study”

The “shift-left” movement, an idea that was coined decades ago around testing, was an attempt to fix friction between teams when security and quality assurance were being tested at the end of an application’s development lifecycle. The general idea was to push testing and other aspects of security and QA review to the early and middle stages of development, not just at the end, when reviews would find multiple issues and send an app back into redesign stages.

During the emergence of DevOps philosophies, the shift-left movement went hand-in-hand with cross-team skilling, where managers wanted to turn developers and IT pros into experts in everything from development to operations (and sometimes cybersecurity). For companies that couldn’t afford the top 1% of engineering talent, this movement fell flat on its face.

Trying to get all developers to become well-versed in cybersecurity so that those controls and strategies can be implemented in the design phase is unrealistic — it’s the wrong way to shift-left.

Instead of focusing fully on shifting security left from a culture or skilling perspective, it needs to be done with tools, because software eats culture for breakfast. Think of it as shifting further left.

It’s “further” left because it’s there before the developer even starts coding. Secure designs are baked-into the various templates developers use to start a project in CI/CD and in their infrastructure platform. When organizations deploy a platform-based shift-left approach that leverages APIs, automated checks, self-service tooling, and guardrails like secure modules and policy as code, they avoid the bottlenecks created by development teams submitting changes for manual review by security, Ops, or compliance teams.

At the same time, security teams can be confident knowing they have embedded required policies and best practices before code and applications make it to production.** There are fewer tickets for them!**

Developers will like the fact that they can just code and not have to know a lot about cybersecurity best practices, or keep up with changing company compliance and security policies. As long as the guardrails don’t become a “golden cage” rather than facilitating a golden path, developers should work much faster. Eventually platform teams want the developer experience for security to feel invisible, removing as many manual touchpoints as possible. For example, with the right secrets management solution, developers should barely realize they’re managing secrets in their workflow.

»

DevSecOps partly because it “[r]educes friction between the development, operation, and security teams in order to maintain the speed and agility needed to support the organization’s mission while taking advantage of modern and innovative technology.”

While NIST continues to identify software supply chain and DevOps security practices, many organizations now embrace DevSecOps but haven’t deployed “modern and innovative technology” to improve their cloud security and reduce the stress between their infrastructure and development teams.

Today, a modern platform must prioritize cloud security and the developer experience, establishing a secure and consistent workflow that supports all teams in the delivery pipeline. Platform teams should pick tools and products that excel at these functions:

  • Version control tooling
  • Static and dynamic scanning tools
  • Secrets management platforms
  • Secret scanning tools
  • Infrastructure as code provisioning platforms with built-in policies as code engines
  • Secure remote access tools
  • Image and module lifecycle management

In particular, platform teams want to focus on the lifecycles that matter most to developers and security teams:

  • Infrastructure Lifecycle Management (ILM): A systematic and repeatable approach to creating, securing, and maintaining infrastructure.
  • Security Lifecycle Management (SLM): A systematic way for organizations to manage their most sensitive data, especially secrets/credentials, from creation to expiration or revocation. This also includes having a platform for the management of remote access sessions.

While executives and managers can take years shopping for dozens of products to build holistic ILM and SLM solutions, or even longer trying to manage initiatives to roll their own toolchains, the savvy leaders are focused on consolidating down to fewer tools with a small number of trusted partner vendors (we know that half of CISOs are asking for tool consolidation right now).

HashiCorp is one of those trusted ILM and SLM partners to thousands of customers with a consolidated solution: The Infrastructure Cloud. It includes the world’s most popular infrastructure as code provisioner, HashiCorp Terraform, and the gold standard of secrets management platforms, HashiCorp Vault. Along with other products, organizations can deploy Terraform, Vault, and other components of the Infrastructure Cloud as on-prem, self-managed software, or as managed services on the HashiCorp Cloud Platform (HCP).

»What the right SLM and ILM tools can do

Modern ILM is all about empowering developers to provision cloud and on-prem resources quickly without a burdensome, ticket-heavy or review-heavy workflow. Platform teams avoid these problems by providing a standardized shared service with curated self-service workflows, tools, and templates for developers that propagate best practices for every deployment while automating secure practices and guardrails.

HCP Terraform and Terraform Enterprise support secure provisioning, enabling best practices including:

  1. Standardized workflows — Baking security fundamentals into the workflow with templates that empower even junior developers to become highly productive.

  2. Secure modules — Managing version control and provisioning becomes easier when you codify, store, version, and deprecate modules in one place.

  3. Policy as Code guardrails and gates — Automating the enforcement of identity and access management (IAM) controls, CIS benchmarks, proper infrastructure tagging, and the storage location of data (for GDPR compliance).

  4. Custom condition checks — Platform engineers can add ongoing security checks at all phases of the infrastructure lifecycle to detect insecure modules that might slip through other guardrails.

  5. Drift detection and continuous validation — Teams need a system to detect problems leading to outages, higher costs, and vulnerabilities.

  6. Observability — Teams need visibility into workspaces, a reporting component, and a clear audit trail for all changes.

“We have many developers who want to deploy apps on the cloud, but they aren’t familiar with all the different cloud service providers, or they might want to deploy their application on multiple clouds. By using modules, we can deploy standardized solutions across multiple clouds using a common syntax: HashiCorp Terraform [which uses HashiCorp configuration language (HCL)]. We’re able to bake in our security controls so our developers don’t have to go look at a long list of controls before they’re able to do anything in the cloud.”

— Itay Cohai, “Compliance at Scale: Hardened Terraform Modules at Morgan Stanley”

For modern SLM practices, secrets management is the core focus since compromised credentials are still the #1 cause of most breaches. It’s also the antidote to secret sprawl, where secrets such as passwords are kept in obvious, often unguarded places for attackers to find and exploit.

HashiCorp Vault makes implementing a scalable, secrets management program with solid governance, auditing, and security easy. The key is centralizing your management through one control plane.

Here are five best practices for a well-managed secrets management platform:

  1. Central secrets control plane — Reduces errors, speeds up debugging and auditing, and simplifies security management
  2. Access control lists — Limit lateral movement through your systems
  3. Dynamic or auto-rotated secrets — Temporary credentials that reduce the time of breach
  4. Encryption as a service — Prevents breaches and enables encrypted data during transit as a service
  5. Auditing — Better understanding of your security posture and breach detection

Canva, an online platform for visual communication and graphic design, sought to simplify secrets management for its developers using Vault:

“They’ll just get some sort of key with a click or two and then plug that key into their target client. The secrets management system should take care of issuing the secret to the correct client and integrate with a wide array of products and all the major cloud providers.”

—Moe Abbas, “Streamlining secrets management at Canva with HashiCorp Vault”

»

»Leveling up dev and sec collaboration

Misaligned priorities, mismatched tools, and inconsistent workflows are the precursors of friction between security and development teams. Prolonged problems between these teams elevate security and compliance risks and hinder development speed and time to market. Platform teams understand that the right tools can propel a cultural shift that reduces risk and cost while accelerating production.

Platform teams understand that an effective cloud security program eliminates friction, enables reproducibility, and establishes infrastructure automation. The Infrastructure Cloud helps organizations shift left, lifting the burden of implementing security requirements from development teams and removing many common friction points between security and dev teams.

Move fast and secure things by bridging the gap between developers and security teams: Read our white paper for more information on this topic.



Source link

Read more

Local News