Research

Securing Personal Health Records (PHR) for healthcare providers is supposed to be the next frontier for many security technologies. Security vendors market solutions for Protected Health Information (PHI) because HIPAA and HITECH impose data security and privacy requirements. Should a healthcare provider fail in their custodial duty to protect patient data, they face penalties – theoretically at least – so they are motivated to secure the data that fuels their business. Tokenization is one of the technologies being discussed to help secure medical information, based on its success with payment card data, but unfortunately protecting PHR is a very different problem. A few firms have adopted tokenization to substitute for personal information – usually a single token that represents name, address and Social Security number – with the remainder of the data in the clear. But this use case is a narrow one. The remainder of the health-related data used for analysis – age, medical conditions, medications, zip code, heath care, insurance, etc. – can be used while the patient (theoretically) remains anonymous. But this usage is not very effective because it’s part of the medical, billing and treatment data that needs to be anonymized. It has not yet been legally tested, but a company may be protected if they substitute a person’s name, address, and Social Security number, even if the rest of the data should be lost or stolen. Technically they have transformed the records into an ‘indecipherable’ state, so even if a skilled person can reverse engineer the token back into the original patient identity, the company has reduced the risk of penalties. At least until a court decides what “low probability” means. So while there is a lot of hype around tokenization for PHI, here’s why the model does not work. It’s a ‘many-to-many’ problem: we have many pieces of data which are bundled in different ways to serve many different audiences. For example, PHI is complex and made up of hundreds of different data points. A person’s medical history is a combination of personal attributes, doctor visits, complaints, medical ailments, outsourced services, doctors and hospitals who have served the patient, etc. It’s an entangled set of personal, financial, and medical data points. And many different groups need access to some or all of it: doctors, hospitals, insurance providers, drug companies, clinics, health maintenance organizations, state and federal governments, and so on. And each audience needs to see a different slice of the data – but must not see PHI they are not authorized for. The problem is knowing which data to tokenize for any given audience, and maintaining tokens for each use case. If you create tokens for someone’s name and medical condition, while leaving drug information exposed, you have effectively leaked the patient’s medical condition. Billing and insurance can’t get their jobs done without access to the patient’s real name, address, and Social Security number. If you tokenized medical conditions to ensure patient privacy, that would be useless to doctors. And if you issue the same tokens for certain pieces of information (such as name & Social Security number) it’s fairly easy for someone to guess the tokenized values from other patient information – meaning they can reverse engineer the full set of personal information. You need to issue a different token for each and every audience, and in fact for each party which requests patient data. Can tokens work in this ‘many-to-many’ model? It’s possible but not recommended. You would need a very sophisticated token tracking system to divide up the data, issuing and tracking different tokens for different audiences. No such system exists today. Furthermore, it simply does not scale across very large databases with dozens of audiences and thousands of patients. This is an area where encryption is superior to tokenization. In the PHI model, you encrypt different portions of personal health care data under different encryption keys. The advantage is that only those with the requisite keys can see the data. The downside is that this form of encryption also requires advanced application support to manage the different data sets to be viewed or updated by different audiences. It’s a many-to-many problem, but is feasible using key management services. The key management must be very scalable key to handle even a modest community of users. And since content is distributed across multiple audiences who may contribute new information, record management is particularly complicated. This works better than tokenization, but still does not scale particularly well. If you need to access the original data at some point in the future, encryption is your only choice. If you don’t need to know who the patient is, now or in the future, the practical alternative is masking. Masking technologies scramble data, either working on an entire database or on a subset of the data. Masking can scramble individual columns in different ways so that the masked value looks like the original – retaining its format and data type just like a token – but is no longer sensitive data. Masking also is effective for maintaining aggregate value across an entire database, meaning the sum and average values within the data set can be preserved while changing all the individual data elements. Masking can be done in such a way that it’s extremely difficult to reverse engineer back to the original values. In some cases, masking and encryption provide a powerful combination for distribution and sharing of medical information. Tokenization is an important and useful security tool with cost and security advantages in select use cases – in some cases tokens are recommended because they work better than encrypted data. The goal is to reduce data exposure by reducing the number of places sensitive data is stored – using encryption, tokenization, masking, or something else. But every token server still relies on encryption and key management to safeguard stored data. End users may only see tokens, but somewhere in the tokenization you can always find encryption services supporting it. We recommend tokenization in various

With the two girls at sleepaway camp, the Boss and I weren’t sure how the Boy would handle it. After all, he’s pretty much always surrounded by someone. Having a twin sister will do that to you. If he’s not at school, with his buddies, or doing an activity, he’s usually playing with one of his sisters. In fact, we think his ability to tune out almost everything directly correlates to always being around people. But don’t think the summer is only fun and games. I described Mommy Food Camp last week, and he’s doing well. He eats hot dogs now (“I don’t like them, but I’ll eat them”), and I even got him to eat a hamburger (“It was horrible!”). He’s now thinking of becoming a vegetarian (like his Dad), and tried to convince me that there’s no meat in Chicken Nuggets. He may actually be right, but that’s another story. We were also hoping he would become a bit more assertive, as he tends to be pretty quiet. We learned this was a non-issue when he had a tantrum at day camp when he wasn’t in a group with his buddies. Suffice it to say, the situation was rectified immediately, and we didn’t have to get involved. Of course, we’d like him to deal with things without crying and screaming, but he has friends who were put in the wrong group and didn’t say a word for days. We’ll take Mr. Assertive any day of the week. Truth be told, I think he likes the peace and quiet. We joke that the only time he had any peace was the minute after his sister was born, while he was waiting his turn. We do let him play on one of the iPads a bit and maybe watch a little TV, but nothing crazy. We’re glad he’s enjoying the few weeks he’s flying solo because the plan is to send him to sleepaway camp next year. Even though he maintains that he doesn’t miss his sisters, we make him write letters to them anyway. It’s as much to keep him writing as anything else, though we know the girls love to hear from him. He wrote a nice letter, telling them what’s he’s been up to, who he’s been hanging out with, and that he just lost another tooth and is awaiting the Tooth Fairy’s visit. At one point in the letter, he wrote: “I’m the King of the House.” We wondered whether we should pull that out, since it might make the girls feel bad, but decided to leave it in. Mostly because it was so damn cute. But when we dug a bit deeper, clearly the Boy does get overshadowed by his strong-willed sisters. With them not around (for a little while anyway), he assumes the mantle of the King. Of course, I don’t have the heart to burst his bubble. He’s no more the King of the House than I am. But that didn’t stop us from asking the King to clean up his dishes and get ready for bed. Even royalty needs beauty sleep. -Mike Photo credits: “KING CLUB” originally uploaded by oknovokght Incite 4 U The Daily Breach: Given the challenges of traditional media, it’s surprising that none of the tech books have launched a Daily Breach newsletter. It’s not like there’s no inventory. I mean, check out this screen grab of my SC Magazine newsletter this AM. 4 latest news stories, and 4 breaches. And that doesn’t even include the Booz Allen breach. Folks, this is the new reality. Breaches happen. Breaches are disclosed. Customers are pissed. Some folks would use a data point like this as an excuse to be grumpy or to do nothing. But there has always been a Daily Breach. You just didn’t know about them before. So now the spotlight is on us. Guess we should have been careful what we wished for. – MR Just do the work, or hire crap: Let’s look at A List Apart’s recent post on “RFPs: The Least Creative Way to Hire People”. You don’t need to be creative to hire people – you want to hire creative people (whether or not you yourself are). I have seen just as many bad creative hiring methods as bad conventional ones – both unwittingly filter due to the process. Have I even mentioned the time I was interviewed by 115 people for a VP of Engineering Job? Only two interviewers actually understood the skills needed for the job, and one interviewer wanted a bad candidate to ensure there was no challenge for her fiefdom. However it’s done, you just need to put in the time to understand what you are hiring for and adequately screen the sea of resumes. It’s the latter point that people don’t want – or know how – to do. So they create, effectively, giant lists of screening questions to filter the resumes. But here is a hint: PEOPLE LIE. Liars get through, and honest people don’t. Forget all the other fancy nonsense, put in the time, and do the work. – AL Know thyself: Managing your identity online is more than merely controlling your credentials and avoiding keyboard-mediated tourettes (something I should probably work on). In the real world our lives are naturally compartmentalized. There’s work, home, hobbies, groups, and all sorts of social circles. The online world isn’t really set up like this, and when we use work email accounts for personal communications, or tie our identities to our jobs, or link in everyone on the same social media platforms, we blur lines in ways we cannot always anticipate. That’s why Jeff Jones’ article on how he’s segregating his identities really resonated with me. I did something similar a while ago – Twitter is fully public, Facebook is now for (mostly) non-work friends and family only, and I’ve switched more personal email off Securosis, despite being a partner in the company. Think about your online personae, and it