Business Executives, Technologists, and Auditors Need Least Privilege

“Privileged Identity Management (PIM) is part of the overall identity and access management (IAM) family of technologies, which together provide corporations mechanisms to govern the who, what, where, when and why of secure access management and provisioning.”

—Sally Hudson, International Data Corporation

At first glance, one might think that combining least privilege with business executives, IT professionals, and auditors would be impossible given the significant differences in points of view and motivations. Upon closer look, however, this idea makes perfect sense, because it combines security and productivity with rank and privilege.

Indeed, this is not a compromise between the three segmented players, but it makes these forces interdependent and dynamic. In other words, least privilege becomes the force by which each employee is empowered to do what they need to do, when they need to do it. It ensures that they can't abuse their rank, and do what they shouldn't be doing, at a time when the company least expects it.

In Chapter 1, we introduced the concept of these three business roles as “Insider Heroes:”

• Secure Sam—Sam is your typical Chief Security Officer (CSO) or IT manager responsible for the governance, compliance, and security of the information assets of your corporation.
• Least Privilege Lucy—Lucy is your average network or systems administrator responsible for administrating systems and/or infrastructure, be they physical, virtual, or cloud-based systems.
• Compliance Carl—Carl is your classic auditor responsible for regulatory compliance reporting and auditing of IT policies for enforcement of corporate governance.

These insider heroes deal with the harsh realities of rank and privilege on a daily basis as they set about to accomplish their responsibilities within the perimeter of today's extended enterprise. They also have to deal with the differences between rank and privilege, being careful not to collapse these two ideas together.

Remember that we discussed rank as the role or position one has inside an organization, while privilege is the level of authorization that person has to specific IT resources under specific circumstances. Trusted insiders tend to want to collapse rank and privilege into one concept, which inherently is why good people get triggered to do bad things. Perhaps it's something about the hubris of human nature to assume that the higher the rank we achieve, the more competent and knowledgeable we are. Indeed, this is exactly where complacency can set in—when we achieve a certain rank, we can so often drift into comfort zones that keep us insulated from the need to continuously educate ourselves.

Sam constantly has to deal with everyone demanding administrator access rights (privilege) to specific IT resources, especially their desktops. It always seems that the higher placed the titles and place in the organization chart (rank), the more vigorous the demand. What's interesting about Sam's dilemma is that the requestor usually doesn't know why they are asking for admin rights. They just believe that since their title is what it is, they should have omnipotent access to said resource, in spite of the fact that they might not be competent to do so.

Lucy has to manage the variety of privileges required to deal with IT issues across such a diverse set of platforms as Windows desktops, physical servers (at least four different operating systems and every permutation of version and patch), virtual servers (at least three operating systems and every permutation of Hypervisor manager), infrastructure (at least four different databases, hundreds of legacy applications, and potentially thousands to hundreds of thousands of desktop data requirements), and of course the new rage of cloud migration (public, private, and hybrid). Her persona requires a fluid level of privilege tied to specific policy and circumstance despite her fixed role (rank) in the enterprise.

Carl is a unique persona. He usually sees the world in black and white. For Carl, access to IT resources (privilege) is to be measured against his interpretation of the germane regulations and therefore will interrogate entitlement reports (rank) accordingly in order to determine compliance or the need for remediation.

Let's explore each of these insider heroes in more depth using examples from the global news and your peer community, to further illustrate how confusing rank and privilege can cause Good People to do Bad Things.

Secure Sam Examined Closer

Ever see how a duck glides through water? It looks effortless from the surface, but beneath the waterline is a different story. In reality, the poor duck is paddling his webbed feet feverishly in order to move about. Now you know what it's like to be a CSO, or IT manager responsible for information security, managing today's enterprise security requirements. One of these, or some variation thereof, is ultimately the title Secure Sam holds in your organization. Now you know what his day is like.

At face value, the successful Secure Sam (Figure 3-1) projects an air of calm, cool, and collected control over the enterprise governance, risk, and compliance mitigation requirements. Behind the scenes, he is a whirling dervish of politician meets technician meets mind reader meets soothsayer all served up with one great big stress sandwich.

The successful Secure Sam understands the need for:

Figure 3-1. Secure Sam

• Constant diligence against insider threats as well as attack from outsiders
• Relentless education on new technologies and techniques to control access to all information assets
• Ever-present knowledge of industry and competitive breaches published in the press and on the Internet
• Real-time change control for corporate policy enforcement at every IT endpoint
• On-demand entitlement and audit capabilities for when the CEO, CFO, or auditor asks for specific reports
• A vision of what is possible in his role, when all of the above are competently handled.

The common pitfalls a Secure Sam faces can include:

• Focuses only on outsider threats and over-spend budgets on perimeter security
• Relies solely on trust and written corporate policies for employee use of information technology resources
• Assumes that HR is for hiring and firing, and has little to offer him in terms of insight about how to manage his network
• Remains blissfully ignorant of the impact felt by peer companies and competitors when insiders attack
• Secretly likes the adrenaline rush of fighting outsiders, to the point he hasn't yet recognized the internal threat
• Uses policy changes as job security because his team is the only one with the knowledge of what needs to be done
• Takes two to four weeks for custom reporting when requested

Secure Sam in the News

How much press will we have to endure on the significant problems created by WikiLeaks and the public lynching of those who perpetrate these leaks before we realize that if you give someone an inch (excessive admin rights), they will take a mile (misuse that privilege)?

To use a metaphor: If I sneeze, will you give me a tissue and send me on my way? Will you give me cold medicine? How about allergy medicine? Without knowing the cause, the disease, then reacting to the sneeze, the symptom, will ultimately result in a response that may be over-kill or under-kill.

Some journalists do get it. Mike Martin at TechNewsWorld published an insightful story titled WikiLeaks Wrangling May Be Escalating Into Cyberwar. He rightly points out “the WikiLeaks controversy could be devolving into a wiki-war.”

So why is it that every journalist seems to be focused on the symptom, the leak, instead of the disease, the “intentional misuse of privilege” caused by “excess admin rights?”

An article posted on eWeek.com on January 6, 2011 proclaimed “Now, another train is coming and I'm telling you right now, it's headed in your direction. WikiLeaks has brought new meaning to the concept of insider threat by providing a convenient vehicle to empower staff to quickly and instantly hand over privileged information.

Acknowledging the WikiLeaks phenomenon, the important lesson is: your company could be next. Given the volume of leaks WikiLeaks has on private companies, if you work for a Global 2000 corporation, there's a good chance WikiLeaks already has some dirt.”

Why Sam Should Know Your Business Partner Might Be Your Weakest Link

The drive for greater company-wide efficiencies and overall cost savings has made the reality of outsourcing a significant part of 21st century business practices. But as Secure Sam has come to learn the hard way, by handing over your data and network access to third parties, no matter how trustworthy, your enterprise could be at risk of suffering a serious and damaging data leak.

According to a new study from the Ponemon Institute, 39 percent of data breaches involve third-party outsourcers. Many companies experienced this problem first-hand when a recent, very highly publicized data breach by e-mail marketing service provider, Epsilon, affected some of the nation's largest banks, and technology and retail brands. This specific breach only involved the release of names and e-mail addresses. However, exposure of more confidential information, traced back to outside vendors, is occurring on a much more alarmingly frequent basis.

The lesson we can all learn here is that companies not only have to monitor their own security, but also that of their associates and vendors. While it is important to provide the information and access necessary for third-party resources to do their jobs, at the same time it's irresponsible to allow vendors free reign over sensitive data or network assets. An all-or-nothing approach to granting users access doesn't work here. Effective PIM coupled with comprehensive knowledge of your partners' and vendors' security policies and practices are the best way to safeguard your company's most valued asset.

Sam Must Arbitrate Tablets at the Office as Friend or Foe

A decision that Secure Sam has to weigh in on now that he wouldn't have had to deal with just two or three years ago is the proliferation of personal tablets and mobile computing devices.

According to Gartner, worldwide media tablet spending is projected to reach $29.4 billion in 2011, up from $9.6 billion in 2010. Gartner also predicts that by 2013, 80 percent of the workforce will be using tablet devices. Whether employees are being issued tablets by their employers, or bringing in their personal devices, embracing tablet computers is very attractive for many enterprises looking to keep their employees connected, while reducing costs.

But mobile malware threats are on the rise. According to Andrew Hickey at CRN in February 2011, “mobile device platforms have become the latest and greatest attack point as mobile device security threats rose to new heights in 2010's fourth quarter and will continue in 2011...” The May 2011 detection of a Mac OS “crime kit” could also heavily impact iPad users and serves as an indicator of what we can potentially see in the future as tablet adoption continues to grow. Presently, most tablet end points are relatively unsecured, which is cause for concern as these devices connect to the corporate network. Data storage on untrusted end points must therefore be heavily weighed and controlled. There should always be a preference for enterprise data to remain on corporate assets, with remote access capabilities limited to secure, encrypted VPN connections, else the potential for misuse of privilege will occur.

Adopting smartphone security best practices will help alleviate some of the headaches associated with tablets in your network environment. It's also important to employ stringent access controls and make sure your end users only have access to what they need to in order to do their jobs.

Least Privilege Lucy Examined Closer

Depending on the size of your company, Lucy (Figure 3-2) could be 1 “jack of all trades” or 1 of 100 specialists each focused on a specific operating system, platform, geography, or business unit. The unifying characteristics include one part technical wizard, one part fire fighter, one part customer service representative, one part project manager, and one part CSI forensic analyst.

Least Privilege Lucy is the first person called whenever something technical needs to be done, from deploying a new desktop, physical server, virtual server, or application in the cloud, to upgrading software versions and patches, to rebuilding damaged systems courtesy of the latest malware attack or user “accidentally” doing something inappropriate. And let's not forget that the CEO will also call her instead of picking up an instruction manual every time he hits the wrong key on his BlackBerry.

The successful Least Privilege Lucy understands the need for:

Figure 3-2. Least Privilege Lucy

• Policy creation; monitoring and management of each role in the organization to ensure against over-privileged” or under-privileged users
• Real-time brokering of appropriate privileges across platforms based on those polices
• Tight integration with existing trusted repositories for policy and credential management (such as MS Active Directory, Group Policy, Oracle database, and so forth)
• A single privilege identity footprint for desktop, physical, and virtual servers and cloud deployment that can adapt to situations based on policies evoked
• Real-time logging for remediation and reporting
• Insight into what she would do with the cost savings created from not having to fight fires caused by over- or under-privileged users jamming her phone line all day

The common pitfalls or traits a Least Privilege Lucy might enable:

• A one-size-fits-all approach to user authorization levels across all platforms accordingly (that is, all desktops use policy one, while all virtual servers use policy two)
• Require only managers or help desk personal to have admin rights to be invoked personally (that is, walk over and type in a password) for every request for elevated permissions
• Assume they can keep up with the level of change required to meet corporate governance and regulatory changes through manual programming
• Remain blissfully ignorant of the impact felt by peer companies and competitors when insiders attack
• Use personal technical expertise as job security because her team is the only one with the knowledge of what needs to be done
• Addiction to fighting fires, because it gives her a sense of importance and allows her to be visible in the organization
• Taking 2-4 weeks for every request not made by a senior executive who will usually get a response within 24 hours

Least Privilege Lucy Is Disgruntled Dave Before He Became Disgruntled

If you haven't figured it out yet, yes, Least Privilege Lucy is actually the same persona as Disgruntled Dave introduced earlier, but with a significant difference. Dave has had something that upset him to the point where he has decided to use his technical expertise to intentionally misuse his privilege and perpetrate damage (electronically or financially), while Lucy still adheres to the values of only doing right by the company. Another aspect of that difference is intent and action:

• Intent—Lucy's intent is to use authorizations and privileges as befit the resource or situation, while Dave's intent is to misuse his privilege to intentionally steal, modify, or delete data or plant malware that will activate at some time after he leaves.
• Action—Lucy's actions establish a pattern of doing what is necessary in a given situation, while Dave's actions exhibit a covert behavior that may even go unrecognized until the damage is done and he is already in a non-extradition country sipping on a daiquiri and spending the $100 million he made selling your customer files to the competition.

When Lucy Was In Fact David Not Dave

In the press, you will find mostly articles about the Disgruntled Dave persona versus Least Privileged Lucy because most news that attracts viewers is of the doom, gloom, and tragedy perspective. So looking at a case study, we find a great example in David Nester at M.D. Anderson. When David came on board as the Unix security architect at M.D. 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 in to the hands of our system administrators.”

David 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 M.D. Anderson,” says Nester. “If something were to go wrong, we would not have the luxury of time because people's lives are at stake.” So you will find that David is much more of a Least Privilege Lucy (in male form) then he is a Disgruntled Dave.

Lucy's Worst Nightmare: “Your Password Is What?”

Who's on first? What's on second? I don't know's on third, and your password is Password? HUH?!? Yep, it seems like the classic Abbott and Costello baseball sketch is now Least Privilege Lucy's worst nightmare when it comes to password management. According to a recent Wall Street Journal article on The Top 50 Gawker Media Passwords, the average user seems to either have a relaxed sense of security, a love for Abbott and Costello-like humor, or are just lazy when it comes to identity-related security. It's no wonder the average hacker can break into sites with relative ease.

Now translate that into what happens across your enterprise when just one employee uses this protocol for personal passwords on corporate resources, which may contain proprietary and/or confidential information worth stealing, selling, or vandalizing. Scared yet? You should be!

Just implementing password protocols is not enough in today's ever-changing environment. The real solution should involve the elimination of users owning their own passwords and implement an automated password management solution. This allows users to “pull credentials” when required from a centralized policy-managed repository, instead of relying on individual credentials being “pushed” by the user.

These solutions create, manage, and remove random machine-generated passwords. These passwords are then transparently used by the requesting resource without the user ever knowing the password or login credential. Therefore, the likelihood of someone misplacing, loaning out, or hacking a password is greatly diminished.

Lucy Knows that Sharing Isn't Always Caring

In kindergarten, we all learned an important lesson: how to share. Some people, as they grew up, seem to have taken this concept a little too far, with no real consideration for possible consequences. I'm not trying to undermine the importance of sharing as a general rule, but let's just take a quick look at how sharing has “helped” in the recent past.

Vodafone. We've talked about it before, but it's the perfect example of how sharing isn't always the way to go. They experienced a breach in early 2011 that affected private customer data. This information was leaked as a result of the misuse of a password. More than likely, the damage that password caused was a result of it being sold or given to someone else. The consequences of this breach were severe: fines to be paid, fired employees, and a whole unnecessary mess to be cleaned up. All because someone was loose with their password.

Every user in every organization must have their own unique credentials. Every time. Sure, it can be easier to let someone use your password. Yes, they would probably end up with privileged access if they had called the help desk anyway. But at what cost does sharing become acceptable? Organizations need not risk sensitive information for laziness.

Companies also need to have the ability to track and log the use of those passwords. Granular details about when someone logged in, the keystrokes they performed, and the information they accessed is the key to correct governance, as well as fast response time if a breach were to occur. Without a system in place to ensure the proper people are using their passwords appropriately, all of your efforts will have been for naught.

We think it's safe to say that sharing is not always a benefit. Should we take it too far and stop teaching children to share? No. Should we stop teaching adults with the keys to their enterprises' kingdom to share? Absolutely.

Compliance Carl Examined Closer

This persona is about dualities: part technical analyst, part financial analyst. At his best, Carl is part Sherlock Holmes and part Judge Judy. At his worst, he is part Homer Simpson and part Harvey Two-Face.

Figure 3-3. Compliance Carl

Most business and IT executives alike tremble when Compliance Carl (Figure 3-3) comes around because they know their practices and systems will be scrutinized. Part of this generalized fear is the black and white nature of a compliance audit. At the end, they will either pass or fail. A failing mark can mean anything from small policy changes required to massive financial fines. Because these decisions are almost solely at the discretion of the type of Compliance Carl you have in your organization, the difference between the “Holmes/Judy” version can be dramatically different than the “Simpson/Two-face” version.

The successful Compliance Carl understands the need for:

• Accreditation with certifications such as Certified Information Systems Auditor (CISA) or Certified Information Systems Security Professional (CISSP)
• Ongoing education on best practices for information technology audit from such organizations as ISACA
• An objective point of view relying on quantitative and qualify-able data directly measured to governance or regulatory standards
• Thorough documentation on entitlements (that is, user authorizations) across all platforms physical, virtual, and cloud
• Ongoing education and refreshers on regulatory mandates and how they relate to your industry or organization.

The common pitfalls a Compliance Carl faces can include:

• A strong IT background doesn't necessarily make for a strong IT auditor as the disciplines are completely different without proper training and accreditation
• Assuming that compliance is a project and not a process that requires ongoing diligence for meeting governance and regulatory requirements
• Believing that once a regulation is published, it will not change and failing to implement any form of regulatory change communication alerting system
• Using subjectivity and personal bias or high-level trend data instead of detailed reports to determine compliance
• Being overwhelmed by techno-jargon to the point of being misled from compliance risks
• Acting like Harvey Two-Face in Batman, using a coin-flip for every decision made

Compliance Carl in the News

What is sweet revenge to the business and IT executive is when they read about the IT auditor who fell under the scrutiny of the press and questions of favoritism arise. In June 2010, CBS News Canada reported that an “Alberta IT Auditor Appeared In YouTube Promo.” It went on to report that “Patrick Dunnigan, an information technology auditor, is shown in the infomercial extolling the virtues of software from New York City company Application Security Incorporated (ASI) purchased by the Alberta auditor general last year. Dunnigan helped choose the software for the office.”

The article went on to say “Both the company and the auditor general's office say Dunnigan was not paid to take part in the video nor was the software purchase price reduced in return for his appearance. However, assistant auditor general Ed Ryan said the promotion was not authorized by anyone in the office and an investigation is now underway to determine if Dunnigan broke the code of conduct.” Here is an example where a Compliance Carl came under scrutiny for ethics and casts a shadow of doubt on credibility.

This is a real-life example of why Carl is the most tenuous character here. His capacity to hit the common pitfalls and be another “good person doing a bad thing” or the errant ability to confuse rank and privilege will lead him to underestimate insider threats relative to external threats as the weakest link.

Compliance Carl in the Blogosphere

If you frequent the blogosphere on the Internet, then you can also find lots of opinions on IT auditors: the good, the bad, and the ugly. One of the favorite passages we found was on theitauditor.com who, in June 2010, wrote:

“Another place where blame lies is with audit managers who are more concerned with maintaining the contract than providing the client with the ability to decide which issues are significant enough to worry about. It is my belief that all weaknesses found during an audit should be communicated to the client in writing in some form. I am not promoting the idea that all findings should make it into the final report, or even that all findings are reportable. I am saying that in daily interactions, status meetings or briefings the client should be presented a list of every single finding that was observed, this provides legal/regulatory coverage for the auditors, and it allows the client to make the decision to address or ignore each issue individually. The way I see it, my integrity as a professional is more important than the contract that I am working under. If my client is intimidated by a long list of findings, they can either keep me around to help them correct the situation or they can continue to bury their head in the sand and either terminate my contract or I may refuse to return upon the end of that contract. Auditors are a resource that should be used to help; if we are seen as adversaries to the system admins or management our work will not add any value to their processes.”

Why McAfee Knows that Carl Still Looks Outside the Perimeter Instead of Within

To add fuel to Compliance Carl's list of daily action items, you may have already seen the results of a 1,000+-person survey conducted recently by McAfee and wrapped up in a crisp report. They estimate that businesses lost more than $1 trillion in 2008 as a result of data leaks. With the help of SAIC and international research firm Vanson Bourne, the company has added some meaty authority to what would otherwise be seen as a vendor-biased report.

According to the report, the most popular methods of protecting sensitive data are anti-virus, firewalls, and intrusion detection/prevention systems, which are implemented by more than four in five organizations, perhaps followed by deep packet inspections, which was reported by two-thirds of respondents. It figures that all of these are outward-facing security mechanisms primarily intended to prevent malicious hackers, viruses, and worms. Therein lies the problem.

Surveys from the Computer Security Institute (CSI)/FBI research team also show that most organizations believe the majority of their security risks are from external threats, yet actual analysis of real breaches shows that internal threats outweigh external ones. AT the 2011 RSA show we remember one of our execs was telling a reporter that people are finally realizing that their risks are from within. This was also a big story during the recession, where many organizations were bracing themselves for massive layoffs that were creating armies of angry, unemployed, ex-employees. Before the recession, reports like those from the CSI were trying to change our minds to realize where our focus should be—demonstrating the internal problem. Therein lies the value of a least privilege solution to help prevent good people (insiders) from doing bad things (steal or harm data).

And yet, after all that, the industry hasn't caught on. What else could anyone possibly do to erase this perspective that the vast majority of risk comes from over-glorified hackers?

Why Carl Just Doesn't Always Realize the Outside Is Also the Inside on the Outside for Today's Mobile Workers

An auditor's nightmare is trying to keep track of remote users and how to keep track of their potential or capacity for generating compliance or governance issues. According to a Runzheimer survey released in April 2011, 45 percent of today's workforce is mobile. For companies, having such an extensive number of remote employees can provide a number of great advantages, but it has plenty of downsides, too.

Among the top concerns of enterprise executives is being able to effectively manage the mobile workforce to ensure maximum productivity and control the distribution of data. IT managers have indicated that it is a lot more challenging to keep remote employees informed of security policies and initiatives. On top of that, mobile workers are significantly more likely to access dangerous content than those in the office. Additionally, when employees bring their own personal mobile devices into the office network fray, security management can seem like a nightmare.

But it's not all bad. By combining the deployment of up-to-date security solutions with instituting best practices and compliance standards, organizations have a golden opportunity to capitalize on all of the positive aspects of a mobile workforce, while minimizing the potential for data losses, breaches, or even worse. Part of companies' mobile security strategy should also include implementing a least privilege solution, ensuring that remote workers can only access the data and perform the computing functions needed to do their jobs. Employees can't lose what they can't access.

So, now we have a better idea of the role least privilege can play in the lives of the business manager, represented by Sam, the IT admin, represented by Lucy, and the compliance auditor, represented by Carl. We've illustrated how it represents a common thread between their roles despite their rank. Let's now return to our overarching concern in this book—the vagaries of human nature—and uncover other areas where this problem occurs.

The Problem Still Exists Between the Keyboard and Chair

There Is No Patch For Stupidity. No, we're not talking about a Boy or Girl Scout patch (or merit badge) now awarded for making dumb errors with information technology at work. We're referring to the ever-present vendor tech support cry of “just install the patch” whenever something goes wrong.

In this case, the patch is a “fix” for the buggy software that invariably caused some loss of data and/or productivity. But what happens when the error is human error? Unfortunately, there are no “patches” for that, unless you count getting rid of said employee and replacing him with someone smarter. A common cry of helps desk personnel worldwide is PEBKAC! If you don't know what that means, you're not alone. We had to look up that acronym as well to discover it meant “Problem Exists Between Keyboard and Chair.”

Accidents happen, and if you are still providing excessive privileges to your desktop/laptop users or server/network/database/cloud/virtual administrators, then you are at risk of the accidental misuse of privilege. Sometimes, these accidents can cause harm that is newsworthy. In this instance, you not only have to deal with the problems created, but also the public fallout that follows from the press and blogosphere.

First, you need to eliminate admin rights on Windows desktops and root privileges off of servers, then you implement a PIM solution to create a least privilege environment such that no one will have enough permission to cause harm if they misuse their privileges. In this way, you can mitigate the severity of potential user stupidity and not have to deal with the help desk crying PEBKAC or fear an unpleasant expose in the Wall Street Journal, local paper, wikileaks.com, or the blogosphere.

The Swiss Cheese Model

We've heard a lot of stories from executives, administrators, and auditors alike on how they tried implementing a least privileged model without a PIM solution. Some folks used scripts to grant/remove administrator rights to the user; others used native settings such as Group Policy Files system and Registry ACL policies. We are not speaking badly of these admins and admittedly, have taken similar steps in the past; and in moderation, these do have a place.

The problem with utilizing this approach to completely address east privilege or least-privileged user accounts (LUA) is that you get into what we refer to as, “The Swiss Cheese Model.” You inherently open up a number of security holes in your enterprise, not to mention risk breaking compatibility with applications, and create an incredible amount of work to maintain these policies and transfer this knowledge to other administrators. Following is an excerpt taken from a Microsoft Knowledge Base on this:

“Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs ACL changes, or you apply the system defaults; you cannot roll back the original ACLs. Changes to the ACL in the %SystemDrive% folder may cause the following scenarios:

• The Recycle Bin no longer functions as designed, and files cannot be recovered.
• A reduction of security that lets a non-administrator view the contents of the administrator's Recycle Bin.
• The failure of user profiles to function as expected.
• A reduction of security that provides interactive users with read access to some or to all user profiles on the system.
• Performance problems when many ACL edits are loaded into a Group Policy object that includes long logon times or repeated restarts of the target system.
• Performance problems, including system slowdowns, every 16 hours or so as Group Policy settings are reapplied.
• Application compatibility problems or application crashes.”

Establishing a least privilege environment or implementing a PIM solution is one of the only ways to solve this. Doing that correctly requires Secure Sam, Least Privilege Lucy, and Compliance Carl to come together.

Security Is a Team Sport and Least Privilege Is the Team Motto

In organizations that aren't sophisticated with measuring the value of risk, getting budget for security can be a tough gig. SC Magazine has an entire blog dedicated to an active running list of publicly known breaches, yet no matter how many examples you show, sometimes the logic that it will never be you is just a wishful-thinking phenomenon that can't be beat.

This is especially problematic when we talk about the risks of an accident, which requires systematic oversight to avoid. It would be so much cheaper and easier to just not make mistakes, right? So just don't screw up!

That must have been what the National Guard was thinking when they released the names, Social Security numbers, pay, and more for the 155th Brigade Combat Team by accident. The data was accidentally posted to an unsecure SharePoint site.

Details of the breach are still unknown, but the National Guard believes it was done inadvertently when uploading files to a new computer system. Let's make the leap and say that it had to be someone with administrative privileges who uploaded the database somewhere it shouldn't have been uploaded.

Who else would have access to 3,000 personal records and be moving that data around to support a new system?

Chances are it was a specific IT administrator that made the mistake, but the company did the right thing in not revealing who that person was. Hopefully, they took responsibility for systematic shortcomings that would allow the mistake of a single individual to cause so much harm.

It's a far cry from the case of the University of North Carolina, who attempted to fire their staff member who was responsible for a server that got breached by hackers. The organization decided this single individual was responsible for the utter and complete lack of security on the server.

Security is a team sport, but unlike soccer, you can't let the opposing team score a single goal. That means you can't let a player that trips lose the game for you.

Weighing In

All too often, the focus of attention can fall to what is going wrong, who was responsible, and what it cost, when information technology security is being discussed. By recognizing the Sams, Lucys, and Carls in your organization, and taking steps to support their activities, you will be investing in a secure and compliant future. This can also greatly limit your “misuse of privilege” liabilities.

We have analyzed numerous examples of these key insider hero personas along with supporting case studies and industry press. The primary lesson learned is understanding the need for separating rank from privilege and the value of implementing IT authorizations accordingly. There are several lessons we can take away from these experiences, but let's hear from our insider heroes:

Secure Sam:

Being the gateway for all users' administrator rights is a heavy responsibility, but one that is necessary in every organization. While not everyone needs the keys to the kingdom, everyone seems to think they do. Approving these privileges to those users who legitimately require them for their job functions is such a crucial step to the security of any organization, and not succumbing to political reasoning is equally important. The bottom line is this: understand the threats and protect all perimeters from threats. It can be so easy to focus on the outsider threat and ignore the very real reality that insider security is just as important. It's even easier to remain blissfully ignorant to attacks around us. It takes constant vigilance to protect precious company assets from both attackers outside the company walls as well as those that exist within the perimeters. It's vital to have the right individual in the role of CSO—one who has a big picture of his role, is willing to remain educated on new technologies, and has integrity with regard to his job and the quality of work he performs. Finding the right Security Sam for each individual enterprise is such a critical decision.

Least Privilege Lucy:

Managing the spectrum of privileges in an equally diverse set of platforms requires the juxtaposition of flexibility and rigidness. Whether it's Windows desktops, physical servers, virtual servers, databases, or cloud-based applications, users need a set of privileges that are specific to their individual jobs. While managing these user rights, you must also take certain things into account. The cost, for example, of IT personnel and the savings that can occur when privileges are appropriately delegated. Also, adapting rights and monitoring privileges for different network situations. Managing enterprise security is not a one-size-fits-all kind of thing, and a thorough analysis of required privileges is a vital exercise in ensuring said security. If users don't need to install software as part of their job function, then they don't need the administrative privileges that allow them to do that. Having the focus to create policies, then manage and monitor those policies, is critical to ensure against the over- and under-privileged user. It's also critical to understand human shortcomings in this process. It's absolutely not possible to manually program and upgrade this level of change while still meeting corporate governance and regulatory mandates. Knowing the proper tools and techniques plays a huge roll in this endeavor. Administration becomes an artifact of good decisions, good tools, and IT education. A lot of the time, this administration also happens in real-time.

Compliance Carl:

Being an auditor in today's ever-changing world of government compliance mandates is a role that is clearly outlined, especially when talking about user privileges. The way I see it, audits are simple: a company is compliant when its users have access to only those IT resources they are required to have access to. This access is based solely on job descriptions and necessity, and is outlined by industry-specific regulations. When analyzing a company for compliance, my assessment is predicated on what the entitlement reports show and whether the enterprise delegates privileges according to the mandates by which they're governed. Often, the difficulties arising from these mandates change and morph over time as the industry and associated regulations also change. Compliance, therefore, is a process and not just an event a corporation prepares for once. This applies to me in my role, as well, as an on-going education of regulations allows my point of view to remain refreshed and relevant. Continual training also allows for more thorough understanding of information technology best practices, as well as providing enough information for thorough audits to be performed. Knowledge is what keeps auditors objective, and it ensures audits rely on data, which is ultimately what keeps enterprises safe from both inside and outside attacks.