You Can’t Protect What You Can’t Find

In the first article in this series, I talked about something I’ve seen happen increasingly often. Experienced IT managers, infrastructure managers and system administrators are finding cyber security added to roles that have already changed considerably over the years.

These are people who understand technology and have spent their careers running infrastructure, managing change, solving outages and keeping services available. Now they’re also being asked about ransomware, vulnerability management, regulatory requirements, AI risk and whether the organisation is doing enough to protect itself.

This series is intended to help make some sense of that. We’re going to use the NIST Cybersecurity Framework to bring structure to the problem, while relating it back to the infrastructure skills and experience many of us already have.

A good place to start is with something every infrastructure professional will recognise: trying to work out what you actually have.

If you’ve spent any length of time working in infrastructure, you’ll probably have been involved in an asset discovery exercise at some point. It might have started with an attempt to improve the CMDB, preparation for a migration or hardware refresh, or because somebody asked what should have been a fairly simple question, “how many servers do we actually have?”

The spreadsheet says one thing. VMware says another. Active Directory knows about systems nobody recognises. There are devices responding on the network that appear to belong to projects completed years ago. Someone remembers an application that was supposed to have been retired, and a quick check reveals that it’s still running because another application still depends on it.

None of this will be particularly surprising to anyone who has managed infrastructure for a while. Environments grow organically. People leave, projects finish, companies merge, temporary solutions become permanent and documentation gradually falls behind reality.

From an operational point of view, that’s frustrating. From a security point of view, the consequences can be considerably more serious.

One of the first things I would encourage anyone who has recently inherited responsibility for security to do is establish how closely their documentation reflects the environment around them.

That sounds obvious, but it’s surprisingly difficult.

Traditional asset management often developed around technology the IT department deliberately purchased and deployed. Servers went through procurement, network equipment was installed by the network team and software had licences. Someone generally knew who owned everything.

Modern technology estates don’t behave quite so neatly. Cloud changed some of that, and SaaS changed it further. People can consume technology without necessarily involving the infrastructure team in the way they once did. We now have remote devices, cloud workloads, third-party services and applications spread across environments that may have grown very differently from the datacentre we started with.

AI adds another dimension. An organisation may have a reasonably good understanding of its approved technology while having far less visibility of which AI services people are using, what information they’re sharing with them or where AI capabilities have appeared inside applications they already use.
Knowing what you have has become considerably broader than maintaining a list of servers, switches and laptops.

Think about patching for a moment.

Most infrastructure teams have well-established patching processes. There may be maintenance windows, deployment rings, vulnerability scanning and reporting. You can have an excellent process for patching everything you know about and still carry significant risk from the things you don’t.

The same problem appears elsewhere. A system nobody knows exists can sit outside vulnerability management. A device you’re not monitoring can behave suspiciously without anybody looking for it. An unapproved SaaS application can introduce data risk without appearing on anybody’s security dashboard. This is where asset management starts to become part of the security architecture.

NIST places Asset Management within the Identify function of the Cybersecurity Framework. Its scope goes well beyond maintaining a hardware inventory. CSF 2.0 covers inventories of hardware, software, services and systems, as well as network communications and data flows, supplier-provided services and designated data. It also asks organisations to prioritise assets based on their importance and potential impact. That’s much closer to the reality of the technology estates we’re managing today.

Infrastructure people naturally gravitate towards inventory because it’s familiar. Give us a list of servers, switches, applications and IP addresses and at least we feel as though we’re getting somewhere.

Once you’re looking at the environment through a security lens, another question quickly follows, what does this thing actually do?

A forgotten development server and the platform processing your customer transactions may both appear as a row in an asset register. Clearly, they don’t carry the same importance to the business.

This is where your existing knowledge of the environment becomes incredibly valuable. Which services are critical? What depends on them? Where does important data reside? Which systems are externally accessible? Which services depend on third parties? Which ageing applications are still running because nobody is entirely sure what will happen if they’re switched off?

NIST reflects this by including the prioritisation of assets based on classification, criticality, resources and impact on the organisation as part of Asset Management. That context turns a list into something you can actually use to make security decisions.

If you’re coming from an infrastructure background, there’s a good chance somebody will point towards the CMDB at this stage. It’s a useful starting point, although anyone who has been through a large migration will know how quickly discovery can uncover things that never made it into the documentation.

Security discovery requires much the same curiosity.

These questions begin to turn asset discovery into risk discovery.

And there’s another important point about NIST here. CSF 2.0 describes cyber security outcomes but doesn’t prescribe exactly how an organisation must achieve them. For our purposes, that means we’re not following a NIST instruction that says every organisation must begin its security programme with a particular discovery tool or process. We’re using the framework to help us think about the outcome we’re trying to achieve. For someone coming from an infrastructure background, getting an accurate picture of the estate is a very practical place to start.

AI is a good example of how far the idea of visibility has expanded. Alongside traditional infrastructure, we increasingly need some understanding of which AI services employees are using, what company information may be passing through them and where AI functionality has appeared within applications the organisation already uses.
This introduces considerations that don’t fit neatly into a traditional asset register. Services the organisation consumes, the information flowing through them and the dependencies being created around them all contribute to the risk picture.

The underlying discipline should still feel familiar to someone from an infrastructure background. You’re building up an understanding of the estate, how its different parts relate to one another and where areas of uncertainty remain.

I wouldn’t begin by trying to create the perfect asset inventory. In a reasonably complex organisation, the environment will continue changing while you’re documenting it.

Start with what already exists. Look at the asset register, CMDB and network documentation. Compare them with what your management and monitoring platforms can actually see. Bring cloud services, software, externally provided services and important data into the picture rather than limiting discovery to traditional infrastructure.

Then start adding context. Which assets support your most important business services? Which are externally accessible? Where are the obvious legacy systems? Where do third parties feature? Where does sensitive information live and move?

Perhaps most importantly, look for the gaps between the environment you’ve documented and the environment you can actually see. The gaps you uncover are valuable in their own right. They tell you where assumptions have crept in and where your understanding of the environment needs more work.

For someone who has inherited security responsibility, I think this is one of the most useful places to begin.

You’re taking what can initially feel like an enormous and unfamiliar cyber security problem and bringing it back into familiar territory. You’re building a picture of the environment, understanding dependencies, identifying what’s important and finding the places where assumptions don’t quite match reality.

That knowledge gives everything else somewhere to start. Vulnerability management becomes more meaningful when you understand which assets matter. Security controls make more sense when you understand what you’re protecting. Detection improves when you know what belongs in the environment. And if an incident does happen, familiarity with the systems and dependencies involved gives you a much better starting point for understanding what has been affected.

NIST calls this Identify. More precisely, the asset-focused part we’ve been discussing sits within Asset Management (ID.AM) under Identify.

For an infrastructure professional, much of it should feel reassuringly familiar. You’re understanding your estate properly, just through a broader risk lens.

And from there, we can start thinking about what actually needs protecting.