Breaking News

Could These IoT Design Flaws Put The Lights Out?

Category: Energy & Environment,Finance

Could IoT protocol design flaws put the lights out as far as smart cities are concerned?Getty

New research has highlighted an old problem: The Internet of Things isn't exactly secure. Hardly news, you might say, but the researchers from Trend Micro discovered that two popular IoT protocols are insecure by design. So insecure, indeed, that they are putting both 'Industry 4.0' smart factory implementations and smart cities at risk. In fact, these are the design flaws that could quite literally turn the lights out.

The Fragility of Industrial IoT's Data Backbone report found that both the Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) protocols are insecure by design and to make matters worse hundreds of thousands of both hosts are reachable via public-facing IPs. These machine-to-machine (M2M) communications form the core of Industrial IoT systems that are deployed within large-scale networks seen within smart factory and smart city projects. Paul Dignan, a senior systems engineer with F5 Networks, helped me to understand the more commonly used MQTT protocol better. "MQTT is a publish-subscribe messaging protocol that allows devices such as cameras, heat sensors and lP-enabled light bulbs to publish data to an intermediary module" he explained, continuing "by default, the data the protocol sends is un-encrypted when in transit, which ultimately means that applications can then subscribe to this intermediary module (also known as message brokers) and retrieve the published data."

Across a period of four months, the Trend Micro researchers identified in excess of 200 million MQTT communication messages, and more than 19 million messages from the less popular CoAP machine-to-machine protocol, leaked by exposed brokers and servers. If this wasn't worrying enough in and of itself, that this production data could be located by anyone with the ability to perform a few simple keyword searches just multiplies the worry. Armed with this information on assets, personnel and technology an attacker could remotely control IoT endpoints or launch a Denial of Service (DoS) attack. SO, for example, researchers found data exposure related to the manufacturing sector that were leaked by a programmable logic controller and which had the names assigned to specific control systems and details of manufacturing processes; gold dust for the reconnaissance phase of an advanced persistent threat attack. Martin Thorpe, enterprise architect at Venafi, reminds us that "IoT devices are rarely built with more than basic connectivity in mind" and adds "deploying insecure IoT devices more widely across the enterprise, supply chains and within smart cities will undoubtedly create new risks." He's not wrong, not wrong at all. That these protocols are easily the most pervasive used by IoT devices, designed with apparently little thought given to security at the time and yet used in mission critical deployments in most smart factory manufacturing environments as well as throughout flagship smart city projects, is a major cybersecurity risk.

I contacted Bharat Mistry, principal security strategist at Trend Micro, to chat about the findings. He told that because CoAP is a more recent and less widespread protocol than MQTT, its design is less flawed. He also warned that, despite this, CoAP protocols remain susceptible to IP spoofing which is where criminals can pose as legitimate or anonymous end points in order to capture data. When it comes to the more widespread MQTT protocols, the most prominent flaws are "undoubtedly its payload remaining length, the Unicode handling in topic strings and its URI-style topic validation" Bharat says, continuing "all of these have provided a pathway for vulnerabilities to emerge which have inadvertently been implemented on a global scale."

It's the global nature of the impact of these flaws which is truly hard to comprehend, not least as Bharat points out neither of the protocols were ever intended for deployments over public networks or designed to carry sensitive data. "The intended use for these protocols are for environments that are typically closed or private" he explains, adding "used to transport control data over networks that are low bandwidth, high packet loss and low powered and in some cases very distant." They were also designed to work on devices with very limited CPU and memory 'compute' power so designed to be very lightweight with little or no overhead for meaningful security features. All of which means that the real-world security implications to large-scale deployments across large enterprise, industry 4.0 manufacturing and smart city projects is massive. "If even just one internal device is accessible via public-facing IPs, it can compromise the entire security infrastructure in place and leave the door wide open for bad actors to take control of these devices and gain access to a network" Wallace Sann, VP of global systems engineering at ForeScout told me.

So what can be done to mitigate the risk from these inherent protocol flaws? Dr Jacqui Taylor, CEO and co-founder of FlyingBinary is also a strategic advisor to the UK Government on smart cities and part of the UK Centre for the Protection of National Infrastructure team. She explained to me that a large part of the problem is that when considering the IoT, traditional security approaches are not appropriate as fundamentally IoT is an engineering challenge. "IoT in any domain needs a layered approach to security which does not assume some form of command and control integration" Jacqui explains, continuing "in reality if the assumption is that each connected device will need to be secured this is doomed to failure." And she should know as she has written the British Standard to articulate this for smart cities, which is currently being fast-tracked to an international standard. "I will be speaking on this and the future of the Cyber Security industry we will need at Davos in January" she says. So, when it comes to mitigation best practice the entire value chain in each use case needs to be considered to solve the problem according to Jacqui. "Like all IoT use cases, the enterprise, factory or smart city will need to be cloud first" she explains, adding that this this really needs to be done at the outset. "The services and data in the IoT ecosystem will determine the layers which need to be implemented to curate and evidence the security and privacy controls which have been implemented" Jacqui insists, concluding "this is particularly important for European data which is subject to new legislative and regulatory regimes."

I reached out to the wider cybersecurity community to see what other mitigation advice was forthcoming, the answer was a lot but not all of it very reassuring it has to be said. Trying to prevent vulnerabilities in protocols altogether is a noble pursuit, says Dr. Zulfikar Ramzan, CTO at RSA Security, who added it was also "ultimately an exercise in futility." Instead, he recommends that organizations "embrace a holistic risk-driven view that considers both the likelihood of vulnerabilities being exploited and the corresponding probable impact." Unfortunately, while proper governance is crucial to the security of M2M deployments it is also often overlooked when it comes to smart cities according to Matt Lewis, research director at NCC Group who argues this is largely because it's unclear who the CISO actually is. "By assigning clear risk ownership and direction for setting security policies and baseline standards" Matt insists, "the risk of deploying these devices with a lack of security measures can be mitigated."

Dr Guy Bunker, SVP of products at Clearswift, explains that the weakest point in the chain is most vulnerable to attack. "Injecting false data into the system upstream can create undesired impacts on end devices" he says, adding "this might not be a simple on/off type of command, but may well be ones which push the limits of the device." So, for example, pushing a pump to 100% but then leaving it at that setting such that it burns out. "Verified authentication and authorization is one part of the solution" Guy advises "but we all know that credentials can and will be compromised at some point, so additional measures need to be taken to protect systems and infrastructure based on that assumption." And finally, don't underestimate the blockchain is the advice from Prakasha M. Ramachandra, AVP of technology and innovation at Aricent, who recommends that organizations should "adopt blockchain based distributed apps (DApps) that can utilize federated learning to highlight or take action in semi-automated ways for the anomalies detected in IIoT assets." Prakasha also thinks that leveraging blockchain smart contracts to develop capabilities like identity-aware dynamic access control for IIoT devices is worthwhile. "Despite all the hype and negative press" he concludes "blockchain is certainly worth considering!"

">

Could IoT protocol design flaws put the lights out as far as smart cities are concerned?Getty

New research has highlighted an old problem: The Internet of Things isn't exactly secure. Hardly news, you might say, but the researchers from Trend Micro discovered that two popular IoT protocols are insecure by design. So insecure, indeed, that they are putting both 'Industry 4.0' smart factory implementations and smart cities at risk. In fact, these are the design flaws that could quite literally turn the lights out.

The Fragility of Industrial IoT's Data Backbone report found that both the Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) protocols are insecure by design and to make matters worse hundreds of thousands of both hosts are reachable via public-facing IPs. These machine-to-machine (M2M) communications form the core of Industrial IoT systems that are deployed within large-scale networks seen within smart factory and smart city projects. Paul Dignan, a senior systems engineer with F5 Networks, helped me to understand the more commonly used MQTT protocol better. "MQTT is a publish-subscribe messaging protocol that allows devices such as cameras, heat sensors and lP-enabled light bulbs to publish data to an intermediary module" he explained, continuing "by default, the data the protocol sends is un-encrypted when in transit, which ultimately means that applications can then subscribe to this intermediary module (also known as message brokers) and retrieve the published data."

Across a period of four months, the Trend Micro researchers identified in excess of 200 million MQTT communication messages, and more than 19 million messages from the less popular CoAP machine-to-machine protocol, leaked by exposed brokers and servers. If this wasn't worrying enough in and of itself, that this production data could be located by anyone with the ability to perform a few simple keyword searches just multiplies the worry. Armed with this information on assets, personnel and technology an attacker could remotely control IoT endpoints or launch a Denial of Service (DoS) attack. SO, for example, researchers found data exposure related to the manufacturing sector that were leaked by a programmable logic controller and which had the names assigned to specific control systems and details of manufacturing processes; gold dust for the reconnaissance phase of an advanced persistent threat attack. Martin Thorpe, enterprise architect at Venafi, reminds us that "IoT devices are rarely built with more than basic connectivity in mind" and adds "deploying insecure IoT devices more widely across the enterprise, supply chains and within smart cities will undoubtedly create new risks." He's not wrong, not wrong at all. That these protocols are easily the most pervasive used by IoT devices, designed with apparently little thought given to security at the time and yet used in mission critical deployments in most smart factory manufacturing environments as well as throughout flagship smart city projects, is a major cybersecurity risk.

I contacted Bharat Mistry, principal security strategist at Trend Micro, to chat about the findings. He told that because CoAP is a more recent and less widespread protocol than MQTT, its design is less flawed. He also warned that, despite this, CoAP protocols remain susceptible to IP spoofing which is where criminals can pose as legitimate or anonymous end points in order to capture data. When it comes to the more widespread MQTT protocols, the most prominent flaws are "undoubtedly its payload remaining length, the Unicode handling in topic strings and its URI-style topic validation" Bharat says, continuing "all of these have provided a pathway for vulnerabilities to emerge which have inadvertently been implemented on a global scale."

It's the global nature of the impact of these flaws which is truly hard to comprehend, not least as Bharat points out neither of the protocols were ever intended for deployments over public networks or designed to carry sensitive data. "The intended use for these protocols are for environments that are typically closed or private" he explains, adding "used to transport control data over networks that are low bandwidth, high packet loss and low powered and in some cases very distant." They were also designed to work on devices with very limited CPU and memory 'compute' power so designed to be very lightweight with little or no overhead for meaningful security features. All of which means that the real-world security implications to large-scale deployments across large enterprise, industry 4.0 manufacturing and smart city projects is massive. "If even just one internal device is accessible via public-facing IPs, it can compromise the entire security infrastructure in place and leave the door wide open for bad actors to take control of these devices and gain access to a network" Wallace Sann, VP of global systems engineering at ForeScout told me.

So what can be done to mitigate the risk from these inherent protocol flaws? Dr Jacqui Taylor, CEO and co-founder of FlyingBinary is also a strategic advisor to the UK Government on smart cities and part of the UK Centre for the Protection of National Infrastructure team. She explained to me that a large part of the problem is that when considering the IoT, traditional security approaches are not appropriate as fundamentally IoT is an engineering challenge. "IoT in any domain needs a layered approach to security which does not assume some form of command and control integration" Jacqui explains, continuing "in reality if the assumption is that each connected device will need to be secured this is doomed to failure." And she should know as she has written the British Standard to articulate this for smart cities, which is currently being fast-tracked to an international standard. "I will be speaking on this and the future of the Cyber Security industry we will need at Davos in January" she says. So, when it comes to mitigation best practice the entire value chain in each use case needs to be considered to solve the problem according to Jacqui. "Like all IoT use cases, the enterprise, factory or smart city will need to be cloud first" she explains, adding that this this really needs to be done at the outset. "The services and data in the IoT ecosystem will determine the layers which need to be implemented to curate and evidence the security and privacy controls which have been implemented" Jacqui insists, concluding "this is particularly important for European data which is subject to new legislative and regulatory regimes."

I reached out to the wider cybersecurity community to see what other mitigation advice was forthcoming, the answer was a lot but not all of it very reassuring it has to be said. Trying to prevent vulnerabilities in protocols altogether is a noble pursuit, says Dr. Zulfikar Ramzan, CTO at RSA Security, who added it was also "ultimately an exercise in futility." Instead, he recommends that organizations "embrace a holistic risk-driven view that considers both the likelihood of vulnerabilities being exploited and the corresponding probable impact." Unfortunately, while proper governance is crucial to the security of M2M deployments it is also often overlooked when it comes to smart cities according to Matt Lewis, research director at NCC Group who argues this is largely because it's unclear who the CISO actually is. "By assigning clear risk ownership and direction for setting security policies and baseline standards" Matt insists, "the risk of deploying these devices with a lack of security measures can be mitigated."

Dr Guy Bunker, SVP of products at Clearswift, explains that the weakest point in the chain is most vulnerable to attack. "Injecting false data into the system upstream can create undesired impacts on end devices" he says, adding "this might not be a simple on/off type of command, but may well be ones which push the limits of the device." So, for example, pushing a pump to 100% but then leaving it at that setting such that it burns out. "Verified authentication and authorization is one part of the solution" Guy advises "but we all know that credentials can and will be compromised at some point, so additional measures need to be taken to protect systems and infrastructure based on that assumption." And finally, don't underestimate the blockchain is the advice from Prakasha M. Ramachandra, AVP of technology and innovation at Aricent, who recommends that organizations should "adopt blockchain based distributed apps (DApps) that can utilize federated learning to highlight or take action in semi-automated ways for the anomalies detected in IIoT assets." Prakasha also thinks that leveraging blockchain smart contracts to develop capabilities like identity-aware dynamic access control for IIoT devices is worthwhile. "Despite all the hype and negative press" he concludes "blockchain is certainly worth considering!"


Source link

No comments