Database Security 3.0

Team SHATTER Database Vulnerability 4 of 10 – Minimize your attack surface

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Database Management Systems (DBMS) have extended far beyond the simple data storage systems that they were in the early 1970s and are now impressive software packages  in their own right.  They now offer many features to analyze and report on data, run Java and other extensible languages, and even have various levels of OS access built in.

These features provide database application developers with a lot more power when working with a DBMS.   The flipside of the coin is, the more power you give a developer, the more attack vectors you potentially expose to the bad guys.

Many of these features are optional and are not required by applications accessing a Database Management System. DBMS vendors like to include all the bells and whistles in order to up-sell opportunities.

In this week’s edition of our Database Vulnerability of the Day series, we will highlight various optional components and features that should be removed or disabled – unless there is a valid business reason to make them available.

In our Team SHATTER Vulnerability of the Day series on Twitter, we will provide you with what and how to check for to mitigate these risks. To stay informed on the Top 10 Database Vulnerabilities follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 3 of 10 – Extensive User/Group Privileges

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is about extensive privileges assigned directly to users or indirectly through user groups.

There are two very important concepts that apply to information systems security controls: separation of duties and the principle of least privileges.

Separation of duties manages conflicts of interest and implements an appropriate level of checks and balances on an individual’s activities to ensure they do not have toxic privilege combinations.

The principle of least privileges requires that users have the least amount of privileges required to perform their specific tasks – only they the data they need and nothing more.

The process of collecting a comprehensive list of all rights that a user has can become a daunting task. Privileges aren’t typically just assigned directly to the users they also inherit privileges from groups or roles they belong to.

In this week’s edition of our Database Vulnerability of the Week series, we will highlight several important rights, privileges and common groups to look out for when reviewing user and group rights, as well as group memberships.

In our Team SHATTER Vulnerability of the Day series on Twitter, we will provide you with what and how to check for to mitigate these risks. To stay informed on the Top 10 Database Vulnerabilities follow @TeamSHATTER on Twitter.

Compliance Mandates Met Some Teeth.

According to Dark Reading, the bottom lines of two companies were hit over the past

several weeks due to data breach fines. The Financial Industry Regulatory

Authority (FINRA) fined one firm $375,000 while the Florida Attorney General fined another $975,000. Read the full article here:

http://www.darkreading.com/database_security/security/attacks/showArticle.jhtml

Are Data Breach Notification Laws The Right Approach?

Nearly every state has a data breach notification law. Most recently, Mississippi passed a law requiring organizations to notify residents of any breach impacting personal identifiable information (PII).  PII is defined as records that contain the first name and last name or first initial and last name plus any of the following:

• Social Security number
• Driver's license or state-issued identification card number
• Financial account number
• Credit or debit card number

Only four states have not passed data breach notification laws. They are Alabama, Kentucky, New Mexico, and South Dakota. It is highly likely that they will follow suit in the near future.

The only state that has gone above and beyond these notification laws is Massachusetts. The state has taken a more proactive approach to sensitive information and recently passed the Massachusetts Data Privacy Law 201 CMR 17 (March 1, 2010). The law requires the establishment of a comprehensive information security program to ensure every Massachusetts resident is protected against identity theft or fraud.

Mass 201 impacts nearly every large organization. The law doesn’t care where the business is located –if information about a Massachusetts resident’s PII has been collected, the regulation applies. And if an organization doesn’t comply with the law it can result in penalties of up to $50,000 for each instance.

 

What really confuses me is why has it taken so long for other states to follow? And is establishing data breach notification laws based upon a map really the right approach? I mean if data breaches never happened, no one would need to be notified… proactively securing sensitive data in order to prevent breaches sounds much more sensible AND ultimately more cost effective. If I stop by my local retailer on the way home from work tonight, I’d feel a lot better knowing  that my sensitive information is secure  --  rather than knowing that they’ll let me know if it’s compromised.

To learn more about the Mass 201 law, check out our Website. 

 

XVZAPQWT57WH

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.