Where the hours actually went

Recording a mitigation against a single firewall takes about two minutes. Getting to the point where you can spend those two minutes was a different story. An engineer would research the vulnerability, work out which firmware versions it affected and filter for the clients running them. Then they’d open each client’s firewall records one at a time to note what had been done. Often this happened while preparing for a monthly client review, because that was when the question got asked.

Across all clients, a two-minute task was turning into an hour or two of navigation. And the record of what we’d done lived in a central spreadsheet and in people’s notes. That meant only the person who did the work could easily answer the question every client really wants answered: are we covered?

That’s a workflow problem, not a scanning problem. Better scanning would have told us about more vulnerabilities, sooner, and we’d have been no quicker at showing what we did about them.

One board for the whole fleet

We built a single board in the back end of inSight, our network intelligence platform. It lists every managed device with a known vulnerability, across every client, and you can filter straight to the affected devices and work down the list. Mitigations are often similar from one firewall to the next, so an engineer can carry an assessment across devices rather than rediscovering it client by client. We expect the job that used to take one to two hours to come down to 10 to 20 minutes.

inSight vulnerability management board listing managed firewalls with known vulnerabilities and their mitigation status
“Mitigation” here means a record written against the specific device: what we investigated, what we found, and what we did about it. Sometimes that’s a configuration change, and those still go through change control. Nothing is pushed to a client’s firewall straight from a dashboard. Sometimes it’s a documented decision not to change anything at all.

That second case matters more than people expect. Right now 28 devices on the board show known vulnerabilities, and every one has been assessed. Several belong to clients who have chosen to stay on older firmware for sound operational reasons, and the vulnerabilities in question affect features those clients don’t use. A vulnerability with a written, reasoned decision against it is a very different thing from one nobody has looked at. On a scan report, though, they look identical.

Clients see the work, not just the risk

The part I’m proudest of is what happens once the record is written. It flows straight through to each client’s own inSight dashboard. When clients open their view, they can see that a vulnerability was assessed and what was decided, in real time, without waiting for the next monthly meeting.

Building the board also exposed something we hadn’t fully appreciated: gaps in our own asset records. A missing serial number or a lapsed licence doesn’t feel urgent until the day you need it. We now flag missing data on the boards our Trusted Response Centreâ„¢ engineers use every day, with one click to fix it on the spot. Three boards have it so far, and every new board we build will get it.

The question worth asking

If you’re responsible for IT risk in your business, try asking whoever manages your network a slightly different question. Not “do you scan for vulnerabilities?” but “show me what you decided about each one, and when.” A provider who can answer that in minutes has a workflow. A provider who needs a week to pull it together probably has a spreadsheet.