Security, et al

I never have to convince people that monitoring Domain Controller security logs is important.  With member servers on the other hand I sometimes have to explain why those security logs are important but that’s not difficult because folks, and management in particular, understand that member servers is “where our data is”.  But when it comes to workstations I often face an uphill battle helping people understand why workstation security logs are so important. 

Frequently I hear things like “but we have a policy that forbids storing confidential information locally”.  Be that as it may workstations and especially 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 your page file which at any time can contain content from any document or other information you are working with.

But even if there were no confidential information on your workstations, their security logs are still very important to your enterprise audit trail, forensics and for detecting advanced persistent threats.  There’s a wealth of audit trail information logged by workstations that you can’t find 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, you can only find this information in the workstation’s security log.  Domain controllers audit your initial authentication when you logon to your workstation but essentially forget about you after that.  You can’t figure out logoff times based on shared folder connections because Windows does not keep network logons open to file servers between file accesses.  So, when you logout from Windows, the only computer on the network that logs this is your 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 0x12 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 you also need to know if someone is trying to break into to a workstation. If the attacker is trying to break into the workstation with a domain account you can find evidence of this in your 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. Don’t let the description of this event throw you because it says “The domain controller failed to validate the credentials for an account”.  The event should say “the system” instead of “domain controller” because this event is logged on all types of computers.

You can track what files a user accesses on file servers with file system auditing on those servers but to have an audit trail of what programs the user is executing, that too is only logged on workstation security logs. In forensic investigations I’ve found that knowing what programs a user ran and for how long was crucial to documenting what occurred and making our case.  Furthermore, many of the advanced persistent threat (APT) attacks being waged depend on malicious executables run on end user workstations.  So 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.

As you can see there’s a lot of critical audit trail information only available if you enable auditing on your workstations.  Of course enabling auditing on workstations is one thing while collecting logs from thousands of additional computers is another.  In addition there are some very important workstation security events which Windows auditing does not record.  For instance, Windows does not audit when you connect or disconnect devices or removable storage like flash drives.  Much less does it record what files you transfer to or from the removable storage.  Nor does Windows audit the installation of software.

 In a webinar I will present later this year in cooperation with Prism Microsystems I’d dive more deeply into these issues and how to address them.  t’s important that we all educate decision makers about why endpoint security and in this case audit logs from endpoints is so important.  We have to get beyond the mainframe inspired mindset that security only matters on the centralized systems where critical data resides.  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.  Keep an eye and be sure to register for this event and invite your manager.