It’s being launched amid reports of rampant use of unlicensed engineering and design software by practitioners in these industries.
Software tools can be very helpful if there are certain specific things you want to discover. But they’re subject to some very irritating limitations, including the infuriating fact that you often can’t take advantage of their automated data collection capabilities unless you send a person round to every machine to actually click all the dialog boxes.
Software tools also tend to lack any sense of discretion. When you’re carrying out an internal audit, the impulse is often to kitchen-sink the job and ask for every possible bit of data. This is liable to leave you unable to see the wood for the trees, and while the software may be able to discover irregularities, it’s very unlikely to put them into context for you, or tell you which ones you need to panic about.
Some companies skip the software and ask employees to self-report the information of interest, but this comes with its own risks. Obviously, you need to account for devices that aren’t anybody’s personal workstation. And you can’t always rely on staff to recognise or honestly report stuff that shouldn’t be there.
What should I expect from an external auditor?
It’s clear that there are advantages to taking on an experienced outsider to run your audit. In fact, you may already have one on call, because any outsourced IT support contract is going to rely on accurate auditing to confirm exactly what the provider is responsible for. Obviously, there’s a cost involved, but with experience comes efficiency, and independent audits are generally narrower than internal ones – which needn’t be a problem as long as the purpose is sufficiently well defined.
Certain companies even offer all-remote audits too, using a remote access tool such as TeamViewer: again, that’s fine, and more time-efficient than having a horde of clipboard-wielding inspectors descend on your premises – as long as everything you’re looking for is remotely discoverable.
There’s also one other sort of external audit that’s worth thinking about, and that’s the sort that isn’t directly instigated by you. For example, say you are a travel business and you want to enter into a partnership with American Express. The process is likely to begin with a third-party audit of not just what your computers contain, but how you run them – and if you don’t pass muster, you won’t be doing business.
This is a much more stressful scenario than finding an out-of-date version of Office running in reception, and the remedy isn’t a simple upgrade but a root-and-branch reform of how your company works. You might want to get in your own external auditor to help you make sure your business meets the required benchmarks before the real examiners get a look in.
How do you know that your audit is good enough?
Here’s where things get tricky! For a start, “auditing” means different things in different contexts. Notably, in the world of ITIL – a standard for how IT resources are managed – it can mean getting the management right, rather than the results. If you’re seeking reassurance that you’re doing the right thing, you could easily be led up the wrong path.
Furthermore, even the sorts of audit we’re talking about come in all shapes and sizes. Some data sets will fit on a beermat, while others are so broad or fast-moving that they can never properly be completed. You will look in vain for universal guidelines.
If that sounds hopeless, the slightly faded buzzphrase “fail often, fail early” may be of some use. It’s far better to have an approximate audit than none, because as soon as you start to collect data, that data will start to speak for itself. If you try to put together a set of axioms and assumptions before you even start, you’re likely to find that your results overturn at least some of those ideas.
For similar reasons, if you’re doing your auditing in-house, it’s never too early to bring your IT staff into contact with your chosen auditing tools and practices. It hardly matters how approximate they are on the first pass: once the agent software is up and running across your network, each iteration of the results will give them pointers on where to look next.
How do we execute an audit?
There’s no one-size-fits-all flowchart for carrying out an IT audit, and precious little in the way of generally accepted best practice. However, we’d expect to see IT workers physically sitting down at computers, and logging in with the credentials of the people who normally use them. That way they get to see each machine and its connections as a regular user would: when it comes to spotting and diagnosing strange behaviours by company PCs, there’s no substitute for the human eyeball.
For data capture, I would expect to come away with a paper tick-list for each PC, covering its basic physical specification and software revisions, along with a list of any missing management and security tools. It’s not the most scintillating task, but if you need to do an audit it’s usually precisely because this critical information hasn’t previously been properly recorded.
How does auditing work with cloud services?
A good, and increasingly relevant, question. The short answer is: it doesn’t. The major cloud providers offer tools that let you hunt out cloud instances that happen to contain your company name or postcode or similar, but if you’re trying to authoritatively find and catalogue all the VMs in the cloud that are being accessed by your apps and employees then good luck.
If you really need to keep track of that stuff, your best bet is to set up some traffic-sniffing tools at your border devices, and try to identify what’s communicating with an Amazon or Azure address. This isn’t exactly within the bounds of a traditional audit, though – it’s more like an interrogation, or a penetration test in reverse.
How do we audit when staff use their own devices?
The “BYOD” (bring your own device) model has become popular, and it’s not the quagmire you might fear. Generally, BYOD works because the services your employees are using reside in the cloud. The specifics of the actual device they’re using are almost irrelevant, and the service standard is about not leaving very much on the machine, or asking much of the purchasing power of the user. So most of the disaster scenarios are actually pretty unlikely to arise.
If you really need to find out what’s happening on your employees’ personal machines then there’s a universe of MDM (mobile device management) tools and services to explore. These might not normally be marketed as auditing tools, but they can do a decent job of collecting the information you care about.
The biggest challenge will be getting your users to agree to install the device-manager application, as this isn’t always painless for them. It’s not at all unusual for MDM products to insist on a cold reset of the device, or to require that a different username and password is used, distinct from the one that the device owner uses to store 2,500 holiday pictures. That disaster is a different subject, thankfully, from auditing.
What should we do with our audit results?
As I’ve mentioned, an audit is the start of a process, not an end in itself.
Whether this is understood or not, there’s an instinct in many companies to treat the findings as if they were valuable business secrets, and to keep them as far as possible from the eyes of the public and the workforce. However, we believe it’s far better to share your findings with your staff, and canvass their experiences and opinions – for exactly the same reasons that you carried out the audit in the first place.
In short, even in the most hierarchical businesses, the only sensible conclusion to an audit process is an open discussion of what has been found and what ought to be done. There’s a good chance your audit will have turned up something unexpected, so be open-minded in your response.