With cybersecurity guidelines coming down from the executive branch, industry and policymakers clearly both see the extent of the cyberattack problem. Take a look at the contents of the Biden administration’s May executive order and what it means for people working in the industry, especially in regards to supply chain attacks.

The executive order covers a wide range of issues, including sharing threat information, public/private partnerships and closer teamwork with federal partners. It puts the onus on the federal government to take at least some responsibility for protecting digital systems, establishes working groups and takes existing NIST guidelines as formal instructions around some government agencies. Today, we’ll focus primarily on part 4 of the order, which covers software supply chain security. Why is this important, and how can the industry use it to make our jobs easier?

Why Attackers Use Supply Chain Attacks

Supply chain attacks get their own section for a reason. They’re a major feature of the security landscape right now. As we learned during the work-from-home era, functioning interconnectivity is critical to keeping businesses running. Much of that interconnectivity relies on the software supply chain. As a result, you no longer have to worry about just your own problems. You also have to take into account the problems of those you rely on. Put another way, your risk footprint just got a whole lot bigger. Plus, a wide group of stakeholders will feel that risk.

That is the appeal of supply chain attacks. Threat actors know they can force multiply an attack, hitting a wide group of stakeholders all at once. Attackers see supply chain attacks as highly rewarding.

If you want to stop an attack, you need to understand what is driving it. You see, threat actors are still operating ‘a business’, albeit a dishonest one. They are looking for a reward for their efforts. That reward comes in many forms, including but not limited to money, influence or suppression and pressure campaigns, just to name a few. Just like any other aspiring or successful business person, attackers will seek means to maximize their return on investment. Software supply chain attacks give them just that.

That’s why the software supply chain needs to be top of mind for both developers and users.

Securing Against Software Supply Chain Attacks

Section 4 of the order gives us a good primer on hardening the software supply chain, outlining nearly two dozen action items. Let’s look at some of those areas in a bit more detail, specifically the three general areas directed at NIST guidelines:

• Criteria to evaluate software security
• Criteria to evaluate the security practices of the developers and suppliers themselves
• New tools or methods to demonstrate they follow secure practices.

Because safety is always a hard sell. That is, just up until the moment right before you have been bitten. In order to have an honest and candid dialogue about supply chains, we need to address the two elephants in the room. First, good code is not cheap, as it requires serious talent to develop and test.

Second, being productive is still taking precedent over security. If we were at a stage where enough organizations had adopted security by design principles, one could argue that attackers are simply better at using the tech than their victims. However, we’re far from that adoption being complete. Instead, we’re still at the step of making business decisions about how to fit our defenses in. Therefore, it is worth going back to the old favorite: what amount of risk are you willing to take on? It’s all about risk management, every single time. You have to know that before you can even start to talk about defending against supply chain attacks.

Setting Standards

One major outcome of the executive order is baselining. People may disagree what would constitute ‘critical’, but at least we have a formal definition on the books now.

As cybersecurity issues sometimes feel as though we are Alice in Wonderland, it is worthwhile to invoke the words of Lewis Carroll: “Begin at the beginning,” the King said, very gravely, “and go on till you come to the end: then stop.”

Let’s, therefore, begin with the first two supply chain security essentials defined by NIST: definitions of critical software and suggested minimum standards for testing software source code.

Critical software as mentioned in the executive order is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:

• Is designed to run with elevated privilege or manage privileges
• Has direct or privileged access to networking or computing resources
• Is designed to control access to data or operational technology
• Performs a function critical to trust
• Operates outside of normal trust boundaries with privileged access.

One of the first steps to achieving cyber resilience against supply chain attacks requires you to know what to protect. This is the core of the all-hazards approach. Therefore, anything that ‘looks’ like the above is deemed critical and must be secured. The attached guide goes into greater detail on what to focus on first (in this case, on-premises systems, with hybrid and cloud systems later) and provides a handy table on software classification. Again, this is more of ‘begin at the beginning’ type material required to level-set ourselves. Call it the ‘what’.

Next, we move to the ‘how’.

If You Haven’t Tested Your Plan, You Don’t Have a Plan

Another short-term result of the order was for NIST to develop a minimum standard for vendor or developer verification of code. This is more of the ‘same song sheet’ type material, but if we can actually get to a minimum level of verification, we will be in a better place (more detailed NIST document here). We are not there yet, and we may never get there because of the two elephants, but this is a step towards something like an Underwriters Laboratories certification for products and code. (For those unfamiliar with the UL label, it is a safety consulting and certification company that carries out performance and safety testing on products.)

But does a best practices authority for software like this actually exist? Not yet, but in the future, it could become a force on how we address software flaws and risks that can lead to supply chain attacks. Think about the downstream effects: if safer and more secure code replaces vulnerable code, all of a sudden, your risks change, including those that are people-intensive. The pressures on your managed services providers, in-house team, security operations center and incident responders, at least in theory, should all go down (and do wonders for burnout rates). Imagine your team only has to worry about 1,000 fires instead of 100,000 fires. But again, this type of sea change requires addressing the two elephants in the room.

Why the Executive Order Is Heavy on the Basics

While covering supply chain attacks, section 4 of the executive order also discusses some more issues we continually hear about: using administratively separate builds, auditing relationships, multi-factor authentication, minimizing dependencies, monitoring and, of course, encryption. Why are these being called out if we should know them already? It is because we keep on missing the basics and lack that culture of cybersecurity in the workplace. If money is the first elephant, the culture issue is the second.

… And What It Doesn’t Do

There’s also the problem of putting this into practice. While the executive branch can enforce some guidelines over the federal government, there is no legal mechanism to ‘write well’ yet. Therefore, it is going to have to fall on the software industry to make a business decision. Otherwise, if the product failures or mishaps keep piling up, it will start to directly cost them money.

In the end, that may be the motivation that drives good security in the supply chain. Right now, the attacker sees supply chain attacks as a great return on investment. We need to turn the tables on them. Make it expensive, difficult and time-consuming for them to attack the supply chain. They may just back off this specific fight.