Tag Archives: iot

Creating initial IoT risk categories

Leave a reply

With the onslaught of new IoT systems and devices as well as existing old school IoT-ish systems such as HVAC, we all know that this is risk that needs to be assessed and managed. However, some of it is so new that we don’t really know where to start. We don’t have a broadly understood language to discuss, categorize, and classify new IoT systems. There has to be at least some rough categorization if there is going to be any attempt to manage risk brought to our organizations by evolving and rapidly growing numbers of IoT systems and devices.

Whence it came — using provenance to create IoT risk buckets

One approach to an initial categorization to IoT systems and devices can be to identify where those IoT systems are coming from. How do they show up in your offices, buildings, and corporate/institutional spaces? How did they get there?

Some IoT just 'walks on' to corporate and institutional spaces while other IoT systems are purchased via different mechanisms

Some IoT just ‘walks on’ to corporate and institutional spaces while other IoT systems are purchased via different mechanisms

While trying to categorize IoT systems and devices by function, features, behavior, etc is a logical approach, it can be difficult to do in practice because so many new and varied IoT systems, devices, and applications are constantly showing up on our networks. Categorization and classification with this more traditional method can be a moving target, at least for now. Also, this approach can lead us down a rabbit hole looking for a perfect (and complex) taxonomy that would take a long time to develop, would likely be poorly understood, and probably largely not agreed upon. It reminds me of some older large websites that might have had perfect, library-like taxonomies but where 90% of the pages were never accessed.  The website’s taxonomy might have been awesome, but no one cared.  In fact, that perfect taxonomy might have actually diminished usability.

To begin the process of managing IoT risk now, we need some categorization now so that we have some buckets of risk to work with. This doesn’t mean that efforts to develop other classification schemes should be abandoned, but rather that categorizing IoT risk by source, aka the-way-it-got-here, is an approach that we can work with now.

Size matters

The manner in which businesses or institutions purchase IoT devices and systems typically varies with size of the organization. Smaller organizations will likely have fewer purchasing mechanisms than larger organizations. For example a small company might write a check or use a company credit card to purchase a simple IoT-based security system. Where as a larger organization might have a person or purchasing department that handles many purchases, uses purchase orders and invoicing, and probably has some purchasing policies and criteria and is used to purchase an HVAC system, for example.  And yet an even bigger organization or government might have a central planning office that makes recommendations for new buildings or large scale building or community asset modifications. Larger organizations probably have all of these.

Regardless of how many purchasing options an organization has, using purchasing options to create categorized buckets of risk for IoT devices and systems could be a helpful way to go.

Walk-On-IoT — bring it, wear it, or fly it to work

One thing that all organizations have in common is that they all have “walk-on-IoT”. By the walk-on-IoT category, I mean IoT systems purchased or acquired by an individual on their own and that they then bring to work. Whether it is FitBit devices, drones, robotics, consumer networked video cameras, or others, these are devices that a person can purchase at BestBuy, Target, Amazon, or even their local drugstore and bring directly to their corporate or institutional work place.

Other potential source-based IoT risk categories

Some other potential source-based IoT risk categorizations might be:

  • IoT devices/systems purchased with a company credit card
  • IoT devices/systems purchased via a company’s central purchasing/contracting group
  • IoT devices/systems recommended in the course of planning for major building modifications or new buildings (eg, in the case of large businesses and cities)
Identifying where an IoT system or device came from as a basis for initial IoT risk categorization

Identifying where an IoT system or device came from as a basis for initial IoT risk categorization

With these categories, we can start to ask some high level risk questions within each category. For example, is it even possible to feasibly manage this risk? If this risk is unmitigated, what is the impact? For example, can I really manage FitBit devices that walk on to my network? Probably not easily. More importantly, do I really care if FitBit users use their devices on my networks?  Maybe not.

Conversely, because of privacy issues and other concerns, I might indeed care about how an enterprise-wide biometric building access system is selected, installed, commissioned, and supported over its lifetime. Furthermore, this risk probably is manageable with thoughtful institutional safeguards.

Source-based categories can lend themselves to unique risk mitigation approaches

Finally, sourced-based IoT risk categorization can also provide some natural mitigation approaches. For example, purchases via central purchasing can provide the opportunity to see a purchase request (prior to actual purchase) and then provide guidance on the selection of the IoT system, help identify resources for secure implementation, as well as help develop long term support plans for the IoT system. While less involved, IoT purchases via corporate credit card have records amenable for review so that an organization can get an estimation of number and variety of types of IoT devices and systems arriving in the enterprise. This can help with ongoing mitigation and support services planning.

Source-based categories for IoT system risk analysis and management for the enterprise can be a place to start. It is not the end-all by any stretch. As more IoT systems and devices enter our enterprises, we will learn more about their short and long term effects as well as emergent effects between IoT systems. From this we can continue to evolve categories and approaches, but if we need a place to start now, source-based risk categories are not a bad idea.

Developing an IoT vendor strategy

Leave a reply

The vendor count for IoT systems that a company or organization manages will only increase in the coming months and years and it will possibly increase substantially. Some of this will be from traditional systems like HVAC that have been in the space longer than most and are maturing and extending their IoT development and deployment.  New growth in an organizations’s vendor count will be from vendors with brand new products and service lines made possible by IoT innovation and expansion.  Many of the benefits of IoT will be from products and services from different vendors that interact and exchange information with each other such as an IoT implementation leveraging the cloud.   Regardless of the source, the number of IoT vendors that an organization has will grow.

This increased IoT system vendor count is not a bad thing in its own right. However, a somewhat insidious effect is that the number of relationships to be managed (or not managed) will grow even faster than the increasing vendor count itself.

number of relationships grows increasingly faster than the number of nodes

number of relationships grows increasingly faster than the number of nodes

Relationships have friction

Every relationship has friction or loss from an idealized state. Nature has plenty of examples —  pressure loss in a pipe, channel capacity in information theory, marriage, and heat engine efficiency established nearly 200 years ago by Sadi Carnot. Carl Von Clausewitz famously established the concept of friction in war in his book On War in which he sometimes evokes the image of two wrestlers in a relationship.

Relationships between business customer and their vendors have friction too — from day-to-day relationship management overhead such as communication planning and contract management to more challenging aspects such as expectation alignment/misalignment and resource allocation problems.

heatengine

there’s a limit to how much work can get done between any two points

Friction in a business customer-vendor relationship (unavoidable to some degree) means less information gets communicated than expected, similar to Shannon’s observations on information exchange. And similar to limits expressed with Carnot’s engine efficiency, less work gets done in practice than in the idealized state. Particularly for the former, a reduction in expected information exchange, by definition, increases uncertainty. Further, friction in a network of relationships can manifest itself in yet even more uncertainty.  Less work gets done than is expected and the state of things is unclear.

With a growing network of nodes (IoT vendors in this case), the even faster growing number of relationships, and the friction that naturally exists between them, our business environments are becoming increasingly complex and accompanied with increased uncertainty. Vendor management and its associated risk, in the traditional sense, have left the building.

Sans organizational IoT strategy, IoT vendors will naturally optimize for themselves

While a strategy around IoT deployment and IoT vendor management can be difficult to devise and establish given the complexity and relative newness of the phenomenon, we have to acknowledge that vendors/providers will naturally optimize for themselves if we don’t have an IoT implementation strategy for our organizations.

This is not an easy thing. We really don’t know what is going to happen next in IoT innovation, so how do we establish strategy? Also, the strategy might cost something in terms of technical framework and staffing — and that is particularly hard to sell internally. However, without some form of an IoT system implementation strategy, each individual provider will offer a product or service line implementation that’s best for them. They won’t be managing the greater good of our organization. This is not evil, it’s natural in our market economy — but we as business consumers need to be aware of this.

Similar to the concept of building a socket in the last post, in establishing a policy or framework for IoT vendor relationships, some IoT vendor considerations might include:

  • Are there standard frameworks that can be deployed to support requirements from multiple different IoT vendors? For example, does every vendor need their own dedicated, staffed, and managed database? If individual vendors demand dedicated support frameworks/infrastructure, are they willing to pay for it or otherwise subsidize it?
  • Does your vendor offer a VM (virtual machine) image that works in your data center or with your cloud provider? Do they offer a service that helps integrate their VM image into your data center or cloud environment?
  • Are there protocols that can be leveraged across multiple different vendors? Does the vendor in consideration participate in open-source protocols? For example, for managing trust, Trusted Computing Group has extended some of their efforts in an open source trust platform to the IoT space.
  • Does the vendor provide a mechanism to help you manage them for performance?  If so, the vendor acknowledges the additional complexity that managing many IoT systems brings and offers to help you review and manage performance.

While an IoT framework or policy at this stage is almost guaranteed to be imperfect, incomplete, and ephemeral, the cost of not having one puts your organization at every IoT system provider’s whim.  And that cost is probably much higher.

Systems in the seam — shortcomings in IoT system implementation

2 Replies
Jose Abreu

Coming apart at the seams

One of the greatest areas of risk related to the Internet of Things (IoT) in an organization, corporation, or institution comes not necessarily from the IoT systems themselves, but rather the implementation of the IoT systems. A seam forms between the delivery of the system by the vendor/provider and the use of that system by the customer.  Seams, in themselves, are not bad. In fact, they’re essential for complex systems. They connect and integrate different parts of a system to work towards a cohesive whole.  However, how we choose to approach and manage these seams makes a difference.

Managing the seam

Seams are where interesting things happen. College baseball changed its ball seams this year to flat instead of raised to drive more hits and home runs and, sure enough, balls are traveling an average of 20 feet further.  There are seam routes in football where the receiver tries to exploit the gap between defenders. And anyone that’s ever sat in the window seat by the wing of an airplane can attest that there are many more seams than they would probably care to see. Finally, of course, seams can also be where things come apart.

More seams than I would care to be aware of

More seams than we would probably care to acknowledge

Vendor relationships and vendor management have always been important for firms and institutions. However, the invasive nature of IoT systems makes vendor management particularly important to successful IoT system implementation and subsequent operation. However, the work and staffing required to manage those customer-vendor relationships and to provide the oversight needed to operate safe and effective systems often gets obfuscated by the promises and shininess of the new technology.

IoT systems are different from traditional deployments of workstations, laptops, and servers. By their very nature, IoT systems have the ability to sense, record, transmit, and/or interact with the environments in which we live and work. Further complicating the IoT systems deployments and support, these systems may well be invisible to us and organizational IT might not even know the systems exist much less be able to provide central IT support.

Firms and institutions purchase IoT devices and systems en masse to address some need in their operation. These IoT systems might be related to environmental control and energy efficiency, safety of staff and the public (fire, security, other), biometric authentication systems, surveillance systems and others. Because of this, IoT devices can be brought into an organization’s physical and cyber space by the hundreds or thousands or more. When such systems and devices are partially or improperly configured, there can be significant consequences to the organization. Similarly, a lack of planning of long-term support, whether local or via maintenance contract with the vendor or both, can also have significant implications.

Cost of building a socket

In most organizations, implementing a third-party solution, whether hardware, software, SaaS, or hybrid, requires a supporting infrastructure for that solution. I call this supporting structure a socket. The customer organization must create a socket that allows the new vendor solution to interface with appropriate parts of the customer’s existing infrastructure. Taking the time and resources to plan, build, and maintain this socket is integral to the operational success of the new system. It also provides the opportunity to manage some of the risk that the new system introduces to the organization.

VendorSocket

Building a socket to support vendor IoT systems

Know yourself

One of the worst case scenarios for an organization is believing that an IoT system is managed when it is actually not managed. At this point in the evolution of IoT deployments, I suspect that this scenario is more of the rule than the exception. Given the scale and speed of IoT innovation and growth and the lack of precedence for managing this sort of risk, the famed Sun Tzu guidance to know yourself can be elusive.  The IoT phenomena will change how we seek to know and characterize our organizations as a part of the risk management process.  A good place to start knowing ourselves is planning, building, and managing that seam where the interesting things happen.

Socializing Internet of Things risk

Leave a reply
IoTRisk-g

adding risk from IoT doesn’t mean the existing risk to an organization conveniently disappeared …

There is a lot of conversation regarding security, privacy, safety and other issues regarding the ongoing proliferation of the Internet of Things (IoT). While IoT promises many helpful and useful things, concern about how it might (and will) be misused are valid. However, there are more than a couple of challenges to addressing this new source of risk to an organization.

Lions and Tigers and Bears

It’s easy for anyone to call out things that could happen with the IoT growth. Medical devices can be hacked , SmartMeters can be compromised and steal privacy information, the utility grid is widening its attack surface, drone video is intercepted and hacked , and countless others . Long live fear, uncertainty, and doubt, right?  While highlighting examples of IoT issues is important, the larger and more difficult thing for an organization to do is to communicate risk around IoT in a way that allows it to be managed.

Communicating IoT risk in an organization

Within an organization that already manages risk in some form, communicating and socializing the idea of IoT risk can be a challenge. There are at least two broad components to that challenge:

  • IoT defies traditional classification/categorization and is still little understood. It’s hard for people to wrap their heads around it
  • the other risks that the organization faces are still there. They haven’t gone away and IoT risk only adds to that

In order to begin to manage IoT risk, management must have some vocabulary for it. IoT is still new, its effects largely unknown and likely emergent, and precedents and analogies are few. We need to surface some language and concepts for it so that it can be discussed.

Another significant aspect of communicating IoT risk issues is that the other risks that an organization already faces — safety, liability, financial loss, reputation damage, technology challenges, business competition, and many more have not gone away. These risks are still there. We are asking senior management to make room in their list of existing risks that they are wrestling with to add yet more risk.  And possibly substantially more risk. Nobody wants to hear this.

Because of this, how we communicate these security, privacy, and risk issues is important. We are competing for a small slice of available cognitive bandwidth, so we must use this opportunity to communicate as well as we can.

Lather, Rinse, Repeat

If you either want to or are tasked with communicating IoT risk in your organization, I would suggest starting here:

  • find out what other risk the organization is already working with. Is there an annual report? Is there someone in the know in your network?
  • identify places where IoT is already in your organization or where you expect it
  • use the language of managing existing risk in your organization to begin to talk about IoT risk. If you have existing IoT risk examples, describe them in traditional risk language for your organization
  • repeat

A key to this communication is to get some IoT risk concepts out early. Give management some language to use to reflect on IoT risk and to discuss with their peers. It’s also important not to be heavy-handed in the approach. Yes, IoT risk is important, the impacts potentially very high, and the opportunities for abuse many, but the other existing risks that an organization faces haven’t gone away and they still must be managed too.

Chip producer ARM — major IoT player?

Leave a reply

ARM ChipUK company ARM Holdings appears to be backing up its claims as a major processor design player in the Internet of Things (IoT) market. ARM signed 53 licenses for processor designs compared with 26 the previous year.

Smart phones to IoT

While ARM is the chip designer behind the vast majority of the smart phones in the world, it is also aggressively entering the machine-to-machine market, a significant subset of the Internet of Things.

ARM further signaled its interest in Internet of Things marketshare with its purchase of Offspark last week, an IoT security firm. The company is also moving into server technology which, given the symbiotic relationship of IoT and the Cloud, could be a winning combination. ARM produced 12 billion chips in 2014.

Over 25 IoT devices per person on the planet

While some predict ARM might be slowing because of projected reduced smart phone sales, projections of 25 plus networked computing devices per person on the Earth, might give ARM plenty of room to work.

FTC IoT guideline describes complexity, nuance of IoT

Leave a reply
FTC IoT development guidelines http://1.usa.gov/1LeGOpX

FTC IoT development guidelines http://1.usa.gov/1LeGOpX

The Federal Trade Commission (FTC) has issued a guideline to companies developing Internet of Things (IoT) products and services. The guideline addresses security, privacy, encryption, authentication, permission control, testing, default settings, patch/software update planning, customer communication and education, and others.

IoT irony

The irony is that the comprehensiveness of the document, the things to plan for and look out for when developing IoT devices and systems, is the same thing that makes me think that the preponderance of device manufacturers will never do most of the things suggested. At least not in the near term. Big companies that have established brand, (eg Microsoft, Cisco, Intel, others) will have the motivation (and capacity) to participate in most of these recommendations. However, the bulk of the companies and likely the bulk of the total IoT device/system marketplace entries will be from the long tail of companies and businesses.

These companies are the smaller companies and startups that are just trying to get into the game. They won’t have an established brand across a large consumer base. This can also be read as, ‘they don’t have as much to lose’. Their risk and resource allocation picture does not include an established brand that needs to protected. They don’t have a brand yet. For most of these startup and small companies, they will view their better play to be:

  • throw our cool idea out there
  • get something on the market
  • if we get a toehold & start to establish some brand, then  we’ll start to worry about being more comprehensive with the FTC suggestions

Change

Again, to be clear, I am appreciative of the FTC guideline for manufacturers and developers of Internet of Things devices. It’s a needed document and is thoughtful, well-written, and thorough. However, the same document can’t help but illustrate all of the variables and complexities of networked computing regarding privacy and security concerns — the same privacy and security concerns that most companies will have insufficient resources and motivation to address.

We’re in for a change. It’s way more complicated than just ‘bad or good’. Where we help protect and manage risk for our organizations, we’re going to have to change how we approach things in our risk management and security efforts. No one else is going to do it for us.

Attacks on internet of things top security predictions for 2015

Leave a reply

iotattacks

Attacks on Internet of Things tops list of Symantec’s 2015 Security Predictions. The post and infographic say that there will be a particular focus on smart home automation. Interestingly, the blog post references what is likely the Shodan database, referring to it as a “search engine that allows people to do an online search for Internet-enabled devices,” but does not mention it by name. While attacks on IoT devices/systems or attacks via IoT devices/systems is certainly not the only risk, it is further evidence that the attack surface provided by the rapid growth of IoT/ICS devices and systems is a burgeoning risk sector.

The report also highlights attacks on mobile devices, continuing ransomware attacks, and DDOS attacks.

Cerealboxing Shodan data

Leave a reply

luckycharmsIn 2010, Steve Ocepek did a presentation at  DefCon where he introduced an idea that he called ‘cerealboxing’.  In it, he made a distinction between visibility and visualization. He suggested that visualization uses more of our ability to reason and visibility is more peripheral and taps into our human cognition.  He references Spivey and Dale in their paper Continuous Dynamics in Real-Time Cognition in saying:

“Real-time cognition is best described not as a sequence of logical operations performed on discrete symbols but as a continuously changing pattern of neuronal activity.”

Thinking on the back burner

Steve’s work involved building an Arduino-device that provides an indication of the source country of spawned web sessions while doing normal web browsing.  The idea was that as you do your typical browsing work, the device, via numbers and colors of illuminated LEDs would give an indication of how many web sessions were spawned on any particular page and where those sessions sourced from.  I built the device myself, ran it, and it was enlightening (no pun intended).

Using Steve’s device, while focused on something else — my web browsing, I had an indication out of the corner of my eye that I processed somewhat separately from my core task of browsing.  Without even trying or ‘thinking’, I was aware when a page lit up with many LED’s and many colors (indicating many sessions from many different countries).  I also became aware when I was seeing many web pages, regardless of my activity, that came from Brazil, for example.

Cerealbox

Steve named this secondary activity ‘cerealboxing’ as when you mindlessly read a cereal box at breakfast.  From one of his presentation slides:

  • Name came from our tendency to read/interpret anything in front of us
  • Kind of a “background” technology, something that we see peripherally
  • Pattern detection lets us see variances without digging too deep
  • Just enough info to let us know when it’s time to dig deeper

Back to excavating Shodan data

As I mentioned in my last post, Shodan data offers a great way to characterize some of the risk on your networks.  The challenge is that there is a lot of data.

One of the things that I want to know is what kinds of devices are showing up on my networks? What are some indicators? What words from ‘banner grabs’ indicate web cams, Industrial Control Systems, research systems, environmental control systems, biometrics systems, and others on my networks?  I started with millions of tokens.  How could I possibly find out interesting or relevant ‘tokens’ or key words in all of these?

To approach this, I borrowed the cerealboxing idea and wrote a script that continuously displays this data on a window (or two) on my computer. And then just let it run while I’m doing other things. It may sound odd, but I found myself occasionally glancing over and catching an interesting word or token that I probably would not have seen otherwise.

cerealboxunordered

unordered tokens

So, in a nutshell, I approached it this way:

  • tokenize all of the banners in the study
  • I studied banners from my organization as well as peer organizations
  • do some token reduction with stoplists & regular expressions, eg 1 & 2 character tokens, known printers, frequent network banner tokens like ‘HTTP’, days of the week, months, info on SSH variants, control characters that made the output look weird, etc
  • scroll a running list of these in the background or on a separate machine/screen

I also experimented with sorting by length of the tokens to see if that was more readable:

ordered5char

sorted by order — this section showing tokens (words) of 5 characters in length

In the course of doing this, I update a list of related tokens.  For example, some tokens related to networked cameras:

partiallist_networkcamera

And some related to audio and videoconferencing:

partiallist_telecom_videoconf

This evolving list of tokens will help me identify related device and system types on my networks as I periodically update the sample.

This is a fair amount of work to get this data, but once the process is identified and scripts written, it’s not so bad. Besides, with over 50 billion networked computing devices online in the next five years, what are you gonna do?

Excavating Shodan Data

Leave a reply
excavator

A shovel at a time

The Shodan data source can be a good way to begin to profile your organization’s exposure created by Industrial Control Systems (ICS) and Internet of Things (IoT) devices and systems. Public IP addresses have already been scanned for responses to known ports and services and those responses have been stored in a searchable web accessible database — no muss, no fuss. The challenge is that there is A LOT of data to go through and determining what’s useful and what’s not useful is nontrivial.

Data returned from Shodan queries are results from ‘banner grabs’ from systems and devices. ‘Banner grabs’ are responses from devices and systems that are usually in place to assist with installing and managing the device/system. Fortunately or unfortunately, these banners can contain a lot of information. These banners can be helpful for tech support, users, and operators for managing devices and systems. However, that same banner data that devices and systems reveal about themselves to good guys is also revealed to bad guys.

What are we looking for?

So what data are we looking for? What would be helpful in determining some of my exposure? There are some obvious things that I might want to know about my organization. For example, are there web cams reporting themselves on my organization’s public address space? Are there rogue routers with known vulnerabilities installed? Industrial control or ‘SCADA’ systems advertising themselves? Systems advertising file, data, or control access?

The Shodan site itself provides easy starting points for these by listing and ranking popular search terms in it’s Explore page. (Again, this data is available to both good guys and bad guys). However, there are so many new products and systems and associated protocols for Industrial Control Systems and Internet of Things that we don’t know what they all are. In fact, they are so numerous and growing that we can’t know what they all are.

So how do we know what to look for in the Shodan data about our own spaces?

Excavation

My initial approach to this problem is to do what I call excavating Shodan data. I aggregate as much of the Shodan data as I can about my organization’s public address space. Importantly, I also research the data of peer organizations and include that in the aggregate as well. The reason for this is that there probably are some devices and systems that show up in peer organizations that will eventually also show up in mine.

Next, using some techniques from online document search, I tokenize all of the banners. That is, I chop up all of the words or strings into single words or ‘tokens.’ This results in hundreds of thousands of tokens for my current data set (roughly 1.5 million tokens). The next step is to compute the frequency of each, then sort in descending order, and finally display some number of those discovered words/tokens. For example, I might say show me the 10 most frequently occurring tokens in my data set:

devices1st10

Top 10 most frequently occurring words/tokens — no big surprises — lots of web stuff

I’ll eyeball those and then write those to a stoplist so that they don’t occur in the next run. Then I’ll look at the next 10 most frequently occurring. After doing that a few times, I’ll dig deeper, taking bigger chunks, and ask for the 100 most frequently occurring. And then maybe the next 1000 most frequently occurring.

This is the excavation part, gradually skimming the most frequently occurring off the top to see what’s ‘underneath’. Some of the results are surprising.

‘Password’ frequency in top 0.02% of banner words

Just glancing at the top 10, not much is surprising — a lot of web header stuff. Taking a look at the top 100 most frequently occurring banner tokens, we see more web stuff, NetBIOS revealing itself, some days of the week and months, and other. We also see our first example of third party web interface software with Virata-EmWeb. (Third party web interface software is interesting because a vulnerability here can cross into multiple different types of devices and systems.) Slicing off another layer and going deeper by 100, we find the token ‘Password’ at approximately the 250th most frequently occurring point. Since I’m going through 1.5 million words (tokens), that means that ‘Password’ frequency is in the top 0.02% or so of all tokens. That’s sort of interesting.

But as I dig deeper, say the top 1500 or so, I start to see Lantronix, a networked device controller, showing up. I see another third party web interface, GoAhead-Webs. Blackboard often indicates Point-of-Sale devices such as card swipers on vending machines. So even looking at only the top 0.1% of the tokens, some interesting things are showing up.

LantronixGoAheadBB

Digging deeper — Even in the top 0.1% of tokens, interesting things start to show up

New devices & systems showing up

But what about the newer, less frequently occurring, banner words (tokens) showing up in the list? Excavating like this can clearly get tedious, so what’s another approach for discovery of interesting, diagnostic, maybe slightly alarming words in banners on our networks? In a subsequent post, I’ll explain my next approach that I’ve named ‘cerealboxing’, based on an observation and concept of Steve Ocepek’s regarding our human tendency to automatically read, analyze, and/or ingest information in our environment, even if passively.

Poor Man’s Industrial Control System Risk Visualization

Leave a reply

The market is exploding with a variety of visualization tools to assist with ‘big data’ analysis in general and security and risk awareness analysis efforts in particular. Who the winner is or winners are in this arena is far from settled and it can be difficult to figure out where to start. While we analyze these different products and services and try some of our own approaches, it is good to keep in mind that there can also be some simple initial value-add in working with quick and easy, nontraditional (at least in this context), visualization

Even simple data visualization can be helpful

I’ve been working with some Shodan data for the past year or so. Shodan, created by John Matherly, is a service that scans several ports/services related to Industrial Control Systems (ICS) and, increasingly, Internet of Things sorts of devices and systems. The service records the results of these scans and puts them in a web accessible database. The results are available online or via a variety of export formats to include csv, json, and xml (though xml is deprecated). In his new site format, Matherly also makes some visualizations of his own available. For example, here’s one depicting ranked services for a particular subset of IP ranges that I was analyzing:

Builtin Shodan visualization -- Top operating systems in scan

One of the builtin Shodan visualizations — Top operating systems

Initially, I wanted to do some work with the text in the banners that Shodan returns, but I found that there was some even simpler stuff that I could do with port counts (number of times a particular port shows up in a subset of IP addresses) to start. For example, I downloaded the results from a Shodan scan, counted the occurrences for each port, ran a quick script to create a file of repeated ‘words’ (actually port numbers), and then dropped that into a text box on Wordle.

Inexpensive (free) data visualization tools

Wordle is probably the most popular web-based way of creating a word cloud. You just paste your text in here (repeated ports in our case):

Just cut & paste ports

Just cut & paste ports into Wordle

Click create and you’ve got a word cloud based on the number of ports/services in your IP range of interest. Sure you could look at this in a tabular report, but to me, there’s something about this that facilitates increased reflection regarding the exposure of the IP space that I am interested in analyzing.

 

org3portwordle

VNC much? Who says telnet is out of style ?

[For some technical trivia, I did this by downloading the Shodan results into a json file, used python to import, parse, and upload to a MySQL database, and then ran queries from there. Also, Wordle uses Java so it didn’t play well with Chrome and I switched to Safari for Wordle.]

In addition to quickly eyeball-analyzing an IP space of interest, it can also make for interesting comparisons between related IP spaces. Below are two word clouds for organizations that have very similar missions and staff make up. You would, I did anyway, expect their relative ports counts and word clouds to be fairly similar. As the results below show, however, they may be very different.

org1portwordle

Organization 1’s most frequently found ports/services

org2portwordle

Organization 2’s most frequent ports/services — same mission and similar staffing as Org 1, but network (IP space) has some significant differences

Next steps are to explore a couple of other visualization ideas of using port counts to characterize IP spaces and then back to the banner text analysis. Hopefully, I’ll have a post on that up soon.

If you’re doing related work, I would be interested in hearing about what you’re exploring.