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.
Iot Security and BotNets are a hot topic right now because of several high-profile attacks. On September 20, 2016 Brian Krebs security blog krebsonsecurity.com 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
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.
The Internet of Things, and now the U.S federal government along with it, have a problem. Devices are smart enough to impact the world around them, but aren’t built smart enough to protect themselves. In the recent past, these devices have been maliciously commandeered to bring down large swathes of the Internet, steal sensitive information, send spam emails, spy on individuals, and bring a whole city to its knees.
The first step in solving a problem is admitting you have one, and the Senate took this step with the introduction of the “Internet of Things Cybersecurity Improvement Act of 2017”.
The new legislation introduced by Sen. Mark Warner and Sen. Cory Gardner, sets minimum standards for the manufacturing, deployment and maintenance of IoT devices purchased by the U.S federal government. It received inputs from technology experts at the Atlantic Council and Harvard University to address cyber attacks that leverage IoT devices. The bill is aimed at responding to the “obvious market failures,” said Warner in an interview with Reuters and also to prevent further intrusions into federal systems “without halting the life-changing innovations that continue to develop in the IoT space,” said Gardner.
The key provisions of the bill are:
- The manufacturer or the contractor of the device to the federal government must provide a written certification bearing, but not limited to the following:
- No known vulnerabilities are to be present at the time of delivery of the device. If present, mitigation strategies are to be disclosed to the agency in detail.
- Any updates to the device (inclusive of hardware, software and firmware) are to be properly authenticated by means such as digital signatures.
- The devices are to use only non-deprecated industry-standard protocols and technologies.
- The devices will not have fixed or hard-coded credentials such as usernames, passwords, tokens, cryptographic keys and other authentication primitives and that these credentials will not be modified or revoked by the user or manufacturer, except via an authenticated firmware update.
- The U.S federal government and associated agencies are to outline policies and procedures for conducting cybersecurity research on Internet-connected devices and safeguards for such well-meaning and good-intended researches from criminal liabilities or penalties.
- Finally, that if an existing third-party security standard for Internet-connected devices provides an equivalent or greater level of security, an executive agency may allow a contractor to demonstrate compliance with that standard in lieu of the requirements followed by a written certification that the device complies with the security requirements of the industry.
Assuming this bill passes, what does this mean for enterprises purchasing IoT devices? In theory, the purchasing power of the federal government should lead large IoT manufacturers to start following these minimum security standards, which would benefit all companies by default. However, an enterprise should not assume this to be the case. Companies should use the key provisions in the Senate bill as guidelines to discuss with their device manufacturers before a purchase. Ask your suppliers if they meet these provisions, and if not, where they have gaps and what their plan is to fill them.
For device manufacturers, this bill will affect your approach to security. Let’s look at each requirement and its possible ramifications:
- No known vulnerabilities are to be present at the time of delivery of the device to the federal government:
There are several nuances in this point that should be explored. First, a vulnerability must be known to be covered by this provision. It’s not perfectly clear if it is specifying if the word ‘known’ means ‘publicly known’ or just ‘known by the company’, but I would guess the latter. Assuming it’s known, the company has two options: fix it or report it at procurement time along with mitigation strategies. Taking this into account, what is the incentive for manufacturers to perform detailed security testing? This is where the provision on cybersecurity research comes in. Since cybersecurity research is encouraged, it is likely someone will find vulnerabilities in your products. It is generally in the company’s best interest to find vulnerabilities internally and patch them rather than have a vulnerability exposed publicly.
Finding vulnerabilities in IoT devices includes software vulnerabilities, but there are also key hardware tests that should be performed. IoT hardware testing involves attacks such as side channel attacks, fault injection, imaging and IC modification. The testing process also involves source code audit, deobfuscation testing, fuzzing, cryptography implementation audit, software vulnerability verification, assessment of long-range wireless IoT protocols and of short-range communication protocols. The assessment process can be daunting to device manufacturers, but some IoT security solutions companies have the skills and experience to perform advanced hardware penetration testing (device, application, network) while leveraging proprietary security schemes and security intelligence.
Remember that device manufacturers do have the option to mitigate vulnerabilities without fixing the root cause. The vulnerability and mitigation strategy need to be disclosed at the time of delivery. In general, the manufacturer should continue to work on mitigating the vulnerability completely and integrate it into their future upgrades to the device, if applicable.
- Any updates to the device (inclusive of hardware, software and firmware) are to be properly authenticated by means such as: digital signatures: This provision is relatively straightforward: updates should be authorized and authenticated before they are applied to the device. There is no language that indicates this is a reference to over–the-air updates only, so even locally initiated updates need to be secure. Generally, authentication uses digital signatures, which can be challenging to implement correctly at scale. Device manufactures that lack expertise to implement or assess the implementation of PKI could rely on security solution companies to provide key management solutions that involve online and secure generation of device keys. Alternatively, device manufacturers can use third-party solutions to manage their updates that provide authentication.
- The devices are to use only non-deprecated industry-standard protocols and technologies: The federal government expects the device manufactures to adhere to industry security best practices for the manufacturing of the devices and hence, on those grounds, the device manufactures would need to stay abreast with the current trends and practices in the field of cybersecurity. Although it is best practice to use the latest version of protocols and technology if possible, this provision only prohibits deprecated technology (such as the MD5 algorithm). Device manufacturers could rely on technology consulting or security advisory companies for guidance in implementing these solutions.
- The devices will not have fixed or hard-coded credentials such as – usernames, passwords, tokens, cryptographic keys and other authentication primitives and that these credentials will not be modified or revoked by the user or manufacturer, except via an authenticated firmware update: Hard coded and global credentials have been the root of many IoT security incidents in the last two years. This provision ensures that keys and credentials can be changed or rotated, and hopefully are not set globally on all devices (although this isn’t technically in the provision). It also mandates that any changes to credentials be done in a secure fashion. Rotating device secrets securely at scale is a challenging undertaking, and should be approached with care. There are IoT platform vendors that provide this service today, and unless a manufacturer already has an infrastructure to support this, they should consider using third-party support.
- To outline policies and procedures for conducting cybersecurity research on Internet-connected devices and safeguards for such well-meaning and good-intended researches from criminal liabilities or penalties: Cybersecurity research usually involves breaking into things (this involves open source and proprietary devices, protocols, softwares, hardwares, etc.) and anything that requires breaking without prior notice or permission may be considered a crime. While the procedures to obtain permission can be rigid and expensive, it leaves little room for cybersecurity researchers to perform experiments and studies and to provide the best security measure to safeguard devices. This in turn, results in limited knowledge among device manufacturers about the best way to secure the devices. By being more open to cybersecurity research on IoT, the device manufactures could invest into cybersecurity research and the IoT community as a whole stands to benefit from the outcomes of the research as has been in the field of digital media (robust watermarking and anti-piracy technologies have morphed and evolved through over decades of research and experiments)
- Finally, that if an existing third-party security standard for Internet-connected devices provides an equivalent or greater level of security, an executive agency may allow a contractor to demonstrate compliance with that standard in lieu of the requirements followed by a written certification that the device complies with the security requirements of the industry: This provision allows the device manufacturers to employ third-party institutes to evaluate and certify their devices from a security perspective. One example of a device certification is the CSPN from ANSSI (L’Agence Nationale de la Sécurité des Systèmes d’Information).
Though the proposals and guidelines will later be detailed by NIST and other related federal agencies (provided the bill is passed), it is a safe bet to say that IoT security is imminent. Through rapid and educated investments in advanced labs and strong R&D base, device manufacturers can be uniquely placed to meet current and future security requirements of this fast-growing industry. Alternatively, device manufacturers also have several options to partner with IoT security solution companies that provide in-depth security assessments and evaluations of IoT products allowing the device manufacturers to identify and address security vulnerabilities before products go to market, and helping ensure their company doesn’t become the next big cyberattack headline.