Tag Archives: iot

Shodan creator opens up tools and services to higher ed

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)

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.

 

A trash can, a credit card, & a trip to the computer store

“A trash can, credit card, and a trip to the computer store” is how Bruce Schneier recently described the software update process (patch management) for networked consumer devices, aka Internet of Things devices. This category of devices already include home/small business routers and cable modems and is quickly growing to include home energy management devices, home health devices and systems, and a plethora of automation devices and systems.

I believe he is spot on. There may be a few people who consistently download, reprogram, and reconfigure their devices but I would estimate that it’s well under 1%.

The problem of software updates/patch management for Internet of Things devices, both consumer and enterprise, is a significant issue on its own. The bigger issue, though, is that we largely tend to think we’re going to manage these updates in a traditional way such as Microsoft’s famous Patch Tuesday. That simply won’t happen with the raw number of Internet of Things devices as well as the variability of types of devices.

The work before us then is twofold: 1) Are there automated patch management solutions that can be developed to detect outdated software and update/patch the same for at least a subset of all of the devices on the network, and 2) Find a way to formally acknowledge and document the risk of that larger group of devices that remain forever unpatched.

Option 1 has a cost. Option 2 has a cost. I think it will turn out that wrapping our heads around Option 2, the risk, will prove to be more difficult than creating some automated patching solutions.

Biometric systems can put unseen burden and risk on IT infrastructure

eyeimageRemember the old ad line, “Sell the sizzle, not the steak” ? There seems to be a lot of that going on with biometric systems.  There’s all kinds of excitement about what new body part can be quantified and its near-holy-grail-ness for authentication (the sizzle), but not a lot of talk about the infrastructure required (the steak) to provide the sizzle.  By default, the cost of the steak falls back to the customer, the implementer of the biometrics system.

Interest in biometrics systems for authentication — sensing fingerprints, iris scanning, voice, other — continues to accelerate for several reasons:

  • recognition of inadequacy of passwords as sole system for authentication
  • increasingly hostile online world — cybercrime, nation-state actors, civil unrest
  • rise of the Internet of Things — rapidly increasing ability to manufacture and deploy inexpensive, microcontrolled, networked sensors
800px-Biometric_system_diagram

Image: WikiCommons

Complex Subsystems

Biometrics systems require several functional, secure, and integrated components to work properly with appropriate privacy requirements in mind. They need a template to structure and store the biometric data, secure transmission and storage capabilities, enrollment processes, authentication processes, and other components.  These backend systems and processes, the steak, can be large, complex, and require real oversight and resources.  For example, the enrollment process (getting someone’s biometric profile, aka template, into the database involves multiple, if quick, phases — sensing, pre-processing, feature extraction, template generation, etc.)

Like all systems, there are many points of attack or places where the system has some vulnerabilities as indicated in this vulnerability diagram in a paper by Jain, et al in this article.

fishbonevulnerabilities

Biometric Template Security. Jain, Nandakumar, Nagar.

 

Uncaptured Cost of Infrastructure Enhancement

While there are many points of failure (again as in all systems), the infrastructure component lies squarely with the customer.  Its cost will show up as required enhancements, resources, and staffing to support the additional required infrastructure or it will show up as the cost of unmitigated risk.

biometricvulnerability3

Biometric Template Security: Challenges & Solutions. Jain, Ross, Uludag. (comment by author) http://bit.ly/1fWC21i

The infrastructure cost (or cost of unmitigated risk) occurs because the user’s biometric profile has to be stored somewhere and has to be transmitted to that somewhere and all the other things that we sometimes do with data — backup locally, backup at a distance, audit, maybe validate, etc.   That profile data is the data that is used for comparison for a new real-time scan when someone is trying to unlock a door, for example.  It is the reference point.

Because biometric data is about as personal as you can get, way more personal than a Social Security Number or credit card number — you can change those after all — that personal profile data needs to be highly protected.  So that means that, at a minimum,  you’ll probably want to store the profile encrypted and also transmit the data in encrypted sessions. That’s generally an IT infrastructure function, not a biometric device function.

Some questions to ask your vendor

When considering purchase of a biometric system, a partial list of things to consider might include:

  1. How is the biometric profile data (a parameterized fingerprint, for example) exchanged between the sensing/scanning device and the database that stores the parameter? Is it encrypted? If encrypted, how is it encrypted? Protocols?
  2. Is biometric profile data cached on the device either at time of enrollment or actual use? If so, how long? While cached, is it encrypted?
  3. Does the system use 3rd party software anywhere in the chain, eg device configuration via web service? If so, who wrote it? What is their reputation?
  4. Does the device manufacturer publish data on the current chip set? Chip manufacturer, version, when purchased, etc?
  5. How long does the enrollment process take?
  6. What is the scope of the install? Door entry? Computer access? Other?
  7. Are there other installations? Case histories of user adoption?
  8. Are there auditing, logging, reporting functions from the system?

Whether the biometric system includes just the sensing endpoint device or has backend support to include database and application support,  it is critical that the customer knows where the biometric system infrastructure ends and where their own infrastructure begins and has to carry the burden of the new biometric system implementation.

To ensure privacy and security, someone has to pay for the steak that provides the sizzle. It’s best to figure that out who’s going to do that ahead of time.

 

Other reading:

 

 

[Eye Image: licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.

Chuck Benson’s Information Risk Management Video Lectures

Slide from lectures -- Building an Information Risk Management Toolkit -- Week 9My lectures on Information Risk Management are on deck again this week in the University of Washington & Coursera course Building an Information Risk Management Toolkit.

(Use the link above & click on Video Lectures on left & then go to Week 9.  The video “Bounded Rationality” is a good place to start. Just need e-mail & password to create a Coursera account if you don’t have one).

slide from lectures -- Building an Information Risk Management Toolkit

Slide from lectures — Building an Information Risk Management Toolkit

Coursera-BuildinganRMToolkit

Automation — another long tail

taskfrequency

Descending frequency of different tasks moving left to right — and the who and what performs these tasks

Jason Kingdon illustrates what types of tasks are done by different parts of an organization and argues that that more use can be made of “Software Robots” to handle those many different types of tasks that occur with low frequency, aka in the long tail — stretching out to the right. (That is, each particular type of task in this region occurs with low frequency but there are many of these low frequency task types).

The chart shows how often particular tasks are carried out, ranked in descending order left to right, and who (or what) does the task — an organization’s core IT group, its support IT group, or end users.

  • Core IT has taken on tasks such as payroll, accounting, finance, and HR
  • Support IT has taken on roles such as CRM systems, business analytics, web support, and process management
  • People still staff call centers to work with customers and people are still used to correct errors, handle invoices, and monitor regulation/compliance implementation.

Kingdon says that Software Robots mimic humans and work via the same interfaces that humans do, thereby making them forever compatible. That is, they don’t work at some deeper abstracted systems logic, but rather via the same interface as people. Software Robots are trained, not programmed and they work in teams to solve problems.

I think there is something to this and look forward to hearing more.

Satellite communication systems vulnerable

dishSimilar to other Industrial Control System (ICS) and Internet of Things (IoT) devices and systems, small satellite dishes called VSAT’s (very small aperture terminals) are also exposed to compromise.  These systems are often used in critical infrastructure, by banks, news media, and also widely used in the maritime shipping industry. Some of the same problems exist with these systems as with other IoT and ICS:

  • default password in use
  • no password
  • unnecessary communications services turned on (eg telnet)

According to this Christian Science Monitor article, cybersecurity group IntelCrawler reports 10,500 of these devices being exposed globally.  Indeed, a quick Shodan search just now for ‘VSAT’ in the banner returns over 1200 devices.

The deployment of VSAT devices continues to rapidly grow with 16% growth demonstrated in 2012  (345,000 terminals sold) and 1.7 million sites in global service in 2012.  2012-2016 market growth is expected to be almost 8% for the maritime market alone.

Clearly, another area in need of buttoning up.

[Image:WikiMedia Commons]

Don’t forget the water

GrandCoulee

Grand Coulee Dam

Changes in water temperature and water availability will lead to more power disruptions in the next decades.

Ernie Hayden points out several often overlooked facts regarding electrical power generation in his Infrastructure Security blog.

Water is critical in electricity generation. Heat is generated by fueled power sources which spin the generators, whether combustion engines, coal-fired, nuclear, or other. That heat has to go somewhere. The primary coolant used in industrial power generation is water. Warmer water and diminished water flow reduce the ability to take that heat away which in turn reduces power generation.

Hayden points out a few examples of where warmer water or reduced water flow caused power degradation or complete shutdown:

* Millstone Nuclear Plant, Connecticut, 2012 — natural cooling water source (Long Island Sound) became too warm (almost 3 degree F ambient increase since plant’s inception in 1975). Plant shutdown for 12 days
* Browns Ferry Nuclear Plant, Alabama, 2011 — shutdown multiple times because water from Tennessee River was too warm
* Corette Power Plant, Montana, 2001 — plant shut down several times due to reduced water flow from Yellowstone River

Estimates of thermoelectric power generating capability are expected to drop by as much as 19% due to lack of cooling water.  Further, incidents of extreme drops in generation capability, ie complete disruption, is expected to almost triple.

Keep up your scan

An Information Risk Management 'scan' can be similar to a cockpit scan

An Information Risk Management ‘scan’ can be similar to a cockpit scan

Much like flying an aircraft, we have ‘keep up our scan‘ when analyzing these system risks. These are complex interconnecting systems. We are becoming increasingly concerned about cyberattacks on electrical and smart grid systems. That attention is good and overdue, but that is only part of the puzzle. We have to train ourselves to constantly scan the whole system — just because there’s a big fire in front of us, it doesn’t mean that there’s not another one burning somewhere else.
 
 

For want of a nail the shoe was lost.
For want of a shoe the horse was lost.
For want of a horse the rider was lost.
For want of a rider the message was lost.
For want of a message the battle was lost.
For want of a battle the kingdom was lost.
And all for the want of a horseshoe nail.

 

[Image 1: Wikimedia Commons: Farwestern / Gregg M. Erickson. Image 2: author’s]