Re: Windows Domain Controllers: Risks involved

["Ryan S. Johnston" <rsjohns () ILSTU EDU>]

Another thing with EFS, if your domain/enterprise admins have been 
designated the EFS Recovery Agent role, then encrypting the data with 
EFS isn't going to keep them out either.


Ryan

Ryan S. Johnston
Lead Windows System Administrator
Computer Infrastructure Support Services
Illinois State University



Brian Desmond wrote:
> *Hi Marmina-*
>
> * *
>
> *So fundamentally you're going to have to agree to trust the people 
> who are your domain admins. Let's say you apply ACLs to all your data 
> preventing domain admins from seeing it. As a domain admin I could 
> still go reset the password of a user in say the Finance department, 
> login with their ID and access the data they have access to. Or I 
> could add myself to let's say the Finance Users group and have access 
> to a folder full of data which is secured by that group.*
>
> * *
>
> *So as far as proactive protection here's a few things I'd aim for:*
>
> * *
>
> è *Know where your sensitive data is. It should all be on file 
> servers, Sharepoint servers, a document management system, etc. 
> Sensitive data on people's laptops, personal machines, USB thumb 
> drives, etc is just asking for getting your employer some quality real 
> estate on the front page of the newspaper one day. *
>
> o   *Once you know where your sensitive data is you can manage the 
> access to it with ACLs. The first thing you'd do here is pull the 
> default ACL which gives domain admins amongst others access and apply 
> a custom ACL. A typical folder access structure that actually tends to 
> work really well is to have two groups defined for every file share - 
> <Share> Modify and <Share> Read where <Share> is the name of the 
> share. I push hard for these standards based permissions structures 
> because overly complicated permissions add a lot of support overhead 
> and in my experience you're going to drastically increase the skill 
> level requirements of your Wintel admins if you expect them to support 
> complicated ACLs. *
>
> o   *Once you have defined baseline permissions you can audit the data 
> with a script or some other tool on a recurring basis and trap any 
> deviations from the baseline. *
>
> o   *If you're still concerned, setup auditing at the file system 
> level. Use an event log collection/alerting tool (e.g. Microsoft SCOM 
> & ACS) to trap audits for suspicious activity (e.g. change of 
> permissions).*
>
> è *Audit group membership changes in the directory*
>
> o   *Again use something to collect these security events, alert, and 
> report on them*
>
> è *Manage group membership with a self service tool in conjunction 
> with identity management. Generally speaking the people best equipped 
> to speak for access to data are the people who own it. Use a 
> workflow/self service package where users can request access to a 
> group. When the user requests access to the group an approver (e.g. 
> the owner of the data the group secures) has to approve it, possibly 
> the approver's manager, and also possibly the requestor's manager.*
>
> o   *On the flipside, setup access renewal for really sensitive stuff. 
> Every X months (call it 6) every member of a group has to have their 
> membership re-approved by the group owner/whoever else. This handles 
> the ever present problem with people not losing access to data 
> specific to their old job when they change jobs. *
>
> * *
>
> *As far as encryption goes, this is a double edged sword in some ways. 
> EFS (Encrypting File System) works great -- it's native to NTFS and 
> has been there since Windows 2000. The downside of it is that it's 
> really not the easiest thing to support and it will generate support 
> calls. In order to really do EFS right you're looking at deploying 
> PKI. There are a very limited number of people who know how to 
> actually do this right, so to be quite honest you're going to want to 
> hire one of those people as a consultant to set it up, write the 
> support procedures for you, and train your people. When someone loses 
> access to their data for whatever reason you use what's called a 
> recovery agent in EFS which allows you to decrypt the data without the 
> user's key. EFS will definitely make it a lot harder for a determined 
> domain admin to get at the data. That said, I would spend a good deal 
> of time weighing risk versus reward on this part of the discussion 
> though (EFS).*
>
> * *
>
> *Thanks,*
>
> *Brian Desmond*
>
> *brian.desmond () morantechnology com*
>
> * *
>
> *c - 312.731.3132*
>
> * *
>
> */Active Directory, 4th Ed/** - http://www.briandesmond.com/ad4/*
>
> *Microsoft MVP - https://mvp.support.microsoft.com/profile/Brian*
>
>  
>
> * *
>
> *From:* The EDUCAUSE Security Constituent Group Listserv 
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Marmina Abdel Malek
> *Sent:* Friday, March 13, 2009 6:39 PM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] Windows Domain Controllers: Risks involved
>
>  
>
>  Brian, you seems to be a super expert. So tell me, do you have any 
> recommendations to proactively protect the sensitive information 
> stored on these machines such as budgets, payroll, e-mails, etc. 
> I'm interested in a solution to protect users data from being accessed 
> by domain admins, rather than a solution which can detect malicious 
> access. Should we use encrypted folders/drives? if yes, what if a user 
> forgot his password, how can we recover his/her files?
>
>  
>
> Marmina
>
>  
>
>  
>
>  
>
> On Fri, Mar 13, 2009 at 10:41 PM, Brian Desmond 
> <brian.desmond () morantechnology com 
> <mailto:brian.desmond () morantechnology com>> wrote:
>
> Sure so the basic idea was that you would have this empty root and you 
> would
> isolate a few key security groups e.g. Schema Admins and Enterprise 
> Admins.
> You'd have a couple trusted people or maybe some sort of system where two
> trusted people had half the password or something to get access to 
> accounts
> in these groups.
>
> In turn you'd end up with X number of child domains with say X*3 domain
> admins - all different people. The theory then was that domain admins in
> Dom1 were only able to control things in Dom1, Dom2 Domain Admins 
> could only
> control Dom2, and so forth. Above all the assumption was that neither Dom1
> admins or Dom2 admins could do anything with your root domain, RootDom.
>
> In reality, as a domain admin in a child domain you can get at security
> groups in the root domain or another child domain. It's not 
> particuarly hard
> at all for Dom1 domain admins to make themselves members of the enterprise
> admins group or similar if they want.
>
> So the net result today is that if you want true security isolation 
> with AD
> you need separate forests. The only thing an empty root really gives 
> you now
> is an "anchor" name so to speak in a multidomain namespace.
>
> Thanks,
> Brian Desmond
> brian.desmond () morantechnology com 
> <mailto:brian.desmond () morantechnology com>
>
>
> c - 312.731.3132
>
> Active Directory, 4th Ed - http://www.briandesmond.com/ad4/
> Microsoft MVP - https://mvp.support.microsoft.com/profile/Brian
>
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
>
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU 
> <mailto:SECURITY () LISTSERV EDUCAUSE EDU>] On Behalf Of Jason Testart
> Sent: Friday, March 13, 2009 3:33 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU <mailto:SECURITY () LISTSERV EDUCAUSE EDU>
> Subject: Re: [SECURITY] Windows Domain Controllers: Risks involved
>
> Brian Desmond wrote:
> > The model of having the empty root is a Windows 2000 era
> > thing that was largely from misguided assumptions.
>
> Could you please elaborate on what these misguided assumptions might be?
>
> jt
>
> --
> Jason A. Testart, BMath               | Voice: +1-519-888-4567 x38393
> Manager, IT Security                  | Fax: +1-519-884-4398
> Information Systems and Technology    | http://ist.uwaterloo.ca/security
> University of Waterloo, Waterloo, Ontario  N2L 3G1 CANADA
>
>