“It is possible for us to learn how to control our own uses of technology.”
—Niel Postman, American educator, media theorist, and cultural critic, 1931-2003.
In our previous post on performing discrete range searches, we proposed a general algorithm for performing discrete range searches on databases protected with Format-Preserving Encryption (FPE) at the data item (or field) level, the highest level of database protection possible. Earlier, we discussed how implementing FPE with partial data item protection eliminated the need for re-identification in over 90% of business use cases. We’ve also suggested that using alternative column encodings of sensitive data items allows us to perform secure analytics using clear-text, non-sensitive, “loss-full” equivalents of genuinely sensitive data. And we started off this series by noting how enforcing third-normal form (3NF) in database table design removes the need to protect database primary and foreign key columns in the first place.
These posts have been, for the most part, theoretical. Postman is correct that we security professionals need to learn how to control our own uses of data item level FPE technology, mostly by learning from practical examples. Which is what this article is all about: we’ll consider several real-world use cases. And examine creative ways we can accomplish our objectives using protected data.
Customer Verification Via Interactive Voice Response
I’m sure you’ve called customer service in conjunction with a financial product and heard an Interactive Voice Response (IVR) system say something rather similar to the following:
Thank you for calling Weasel Global Financial Services. Please enter the last four digits of your account number.
Thank you. To confirm we have looked up the correct account, please enter the last four digits of your social security number.
Assuming you entered the correct responses, the next IVR message might be the main menu. Now how does this use case fit in with database security?
Part of this interaction relies on the capabilities of the IVR system itself. The IVR receives a block of data including your originating phone number. Before starting the call, the IVR takes that number, protects it, and then looks for a matching row in a protected database. The IVR can answer the call, play a script, and use your voice or keypad responses to verify you are authorized to access the account. Using partial protection allows the IVR to perform this validation without performing additional database queries.
Most loyalty programs, such as frequent flyer, shopping club, or a movie discount programs, ask for a birthdate at registration. Why? Well, one common reason is to offer members discounts, free stuff, or greetings on their birthdays. However a birthdate is personally identifiable information (PII) and often protected when stored in the loyalty program’s records.
If those birthdates are protected, how would the program know whom to send birthday greetings? Well, there are two possible solutions. The first is to create an alternative column encoding of just the birth day and month (DD/MM) without the year. Then we could use this column directly for many anniversary related queries, including quarterly reminders.
If our governance standards, however, consider birth day and year to be sensitive information, we need another technique, namely a discrete range search. Let’s assume our loyalty program does not contain a person under thirteen years of age—as this is illegal in some cases. And also assume that all of our members are under one hundred and thirteen—while it’s possible to live longer, that’s very rare. This gives us only one hundred discrete items to search for. The pseudo code would look something like this:
currentDate = today();
for age = 13 to 113 ageList += protect(currentDate – age);
SELECT id, access(name), access(email)
WHERE birthdate IN (ageList);
This pseudocode creates a list of protected birthdates from 13 to 113 years ago and then performs a discrete range query. We use the unprotected result set to update each member’s reward status and also send an email greeting.
Early Prescription Abuse Detection
Health care companies are in a bind when saving lives by detecting prescription abuse as early as possible. First, the industry is bound by the Health Insurance Portability and Accountability Act (HIPAA) to protect multiple Protected Health Information (PHI) fields, including names, addresses, dates, prescription names, and any other data item that may be reasonably used to identify a person’s past, present or future health condition, care, or payment. So most health care databases are protected.
How can we possibly find prescription abuse early when all of the PHI surrounding a patient is protected? Well, first we need to ask ourselves how do we detect such abuse?
We define prescription abuse as a patient filling a prescription more frequently than allowed by one doctor. So if we can find a person (whose name we do not know) who fills the same prescription (whose medicine ID we do not know) multiple times within the same month (which we know as a time stamp does not reasonably identify a person), we have good reason to believe abuse is taking place.
There are third-party data science organizations that can take an encrypted data set and, as long as the timestamps are in the clear, perform analytics to detect prescription abuse—as fast as two hours after the abuse occurs. The result set is protected yet small. And authorized personnel may decrypt the result set to intervene as necessary.
If PHI data is not protected, HIPAA’s privacy regulations outright ban the sharing of that data with a third-party firm. However protecting PHI allows hospitals and health insurers to use outside services and save lives.
In our next post, we’ll wrap up key takeaways from this blog series on relational database security. Meanwhile what are your thoughts on use cases for protected data? Have you written a customer service application that used protected data? Performed useful analytics on mostly protected data? If you have a thought on these matters, please leave a note in the comments section below.
 Wikiquote, Wikimedia Foundation, Inc., 14 May 2019, en.wikiquote.org/wiki/Neil_Postman.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.