The Age of IoT Is Here – Is Your Enterprise Secure?

The Age of IoT Is Here – Is Your Enterprise Secure?

Whether you were ready for it or not, your network is likely supporting hundreds if not thousands of connected endpoints at this very moment. When we talk about IoT, especially in the enterprise, we’re not just talking about connected refrigerators anymore. IoT is powering manufacturing lines, medical devices, and entire cities.

The possibilities for IoT have never been greater, and neither have the stakes. Just look at what happened in 2016 when Mirai, the infamous IoT botnet, took down major websites like Netflix, Twitter, and Amazon via a massive distributed denial-of-service attack using hundreds of thousands of compromised IoT devices.

Nonetheless, 2018 will be the tipping point for IoT in the enterprise with nearly half expected to deploy IoT solutions by the end of the year. What has made the explosion of IoT adoption possible is also its Achilles heel? The diversity and volume of device manufacturers, platforms, and use cases have made it nearly impossible to standardize any type of security controls. Many device manufacturers don’t even prioritize security, often because their customers don’t. The onus, therefore, is and will likely continue to be on the consumer – whether that’s an individual or an enterprise.

A lack of standard security controls isn’t the only thing standing in the way of securing IoT environments. IoT environments look different than traditional enterprise networks. They’re inherently more complicated and fragmented, requiring a different approach to security architecture. This also makes it much more difficult to have visibility and control over every connected device. Industry standards and regulations are just as fragmented and obscure. Many organizations have published their own set of best practices, but there is not a universally agreed upon standard as of yet.

To that end, Kudelski Security has spent the last year researching the current state of IoT in the enterprise and the best practices for securing it. The findings are presented in our IoT Security Reference Architecture, which is designed to help enterprise security teams build a strategy for secure IoT deployments using a combination of people, process, and technology.

Inside the architecture, the team provides an overview of the differences between IoT and traditional network environments; the IoT security threats, challenges, and business impacts enterprises face; IoT security best practices at the people, process, and policy level; and the security controls and technical measures IoT enterprises should have in place.

The reference architecture takes into account numerous security guidelines and standards, with the two primary sources of inspiration being ENISA’s Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures and the Industrial Internet Consortium’s Industrial Internet of Things Volume G4: Security Framework. (A full list of IoT guidelines is available in the report.)

This guide is best-suited to organizations who already have IoT devices deployed in their environment. We recommend comparing the best practices presented in the architecture with existing security controls to identify security gaps or complementary technology solutions to improve IoT security efforts.

To download the IoT Security Reference Architecture, click here.


The Business Case for Resilient IoT Security – Review of New Research

The Business Case for Resilient IoT Security – Review of New Research

IoT and a Growing Attack Surface

There is no doubt that the IoT brings with it tremendous opportunities to deliver more and richer data to drive operational efficiency and smart decision making.  But as IoT devices proliferate, they also increase the overall attack surface and expose organizations to additional threats. It has always been clear that it is far more cost-effective to implement good data security during the design phase of any product or system, and exponentially more expensive to fix it after there’s been a breach. Even though IoT security has been commonly recognized for years as one of the key barriers to successful IoT implementation, many management boards have yet to make the necessary investment in it.  So how does a product manager or security officer justify the business case for implementing the right level of IoT data security from the start?

Now thanks to new research released from the Ponemon Institute and IBM this month, those costs can now be quantified based on the real-life experience of 477 different companies who have gone through data breaches themselves, and the scope and cost of the problem can be better understood. In summary, the bad news is that the implementation of IoT devices has indeed increased the attack surface and the overall cost of recovery from data breaches, but the good news is that organizations implementing robust data encryption and incident response services have significantly lowered the cost of those breaches. Let’s look at some of the highlights in more detail.

IoT Data Breach Trends 2017-2018

More than 2000 IT and compliance professionals whose companies had suffered data breaches over the past 12 months were interviewed for the study.

  • They reported that the total cost of an average customer data breach was a staggering US$3.86 million.
  • That’s a year-over-year cost increase of 6.4%
  • The average cost per stolen consumer record of $148.
  • For healthcare, that figure skyrockets to a whopping $408 per lost or stolen patient record.
  • Companies making extensive use of IoT devices saw the average cost per stolen customer record increase incrementally by $5, suggesting indeed that deploying IoT devices can tangibly increase the risk of data loss.

That said, organizations who had taken proactive measures to encrypt most of their data (whether coming from their IT or IoT infrastructure) saw the average cost per stolen record adjusted down by $13, while those who had strong incident response (IR) capabilities – either in-house or with trusted third-party cybersecurity experts – were able to generate another $14 savings per stolen record. That suggests that an organization employing both capabilities might save more than 18% on the cost of a data breach. That means a savings of $700,000 on an average breach. And the survey further shows that companies who have had a single material breach have a 27.9% chance of suffering from an addition breach within the following two years, driving the breach costs (but also the potential savings of good security) even higher.

But we have now also entered the era of the “mega-breach”, according to the report. Ponemon measured for the first time the impact of breaches of between 1 and 50 million records and showed that they had a cost of $40 million and $350 million respectively. When companies invest in IR and encryption technologies for this type of volumes, the savings generated run far into the millions of dollars.  How many records do you have and what would be the total costs to you of such a breach if your company were to suffer one? That’s important to know and contributes directly to your IoT and cybersecurity business case.

Justifications Beyond Data: the Kudelski Group Analysis

But even with this excellent justification for IoT security investment, data breaches are only one potential factor that should be considered as part of the overall business case. Our experience at the Kudelski Group is that devices can also be compromised if not properly protected and could by hijacked by botnets designed to launch distributed attacks on popular websites or services. They could also be hacked to provide false data to their owners, which in the case of industries like power, health care and energy could cause serious productivity, availability, fraud, damage or – even worse – safety issues. The same is true in reverse, where unauthorized commands mistakenly accepted by insufficiently protected devices could cause them to behave in ways that are dangerous – think automotive, aviation and smart buildings. These device security scenarios must also be considered when creating the business case for IoT security but were not the subject of this study.

All the elements discussed so far fall under the category of “risk mitigation”, and while they are very compelling and must be considered, IoT also brings great promises of new features, new business models and operational efficiencies that positively and directly impact the bottom line. Organizations should rightly include (realistic) forecasts for value that IoT will add to the business over the long term. When all these factors are combined, we believe that the justification for a management board to invest in the proper design and implementation of robust, sustainable IoT device and data security as well as managed security and incident response services is overwhelming. And that’s why some of the world’s most recognized and security-conscious brands are already working with us to secure their connected futures.


Black Hat USA 2018 Presentation Picks

Black Hat USA 2018 Presentation Picks

As Black Hat continues to draw closer we wanted to take a moment to highlight some talks that we are excited about. There is a lot of great content, so picking just a few was difficult, but these are the presentations that I and some of my colleagues are looking forward to attending.


AI & ML in Cyber Security – Why Algorithms are Dangerous

By Raffael Marty

The topic of AI disciplines is one I spend quite a bit of time talking about myself. It seems you can’t turn anywhere these days without encountering some product claiming to use a subset of AI in some “advanced” way. A healthy dose of real-world challenges helps cut through the marketing hype and get to core issues. This talk is a much-welcomed reality check.


Blockchain Autopsies – Analyzing Ethereum Smart Contract Deaths

By Jay Little

Blockchain technologies aren’t just for cryptocurrencies. This technology is gaining more and more acceptance in the business world and being used or evaluated to solve a range of business challenges. Blockchain technologies aligned with business challenges, like Ethereum Smart Contracts, have a higher chance of success and longevity. Understanding how these contracts work as well as the various risks they present, is critical.


Applied Self-Driving Car Security

By Charlie Miller, Chris Valasek

Come on, who doesn’t love the thought of hacking self-driving cars? What’s even better is getting this information from the experts on the subject. In the not too distant future, we will share the road with people taking a nap, eating lunch, and texting. Okay, we do that now, but in the future people may not have control of their cars the way they do today. Highlighting these risks now helps us avoid running  into them tomorrow. This presentation promises to be informative and entertaining.


Understanding and Exploiting Implanted Medical Devices

By Billy Rios, Jonathan Butts

Self-driving cars are one thing, but IoT gets scarier when it’s inside your body. Increased attack surface from a device inside your body is the stuff of nightmares and Hollywood movies. This presentation promises to shed light on these risks.


WebAssembly: A New World of Native Exploits on the Browser

By Justin Engler, Tyler Lukasiewicz

WebAssembly is a technology supported by all of the major browsers that allows for the compilation of languages like C, C++, and Rust for the web. WebAssembly makes a promise of better performance and increased security, but is it a lot of hot air? This talk highlights this technology and the security risks it introduces.


Squeezing a Key Through a Carry Bit

By Filippo Valsorda

Although this presentation isn’t some destruction-of-the-Internet-style vulnerability, it demonstrates a great example of why no small bug should be ignored. In an amazing feat of crypto engineering, by exploiting a single bit bug, the presenter shows how a cryptographer’s worse nightmare comes true. Secret keys can be recovered in about 500 submissions on average. Don’t miss this highly technical talk on the cryptography track that shows a small bug can yield a big result.


Kudelski Security Events

We also have a few events happening while we are out in Vegas.

Join us for our Kudelski Security Bash party Tuesday night from 6-9pm in the Foundation Room at Mandalay Bay.

We are also doing a couple of breakout debriefs from 4:30-6pm on Wednesday, August 8th, and Thursday, August 9th. Wednesday’s session is on IoT and Operational Technology security. Thursday’s session is on Blockchain. Use the following link to RSVP for these sessions.


If you are hanging out for Defcon as well, check out our presentation:

Reaping and Breaking Keys at Scale: When Crypto Meets Big Data

Presented by Yolan Romailler and Nils Amiet.

In this talk, we show how we collected over 300 million public keys leveraging our scanning infrastructure and our open source fingerprinting tool, Scannerl, and tested them for vulnerabilities such as the recent ROCA vulnerability or factorization using batch-GCD. We performed this analysis on a 280 vCPU cluster and are able to test new keys against our dataset in just a few minutes thanks to a novel in-house distributed implementation of the algorithm. As a result of our research, we could have impersonated hundreds of people, mimicked thousands of servers and performed MitM attacks on over 200k websites. Fun stuff.

If you see any of us around the week after next, say hello. See you at Black Hat and Defcon!

Move Over Functional Obsolescence: Cybersecurity Is Driving Lifecycle Management For Connected Medical Devices

Move Over Functional Obsolescence: Cybersecurity Is Driving Lifecycle Management For Connected Medical Devices

As CIO’s and CISO’s who walk the halls of healthcare institutions know all too well, the number of devices being enabled in the Internet of Things and Internet of Medical Things around us is exploding exponentially. With this explosion, complexities arise in security, data collection, storage, and especially lifecycle management. Devices have varying degrees of security and lifespans that range from two years up to 15 years, adding complications to management strategies.

Medical devices are the next perfect storm as a security threat vector and lifecycle management is now becoming predicated on risk and security vulnerabilities within the legacy device ecosystem. Hackers increasingly turn to medical technology used by providers as the next mechanism to commandeer and attack networks and hold organizations for ransom. Medical IoT devices are connected to a vast array of sensors, monitors and numerous applications making them an ideal entry point into the larger hospital networks and an easy way to propagate attacks to other systems.

The FDA started to make cybersecurity a priority in 2013 as a requirement for connected medical devices; however, due to the long development cycle of these devices and long time to get certified for use in the market, the rollout is slow. This will result in a significant lag in the introduction of connected devices that have embedded cyber threat resilience components that can thwart modern threats. This creates an incredibly complex lifecycle management challenge for healthcare technology.

Cybersecurity challenges are now becoming the primary driver for lifecycle management of medical technology. Older compromised systems present a sizeable risk to cybersecurity and leave every member of the C-Suite asking how to tackle this challenge. Often these systems have little to no update capabilities, are outside of vendor support or have been replaced with newer, better supported product lines. Vendor support for cybersecurity vulnerabilities typically takes time to create, test and patch before they can be deployed across the entire device population. As an example, an EEG monitor has a typical lifespan of 10 years. During that period security vulnerabilities will change and morph making it difficult for manufacturers to keep pace with the cybersecurity threat landscape. Even worse, securing these devices ultimately rests on the provider.

One must keep in mind that vulnerability testing is complex because of the various systems, subsystems and chipsets that are embedded in these devices. Most organizations simply do not have a $10 million budget to create a lab or staff who has the functional expertise to effectively perform hardware and software vulnerability testing with the rigor required to pass a security audit. Organizations must hire vendors who have the needed technical expertise, specialized staff and equipment in ferreting out vulnerabilities in purpose-built devices. It is not enough to perform a software scan on a device and assume it is secure.

So what approach should an organization take to lowering their risk on medical devices with varying usable lifespans and cybersecurity protections?

Evaluate Your Environment For Risk

  • Identify devices that are end of life. These devices will have no updates released, which exposes them to risk. Furthermore, discovered vulnerabilities may not be announced by the company. We recommend you replace these devices with supported systems.
  • Identify systems that are no longer covered by service contracts or lack current operating systems capable of being secured. This issue is similar to devices that are end of life, and should also be replaced or covered by a new service contract.
  • Audit prospective vendors security, patch management and cyber-security countermeasures to ensure satisfactory risk mitigation
  • Contract for penetration testing of on premise devices. It’s important to cover both the hardware and software of the device in this assessment.
  • Consider WIFI, Bluetooth, SD card and proprietary RF interfaces as potential areas of compromise on devices. Ensure there are controls in place to monitor and protect devices over all communication protocols. Disable protocols that are not in use if possible.
  • Create a risk profile for each device used in your environment and a risk score and then prioritize based on that risk creating a lifecycle management posture rooted in security.

Global Risk And Compliance

  • Have an action plan: Create standard operating procedures for what to do when medical devices are compromised
  • Create a risk framework for each device to determine what to do if a device is infected with malware or has been compromised by a hacker
  • Include medical devices in your governance plan to ensure that compromises are dealt with at an appropriate level and escalation paths are included
  • Ensure you have logs for each device with current firmware versions, patches, etc. and ensure you have a process and policy to perform medical device updates.
  • Create Incident response plans specific to breaches involving medical devices and have a team assembled. Include retainers for breach mitigation and post-mortem cyber forensics.

By implementing and monitoring the product lifecycle, leaders, CSOs and CISOs can better plan when to introduce new operational technology in the environment. Ensuring that each of these devices will not negatively impact your operations is critical for continuity of care and allowing for the transformative delivery of healthcare services and improved patient outcomes. Implementing a lifecycle management approach to medical device refreshes rooted in a security framework will allow providers to keep pace with the rapidly evolving threat landscape that is currently plaguing the industry, while ensuring compliance and minimizing security threats and vulnerabilities in the process.

Cyber-Attacks and the IoT Landscape: Botnets and Why Getting Your IoT Security House in Order Matters

Cyber-Attacks and the IoT Landscape: Botnets and Why Getting Your IoT Security House in Order Matters

Iot Security and BotNets are a hot topic right now because of several high-profile attacks. On September 20, 2016 Brian Krebs security blog was the victim of such an attack. One of the largest attacks recorded exceeded 620 gigabits per second(Gbs.).[i]

After the Mirai botnet was declared the major culprit in the largest DDoS attack in history it became evidently clear that IoT was the next battleground on the front against Botnets.  Striking at the core of Dyn a major domain name service company this botnet wreaked havoc in a 3-wave attack. It shut down major sites across the internet, gaming networks and other online services. “Attackers used the Mirai botnet to overwhelm Dyn’s DNS servers with a whopping 1.2 terabits per second of traffic. Dyn’s DNS servers couldn’t respond to legitimate DNS queries under the load, which rendered Dyn’s customers — including the New York Times, Reddit, Tumblr and Twitter – unreachable”[ii] As we look back through the annals of IoT breach history operational technology systems, consumer devices, medical devices and industrial control systems pose some of the highest risks to be taken over and enlisted as a zombie horde of devices just waiting to unleash havoc on networks with increasing frequency.

In February of 2017 a new threat emerged rooted in a multi-vector attack. A Windows Trojan that harbored IoT attack code was detected in the wild by malware researchers. It essentially looked-for vulnerabilities in Windows computers, infected them with a trojan horse that then scanned for vulnerable IoT devices infecting them with a variant of Mirai IoT botnet code. Why is this important? A computer infected with the trojan is sitting behind the firewall. Now it is scanning for vulnerable IoT Devices behind the firewall effectively circumventing the firewall and intrusion detection systems and taking command of the devices inside your network to launching a DDoS attack from inside your own network or worse.  Now machines can orchestrate a DDoS attack using SSDP because they have already successfully bypassed the firewall and other defense mechanisms.

The challenge however is that SSDP can lead to a 30x amplification of the attack. The Windows Mirai Spreader essentially flipped the script on what we believe to be innocuous devices on our own internal networks. This invariable will gain more importance as IoT 4.0 implementations happen in buildings, cities, industrial controls and vehicle networks. As attackers grow more sophisticated in their approaches we are not beyond the realm of polymorphic IoT attacks targeting command and control server environments causing servers or devices to return adaptive malicious code which fits the specific task it has been assigned to do.

Ever increasing complexity of the delivery systems now poses an even greater threat. Imagine you are a hospital with thousands of medical devices connected to your network.  Someone infects those devices and they launch an internal DDOS attack against the network. Suddenly your operational systems are shut down at a hospital crippling scheduling system, billing systems and other infrastructure and thereby causing the facility to have to shut down. It would no longer be able to schedule procedures to occur and even worse force the relocation of patients to other facilities. The potential is there for a Botnet to become the delivery mechanism for crypto lockers. Essentially ransoming medical devices, operational controls, elevators or any device within the IoT realm. The effects on facilities could be catastrophic and even potentially life threatening.

Now we are facing Reaper. It is gathering a horde of devices. It is estimated that Reaper has over 2m troops and it could grow to 3.5m or more. It is currently growing at a rate of 88k a day according to Krebs on Security. Much of Repear is built on the same foundation as the Mirai botnet which was incredibly successful. The approaches of each are different.  Mirai used a known list of default passwords to compromise IoT devices and turn them into an army of DDoS troops. However, Repear appears to be much more methodical in it’s approach. It is constantly trying numerous weaknesses until it infiltrates the machine. Reapers method is faster and easier, and it can learn new vulnerabilities as it discovers them. Checkpoint believes that attacks were coming from many different countries totaling approximately 60% of corporate networks which are part of the ThreatCloud Global Network.[iii]

Although the author of Mirai was recently identified and arrested and sentenced the author of the Repear botnot is unknown. Therefore, it is better to be safe than sorry and anyone with IoT devices should investigate their safety as soon as possible. As leaders responsible for stopping threats to operational technologies, IoT systems & devices and ensuring the overall security of your network you must take steps to ensure you minimize the risks from IoT devices & Botnet attacks

Recommended steps should organizations take to secure IoT devices:

  • Conduct security evaluations of all IoT hardware being used both inside and outside the firewall including testing the physical hardware for vulnerabilities, whitebox testing software, and penetration testing your IoT network and devices.
    • Start at the bottom at the chip level. Cases have already shown nefarious code implanted in chips. Perform hardware penetration testing at the chip and board level.
  • Limiting remote access to the devices to only administrators.
  • Ensure you have strong authentication mechanisms if remote access is needed. Strong unique non-sequential passwords for devices and include a second authentication factor.
    • For administrator and user services require strong authentication to systems and supporting software.
  • Include logic to verify updates before any changes to the devices are made to ensure only authorized software and firmware are used.
  • Utilizing an MSSP to manage security of IoT devices to better react to threats and stop any exploit before it becomes more prolific and attacks non-IoT portions of your network.

[i] KrebsOnSecurity: KrebsOnSecurity Hit With Record DDoS

[ii] Forbes Technology Council: Distributed-Denial-Of-Service Attacks And DNS

[iii] Checkpoint Research:  A New IoT Botnet Storm is Coming

Getting IoT Security Right: Lessons from Other Security Conscious Markets

Getting IoT Security Right: Lessons from Other Security Conscious Markets

IoT security has been a “topic” for the past 24 months with many articles and conferences expanding on the belief that the biggest single obstacle to growth in this industry will be the lack of a comprehensive solution to secure IoT devices. While interesting as a headline grabber this observation does not really help to advance the topic and therefore this article seeks to draw parallels with other industries that have historically had reason to pay strong attention to security over the years. Understanding the technical and commercial structure of these markets should (in theory) indicate a direction that IoT device manufactures can start looking in their quest for security.

So which industries are we talking about here? Well traditionally high security has been synonymous with the use of smart cards and industries seeking highly secure solutions have relied on smart cards to protect their applications. In terms of applications this has ranged from bank applications where smart cards have been used in payment cards and credit cards, to telecommunications where smart cards (in the form of sim cards) have been used to secure the secrets required for terminals to access mobile networks and also network access where PKI has long been the solution of choice for highly sensitive network access and lastly but not least the market of Pay television where many of the worlds’ leading television operators have relied on smart cards to control access to their television content.

Smart cards are designed to resist attacks from the most determined pirates and as a consequence these industries have (in the large part) resisted even sustained efforts from organized criminals to undermine the business and have flourished with the use of smart cards being widespread in the above industries Smart cards provide a secure place for data and algorithms that need to remain “secret” in order to avoid counterfeit and pirate solutions becoming widespread.

However, in addition to the technical benefits on which we will further expand later in this article, smart cards also provide a commercial delimitation between a device manufacturer and the operator (or owner) of a particular service. This is very important to integrate when we consider IoT device security. The question of “who is responsible for what” is one that needs to be unequivocal and in the historical world of smart cards this was a by-product in the sense that the companies providing smart card technologies were effectively different companies than those providing the devices themselves. Therefore security responsibilities were distributed de-facto and when pirate attacks occurred (as they inevitably will) service operators knew to whom they could turn for support. Mobile network operators turned to their sim vendors, TV operators to their CAS suppliers, network administrators to their PKI card provider etc. These vendors were (and remain) acutely aware of their responsibility in keep the aforementioned services secure and provided long term security expertize to their customers. These vendors were (sometimes implicitly) the de-facto “security vendor” ensuring long term (in some cases decades long) security.

Cut to IoT and we see few parallels with these secure industries. Firstly many IoT devices seem to be designed with security as an afterthought and very few seem to consider the use of specialized hardware for security. Yes, many of the IoT silicon vendors are positioning with “security” as a selling point for their silicon in the hope they can differentiate what is often a low complexity (read low margin) business despite the massive IoT hype but even designing security into IoT chipsets does not even begin to equate what happened with the provision of smart cards as the security features are tightly coupled with the functionality of the device and indeed there is no way for a 3rd party to be assigned as the “security vendor”. This trend to LSI (large scale integration) is driving consolidation in the chipset industry (i.e. Qualcomm / NXP tie-up) leading to more integrated solutions with less vendors. This obviously has benefits in terms of overall device cost but it also has consequences in terms of traditional role and responsibility breakdown. Whereas in the past security was separated in separate smart card or secure element chipsets, it is now expected to be combined with the application chipsets leading to an impossibility for traditional security vendors to guarantee the long term security of a given solution and therefore confusion on the question of who is responsible for this.

Is the IC vendor the long term guarantor of the system security? If so they probably need to consider changing their current business models to support applications long after their original deployment. We have seen time and time again that once chipset vendors sell their solutions they don’t consider it their long term responsibility to support future software upgrades and security enhancements. We only have to witness the speed at which software upgrades to remedy serious security vulnerabilities in IoT (add a few references here) are delivered to realize that the “old” paradigm of “separated” security made sense from both a technical and commercial perspective. An interesting recent development has been the Intel decision to spin out its McAfee security business from its chipset group. It’s interesting because while Intel correctly identified the need to improve security and made the (big) decision to invest in acquiring McAfee it appears now to realize that the security and chipset business dynamics are not aligned. Maintaining long term security simply does not fit with the chipset “sell and move-on” business.

So what does this mean for IoT security? It means that device vendors and service providers need to ask themselves fundamental questions on security which will impact the security architectures and choices they will make. They need to consider if they require a “security vendor” as a partner and if so what exactly they expect from this security vendor.

From a purely technical perspective we can expect IoT devices to come under attack via the same vectors already experienced in the traditional smart card industries. This means withstanding attacks such as Differential Power Analysis (DPA) which is monitoring of a device’s power consumption to ascertain when secret keys are being used, using electrical glitches and laser glitches to disturb the correct operation of a device in order to make it malfunction and generate errors that can be used to dump its internal secret keys and algorithms. Attacks such as the above are “table stakes” in serious piracy with the ante being the use of sophisticated tools such as a Focused Ion Beam Microscope (FIB) to modify electronic circuits and their protection circuits in order to extract secret keys and algorithms. Even the most advanced chipsets are challenged to withstand such attacks and it is a question of “when” not “if” such attacks will be used against IoT devices. If IC vendors are serious considering positioning themselves as security vendors then they need to be capable of addressing the above concerns in a manner that generates a viable and sustainable model for themselves and their customers.

So let’s assume for the moment that service providers integrate the concept of identifying a party responsible for security and try to determine what options are open to such a 3rd party to really secure applications long term. Obviously a long term partnership on security architecture with key chipset vendors and the ability to influence their designs would be required. The ability to provision produced devices either in the fabrication process or over-the-air (OTA) with secrets would also be required, again requiring collaboration and partnerships between the security vendor and the IC vendor. The ability to quickly update code on deployed products in case of piracy would be essential and the ability to constantly monitor (via in-field diagnostics) any deployed products to anticipate potential security compromises (by using techniques such as artificial intelligence based behavioral monitoring techniques for example).

A 3rd party security vendor may also require proprietary security mechanisms embedded into the silicon in order to activate counter-measures (as has historically been done with smart cards) in the event of a security breach. Cryptographic algorithms and other elements may be changed in-the-field on deployed products to counteract piracy on deployed devices. This would require a strong collaboration on design between IC vendors and security vendors in order to align on the required features.

Is such collaboration likely to happen? In some industries it is already happening and whether it becomes the norm in the IoT will depend greatly on the decisions made by service providers when they chose their partners and IC vendors. Sometimes at the outset it may appear efficient to select a “one-stop shop” solution but a judicious reflection needs to consider the long term and a key question is “who do I call when bandits knock at my door?”

More and more new business ideas are rooted on data and the exploitation of date and the value of this date is often difficult to calculate. In security often the most pertinent question is not when or if but rather “why” and this why depends often on the value that can be obtained by manipulating a particular device. This “why” is a tough question to answer also as the value of the secret is very application dependent. Taking the example of the famous coca cola formula we can easily understand that if a business model is dependent on keeping something unique (which the best business models often are) then the value that can be extracted by obtaining the secret is potentially immense. This means that each application provider needs to understand the value of what he considers his “secret sauce” and how this remains unique over time. He needs to select a partner that he believes will be a long term security advisor and whose business model is compatible with the value that the application provider is hoping to secure.

In summary, IoT device makers and service providers are invited to consider two very important axes that may at the outset be seen as tangential – technical ability to withstand both “table stakes” and “increased ante attacks” (DPA, CPA, FIB, EMC etc.) and commercial business model alignment around long term security maintenance. Selecting a security vendor who has the ability and relationships to execute on the required technical features to provide a long term maintainable security is crucial. Once these types of questions become seriously considered in the IoT market we will start having serious solutions and stop having pointless debates about the security risk without any serious debate on underlying issues.