Why Workstation Security Logs Are So Important
Thu, 16 Feb 2012 15:35:21 GMT
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.
Live with Dell at RSA 2015
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
Virtualization Security: What Are the Real World Risks?
Audit Myth Busters: SharePoint, SQL Server, Exchange
previous | next
powered by Bloget™