Companies of all shapes and sizes are under enormous pressure to document (and regularly audit) various types of network events and system/security logs. Public companies in particular have seen a significant change in their regulatory burdens, and are now required to retain reams of data that can be used to perform forensic audits.
Having an audit-friendly network infrastructure can go a long way toward simplifying the process of documenting and auditing network activities.This article discusses network design approaches which can significantly reduce headaches when performing audits.
Optimizing Subnet Design
Your network can be much more audit-friendly if the hosts that reside on it can generally be found at predictable IP addresses. When unused IP addresses start running short, most DHCP severs will expire orphaned leases first, and re-use these addresses for new hosts coming onto the network. While this is an efficient way to minimize the size of a subnet, modern Network Address Translation (NAT) techniques have virtually eliminated "IP address shortages" from the network design equation.
You're far better off to overprovision in most "corporate" environments. By having plenty of spare addresses on hand, you can keep a tighter (though not total) grip on the IP address assignments that are made through DHCP.
Don't go completely hogwild here though. You probably don't need a full Class A block for each department in a typical small or mid-size company. Unnecessarily large address blocks may also cause problems for security scanning tools.
DHCP Lease Policies
Wherever possible, configure long leases on your DHCP server, and bind the client MAC address to the IP assignment. While it is not possible through DHCP to completely prevent unanticipated (or unauthorized) IP address assignments, it nonetheless simplifies the auditing process significantly. In any forensic investigation, you'll still need to perform additional checks to ensure a particular IP address is (or was) who or what you expected it to be.
Some security folks might question the wisdom of what is essentially a near-static IP addressing policy. However, chances are, your most important systems - your servers - already reside at very predictable (i.e. static) IP addresses. Security through obscurity doesn't work anyway.
Host Naming / DNS Conventions
I've seen many companies that have all of their key servers named after prominent Lord of the Rings characters, for example. Very cool, for sure, but not always practical - you'll usually have to translate these names into more meaningful representations at some point.
A good hostname should identify a system's location and purpose. Consider including the class of system (i.e. SQL server, printer or workstation), geographical location or department, and for worksations, some type of user identification (or type of user, in cases where systems are shared amongst multiple staff).
Logging Policies
System security and event logs are among the most crucial pieces of information required in any forensic audit. You'll need these logs, for example, to definitively match an individual user to a specific set of network activities. Since user-specific information is not typically embedded in network packets, that information must therefore be gathered from the security and event logs of the network host in question.
Having a central repository of this log information is also a way to identify log tampering. By having a duplicate log entry sent to a central log repository as the event happens, you can gain visibility into log entries that may actually no longer exist on the target system.
Most network hardware vendors support the SYSLOG standard. Microsoft uses its own proprietary Event Log format. Make sure your log collection system can adequately work with both of these formats. (Netmon Professional Edition and Netmon Enterprise Edition can collect security/event logs from both types of systems.
Host / User Reconciliation
Identifying suspicious activity from a particular IP address is only part of the equation. Depending on the nature of such activity, you may also be required to link a particular user to the events in question.
In most cases, network activity traces alone are not sufficient to prove that a particular user was responsible for a particular set of activities, especially when it comes to shared systems. In these situations, you'll need to provide additional evidence to indicate that a particular user was, in fact, logged onto the system in question at the time of the event in question.
The most effective way to do this is to ensure that logon/logoff events and security log entries are recorded by your monitoring system.
Summary
A network which is designed from the outset to facilitate audits can significantly reduce the headaches and costs associated with regulatory compliance and forensic investigations. These design guidelines can also be implemented on existing networks in independent phases, allowing you to take small steps without too much fuss.