Slash Boxes

SoylentNews is people

Submission Preview

Link to Story

The Good and Not So Good of the IoT Cybersecurity Improvement Act of 2020 - Security Boulevard

Accepted submission by upstart at 2020-10-17 15:23:36

████ # This file was generated bot-o-matically! Edit at your own risk. ████

The Good and Not So Good of the IoT Cybersecurity Improvement Act of 2020 - Security Boulevard []:

Cyberlaw [] Cybersecurity [] Featured [] Governance, Risk & Compliance [] IoT & ICS Security [] Security Boulevard (Original) [] Spotlight []

In September, the House of Representatives passed a bill requiring that all internet of things [] (IoT) devices purchased by the government meet minimum security requirements.

Of course, with everything being connected to everything, there needs to be a step function improvement in the security of the networks being used to share information. I have seen reports that indicate as much as 98% of traffic from IoT devices are unencrypted today, and clearly that number has to become near zero. Security is not free. It is relatively bulky from a silicon area perspective and burns energy. But it is a prerequisite for the services on which we want to be relying on in the coming years.

H.R. 1668 [] has the potential to improve the security of the IoT for two high-level reasons. Any activity that places cybersecurity front and center of IoT conversations is a good thing. This bill could and should create demand for higher quality devices, which incentivizes the supply chain to build platforms. This is different from other (market “push”) security initiatives and standards such as Arm’s Platform Security Architecture [], in which it is a technology company proposing something. Here it is an end customer stipulating requirement that creates market “pull.”

The bill also outlines key themes that should be addressed rather than getting caught up in specific technologies.

That said, I think some elements of this show where the U.S. government may have some challenges. There are three elements we feel could do with improvement here:

  • No device can be regarded as 100% secure. Software has to provide earlier recognition that a device has been compromised. We have seen that in the enterprise arena; hacks can remain hidden for months, such as in the Citrix case [] in which hackers laid dormant for five months. The bill’s section 4, subsection 2, should be a separate section that discusses this set of system capabilities. Maybe it is contemplated and articulated under “patching” or “secure development,” but it is important enough to be called out separately.
  • The publishing guidelines in another section (Section 4, C I) are set for five years. This is simply too slow. This industry is far more dynamic and will need a cadence far quicker than this.
  • I believe in applying different (tiered) levels of security based on the device’s use case and the value of the data that could be exposed. The concern here is that there will be some applications that need absolute bulletproof security. There will be other things (simple sensors) for which less security is required—doing a one-size-fits-all approach risks making systems too costly, too power-hungry etc.

Now, given that a lot of consumer devices aren’t things that would be purchased by the U.S. government, one could argue whether this will really help with the security of those devices in any way? Granted, volume is relatively low in the U.S. government, so I’m hopeful that companies that are driven to meet these requirements will also sell those products into other applications. That’s why it is important for tiered levels of security, as this might better help hit price and power points for broader adoption.

This is only the first step in a long list that the U.S. government can look to for improving security. It should consider its role with “carrot” and “stick” initiatives, such as the U.S. taking an active role and driving down power usage for certain devices (screens, laptops and TVs) through the delivery of financial incentives for people that purchased energy-efficient devices. That is the “carrot” initiative; something similar for purchasing secure IoT devices might help.

The “stick” represents how the compliance of the bill is policed. The European government has agreed that IoT security is important and they are empowering governments to track and potentially issue punitive fines if devices are found to be “below the line” in terms of security. The U.S. government can do something similar. I believe tier 1 cloud infrastructure companies and service providers will be highly supportive; these are the companies that will likely appear on the front of a magazine if a specific company using their services is hacked, so it is prudent for them to raise the bar and to continue to raise it, as security is not a static thing.

IoT Cybersecurity Improvement Act of 2020 [], IoT Security [], legislation []The best cybersecurity defense is always applied in layers—if one line of defense fails, the next should be able to thwart an attack, and so on. Now that DevOps teams are taking  more responsibility for application security by embracing DevSecOps processes, that same philosophy applies to security controls. The challenge many organizations are facing now ... Read More []

Original Submission