MC Press Online

Friday, Mar 24th

Last updateFri, 17 Mar 2017 12pm

You are here: Home ARTICLES Internet of Things Internet of Things - Other Internet of Things: You Can’t Avoid the Inevitable

Internet of Things - Other

Internet of Things: You Can’t Avoid the Inevitable

Support MC Press - Visit Our Sponsors
Element Break 290x14

Nine Books from MC Press Bookstore Featured Author: Roger E. Sanders. 20% off at the MC Press Bookstore until Wednesday, 3-22-2017. Use promo code: SANDERS

Element Break 290x14


DB2 10.5 Fundamentals for LUW (Exam 615)



Click for this Month's

Bookstore Special Deals

This article is excerpted from Identity Management: A Business Perspective, chapter 7.

The Internet of Things (IoT) is upon us. “What does that mean?” you may ask. Well, it means you had better get ready to use your identity management environment to support access to “things.” “But we don’t do that,” you reply. “Why not?” is my response. It is highly likely that there are business processes within your organization that could benefit from the deployment of things. So when you finally get pulled into the 21st century, you will need to plan for more than just people accessing your systems.

Over the past few years, we have experienced a dramatic reduction in the cost of devices that monitor things and actuators that control things. It is now very inexpensive to remotely measure things and to turn things on and off. It’s important that companies evaluate the potential of exploiting these cost reductions and take advantage of the opportunity that they afford.

But before you invest in IoT, there are a few questions you will need to answer, as shown in Table 7.1

Table 7.1: Questions to ask when assessing IoT

Collection Devices

Control Devices

How will you associate ownership with collected data?

Who should be able to access control devices?

How will you protect data, and how will you give owners access to it?

What level of access should approved users be given?

How will you allow users to share data with authorized persons?

Should users be able to delegate access to others?

If you can answer these questions, improvements to numerous business applications await.

Devices as Things

So the next question is: “What’s a ‘thing,’ and what does it want?”

Things can basically be divided into two categories: those that can measure something (sensors) and those that control something (actuators). Sensors can be as simple as a thermometer that measures the temperature inside a house, or as complex as the monitor that measures a car’s fuel mixture as the vehicle accelerates.

In a manufacturing environment, IoT data can be very valuable. IoT data can, for example, show how much product is being produced and the rate of rejects, how many people are on a ship’s bridge and their ranks, or the current rate of inventory depletion, and project when the manufacturing department will run out of raw material. Increasingly, we need to share this data with others in the company or business partners outside the company. How do we control the release of sensitive information, and how do we restrict its usage to approved persons?

Actuators are even more interesting. They can either be discrete, turning something on or off, or they can be a continuous process-control device such as a valve moderating the flow of a gas, liquid, or granular solids in accordance with external stimuli. Adding cement, aggregate, and water into a cement mixer is an example. It should be obvious that restricting access to actuators to authorized personnel is very important.

Contributing Technologies

It is fortunate that IoT technology is developing at a time in which related services are becoming available. Not only are manufacturing economies of scale driving down the cost of devices, other technology developments are contributing to the economic viability of IoT installations.


There are multiple areas in which the cloud contributes to IoT deployments. Data storage is one area to be addressed in any installation of IoT devices. In some cases, where data volumes are large, it makes sense to store data in the cloud, where the requisite encryption is facilitated and the business continuity services offered by cloud service providers (CSPs), such as data backup and restore, can be leveraged.

It is arguably also easier to manage access to data in the cloud. With on-premises databases, there is a requirement to configure the access control settings for the database or put the data store on a protected subnet. In the cloud, user access can be restricted by the cloud service access control facility based on an attribute in the user’s directory entry.

A CSP can also perform a useful communications task for companies with industrial computer installations with remote monitoring facilities. CSPs with multiple data centers can be used to collect data from remote monitoring points close to one facility and make it available via a data center close to the company’s administration point.

Big Data Analysis

Sometimes devices produce a lot of data that needs to be analyzed either continuously or periodically for trends or to identify significant events. Here cloud-based services can be advantageous. Hadoop analysis and map-reduce functionality are easier to deploy in the cloud and can facilitate turning raw data into information for managers tasked with understanding IoT data and making appropriate management decisions.


It’s generally agreed among industry analysts that we are heading toward a catastrophe with IoT technology; it could be corporate but will more likely occur in the public sector. It will probably entail unauthorized access to sensitive data that is subsequently released to nefarious persons, or it may be a malicious attack on a control device resulting in inappropriate messages being sent to an industrial process. The result will be unprecedented regulation being imposed on IoT systems. It will be the classic “closing the gate after the horse has bolted” syndrome and will happen because:

  • Those in authority in this technology space are abrogating their responsibility to understand and impose governance over IoT. This is most unfortunate because it does not need to happen: plenty of help in the form of information and tools is available, and there are enough people who know how to use them.
  • Those with regulatory authority fail to develop regulation until they have to. This, too, is most unfortunate because we know what can go wrong, and we have the technology to stop things from going wrong. Industry is quite capable of working with government to ensure that regulation is sufficient and fit-for-purpose; waiting until there’s a political expediency means regulation will likely be draconian and expensive.

But it’s not all doom and gloom. There are some bright spots that we will come to soon.

Best Practices

There are a number of areas in which organizations should plan their IoT implementations to optimize their usefulness and avoid potential problems.

Data Management

Data from sensors must be securely collected and adequately protected in storage. The data communication channel must be managed, and appropriate notifications should be issued. For instance, for temperature measurements, periodic transmissions are adequate with only averages stored for any length of time. However, if a temperature reading is outside normal ranges, an alarm should be raised. 

Depending on the sensitivity of the data, it might be necessary to digitally sign the transmission of data collected so that the receiver can be sure it originated at the prescribed sensor. Or the data might be encrypted to ensure that the message can’t be intercepted and understood.

It is also necessary to define controls on data being written to corporate systems. If Web services are being used, the HTTP method(s) that can write—to a database, for instance—and the conditions placed on it should be documented. For high-security environments, APIs should be used that define the data that can be passed through the interface and what can be done with it. For instance, a popular data transfer mechanism is an XML file using a signed SOAP message. If the message is not appropriately signed, it will not be actioned, and if the XML file does not use the prescribed tag names, the data will not be written to the protected repository.

Note: Enterprise data store interface protocols such as SQL or LDAP should not be deployed in a cross-boundary environment. If data is originating from a remote location, the use of an API is highly recommended. In this way, the appropriate API security, which ensures the confidentiality and integrity of the data, and API management, which ensures that governance processes are observed, will be implemented. When it comes to actuators, it is most important to adequately restrict access to these devices. If a device can be controlled by an unauthorized person, a potential catastrophe is enabled.

Device Categorization

Device capability, management requirements, and security controls vary widely depending on their “category.” A controller in an in-house production line has a different security profile from the HVAC thermostat. Data from the production management system has a different sensitivity than the research results from the latest pharmaceutical trials. Categorization will ensure appropriate treatment of access control to devices and data from devices. This, in turn, will ensure that IoT infrastructure is not over-engineered, which adds costs, or under-engineered, which could possibly expose the organization to unnecessary risk.

Next Steps

So, how should organizations exploit this potential? What can be done to make sure companies don’t miss the opportunities that arise?

Step 1: Strategy Development

The most important step in exploiting IoT is developing a strategy. Without this step, there will be no appreciation of the potential of IoT to assist the organization and therefore no development of competitive advantage based on the potential of “things” to improve business processes.

Worse still, some business units within the organization might decide to “go it alone” and develop IoT facilities without implementing the proper controls or a plan for wider development in the company. This is dangerous because there will be no management oversight of interfaces that are developed, resulting in exposure of the company to unnecessary risk and potential damage to corporate infrastructure and potentially the community.

Ideally, IoT integration should be within the controls established for technology integration in the corporation’s enterprise architecture. IoT devices should be addressed at the technology level to give business units guidance on supported device types so that there is not a plethora of different devices deployed within the organization. At the application level, APIs for device integration should be determined with management and security requirements stipulated. At the information level, the device integration should be addressed with direction given for database interfaces and data management controls. At the business level, the processes impacted by IoT devices should be determined with consideration given to wider deployment of IoT technology or sharing of IoT data with a wider audience.

Interfaces to the identity management and access control facilities should be addressed at the information architecture level.

Strategy must, by definition, include an environmental scan that determines the current situation. This will include documenting current capabilities and desired goals, and possibly a SWOT analysis to identify the weaknesses to be overcome and the opportunities to be exploited.

This must include a definition of how IoT will integrate with the IdM environment.

Step 2: Capability Development

There’s little point in developing a strategy if there’s no capability to put it into action. Organizations might have IoT expertise on staff— particularly if they are managing a production environment, these staff should investigate the opportunity to extend their manufacturing system to provide better data or controls to business unit personnel. In the event that there is no in-house expertise, it will need to be brought in or developed. In the event that a system integrator is engaged to deploy an IoT system, reliance on the supplier might well be the best approach, but this must be done within the constraints of the company’s policy and practices. It is important to ask the right questions so that the organization’s commercial integrity and intellectual property are protected.

Step 3: Infrastructure Deployment

The deployment step is a standard project-management exercise:

  • Plan—Investigate options and develop a project plan.
  • Design a solution—This will include understanding the business unit requirements and documenting the desired outcomes.
  • Deploy the technology—This will include an interface to the organization’s IAM environment to manage access controls.
  • Test, both functionality and volume, to ensure that the project deliverables meet the customer requirements and expectations.
  • Transition to operations—Once the acceptance testing has been completed, the infrastructure transitions to maintenance. This may be in-house or outsourced.

Step 4: Business Process Integration

Once the project is completed and the IoT environment is generating a data stream and providing control capabilities, the next step is to integrate the IoT system into the business. This could be simply training business unit staff on the system capabilities. In other cases, the IoT data feeds will need to be integrated with business system databases, and the ability to control processes integrated with business systems. Identity management that provides access control to data and devices will be paramount.

Graham Williamson
Graham Williamson is an identity management consultant in Brisbane, Australia. He has 27 years of experience in the IT industry, with expertise in identity management, electronic directories, public key infrastructure, smart card technology, and enterprise architecture. He is a coauthor of Identity Management: A Primer (MC Press, 2009).