Applications, Databases, and Desktop Data Need Least Privilege, Too

“Only 40% of security professionals indicated that existing controls can adequately protect all of their organization's confidential data while the remainder of respondents reported numerous data security gaps.”

—Jon Oltsik, Enterprise Strategy Group

Physical, virtual, and cloud infrastructure exists for only one purpose: to store information assets and run applications that give those assets purpose. Since you've kept reading this far, you are now aware of the implications of unmonitored access to this infrastructure, but what about the core reason for buying, implementing and managing all of this in the first place?

All of your investments in legacy applications were done so for specific productivity, profitability, or compete-ability reasons, but the privileges to run them leave gaping security holes. Most applications were originally architected without the concept of granular authorization levels. So how do your users run them today? For most organizations, the answer is to continue to grant full administrative rights so that they don't have to incur the costs of re-architecting and developing those applications without the admin-level requirements.

A better answer, obviously knowing our thoughts on least privilege by now, is not to grant or take away all of those privileges, but to allow users to run them based on what is required for their jobs. This relieves pressure on IT administrators who think the only way out is to upgrade or pay for an in-house patch. This is especially true for database and database-based applications.

Servers Store the Good Stuff…In Databases

In Chapter 5, we spent time discussing how servers are the primary attack point for insider and outside hackers alike. We highlighted that that's because the most important information assets tends to be stored on servers, but what we must point out is the fact that most of that data is residing within a database. Think of it this way—if applications provide the engine to user productivity, the information stored in databases (on servers) and on personal desktops provides the fuel.

So why do databases merit their own chapter?

Put simply, because database-based applications are often also legacy apps. As we have mentioned elsewhere, legacy apps are required for the operation of enterprises everywhere, but the privileges to run them leave gaping security holes in enterprises. The answer, obviously, is not to take away those privileges, but to allow users to run them with a least privilege solution to elevate privileges as required and allowed by policy. This relieves pressure on IT administrators who think the only way out is to completely rewrite code, upgrade to different applications or pay for an in-house patch.

So why not simply upgrade the legacy apps?

As you well know, courtesy of Moore's Law, technology is still getting twice as fast at half the price every 18 months or so, yet businesses still prefer to operate under the assumption pervasive in nearly every enterprise, that “if it isn't broken, don't fix it.”

If you won't fix it, then at least be aware that your databases are prone to the same whims of human nature as any other IT environment.

DBA: The Privileged Database User

If you haven't been keeping up with all of the TLA tiles in your organization, then DBA may be one you've missed. DBA stands for database administrator and this is the primary privileged user designated for your database. Like the systems administrator, the DBA has omnipotent access to the database. They can not only monitor and maintain the data, tables, and indexes, but also can add, delete, and modify all of the above to their heart's content.

Similar to your server administrator, the DBA can take on the persona of insider hero Least Privilege Lucy or insider villain Disgruntled Dave, with the only difference being scope of influence limited to the database and not the actual physical or virtual server upon which it resides.

Database Security Risks

As you can imagine, databases are in a class of data storage, organization, and management unto themselves. As such, the inherent security vulnerabilities in which a least privilege solution can help mitigate are also relatively unique. We've uncovered six that should be explored:

1. Misconfigurations: Database schemas can be very temperamental and any misconfiguration error can cascade into a huge problem or be so subtle that it may be difficult to uncover the impact. A frequent challenge here is the ambitious developer who somehow gets access to the production system instead of just their development sandbox.
2. Updates: Out-of-cycle patching can cause major disruption in operation and potentially lead to lost revenue if done on the primary transaction database. Here is where the ambitious tech support technician or developer believes that blindly trusting that your database vendor's testing capabilities keep current with their latest patch is a good thing.
3. Application Attacks: Sometimes the easiest way to attack your database is to attack the outward-facing applications that are connected to that database, especially if those application are web-based. This can also come in the form of database access through non-approved channels such as open source tools capable of bypassing normal admin dashboards.
4. Transaction Monitoring: Sometimes it's the smallest of things that can trip you up when looking to satisfy compliance or track down data theft or damage, so monitoring every transaction can be very important. However, it can also drown your data stores in amounts of information too voluminous to even interrogate.
5. Data Awareness: What is perceived, or in actuality is, confidential data can be subjective in some organizations and very clearly identified in others. Being aware of what class of data is stored where will be another critical success factor.
6. Privileged Users: Our favorite, of course, is the privileged user. As discussed previously, the DBA's omnipotent access to your database must be managed through a least privilege solution in order to ensure your governance and compliance policies are met as well as protect against the misuse of that privilege—intentionally, accidentally, or indirectly.

Legacy Applications Are Still Pervasive

While databases store most anything of value, it's the legacy applications that sit on top of those databases that provide your business users access. Most enterprises have more bespoke legacy applications then they do off-the-shelf software. These applications were mostly written in-house, by developers who more were concerned with making their app work (with admin rights) but without considering the impact granting those rights would have on running other apps. Least privilege is the intersection here between database management, legacy applications, and the infrastructure on which they run.

Your DBAs, IT admins, and business users in each division, department, or business unit will tend to isolate themselves and consider their silo the most important. This again is due to a classic weakness in human nature and the inability to communicate and collaborate between each other. Let's look at the implications of some of these silos.

Desktops Have Legacy Application Challenges as Well

In an enterprise Windows' desktop environment, whether a company has 100 or 10,000 seats, the challenge of managing access is fraught with difficulty. Why? Because every user is going to want to work with their desktop computer the way they work on their own personal computer on their personal time. The proliferation of personal computing has actually made IT's job that much harder as every user considers themselves an expert if they've “Googled” something on the Internet.

One way to control these rogue desktop users is to shut down all privilege. We discussed that at length back in Chapter 4 on desktop least privilege, but then the dreaded UAC pop-up window wreaks havoc with your help desk.

Even if an IT administrator can work out how to circumnavigate Windows User Access Controls or how to set a Group Policy for every application, there will invariably still be a legacy application on which the company relies, which will only run if every user is given administrator status.

In effect, one or more legacy applications force the company to leave the entire network vulnerable to either intentional or accidental damage from giving users a higher level of privileged access than they require.

These applications will have been written in-house, or by a third party provider, to meet the bespoke needs of the company—and yet without recognizing the security risks and compliance headache caused by leaving desktop access wide open.

Equally rife is the use of legacy apps such as Sage Instant Accounts and Intuit QuickBooks, more associated with the individual user or small company, but more often than not used en-masse in larger companies with 100+ desktops.

The impact of these legacy apps is not just the security risks they pose, but also the impact on IT support in fixing the unintentional errors caused by over-privileged desktop users. That's time and money that might be used more strategically, rather than on the tactical day-to-day fire-fighting.

Good role-based user privilege management software can easily circumnavigate the requirement of legacy apps to run desktops on administrator or super user status without requiring their modification or removal.

Desktop DLP Helps Mitigate Different Insider Threats

It may be appropriate to take a small break from a pure least privilege management discussion and highlight another technology that supplements our solution for the mitigation of insider threats on local data stored or accessible by local desktops. Endpoint data leak prevention (DLP) is a solution that compliments the brokering of privilege authorization and aids in securing the perimeter within by dealing with data in use and at rest. DLP leverages a policy engine similar to that of least privilege to ensure specific data is dealt with according to your governance and compliance requirements. Here, specific phrases, paragraphs, or documents can be protected against movement, copy, modification, or deletion.

Loss of customer account details, exposure of confidential information, and theft of sensitive data are typical data leak cases that cost companies up to 5% of revenue every year. Insiders, employees, and contractors who have authorized access to confidential data are liable for 70% of total data leaks.

Compliance Audit Failures

If you can't protect your data in databases, in legacy applications, or on personal desktops, then ultimately you face a compliance audit failure (see Figure 8-1), in addition to potential damage, loss, or theft.

Figure 8-1. Reasons for failed audits

Stolen Fruit

I'm sure you've heard the saying “stolen fruit is the sweetest.” It's a phrase that gets thrown around lightly, but it's time to take it to heart. In a day when information and sensitive data are being stolen, manipulated, and blasted for the world to read, this is a saying we all need to look at twice. Hackers, inside security leakers, and thieves all agree: that which is stolen is the sweetest. You don't want to find out how sweet the information in your enterprise will be to them. Steps should to be taken to secure the sensitive information and data in enterprises across the world.

Who are these people stealing the “fruit?” I think you can probably guess—hackers, thieves, and those abusing administrator rights. These are the people enterprises must protect against. According to a study performed by the Professional Association for SQL Server (PASS), 44% of database security challenges come in the form of inside hackers and the abuse of privileges. Outside hackers and thieves do present a threat to the integrity of our databases and the information therein, but our attention should first be turned to those already in our organizations. Often, these individuals have too much access to information they simply do not need. And why do they steal this data? Because your data is truly sweet to them—they see a huge payday without the hard, bitter work. If you think this doesn't apply to you, or that none of your employees are capable of such atrocity, let me turn your attention to the Goldman Sachs debacle. I bet they thought their enterprise wasn't in danger either—yet look at what transpired. How much will the “sweetest fruit” cost your company?

If you are concerned about the security of your enterprise (you should be if you haven't already taken measures to keep your sensitive information safe), it's time to implement a privilege management policy and become compliant with government mandates. It's the only way to prevent the fruits of your company from becoming sweet and stolen. Don't let your employees assign a price to the sweet information in your enterprise. Set up a protocol that allows users just the right amount of access to information.

Top Ten Reasons to Implement Least Privilege for Applications and Databases

Taking a more tongue-in-cheek approach to highlighting the types of privilege misuse that occurs daily in applications and databases inside most organizations, we thought that a top-ten list approach might appeal to you as well. How may of these have you seen throughout your organization?

#10—Sam, the CSO, can now sleep nights knowing that inappropriate database activities are not only being monitored but also prevented via policy enforcement at a granular level.

#9—Fiona, the DBA, won't be able to modify the production database instead of the test copy in the sandbox accidentally or even accidentally on purpose.

#8—Frank, your sole Application Developer, will no longer have to rewrite legacy applications in order to strip out any code requiring administrative privileges.

#7—Ted, the overzealous Tech Support Tech, won't be able to upgrade your production database to the latest version of Oracle released today before the IT department has had time to vet the impact on current processes and attached applications.

#6—Ken, the CSO, can delegate database access based on access control policies that leverage external context such as SOX, PCI-DSS, and FFIEC compliance.

#5—Carl, the Compliance Executive, can now quickly identify all privileged users, review entitlements, and if necessary, de-provision obsolete users in order to pass your next enterprise IT audit.

#4—Francine, the COO, can now easily ensure adherence to change control processes across the extended enterprise for all databases and even reconcile with the change ticketing system.

#3—Larry, the new DBA, won't have to call his predecessor, who is now serving eight years in the penitentiary for identity theft and attempted sale of your entire customer credit card transaction database, to learn the new processes for database activity monitoring (DAM).

#2—Beth in Human Resources won't be able to forward the entire company payroll ledger to WikiLeaks because the CEO didn't tell her how great she looked today.

#1—The IT department can still have the 35^th annual birthday party next week for that payroll application that requires desktop admin rights, but no one knows where the source code is to make it more contemporary instead of replacing it outright.

In the News

You probably already saw in December of 2010 that a group called Gnosis hacked over one million rows of data from Gawker, claiming the organization had some of the worst security they could have imagined. Gnosis gained access to their database in one day and even Gawker said in an internal memo that they were largely caught unprepared.

Now for your own entertainment, you should see the Wall Street Journal blog of December 13, 2010, which shows that over 3,000 Gawker users had the password “123456” and 2,000 had the password “password”. Everyone knows users often set poor passwords when left to their own devices, but the chart presented in the Wall Street Journal blog really brings it to life. Gawker clearly didn't have adequate requirements for more complex passwords.

It's unclear how exactly Gnosis gained access to Gawker's database. They mention that there were a lot of vulnerabilities in outdated software. However, what is clear is their motivation: vengeance, and why Gawker was so easy to hack: lack of preparation.

Vengeance is such a powerful mission that it's created a plethora of music, movies, books, and even video games. In the movie Vengeance, a chef seeks vengeance for a violent attack on his family that left three dead. In real life, vengeance is not always so compelling; Gnosis sought vengeance because they were offended.

Yup, that really is all it takes. Now think back to the last time you fired someone, they quit, or maybe you were the one leaving. How often was the departing employee bitter about something?

Vengeance is easily ignited and when you're a member of the IT team with privileged access to IT systems and special skills, what else would possibly be your weapon of choice? Terry Childs, the former network administrator who was arrested on computer crimes in June 2008 for refusing to divulge the passwords to San Francisco's FiberWAN system, is an example of how IT staff enacts vengeance. Gnosis is how hackers enact vengeance. IT sabotage and penetration is how computer enthusiasts cause damage to those they will it on.

So prepare for it.

Why Give a DAM

The lack of control of privileged database credentials continues to expose corporations to significant risk associated with insecurity and inaccuracy of the key data assets that drive business activities, decisions, and value. We've previously covered the six questions you should ask yourself if you should give a DAM, so now it's time to look a little deeper at the implications.

Specifically, weak control of privilege credentials provides the opportunity for the insiders holding those credentials (or hackers who acquire them) to misuse their elevated privileges to steal or fraudulently manipulate data or simply introduce inaccuracies through human error. The consequences of these unauthorized actions can be severe for businesses, especially if the activity goes undetected for a prolonged period of time. Secondarily, the compliance costs associated with proving to IT audit that adequate database controls around these privileged users are in place is high.

The solutions currently available to corporations today are often times not entirely effective, and are expensive to purchase, deploy, and maintain. Custom-developed solutions that leverage the database's native security and audit features are a common approach. These solutions are expensive to design, develop, maintain, and operate. DAM products on the market today are another alternative. These products provide tools to implement detective and preventative controls for DBAs; however, there are three key weaknesses in these products:

1. The preventative capabilities are driven largely by policies involving rudimentary session attributes, access patterns, and activity thresholds. These do not provide the capability to control activity on a fine-grained basis based on external context.
2. The monitoring capability of many of these products does not provide the level of visibility into what is happening to data assets stored within the database, nor does it provide the activity detail needed to assess impact of the activity and remediate it if necessary.
3. The products are expensive and complex to implement.

DAM Value

First, securing the database is critical. The database is where the business' valuable data assets live, and is therefore most often the target of attack when it comes to frauds and data breaches. Controlling the users that hold elevated privileges on the database is critical to any data security effort. A complete solution to this problem must include the following:

• Effective Credential Management: Identifying privileged accounts across database infrastructure. Provisioning access to and privileges on those database systems based on business justification, and quickly de-provisioning access and privilege when justification no longer exists.
• Policy-Based Access Control and Privilege Delegation: Control systems based on the principal of least privilege. Privileges are delegated only when needed and authorized (need and authorization based on evaluation of external context such as a change ticketing system), only for the duration to execute distinct authorized change activities.
• Activity Monitoring and Closed-Loop Reconciliation with Change Management: Capture, review, and reconcile all activity executed by privileged users against change ticketing to verify that the activity was authorized, followed change-management processes, and did not impact systems or business objectives negatively.
• Data Audit: Maintain a forensic audit repository of changes to key data fields, access to key data fields, or change of system configurations and controls that protect those data assets.
• Compliance Reporting: Compliance is a by-product of effective controls. A solution must produce evidence that effective control is being maintained.

Implementing Least Privilege for Databases

Fundamentally, the implementation of least privilege for a database isn't that different than implementing least privilege on a server. The difference is that the target is the specific database and associated commands (that is, select, view, copy, delete, etc.) executed by privileged users (DBAs) versus the systems administrator who needs to execute root-level commands.

So, Figure 8-2 should look very familiar to you by now, as it effectively is the same architecture we've presented for physical and virtual servers. Now you are monitoring the DBAs access, enforcing database-specific access policy and DAM instead of the least privilege solution monitoring commands sent to the operating system, enforcing policies, and either elevating the privilege necessary for that command or not along with logging the associated keystrokes and events,.

Figure 8-2. Architecture for database least privilege

Controlling Your Privileged Database Users

Implementing a least privilege solution for your databases will also ultimately deliver on the promise of best practices for:

• Managing privileged credentials: identifying and managing entitlements
• Enforcing policy: establishing and enforcing governance across the extended enterprise
• Monitoring and reconciling privileged activity: ensuring that no insider hero turns into an insider villain
• Maintain a high-quality audit repository: for business intelligence or remediation purposes
• Automate compliance reporting: for speed, ease, and lower costs when time for proving compliance

Weighing In

Least privilege is a critical part in the security of all of a company's assets. By turning first to the insiders with access to databases, applications, and desktop data, organizations can make sure those closest to an enterprise's sensitive information are prevented from leaking or accidentally manipulating it.

Let's hear what our Insider Heroes have to say.

Secure Sam:

Protecting information from insiders is crucial to the security of an enterprise. Obviously, not all insiders are malicious—people make mistakes just as much as they have intentions of pilfering corporate information from secure databases. It's crucial to prevent people within your organization from sabotaging (whether accidentally or on purpose) your sensitive information and this responsibility lies with you. As someone in a position of authority over the IT resources in your enterprise, you must be the one to govern the usage of these assets and the people who access them. Attention should be focused first on the internal structure of security. A handle must first be had on what goes on inside the walls of your individual enterprises, especially since it's how insiders use their privileges that determines how easy it is for outsiders to get in. Don't allow users free access to assets—especially when it comes to applications, databases, and desktops. You must secure procedures to govern the usage of resources in your company. There really is no other way to be compliant and secure.

Least Privilege Lucy:

By now you understand the concept of least privilege. You get why it's important, and you know it's an important step in securing your company's IT infrastructure. Least privilege helps mitigate so many security vulnerabilities that it's unwise to ignore it when making your plan for securing sensitive information. Especially when talking about databases and the data stored therein, companies take a huge risk by not monitoring and managing users' access to such information. The chapter spelled out six of the most susceptible vulnerabilities that least privilege can ease, and I whole-heartedly stand behind them. Too many times I've seen users misconfigure schemas and cause horrendous problems. Updates and application attacks are among the highest offenders, as well. It is so important for enterprises to be aware of the data in their systems, as well as to monitor the usage of said information. Without constantly watching what is moving and how it's moving, you're turning your back on a glaring security problem. The same goes for the individuals who have access to your sensitive data. It's paramount that they (along with their privileges) be monitored tightly.

Compliance Carl:

Compliance isn't only beneficial because it helps you avoid hefty fines. It ensures security of IT resources and stability in information infrastructures. If your company is incapable of protecting its assets, a failed audit is only a matter of time. Unfortunately, that failed audit is the driver behind most companies' security efforts. The deeper issue is damage to database information, loss of resources, or theft. Insiders are a hugely contributing factor to the security of an enterprise's data. All around are reports of breaches—the devastating results of insiders whose privileges haven't been reigned in. There are mandates preventing such breaches… a concept I feel most companies forget. Compliance isn't about paying the government money or having to jump through more hoops to make Uncle Sam happy. Quite the opposite actually; compliance makes your information safe. It's as simple as that. It's also very black and white—either you're following mandates or you're not. One thing I've noticed in various companies is that least privilege is a common denominator to passing audits and following mandates. It's a principle that helps your company be successful with security. Without fail. If a company has implemented a least privilege policy, they will be found compliant. Even better, they will be free from the devastating side effects of letting insiders run free.