IoT Security: Debunking the "We Aren't THAT Connected" Myth
•Transferir como PPTX, PDF•
1 gostou•271 visualizações
In a world where convenience is key, consumers are adopting every new connected device that hits the shelves - and doing so with the assumption that due diligence security has been considered. But recent IoT attacks suggest otherwise. As organizations migrate from a primarily offline to online business model, they are failing to consider IoT’s unique threats which traditional solutions are unable to secure. As a result, steps must be taken to ensure that the device, connections and infrastructure are hardened, especially software which runs IoT devices and is the source of ~90% of attacks. This webinar is ideal for risk, technology, and security professionals that want to understand why a hacker would want to attack their “harmless” IoT device and what the stealth risk to their organization and consumers is. Topics covered include: - 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 software development
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a IoT Security: Debunking the "We Aren't THAT Connected" Myth
Semelhante a IoT Security: Debunking the "We Aren't THAT Connected" Myth (20)
Mais de Security Innovation
Mais de Security Innovation (20)
Último
Último (20)
IoT Security: Debunking the "We Aren't THAT Connected" Myth
- 2. What We Do Software runs 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 • CEO by 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 Old Days” • 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 A not 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 & Customers Getting 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 • Do you 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 Software Applications • 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 applications and 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: IoT Deployment is Complex
- 17. IoT vs. Web Application Stack
- 18. IoT Attack Surface Identification 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 security training • 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 • What type 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 Chain Ownership 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 your IoT 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 security into 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 • Do you 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 processes in 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 is the 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 Device Built 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 SDLC practices 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 done properly • 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 the data 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. Questions?
- 38. IoT Developer Mobile Developer 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
Notas do Editor
- 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.
- 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.
- 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
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.