In simple words, Software Supply Chain is a more conclusive term for a birds-eye view on the software development lifecycle. The stages of the cycle may vary following different standards and frameworks, but the general idea is that any code that is being developed for a software, or an application goes through different stages. It usually starts with gathering requirements that mandate a design direction, then those working on the software start their design implementation process where the code is written and compiled. After that comes the testing stage to make sure that everything is running as expected. Next comes the deployment phase where most of the problems start to occur once the system starts getting distributed, and finally the maintenance stage, where any broken function or bugs are found get fixed and enhanced.
It looks straight-forward and possibly trouble-free. Yet, cybercriminals have been following a malicious act of targeting software companies, sometimes before they even publish their online-facing touchpoints or before the deployment phase. Such attacks, known as software supply chain attacks, target those working on applications that can converge a high number of data transactions, whether this application will be used internally by a large organization, or online by public users like a mobile or a web application.
Threats that target the developing end: (Software/Application developer or vendor)
Whether you’re with or against the hypothesis, Software supply-chain victims are held liable for compromises initiated on their applications. While we do empathize with the developers in such a case. We still believe that diligence and security practices must be strictly followed when coming up with a new product for the market. And when the time comes for an unfortunate event, a compromised client will not have the capacity to tolerate a vendor for overlooking a code-level vulnerability.
Here are the most common vendor-side vulnerabilities:
Input validation errors: These occur when software does not properly validate user input, which can allow malicious actors to inject code or manipulate data in text or input fields.
Authentication and authorization flaws: These occur when software does not properly authenticate and authorize users, which can allow unauthorized access to sensitive data and systems.
Buffer overflow errors: These occur when software does not properly manage memory allocation, which can allow malicious actors to execute arbitrary code.
Cross-site scripting (XSS) attacks: These occur when software does not properly sanitize user input, which can allow malicious actors to execute scripts on other users' browsers.
SQL injection attacks: These occur when software does not properly validate user input, which can allow malicious actors to execute SQL commands on a database.
The software I developed runs offline, am I still vulnerable?
It is true that some software still runs completely offline or has no internet-facing application. Yet, this doesn’t eliminate the attack surface. Internal users of such systems still access online resources and download e-mail attachments which could be part of a social engineering attack and still pose as a threat to the running system. Naturally, when a software in internet-facing, the attack surface becomes wider, and the security measures need to become more robust. MHE usually refers to the OWASP top 10 list that is periodically published to guide software engineers and security professionals to the highest-priority vulnerabilities. The latest version of the list and more information about the most common threats could be found here.
I am a third-party software user, but I have a firewall, does this make me secured against SSC Attacks?
Yes and no, for one thing, a firewall has limited visibility over the threats going in your system. It is true that gateway security does protect your network, but if you look at all the layers, multiple solutions are required to have a more solid cybersecurity posture. Having a firewall that allows in/outbound connection to/from a third-party software leaves you vulnerable to compromises vectoring such software. In this case, you allow the connection (that is necessary for your team to operate) and you cannot enforce a policy that denies said connection. Some malwares are too quiet to be detected by firewalls and require deeper level monitoring to be detected and neutralized.
But I only use licensed software, with constant patching and security updates.
This still doesn’t make you 100% secure in the case of the attack we’re discussing now. And this is the main issue with Software Supply Chain attacks. Building up on the previous firewall policy example, if you allow a connection to Software A, that has recently fallen victim to an SSC-Attack and the attack is cascaded to the software users through a patch or an alleged security update, a user would deploy the update unknowingly. With this deployment, the cybercriminal or attacker gains access not only to the software developer (server side) but also to the client (user-side) which is why empathy for the developers could be understood, but the liability cannot be cleared.
Case study: SolarWinds Orion "Sunburst" attack ...
In 2020, FireEye, a well-known cybersecurity company discovered a rather sophisticated attack that compromised many sensitive organizations including US-government agencies. To the date of writing this blog post, the scope of Sunburst attack vectoring Orion is still being discovered. The level of sophistication for this attack suggests that it was backed by a state-agency (The Russian SVR) but this piece of information is still not confirmed.
SolarWinds markets a Network Management and Monitoring software to many organizations including Fortune 500 companies. The attackers inserted malicious code into the updates of SolarWinds’ software that allowed them to gain backdoor access to SolarWinds’ clients’ networks. The attack was discovered by FireEye (one of the compromised organizations as well) in 2020, yet the initial attack date and the scope of the attack are still unknown. This attack was particularly impactful in the software industry and has led to higher scrutiny of the software supply chain and showed the necessity of following a secure framework during the SDLC to ensure a more secure product offering to end users and pushed the limits in reactive security solutions to some rather impressive AI-driven solutions for third-party users.
How can I develop my software or application securely?
To ensure a basic security posture, organizations should implement a few uncompromising security practices. These include:
Code review: Code review involves manually inspecting the code for vulnerabilities and weaknesses. It can be time-consuming, but it is a critical step in securing the software supply chain. (For the most common code-level vulnerabilities, check out the CWE and CVE lists published by NIST)
Code signing: Code signing involves adding a digital signature to the software to verify that it has not been tampered with. It ensures that the software is authentic and has not been modified since it was signed.
Patch management: Patch management involves applying updates and patches to the software to address known vulnerabilities. It is important to keep software up-to-date to prevent known vulnerabilities from being exploited.
Access control: Access control involves limiting access to sensitive systems and information. It is important to control who has access to the software supply chain to prevent malicious actors from compromising it.
Incident response: Incident response involves having a plan in place to respond to security incidents. It is important to have a plan in place to minimize the impact of a security breach and to quickly recover from it.
The NIST framework includes applying the 5 following steps to ensure a basic-level security from the developers side:
Identify: This step involves identifying the software components and their dependencies, as well as the organizations and individuals involved in the software supply chain.
Protect: This step involves implementing measures to protect the software supply chain, such as access controls, threat detection and response, and security testing.
Detect: This step involves detecting and analyzing potential security incidents in the software supply chain, such as anomalous behavior or unauthorized access.
Respond: This step involves responding to security incidents in the software supply chain, such as isolating affected systems, investigating the incident, and notifying stakeholders.
Recover: This step involves restoring the software supply chain to normal operations after a security incident, such as restoring systems and data, and implementing measures to prevent similar incidents from occurring in the future.
As a user of third-party software user, here’s how you secure your organization against SSC attacks:
We highly recommend referring to MHE’s 7 Layers of cybersecurity blog to comparatively identify the potential gaps and shortcomings in your current security setup. A cybersecurity strategy for organizations that use third-party software (like Slack, MS365, G-Workplace … etc.) must include third party vendors for security. The reason being the fact that objectively no system is 100% secure, but some solutions are better at facing certain vulnerabilities than others. A software vendor cannot be competitive in both the development and the security of the software alike, unless the organization is heavily financed and has enough resources to accommodate teams in both directions, which will highly dilute their value proposition from a business perspective. An organization that uses third-party software (which is mostly the case now) can stay secure with the right security practices:
Raise the team’s cybersecurity awareness through training: This is a practice that bigger organizations are following relentlessly now, some have even implemented the cybersecurity awareness training within their HR onboarding procedures to make sure that all the team members are equally aware of the threats and how to stay protected online. Companies that haven’t adopted this approach could also resort to Security Awareness Training solutions that are able to constantly train employees on the go. This is done through ongoing simulations and live examples carried out by specialized cybersecurity solutions.
Deploy an Endpoint Protection Solution: You can protect your organization’s endpoints with multiple solutions. On the proactive end, you can deploy an EDR solution that runs a client on your endpoints regardless of where they’re operating to ensure that no malicious code is acting on behalf of the user or trying to gain access to areas that are unauthorized or contain sensitive information. Competitive solutions like SonicWall’s Capture Client and TrendMicro’s EDR solutions both leverage AI and Machine Learning to provide faster and deeper understanding of running threats, some of which could be zero-day attacks.
Run a Threat Intelligence tool if the budget allows for it: Such tools can provide real-time information about known threats and vulnerabilities, including those related to software supply chain attacks. This can help security teams stay informed about emerging threats and take proactive steps to protect against them.
Incident Detection and Response solutions should be your next milestone: While this could be part of your deployed EDR solutions, Incident detection and response is broader, and covers a wider scope of your landscape than just the endpoints. SIEM solutions do a great job in aggregating security logs from across your entire mesh, with a bit of correlation efforts from your SOC team, you are able to identify attack patterns before they even take place.
By now, you should have a clear overview of SSC Attacks, how you can fall victim if you’re on either end of the landscape (developer-user) and how you (as a developer) could leverage common security reports and lists to develop and more cyber-secured offering. And also, how you (as a user) could deploy basic solutions to stay protected against third-party vulnerabilities.
Our resources are quite limited as users, how can we secure our organization?
Hiring a Managed Security Services Provider could be the most cost-effective solution in your case. On the one hand you get specialized professionals proactively monitoring your environment for threats and alerts, and on the other hand you don’t find yourself faced with the complexity of deploying and monitoring the tools yourself. This also comes with huge savings in your IT spend, since you don’t hire specialized professionals full-time. A Managed Security Services Provider can keep an eye on your assets, provide awareness training, make sure all your third-party software and OS are patched and up to date with the latest, most secure packages only. Speak to MHE if you’re looking for ways to fortify your security posture at reasonable monthly payments.