Evolving Data Security Involves Database Architecture

Tom Basiliere, CIO, Provant

Tom Basiliere, CIO, Provant

A few weeks ago, my wife got a call from my daughter. She called to ask us about the risk of using a mobile funds exchange service that required her to enter her bank account number into a mobile app so that funds could be transferred in and out of her bank account. Wisely, she worried about a hack to the app that could result in her bank account being compromised and about whether the bank would be responsible for guaranteeing her funds. I’m not sure we gave her a definitive answer but it made me think; is there anyone in the developed digital world we live in today who is not asking “Is my information safe?”

Businesses are asking the same question. The first thing I’m asked by a new or prospective client is “How are you protecting sensitive data?” It’s a broad question and it seems to be on the minds of C-level, manager and procurement level people in every company, especially after the very public stories of data loss coming from some of the world’s biggest companies. More recently, the threat of a data breach has expanded to include the threat of a ransomware attack. While the first scenario creates risk of sensitive data being exposed publicly, the second risks data being lost or a company being shut down altogether. Both are scary and very expensive to recover from.

While traditional protection methods, like firewalls, encryption and multi-factor authentication, help, there is no single answer to protect data against all threats. However, the idea that a business can evaluate the risk of a breach and make an ROI decision on investing in security is outdated. It is no longer a decision but instead is a basic tenet of doing business in an ever-changing digital world. Knowledge about your data and how it is stored is fundamental to surviving audits and designing protection that lets you sleep at night.

Information security audits that result in a SOC2 or HiTrust certification are deemed as good benchmarks for a company's commitment to protect data. It’s true that both force a company being audited to evaluate, correct and maintain internal processes, as well as technology infrastructure that protects data. They also require standards around password change frequency, security training for employees and patch management.

All of these things help assure that the most common vulnerabilities are dealt with and that all reasonable steps are being taken to protect information. However, most of these methods are focused on putting a fence around applications and databases that were not necessarily designed with security in mind when they were built. I believe that the way the security space will evolve includes getting into the database architecture itself. What do I mean by this? Let’s start by defining two types of data. The first is data that belongs to a person. This includes PII (Personally Identifiable Information) and PHI (Personal Health Information) as well as other categories. By definition, these are only sensitive, and therefore are targeted, because they are tied to a person. Knowing who the data belongs to gives it value. For instance, a birth date isn’t valuable by itself but if it is tied to a person, it definitely does have value. Combine a birth date with gender and a geographic data point (like city address) and there are plenty of ways to figure out the exact person to whom the data belongs, even if their name is unknown. In contrast, individual data points like height, weight, BMI, salary, or prescription drugs taken are of no value without linking them to a person.

Knowledge about your data and how it is stored is fundamental to surviving audits and designing protection that lets you sleep at night

The second type of data is harder to “de-identify” and harder to secure because it has value in and of itself. A list of software vulnerabilities or a decryption code is hard assets and valuable to someone who wants to cause harm. Sure, a list of people who are using the vulnerable software is of value too, but is not necessary to do real damage if the wrong person gets their hands on information like this.

Architecting for security involves rethinking how you structure databases and applications. This includes when you should use logical versus physical separation of data as well as how you minimize the need to access the data points that create truly identifiable and therefore valuable information. If you create a random identifier to store with a transaction, and remove all the PII in the process, you’ve made the transaction data less valuable and reduced your risk. There are very few systems or workers who really need to know to whom that transaction belongs.

At the end of the day, protecting information is hard. Broad use of strong encryption, like cryptography, is coming and will help companies protect data better. However, there aren’t a lot of experts to help you figure out what it is and how to use it today, so don’t expect to find a silver bullet out there waiting for you. As a technology leader, you need to take data security seriously and make it a priority. No matter what your role is in the organization, you need to convince those above and around you that your company needs to deal with this. If they haven’t already, customers and consumers will soon be knocking on the door asking for more proof of protection against the latest threats. The risks are just too great.

Three things to do this month are:

• Get educated

• Talk to your peers, go to a conference, listen to a security podcast

• Spend some time and money on security architecture

• Look for independent outside help but don’t defer responsibility to them.

• Ask your application, database and infrastructure teams a simple question: “Is our data secure?”..