Research

According to IBM’s ISS (via eWeek), the number of publicly reported vulnerabilities dropped in 2007. Pete Lindstrom cautiously (unusual for him) wonders if this means we’re over the hump. I wanted to pick on Pete, but he was cautious enough in his wording that I don’t get to go all crazy and have too much fun at his expense. Here’s what I think is going on: More researchers sell vulnerabilities. There is a big market, and I’m not just talking about the Zero Day Initiative or other “public” programs. Both good guys and bad guys are quietly buying them up. Some researchers report vulnerabilities and don’t disclose them in public. I know at least a few who leave it up to the vendor to reveal any details. Some irresponsible researchers and bad guys just pass them around in the dark, never issuing a disclosure. I suspect a fair few of these make it into the light eventually. There is high risk to the researcher in disclosing web application vulnerabilities, since that’s effectively hacking someone’s site and is rarely, if ever, legitimate (or legal). There is a lot of money involved in security research these days. Some of it good, some of it bad. Also, some researchers just don’t want to deal with the hassles and ugly tactics of certain vendors, while others don’t feel the need to disclose in public. Overall, the landscape for reporting has changed in big ways over the past couple years, but I highly doubt the lower numbers are in any way related to an actual reduction in code vulnerabilities across the industry. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Vulnerabilities Share:

I’m pretty angry right now. I just went to vote in the primary. In hand was my driver’s license and voter ID card. Because the addresses didn’t match, I wasn’t allowed to vote until I showed another form of ID with matching addresses. I, of course, didn’t have one. None of the materials mailed to us or displayed in our polling place mention this requirement. The thing about AZ is that our licenses don’t expire for a really long time, and as long as you register your new address with the state they don’t re-issue your license. Thus, the odds are very high you’ll have an ID with a different address than where you live. Digging through the car we found the sample ballots mailed to us. It turns out anything with your name and address on it, including utility bills, is considered a valid ID. They let us skip the line and vote. From a security perspective this does nothing to reduce voter fraud. Most of the illegals in the area who are willing to risk registering and trying to vote can easily produce a utility bill, and that combined with the voter ID card mailed to them will work just fine. Pretending to be someone else? I suppose you could pull that off, but you’d know the ID requirement and their name going in and could easily fake it. I won’t go all civil-liberties on you and talk about how these ID requirements are generally class warfare. We did get to vote, but perhaps any of you legal types out there will have fun with this hidden requirement, never mentioned in any materials mailed or posted. The poll workers were very frustrated with the requirement. They informed us most people had an updated vehicle registration of insurance card they could scrounge up, and nearly everyone was allowed to vote. Needless to say, we’ll be filing a complaint. Share:

There are a lot of things I love about working for myself, but I have to admit sometimes it’s hard to keep everything balanced. For a while there I was taking whatever work came in the door that aligned with my goals and didn’t violate my objectivity requirements. Needless to say, the past few months have been absolutely insane; deadline after deadline, 2-3 trips a month, and a heck of a lot of writing. The upside is I’m ahead on my goals for the year. The downside, other than a little stress, is that I haven’t been able to keep the content on the blog up as high as I’d like. How can I tell? This is part 3 of my series on Database Activity Monitoring, and I last posted part 2 in the beginning of November. Oops. With that mea culpa out of the way (assuming Jews are allowed to mea culpa), let’s jump back in to DAM. Part 1 Part 2 Today we’re going to start on the basic characteristics of the central management server, including aggregation and correlation and policy creation. Tomorrow (for real) we’ll cover alerting, workflow, and reporting. Aggregation and Correlation The one characteristic Database Activity Monitoring solutions share with log management or even Security Information and Event Management (SIEM) tools is the ability to collect disparate activity logs from a variety of database management systems. Where they tend to exceed the capabilities of these related technologies is their ability to not only aggregate, but to normalize and correlate events. By understanding the Structured Query Language (SQL) of each database platform, they can interpret queries and understand their meanings. While a simple SELECT statement might mean the same thing across different database platforms, each database management system (DBMS) is chock full of its own particular syntax. A DAM solution should understand the SQL for each covered platform and be able to normalize events so the user doesn’t necessarily need to know the ins and outs of each DBMS. For example, if you want to review all privilege escalations on all covered systems, the DAM solution will recognize those events regardless of platform and present you with a complete report without you having to understand the SQL. A more advanced feature is to then correlate activity across different transactions and platforms, rather than just looking at single events. For instance, smart DAM tools can recognize a higher than normal transaction volume by a particular user, or (as we’ll discuss in policies) tie in a privilege escalation event with a large SELECT query on sensitive data, which could indicate an attack. It also goes without saying (but I’ll say it anyway) that all activity is centrally collected in a secure repository to prevent tampering or a security incidents involving the repository itself. Since you’ll be collecting a massive volume of data, your DAM tool needs to support automatic archiving. Archiving should support separate backups of system activity, configuration, policies, alerts, and case management. Policy Creation One of the distinguishing characteristics of Database Activity Monitoring tools is that they don’t just collect and log activity, they analyze it in real time for policy violations. While still technically a detective control (we’ll talk about preventative deployments later), the ability to alert and respond in practically real time offers security capabilities far beyond simple log analysis. Successful, loss-bearing database attacks are rarely the result of a single malicious query- they involve a sequence of events leading to the eventual damage. Ideally, policies will be established to detect the activity early enough to prevent the final loss-bearing act. Even when an alert is triggered after the fact, it supports immediate incident response and investigation far sooner than analysis days or weeks later. Policies fall into two basic categories, and I’m sure some of the engineers working on these products will drop additional options down in the comments: Rules-based: Specific rules are set up and monitored for violations. They can include specific queries, result counts, administrative functions (new user creation, rights changes), signature-based SQL injection detection, UPDATE or other transactions by users of a certain level on certain tables/fields, or any other activity that can be specifically described. Advanced rules can correlate across different parts of a database or even different databases, adjusting for data sensitivity based on DBMS labels or through registration in the DAM tool. Heuristic: The DAM solution monitors database activity and builds a profile of “normal” activity. Deviations then generate policy alerts. Heuristics are complicated and take proper tuning to work effectively. They are a good way to build a base policy set, especially with complex systems where manually creating deterministic rules by hand isn’t realistic. Policies are then tuned over time to reduce false positives. For well-defined systems where activity is pretty standard, such as an application talking to a database using a limited set of queries, they are very useful. Heuristics, of course, fail if you profile malicious activity as known good activity. The more mature a solution, the more likely it is to come with sets of pre-packaged policies. For example, some tools come with pre-defined policies for standard deployments of databases behind major applications, like Oracle Financials or SAP. Yes, you’ll have to tune the policies, but it’s far better than starting from scratch. Pre-built policies for PCI, SOX, and other generic compliance requirements may need even more tuning, but will help you kick start the process and save many hours of custom policy building. Policies should include user/group, source/destination, and other important contextual options. Policies should also support advanced definitions, like complex, multi-level nesting and combinations. Ideally, the DAM solution will include policy creation tools that limit the need to write everything out in SQL or some other definition language. Yes, you can’t avoid having to do some things by hand, but basic policies should be as point-and-click easy as possible. For common kinds of policies, like detecting privileged user activity or count thresholds on sensitive data, policy wizards are extremely useful. Content-Based