security and IoT

copyright ©2016,2019 arden henderson

for the want of a (digital) nail

Loosely paraphrasing the famous centuries-old proverb [1],
a timely update herein:

For want of security-by-design, IoT security was lost;
For want of IoT security, IoT control was lost;
For want of IoT control, the internet was lost;
For want of the internet, infrastructure was lost;
For want of infrastructure, the nation was lost;
And all for the want of security-by-design.

a not so hypothetical bad day for the internet

Imagine, if one might, this scenario, one from the worst-case scenarios. First, there is the critical mass. And the point of diminishing returns. On some bright, clear day in the near future, critical mass has been reached over multiple botnets comprised of corrupted things on the internet. Many of the IoT botnets are running their own show, executing their missions of capturing and herding IoT. Other IoT botnets are under state control, for state agendas. The IoT botnets are a bubbling sulfur-and-brimstone stew of IP cameras, smartphones, and thousands of other internet-connected devices no one ever imagined would be compromised.

There are the routine IoT botnet-launched Distributed Denial of Service (DDoS) attacks, cutting off social media and news sites. As events unfold, people rush to their usual news sources for more information only to find silence. Then, control of multiple compromised motoring IoT devices, formerly known as automobiles, is wrested from hapless drivers as they speed down the freeways, by-ways, across bridges and through the woods to grandmother’s house. Off in the distance, dark plumes of smoke begin to rise as smart appliances are instructed to self-destruct.

Events cascade. The world that depends on the internet grinds to a slow, miserable stumble. People are hurt. Bank accounts are emptied. Chaos.

“Dogs and cats living together, mass hysteria!”
Dr. Peter Venkmann, Ghostbusters (1984)

Okay, so what is the Internet of Things (IoT) anyway? [2] And what is DDoS? [3] And why is the IoT vulnerable to exploits? Let’s take a quick dive, deep enough, in the next sections.

IoT isn’t just a fitness band

In the news today is the Internet of Things [4], everything from refrigerators to fitness bands to TVs to IP cameras connected to the internet. But the IoT is more than just consumer goods. IoT includes devices controlling industry. Like things controlling nuclear plants. [5]

Or things wrecking Iranian nuclear centrifuge equipment, even in the air-gapped Natanz refining facility. But worms and viruses and such can be wily forces, migrating to other things, escaping into the wild to invoke unexpected, unintended havoc. [6]

Modern automobiles are also now internet-connected things. Masayoshi Son, CEO and Chairman of the Board, SoftBank Group, commented in his keynote for ARM TechCon 2016 that no car today has encrypted chips or communication. He also notes that IoT has become the center of the internet and in the next two years, the number of IoT devices will cross over mobile. [7]

Charlie Miller notes in his keynote for ARM TechCon 2016 that it was a gradual process, as computers were deployed in vehicles and then connected to the internet, implemented with no security in mind, compounded by apparent disinterest of automotive manufacturers, which in some cases, believed car hacking somehow was mitigated with electromagnetic shielding. [8] Charlie Miller and Chris Valasek proved a Jeep could be hacked from anywhere via the internet, establishing control, such as applying or disabling brakes. [9]

Aside from someone, or some state, taking over one’s car, there are the Distributed Denial of Service (DDoS) attacks that occur all the time, at all hours. The really big DDoS attack [10] – and they are getting bigger – are the ones that make the news, primarily because thousands of users suddenly realize they can’t access their favorite social media site and want to know why. [11] All of the vulnerable things [12] on the internet, for example, IP cameras [13], can be herded into botnets [14] to launch massive DDoS attacks against websites, infrastructure – essentially rendering multiple services on the internet inaccessible.

Even if not exploited (yet), IP cameras with peer-to-peer (P2P) capability (meaning cameras that are present on the internet with an IP address) are quietly “phoning home” and seeking peers [15]. Manufacturers create devices like this on-purpose, as a “feature,” their devices connecting back to, say, China, and hunting for their peers to create a huge network. Furthermore, since the cameras can be seen, and controlled, from afar, one might end up seeing themselves on their own camera, along with everyone else. It’s this unadvertised, built-in behavior that is slowly creating a prudent fear of IoT. [16]

It’s not just cameras phoning home and joining peer networks. Something trivial as a smart plug that allows the user to switch power on and off to appliances through their cellphone will do the same thing. [17] Basically, if a device is connected to the internet, it can, and more often than not does, connect back to the manufacture, sending data and also connect to other devices like itself. And that’s when it’s not exploited and pressed into a botnet; the phoning home is by design.

One group of internet things pressed into botnet servitude are Android cellphones. [18] Users install malware-drenched Androids apps and, as if by magic, their phone is suddenly exploited and herded into a Android botnet. Android botnets are useful for DDoS attacks [19], with sheer numbers overshadowing the huge October and November 2016 Mirai [20] DDoS attacks. [21]

The list of things connected to the internet is growing every day by leaps and bounds. While we usually think of the aforementioned consumer devices as IoT, infrastructure devices also are connected to the internet, often with no security whatsoever. For example, smart meters. [22] It has been shown that smart meters can be easily exploited to shut off power or steal electricity. [23] Unlike customer choice of IoT consumer products, smart meters are usually not an elective.

And then there are the appliance routers/firewalls. Routers have been found with a back door port straight into the device, unprotected by even the most trivial of methods, such as no password required. [24] Apparently, some router manufacturers leave these back doors either for “maintenance” or as a forgotten development debugging path. Router DNS settings can be compromised, short-circuiting domain name requests resulting in bogus IP address replies to divert traffic. [25] (Safety Tip: One should build their own gateway to the internet, for business or home.)

home invasion

But it gets worse. Much worse. IoT in the home means potential invasion of the home. Smart TVs can watch people watching TV. [26]

Internet-connected baby monitors infamously lacking of security, allow the monitor camera and microphone to be used for listening and watching from afar, even allowing the watcher to speak through the speaker. [27]

Internet-connected toys interact and literally listen to children (without consent), recording conversations between child and toy, sending the data to far away places, including a defense contractor in one case. [28] Consumer groups are raising the alarms about listening-eavesdropping internet-connected toys. [29] Even the venerable Barbie, now connected and listening, has achieved one group’s Worst Toy award. [30]

the unicorn has already left the barn

Notably, it’s notoriously difficult to fix security failures in shipped IoT devices in the wild. The failure could be because of a bug or because security just wasn’t really thought-out and implemented properly in the first place. The latter is usually not fixable. The former requires a patch but getting the patch into the device is the rub.

It’s difficult to get the word out. Even if the IoT device is an automobile, informing the customer is problematic and creating a fix that can be easily installed by customer base with a wide-ranging technical expertise presents a wide array of logistical and practical problems. (Tesla is an exception to this with software upgrades automatically downloaded to vehicles. [31]) Therefore, once shipped and in use, many IoT devices will forever be vulnerable until unplugged and discarded, either because the security holes are baked-in or the customer never finds out the device is vulnerable.

Add to the mix that the bad guys are always cooking up new ways to exploit any given number of IoT devices. If careful, deliberate security was not part of the design from the beginning, the manufacturer will always be running one or two patches behind – presuming the IoT device can be patched in the first place. Or, if fixable, will receive the patch in time.

real people can get hurt

It’s not about just the inconvenience of social media crashing, unable to post kitten photos on Facebook or tweet what one had for breakfast. There are risks of identity theft, bank account vacuuming, physical danger from lost of control of an automobile or losing electrical power or natural gas during a blizzard, and house fires can set by smart outlet control.

As things on the internet send data to vast big data warehouses, and things are hacked so that portions of people’s personal data can be collected, risk multiples of assembling enough metadata [#metadata] along with publicly available social media information to fill in the gaps, creating a full profile, more or less.

And listening or watching or speaking the inside homes or businesses without the knowledge of the occupants is a quantum leap of risk in addition to producing stress, anxiety, and fear.

how do we stay secure in a connected world?

It’s important to be aware of the many ways insecurity is introduced in the connected world, and in particular with IoT. Let’s hit a few highlights.

The most trivial and least expensive way to exploit machines is simply phish the user. Phishing is a simply creating an authentic-looking HTML-based email and relying on naive users clicking links. Or, with some exploited email client bugs, just opening the email. (Chilling Note: Many emailers open email automatically in the preview.)

Phishing [32] still is the main attack vector for reaping easily-harvested usernames and passwords, a cascading effect since many use the same password for multiple accounts. It’s how the DNC email was vacuumed up via John Podesta’s Gmail account, a simple phishing attack with malicious links lurking under authentic-appearing HTML. [33] (Safety Tip: Don’t do HTML-based email. Not even once. Plain text is the path to happiness.) It could have been worse – now phishers are going after chicken. [34]

Aside from gaining passwords, phishing can also “automagically” install malware on the user’s machine with the click of the link or the simple viewing of the email. Phishing is both extraordinarily low-tech but stunningly successful.

Enter the Internet of Things which don’t receive email. They are just machines. No fooling them with HTML-based email. But, it turns out, manufacturers have a long, checkered history of leaving them wide-open with development debugging backdoors, default usernames and passwords, and vulnerable hardware lacking security-by-design.

Additionally, there is the potential of corrupted software tools used to build the software, the horrifying notion that the very compiler or other tools used to create the software has been compromised and now is cheerfully installing malware in the product. Or itself, corrupted tools building more corrupted tools. Source code can be reviewed and lurking danger discovered. Not so much with binary code, which is the nefarious advantage of such an exploit. This is known as the “trusting trust” attack and has been the stuff of developer nightmares – and PhD dissertations – for some time now. [35] Obviously, to ensure clean tools building product, all sorts of best practices and due diligence must be put into play, often the very things discarded in the rationalized, frantic, top-pressure, pell-mell race to market.

Securing the silicon, as the phrase goes, is becoming the next trendy thing in cybersecurity. It’s dawning on IoT manufacturers, of everything from toasters to automobiles, that IoT should be made secure [36], and security should start at the deepest level. Attacks are moving down the hardware stack [37] and security should start with the silicon. [38]

And yet, any IoT security strategy might seem willy-nilly with the lack of any standards. [39] In December, 2016, Commission on Enhancing National Cybersecurity published its “Report on Securing and Growing the Digital Economy.” Report on improving cybersecurity specifically mentions, among other useful topics, default username/passwords in Action Item 2.1.4:

Initial best practices should include requirements to mandate that IoT devices be rendered unusable until users first change default usernames and passwords.

That this report exists and says such things is good news. Take the long view. It’s been a long time coming. Default user names and default passwords have been an enduring problem, a red flag consistently brought up again and again over the years, as for example, the 2007 SANS Technology Institute “The Risk of Default Passwords” article. [40] It’s a good sign that such notions are entering the main dialogue, surfacing in government reports and re-surfacing in the tech media. Since many people struggle with usernames and passwords in their own computing adventures, the concept that IoT has the same sticky wicket, and can be brought down the same way, is easily grasped by the public.

So, security starts with awareness. Awareness on part of the developer, who begins to start every idea with security in mind. Soon, design is driven from both the top-down and the bottom-up by security.

Awareness starts with the consumer as well. The more awareness of IoT, the more awareness of dangers of no security-by-design, the better. An informed public will not support IoT with flimsy security (or no security at all) with their hard-earned dollars. In fact, as awareness grows, the informed, IoT-savvy consumer will be able to ask the hard questions before hopping into some swoopy internet-connected automobile or purchasing a cool, “smart” refrigerator. Or snapping up a huge “smart” TV on Black Friday, and therefore make good IoT purchasing choices. Okay, well, it’s something to work toward, anyway. And, the point is, the trends indicate the right path to awareness.

We’ll touch on some specific common-sense prudent ways to move from awareness to action later on, for developer and consumer. Before that, let’s visit securing the silicon.

secure silicon with what?

Securing IoT devices starts with the hardware.

First, securing the boot is important. Secure boot is also called “a root of trust.” [41] It’s where everything begins. Boot code should be in ROM. The microprocessor should be able to boot from this internal, immutable memory without loading it elsewhere. If the boot code must be loaded into RAM first, for example, already the device is essentially open to low-level attack vectors. Imagine a tiny MITM (Man-In-The-Middle) bit of code that can be squirreled away somewhere else, intercepting the boot code as it transferred to RAM.

Signing code is important as well. The binary executable code for the secure boot and application code – any code that runs on the device – should be signed. Public key cryptology is an essential level of security. [42]

Boot, load, and verify from a trusted point is the first line of defense against exploitation and corruption. [43]. To that end, chip manufacturers are bringing the power of encryption and security-by-design to market at the chip level, moving IoT device development to a stage where security is built-in, such as the Atmel Certified-ID security platform [44], Synopsys DesignWare ARC SEM Security Processors [45], and Maxim’s DeepCover[46] embedded security solutions.

lack of IoT security seems endless. what to do?

What, then, is lack of IoT security? It’s leaving permanent development debugging backdoors in devices. It is manufacturing thousands of IoT devices with the same default password. It is building in “features” like phoning home and peer-to-peer hunt-and-connect. It is interacting with children, recording conversations, and sending that data back to unknown vast data warehouses.

By now, readers of this article may be thinking of taking a sledgehammer to all of their new, bright and shiny IoT devices they just brought home. Or received as a gift. (Environmental Tip: Take all shattered IoT device pieces to the friendly, neighborhood electronics recycler.) Some might mull over going off the grid, disconnecting from all things electric and electronic. That would be one way to avoid IoT shenanigans and skulduggery. Let’s touch on what users (consumers) of IoT can do and what IoT developers should do.

IoT customers

Such extremes can be avoided; IoT security risk can be managed. As mentioned before, security awareness is the starting point. Common sense is a big deal here, too. Add a healthy dash of skepticism. Think security first and last. And in-between.

Look for the red flags. If the manufacturer’s privacy agreement is in tiny text requiring a magnifying glass, that’s a red flag. If the phrase “data may be shared with 3rd parties,” that’s another red flag. If no privacy and security policies can be found, that’s a huge red flag.

Avoid appliance routers, firewalls, and other related gear for the home or business gateway. Best to “roll your own.” [47] OpenBSD is the go-to OS. [48] Packet Filter (PF) is the way. [49] Such is surprisingly reachable on many levels. One advantage to building a gateway rather than grabbing an over-the-counter appliance is the control over all aspects of the gateway, including the firewall. With a custom firewall is entire countries can be blocked. For example, blocking Korean and Chinese IP addresses outgoing and incoming not only prevents IoT from phoning home to manufacturers, it provides useful logging of activity. Having access to useful, detailed, and user-configurable firewall logs will tell the story. (If an IoT device must reach servers outside the country, that’s a cause for pause and a red flag.)

If an over-the-counter product, such as a router, must be purchased, for the home and small-to-middle business, find a used pro-grade unit. Read up on the product first, do some research. Ensure the product can provide detailed firewall logs and provides the user with detailed control.

Point IoT scanners at one’s own IP address(es) to see what’s cooking inside the business or home. Use your favorite search engine to search for “Miria scanner” and “IoT scanner” and “Shodan.” (Miria scanner caveat: A properly configured firewall blocking the scans may give false positives, even if there are no IoT devices behind the firewall.) Scanners will have varying levels of technical complexity. One fairly new wide-audience scanner (with useful background info) is the BullGuard scanner. [50]

There are websites that will also do an extensive port scan of the reader’s IP address(es) to determine if there are unexpected open ports. Steve Gibson’s venerable ShieldsUp site is a recommended go-to for online port scanning. [51] (Safety Tip: One will have complete control over a custom-built gateway, including the firewall. Unexpected ports won’t be a problem.)

IoT developers

It turns out developers of IoT devices can do everything described above as part of their security-by-design best practices.

The entire developer team must do security, breathe security, practice on-going learning of security, go to sleep thinking of security and wake up thinking security. All team members must be on the same security page, even if this means taking time out for in-house security seminars to bring everyone up to the same speed.

Secure the development realm. In the case of offshored manufacturing of internally designed IoT, appropriately blocked firewalls will provide logs showing any unexpected creeping “featurism” added by the manufacturers. Secure the tools.

Careful, deliberate authoring of specific written product privacy and security policies (and “Terms and Conditions”) will inform developer practices. In fact, it’s prudent to spell out the product privacy and security policies that will accompany the product and/or be published to a product website before starting design and development. The privacy and security policies will become the overarching top-down documents informing design and development.

The rest of security-by-design has straightforward, obvious best practices, learned the hard way by the industry. That is to say, leave no backdoors whatsoever. Stop shipping devices with default login name and passwords. Indeed, create devices that will not operate until the user changes the password and login name. And add just a little special sauce to reject the usual lazy easily-guessed passwords.

Ship no devices with P2P (peer-to-peer). If the IoT device must connect to servers for outside access by the customer, ensure all traffic is encrypted and access is only via a unique public key assigned to the customer. Never allow access to the device without a password – just say no to telnet. [52] Notably, it is an incredible testament to some IoT manufacturers’ naivete and laziness that, in the two-thousand-tens, IoT devices can be hacked by ancient ways dating back to the mainframe era. [53]

Design and implement IoT from the hardware up for security. Use signed code. Think of every possible attack vector, starting with the hardware. Bug bounties are a good idea before product release. Bug bounties are big deal. For example, Apple offers $200,000 to crack iOS secure boot components and one can be sure people are working on that every step of the way. [54] [55] Design in easy, straightforward ways to fix problems found after shipping.

And stop manufacturing IoT devices that are basically trojan horses to collect customer data.

The track record is clear; IoT developers and manufacturers, as a whole, can do better. Security-by-design, building secure tools to create useful, secure products, and protecting the customers, starts here. It’s the right thing to do, done the right way.

Written for Mouser Electronics back in the day.

bibliography


  1. Wikipedia. (2016, Nov 1) For Want of a Nail Retrieved Dec 10, 2016, from https://en.wikipedia.org/wiki/For_Want_of_a_Nail.

  2. Kobie, Nicole. (2015, May 6). What is the internet of things? Retrieved Dec 6, 2016, from https://www.theguardian.com/technology/2015/may/06/what-is-the-internet-of-things-google.

  3. Wikipedia. (2016, Dec 14). What is the internet of things? Retrieved Dec 14, 2016, from https://en.wikipedia.org/wiki/Denial-of-service_attack.

  4. Mouser Electronics. (2015, May 6). Internet of Things Overview Retrieved Dec 6, 2016, from http://www.mouser.com/applications/internet-of-things/.

  5. Hitchin, Penny. (2015, Sept 15). Cyber Attacks on the Nuclear Industry. Retrieved Dec 6, 2016, from http://www.neimagazine.com/features/featurecyber-attacks-on-the-nuclear-industry–4671329.

  6. Anderson, Nate. (2012, June 1). Confirmed: US and Israel created Stuxnet, lost control of it Retrieved Dec 6, 2016, from http://arstechnica.com/tech-policy/2012/06/confirmed-us-israel-created-stuxnet-lost-control-of-it/.

  7. Son, Masayoshi. (2016, Oct 25). Keynote: ARM and SoftBank: A Joint Vision of the Future Retrieved Dec 6, 2016, from https://www.youtube.com/watch?v=eONE2_F7gmM.

  8. Miller, Charlie. (2016, Oct 27). Keynote: Automotive Security: A Hacker’s Eye View Retrieved Dec 6, 2016, from https://www.youtube.com/watch?v=l7MnJYuUBRw.

  9. Greenberg, Andy. (2015, July 21). Hackers Remotely Kill a Jeep on the Highway – With Me in It Retrieved Dec 6, 2016, from https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/.

  10. Turton, William. (2016, October 21). Today’s Brutal DDoS Attack Is the Beginning of a Bleak Future Retrieved Dec 6, 2016, from http://gizmodo.com/todays-brutal-ddos-attack-is-the-beginning-of-a-bleak-f–1788071976.

  11. Krebs, Brian. (2016, Oct 21). DDoS on Dyn Impacts Twitter, Spotify, Reddit Retrieved Dec 6, 2016, from https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/.

  12. Krebs, Brian. (2016, Dec 6). Researchers Find Fresh Fodder for IoT Attack Cannons Retrieved Dec 6, 2016, from https://krebsonsecurity.com/2016/12/researchers-find-fresh-fodder-for-iot-attack-cannons.

  13. Serper, Amit. (2016, Dec 6). Zero-day exploits could potentially turn hundreds of thousands of IP cameras into IoT botnet slaves Retrieved Dec 6, 2016, from https://www.cybereason.com/zero-day-exploits-turn-hundreds-of-thousands-of-ip-cameras-into-iot-botnet-slaves.

  14. Gamer, Noah. (2015, Dec 17). The state of botnets in late 2015 and early 2016 Retrieved Dec 6, 2016, from http://blog.trendmicro.com/the-state-of-botnets-in-late–2015-and-early–2016/.

  15. Cassel, David. (2016, Feb 27). ZPeer-Seeking Webcam Reveals the Security Dangers of Internet Things Retrieved Dec 6, 2016, from http://thenewstack.io/snooping-webcam-reveals-security-dangers-internet-things/.

  16. Krebs, Brian. (2015, Jan 12). This is Why People Fear the Internet of Things Retrieved Dec 6, 2016, from http://krebsonsecurity.com/2016/02/this-is-why-people-fear-the-internet-of-things/.

  17. Ullrich, Johannes. (2015, Jan 12). IoT: The Rise of the Machines Retrieved Dec 6, 2016, from https://isc.sans.edu/diary/IoT%3A+The+Rise+of+the+Machines+%28Guest+Diary%29/19173.

  18. Smith, Daniel. (2016, May 25). The Rise of Smartphone BotNets Retrieved Dec 13, 2016, from https://blog.radware.com/security/2016/05/the-rise-of-smartphone-botnets/.

  19. Bekerman, Dima; Herzberg, Ben; Gayer, Ofer. (2016, Sep 22). The Headless Android Bot: DDoS and a Mobile Botnet Retrieved Dec 13, 2016, from https://www.incapsula.com/blog/android-mobile-botnet.html.

  20. Segal, Liron. (2016, Oct 7). Mirai: The IoT Bot That Took Down Krebs and Launched a Tbps DDoS Attack on OVH Retrieved Dec 19, 2016, from https://f5.com/about-us/news/articles/mirai-the-iot-bot-that-took-down-krebs-and-launched-a-tbps-ddos-attack-on-ovh–21937.

  21. Dan, Worth. (2016, Oct 27). Mirai will be dwarfed by future Android botnet DDoS attacks, Lookout warns Retrieved Dec 13, 2016, from http://www.theinquirer.net/inquirer/news/2475539/mirai-will-be-dwarfed-by-future-android-botnet-ddos-attacks-lookout-warns.

  22. Clark, Jeff. (2014, Oct 2). Smart-Meter Hacking: A Preview of the IoT? Retrieved Dec 15, 2016, from http://www.datacenterjournal.com/smartmeter-hacking-preview-iot/.

  23. Higgins, Kelly Jackson. (2014, Oct 1). Smart Meter Hack Shuts Off The Lights Retrieved Dec 15, 2016, from http://www.darkreading.com/perimeter/smart-meter-hack-shuts-off-the-lights/d/d-id/1316242.

  24. Chirgwin, Richard. (2014, Jan 6). Hacker backdoors Linksys, Netgear, Cisco and other routers Retrieved Dec 19, 2016, from http://www.theregister.co.uk/2014/01/06/hacker_backdoors_linksys_netgear_cisco_and_other_routers/.

  25. @kafeine. (2016, Dec 13). Home Routers Under Attack via Malvertising on Windows, Android Devices Retrieved Dec 19, 2016, from https://www.proofpoint.com/us/threat-insight/post/home-routers-under-attack-malvertising-windows-android-devices.

  26. Geigner, Timothy. (2012, Dec 12. Smart TV Exploit Means Hackers Can Watch You Watch TV Retrieved Dec 15, 2016, from https://www.techdirt.com/articles/20121212/10482321363/smart-tv-exploit-means-hackers-can-watch-you-watch-tv.shtml.

  27. Goodin, Dan. (2015, Sep 2). 9 baby monitors wide open to hacks that expose users’ most private moments Retrieved Dec 15, 2016, from http://arstechnica.com/security/2015/09/9-baby-monitors-wide-open-to-hacks-that-expose-users-most-private-moments/.

  28. Cox, Kate. (2016, Dec 6). These Toys Don’t Just Listen To Your Kid; They Send What They Hear To A Defense Contractor Retrieved Dec 6, 2016, from https://consumerist.com/2016/12/06/these-toys-dont-just-listen-to-your-kid-they-send-what-they-hear-to-a-defense-contractor/.

  29. Tomlinson, Kerry. (2016, Dec 16). Don’t Buy These Two Toys, Consumer Groups Say Retrieved Dec 6, 2016, from http://www.archersecuritygroup.com/dont-buy-two-toys-consumer-groups-say/.

  30. Quirk, Mary Beth. (2016, Dec 8). Eavesdropping Barbie Brings Home The Win For Worst Toy Of The Year Retrieved Dec 6, 2016, from https://consumerist.com/2015/12/08/eavesdropping-barbie-brings-home-the-win-for-worst-toy-of-the-year/.

  31. Snyder, Elliott; Robertson, Jordan. (2016, Sep 20). Tesla Fixes Software Bug That Exposed Hacking Vulnerabilities Retrieved Dec 15, 2016, from https://www.bloomberg.com/news/articles/2016–09–20/tesla-fixes-software-bug-that-exposed-hacking-vulnerabilities.

  32. Wikipedia. (2016, Dec 12). Definition of Phishing Retrieved Dec 13, 2016, from https://en.wikipedia.org/wiki/Phishing.

  33. Franceschi-Bicchierai, Lorenzo. (2016, Oct 20). How Hackers Broke Into John Podesta and Colin Powell’s Gmail Accounts Retrieved Dec 13, 2016, from http://motherboard.vice.com/read/how-hackers-broke-into-john-podesta-and-colin-powells-gmail-accounts.

  34. Leonard, John. (2016, Dec 13). KFC regulars may get an order of phish with their chicken Retrieved Dec 13, 2016, from http://www.theinquirer.net/inquirer/news/2479519/kfc-regulars-may-get-an-order-of-phish-with-their-chicken.

  35. Wheeler, David A. (2009, November 23). 2009 PhD dissertation: Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers Retrieved Dec 13, 2016, from http://www.dwheeler.com/trusting-trust/.

  36. Dorsch, Jeff. (2016, Oct 26). Securing The IoT Retrieved Dec 13, 2016, from http://semiengineering.com/securing-the-iot–4/.

  37. Rosenquist, Matthew. (2016, Jan 14). Changes in Hardware Security Retrieved Dec 13, 2016, from http://itpeernetwork.intel.com/changes-in-hardware-security/.

  38. Rosenquist, Matthew. (2016, Jan 5). Security on Silicon the Next Big Step in Cyber Protection Retrieved Dec 13, 2016, from https://securingtomorrow.mcafee.com/mcafee-labs/security-on-silicon-the-next-big-step-in-cyber-protection/.

  39. Dorsch, Jeff. (2016, Oct 10). Where Are The IoT Industry Standards? Retrieved Dec 13, 2016, from http://semiengineering.com/where-are-the-iot-industry-standards/.

  40. Northcutt, Stephen. (2007, May 11). The Risk of Default Passwords Retrieved Dec 13, 2016, from https://www.sans.edu/cyber-research/security-laboratory/article/default-psswd.

  41. Loisel, Yann; di Vito, Stephane. (2015, Jan 11). Securing the IoT: Part 2 - Secure boot as root of trust Retrieved Dec 15, 2016, from http://www.embedded.com/design/safety-and-security/4438300/Securing-the-IoT–Part–2—Secure-boot-as-root-of-trust-.

  42. Loisel, Yann; di Vito, Stephane. (2015, Jan 11). Securing the IoT: Part 1 - Public key cryptography Retrieved Dec 15, 2016, from http://www.embedded.com/design/safety-and-security/4438298/Securing-the-IoT–Part–1—Public-key-cryptography.

  43. Raucher, Angela. (2016, Jun 2). Securing processors for IoT edge nodes Retrieved Dec 15, 2016, from http://embedded-computing.com/articles/securing-processors-for-iot-edge-nodes/.

  44. Ahmad, Majeed. (2015, Dec 8). Security coprocessor marks a new approach to provisioning for IoT edge devices Retrieved Dec 15, 2016, from https://atmelcorporation.wordpress.com/2015/12/08/security-coprocessor-marks-a-new-approach-to-provisioning-for-iot-edge-devices/.

  45. Marmie, Monica. (2016, Sep 12). Synopsys Introduces ARC Security Processors for Low-Power Embedded Applications Retrieved Dec 15, 2016, from http://news.synopsys.com/2016–09–12-Synopsys-Introduces-ARC-Security-Processors-for-Low-Power-Embedded-Applications.

  46. Maxim. (2016). Maxim’s DeepCover Retrieved Dec 15, 2016, from https://www.maximintegrated.com/en/products/digital/embedded-security/deepcover.html.

  47. @blakkheim. (2014, Nov 13). The ultimate OpenBSD router Retrieved Dec 16, 2016, from http://www.bsdnow.tv/tutorials/openbsd-router.

  48. OpenBSD (2016, Dec 19) OpenBSD Retrieved Dec 19, 2016, from http://www.openbsd.org.

  49. OpenBSD (2016, Dec 19) OpenBSD PF Retrieved Dec 19, 2016, from http://www.openbsd.org/faq/pf/index.html.

  50. -. (2016). BullGuard Internet of Things Scanner Retrieved Dec 16, 2016, from http://iotscanner.bullguard.com/.

  51. Gibson, Steve. (2016). Steve Gibson’s ShieldsUp Retrieved Dec 16, 2016, from https://www.grc.com/.

  52. Craig, Scott. (2016, May 5). Telnet: An Attacker’s Gateway to the IoT Retrieved Dec 16, 2016, from https://securityintelligence.com/telnet-an-attackers-gateway-to-the-iot/.

  53. Security Intelligence Staff. (2016, May 5). IBM X-Force Research: Beware of Older Cyber Attacks Retrieved Dec 16, 2016, from https://securityintelligence.com/media/beware-of-older-cyber-attacks/.

  54. Amin, Ramtin. (2016, Dec 5). iPhone secure boot firmware component could be dumped Retrieved Dec 16, 2016, from https://twitter.com/key2fr/status/805767041026232320.

  55. Amin, Ramtin. (2016, Dec 5). Secure Rom extraction on iPhone 6s Retrieved Dec 16, 2016, from http://ramtin-amin.fr/#nvmedma.