Servers Are the Primary Target for Insiders and Hackers Alike
“As in previous years, nearly all data were breached from servers... This continues to be a defining characteristic between data-at-risk incidents and those involving actual compromise.”
—Verizon RISK Team with US Secret Service,
2010 Data Breach Investigation Report
There is a significant distinction between the data on desktops described in the last chapter and the data on the server. To use another metaphor: if misusing desktop privilege can get you into the bank, then misusing server privilege is the equivalent of carte-blanche access to the bank vault. Indeed, in a secure and compliant server environment, end users are not entitled to the root password or even superuser status because organizations can no longer tolerate the security risks posed by intentional, accidental, or indirect misuse of privileges. However, organizations need to provide the admins of the plethora of heterogeneous servers across the enterprise with necessary privileges within specified guidelines to do their job safely.
Without a viable least privilege solution, the most common responses to this problem include sharing the root password, manually managing policy creation and change across each individual account, or being forced to implement inefficient and insecure alternatives. A server-based least privilege solution allows system administrators the ability to delegate privileges and authorization without disclosing the root password on Unix, Linux, and Mac OS X platforms. Additionally, all privileged access is recorded for audits, including keystroke information.
Servers Store the Good Stuff
That's right. Most anything of tangible asset value is most likely stored on a server somewhere within the perimeter of the enterprise. In today's world, that could even mean on a cloud platform, but that still constitutes the “enterprise perimeter.” You probably have separate servers for e-mail, transaction databases, your financial information, and possibly a contact management system—any one of which if compromised could cost your company significantly in tangible expense and lost productivity.
Server Breaches in the News
If you have 1 of 44,000 inactive Mozilla accounts, you may have received a belated Christmas present in December 2010, when the company sent out notifications of a potential leak of their account information. In this case, the company was able to reassure those users there was virtually no possibility of any harm to them.
However, what's interesting about the incident is that one can only presume it ties back to a very specific administrator who on a very specific day and time made a mistake and put the database on the wrong server. Something we see with surprising frequency.
Now put yourself in Mozilla's shoes. If this happened to you, would you know which IT staff was responsible? What would you tell the CEO? Would a witch hunt ensue and how would that impact the department?
The incident highlights once more that the IT staff can and do make terrible mistakes that can cost millions in breaches, notifications, and more. Because IT staff has such deep access to the IT systems themselves, a single logistical mistake can have deep security implications.
The incident highlights why organizations need processes and systems in place that account for the very real possibility of errors by IT staff. In other words, you need to monitor and record the actions of individual administrators and remove blanket root access.
This not only creates accountability for individual staff to not make a mistake in the first place, but avoids the witch hunt when it happens. Employees need to know that if they make mistakes, intentionally or accidentally, the company will know who it was. This, in and of itself, remains the cornerstone of deterring good people from doing bad things. If you know your actions are being recorded, you are more likely to only do what you have been asked to do.
Black Market for Server Data
The economy of cyber crime is all too real—and too enticing. No longer sequestered to dark alleys and seedy bars, data thieves have almost unlimited options to market their ill-gotten wares to potential buyers. What this means to employers and organizations: the temptation to access and “appropriate” sensitive data may be too great for some to resist.
So just how easy is it for cybercriminals to sell data? Shockingly easy.
Although the sale of stolen information often takes place completely underground in secret, closed to the public credit forums, people who want to join these groups can locate them quite easily. Once vetted by forum administrators to ensure they are not from law enforcement, they are invited into the network to market and distribute their wares. According to Sue Walsh at AllSpammedUp.com in July 2009: “The personal information of at least 4 million Britons and a whopping 40 million others, most of whom are Americans, is being bought and sold online. This includes usernames and passwords, credit card details, bank account numbers and more.”
And individuals need not even proactively seek out to divest an employer of sensitive, valuable data. Today, recruiters actively target individuals with local or specific data types, going so far as to even create job postings with such criteria as “an established relationship with local banks” as a prerequisite for crime family consideration.
The ease with which individuals can locate black market buyers of data should scare every employer who provides mid- to low-level access to any type of sensitive information. Like some bizarro-world eBay, many of these markets actually have incentive packages. Competing prices, additional services, free trials, money-back guarantees, and terms and conditions are all offered. Prices for data are qualified like any other commodity: data is priced based on the domain, if the account belongs to a real person, and how popular it is. It can depend on the number of followers, how commercial the niche is, and if the data is real or bot-generated. Prices for online banking and payment systems dependent on account verification.
To make matters worse, the cyber-crime black market, which has traditionally centered on distributing bank and credit-card details stolen from users around the world, has diversified its business model since 2010, and now sells a much broader range of hacked confidential information, including bank credentials, logins, passwords, fake credit cards, and more.
So, while CSOs struggle to combat an ever-evolving crime organization that morphs and changes in a nanosecond, it may be the guy in the cube next to you seeking to supplement his bank account who could exact the most damage to your database.
The Architecture of Server Least Privilege
Implementing a least privilege environment across servers is a bit different than that of desktops. Not just because of the operating system requirements, but the very nature of server administration. Ultimately, an admin needs least privilege instead of full superuser rights on the server or they may:
- Share the root password to perform tasks
- Manually manage policies across disparate Linux systems (such as Red Hat and SuSE)
- Store logs insecurely
- Transmit data unencrypted
Least privilege on a server isn't dissimilar to implementing least privilege on a desktop (see Figure 5-1). The fundamentals of a policy engine, an authorization broker, and a log server still exist. The fundamental difference is that servers tend to be more command-line–driven for administration, while desktops tend to be GUI–driven. Command requests are therefore submitted in order for the least privilege engine to do its magic. It is also important to note that the propensity for error is greater with command-line interfaces than with GUIs due to the possibility of missing parameters or mis-typing specific command qualifiers. So, the need for policy oversight at a keystroke level also becomes a critical success factor when implementing least privilege in server environments. Here is a typical flow:
- A user submits a request to run a command.
- The Master Host validates it against security policy files to either approve or reject it.
- An accepted request is executed on the Run Host as a privileged user.
- All activity is logged and recorded by the Log Servers.
Figure 5-1. Architecture of least privilege
Of WikiLeaks and Servers
We're used to the media getting sidetracked by the content of data breach stories, rather than how they happened. Not surprisingly, then, the WikiLeaks story of early 2011 is no different. With thousands of sensitive diplomatic dispatches to wade through, reporters will likely have enough information to keep them busy for quite some time. Of course, there is a place for this analysis, and yet not for the first time, another opportunity has been lost to pinpoint the weakest link in better securing data.
Although it's likely the White House attempts to identify the weakest link, they also use smokescreens to divert attention from the content of the leaks to those responsible for handling classified information in a surprisingly effective manner.
“...create a ‘security assessment team’ to review the implementation of procedures to safeguard such information, a review to include making sure that no employee has access to information beyond what is necessary to do his or her job effectively.”
By pointing to the management of privileges as the cornerstone of best security practice, they recognize the delicate balance that must be struck between ensuring productivity on the one hand, and security on the other. Bottom line: by leveraging access based on job definition and the privileges that job requires, rather than seniority, organizations will ensure no employee has access to information “beyond what is necessary to do his or her job effectively.” It's worth reiterating that CEOs don't need access to servers running the network, while the IT help desk doesn't need access to the CFO's domain.
However, what the White House doesn't say is just how rife access to information “beyond what is necessary to do his or her job effectively” (over-privilege access) is.
According to a multi-industry survey conducted by the Ponemon Institute in early 2011, 79% of government IT practitioners admitted to having too much access to information resources that aren't pertinent to their role in the organization.
The report's authors rightly say this may be because government organizations cannot keep pace with access change, which happens continuously, and indeed, 75% of those surveyed said that they could not respond quickly enough to such changes. 60% also do not immediately check user requests against security policies before access is approved and assigned.
This speaks of a world in which access, when it is controlled, is still elevated manually by request (or not) from individual users. This leaves network access open to abuse, either through error, or, as is the case with WikiLeaks, from employees set on making mischief.
Far better government organizations consider some kind of automated privilege access lifecycle management, which elevates access, based on the pre-prescribed role definition of each employee, and keeps a log to show who went where, when, and for how long.
This doesn't, by any stretch, prevent data breaches from happening. If someone has privilege access, they can still steal or leak sensitive data. As suggested at the beginning of the chapter, what good least privilege solutions can do, however, is provide a strong deterrent, because good least privilege solution means access is not just leveraged on a “needs must” basis, it is logged too.
In organizations where everyone has full administrator access to the network, determining who might have leaked data would be like looking for a needle in a haystack. For organizations running good least privilege systems, it's possible to narrow down the possibilities of who had access to what and when to fewer individuals. With that in mind, employees might think again before blowing the whistle. This is especially true for server-based least privilege solutions where keystroke logging will record everything done at a granular level, whereas desktop least privilege usually just tracks at an event level.
WikiLeaks and WikiWar
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 overkill or underkill.
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 that “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)?
Implementing a privilege identity management (PIM) solution and eliminating admin rights from servers, desktops, network devices, virtual servers, and cloud environments is a strong move in the right direction to ensure that everyone in your organization only has access to what they should have based on corporate policy. This ensures governance and regulatory compliance and limits the potential for other leaks from your organization.
To exacerbate the situation, we've seen it described as everything from a WikiWar to Wiki Gaga, and yet most writers are still forgoing that if you give someone permission to do something, they will inevitably do it. In this case, we are once again referring to the IT privileges granted to individuals and associated technologies to monitor and control what these people are doing. Or the lack thereof.
By implementing a least privilege solution, you are taking the first step toward better IT management and a method of policing corporate governance. The root cause (excuse the pun) should ultimately be recognized as the misuse of privilege.
Implementing a PIM solution can allow you to:
- Eliminate admin rights across servers, desktops, network devices, virtual, and cloud environments to prevent anyone from having omnipotent access to those resources.
- Control levels of privilege for those resources to ensure the elimination of the misuse of privilege.
- Log all events and administrator activities so that in the event of a breach or a misuse of privilege, you can remediate that breach.
- As today's t-shirt points out, you can focus on the variables that positively affect your business growth instead of being at war with your user community or wind up in the press.
One solution that seems to be prevalent in some circles to use the open source solutions available to implement least privilege. This solution is called Sudo and was created by Bob Coggeshall and Cliff Spencer around 1980 at the Department of Computer Science at SUNY/Buffalo.
Why Do You Sudo the Way You Do?
Sudo has been one of the Unix/Linux administrator and self-designated geek's best friend for the last two decades, but it probably isn't right for your enterprise. For one thing, it's open source software, which means no one company can be held accountable for bug fixes, enhancements, or any liability resulting from flaws in design. Of course, being software guys, we naturally lean toward licensed code and cover the subject of licensed code versus freeware (see Figure 5-2) a little later in this chapter.
Indeed, many IT professionals believe that by implementing Sudo across their enterprise, they are now protected from the intentional, accidental, and indirect misuse of privilege. Unfortunately, that is not the case, as anyone with a browser and the keywords “Sudo breach,” “Sudo tricks,” or “Sudo hack: will learn. If you have three minutes to spare, there is even a YouTube video to show you how in step-by-step instructions for the Guy Hawkes Hack.
In the land of Unix and Linux systems administration, nothing seems to elicit such polar love and hate as does the use of Sudo for root rights elevation.
Pro Sudo: The single biggest cry for support of Sudo tends to be “it's Free!” or “it came with my OS". Suffice it to say that Sudo has been in use since “around 1980", when it was developed by Bob Coggeshall and Cliff Spencer and made available as open source software. Currently it is actively developed and maintained by Todd Miller and distributed under a BSD style license. The second biggest cry for support is “but it passed my last audit.”
Con Sudo: The amount of effort required to configure and maintain, especially since Sudo requires separate Sudoers files on each server instead of centralizing policy management and reporting. Nothing is truly free when it comes to freeware. Periodic review of Sudoer files alone can be so time consuming as to potentially miss an audit or inhibit other more pressing priorities. Yes, you can create a “Master Sudoers” file, but once it is copied to a server, it could be edited independently. It is also very difficult to map master entitlement reports to actual Sudo commands across the extended enterprise, especially in a changing environment. And finally, as Google just discovered, whenever you have an open source solution, the possibility of malware injection escalates significantly.
Ultimately, you will need to decide whether or not good is good enough long-term and uncover what the true cost or “free” is to your organization. So, why do you Sudo the way you do?
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, 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? Figure 5-2 shows the primary differences between freeware and/or open source software versus products licensed and supported by commercial vendors.
Figure 5-2. Differences between licensed software and freeware.
Now consider the 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 you can do this with Sudo just as you 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.
Sudo Vulnerabilities
From 2010 through Q1 2011, the Department of Homeland Security (DHS) released ten vulnerability alerts for Sudo with a medium or high severity rating. DHS' National Vulnerability Database (NVD) is the US government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP).
Figure 5-3 illustrates the types of vulnerabilities that have appeared since 2010 on DHS' NVD, and the number of times these vulnerabilities appeared among the ten Sudo alerts. It is important to note that multiple types of vulnerabilities have appeared in one alert (that is, Allows Disclosure of Data). This data was retrieved from http://web.nvd.nist.gov/view/vuln/search.
Figure 5-3. Sudo vulnerability alerts
What's really interesting about this chart is the subtext that implementing Sudo actually introduces some potential for security breach and insider threats than not implementing it at all. It also doesn't make it any less likely that good people will do bad things, as it simply exacerbates the complacent approach to PIM inherent in most organizations. It could even be construed as a “sloppy” approach to attempting least privilege given its open source nature.
Top Ten Reasons to Implement Least Privilege on UNIX and Linux Servers
Taking a more tongue-in-cheek approach to highlighting the types of privilege misuse that occurs daily on servers inside most organizations, we thought that a top-ten list approach might appeal to you as well. How many of these have you seen throughout your organization?
#10—Sam, the CSO, can now sleep nights knowing that excess privileges will no longer be responsible for failing a SOX, HIPAA, PCI, DSS, GLBA, or FDCC and FISMA audit (even though he isn't required to even deal with the last two).
#9—Andy the Auditor can get a full report of who has what entitlements instantly to satisfy compliance successfully, instead of taking weeks of manual effort.
#8—Ted in Tech Support won't be able to reset file and directory permissions on any Linux server he has admin rights to so liberally that anyone with a login can access confidential data just because it makes his job easier.
#7—Sid in Development won't be able to download Apache applications or any other unauthorized open source “tools” potentially injecting malware into the corporate network.
#6—Fiona and Felix, our new server administrators, won't make one, or more, of the Ten Mistakes New Linux Administrators Make.
#5—Vito, the ever-industrious programmer, will no longer be able to code suid root binaries into his programs, allowing programmatic access beyond what is allowed by corporate policy or regulatory requirements.
#4—Alice in IT will no longer be responsible for DNS misconfiguration errors, as her role won't facilitate this level of admin privilege.
#3—Fred in IT won't be able to install a Trojan on the mission-critical server, bringing it down for four hours and costing the company over $1M in lost transactions, because he was passed over for a big promotion.
#2—Sarah, the CIO. will no longer have to hide Unix and Linux root credentials in a sealed envelope in her office safe and deal with a manual check in/check out process.
#1—Tony, the Palo Alto Linux administrator. will no longer be able to wear that ratty old T-shirt with the slogan “Bow before me, for I am root” any longer.
More Server Breaches in the News
Health information exchanges (HIEs) is the latest buzz phrase to hit the compliance marketplace. In a recent post, blogger phiprivacy.net reported on the opinions of top IT experts about the top patient healthcare information trends for 2011.
Among a clear indication of increased breaches, imposition of fines and other regulatory action, and the implementation of new laws, the experts identified the launch of new HIEs as the main driver of change in enforcing increased security and privacy.
Although HIEs have a noble purpose in making it easier for healthcare professionals to access patient information electronically across multiple organizations within a region, community, or hospital system in order to provide more efficient and effective care, the risks of increased exposure to data breach remain high.
Not only do the experts point out that many HIEs will be launched by inexperienced and understaffed organizations, they will be launched in an industry (healthcare) that has consistently failed to keep pace with data security best practices and governance.
This is clearly a case of healthcare organizations putting the cart before the horse. In an ideal world, the horse is an efficient IT system, and the cart is the service that system is able to provide to the end user.
Trying to improve the cart without upgrading the horse from the old nag it currently represents is likely to leave healthcare organizations even deeper in the mire. Best practice for healthcare data security is no different from any other industry.
Indeed, sensitive user access control, based on least privilege role definition, remains the cornerstone of HIPAA compliance and will require the elimination of admin rights to prevent the misuse of privilege.
Case Study: Replacing Sudo in a Production Environment
CETREL S.A. (www.cetrel.lu), a leader in advanced electronic payment technology, expert in electronic transfers, and a trusted partner for electronic payment offers, experienced significant compliance and auditing challenges using Sudo to manage their IT environment.
Nicolas Debeffe, head of operational security at CETREL, is responsible for overseeing CETREL's security operations, which includes their complex IT environment. For the last several years, Mr. Debeffe's security team had been using Sudo to manage their critical Unix/Linux assets and trace any access from CETREL's support teams to applicative or generic users.
While Sudo initially seemed to manage CETREL's IT environment, they soon discovered that there was an imminent need to find a simpler and more secure method to manage access and accountability to generic users.
“As we have been continually adding Unix and Linux servers to our environment, as required for our operations, it was clear Sudo raised significant red flags over the adequate security over our logs required by PCI DSS mandates,” said Nicolas Debeffe.
“Productivity was being hindered, as reviewing Sudo logs required accessing every server individually. Furthermore, Sudo logs were alterable by the super user and the Sudo configuration time required by system engineers was simply unacceptable,” added Debeffe.
This example is a very common and real challenge for security managers globally, and the faster organizations are cognizant of such red flags, the faster they can implement preventative measures from a strategic and compliant perspective.
Vulnerability Scanning Requires Least Privilege
Many companies still rely heavily on vulnerability scanning to ensure outsiders aren't getting in. Root-level access for authenticated scanning is an important part of vulnerability management scanning and required for policy compliance scanning. This creates another open doorway for the misuse of privilege in your organization. Yep, yet another account that has unlimited access to corporate resources under the guise of “being more compliant.”
The good news is that some industry leaders in vulnerability management and policy compliance scanning recognize this and are doing something about it. Specifically, they have partnered with least privilege vendors to create a more secure scan.
Most vulnerability scanning vendors use a Software-as-a-Service (SaaS) model to automate the process of vulnerability management and policy compliance via remote authenticated scanning without the use of agents. Using a least privilege solution in combination with this enables system administrators to delegate privileges and authorization without disclosing root passwords, preventing misuse of privileges on desktops and servers in heterogeneous IT environments. This integration enables you to use least privilege root delegation functionality for authenticated vulnerability and compliance scans on Unix systems. This allows system administrators to better manage access while scanning their environments as they can delegate privileges and authorization and record all interactions, including keystroke information, for auditing purposes.
Patching Needs Least Privilege
A report came out in early 2011 highlighting vulnerabilities in NASA's IT that could have impaired critical space missions or leaked sensitive information.
Using the NASA CIO's own words, The Network World story by Tim Greene points the finger in the same mistaken direction most anyone would as a reflexive response: the lack of an ongoing program to identify and patch vulnerabilities. But the article itself also presents the very obstacle to that. NASA was/is patching software routinely, but there's just too much to patch, too many updates, too often that need to be implemented too quickly. Mistakes and overlooked vulnerabilities are bountiful. What about vulnerabilities that aren't discovered yet, were just discovered but not patched, or are known but overlooked. Is there no room for error?
The report states the agency has over 190 IT systems and projects that include assets that control the Hubble Space Telescope, the Space Shuttle, and the International Space Station among others and describes previous breaches where extremely sensitive information had been leaked by sophisticated attacks. In one case, malware was allowed to spread and make 3,000 unauthorized connections to IP addresses all over the globe. The report blames “inadequate security configurations.”
This is another example of the indirect misuse of privilege discussed at length in Chapter 2. Anyone who still has admin privileges is susceptible to having those credentials hijacked and malware planted.
What the NASA story is missing in the mainstream media is that running around patching vulnerabilities everywhere they can be found is only half the solution. It's like a game of whack-a-mole—you're never done and you'll always be too late to at least one. Companies need to reduce their risk exposure even under the assumption that some vulnerabilities will be leveraged—and they will.
Privilege Identity Management System Logs Help Spot Other Security Weaknesses
Those detailed compliance logs you have been generating are a gold mine of information. Analyzing large amounts of data is a growing trend. From Google to Walmart, companies are building their strategies on complex models and algorithms.
You can use systems logs not just to look for patterns that indicate a security threat, but those same patterns can show where security and other procedures such as improper configurations of new systems are hurting productivity. Finding those patterns can help uncover opportunities to better train, simplify procedures, and uncover best practices that not everyone is following. And once those best practices are discovered, you can use controls to ensure that best practices are being followed.
Realizing that value requires a data analysis strategy and a strategy for how to engage the organization in using that analysis. Your data analysis strategy needs to consider the roles of monitoring, logging, and reporting, as well as when and how to combine data from different sources. Single silos of data are simpler to use, but correlating data across silos provides more powerful insights. Ultimately, you will need both, but your data analysis strategy needs to focus on providing insights your organization can act on. And that's where you need to consider how to engage your people in using the data.
Weighing In
Servers can be the holy grail of targets for insider villains, and as such need to be dealt with specifically and diligently. We've discussed how they are the primary attack point and for good reason: this is where the most valuable data is usually stored. We showed how some organizations attempt to implement least privilege using an open source solution that may open other vulnerabilities. What we think is most interesting is the magnitude of the impact caused by the lack of least privilege implemented in server environments and the hundred of millions of dollars and potential jail time that can be associated with insider breaches.
Let's hear from our Insider Heroes:
Secure Sam:
One of the responsibilities I have (and candidly, the one that stresses me out the most) is making sure people within my organization have the right amount of privileges. I've seen it all—between the classic accident-prone employees who are always downloading malware without knowing it to the ones who are a bit too cavalier with passwords—it seems like it's a battle I will always have to fight. The idea of least privilege is crucial in this battle, especially on our servers. The information stored on the servers of our company hold mission-critical data. It's not data I can afford to risk because of a mistake. My IT staff has such entrenched access to the IT system, one mistake can have catastrophic results. Because of this, access to company resources and assets are restricted to a need-to-know basis. All users have access to only the information they absolutely need to do their job productively. No one has root access—a mistake at the root level is simply not acceptable. We also have processes that monitor and log all activity in the event that something does happen. Especially with servers, these measures must be taken to ensure the highest level of security and compliance.
Least Privilege Lucy:
There are a lot of security things that can go wrong, especially in large enterprises. Particularly in server environments, it's paramount that data protection is taken seriously—in both word and in action. Everyone says they're concerned with security and that it's their top priority, but when I go to work and have to put out fire after fire, it becomes very obvious that what users say and what they do are on completely different planes. This is why least privilege is so important. And not just least privilege, but a solution that centrally delegates privileges so I don't have to hassle with Sudo or other open source command lines. Here's an example of how this is effective. Take my biggest pet peeve: a user with access to the root password sharing it with other users who are not cleared to have that information. Not only is this a huge breach of security, but it is also not compliant with federal regulations to which we are held. With a least privilege solution, no users have the root password; therefore, it remains safe from those who don't need it. Instead, those requiring root access for their job functions are automatically delegated that privilege by elevating the individual task. With so much on the line and with so many data breaches in the media, this is a safeguard that is necessary.
Compliance Carl:
Compliance on servers is crucial, as that is where the most critical of information is stored. There are regulation mandates in place to protect this data, and in most companies I visit, it seems like this concept isn't fully understood. Yes, IT administrators get that keeping servers secure is paramount to the company's IT health, but if they fully grasped the concept, I wouldn't see open source software ruling the policies and privileges of the company's secure information. Even if the files are regularly inspected (which is required by various regulations), there is too much left to human error for that to be a viably secure protocol. Several things make this a challenge, which was talked about before, but as they are real struggles in real IT environments, I thought it prudent to reiterate a couple of them here. First of all, with open source software like Sudo, each individual server has a unique file that must be analyzed and reviewed. This becomes an enormous task when there are a lot of servers in an enterprise. Secondly, because the command policies are so heavily code-based, it is time-consuming and expensive to manage privileges in this way. Sudo has its place, but it is definitely not in large companies. The best option is this: a privilege delegation strategy that centrally manages privileges, logs activity, and ensures security while saving time and productivity.