Aaron Guzman is a Manager with Gotham Digital Science (GDS), located in Los Angeles, CA. Mr. Guzman previously worked with established tech companies such as Belkin, Linksys, Symantec and Dell SecureWorks breaking code and architecting infrastructures. Aaron has spoken at many conferences worldwide which include DEF CON, OWASP AppSec EU, OWASP AppSec USA, HackFest, Security Fest, HackMiami, AusCERT as well as a number of BSides events. Aaron leads the OWASP Embedded Application Security project; providing practical guidance to address the most common firmware security bugs to the embedded and IoT community. Furthermore, Aaron is a Chapter leader for the Open Web Application Security Project (OWASP) Los Angeles, Cloud Security Alliance SoCal (CSA SoCal), and a Technical Editor for Packt Publishing. He has contributed to many IoT security guidance publications from CSA, OWASP, Prpl, and others. Follow Aaron’s latest research on Twitter at @scriptingxss
Hi Aaron, thank you for being part of our Thought Leadership series. Could you start us off by giving us a brief background of your involvement in IoT security and OWASP?
Thank you Lani, I am happy to share my insights with IoT Sec Australia. Definitely! My involvement in IoT Security stems from my time on the product security team for Belkin and Linksys. Having first-hand experience into how IoT products are designed from inception to deployment into production helped me understand the challenges that place IoT at risk. With this experience, I have edited IoT security books, now writing an IoT Penetration Testing cookbook, edited IoT security courses, and contributed to several IoT Security guidance papers with Cloud Security Alliance (CSA) as well as OWASP; leading the Embedded Application Security project.
Security professionals like yourself have long advocated for a "Secure by Design" approach to IoT. Pragmatically though, what does this mean?
Secure by Design is a principle that builds security controls into a product starting from the requirement stages before any code is written with a goal of establishing secure defaults. Typically, communication between a product manager, program manager, engineering manager/director, security professionals and sometimes legal departments are involved in reviewing proposed business product requirements where each representative discusses their respective input from their perspective. At this time, security professionals can discuss potential risks and suggest proposed security controls. When in a requirements stage, many items may be influx. Proposing security principles may help to ensure the team is aware of such requirements before code is written. For instance, proposing the following security requirements may work for initial meetings and then may be tailored accordingly once the product matures:
Security configurations must be enabled by default
Ensure the device fails securely
Communication to and from the device must be over TLS
Ensure data is stored securely on the client application(s) and device
The next stage of the development process is threat modeling the device’s ecosystem. Threat modeling is performed prior to deploying the device to market as a cross functional exercise between technology teams. Upon completion of threat modeling, potential risks, their impact, as well as mitigations should be established and agreed upon by the business. Later, the security controls employed within the device’s ecosystem are penetration tested prior to production as well as when new builds are created throughout the device’s lifecycle.
To alot of companies providing IoT enabled services, particularly startups this adds complexity, cost and extended project timelines. What would be your guidance to an company producing an IoT enabled service who values secure by design but also exists in a competitive landscape?
Security by design does not require a security professional to be on staff. It is more of a mentality or thought process that incorporates threats and their associated risks into design decisions. A piece of guidance I often give to any company building software is incorporating threat modeling into their development lifecycle. Basic threat modeling exercises would prevent the common IoT bugs we are seeing in the market. Threat modeling is free and there are plenty of tools as well as resources to aid development teams. The only cost is the time spent creating the threat modeling and communicating with the technology teams. This time can be as little as an hour or days depending on the complexity of the environment. A simple white board could be used to jot down how each IoT enabled service communicates within the deployed environment. Not only will threats be more apparent but safety and privacy concerns will be brought to light. As the IoT enabled service matures, threat models should be iteratively updated
Another challenge that comes to mind is the current skills/talent shortage which is a global phenomena. Given this area requires a high degree of technical expertise, should providers of IoT enabled services make more use of third parties/consultancies/contractors?
Hiring a third-party to review an IoT providers service may be dependent on the maturity, regulatory needs, and budget (if a start-up) of the IoT service provider. It is never a bad idea to have extra set of eyes but there is also an issue of vetting the third-party consultancies/contractors when the provider does not have a clue what to look for. On the other hand, an experienced consultancy/contractor could help build a security culture and program within a provider's company. As a consultant, I have seen a rise in start-ups as well as capital investors looking towards third party firms for assistance in secure design and architecture services as well as penetration testing services. A rise in IoT mergers and acquisitions (M&A) are also utilizing third party security firms for such services as well.
One of the challenges of "Secure by Design" is the complex nature of the IoT ecosystem. Your presentation at Defcon 23 demonstrated just how many layers/components were involved in a single device ie, it's supply chain. How does an organisation who is a user of IoT ensure this supply chain is adequately secured?
Great question! Depending on the industry vertical of the organization, there may be minimal verification of an IoT’s supply chain such as the utilization of a bill of materials document required as a service agreement. Although, unless security testing is manually performed against the IoT device there is not an established function (that I am aware of) to ensure the security of the supply chain prior to purchasing a device. In the future, “industry 4.0” may help with ensuring supply chain security with transparency into a device’s supply chain both in hardware as well as software.
Standards has been touted as an answer to the challenge of complexity and diversity of IoT. Do you agree and why?
I believe standards are a baseline to address some of the challenges within IoT. However, IoT is not one “thing” or industry. IoT spans across many industries, countries, and regulatory bodies where there is no "one size fits all" approach to address the challenges we are seeing in the market. The basic security principles still apply to all information systems included in an IoT system however the practicality may vary. For example, we have experienced the world’s largest DDoS attack in 2016 against vulnerable consumer IoT DVR’s that failed to employ basic security controls into products. This may be due to the lack of security personnel building the devices, lack of a regulatory body enforcing controls, or lack of incentives in the consumer market to build security into products.
Australia's primary science research organisation Data61 is developing a trustworthy system to harden at the chip level. One of the downsides is the cost may not make it applicable to most IoT devices. What are your thoughts on Trustworthy systems?
Trustworthy systems seem to be promising for industries that can afford the solution. All devices should be created in a manner that takes into account hostile environmental variables and perform its functions despite potential disruption. At this time, these industries are mainly those who do business in a regulated environment or commercial device makers who do business in a regulated environment (cyber physical systems, medical, connected vehicles etc.). Unfortunately, these solutions tend to be closed and unavailable for the public review. It has been proven that security through obscurity is not a valid control. I would like to see more trustworthy system makers who have a more open approach to sharing their source code and design to the community for review. With greater transparency comes greater trust with user’s and the community.
Thanks Aaron, your insights have been invaluable. Any parting recommendations for security professionals to stay up to date on security issues in the IoT ecosystem?
It’s been a pleasure Lani. For staying up to date on IoT Security, I leverage working groups such as CSA’s IoT working group, LinkedIn groups (anything embedded and IoT) , Twitter feeds (too many to list but ping me if interested), and many slack channels I am a member of (e.g. OWASP, I am the Cavalry, etc). If readers are interested in embedded security, I lead an OWASP project that many could benefit from called “OWASP Embedded Application Security Project”. Readers can follow my latest IoT security research on Twitter at @scriptingxss.
