This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "MHWG Security"

From HL7Wiki
Jump to navigation Jump to search
Line 137: Line 137:
  
 
'''Information Owner'''<br/>
 
'''Information Owner'''<br/>
.. an entity whose information is stored and/or processed on a device..”<br/>
+
.. an entity whose information is stored and/or processed on a device..”<br/>
“  .. an Information Owner can be an application specific provider, a digital product provider, or an enterprise that allow access to resources from mobile devices..”<br/>
+
“  .. an Information Owner can be an application specific provider, a digital product provider, or an enterprise that allow access to resources from mobile devices..”<br/>
“ .. it is assumed that each mobile device has a single Device Owner and one or more Information Owners..”
+
.. it is assumed that each mobile device has a single Device Owner and one or more Information Owners..”
 +
 
 
=== Private Usage ===
 
=== Private Usage ===
 
< Cases to be provided>
 
< Cases to be provided>

Revision as of 21:40, 3 October 2013

Mobile Health: Security Subgroup

Subcommittee

Chair: Paul Petronelli
Co-Chair: David Gobuty

Members:

Ed Heierman
David.P. Morris.jr
May Ng
John Moehrke
Nadine Manjaro
Jeff Brandt
Jay Kaspberger
Allen Hobbs
Tim A. Mckay

Frequently Asked Questions and Answers

mHealth Identification

What is identification in the realm of MHealth Devices?

Identification enables the device to present controls and displays tailored to the work the user intends to perform with it. It also links the identification to the record of actions performed using the device.

How does identification differ from authentication?

Identification begins to form a link between the device and a specific user (or users), while authentication raises likelihood to an acceptable level that the user (or users) are who they claim to be.

Why require an identification step?

Identification can enable presentation of role-specific controls and displays. In this way it can manage access to controls and displays for which an identified user is not privileged to use or see. For example, identification as a general user can preclude changes to the audit record, a privilege that would be available only to an administer user (whose identification would be added to the audit record as the one who made the change).

Is identification necessary for a personal MHealth device?

Identification can occur concomitantly with authentication providing the number of users is small (one or two individuals), provided the automated identification controls against change to sensitive audit records. Identification can require specific action to gain privilege to use controls and view displays that should be reserved when the single user wants to acting as an administrator. This can prevent inadvertent changes to device settings or audit records.

Does a MHealth device need an identification step if used by more than one person?

Yes, because the audit record must contain the identification of the user responsible for the recorded event.

How is identification used in a MHealth device?

Identification enables role-based management of controls, displays and privilege available to a specific user.

Can identification and authentication be performed in a single step?

In personal MHealth devices, where the user population is small (one or two individuals), the identification and authentication steps can be performed in a single action, provided there are measures in place to control against manipulation of audit records.

mHealth Authentication

What is authentication in the realm of mHealth Devices?

Authentication is a process that can raise likelihood to an acceptable level that a claimed identity is true. “Users” of mHealth devices can be an individual or individuals, or another device with authority to interact with it. Authentication attempts to prove that the identity of a user or a device is in fact the user or device it purports to be.

What is the relationship between authentication and authorization?

Authentication is distinct from authorization, where the former attempts to prove validity of a claimed identity, while the latter describes the access privileges to which an authenticated identity can be granted. Authentication ensures that the individual or device is who or what it claims to be, so that accurate access rights can be granted and meaningful audit records can be collected, but of and by itself says nothing about the authorizations themselves.

What are common authentication mechanisms?

Authentication can be implemented based in the concept (or factor) of something known. It may also be linked to the factor of something had. A password (something known) can authenticate a claimed identity when it is carefully constructed, stored safely, e.g., memorized, and carefully revealed during logon. A token or cypher (something had) can also be used to authenticate a claimed identity when it is safeguarded when not in use and carefully presented or computed during logon.

What is meant by one factor or two factor authentication?

One factor authentication or two factor authentication refers to the number of factors employed to prove a claimed identity. Using only a password or a token to authenticate a claimed identity is an example of a one factor authentication system; using both a password and a token is an example of a two factor authentication mechanism. Logically, authentication can be based on employing one or more factors.

Must authentication always be the 2nd step in granting access?

No, identifying and authenticating a user or a device before granting access to an mHealth Device can be performed in a single step if the user or device attempting access can be unequivocally associated with the credential presented. For example, when an mHealth device supports access by a limited realm of users, both identification and authentication can be processed as a single step. Typically, when authorized devices attempt access to an mHealth device and present a computable cypher as their authentication token, a separate identification step is not necessary.

What should happen when either the identification or the authentication process does not successfully conclude?

Failure of the identification or authentication process should result in the mHealth Device denying access. The user or device should simply be alerted to the fact the credentials presented were in error. The mHealth Device should not specify which credential was faulty.

General Design Issues

  1. Can identification be tied to SIM (Subscriber Identity Module) card of the user mobile device?
    This would enable the user to access Personal health Records from his/her device.
    Answer: <To be supplied>
  2. What are the safeguards to protect the patient’s data if the device is stolen?.
    Answer: <To be supplied>
  3. What kinds of authentication/authorization could be used in this scenario to verify that the person accessing the information is actually the intended user?.
    Answer: <To be supplied>
  4. Can biometrics be used?.
    Answer: <To be supplied>
  5. Will the data be encrypted during transit?.
    Answer: <To be supplied>
  6. Will the data be encrypted at rest?.
    Answer: <To be supplied>
  7. How do you prevent replication of PHR data onto unsecure platforms or environments?.
    Answer: <To be supplied>

Business Associate Agreement

There are new platforms that are entering the discussion such as Samsung SAFE that provide an environment of security. There are also companies such as Box that claim that their systems are HIPAA compliant. We may want to look into what this really means for the security of PHI

Discussion with Nathan I'm not sure I understand your question Jeff. When you say "organizations" do you mean such as eligible providers?

If so, then if patient data passes through the app developers systems in any way, then according to the recent Omnibus they would need to have a BA in place with them. If it is only that the application is being purchased and installed locally then I would think not. In that case, providers would just need to make sure that the general contract for the purchase confirms that it passes all OCR requirements and would need to.

What Box seems to be implying though is that data stored by them for your organization is HIPAA compliant. This is the quote from their literature: "Box supports HIPAA and HITECH compliance following the Department of Health and Human Services’ publication of the Omnibus Final Rule in January of 2013. Box also signs HIPAA Business Associate Agreements (BAAs) with customers."

On Fri, May 24, 2013 at 11:24 AM, J Brandt <jbrandt@comsi.com> wrote: There are a lot of apps on the market that claim security, however there is not way to confirm. Box with sign a BA with the developers; I assume organizations should have BA with the App developers?? Jeff

Data Storage on Mobile Devices

These are extracted from information that will be available in a soon to be published CLSI Auto11 Document on the Security of IVD Instruments (I’ve contributed to the development of this document). These were initially identified from the perspective of diagnostic instruments and systems, but really apply for most mHealth applications/devices. These could be broken down into more than one FAQ, and additional details could be provided.

What are some guidelines to follow pertaining to the storage of data on mobile devices?

  • mHealth data on a mobile device should not be stored or the storage should be treated as temporary and not reliable.
  • The confidentiality of data transmitted to the mobile devices should be assessed based on the risk assessment of the specific use cases and involved systems.
  • The mHealth data should be encrypted on the mobile device.
  • The validity of mHealth data stored on mobile devices should be limited to current user session.
  • mHealth data stored on mobile devices should be removed when the user session ends.


Examples of when a user session ends include:
  • Within 1 hour after end of the working shift of the user of this mobile device
  • Connection to the network is lost for a period of time
  • Logging off the device
  • Logging out of the application

Also, HIMSS has a “mHIMSS Mobile Privacy & Security Toolkit” that contains quite a few references on various topics. The Wiki could point to this resource as a general source of information: http://www.mhimss.org/resource/mhimss-mobile-privacy-security-toolkit

Biometrics

<To be supplied>

National Institute of Standards (NIST)

<To be supplied>

Use Cases for Mobile Devices

These use cases deal with the security issues for mobile medical devices in a number of environments.

Terminology (From NIST 800-164 (Draft)

Device Owner

“  .. an entity that has purchased and maintains ownership of a mobile device…”

Information Owner

“  .. an entity whose information is stored and/or processed on a device..”
“ .. an Information Owner can be an application specific provider, a digital product provider, or an enterprise that allow access to resources from mobile devices..”
“ .. it is assumed that each mobile device has a single Device Owner and one or more Information Owners..”

Private Usage

< Cases to be provided>

<BYOD>
<Enterprise provided device>
<Centralized authentication>
<Local authentication>
<Shred devices>


Enterprise Usage

The following remarks are from the executive summary of: NIST Special Publication 800-124 Revision 1, Guidelines for Managing the Security of Mobile Devices in the Enterprise, June 2013:
• Organizations should have a mobile device security policy
• Organizations should develop system threat models for mobile devices and the resources that are accessed through the mobile devices
• Organizations deploying mobile devices should consider the merits of each provided security service, determine which services are needed for their environment, and then design and acquire one or more solutions that collectively provide the necessary services
Most organizations do not need all of the possible security services provided by mobile device solutions. Categories of services to be considered include the following:
General policy: enforcing enterprise security policies on the mobile device, such as restricting access to hardware and software, managing wireless network interfaces, and automatically monitoring, detecting, and reporting when policy violations occur.
Data communication and storage: supporting strongly encrypted data communications and data storage, wiping the device before reissuing it, and remotely wiping the device if it is lost or stolen and is at risk of having its data recovered by an untrusted party.
User and device authentication: requiring device authentication and/or other authentication before accessing organization resources, resetting forgotten passwords remotely, automatically locking idle devices, and remotely locking devices suspected of being left unlocked in an unsecured location.
Applications: restricting which app stores may be used and which applications may be installed, restricting the permissions assigned to each application, installing and updating applications, restricting the use of synchronization services, verifying digital signatures on applications, and distributing the organization’s applications from a dedicated mobile application store.


• Organizations should implement and test a pilot of their mobile device solution before putting the solution into production.
• Organizations should fully secure each organization-issued mobile device before allowing a user to access it.
• Organizations should regularly maintain mobile device security

Clinical Usage

< Cases to be provided>

List of useful References

Tutorials

The following were presented at the HL7 meeting in the Security wg free Wednesday tutorial. It speaks of very basic mobile device security and points at NIST 800 documents for details. This helps set the ground work for the later discussion on specifics of user identity, and application identification...

http://healthcaresecprivacy.blogspot.com/2013/05/security-tutorials-on-mhealth-security.html

Standards

<To be supplied>

Industry Agreements

<To be supplied>

HL7 Organization

<To be supplied>