How many people are required to purchase a pair of shoes? The question is kind of confusing. It requires you and the other person with who you are dealing (assuming you are in a physical store). However, the real question is: How many people go through the process of purchasing a pair of shoes? There are salespeople, store managers, shipping and logistics companies, shoe manufacturers, tool and equipment manufacturers, raw material manufacturers, and so on. The supply chain is made up of all different entities.
Because each of those providers can be seen as a link in a chain, the term “supply chain” is suitable. Additionally, you can begin to see how complicated and linked our world’s economy and way of life are. Since almost everyone is a supplier to someone else (When was the last time you gave your aglet provider any thought at all? ), the shoe example could be an interesting thought experiment.
But what if we talked about buying a software solution instead of shoes? The supply chain size can range depending on the software in question, but the concept is the same. Even internal custom software solutions have their supply chains; but, for this article, let’s focus on the software you are buying, especially open-source software.
Members of the open-source community contribute code to upstream projects, which is basically where the supply chain for open-source software begins. This code is free to use and is contributed to by many groups and individuals worldwide. From there, businesses and other organizations take the code and either add it to a product they sell or distribute and support it for a fee.
Companies like Red Hat, for instance, charge monthly fees for support and maintenance so that the customers don’t have to perform these tasks themselves (which is certainly an option). Other businesses incorporate open-source software into manufactured goods, such as Internet of Things devices. Today, chances are good that you already have a piece of equipment running open-source software.
You can start to visualize the software supply chain based on these examples. By the way, you can generally find a note in the user interface—for example, under a “help” or “support” menu option—if you wish to see if a device uses open-source software.
Supply chain attacks are nothing new; this strategy has been used for a very long time. To achieve a tactical or strategic edge, an adversary would, for instance, try to sabotage or damage an enemy’s supply line (such as food or artillery) during a military fight. A software supply chain attack, however, differs significantly from the previous example and to some part from other cyberattacks. But in each of these situations, the attacker is searching for a weakness in the code to take advantage of (and at a high level). Attacks on the software supply chain are frequently (though not always) used as a way to gain access to something else. In other words, the “maker” is just a means to an end; they are not the goal.
When major retailers and home improvement companies faced breaches because of a weakness in their supply networks, the early examples of supply chain attacks made the news. The retailer’s internal network was accessed through a hack at a software provider. The attackers in this case, as well as similar ones, were for data, specifically the credit card details and other sensitive data of their customers. However, such a breach resulted in additional problems that made the attacker’s task simpler. In a moment, they’ll expand a little more on it. Attacks on the software supply chain have advanced in recent years as cybercriminals learn and adjust to better security standards and procedures.
Early in 2020, a new supply chain attack made news throughout the world. The attackers were able to access the organization’s source code repositories and insert malicious code, which exposed the clientele of the organization. Once more, the software solution provider was not the end goal; rather, it was the data of their clients, likely for use in espionage and other illegal activities. Actors who are “state-sponsored” are supposedly involved in this case. And in yet another instance, when a network of an energy company was breached as part of a ransomware attack, a supply chain was seriously affected. The physical and financial effects of this attack are felt right away. They bring up this particular occurrence because its effects spilled over into the physical world and had an impact. Long queues at the gas pumps are caused by a cyberattack where I live. Future supply chain threats should and can be anticipated to become more sophisticated.
If the examples that gave above are not enough, their partner Alison Naylor highlighted that the world is getting more connected and that there are connected devices almost everywhere in her blog article about IoT devices and their security. Each of those devices is powered by software in some way (also called firmware). Going about your regular activities without interacting with anything that runs software would be difficult, if not impossible. All of the things you use every day that rely on software are devices, including your home, automobile, neighborhood grocery shop, nearby gas station, and a long list of other things. And chances are they are related to one another. Manufacturers of these devices must treat their source code properly; however, they’ll get to that in a minute. The point is that we are almost surrounded by computer-controlled objects, and they depend on this software to carry out their daily tasks and manage their lives. Suppliers of software must make sure their code is as safe and secure as possible.
You should have a security program that makes it significant, teaches, and advocates security practices since security is not a place you reach or can declare “winning” over. Your information security team should have created rules that force compliance and validate it. Do you remember the incident where we said that the attacker’s job was made even simpler? The attacker was able to access the data in plain sight since the company’s documented best practices for storing sensitive data were not being followed. Additionally, you should have a product security organization (or something comparable) whose goal is to confirm the reliability of your program. Your team can no longer limit itself to addressing the most recent code vulnerabilities. To promote fundamental security practices on the systems and services that make up your software pipeline, your product security organization should collaborate with your information security organization. But it goes further than that. If they haven’t already, product security should also be considering and planning to implement techniques like Supply-Chain Levels for Software Artifacts (SLSA) or NIST’s Secure Software Development Framework (SSDF). Following those kinds of frameworks not only puts you on the right road for improving the security of your specific link in the supply chain but also shows your customers that you are responding correctly.
An attempted cyber attack is not a question of if it happens. It will happen. No matter what position you take, it is your responsibility as a company associate to actively prevent attacks or at the very least to minimize their success. Your security program should make appropriate plans, and a strong security program also includes having a resiliency strategy. A company interruption could be exceedingly expensive, harmful, or worse. Numerous research and statistics surround this, but one number recently caught my attention was the following: “96% of businesses with a disaster recovery plan in place fully recover operations.” That is an astounding success rate!
This article is not intended to serve as a road map for creating a strategy to increase supply chain security, but it should provide you with some ideas and great starting points. However, creating and implementing security policies will depend on what is best for your organization, including the risks you may face and are prepared to take. A huge international corporation is more likely than, say, a nearby small business to be both at risk of attack and unwilling to accept some degree of risk.
Where to begin (certainly not an exhaustive list):
Reminder: Solving each of these difficulties can be extremely difficult, expensive, and time-consuming. Divide these issues into more manageable ones. Determining your degrees of risk and risk acceptability will help you do this and prioritize where you should spend your efforts initially. Attempting to address all of these issues at once will likely lead to organizational frustration and burnout, little progress on all fronts, and essentially no risks avoided or minimized.
One final thought for all of us who work in this field: Being the “weakest link” in the chain (either personally or organizationally) is unacceptable, even when we don’t want to be it. You must hold each other responsible as a community of software developers, providers, and users. Asking your suppliers to confirm—and even demonstrate—that they are adhering to particular standards, legislation, etc. is quite acceptable. This could already be a question your customers are asking of your business. Such accountability only makes your community stronger.
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com