It has been reported that Forescout security researchers have disclosed 33 security flaws (named Amnesia:33) in four open-source TCP/IP libraries currently used inside the firmware of products from more than 150 vendors. Cybersecurity experts provide an insight on this discovery below.
Today’s discovery of 33 new security vulnerabilities in popular and widely-used open source packages provides yet more evidence that it’s open season on open source.
Modern software is no longer built from scratch, but by using prefabricated open source components. But with 11% of components known to have a documented vulnerability, it’s clear that today’s findings are indicative of a much bigger problem – companies aren’t doing enough to secure their software supply chains. Software Supply Chain security is particularly challenging when it comes to IoT. The highly competitive IoT ecosystem remains a significant breeding ground for flawed software due to complex supply chains that propagate vulnerabilities, yet flaws are often difficult to patch.
To mitigate these issues, it is critical that businesses have a software bill of materials in place for every release. Acting like a list of ingredients that certifies the software supply chain, a bill of materials enables companies to quickly determine whether a vulnerable software component is in a device, and take steps to remediate the issue.
“Proposed legislation by the UK government to secure IoT devices should also help mitigate threats in the long term, but there needs to be greater onus on manufacturers to take responsibility for what goes into their products. The tools are available to enable manufacturers to build security into their applications, so failure to do so should amount to gross negligence. No other manufacturing industry is permitted to ship known vulnerable or defective parts in their products, so why should the software components in connected devices be any different? Instead, manufacturers should be able to certify that their software, and their devices, are secure at the time of shipping, and should ensure their security updates last for the mandated time. Only with a combined effort from manufacturers and businesses, backed by IoT legislation, can we be confident of proper software hygiene in the ever-expanding connected ecosystem.
One thing that IoT users need to be aware of is that many of the devices on the market and used in their homes will or have already passed the maintenance guarantee period offered by the manufacturer. In other words, the difficulty is in ensuring that devices are patched, particularly for any low cost/high volume product. This same concern also applies to license conflict issues that may surface in the software. Therefore, manufacturers of such products have to put extra energy into “getting it right” along all dimensions before release. It also means that, in many cases, users or organisations will have to proactively adopt preventative measures themselves. Deploying mitigation techniques, such as treating devices as untrustworthy, monitoring their behaviour, creating subnets in which they work and abiding by the principle of least privilege are just a few steps one can take to protect their assets.
Security must be part of every phase of software development. During the design of an application, threat modeling and architectural risk analysis are critical. During development, static analysis helps minimize weaknesses, and software composition analysis (SCA) help minimize risks of third-party components. Fuzz testing minimizes risk by helping developers harden the application to unexpected or malicious protocol inputs. Security even plays a key role in software maintenance, when new vulnerabilities in software components might be discovered and software updates might be necessary.
The Amnesia:33 disclosures affect a software component used in many IoT devices for networking. While these weaknesses were most likely located using fuzzing, they highlight the importance of software composition analysis for vendors. After you release a product, you need to respond if new weaknesses are discovered in software components that you already used. In an ideal scenario, devices would be able to update themselves with a newer version of the component that does not have the same weaknesses.
For many IoT devices, getting a functioning product to market quickly takes precedence over, which means manufacturers might not have an automatic mechanism for updates, or indeed, might not even be devoting resources to maintaining released products.
These findings join a long trail of similar high-impact security discoveries in embedded and IoT devices. As more and more embedded devices are used in things like building management systems, cameras, routers, sensors, locks, lights, scanners, robots, motors, and hundreds of other devices, the problem will become more prevalent. There is no slowing down on the volume or variety of embedded devices being manufactured and deployed. For the most part, not much has changed at the manufacturer level; products are being developed as quick and as cheap as possible, released, and then forgotten about. Meanwhile, attackers take advantage of the vulnerabilities that remain undetected for up to 20 years before a public disclosure is made. Even after disclosure, the teams that developed the software and can patch it are probably long gone.
Knowing that the root-cause of the problem (deploying vulnerable embedded and IoT systems) is growing at and exponential and alarming rate, it’s clear that the risks need to be accounted for and properly mitigated. In many cases, embedded and un-managed technology is difficult to identify, much less considering it part of a managed asset inventory. After the embedded systems are identified, the expected behaviours of those devices can be difficult to ascertain and manage. Furthermore, understanding how to mitigate the vulnerabilities after they’ve been identified is a another matter. In fact, sometimes it’s impossible to patch, leaving operators with the realisation that they have no choice but to assume the risks.
This quandary serves to underscore one of the key drivers that drive customers to our space. Facility operators need an independent set of eyes and ears to monitor everything in their environment, while assuming it’s always infected, trusting nothing, and then placing a usable asset inventory combined with artificial intelligence, machine-learning, anomaly detection, auditing, vulnerability management, and cyber-attack detection into the hands of our community. This enables organisations with mature cybersecurity programmes to understand, and account for the risks associated with the constant flow of IoT and embedded systems vulnerabilities. In essence, organisations that spend budget on cybersecurity are already equipped to manage, or at least minimise the impact of these types of exposures. Those that didn’t invest in cybersecurity? Let’s just say….unfortunately, they will be some pretty busy folks through the holidays.
Today’s discovery of 33 new security vulnerabilities in popular and widely-used open source packages provides yet more evidence that it’s open season on open source.
Modern software is no longer built from scratch, but by using prefabricated open source components. But with 11% of components known to have a documented vulnerability, it’s clear that today’s findings are indicative of a much bigger problem – companies aren’t doing enough to secure their software supply chains. Software Supply Chain security is particularly challenging when it comes to IoT. The highly competitive IoT ecosystem remains a significant breeding ground for flawed software due to complex supply chains that propagate vulnerabilities, yet flaws are often difficult to patch.
To mitigate these issues, it is critical that businesses have a software bill of materials in place for every release. Acting like a list of ingredients that certifies the software supply chain, a bill of materials enables companies to quickly determine whether a vulnerable software component is in a device, and take steps to remediate the issue.
“Proposed legislation by the UK government to secure IoT devices should also help mitigate threats in the long term, but there needs to be greater onus on manufacturers to take responsibility for what goes into their products. The tools are available to enable manufacturers to build security into their applications, so failure to do so should amount to gross negligence. No other manufacturing industry is permitted to ship known vulnerable or defective parts in their products, so why should the software components in connected devices be any different? Instead, manufacturers should be able to certify that their software, and their devices, are secure at the time of shipping, and should ensure their security updates last for the mandated time. Only with a combined effort from manufacturers and businesses, backed by IoT legislation, can we be confident of proper software hygiene in the ever-expanding connected ecosystem.
One thing that IoT users need to be aware of is that many of the devices on the market and used in their homes will or have already passed the maintenance guarantee period offered by the manufacturer. In other words, the difficulty is in ensuring that devices are patched, particularly for any low cost/high volume product. This same concern also applies to license conflict issues that may surface in the software. Therefore, manufacturers of such products have to put extra energy into “getting it right” along all dimensions before release. It also means that, in many cases, users or organisations will have to proactively adopt preventative measures themselves. Deploying mitigation techniques, such as treating devices as untrustworthy, monitoring their behaviour, creating subnets in which they work and abiding by the principle of least privilege are just a few steps one can take to protect their assets.
Security must be part of every phase of software development. During the design of an application, threat modeling and architectural risk analysis are critical. During development, static analysis helps minimize weaknesses, and software composition analysis (SCA) help minimize risks of third-party components. Fuzz testing minimizes risk by helping developers harden the application to unexpected or malicious protocol inputs. Security even plays a key role in software maintenance, when new vulnerabilities in software components might be discovered and software updates might be necessary.
The Amnesia:33 disclosures affect a software component used in many IoT devices for networking. While these weaknesses were most likely located using fuzzing, they highlight the importance of software composition analysis for vendors. After you release a product, you need to respond if new weaknesses are discovered in software components that you already used. In an ideal scenario, devices would be able to update themselves with a newer version of the component that does not have the same weaknesses.
For many IoT devices, getting a functioning product to market quickly takes precedence over, which means manufacturers might not have an automatic mechanism for updates, or indeed, might not even be devoting resources to maintaining released products.
These findings join a long trail of similar high-impact security discoveries in embedded and IoT devices. As more and more embedded devices are used in things like building management systems, cameras, routers, sensors, locks, lights, scanners, robots, motors, and hundreds of other devices, the problem will become more prevalent. There is no slowing down on the volume or variety of embedded devices being manufactured and deployed. For the most part, not much has changed at the manufacturer level; products are being developed as quick and as cheap as possible, released, and then forgotten about. Meanwhile, attackers take advantage of the vulnerabilities that remain undetected for up to 20 years before a public disclosure is made. Even after disclosure, the teams that developed the software and can patch it are probably long gone.
Knowing that the root-cause of the problem (deploying vulnerable embedded and IoT systems) is growing at and exponential and alarming rate, it’s clear that the risks need to be accounted for and properly mitigated. In many cases, embedded and un-managed technology is difficult to identify, much less considering it part of a managed asset inventory. After the embedded systems are identified, the expected behaviours of those devices can be difficult to ascertain and manage. Furthermore, understanding how to mitigate the vulnerabilities after they’ve been identified is a another matter. In fact, sometimes it’s impossible to patch, leaving operators with the realisation that they have no choice but to assume the risks.
This quandary serves to underscore one of the key drivers that drive customers to our space. Facility operators need an independent set of eyes and ears to monitor everything in their environment, while assuming it’s always infected, trusting nothing, and then placing a usable asset inventory combined with artificial intelligence, machine-learning, anomaly detection, auditing, vulnerability management, and cyber-attack detection into the hands of our community. This enables organisations with mature cybersecurity programmes to understand, and account for the risks associated with the constant flow of IoT and embedded systems vulnerabilities. In essence, organisations that spend budget on cybersecurity are already equipped to manage, or at least minimise the impact of these types of exposures. Those that didn’t invest in cybersecurity? Let’s just say….unfortunately, they will be some pretty busy folks through the holidays.