The current generation of IoT devices have mostly neglected security. Some of the reasons are:
1. No immediate cost, or penalty for weak or no security: A device manufacturer does not have any reason to make the device secure as there is no penalty to the manufacturer. On the other hand, Smart meter hacks can result in direct losses to the utility and are hence being made secure. A typical example (see references) is the situation where Tripwire contacted an IP camera manufacture and got a standard dismissal.
2. Added upfront cost: Code scanning, security testing and threat modeling take time. A single license costs $5000 and requires installation and fixing issues with code. I have noticed a resistance from teams because of the large number of false positives and initial failures in following through with the program.
3. Quicker time to ship and Minimum Viable Product Strategies: Secure design, coding and testing takes time and resources. It is far easier to ship early and ignore security issues. The concept of the Minimal Viable Product generally ignores security.
4. Unclear Security Requirements: How much security is good enough is not always clear. Clearly all the Hacked Video Cameras costing $25 had no security and a Hardware Security Module has an extreme about of security but costs $25,000. There are very few standards or techniques. For example, very few people are aware of a risk based approach for security risk assessment (FAIR). Different devices need different levels of security. For example, a smart card or a smart electric meter needs hardware protection from intrusion but a webcam doesn’t. On the other hand, a webcam is connected to the internet directly while the smart card and the smart meter are isolated.
5. Impact not understood: The fact that any device, once connected to the Internet, can get infected was mildly understood. The real impact of millions of infected devices spewing out attacks was never even contemplated by the manufacturers and dismissed by them as the monetary damages were minimum. The current DDoS attack is occurring because the cost of DDoS and any liability related to privacy for devices like webcams were completely not accounted for. The cost of a recall can be 10X of manufacturer’s sale price to the retailer.
6. Lack of resources to address security issues:
a. R&D: Most engineering organizations lack the time or resources to follow through on Secure Development Life Cycle.
b. Manufacturing: Most Manufacturing organizations struggle with making devices secure.
c. Support: Most Field support personnel have trouble with fully secured devices.
d. Interface Design: And most secure devices need to be easy to use; the common issues related to password length, complexity, and uniqueness are just some of the issues related to making a device secure.
A New Approach
There is no panacea; we can’t patch our way out of this mess. We have to approach the problem on a broad front. Throwing a security engineer at the problem is not good enough.
1. Set standards for IoT Devices. This is not an impossible task. If it can be done for smart meters, it can be done for IoT devices. This is where NIST and other standards bodies come into play. The current EAL, PCI, and FIPS standards do not work for low cost devices. A more industrial level approach is Factor analysis of information risk (FAIR). The approach is based on risk and the cost to mitigate the risk.
2. Set up a Security Certification Process: The current EAL certification process (and similar ones) are laborious and extremely expensive. We may want to set up systems like the UL Labs certification process. The current process, for example, used for smart meters and set top boxes is based on industry accepted best practices but are not standardized.
3. Organizational Approach must change: The current approach of patching our way out of this mess is not going to work. The issues must be addressed by all stake-holders including sales, marketing, manufacturing, field support, engineering, security incidence planning, etc. Some ideas that have worked in my experience:
a. Executive Level Function: Security should be an essential business activity reporting to the CEO and the Board. The cost of a recall or the penetration of a device's security can be extremely expensive and may damage the brand name. The Board must be aware of any potential for any damage.
b. Reward Security Wins: Internal compensation, which drives most, if not all people, should have security quality as a key metric. Most industries call these Key Performance Indicator (KPI). For example, Marketing will definitely include security as a key product requirement if it helps them meet their KPIs.
c. Security Champions: Have security champions in every business unit. The champions know the language of the sub-organization and will know how to communicate the requirements properly as security is a completely different domain.
d. Security Maturity: Evaluate the organizations Security using any of the Security Maturity Modeling tools available and take corrective action.
e. Training and follow-through: Almost everyone has had a gym membership at one time or another but less than 5% follow through. Similarly, train people in security but do follow through on execution by making security a KPI and holding people accountable for delivery.
f. External Validation of Security: It is easy to pat ourselves on the back but do use an external security vendor to fully test your product.
4. Customer Advocacy Groups: Customers MUST be able to demand secure products. Customers MUST be educated and given the tools to identify well secured vs. badly secured products. The requirements for standards and security certification should be demanded by the customers.
5. Attack Mitigation Processes Must Be Created: These are formally known as Incidence Response Plans. With anyone and everyone wanting to connect to the Internet, there must be tools and processes to prevent attacks from proliferating throughout the Internet. The DDoS attacks were a call to arms. The degree of collaboration required between manufacturers, service providers, and the many parts of the Internet is huge. Instead of just having isolated plans, we should start moving towards a global IoT Attack Mitigation Plan.
6. Hold Product Vendors Liable: Just like Target is being held liable for credit card losses by the banks, these device manufacturers must be held liable for any disruption and even non-compliance to the standards.
If you would like to receive more updates and have specific questions, please connect to me via LinkedIn at https://www.linkedin.com/in/rajeshkanungo
1. Vulnerability: Who is Watching Your IP Camera? https://www.tripwire.com/state-of-security/vulnerability-management/vulnerability-who-is-watching-your-ip-camera/
2. Factor analysis of information risk (FAIR): https://en.wikipedia.org/wiki/Factor_analysis_of_information_risk
3. Minimum Viable Products are Dubious in Critical Infrastructure: http://www.robertmlee.org/minimum-viable-products-are-dubious-in-critical-infrastructure/
4. Startup Security: Minimum Viable Product Shouldn’t Mean Minimum Security: https://www.tripwire.com/state-of-security/security-data-protection/startup-security-minimal-viable-product-shouldnt-mean-minimal-security/
5. Capability Maturity Model: https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration