What Steps Do I Take to Shift Left in Security?

Question: What does it mean to shift left in security? What steps do I take to start?

Vishal Jain, Co-Founder and CTO at Valtix: Shift left in security should go deeper than just code.

Security has always been an afterthought and was often improved only in reaction to a vulnerability or incident. With app developers shifting many late-cycle disciplines left or earlier in the cycle, security has benefited. Developers now test and scan code earlier, deploying many more secure applications; proactive processes reduce risk by creating robust applications that are less expensive to maintain and secure over time.

However, we are constantly reminded that there is no such thing as an invulnerable application. Log4j is a perfect example. You have ubiquitous code that turns into a severity 10 vulnerability. Even with secure development practices, many organizations are still grappling with the impact of the Log4j vulnerability. This highlights another important aspect of shifting security left: depth.

If we assume that there is no such thing as an invulnerable application, then we acknowledge the need for defenses that work outside of the app. And while there are many ways to deploy such defenses (network-based, agent-based, etc.), they all have one thing in common: It’s much easier and cheaper to put them in place if we shift left. What does that mean for an organization? It means deploying these controls, the policies using as-code, and constructs like Terraform. In other words, think about, plan, and build these layered defenses when planning and building the app, and you’ll skip the scramble when your app becomes vulnerable for a time (i.e., when the next Log4j hits).

These controls are not new, conceptually, but can be implemented in a variety of ways. In layman’s terms, we should manage who we are talking to, how we are speaking, and what we are talking about. In other words, these controls (defenses) work outside the app and might look at:

• Who: Controls that look at identification and authentication of users, what organizations they come from, and what countries their traffic originates from. These access controls might go deeper and include various segmentation schemes.
• How: Controls that limit the methods and protocols that access the application, and the kinds of trustworthy/untrustworthy spaces (e.g., unregulated service accessing a compliance-impacted application or service).
• What: Controls that look at the content of the conversation — whether sensitive/confidential information and data that indicates a threat or attack at any level (e.g., network, app).

Organizations react to vulnerable applications by deploying web application firewall (WAF) solutions, installing endpoint protection, and monitoring logs for cyberattacks. Where these defensive capabilities should have already been in place, the app remains vulnerable, and time is spent managing the risk instead of improving processes that secure it. Organizations need to make a hard shift-left on the proactive security processes they need to secure their app.

The practical advice is to think about the depth of your security at each layer of the application’s stack. As you shift security left, with depth, you’ll have a better, more secure application.