Monday, November 30, 2009

Patient Information Allegedly Sent to Attorneys’ Offices

Private information about accident victims treated at University Medical Center has apparently been leaking for months, the Sun has learned, allegedly so ambulance-chasing attorneys could mine for clients.

Sources say someone at UMC is selling a compilation of the hospital’s daily registration forms for accident patients. This is confidential information — including names, birth dates, Social Security numbers and injuries — that could also be used for identity theft.

Hospital officials knew of rumors of the leaks since the summer, but doubted them until provided evidence Thursday by the Sun. Now they’re scrambling to catch up to a crisis that may affect hundreds, if not thousands, of patients.

Selling ­— or even giving away — such information would violate federal patient-privacy laws and could result in fines and prison time.
MIAOULIS NOTE:  Could this happen at your organization.  Are you reviewing Audit logs of individuals that are viewing electroninc records of emergency room paitents?

UMC risking steep fines over patients' privacy
Because of recent changes in federal law, University Medical Center could face steep fines over allegations of violations of patients' privacy.
One part of the economic stimulus law enacted in February calls for federal agencies to impose fines as high as $1.5 million on medical providers who inadequately protect patients' data.

Monday, November 16, 2009

Creating STRONGER Passwords (Miaoulis Writes)

HIPAA tells us to train workforce members on the procedures for creating, changing, and safeguarding passwords.  Passwords are a security weak link,  but you should take steps to make them as strong as possible. 

Does your training go something like this, do not use your pets name, your signon ID, passwords that are easily guessed (actual words), and make sure they contain alpha and numeric characters.   Training should instruct individuals in how to create a stronger password.  Some helpful hints for selecting stronger (better) passwords:
  • Select a Phrase and use the first letter of the phrase:  BltpGED#4, is from the phrase, Bill Loves To Play Golf Every Day. 
  • Mix upper and lower case
  • Replace letters with special characters or numbers.
  • Combine parts of words (hapnewyr08, mahaalit$7) (Translation: HappyNewYear and Maryhadalittlelamb)
  • Train users not to number their password (billy#01, billy#02) (see NOTE BELOW) 
There are a couple of sites to test user passwords, one of those is Microsoft, users can use this type site to ensure that their passwords are stronger.  (Note: To be a BEST password, Microsoft requires 14 characters:)
Microsoft provides information on selecting strong passwords at

NOTE: Statistics say to use numbers as part of passwords since there are different permutations, but I am not 100% convinced this is a good idea.  I believe it encourages users to number their passwords (BLtpg#4 becomes BLtpg#5) when forced to change. In classes in which I have asked the questions, fully 95% number their passwords.

There are technical controls that can also assist, systems can be built to require stronger passwords.  If your vendor does not provide a mechanism for stronger passwords, then work with them and the vendor user groups to get stronger passwords.  When selecting new systems, password strength controls should be part of the process.  What are some good controls:
  • Systems that test against common names
  • Systems that give users a couple of day warning to change their password
  • Systems that require password strength (Alpha numeric, caps, password length, etc.).
  • Systems that require you to change more than ONE character.  This is important as many users if not most users, will create a password BLTPGED#4, then when forced to change, go to BLTPG#5.
If you have questions or comments, contact me.

Friday, November 13, 2009

Password Guessing - Easy to Do (Miaoulis Writes)

Passwords can be the weak link in information security.   Many organizations believe that somone guessing would only get three, four or five attempts to guess a password because the system would lock them out. In most cases, this is a FALSE statement. Password guessing can be easy and effective in hacking into a system. There are safeguards and control that organizations can implement to reduce risks. Audit Trail for failed login attempts is one area many organizations do not review frequently enough or take as seriously as they should.

To help folks understand why it is important to review failed login attempts, it is important that organizations understand how a manual hacking attempt can be hatched. Instead of guessing the password of an individual, they will take a phone list, email directory, etc. and using the organizations standard naming convention and then use the SAME password against all accounts. Assuming first initial, last name as a login (Wmiaoulis)a password guessing process can occur something like this. Lets assume we were are in Dallas, the password we will use is Cowboys#1. (local sport teams are favorite passwords of users)

wmiaoulis --- PSWD Cowboys#1
fflintstone --- PSWD Cowboys#1
BRubble --- PSWD Cowboys#1
JNewtron --- PSWD Cowboys#1
SSquarep --- PSWD Cowboys#1

Under this technique, someone guessing passwords could continue for sometime. Using this technique, I have obtained up to 15 passwords in less than two hours.

So what should organizations do? A few things can help to strengthen the inherent weaknesses of passwords.
  • Reviewed failed password attempts by using audit trail, alarms which alert personnel when a threshold is hit (5 from the same terminal) would be a way to reduce risks in this area.
  • Run hacking programs against yourself to identify individuals with weak passwords, coach them on how to select good passwords.
  • Install stronger authentication mechanisms (onetime passwords, tokens, cards, three factor authentication). This is especially important for access outside your facility (Remote Access).
  • Train users on selecting strong passwords (techniques for doing this will be provided in a post next week).
  • Modify the standard sign-on naming convention to something like "wmiaoulis3k" instead of "wmiaoulis" will also limit the ability of organizations to hack. For accounts with special privileges, this is recommended.
Understanding how passwords can be the weak link, organizations should take steps to address this important risk.   Please contact me with questions or comments.   Is your organization taking additional actions to reduce risks?  Share it by posting a comment.

Friday, November 6, 2009

HITECH Impact On Security (Miaoulis Writes)

Original Content - Posted by Bill Miaoulis.

A lot has been written about HITECH and the impact on the security efforts at healthcare organizations.  The changes with regards to security can be summed up in a few statements:
  • Breach Notification means organizations have to tell the world when they have a breach (self reporting on weak security controls?)
  • Criminal and Civil Penalties are more likely (enhanced enforcement) and have been increased significantly.
  • Business Associates and their employees must now comply with HIPAA
With notification, enhanced enforcment and increased penalties, all healthcare organizations should evaluate their current HIPAA compliance and their Security controls. 

It is always better to PREVENT a breach, then REPORT a breach.

Thursday, November 5, 2009

HIMSS Survey: Healthcare organizations' security not up to HITECH standards

CHICAGO – Healthcare organizations aren't prepared to meet privacy and security standards associated with the American Recovery and Reinvestment Act, according to a new survey.

The survey of 196 healthcare information technology and security professionals, conducted by the Healthcare Information and Management Systems Society and sponsored by Symantec Corp., a Mountain View, Calif.-based developer of security, storage and systems management solutions, indicated healthcare organizations aren't using available security technologies to keep patient data safe. Reasons given include stretched budgets and lack of a chief security officer (CSO) or chief information security officer (CISO).

Approximately 60 percent of respondents said their organization spends 3 percent or less of their organization's IT budget on information security. This is consistent to the level of spending identified in the 2008 HIMSS study. And fewer than half of the respondents said their organization has a formally designated CISO or CSO.

Wednesday, November 4, 2009

Breach Notification - Which State Law Applies (Miaoulis Writes)

Original Content - Posted by Bill Miaoulis.

If a hospital in Colorado has a security breach and the breach includes patients from California, North Carolina, Alabama, etc. which state breach notification law applies? From my point of view (I am NOT an attorney and give no legal advice), the State of Colorado Law would apply and of course the Federal HITECH Breach Notification requirements. But some in my profession and some attorneys have stated that the Colorado Hospital would also have to comply with California, North Carolina and Alabama law. If this is in fact true, then it creates a huge responsibility on healthcare providers to comply with the 44 state laws, District of Columbia,Puerto Rico and the Virgin Islands and of course HITECH.

One of the best sources of information about individual states can be found at the

Clearly health care providers need to concern themselves with HITECH and their states Breach Notification Requirements. I would also believe that integrated delivery networks must also comply with any state in which they have a physical presence. The difficult part to answer is when do you have to comply with out of state law. I still find it hard to believe that California Law can govern Hospitals in Colorado, but some folks believe that. Your comments are welcome and appreciated. If you have something to add, please contact me or post a comment.

4th Red Flag Delay - July 2010

At the request of Members of Congress, the Federal Trade Commission is delaying enforcement of the “Red Flags” Rule until June 1, 2010, for financial institutions and creditors subject to enforcement by the FTC.

The Rule was promulgated under the Fair and Accurate Credit Transactions Act, in which Congress directed the Commission and other agencies to develop regulations requiring “creditors” and “financial institutions” to address the risk of identity theft. The resulting Red Flags Rule requires all such entities that have “covered accounts” to develop and implement written identity theft prevention programs to help identify, detect, and respond to patterns, practices, or specific activities – known as “red flags” – that could indicate identity theft.

Monday, November 2, 2009

OCR Press Release: HITECH Act Enforcement Interim Final Rule

The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted as part of the American Recovery and Reinvestment Act of 2009, was signed into law on February 17, 2009, to promote the adoption and meaningful use of health information technology. Subtitle D of the HITECH Act addresses the privacy and security concerns associated with the electronic transmission of health information, in part, through several provisions that strengthen the civil and criminal enforcement of the HIPAA rules.

Section 13410(d) of the HITECH Act, which became effective on February 18, 2009, revised section 1176(a) of the Social Security Act (the Act) by establishing:

Four categories of violations that reflect increasing levels of culpability;

Four corresponding tiers of penalty amounts that significantly increase the minimum penalty amount for each violation; and

A maximum penalty amount of $1.5 million for all violations of an identical provision.

It also amended section 1176(b) of the Act by: 
Striking the previous bar on the imposition of penalties if the covered entity did not know and with the exercise of reasonable diligence would not have known of the violation (such violations are now punishable under the lowest tier of penalties); and

Providing a prohibition on the imposition of penalties for any violation that is corrected within a 30-day time period, as long as the violation was not due to willful neglect.

This interim final rule conforms HIPAA’s enforcement regulations to these statutory revisions that are currently effective under section 13410(d) of the HITECH Act. This interim final rule does not make amendments with respect to those enforcement provisions of the HITECH Act that are not yet effective under the applicable statutory provisions.

This interim final rule will become effective on November 30, 2009. HHS has invited public comments on the interim final rule, which will be considered if received by December 29, 2009.
View the Enforcement Interim Final Rule:

MIAOULIS NOTE: This interim rule does not modify the regulations, but supports the HITECH Act requirements for penalties.

Sunday, November 1, 2009

Palmetto General Hospital employee and accomplice sentenced for stealing patient records

Jacquettia L. Brown, 29, and Tear Renee Barbary, 25, both residents of Miami-Dade County, were both sentenced this week following their conviction on offenses relating to the theft of patient records from Palmetto General Hospital to further a fraud scheme.

U.S. District Court Judge K. Michael Moore sentenced Brown to two years and five days of imprisonment, to be followed by three years of supervised release. Barbary was sentenced to eleven months of imprisonment, to be followed by three years of supervised release. Both Brown and Barbary were prohibited from working in the health care industry while on supervised release.

Brown and Barbary had previously been convicted of conspiracy to commit access device fraud, in violation of Title 18, United States Code, Section 1029(b)(2), and criminal violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), Title 42, United States Code, Sections 1320d-6(a)(2), (a)(3), and (b)(3). In addition, Brown was convicted of aggravated identity theft, in violation of Title 18, United States Code, Section 1028A(a)(1).

Breach Notification Rule - Encryption Key (Miaoulis Writes)

Original Content - Posted by Bill Miaoulis.

The recent guidance on the HITECH breach notification may make encryption more difficult for the organization. Specifically the guidance says that authentication (passwords, etc.) do not provide protection from breach notification and does not qualify to make data indecipherable (see the HHS comments below). This writer agrees that for unencrypted laptops a password is not enough, but what about for encrypted laptops? Is a password enough? Are organizations required to implement two factor authentication, plus encryption to truly be secure?

The guidance also specifically states that the encryption key must be maintained separately from the encrypted data. This may indicate that if you encrypt a laptop, the key to decrypt must reside on a devices such as a thumb drive or central server. Obviously when creating encryption, the rescue key or escrow key should be maintained separately, but the laptop also contains a key to encrypt and decrypt. Assuming this is what the rule is referreing to, then installing encryption protected by a password may be enought to make data protected and not subject to breach notifiction

For data at rest (laptops, Thumbdrives), this creates numerous questions about implementation. For laptops is it enough to keep the escrowed key (rescure/recovery disk) separate from the laptop? Is that what they rule is referring to? However, for databases and backup tapes the keys can be maintained separately.

There is another way to look at the rules. That the two statements are different and do not apply at the same time. The first saying that a password to protect a laptop is not enough and I agree with that. But that an organization using a password (That is not stored on the device) is a confidential process and would offer protection. In other words; a confidential process includes the use of authentication (a password). The guidance can be more easily applied if it is determined that this is adequate. In my opinion, additional guidance is needed from HHS. Organizations should review this rule and determine their own best course of action. Organizations can still comment on this rule and impact the guidance.

The published rule can be found here

From the Comments Section: While we believe access controls may render information inaccessible to unauthorized individuals, we do not believe that access controls meet the statutory standard of rendering protected health information unusable, unreadable, or indecipherable to unauthorized individuals. If access controls are compromised, the underlying information may still be usable, readable, or decipherable to an unauthorized individual, and thus, constitute unsecured protected health information for which breach notification is required. Therefore, we have not included access controls in the guidance; however, we do emphasize the benefit of strong access controls, which may function to prevent breaches of unsecured protected health information from occurring in the first place.

The actual guidance (see page 4 from the published rule, which reprints the guidance): (a) Electronic PHI has been encrypted as specified in the HIPAA Security Rule by ‘‘the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key’’ and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.

Organizations need to make their own decisions, this should not be viewed as providing any legal advise.