The Internet of Things, or IoT, is a fancy way of saying ‘same problem, different day’ in terms of security.
Most security professionals I know groan and roll their eyes each time they hear this buzzword –knowing that buzzwords aside, code is code, and all code contains security vulnerabilities. This is true no matter if the code is running on a server, desktop, laptop, tablet, phablet, phone, industrial control system, car, insulin pump, fitness tracker, home temperature control system, or refrigerator.
The issue we’re seeing in these latter products is that vendors—who have never run code inside these devices before or haven’t previously exposed their code to the Internet—are often the same vendors manufacturing them.
In turn, they are making enough coding errors that many ‘low-hanging fruit’ are present in their code, like simple buffer overflow vulnerabilities or cross-site scripting errors.
Even though these newer vendors of interconnected Things know they will need some way for friendly hackers, or security researchers, to report vulnerabilities in their products to them, they are often stuck in the early stages of what I call “The Five Stages of Vulnerability Response Grief.”
Lastly, the vendors who don’t know security history are doomed to repeat it.
Gaps in Software Security for All the Things
For code that runs on servers, desktops and laptops, hard lessons in security were learned because of widespread, frequent attacks sweeping through the early Internet, bringing systems and the organizations that depended on them to their digital knees. The “Age of the Great Worms” in the early 2000s acted as a forcing function to get software vendors to re-evaluate their priorities, adding security as an important pillar on which their bottom line depended.
These older software vendors started trying to not only fix security issues, but more importantly, also build security in from the beginning. The new vendors making interconnected, ubiquitous, Internet-exposed Things should be focusing their heaviest security investments into proactively trying to harden their future products and services via a Security Development Life Cycle, otherwise they risk making security mistakes in design and implementation, which are more difficult to address after the code is deployed.
Vulnerability Response and Coordination
But what happens when a vulnerability is found in code that is already deployed? Do these IoT vendors have a coordinated vulnerability disclosure policy, letting friendly hackers know how to report potential issues to them?
This is one of the basic capability requirements outlined in a new ISO standard on vulnerability disclosure published in early 2014 – ISO 29147. A related standard, ISO 30111, provides organizational guidance on how to investigate, triage and make remediation decisions on vulnerabilities discovered both during internal testing, or reported from outside an organization by a hacker, customer, partner or anyone else.
However, most organizations, let alone new IoT vendors, haven’t yet heard about these standards or understand how to use them – yet guidance on these two ISO standards exists.
Thing or No Thing – If You’re On the Internet, You Are Being Tested for Vulnerabilities
…You just may not be getting the report.
Attackers on the Internet have been around since the beginning, evolving during this time too, going from motivations around curiosity and fame to hacktivism to crime and fraud. The race between attackers and defenders was met and enabled by a growing security industry and broader ecosystem, all providing some goods and services to aid attackers or defenders or both.
The only difference between the world we came from and the world we are entering with this new trendy term for “ubiquity” is that we have a chance to build these new systems with lessons learned from the waves of technology by other names that came before.
Internet of Things vendors, as well as all other organizations with exposure to the Internet, must understand that all code contains bugs, even after strong investments in secure code development, and that they will eventually be under attack.
Being prepared means planning a meaningful and effective response to those attacks, while building partnerships with the hacker community – who often stand as sentinels before new widespread exploitation takes place. The path forward is to build a resilient computing ecosystem that is increasingly expensive to attack, and increasingly reasonable to defend.
The tools and knowledge to defend are already with us, but it falls to us to follow the principles and bring these lessons to new industries.
About the Author: Katie Moussouris is the Chief Policy Officer for HackerOne, a platform provider for coordinated vulnerability response & structured bounty programs. She oversees the company’s philosophy on vuln disclosure, advises customers & researchers, & works to legitimize & promote security research to help make the internet safer for everyone. Katie’s earlier Microsoft work encompassed industry-leading initiatives such as Microsoft’s bounty programs & Microsoft Vulnerability Research. She is also a subject matter expert for the US National Body of the International Standards Organization (ISO) in vuln disclosure (29147), vuln handing processes (30111), secure development (27034), and penetration testing (20004). Katie is a visiting scholar with MIT Sloan School, doing research on the vulnerability economy and exploit market. She is an ex-hacker, ex-Linux developer, & persistent hugger. Follow her and HackerOne on Twitter http://twitter.com/k8em0 and http://twitter.com/hacker0x01
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
The Executive’s Guide to the Top 20 Critical Security Controls Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Image courtesy of ShutterStock.