Downloaded 30 times
Uploaded bySecurity Innovation
IoT Security: Debunking the "We Aren't THAT Connected" Myth
The document discusses the complexities and risks associated with IoT security, emphasizing the evolution of devices from simple code-based tools to interconnected systems that require careful management of vulnerabilities. It details the legal implications, manufacturer responsibilities, and consumer risks linked to security deficiencies, citing real-world examples of IoT device vulnerabilities, such as in medical devices and consumer goods. The text also presents essential strategies for improving IoT security, including robust development practices, training, and auditing processes to mitigate potential security threats.
More Related Content
![Technology & Policy Interaction Panel at Inform[ED] IoT Security](https://cdn.slidesharecdn.com/ss_thumbnails/03-technologypolicyinteraction-3-170509164607-thumbnail.jpg?width=640&height=640&fit=bounds)
![IoT Security: Cases and Methods [CON5446]](https://cdn.slidesharecdn.com/ss_thumbnails/j1-2016-con5446-security-160927112335-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to IoT Security: Debunking the "We Aren't THAT Connected" Myth
More from Security Innovation
IoT Security: Debunking the "We Aren't THAT Connected" Myth
- 2. What We Do Softwareruns the world. We Reduce its Risk • Expertise • Commitment to Excellence • Trusted Advisor How we Do It
- 3. About Security Innovation •Authority in Software Security • 15+ years research on software vulnerabilities • Security testing methodology adopted by SAP, McAfee, Microsoft, Symantec, and others • Microsoft MVPs, Privacy by Design Ambassadors, Apple and Barracuda Hall of Famers, Ponemon Institute Fellows • Authors of 18 books
- 4. About Me • CEOby day; engineer by trade (and heart) • Mechanical Engineer, Software Engineer • Ponemon Institute Fellow • Privacy by Design Ambassador, Canada • In younger days, built non-lethal weapons systems for Federal Government
- 5. Agenda IoT security –why it’s so different….and tough • The IoT ecosystem and attack surface • Managing liability - IoT risks to consumers and vendors • Auditing IoT development & deployment
- 6. The ”Good OldDays” • Devices were just… devices o Still ran on code; made to serve a specific purpose o Real-time changes; no “wait for compile” and see o Had to be physically at the device to access/change o Sharing data meant print, verbal, film, CD, etc.
- 7. Today’s IoT Devices •Devices are still devices, but… o Run on LOTS of code; made to serve single/multiple purposes o Real-time changes; no “wait for compile” and see o Make changes from anywhere via cellular or wifi connection o Sharing data is instantaneous and digital
- 8. Dyn DDoS Attack Anot so oldie, but a goodie • Domain Name System (DNS) service disrupted • Affected nearly 1/3 of all Internet users in US and Europe • No access to (short list): • Amazon.com • Comcast • DirecTV • GitHub • Netflix • Twitter • PayPal • Starbucks • Verizon • Visa • Walgreens • Xbox Live • PlayStation Network • iHeart Radio • BBC • NY Times • GrubHub • Slack Millions of IoT Devices (printers, IP cameras, baby monitors) infected with Mirai malware and used to flood Dyn with traffic (DDoS)
- 9. Recent IoT Trouble Consumer& Medical Devices • 465,000 vulnerable pacemakers from St. Jude • Implantable cardiac devices have vulnerabilities • Unauthorized remote access • Deplete battery, change pacing, or deliver shocks • Owlet WiFi Baby Heart Monitor • Alerts parents when babies have heart troubles • Connectivity element makes them exploitable Best intentions exploited via careless manufacture configuration
- 10. Government & CustomersGetting Involved • FTC vs D-Link: The legal risks of IoT insecurity • Lawsuit against D-Link • Claims company put thousands of customers at risk • Unauthorized access to its IP cameras and routers • Customers vs John Deere: The business risks of IoT • US farmers dispute rights to repair their tractors • Contain embedded software (it’s an IoT device) • Company issued a new license agreement • Prohibits software modification on its tractors • Ensure all repairs are done by John Deere contractors
- 11. Convenience-Risk Trade Offs •Building in security takes time initially; equates to money • Time to market pressures often trump this investment • Security can equate to safety in consumer IoT devices • Ease of setup and operation • Consumers want devices to “just work” • Quick setup and minimal configuration required • Often means little to no authentication or default (same for all devices) • When vulnerabilities discovered, patching is the answer • But IoT patching can be difficult, impossible, and illegal Consumers demand easy and convenient features, until they backfire
- 12. Polling Question • Doyou have an active IoT system/program in use today with >1,000 devices, sensors, machines, etc. exchanging data?
- 13. Agenda • IoT security– why it’s so different….and tough The IoT ecosystem and attack surface • Managing liability - IoT risks to consumers and vendors • Auditing IoT development & deployment
- 14. • Smart SoftwareApplications • Access to data for real-time assessment and action • Distributed Computers • Facilitate local aggregation and communicate with centralized servers via public internet • Embedded/IoT Devices • Microchips, embedded applications, wireless enabled • Sensors gather/analyze data better and faster The Idea is Simple…
- 15. • Cloud applicationsand wireless networks accessible by others • Distributed devices may be used for email, DDoS, and other applications subjected to social engineering • Devices may be accessible by unknown or unauthorized people • Devices may have open connections • Devices likely lack encryption • Physical interfaces on the devices leak sensitive data • Debug ports (JTAG, UART) lead to privileged access on the device • Radio and network communication protocols (Cellular, WiFi, NFC, Bluetooth, Zigbee, SDR, etc) can be exploited • Weak Firmware security can lead to complete device compromise But Loaded with Attack Vectors…
- 16. Reality Check: IoTDeployment is Complex
- 17. IoT vs. WebApplication Stack
- 18. IoT Attack SurfaceIdentification Element Example Device hardware Memory, physical interfaces, ports, sensors (light, imaging, location, etc.) Device firmware Signed/unsigned, update verification, unencrypted files, other software Mobile application Authentication, data in local storage, default passwords, transport encryption, password security (2FA, TouchID), excessive collection of PII and user data Web application Admin interface, default/weak passwords, XSS, SQLi, CSRF, brute-force protection Radio & network communication Cellular, WiFi, TCP/IP, NFC, Bluetooth, Zigbee, etc. Network services Web services, vendor APIs, custom protocols, unnecessary services, etc. Authentication/ Authorization Default/weak credentials, user roles, password reset, session expiry
- 19. • Insufficient securitytraining • Humans #1 weak point: building, deploying, using • Weak Physical Security • Debug interfaces (JTAG, UART, etc.) and USB ports allow unintended device or data access • Infrequent updates • Firmware, device apps, admin apps/interfaces • Expensive and/or remote IoT devices long lifespan (difficult to update) • Weak Data Protection • Data at rest/transit uses weak encryption techniques • Lack of dedicated security chips and modules to store sensitive data. Top 4 IoT Security Weak Points
- 20. Polling Question • Whattype of testing IoT devices for security do you practice?
- 21. Agenda • IoT security– why it’s so different….and tough • The IoT ecosystem and attack surface Managing liability - IoT risks to consumers and vendors • Auditing IoT development & deployment
- 22. • Privacy -PII leakage • Mass surveillance • Stalking • Theft • Data breaches • Liability • Reputation • Botnets, e.g. Mirai, for mass hacking Main IoT Risks
- 23. IoT Connection ChainOwnership Threats Device hardware/firmware Vendor X Known vulnerabilities with Vendor products Patching process for Vendor X products Mobile application Vendor Y Secure SDLC activities for Vendor Y Web application Us Our own Secure SDLC activities/process Information/Data management Us Storage and transport of data Where is it encrypted? Channels of transmission Telco X Security guarantees/SLA with Telco X User authentication/roles Us Enumerate each role and authorized activity Authentication for each role Assessing IoT Risk
- 24. Threat #12 Compromise App Password 1.1 Access“in-use” password 1.2 Guess password 1.3 Access Password in DB 1.1.1 Sniff network 1.1.2 Phishing attack 1.2.1 Password is weak 1.2.2 Brute force attack 1.3.1 Password is in cleartext 1.3.2 Compromise database 1.3.2.1 SQL injection attack 1.3.2.2 Access database directly 1.3.2.2.1 Port open 1.3.2.2.2 Weak db account password(s) Use TLS to encrypt OpenSSL 1.0.1f Require strong Password 8+ char, upper, lower, number, special char Use Prepared Statements .NET parameterized queries OleDbCommand() with bind variables Restrict Port Access Firewall configuration Enumerate Defenses For Each Threat
- 25. • Know yourIoT technology vendor’s track record o Update your evaluation process, if necessary • Invest in IoT security training for all in-house systems staff o Coding (if building or interfacing w/ device); Configuration for Ops team • Perform proactive penetration testing o Obtain right to do so from 3rd-parties • Adopt a "defense-in-depth" strategy o e.g., WAF between IoT devices and cloud admin app? • Eliminate all hardcoded default passwords and backdoors IoT Security tipsheet @ end of webcast Tips for Securing IoT Systems
- 26. • Build securityinto devices at the outset, rather than as an afterthought • Train employees about the importance of security • Ensure security is managed at an appropriate level in the organization • Ensure outside service providers are capable of maintaining reasonable security, and provide oversight of providers • Consider a “defense-in-depth” strategy whereby multiple layers of security may be used to defend against a particular risk • Keep unauthorized users from accessing device data, or personal info • Monitor connected devices; provide security patches for known risks * https://www.ftc.gov/news-events/press-releases/2015/01/ftc-report-internet-things-urges-companies-adopt-best-practices US FTC IoT Security Best Practices*
- 27. Polling Question • Doyou plan to purchase/deliver IoT-specific security training for your team(s) in the next 12 months?
- 28. Agenda • IoT security– why it’s so different….and tough • The IoT ecosystem and attack surface • Managing liability - IoT risks to consumers and vendors Auditing IoT development and deployment
- 29. • All processesin the development of the technology must be controlled • All protocols and services used must be monitored • Each new capability is assessed for risk before going live The following questions and tables will start you on your way High-level Objectives (can’t be met 100%)
- 30. • How isthe IoT deployed in our organization today, and who owns it or its respective components? • IoT inventory and business activity/role • Don’t expect the word “IoT” to show up in project docs • Do we know what data is collected, stored and analyzed? Have we assessed the legal, security and privacy implications? • Governance policies cover data captured at thousands of sensors? • Do we have contingency plans in place in case our IoT “things” are hijacked or modified for unintended purposes? Driven by Key Threats & Attack Surface Start with “Simple” Questions
- 31. Query Objective Is DeviceBuilt to “minimum requirements”? • Fewest features to obtain business objective Is Device “tamper proof”? • Detect opening of cover or removing a part of the device • Disable/Notify upon detection How is critical data protected? • Encrypted storage • Boot protection, e.g., Trusted Platform Module (TPM) How are updates processed? • Secure delivery of firmware upgrades • Physical access required to update device? Auditing IoT Device Development
- 32. Query Objective Secure SDLCpractices for connecting device to systems • Follow prescriptive methodology, e.g., Microsoft SDL • Document/mitigate vulnerabilities for open-source How are boundaries secured? • Check all interfaces of components being integrated for security flaws • API security considered, e.g., input/output sanitation • Protect against fuzzing and buffer overflow attacks Authentication key protection • Each device requires device IDs and associated authentication keys, e.g., generated by a cloud service/app • Protection mechanism pre- and post-deployment. Physical security considerations • IoT devices in unsecure locations, e.g., public or unsupervised spaces • Check debug interfaces (JTAG, UART, etc.) and USB ports for unintended device or data access Auditing IoT System Development/Deployment
- 33. Query Objective Is Authentication/Authorization doneproperly • Deploy role-based access control • Mandate the use of multi-factor authentication for privileged accounts • Ensure that a strong password management policy is in place Is the communication channel secure? • Secure the Wi-Fi and Bluetooth interfaces by means of secure configurations (encryption, password, etc.) and drivers • Secure the exposed services and keys during device enrollment • Ensure that sensitive data is not sent over unencrypted bus lines • Test for side-channel leakage by means of power/timing analysis and glitching attacks • Configure TLS to conform with accepted encryption standards Auditing IoT System Development/Deployment
- 34. Query Objective System up-to-date?• OS and device drivers at latest versions • Automatic update enabled • All updates are signed and verified • Bootloader verified at every stage of the boot sequence Malicious activity protections • Antivirus and antimalware on each device (if disallowed by OS, what’s the risk?) Event logging • Reviewed frequently for security breach • Use of human vs. automated/telemetry stream to cloud service where it can be analyzed Physical protection • Access controls • Logging of physical access, such as USB port use Cloud credential protection • Used for configuring and operating IoT deployment • Change password frequently • Refrain from using credentials on public machines Auditing IoT/Infrastructure Operator
- 35. Summary • Follow thedata trail - it’s what hackers are looking for • Big attack surface = lots of open doors = big problems • Always treat IoT devices as insecure by default • Understand who owns what activities (both internal and external) throughout development and deployment
- 36. • Standards –Set goals and make it easy Secure coding standards and policy development Education – Enable me to make the right decisions Computer-based and simulation training for an authentic environment • Assessment – Show me the Gaps! Software, Infrastructure and SDLC assessments How We Help Clients
- 37.
- 38. IoT Developer MobileDeveloper Cloud Developer • Fundamentals of Secure Mobile Development • Creating Secure iOS Code in Swift • Creating Secure Android Code in Java • OWASP MOBILE SERIES • Mobile Threats and Mitigations • Defending Mobile Data with Cryptography • Mobile App Authentication and Authorization • Defending Mobile App Code • Fundamentals of Secure Development • Web Vulnerabilities – Threats & Mitigations • Fundamentals of Secure Cloud Development • Creating Secure Code - AWS Foundations • Creating Secure Code - Azure Foundations Infrastructure/Operations • Securing Network Access • Securing Operating System Access • Securing Cloud Instances • Essential Security Engineering Principles • Essential Application Protection • Essential Data Protection • Application, Technical & Physical Access Controls We build customized learning paths for the most contextual training • Insecure IoT Web Interfaces • Insecure IoT Authentication and Authorization • Insecure IoT Network • Insecure IoT Communications • Insecure IoT Mobile Interface • Insecure IoT Firmware • IoT Embedded Systems Security • Creating Secure C/C++ Code - IoT Sample Role-Based eLearning Programs
- 39. Thank You! @AppSec |eadams@securityinnovation.com @SecInnovation getsecure@securityinnovation.com
Editor's Notes
- #4 Security innovation is a company dedicated to helping our customers with hard application and data security problems. We’ve spent years researching security vulnerabilities, why they occur, what they look like in production code and how to find and fix them. We have experience working with some of the largest companies in a variety of industries - from software companies such as Microsoft to e-commerce companies such as amazon, financial companies and many more. We offer solutions for all phases of the SDLC including instructor led training, computer based eLearning courses, on-site consulting and security assessments as well as technology to help secure sensitive data over the network or at rest. Over the years we’ve analyzed more than 10,000 vulnerabilities both in the course of research studies and through the assessments of software for our customers We got our start as a security testing company, grew to a products and services company that focused on breaking systems (code review, pen test, etc) and then helping fix the problems through secure design and implementation. We acquired NTRU in 2009 to expand our data protection services focused on data in transit as well as data at rest with best in class, high performance cryptography.
- #8 All of our devices are conveniently connected and able to communicate with each other either via central control systems or with some consumption device like your phone or tablet. Getting too hot? Just have your thermostat signal your blinds to close. Speak into your phone and have your front-door unlock. Washing machine in need of a check-up? It can request service by itself through an API call.
- #9 Summary - Friday October 21, 2016 - Dyn (The company that controls much of internets domain name system infrastructure) came under attack by two large and complex Distributed Denial of Service (DDoS) attacks against its Managed DNS infrastructure. High flood of TCP and UDP traffic both with destination port 53 (DNS port) from large number of source IP addresses. When service went down – legitimate devices started trying to reconnect to the services. This made it difficult to differentiate between real and fake requests. Many devices had no login credentials; others had default username-password; the “tough” ones to crack were easily brute-forced by Mirai Mirai open-source software freely available
- #10 St. Jude/ Abbott: The wireless protocol (RF) used had serious security vulnerabilities that could be exploited by unauthorized attackers (as far as 10 ft away .. but can be extended with off-the-shelf parts). The unauthorized commands could modify device settings (e.g., stop pacing), deliver shocks or impact device functionality. Owlet WiFi Baby Heart Monitor: sensor that babies wear in a sock that monitors their heartbeat and relays that data wirelessly to parent's smartphones if anything is amiss. Vulnerabiility was that the device created its own base station which is basically an unlocked wifi network that anyone can join. After joining the attackers can monitor a stranger's baby and prevent alerts from being sent out.
- #20 we conduct trainings at well known conferences like Black Hat. That way they can trust that we know what we are talking about. Most organizations don’t have sufficient in-house expertise to keep their IoT systems secure day in and day out. Developers, testers, operators, and system administrators often lack the training to identify common vulnerabilities, understand why they’re dangerous, and mitigate their risks. Without this in-house security expertise, IT staff don’t recognize system vulnerabilities until after a hack or breach occurs. People can’t protect themselves if they don’t understand the threat. In addition to this lack of in-house knowledge, when organizations deploy IoT systems, they’re also typically constricted by tight deadlines and inadequate in-house experience. These combined constraints, coupled with complex documentation and deployment processes, will inevitably leave systems unsecured and vulnerable to hacks and breaches. Weak Physical Security – Opening up the IoT device you can find test pads. These may be debug ports like JTAG, UART. In the past we’ve encountered devices that directly drop us to “root” when we connect hardware tools to it (Eg: http://konukoii.com/blog/2018/02/16/5-min-tutorial-root-via-uart/ and https://blog.malwarebytes.com/security-world/2014/02/uart-root-shell-on-commercial-devices/). This is pretty common in our projects too. Updating firmware on IoT devices can be a daunting task. It’s understandable that an organization may want to avoid the hassle and potential business risk of updating firmware regularly, especially if the business doesn’t have trusted processes in place. But firmware releases often contain critical security updates. By skipping releases, not only does an IoT infrastructure get out-of-date; it also becomes vulnerable to threats. IoT devices tend to have a much longer lifespan than typical software applications, largely because they are physical devices, some of which have relatively high capital costs (think refrigerators and TVs). The legacy systems supporting these devices can be difficult to keep up-to-date, and may have vulnerabilities that can't easily be patched due to legacy design issues or a lack of vendor support.
- #24 Go back to the Attack Surface list and start identifying who owns what Then discuss threats for each piece of the IoT chain Finally, discuss steps to mitigate each threat identified
- #26 If you’re investing in new IoT technology, perform due diligence to understand whether the vendor comes with a history of insecure firmware, inadequate responses to public vulnerability reports, or any kind of lax attitude towards security. If so, find a different vendor. In-house expertise and sound internal processes can help prevent human error and ensure systems are secure. However, because they can't prevent what they don't know, developers need to understand common vulnerabilities before they can avoid them. When planning your initial security spending priorities, ensuring the security knowledge of your in-house staff will be your best line of defense, and will deliver your best security value overall. Remember that if you’re switching to a new IoT technology platform, your operations, system admins, testers, and others have to be ramped up on the new technology. They’ll also need to draft new systems deployment, configuration, and verification guidelines. Organizations, particularly those with high-risk applications, need to undergo regular penetration testing – before product launch (for manufacturers) and before product deployment (for customers). Too often, penetration testing doesn’t happen until after a breach, public disclosure, or other event that tarnishes a company’s brand or leaks customer data. IT managers can mistakenly assume that their firewalls, network segmentation, and perimeter defenses will be enough to secure their IoT assets. As a result, they fail to prioritize application security on the devices themselves, leaving gaping security holes. The IoT firmware, applications that run on the IoT devices, communication to outside resources, and servers (to which IoT devices upload data), all need to be secured. Device firmware sometimes includes default credentials or "administrative backdoors.” While these "features" may make it easier to troubleshoot potential problems that on the devices, they also create a large attack surface for hackers. The safest solution is to adopt the more secure key-based and multi-factor forms of authentication.
- #31 How is the IoT deployed in our organization today, and who owns it or its respective components? This includes determining an organization’s potential IoT inventory and IoT’s business activity role. The IoT could play a part in the end products that a business sells, for example, or in internal process management. It most likely does not reside in the IT organization. In many cases, projects will not include the wording “IoT” in their project plans or definitions. This underscores the importance of having skilled IT auditors who are able to link strategy and the underlying implementation mechanisms to identify where the IoT exists within the organization. Do we know what data is collected, stored and analyzed, and have we assessed the potential legal, security and privacy implications? If IoT technology is found within a company’s solution offerings, for example, customer agreements may require disclosures regarding what information the devices are capturing and sharing. Do the organization’s data governance policies cover the tremendous amount of data being captured through the thousands of deployed sensors? Does the collection of sensor data pose risks that data may be aggregated in a manner that would create privacy concerns? Do we have contingency plans in place in case our IoT “things” are hijacked or modified for unintended purposes? Among other considerations, it is critical to identify how an organization uses IoT devices and how a partial or full network shutdown would impact the business. Does the loss of these devices pose a risk to our organizations or other organizations? Is there a risk that our devices sold to others could be compromised on a large scale? One well-publicized example was the utilization of thousands of internet-connected devices as part of a denial of service attack on Dyn in October of 2016.
- #32 An example is to include USB ports only if necessary for the operation of the device. These additional features open the device for unwanted attack vectors that should be avoided.
- #33 An example is to include USB ports only if necessary for the operation of the device. These additional features open the device for unwanted attack vectors that should be avoided.
- #34 An example is to include USB ports only if necessary for the operation of the device. These additional features open the device for unwanted attack vectors that should be avoided.
- #35 An example is to include USB ports only if necessary for the operation of the device. These additional features open the device for unwanted attack vectors that should be avoided.