Skip to content

HIPAA Security Risk Assessment – Should I bother?

Not only is performing a Risk Assessment best practice to help you manage the risk to your organization, it is part of being compliant with the HIPAA/HITECH regulations, and as a provider practice implementing a qualifying Electronic Health Record (EHR), it is one of the core measures to meet the  Meaningful Use requirements.

If you are a Provider Practice, a Business Associate or implementing a qualifying EMR , you know that a Risk Assessment is required implementation specification under the Security Management Process Standard of the Administrative Safeguards portion of the HIPAA Security Rule as per Section 164.308(a)(1).  The question is, if someone walked into your office and asked to see written evidence of a risk assessment, would you be able to provide it?  When was it performed?  Is it relatively current?  If you can’t show a relatively current written document showing that each area of risk within the HIPAA regulations has been addressed and analyzed, then you don’t meet the test of HIPAA compliance.  The same goes for meeting the core measure of Meaningful Use criteria.

It is about more than just meeting the regulatory requirements of HIPAA and Meaningful Use, protecting the security of your patient’s information is an essential component of delivering quality care and service.  Many of the breaches listed on the Office of Civil Rights (OCR) breach notification website may have been eliminated through an understanding of the risks and the implementation of the proper controls.

At a minimum the HIPAA Security Risk Assessment should:

  • Identify where e-PHI is created, received, maintained, processed or transmitted.
  • Document realistic threats and identify vulnerabilities
  • Assess current security controls that safeguard e-PHI (technical, physical and administrative)
  • Review the likelihood and impact of a threat exercising a vulnerability to determine the level of risk
  • Recommend additional security controls to address deficiencies

The results of the Risk Assessment should provide a road map and guide you in your remediation efforts.  By understanding where the data is and the security control deficiencies present, you can apply effort and budget to the areas of most risk, improving security against changing and ever-increasing threats.

A comprehensive guide for the Risk Assessment process is published in Appendix E of the NIST guide for implementing the HIPAA Security Rule—see NIST 800-66.

Need help in achieving overall compliance with HIPAA/HITECH or meeting the HIPAA compliance requirements of the Meaningful Use rules?  Contact Assurity River Group.

Chris Cathers

Assurity River Group

Posted in All, Information Security Industry.

1 comment

By Chris Cathers – January 28, 2011

BCP Work From Home Test

 Telework Exchange Announces a Nationwide Telework Week – February 14-18, 2011

Remember those business continuity questions about how many staff can work from home? We ask that to determine who has the capabilities to work from home, what processes are able to be performed at home, and if the work-from-home strategy has been tested.

 Here is your opportunity to test your work-from-home strategy! 

View the Telework Exchange announcement and get some of your employees to participate during this Nationwide Telework Week. You may want to consider those sending those employees home to work that perform some of the critical processes. 

The next time that Pandemic hits or that ice or snow storm prevents travel, you’ll be ready to have staff work from home! 

Here is the link: http://www.businesswire.com/news/home/20101117006540/en/Telework-Exchange-Announces-Nationwide-Telework-Week-%E2%80%93

Teri Behling

Assurity River Group

Posted in All.

1 comment

By Teri Behling – January 21, 2011

Update to Facebook Mobile Update Security

As a follow up to the recent Facebook mobile update vulnerability posted here, I wanted to clarify some of the brute force attack details. The initial review of the attack overstated the number of possible Facebook email addresses, due to the size of the dictionary. In order to properly size up the potential brute force attack on the Facebook email status update system, we needed to reduce our dictionary size to only accommodate words that are 2 to 8 characters long.

I started by taking the Scowl dictionary file (http://wordlist.sourceforge.net/) and reducing the size. The dictionary contained multiple words that did not apply to the attack (British, Canadian, Upper Case, Abbreviations, Contractions, Proper Names, Roman Numerals, Hacker Spellings, and Variant spellings) so they were all removed.

By reducing the dictionary to only English and American English words we’re only able to get the dictionary size to 486,156 words. That really does not do us much good, seeing as the Oxford dictionary we previously looked at clocks in at 228,132 words. In order to bring this dictionary file down to a “reasonable” size, I removed any words with apostrophes as they would not be used in the Facebook email addresses. I also filtered the word length down to words between 2 and 8 characters. Furthermore, I only used the two letter “words” that are acceptable for play in Scrabble (source). This brought down the total number of words down to 162,446 potential words to use for generating Facebook status update email addresses.

So working with the new parameters:
> 162,446 words
> 1000 Three digit numbers (000-999)
> 500 Million Facebook users

The number of possible Facebook user emails comes out to 13,194,270,235,000 = (162,446 words choose 2 * 1,000 numbers choose 1)
This is a reduction of over 50% from the 26,021,990,646,000 potential emails that we initially calculated. This increases the probability of hitting one of the 500 million Facebook status update email addresses with one of these generated addresses, to 0.0037%. Still highly unlikely.

Once the possibles list is generated, someone could try the list out against the Facebook email server to see if they are valid email addresses, but that’s not really an option here. Facebook’s email server for the m.facebook.com domain seems to have a * catchall email filter that accepts any email address for delivery, regardless of validity. They also disallow any SMTP VRFY commands to verify the validity of an email address. This is a positive control on their part that prevents an attacker from generating the list of legitimate m.facebook.com email addresses, by slowly checking them against the mail server.

Here’s the code I wrote to generate the list of the email addresses and check them against the mail server with the VRFY command.

Note: 2to8Char.txt is the 2 to 8 character word list and 000to999.txt is all numbers from 000 to 999. Feel free to critique the nested for loops. You’ll have to insert your own tabs, WordPress didn’t like my tabs.

————————–Code Sample————————–

#!/usr/bin/python

# Karl Fosaaen
# Assurity River Group 2010

import os, sys, string, smtplib

i = open(‘totalemaillist.txt’, ‘w’)
f = open(’2to8Char.txt’, ‘r’)

for line in f:
g = open(’000to999.txt’, ‘r’)
for line2 in g:
h = open(’2to8Char.txt’, ‘r’)
for line3 in h:
tofile = “%s” %str(line).rstrip()
tofile2 = “%s%s” %(tofile, str(line2).rstrip())
tofile3 = “%s%s@m.facebook.com\n” %(tofile2, str(line3).rstrip())

#Checks email address against server records
server = smtplib.SMTP(‘mx.snc1.tfbnw.net’)
server.set_debuglevel(1)
response = server.verify(“%s%s@m.facebook.com” %(tofile2, str(line3).rstrip()))
server.quit()

#If the server verified the email, write it to the file
if response[0] == “250″:
i.write(tofile3)
print tofile3

h.close()
g.close()
f.close()

————————–End of Sample————————-

NOTE: YouTube also offers email uploads the same way that Facebook does. My old YouTube upload address was ppag0nno13sl@m.youtube.com. Their implementation seems even more secure than Facebook’s.

Posted in All, Tech Corner.

Tagged with , , , , , , , .

No comments

By Karl Fosaaen – November 11, 2010

Hacked Government and School Websites Selling Viagra is not just a UK Problem

Assurity River Group (ARG) discovered multiple US government websites and schools have also been hacked.  The compromised websites carefully select who to redirect to online drug stores.

Earlier this year a few news articles (such as this one and this one) were published in the UK about British government and educational websites being hacked and subsequently taken over by criminals to sell drugs including Viagra.  It appears as though these types of criminals are not picky about where they sell their goods.  Our research has shown that they have brought their stores overseas to the US as well.

ARG has discovered that even an Air Force website, as well as multiple government websites and colleges have been compromised.

As of this post’s publication the website has been taken down. Watch the video here or on YouTube:

What’s interesting about the drug stores we are examining is the way the criminals appear to hide the drug store websites on the compromised servers.  The compromised website appears to be aware of how the user is arriving at the exploited server and makes a careful decision as to whether or not to redirect the viewer to a drug store.  If you browse directly to the website, no store.  You can only access the drug store if you click on a link from a search engine.  This is pretty clever on the attacker’s part because the regular users of the website will not know that their server has been compromised.  Technically speaking, this is possible because the web server is only redirecting you if you are referred to the site by a search engine.  In our research, the majority of the compromised servers uses a 302 error redirect.

For example, if you were to browse directly to www.vidol.gov you will see the US Virgin Islands Department of Labor.  No drug store.  However, if you were to click on a Viagra link Google suggested, the compromised web server would recognize that you followed a link for Viagra and then forward you to one of the drugstore websites under the control of the criminals.

The criminals appear to be very diligent and thorough in their attacks.  Not only are many web servers compromised and hosting drug stores, but in some instances the domain names for websites were also compromised.  Some examples include “buy-viagra.sacmetrofire.ca.gov” or  “buy-viagra.haskell.edu”.

Protecting Your Website From This Attack

This is a pretty complicated attack and the attackers are taking a novel approach to prevent their activities from being detected. 

External vulnerability / malware scanners ineffective

I scanned multiple compromised websites with a website malware scanner, nothing showed up as suspicious.  I assume because scanner URL requests did not include the referral from a Google search for “viagra online”.  Therefore external scanners may not really find a compromised site.  Remember that the compromised server only shows you the drug store if you found it by a search, not accessed it directly, which is what a scanner would do.

Intrusion Detection

One of the tools I would recommend is to train your intrusion detection system to look for the key words “pharmacy”, “viagra” (et al) coming FROM your web server.  This should be an immediate red flag.

Security Monitoring

Ensure that you are monitoring all administrative and user accounts that have access to modify the configuraiton of your web server.  If these credentials have been compromised, and you are monitoring for unusual login times, you should be quickly alerted to the compromise.

Patch The Software, Harden it

While I haven’t completed the statistical analysis, it appears as though many of the websites compromised are using WordPress.  Ensure that you have patched and locked down your web server.

Stay tuned for additional blogs where we will discuss our research as well as describe our theory on the CONTROL SERVERS for the drug stores and the way they are kept up to date.  It is very complex and we are working on analyzing all the data.  Sites we have found to be hosting web pages for drug stores, or links to drug stores or control servers from a wide range of sites like NASA to Berkley.  We will explain our theory on how message boards appear to be used to “seed” the list of current compromised “central” drug store servers.

Daren Mehl
Senior Information Security Consultant
Assurity River Group

Posted in All, Information Security Industry, Tech Corner.

Tagged with , , , , .

1 comment

By Daren Mehl – October 18, 2010

Facebook Mobile Update Vulnerability

The popular social networking site Facebook allows users to update their profile status many different ways. One of these ways is via email using a user-specific email address at the “m.facebook.com” domain. I’ve recently discovered that Facebook does not actually check the source of the update emails, allowing anyone to update another user’s status if they know the right email address.

For example, my Facebook account is linked to my personal email address (not my assurityriver.com address). By knowing my “private” Facebook email address (smote838tears@m.facebook.com), I’m able to update my Facebook status from my assurityriver.com email address. Facebook only discloses this private status update address to me through the Facebook website, but this blog will outline potential ways for other people to find it out. I have since changed my private Facebook email address, but it serves as a good example for how these addresses are created.

A quick survey of five “m.facebook.com” email addresses showed that the typical email address consists of:

  • One Random Word = smote
  • A 3 digit Number = 838
  • A Different Random Word = tears.

Given that Facebook claims over 500 million users (Source), there would be approximately 500 million “m.facebook.com” email addresses already allocated. For the sake of simple statistical analysis, let’s cap that number at exactly 500 million users.

According to the Oxford Dictionary, there are “full entries for 171,476 words in current use, and 47,156 obsolete words. To this may be added around 9,500 derivative words included as subentries.” (Source) So we can put a conservative dictionary size of 228,132 words. The random words have a typical length of 2 to 8 characters, effectively reducing the size of the dictionary of “random” words. The statistics have not been adjusted to reflect the smaller dictionary size. The numbers do assume that the first random word is not repeated as the second word.

Feel free to correct my statistical analysis here (it’s been a couple of years since I was in statistics), but assuming:

  • 228,132 words in the Oxford dictionary
  • 1000 Three digit numbers (000-999)
  • 500 Million Facebook users

The number of possible Facebook user emails comes out to 26,021,990,646,000 = (228,132 words choose 2 * 1,000 numbers choose 1)

Over 26 trillion possible combinations. Now this sample size can be reduced by the 500 million currently registered Facebook users, but that leaves us with 26,021,490,646,000 invalid or unused email addresses. So in terms of brute force guessing, an  attacker could generate these permutations fairly quickly. In terms of practicality, sending out 26 trillion emails would set off alarms at any ISP. If we start reducing the dictionary size by filtering it to words with 2 to 8 characters, we would surely see a smaller set of possible email addresses, but we won’t go to that level of detail for this blog.

A More Practical Attack

If a user manages to disclose their private “m.facebook.com” email address, they expose themselves to status update hijacking. While this would most likely be used by spammers to push links out to someone’s status updates, it could be used (with some crafty coding) as a self-propagating Facebook worm. Let’s assume that there’s a practical cross-site request forgery (XSRF or CSRF) vulnerability on Facebook’s mobile page(http://www.facebook.com/mobile/). An attacker could host the XSRF code on a site and use the vulnerability to email the visitor’s “private” status update email address to the attacker. The attacker would then use the compromised emails to spam a link out to friends of the victims.

Other possible situations:

A network sniffer could intercept outbound email traffic bound for the the m.facebook.com domain and collect the status update email addresses. Similarly, an email administrator could monitor messages sent to the m.facebook.com domain. Both of these require the attacker to be on the same network as the victims, but they are both likely scenarios. The one item to note, is that most people do not use email to update Facebook. So the probability for these attacks is fairly low.

How to protect yourself:

Although the attack is easy to execute, users do have some protection from status hijacking. As of right now, this attack can only be exploited if an attacker knows a user’s “private” status update email address. Users can protect themselves by guarding their status update address. Facebook could offer an opt-out option for email status updates, but that’s currently not an option that I could find. I personally have no need for updating my status via email and would prefer not having it enabled for my account.

The fix to all of this? Facebook should only accept status update emails from email addresses that are linked to the Facebook account that is being updated. If Facebook really wants to go the extra mile, they could implement a reverse DNS solution to validate that status update email from kfosaaen@assurityriver.com really did originate from the assurityriver.com domain.

Karl Fosaaen
Information Security Consultant
Assurity River Group
kfosaaen@assurityriver.com

Posted in All, Tech Corner.

Tagged with , , , , .

3 comments

By Karl Fosaaen – October 7, 2010