Security, et al

Just a quick heads up that changes are coming - actually some pretty good sounding enhancements - to auditing in Windows Server 2012. 

We are finally getting expression-based audit policies which will hopefully make it possible to define super granular audit policy and finally configure the noise out of the security log! 

Also there are enhancements to file access, user logon auditing and new support for removable storage devices. 

Stay tuned - I'll surely be posting more info as I work with the actual bits.  Not to mention great webinars on the new features.

I have 2 rules of thumb when it comes to audit logging.  First, if it has a log I recommend enabling it – as simple as that.  The only exceptions are prohibitively verbose logging options associated with debugging or the surprisingly rare case where logging has an impact on performance.  Second, if you can collect the log and archive it with your log management/SIEM solution, do it - even if you don’t set up any alert rules or reports. 

I’ve repeatedly seen the value following these 2 rules for several reasons.  First, you really never know what audit log data will be valuable in a forensics situation and there is no way to reconstruct log data after the fact.  Enable auditing beforehand or forever hold your peace.  The most obscure or seemingly unimportant systems and applications may end up being crucial to determining the extent or root vector of an intrusion or critical to building your case in insider investigations.  One time I was called upon to help document a case of inappropriate behavior by a user and the client program for a popular Internet provider who at the time provided a log which proved very helpful in showing the user accessed certain forums at specific times linked to the actions being investigated.

Security events that you don’t necessarily monitor and respond to may also be valuable in providing documentation that you performed certain actions when necessary as part of a compliance related matter.  For instance in my standard audit recommendations for Active Directory I suggest auditing and archiving events related to the disabling and deletion of accounts and group membership removals.  There is typically no need to review these events but when the auditor comes around you can use them to document that you removed access in response to changes in employee status and role.

Finally, audit logs even if not reviewed can serve as a powerful deterrent against malicious actions and policy violations by end users and administrators alike.  If they know that their actions are being recorded and can be looked up and used against them in the future they will be much less likely to take chances.  But that’s only true if the audit logs are collected an archived to a system separate from the people being monitored.  Otherwise, especially in the case of administrators, logs a vulnerable to deletion or tampering.

What are some common logs that you should consider enabling and if possible adding to your log management process for collection and archival besides the obvious candidates like your domain controller security logs?  First and foremost, I strongly recommend you enable appropriate auditing on member servers and at least securely archiving them with your DC logs.  Many of the most critical security events on your network are only caught by your member servers.  This would include attempts to break into member servers with local accounts, security configuration changes, programs executed and files accessed.  Then like I stressed in last month’s article there is a wealth of security information in your workstation security logs.  I understand that you have a lot of workstations and it may be a challenge to collect and archive that many logs and that amount of data, but at least enable auditing on those workstations.  Set maximum log size to 300MB and chances are the audit data will be there when you need it even if you aren’t centrally managing them.

Besides the Windows security logs of all your systems, what are other good candidates for logging?  I highly recommend enabling DHCP server logging because many other security logs list the IP address but no other information to identity to identify the client.  If you have your DHCP logs you can look up that IP address and date and time against the lease events to figure out the MAC address and likely the computer name of the system that had that IP address at the time the event was recorded.  If you use RRAS (Routing and Remote Access Server) be aware that it has client authentication and connecting logging capabilities which record important events not sent to the Windows security log.  The same goes for IIS.  IIS can log every incoming request to any web based application you host including URL, verb, result code, client IP address and more.  This is critical for tracking down attacks against your website and other web based applications.  More and more companies are beginning to store and process security and compliance critical information in SharePoint and SharePoint too has an audit log capability.  Exchange 2010 has a new non-owner mailbox activity log and a new administrator audit log.  VMWare has an audit capability that is critical to ensuring accountability over your virtualization infrastructure.  SQL Server 2008 has a new audit log too.  Even Microsoft Dynamics CRM 2010 has an audit capability. 

 It seems like every software vendor is seeing the need to provide audit trail capability which is good news for information security but it also means we need to learn how to at least turn on these new audit features and ensure we don’t inadvertently consume too much storage or other resources.   And remember, there’s good reason to enable auditing even if you aren’t regularly reviewing or monitoring the logs.  If at all possible get these logs out of the systems and applications where they are generated and into your separate and protected log management/SIEM solution so that the integrity of these audit trails in ensured.  Follow these steps and chances are you will score points in the future when you can explain who did what and when they did it!

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.

This month I’m going to zero in on a specific area of audit logging that creates no end of confusion, and that is the difference between 2 categories in the Windows security log: Account Logon events and Logon/Logoff events.  These 2 categories are related but distinct and their names contribute to the confusion.  Let’s start by calling Account Logon events what they really are – authentication events.  I wish Microsoft had named the Account Logon category Authentication; it would have helped a lot. The way I remember it is, “the A in Account Logon is for Authentication.”

That being said, what is the difference between authentication and logon?  In Windows, when you access the computer in front of you or any other Windows computer on the network you must first authenticate and then you obtain a logon session on that computer.  Authentication is a point in time event.  A logon session has a beginning and end.  So are authentication events simply a duplicate of logon events?  No, and the reason is that authentication may take place on a different computer than the one you are logging into. 

Workstation Logons

Let’s start with the simplest case.  You are logging onto at the console (aka “interactive logon”) of a standalone workstation – meaning it is not a member of any domain – in fact let’s say it’s not even connected to a network.  The only type of account you can logon with in this case is a local user account defined in Computer Management \ Local Users and Groups.  You don’t hear the term much anymore but local accounts are the same thing as a SAM account.  In this case both the authentication and logon occur on the very same computer because we simply logged on to the local computer using a local account.  Therefore you will see both an Account Logon event (680/4776) and a Logon/Logoff (528/4624) event in its security log.  Note in this article I’ll always note the 3 digit Windows 2003 event followed by the 4 digit Windows 2008 event.

Now let’s make this workstation a member of a domain.  At this point it’s possible to authenticate to this computer using a local account or a domain account – or, for that matter, a domain account from any domain that this domain trusts.  We’ve already discussed what happens when you logon with a local account so let’s logon with a domain account.  Since the user specifies a domain account, the local workstation can’t perform the authentication because the account (and its password hash) isn’t stored locally.  So the workstation must request authentication from a domain controller via Kerberos.  So this time, the authentication event (672/4768) is logged on which ever domain controller handles the authentication request from the workstation.  Once the domain controller tells the workstation that the user is authentic the workstation proceeds with creating the logon session and a records a logon event (528/4624) in its security log. 

What if we logon to the workstation with an account from a trusted domain?  In that case one of the domain controllers in the trusted domain will handle the authentication and log 672/4768 there, with the workstation logging 528/4624 the same as above. 

In all such “interactive logons”, when you finally logoff, the workstation will record a “logoff initiated” event (551/4647) followed by the actual logoff event (538/4634).  You can correlate logon and logoff events by Logon ID which is a hexadecimal code that identifies that particular logon session.

Accessing Member Servers

After logging on to a workstation you normally re-connect to shared folders on a file server.  What gets logged in this case?  Remember, whenever you access a Windows computer you must obtain a logon session – in this case a “network logon” session.  Intuitively you might assume that the logon session begins when you connect to the share and then ends when you disconnect from it – usually when logging off your local workstation.  Unfortunately though, Windows servers only keep network logon sessions alive for as long as you have a file open on the server.  This accounts for why you see repeated logon/logoff events on Windows file servers by the same user throughout the course of the day.  With network logons, Windows 2003 logs 540 instead of 528 while Windows 2008 logs 4624 for all types of logons. 

When you logon at the console of the server the events logged are the same as those with interactive logons at the workstation as described above.  More often though, you logon to a member server via Remote Desktop.  In this case the same 528/4624 event is logged but the logon type indicates a “remote interactive” (aka Remote Desktop) logon.  I’ll explain logon types next.

Something we often need to know, when looking at logon events is what type of logon are we dealing with?  Is this an interactive logon at the console of the sever indicating the user was physically present or is it a remote desktop logon.  For that matter the logon could be associated with a service starting or a scheduled task kicking off.  In all such cases you will need to look at the Logon Type specified in the logon event 528/540/4624.  A full list of Logon Types is provided at the provided links for those events but in short:

Events at the Domain Controller

When you logon to your workstation or access a shared folder on a file server, you are not “logging onto the domain”.  There’s no such concept.  Each Windows computer is responsible for maintaining its own set of active logon sessions and there is no central entity aware of all everyone who is logged on somewhere in the domain.  After servicing an authentication request, the domain controller forgets about you; it doesn’t know how you were logging (console, remote desktop, network, etc) nor when you logoff. 

“But wait,” you might say “I see logon events on the domain controller, not just authentication events, whenever a user logs on to their workstation” and then periodically after that.   OK, that’s true: on domain controllers you often see one or more logon/logoff pairs immediately following authentication events for the same user.  But these logon/logoff events are generated by the group policy client on the local computer retrieving the applicable group policy objects from the domain controller so that policy can be applied for that user.  Then approximately every 90 minutes Windows refreshes group policy and you see a network logon and logoff on the domain controller again.  These network logon/logoff events don’t tell you much, I regard them usually as noise.  In forensic situations they could give you a rough idea of how long the user was logged on since as long as the user remains logged on group policy will refresh about every 90 minutes.  The other possibly useful thing about these group policy related logon/logoff pairs is that they help you infer that the preceding authentication events for the same user were in conjunction with an interactive or remote desktop logon as opposed to a service or scheduled task logon. 

What about the other service ticket related events seen on the domain controller?  That requires an in-depth discussion of Kerberos and how it’s implemented which is beyond the scope of this article.  Basically, after your initial authentication to the domain controller which logs log 672/4768 you also obtain a service ticket (673, 4769) for every computer you logon to including your workstation, the domain controller itself for the purpose of group policy and any member servers such as in connection with shared folder access.  Then as computers remain up and running and users remain logged on, tickets expire and have to be renewed which all generate further Account Logon events on the domain controller.

The Facts: Good, Bad and Ugly

Both the Account Logon and Logon/Logoff categories provide needed information and neither can replace the other – you need both.  And, ideally, you really need both categories of events from all your computers – including your workstations.  Here’s a number of important facts you need to understand, and… well… accept. 

1.       To determine definitely how a user logged on you have find the logon event on the computer where the account logged on.  You can only make some tenuous inferences about logon type by looking at the domain controller and that requires analyzing multiple events. 

2.       To determine when a user logged off you have to go to the workstation and find the “user initiated logoff” event (551/4647).

3.       To correlate authentication events on a domain controller with the corresponding logon events on a workstation or member server there is no “hard’ correlation code shared between the events.  Folks at Microsoft have suggested the Logon GUID field in these events would provide that but my research and experiments indicate that unfortunately the GUIDs are either not supplied or do not match.  So to make that correlation you basically have to dead reckon based on time, computer names and user account names. 

4.       Account Logon events on domain controllers are great because they allow you to see all authentication activity (successful or failed) for all domain accounts.  Remember that you need to analyze the security logs of all your domain controllers – security logs are not replicated between DCs. 

5.       Account Logon events on workstations and member servers are great because they allow you to easily pick out use of or attacks against local accounts on those computers.  You should be interested in that because using local accounts is bad practice and bad guys know they tend to be more vulnerable than domain accounts.  But, you don’t have to use Account Logon to detect logon attempts on local accounts; you can use Logon/Logoff events if you know what you are doing.  When viewing a Logon/Logoff event compare the domain name in the event details to the computer name that generated the event; if they match you are looking at a local account logon attempt – otherwise the domain name field with reflect some domain.  So can you survive with only enabling Logon/Logoff events on member servers and workstations?  I suppose so.

6.       Logon/Logoff events are a huge source of noise on domain controllers because every computer and every user must frequently refresh group policy.  If you disable this category on domain controllers what will you lose?  You will lose some visibility into logons at the domain controller itself such as when an admin logs on at the console, via remote desktop or a service or scheduled task starts up.  In all cases Account Logon events will still be logged but see points 1 and 2 above.

7.       Basically, successful network logon and logoff events are noise on domain controllers and member servers because of the amount logged.  Unfortunately you can’t just disable successful network logon/logoff events without also losing other logon/logoff events for interactive, remote desktop, etc.  My old adage is: “you can’t configure the noise out of the Windows security log” – that’s the job of your log management / SIEM solution. 

So that’s the difference between Account Logon (i.e. authentication) and Logon/Logoff events.  All things considered, I’d like to see both categories enabled on all computers ideally.  I haven’t seen these events create a noticeable impact on the server but the amount of log data might exceed your log management / SIEM solution’s current capacity.  If you can’t afford to collect workstation logs, I still suggest enabling these 2 categories on workstations and letting the log automatically wrap after reaching 100MB or so.  Chances are the data will be there if you need it for forensic purposes.

Intrusion detection and compliance are often the focus of log management/SIEM efforts and security logging in general.  But security logs (when managed correctly) are also the only control over rogue admins.  Why do I say that?  Well, once you give someone root or admin authority there is nothing they cannot do.  They can circumvent any access or authorization controls you implement on the system because with admin authority they can either directly change those settings or use hacker tools that leverage their root access to tamper with the internals of the operating system.  Beyond rogue internal admins, the same issues I bring up in this article apply to the risk of outside attackers who gain admin authority (aka root access).

The only control you really have over privileged super users is an audit log that, if properly handled, can serve as a deterrent and possibly detective control against misuse of privileged authority.  But notice I say “if properly handled”.  Those 3 words serve as in important warning that simply enabling auditing and deploying a log management solution may not suffice to provide a solid deterrent to rogue admins. 

To really be a deterrent, the audit log must be protected from deletion or tampering by rogue admins.  First and foremost that means you must move log data as frequently as possible from the system where it is generated to separate secure log repository.

Today’s enterprise log management solutions do a great job of frequent log collection and long term archival.  However, who has privileged access to your log management solution and the systems on which it runs?

A log management process is not an effective control over administrators if those same administrators have privileged access to the log management components.  To be clear I’m not suggesting that administrators be denied access to run reports, configure alerts or research logs.  I’m talking about privileged access to the log management solution that allows someone to disable, erase or otherwise compromise the integrity of the log collection and archival process.

So, to reiterate: a log management solution cannot serve as a deterrent over administrators if those same administrators have privileged access to it at the application level or any of the infrastructure components on which it runs.  That includes:

·         the operating system of the log management solution

·         any database servers it uses

·         the Active Directory forest in which the log manage server resides if a Windows server

·         the NAS or SAN where it stores log data

Moreover if the log management application or any of the components above run inside a virtual machine you should also include:

·         the virtualization host, such as VMWare ESX(i), if it runs inside a virtual machine

·         the virtualization manager, such as VMWare vCenter

·         any of the components listed earlier which are used by or host the virtualization manager

And of course physical access to any of those components would also potentially allow administrators to compromise the integrity of your audit trail.  Wow!  Does that mean your log management solution needs to run on a completely separate infrastructure?  To the extent possible, absolutely.  It certainly speaks to at least consider building your log management components from traditional physical servers and local disk storage.

And remember such separation is a protection against not just internal rogue admins but any outsider that succeeds in obtaining privileged access well.  Any outsider sophisticated enough to achieve that will also make efforts to erase their tracks.

Of course there are always cost/benefit comparisons to be made.  Typically the larger the organization the more important and more practical it is to achieve maximum separation between the log management solution and the environment it monitors. 

Beyond hardware and software separation, you must also consider who will provide the care and feeding for the log management application, database servers, storage, OS and other components.  Larger organizations have a dedicated information security team.  Within that team there should be a group with responsibility for the audit log management process.  For full accountability and separation of duty, that team should have no privileged access to production business systems monitored by the log management process.  Ideally that group would provide the care and feed necessary for all components in the log management solution.  Of course that may be impractical since information security professionals on that team may not be conversant in all the technologies involved.  In that case they should call upon the expertise of IT staff with the required skills as needed and ideally they would supervise the actions taken by such staff to ensure they do not compromise audit log integrity such as through the introduction of backdoors.

There are a host of reasons why even the “supervised access” method described above may not work.  Staff in smaller IT shops have to back each other up and often can’t specialize so the possibility for separation of duty like that described above may not exist.  Or, there may be a dedicated security and compliance officer, but that person may not be technical enough to supervise IT staff when maintenance is required on log management components.  Finally in some organizations there may be great push back to carving out a separate physical hardware environment for audit log management.  

When an in-house physically and logically separate log management system isn’t possible organizations, log management as a service may be an interesting alternative.  With cloud-based log management the entire log management system is at another site under the control of a professional service team.  Furthermore, some services can be set up with role based access control so that the ability to erase audit logs is controlled.  If organizations can overcome the frequent pushback to shipping audit logs to the cloud, full isolation and integrity of log data can be achieved without building a separate log management system and without needing system care and feeding expertise within the team responsible for audit log management.

Whether an organization goes with an in-house audit log management or turns the cloud it should carefully assess whether its choices in architecture and administrative responsibility allow it to rely on the log management system as a deterrent/detective control over rogue admins and as a means of impact analysis and recourse against outside intruders who gain root access.  When the worst happens, audit logs may be all you have.  Are they secure?

Security standards and auditors make much of reviewing logs for malicious activity and I am constantly asked for event signatures indicative of intrusions or even more simplistically some ask “What are the top Event IDs for intrusion detection?”  Ah, if it was only that easy.  Movies make it look that way, the protagonist furiously defends the network while a computer voice stridently calls out “intruder, intruder”. 

But in the real world, if the computer can detect an intruder it takes immediate preventive steps instead of simply logging the intrusion or helplessly calling out “intruder”.  For instance if an attacker tries to discover an account’s password through repeated logon attempts, the system locks out the account.  On the other hand, if a disgruntled employee copies sensitive data to flash drive, to the operating system it looks like any other day of normal usage.  An authentic user accessing authorized data.  If the system is logging anything at all, there will just be an audit trail of successful access attempts. 

It’s not impossible to use logs to detect some intrusions and malicious activity but the first and foremost return on investment from logging is an audit trail that can be used to detect high impact changes in security stance, investigate incidents, perform impact analysis, take action against offenders and learn how to prevent repeat attacks in the future.  Moreover, a properly deployed audit system serves as an effective deterrent control against insider abuse.  All of this can be accomplished by enabling logging on monitored systems and implementing a log management solution with high integrity deployment characteristics.

But to get more than change detection and audit trail usage from your logs you must go upstream from the logging function and get the cooperation from system administrators to configure and operate systems in such a way that certain foreseeable types of malicious activity will recognizable to your log management solution.

Take security log integrity in Windows as a simple example.  Windows provides strong protection against tampering with the security log.  Unless the operating system is down and you have physical access to the system you basically have to be an administrator to erase the security log.  (It’s very difficult even with administrator authority to modify event records in the security log – you need a program like the old WinZapper.)  Windows graciously logs a specific event ID (517 on Win2003 and 1102 on Win2008) whenever the log is cleared so it makes sense to generate an alert whenever security logs are cleared as a deterrent to rogue administrators trying to cover their tracks or as a way of detecting an intruder doing the same.  But if your administrators are in the habit of clearing the log when diagnosing system problems, your alert rule will generate false positives.  Therefore, in addition to reactive log management you must proactively get administrators to comply with a policy to never clear security logs and allow old events to die a natural death as records are purged.

While the previous case demonstrated an example of procedural measures implemented upstream from the log management process, detecting the spread of file based malware requires you to work with system administrators to setup system objects ahead of time for the purpose of helping the log management solution distinguish between normal file access and malicious.  Here’s the premise: you want to detect malware that has made it through your preventive controls like antivirus.  Most malware either spreads by injecting itself into files of affected file types (i.e. word documents or image files) or looks for files that it can send back to its nefarious operator. 

So, we set up the equivalent of a trip wire for unsuspecting malware or outside intruders to trigger.  (In this example I’ll stick with the Windows and Active Directory environment but the concepts would be applicable to other platforms.) To do this we work with various system administrators to create “honeypot” folders on servers throughout the network.  In these folders we put a collection of files with all the common file types including Office documents, image files (e.g. JPG, GIF), PDFs and others that have been targeted by malware.  Ideally we name these honeypot folders with just one or a few easily recognizable folder names.  We grant everyone access to these folders and enable file system auditing so no matter what user is the victim, the malware will have access to folder in order to trigger the tripwire.  If we want to detect malware that is spreading itself or simply corrupting data, we limit file system auditing to WriteData and AppendData.  On the other hand if we also hope to detect malware that is stealing data we would also enable auditing of ReadData. Then back at our log management solution we would enable alert rules when file system audit events (event ID 560 on Windows 2003 and 4663 on Windows 2008)  arrive which identify one of our honeypot folders as having activity.  To prevent false positives some training and reminders may be necessary for end-users so that they understand these folders (especially those on file server shares) have nothing useful for them and are there for “system” purposes. 

These 2 examples demonstrate you can take a foreseeable type of malicious activity and implement procedures or system objects that make it possible to detect activity that would normally blend in with the background noise of everyday, legitimate usage.  The downside of course is that you require cooperation from folks who are upstream from the log management solution.  Depending on the capabilities of your log management solution, you may be able to discover malicious activity without implementing upstream tripwires using a final method: anomalous changes in activity levels. 

Some types of malicious activity cause a spike in audit events that can be detected if your log management solution has sufficient real-time analysis capabilities.  My favorite example is the disgruntled insider who intends to post thousands of documents to a site like Wikileaks.  The user likely already has access to the sensitive documents in question so there may be little or no failed access attempts to alert you to what is happening.  Instead, file system auditing, if enabled, will generate successful read attempt events for each file accessed.  However, if a typical day in the life of the angry employ involves accessing just a handful of documents and now he or she suddenly accesses many times that amount, a feature rich log management solution should be able to keep a rolling average of normal Read events on sensitive folders for each user and detect a spike like this.  At that point there is sufficient cause to generate and alert and devote some security staff time to determining the cause.  With anomalous activity level detection, some thresholds can be generalized and baked into the log management solution but others would need at least some amount of customization by the organization such defining folders or servers that are considered sensitive. 

As you can see, detecting intrusions and abuse with logs is possible but it requires a variety of analysis techniques.  Likely you will need the cooperation of system administrators upstream from your log management system in order to setup procedural or system level tripwires.  Finally your log management solution’s ability to analyze large amounts of data detect sudden changes in activity levels for a given system or user can be very effective in alerting you that something is afoot. 

Vista, Windows 7 and Windows Server 2008 generate a lot of events regarding the Windows Firewall and for most of us in most scenarios this is at best chatter if not down right noise.  Here's how to get rid of it.

You need to disable all of the audit subcategories that reference Filtering Platform or MPSSVC as well as the "Other Policy Change Events" and other "System Events" subcategory. That's:

• Other Policy Change Events
• Other System Events
• MPSSVC Rule-Level Policy Change
• Filtering Platform Policy Change
• Filtering Platform Packet Drop
• Filtering Platform Connection

That's what I do in my Recommended Audit Baseline.  If you are on Windows Server 2008 R2 you can use group policy instead of the auditpol command; look for the Advanced Audit Policy folder at the bottom of Security Settings.

Don't forget to enable this policy before you start configuring subcategories.

Related webinars:

• Configuring Windows Audit Policy to Minimize Noise: Provide Compliance, Support Forensics and Detect Intrusions
• 7 Ways to Reduce the Noise in the Windows Security Log

Wow I just got off the phone with a prospective customer helping them to determine if out LOGbinder SP product would integrate with their SIEM solution (it did and does with all SIEM solutions). 

During the call they told me something I found very surprising.  After verifying that LOGbinder SP can purge old SharePoint audit events they said that every SIEM provider they speak to tells them that it’s not the job of the SIEM solution to delete old logs – it their job as part of operations. 

The customer’s beef with that response is that it causes them extra work to delete voluminous logs

Well I agree that SIEM solutions should be able to delete old logs but for a very different and much more important reason.  Here’s the theorem:

1.       Security logs should not be left on the system where generated.  This is infosecurity best practice 101.  You need to get logs off the systems where they are generated and into a separate, secure archive.  Why? Log integrity: 1) If a bad guy breaks in to your system the first thing he’ll do is delete your logs to cover up his tracks.  2) Logs are the only control over administrators but if your official copy of logs are left on the system they administer they can tamper with the logs that are supposed to provide accountability over them.

Ergo: Logs need to be collected.

2.       Logs eventually need to be cleaned up on the system where they are generated.  Some logs automatically wrap – like the Windows event log for instance – but some applications logs grow and grow – like the IIS for instance.  These logs can soon consume gigabytes of space

3.       Logs should not be deleted before they have been collected or else you lose valuable audit events and the integrity of your audit trail.

Ergo: If logs need to be collected, need to be deleted from local systems but should not be deleted before being collected then who is the in the best position to do that?  The SIEM solution, right?