Security Does Not Equal Compliance

“Expensive episodic compliance exercises are giving way to continuous cost-sustainable compliance processes.”

—Ian Glazer, Gartner Inc.

Analysts know better than any that compliance is not a checklist of policies to create, but instead a benchmark for the better integration of people, technology, and processes. Or at least, that's what compliance rules and regulations should impel businesses to create. The rules and laws of each individual company must be strict and consistent to ensure productivity, compliance, and security. These rules must be constantly monitored and updated by both a human resources (HR) rep that understands rank and privilege and IT administrators who can implement privileges based on the description given by HR.

All too often though, management can mistake well-planned and executed information security architecture with satisfaction of compliance and regulatory statutes. Unfortunately, nothing could be further from the truth. Great, or even good, security practices don't always mean compliance, and vice versa. Satisfying compliance and regulatory mandates to the letter may still leave you vulnerable to security breaches, especially the dreaded insider attack that we have discussed at length throughout this book.

This is another area where the intersection of human nature and technology becomes important and requires least privilege as a key success factor for establishing a compliant architecture. 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 toward one that fulfills this principle's goals. You are at the same time going far toward fulfilling the requirements of most of the current regulations, as almost all have some form of clause emphasizing fraud control and have identified “privileged access” as an area of higher risk by which fraud has been committed.

GRC Demystified

Every discussion around security and compliance brings up yet another acronym that must be dissected, analyzed, and demystified. In this case, the acronym is GRC and is the short form for governance, risk, and compliance. These three letters seem to have more events, budget dollars, companies, real and “marketectured” solutions, publications, bloggers, certifications, and water-cooler conversations than any other acronym (with perhaps FUD [fear, uncertainty, and doubt] as the exception, but that is the subject of another book).

Let's look at each of these areas individually for a better understanding of how they fit within your strategy.

Governance

Corporate governance ensures accountability across the extended enterprise. It facilitates staying competitive and satisfying ever-changing government regulations while providing mechanisms and controls to reduce the inefficiencies that arise when individuals misuse privileges granted to them.

If You Can't Change It, You Can't Govern It

A key aspect of corporate governance is ensuring that the changes decided by management are in fact enforced across every office and IT system despite geographic, network, and operating system differences. This can be especially difficult for companies that grow through acquisition where newly acquired IT assets rarely match current corporate standards. Getting new policies rolled out and enforced to new acquisition assets can be extremely time consuming and tedious work but very necessary to maintain compliance. Without these types of controls, companies face the dire consequences already seen by the likes of Enron and MCI (formerly WorldCom). We have already discussed the intentional, accidental, and indirect misuse of privilege at length in all of the previous chapters.

Implementing a privilege identity management (PIM) solution can significantly impact corporate governance accountability and change management in real-time across the extended enterprise, as well as eliminate the misuse of privilege across heterogeneous systems and virtualized, or even cloud-based, administrators. Any change to privileged access can be accomplished from a centralized console and pushed to every environment in real-time. All entitlements and audit logs can also be reviewed on-demand and therefore your company can ensure governance mandates.

Steps to Good Governance

Managing and auditing corporate governance initiatives are an often-overlooked area for executives and IT professionals. Reading any one of the thousands of business books that describe successful companies, you will uncover that it was their ability to react and pro-act to market changes at an enterprise level that allowed them to exceed market or competitive norms. Likewise, in those same books, you will find examples of failed companies whose IT infrastructure actually prevented or inhibited their ability to enforce change across all employees.

Audits for compliance are typically required, but extending this practice to real-time governance can be the difference between success and failure for companies in today's ever-changing market climates.

• Making changes in who has privilege to do what on specific IT resources (servers, desktops, network devices, virtual & cloud environments) should be as simple as making a central policy change and having that propagated and enforced in real-time across the extended enterprise.
• Implementing a PIM solution is the best first step in establishing this real-time corporate governance.

Risk

Risk is a very subjective subject. What is an acceptable level to one executive or company may be considered far too radical for another. We haven't seen anything that can guarantee 100% safety when it comes to IT security, but we have seen some architectures that come close. So, at best, you can only hope to manage risk and the associated expectation around cost of protection versus cost of damage reparation.

At some point in your life, you have probably heard the story about closing the barn doors after the horses have already left the stable and its corollary that “an ounce of prevention is worth a pound of cure.” The same can be said for dealing with insider threats and the types of solutions available today.

Figure 9-1. Levels of insider threat mitigation solution

Fundamentally, you will find three levels of insider threat mitigation solutions (Figure 9-1) available to you:

• Credential Management: Vaulting of passwords and credentials to control who has access to what resources under what circumstances. On the positive side, you will know who was logged into a resource when a breach occurred, but the challenge with this technology is the lack of visibility into what they did once they were logged in. In this situation, you have eliminated users maintaining their own credentials and facilitate the access to IT resources through a web-based shared account password management (SAPM) solution. When the user desires access, they go to a specific web screen that then logs the user into the requested resource based on some recognized stored policy. The good news here is that in the event someone misuses that resource, you have a record of who was using it at the time of the breach. This is the equivalent of knowing who did the damage but not what they did.
• Session Management: In addition to managing credentials, some solutions can also log everything done by individuals while logged into a resource. On the positive side, you will know who was there and what they did so that you can possibly remediate the damage, but the challenge with this technology is the inability to prevent the damage from being done in the first place. In this situation, you are building on password management with the addition of automatic logging of every event (or keystroke) to another server of what was done once someone is granted access to the resource. If harm does occur in this situation, then you not only know who did the harm but what they did, so you can “unwind” or fix what was done.
• Privilege Management: In addition to managing credentials and logging activities, this solution can also enforce policy at a fine-grained entitlements level to ensure only those with proper authorization can do what they are attempting to do. On the positive side, you not only manage credentials and log transactions, you also prevent damage from occurring by limiting the privileges to only those necessary. In this situation, you are delegating privileges (system authorizations) to specific users based on defined, centralized corporate policy. This builds on session logging and delivers all of the previous value, but now limits the damage potentially done as it limits what authorizations are available based on policy. In effect, you have prevented harm from being done and have a record of who attempted to do harm and what they attempted to do.

Compliance: The Big C

In a survey conducted by Unisphere Research, results showed that even though many DBAs are willing to assume much-needed security practices in their daily duties, there is an overwhelming communication disconnect between these data managers and the security and executive leadership responsible for the data security at the end of the day.

The report surveyed 761 members of the Professional Association for SQL Server (PASS) in September 2010. Behind human error, the most commonly cited challenges to database security are insider hacks and the abuse of privileges (44%).

The key take away from the report is that there is a disconnect between what DBAs know needs to be done at the technical level versus the amount of support and awareness the executives on the business side actually give to them.

Monitoring database access is part of the solution, but addressing the misuse of privilege requires going beyond that. It is just as essential to continually audit privileges to ensure that employees and partners only have access to the minimum amount of sensitive data necessary to perform their duties. This requirement for separation of duties is also a cornerstone of virtually all compliance regulations.

One in five respondents “fears that their organization will experience a major data breach over the coming months, but few are aware of the potential costs to their organizations.” Among those respondents that are aware of where data breaches have occurred, they cite “a pattern of inside abuse and errors.”

Cloud Compliance Introduces New Issues

One of greatest challenges for organizations leveraging cloud environments is demonstrating policy compliance. For many business functions that commonly run in the cloud, such as hosting web sites and wikis, it is often sufficient to have a cloud provider vouch for the security of the underlying infrastructure. However, for business-critical processes and sensitive data, it is absolutely essential for organizations to be able to verify for themselves that the underlying cloud infrastructure is secure.

The use of virtual machines adds further complexity into the mix, since creating an identity for an individual virtual machine and tracking that virtual machine from creation to deletion can be challenging for even the most mature virtualized environments. Proving that the physical and virtual infrastructure of the cloud can be trusted becomes even more difficult when those infrastructure components are wholly owned and managed by external service providers.

Cloud providers must be able to demonstrate that they have tested and can ensure that privileged user access is controlled and monitored. For instance, ISO/IEC 27001 requires an organization to create an information security management system (ISMS). This enables an organization to use a risk-based approach to identifying and satisfying all compliance requirements, justify the selection and implementation of controls, and provide measurable evidence that the controls are operating effectively.

Organizations that claim to have adopted the ISO 27001 standard can therefore be formally audited and certified compliant with the standard. It is already fairly well known and accepted outside of the US and is slowly gaining awareness and acceptance within the US. ISO 27001 requires that management:

1. Systematically examine the organization's information security risks, taking account of the threats, vulnerabilities, and impacts;
2. Design and implement a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable; and
3. Adopt an overarching management process to ensure that the information security controls continue to meet the organization's information security needs on an ongoing basis.

When appropriate, organizations should also ask for a commitment from providers to meet regulatory standards such as the Payment Card Industry (PCI) Data Security Standard (DSS), Health Insurance Portability and Accountability Act (HIPAA) in the US, and the EU Data Protection Directive.

Alphabet Soup

In the United States alone, there are over 300 federal agencies that have posted tens of thousands of regulations that need to be traversed, understood, and acted upon in order to maintain compliance. The US government has a web site, regulations.gov, that not only lists the regulations but has a dedicated page to list “Regulations with Comment Periods Coming Soon” to make sure you don't miss any reporting deadlines.

Unfortunately, there are more acronyms here than permutations available for uniqueness. So, you need to be careful when someone talks about an acronym in a conversation. For example, when talking about PCI, you need to determine if they are referring to the Payment Card Industry Data Security Standard or Peripheral Component Interconnect standard for hardware expansion bus communication.

Let's look a little closer at some of the more visible regulations that are especially affected by least privilege or the lack thereof. To illustrate, we will do a deep dive on HIPAA to show how details of a regulation can sometimes be a bit tricky, then highlight some of the other regulations to point you in the right direction. There are many other resources available to take you through the details of each and every regulation and we didn't feel this book was the appropriate place for that.

HIPAA

In 1996, the Department of Health & Human Services set the rules for protection of individually identifiable health information under the Health Insurance Portability and Accountability Act (HIPAA).

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.

So, where do HIPAA, admin rights, and least privilege intersect?

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

We discussed at length how 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.

PCI DSS

Another key regulation is the Payment Card Industry (PCI) Data Security Standard (DSS), which is a set of comprehensive requirements for enhancing payment account data security in an effort to thwart the theft of sensitive cardholder information. The core group of requirements is as follows:

• Build and maintain a secure network
• Protect cardholder data
• Maintain a vulnerability management program
• Implement strong access control measures
• Regularly monitor and test networks;
• Maintain an information security policy

On October 28, 2010, the PCI Security Standards Council (SSC) unveiled version 2.0 of the PCI DSS. Until then, PCI DSS had not had an update since version 1.2 in October 2008. The recent “Summary of Changes” document released by the PCI SSC covers the proposed changes in version 2.0, and as experts expected, few alterations were made between the summary and the final release.

However, one important area to note in the new version is in the PCI DSS Intro and Various Requirements section. In this section, the focus is on virtualization, and though minor, it expands the definition of system components to include virtual components. This addition should alert enterprises to begin assessing their security policies to virtual servers and desktops in their IT environment.

Organizations moving their physical server infrastructure onto virtual platforms for cost savings are finding their virtual hosts and guests are now open to new security and non-compliance risks. Attaining least privilege user posture in virtualized desktop and server environments is challenging and customers are consistently forced to make compromises on security in favor of cost-savings.

Remember, the PCI DSS has never been a compliance program. It is a standard baseline for assessing compliance that the five major card brands (Visa, MasterCard, American Express, Discover, and JCB) agreed to use as the foundation for their actual, individual compliance programs. At the end of the day, each of the five major card brands still retains final say on compliance and can implement their own compliance requirements over and above the PCI DSS (and Payment Application Data Security Standard [PA DSS]) when or if they see fit.

The Cost of SOX Is Declining?

No, we're not talking about socks that protect your feet; we're talking about the government regulation that most of you are worried about. Sarbanes-Oxley (SOX) was enacted in 2002 to counter a number of major corporate and accounting scandals and establish a set of public accounting reforms and investor protection mandates.

Protiviti released a new study in the spring of 2011 on the effectiveness and costs of SOX compliance with a number of interesting insights for IT managers who are concerned about the effectiveness and costs of their IT controls. The overall results are encouraging.

According to Protiviti's 2011 SOX Compliance Survey, the cost of SOX compliance is declining and most participants believe the benefits of the controls outweigh the costs. Now we are little skeptical that all of the companies surveyed are including the full impact of SOX controls on IT costs, especially since less than 50% track and report the hours and costs of compliance. I suspect some companies have just gotten comfortable that some of the activities they added are just part of a new normal. Sort of like the metaphor of a slowly boiling frog not jumping out of the pot.

Nevertheless, the way companies are approaching the continuous improvement in their SOX controls is telling. They are simultaneously reducing costs and increasing the effectiveness and efficiency of operations by following a number of key strategies:

• Using the COSA framework to define best practices. COBIT would provide a similar framework for IT.
• Increase use of automated controls and continuous monitoring including a shift to preventative rather than detective controls.
• Use of data mining and analytics to increase understanding of process performance.
• Consolidating IT processes, platforms, and systems.

These are all things IT can embrace and as a strategic vendor of compliance and security solutions to the enterprise, things we should and can help our customers with. Implementing least privilege across physical, virtual, and cloud-computing environments can also add to these savings.

Privilege Security Requirements

Banks, insurance companies, and other institutions are faced with the monumental task of managing authorization to mission-critical systems. These organizations have large numbers of internal and external users accessing an increasing number of applications, with each user requiring a different level of security and control requirements. In addition, these organizations must also address identity management concerns that arise from compliance issues related to such regulations as SOX, HIPAA, and PCI DSS.

High administrative costs due to account maintenance, password resets, inconsistent information, inflexible IT environments, silos due to mergers and acquisitions, and aging IT infrastructures make this even more challenging for organizations. Together, these factors are propelling the adoption of least privilege solutions across all industries. A least privilege architecture framework should consist of four continual stages running under a centralized automated platform: access to privileged resources; control of privileged resources; monitoring of actions taken on privileged resources; and remediation to revert changes made on privileged IT resources to a known good state:

• Access: Access includes the process of centrally provisioning role-based time-bound credentials for privileged access to IT assets in order to facilitate administrative tasks. The process also includes automation for approval of access requests and auditing of access logs.
• Control: Control includes the process of centrally managing role-based permissions for tasks that can be conducted by administrators once granted access to a privileged IT resource. The process also includes automation for approval of permission requests and auditing of administrative actions conducted on the system.
• Monitor: Monitor includes audit management of logging, recording, and overseeing user activities. This process also includes automated workflows for event and I/O log reviews and acknowledgements and centralized audit trails for streamlined audit support and heightened security awareness.
• Remediation: Remediation includes the process of refining previously assigned permissions for access and/or control to meet security or compliance objectives, and the capability to centrally roll back system configuration to a previous known acceptable state if required. Automation of the privileged access management lifecycle includes a central unifying policy platform coupled with an event review engine that provides control for and visibility into each stage of the lifecycle. See figure 9-2.

Figure 9-2. Risk Lifecycle.

Case Study: Using Least Privilege to Meet Compliance

DCI (www.datacenterinc.com), headquartered in Hutchinson, Kansas, is a premier developer of innovative core bank processing software and related technology serving hundreds of banks nationwide. DCI was founded by community bankers in 1963, and remains privately owned by several clients, with customers serving on their Board of Directors.

The corporation delivers technology solutions that allow banks to prosper and thrive. Because of the nature of the company and the services it provides, heavy IT support is necessary for the deletion, migration, and back-up of large amounts of sensitive data.

Dale Martinson, manager of systems and security at DCI, is responsible for managing the company's ever-increasing IT demands, including ongoing support for these procedures. To ensure the ability to support DCI's long-term strategic growth, Martinson and his staff performed a comprehensive evaluation of the IT infrastructure, including its safeguards and security functions.

The internal audit incorporated access-related areas such as reviewers, users' access rights, password rotation policies, and access history. The primary goals were to assess the situation and implement a solution that could be efficient and continue to comply with rigid financial industry regulations (such as SOX, PCI DSS, and GLBA).

“DCI is a very technical business, with many people requiring access to sensitive areas. Additionally, the majority of our 1,300+ users require multiple access rules and policies that impact our entire IT environment including, what specific areas can be accessed or when, during a specified time of day. Managing these policies manually was very time consuming and required cumbersome report consolidation. We agreed that we needed a solution to securely automate privileged access, reporting, and password management lifecycles across multi-platforms,” said Martinson.

DCI selected a PIM solution following months of extensive review and analysis. The company sited regulatory compliance, ease of deployment, and scalability and flexibility of solution as the main purchase points. With this solution, DCI is able to:

• Automate the management of users/applications with authorized access to critical data
• Automatically purge unused user IDs and access rights from the system
• Generate reports to demonstrate compliance with a wide range of federal regulations

The Demand of Compliance Versus the Ease of Open Source

Ah, open source software! What better way for developers and administrators to reduce costs and speed the deployment of new functionality across the extended enterprise? If we are talking about least privilege, then we should revisit a subject bought up in Chapter 5 and that is Sudo.

What better way for IT admins to eliminate the proliferation of the root password throughout IT and development organizations? What better alternative to using root accounts to perform routine maintenance on UNIX and Linux systems? Just grant users the proper permissions in the local Sudoers files and you're in business. Oh, and the utility is free. What's not to love?

Now consider the compliance implications. Using Sudo for privilege management is like using a fish net to protect the fish in your pond from escaping. While it will catch most, there will always be holes big enough for something to escape.

As it turns out, deploying Sudo isn't as trouble-free as it may seem. Sure, Sudo is a far better practice than the rampant use of root, but that's not exactly the bar against which any security professional should be measuring internal IT processes.

One of the problems with Sudo is the ease with which it can be deployed haphazardly, without a lot of forethought, to address a particular day's privilege challenges. Mary needs to manage the office printers. John needs to reset passwords for people in the business unit he supports. Janice needs to perform server maintenance. The admin that restricts access to the root password without a ready alternative will become popular indeed, and not in a good way.

Enter Sudo as that ready alternative. Privileges can be granted quickly, independently, and with minimal effort. But before you know it, one privilege request processed on top of another leads to a hodgepodge of poorly maintained Sudoer files, all hosted on local servers with local log files and no audit trail to speak of. Better than the proliferation of the root password? Sure, but by how much?

Now consider more compliance implications. Many companies have standard compliance policies for Sudo, most of which require routine inspections of each Sudoer file to ensure that permissions granted to each user are appropriate. Not an easy task when the server count is in the hundreds or more. Many organizations find that a spot check of Sudoer files reveals permissions for users who have long since left the company—a guaranteed audit violation.

In reality, there is no substitute to carefully creating a privilege delegation strategy and designing a rollout plan that ensures security and compliance while minimizing the impact on users. While this can be done with Sudo just as it can with commercial tools, the fact is that commercial tools provide better guardrails around deployment and more sophisticated native features, such as encrypted logging and centralized policy stores, for enabling security protections and ease of maintenance. And the most robust ones provide an easy path to proving compliance, a challenge most administrators of Sudo deployments find all too formidable.

Walk on the Wild Side of a Failed Audit

We couldn't resist the homage to classic rock. Hopefully, you are familiar with the Lou Reed classic “Walk on the Wild Side” off of his 1972 Transformer album. If not, then check it out if you want a slice of New York in the late 1960s and early 1970s.

The reason we are using it as a metaphor in our chapter on compliance and security is because when we were talking with an IT auditor about compliance and failed audits in July 2011, this tune was playing in the background. Lou was singing “everybody had to pay and pay; a hustle here and a hustle there...hey babe, take a walk on the wild side” while we chatted about the right, wrong, and wild side of the dreaded audit.

• The Right Side: “You should have seen him go go go”—If you start by leveraging the resources available at SANS and ISACA, then you will be able to identify specific regulations pertinent to your audit requirements and what is necessary to ensure passing.
• The Wrong Side: “Everybody had to pay and pay”—Ignorance is not an effective defense of against a failed audit. Failed audits are becoming much more commonplace as technology facilitates better review of identity and access entitlements as well as user and administrator activities.
• The Wild Side: “A hustle here and a hustle there”—Now we enter the danger zone. Implementing partial solutions or still relying on “trusted users/administrators” can deliver mixed results when the auditors do their thing. Decisions like using open source versus licensed software or if logging constitutes protection can have dramatic differences from one auditor to the next.

Ultimately, in a discussion on compliance and security, it is important to recognize that at the intersection point is the auditor. Most of your decisions regarding both security and compliance will be predicated to some degree on how you perceive your auditor will react and then consciously choose to be on the right, wrong, or wild side.

Case Study: Satisfying Auditing Challenges

The University of Texas MD Anderson Cancer Center was created by the Texas Legislature in 1941 as a world-leading institution for cancer treatment and care. In 2008 alone, nearly 1,000,000 people turned to MD Anderson for cancer care in the form of surgery, chemotherapy, radiation therapy, and immunotherapy. Four out of the past six years, MD Anderson has ranked the number one in cancer care in the “America's Best Hospitals” survey published by US News & World Report.

MD Anderson's world-famous cancer treatment facilities are backed by a powerful and secure UNIX network infrastructure that provides support to a faculty and staff of both MDs and PhDs numbering over 20,000. This network, which hosts in excess of 500 UNIX servers, houses confidential patient information and several critical financial and healthcare applications, all key to providing the level of service and expertise associated with MD Anderson.

With the HIPAA requirement deadlines quickly approaching, and critical patient care dependent on the reliability of network computer systems, the University of Texas MD Anderson Cancer Center, located in Houston, needed to find a secure way to manage and protect its IT infrastructure. Through a combination of inside systems expertise and outside software technology, security was able to not only meet current demands, but also prepare for future threats and requirements.

When David Nester came on board as the UNIX security architect at MD Anderson, he was charged with developing UNIX and web security for the institution's massive information network. Of particular importance for Nester were access control, authorization, root delegation, and auditing capabilities of the network. “The previous UNIX environment was not centralized, and it was difficult to understand what activities were being performed at each machine,” says Nester. “I was assigned the challenge of placing controls back into the hands of our system administrators.”

Nester knew that a strong IT infrastructure was vital to supporting the patient care services and overall mission of the institution. “The ability of our systems to operate effectively can substantially affect the critical medical care provided here at MD Anderson,” says Nester. “If something were to go wrong, we would not have the luxury of time because people's lives are at stake.”

MD Anderson selected a least privilege solution to sit on top of their UNIX servers and provide security and accountability by enabling systems administrators to delegate administrative privileges and authorization without disclosing the powerful root password. Other administrative tasks such as system programs mounting, performing backups, and adding new users can be delegated to individuals or groups at a granular level, thus reducing the risk of intentional or accidental damage. Additionally, it also grants granular user access to files, directories, and third-party applications and accounts (such as Oracle, SAP, and so forth).

Nester admits that he has noticed a significant correlation between the security enhancements provided by their server least privilege solution and return on investment in the form of system reliability. “[Our least privilege solution] allows us to tie the uptime of our environment directly to business productivity,” says Nester.

In addition to granting delegated access across their network, it provided extensive auditing and logging features. This functionality provides a full audit trail of all actions occurring in important accounts such as root. Maintaining a complete audit trail of administrative actions now provides system administrators at MD Anderson with the ability to track exactly which actions have been undertaken by which users, when, and on which machines.

Nester was particularly impressed with the off-site logging capabilities of the solution as well. Prior to implementing the software, logging and auditing capabilities at MD Anderson were maintained on the individual machines for which the activity was being recorded. Nester says this was a significant security risk because it allowed hackers or internal users to manipulate records or erase evidence of system activity. “No other application allows you to have the audit replay ability like PowerBroker for Servers,” says Nester. “Now I don't have to retrieve logs from each individual machine. The centralization is really powerful and cost effective.”

Paralleling other healthcare institutions, MD Anderson is also faced with the daunting task of ensuring that all critical systems are HIPAA–compliant. Enacted by the US Congress in 1996, HIPAA establishes national standards intended to ensure privacy in electronic healthcare transactions. Security architects at MD Anderson have taken the opportunities provided by HIPAA to make sure their systems maintain all appropriate levels of security and privacy, while balancing security, productivity, and compliance.

Balancing Security, Productivity, and Compliance

If you regularly incorporate least privilege into your GRC discussions as you've seen in the MD Anderson case study, you will find that, when it comes time for the auditors to do their job, it will go much smoother than without.

As new security breaches continue to come to light almost daily, stricter compliance requirements are being put into place. Access control rules are being regulated and IT configurations are being mandated. The debate of security versus usability continues to be a hot topic, and the bottom line is always at the forefront of every decision. What can an enterprise do to be sure a costly audit won't derail the company? Follow these three steps to good IT health:

1. Start by eliminating administrator rights for all users who don't need them for tasks directly related to their job description thus removing the ability for inside data breaches (whether intentional, accidental, or indirect).
2. Have clear and separate duties for each user. With distinctive objectives about what each employee requires in order to do their respective jobs, the privileges allowed to each person will accurately correspond to the amount of privileges they need.
3. Don't immediately expect a “pass” on your first audit after implementing a least privilege solution. You cannot implement a least privilege policy and assume you're compliant. You need to continually audit privileges as work roles, new employees, and new data emerge and change.

Human nature once again is at play, so constant diligence is required across the extended enterprise. Implementing some form of identity and access management infrastructure isn't just a “nice to have.” It's necessary. Once we accept this and make a place for it in our enterprises, the result will be a healthier, more secure, and more cost-effective IT environment

The Tradeoffs Between Security and Productivity

Since it's hard to analyze the tradeoffs between security and productivity, IT organizations can fall back on gut feel, rules of thumb, and past practices in making these decisions. The easiest answer is frequently to just follow the rules and regulations so you remain in compliance with industry regulations or current policies. As a result, compliance becomes a substitute for security. But are they really equal? Does being in compliance mean you have a secure IT environment?

We see a number of major challenges when staying in compliance is substituted for a well-thought-out IT security strategy. First, compliance-oriented policies tend to be backward–looking, making sure that past problems don't reoccur but do little to help anticipate new threats. Compliance also focuses on process rather than results, in many cases with a heavy emphasis on record keeping. And focusing on compliance can stifle innovation because new security techniques are needed to deal with new technical approaches.

Now don't get us wrong. Staying in compliance is a good thing to do. It's essential in many businesses. And the rigor that comes with staying in compliance is a necessary element of good security strategy. Maintaining SAS 70 Type II compliance, for example, lets everyone in the organization know that key processes are important and gives everyone an independent perspective of whether an organization is doing what they say they are going to do. And while it's often joked about, a compliance mandate often pays the bills for real security. If that's what it takes to upgrade key infrastructure, that's good too.

But it's clear that compliance doesn't equal good security. According to Jim Jaeger, director of DoD & Commercial Cyber Solutions for General Dynamics Advanced Information Systems, “virtually every breach we investigate, that company has been certified as being compliant within the last year.” And at its worst, Jaeger sees that “these compliance regimes give people an incredible false sense of security.”

So while compliance is a great way set a minimum bar for security policies, you still need to take into account the real value of your data and the threats that face your industry and particular business. So we are back to having to do that difficult analysis on the real costs and benefits of security. And while there is no simple answer, there may be a different way to frame the problem. Can you implement security in a way that enhances productivity? Wouldn't that be great! The good news is that implementing a PIM solution can mitigate most of these trade-offs.

So, be wary of how proud your CEO can be with a bit of paper saying your company has met compliance requirements. As we've shown repeatedly in this chapter, the majority of data breaches were from companies who were compliant. Clearly the intersection of productivity, security, and compliance is a delicate balance that requires constant diligence, and of course that starts with the implementation of least privilege.

Weighing In

The balance between governance, compliance, and risk has always been a conversation that merits significant attention. In the world of IT security, all three of those are topics that must be addressed. Without one, the others will ultimately fail; therefore, appropriate time should be spent on the importance of each. The chapter outlined a lot of these, but let's hear opinions from our experts:

Secure Sam:

Governance is a crucial part of enterprise security. The rules and mandates must be decided on, and each of those must be enforced. This can be a very tricky thing—especially when geographical locations and political opinions get in the way. Particularly when it comes to least privilege, the concept of managing privileged access for people in different areas and with different perceptions of what they should be allowed to do can be complicated. Both from a logistical standpoint as well as from the stance that you don't want to completely upset all employees, there are definitely things to consider when governing least privilege in an organization's security plan. Being able to monitor and manage privileged identities, however, more than makes up for the challenges. The key is to follow the steps to good governance outlined—specifically the first one listed. It's vital to make changes in privileged access using a central policy change. Changing it centrally and then having it propagated and enforced across an extended enterprise solves the problem of geographic stipulations.

Least Privilege Lucy:

As the chapter pointed out, risk is a very subjective subject. The thing is, however, that certain behaviors and patterns always pose a threat and a risk to any given enterprise. For example, allowing all users access to sensitive data. This will always put your company at risk for a data breach. If the insider using his credentials to access said information doesn't manipulate or steal data, someone from the outside can easily hijack those credentials and take care of the crime instead. Therefore, to reduce the risk of such a catastrophic IT event, appropriate credential management is necessary. With changing job descriptions, new hires, and employees who either leave or are dismissed, functions change frequently. In order to mitigate these changes and avoid potential data travesties, managing privileges is crucial.

Compliance Carl:

I've said it before and I'll say it again—compliance isn't just about avoiding government fines. It's about protecting sensitive information and data within any given organization. Because different industries have different types of information and varying standards of security, there are multiple mandates that indicate how compliance is measured. Some of them, such as HIPAA, are based on protecting personal data with technical controls. Others, like PCI DSS, enhance payment security to help consumers avoid identity theft. The important thing to remember with these mandates is that they ultimately make your organization secure. The best way to do this is through a least privilege solution. Specifically, limiting access to sensitive IT resources while controlling and monitoring the use of data.