Server Audit for the Dauntless

If you’re looking for an insightful server audit, and you’re dauntless, you might want to jump on this train.

First, why do you need to be dauntless?

Because you’re going to need to obtain your data from a number of different sources; the bigger your company, the more likely you’ll need to call on and question more than a handful of people.

Because comparing and tracking all the servers that are on one list, but not another can be a challenge.

Because it his highly LIKELY that you WILL find something and the server team will not be happy.

Unless you enjoy torture, I’d suggest auditing the Windows and Unix servers separately, and don’t forget about virtual servers and appliances.

Because I usually audit large companies, I always include the Windows virtual servers in the Windows audit, and the Unix virtual servers in the Unix audit, and do the appliances on their own.

By appliance, I mean pre-packaged  or pre-configured physical or virtual servers that you drop in the network or virtual host as is; you typically don’t load them or configure them. Some vendors insist that you don’t alter their appliances (e.g., installing antivirus or monitoring), which increases the attack surface and risk to your company.

Second, the objective is to determine the following:

• How many servers do you have, and are they all accounted for?
• Are all the servers approved and in use?
• Are all the servers running the appropriate security and/or control software?
• Are all the servers appropriately monitored (not just logged)?
• Should some servers be segregated so they are not accessible by other parts of the network?

Before you gather the various lists, ask yourself, “What risk exists if a server is not on THIS list?” Based on the risk, include or ignore gathering and analyzing that list.

Third, obtain a list of all servers:

1. From the server team. They often maintain a manual listing, which is usually the most out-of-date of all the server lists. This list usually indicates (or attempts to indicate) which servers are being built, active, suspended or turned off, or being decomissioned.
2. From Active Directory, the Unix directory, or other LDAP.
3. From the antivirus console (which servers are running antivirus). Make sure you also get the last date the antivirus patterns were updated.
4. From the monitoring console(s). Some companies use multiple monitoring systems to monitor whether a server is up/down, monitor database performance, monitor disk usage, etc. Get a list of servers from each console.
5. From the text file or database used by all your IT/Security department’s scripts. This list is usually used by many processes to run all kinds of scripts that check server configurations, check for server heartbeats, monitoring, etc., on all the servers. It is considered by most to be THE LIST. Usually, this is the most up-to-date list you’ll find. If you can’t find it, start reading your most critical IT scripts and you’ll locate it pretty quickly.
6. From the DNS console. This list often contains lots of retired servers and sometimes causes havoc when server names and IP addresses are reused; DNS entries can point processes to the right server name at the wrong IP address.
7. From the inventory console. Many shops use Tivoli or other products to maintain an inventory of servers.
8. From the virtual environment. Make sure you get a list of virtual hosts also.
9. In the DMZ. If IT can’t immediately provide a list of all servers in the DMZ, that’s your first finding. The list should include information like server type (physical or virtual), purpose, key software installed, IP address(es), VLAN, who approved, who to contact, etc.
10. From the security team. They might have their own list that they maintain. Ask them for the results of the last scan they did on the network.
11. From the team that manages server OS licensing and support contracts. This team has to do a true-up every year to ensure they have the correct number of licenses and the right level of support for each OS. Ask them who generates the list they use for true-up, and get that person to generate you a fresh list.
12. From vendors, if they provide any management, assistance, or monitoring of servers.
13. From the configuration management database. This is often tied to a help-desk ticketing application, such as BMC Remedy or HP Service Manager.

Each time you gather one of these lists, ask the subject matter expert (SME) questions like these:
– Who has access to this console?
– How is that access assigned, and can you show me (e.g., which AD group do you have do be in?) and provide a list of members?
– How often is that access reviewed? Do you have evidence of the last 2 reviews?
– How frequently is this list monitored (especially if antivirus or security monitoring service)? Do you have evidence of the last X times the console was monitored for failures and messages?
– Are any servers purposely left off or removed from this list (e.g., list of servers that antivirus is not installed on)? Why? Who approves the exceptions? Do you have evidence of the last X exceptions? How often is the list of exceptions reviewed to ensure the exception reasons are still valid? Who approves that?

In addition, determine where you can look up the approval/signoff forms/tickets for all servers (when they first came online). Since some servers are probably older than the approval/signoff process, ask when the approval/signoff process went into effect so that you know whether you can expect to find a completed form/ticket for it.

Then the fun begins.

Compare each list to every other list. When I did this audit, I did it all in Excel using vlookups. I then created a master matrix of each server and on which list it appeared, and if it was missing from a list, I noted whether the server have an written exception document that was approved and reviewed within the last year.

In addition, determine WHY those servers were missed by interviewing the various groups involved, and compile a list of those reasons.

For example, I identified a group of servers that were running a specific version of an OS, and those servers were not being monitored. I discovered that the previous year, the vendor of the monitoring software directed the monitoring team not to install the software on that OS version until an issue was fixed.

Months later, when a fix was issued and applied by the server team, they neglected to notify the monitoring team, so the monitoring was never installed.

Finally, don’t forget to check whether the server decommission process is working, especially in the virtual environment. Often virtual servers are created, used for a while, and then abandoned. If no one checks the last time a server is accessed, those servers will live unused in infamy.

This type of audit can also be applied with applications, databases, etc.

Has anyone else done this type of audit? If so, what did you find?

Advertisement