I attended a Webinar recently put on by Application Security Inc. regarding the threats to databases for the coming year. If you did not attend it, you missed a good session. But the most disturbing thing brought up was their top 10 list database vulnerabilities and misconfigurations. Their top 10 list is:
- Default or weak passwords
- SQL injection
- Excessive user and group privileges
- Unnecessary DBMS features enabled
- Broken configuration management
- Buffer overflows
- Privilege escalation
- Denial of Service
- Unpatched RDBMS
- Unencrypted data
If you look at my post a while back on the 2011 Verizon Business Services’ reasons for why organizations were breached, there is a great correlation between Verizon’s report and what Application Security Inc. is saying.
Their first point about weak or default passwords is very clear and should not need to be discussed. In this day and age, we should all be ashamed that this is even on the list, let alone the first item on the list. The bottom line here is that, if you use default or weak passwords, you deserve to be breached.
They brought up and interesting point about SQL injection attacks that a lot of organizations do miss or underestimate and that is the internal SQL injection. Most organizations are so focused on the external threat that they forget about the threat from the inside. Worse yet, most security professionals and DBAs are unaware of the threat SQL injection poses even without the Web. Since most of today’s attacks are perpetrated once past the perimeter, the protection from the inside attack is very relevant and very important. Because once an attacker is on the inside, it is relatively trivial to use SQL injection or other techniques to obtain data. More and more organizations are beginning to understand the insider threat and are firewalling all of their database servers away from the general user community as well as minimizing the number of users that have direct SQL access to those servers.
Excessive privileges cannot always be addressed at the DBMS level. In today’s packaged software world, a lot of the rights are managed and maintained at the application level and that security matrix is maintained in a database table. The granularity that can be granted is usually where things go awry because the application’s security system only provides an “all or nothing” approach. Application vendors are getting better with this because of SOX, HIPAA, PCI and the like. However, organizations typically need to be on the most current releases to have access to such enhanced security granularity. Unfortunately, there are very few organizations that can afford the most current release or can implement the most current release due to their extensive modifications. The simplest way to address this issue is the periodic reviews of database privileges and minimizing those users that have excessive privileges. In the longer term, I expect we’ll see the return of the data dictionary with the addition of user rights and roles that will manage this problem.
Unnecessary features enabled are a vendor and DBA issue. In some cases, vendors make changing features impossible or near to impossible once the RDBMS is installed. In some cases, there are physical reasons as to why a feature must be enabled at installation. However, there are also instances where features could be enabled or even disabled at anytime, but because the vendor only wanted to do that at installation, that is the only time you can deal with the feature. This results in a lot of DBAs installing the RDBMS with every feature/function available, whether it is needed or not, just in case they might need it later on. Do not get me wrong as I understand the drivers for this practice. In today’s “I needed it yesterday” world, it is tough to be responsive when something will require an entire re-install of the RDBMS and migration of existing data in order to get something done. It is time for IT people as a whole to start explaining to non-IT people that there are just some tasks that take time to do properly no matter how quickly anyone needs them completed. Our infrastructure has become susceptible to attack in large part because of this rapid response desire. If we intend to make things secure, we need to stop and think things through before creating even larger issues.
The pervious issue feeds directly into the next; broken configuration management. Configuration management is broken because the vendors make it virtually impossible not to break it. And even when configuration and changing configuration is easy and manageable, DBAs are not always as structured as other IT operational disciplines. As a result, whether talking about the configuration of the RBDMS or the client that loads on the workstation, configurations are too broad because of the “just in case” factor. I know it is a pain to only enable what needs to be enabled and then six months later have to reinstall everything just for a particular feature, but that is the correct way to do things if you intend to be secure.
Buffer overflows, privilege escalations and denial of service are all common vulnerabilities that organizations will have differing levels of success in mitigating. I will tackle the easiest to address first, privilege escalation. If there is any area where security can always be addressed it is with privilege escalation. The reason privilege escalation exists is because someone, usually a developer, created the issue because they decided to allow users to perform a task that the user should not be allowed to perform. Because if they were allowed to perform the function, then they would not need their privileges escalated to perform it. The easiest thing to do is to disable those functions that require privilege escalation. However, in some cases, that approach will create operational issues that will be unacceptable. In those cases, monitor the daylights out of things so that you can be sure that the privilege escalation did not result in a different outcome.
In a lot of cases, there can be little done to address a denial of service (DoS) attack short of blocking the offender(s). Denial of service does not compromise information; it just makes the information stored in the database unavailable. And for most organizations, that is an important distinction. If no information has been or can be compromised, then DoS is an annoyance and should be treated as such. However, some DoS attacks can be used to defeat security measures in the RDBMS by causing the RDBMS to fallback to a basic operational state. It is in these situations that one has to be careful because information can be lost. The easy fix is to put a firewall in front of the database and enable DoS attack protections.
Buffer overflows are the most insidious attacks because, in some cases, there is little that can be done to stop them. A lot of security professionals make the success of buffer overflow attacks sound like they are all the result of sloppy coding practices. And while there is some truth to that view, the amount of which depends on the skills of your programmers, the success of buffer overflow attacks is also the result of embedding too much flexibility into our applications and leveraging the capabilities of the RDBMS. In today’s world of open constructs such as SQL and RegEx, we have effectively made everyone a potential database programmer all in the sake of expediency. Yes, customer service is highly improved, but at what cost? Web application firewalls can minimize buffer overflows by “learning” how your SQL calls are typically structured, but they are not a complete answer nor do they completely remove the risks. The way to fix the problem is to reduce functionality and make applications more complicated and difficult to use. For most organizations that is not an option. As a result, we must minimize the risks but be willing to accept the risks that remain as a result of our desire for ease of use and flexibility. Minimizing the risk may mean implementing that Web application firewall internally as well as externally.
While I was glad to see that unpatched RDBMS software low on the top 10 list, I was very disappointed that it was still in the top 10. One would think with all of the discussions about the importance of patching software, this would not occur in the top 10. I understand the issues of compatibility and testing that make patching difficult, but really? Maybe you need to invest in more than one or two instances of the RDBMS. This is the cost of doing business the correct way. If you are not doing things the correct way, then do not complain when you have a breach. So while you saved yourself money on licensing costs on the front end, you likely paid for that cost savings a hundredfold on the back end.
I also understand the issues and fears with encryption. For a lot of people, encryption is this mystical science that only certain “geeks” practice and practice well. For others, the problem with encryption is the perceived loss of ready access to their data. As time goes on, I would say that unencrypted data will rise to the top of the top 10 list. Why? Because the information age is all about the control of information. The more information you control and can use to your advantage, the more power and control. If your information can be readily obtained through public sources or the lax security surrounding your information systems, then you have little, if any, power or control. The next 10 years will likely be spent by most organizations figuring out what information is critical to their business model and implementing the necessary protections around that information. Critical information will be protected like the gold at Fort Know because, to that organization, that is their “gold” and it must be protected accordingly. And that protection will likely involve encryption for some or all of it.
I know that people have a lot on their plates these days. However, if you are a security person or a DBA, you need to leverage these surveys to your advantage and address the top 10 issues. If more companies did this, the less data that would be breached.
