Four Things Security Can Do to Keep Up with DevOps CI/CD

Source: securityboulevard.com

Editor’s Note: Part 4 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 Chief Information Security Officers (CISOs.) This installment covers how security teams can adapt processes for modern application testing.

With the promise of shorter development cycles more closely aligned with business objectives, organizations are embracing DevOps for everything from insurance customer service and banking applications to mobile check-in and loyalty apps. With the push to be fast, agile and accelerate digital transformation initiatives, DevOps is perfectly suited to deliver high-value applications that can be rapidly iterated and scaled. Yet, while DevOps is increasingly essential for today’s digital business, it exposes new privileged access security-related risks that security teams must address.

This is particularly true when it comes to Continuous Integration, Continuous Delivery (CI/CD). Using Continuous Integration (CI), development teams can merge code changes to a repository and automatically integrate it into builds multiple times a day. Continuous Delivery (CD) requires that code always be in a deployable state so that it can be deployed to production at any time at the touch of a button.

Traditionally, security teams could put up “gates” in the development process to check that the application met security requirements before it was delivered. But with CI/CD, these gates no longer fit the deployment model and security teams will need to rethink and update their processes.

In this chapter of our CISO View Insights blog series, we’ll explore four ways that security teams can evolve their processes to keep pace with continuous application delivery while upholding key privileged access security requirements. These recommendations are based on the real-world experiences of CISOs from Global 1000 organizations.

1. Integrate Automated Code Testing for Security Issues

Security teams should work to automate as much application testing as possible using a  combination of custom scripts and commercial services.

An automated enforcement engine can perform tasks such as scanning code for secrets before it is checked into a repository. Automatic scanning can identify vulnerabilities and malicious code within applications quickly, an especially important benefit when working at the speed of DevOps. It can also make sure that applications – including any third-party code modules – retrieve secrets correctly from a centralized, encrypted vault. By automating testing and enforcement, security teams can also ensure that passwords are not recorded in event logs.

1. Force Developers to Fix Security Issues with a “Break the Build” Approach

With automated testing, a test failure, gives security teams a new way to drive and influence developer behavior to uphold important cybersecurity requirements. A “break the build” approach forces developers to fix the security issues in their code, since, until the problems are fixed, the developers won’t be able to deliver their code module. This approach also puts pressure on the security teams to have effective test programs and, ideally, to be able to rapidly guide developers to what they need to do to fix their security issues.

With a “break the build” approach, risk scoring becomes integral to build automation tools, so that when the risk exceeds a certain threshold, the build will automatically break.

In addition to implementing “break the build,” security teams should continue looking for ways to check for security issues earlier in the process, such as on code check-in or merge. The goal should always to be to enforce application security policies as far left in the process as possible to mitigate the most risk.

1. Maintain Manual Testing and Red Team Exercises

While integrating automated testing is essential, it cannot stop there. Remember that attackers are creative and persistent, and will often find ways to bypass the issues that automatic security tests are designed to find.

To catch these increasingly sophisticated attackers and stop attacks before they impact business, organizations must adopt an attacker’s mindset. To do so, use a combination of automated static and dynamic testing, as well as manual penetration testing. When pentesting, security teams should test both the tools used to roll out the application and the application itself. Periodic Red Team exercises can also be very helpful in uncovering vulnerabilities, identifying areas of improvement and making risk-prioritized recommendations.

1. Consider Launching a Bug Bounty Program

Security teams can supercharge their ability to identify and address DevOps security risks and weaknesses by implementing a bug bounty program. With such a program, the company invites security researchers to find security issues, and pays a reward for issues found and confidentially reported.

Security researchers can find out, for example, if practitioners are embedding credentials in code or in DevOps tools, so that teams can quickly course-correct. The program can also help DevOps teams become more accountable for security. Furthermore, tracking the results can provide an ongoing visual record of security issues and their financial cost to the company.

Before launching a bug bounty program, it’s very important to set up a formal operating agreement between the organization and security researchers that establishes the expectation that the researchers will do no harm. As part of this, make sure executive leadership team understands the nature of the program and the norms of the security researcher community – and maintain transparency throughout the process.

Security needs to embed and integrate security processes into the automated CI/CD processes, such as with automated testing and break the build approaches. Additionally, security needs to step out of the box and set up processes to hunt down and identify the risks and vulnerabilities that “cannot happen.” This means using pen-testing, red teams, bug bounties and other creative approaches to find and address issues before attackers do.

Lastly, security should continue to collaborate with developers and remind that that developers and security professionals share responsibility for security. It’s important for developers to understand that what security wants is to help development teams ensure that the applications they deploy are secure.

For more insights on bringing DevOps culture and security teams into alignment to better secure today’s digital business, 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.

The post Four Things Security Can Do to Keep Up with DevOps CI/CD appeared first on CyberArk.