Embracing DevOps: What Security Teams Need to Know
September 25, 2018 | DevOps | Amy Burnis
We’ve all read about credentials exposed via GitHub and other repositories. It’s clear organizations have security blind spots in DevOps that need to be addressed. Developers want velocity and too often see security as “getting in the way.” We recently held a webinar, featuring special guest speaker Forrester Senior Analyst Chris Condo, to explore the challenges developers face and collaborative ways security teams can help. Following are some highlights from this presentation.
What Good is Speed Without Security?
Chris shared a story of an organization that releases code within five minutes – from checking it in, running it through an automated process then fully deploying it. This is becoming the norm as development teams feel the pressure to move faster. According to the Forrester Business Technographics Developer Survey 2018, the top priority for 40 percent of software development teams over the next 12 months relates to speed and automation. Additionally, 34 percent of software decision-makers say that introducing or expanding DevOps is a high or critical priority to create and improve customer-focused products faster and more efficiently.
If an organization releases code at breakneck speed and also inadvertently exposes credit card numbers, credentials or PII, what good is speed, really? Forrester’s research underscores this point, indicating that software vulnerabilities (exploits), web applications (SQL injection, cross-site scripting, remote file inclusion), and stolen credential use (logins, encryption keys) are the top three ways that external attacks are carried out.
The Security and Development Disconnect
Developers, IT operations staff and administrators require quick, easy workflow to do their jobs effectively. Therefore, they can’t be constrained by restrictive security policies that impede the velocity of the delivery pipeline. When it comes to working with these teams, Chris explained that security professionals must re-shape perspectives by shifting away from checklists and stop signs and focusing instead on educating tams about the potential negative impacts to the business – response/notification costs, employee productivity loss, lawsuits/settlements regulatory fines, additional security and audit requirements and brand recovery costs. When and how they convey this information to development teams is equally important. Once security teams can communicate these ramifications within the context of the business, they can begin a more effective dialogue about embedding security knowledge and best practices into the software development process.
How Security Teams Can Work within DevOps
Chris shared a number of best practices for putting security right in the middle of the DevOps “Venn diagram” of lean product development, continuous delivery and effective culture and organization including:
- Support product teams through education. One of the ways that development teams aim to gain traction is through integrated product teams, which are not only responsible for developing product features, but also with learning from their release and continuously improving processes. They follow a “You Write It, You Own It” mantra – which means they also own security. Security teams should play an advisory role to these teams, providing guidance and educating them on threats and attack vectors.
- Be part of product planning and design. During this initial phase, security teams should be heavily involved, asking questions and preemptively thinking through potential issues. Instead of prescribing fixes, they should advocate for proactive defense measures. This helps to ensure developers incorporate strong security into the whole product from the beginning – rather than bolting it on at the end.
- Advise development for best practices regarding static code analysis. Security teams should also play a role in creating security checklists that development teams can create automation against. For example, if an organization needs to ensure that there are no hard-coded credentials in the software, or that it is following cross-site scripting, the security team should be front and center, offering recommendations on how to introduce scanning tools that can be part of the check-in process.
- Define best practices for automated open source screening. Similarly, security teams should guide development on best practices for automating open source components, along with license management and patching schedules. By educating the development team on how to incorporate these tools directly into their software development process, it becomes natural for users to choose the right version of a particular piece of open source code – they know the lineage of that code, they know that its been patched and they receive updates automatically when the code needs to be patched.
- Provide guidance for secure micro-service architectures. Though micro-service architectures help streamline processes and break down code, they also expand the attack surface significantly by introducing APIs and loose linkages between critical components. It’s essential that development and operational communities understand how API gateways can secure traffic flow and how proper network segmentation can isolate critical components, so they can make informed decisions around producing and delivering high-performing and highly secure micro-service architectures.
- Advise infrastructure and operations (I&O) teams to create secure environments using Infrastructure-as-Code (IaC) that is repeatable and verifiable. It’s security’s job to uncover wasteful processes and advise I&O on areas ripe for automation — then provide counsel on available tools that will allow them to embed security rules right into the infrastructure definition language that gets checked in, version controlled and pushed through an automation engine. It’s also security’s responsibility to advise I&O teams on best practices for creating secure containers at each layer: Container orchestration, container network segmentation, container user access, the host operating system and the container run-time environment
- Work with development to create secure DevOps platforms. By providing education on what types of best practices development teams should be implementing, what kinds of environments they need to be building and what types of issues they need to look out for, security can help development streamline vendor and product evaluations. And with this guidance and enhanced visibility into applications’ access points and code, development teams can more confidently answer key questions such as, “Are we releasing the code that we intend to release? And, is there anything extra in here that we shouldn’t be releasing?”
Security education is critical in bridging the security-development gap, but remember, education is a two-way street. Security professionals should take the time to learn about DevOps tools and their unique security profiles. For example, some tools require hard-coded credentials with privileged accounts. Instead of simply shutting them down, find temporary solutions via isolation to maintain velocity. Security teams should actively contribute to new DevOps tool-chain research to collaboratively find solutions that can provide both speed and security.
Bottom line: As a security professional, the best way to embed yourself fully in the DevOps process is to take on a trusted service provider role, encouraging teams to engage with you regularly to review designs, tooling and emerging threats. Be a team player, and it won’t be long before your insights are not only recognized but also actively sought out.