Research

It seems that every time I write the next part of this multipart series I find myself apologizing for taking too long between posts. I swear I have a good excuse this time- with the whole doctor sticking cameras into my shoulder, shaving out bits, cutting tendons and tying them to new places, putting in plastic anchors, and sewing torn parts of muscles together thing. I’m 11 days into my recovery and while the days are fine, despite learning not to use my arm for the next three months, the nights… let’s just say I fear the nights. I think I’m getting closer to figuring out the right combination of drugs, body position, and pillows that will let me get a little closer to some functional sleep. But business is good, I’m gaining a little more productivity every day, and… enough about me. In today’s post we’re going to delve deeper into Database Activity Monitoring. We’re going to talk about alerting, workflow, and reporting. In my previous post we discussed central management, including policy creation. One of the key advantages of DAM over passive auditing and logging solutions is the ability to define policies for active alerts and manage remediation. While policies are mostly deployed in a passive mode (alerting only) some products also support active blocking, which we will cover in a future post. I’m really not a fan of relying on passive auditing for security; it’s often important, but with the tools we have today we can generate immediate alerts allowing us to contain security incidents before they spread, or even stop a multi-stage attack before completion. This is one key characteristic separating proactive security tools from simple monitoring/logging tools. Alerts Your DAM tools should support both active alerting and an incident handling queue, similar to DLP. These alerts take a few different forms, from email integration, to self-contained events, to communications with outside security tools (like SIEM) using anything from SNMP to syslog to proprietary integration. Policies should support granular alerting based on conditions, such as thresholds. For example, detection of a single errant query might trigger a low level incident within the included incident handling system, while an incident involving an administrator or high count of credit cards is emailed to a security admin and dropped into the SIEM tool as a high alert. Not to say you should rely on a SIEM or other external tool to manage your incidents; those tools will never contain the full context and investigative abilities of the dedicated DAM workflow. External alerts play a valuable role in escalating incidents and correlating with external factors, but the primary handling will tend to be managed within the DAM tool itself. Databases are complex beasts, and full understanding of what’s going on internally requires a dedicated tool. Policy based alerts tend to fall into two or three interrelated categories which often overlap: User activity: Incidents when a user takes an action that violates policy. It could be a user running a query on sensitive data, updating an existing financial transaction outside of an application, or an application running a query never seen before. Attack activity/signatures: Some DLP solutions include pre-built detection for certain attack activity. This may be linked to vulnerability analysis, signature based, or heuristic (I’m sure some vendors will chime in with even more options). System and administrative activity: Incidents involving administrative or internal system activity. E.g. new account creation, privilege escalation, DML/DDL changes, system updates. stored procedures, or other configuration changes. Think of these alerts as being focused on SQL (and non-SQL) outside of simple SELECT, INSERT, UPDATE, DELETE queries. Workflow Once an incident is created and any external alerts sent out, it should appear in an incident handling queue for management. This is similar to what we see in DLP and many other security tools, but optimized for database activity. The queue should be visually well-designed to make critical information easier to find, and allow customization for different work styles and interests. Unlike DLP, it’s less important that the queue appeal to non-technical handlers since it’s far less likely that anyone without database and security knowledge will work directly within the system. For DAM, we tend to rely more on reports for the auditors, risk managers, and other non-security types. Incidents should be easy to sort and include color coding for sensitivity and criticality. When you click on an incident, it should let you drill down into more details to assist the investigative process. Handlers should be able to assign, share, and route incidents to different users within the system. I’m a big fan of having a drop down field to change incident status right on the incident row. The system should also support role based administration, allowing you to assign specific handlers/administrators based on the policy violated, database affected, or other factors. The basic workflow must allow for quick sorting, analysis, and investigation of incidents. Once an incident is detected, the handler can close it, add supporting investigative material, change the priority, assign it to someone else, or escalate it. To support investigations you should be able to correlate the current incident with other activity in that database by that user, violations of that policy across different systems, and other factors to help determine what’s going on. Since incident handlers may come from either a database or a security background, look for a tool that appeals to both audiences and supplies each with the information they need to understand the incidents and investigate appropriately. My description has so far focused on database-only incidents, but some systems are now expanding into platform activity on the database host, or application activity. Reports As with nearly any security tool you’ll want flexible reporting options, but pay particular attention to compliance and auditing reports to support compliance needs. Aside from all the security advantages we’ve been talking about, many organizations initially deploy DAM to meet their database audit and compliance requirements. Pre-built report templates can save valuable time, and some vendors

This week, our question is courtesy of Allen: … As a long time Mac user and an inspiring security professional (i am in the process of completing my CISSP certification), I found this article on Macworld’s web site to be very fascinating. If you could please comment on this on your web site and/or on your podcast would be very grateful. The article in question, located here, is a very odd interview with Michael Barrett, PayPal’s chief information security officer. Michael argues that the main reason Safari is less secure is its lack of anti-phishing features or support for Extended Validation SSL certificates. For you non-geeks, those are extra, higher cost, digital certificates that highly trusted websites can buy to prove they are who they say they are. A few snippets: “Apple, unfortunately, is lagging behind what they need to do, to protect their customers,” Barrett said in an interview. “Our recommendation at this point, to our customers, is use Internet Explorer 7 or 8 when it comes out, or Firefox 2 or Firefox 3, or indeed Opera.” … Unlike its competitors, Safari has no built-in phishing filter to warn users when they are visiting suspicious Web sites, Barrett said. Another problem is Safari’s lack of support for another anti-phishing technology, called Extended Validation (EV) certificates. This is a secure Web browsing technology that turns the address bar green when the browser is visiting a legitimate Web site. When it comes to fighting phishing, “Safari has got nothing in terms of security support, only SSL (Secure Sockets Layer encryption), that’s it,” he said. … Still, Barrett says data compiled on PayPal’s Web site show that the EV certificates are having an effect. He says IE 7 users are more likely to sign on to PayPal’s Web site than users who don’t have EV certificate technology, presumably because they’re confident that they’re visiting a legitimate site. Over the past few months, IE 7 users have been less likely to drop out and abandon the process of signing on to PayPal, he said. “It’s a several percentage-point drop in abandonment rates,” he said. “That number is… measurably lower for IE 7 users.” This is complete and utter bunk. I’d like to reference an article at Dark Reading, on anti-phishing, and this one about a Harvard/MIT study: APRIL 13, 2007 | The lock-and-key icon was broken. The site-authentication image was not there. A security message popped up, warning that the site was not properly certified. And still, more than half of them entered a password and tried to log in. That’s the bottom-line finding of a new study from researchers at Harvard University and MIT, who conducted a live test of banking users to measure the effectiveness of browser-based authentication and anti-phishing features earlier this year. The research is scheduled to be presented at the IEEE Symposium on Security and Privacy next month. PayPal is completely off base- I highly doubt the lack of anti-phishing features correlates in any material way to Safari users dropping out of the sign in process. The level of assumptions in those statements is ridiculous. Now, let’s look at Safari. The truth is, based on talking with security researchers. that IE7 on Vista is more fundamentally secure than Safari. I’m not sure about Firefox, but suspect it is also probably more fundamentally secure. But that almost doesn’t matter- the real world risk, today, of using Safari is extremely low. That could change instantly, at any given time, and probably will, but until then I feel comfortable using it for most of my browsing needs. A bigger hole with Mac (or PC) browsing is QuickTime, which is in the midst of some rough times from a security perspective. But QuickTime runs in any browser, not just Safari. My overall take? Most users don’t understand or care about anti-phishing notifications built into their browsers. Safari does lack security features available in competitors, and has had a few vulnerabilities this year, but real-world risk is low for now. Support for extended validation certificates is a nice to have feature, but probably won’t improve Safari security for the average user in any material way. Not that we shouldn’t keep the pressure on Apple to keep strengthening the OS and browser, but I’d prefer they put more effort into sandboxing and other anti-exploitation defenses than little green borders when I visit someone willing to cough up an insane amount of cash to Verisign. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Apple, Mac, PayPal, Phishing, Security Share: