[unisog] ACLs on Windows shares

James A. McCloskey jamesm at uwo.ca
Thu Aug 2 12:57:31 GMT 2007


Can't speak comprehensively in terms of the University of Western
Ontario, but in my last position (industry) we took this approach as a
means to primarily manage the access reporting and auditing - a
particularly serious requirement for that company given regulatory
pressures, but a requirement that is of course becoming more and more
pressing for all types of organizations/institutions.

An additional benefit of this was the ability to implement "allow" ACLs
at the share root without granting/modifying access to the underlying
resources (folders/files) - basically giving us the ability to deny
access to a particularly sensitive share without having to identify all
the access an individual had based on resource-level ACLs (by removing
the user's ID from the share-level "allow" ACL.

As a policy, we implemented a rule that all access would managed at
folder levels via an ACL.
So a one user/one file scenario would be answered through a move of the
file to a new folder, and implementation of a new ACL on that folder. 
Overkill?  Well, certainly more time consuming than simply modifying the
resource permissions directly.  But with a holistic access management
lifecycle perspective, far less time consuming.

Every ACL was associated with a primary and backup data owner (we
actually implemented this concept across all our systems, so we tended
to have the same DOSOs - data owner/system owners - responsible for
approving access to all the resources within their functional area). 
Workflow was implemented to allow for a 24h turnaround between end-user
request for access, routing of that access request to the DOSOs for
approval, and execution of approved changes.  This gave responsibility
for the access back to the "owning" area/manager, while maintaining
central IT control over the execution and logging methods.

Depending on the sensitivity of the data, DOSOs and line management
would be provided a report (from Enterprise Security Reporter data
linked to our MSSQL-based DOSO/workflow database) on a quarterly,
semi-annual, or minimum annual basis to validate access details.  We
basically ran 3 reports:
an ACL membership report, an ACL usage report, and a
consolidated-by-user ACL membership summary report.  The first would
identify to DOSOs which users are in their ACLs; the second would
identify to DOSOs and managers which ACLs control access to which
resources; and the final report would be provided to each user's manager
to provide a separation of duties check (based in part on the second
report of ACL application).

Further, HR termination/transfer-driven IT processes were amended to
ensure that when a DOSO left the company, or changed roles, that any
groups he/she owned would be migrated to the (former) direct supervisor
for reassignment.

All in all, while this sounds like a lot of overhead (it was a while
setting it up), the benefits in terms of demonstrating full auditability
of access through a user's lifecycle were tremendous.  Even the
always-challenging issue of dealing with legacy access for an individual
who has transferred from one role to another was able to be addressed
(albeit reactively): either the new manager would indicate certain
access should be deleted upon review of the user-specific ACL membership
report, or the old DOSOs would indicate access should be deleted based
on the ACL membership reports.

Suffice it to say that the auditors (SOX, DoD, others) were very happy!
And after a year's worth of reporting cycles, most management were on
side as well - all it took was forcing them to review the ACL
membership/usage reports, at which time they almost invariably were
shocked to see who still had access.  From then on, the process was well
received, as each had already seen the value of the process.

J

James A. McCloskey, CISSP
Central Information Security Officer
Information Technology Services
University of Western Ontario
jamesm at uwo.ca
519-661-2111 x. 81091



Russell Fulton wrote:
> We are reviewing how we manage shares on file servers.  We have the MS
> 'best practice' docs and have been looking at other sources too."
>
> We are interested to know if you have any policy or procedure for how
> you manage your shares on your file servers. If you do not have a set
> policy, how do you manage your shares? 
>
> We are looking at putting in a system were users are put into groups,
> these groups are then added to groups that are assigned to
> resources/shares. 
>
> We are particularly interested in how you manage the following. 
>
> - Adding a single user to a single resource. I.e a file in a folder, we
> the user does not need access to the hole folder but just that one file.
>
>
> - How do you manage the relationship between the business and IT terms
> of setting up groups in your AD and then assigning these to resources? 
>
> - Do you use any other tools outside of MS standard tools to manage your
> resources/shares
>
> - Do you have any auditing procedures or tools? 
>
> Russell
>
>
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jamesm.vcf
Type: text/x-vcard
Size: 354 bytes
Desc: not available
Url : http://lists.sans.org/pipermail/unisog/attachments/20070802/ac12943a/attachment.vcf 


More information about the unisog mailing list