Th e second part of this chapter is a description of an implementation of accountability. We will use the technical implementation norms for organizations of the most prevalent operating system and typical setup to build an accountability implementation. Microsoft’s Active Directory for version 2000 or better with Global Groups enabled has the widest audience. With some adjust- ments, this system could work for other operating systems and atypical designs.
Assumptions for this implementation of accountability are as follows: a Windows domain structure under a single forest, universal groups, permissions applied to groups only, a universal naming convention for both groups and shared resources, permissions set on every accessible resource, event logging for security and system events, and Logcaster (a log consolidation tool).
Large Windows domain structures prior to Windows 2000 were typically set up as resource domains trusting accounts domains to overcome limitations in the sizes of databases. Th is is no longer
CRC_AU6708_Ch012.indd 167
necessary, but the concept and a diagram will help to illustrate a domain that is complex enough to be applied to most enterprises (see Exhibit 12.1). In this domain structure, the user account is located in the a.com domain, and the fi le server is located in a separate domain, r.com. Both domains are located in a single forest so that database replication may occur.
Universal groups are found only in a forest where the functional level has been raised to a mini- mum of Windows 2000 native mode for all domains in the forest. Th is cannot be undone unless you restore all domain controllers from backup. (A strong warning: if you raise the functional level and if you have any NT 4.0 domains, you will lose replication capability.) Raising the functional level can be accomplished in the microsoft management console (MMC) for Active Directory Domains and Trust by right-clicking each of the domain objects and choosing from the context menu.
From Windows 2003 server Help fi le: Th e concept of enabling additional functional- ity in Active Directory exists in Windows 2000 with mixed and native modes. Mixed- mode domains can contain Windows NT 4.0 backup domain controllers and cannot use Universal security groups, group nesting, and security ID (SID) history capabili- ties. When the domain is set to native mode, Universal security groups, group nest- ing, and SID history capabilities are available. Domain controllers running Windows 2000 Server are not aware of domain and forest functionality.
It is possible to achieve accountability in separate forests by using a centralized logging facility, but the level of complexity increases.
Permissions need to be set on resources at the group level in a nested fashion to reduce permis- sions confl icts and confusion. An informal polling of hundreds of systems administrators over seven years indicates three things: Th ere is an overwhelming attitude of confusion on how to set permissions correctly, what the eff ective cumulative permissions are on a share, and how to clean up the permissions creep that occurs over the life of an account.
Permissions administrators should use a practical approach to permissions systems. Th e prac- tical approach from Discretionary Access Control Knowledge, a Practical System off ers a new solu- tion for administrators to reduce abuse of access controls and simplify permissions management.
Forest root Accounts domain a.com domain controller Resource domain r.com domain controller
User account File server resource
Accountability 䡲 169
“If the concepts of ‘THE SNAIL’ and the best practices are followed, administrators will be able to reduce the confusion of calculating the eff ective cumulative permissions. Using THE GRID and THE FIVE RULES allow administrators to quickly identify and reduce vulnerabilities….”*
Th is paper also details naming conventions for groups. When inappropriate actions are logged, there needs to be a clear understanding of who did what and when. By implementing standard naming of groups, we know the “who.” By implementing standard naming of resources, we know the “what.” If we have time synchronization with external timeservers, we know the “when.”
Th e organization of groups should follow “Th e Snail” concept of placing users only in global groups, placing global groups in universal groups, and placing universal groups in domain local groups (see Exhibit 12.2). Th is organization of groups allows for slow migration to a mature accountability posture. Th e naming conventions should support a clear path from the user account to the resource and its permissions. Th e following is an example naming convention:
Domain local groups
LgDepartmentFoldernamePermission If there is a deny permission, precede it with “x” Universal groups
UgDepartmentFoldernamePermission If there is a deny permission, precede it with “x” Global groups
GgDepartment
Th e antigroup concept that is critical for accountability implementations to work is employed by assigning all global groups who do not have permission to the resource to the xUg group. Th is may have a high administrative cost if scripts are not employed.
* http://www.sans.org/reading_room/whitepapers/windows/1165.php. Global group
Domain local group
Users Universal group
Exhibit 12.2 Nesting groups.
CRC_AU6708_Ch012.indd 169
Th is naming convention will allow for fast identifi cation of administrative error and the ability to track down accountability issues. Naming and organizing groups will support accountability if owners are assigned in Active Directory under the “Managed By” tab of the group.
Naming conventions and group responsibilities will help with separation of duties. Server operators who are responsible for fi le and print servers can limit their activities to creating shares, setting permissions for domain local groups, and setting auditing for the same groups. Domain administrators for resource domains can limit their activities to creating domain local groups and assigning domain local groups to universal groups. Domain administrators for accounts domains can limit their activities to creating and assigning users to global groups and creating and assign- ing global groups to universal groups. It is possible in a very mature accountability structure to identify inappropriate group creation.
Permissions can be set at three levels within the Windows operating system: share, NTFS (NT File System) folder, and NTFS fi le. To reduce confusion, set share permissions to full con- trol for everyone. Many administrators get upset with this suggestion. Share permissions, if left to stand alone, are never a good access control strategy. Th ey must be supported by NTFS folder permissions that maintain least privilege. Th ere should not be any need for NTFS fi le permissions. Administratively, this should be the only permissions; this can be achieved only by changing the advanced settings to remove inheritance of permissions. Th is is accomplished by removing the check in the “Allow inheritable permissions from parent” box.
At this point, the administrator’s group still maintains full control. Th is group contains the local administrator account of the fi ler and by default contains the domain administrators of the local domain as one of its members. If administrators cannot adjust permissions, they cannot do their job. Th is permission should be left alone so we can see when the administrator makes changes.
When building or adjusting group membership, an organization might want to put all groups in a single active directory container to prevent domain policy inheritance from changing confi gu- ration rights. Th is strategy also increases the speed of searching the directory.
By executing the administrative tasks mentioned, the users are in the correct groups, nesting of group types for the organization has been achieved, eff ective permissions can be set, antigroups are in place, and it is possible to achieve accountability via event logging. Th e result should look like Exhibit 12.3. Th ere should be two to four permissions set on the resource: local administrator with full control, antigroup with deny full control, and the one or two departments with their least privileges set.
Event logging is the core tracking mechanism for accountability. It should be confi gured at the domain policy level and not at the local policy level. For fi lers, audit should be set to success and failure for object access and success and failure for policy change. If additional auditing is turned on, extra events that do not pertain to accountability will be recorded.
Once auditing is turned on at the server and confi gured at the domain level, the objects or resources can be successfully tracked. Th e audit tab on the advanced security settings for the resource should audit for the two groups who do not need access on a regular basis: the adminis- trators and the antigroup. Keep in mind, the antigroup is everyone who does not have permission. Th e antigroup was defi ned by the accounts domain administrator at the universal group level by adding the global groups who do not need access to the resources of the department. If the per- missions administrator failed to set the deny all permission and did set the audit for both success and failure, the inappropriate access would still be logged. Th is is possible only for the antigroup and not the built-in “everyone group.” Th e “everyone group” includes everyone who has access to the network, which includes the people with permissions. If everyone is audited, both inap- propriate access and correct access will be logged. Th e goal is to log only inappropriate access.
Accountability 䡲 171
Th e administrator must see both success and failure audit events at accessing resources by the antigroup. Success audit events indicate incorrectly set permissions. Failure audit events indicate inappropriate attempts. By using the antigroup as the group for logging events, the fi rst part of accountability has been achieved.
Activity of both end-user violation and administrative maintenance must be collected, stored, and used. Th e use of the data for our initial purpose is accountability. Policy will need to be adjusted to fi t the real working conditions, because the accountability data will indicate gaps. Because only inappropriate activity is being collected, collection and storage of logging data will be reduced to a manageable level for review. Using an event log aggregation tool such as Logcaster by Rippletech will allow us to trap critical events as they occur, rather than at the point of offl ine storage. Critical events such as accountability violations, policy changes, audit changes, and per- missions changes should be submitted for immediate review by department managers, account- ability committees, and the end user. Immediate review ties actions to consequences. Automated output allows for immediate review without judgment calls by security teams or administrators. Critical events can be done via e-mail.
Caution should be used when fi rst implementing e-mail notifi cation due to a potential denial of service. Summarization is the best strategy for automation until false-positives are reduced to a manageable level. Any noncritical events such as administrator access should be collected, sum- marized, and reviewed in a reasonable time period.
Exhibit 12.3 Complete diagram of accountability implementation.
Forest Account domain UgDeptAFolderFc xUgDeptAFolder Resource domain LgDeptAFolderFc xLgDeptAFolder
Filer in resource domain with folder
SharePerm = FC everyone NTFS = FC LgDeptAFolderFc = Deny FC xLgDeptAFolder Audit = Succ & Fail
xLgDeptAFolder
= Succ & Fail Admin GgDeptA User GgDeptB GgDeptC GgDeptD CRC_AU6708_Ch012.indd 171 CRC_AU6708_Ch012.indd 171 1/8/2008 12:00:45 PM1/8/2008 12:00:45 PM
Threats
Accountability has many administrative threats. Th ey include prerequisite failures, implementation failures, maintenance failures, and mislabeling. Th e prerequisites of unique identifi cation and identity management are diffi cult to achieve and maintain. To hold people accountable, admin- istrators need to be sure the account is used by one and only one person. It would be bad form to punish someone for another’s actions. Shared accounts of administrators will be most troublesome if the intention is to apply accountability to technical administrative functions.
Initial implementation failures can include a high number of false-positives if the accountabil- ity systems are not installed in stages.
To address maintenance failures, keep in mind that permissions change. It is tempting to leave the past set of permissions in place and add new permissions. Th is violation of least privilege should be addressed by conducting regular reviews. Additional maintenance failures can be caused by staff changes on the administrative side, uncontrolled growth of staff , and lack of automation.
Organizations are likely to mislabel accountability as audit. But audit is a periodic third-party evaluation of gaps between policy and implementation. Accountability is immediate gap notifi ca- tion and correction by the parties involved.
Th ere are a few technical threats, including logging costs, lack of education, and requirement of centralization. Th e act of logging has a dollar value. Some organizations already have logging in place; those that do not have will be starting from scratch and, therefore, spending more. Lack of education on permissions and logging consolidation cause a great deal of unnecessary overhead on accountability systems. Centralization of logging, authentication, and policy are required for most organizations to achieve accountability.