The Internet of Things and IT Asset Management

In October 2016, the BBC reported that Twitter, Spotify and Reddit were among many websites taken offline by a distributed denial-of-service attack mounted from Internet of Things devices. The attack was believed to have drawn most of its firepower from unsecured CCTV cameras built by a handful of Chinese manufacturers.

Those cameras shipped with default passwords that could not be changed. Once the credentials were known, the devices were trivial to control. Worse, the organisations that owned them had no way of knowing they were being used for anything, because nothing in their IT records said the cameras existed.

That is an IT asset management problem before it is a security problem.

How does the Internet of Things affect ITAM?

What is the IoT?

The Internet of Things is not complicated, and it is not new. It is devices connected over the internet, able to talk to us, to applications, and to each other. The domestic example everyone recognises is the smart thermostat: turn the heating up from the office, and have it switch itself off when your phone leaves the house.

The definition is deliberately broad, and that is the point. A thermostat, a badge reader, a building management controller, a networked printer, a warehouse scanner and an industrial sensor are all the same class of thing as far as your network is concerned. Each one is an IP address you either know about or you do not.

Why IoT and ITAM matter to each other

It is tempting to file this under consumer technology. Most of the coverage in 2016 was about heating and doorbells, and it is easy to conclude none of it reaches the enterprise.

It does. Commercial applications were already emerging across manufacturing, medical devices, transport and media, and each of them lands on someone’s network with someone’s asset register failing to mention it.

The CCTV example is the useful one precisely because it is mundane. Nobody signed off a security architecture for those cameras. They were bought as facilities equipment, plugged into the network, and forgotten. In that instance the cameras were used to attack somebody else. The question worth sitting with is the other one: what happens when a device like that is not the weapon but the way in?

How can you secure what you own?

You cannot. Not until you can list it.

Every control that follows — patching, credential rotation, network segmentation, decommissioning — depends on an accurate, current inventory of what is actually connected. A device that is not in the inventory is not patched, not monitored, and not anybody’s responsibility.

That means discovery has to be automatic and continuous rather than a project somebody runs once a year. New devices appear constantly, and they appear without asking.

What CerteroX ITAM does about it

This post was written in 2016 and originally ended by saying you needed a good automated discovery tool. That is still true, but it is now a considerable understatement of what is available. Here is what ships today.

Network Discovery sweeps a class-C subnet in under five seconds using NetBIOS, SNMP and ICMP, then probes port 22 to establish where an agent could actually be deployed. It finds the things that will never run an agent — which is most IoT hardware — as well as the things that will.

SNMP interrogation goes further than presence. CerteroX ITAM reads printer consumables and page counts, switch port assignments and routing tables. For network-attached devices that expose an SNMP agent, you get an identity and a state, not just a responding address.

Ten discovery methods, one schema. Agent, command-line (csinvcli), agentless, standalone for air-gapped systems, Active Directory import, network scan, third-party ITAM import, cloud and SaaS connectors, browser monitoring and file metering all land in the same data model. There is no reconciliation project between them, because there is nothing to reconcile.

Duplicate detection and stale device archiving keep the register honest over time. An inventory that accumulates ghosts is only marginally better than no inventory, because nobody trusts it enough to act on it.

Governance Policies turn the inventory into enforcement. Policies are written against a reusable filter builder — compliance as code — and evaluated continuously. Worked examples include BitLocker enabled, Defender running and Azure VM tag hygiene. The same mechanism will flag a class of device that should not be on a given subnet, or one that has appeared without an owner.

The through-line from 2016 has not moved. Unmanaged devices are unmanaged risk, and the first control is a complete, current, automatically maintained list of what you have. Everything else is downstream of that.

To see what a network sweep returns for the devices that will never take an agent, book a demo.