Security, et al

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?

SharePoint audit policy is widely regarded as a site collection level setting leading many to believe you must apply one audit policy to all objects in the entire site collection.  If that were the case you would run into some real granularity problems leading to either not being able to get the events you need for important lists or libraries or else enabling too much auditing and getting way to many events.

Thankfully though you can enable auditing on specific document libraries or lists but you have to know where to look which I will explain in a moment.

First though what audit policies would you likely want to enable for an entire site collection and what would you want to activate only on specific lists and libraries?  The one audit policy I always suggest enabling "Editing users and permissions" (aka Security Change in LOGbinder SP) which will provide an audit trail of all auditable security related changes for the site collection including permission changes, changes to users and groups and change to audit policy itself.

At the list and library level you have a variety of activities you that you can audit including:

• Viewing
• Editing
• Deletion
• Check in /Check out

List/library level audit policy is extremely important when it comes to auditing who is viewing confidential information.  If you enable View auditing at the site collection level you end up generating events for every page click by every user througout the entire site collection which will create a load on resources and storage. 

To enable auditing for a certain library access the library’s (or list’s) settings page and click the “Information management policy settings” link under Permissions and Management.

In the next page you’ll see entries for the content types allowed for that list or library. For instance a normal document library will have 2 content types: Document and Folder. Click on a content type and configure auditing. In the example below I’ve enabled auditing of any type of view and download access since this is a library contains confidential information.

Now SharePoint will obediently begin auditing those actions on that particular list or library and if you have my LOGbinder SP software you'll be able to report or alert on those events with LOGbinder SP SIEM Edition or if you have your own log management / SIEM solution you can use LOGbinder SP Agent Edition to get SharePoint audit events out of the content database where they don't belong and into your log management solution where they do!  Click here for more information on LOGbinder SP.

I was just reading about the CEO of Lieberman Software and his rant about RSA SecurID.  Talk about kicking them when they're down!  He reportedly accuses RSA of letting SecurID languish.  I don't know if RSA has done that or not.  But what I do know is that anyone can get hacked.  RSA, Lieberman Software, you name it...

So instead of just switching to different strong authentication provider smart organizations are going to look for a strategic way to protect themselves against any of their vendors who might get hacked - especially their authentication vendors.

You should be able to plug and play / mix and match tokens and other strong authentication methods without ripping out your infrastructure, without implementing multiple proprietary authentication servers.  You should be able to use the right token/method for each unique situation in your organization and you should be able to phase out a vendor that gets hacked without major disruption to your users and network.

That's not pie in the sky.  This is all possible when you leverage the OATH framework and select authentication vendors that embrace and support OATH standards.  I just did a webinar on OATH and its relevance to this whole SecurID situation. The recording is at Quest Software who sponsored the webinar.  They were the right sponsor as you will see when then demontrate their Defender solution which is the best implementation of the whole OATH concept that I've seen.  To watch the webinar click here. 

Endpoint malware is getting more and more sophisticated and more and more vendors and content/file types are being targeted. The signature based model of classic antivirus (AV) and the teams and infrastructure behind it are increasingly stretched to keep up with the pace and sophistication of today’s financially motivated malware developers. 

On the other hand patch management is getting more complicated as the bad guys target more and more software vendors.  Moreover both patch management and AV are reactive – not proactive. 

A fundamentally different approach to combating end-point malware is application whitelisting.  Not only is application whitelisting proactive but in contrast to the negative security model used by AV and patch management, whitelisting uses a positive security model to stop malware. 

Traditional approaches to application whitelisting can prove to be maintenance nightmares, impact productivity and cause dissatisfaction among end-users. 

But these challenges can be overcome by an advanced implementation of whitelisting that incorporates more intelligence into trust decisions and that addresses the realities of PC environments. 

These thoughts are prompted by the fact that I just completed a whitepaper for Lumension entitled: “Using Defense-in-Depth to Combat Endpoint Malware: A Technical Paper”.  While researching for this paper I was impressed with the grasp of the issues that Lumension’s team has on endpoint security and the challenges associated with whitelisting.

Whitelisting is a challenge because it’s tougher than you might think to define what software should be allowed to run throughout your network.  Lumension’s Intelligent Whitelisting takes the concept of a static application whitelist and applies it to the real world of hundreds or thousands of unique, ever changing PCs with a practical approach that provides immediate whitelisting benefits to any population of PC without the upfront burden of analysis and testing necessary with traditional whitelisting.  They do this by

1.       Acknowledging the uniqueness of each PC by implementing an automatically customized local whitelist on each computer.

2.       Recognizing trusted agents of change so that patches, enhancements and new applications can be installed without any manual effort required to update whitelist rules.

3.       Allowing you to take a more practical, value driven approach by implementing whitelisting progressively rather than as a point-in-time, do-do-die cutover.

With endpoint malware more dangerous than ever, patch management and AV remain indispensable defenses but are insufficient by themselves due to their reactive nature and negative security model.  Application whitelisting provides the vital 3rd layer of proactive, positive security model defense.

Please request my whitepaper which expands on these issues in much more depth.  Click here to get Using Defense-in-Depth to Combat Endpoint Malware: A Technical Paper.