by Greg Shields Sponsored by
Table of Contents Fulfilling FDCC Compliance by Eliminating Administrator Rights ............................................... 1 Understanding the FDCC................................................................................................................................................... 1 FDCC, Admin Rights, and the Goal of Least Privilege.............................................................................................. 2 Summary ................................................................................................................................................................................. 4
Fulfilling Sarbanes-Oxley Compliance by Eliminating Administrator Rights ......................... 5 Understanding Sarbanes-Oxley ...................................................................................................................................... 5 SOX, Admin Rights, and the Goal of Least Privilege ................................................................................................ 7 Summary ................................................................................................................................................................................. 8
Fulfilling PCI Compliance by Eliminating Administrator Rights .................................................... 9 Understanding PCI DSS ...................................................................................................................................................... 9 PCI DSS, Admin Rights, and the Goal of Least Privilege ...................................................................................... 11 Summary .............................................................................................................................................................................. 12
Fulfilling HIPAA Compliance by Eliminating Administrator Rights ........................................... 13 Understanding HIPAA...................................................................................................................................................... 13 HIPAA, Admin Rights, and the Goal of Least Privilege ......................................................................................... 15 Summary .............................................................................................................................................................................. 16
Fulfilling GLBA Compliance by Eliminating Administrator Rights.................................... 17 Understanding GLBA ....................................................................................................................................................... 17 GLBA, Admin Rights, and the Goal of Least Privilege ........................................................................................... 18 Summary .............................................................................................................................................................................. 20
ii
Copyright Statement © 2009 Realtime Publishers. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtime Publishers (the “Materials”) and this site and any such Materials are protected by international copyright and trademark laws. THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtime Publishers or its web site sponsors. In no event shall Realtime Publishers or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials. The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties. Realtime Publishers and the Realtime Publishers logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. If you have any questions about these terms, or if you would like information about licensing materials from Realtime Publishers, please contact us via e-mail at
[email protected].
iii
Fulfilling FDCC Compliance by Eliminating Administrator Rights There’s a problem with the widespread distribution of administrator rights in your organization, and it has nothing to do with security. That problem is compliance: Compliance with the industry, governmental, and regulatory statutes that define certain configurations within your IT infrastructure. Although many of those configurations are mandated to enforce a greater level of security control, your job as IT professional is to ensure their fulfillment. However, similar to the tradeoffs we endure between strong security and total usability, the solid implementation of a compliant configuration often requires a reduction in user flexibility, administrative capability, and merely getting the job of IT done. Nowhere is this more prevalent than in compliance’s role in reducing the power and spread of administrative rights.
Understanding the FDCC
In the spaces bound by the federal government as well as its contractors and partners, new rules have been drafted that dramatically change how federal desktop configurations are locked down. Falling under the Federal Desktop Core Configuration (FDCC), these rules mandate hundreds of very specific configurations that must be enabled on any desktop that connects to a federal network.
The FDCC is a security configuration that began with a 2007 memorandum by the United States Office of Management and Budget (OMB). That memo discusses the need for a centralization of effort in defining a central configuration for all desktops contained within federal IT environments. Such a unified configuration would strengthen federal IT security by mandating a tested configuration across all federal IT organizations. This configuration would additionally provide a standardized starting point for external vendors, easing their process with developing solutions that work across the whole of government IT. In conjunction with the FDCC, the OMB also began work on the Security Content Automation Protocol (SCAP), a cross-platform vulnerability management protocol that enables outside vendors to validate their products’ functionality with FDCC desktops as well as other regulations required by government systems.
1
For Microsoft operating systems (OSs), today’s FDCC provides guidance for the Windows XP and Windows Vista OSs, describing a list of registry changes and Group Policy changes that must be implemented across all desktops. These changes span from disabling unnecessary services and applications to configuring firewall rules to adjusting user account and event log settings. Currently a version 1.0 release, the specific guidance can be downloaded from the Web site of the National Institute of Standards and Technology (NIST) at http://nvd.nist.gov/fdcc/index.cfm.
You’ll find that the FDCC’s guidance is exceptionally specific. In comparison with other compliance regulations usually associated with private industry—and highlighted in the other papers of this Essentials Series—the FDCC’s guidance is generally considered the most specific. Unlike other regulations, the FDCC documents the exact settings within the Windows OS that must be set to be considered compliant.
FDCC, Admin Rights, and the Goal of Least Privilege
Implementing the FDCC’s configuration dramatically changes the user’s operating environment in a number of very key ways. One of those is in the elimination of administrator rights as a primary logon for users. Individuals who require administrative privileges for the administration of the IT environment will be assigned a secondary logon that must be used only for accomplishing activities that require its level of privileges. This access is granted by waiver only. Effectively, the FDCC eliminates administrative privileges for all but the very few who are members of IT. Although this change in protocol will have the positive effect of increasing the level of overall security, at the same time it stands to reduce the agility of users. These users are those whose job role requires them to regularly switch between administrative and nonadministrative functions throughout the day. According to the FDCC’s guidance, users are directed to log out of this account and log back in with their standard user account once their administrative action has completed.
Of greater significance is the effect that the FDCC will have on typical users who are not IT administrators. These users will no longer be permitted to log in as an administrator and may only have a standard user account. This setup will not only increase security but also ensure that users cannot alter the defined standard desktop settings. With administrator rights, a user may configure his or her computer as they see fit. However, the OMB’s mandate to comply will impact the functionality of certain software packages that require administrative privileges to function. Some software packages simply will not work without administrative privileges. Whether through poor coding or architecture, a legacy approach to permissions, or other fallacies on the part of the software, use of this software requires the user to have administrative privileges. As such, a strict adherence to the FDCC guidelines can prevent some software from successfully running on federal computers.
2
Although not explicitly stated, it is generally accepted that a central goal of FDCC as well as every other industry, governmental, and regulatory compliance statute is the implementation of Least Privilege. The Principle of Least Privilege was developed more than 30 years ago by the United States Department of Defense (DoD). This principle “requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.” By eliminating administrator privileges from your environment, you are moving that environment towards one that fulfills this principle’s goals. You are at the same time going far towards fulfilling the requirements of regulations such as FDCC.
Yet Least Privilege is more than simply eliminating administrator rights. Least Privilege can more broadly be described as the intersection of the user’s role in the organization, the overarching corporate security policy of that organization, and the tasks that are available to be accomplished within the IT infrastructure. In effect, an environment that fulfills the requirements of Least Privilege will be very granularly capable of providing access to each person based on their needs. The User’s Role
Least Privilege The Available Tasks
The Corporate Policy
Figure 1: Least Privilege’s elimination of administrator rights is really the combination of three factors. For a comprehensive look at Least Principle’s three overlapping requirements as well as how the effective elimination of administrator rights requires the involvement of each, check out Essentials Series: Eliminating Administrator Rights, found at http://www.beyondtrust.com/wp_ElimAdminRights_download.aspx?source=Realtime.
3
Unfortunately, the Microsoft Windows OS alone does not natively provide the architecture to enable this granular control. Using the Microsoft Windows OS, it is possible to eliminate the privileges assigned to an individual. However, these person-based privileges are far too coarse in their application. For example, with poorly-coded applications, simply removing administrator rights from a user may actually prevent needed applications from functioning. Other system configuration changes, like connecting to a local printer, can also require administrative rights, making their removal a problem for the user.
Summary
Organizations that fall under the scope of FDCC should consider the use of external solutions that extend the granularity of privileges assigned. Such tools enable privileges to be assigned to applications based on user roles, adding that necessary granularity while still fulfilling the requirements of governmental mandates. These tools also provide the right level of audit-friendly logging that tracks user and administrator actions across systems, ensuring you meet your compliance regulations’ requirements for activity tracking.
4
Fulfilling Sarbanes-Oxley Compliance by Eliminating Administrator Rights There’s a problem with the widespread distribution of administrator rights in your organization, and it has nothing to do with security. That problem is compliance: Compliance with the industry, governmental, and regulatory statutes that define certain configurations within your IT infrastructure. Although many of those configurations are mandated to enforce a greater level of security control, your job as IT professional is to ensure their fulfillment. However, similar to the tradeoffs we endure between strong security and total usability, the solid implementation of a compliant configuration often requires a reduction in user flexibility, administrative capability, and merely getting the job of IT done. Nowhere is this more prevalent than in compliance’s role in reducing the power and spread of administrative rights.
Understanding Sarbanes-Oxley
To begin, let’s look at the regulations that make up the Sarbanes-Oxley (SOX) Act of 2002 itself. SOX was enacted by the United States Congress in response to a number of accounting scandals that occurred early in the decade. Its language implemented a set of requirements for financial reporting as well as corporate disclosure. Although the large majority of its guidance relates to business operations outside Information Technology (IT), some of its language has been interpreted to relate to the practices that IT uses in managing its information.
Of the major US compliance laws, SOX is considered exceptionally non-specific in terms of the guidance it provides to IT organizations. SOX mandates that a set of controls be put into place that manages the distribution and release of information. It further requires that provable auditing of those controls as well as their information under management is enabled at all levels.
5
There are four sections of SOX that are commonly scoped to include changes in IT practices, with one in particular having the most impact: •
•
•
•
Section 302, Corporate Responsibility for Financial Reports. This section requires that documentation of the company’s operational activities and financial statements are certified by the company’s CEO and CFO.
Section 404, Management Assessment of Internal Controls. This section most relates to the operations of IT and requires that operational processes are documented. Further, all sources of data disclosed on financial documentation must be demonstrated. It is the interpretation of this section that mandates changes to IT’s processes, requiring a greater level of control over IT data, privileges, and activity logging.
Section 409, Real-time Issuer Disclosures. This section requires that changes in a company’s financial condition or operations must be disclosed in real time to investors. Section 802, Criminal Penalties for Altering Documents. This section mandates the retention of certain documents using methods that cannot be altered. IT must ensure through some technical means that those documents have not been altered once created.
Unlike other compliance regulations—such as HIPAA for the healthcare industry, GLBA for financial services, and PCI for companies that store credit card information—SOX is not specifically limited to a particular industry. SOX’s guidance relates to essentially any publicly-traded company. This means that organizations in one of these industries must often fulfill compliance from both their industry-specific regulations as well as SOX itself.
The operational realization of these regulations is generally accomplished through the correct assignment of user privileges as well as the monitoring of their activity. Thus, there must be an alignment between the job role requirements of users and the actual privileges those users are given. It also means that the activities of users on the network must be monitored with records of that activity being stored for later review. Further, those records must be stored in such a way that they cannot be erased or modified by an individual. Ensuring SOX compliance is accomplished by proving that such controls are in place and that their auditing data remains unaltered.
6
SOX, Admin Rights, and the Goal of Least Privilege That last statement—ensuring SOX compliance is accomplished by proving that such controls are in place and that their auditing data remains unaltered—is exceptionally important. IT organizations that fall under the rules of SOX must implement a set of “controls” that restrict the actions of users to just those tasks required by their job roles. Further, when users actually work with business systems, users’ activities must be monitored and logged into a verifiable database. This task would be easy if it were natively supported by the Windows operating system (OS). To accomplish auditing on individuals’ actions, many applications log information to Windows event log. However, if users have administrator rights, they can cover their tracks and erase the logs. Although not explicitly stated, it is generally accepted that a central goal of SOX as well as every other industry, governmental, and regulatory compliance statute is the implementation of Least Privilege. The Principle of Least Privilege was developed more than 30 years ago by the United States Department of Defense (DoD). This principle “requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.”
By eliminating administrator privileges from your environment, you are moving that environment towards one that fulfills this principle’s goals. You are at the same time going far towards fulfilling the requirements of regulations such as SOX.
Yet Least Privilege is more than simply eliminating administrator rights. Least Privilege can more broadly be described as the intersection of the user’s role in the organization, the overarching corporate security policy of that organization, and the tasks that are available to be accomplished within the IT infrastructure. In effect, an environment that fulfills the requirements of Least Privilege will be very granularly capable of providing access to each person based on their needs. The User’s Role
Least Privilege The Available Tasks
The Corporate Policy
Figure 1: Least Privilege’s elimination of administrator rights is really the combination of three factors.
7
For a comprehensive look at Least Principle’s three overlapping requirements as well as how the effective elimination of administrator rights requires the involvement of each, check out Essentials Series: Eliminating Administrator Rights, found at http://www.beyondtrust.com/wp_ElimAdminRights_download.aspx?source=Realtime.
Unfortunately, the Microsoft Windows OS alone does not natively provide the architecture to enable this granular control. Using the Microsoft Windows OS, it is possible to eliminate the privileges assigned to an individual. However, these person-based privileges are far too coarse in their application. For example, with poorly-coded applications, simply removing administrator rights from a user may actually prevent needed applications from functioning. Other system configuration changes, like connecting to a local printer, can also require administrative rights, making their removal a problem for the user.
Summary
Organizations that fall under the scope of SOX should consider the use of external solutions that extend the granularity of privileges assigned. Such tools enable privileges to be assigned to applications based on user roles, adding that necessary granularity while still fulfilling the requirements of governmental mandates. These tools also provide the right level of audit-friendly logging that tracks user and administrator actions across systems, ensuring you meet your compliance regulations’ requirements for activity tracking.
8
Fulfilling PCI Compliance by Eliminating Administrator Rights There’s a problem with the widespread distribution of administrator rights in your organization, and it has nothing to do with security. That problem is compliance: Compliance with the industry, governmental, and regulatory statutes that define certain configurations within your IT infrastructure. Although many of those configurations are mandated to enforce a greater level of security control, your job as IT professional is to ensure their fulfillment. However, similar to the tradeoffs we endure between strong security and total usability, the solid implementation of a compliant configuration often requires a reduction in user flexibility, administrative capability, and merely getting the job of IT done. Nowhere is this more prevalent than in compliance’s role in reducing the power and spread of administrative rights.
Understanding PCI DSS
Payment cards and the information they contain can be considered a direct linkage to a person’s personal income. As such, the theft of that information is a major problem for consumers as well as the payment card industry in whole. The central problem with payment cards is that the information on their plastic is actually stored for periods of time on the computers of every storefront where they are used.
Because of this distribution of payment card data and the dangers it presents, in 2004, the major payment card companies—American Express, Discover, JCB, MasterCard, and Visa— agreed to create an industry standard that defined how payment card data would be secured. Describing specific requirements for data security in transit, during processing, and at rest, the Payment Card Industry Data Security Standard (PCI DSS) outlines explicit requirements for businesses that handle payment card information. The compliance mandates required by PCI DSS are placed upon all industries that are involved with any form of payment transaction. This starts at the individual storefront or any institution that takes credit card payment, continues through the third-party processors that handle retail transactions, all the way through the banks that are responsible for the payments themselves. PCI DSS’ regulations apply at every point during a payment card transaction’s life cycle, and relate to any network component, server, or application that is included in or connected to the cardholder data environment.
9
The current PCI DSS version 1.2 is comprised of 12 high-level requirements that relate to six different goals. Each requirement has a number of sub-requirements that further outline its guidance. Specific details about those goals and requirements can be found at https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf. You’ll quickly see in reviewing its goals that PCI DSS’ guidance is fairly specific in relation to other industry and regulatory compliance guidelines currently in place today. Although PCI DSS’ requirements span the range of required security controls, a few relate specifically to the problems of administrator rights distribution: •
Requirement #7. In this requirement, businesses are instructed to restrict access to cardholder data by business need-to-know. Requirement 7.1 states that businesses should “Limit access to system components and cardholder data to only those individuals whose job requires such access.” Requirement 7.2 continues with the need to “Establish an access control system for systems components with multiple users that restricts access based on a user’s need-to-know, and is set to ‘deny all’ unless specifically allowed.”
The widespread distribution of administrator rights in an organization is at direct odds with these requirements. This is the case because administrator rights enable complete and unrestricted access to an entire system for the specified user. Thus, enabling administrator rights to those who do not require it for specific administrative actions specifically violates Requirement #7’s guidance. •
Requirement #8. Some retail establishments historically created generic user accounts for all users of point-of-sale equipment. That practice over time found itself migrating into other areas of the network as well. This practice eases the use of these machines by retail employees but does not provide direct traceability between user and action. As such, no auditable logging of user actions can be done.
To combat this shortcoming, users must be given specified accounts that are based on their person, and those accounts must be granted the granular permissions to accomplish the tasks associated with their job roles. Requirement #8 includes five sub-requirements that specifically define how this process should be accomplished.
10
•
Requirement #10. Similar to the requirement for activity tracking in other compliance regulations, this requirement mandates that access and use of network resources is tracked. This tracking must be done across all accounts and should be protected against deletion. Requirement 10.1 states that businesses should “Establish a process for linking all access to system components to each individual user—especially access done with administrative privileges.”
Requirement 10.2 further mandates that businesses should “Implement automated audit trails for all system components for reconstructing these events: All individual user accesses to cardholder data; all actions taken by an individual with root or administrative privileges; access to all audit trails; invalid logical access attempts; use of identification and authentication mechanisms; initialization of audit logs; creation and deletion of systemlevel objects.” As with other compliance regulations, these sub-requirements mandate that user and administration activities are tracked in an auditable way.
PCI DSS, Admin Rights, and the Goal of Least Privilege
Among other requirements, IT organizations that fall under the rules of PCI DSS are charged with implementing a set of “controls” that restrict the actions of users to just those tasks required by their job roles. Further, when users actually work with business systems, their activities must be monitored and logged into a verifiable database. This task would be easy if it were natively supported by the Windows operating system (OS).
Although not explicitly stated, it is generally accepted that a central goal of PCI DSS as well as every other industry, governmental, and regulatory compliance statute is the implementation of Least Privilege. The Principle of Least Privilege was developed more than 30 years ago by the United States Department of Defense (DoD). This principle “requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.”
By eliminating administrator privileges from your environment, you are moving that environment towards one that fulfills this principle’s goals. You are at the same time going far towards fulfilling the requirements of regulations such as PCI DSS.
Yet Least Privilege is more than simply eliminating administrator rights. Least Privilege can more broadly be described as the intersection of the user’s role in the organization, the overarching corporate security policy of that organization, and the tasks that are available to be accomplished within the IT infrastructure. In effect, an environment that fulfills the requirements of Least Privilege will be very granularly capable of providing access to each person based on their needs.
11
The User’s Role
Least Privilege The Available Tasks
The Corporate Policy
Figure 1: Least Privilege’s elimination of administrator rights is really the combination of three factors.
For a comprehensive look at Least Principle’s three overlapping requirements as well as how the effective elimination of administrator rights requires the involvement of each, check out Essentials Series: Eliminating Administrator Rights, found at http://www.beyondtrust.com/wp_ElimAdminRights_download.aspx?source=Realtime.
Unfortunately, the Microsoft Windows OS alone does not natively provide the architecture to enable this granular control. Using the Microsoft Windows OS, it is possible to eliminate the privileges assigned to an individual. However, these person-based privileges are far too coarse in their application. For example, with poorly-coded applications, simply removing administrator rights from a user may actually prevent needed applications from functioning. Other system configuration changes, like connecting to a local printer, can also require administrative rights, making their removal a problem for the user.
Summary
Organizations that fall under the scope of PCI DSS should consider the use of external solutions that extend the granularity of privileges assigned. Such tools enable privileges to be assigned to applications based on user roles, adding that necessary granularity while still fulfilling the requirements of governmental mandates. These tools also provide the right level of audit-friendly logging that tracks user and administrator actions across systems, ensuring you meet your compliance regulations’ requirements for activity tracking.
12
Fulfilling HIPAA Compliance by Eliminating Administrator Rights There’s a problem with the widespread distribution of administrator rights in your organization, and it has nothing to do with security. That problem is compliance: Compliance with the industry, governmental, and regulatory statutes that define certain configurations within your IT infrastructure. Although many of those configurations are mandated to enforce a greater level of security control, your job as IT professional is to ensure their fulfillment. However, similar to the tradeoffs we endure between strong security and total usability, the solid implementation of a compliant configuration often requires a reduction in user flexibility, administrative capability, and merely getting the job of IT done. Nowhere is this more prevalent than in compliance’s role in reducing the power and spread of administrative rights.
Understanding HIPAA
The Heath Insurance Portability and Accountability Act (HIPAA) of 1996 was enacted for dual purposes. Its first purpose was to establish a mechanism for employees to retain their health insurance coverage during a job loss or job change. The second arrives through what is known as Title II. In this section, HIPAA enacts national standards for the creation, use, and protection of electronic personal health information (ePHI). HIPAA requires the creation and management of documented evidence that security policies exist and are being followed. This document should include elements such as network and server configuration, backup and restore procedures and audits, operational procedures, as well as the auditing of user and administrator actions within IT systems.
13
The majority of HIPAA’s requirements that relate to IT systems are contained within section 45 CFR 164, commonly known as “the final rule.” This final rule outlines HIPAA’s guidance associated with the integrity, availability, and privacy of ePHI. It also outlines guidance associated with authentication to and access control within systems that contain ePHI data, as well as the requirements for auditing such systems. The following list highlights Information about that guidance: •
•
•
•
•
Integrity of ePHI Data—45 CFR 164.312(c)(1), (2), & (e)(2)(i). Technical controls must be implemented that protect ePHI from improper alteration or destruction until it is disposed.
Availability of ePHI Data—45 CFR 164.308(a)(7)(ii). Procedures must be established and implemented that create and maintain retrievable and exact copies of ePHI data. Also, procedures must be established and implemented to restore any lost data.
Authentication to ePHI Data Systems—45 CFR 164.312(d). Systems and/or procedures must be established that verify the person or entity seeking access to ePHI data is the one claimed.
Access Control in ePHI Data Systems—45 CFR 164.312(a)(1), (2), & (3). Systems that contain ePHI data must allow access only to those persons or software programs that have been granted access rights. Unique IDs must be assigned for identifying and tracking users. Sessions must be terminated when they have become inactive.
Audit of ePHI Data Systems—45 CFR 164.308(a)(5)(ii)(c) & 164.312(b). Technical controls must be implemented that record and examine the activity in ePHI data systems as well as procedures that monitor logins and report discrepancies.
The widespread distribution of administrator rights in an organization is at direct odds with these requirements. Such is the case because administrator rights enable complete and unrestricted access to an entire system for the specified user. Additionally, with administrator rights, users can alter system records and generally subvert the requirements for tracking users who access information.
14
HIPAA, Admin Rights, and the Goal of Least Privilege As with other compliance regulations, HIPAA’s guidance revolves around the protection of personal data through the implementation of technical controls. The controls also protect that data from corruption or change through established systems that enforce data integrity.
IT organizations are also charged with implementing a set of “controls” that restrict the actions of users to just those tasks required by their job roles. Further, when users actually work with business systems, their activities must be monitored and logged into a verifiable database. This task would be easy if it were natively supported by the Windows operating system (OS).
Although not explicitly stated, it is generally accepted that a central goal of HIPAA as well as every other industry, governmental, and regulatory compliance statute is the implementation of Least Privilege. The Principle of Least Privilege was developed more than 30 years ago by the United States Department of Defense (DoD). This principle “requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.” By eliminating administrator privileges from your environment, you are moving that environment towards one that fulfills this principle’s goals. You are at the same time going far towards fulfilling the requirements of regulations such as HIPAA.
Yet Least Privilege is more than simply eliminating administrator rights. Least Privilege can more broadly be described as the intersection of the user’s role in the organization, the overarching corporate security policy of that organization, and the tasks that are available to be accomplished within the IT infrastructure. In effect, an environment that fulfills the requirements of Least Privilege will be very granularly capable of providing access to each person based on their needs. The User’s Role
Least Privilege The Available Tasks
The Corporate Policy
Figure 1: Least Privilege’s elimination of administrator rights is really the combination of three factors.
15
For a comprehensive look at Least Principle’s three overlapping requirements as well as how the effective elimination of administrator rights requires the involvement of each, check out Essentials Series: Eliminating Administrator Rights, found at http://www.beyondtrust.com/wp_ElimAdminRights_download.aspx?source=Realtime.
Unfortunately, the Microsoft Windows OS alone does not natively provide the architecture to enable this granular control. Using the Microsoft Windows OS, it is possible to eliminate the privileges assigned to an individual. However, these person-based privileges are far too coarse in their application. For example, with poorly-coded applications, simply removing administrator rights from a user may actually prevent needed applications from functioning. Other system configuration changes, like connecting to a local printer, can also require administrative rights, making their removal a problem for the user.
Summary
Organizations that fall under the scope of HIPAA should consider the use of external solutions that extend the granularity of privileges assigned. Such tools enable privileges to be assigned to applications based on user roles, adding that necessary granularity while still fulfilling the requirements of governmental mandates. These tools also provide the right level of audit-friendly logging that tracks user and administrator actions across systems, ensuring you meet your compliance regulations’ requirements for activity tracking.
16
Fulfilling GLBA Compliance by Eliminating Administrator Rights There’s a problem with the widespread distribution of administrator rights in your organization, and it has nothing to do with security. That problem is compliance: Compliance with the industry, governmental, and regulatory statutes that define certain configurations within your IT infrastructure. Although many of those configurations are mandated to enforce a greater level of security control, your job as IT professional is to ensure their fulfillment. However, similar to the tradeoffs we endure between strong security and total usability, the solid implementation of a compliant configuration often requires a reduction in user flexibility, administrative capability, and merely getting the job of IT done. Nowhere is this more prevalent than in compliance’s role in reducing the power and spread of administrative rights.
Understanding GLBA
The Gramm-Leach-Bliley Financial Services Modernization Act (GLBA) of 1999 brought about a dramatic change in the way banks operate. The act was passed by the United States Congress to open up competition among banks, securities companies, and insurance companies by eliminating the previous rules that forced a separation between investment and commercial banks as well as between banks and insurers. In addition to these large-scale changes to bank operations, two statutes focus on information security: the Financial Privacy Rule and the Safeguards Rule. The Financial Privacy Rule outlines guidance associated with the collection and disclosure of personal financial information for customers of financial institutions. This rule applies to both the financial organizations as well as any companies that receive this kind of information from financial organizations. GLBA’s Safeguards Rule requires all financial institutions to design, implement, and maintain a set of safeguards that protect their customers’ information. As with the Financial Privacy Rule, companies that receive this information are also responsible for these protections.
17
GLBA’s guidelines are quite general in implementation, making them challenging to interpret and making difficult the task of designing solutions that comply with their mandates. Whereas other regulations such as PCI outline specific technical solutions or architectures that ensure security and protection, GLBA’s guidance is at an extremely high level. GLBA’s Privacy Rule includes language that: • • • •
•
Requires the protection of an individual’s personal information through the definition of privacy practices. Requires the creation of a privacy notice that explains those practices.
Requires the distribution of that privacy notice on a yearly basis to customers and consumers of its services. Grants the ability for individuals to opt out of certain data-sharing arrangements that have been established by the financial institution. This can include limiting or blocking the transfer of information to non-affiliated companies. Prohibits the practice of “pretexting,” which involves the collection of personal information under false pretenses.
These general guidelines are enforced through Title V of GLBA’s implementing regulations—the “Safeguards Rule”—which states that:
Each bank shall implement a comprehensive written information security program that includes administrative, technical, and physical safeguards appropriate to the size and complexity of the bank and the nature and scope of its activities…A bank’s information security program shall be designed to: 1. Ensure the security and confidentiality of customer information; 2. Protect against any anticipated threats or hazards to the security or integrity of such records. 3. Protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.
GLBA, Admin Rights, and the Goal of Least Privilege You’ll notice that nowhere in this guidance is any substantive detail about the technical solutions that should be implemented to fulfill these requirements. This specific guidance is left to the federal and state agencies that enforce its provisions. The result is that your auditing process for these regulations can be highly dependent on the agency performing the audit.
18
That being said, as with other compliance regulations, GLBA’s guidance revolves around the protection of personal data through the implementation of technical controls. They also protect that data from corruption or change through established systems that enforce data integrity. IT organizations are also charged with implementing a set of “controls” that restrict the actions of users to just those tasks required by their job roles. Further, when users actually work with business systems, their activities must be monitored and logged into a verifiable database. This task would be easy if it were natively supported by the Windows operating system (OS). Although not explicitly stated, it is generally accepted by auditors that a central goal of GLBA as well as every other industry, governmental, and regulatory compliance statute is the implementation of Least Privilege. The Principle of Least Privilege was developed more than 30 years ago by the United States Department of Defense (DoD). This principle “requires that each subject in a system be granted the most restrictive set of privileges…needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.” By eliminating administrator privileges from your environment, you are moving that environment towards one that fulfills this principle’s goals. You are at the same time going far towards fulfilling the requirements of regulations such as GLBA.
Yet Least Privilege is more than simply eliminating administrator rights. Least Privilege can more broadly be described as the intersection of the user’s role in the organization, the overarching corporate security policy of that organization, and the tasks that are available to be accomplished within the IT infrastructure. In effect, an environment that fulfills the requirements of Least Privilege will be very granularly capable of providing access to each person based on their needs. The User’s Role
Least Privilege The Available Tasks
The Corporate Policy
Figure 1: Least Privilege’s elimination of administrator rights is really the combination of three factors.
19
For a comprehensive look at Least Principle’s three overlapping requirements as well as how the effective elimination of administrator rights requires the involvement of each, check out Essentials Series: Eliminating Administrator Rights, found at http://www.beyondtrust.com/wp_ElimAdminRights_download.aspx?source=Realtime.
Unfortunately, the Microsoft Windows OS alone does not natively provide the architecture to enable this granular control. Using the Microsoft Windows OS, it is possible to eliminate the privileges assigned to an individual. However, these person-based privileges are far too coarse in their application. For example, with poorly-coded applications, simply removing administrator rights from a user may actually prevent needed applications from functioning. Other system configuration changes, like connecting to a local printer, can also require administrative rights, making their removal a problem for the user.
Summary
Organizations that fall under the scope of GLBA should consider the use of external solutions that extend the granularity of privileges assigned. Such tools enable privileges to be assigned to applications based on user roles, adding that necessary granularity while still fulfilling the requirements of governmental mandates. These tools also provide the right level of audit-friendly logging that tracks user and administrator actions across systems, ensuring you meet your compliance regulations’ requirements for activity tracking.
20
