Database Security 3.0

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.

Seatbelts, Seatbacks, and Traytables Folks - Virtualization Changes Everything

If you're not reading Chris Hoff's blog, you probably should be.  There are a ton of reasons, but among them is that he's mining the intersection of security and virtualization like no one else I know of.  There are a few mind-blowing posts, including today's which details the latest network element stack architecture ideas emerging from VMworld. 

The current collision of virtualization, networking, and security reminds me of the sea change the industry went through as everyone opened themselves to the Internet in the 90s.  The benefits were enormous and undeniable and as a result so was the reality that it was going to happen.  But so was risk as the opportunity for loss skyrocketed along with complexity. 

Ditto today with virtualization.  The agility virtualization offers is so incredibly compelling there's simply no stopping it.  But not only will our policies get an order of magnitude more complex (even more "users" doing more intimate things with our data <ahem> at a greater rate of change), so will our infrastructure. 

Between that and the ever-helpful bad guys, though, I guess job security increases too. 

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.

espresso track to your database ;-)

Around the office here, we talk a fair amount about the difficulty of securing all of the conduits to the data (wired, wireless, general-purpose hosts, packaged apps, etc.).  Firms don't have the luxury of giving up this legacy approach overnight, but clearly they are moving toward securing data more directly, a broad trend to be sure of which we play just a part.  I realized today, however, that we left a conduit out - the Internet-connected espresso machine. 

I'm sure these beauties are showing up everywhere ;-) and once that happens the customer database may be just a hop or two away.  After all, where better to store all your dosage, volume, and other crucial settings :-) 

Virtualization Changes Everything

Posted by Ted Julian

Yesterday I recapped some ideas from the first day of Gartner’s IT Security Summit here in Washington, DC.  Today, I’ll cherry-pick from Day 2 because the last session finished the day with a bang – it was the best presentation from the whole event. 

Neil MacDonald gets the “big idea” award for his presentation entitled, “Radically Transforming Security in a Virtualized World.” It was one of the most thought-provoking presentations I’ve seen in my 10+ years in the security business.  Yup, that’s not something you’ll hear me say too often.

Perhaps you’re like me and you thought the security challenge / opportunity had to do with securing virtual environments.  Like any new technology – wireless, Web applications, etc. – virtualization introduces new security problems that need to be addressed.  That may be true – but it’s not the big idea.  The big idea is that virtualization offers a new way to secure IT infrastructure with major benefits over today’s approaches. It will spawn new classes of security products that will change the world and next-generation versions of today’s security solutions that will either kill today’s security vendors or save them.

Here are a few examples Neil walked through ranging from the basic to the profound. 

• Virtual security appliances.  Now that most security appliances run on off-the-shelf hardware, why bother shipping them, powering them, cooling them and otherwise managing them.  Instead, use virtual appliances – software containers you can easily drop into your virtualized infrastructure.  Way easier to try, buy, and manage. 
• VM-spanning versions of existing security solutions.  The hypervisor / virtual machine management layer underneath all your VMs presents a ripe opportunity to do things better in several ways.  If the security function can be abstracted at the hypervisor level, a single security product VM could provide its services to all of the other VMs.  No need to build, buy, or manage distinct security agents for each VM.  One anti-virus VM, for example, could provide a-v services to all of the other VMs whether they are Windows, Linux, etc. This approach is not only easier to build, buy, and manage, it’s arguably faster and more secure.  As these security services run below the host OS of each of your VMs, they are not rootable in the same way and should run faster with more direct access to hardware.
• New, VM-spanning security solutions.  Tapping into the hypervisor / virtual machine management layer should provide a perspective on system activity that spans all the VMs.  Analyzing activity at this level yields perspective that will enable an entirely new class of security and management solutions.   

“Aliens Hacked My Database!?”

Posted by Ted Julian

Gartner’s Science Fiction Writers panel was just crazy enough to work. 

This week I’m in Washington, DC at Gartner’s annual IT Security Summit.  In case you might be familiar with it, they moved it this year from the Marriot Wardman Park in DC proper to the Gaylord National Resort across the Potomac in Maryland.  The locations could not be more different.  The Wardman Park was either historic and quaint or run-down and stodgy depending on your perspective.  But in any case it was in a true DC neighborhood and right on the Metro; so the greater DC area was just a train ride away.  In contrast the Gaylord National is relatively speaking in the middle of nowhere, brand new, and is one of the largest convention-class hotels I’ve even seen.  Think of the largest Vegas complex you know of, then make it bigger and plop it on the banks of the Potomac opposite Alexandria, VA.  In case you’re interested, development of the area is far from done, there are at least three more hotels under construction out here. 

I hope to get a few posts in from the show.  Today I thought I’d recap this morning’s quasi keynote entitled, “Science Fiction Writers Panel: Information Security and the Sci-Fi Future.”

The panelists were Arlan Andrews, Greg Bear, and Robert Sawyer.  Bruce Sterling was listed on the program, but ultimately a no-show.  If you’re into Sci-Fi you probably know one or two of these guys – there have multiple Hugo / Nebula award winners / nominations among them.  If you’re not, let’s just say this is an all-star panel.  Weird unrelated tangents, lengthy obtuse diatribes – this panel could have gone horribly wrong lots of ways.  But thanks at least in part to deft guidance by Mr. Sawyer it didn’t.  I confess I didn’t understand a fair amount of what they were talking about, but below are a few of the more interesting ideas I heard.  By all means, add your feedback for any clarifications or guidance. 

• Bacterial computing.  Mr Bear was the main proponent of this idea. His theme was that the future of IT solutions, including security, was in biology.  Bacterial computing will come after quantum computing.  Biological systems are self-programming and routinely operate without perfect information quite effectively.  For example, bacteria in our mouths and stomachs are constantly working on our behalf – how can we hack into that function to leverage its capabilities?
• The singularity.  According to Wikipedia, this “is a hypothesised point in the future variously characterized by the technological creation of self-improving intelligence, unprecedentedly rapid technological progress, or some combination of the two”  On this idea, Sawyer suggested that we were on the cusp of reaching this moment, and that for security professionals this meant that the artificial intelligence engine of your competitor would be your new enemy.  Bear suggested we are already there as computing systems, including security systems, have become so complex that even the programmers don’t fully understand them.
• Hacked by aliens!.  Andrews proposed that with quantum computing we’ll see the ability for data to transmit through time and space and that when that happens, “aliens” will be able to interact and presumable attack our systems.

Evolving Threats and Budgeting

Posted by Josh Shaul

Where did I put that crystal ball?

It occurs to me that in the information security business, managers have a tough task when it comes to budgeting. Many organizations plan and establish their budgets 9-12 months in advance. This means way back in January, February and March of 2007 many enterprises were making detailed budgeting plans for money to be spent in 2008. This gives organizations much needed visibility into how much money they plan to spend in each area and some real specifics on how the money will be spent. All good stuff when you’re trying to manage finances and run a corporation.

In many parts of the modern IT infrastructure this kind of planning works well and makes sense. Hardware ages and needs to be replaced. Buying new servers, additional storage, new network equipment, even cooling and power are all fairly predictable, particularly in well established organizations. But the challenge is quite different when it comes to budgeting for information security products. The reason for this is the evolving threat. We in the data security world are facing a constantly evolving threat, an arms race if you will, where organizations need to be nimble and react quickly to new attacks vectors on increasingly short notice. The threat in February of 2007 was different then it is today in May 2008. It will be different yet again in January 2009. The fact is, planning to spend on protection technologies more then a year in advance is hard and often requires reshuffling and reallocation of budget dollars to go where the money (and defense) is needed the most.

Over the last year or so we have seen dramatic shifts in the evolution of the threat to the sensitive data that many organizations store. We’ve gone from protecting our network perimeter with firewalls and IDS devices, to the realization that web applications leave gaping holes in the firewall….which led to a quick reallocation of budget dollars to spend on web application scanning tools, code scanning tools, and web application firewalls. Most folks were only getting started planning for and purchasing these technologies when another shift occurred. We started to acknowledge that the data that hackers want to steal mostly lives in a database. At the same time, the concept of Insider Threat has ballooned into something very real and serious, with experts stating that 80+% of attacks on data today involve some component of insider access.

Now organizations that had planned to plug sometimes small sometimes large holes in web applications with various technologies have shifted their focus to the databases for the first time. It’s fairly common today to talk to database administrators that have never scanned their databases for vulnerabilities, never applied a patch, and never enabled auditing on a production system. It’s astonishing to think about it. Databases house the “Gold” in today’s corporations and governments. Banks don’t have cash in the vault, it’s in a database. The IRS doesn’t keep your tax return dollars under a mattress some where, it’s in a database. Companies don’t keep paper files about their customers anymore, it’s all in a database. And for many, up to today the threat to those databases was not at the level of many other threats, so little or no attention was paid to those systems.

The big shift has arrived. For many it comes along with regulatory pressure to comply with various industry and government standards, such as PCI-DSS (Payment Card Industry Data Security Standard), Sarbanes-Oxley, FISMA (Federal Information Security Management Act), and several others. These regulations are often vague when it comes to IT assets and how they should be protected, but the bottom line is always the same. It’s data that is regulated, and wherever that data is stored it must be protected. For others, the concern was less about regulated data and more about pure security. “If I lose my customer data, I lose my business” is the mantra many have adopted. The threat has evolved, attackers are focusing on data stored in databases, and the market is moving aggressively to react.

Let’s go back to where we started. The challenge of budgeting long in advance for purchases of technologies that may not exist yet, or of technologies that may not yet have any relevance to your business. I don’t have the answers, but it is an interesting topic to discuss. How do you handle budgeting for IT Security purchases? Do you have a bucket of dollars allocated to emerging threats? Do you regularly revisit your budget decisions to ensure they are still in line with your business needs? Do you skip the details all together, pick a budget and then figure out how to spend it when the time comes?

This is a big challenge for many and a tough problem to overcome. Whatever type of business you work in, be sure to at least consider the nature of the evolving threat model as you plan next years security spending. If you do, when the threat changes and the time to adjust your defenses arrives, you will be very happy not to have to go reallocating, reexamining, or worst case waiting for next year in order to deal with what the hacker community throws at us.

Oracle's Remote OS Authentication

Submitted by Josh Shaul

A client recently asked me about Oracle’s Remote OS Authentication feature. What does it mean? How does it work? What’s the impact on the security of my database? There are a few interrelated components at play here, and the answers are neither simple nor well known. 

Let’s start with the basics. Oracle supports a number of authentication mechanisms, the most commonly used being database authentication and operating system authentication. Database authentication accepts a username and password, then checks these against credentials stored in the database. Oracle ships with a number of default database accounts, all of which are setup for database authentication. It’s simple to setup accounts for database authentication, when you create the user give them a password:

CREATE USER SCOTT IDENTIFIED BY TIGER

Connecting to Oracle (via sqlplus) with database authentication looks like this:

sqlplus scott/tiger

Note that both a username (scott) and password (tiger) are provided. Also note that versions earlier then 11g, Oracle passwords are not case sensitive.

Operating System Authentication relies on the OS to validate a users logon credentials. Oracle trusts the operating system to do a good job with authentication, and assuming the OS user is a valid database user, they are allowed to login to the database without supplying a password. To create an OS authenticated user, tell Oracle that the user will be identified externally:

CREATE USER OSUSER IDENTIFIED EXTERNALLY

Connecting to Oracle with operating system authentication looks like this:

sqlplus /

Note that no username or password are provided. Oracle takes the username currently logged into the OS, looks up a database user of the same name, and then makes the connection.

There are two types of Operating System Authentication supported, Local OS Authentication and Remote OS Authentication. Local OS authentication is enabled by default, and uses the local operating system (the database server’s OS) to authenticate users. Remote OS authentication is just the opposite. It is disabled by default, but when switched on, it allows a remote OS (which is any client that can make a network connection to the database) to authenticate users. Consider that for a moment. Allowing any client that can make a network connection to the database authenticate users on behalf of the database. If I can get administrative access to any machine on the network, or if I can bring my own machine in, I can create OS users on my local box with the same names as database users and easily make connections to the database. It’s almost like disabling any security for any accounts that can login via OS authentication.

This brings us to another question. Which users can login via OS authentication? This depends on two factors. First is an initialization parameter call OS_AUTHENT_PREFIX (OS authentication prefix). When users connect via OS authentication, Oracle takes the OS_AUTHENT_PREFIX value and prepends it to the OS username to create the database username. By default, the OS authentication prefix parameter is set to OPS$. In this case if I want to allow an OS user named OSUSER to connect to the database, I would have to create a database user as follows:

CREATE USER OPS$OSUSER IDENTIFIED EXTERNALLY

OS_AUTHENT_PREFIX seems simple enough, but it has a dark side. When set to the default value of OPS$, it removes the Oracle security restriction that requires users to be IDENTIFIED EXTERNALLY in order to logon via OS authentication.  This removes an important control and presents some security risk. The reason for this is backwards compatibility, with Oracle6!

What this means to our question about who can login via the OS is that if the OS_AUTHENT_PREFIX = OPS$, then any username that beings with the string OPS$ can logon via the OS. If OS_AUTHENT_PREFIX is set to any other value, only users that are IDENTIFIED EXTERNALLY  (Password column in DBA_USERS/SYS.USER$ will read EXTERNAL) and whose username begins with the OS_AUTHENT_PREFIX can login via the OS.

Ok, so now we know who can authenticate via the OS. We can also check if remote OS authentication has been turned on by examining the init.ora file (REMOTE_OS_AUTHENT parameter). While we’re there we can grab the value for OS_AUTHENT_PREFIX as well. With this information you can figure out if your database has been left open to trust remote (client) operating systems to authenticate their own users, and if so, which users in the database are susceptible to attack via a remote OS authenticated connection.

From a best practices perspective, I recommend that you disable Remote OS authentication on all your Oracle systems. It represents a significant security risk that is almost always unnecessary. I also recommend changing the value of OS_AUTHENT_PREFIX to something other then the default value of OPS$, as this opens yet another security hole. Finally, I recommend checking these settings periodically, at least quarterly on your production systems. Just because the settings look good today doesn’t mean that someone isn’t going to change them tomorrow!

Database Security Hits Home – I’m a Statistic, Pt. 1

View this photo

Posted by Ted Julian

Given what I do all day, thisis pretty ironic.  Today I got a letter in the mail that said, “your account number may have been illegally obtained as a result of a merchant database compromise and could be at risk for unauthorized use...” 

I’ll post more on this later.  But for now, a note to merchants, banks, processors, etc. – please secure your databases!

It’s 10:00 PM, Do You Know Where Your Sensitive Databases Are?

Submitted by Ted Julian

Growing up in upstate New York I remember hearing the public service announcement before the 10 PM news, “It’s 10 p.m. Do you know where your children are?”
(http://www.barrypopik.com/index.php/new_york_city/entry/its_10_pm_do_you_know_where_your_children_are/)
Not unlike security marketing FUD, it certainly was an effective message if the attention and imitation it spawned are any indication.  Multiple discussions at the office today (about customer issues and on a few media calls) reminded me of this phrase’s applicability to not only database security specifically, but data security generally. 

As techies (or in my case a wanna be) it’s tempting to dive right into the sexy features of a database security deployment, like activity profiling or privileged user auditing. But do you know which databases you’d bless with this slick functionality?  After all, with over 220 million records compromised in the last 2+ years
(http://www.privacyrights.org/ar/ChronDataBreaches.htm) and 99 incidents already in 2008 (http://attrition.org/dataloss/#2008) the risks are very real and it’d be a shame to miss one.  In other words, it’s 10 p.m. do you know where your sensitive databases are?

Any database security project, indeed I’d argue any sensible data security initiative, should start with a thorough database discovery.  Sure, we’ve got a great product (http://www.appsecinc.com/products/index.shtml) to help automate this process so this probably seems self serving.  But honestly, whether you buy ours, someone else’s, or do it manually, just be sure to build this inventory.  Experience with hundreds of customers over the years has shown that even the most tightly run IT security organizations have critical databases they don’t know about.  It’s not hard to see why – M&A activity,
a decentralized approach to IT, or simply a rapid pace of change could result in lots of orphaned databases which security staff are unaware of.  Before you jump into deploying any protective database measures, do a discovery first so that as you start with the most important databases, you don’t miss any. 

This same concept applies to assumptions about users as well.  Rich Mogull has a great entry at his Securosis blog here
(http://securosis.com/2008/05/05/information-centric-security-tip-know-your-users-and-infrastructure/ 
where he highlights the importance of knowing what users access your sensitive data before getting carried away with a DLP implementation.  Sort of like, “it’s ten o’clock, do you know whose accessing your sensitive data.”