Aptible Blog Archives @aptible-archives - Tumblr Blog

Posts

A Trojan or other malicious program can spread from one client's office to the cloud server, and from there to other offices.

From: http://www.pcworld.com/article/2070834/are-your-medical-records-safe-in-the-cloud-despite-its-popularity-there-are-hidden-risks-and-costs.html

I see bad information like this on a regular basis, unfortunately.

I understand this is a sponsored post, written by a shill working at a marketing agency (IDG) for Western Digital in order to sell private cloud and storage services. I get that. All of his articles are scare pieces. Ok. There are good reasons for some customers to use those services. But this crosses the line into either deliberate misinformation or incompetence. I know serious security experts don't turn to PC World as a trusted news source, but this popped up in my Google Alerts. I can't be the only one reading this - I imagine other Covered Entities and Business Associates are as well.

Can the author or anyone at IDG, WD, or PC World, provide even one example of a cloud service being infected by a virus from a client's computer? To be generous, the quote above reflects a serious misunderstanding of how the Internet works, not to mention how modern cloud computing companies treat security and secure execution of arbitrary, untrusted client code.

Why use distributed computing?

Cloud services (like...ahem...Aptible) can make it easer to gain visibility over your PHI, to enforce good access controls, and to contain data leakage.

Q: How many organizations have that kind of control over their regulated information?

A: Not enough, apparently.

Take a look at HHS' list of reported breaches affecting > 500 people. The vast majority are due to employee mistakes - losing unencrypted laptops, and employee and third-party mistakes (i.e. "unauthorized access" that aren't "hacking"). Ponemon's own annual benchmark study from 2012 confirms that impression.

Bad access control are bad regardless of whether they're in the cloud or not. But, keeping your employees from making mistakes is easier when a trusted cloud provider controls access to PHI and enforces best practices across your organization.

The Obama Administration is back on the Hill this week. While the question of whether the federal insurance portal needs to comply with HIPAA seems to have died down, concerns about the security and privacy of personal information created and transmitted by the site have not.

#HIPAA #obamacare #privacy #security #hhs

A good list, short and sweet. See especially #4, #5, and #8.

#HIPAA #security #risk analysis #hhs

Healthcare.gov and HIPAA

During the Congressional hearings last week on the failure of Healthcare.gov, the question as to whether the website needed to be HIPAA compliant blew up.

The discussion started and will probably end as political spectacle, but screaming about "monkey courts" aside, it does raise a good opportunity to examine how HIPAA applies to different entities, especially healthcare software developers.

Here's my take:

In general, HIPAA regulates two classes of organizations: Covered entities and business associates. Covered entities are, generally, healthcare providers, payers, and clearinghouses. HHS released a carefully worded statement to CRN asserting that Healthcare.gov is not a covered entity.

That is true. But HHS didn't mention whether the site is a business associate, nor did they argue that the questionnaire does not collect Protected Health Information.

That is illuminating, because a close reading of the regulations suggests that Healthcare.gov may be a business associate, and that they may be transmitting regulated information.

Let's start with the facts:

Healthcare.gov collects administrative information from potential applicants, mostly non-medical demographic facts. It then determines eligibility for specific plans and helps facilitate the purchase of insurance.

What information is PHI?

The relevant definitions we are looking for are in 45 C.F.R. § 160.103.

While some have argued that Healthcare.gov doesn't need to be HIPAA compliant because it doesn't collect answers to "medically specific questions," that isn't a regulatory category of information.

Rather, HIPAA defines three categories. The broadest is "health information," which encompasses "any information" "created or received" by certain entities (including covered entities) and that "[r]elates to the ... the past, present, or future payment for the provision of health care to an individual."

That bears repeating: In the context of a health insurance portal, health information is any information created or received by certain entities that relates to payment for the provision of health care.

"Individually identifiable health information" (or IIHI) is a subset of health information. It means basically what it says.

"Protected health information" is IIHI that is transmitted or maintained in a form or medium (i.e., not orally).

Information received by a health plan for purposes of determining eligibility for insurance (that would pay for healthcare in the future) is arguably "health information." It follows in short order that such information would be IIHI and PHI.

HHS has not issued guidance to clarify whether information for eligibility checks on health insurance portals sufficiently "relates" to payment for the provision of healthcare, so this remains a grey area.

Is Healthcare.gov a Business Associate?

There are two ways to be classified as a business associate: 1) "create, receive, maintain or transmit" PHI on behalf of a covered entity for a regulated function or activity, or 2) Provide certain services to a covered entity, including "administrative" services where the provision of services involves PHI being disclosed from a covered entity (or other business associate) to the potential business associate.

Information is only going from Healthcare.gov to the payers, so #2 doesn't seem likely. But the site may be creating and transmitting PHI (as discussed above), and therefore fall under #1.

[There is a specific exception for government agencies with respect to determining eligibility for or enrollment in a government health plan, but the plans at issue here are private, so the exception does not apply.]

Again, HHS has not issued guidance to clarify whether it considers health insurance portals to be performing a regulated "function or activity" for covered entities such as health insurance companies. Another grey area.

Better safe than sorry:

Reasonable minds can differ as to whether information collected and transmitted to a health plan for eligibility determination is "health information," and also as to whether Healthcare.gov is performing a regulated function.

Of course, if HHS says their own site is not regulated, that is the final verdict. The best outcome of all of this would be for HHS to issue some clarifications, especially as to how they intend to regulate health insurance portals.

In the meantime, for those of us who are building applications for customers who don't regulate themselves (!), it's probably best to err on the side of customer security and privacy.

As CRN paraphrased an unnamed "solution provider" CEO:

Regardless of whether the site needed to be HIPAA compliant or not, the CEO said that it would have been a smart move for the site to comply because of the many controversies recently, mostly stemming from the NSA and concerns over the online privacy. Although the CEO said he recognized that, given the size of the project, the move to make the entire site HIPAA compliant would have been a very large undertaking, users need to know their information is safe.

I agree.

#HIPAA #healthcare.gov #monkey court

The Chain of Trust

A few days ago, I received some web-scraping spam from a company that makes a file-level encryption plugin for Dropbox. Their offer was to pay me in exchange for offering my readers a discount.

I'm not interested for two reasons. First, I'm not going to be a shill. Second, the company's product, which they are aggressively marketing to healthcare customers as a HIPAA compliance solution, appears to be fundamentally non-compliant.

To explain why, I've included a redacted version of an email I sent them. I will publish any response I receive. I don't expect to hear back. If Dropbox does decide to sign BAAs in the future, like Box, this product might be a good fit for small- and medium-size organizations.

In the meantime, remember: Encryption is not HIPAA compliance. Real compliance requires the entire chain that handles ePHI, from covered entities to business associates to subcontractors, to be following the rules and extending assurances to each other.

**************************************************************************************

From: Chas Ballew <[email protected]>

Subject: Re: HIPAA compliant Dropbox

Date: October 16, 2013 1:25:28 PM EDT To: [Marketing Director, Company X]

Hi [...],

[Grumbling about spam and seedy marketing techniques.]

But I do have a question for [Company X]:

Dropbox has a very clear position that they do not support HIPAA compliance (https://www.dropbox.com/help/238/en). The United States Department of Health and Human Services is also very clear that subcontractors that maintain ePHI are business associates and are required to comply with the HIPAA regulations, including the requirement to have a Business Associate Agreement in place (http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/contractprov.html)

My question: Does [Company X] have a Business Associate Agreement in place with Dropbox?

If not, how can you represent your product as enabling HIPAA compliance? It seems entirely clear that any ePHI passing through [Company X] is maintained by Dropbox.

If my understanding is correct, [Company X's] marketing strategy is, at a minimum, misinformed and supporting illegal information management. At worst, it might be deliberately misleading and unethical in the sense that you are preying on customers that do not understand how HIPAA regulates information.

If I am wrong or have misunderstood anything, I welcome the opportunity for you to correct me. I'm going to publish soon, so a reply would be appreciated. I will publish whatever response you'd like to provide.

Thanks

Chas

#HIPAA #dropbox #spam #non-compliance

This is from 2004, but applicable now more than ever. HIPAA compliance is not and will never be turnkey. Custom processes and policies, management buy-in, and training matter.

#hipaa

Free HIPAA Advice

If you're at a healthcare tech startup and are wondering what the new HIPAA regulations mean and how they apply to you, your customers, and your tech stack, shoot me an email anytime at [email protected]. I'd be happy to help you get your bearings.

#HIPAA #advice

Health care will be provided by big institutions, in a more standardized fashion, with less overall cost, but less of a personal touch.

In sum: More pressure on small providers and small hospitals, more consolidation across provider groups, and more care being provided out of traditional clinical settings.

#care transformation #the future #Healthcare

Happy Omnibus Day

Happy Omnibus Day everyone! As of today, September 23, 2013, the HIPAA Omnibus Rule is in effect. If you're a Business Associate, you're now directly regulated under HIPAA. And if you create, receive, transmit, or maintain ePHI on behalf of a Covered Entity, you're probably a Business Associate. Get those risk assessments, policies, and training plans in place!

#hipaa #omnibus

The enterprise that actually gets security realises it's all about the application of best practise, risk assessment and common bloody sense in equal measure...[Cloud service providers] are probably more focused on security right now than the average enterprise is, or has ever been.

Davey Winder echoes what Bruce Schneier was saying in the Google talk I posted last month: For most users, the cloud providers are providing security (tech + process) above what your organization has. If you trust your cloud provider to do what they say they do, and you keep your encryption keys, the cloud is probably much more secure than anything you can roll yourself.

#cloud computing #security #best practices #risk

The reality about cloud computing ... is that these challenges have been met for some time, but that the message about how these issues can be solved - using a combination of governance strategy and security technologies - is only now starting to get through to the management professionals that matter.

#cloud computing #governance #security

Here's a great post from Lee Bendekgey at DNAnexus on how cloud environments, when properly configured, can significantly reduce risk of HIPAA breaches. Lee is spot on here.

Most breaches (66% by number, 73% by individuals affected) result from loss of theft of physical equipment containing unencrypted data. Unauthorized access (the bad kind of "hacking") amounts to 8% of incidents.

Your organization should strive not to keep data on devices that can be lost or stolen. And regardless of where data is, it should be encrypted in transit and at rest. These aren't requirements under HIPAA, but they are best practices.

Using a reputable cloud provider, backed by a business associate agreement, means that your production environment is located in a data center with physical and technical safeguards that are probably far beyond what you could implement yourself. Combine that with best practices and you significantly reduce [the lawyer in me won't let me say "eliminate" :) ] your compliance risks.

#HIPAA #security #cloud computing #best practices

[E]ven if the covered entity encrypts the data before sending to the vendor and retains possession of the key so that the vendor cannot decrypt the information their status as a business associate is still dictated by possession not access.

Here's a good post by Mac McMillan on what makes a business associate. The key point is that on September 23rd, anyone who comes into possession of ePHI is now a business associate. Mac is right that the best way to reduce risk and avoid headaches down the line is to clearly establish responsibilities and expectations between covered entities and business associates.

I'll add that focusing on creating great processes and procedures, and training your employees well on them, is not only good for your business, it's good for your customers and your patients.

#HIPAA #omnibus #business associate

From the Journal of the American Medical Association, an excellent overview of the difficulties that businesses face with regards to evolving technology and HIPAA.

#HIPAA

For most people, the cloud providers are better at security than they are. Automatic cloud backup is fantastic. Automatic updates [are] fantastic. All these things are good. So feudal security provides this level of security that most everybody is below. So it will raise them up to whatever level the providers are providing. For those [already at a high level of security], it lowers them down. And where you see barriers to people adopting [cloud computing] are things like the banks, who, naturally, have a higher level of security, and don't want to go down. I assume that at some point, we are going to see a business model of a high security cloud vendor-- whether it's a Dropbox or an email service-- just something for some of these more high assurance users. We also have the problem of regulation. For a lot of companies, they have auditing reporting requirements. And if you go to Dropbox and say, we're using you for our company, we need to audit your system, they will say, go away, or [the same if you go] to Rackspace. I assume we're going to see some water flow auditing model, where the Rackspace audit flows down to whatever service works on top of that, which flows down to whatever company now uses that service. Because I think we have to solve the regulatory barriers, here.

Bruce Schneier

http://youtu.be/m3NJ-Ow2Lvg?t=11m10s

#bruce schneier #cloud computing #security

Reverse SSH tunneling with AWS

I mostly blog about healthcare here, but I wanted to put up a quick tutorial on reverse tunneling for developers. There are plenty of explanations out there, but I wanted to write one that is simple, easy to understand, and repeatable.

What is reverse tunneling, and why is it useful for web developers?

SSH, or Secure Shell, is a cryptographic network protocol that allows us to set up secure connections between computers over an unsecure network, like the Internet. We can use it to run commands, forward ports, and transfer files. We can also use it to create a secure "tunnel" by wrapping unencrypted protocols (such as HTTP) in encryption.

Normal tunneling forwards a port on a local machine to a port on a remote machine. Reverse tunneling forwards a port on a remote machine to a port on a local machine.

This is useful because it allows us to direct third-party services and devices to a remote machine that is exposed to the Internet. Those requests will then be forwarded to our local machine. It's faster than deploying to a staging server.

I use it mostly to check how my iPhone and iPad are displaying CSS media queries, in addition to the Safari Developer tools.

How to set up a reverse tunnel

First off, you don't have to DIY. You can use Localtunnel or Forward for this. I like setting up my own because it's easy, responsive, and gives me a lot of control.

How easy is it? There are four steps:

Start a server, configured to allow reverse ssh tunneling

Configure our local ssh settings

PROFIT

Ok, the real steps:

Configure and start a server

Configure our local ssh settings

Configure server ssh settings and reload ssh config

Establish the reverse tunnel

I'm using OS X Terminal, OpenSSH and Amazon Web Services.

Step 1: Configure and Start a Server

We are going to launch an EC2 instance using the AWS Management Console interface. Go into the EC2 Mangement Console, go under Instances, and hit the "Launch Instance" button. You should see the Quick Launch Wizard:

Name your instance

You may need to create and download a keypair

I like Ubuntu Server 12.04.2 LTS

Hit "Continue." Next, let's edit the instance details.

I just use a t1.micro. If you want something beefier, select it under the Instance Details radio button.

Under Security Settings:

Create a new Security Group

Call it something like "Reverse SSH Tunnel", add a description

Add a rule to allow access on port 22 (SSH) at source 0.0.0.0/0

Add another rule to allow access on port 3000 (or whatever port you want to forward traffic from) at source 0.0.0.0/0

Create the Security Group

Select that group and hit Save Details

Launch the instance

Note that you can also launch an instance and edit the Security Group afterwards. The process is similar.

Optional: Assign an Elastic IP

When your instance launches, you will see it is assigned a default IP address, something like ec2-54-211-63-58.compute-1.amazonaws.com. To make that a little more manageable, and to persist an IP across starting/stopping an instance, let's assign an Elastic IP.

Under Network & Security, go to Elastic IPs

Allocate a New Address, in EC2

Associate the Address with your instance

Now when you select your instance, you should see something like this, with a nice static IP:

Step 2: Configure Local SSH Settings

Find the *.pem key you downloaded and copy it to your ~/.ssh folder. For me this was:

$ mv ~/Downloads/reverse-ssh-key.pem ~/.ssh

AWS requires us to set the permissions on our key so that only the owner may read it.

$ chmod 600 ~/.ssh/reverse-ssh-key.pem

To avoid having to pass in a long set of parameters every time we want to open the tunnel, we can edit the ~/.ssh/config file to include:

host 54.227.245.213 user ubuntu StrictHostKeyChecking no UserKnownHostsFile /dev/null CheckHostIP no IdentityFile ~/.ssh/reverse-ssh-key.pem ServerAliveInterval 120

Hit $ man ssh_config to read about these options.

Host is the IP address of the instance we fired up.

User should be whatever your OS prefers. If you use Amazon's Linux AMI, it will want you to log in as "ec2-user." Ubuntu will let you start a console as root, but will want you to be a normal user for other tasks.

Several options have to do with checking/managing keys. I'm ok here because we are just connecting to a specified IP. If you wanted to be paranoid then...you shouldn't be following this tutorial.

ServerAliveInterval pings the remote host every n seconds, to keep the connection alive. Not setting it will eventually result in a "Write failed: Broken pipe" error.

Save and open a new shell window to load the new config.

Step 3: Configure Server SSH Settings and Reload SSH Config

Check that you can ssh into your server now:

$ ssh 54.227.245.213

Awesome.

Finally, we have to configure the port binding on the instance. Get into the sshd_config file with write access and add "GatewayPorts yes".

ubuntu@ip-10-147-225-211:~$ sudo vim /etc/ssh/sshd_config

(In vim, arrow scroll to where you want to insert, hit “i” to insert, esc to end the insert, “:w” to save, “:q” to quit.)

If you need to not bind everything on the wildcard, you can set GatewayPorts to other things. ($ man ssh and $ man sshd_config it.)

Finally, reload the ssh configuration and exit the session:

ubuntu@ip-10-147-225-211:~$ sudo reload ssh ubuntu@ip-10-147-225-211:~$ exit

Step 4: Establish the Reverse Tunnel

Now it's time for magic. Fire up a local server. I'm using port 3000. The syntax for reverse tunneling is:

$ ssh -R [bind_address:]port:host:hostport address

With GatewayPorts set to "yes" on the server, we can leave out the bind_address. So:

$ ssh -R 3000:localhost:3000 54.227.245.213

means that port 3000 on the remote server is to be forwarded to the given host and port on the local side. Remember, if you want to use a different remote port, you need to allow access in your EC2 Security Group settings.

You should be able to point a web browser at the specified port on your server (54.227.245.213:3000 here) and interact with your development environment.

Optional: Add an Alias

The last thing I'm going to do is add an alias in my ~/.bashrc file:

alias devtunnel="ssh -NR 3000:localhost:3000 54.227.245.213"

-N runs the ssh session without executing a remote command. You can also run it with -f to send it to background.

Now, after I open a new shell window, I can start a new tunnel with:

$ devtunnel

That's it. Enjoy.

#reverse tunnel #ssh #aws

Good introductory post by Hartley Brody on how TLS/SSL works.

#https #encryption #security

Trending Blogs

Recently Viewed Blogs

Aptible Blog Archives