Tag Archives: risk

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.

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.

Side effect of IoT growth – more attack platforms

Leave a reply

iotgrowth

Rapid growth brings many good things, but also drives how we manage risk. [Image: theconnectivist.com http://bit.ly/1owv1dp]

The rapid growth of the Internet of Things (IoT) phenomenon, along with its corresponding rapid growth in device count, has been the talk about town over the past year or so. While IoT promises many good things, more conversation is being directed toward the risk brought about by the Internet of Things. Often this is in the form of someone will hack your web cams, steal your FitBit health information, hijack your routers and printers, or monkey with your thermostat remotely. While all important risks and concerns, I think that the bigger IoT risk has more to do with the sheer numbers of devices.

IoT devices as attack enablers

In all of the hoopla and coolness and excitement of the Internet of Things, we can sometimes forget the underlying subtle and amazing thing that they are all networked computing devices, many with well known and well understood operating systems. So, for a moment, forget that cool thing that the IoT device does in its local environment (capture video, audio, biometric authentication information, health information, temperature, humidity, refrigerator status, air composition, etc) and just remember that they are networked computing devices — many of these with substantial computing resources.

What this means is that IoT devices are not just targets themselves, but can also act as attack enablers or attack platforms. This can occur via direct hack or by unwitting participation in a botnet.

turkishpipelinehack

Baku-Tbilisi-Ceyhan (BTC) pipeline near the eastern Turkish city of Erzincan on Aug. 7, 2008.

From this recent analysis of a 2008 Turkish pipeline hack and sabotage:

“As investigators followed the trail of the failed alarm system, they found the hackers’ point of entry was an unexpected one: the surveillance cameras themselves.

The cameras’ communication software had vulnerabilities the hackers used to gain entry and move deep into the internal network, according to the people briefed on the matter.

Once inside, the attackers found a computer running on a Windows operating system that was in charge of the alarm-management network, and placed a malicious program on it. That gave them the ability to sneak back in whenever they wanted.”

So, the networked computing presence of the cameras themselves were used as a stepping stone (aka attack point) into the larger network. Some weakness in the operating system (OS) of the camera devices themselves provided a point of entry (‘vector’ in geek speak) into the pipeline’s operational network.

Big numbers

So, if we look at the growth in the number of IoT devices and consider them, for now, only as networked computing devices capable of being compromised, that’s a lot of new stepping stones for attacks.

These growing number of devices can enable & assist attacks by:

1) providing many more attack platforms, which …
2) provides more opportunities for indirection in attack, which …
3) makes attribution more difficult

buttonsLet’s get transitive – Kauffman’s buttons

At the risk of being a little bit tangential, all this reminds me of another network phenomenon, dealing with botnets, that I believe occurs. It is one that is exacerbated by the rapid increase in networked computing nodes, eg from IoT growth and has to do with how quickly the character of a network can change under fairly simple conditions.

I’ve always been intrigued with this ‘toy problem’ that Stuart Kauffman describes in his book, At Home in the Universe. He says to imagine that you have a bunch of buttons on the floor and some pieces of thread. You arbitrarily pick two buttons and then connect them with a piece of thread, a button at each end. Then you arbitrarily pick two more buttons and connect those two. (The original buttons are not excluded; they are still contenders. ) Keep doing this. While doing so, create a graph and plot the thread to number of buttons ratio on the X axis and the size of the largest cluster on the Y axis.

kauffman

Not too much happens at first. Early on, the largest button cluster stays pretty small. Then, at a certain point, the size of the largest cluster leaps. Logically, it’s not surprising. You can see how it happens. However, I still find myself staring at that big jump. That’s a real phase change for at least one aspect of that button network.

kauffman2

Quite a leap — https://keychests.com/media/bigdisk/pdf/16096.pdf

 

I think a similar thing happens with some botnets, particularly P2P botnets, as they grow in size. We can make the reasonable assumption that some botnet sizes are more effective than others at carrying out their varied nefarious tasks, eg 1000 is probably better than 10. While individual bots in botnets do not connect to all of the other bots on the network, they do connect to many.

IoT growth => More buttons

In this environment, I think Kauffman’s toy problem still applies. Namely, at some point, the largest cluster size grows very rapidly. Maybe not with the near-vertical drama of Kauffman’s problem where everything can be connected, but still with a significant acceleration in growth of the largest cluster once a critical point is reached. And if the largest cluster size suddenly meets or exceeds that putative optimal botnet size, well then, we’ve got ourselves an effective botnet.

So if the rapid growth in IoT provides many more buttons, then there are also many more buttons/potential botnet participants for the network. And the fact that these botnets can fairly suddenly (aka seemingly arbitrarily) reach their optimal effectiveness adds another air of uncertainty and difficult-to-predictness to the whole thing.

Not gloom & doom, but evolving risk picture

The sky is not falling and the Internet of Things holds much promise, but the way we look at risk will need to change. The advent and rapid growth of the Internet of Things will change some of the math on the Internet. More botnets will come online and they will do so in unpredictable ways. I’m not saying the end is near, but rather the way we look at risk will have to change.

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.

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 Risk Visualization II

Leave a reply

Categorizing and clumping (aggregating) simple exposure data from the Shodan database can help communicate some risks that otherwise might have been missed.  Even with the loss of some accuracy (or maybe because of loss of accuracy), grouping some data into larger buckets can help communicate risk/exposure. For example, a couple of posts ago in Poor Man’s Industrial Control System Visualization, Shodan data was used to do a quick visual analysis of what ports and services are open on publicly available IP addresses for different organizations. Wordle was used to generate word clouds and show relative frequency of occurrence where ‘words’ where actually port/service numbers.

Trading-off some accuracy for comprehension

This is great for yourself or colleagues that are also fairly familiar with port numbers, the services that they represent, and what their relative frequencies might imply. However, often we’re trying to communicate these ideas to business people and/or senior management. Raw port numbers aren’t going to mean much to them. A way to address this is to pre-categorize the port numbers/services so that some of them clump together.

Yes, there is a loss of some accuracy with this approach — whenever we generalize or categorize, there is a loss of information.  However, when the domain-specific information makes it difficult or impossible to communicate to another that does not work in that domain (with some interesting parallels to the notion of channel capacity), it’s worth the accuracy loss so that something useful gets communicated. Similar to the earlier post of port/service numbers only, one organization has this ‘port number cloud’:

org1portnum

A fair amount of helpful quick-glance detail consumable by the IT or security professional, but not much help to the non-IT professional

Again, this might have some utility to an IT or security professional, but not much to anyone else. However, by aggregating some of the ports returned into categories and using descriptive words instead, something more understandable by business colleagues and/or management can be rendered:

org1word

For communicating risk/exposure, this is a little more readable & understandable to a broader audience, especially business colleagues & senior management

How you categorize is up to you. I’ll list my criteria below for these examples. It’s important not to get too caught up in the nuance of the categorization. There are a million ways to categorize and many ports/services serve a combination of functions. You get to make the cut on these categories to best illustrate the message that you are trying to get across. As long as you can show how you went about it, then you’re okay.

portcat

One way to categorize ports — choose a method that best helps you communicate your situation

The port number and ‘categorized’ clouds for a smaller organization with less variety are below.

 

org2portnum

A port number ‘cloud’ for a different (and smaller) organization with less variety in port/service types

org2word

The same port/service categorization as used above, but for the smaller organization, yields a very different looking word cloud

One challenge with the more clear approach is that your business colleagues or senior management might leap to a conclusion that you don’t want them too. For example, you will need to be prepared for the course of action that you have in mind. You might need to explain, for example, that though there are many web servers in your organization, your bigger concern might be exposure of telnet and ftp access, default passwords, or all of the above.

This descriptive language categorization approach can be a useful way to demonstrate port/service exposure in your organization, but it does not obviate the need for a mitigation plan.

Borrowing from search to characterize network risk

Leave a reply
Most frequently occurring port is in outer ring, 2nd most is next ring in, ...

Most frequently occurring port is in outer ring, 2nd most is next ring in, …

Borrowing some ideas from document search techniques, data from the Shodan database can be used to characterize networks at a glance. In the last post, I used Shodan data for public IP spaces associated with different organizations and Wordle to create a quick and dirty word cloud visualization of exposure by port/service for that organization.

The word cloud idea works pretty well in communicating at a glance the top two or three ports/services most frequently seen for a given area of study (IP space).  I wanted to extend this a bit and compare organizations by a linear rank of the most frequently occurring services seen on that organization’s network.  So I wanted to capture both the most frequently occurring ports/services as well as the rank amongst those and then use those criteria to potentially compare different organizations (IP spaces).

Vector space model

I also wanted to experiment with visualizing this in a way that would give at a glance something of a ‘signature’.  Sooooo, here’s the idea: document search often uses this idea of a vector space model where documents are broken down into vectors.  The vector is a list of words representing all of the words that occur in that document.  The weight given to each word (or term or element) in the vector can be computed in a number of different ways, but one of the most popular is frequency with which that word occurs in that document (and sometimes with which it occurs in all of the documents combined).

A similar idea was used here, except that I used frequency with which ports/services appeared in an organization instead of words in a document. I looked at the top 5 ports/services that appeared.  I also experimented with the top 10 ports/services, but that got a little busy on the graphic and it also seemed that as I moved further down the ordered port list — 8th most frequent, 9th most frequent, etc — that these additional ports were adding less and less to the characterization of the network. Could be wrong, but it just seemed that way at the time.

I went through 12 organizations and collected the top 5 ports/services in each. Organizations varied between approximately 10,000 and 50,000 IP addresses. To have a basis for comparison of each organization, I used a list created by the ports returned from all of the organizations’ Top 5 ports.

Visualizing port rank ‘signatures’

A polar plot was created where each radial represents each port/service.  The rings of the plot represent the rank of that port — most frequently occurring, 2nd most frequently occurring, …, 5th most frequently occurring. I used a polar plot because I wanted something that might generate easily recognizable shapes or patterns. Another plot could have been used, but this one grabbed my eye the most.

Finally, to really get geeky, to measure similarity in some form, I computed the Euclidean distance between each possible vector pair. Two of the closest organizations of the 12 analyzed are (that is most similar port vectors):

 

mostsimilar

2 of the most similar organizations by Euclidean distance — ports 21, 23, & 443 show up with the same rank & port 80 shows up with a rank difference of only 1. This makes them close.  (Euclidean distance of ~2.5)

Two of the furthest way of the 12 studied are these (least similar port vectors):

 

leastsimilar

While port 80 aligns between the two (has the same rank) and port 22 is close in rank between the two, there is no alignment between ports 23, 3389, or 5900. This non-alignment, non-similar port rank, creates more distance between the two. (Euclidean distance of ~9.8)

Finally, this last one is some where in the middle (mean) of the pack:

 

midsimilar

A distance chosen from the middle of the sorted distance (mean). Euclidean distance is ~8.7. Because this median value is much closer to the most dissimilar, it seems to indicate a high degree of dissimilarity across the set studied (I think).

Overall, I liked the plots. I also liked the polar approach. I was hoping that I would see a little more of a ‘shape feel’, but I only studied 12 organizations.  I’d like to add more organizations to the study and see if additional patterns emerge. I also tried other distance measuring methods (Hamming, cosine, jaccard, Chebyshev, cityblock, etc) because they were readily available and easy to use with the scipy library that I was using, but none offered a noticeable uptick in utility over the plain Euclidean measure.

Cool questions from this to pursue might be:

1. For similar patterns between 2 or more organizations, can history of network development be inferred? Was a key person at both organizations at some point? Did one org copy another org?

2. Could the ranked port exposure lend itself to approximating risk for combined/multiprong cyber attack?

Again, if you’re doing similar work on network/IP space characterization and want to share, please contact me at ChuckBenson at this website’s domain for email.

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.

Shodan creator opens up tools and services to higher ed

Leave a reply
beecham_research_internet_of_things

Cisco/Beecham

The Shodan database and web site, famous for identifying and cataloging the Internet for Industrial Control Systems and Internet of Things devices and systems, is now providing free tools to educational institutions. Shodan creator John Matherly says that “by making the information about what is on their [universities] network more accessible they will start fixing/ discussing some of the systemic issues.”

The .edu package includes over 100 export credits (for large data/report exports), access to the new Shodan maps feature which correlates results with geographical maps, and the Small Business API plan which provides programmatic access to the data (vs web access or exports).

It has been acknowledged that higher ed faces unique and substantial risks due in part to intellectual property derived from research and Personally Identifiable Information (PII) issues surrounding students, faculty, and staff. In fact, a recent report states that US higher education institutions are at higher risk of security breach than retail or healthcare. The FBI has documented multiple attack avenues on universities in their white paper, Higher Education and National Security: The Targeting of Sensitive, Proprietary and Classified Information on Campuses of Higher Education .

The openness and sharing and knowledge propagation mindset of universities can be a significant component of the risk that they face.

Data breaches at universities have clear financial and reputation impacts to the organization. Reputation damage at universities not only affects the ability to attract students, it also likely affects the ability of universities to recruit and retain high producing, highly visible faculty.

This realm of risk of Industrial Control Systems combined with Internet of Things is a rapidly growing and little understood sector of exposure for universities. In addition to research data and intellectual property, PII data from students, faculty, and staff, and PHI data if the university has a medical facility, universities can also be like small to medium sized cities. These ‘cities’ might provide electric, gas, and water services, run their own HVAC systems, fire alarm systems, building access systems and other ICS/IoT kinds of systems. As in other organizations, these can provide substantial points of attack for malicious actors.

Use of tools such as Shodan to identify, analyze, prioritize, and develop mitigation plans are important for any higher education organization. Even if the resources are not immediately available to mitigate identified risk, at least university leadership knows it is there and has the opportunity to weigh that risk along with all of the other risks that universities face. We can rest assured that bad guys, whatever their respective motivations, are looking at exposure and attack avenues at higher education institutions — higher ed institutions might as well have the same information as the bad guys.

Managing the risk of everything else (and there’s about to be more of everything else)

Leave a reply
see me, feel me, touch me, heal me

see me, feel me, touch me, heal me

As organizations, whether it be companies, government, or education, when we talk about managing information risk, it tends to be about desktops and laptops, web and application servers, and mobile devices like tablets and smartphones. Often, it’s challenging enough to set aside time to talk about even those. However, there is new rapidly emerging risk that generally hasn’t made it to the discussion yet. It’s the everything else part.

The problem is that the everything else might become the biggest part.

 

Everything else

This everything else includes networked devices and systems that are generally not workstations, servers, and smart phones. It includes things like networked video cameras, HVAC and other building control, wearable computing like Google Glass, personal medical devices like glucose monitors and pacemakers, home/business security and energy management, and others. The popular term for these has become Internet of Things (IoT) with some portions also sometimes referred to as Industrial Control Systems (ICS).

The are a couple of reasons for this lack of awareness. One is simply because of the relative newness of this sort of networked computing. It just hasn’t been around that long in large numbers (but it is growing fast). Another reason is that it is hard to define. It doesn’t fit well with historical descriptions of technology devices and systems. These devices and systems have attributes and issues that are unlike what we are used to.

Gotta name it to manage it

So what do we call this ‘everything else’ and how do we wrap our heads around it to assess the risk it brings to our organizations? As mentioned, devices/systems in this group of everything else can have some unique attributes and issues. In addition to using the unsatisfying approach of defining these systems/devices by what they are not (workstations, application & infrastructure servers, and phones/tablets), here are some of the attributes of these devices and systems:

  •  difficult to patch/update software (& more likely, many or most will never be patched)
  •  inexpensive — there can be little barrier to entry to putting these devices/systems on our networks, eg easy-setup network cameras for $50 at your local drugstore
  • large variety/variability — many different types of devices from many different manufacturers with many different versions, another long tail
  • greater mystery to hardware/software provenance (where did they come from? how many different people/companies participated in the manufacture? who are they?)
  • large numbers of devices — because they’re inexpensive, it’s easy to deploy a lot of them. Difficult or impossible to feasibly count, much less inventory
  • identity — devices might not have the traditional notion of identity, such as having a device ‘owner’
  • little precedent — not much in the way of helpful existing risk management models. Little policies or guidelines for use.
  • everywhere — out-ubiquitizes (you can quote me on that) the PC’s famed Bill Gatesian ubiquity
  • most are not hidden behind corporate or other firewalls (see Shodan)
  • environmental sensing & interacting (Tommy, can you hear me?)
  • comprises a growing fraction of Industrial Control and Critical Infrastructure systems

So, after all that, I’m still kind of stuck with ‘everything else’ as a description at this point. But, clearly, that description won’t last long. Another option, though it might have a slightly creepy quality, could be the phrase, ‘human operator independent’ devices and systems? (But the acronym ‘HOI’ sounds a bit like Oy! and that could be fun).

I’m open to ideas here. Managing the risks associated with these devices and systems will continue to be elusive if it’s hard to even talk about them. If you’ve got ideas about language for this space, I’m all ears.