Database Denial of Service: Countermeasures

Before I delve into the meat of today’s post I want to say that the goal of this series is to aid IT security and database admins in protecting relational databases from DoS attacks. During the course of this research I have heard several rumors of database DoS but not found anyone willing to go on record or even provide details anonymously. Which is too bad – this type of information helps the community and helps reduce the number of companies affected. Another interesting note: we have been getting questions from network IT and application management teams rather than DBAs. In hindsight this is not so surprising – network security is the first line of defense and cloud database service providers (e.g., ISPs) don’t have database security specialists. Now let’s take a look at database DoS countermeasures. There is no single way to stop database DoS attacks. Every feature is a potential avenue for attack so no single response can defend against everything, short of taking the databases off the Internet entirely. The good news is that there are multiple countermeasures at your disposal, both detective and preventative, with most preventative security measures essentially free. All you need to do is put the time in to patch and configure your databases. But if your databases are high-profile targets you need to employ preventative and detective controls to provide reasonable assurances they won’t be brought down. It is highly unlikely that you will ever be able totally stop database DoS, but the following mitigate the vast majority of attacks: Configuration: Reduce the of attack surface of a database by removing what you don’t need – you cannot exploit a feature that’s not there. This means removing unneeded user accounts, communications protocols, services, and database features. A feature may have no known issues today, but that doesn’t mean none are awaiting discovery. Relational databases are very mature platforms, packed full of features to accommodate various deployment models and uses for many different types of customers. If your company is normal you will never use half of them. But removal is not easy and takes some work on your part, to identify what you don’t need, and either alter database installation scripts or remove features after the fact. Several database platforms provide the capability to limit resources on a per-user basis (i.e., number of queries per minute – resource throttling for memory and processors), but in our experience these tools are ineffective. As with the judo example in our earlier attack section, attackers use resource throttling against you to starve out legitimate users. Some firms rely upon these options for graceful degradation, but your implementation needs to be very well thought out to prevent them from impinging on normal operation. Patching: Many DoS attacks exploit bugs in database code. Buffer overflows, mishandling malformed network protocols or requests, memory leaks, and poorly designed multitasking have all been exploited. These are not the types of issues you or your DBA can address without vendor support. A small portion of these attacks are preventable with database activity monitoring and firewalls, as we will discuss below, but the only way to completely fix these issues is to apply a vendor patch. And the vendor community, after a decade of public shaming by security researchers, has recently been fairly responsive in providing patches for serious security issues. The bad news is most enterprises patch databases every 14 months on average, choosing functional stability over security, despite quarterly security patch releases. If you want to ensure bugs and defects don’t provide an easy avenue for DoS, patch your databases. Database Activity Monitoring: One of the most popular database protection tools on the market, Database Activity Monitoring (DAM) alerts on database misuse. These platforms inspect incoming queries to see whether they violate policy. DAM has several methods for detecting bad queries, with examination of query metadata (user, time of day, table, schema, application) most common. Some DAM platforms offer behavioral monitoring by setting a user behavior baseline to define ‘normal’ and alerting when users deviate. Many vendors offer SQL injection detection by inspecting the contents of the WHERE clause for known attack signatures. Most DAM products are deployed in monitor-only mode, alerting when policy is violated. Some also offer an option block malicious queries, either through an agent or by signaling a reverse proxy on the network. Database monitoring is a popular choice as it combines a broad set of functions, including configuration analysis and other database security and compliance tools. Database Firewalls: We may think of SELECT as a simple statement, but some variations are not simple at all. Queries can get quite complex, enabling users to do all sorts of operations – including malicious actions which can confuse the database into performing undesired operations. Every SQL query (SELECT, INSERT, UPDATE, CREATE, etc.) has dozens of different options, allowing hundreds of variations. Combined with different variables in the FROM and WHERE clauses, they produce thousands of permutations; malicious queries can hide in this complexity. Database firewalls are used to block malicious queries by sitting between the application server and the database. They work by both understanding legitimate query structures and which query structures the application is allowed to use. Database firewalls all whitelist and blacklist queries for fine-grained filtering of incoming database requests – blocking non-compliant queries.This shrinks the vast set of possible queries to a small handful of allowed queries. Contrast this against the more generic approach of database monitoring, alerting on internal user misuse, and detection of SQL injection. DAM is excellent for known attack signatures and suspect behavior patterns, but database firewalls reduce the threat surface of possible attacks by only allowing known query structures to reach the database, leaving a greatly reduced set of possible complex queries or defect exploitations. Web Application Firewall: We include web application firewalls (WAF) in this list as they block known SQL injection attacks and offer some capabilities to detect database probing. For the most part, they do not address database denial of service attacks, other than blocking specific queries or access to network ports external users should not see. Application and Database Abstraction

Read Post

Incite 7/23/2013: Sometimes You Miss

The point of sending the kids to sleepaway camp is that they experience things they normally wouldn’t. They expand their worldviews, meet new people, and do things they might not normally do when under the watchful (and at times draconian) eyes of their parents. As long as it’s legal and appropriate I’m cool. We got a letter from XX1 yesterday. The Boss and I really treasure the letters we get because it gives us some comfort to know that they are 1) still alive, and 2) having fun. All the kids go to Hershey Park at the end of their first month at camp. So I asked in one of my daily messages, what rides did she go on? The letter told me she went on the SooperDooperLooper and also the Great Bear. Two pretty intense roller coasters. Wait, what? When we went to Six Flags over Georgia a few years ago, I spent the entire day coercing her to go on a very tame wooden coaster. I had to bribe her with all sorts of things to get her on the least threatening ride at Universal last year. I just figured she’d be one of those kids who aren’t be comfortable on thrill rides. I was wrong. Evidently she loved the rides, and is now excited to go on everything. She overcame her fears and got it done, without any bribes from me. Which is awesome. And I missed it. I was with XX2 when she rode her first big coaster. But I missed when XX1 inevitably had second thoughts on line, the negotiations to keep her in the line, the anticipation of the climb, the screaming, and then the sense of satisfaction when the ride ends. I was kind of bummed. But then I remembered it’s not my job to be there for absolutely everything. My kids will live their own lives and do things in their own time. And sometimes I won’t be there when that time comes. As long as they get the experiences and can share them with me later, that needs to be enough. So it is. That doesn’t mean I won’t become a Guilt Ninja when she gets home. But I’ll let her off the hook, at a cost. We will need to make a blood oath to ride all the coasters when we go to Orlando next summer. Me, my girls, and a bunch of roller coasters. I don’t think it gets much better than that… –Mike Photo credit: “Great Bear 2” originally uploaded by Steve White Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. The Endpoint Security Buyer’s Guide Endpoint Hygiene: Reducing Attack Surface Anti-Malware, Protecting Endpoints from Attacks Introduction Continuous Security Monitoring The Attack Use Case Classification Defining CSM Why. Continuous. Security. Monitoring? Database Denial of Service Attacks Introduction API Gateways Implementation Key Management Developer Tools Security Analytics with Big Data Deployment Issues Integration New Events and New Approaches Use Cases Introduction Newly Published Papers Network-based Malware Detection 2.0: Assessing Scale, Accuracy, and Deployment Quick Wins with Website Protection Services Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Understanding and Selecting a Key Management Solution Incite 4 U Sideshow Bob: One of the advances big data clusters offer SIEM is the capability to collect more data – particularly as vendors begin to capture all network traffic rather than a small (highly filtered) subset. As Mike likes to say, that’s how you react faster and better. But stored data is of little use unless we do something with it – such as extract actionable intel from the data. This is why I stress that you need to stop thinking about “big data” as a lot of data – big data offers a fully customizable technology platform that can help you derive information from data you collect. Don’t be awed by the size – it’s what you do with it that counts. There’s a joke in there somewhere… A big data platform can also handle much larger data, but that’s a sideshow to the main event. – AL Pick a number, any number: I have long argued that we lack the fundamental structural frameworks to even consider measuring economic losses due to cybercrime. We can barely measure losses associated with physical theft – never mind IT. For example, how do you define downtime or response time, so you can measure is cost? I’ll bet your definition doesn’t match the person who sat next to you at your last conference, and neither of you really measures it consistently over the course of a year to produce valid statistics. This is why I slam all the Ponemon loss surveys – no matter how well the survey is built, there aren’t enough people in the world actually tracking these things to provide meaningful data. So it comes as no surprise that a report released by McAfee and the Center for Strategic and International Studies pegs cybercrime losses at somewhere between $300B and $1T. I give them props for honesty – they cite the problems I mentioned and more. But not even governments can make decision based on ranges like that. Maybe we should just say “bigger than a breadbox” and be done with it. – RM Make that a triple mocha grande exfiltration: One of our favorite Canadians (tied with Mr. Molson), Dave Lewis is now writing a blog for CSO Online, and doing a great job. Not that I’m surprised – Dave is not just an epic beard with security kung fu. The dude can write and come up with cool analogies, such as how data exfiltration is like a coffee ring on the table. Huh? Dave points out that like that inexplicable coffee ring, sometimes data is just lost. Then he goes through the fundamentals of incident response and data protection. Even telling a story or two

Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.