Unsecured industrial sensors present a security risk for the enterprise supply chain - customers, suppliers, and even the enterprise itself. These unsecured devices are vulnerable to attack which can disrupt operations and even cripple the business. As part of a healthy risk management and security framework, businesses should adopt SensorSecure to detect and address these vulnerabilities.
What it does
SensorSecure is a detection and alerting platform that provides actionable intelligence for Enterprise Risk and Security teams. The powerful and interactive visualization interface provides insights on exposed sensors that are vulnerable to attacks. The platform is powered by an automated IP-geolocation model and linked data to identify potential customers and other entities in your supply chain. It also provides contact information for each associated entity to help you quickly re-mediate the situation. This web-based platform is also available on-the-go via mobile so you can receive alerts anytime, anywhere. Access our demo at SensorSecure.
How we built it
The end goal was to have a list of potential customers that are at increased risk/vulnerability because some of their IoT devices are currently connected to the web, when these devices should not be connected. To find a list of potential customers, we followed a set of steps that will be outlined below.
Step 1: Find a list of vulnerable IP addresses
We used the Shodan search engine to get a list of potential vulnerable IP addresses related to connected GE-IoT devices, specifically PLC 90*30 Series controllers. We made sure to tailor our search query to limit the number of results to the relevant PLC controllers in mind. As such, our search query was similar to:
port:18245,18246 product:"general electric" country:"US"
since the ports these PLC controllers operate on are
18246. We restricted ourselves to ones in the US. Manually, we looked at the results, and retrieved the IP addresses into a list in a csv file.
Step 2: Get additional info from Censys
For each IP address in the list provided from Shodan, we then used the Censys search engine to get additional information about each IP. We found that the
lat/lng parameters from Shodan were not accurate (often pointing to Cheney Reservoir). Therefore, we tested the
lat/lng parameters from Censys. Often these were not accurate either, but the result at least gave us additional information, such as the
prefix_route of the IP address.
Step 3: Get the lat/lng from ipinfodb
Once we got the
prefix_route from the Censys search engine, we plugged this route into IP Info DB and got a more accurate
Step 4: Get potential customers nearby
Once we had a more accurate
lat/lng, we used the Google Maps interface to find potential customers nearby that may be at risk. Such customers may include:
- Water Treatment Facilities or Water Departments
- Power Plants
We manually looked around the
lat/lng for these potential customers and aggregated data including full name, address, and phone number about each potential customer that may be at risk.
Automation in Mind (backend)
The four steps outlined above were a very manual effort. To facilitate this in the future, we built an automated pipeline in
python that performs each of these steps. All of the functions and utilities are included in the github repo and file
*List of functions: *
get_ips_from_shodan: (Step 1) gets a list of IP addresses from Shodan
get_info_from_censys: (Step 2) gets additional info from Censys
get_true_lat_lng_from_ipinfodb: (Step 3) Gets true
lat/lngfrom IP Info DB
get_location_from_google_maps: (Step 4) Gets the name/address/phone number from the Google Maps Places and Nearby API
We believe further automation of the sensor detection and geolocation could be accomplished by using the paid APIs for Shodan and Censys.
Front End Interface
The user interface was built with the end user in mind.
By conducting user feedback sessions with GE staff we were able to come to a consensus on the important factors the app required, how they would interact with it, and how it could properly address the problem at hand.
The framework is lean and expandable to accommodate change in datasets and future upgrades.
This was accomplished by using:
Through each rendition of the UI our team validated that we were on task and focused on ensuring that our output met and/or exceeded the requirements of our end users. The application also has the ability to be deployed on mobile devices with the opportunity to be fully functional on phones as well.
What we learned
Finding the geolocation of a sensor is much harder than expected because IP providers obscure location information to prevent fraud. It requires using multiple sources of information and following bread crumbs to uncover the true details.
What's next for SensorSecure powered by Octane
Add real-time alerts for ongoing monitoring to enhance workflow functionality. The user will also be able to take action with each alert - either choosing to investigate further or silence a known threat. History logs can drill down prior activity by sensor, entity or location. We will also expand functionality to screen for other types of industrial sensors.