UltimateWindowsSecurity.com Forum / Ultimate Windows Security Forum / IT Audit / Windows Server / SOD - practically for Windows administrators / Latest Posts

RE: SOD - practically for Windows administrators

RandyFranklinSmith — Thu, 08 Jul 2010 09:32:30 GMT

Agreed. You must pare down members in local Administrators and the AD Enterprise Amdin, Domain Admins and Administrators to the bare minimum. It is possible but you have to use AD's delegation

RE: SOD - practically for Windows administrators

dmcinnis — Mon, 28 Jun 2010 05:50:32 GMT

As for arcsight connector agents being tamper proof I can assure you they are not.By virtue of relying on the windows event logs , anyone who can successfully modify the event logs without leaving a explicit audit trail on the system can trick the connector.The connector only grabs and parses what it thinks is there from the event logs.
As for the delegation of access and decreasing the amount of domain admins that you have, requires proper AD structure organising ,planning and maintaining, along with strong boundaries of responsibilities.The stronger and more strict the structure, the easier it is to work with delegation.Some companies might find they lack the internal fortitude to restructure their AD based on the fact they need to make everything more auditable and controllable.

RE: SOD - practically for Windows administrators

ottermaton — Wed, 05 Aug 2009 19:05:03 GMT

Thanks for all of the info. I'm still curious to know what the "tell-tale events that lead up to a change in system audit policy" might be. Can you share any insight? Or is that some Alert Logic secret sauce?

RE: SOD - practically for Windows administrators

RandyFranklinSmith — Wed, 05 Aug 2009 15:34:39 GMT

Yes you can control operations on the security log using the CustomSD registry value. See this article in my wiki: http://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/Manage-auditing-and-security-log.

RE: SOD - practically for Windows administrators

RandyFranklinSmith — Wed, 05 Aug 2009 15:23:12 GMT

SEIM providers should be very careful about making any claims about their agent being tamper proof. The fact the agent is running on a computer where the admin has admin authority makes the agent subject to the so-called immutable laws of computer security http://technet.microsoft.com/en-us/library/cc722487.aspx. You can make the agent somewhat tamper resistant but no where close to tamper-proof.

RE: SOD - practically for Windows administrators

ottermaton — Wed, 05 Aug 2009 12:54:52 GMT

My last question pertained to the auditing component. However, pertaining to separation of duties, are there native capabilities in Win2k3 or Win2k8 to grant/deny specific permissions for changing audit policies and/or clearing the event logs? It would be beneficial to at least limit the number of administrators in the environment with these specific permissions, even if they could do just about anything else they wanted to. This would force them to do more work to execute their bad behavior and to cover their tracks, as they'd have to first add themself to the "Audit Gods" group before they could set to work.

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.

RE: SOD - practically for Windows administrators

ottermaton — Wed, 05 Aug 2009 12:44:17 GMT

Randy:

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.

RE: SOD - practically for Windows administrators

RandyFranklinSmith — Thu, 02 Jul 2009 06:57:44 GMT

This is a great question.

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".

SOD - practically for Windows administrators

sulovsky — Tue, 23 Jun 2009 10:03:54 GMT

Hi,

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