Layered Database Security in the age of Data Breaches

We live in a time of daily breach notifications. One recently affected organization in Germany put out a statement which said: "The incident is not attributable to security deficiencies." and "Human error can also be ruled out." They went on say that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." It's a tough climate we find ourselves in. It  just feels too hard or impossible at times. And there's some truth to that. There are way too many potential attack vectors for comfort.

Many breaches occur in ways that make it difficult to pinpoint exactly what might have prevented it. Or, the companies involved hide details about what actually happened or how. In some cases, they lie. They might claim there was some Advanced Persistent Threat on the network when in reality, it was a simple phishing attack where credentials were simply handed over.

In one recent case, a third party vendor apparently uploaded a database file to an unsecured Amazon AWS server. A media outlet covering the story called out that it was not hacking because the data was made so easily available. Numerous checkpoints come to mind that each could have prevented or lessened the damage in this scenario. I’d like to paint a picture of the numerous layers of defense that should be in place to help prevent this type of exposure.

Layer 1: Removing Production Data

The data should have been long removed from the database.

Assuming this is a non-production database (and I sure hope it is), it should have been fully masked before it was even saved as a file. Masking data means completely removing the original sensitive data and replacing it with fake data that looks and acts real. This enables safe use of the database for app development, QA, and testing. Data can be masked as it’s exported from the production database (most secure) or in a secure staging environment after the initial export. Had this step been done, the database could safely be placed on an insecure AWS server with limited security concerns because there’s no real data. An attacker could perhaps use the DB schema or other details to better formulate an attack on the production data, so I’m not recommending posting masked databases publicly, but the risk of data loss is severely limited once the data is masked.

Layer 2: Secure Cloud Server Configuration

The researcher should never have been able to get to the file.

A security researcher poking around the web should never have been able to access this database file. Proper server configuration and access controls should prevent unauthorized access to any files (including databases). In addition to documenting proper security configuration, certain Cloud Security Access Brokers can be used to continuously monitor AWS instances to ensure that server configurations match the corporate guidelines. Any instances of configuration drift can be auto-remediated with these solutions to ensure that humans don’t accidentally misconfigure servers or miss security settings in the course of daily administration.

Layer 3: Apply Database Encryption

Even with access to the database file, the researcher should not have been able to access the data.

At-rest data encryption that is built into the database protects sensitive data against this type of scenario. Even if someone has the database file, if it were encrypted, the file would essentially be useless. An attacker would have to implement an advanced crypto attack which would take enormous resources and time to conduct and is, for all intents and purposes, impractical. Encryption is a no-brainer. Some organizations use disk-layer encryption, which is OK in the event of lost or stolen disk. However, if a database file is moved to an unencrypted volume, it is no longer protected. In-database encryption improves security because the security stays with the file regardless of where it’s moved or exported. The data remains encrypted and inaccessible without the proper encryption keys regardless of where the database file is moved.

Layer 4: Apply Database Administrative Controls

Even with administrative permissions to the database, the researcher should not have been able to access the sensitive data.

I’m not aware of similar capabilities outside of Oracle database, but Oracle Database Vault would have also prevented this breach by implementing access controls within the database. Database Vault effectively segregates roles (enforces Separation of Duties) so that even an attacker with DBA permissions and access to the database file and encryption keys cannot run queries against the sensitive application data within the database because their role does not allow it. This role-based access, enforced within the database, is an extremely effective control to avoid accidental access that may occur throughout the course of daily database administration.

Layer 5: Protect Data Within the Database

Even with full authorization to application data, highly sensitive fields should be protected within the database.

Assuming all of the other layers break down and you have full access to the unencrypted database file and credentials that are authorized to access the sensitive application data, certain highly sensitive fields should be protected via application-tier encryption. Social Security Numbers and Passwords, for example, shouldn’t be stored in plain text. By applying protection for these fields at the app layer, even fully authorized users wouldn’t have access. We all know that passwords should be hashed so that the password field is only useful to the individual user who enters their correct password. But other fields, like SSN, can be encrypted at the app layer to protect against accidental exposure (human error), intentional insider attack, or exposed credentials (perhaps via phishing attack).

Maybe the vendor didn’t follow the proper protocols instituted by the organization. Maybe they made a human error; we all make mistakes. But, that’s why a layered approach to database security is critical on any database instances where sensitive production data resides. Security protocols shouldn’t require humans to make the right decisions. They should apply security best practices by default and without option.

Assuming this was a non-production database, any sensitive data should have been fully masked/replaced before it was even made available. And, if it was a production DB, database encryption and access control protections that stay with the database during export or if the database file is moved away from an encrypted volume should have been applied. The data should have been protected before the vendor's analyst ever got his/her hands on it. Oracle Database Vault would have prevented even a DBA-type user from being able to access the sensitive user data that was exposed here. These are not new technologies; they’ve been around for many years with plentiful documentation and industry awareness.

Unfortunately, a few of the early comments I read on this particular event were declarations or warnings about how this proves that cloud is less secure than on-premises deployments. I don’t agree. Many cloud services are configured with security by default and offer far more protection than company-owned data centers. Companies should seek cloud services that enable security by default and that offer layered security controls; more security than their own data centers. It’s more than selecting the right Cloud Service Provider. You also need to choose the right service; one that matches the specific needs (including security needs) of your current project. The top CSPs offer multiple IaaS and/or PaaS options that may meet the basic project requirements. While cloud computing grew popular because it’s easy and low cost, ease-of-use and cost are not always the most important factors when choosing the right cloud service. When sensitive data is involved, security needs to be weighed heavily when making service decisions.

I'll leave you with this. Today's computing landscape is extremely complex and constantly changing. But security controls are evolving to address what has been called the extended enterprise (which includes cloud computing and user mobility among other characteristics). Don't leave security in the hands of humans. And apply security in layers to cover as many potential attack vectors as possible. Enable security by default and apply automated checks to ensure that security configuration guidelines are being followed.

Note: Some of the content above is based on my understanding of Oracle security products (encryption, masking, CASB, etc.) Specific techniques or advantages mentioned may not apply to other vendors’ similar solutions.

A Few Thoughts on Privacy in the Age of Social Media

Everyone already knows there are privacy issues related to social media and new technologies. Non-tech-oriented friends and family members often ask me questions about whether they should avoid Facebook messenger or flashlight apps. Or whether it's OK to use credit cards online in spite of recent breach headlines. The mainstream media writes articles about leaked personal photos and the Snappening. So, it's out there. We all know. We know there are bad people out there who will attempt to hack their way into our personal data. But, that's only a small part of the story.

For those who haven't quite realized it, there's no such thing as a free service. Businesses exist to generate returns on investment capital. Some have said about Social Media, "if you can't tell what the product is, it's probably you." To be fair, most of us are aware that Facebook and Twitter will monetize via advertising of some kind. And yes, it may be personalized based on what we like or retweet. But, I'm not sure we fully understand the extent to which this personal, potentially sensitive, information is being productized.

Here are a few examples of what I mean:

Advanced Profiling

I recently viewed a product marketing video targeted to communications service providers. It describes that massive adoption of mobile devices and broadband connections suggesting that by next year there will be 7.7 billion mobile phones in use with 15 billion connections globally. And that "All of these systems produce an amazing amount of customer data" to the tune of 40TB per day; only 3% of which is transformed into revenue. The rest isn't monetized. (Gasp!) The pitch is that by better profiling customers, telcos can improve their ability to monetize that data. The thing that struck me was the extent of the profiling.



As seen in the screen capture, the user profile presented extends beyond the telco services acquired or service usage patterns into the detailed information that flows through the system. The telco builds a very personal profile using information such as favorite sports teams, life events, contacts, location, favorite apps, etc. And we should assume that favorite sports team could easily be religious beliefs, political affiliations, or sexual interests.

IBM and Twitter

On October 29, IBM and Twitter announced a new relationship that enables enterprises to "incorporate Twitter data into their decision-making." In the announcement, Twitter describes itself as "an enormous public archive of human thought that captures the ideas, opinions and debates taking place around the world on almost any topic at any moment in time." And now all of those thoughts, ideas, and opinions are available for purchase through a partnership with IBM.

I'm not knocking Twitter or IBM. The technology behind these capabilities is fascinating and impressive. And perhaps Twitter users allow their data to be used in these ways by accepting the Terms of Use. But, it feels a lot more invasive to essentially provide any third party with a siphon into the massive data that is our Twitter accounts than it would be to, for example, insert a sponsored tweet into my feed that may be selected based on which accounts I follow or keywords I've tweeted.

Instagram Users and Facebook

I recently opened Facebook to see an updated list of People I may know. Most Facebook users are familiar with the feature. It can be an easy way to locate old friends or people who recently joined the network. But something was different. The list was heavily comprised of people who I sort of recognize but have never known personally.

I realized that Facebook was trying to connect me with many of the people behind the accounts I follow on Instagram. Many of these people don't use their real names, talk about their work, or discuss personal family matters on Instagram. They're photographers sharing photos. Essentially, they're artists sharing their art with anyone who wants to take a look. And it feels like a safe way to share.

But now I'm looking at a profile of someone I knew previously only as "Ty_Chi the landscape photographer" and I can now see that he is actually Tyson Kendrick, retail manager from Chicago, father of three girls and a boy. Facebook is telling me more than Mr. Kendrick wanted to share. And I'm looking at Richard Thompson, who's a marketing specialist for one of the brands I follow. I guess Facebook knows the real people behind brand accounts too. It started feeling pretty creepy.

What does it all mean?

Monetization of social media goes way beyond targeted advertising. Businesses are reaching deep into any available data to make connections or discover insights that produce better returns. Service providers and social media platforms may share customer details with each other or with third parties to improve their own bottom lines. And the more creative they get, the more our sense of privacy erodes.

What I've outlined here extends only slightly beyond what I think most people expect. But, we should collectively consider how far this will all go. If companies will make major financial decisions based on Twitter user activity, will there be well-funded campaigns to change user behavior on Social Media platforms? Will the free-flow exchange of ideas and opinions become more heavily and intentionally influenced?

The sharing/exchanging of users' personal data is becoming institutionalized. It's not a corner case of hackers breaking in. It's a systemic business practice that will grow, evolve, and expand.

I have no recipe to avoid what's coming. I have no suggestions for users looking to hold onto to the last threads of their privacy. I just think it's worth thinking critically about how our data may be used and what that may mean for us in years to come.

Mobile Apps for Health

Jennifer Flynn (same family) who is a health field professional has a bog called Health & Productivity Thinker where she posted yesterday on Mobile Apps for Health. She asks "what type of app would you want to use for your health?"

As a security professional, I'm very interested in the answer. As an industry, we spend a lot of time focused on information privacy and health information is among the most talked about types.

Health organizations spend a fortune on personal health information protection (perhaps primarily in an effort to comply with HIPAA). Johns Hopkins and similar organizations have reported spending $4-5 Million in their early HIPAA compliance efforts. Earlier this year, the HHS fined one provider in MD $4.3M for a privacy violation. CVS paid over $2M in 2009 and Rite Aid $1M in 2010. Walgreens is currently being investigated. Early on, Gartner estimated that the industry would spend near $4B per year on HIPAA and the HHS estimated it would cost the industry $18B in the first decade. (I couldn't find current/actual numbers)

So, protection of consumer health information is a big deal. A lot of time, money, and energy is expended in the process. But do people really care? If someone gave you an app for your phone that enabled you to carry around your complete medical history for easy distribution to doctors and health providers -- and it meant you'd never have to fill out another form in a doctor's office waiting room -- would you use it? My guess is that most people would. If it makes life easier, it will get used regardless of the privacy risk.

We all know that our phones and computers are susceptible to privacy breaches, eavesdropping, and other data leakage, but would that stop you from using an app that improved your health? Made life easier? I'd love to know, so if 2000 of you would please go answer Jennifer's question, I'd appreciate the info.

Security must be Easier or Cheaper

Remember when I said that end-users (i.e. People) are motivated more by "easier" and "cheaper" than they are by "more secure"? Well I did. And they are. If this MSNBC article doesn't make the point, I don't know what will: Why should I care about digital privacy?

The article discusses how a number of people sitting in a coffee shop were actively hacked & eavesdropped, alerted to the hack, and they chose to simply ignore the alerts, continue browsing and even making online purchases.

I was once in the audience while security guru Bruce Schneier was speaking. He made the point that while the security industry is all jazzed up about privacy, all of our efforts may not have much impact because the people we're concerned about ("young people") just don't care. They live their lives on-line and don't have the same ideas about privacy that us old people have.

There is an on-going debate about whether sending (texting) a nude photos of oneself while underage is a criminal offence worthy of a 'sex offender' label. The simple fact that we need to have that debate is evidence that Schneier is right.

I find more evidence when I ask any facebook user about privacy. It seems to be common knowledge among young and old that facebook users should be concerned about privacy. There are unanswered questions about personal information. [I'll give facebook the benefit of the doubt for this discussion and say that the security tools are in place to protect yourself if you're knowledgeable and cautious. But that's a big IF.] The fact is, most seem to think that facebook is not secure, yet they continue to use it. Because it's a cheap and easy way to communicate with friends, stay in touch with gossip, get news, play games, etc. For any security mechanism to be truly effective in an environment where security can not be mandated (corporate setting), like the general public, it needs to be (say it with me) easy and cheap. Easy as in built-in and transparent. Cheap as in Free.

btw, SSL (secure browsing over HTTPS) is sort of like that, until some CA (not mentioning any names but maybe sounds like a type of dragon) gets breached and generates bad certificates. Then, it's less easy. Also, SSL requires that an end user actually observe the browser to confirm that it's a secure connection. And in reality, the observation only tells you that you're connected to a secure page right now - it doesn't tell you where the submission form will take you. So it's really only secure if we're trusting the sites we visit or are unusually saavy web users.

Business Case for Claims-Based Authorization

Jackson Shaw provided a great use-case for claims-based authorization this week. While I've always seen the value of the claims-based approach, I've always felt that the thing that's missing is the motivation. End-users and consumers are typically motivated by what is easier or cheaper. Corporations, similarly, are motivated financially and not, as we might hope, by security or privacy as an end in itself. But his example, which applies to any major corporation who gives discounts based on employer (hotels, car rentals, wireless phones, etc.) shows that there are millions of dollars on the line.

$$$ = motivation

It might be just what corporations need to push them toward adoption -- and that includes providing incentives for customers to move to a claims-based model. I think mobile phone companies are situated perfectly - they can provide the authentication mechanism built into the devices they sell, which makes it potentially easier for users to browse the web (could solve the 'numerous passwords' problem) - remember:

Easier = motivation

...and they have a huge financial motivator because many big companies negotiate mobile plan discounts for employees.

But perhaps budgets can be pooled together by a consortium of companies that are losing money to create a compelling solution that end-users will want to adopt. And in the end, we'll see better security and privacy as a result.

Online Identity Privacy - Users Don't Take Precautions

One of my tenets for online privacy is:

Don't do anything online that you absolutely want to keep private.

Case in point:

I was looking through the form submissions to my company's web site. There is consistently some percentage of submissions that are auto-submitted SPAM. Sometimes, it's obvious and sometimes not.

Today, I was researching one submission and googled her name and email. The search brought me to a page that listed a spreadsheet of form submissions to another site - complete with names, email, phone numbers, and comments. Some obvious spam, but others obviously real.

They're showing up because of a technical glitch or security issue on the site. The google search brought me directly to the site's administrative page with no logon.

What makes this story interesting is that the site is a Las Vegas escort service and some of the form submissions read as follows:

• From a student (@uwec.edu) - "very interested"
  
• From a student (@wvu.edu) - "I need a price on ____"
  
• From someone claiming to work at Microsoft - "Hi, I'm planning a trip to Vegas with my fiance but I wanna get away from her for one night. What is the limit to your services and who would you recommend? I need a girl with _____. Thank you for your time." (how polite) ...he may not have put his real company, but another quick search found his email address with a profile telling me that he lives in Seattle(!)
  
• From a Web Developer in MN - "I am interested in an escort to accompany me to dinner" - (I found his LinkedIn profile because he provided his real company name)

...you get the idea.


Two lessons:

• First, the obvious one - don't trust web sites to keep your information private.
  
• Second, (to the security practitioners who read this blog) - don't underestimate how willing people are to give up their personal information to even the most suspect organizations.

btw - Who thinks this privacy breach will be reported?

Know what you're protecting against

You know that advertisement where the CEO (Todd Davis) gives out his social security number and tells you how secure it is because he uses his company's product to protect his identity information? Well, there have been 20 people who used his social security number to get a drivers license. And there was one "guy in Texas who duped an online payday loan operation last year into giving him $500 using Davis' Social Security number".

Today, I read a few articles (including this one and this one) that suggest that LifeLock should be chastised because it doesn't protect you against everything that one might think it should. My first reaction was to agree with the writers. I always knew there was no way for a product to protect your SSN against any or all unwanted uses. And they shouldn't claim it does. And ha ha for Mr. Davis' identity being compromised.

But, then I read Davis' rebuttal, "There's nothing on my actual credit report about uncollected funds, no outstanding tickets or warrants or anything" and I realized that this isn't really a case of a product not doing what it claims to do. It's a case of mis-aligned expectations about what a product can (or should) do.

It reminded me of all the times I've heard that some strong authentication technique isn't effective because it's susceptible to man-in-the-middle techniques. Sure it is, but that's the wrong problem. SSL was developed to solve that problem. There are certainly issues with SSL (mostly around user experience and education about how it works), but strong authentication is not the answer.

In the same way, there are problems with relying on SSN as authentication. And LifeLock won't protect against that. But, if it keeps your credit report clean, then maybe it's doing what it's supposed to. I haven't really followed the ads and I have no idea what the company promises its customers, but I thought I'd use this opportunity to remind you of the old cliche – there is no silver bullet. Analyze your risks and know which types of threats a security solution will be effective at protecting you against.

Correctly aligned expectations yield happy customers.

Data Loss Worse Than I Thought

Here is the list of Data breaches provided by the Privacy Rights Clearinghouse. We keep hearing about the same two or three events (VA, TJX), but there seems to be a new one almost every day. And the data is sneaking off the network in almost as many new ways as there are incidents. If you're building a data security policy, this list can be helpful in identifying areas where policies can be useful.