Time and again we have witnessed hackers use a software’s supply chain to take advantage of exposures and sneak into its systems and wreak havoc. There are many such instances where exposures have gone undetected for months or even years altogether. Most notably – The Solarwinds Orion attack (also called Solarwinds supply chain attack) that went undetected for 14 months from Sep. of 2019 through to Dec. of 2020.
Notable Hacks/ Attacks from the past
While it was initially reported that a stagerring 18,000 customers applied the Sunburst update, Solarwinds later corrected that only 100 companies were hacked. Among notable victims, 20% of the attack was on government agencies, including the US departments of health, treasury, and state. The remaining 80% of victims that were private corporations, included big players in their industry with their fair share of high-profile clients. The hack affected companies like Cisco, Intel, Deloitte, and Microsoft, as well as some medical institutions, hospitals, and universities.
While this is just one example, there are countless other organizations that have suffered because of vulnerabilities/ exposures in their software supply chain, specifically relating to software deployment/ software delivery. Target (2013), Equifax (2017), Log4J (2021), Kaseya (2021), and Codecov (2020), are some notable examples of CVEs arising from a lack of security measures in their software delivery chain.
If you are bewildered by the various terminologies/ concepts discussed thus far, then let me get down to the basics and clarify some of the terms/ concepts before we go further. This will help you relate to the rest of the contents of this blog.
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures.
Vulnerability is a weakness in a system – something that has the potential for being exploited. Vulnerabilities can allow attackers to run code, access system memory, install different types of malware and steal, destroy or modify sensitive data.
However, an Exposure is a known incident in which the vulnerability was acted upon. It is a mistake that gives an attacker access to a system or network.
What is a supply chain attack?
A Supply Chain Attack is a cyber-attack with an intention to damage an organization’s reputation by targeting the less secure elements in their software supply chain. Typically, a supply chain attack is carried out by targeting an organization’s (software) suppliers as a means to gain unauthorized access to that organization’s systems or data. They’re sometimes also called value chain or third-party software attacks.
Typically, supply chain attacks seek to gain access by implanting a backdoor into products, typically software, used by the target organizations. This allows the attackers to deliver automated patches or “trojanized” software updates that open the door for malware and other attacks. In the case of the Solarwinds hack, the attack was in the form of a routine software update.
Why should organizations put an effort into enhancing Security?
Besides the reasons and examples explained above, in most major breaches, the impact is never really restricted to the breached environment (that includes internal systems, employees, and its finances). The impact almost always extends to its clients/ customers. And what takes the biggest hit in such cases? Trust, branding and reputation! Which inturn disarms them from onboarding new and big enterprises, let alone retain the existing one’s.
It is estimated that 70% of business applications used by companies today are SaaS-based. It is also estimated that this SaaS adoption will grow to 85% by 2025. Another independent research by BetterCloud, states that a company with an employee count of 500 to 999, uses about 93 different SaaS applications, with that number rising to 177 for companies with over 1,000 employees.
From this, it is clear that we live in a world where organizations are inter-connected by the underlying software (or SaaS these days). So it is absolutely imperative that the software powering us in our day-to-day is secure and trust-worthy. But given how impressive and innovative contemporary Attack Vectors are, extra care should be given to fool-proof software delivery/ deployment. Look at the table below to understand the different attack vectors and the stage during when they are incubated.
The data from the above table coupled with the historical evidence of hacks all over the world clearly indicate that Threat Actors target the build and delivery/ deployment tools of the software supply chain in order to exploit vulnerabilities and exposures.
While software vulnerabilities can also be caused by factors such as coding errors, poor design, and the use of outdated or insecure software, the most prominent cause is the use of/ introduction of third-party libraries or components that have not been properly vetted for security.
So, how do you Secure your Software Delivery?
The answer is pretty simple. You need to leverage a tool that:
- Constantly monitors your deployment and tracks vulnerabilities
- Automatically assesses risks and enforces organization/ industry specific policies
- Integrates seamlessly with your existing DevOps & DevSecOps toolchain
- Enhances your overall security posture
In short, you need a Deployment Firewall!
Securing Software Delivery with OpsMx’s Deployment Firewall
As the name suggests, our Deployment Firewall is analogous to an actual Network Firewall. In short, it provides a gating mechanism for your existing CI/CD tools to prevent security vulnerabilities from going to staging or production. Being the last line of defense, the Deployment Firewall enforces Security, ensures Code Quality, and regulatory Compliance practices – all within the CI/CD platform.
The Deployment Firewall - what is it & how does it work?
The Deployment Firewall (an integral feature of OpsMx Secure Software Delivery) is governed by a comprehensive set of firewall rules (mostly prepackaged) with an ability for the end user to create new rules, redefine and reconfigure as per the need. The goal of the Deployment Firewall is to perform real-time checks during delivery time so as to determine if the software delivery meets the pre-defined firewall rules or not.
By checking for broken rules or policy violation flags, and by deriving the Delivery Bill of Materials (DBOM), the decision to deploy or not will not only get automated, but also ensures that the applications deployed are secured and 100% compliant.
Here are a few examples of the Deployment Firewall rules:
- Does this deployment or Artifacts associated with this deployment have any critical CVEs?
- Will this deployment introduce any recently reported CVE into the environment?
- Do we have adequate unit test coverage?
- Is the quality code meet approved by DAST and SAST?
Another very popular use case of the Deployment Firewall is when a vulnerability is newly reported, you can enforce a real time rule to stop all deployments containing the affected packages/ artifacts.
Securing Software Delivery with OpsMx’s Deployment Firewall
Just to summarize what I’ve explained so far, the Deployment Firewall makes the last mile checks (in real time) to make sure that the deployment is in full compliance with the configured deployment rules. And to power this process, there are 3 distinct elements to it:
1. Admin layer
- This is the UI layer where you (or users) can manage and configure the firewall rules
- This layer is typically where all the data/ information is ultimately defined
2. Intelligence layer
- This layer makes up the core of the Deployment Firewall engine
- It compares the defined rules against actual instrumentation data coming in from other DevOps/ Security tools
- It is the combination of the rules configured in Admin layer and data collected from other DevOps integrations, that checks if any critical CVE is present
- As the name suggests, this is the enforcement layer which checks if the deployment is in 100% compliance and there are no broken rules
- It checks for open violations and blocks deployment. In addition, it notifies concerned personnel about the blocked deployment
- It also allows you to manage exceptions in case deployment needs to happen with a warning.
Conclusion
Deployment Firewall is one of the key capabilities to implement DevSecOps. It prevents security vulnerabilities and compliance issues from going to the staging or the production.
Please visit Secure Software Delivery for overall DevSecOps capabilities or request a detailed demonstration of Deployment Firewall.
About OpsMx
Founded with the vision of “delivering software without human intervention,” OpsMx enables customers to transform and automate their software delivery processes. OpsMx builds on open-source Spinnaker and Argo with services and software that helps DevOps teams SHIP BETTER SOFTWARE FASTER.
0 Comments