Attacks on Critical Infrastructures are Rising. Is President Biden’s Executive Order the Solution?

Cyberattacks are not a new concept. Recently, however, these attacks have become more sophisticated, targeting critical infrastructure, disrupting the daily lives of citizens, and costing victims millions of dollars. In fact, according to blockchain data platform Chainalysis, the total amount of ransom paid by victims increased 311 percent in 2020—reaching nearly $350 million worth of cryptocurrency.

Since the recent supply chain attack on SolarWinds, infrastructure attacks have been reported at an exponential rate. The Colonial Pipeline fell victim to ransomware, triggering a widespread fuel shortage; leading meat supplier JBS suffered from a ransomware infection soon thereafter, threatening another potential meat shortage since the pandemic-induced panic-buying habits in early 2020. Even Martha’s Vineyard was attacked, seizing and holding ferry services and operations hostage.

With these events happening within a matter of weeks, U.S. President Joe Biden signed an executive order on 21 May to ensure that the United States has a better response to infrastructure attacks for both public and private sectors—especially as private sectors historically weren’t required to follow cybersecurity guidelines set by the government.

Additionally, the order mandates that regulations and programs, such as cybersecurity labels, be put in place to help prevent or mitigate the impact of future attacks and the fallout associated with them. Even though this is a step in the right direction to address the growing cybersecurity concerns, it raises the question: Is it the responsibility of the U.S. government to protect the nation’s connected security?

A Closer Look at Biden’s Executive Order

With the recent hacks on critical infrastructure being top of mind for leaders, this executive order focuses on addressing those challenges. As a result of the hacks, zero-trust among federal devices must be implemented so they can’t interact with one another. In a situation where hackers gain access to a computer in this environment, there will be limited consequential damage since that computer won’t be able to communicate with others. It won’t act as a jumping off point to gain access to sensitive company information.

Is it the responsibility of the U.S. government to protect the nation’s connected security?

In addition, the executive order strongly recommends creating a software bill of materials (SBOM) so the software that companies are using can be consistently monitored and maintained with appropriate updates—preventing vulnerabilities from outdated programs. A software bill of materials should include all the software libraries which are included in the product. This would include the custom code developed by the manufacturer, the operating system, all the communications libraries, along with the crypto libraries.

While having an SBOM is beneficial, it’s challenging to convince companies to apply this approach. The problem is that the SBOM for a device is not just: manufacturer's custom code plus Linux. Instead, it needs to include all the packages which are included and most importantly, which ones are actually used. For example, if you look at Linux on a Chromebook, there are more than 600 packages included. However, not all are actively being used.

The other issue is a device may include a hardware component which also includes embedded software. For example, most devices which have a cellular modem use modems from another manufacturer who also writes the communication library which is included inside the modem. Some of those libraries may actually come from other companies in the supply change. All of this creates a complex web of code and hardware, which currently is not being tracked by most companies.

Thus, SBOMs should instead be required from the onset of device manufacturing, rather than suggested, and enforced by leading industry organizations who bring together major technology companies, manufacturers, and stakeholders.

Piloting a Software Label Program

Another important component to the executive order is the software label program, a pilot program to create an Energy Star style label for software development. With this, there will be a visible signal on devices’ packaging that will indicate to end-users that the product has been tested for security and has met or exceeded guidelines. For this program to be successful, however, there needs to be a unique labeling system that goes beyond bronze, silver, and gold levels and provides transparency to consumers about the testing and results.

When you have just these three levels, a misconception is created that one level is “better” than the other. A lightbulb, for example, would receive a bronze label compared to a security camera receiving gold, not because it’s less secure, but due to the fact that the risk of a lightbulb is lower than that of a security camera. Yet, in the eyes of a consumer, this bronze-level label makes it appear to be inadequately secure, causing confusion.

To avoid a potentially misleading labeling system, manufacturers should approach security labels based on the profiles of specific products, applying the necessary security requirements according to each level of risk. With the guidance of leading industry organizations, manufacturers can give their products only one label, instead of a variety of three, to simply show that it’s secure for use—ultimately giving consumers an easier way to recognize security, which will allow them to make more informed decisions.

Security Testing

To apply these software labels successfully, devices need to be validated through security testing labs or third-party certifications. To account for the large numbers of devices that need to be tested, manufacturers can also self-certify devices and have the results validated as an alternative. To be accountable and prevent bad actors throughout both processes, industry standards organizations should be consulted and partnered with. This will allow researchers to verify the quality of the self-certification, checking for any vulnerabilities and openings that could be left exposed to hackers. By having these checks and balances for self-certification, devices can be tested, secured, and confidently given a cybersecurity label, while maintaining convenience and still providing a variation of third-party and security lab assessment options.

This executive order has the potential to change the way the United States approaches cybersecurity. While this is the step in the right direction and sets the stage for a national software labeling program, it’s important that government agencies, like the Federal Trade Commission, help enforce the application of security labels and that stakeholders uphold the significance of these labels. Leading industry organizations should also be closely involved and aligned with this program to help apply standards and regulations to prevent innovation from being stifled, while still ensuring that connected products have the proper level of security—creating a more secure ecosystem and protecting all end-users from future attacks on infrastructure.

Brad Ree is chief technology officer of ioXt. In this role, he leads ioXt’s security products supporting the ioXt Alliance. Brad holds over 25 patents and is the former security advisor chair for Zigbee. He has developed communication systems for AT&T, General Electric, and Arris. Before joining ioXt, Brad was vice president of IoT security at Verimatrix, where he led the development of blockchain solutions for ecosystem operators. He is highly versed in many IoT protocols and their associated security models.