The SolarWinds Orion Attack was so impactful that the U.S. Department of Homeland Security (DHS) had to issue an emergency directive. The SolarWinds Orion platform is used by 400+ of the Fortune 500 and many U.S. government agencies. The attackers managed to inject malicious code in an Orion application library, which was then shared into customer instances through software updates. Attackers were then able to forge access tokens that allowed them to impersonate existing users on the network, including privileged accounts. It’s estimated that about 18,000 customers received the contaminated updates, and that several dozen got breached. Those affected include Microsoft, the U.S. Department of Homeland Security (DHS), and FireEye, a cyber security vendor.

The malicious updates were first distributed back in March, which means the list of companies and agencies impacted by this attack will undoubtedly grow. The reputation damage and financial impact still to come from this event will likely be extensive. Over the next few months, many organizations will be dissecting this incident in an effort to protect their own businesses from similar attacks. 

One key learning is the importance of DevSecOps. Let’s take a look at how this could have been avoided with more sophisticated and mature DevSecOps practices:

Behavior Analysis based Threat Detection

In this scenario a developer’s account is likely comprised and allowed the attacker to commit the code. If there was an abnormal behavior analysis in place to review access, they could have very likely detected when the attacker first logged in to the account. Signs such as an anomalous location, unusual timestamp, login attempts, or new IP address should have raised alarm bells with the appropriate stakeholders.

How Kaiburr can Help?

Kaiburr’s Abnormal Behavior Detection capability in its AIOps module can identify any new behaviors like a login at an odd time, no. of login attempts, no. of commits, IP addresses involved. Below are examples of abnormal behavior detection based on commits and release process performance –

Software Supply Chain Governance through Policy Automation

The attacker probably acted on a file that was rarely updated by developers. Had other developers been reviewing pull requests, they should have noticed a change to a generally static file and performed a brief review of the changes. A quick review of the modifications should have made it blatantly obvious the HTTP connections to a Command-and-Control server were malicious.

Having overall DevSecOps governance policies in place on peer review, security testing, thresholds, segregation of duties, pull requests, commits can help identify risks before they become issues and lead to security breaches. You need to both define these policies at an atomic level, automate the validation of these policies and have guardrails in place to stop release processes and alert stakeholders instantly.

How Kaiburr can Help?

DevSecOps and Compliance Policies are setup in Kaiburr to make sure appropriate Peer Reviews are in place with approved reviewers. Also to verify that pull requests are performed before merging to master. In addition, other policies like checking if SAST, DAST, OSS Testing, Image / Container Scan are performed and at the right threshold, segregation of duties, proper commits with messages, linking of commits to stories / requirements, necessary approvals, branching can be configured and validated for every build, deployment and release process using Kaiburr’s Rules Engine.

Here is a screen shot of policies around pull requests and other topics being automated in Kaiburr for a business application / initiative –

Kaiburr provides many of these policies out of the box and new policies specific to a particular organization can also be applied using the policy (rules) editor.

Effective Use of Static Application Security Testing (SAST)

Use of SAST in the build and deployment process will help detect the backdoor code. Some times vulnerabilities like this can slip through if there is too many backlog items to be resolved from prior SAST runs. It is important to be up to date with vulnerability remediation.

Also having guardrails in the CI-CD process to stop the process when SAST thresholds are not met is very important.

NIST 800-53 Cybersecurity Framework

Another key consideration to address the problem is the adoption and enforcement of security standards like NIST 800-53 Cybersecurity Framework that specifies application security standards. The new techniques that were added to NIST 800-53 enable groups to evaluate the security of software using interactive application security testing (IAST).

How Kaiburr can Help?

Kaiburr helps automate NIST 800-53 controls using its controls automation framework. Here is a sample of NIST 800-53 controls applied on AWS and Azure.

Kaiburr provides sophisticated DevSecOps workflow templates out of the box with extensive security testing included like SAST, DAST, Image Scan, Container Scan, Software Composition Analysis (OSS Scan) along with automated security and compliance policies and state gates to stop deployment and release processes when testing thresholds or policy requirements are not met.

Here is a sample DevSecOps template from Kaiburr with build (using Jenkins), Image Scan (using Prisma Cloud/Twistlock), SCA Scan (using Blackduck), SAST (using App Scan), Deployment with (Spinnaker) along with security and compliance policy automation using Kaiburr’s Rules Engine and stage gates for security testing thresholds and policy validation. These and many other DevSecOps templates provided by Kaiburr can be implemented with minimum effort from Developers and DevSecOps engineers.

Kaiburr simplifies the use of the industry standard open source and commercial DevSecOps tools and automation of the policies so you and your teams do not have to learn all these DevSecOps tools and best practices to achieve high degree of maturity. Also you can get to a maturity of 8 or 9 out of 10 with your DevSecOps process in weeks instead of months taken by most organizations today.

For companies impacted by the SolarWinds breach, it is undoubtedly frustrating to see how they could have potentially detected this vulnerability in the past nine months. For immediate risk remediation for affected organizations, please update your SolarWinds Orion software to the latest version and review the threat research post from FireEye, which outlines various mechanisms for detecting and preventing the attack.

Start applying mature DevSecOps processes including those mentioned above and avoid security breaches like the one with SolarWinds.

If you need help with your DevSecOps journey you may reach out to Kaiburr’s team at