Do you know what's on your office computers? Perhaps more to the point, how do you know?
Such questions might seem rather pointed, especially when they're being asked by a nitpicking professional such as an insurer or an accountant. But they're ones that you, as an IT manager, should be asking yourself rather than waiting for circumstance to expose any gaps in your knowledge.
What is the purpose of an audit?
An audit isn't just a list of assets it's the basis for a plan of action. That may make it sound even more complicated than you were fearing, but it also means that an audit doesn't have to be a vast, all-encompassing project. An audit of business assets, for example, won't need to look at many of the specifics that a security audit will cover, and a software licensing audit won't need to worry about value just compliance.
A portable appliance testing (PAT) audit meanwhile will barely record any information at all, apart from the date on which each device passed the test, typically recorded in fading ballpoint on little stickers attached to each machine.
In each case, the process of determining and recording exactly what you're working with isn't an end in itself. Rather, it's the start of a project potentially a business-critical one. The exact scale and import are difficult to predict ahead of time, because the whole rationale of an audit is that you don't know what discoveries you'll make and what the implications may be until you look.
In other words, your business may well have got away so far without having to carry out an audit, and you may be questioning whether you need one now. But if you want to head off nasty surprises in the future, it's in your own best interest to embrace auditing, and to do it frequently.
What about very small companies?
Tiny startups may not own many physical computers, but that doesn't mean there's nothing to audit. That's partly because the smallest businesses are often heavily reliant on the cloud. This makes a lot of sense in terms of costs and flexibility but cloud operators have a tendency to treat small business customers like experimental subjects, frequently tempting them with upgrade offers and poorly defined technical updates that leave the customer with a patchy and unclear audit trail.
It's easy, in an environment like this, to end up in a situation where you're unsure exactly which cloud products have access to what data, what sort of access protections you have in place, and so forth. You know what the solution is - and the upside of going through an audit like this is that it makes on-premises auditing seem comparatively painless.
Do we need regular audits?
In an ideal world, you should be regularly carrying out audits as a matter of course but the truth is that auditing is an intrusive and expensive process, and nobody really does it without a serious business driver behind it. So prioritisation is the order of the day.
It may sound like a good idea to have an annual H&S/PAT audit, but if you have concerns over the state of your software licensing then that's where you're going to want to direct your energies. It's not that electrical safety is unimportant, but an accusation of software piracy can quickly progress to an enforced, overseen physical audit by an independent third party.
Irregular snap audits tailored to the question of the moment can be more useful than repetitions of the same tests, year in, year out. If you target your audits as tightly as possible, that gives you the best chance of finding out what you need to know, with the minimum cost and disruption.
Can't software tools do most of the work?
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.
Image: Shutterstock
