Top 5 tips to prevent the SolarWinds Solorigate supply chain attack

Vendors in the security industry continue to investigate the supply chain Solorigate attack and its implications on vendors (like FireEye) and customers worldwide using the traditional kill chain approach (which brings a kind of nostalgia for when my team at Aorato – Tal Be’ery and Michael Dubinsky and I built this chart).

We, at Apiiro, think about this from a different perspective – how to identify this risky material code change and prevent it from being deployed in the first place.

Today, everyone knows that “Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win”(by John Lambert). So at apiiro, we built a graph from the beginning of time across changes, developer knowledge and behavior, business impact and more. We call it the Spacetime Graph™.

We are using AI on top of the graph to enforce adaptive risk-based governance rules on vendors and internal development teams’ code bases and to identify risky material changes before they become vulnerabilities. From code to cloud.

According to the Microsoft 365 Defender Research Team and Microsoft Threat Intelligence Center (MSTIC)

“The discreet malicious codes inserted into the DLL called a backdoor composed of almost 4,000 lines of code that allowed the threat actor behind the attack to operate unfettered in compromised networks.”

This is a material change!

Apiiro understands the history of all user stories, bugs, features, epics, and code changes – together with the knowledge, location, and behavior of all contributors (e.g., developers, product managers, QA, security architects) that are relevant throughout the development process and connect them to business risks. This is how we identify risky material changes

These are our top 5 tips:

1. Build an adaptive inventory of all your code components, controls, data, developer knowledge, locations, and behaviors across all of your products. For example: explore in seconds which products and which components (APIs, UI, Backend, Mobile, etc.) are using a specific library + who upgraded it + when + which developer changed the code + what’s his/her knowledge + where it is deployed, and more!
2. Identify the historical audit trail of all material changes for all code components. For example: filter in real-time across the history of all risky material changes in a specific library to learn the velocity and context
3. Automatically trigger contextual security processes (e.g., security design review, security code review, pen-testing, SAST, DAST) only for risky material changes in critical code components (e.g., critical business logic like money transfer). This will help you reduce the risk in a contextual manner
4. Create a unified risk view across all nodes in the graph for each commit, PR or release. This will help you make informed, risk-based decisions
5. Approve risky material changes only based on the unified risk view

Last but not least, I will quote Gartner

“Stop trying to remove all unknown vulnerabilities in custom code, which increases false positives. Instead, focus developers on those with the highest severity and confidence”

Source: Gartner. “12 Things to Get Right for Successful DevSecOps” By Analysts Neil MacDonald, Dale Gardner. 19 December 2019

We are here to share our knowledge with customers on how to implement these top 5 tips. Ping me with any questions!