Endpoint

5/16/2018
07:00 PM
50%
50%

7 Tools for Stronger IoT Security, Visibility

If you don't know what's on your IoT network, you don't know what to protect -- or protect from. These tools provide visibility into your network so you can be safe with (and from) what you see.
Previous
1 of 8
Next

(Image: Geralt)

(Image: Geralt)

It's hard to protect what you don't know you have. Put another way, it's those "unknown unknowns" that tend to get you. And the number of unknown unknowns is increasing because of the rapid rise in enterprise IoT devices and the incredibly disruptive rise of the "shadow IoT" that parallels the shadow IT seen in the traditional IT space. That's why one of the words most commonly heard at security conferences is "visibility," and why getting a handle on what's actually attached to the network is a critical step in any security plan.

It's also why there are so many new tools for getting that critical visibility, all looking at the computing environment from different vantage points.

Visibility for security means knowing all of the devices attached to the network, all the software running on those devices, which cloud services they might be using, and more. Traditional instruments of network visibility - like the tap or span port - might not be enough for IoT. While these are valuable tools when use as part of non-destructive traffic flow analysis, they're layer 1 devices that don't, in and of themselves, provide the kind of network or IoT visibility that comes through the systems included here. They may provide access to the network, but they don't provide analysis.

The good news is, the visibility-increasing IoT security-enabling tools listed here can help your IT team in more ways than one. The same tools that provide visibility for security can often provide visibility for management and operational analytics or other applications through APIs; or, improved visibility might be a critical piece of a larger IT solution.

Here are seven options for your security team to consider:

 

 

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Previous
1 of 8
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
To Click or Not to Click: The Answer Is Easy
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  11/14/2018
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19279
PUBLISHED: 2018-11-14
PRIMX ZoneCentral before 6.1.2236 on Windows sometimes leaks the plaintext of NTFS files. On non-SSD devices, this is limited to a 5-second window and file sizes less than 600 bytes. The effect on SSD devices may be greater.
CVE-2018-19280
PUBLISHED: 2018-11-14
Centreon 3.4.x has XSS via the resource name or macro expression of a poller macro.
CVE-2018-19281
PUBLISHED: 2018-11-14
Centreon 3.4.x allows SNMP trap SQL Injection.
CVE-2018-17960
PUBLISHED: 2018-11-14
CKEditor 4.x before 4.11.0 allows user-assisted XSS involving a source-mode paste.
CVE-2018-19278
PUBLISHED: 2018-11-14
Buffer overflow in DNS SRV and NAPTR lookups in Digium Asterisk 15.x before 15.6.2 and 16.x before 16.0.1 allows remote attackers to crash Asterisk via a specially crafted DNS SRV or NAPTR response, because a buffer size is supposed to match an expanded length but actually matches a compressed lengt...