Risk-Based Testing for IoT Systems
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,220 views
IoT Systems provide powerful, flexible features for IT systems — tracking, monitoring, and other data sharing. Today’s IoT devices utilize microservices and APIs that make them easy to put into production. But securing them isn’t as easy. This webinar will look at security risks of IoT devices, interfaces, and implementations. We’ll provide practical steps and checklists any DevOps team can use to make their IoT components as secure as possible. We’ll also cover some testing best practices that can be done pre- and post-production to verify security and resilience on an ongoing basis.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Risk-Based Testing for IoT Systems
Ähnlich wie Risk-Based Testing for IoT Systems (20)
Mehr von Security Innovation
Mehr von Security Innovation (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Risk-Based Testing for IoT Systems
- 2. Risk-Based Testing for IoT Systems Ed Adams 11 June 2019
- 3. About Me • CEO by day; engineer by trade (and heart) • Mechanical Engineer, Software Engineer • Research Fellow, Ponemon Institute • Privacy by Design Ambassador, Canada • In younger days, built non-lethal weapons systems for US Federal Government
- 4. Agenda Security Risks of IoT Devices • Risk-based Testing Essentials • IoT Device Considerations • Securing Our Digital Future
- 5. So many connected “things”…
- 6. Good Ol’ Days: Devices Were Just Devices • Ran on a little code; made to serve a specific purpose • Cash payments • Real-time changes; no “wait for compile” and see • Had to be physically at the device to access/change • Sharing data meant print, verbal, film, CD, etc.
- 7. Today’s Devices are Still Devices but... • Run on LOTS of code; made to serve single/multiple purposes • Make changes from anywhere via cellular or Wi-Fi connection • Sharing data is instantaneous and digital
- 8. The Mirai Botnet (aka Dyn Attack) A not so oldie but 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. More 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 • TRENDnet SecurView Webcam • Faulty software anyone who obtained a camera’s IP address could look through it and listen as well • Transmitted user login credentials in clear, readable text • Mobile app stored login information in clear, readable text Best intentions exploited via careless manufacture configuration
- 10. Governments & 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. Skimmers • Evolved from mag stripe readers Bluetooth and cellular transmitters • devices keep getting smaller • embedded inside pumps and PoS devices • Future skimmers • Embedded devices that don't steal credit card data but rather attack your networks directly.
- 12. Agenda • Security Risks of IoT Devices Risk-based Testing Essentials • Weak Links, Soft Spots, Blind Spots • Securing Our Digital Future
- 13. 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
- 14. Today’s IoT Deployment in Practice • How is testing IoT different from our other platforms, e.g., web, mobile cloud? The answer is it’s not very different. • Most IoT devices are connected to many of the following: • Mobile App • APIs • Cloud Infrastructure • Web App • KEYPOINT: IoT is not a magical technology, but a mash up of many different technologies – and at its core, it’s just almost all software Sources: “International Journal of Web Portals” Ahmedi, Sejdiu, et al; Geoff Vaughan Security Innovation, Inc.
- 15. Top 4 IoT Security Weak Points • Insufficient Security Awareness • 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.
- 16. 3 Must-have IoT Security Considerations • “Shift left” • Think security earlier and more often in system design • Account for resources that will be able to provide security updates • Could be vendor, e.g., maintenance agreement, and/or internal staff, e.g., patching • KEYPOINT: Every component needs to be tested as part of the ecosystem • Not just individual IoT device testing Sources: “Dr. Dobbs” Larry Smith; Geoff Vaughan Security Innovation, Inc.
- 17. Start with “Simple” Questions • 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
- 18. Start by Assessing IoT Risk/Liability 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
- 19. US FTC IoT Security Best Practices* • 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
- 20. Agenda • Security Risks of IoT Devices • Risk-based Testing Essentials IoT Device Considerations • Securing Our Digital Future
- 21. Testing IoT Devices • ~8-10 very technology specific areas to consider • Component Identification and Classification • Static Firmware Analysis • Dynamic Debugging • Peripheral Hacking • Protocols and Data Sniffing • WIFI • BLE • SDR • Cellular • USB • Hardware Hacks • JTAG • UART • SPI • Obtain from vendor website • Web search: support and community forums • Reverse the mobile application • Sniffing the OTA update mechanism • Dumping it from the device Tools such as Binwalk, IDA Pro, Radare2 can be usefulSimilar to other network-based testing • What services are running? • What communication protocols are being used? • What ports are open? • What version is running? Known vulnerability? Sources: Attify, Security Innovation
- 22. Agenda • How Connected Are We? • Nothing Ever Goes Wrong… Right? • IoT Device Considerations Securing Our Digital Future
- 23. Top 5 IoT Security Tips TIPS Secure the Device OS and Firmware Ensure Sufficient Data Protection Secure the Physical Device Secure the Communication Channel Enforce Authentication and Authorization
- 24. Secure the Device OS and Firmware Security Controls Ensure updates are over a secure channel, signed and verified Ensure bootloader firmware is secure and has not been tampered with Ensure installed bootloader is verified at every stage of boot sequence Ensure device makes use of full disk encryption Disable unnecessary services running on the device Protect against fuzzing and buffer overflow attacks Ensure that binaries are compiled and signed for security
- 25. Ensure Sufficient Data Protection Security Controls Encrypt data at rest using strong and known encryption techniques Ensure device uses dedicated security chips and modules to store sensitive data Avoid usage of hard-coded credentials or cryptographic key Do not collect data not essential for device functionality Avoid usage of weak, broken, or risky cryptographic algorithms Log all secure data access and alter events Ensure authentication and authorization to all PII
- 26. Secure the Physical Device Security Controls Ensure data storage is not directly accessible Test debug interfaces (JTAG, UART, etc.) and USB ports for unintended device or data access Ensure tamper protection/resistance techniques are in use Limit the admin functionalities present on the device
- 27. Secure the Communication Channel Security Controls Secure the Wi-Fi interface via secure configurations (encryption, password, etc.) and drivers Ensure protection against Denial-of-Service (DoS) and fuzzing attacks Secure the exposed services and keys during device enrollment Audit the file, printer and device sharing mechanism in place regularly Secure the Bluetooth interface via secure configurations (discovery modes, PIN, etc.) and drivers Verify that secure Bluetooth modes are in use Ensure sensitive data is not sent over unencrypted bus lines
- 28. Enforce Authentication and Authorization Security Controls Ensure role-based access control is currently in place Mandate the use of multi-factor authentication for privileged accounts Ensure that a strong password management policy is in place
- 29. Summary of Tips for Securing IoT Systems • Know your technology vendor’s track record • Update your evaluation process, if necessary • Invest in security training for all in-house systems staff • From “Don’t Click on Sh*t” toTechnical/Configuration for IT/Ops teams • Perform proactive penetration testing • Obtain right to do so from 3rd-parties • Adopt a "defense-in-depth" strategy • e.g.,WAF between IoT devices and cloud admin app? • Eliminate all hardcoded default passwords and backdoors IoT Security Toolkit: https://tinyurl.com/y4zxw577
- 30. Engage with Security Professionals •Have a chat with us •Bug Bounty Programs •Non-hostile relationship with “researchers” •Vulnerability Disclosure Program •Direct Relationship • Use as independent 3rd-party • Share info about good/bad ones
- 31. Questions? @AppSec eadams@securityinnovation.com Want a whitepaper? ….and/or Tip Sheet?
Hinweis der Redaktion
- 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. loaded with Attack Vectors Cloud apps 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/unauthorized people Devices may have open connections Devices likely lack encryption Physical interfaces on the devices leak sensitive data Debug ports lead to privileged access on the device Radio and network communication protocols can be exploited Weak Firmware security can lead to device compromise
- 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.
- 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.
- 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.
- 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.