28 June 2012

TEXT MESSAGES used for Patient Care are NOT HIPAA COMPLIANT!


TEXT MESSAGES used for Patient Care are NOT HIPAA COMPLAINT because the telecom servers used to sent those messages are not secure, and the telecoms store the actual content of the messages for up to seven years!

Additionally, the telecoms do not now, nor will they likely in the future, provide proper HIPAA / HITECH training to their employees. Telecoms also do not provide Letters of Agency to outside contractors and are not compliant with data and log retention policies required under the HITECH portion of HIPAA

All of these things are required to meet the compliance requirements required by HITECH.

In a recent article in Wired Magazine, Wired included data which showed the SMS message and data retention policies of the four major wireless carriers. Wired included data which showed the SMS message and data retention policies of the four major wireless carriers

Wired's article, which can be found here, was based on a secret memo obtained from the Justice Department.

The memo exposes the length of time which data is stored by wireless carriers. Of concern in this article is both the amount of time that TEXT or SMS messages are stored by wireless carriers and the fact that that data is neither stored on secured servers or by employees and vendors who have been properly trained under the HITECH portion of the HIPAA requirements.



While the second line of the chart shows that the CONTENT of the message may only be contained for 3 to 5 days, the fact that this is saved at all raised questions under HIPAA / HITECH.  Because the first line states the DETAIL of the message is saved for up to 7 years, we can realize that some providers choose to keep the CONTENT of the message in the DETAIL of the message.  Either way, the fact that they are saving confidential patient PHI for even a second, along with the fact that the data it is running through unsecured servers and data circuits, this is clearly a violation of HIPAA / HITECH.


The next two line show IP SESSION and IP DESTINATION information.  Because IP assignment records are kept for various periods by the different carriers, this ties patients and healthcare providers together because the IP session and destination information can be directly tracked back to a specific provider who is caring for a specific patient.
In the last lines, we see the call detail record retention rates.  While many may construe this to pertain only to voice calls, SMS or TEXT MESSAGES are part of those call records and, once again, this can be used to tie specific providers to specific patients.
To both handle and save patient PHI data, as well as to meet the requirements of HIPAA / HITECH, requires the use of:
  • secure servers;
  • controlled access to the servers;
  • controlled access to server rooms based on a need to have access basis only;
  • security training on a minimal time table of at least twice a year, and;
  • a written business associate agreement between the healthcare provider who uses the telecom provider's text messaging service and the service provider.
Because the telcos also have outside vendors who work with the switches and software, this will also require business associate agreements with everyone who comes in contact with the switches and even the buildings in which they are housed.  The HITECH portion of HIPAA also requires those same business associate agreements and training for everyone who maintains the cellular towers and the lines between the towers and the provider's switches.

The servers used by telecom providers are not HIPAA / HITECH secure.  I have yet to see a telecom provider, wireless or landline, sign a business associate agreement with a healthcare provider.  I also believe that it is unlikely that any telecom provider will ever sign a business associate agreement because telecoms love to hide behind the fact that they are regulated by the Federal Communications Commission and are not beholden to any other rules or regulation.

The problem is the fact that SMS / TEXT messaging is so readily available.  Almost everyone who has a smart phone, cell phone, tablet, or any other device which is SMS equipped has SMS / TEXT messaging capability.

Because SMS / TEXT messaging is so easily used, via small and portable wireless devices, text messaging is has the potential to be, and is perceived to be, an extremely valuable tool to healthcare.  In reality, it is.  From a security standpoint, it is not.

Unfortunately, and primarily because of the non-compliance with HIPAA / HITECH, SMS and TEXT messaging use must be prohibited by healthcare providers at this time - prohibited until the issue of PHI, data security, server security, network security and HIPAA / HITECH compliance is addressed.

The solution is not going to be implemented at the level of the wireless provider and telcos.

The good news is that there is a solution.  The solution is the adaptation of secure SMS and TEXT MESSAGING systems from third-party providers.  While this places an additional burden on healthcare providers, it is the only way to ensure that patient data is properly protected and secured as we move forwarded under HIPAA / HITECH.


================================================

Read all of ChicagoNetTech's security blogs at: http://networkbastion.blogspot.com/

If you have any questions, or are looking for hosted solutions, please feel free to contact me.
Copyright © 2012, Bruce Barnes, ChicagoNetTech Inc, All Rights Reserved

01 June 2012

Snooping Mobile Security Apps!

Have you notice how snoopy mobile security apps have become in recent months?

NOTE: the products listed below were chosen at random from Google's Play store.  [don't even get me started on why someone would call an app market a "PLAY" store!]


Let's start with Norton's mobile product.  Norton can:
  • add and modify calendar events and sent e-mail to guests
  • read your browser's history and bookmarks
  • read your calendar events, read contact data, read sensitive log data, wrote browser's history and bookmarks and write contact data.
  • intercept outgoing calls - allows applications to process outgoing calls and change the number to be dialed.
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • modify SD card contents
  • create Bluetooth connections because it allows the phone to make and accept connections with paired devices.
  • allow Bluetooth to discover and pair with remote devices
  • create its own network sockets because it must have full network access at all times
  • modify global system settings and modify the systems settings data.
  • access course location sources like the cellular network database to determine an approximate the approximate location of your phone
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • change your audio settings
  • access extra location provider commands

How about BITDEFENDER?  Bitdefender can:
  • add and modify calendar events and sent e-mail to guests
  • read your browser's history and bookmarks
  • read your calendar events, read contact data, read sensitive log data, wrote browser's history and bookmarks and write contact data.
  • intercept outgoing calls - allows applications to process outgoing calls and change the number to be dialed.
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • modify SD card contents
  • create Bluetooth connections because it allows the phone to make and accept connections with paired devices.
  • allow Bluetooth to discover and pair with remote devices
  • create its own network sockets because it must have full network access at all times
  • modify global system settings and modify the systems settings data.
  • access course location sources like the cellular network database to determine an approximate the approximate location of your phone
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • change your audio settings
  • access extra location provider commands

TOPJOY MOBILE SECURITY.  Topjoy Mobile Security can:
  • modify your SD card contents
  • disable keylock and prevent your phone from sleeping
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • create its own network sockets because it must have full network access at all times
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages

MOOBILA ANTIVIRUS FOR ANDROID:
  • modify your SD card contents
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • create its own network sockets because it must have full network access at all times
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • control the vibrator on your phone

MOBILE CLOUD SOLUTIONS - Andriod AntiTheft Security
  • modify your SD card contents
  • read the phone state and identity - allows the application to access the phone features of the device.  It can determine the phone number, serial number of the phone, whether a call is active and the number the call is connected to.
  • create its own network sockets because it must have full network access at all times
  • access the GPS system to get a more accurate location of you phone
  • directly call numbers - potentially costing you money
  • send SMS messages, but it does not state that you can limit those SMS messages
  • discover known accounts
While I am an avid supporter of both mobile antivirus programs and encryption software being installed on any mobile device, whether it be a smart phone, laptop, tablet, or any other mobile device, I feel we all need to be aware of what these applications we are installing have access to.

In some cases, as shown by the very limited number of examples I have listed below, I also believe they go a bit too far.  Since when does a mobile protection application need to detect and log the telephone number of a call you are connected to?  If there is a name associated with the call, and you are a doctor or nurse, this could potentially be a violation of the HITECH portion of the HIPAA laws.

My point is, before you download ANY application, make certain you have read the information on what the product has access to, how it has access and try to find out WHY it must have that access.

It's user beware when it comes to applications.  While protecting our mobile devices is a critical part of the security which we must now endure, we also need to make certain we are dealing with a reputable vendor who doesn't snoop too much in the wrong places in the name of "protecting" us.

================================================

If you have any questions, or are looking for hosted solutions, please feel free to contact me.


Copyright © 2012, Bruce Barnes, ChicagoNetTech Inc, All Rights Reserved



06 February 2012

Anonymous vs the FBI . . .

When the hacker group, Anonymous, found out that Scotland Yard and the FBI were planning a conference call to discuss how to deal with Anonymous, and several other groups considered to be nefarious, the e-mail, setting up and giving conference call meeting instructions, was intercepted by someone from the group Anonymous.

Anonymous then used this information to their advantage to turn the tables on the FBI and Scotland Yard by recording the scheduled call and posting it on YouTube.


So how was Anonymous able to intercept an e-mail which should have been both encrypted prior to sending and sent via an encrypted network?
The answer lies in the fact that all e-mail is sent as PLAIN TEXT across the Internet.  Unless the message is encrypted, either at the workstation, or via the e-mail server software, it is PLAIN TEXT and can be read by anyone who can capture the data during its journey.


Short answer:  Either someone at the FBI got lazy, and there was no SSL/TLS on the FBI e-mail servers or one or more of the recipients has a very poor password on their e-mail account.


Whether the original sender of the message “forgot” to encrypt, his workstation was not equipped to encrypt, the connection between his workstation was not encrypted, or the FBI is not equipped to encrypt, this incident is unforgivable and, once an investigation has been completed, the responsible parties be should terminated.


In fact, this should not be under the control of the sender of the e-mail at all.  With any government security agency, or even with any business, the process of encrypting e-mail should be fully automatic and transparent to the users.


E-mail, unless encrypted, is sent as plain text over the public Internet, I always advise both my hosted and consulting clients to “never write anything in an e-mail message you would not want to see in the newspaper or on TV.”  They usually laugh when I say that but my concerns are being borne out by both the reports which have so frequently appeared in the new and the fact that there are so many new legal requirements mandating e-mail  encryption in the banking, healthcare, legal, and ever increasing numbers of other business groups.


So, now that the proverbial cat is out of the bag at the FBI, what can you do to prevent your e-mail from getting into the wrong hands?

At ChicagoNetTech we run TLS on our SmarterMail e-mail server product.  TLS is an extension of the SSL encryption protocol which actually allows our clients to both make an SSL connection to the e-mail server to originate their e-mail via POP, IMAP, ActiveSync, or our SSL encrypted web interface if so desire, originate their e-mail message, and send it through the Internet via the TLS security protocol.


TLS is a relatively new encryption capability on many e-mail systems and, as part of the transmission process, encrypts inter-e-mail server data traffic so it cannot be easily intercepted.
Whether or not TLS is supported by an e-mail server is very easily tested.  In the case of e-mail sent to and from Timothy Lancaster, the originator of the conference call intercepted by Anonymous, we see the following results:

The US FAILS:
TestReceiver
CheckTLS Confidence Factor for "Timothy.Lauster@ic.fbi.gov": 0
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
mail.ic.fbi.gov
[153.31.119.142]
10
OK
(85ms)
OK
(786ms)
OK
(74ms)
FAIL
FAIL
FAIL
OK
(1,020ms)
OK
(76ms)
Average

100%
100%
100%
0%
0%
0%
100%
100%


The results in the grid above show that the FBI’s e-mail server FAILS the most basic of Internet e-mail security, TLS.  The e-mail server used for the FBI’s domain, IC.FBI.GOV does not have even the most basic of security enabled.

Repeating this TLS check test for Stewart.Garrick@met.police.uk shows the same thing:

ENGLAND FAILS:
TestReceiver
CheckTLS Confidence Factor for "Stewart.Garrick@met.police.uk": 0
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
mail3.met.police.uk
[212.74.97.198]
15
OK
(180ms)
OK
(167ms)
OK
(169ms)
FAIL
FAIL
FAIL
OK
(682ms)
OK
(163ms)
mail4.met.police.uk
[212.74.97.212]
15
OK
(181ms)
OK
(165ms)
OK
(164ms)
FAIL
FAIL
FAIL
OK
(673ms)
OK
(165ms)
mxbackup.uk.cw.net
[195.92.195.234]
20
OK
(155ms)
OK
(241ms)
OK
(144ms)
FAIL
FAIL
FAIL
OK
(686ms)
OK
(782ms)
Average

100%
100%
100%
0%
0%
0%
100%
100%

The e-mail servers for the domain MET.POLICE.UK FAIL the TLS test and do not have the capability to encrypt inter-domain e-mail messages.
Validating against other domains included in the e-mail message intercepted by Anonymous, we the following results on the part of the e-mail servers used by other high-level security officials in other countries who were invited to participate in the conference call:

FRANCE PASSES:
TestReceiver
CheckTLS Confidence Factor for "olivier.nael@interieur.gouv.fr": 90
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
tigre.interieur.gouv.fr
[212.234.218.76]
10
OK
(172ms)
OK
(337ms)
OK
(162ms)
OK
(161ms)
FAIL
OK
(1,433ms)
OK
(163ms)
FAIL
Average

100%
100%
100%
100%
0%
100%
100%
0%

Note: Cert failures do not affect TLS encryption, but may mean the site isn't who they say they are.

NOTE that the CERT failure means that the TLS test was unable to verify the e-mail address.   They may be because it was changed since being published by Anonymous or that the domain INTERIEUR.GOUV.FR runs Greylisting.  If we test in a few minutes and the CERT OK changes to PASS, then we will know they run Greylisting.

The NETHERLANDS PASSES:
TestReceiver
CheckTLS Confidence Factor for "michel@nhtcu.nl": 90
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
pochta3.nhtcu.nl
[83.149.67.40]
8
OK
(154ms)
OK
(688ms)
OK
(144ms)
OK
(143ms)
FAIL
OK
(1,663ms)
OK
(150ms)
OK
(149ms)
pochta4.nhtcu.nl
[83.149.94.112]
9
OK
(154ms)
OK
(159ms)
OK
(144ms)
OK
(145ms)
FAIL
OK
(1,138ms)
OK
(150ms)
OK
(151ms)
Average

100%
100%
100%
100%
0%
100%
100%
100%

GERMANY PASSES:
TestReceiver
CheckTLS Confidence Factor for "andre.dornbusch@iuk.bka.de": 90
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
smtp.ts-businessmail.de
[217.150.155.10]
100
OK
(209ms)
OK
(696ms)
OK
(174ms)
OK
(175ms)
FAIL
OK
(1,934ms)
OK
(404ms)
FAIL
Average

100%
100%
100%
100%
0%
100%
100%
0%

SWEDEN FAILS:
TestReceiver
CheckTLS Confidence Factor for "peter.ericson@rkp.police.se": 0
MX Server
Pref
Con-
nect
All-
owed
Can
Use
TLS
Adv
Cert
OK
TLS
Neg
Sndr
OK
Rcvr
OK
mail.telia.com
[62.20.233.128]
10
OK
(193ms)
OK
(182ms)
OK
(178ms)
FAIL
FAIL
FAIL
OK
(1,118ms)
FAIL
Average

100%
100%
100%
0%
0%
0%
100%
0%



Getting back to that "what happened" question asked at the top of this posting, it looks like neither the FBI, nor several other high-security installations run TLS!

While I would certainly not consider TLS to be the only security protocol implemented for communications between international security agencies, it should, at the very least, be a jumping off point for any secure e-mail communication.

No matter what kind of e-mail server you are running, or what purpose you are running your e-mail for: personal, business, not-for-profit, whatever the use, always remember that e-mail is transmitted as plain text across the internet and should always be encrypted.


The level of encryption depends on both regulatory requirements and what your business does.  HIPAA / HITECH, Sarbanes Oxley, and government regulations all have similar, and, because of highly publicized incidents like the one outlined above, merging requirements.


Protect yourself now.  Check the status of your e-mail encryption and make certain you are running TLS on your mail servers – as a very MINIMUM requirement.


You can check your e-mail server's TLS capabilities at: http://www.checktls.com/perl/TestReceiver.pl.


Select "CertDetail" from the drop-down box for intensive result reporting.
If you have any questions, please feel free to contact me and we can discuss your e-mail and network security to make certain your business is protected.


Now for the fun part, the actual e-mail intercepted by Anonymous is listed below.


NOTE: Because this has been previously published on the Internet by Anonymous, we decided to keep all of the data exactly as previously published:

======================================
MIME-Version: 1.0
acceptlanguage: en-US
Accept-Language: en-US
Content-class: urn:content-classes:message
Subject: Anon-Lulz International Coordination Call
Date: Fri, 13 Jan 2012 19:21:49 -0000
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: Anon-Lulz International Coordination Call
From: "Lauster, Timothy F. Jr." Timothy.Lauster@ic.fbi.gov To: "Reichard, Gerald A." Gerald.Reichard@ic.fbi.gov,
paul.hoare2@met.police.uk,
Raymond.Massie@met.police.uk,
trevor.dickey@met.pnn.police.uk,
Stewart.Garrick@met.police.uk,
"Gillen, Paul G" paul.g.gillen@garda.ie,
"Gallagher, Colm" colm.gallagher@garda.ie,
pim@nhtcu.nl,
Gea@nhtcu.nl,
michel@nhtcu.nl,
olivier.nael@interieur.gouv.fr,
olivier.moalic@interieur.gouv.fr,
thierry.mezenguel@interieur.gouv.fr,
andre.dornbusch@iuk.bka.de,
peter.ericson@rkp.police.se,
stefan.kronqvist@rkp.police.se,
ulrika.sundling@rkp.police.se,
Jaap.Oss@europol.europa.eu,
valentin.gatejel@europol.europa.eu,
"Helman, Bruce C. Jr." Bruce.Helman@ic.fbi.gov,
"Sporre, Eric W." Eric.Sporre@ic.fbi.gov,
"Buckler, Lesley" Lesley.Buckler@ic.fbi.gov,
"Geeslin, Robert C." Robert.Geeslin@ic.fbi.gov,
"Plunkett, William R." William.Plunkett@ic.fbi.gov,
"Roberts, Stewart B." Stewart.Roberts@ic.fbi.gov,
"Brassanini, David" David.Brassanini@ic.fbi.gov,
"Stangl, Christopher K." Christopher.Stangl@ic.fbi.gov,
"Patel, Milan" Milan.Patel@ic.fbi.gov,
"Ng, William T." William.Ng@ic.fbi.gov,
"Adams, Melanie" Melanie.Adams@ic.fbi.gov,
"Culp, Mark A." Mark.Culp@ic.fbi.gov,
"Arico, Nicholas J." Nicholas.Arico@ic.fbi.gov,
"Tabatabaian, Ramyar" Ramyar.Tabatabaian@ic.fbi.gov,
"Penalosa, Jensen" Jensen.Penalosa@ic.fbi.gov,
"Bales, Will" Will.Bales@ic.fbi.gov,
"Burton, Kevin C." Kevin.Burton@ic.fbi.gov,
"Nail, Michael A." Michael.Nail@ic.fbi.gov,
"Grasso, Thomas X." Thomas.Grasso@ic.fbi.gov,
"Thomas, Christopher T." Christopher.Thomas@ic.fbi.gov,
"Caruthers, John" John.Caruthers@ic.fbi.gov,
"Phoenix, Conor I." Conor.Phoenix@ic.fbi.gov,
"Hunt, Chad R." Chad.Hunt@ic.fbi.gov,
"Willett, Bryan G." Bryan.Willett@ic.fbi.gov,
"Patrick, Kory D." Kory.Patrick@ic.fbi.gov

All, 
A conference call is planned for next Tuesday (January 17, 2012) to discuss the on-going investigations related to Anonymous, Lulzsec, Antisec, and other associated splinter groups 
The conference call was moved to Tuesday due to a US holiday on Monday.

Date: Tuesday, January 17, 2012
Time: 4:00 PM GMT=20
BridgeTN: 202-393-2430
Access Code: 6513211# 
Please contact me if you have any questions.

Regards,
Tim

SSA Timothy F. Lauster, Jr
Federal Bureau of Investigation
202-651-3211 (w)
202-651-3193 (f)
Protect your e-mail server today

- ENCRYPT YOUR COMMUNICATIONS!


======================================
If you have any questions on how to do so, or are looking for hosted solutions, please feel free to contact me.

Copyright © 2012, Bruce Barnes, ChicagoNetTech Inc, All Rights Reserved