IoT
3/3/2016
10:30 AM
Pritesh Parekh
Pritesh Parekh
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

IoT Security Checklist: Get Ahead Of The Curve

The security industry needs to take a Consumer Reports approach to Internet of Things product safety, including rigorous development practices and both physical and digital testing.

In just two to three years, the Internet of Things will be a major avenue for hackers for the simple reason that everything is going to be connected. What systems and processes do security professionals need to put in place to defend against IoT product risk in the not-too-distant future? Here is a checklist of 9 IoT security strategies that belong in every stage of the product development life cycle

#1. Begin at the beginning to reduce attack points

Every phase of the development process must take digital security into consideration. Security should be a part of product requirements and design consideration, and be embedded at every stage of the development life cycle. The Quality Assurance cycle must account for security in addition to functionality. An important component of this is fail-safe systems. When something fails - and things will fail - it should be built to fail safe and secure so that the failure can be contained and doesn’t lead to a greater systemic failure.

#2. Authentication & authorization

Your car, your garage door opener, your medical device - all of these things have to communicate with other devices and, potentially, a mothership. The IoT will need strong authentication for these communications, using techniques like multi-factor authentication or asymmetric encryption to protect each device by using their own unique key.

You can’t expect a user to enter a password every time they get into their car, so there needs to be another form of security. One of the stronger forms of authentication is certificate-based in which devices have embedded certificates that can authenticate to the mothership. For example, a connected car should have a private certificate that it uses to communicate to the mothership. If a private certificate is compromised, the consumer is issued a new certificate securely. In this way, cars can safely communicate with the mothership to download patches, etc.

Authorization is also important. Strong authorization means role-based access controls that can be enforced to limit exposure: if a specific part of a product is compromised, it can be contained and not escalate into other components.

#3. Encryption

Sensitive personal data that is stored on a device needs to be encrypted at rest. And all communication to and from the device (to another device or to the mothership) must be encrypted in transit using secure protocol. Key management is also an important consideration. If someone has potential access to a device, they shouldn’t be able to extract data. The actual key that protects data needs to be protected.

#4. Privacy

With collected data, there must be transparency into the type of data that is collected, how it is used, and, if feasible, opt-out options. By default, personal data collection should be limited to only that which is necessary. For example, with a connected car, you may need a consumer’s VIN number, but why would you need personal data like their birthday? If you don’t need the info, don’t collect it. Only protect what you need to protect in order to reduce exposure.

#5. Consumer awareness

Some of the responsibility for IoT security falls to the consumer but as professionals, we need to build this consumer awareness. If you look at the credit card market, you see companies sending notifications to consumers with alert warnings and best practices for sharing credit card information. Empowering consumers with this information is a good practice: consumers can assist in an organization’s efforts to prevent fraud.

IoT security professionals also need to take a defensive posture with IoT by thinking about vulnerabilities before breaches occur, especially now, while the advance is still currently low. Communicating directly with consumers about these types of security best practices is an important touch point. For example, if a consumer is driving a connected car, what are the security features he or she needs to know about that car? 

#6. Security testing: digital & physical

Testing is key to IoT security. With IoT devices, this testing has to include digital testing as well as brutal physical product testing. We need to take a Consumer Reports’ approach to ensure that products can hold up to such testing, following best practices such as proactive hunting and continuous security testing. It’s not possible to detect everything during the product life cycle, so continual testing and patching is also a key consideration.

Safety airbags are a good example. When companies test their cars, airbags are always one of the top features tested for safety. There are literally hundreds of tests just to ensure that airbags are turned on at the right time. Security professionals need to invest the same level of rigor to digital testing, so that an unauthorized hacker can’t just remotely turn off your airbag while you’re driving.

#7. Third-party testing

It’s not enough for security professionals to perform internal testing on IoT products. Once products have been built and internally tested, there needs to be an additional check to uncover security flaws by a third party that specializes in IoT security. This will give manufacturers time to address potential issues without impacting consumer security. Likewise, whenever you make any significant changes to your product, you’ll need to recruit third-party testing again.

#8. Internet-enabled security software updates and vulnerability management

Remote patching of IoT devices is a critical requirement. The Chrysler Cherokee flaw resulted in a physical recall of 1.4 million vehicles; a remote patch functionality would have negated the need for a physical recall and contained the risk more quickly. Patching not only leads to lower risk, but also cost savings for the vendor, and an improved customer experience. Vulnerability management is a product discipline that should be embedded as part of the product life cycle.

#9. Security analytics to detect intrusion

The amount of data that is generated by IoT is enormous; we’re talking real big data. The challenge is that traditional intrusion software cannot effectively process so much data. So there needs to be new technology (based on machine learning, data science, security analytics) to help detect intrusion and to detect malicious traffic patterns on IoT devices. Security professionals need to be working on creating technology to support this, to set up trigger alerts when someone is attempting to bypass security.

We’ve seen companies in other sectors fail to perform proper due diligence and invest in security. The result? Massive breaches which lead to loss of consumer confidence, falling stock prices, and major organizational shake-ups. For IoT, the risks are even greater. While we’re still in the early stages, now is the time to build out a proactive and thorough security program to protect against threats that we haven’t yet even begun to imagine.

Related Content

  

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

Pritesh Parekh is the VP & CSO of Zuora. He has over 15 years of experience in building and managing enterprise security programs, and a decade of leading security for cloud platforms. Prior to joining Zuora, Parekh was leading worldwide Security and Compliance for ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
priteshp
50%
50%
priteshp,
User Rank: Apprentice
3/3/2016 | 5:27:01 PM
Re: Encryption
Agreed. Especially, data at rest encryption is not widely adapted. 
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
3/3/2016 | 11:29:01 AM
Encryption
Encryption needs to be standard at this point. Its one of the stronger security safeguards and it seems that still some IoT devices resist implementation.
Register for Dark Reading Newsletters
Dark Reading Live EVENTS
INsecurity - For the Defenders of Enterprise Security
A Dark Reading Conference
While red team conferences focus primarily on new vulnerabilities and security researchers, INsecurity puts security execution, protection, and operations center stage. The primary speakers will be CISOs and leaders in security defense; the blue team will be the focus.
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: No, no, no! Have a Unix CRON do the pop-up reminders!
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.