Forum

During the IT audit I have hit into practical problem asked by auditees - how we can practically organise the segregation of duty in MS Windows environmnet, so that administrators would not have access to top management file server, or i.e. their Exchange mail? Of course, SOD could be applied at least to different roles of admins (MS Exchange v.s. file server admin), but as they often need to be domain admins to do their regular job, I am not sure if chance to take priviledges is not a risk. Of course, turning on audit trail could be a way, but I believe this kind of activity will be under carpet within 6m.

I was also thinking if ILP (Information leak protection) systems could not help them in this risk control?

Thanks for any open ideas,

Jiri

Most of the folks you mentioned don't really need to be full domain admins.  Any tasks they need to perform in Active Directory can be delegated in a granular fashion using AD's delegation of control feature.  It's also important to dedicated domain controllers to just being DCs; don't install databases or other applications servers on DCs.  DB and application admins typically require admin authority to the operating system but on DCs that effectively makes you a Domain Admin.  If you follow those to recommendations you can limit the number of people with Domain Admin authority to a handful. 

For that small group of Domain Admin folks there are no preventive controls - only deterrent/detective controls in the form of a high integrity audit trail as you alluded to.  To address the log overwrite (or tampering) issues you mentioned you need a log management solution implemented according to special requirements.  For more information see my whitepaper "When Good Admins Go Bad: The Critical Need for Log Management as a Deterrent/Detective Control".

I read your When Good Admins Go Bad whitepaper.  I'm curious to know what the "tell-tale events that lead up to a change in system audit policy" might be.

Are these the only defenses against this type of abuse?

• collecting and securing events in a non-domain controlled container as quickly as possible
• This might allow one to collect and secure the "audit policy changed" events before they can be erased.
• This also raises an interesting question.  Can one clear the event log without it resulting in an "audit log cleared" event, which must be cleared creating another "log cleared event", and so on?
• noticing gaps in the event stream, indicative of tampering
• noticing other "tell-tale" signs of tampering within the logs in the absence of "audit policy changed" and "audit log cleared" events

Are there any other approaches with merit?  I've heard of the SIEM vendor Arcsight claiming that their collection agents, placed on each host machine, can help mitigate the risk of this type of abuse, though I don't know their specific approach.  Thanks.

Or are there overlay "four eyes" products from Quest Software, etc. that can require two levels of approval for making changes to the audit policy or clearing the event log?  Does Win2k8 have built-in "four eyes" approval capabilities--I thought I'd heard it might.