With the announcement that KPMG really is going to start performing HIPAA Privacy Audits in the New Year, we’ve had numerous conversations with healthcare providers around getting their privacy and security programs up to scratch. 

It’s a well-known secret in the healthcare industry that HIPAA compliance does not receive the attention (or the funding) that it should.  There are of course exceptions and I should note that most security and privacy professionals in the healthcare industry take their jobs very seriously and honestly do consider the protection of patient data to be their number one priority.  But, it’s often difficult to do your job if you don’t have the funding or resources needed to do it properly.

The federal government hasn’t helped – creating a mandatory requirement, but not putting in place any mechanism for testing compliance with that requirement rapidly creates a sense of non-urgency.  What’s the point of REALLY making sure that we’re HIPAA compliant if no one’s going to check?  It costs a lot of money, it’s annoying to doctors, it’s not even the slightest bit sexy, and it’s going to impact options to the organization.

And, if none of your competitors are limiting themselves and spending extra money on ensuring HIPAA compliance, a healthcare executive is going to see true HIPAA compliance as a competitive disadvantage.  Now it looks like everything is going to have to change.  Don’t believe me?  Think the audits are going to be ‘no big deal?’  Let’s draw a parallel with another compliance requirement – PCI DSS.

For those of you not familiar with PCI, you should be – you probably have to comply with this as well.  In any case, it’s the data security standard inflicted on merchants and service providers (companies that facilitate credit card payments) by the large credit card brands (VISA, MasterCard, etc.)  Anyone that takes (or processes) a credit card for payment needs to be PCI compliant.

Although the card brands catch a lot of flak for ‘inflicting’ PCI on the world, the truth of the matter is, something needed to be done.  Credit card data was not being protected and it was costing the card brands a LOT of money in fraudulent charges and impacting consumer credit ratings.  If they hadn’t created their own standard the government most likely would have.

When PCI was first rolled out to the community there were a lot of merchants that thought it was no big deal, but they didn’t plan on three things:

1. The card brands were perfectly willing to let non-compliant merchants make ‘examples’ of themselves (link, link)
2. The legal community quickly learned what ‘PCI-compliant’ meant and how not being PCI-compliant could be used in things like multi-million dollar class-action lawsuits
3. The PCI standard gave consumers a benchmark against which to judge the merchant’s brand.

These points have been effective because the card brands maintain a unified front when it comes to PCI (they all agree to the codified requirements as the baseline required by merchants to transact credit cards securely) and because they have a mandatory audit mechanism in place that gives them the power to take action if the merchant or service provider isn’t complying with PCI.

I think that we have the same dynamic going on now with HIPAA.

1. KPMG is going to be looking to justify their million dollar contract with the government – they will find issues with compliance during their audits.
2. The legal community is already very aware of privacy breaches in healthcare and what that means for things like multi-million (and multi-BILLION) dollar class-action lawsuits (link, link, link)
3. Everyone now has a benchmark against which to judge how much a healthcare provider cares about their patients’ data

I think that it’s time to figure out a plan on how to really address HIPAA – both in the short-run (i.e. achieving an initial compliant state) and long-run (maintaining compliance moving forward.)  If you aren’t familiar with the recent announcement involving the upcoming audits here’s a link on the HHS site which includes a sample of the letter that will be sent out to organizations.  Also note – the first round of audits is going to focus on Covered Entities, but future rounds will also include Business Associates.

For some additional information on how to put together a workable approach to really achieving HIPAA compliance please see material on the NetSPI blog and NetSPI services pages.  Also – NetSPI will be putting together whitepapers, additional blog posts, and (possibly) a webinar on this topic over the next couple of months.  Please check back here for more information, make a comment, or send me an email (link below) if you would like to discuss.

The problem is that individuals have found that they can recover the silver found within the film. While it isn’t a lot of silver (roughly 2% of the film’s weight) a few hundred pounds could make it a lucrative venture. That’s why it’s not surprising that thieves have begun stealing them. Let’s be honest here, when was the last time you checked the credentials of the crew coming to take away what you would consider to be garbage?

The issue here isn’t that these films will be used for identity theft purposes, it’s that you are now forced to go through breach notification procedures at your cost… for what is technically considered refuse! Three organizations in Pennsylvania already had to go through this as they’d fallen victim to thieves stealing the films from unsecured areas, and in one instance posing as a radiological film destruction company.

What can you do? Start securing X-rays and make sure they aren’t accessible to unauthorized parties, regardless whether the file is useful or scheduled for destruction. Many organizations store the X-rays near the equipment in semi-open rooms. If the rooms aren’t used 24×7 then you should either secure the room when not in use using your normal physical security system (key, badges, dragons, etc.) and monitoring equipment. If you don’t want to go to such extreme measures (I hear dragons eat a lot) then you may consider digitizing your x-rays and then securely dispose of the physical copies. Otherwise you may want to start recovering the silver yourself to help pay for the breach notification efforts you might find yourself facing.

Further reading:

http://www.ehow.com/how_4501375_extract-silver.html

http://www.ehow.com/facts_7786835_xray-silver-recovery.html

http://philadelphia.cbslocal.com/2011/10/17/thieves-seeking-quick-steal-x-ray-film-from-area-hospitals/

http://www.jeffersonhospital.org/Patients/scrap-x-ray-film-theft.aspx

Initially I thought of trying to showcase some of them in a silly reference; but I thought it might be too OPAQUE.

O – Overreacting is not going to get you through the event

P – Preparedness is key

A – Accept that it will happen to you

Q – Quit keeping old data

U – Understand the laws that impact your organization

E – Empathize with your customers/patients/employees – how are they going to react to your response?

In all seriousness; Q and A (no pun intended here) are both important and I wanted to point those two out.  

If you don’t need the data, as an organization you need to ask yourself, “what are we gaining by keeping this data?”  The liability is attached to every piece of information you retain regardless if you use it or not.  Having (and following) data retention policies will limit such a liability. 

Accepting that it is going to happen, now that’s a hard pill to swallow.;but similar to Emergency Preparedness techniques that many organizations routinely practice.  As they say, practice makes perfect even if you never have to use those techniques.  Organizations that routinely train for various circumstances are the ones best prepared to handle them.  If you accept that a data breach is going to happen, you’ll find yourself equipping and (more importantly) training for how to respond.  Whether you attach this to existing emergency practices or not is not as important as actually having a response.  Many organizations have suffered both from a Public Relations perspective and financially (fines) by their seemingly lack of response. 

In the end, training staff how to deal with data breaches because you accept that it will happen will yield positive results from a negative situation.  It’s amazing how people remember what to do during emergency situations; I still remember to get under my desk during an earthquake.

• Why is NetSPI not listed on their website? (Answer: We don’t need to be; we meet other requirements that make us qualified certifiers)
• Is NetSPI allowed to certify our application before you are listed on DEA’s website? (Answer: Yes)

According to 21 CFR 1311.300(a), there are two alternative processes for achieving the necessary qualifications:

1. “A third-party audit conducted by a person qualified to conduct a SysTrust, WebTrust or SAS 70 audit or a Certified Information System Auditor as stated in 21 CFR 1311.300(b), which comports with the requirements of paragraphs (c) and (d) of 21 CFR 1300.300” or
2. “A certification by a certifying organization whose certification process has been approved by DEA”

Therefore, the certification process emphasized within the clarification is simply one of the alternatives, and is in no way required or mandatory.  While the principal consultant involved with the EPCS Certification is a Certified Information System Auditor (CISA) in good standing, there should not be any issues with qualifications.  Experience with SysTrust, WebTrust, or the slightly outdated SAS-70 (in my opinion) are more a derivative of training provided by ISACA as part of CISA.

The bigger question would be whether having appropriate qualifications is the only measure by which you should select your certifying agent. This is where things like experience with certifying applications in other standards, experience in healthcare, and understanding of software development lifecycle can be significant differentiating factors.  Certainly, like with any other regulatory standard, there will be (perhaps already are) many low-cost, rubber-stamp firms that might get you the certification letter you are seeking.  They may let you replace application controls with policies and documentation, conduct the whole assessment by phone, and turn the whole certification process around in 24 hours.  However, obtaining the certification is only the first step in the long journey of maintaining DEA EPCS compliance.  If your client decides that your application does not meet requirements or is in violation of EPCS, you will have to investigate all such claims and if confirmed, announce to all of your customers that they can no longer use your application to prescribe or accept electronic prescriptions of controlled substances. (21 CFR 1311.302) 

While it may seem appealing to take a run at getting through the certification fast, trust me, taking this shortcut is not a good idea, and any perceived savings of time and money will likely come back to haunt you in the future.  Going for the low-cost auditor in this case may actually be the most expensive option.

Finding Sensitive Data
There are a lot of great tools available for finding data quickly on a SQL Server. Some are commercial and some are open source. Most of them can be useful when gathering evidence during PCI penetration tests or when simply trying to determine if sensitive data exists in your database. In this section I’m going to cover how to find and sample data from SQL Servers using my TSQL script, and the Metasploit module based on the script.

TSQL Script – FindDataByKeyword.sql
This script will search through all of the non-default databases on the SQL Server for columns that match the keywords defined in the script and take a sample of the data. For more information please refer to the comments in the script.

Important Note: This script does not require SYSADMIN privileges, and will only return results for databases that the user has access to.

1. Download the “finddatabykeyword.sql” TSQL script from:
   https://github.com/nullbind/Metasploit-Modules/blob/master/finddatabykeyword.sql.
2. Sign into an existing SQL Server using Management Studio.
3. Open the “finddatabykeyword.sql” TSQL script. Next, set the “@SAMPLE_COUNT” variable to the number of rows that you would like to sample. If “@SAMPLE_COUNT” is set to 1, then the query will also return the total number of rows for each of the affected columns that contain data.
4. Then, modify the @KEYWORDS variable to set words to search for. Each keyword should be separated by the “|” character.
5. Execute the “finddatabykeyword.sql” TSQL script to sample data from columns that match defined keywords.

Metasploit Module – mssql_findandsampledata.rb

This is my first Metasploit auxiliary module. I recently wrote it with a little help from humble-desser and DarkOperator. The module is essentially a Measploit wrapper for my original TSQL script. Currently, this script will search through all of the non-default databases on the SQL Server for columns that match the keywords defined in the keywords option. If column names are found that match the defined keywords and data is present in the associated tables, the script will select a sample of the records from each of the affected tables. The sample size is determined by the samplesize option.

Before I provide an overview of how the module works, I would also like to thank Digininja. His original Interesting Data Finder module (http://www.digininja.org/blog/finding_interesting_db_data.php) was my starting point for this script. Although, I didn’t use much of his IDF module, I did borrow his method for auto sizing columns. So Thanks! I think it’s a good time to mention that I haven’t submitted this to the Metasploit code base yet, because I would like to finish a few additional options. So enjoy the sneak peak! Hopefully some one finds it useful. Below is an overview of how to use the Metasploit module:

1. Download and install the Metasploit Framework. It can be downloaded from:
   http://metasploit.com
2. Download the “mssql_findandsampledata.rb” module from:
   https://github.com/nullbind/Metasploit-Modules/blob/master/mssql_findandsampledata.rb
3. Copy the “mssql_findandsampledata.rb” file into Metasploit. Below are the locations it should be copied to for Metaploit Framework and Pro:

       Metasploit Framework –Windows (Free Version):
       C:\framework\msf3\modules\auxiliary\admin\mssql\
   
       Metasploit Pro – Windows (Commercial Version)
       C:\metasploit\apps\pro\msf3\modules\auxiliary\admin\mssql\

4. Open a Metasploit console. Important Note: The pro version of Metasploit is not required.
   
5. Select the “mssql_findandsampledata.rb” auxiliary by typing: “use auxiliary/admin/mssql/mssql_FindandSampleData”
   
6. Set the required configuration parameters as illustrated below. Please note that enabling file output is not required. Also, IP ranges and cider notation can be set via RHOSTS.
   
7. Type “show options” to confirm you’ve entered your information correctly.
   
8. Type “exploit” to enumerate data from the remote SQL Server and write it to a file. If it fails confirm that the IP address, port, username, and password are correct.
   
9. Open file in excel for easy viewing and sorting.
   

Hopefully someone will find these scripts useful. If anyone has feedback or questions please feel free to email me. I always welcome the opportunity to improve scripts, approach, share knowledge etc. Also, next time I will be releasing a TSQL script and Metasploit module for attacking shared services accounts. In the mean time good hunting.

For those that suffer through this during your Policy Update sessions, there a few ways to break out of this cycle:

1. Establish a Grace Period when policies are updated. This is usually established within a policy about policies (feel like the definition of recursion?). Some organizations will issue policies with a Published Date and next to it an Effective Date. This reminds readers about the Grace Period while reinforcing the expectation that compliance is required in the near future.

a. Pros: Staff can work towards compliance by the established deadline without the label of ‘Non-Compliant.’ Project plans, budgets, and resources can be lined up to tackle the changes.

b. Cons: Effective dates may be too soon for some large changes, but having different effective dates for some projects but not everything leads to confusion. If the timeframes don’t run in parallel with budget cycles then there may not be enough available funds for changes that require fiscal resources. The other concern is that during the Grace Period, there may be the perception of having two active policies which may lead to some confusion.

2. Establish, or merge with an existing, Exception Process for non-compliant areas when the policies are published. If there are areas of non-compliance when the policies are updated then an exception must be immediately requested for a temporary acceptance. Part of this exception process will be to establish a plan of attack for reaching compliance.

a. Pros: The exceptions help to prioritize the identified non-compliant areas which may make it easier to see the total cost of compliance; this method is easier for organizations that have strong Project Management departments.

b. Cons: It may be overwhelming for the team reviewing all the exception requests. Especially for those that can’t assess all associative risks (such as business versus IT risks). There will also be overhead to track all the exceptions and the deadlines. Continual exception requests will have to be managed appropriately.

3. Establish a Hybrid Approach. This method takes a little from each above with tweaks to meet the needs of your organization. For example, establishing a short Grace Period for new / updated policies and anything that will need longer must be identified immediately and go through the Exception Process.

a. Pros: A sooner effective date will meet with regulatory requirements quicker. There may be a smaller Exception handling team yet the organization still receives the benefit of using Project Management to handle the outliers.

b. Cons: It is easy for this method to slide more into the Exception Process without the constant enforcement of the effective dates. A shorter Grace Period may result in an unexpected amount of Exception requests depending upon the policy.

Regardless of the method, the most successful implementations negate the Cons listed above with two major factors: (1) Management’s full support (which includes enforcement) and (2) communication.  Lack of those two elements often will leave you with a feeling that the wheels are spinning, but you aren’t moving.  Of course funding, or the lack thereof, is like a car with no gas – it’s only great if you want to go where you already are. 

The corporate culture may also dictate which approach is more likely to succeed.  Proactive organizations usually try for the Grace Period method while reactive organizations are better suited for the Exception Method.  This isn’t a slight against one or another, but in those instances the culture has established tools and workflows designed for one or the other. 

For example; reactive cultures are usually found in healthcare, especially hospitals, since that’s the name of the game: reacting to the events around them.  Financial institutions tend to be more proactive due to many of the existing regulations (SOX, GLBA, etc.).   It’s not to say that you won’t find Proactive healthcare institutions (which some are trying to be) or reactive financial organizations. 

Hopefully adoption of one of the above methods helps during your next Policy Update cycle so you can make changes happen; as behaviors, controls, and other requirements usually won’t change just because they can. 

“Catch-22 says they have a right to do anything we can’t stop them from doing.

According to Wikipedia, cloud computing is “the delivery of computing as a service rather than a product, whereby shared resources, software, and information are provided to computers and other devices as a utility (like the electricity grid) over a network (typically the Internet).”  What this pretty much amounts to is outsourcing.  There are a lot of reasons that people “move to The Cloud” and I’m not really going to dive into them all; suffice it to say that it comes down to cost and the efficiencies that Cloud providers are able to leverage typically allow them to operate at lower cost than most organizations would spend accomplishing the same task.  Who doesn’t like better efficiency and cost savings?

But what is cloud computing really?  Some people use the term to refer to infrastructure as a service (IaaS), or an environment that is sitting on someone else’s servers; typically, the environment is virtualized and dynamically scalable (remember that whole efficiency / cost savings thing).  A good example of an IaaS provider is Amazon Web Services.  Software as a service (SaaS) is also a common and not particularly new concept that leverages the concept of The Cloud.  There are literally thousands of SaaS providers but some of the better known ones are Salesforce.com and Google Apps.  Platform as a Service (PaaS) is less well-known term but the concept is familiar: PaaS providers the building blocks for hosted custom applications.  Often, PaaS and IaaS solutions are integrated.  An example of a PaaS provider is Force.com.  The Private Cloud is also generating some buzz with packages such as Vblock, and OpenStack; really, these are just virtualized infrastructures.

I’m currently at the Hacker Halted 2011 conference in Miami (a fledgling but well-organized event) and one of the presentation tracks is dedicated to The Cloud.  There have been some good presentations but both presenters and audience members have struggled a bit with defining what they mean by The Cloud.  One presenter stated that “if virtualization is involved, it is usually considered to be a cloud.”  If we’re already calling it virtualization, why do we also need to call it The Cloud? To be fair, The Cloud is an appropriate term in some ways because it represents the nebulous boundaries of modern IT environments.  No longer is an organization’s IT infrastructure bound by company-owned walls; it is an amalgamation of company and third party managed party services, networks, and applications.  Even so, The Cloud is too much of a vague marketing term for my taste.  Rather than lumping every Internet-based service together in a generic bucket, we should say what we really mean.  Achieving good security and compliance is already difficult within traditional corporate environments.  Let’s at least all agree to speak the same language.

My recommendations for mitigating the risk of mobile devices in your environment include the following:

• Establish a Strong Policy
• Educate Users
• Implement Local Access Controls
• Minimize the Mobile Footprint
• Restrict Connectivity
• Restrict Web Application Functionality
• Assess Mobile Applications
• Encrypt, Encrypt, Encrypt
• Enable Remote Wipe Functionality
• Implement a Mobile Device Management System
• Provide Support for Employee-Owned Devices 

For more detailed information, take a look at the white paper that I just put together on the subject: Dealing with Mobile Devices in a Corporate Environment.

Apart from the obvious benefits that such advancements have brought to healthcare, it also brings some responsibilities.  Since Mr. Radcliffe’s presentation there has been lots of discussion about the security of insulin pumps and what the manufacturer should do.  However I’d like to discuss the broader topic and maybe from a slightly different angle. 

Speaking generally about medical device security there is a lot of confusion about what can be done to ensure that privacy and security is maintained on, for all intents and purposes let’s call them “smart” devices.  Many individuals will say that FDA regulated devices cannot be altered in any way.  However; the FDA itself has published articles going back a couple of years now indicating that this is incorrect.  Aware of such misinterpretation a November 2009 post clearly reminds readers that “cybersecurity for medical devices and their associated communication networks is a shared responsibility between medical device manufacturers and medical device user facilities.” 

That’s a powerful statement and what some may think upon first read, unfair.  This doesn’t just say it is solely the responsibility of the device manufacturer but also to the organization that uses, distributes, and maintains them.  If a pump or other medical device that transmits information and/or receives instructions remotely (such as heart pumps) fails, the patient will most likely go back to the covered entity for a reason.  It doesn’t matter if it’s because the pump was damaged, altered maliciously, or just had a design flaw, both organizations will take a public relations hit. 

So what does this mean for covered entities?  Devices used and distributed by covered entities should have had security as part of the design process and allow for updates if necessary.  For example, if the device uses a Windows operating system, how will it receive updates and what department will be responsible for that?  

If you’d like to get more involved in this type of discussion check out the HIMSS Medical Device Security Work Group or the FDA Draft Guidance which is out for comments now.

Two effective methods for identifying sensitive data repositories and transmission channels are data flow mapping and automated data discovery.  A comprehensive and accurate approach will include both.  Note, of course, that both methods assume that you have already defined what types of data are considered sensitive; if this is not the case, you will need to go through a data classification exercise and create a data classification policy.

Data flow mapping is exactly what it sounds like: a table-top exercise to identify how sensitive data enters the organization and where it goes once inside.  Data flow mapping is typically pretty interview-centric, as you will need to really dig into the business processes that manipulate, move, and store sensitive data.  Depending on the size and complexity of your organization, data flow mapping could either be very straightforward or extremely complicated.  However, it is the only reliable way to determine the actual path that sensitive data takes through your organization.  As you conduct your interviews, remember that you want to identify all the ways that sensitive data is input into a business process, where it is stored and processed, who handles it and how, and what the outputs are.  Make sure that you get multiple perspectives on individual business processes as validation and also match up the outputs of one process with the inputs of another.  It is not uncommon for employees in one business unit or area to have misunderstandings about other processes; your goal is to piece together the entire puzzle.

Automated data discovery does a poor job of shedding light on the mechanisms that move sensitive data around an organization but it can be very valuable for validating assumptions, identifying exceptions, and helping to reveal the true size of certain data repositories.  There are a number of free and commercial tools that can be used for data discovery (one of the most popular free tools is Cornell University’s Spider tool) but they all aim to accomplish the same objective: provide you with a list of files and repositories that contain data that you have defined as sensitive.  Good places to start your discovery include network shares, databases, portal applications, home drives on both servers and workstations, and email inboxes.  Be aware that most discovery tools will require that you provide or select a regular expression that matches the format of particular data fields.  However, some more advanced commercial tools also provide signature learning features.

Ultimately, your data discovery exercise should result in a much improved understanding of how sensitive data passes through your organization and where it is stored.  The next step is to determine how to apply controls based on where data is stored, processed, and transmitted.  Also, where necessary, business processes may need to be adjusted in order to consolidate data and meet data protection requirements.   While identification of sensitive data is only the first phase in a process that will result in better data security and reduced risk, it is an absolutely critical step if application of security controls is to be effective.