Database Security 3.0

How Do You Protect 27% of the World’s Wealth?

An interesting story broke today that is flying under the radar. It’s being reported that Swiss Banks are in conversations with the government on sharing sensitive data. Switzerland has been called out by France for the lack of a cohesive policy around how they share highly confidential customer information.

The bulk of this discussion centers around taxes, and how foreign tax authorities are requiring information – basically because Switzerland had to make some deals with the UK, US and France to stave off a blacklisting by the OECG as being a tax haven for evasion.

What’s interesting are the data security challenges associated with whatever mandate the Swiss government enacts. Why? Because 27% of the world’s privately vested offshore wealth resides in Swiss bank accounts. Not a small chunk of change. And likely a LOT of data.

Guess where the data at most of those Swiss banks probably lives? Oh yes, multiple databases. And guess where the most coveted information exists? You guessed it, in those databases.

But the million-dollar question is do all those banks have the right database controls and protection deployed so that they can ensure that confidential information remains confidential? And will the Swiss government require the right levels of protection to comply? And once they roll out the requirements (and its announced publicly) will the hacker community pounce on it, knowing some of the banks won’t implement what they need to during this equivalent of a patch gap? Probably.

This all speaks to the issue of continuous compliance in the database and the need for a methodology that should enable an organization to know what the audit result will be before that database is audited. And it speaks to the need for the right combination of scanning and monitoring functionality to avoid that ‘gap’ which can leave systems extremely vulnerable to attack.

Is it possible we have hit the crisis point?

Our annual study with Enterprise Strategy Group usually generates a lot of buzz around what firms aren't doing to protect their most critical applications that house sensitive information - you guessed it, the database.

But what we've seen in our survey that we launched today isn't just a bunch of statistics – it’s a grim reminder that we are facing perhaps the worst of threats to our confidential data, and there are things we are either overlooking, don't understand...or, simply doing nothing about.

We polled 175 IT Security execs at large organizations, and based on some of the staggering numbers, it’s possible we may have a crisis on our hands...

The study reveals that 60% of organizations don’t feel their existing database controls adequately protect their organization’s confidential data. Coming from security executives, this doesn't inspire a lot of confidence.

In addition, the data reports that nearly 70% of organizations do not feel that their existing database controls are well-defined. Again, considering the source, if controls aren't spelled out and communicated appropriately, how can IT Security even do its job?

The survey reveals that despite the fact that over two-thirds of organizations are spending moderate to significant amounts of time writing custom scripts, remediating compliance issues, and engaging in associated tasks - which means costly manual processes are the norm. 

38% of organizations still failed database security audits, which tells us that while companies may be better this year in identifying database audits as important, they aren't taking a continuous approach to compliance. Therefore they may be passing one audit, but what happens in the next one a month or even a week later? 

The study further reveals the troubling statistic that less than 4% of IT budgets are spent protecting the data where it lives – in the database. Why is it troubling? Well, if companies looked at their overall IT Security spend and re-prioritized their misplaced spending, they'd be able to ground both their compliance initiatives and protections in the database.

 

Authorized Database Roles - Where do they go when someone leaves?

By now you know the drill - another data breach, more identity theft, more records potentially compromised. MassMutual experienced a database breach of employee information over the weekend through a contracted vendor database.

There's some information that's come to the surface already, and it appears they've been able to curb the damages and take the proactive steps to protect employees.

What this breach underscores is the fact that organizations are still not taking the right steps to protect sensitive, confidential information in a comprehensive way. What also persists to be a major issue is the lack of segregation of duties in the database.

As the unemployment rate hovers around 10% and organizations are still slashing headcount, roles and privileges to data still exist, possibly even if that employee has been let go, has moved on or has been reassigned. When those access controls still exist, organizations are at risk.

Databases contain sensitive information are large, enterprise organizations. 99% of enterprise data exists in some form inside a database. Yet with breach numbers up to 340,102,273 you'd think there would be a massive call to action for organizations who have are facing a radically scaled-up threat environment.

Beanbags and Database Security. A discussion at CSI 08.

By Josh Shaul.

The week before Thanksgiving I led a session at the CSI 08 conference in Washington, DC. It was setup as a group discussion in a small room with bean bags instead of chairs. It was a relaxed atmosphere designed to foster a philosophical discussion. In reality, there was one row of chairs at the back of the room. Everyone except one or two folks sat on chairs. The bean bags were a little intimidating. Once you sit in one of those things, there is no telling if you’re ever getting up. 

Decision Making - The Stakeholders

Our discussion was an exploration of who the stakeholders and responsible parties are in a typical corporation’s database security program. We started by reviewing a few recent data breaches, discussing how they happened and could have been prevented. With an understanding of the mechanics of a data breach, we began on discussion on responsibilities. 

It quickly became clear that not everyone in the audience knew of a database security program at their office. Some even came clean, admitting that they have no such program or effort. Those who did have a plan in place discussed radically different approaches and experiences.  

Group Authority?

A security manager at a large retailer described how his team was responsible for ensuring that databases and other applications are configured securely; in accordance with the requirements of internally developed standards. That was the good news. The bad news was that his group was not responsible for making sure databases had security patches applied. That was someone else’s responsibility. His group was also not responsible for auditing access to databases or monitoring for attacks. Those activities would also fall into other groups….if they were in place at all…he wasn’t sure.

Split up Responsibilities

Another member of the audience described that they have a policy that mandates some basic database security requirements such as strong passwords and access controls. The policy is fairly solid, but there is no one responsible for ensuring that the policy is implemented. Some systems are likely in compliance, others are not. The only people who have a chance of knowing are the system owners, and the scope of their knowledge is very narrow, they only know about the systems they personally own and manage. 

Clear ownership, No ownership

We also heard from a utilities company where there is clear ownership of policy development, and database assessment and auditing, but nobody responsible for remediation or risk reduction. This group made an investment in technology and processes to measure their security posture, but gain very little return from that investment because they rarely fix the problems they find. 

Does anyone own database security? 

According to the group I met with, no one person ultimately does. It boils down to a shared responsibility between operations teams (database admins), IT security teams, and often audit / compliance teams. The group agreed that picking a vocal leader for each of the major functions of a database security program (policy development, assessment, auditing, monitoring, and remediation) is a critical step.

Ensuring that the leaders communicate and cooperate, and are held accountable when their functions don’t deliver is the ultimate key to a successful program, but is often the biggest hurdle to overcome.

It's the Privileged Activity You're After....Not Just the Privileged Users

By Josh Shaul

It’s a problem that I see organizations struggling with every day. An audit finding has come down requiring the monitoring of privileged users in databases containing sensitive or regulated data. From the outside, this seems simple. Get a list of privileged users and log whatever they are doing. However, as folks dig into this, the first question they have to ask is who are the privileged users? And that’s where the trouble starts.

What exactly is a privileged database user? It’s probably not anyone and everyone with access to the system. Maybe it’s only the database administrators, but what exactly does that mean? Membership in a DBA or SysAdmin role? That can be very misleading, since DBA level privileges can be granted directly to a user without any role membership, or new roles with names like Not-A-DBA can be created with DBA equivalent privileges.

Maybe a privileged user is anyone with write access to the database? But that tends to include everyone, since it’s been pointed out by database security researchers many times in the past that creating a read-only database user is essentially impossible, due to all the write privileges that are typically (and often irrevocably) granted to PUBLIC (that’s everyone in the database).

Even with a firm definition of what makes a user a privileged user, the problems don’t go away. Just because a user is not privileged today, does not mean they won’t be privileged tomorrow. Actually creating and maintaining an accurate list of privileged users in an enterprise full of databases can be an impossible task.

There is another way forward though. One that is simple to define, implement, and maintain. One that meets the letter of regulations and audit findings, and one that ensures that no matter how or when a user obtained their privileges, that their activities in the database are tracked. The answer is to pay attention to the activity first, and who did it second.

While it’s hard to define what a privileged user is, it is easy to define what privileged activity is. Changes to the structure of the database (DDL) and changes to the privileges in the database (DCL) are both clear areas of privileged access that must be tracked. Changes to data (DML), particularly changes to sensitive or regulated data is another clear area of privileged access. Perhaps direct connections to a database via an ad-hoc query tool, or via MS Access or MS Excel are considered privileged access. Check out the latest Insider Threat White paper in the Application Security resource center.

In the end the exact definition of what is and is not considered privileged access is going to be dependent on the organization, the auditors involved, and the regulations that govern protection of the stored data. However, in every case, these definitions are fairly straightforward to establish, and once they are have been laid out, it’s easy to implement monitoring based on the activity type, instead of based on the user running queries.

There are a number of ways to actually implement this monitoring. All DBMS vendors provide some native auditing functionality. For the major database vendors, these audit systems allow configuration based on the commands being issued, not just the user issuing them. Native database auditing systems have a poor reputation though as a performance nightmare, so DBAs often fight hard against enabling them. There is another equally important reason not to rely on native database auditing. Those systems are under the complete control of the DBA, the exact people that we’re being asked to monitor. It is hard to prove the integrity of an audit trail when the persons being audited can enable, disable, and reconfigure the audit system at will.

A much better approach is to use a 3rd party database activity monitoring (DAM) tool. These products tend to have little to no impact on database performance, and the good ones on the market are setup such that they are not under the control of the administrators being monitored. I fully expect that in the not too distant future, IT auditors will require the use of trusted 3rd party systems to implement privileged activity monitoring, purely for the segregation of duties benefits that they bring.

If you’re facing a situation where you’ve been required to monitor your privileged users, make things simple for yourself by turning the problem on its head and monitoring the privileged access.

For more information on Database Activity Monitoring, visit the Application Security, Inc. website at www.appsecinc.com.

If you are serious about monitoring priviledged users and activity, I definately recommend checking out the Arrest the Threat white paper.

Black Hat 2008

Last week I took part in  the yearly security pilgrimage called Black Hat in Las Vegas. This years briefings were at Cesars Palace, with 8 parallel tracks ranging from App Sec and 0-Day to Reverse Engineering and Over The Air.

Day 1

I started the day out with a great refresher on everything Application Security by Jared DeMott. Anybody interested in a great general purpose intro on all the different App Sec jargon, and techniques should take a look at this once it shows up in the Black Hat archives.

Next I wanted to see Dan Kaminsky’s ‘DNS is broken’ presentation. Unfortunately clouds of people were already outside the doors and I could not get in the room. But then this got covered by the press and on various blogs in enough detail by now. So in the end, it won the ‘coveted’ most overhyped talk award at the end of day one.

After lunch I sat in the talk by Petko Petkov aka PDP. He had a great presentation mostly talking about x-site/application authentication issues. The core of his message was that we can’t take systems out of context for security testing. An application that is quite secure standalone or in a particular environment, can be used quite maliciously when integrated with another app, or ported to a new platform. For example Apple’s Quicktime™ which runs quite secure in the Mac™ environment has had a flew of issues in the recent past on Windows™.

Bruce Potter of SchmooCon fame, had probably the funniest of all presentation and should really consider a second career path as a comedian. While he did quite extensively promote his newest venture, he had some really good thoughts on presenting vast amounts of audit data. Presentation of data can make or break a security product and I’m really exited about our continued reporting enhancements in DbProtect.

Day 2

I started the day out with Arian Evans presentation about double/triple-encoding as well as transcoding attacks. This February’s highly successful SQL Worm and its more recent derivatives are using this class of attacks. Basically an attacker can circumvent all web app firewalls by properly encoding SQL code, and hide its malicious payload until the database interprets the mumbo jumbo passed through from the web sites POST command. Our security team jumped on this earlier this year, and we were able to create DbProtect activity monitoring filters and rules for these attacks.

I see this as proof, that a comprehensive security posture requires more then just perimeter protection, but that the bad guys will always find their way around these protections, and make their way to where the data is, which is where DAM really comes to shine.

Incidentally, my next stop were some short ‘turbo talks’ of which one was by Justin Clarke, who looked at the same class of attacks from a slightly different angle, and who had a really nice working attack demo.

Later this day Microsoft™ introduced 3 new security initiatives. As a security vendor I was really exited about MAPP, the Microsoft Active Protections Program. In a nutshell, Microsoft will give pre-release announcements to select 3rd party vendors for upcoming security patches, including some pretty detailed vulnerability information. This will give active protection vendors like AppSec a leg up on the hackers, allowing for release of application protection content at the same time new patches are released. Allowing IT departments to thoroughly test these new patches, while still being protected from new attacks exploiting the new vulnerabilities.

I really hope for this to be successful, and for IBM™, Oracle™, etc. to come up with similar initiatives.

Finally I was all set to go to David Litchfields talk. I had never had the chance to see him before and was really looking forward to it. Turns out he lost his passport, and by the time he got a replacement, the airfare would have been not worth it for him, to go for one day.

I can’t help it, but to be disappointed. While I don’t know how much his airfare would have been, I wish he would have thought about his audience, too.