The images of an Internet of Things (IoT) app world are iconic, futuristic and real. Trees kitted out with low-water sensors; cars that can alert drivers to less congested traffic routes and free parking spaces; and manufacturing shop floors where machines sense low inventory and automatically order replacements are all examples of the IoT. At the core of the IoT are machines or sensors that generate data, share that data and use that data to create a better and more efficient experience for companies and consumers.
This is exciting stuff. Who wouldn’t want to be warned of a car crash ahead and be automatically rerouted? What retailer wouldn’t want to have automated reporting that showed leggings are a trending back-to-school style but jeans aren’t, allowing the retailer to order more leggings before stock runs out? The promise is vast and exciting, but where there is a lot of data, there is always the potential to misuse or abuse that data and the applications that manage it. The impacts of misuse can range from the moderately spooky to the downright horrifying. This is where application development (app dev) security concerns come into play.
About a year ago, IBM took a look at how the emergence of IoT technology could affect application security and used the pending settlement terms in a Federal Trade Commission (FTC) case against IoT home camera provider TRENDnet. Since that post, the number of IoT devices has increased, and the IBM X-Force research team has created an IoT threat model to help companies understand the risk of the IoT. The final settlement with TRENDnet was approved, and FTC Chairwoman Edith Ramirez said companies creating IoT devices should “put security front and center” since developers are underinvesting in protecting people’s data.
What should organizations do to address the problem of IoT application security in 2014 and start investing in protecting their data?
Something Old
Part of the answer is to go back to the basics of secure application development. Though the range of IoT applications has changed in the past year, the basics of secure coding practices have not. Forgetting security lessons of the past often leads to a “Groundhog Day” cycle of repeating legacy errors like insufficient access control and poor cryptographic key management. To start, make sure the development and application security testing teams are well versed in the core guidance on developing secure code. These resources are still relevant in the IoT and include the following:
While the application use-case changes the risk ranking — for example, the impact of exploiting an app that is serving a blog on fat-free vegan recipes versus one that is managing a diabetic’s insulin pump — it doesn’t change the basic tenets of secure development. Start with defining the security requirements up front and then weave security, testing and risk assessment throughout the cycle.
Something Riskier
However, there are some fresh twists in the focus of app dev security for the IoT because the risks are much greater due in part to the sheer size of the data set and the potential negative impacts from exploits. The classic calculation for determining information technology risk is a “measure of the extent to which an entity is threatened by a potential circumstance or event,” according to NIST, and is typically represented as Impact x Likelihood = Risk, or I x L = R. As the size or magnitude of the impact increases, so does the risk. Risk assessments take into account two additional factors: threats and vulnerabilities, specifically the types of threats and vulnerabilities that inform the impact and likelihood determinations in the risk calculation.
In the IoT, these circumstances or events (attacks) have become both more likely and more impactful. Taking a simple example from health care, imagine a pre-IoT general practitioner’s office creates a Web app through which patients can book appointments online. The Web-based scheduling app is tied to the back-end scheduling app via a one-way script. The data set is pretty small, containing just the patients’ IDs and the providers’ calendars. The impacts of app misuse are also relatively small. Although the appointments could get messed up for a day or so, there is little risk of loss of life.
Now, imagine that office as fully instrumental for the IoT and part of a modern health system. The same booking system is now tightly tied to the complete patient record, billing and insurance, drug dispensing and the larger health system. A motivated and well-resourced attacker could exploit a vulnerability in the appointment booking system to access a patient’s full medical history, steal personal information for identity theft, improperly dispense drugs or even access unprotected medical devices within the health system’s network. The impact of the attack has increased by a few orders of magnitude.
Something New
With great risk comes great responsibility. That has promoted some additional guidance for IoT app dev. OWASP has come out with 10 considerations that highlight the importance of privacy protection and interface security. The sections on interface security are of particular note because “things” become “IoT” when they interface with the cloud and mobile devices. Failure to secure those interfaces puts the entire ecosystem at risk. Attack vectors include insufficient authentication, lack of transport encryption and account enumeration to access data or controls via the mobile interface.
To prevent misuse, OWASP recommends the following:
- Ensure user accounts cannot be enumerated using functionalities such as password reset mechanisms.
- Ensure account lockout after an appropriate number of tries.
- Ensure credentials are not exposed while connected to wireless networks.
As IoT technology matures, so will guidance on securing IoT apps.
Executive Security Advisor, IBM Security