Database Security 3.0

How Do You Assess Your Vulnerability Management Profile?

It’s interesting today when you’re thumbing through analyst reports and the like to find what the hot trends in security and compliance are. Sometimes you feel as though you never really find what you are looking for, exactly.

Dark Reading recently created some Tech Centers that address very specific IT Security and Compliance components with news and analysis. Real analysis, it’s cool.

The freshly minted Vulnerability Management Tech Center published a report from InformationWeek Analytics that recommends a very straight-forward process by which organizations can address overall vulnerability management. (You have to register and its free)

What’s unique about this report is that it looks through a regulatory lens, keeping continuous compliance the goal. It’s also chock full ‘o survey data, we at AppSec love. But what is interesting about Richard  Dreger’s report is that you could pull this up and use it as a quick-reference guide to check your steps throughout an implementation process.

Here’s a few highlights:

· Of the 379 business professionals surveyed, 65% cited HIPAA as the most common regulatory requirement they are concerned with.

· 35% of organizations say they have 4+ regulations their companies are required to comply with.

· As far as compliance drivers, 59% say they fear legal ramifications being found in non-compliance. 38% fear negative audit results, 36% fear negative publicity. That’s a lot of fear, and it proves fear still makes companies do stuff.

· But you have to get down to the 36% who want to implement a comprehensive security program where you scratch your head. Why isn’t this the number one driver? Just speaks to how folks want to avoid interim strikes against them but have no intention of being proactive.

· As for recommendations, starting at the security level is good – and integrating operational guys, technical guys and management into the process is key – agreed.

· At this point I won’t give the whole thing away – but the recommended process is excellent, starting with knowing your goals, an initial configuration check, discovery, deep testing, pen testing your environment for proactive security and compliance – and finally reporting.

· The most telling figure is that only 23% of respondents said their info sec program is very secure and well-documented.

Check this report out and tell these guys they created a nice resource for our market.

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.

 

PCI - Let's Put the Data Back In the Data Security Standard

Submitted by Ted Julian

I have a feeling a lot of you have mixed feelings about PCI just like I do.  On the one hand, the standard’s motives are noble and it’s one of the most prescriptive security standards out there.  With most of PCI’s dirty dozen requirements, it’s pretty clear what you need to do.  But on the other hand, PCI has gotten both broader and deeper over time as it has added new requirements around things like wireless and Web applications, while adding additional detail to legacy requirements.  Meanwhile compensating controls remain ill-defined and largely up to the whim of assessors.

I believe that PCI has lost its way.  The combination of bloat with ample room for interpretation by assessors has weakened the standard’s effectiveness and frustrated the merchants and financial institutions that are critical to its success.  A continuation of these trends – further expanded scope and continued room for interpretation – is not likely to yield rapid improvement in cardholder data security.

 

It doesn’t need to be this way.  As we look toward PCI 2.0, I propose we get back to our roots and focus on what the standard is all about.  After all, unlike broad standards such as COBIT 27001, PCI is relatively bounded.  It’s all about card holder data.  It’s not about rock-solid wireless security or next-generation host security.  It’s not about vulnerability-free application development or holistic security management.  As an industry we have run ourselves ragged trying to secure all the conduits to the data: PCs, wired networks, wireless networks, web applications, etc.  And from a cardholder data security perspective, let’s face it – it hasn’t worked.  More of the same, can’t be the answer.

 

So, for PCI 2.0 I propose that rather than adding a 13 th requirement we bring it down to one (maybe with a few subheads).   Secure cardholder data where it lives. The solution is certainly broader than database security.  And since I work at a database security vendor, I’m certainly biased as could be.  But bear with me – using it as an example helps illustrate an important point.

 

Let’s say Retailer X has done a solid job securing the databases that house cardholder data.  They regularly scan for databases with credit card numbers in them and test those databases for misconfigurations and known security vulnerabilities.  While it’s impossible to keep them all up to current patch levels, they generally stick to their policy of within two patch levels of current.  As a result, the attack surface is well managed, bad guys don’t have a lot to hold on to, and better still, the regular scan reports document their hard work and allow them to demonstrate continuous improvement.  Second, they monitor the activity on these databases.  Not only does this help them flag insider misuse and abuse (ex. the admin trying to run off with all the credit card numbers), but tied to their scanning process it allows them to intelligently monitor those databases they haven’t yet been able to patch.  And finally, they are encrypting the credit card column in those databases to the degree possible.  In short, they’ve locked down those databases pretty tight and in the event of a breach they are likely to know immediately and the bad guys won’t likely get the goods – the data’s encrypted.

In this scenario, and relative to protecting cardholder data, why do they need a firewall?  Anti-virus?  Web application firewalls?  Wireless security?  They don’t.  With a solid data security strategy rooted in database security best practices, all of those other security measures could be compromised (or not even exist) and the data would still likely be safe.