Research

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

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