What to know about global action on cybersecurity
Cybersecurity has reached critical status. Ransomware attacks have caused major problems for critical infrastructure, including healthcare institutions. Today, many attacks focus on stealing and then using the financial data of individuals.
As hacking techniques spread, there are deep concerns about how much future attacks will use Internet of Things (IoT) connectivity to focus on all modern applications, from utility networks through manufacturing plants to medical devices.
Governments are passing core legislation and industry-specific laws, issuing executive orders and reports. Some early and wide-ranging laws, such as the U.K.’s Computer Misuse Act, criminalized many forms of hacking. More recent legislation, such as laws enacted in the U.S., has focused on the systems that might be attacked within individual sectors. However, they typically do not detail cybersecurity countermeasures.
Evolution of cybersecurity regulations in the U.S.
The 1996 Health Insurance Portability and Accountability Act (HIPAA) had the effect of tightening up data security around health care devices and systems. The 1999 Gramm-Leach-Bliley Act focused on the finance and banking sectors. In 2002, the U.S. passed the more wide-ranging Homeland Security Act, which included the Federal Information Security Management Act (FISMA). It demanded government agencies act to protect their systems and information. Only a year later, California turned to the consumer ramifications of attacks and enacted the Notice of Security Breach Act. This required that any company with access to the personal information of California citizens that suffer a security breach disclose the details of the attack’s consequences.
Though there have been attempts to pass further federal laws in the U.S., there has been more movement through executive orders issued by successive presidents. A 2018 executive order sought to improve the security of critical infrastructure, including utility networks. More detailed recommendations for some sectors have followed. U.S. Executive Order 14028 on Cybersecurity issued by the Biden administration in May 2021 called for the products used by government agencies to be accompanied by a software bill of materials (SBOM). From the autumn of 2023, the U.S. Food and Drug Administration’s (FDA) approvals process would no longer accept digital medical devices without an accompanying SBOM.
Improving security through software provenance
The SBOM is fast becoming a key asset in delivering improvements in cybersecurity. It records the software modules used in each deliverable and the provenance of those modules and libraries. The SBOM makes it much easier for developers to use the data provided by security analysts through databases such as the Vulnerability Exploitability eXchange (VEX) to check whether patches need to be applied and distributed to customers.
What goes into your software bill of materials?
These primary pieces of information go into an SBOM for each software module.
In early 2023, the U.S. White House issued a more comprehensive report with several recommendations to improve software security across all industries. Though no U.S. legislation yet enforces its use, a report followed in early 2024 that contained several more detailed recommendations designed to reduce the probability of vulnerabilities being written into software of any kind.
A report issued in February 2024 by the Office of the National Cyber Director (ONCD), entitled “Back to the Building Blocks,” calls for software teams to move to programming languages that offer better guarantees of memory safety than C and its derivatives. Rust, for example, provides programmers with memory-allocation and pointer-management features that prevent programs from trying to access memory that has been freed, or trying to use memory addresses that are out of range. This helps avoid many of the overflow bugs that are exploited by hackers.
Exploiting buffer overflows
A buffer overflow happens when data allocated on the heap to one task spills over into a memory area designated for a different task or function, as shown here with the string “overflowed,” which is too long to fit into the “allocated” space.
Enhancing security through hardware protections and formal verification methods
The ONCD report recommends developers consider hardware protections such as the memory-tagging extensions (MTE) supported by Arm and the Capability Hardware Enhanced RISC Instructions (CHERI) set. Proposed by researchers at the University of Cambridge in the U.K., CHERI has been embraced by the RISC-V community. Arm has also played an active role in developing prototype silicon that uses the instructions. The CHERI set provides support for novel software techniques that deliver fine-grained memory protection to help prevent typical hacking techniques from succeeding and can help protect code written in languages such as C and C++ that lack stringent compiler-based memory-safety checks.
The ONCD report also asks developers to pay more attention to formal verification methods that use static analysis to determine whether a software program will contain vulnerabilities and mistakes that attackers can exploit.
Open-source issues for cybersecurity
The report uses the example of a vulnerability within the open-source Java logging library Log4j to show how vigilance is essential to maintaining software security and how software modules need to be monitored for potential vulnerabilities regularly. However, the authors add that the transparent nature of open source lends itself to continual measurement strategies that allow dynamic monitoring of potential weaknesses in software.
Open source is one consideration of what is possibly the most extensive cybersecurity act in the world: the European Union’s Cyber Resilience Act (CRA). Proposed by the EU in September 2022, it was approved by the European Parliament in March 2024. When passed into law, the CRA applies to all products that contain “digital elements” not covered by sector-specific regulations such as medical devices, motor vehicles and military systems and which can connect to a network. A further exemption is for software provided as a service, which may apply to some industrial software that runs on general-purpose edge computers or reprogrammable machine tools and robots. Instead, the NIS 2 Directive covers such rented software.
The CRA applies to what the legislation calls “economic operators.” These are the organizations involved in a product’s lifecycle, including manufacturers, importers and distributors. However, most of the obligations lie with manufacturers. The law expects them to deliver products with no known exploitable vulnerabilities and to have a structure that limits potential attack surfaces.
The CRA regards the systems it deals with as products with digital elements (PDEs). The legislation applies if such a PDE, which can be software provided separately to a hardware device, is put onto the market, though it could be free of charge.
The manufacturer determines which class of PDE the product falls into. They can use a default category for products that have a low risk to the user if compromised. PDEs classed as important perform functions that are critical to security, or which carry a significant risk of adverse effects if an attack is successful. Critical PDEs are those that could disrupt supply chains.
New legislation and cybersecurity demands for product development
Manufacturers must determine the correct category for their PDEs and use development processes that are appropriate to that category. They can self-certify default PDEs. However, for critical PDEs, the development team needs to pass a third-party conformity assessment process. Developers of a critical PDE will face a stricter set of tests.
The CRA has a different treatment for writers of free and open-source software (FOSS), though any organization that implements a system using open source will need to follow the rules for PDEs. Open-source stewards play a special role under the new legislation where PDEs qualify for being treated as FOSS and are intended for commercial operation. The stewards must establish cybersecurity policies, and encourage the people involved with the project to disclose vulnerabilities responsibly. They also need to be prepared to work with government authorities to address the security risks their software may cause.
The CRA’s demands are similar to some of the recommendations outlined by the White House report issued in February. During the PDE market life cycle, manufacturers will need to manage product vulnerabilities and perform regular testing as well as deliver patches to affected customers and follow responsible disclosure programs. To help control ongoing costs, manufacturers will define a support period that reflects the time they expect the product to be in use. They will not have to provide security updates after that point. But the CRA demands the support period be no shorter than five years, unless the intended lifetime of the product is less than this.
As security threats have proliferated, governments have become far more engaged in legislating for the technology sector than ever. Developers need to take note of government activity and rework processes to implement the new demands of today’s cybersecurity landscape.
More security-related articles from Avnet: