No one needs to be convinced that monitoring Domain Controller security logs is important; member servers are equally as important: most people understand that member servers are where “our data” is located. But I often face an uphill battle helping people understand why workstation security logs are so critical.

Frequently I hear IT administrators tell me they have policies that forbid the of storing confidential information locally. But the truth is, workstations and laptops always have sensitive information on them – there’s no way to prevent it. Besides applications like Outlook, Offline Files and SharePoint workspace that cache server information locally, there’s also the page file, which can contain content from any document or other information at any time.

But even if there were no confidential information on workstations, their security logs are still very important to an enterprise audit trail, forensics and for detecting advanced persistent threats. There’s a wealth of audit trail information logged by workstations that can’t be found anywhere else and consequently a host of questions that can only be answered by workstation logs.

First of all, if you care about when a user logged off, this information can only be found in the workstation’s security log. Domain controllers audit the initial authentication during logon to a workstation but essentially forget about the user thereafter. Logoff times cannot be determined based on shared folder connections because Windows does not keep network logons open to file servers between file accesses. So, during logout from Windows, the only computer on the network that logs this is the workstation.

And what about logon failures? Yes, domain controllers do log authentication failures but the events logged are tied to Kerberos and the error codes are based on RFC 1510’s failure codes. Kerberos failure codes are not as granular and do not map directly to all the reasons a logon can fail in Windows. Therefore some authentication failure codes provided in event IDs 4768 and 4771 can mean any one of several possible reasons. For instance, failure code 0×12 which Kerberos defines as “Clients credentials have been revoked” can mean that the logon failed due to the account being disabled, locked out or outside of authorized logon hours.

With today’s focus by bad guys on the endpoint it’s also important to know if someone is trying to break into a workstation. If the attacker is breaking into the workstation with a domain account, the evidence of this can be found in the domain controller security logs by looking for the same to events mentioned above. However workstations also have local accounts and these are big targets for attackers since local accounts are often poorly secured and tend to fly under the radar in terms of security monitoring. When you attempt to logon to a workstation with a local account, this activity is not logged on the domain controller. Since the authentication is being handled locally the event is also logged locally in the form of event ID 4776. The event description can be confusing; it reads: “The domain controller failed to validate the credentials for an account.” What it should actually say is “the system” instead of “domain controller” because this event is logged on all types of computers.

Files that a user accesses on file servers with file system auditing on those servers can be tracked, but an audit trail of what programs were being executed by the user is logged on workstation security logs. During forensic investigations I’ve found that knowing what programs a user ran and for how long can be crucial to documenting what actually occurred. Furthermore, many of the advanced persistent threat (APT) attacks being waged depend on malicious executables run on end user workstations. You can’t afford not to have a record of what’s running on your endpoints. Unfortunately, the Process Tracking (aka Detailed Tracking) category only logs programs run on the local computer therefore no information about end user desktop program usage is available in domain controller or member server security logs. The only process events logged on servers are the actual server programs that execute there.

There’s a lot of critical audit trail information only available if auditing is enabled on the workstations. Of course enabling auditing on workstations is one thing while collecting logs from thousands of additional computers is another. There are some very important workstation security events which Windows auditing does not record. For instance, Windows does not audit when devices or removable storage like flash drives are connected or disconnected, and it does not record what files are transferred to or from the removable storage, nor does Windows audit the installation of software.

Workstations are really just as important as any other component of a secure network. If an attacker can compromise the workstation of a user with access to critical information the attacker can impersonate that user and access any information or applications that user has access to on the network. Even workstations of users without access to sensitive resources are important because attackers, especially in APT, scenarios are happy to start with any endpoint as beach head and attack other systems from there. Moreover workstations are arguably the most vulnerable components of your network since they process so much content from the Internet connected with web browsing and email, because they come into contact with potentially infected files on removable storage and because they connect to other insecure networks like Wi-Fi hotspots.

In a webinar I will present later this year in cooperation with Prism Microsystems I’ll delve more deeply into these issues and how to address them. It’s important that we educate decision makers about why endpoint security and audit logs from endpoints are so important. We have to get beyond the mainframe inspired mindset that security only matters on the centralized systems where critical data resides. Be sure to register for this event and invite your manager.