The number of devices connected to the internet that makes up the Internet of Things—an amazing collection of sensors, TVs, refrigerators, dog collars, temperature gauges, and virtually everything else you can think of—is constantly expanding. Growth will only increase in the coming years, along with the need to pay closer attention to the Internet of Things and security.
While most businesses wouldn’t think that their office’s climate control system could leave their customers’ credit card information vulnerable, the sad truth is just the opposite. As I mentioned in a previous article, the 2014 Target data breach that resulted in the theft of credit card information for over 110 million unsuspecting customers began with an attack on the air conditioning system.
Unless businesses take this threat seriously, and measures are put in place to prevent it, similarly executed breaches are going to happen in the future. But how do you protect your customers’ data (not to mention your own) when hackers can access it through something as innocuous as a sound system? More importantly, what can developers do to keep their devices safe from attack?
The first step in Internet of Things and Security: Threat modeling.
You need to think like your adversary. Consider the ways that someone could make your “thing” do something you don’t want it to do, and what they might want to achieve. There are several ways that someone can exploit your device, including:
- Denial of service – prevent your system from performing its function
- Assume control – change what your system does, for their own purposes
- Falsify or exfiltrate data – steal your data, or hide their actions from your sensors
- Destroy the device – outright destruction of property
- Indirect attack – Leverage the device to penetrate some other part of the network
Plan for these potential lines of attack, and determine what kind of vulnerabilities you may need to cover during your development process.
The next step is to build security into your embedded device network.
Give your engineers the time and the tools they need to write their code securely in the first place. To get an idea of what is available and some of the considerations you should take, the DHS resource Build Security In is a good place to start.
Keep in mind that quality and security work hand-in-hand, each complementing the other. When the application is high-quality, the code does what it is supposed to do. When the application is secure, the code does not do what it shouldn’t do.
Your team should be using tools that identify vulnerabilities as the code is being written, not after the code is done. Changes at that late stage are very expensive to correct, in terms of time to market, cost (there’s more to correct when the application is complete), complexity (one small change can affect other areas profoundly), and morale (it’s very difficult to motivate a team to make major changes when they believed that the application was “done”).
Types of security testing for Internet of Things systems include:
Manual inspection: This involves reviewing the code in search of potential vulnerabilities. Manual review can uncover vulnerabilities that automated tools can miss, but is difficult to scale appropriately.
SAST (Static Application Security Testing): SAST tools can discover theoretical issues, but can deliver a high number of false positives that can be time-consuming to analyze. SAST results need to be triaged to ensure their validity, because of the number of false positives. However, this kind of testing has the advantage of being both automated and scalable.
DAST (Dynamic Application Security Testing): DAST probes your application while it is running, trying many of the things that an attacker would use. It is most often used later in the development cycle, and is both automated and scalable.
It’s tempting to depend only on a single static analysis tool to detect vulnerabilities during the development process, but any one tool only detects a relatively small percentage of all weaknesses. The best approach is to use a combination of these tools, which is why we created Code Dx, which takes code through multiple SAST tools, integrates with DAST tools as well, and aggregates the results. This offers a wide range of advantages, and provides a much greater degree of accuracy when checking for security risks.
Your Internet of Things application should have security built into every aspect of it. The areas of risk include:
- Network defense: This aspect should be covered external to the device by intrusion detection systems (IDS), which monitor a network for unauthorized activity; intrusion prevention systems, which follow traffic to prevent network vulnerability exploits; firewalls; and antivirus scanners.
- Device defense: This includes simple things such as password protection, policy management, and patching systems to keep up-to-date with new security protocols. Two-factor authentication should be employed whenever practical. For example, withdrawing funds from an ATM requires both a debit card and a PIN; having one or the other is not enough.
- Application defense: Security standards should be in place during the development process. Vulnerabilities should be found during the development stage, not after the application is completed. Third-party code that is embedded into the application—especially open-source libraries—should be scrutinized for vulnerabilities. Any software that is purchased to help produce the application—indeed, any that is used on terminals upon which the application is developed, including things unrelated to it—should also be held to high security standards. Even things like third-party browser toolbars should be monitored closely to make sure they do not represent a security risk. Finally, the application should be protected by a firewall.
- Shared threat intelligence: It’s extremely important for developers to share information concerning cybersecurity threats. Not only could learning something new protect your own application, but any information you provide may also help another developer do the same. The Information Technology Information Sharing and Analysis Center, or IT-ISAC, is an invaluable resource for developers to help prevent cyberattacks, as is the Common Vulnerability Enumeration (CVE).
- User-created issues: Users themselves will often unknowingly create vulnerabilities within an application’s infrastructure. For example, users often will only keep a few simple passwords to access multiple applications and accounts; their email password is usually the same as the one they’ll use when they shop on Amazon, or when they access their banking information online. A vulnerability in one account, even if it’s entirely unrelated to your application, can create a security risk for others because of this. Your users need to be educated as best as possible to maintain a secure environment for themselves and other users.
As devices become more connected, risks and vulnerabilities will continue to expand. However, by maintaining a strict culture of security in your development process, those risks can be reduced, limited, and compartmentalized until they are no longer significant threats.
