A recent endeavor at Stanford University’s Security Lab found more sobering information on the reach and capability currently employed by trackers such as Epic Marketplace (formerly known as Traffic Marketplace).  The lab found that the scripts used on affected sites were very fast and loaded thousands of links in invisible iframes so few users would ever notice them.  Whenever the browser window closed, the scripts sent off their findings and also stored their progress in scanning links with a cookie.  In order to avoid having parallel scripts run concurrently and slowing down the process, some even used some semaphore-like cookies to start and stop.   By scanning thousands of hidden links, these scripts could quickly develop a comprehensive history of browsing, and the lab found that these links ranged from eBay listings to health clinics, a serious privacy concern.

While most browsers have worked to minimize this history sniffing issue, it is estimated that at least half of all Internet users are still quite vulnerable simply because many do not update their browsers on a regular basis.  Some affected users can also reduce this problem by setting their browsers to automatically clear all history whenever they end their session or by always running incognito/private browsing mode.  Of course, you can obviate any JavaScript attacks (history sniffing or otherwise) by disabling all scripts from running with extensions like NoScript for Firefox.  If you have an outdated browser (for testing purposes, right?), you can see a history sniffing script in action at StartPanic.com (The petition there is now obsolete since browsers have updated).   Given the extent of current history-stealing scripts found at Stanford’s lab, it is crucial to remain as up to date as you can on browser patches.  Remember that there are many ways to be tracked that do not involve cookies.

It also sets the stage for wider adoption of EHR in the private sector. But there are reasons to be concerned about this, of course. There are few, if any, pieces of information more intrinsically private and personal than one’s medical records. And while making these records available in an electronic format offers great advantage in medical care, it opens up great risk of compromise.

As with any important data, there are ways to provide EHR. The medical industry in America is very heavily regulated, with HIPAA being the primary source of guidance. Based on HIPAA and related laws and regulations, various healthcare-related certifications exist. The two with which I am most familiar are DIACAP and CCHIT.

DIACAP stands for Department of Defense Information Assurance Certification and Accreditation Process. It’s not specific to medical information, but it is specific to DoD systems. It’s important here because most publicly-available EHR systems will have descended from DoD systems which had to pass DIACAP. DIACAP is a very intensive process which takes reams of documentation and months of work. It’s very comprehensive. Unfortunately, because of how it’s designed it can sometimes be outdated, and even force systems to be insecure. For example, at least as of 2010 when I last worked with it, systems were required to use Internet Explorer 6, with all the limitations of that browser. Nothing newer was possible.

Outside of the DoD, I’ve also worked to certify systems under CCHIT standards. CCHIT stands for Certification Commission for Health Information Technology, and has been required for certain government tax incentives and even in some cases the ability to operate a system at all. While still rather intensive, it is far less so than DIACAP. Realistically, looking back on it, it didn’t go into nearly enough depth on security, being focused on healthcare and data integrity.

This doesn’t even touch on the clinical side of things – the actual data directly gathered by medical devices like MRIs, CT scans, x-rays, etc. Most security audits avoid dealing with clinical data directly – it’s a hassle to allow auditors to know anything about those systems, and the auditors seldom have any idea what they’re looking at anyway. Frequently the data is handled in a proprietary fashion which may or may not be well-documented, and frankly it’s often little short of a miracle that it works at all. As a result, even if a hospital or doctor’s office has a secure computer system, the clinical data, the most revealing data, may be the least secure.

The most worrisome part, having been on both sides of the table for security reviews, is knowing that too often they’re looked upon as just another tedious piece of paperwork. As a tech writer, my job was frequently “write something so these people go away”. I’ve also seen security auditors who felt that their job was “find a reason to fail these people”. These attitudes are, of course, common to all security audits. But they become especially worrisome when it’s medical records on the line.

Comptroller Susan Combs offered another apology Thursday for the information breach in her agency, saying she now is offering a year of free credit monitoring to the 3.5 million people at risk of identity theft after their data was exposed on a public computer server…She announced in a written statement April 11 that the Social Security numbers and other personal information of 3.5 million people were left exposed for a year or more in a publicly accessible computer server at her agency.

Dallas News

According to this article in the Dallas Morning News, 3.5 million identities were left free for the taking on a public server for at least a year. That is a colossal security lapse. However, it is a fairly responsible remediation that credit monitoring is being made available for the affected users. (Contrast this with Sony’s recent Playstation Network breach; Sony won’t even confirm whether or not credit card information was accessed in their attack.) Still, had literally any effort been put into keeping that information secured, the state of Texas wouldn’t have to spend an estimated $21 million for the credit monitoring services.

The security arena is one in which the maxim “an ounce of prevention is worth a pound of cure” holds especially true. How much would it have cost to audit that server deployment? A few thousand dollars? Tens of thousands of dollars? Hundreds of thousands? Any answer less than “21 million dollars” means that this should never have happened.

This facsimile, which may contain confidential or legally privileged information, is intended for the use of the individual to whom it is addressed only. If you are not the intended recipient (or authorized delegate for the recipient) of this message, please telephone the number listed above to advise us, so that we can arrange for its proper destruction and resend it to the correct recipient. Thank you.

It probably goes without saying that there isn’t a “Katie” working here at Gemini (yet). So of course we called the number to let them know we had received this fax in error. It took my office manager over 30 minutes on the phone to get through to the appropriate person to ensure that it was understood that the information went to the wrong fax number. We followed their instructions explicitly, but nobody at the bank seemed to know what to do. Ultimately it wasted our time.

What was in the fax? The materials attached were an absolute treasure trove of information. Names, addresses, phone numbers, birth dates, social security numbers, drivers license numbers… and that was just on the first page. A copy of two driver’s licenses. A copy of two credit cards. A letter of incorporation, a federal EIN, and copies of two credit reports.

This is more than enough information to steal the identity of two individuals and one business. And the terrifying part of it is that nobody would have been the wiser if we didn’t take the time to phone the bank to let them know we had received the information in error.

Which brings up an interesting question. Should we have called the bank? Sure, I feel bad for the individuals and the business who are having their most private information sent via fax. Their information couldn’t be in better hands though – we know better than to do anything with this information, and we securely shredded it. On the other hand, because we called them the bank now has a record that they accidentally sent us this information. If these individuals suffer identity theft, wouldn’t they immediately consider us a suspect?

In these days of heightened concern about identity theft, why are banks still using insecure transport mechanisms such as faxes without even bothering to call the recipients to ensure successful delivery?

Well, it looks like we’re in for a lot more of them, thanks to a new, cheap toolkit that allows users with little to no programming knowledge or experience create these malicious applications.  For the low price of $25, this application will guide you through the process of creating your own nefarious Facebook applications with promises of enormous return on investment by tricking your friends into filling out surveys for various third parties.

So remember, folks – be careful when you allow applications access to your Facebook profile – not all of them are safe, and not all of them deliver on their promises.  Personally, I haven’t installed any apps on Facebook, and I probably never will.

But, you know, I’d never seen this one before. I had to read it to see what the scam was. And that made it far more interesting. There’s no scam. The company is perfectly legitimate, and they’re not trying to sell me anything. It’s a real order confirmation for a real order. Benjamin Hartley really did make this request.

Just, you know, not me. My name isn’t common, but there’s at least one other person with that name. And he’s not at all careful about email addresses. I’ve had email from him in the past – or, rather, from organizations to whom he’s given my email address. I feel as if I know him. I know where he went to school; I know who he works for. I know who he donates money to. I think I even saw his birthday in one of the emails. And now I know he lost his passport. I know when he’s leaving the country. Oh, and I have all the confirmation information to get his replacement passport sent wherever I please, so if I really wanted I could have, well, quite a bit more.

I’m not going to do this of course. But I obviously could. This is potentially very damaging information. And it was just emailed to me. Not even signed or encrypted – just emailed. I’ve not been stalking this guy; I’d be happier to not be receiving this information, but it keeps coming. And, ironically, the one piece of personal information I don’t have about him is his contact information. Actually, that’s not true. I called the company, and – even though I was entirely clear to them that I was not the person who made the order – they still gave me his phone number, which is a whole different security failure.

This is really rather disturbing for two reasons. First off, my nominative doppelganger needs to be far more careful with his information. I don’t know why he doesn’t worry that he never receives the emails he’s expecting; maybe he forgets about them, or checks his email so infrequently that it doesn’t matter. But he’s not getting information which he clearly should be receiving, including some potentially compromising information. Second, the travel document service needs to be far, far more careful. They should have asked me to confirm my identity before discussing the order – at minimum a birthday, but a passport number or social security number would have been better. Of course, given that I told them beforehand that I was not the person who made the order, confirmation is the least of the problems there.

In technology, we’re generally good about confirming the destination for data. Our medium may not be secure, but the technology usually knows if it has connected to the right destination. But that’s because computers do it for us. Out here in meatspace, we’re not so careful. Like this other Benjamin, we generally just assume that our data will go to the right place – or if we don’t get it, then it’s not a problem, it just got lost. And like the travel document service, we simply assume that anyone asking about specifics must be allowed to know about them, and we don’t confirm. And that’s really all that needs to be done here – get a little confirmation that data is going to the right source before sending sensitive information. If that had been the case here, I wouldn’t have been handed this man’s personal information this way. As it is, though, it makes you wonder what other information might have gone astray. The other Benjamin is lucky; his personal information went to someone without ill intent. Others may not be so fortunate.

The victory in the crypto wars didn’t last long. Today, there are a slew of laws in place in various countries controlling the use of strong encryption. Some, like the UK’s “Regulation of Investigatory Powers” Act allows encryption but allows law enforcement to require that information be decrypted. Others, like France, require the use of trusted third parties in case law enforcement desires the keys. Still others, like the Communications Assistance for Law Enforcement Act (CALEA) in the US require other forms of encryption backdoors be in place. In a few places, certain forms of encryption are simply illegal.

There’s good news here, after a fashion. If ever we needed independent confirmation that the current level of cryptographic technology is pretty good, here it is. Governments, in the form of law enforcement, espionage, and military are all concluding that it’s not practical to break existing encryption. (Of course, this doesn’t mean they can’t, just that they either don’t think they can do so fast enough, or that it’s too costly). Still, this is a good sign for the quality of the encryption.

The bad news, however, is that complying with the law may make your data insecure. Notwithstanding how you feel about a given government reading your files and intercepting your communication, it’s a given that if a backdoor exists for one party, it exists for anyone sufficiently motivated to find it. So what are your options?

Well, pretty much the typical ones. First of all, learn the relevant laws about cryptography wherever you’re doing business. This is actually pretty hard, as there doesn’t seem to be any authoritative list, even just for the US, and it’s pretty hard to figure out who would even know. But once you do, it’s time for some hard decisions. You may decide that you can be sufficiently secure within the limits imposed on you. You may choose to keep truly sensitive information off the network, maybe keep something in-house that you’d rather outsource. In some cases, you might even decide you can’t do business, though that’s a pretty extreme measure.

However, after learning how Facebook expects people to request the one-time passwords (via mobile SMS), a potentially negative side-effect becomes apparent. Passwords are often the first line of defense encountered by an attacker. But in this case, OTPs actually undermine the benefit of the original password by creating a temporary token that can be used instead. This creates a security tradeoff, whereby the benefit of a secret password is sacrificed for protection against an untrusted system (kiosk, library computer).

This tradeoff isn’t inherent to OTP systems, and only exists for Facebook because the person requesting the access token is not required to prove their ownership of the respective account each time. Access to the mobile phone linked to the account is all that is required to access the goodies. In the time it takes to send a text message, an attacker could essentially hijack an account.

Curiosity and a few minutes alone with someone’s phone might be all you need to turn Facebook’s shiny new “security feature” into another privacy misstep.

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

Now, the real concern here is what exactly do these actually mean.  If you see a label for “Phone Calls,” should you freak out and immediately think the app is going to start calling your friends, or start making unauthorized long distance phone calls? No (though it might).

This is one area where I think Android needs to step it up. It’s great that they tell you what permission groups are affected by this application. But to be honest, there are quite a few scenarios that could exist in each group. The given example for Phone Calls really only monitors the state of the telephony portion of the OS e.g.: An application could automatically monitor the state of the phone and reject any incoming calls if this happened to be some sort of navigation app, and felt that receiving calls while driving was too much of a distraction. – That’s a fairly obscure example, but it just goes to show what lengths these permission groups can go to. Obviously this same app would most likely pop up the Location group in this section as well as it would be requiring access to the course or fine GPS data.

So what determines which permission groups show up here, and how can you be sure that the developer wasn’t trying to be sly and hide the fact that their application is using the GPS data? Well, the people at Google thought of that. When developing an application, you need to specifically state which permissions groups your application needs in the AndroidManifest.xml file.

<manifest xlmns:android...>
...
<uses-permission android:name="android.permission.LOCATION"></uses-permission>
</manifest>

If this is not included in the manifest, you’re not even allowed to make calls to the classes that implement the functionality located within that permission group. The code simply won’t compile until the manifest file is edited accordingly.

So it seems Google has covered their end fairly well. It’s just up to the users to keep an eye on what they’re installing. Though as stated, I do think they could increase the level of detail that is displayed for each group.

Included below is a table showing all the permission groups. Also if you’d like to have a deeper look at what’s inside each group, have a look at the Android developer site for a full list of all the constants that would indicate what features are being used.

Android Permission Class

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.