Since the beginning of modern computing, security has largely been divorced from software development. Recent vulnerability research confirms this. Consider that over the past five years, out of all published vulnerabilities, 76% were from applications. Given this radical shift in attacker focus, it’s time to embed security with development. The best way to get this done is to implement a shift-left security strategy.
Defining shift-left security
In its most simple terms, “shift left” security is moving security to the earliest possible point in the development process. Modern CI/CD typically involves an eight-step process as shown in Figure 1 below. Many security teams only become involved in the concluding steps of operations and monitoring. Consider that shift-left security is good for reducing not only cyber risk but also cost. The System Sciences Institute at IBM found that addressing security issues in design was six times cheaper than during implementation. The same study also found that addressing security issues during testing could be 15 times costlier.
Being intentional about embedding security in each of these steps starts with a clearly defined strategy.
Figure 1: CI/CD
Step 1: Define your shift-left security strategy
The first step of any journey is to define where you intend to go. Do not underestimate the power of a concisely (ideally one-page) written strategy document. It is critical to define what shift-left means in your organization. This is about painting the most vivid picture possible for your teams so they know what success looks like. Key items to include in this document are vision, ownership/responsibility, milestones, and metrics. Expect the strategy document to mature over time and don’t spend too much time trying to perfect it. Iteration over time is essential.
Step 2: Understand where and how software is created in your organization
Perhaps one of the most challenging aspects of shifting security left is first getting a handle on how and where software is created in your organization. Depending on the size of your company, this could run the gamut from straightforward to extremely challenging. This step is significant because the end result is what allows the security team to understand where they can actually move security closer to development. Large organizations that have not undertaken this process will likely spend a few months digging and taking development teams out to lunch (food always seems to work) when geography permits. Oftentimes, development is outsourced to multiple vendors, which will require additional work and sometimes contract reviews. Small and medium-sized organizations will find this step relatively straightforward but equally rewarding.
The goal of this step is to first look organization-wide and document the overall flow of software in your company. Medium to large organizations will want to start at the macro level and then drill into individual business units. It is highly likely that each business unit will have its own software development process and tools. Key items to identify in this phase include who is developing code (people), how it flows from development laptops to production (process), and which systems they are using to enable the process (technology). This may also be referred to as the CI/CD toolchain. Undoubtedly, much of your software development is being done in the public cloud.
Step 3: Identify and implement security quality guardrails
Quality assurance has always been part of the software development lifecycle. However, software quality has not historically included security. This must change, and the work done in the previous steps will arm you to do this. Every step of the software development process is an opportunity to give feedback and look for security issues. The most effective security teams start small. They arm development teams with simple and effective tools that become part of the daily development routine. One such tool was recently open-sourced by Palo Alto Networks, which means it is free to use.
Step 4: Assess and continuously train development teams in secure coding
Developers clearly know how to code, but do they know how to do it securely? Part of your journey to shifting security left is to ensure that those who do the majority of your coding create secure code in the first place. This is difficult to do if you have no objective measure of where their skills stand today and no plan to improve them continually over time. Given that in one survey, 19% of developers said they were unfamiliar with the OWASP Top 10, this is an area that should not be overlooked. Further underscoring this point was a recent survey published by DevOps service provider GitLab, which found that 70% of programmers are expected to write secure code, but only 25% think their organization’s security practices are “good.” If only 25% of developers feel this way, security teams have a lot of work to do in this area.
What shift-left security looks like
Let’s look at two scenarios where we’ve simplified development into build, deploy, and run phases. In Scenario No. 1, development starts without security. Software quality is only checked during runtime. This often results in an uneasy conversation between security and development when vulnerabilities are found.
In Scenario No. 2, however, security teams have invested the time to understand the development process in their organization. They have also taken the time to embed security processes and tools in the CI/CD pipeline, resulting in automated security quality guardrails.
Conclusion
Utilizing the four steps above will put your organization on a solid path towards not only shifting security left but making security synonymous with development. As your organization moves towards shift left as part of its cloud journey, it’s critical that security controls be automated and API-driven. Palo Alto Networks Prisma empowers security teams to do exactly that by securing DevOps and your CI/CD pipeline.
The post 4 Practical Steps for ‘Shift Left’ Security appeared first on Palo Alto Networks Blog.