FDA Issues Alert Over Vulnerabilities in Abbot Laboratories Defibrillators

Posted by HIPAA Journal

The U.S. Food and Drug Administration has issued an alert about certain Abbott Laboratories implantable cardiac devices over cybersecurity vulnerabilities that could potentially be exploited to alter the functioning of the devices.

Certain implantable cardiac defibrillators (ICDs) and cardiac resynchronization therapy defibrillators (CRT-Ds) are affected, including the Current, Promote, Fortify, Quadra, Unify, and Ellipse families of products. The flaws do not exist on pacemakers or cardiac resynchronization pacemakers (CRT-Ps).

Exploitation of the vulnerabilities is possible using commercially available equipment that could be used to send commands to the devices via radio frequencies. For the vulnerabilities to be exploited, an attacker would need to be in relatively close proximity to the device.

Were an attack to happen, it would be possible to alter the function of the devices and cause them to deliver inappropriate packing and shocks or cause the batteries to deplete prematurely. Exploitation of the vulnerabilities therefore has potential to cause harm to patients.

The vulnerabilities are being addressed with a firmware update. The FDA has assessed the update and confirmed that it mitigates the vulnerabilities and reduces the potential for harm to a reasonable level. After receiving the update, any device that attempts to connect to the ICD or CRT-D would need to provide authentication before any changes could be made.

Abbott Laboratories notes in a recent press release that there have been no reports of the vulnerabilities actually being exploited, and that the update is not an emergency measure but part of a series of planned updates to improve cybersecurity.

The firmware update also corrects an unrelated issue with the lithium ion batteries which can cause them to deplete rapidly, in some cases within a day. This is not caused by malicious actors, instead it is a problem with the batteries, which can form lithium deposits that create abnormal electrical connections. The update includes a new battery depletion alert that will be triggered if rapid battery depletion is detected, informing the patient that they must arrange to visit their physician as soon as possible.

The firmware update cannot be applied remotely. Patients must visit their provider to have their ICD or CRT-D updated.

The update will take approximately 3 minutes during which time the device will operate in backup VVI mode. High voltage therapy will be temporarily disabled and there is potential for the device to deliver no pacing for up to three seconds during the update.

Any firmware or software update has potential to cause a device to malfunction, although the risk is very low and a previous firmware update in August 2017 resulted in no serious malfunctions. In 0.62% of cases, the update was not applied in full. In such cases the issue was rapidly resolved with Technical Services. To reduce the risk of problems, a programmer update has been incorporated which should keep update errors to a minimal level.

Certain devices cannot accept the update due to technical limitations. A fix has been offered by Abbott Laboratories that involves switching off RF functionality via the Merlin@home programmer. While this fix will prevent any exploitation of the vulnerabilities, it would also prevent the device from sending data directly to the physician’s office. Consequently, the FDA recommends that RF functionality is not disabled.

The post FDA Issues Alert Over Vulnerabilities in Abbot Laboratories Defibrillators appeared first on HIPAA Journal.

California Dept. of Developmental Services Notifies 582,000 Patients of Potential PHI Compromise

Posted by HIPAA Journal

The California Department of Developmental Services (DDS) is notifying 582,174 patients that their protected health information has potentially been compromised.

On February 11, 2018, thieves broke into the DDS legal and audits offices in Sacramento, CA. During the time the thieves were in the offices they potentially had access to the sensitive information of approximately 15,000 employees, contractors, job applicants, and parents of minors who receive DDS services, in addition to the PHI of more than half a million patients. The thieves also stole 12 government computers.

It does not appear that the perpetrators were interested in paper records and all computers taken by the thieves were encrypted so data access was not possible. DDS has confirmed that none of the office computers were used to gain access to the department’s network and electronic protected health information remained secure at all times.

In its substitute breach notice, DDS explained that its offices were vandalized and a fire was started, which triggered the sprinkler system causing damage to documents and CDs.

The nature of the vandalism and the damage caused by the fire and sprinkler system has made it impossible to determine with 100% certainty whether any information was taken from the offices or if PHI has been compromised.

If PHI was viewed or stolen it would have been limited to names, medical records, unique state-issued client identifier numbers, service codes, service dates, units billed, and amounts paid for services.

The incident has been reported to law enforcement and the burglary has been investigated but the perpetrators have not been identified.

While it is unlikely that the thieves gained access to the protected health information of patients, notifications have been sent to affected individuals out of an abundance of caution and the incident has been reported to the Department of Health and Human Services’ Office for Civil Rights.

The security breach is the largest to be reported to OCR in 2018, eclipsing the 279,865 -record breach at Oklahoma State University Center for Health Sciences that was reported in January and the 134,512-record breach at St. Peter’s Surgery & Endoscopy Center, reported in February.

The post California Dept. of Developmental Services Notifies 582,000 Patients of Potential PHI Compromise appeared first on HIPAA Journal.

Version 1.1 of the NIST Cybersecurity Framework Released

Posted by HIPAA Journal

On April 16, 2018, The National Institute of Standards and Technology released an updated version of its Framework for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework).

The Cybersecurity Framework was first issued in February 2014 and has been widely adopted by critical infrastructure owners and public and private sector organizations to guide their cybersecurity programs. While intended for use by critical infrastructure industries, the flexibility of the framework means it can also be adopted by a wide range of businesses, large and small, including healthcare organizations.

The Cybersecurity Framework incorporates guidelines, standards, and best practices and offers a flexible approach to cybersecurity. There are several ways that the Framework can be used with ample scope for customization. The Framework helps organizations address different threats and vulnerabilities and matches various levels of risk tolerance.

The Framework was intended to be a living document that can be updated and improved over time in response to feedback from users, changing best practices, new threats, and advances in technology. The new version is the first major update to the framework since 2014 and the result of two years of development.

NIST’s Matt Barrett, program manager for the Cybersecurity Framework, explained that the latest version “refines, clarifies and enhances version 1.0.” While several changes have been made in version 1.1, Barrett explained, “It is still flexible to meet an individual organization’s business or mission needs and applies to a wide range of technology environments such as information technology, industrial control systems and the Internet of Things.”

Version 1.1 of the Cybersecurity Framework includes several updates in response to comments and feedback received in 2016 and 2017 from organizations that have already adopted the Framework.

Version 1.1 sees refinements to the guidelines on authentication, authorization and identity proofing and a better explanation of the relationship between implementation tiers and profiles. The Framework for Cyber Supply Chain Risk Management has been significantly expanded and there is a new section on self-assessment of cybersecurity risk. The section on disclosure of vulnerabilities as also been expanded with a new subcategory added related to the vulnerability disclosure lifecycle.

“Cybersecurity is critical for national and economic security,” said Secretary of Commerce Wilbur Ross. “The voluntary NIST Cybersecurity Framework should be every company’s first line of defense. Adopting version 1.1 is a must do for all CEO’s.”

NIST is also planning to release a companion ‘Roadmap for Improving Critical Infrastructure Cybersecurity’ later this year and will be hosting a webinar later this month to explain and discuss the version 1.1 updates to the Framework.

The post Version 1.1 of the NIST Cybersecurity Framework Released appeared first on HIPAA Journal.

GDPR Password Requirements

Posted by GDPR News

The European General Data Protection Regulation (GDPR) will take effect from May 25, 2018 and will naturally involve GDPR password requirements. The regulation deals with how to safeguard and appropriately process the personal data of people living in the European Union (EU). An important aspect of data and account protection is the system that is being used to access the data – with a critical component of this being whether passwords are part of the access requirements and how passwords can be stored or reset.

While the word “password” itself does not appear anywhere in the text of the GDPR, Regulation (EU) 2016/679, it is stated that “a high level of protection of personal data” must be ensured and that safeguards must be in place “to prevent abuse or unlawful access or transfer”. The law also states that “personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data”.

The law frequently refers to “appropriate safeguards”, “appropriate security”, and “appropriate measures”. This gives entities a certain level of freedom in what approach they take to protect the data. It also acts to somewhat “future-proof” the legislation, by avoiding naming certain technologies or practices which may become obsolete as technology progresses.

One of the sections of the law remarks that “measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected”. This is probably the “in a nutshell” version of the GDPR’s security requirements.

Importantly for our purposes, the use of passwords is not prohibited by this approach, nor are there any specific requirements mentioned e.g. minimum lengths, capital letters, numbers, maximum periods of validity/required change frequency. With the right support systems in place, passwords can be argued to ensure security and confidentiality, while remaining feasible in terms of cost and technology. What support systems would be required for this to be the case?

As we mentioned above, how passwords are stored and reset is a critical aspect of GDPR compliance. Clients and staff members may legitimately forget or need to reset passwords for a number of reasons. GDPR requirements mean that companies must be able to demonstrate that their password reset processes and procedures are secure. Systems must be in place, for example, to prevent help desk employees that may be involved in resets from directly accessing passwords.

Perhaps the optimum way to ensure this is through the use of a secure “self-service” reset system. These systems can make use of two- or multi-factor authentication to check that the person requesting the reset is the legitimate owner of the account. A common method to implement this for online services is to transmit an automatically generated reset code to the telephone number associated with the individual account name. If used within a certain period of time, this then opens a temporary window when a password reset may occur using the account name or email address.

Other “external” factors which can be used alongside the user’s identification to securely reset a password may be voice recognition, fingerprints, or smart-cards. If the person requesting the reset can show they have two or more specific elements –  such as knowledge, a possession, or something inherent to the user and only the user – that only the account holder should have, then the password reset mechanism can be triggered.

In our example above, these specific elements would be the account name/email address and access to the user’s pre-registered telephone. While there is a risk of a third party gaining both knowledge of the account name/email address and possession of the legitimate user’s telephone, it can be considered to be low enough (for now) that this form of password reset can be reasoned to be quite secure. The temporary nature of the reset code and reset window add to the security. As extra layers or factors are added, the safety of the account is increased.

How passwords are stored is not directly addressed. The previously quoted sections relating to appropriate measures still apply. It is also mentioned that “in order to maintain security and to prevent processing in infringement of [the GDPR], the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption”.  From this, we can infer that passwords used to access data should be stored to standards that are comparable to storing them as encrypted data, at a minimum.

Should your organisation choose to use passwords as a security measure for data protected by GDPR, we advise the use of multi-factor authentication for identification and password resets, as well as encrypted storage of data and passwords.

The post GDPR Password Requirements appeared first on HIPAA Journal.

What Countries are Affected by the GDPR?

Posted by GDPR News

What Countries are Affected by the GDPR is a common GDPR question. The General Data Protection Regulation (GDPR) is a European Union (EU) Regulation that was accepted on April 27, 2016. The GDPR will come into force on May 25, 2018. While it is a piece of  EU legislation, even institutions located outside of the EU must be aware of its implications and be on their guard to avoid violating it. The physical location of the organization does not exempt or shield it from facing the consequences of non-compliance.

Institutions that have offices in an EU country or that process the personal data of anyone located within an EU country are obliged to follow the GDPR. As businesses and other organizations often have an international focus and reach, it is quite probable that your entity will be required to comply with the GDPR – especially if it is an entity that operates or offers services via the internet.

Main Countries Concerned by the GDPR

As mentioned above, the physical location of the group is not as important in determining the need to comply with the GDPR as the physical location of the data subject – the person whose data is being stored or processed. We have stated already that most groups will find themselves subject to or impacted by the GDPR. Having said that, organizations located within the EU will likely see their practices change to a greater extent. Logically, they are more likely to process a larger amount of data belonging to individuals located in the EU. Organizations in the following countries, the EU member states, will probably be most concerned by the GDPR:

  • Austria
  • Belgium
  • Bulgaria
  • Croatia
  • Republic of Cyprus
  • Czech Republic
  • Denmark
  • Estonia
  • Finland
  • France
  • Germany
  • Greece
  • Hungary
  • Ireland
  • Italy
  • Latvia
  • Lithuania
  • Luxembourg
  • Malta
  • Netherlands
  • Poland
  • Portugal
  • Romania
  • Slovakia
  • Slovenia
  • Spain
  • Sweden
  • United Kingdom

Even with the uncertainty following Brexit and the United Kingdom’s (UK) future legal status regarding EU laws, for now it remains an EU state. This means that the GDPR will become part of UK law and will remain so until such a time as it is changed by the British government. Accepted EU laws will not just stop applying to the UK once they have left the EU.

How the GDPR Will Affect Non-EU Nations

The GDPR will have a global impact even with the relatively small and localized nature of the EU itself. Despite EU countries being more likely to see the most change, non-EU countries are likely to see greater disruption following the introduction of the GDPR. This is due to the fact that organizations located within the EU are more likely to be prepared for the changes as they as more likely to be aware of the introduction of the GDPR. A large number of organizations located outside of the EU are still unaware of the coming change or are of the opinion that they are exempt or will be unaffected.

There is also a sociological difference at play: non-EU societies such as the United States (US) and others do not have the same expectation of privacy as many EU societies. Privacy laws are in place for certain types of “sensitive” data, such as the Health Insurance Portability and Accountability Act (HIPAA), which regulates healthcare information; or the Gramm-Leach-Bliley Act, which concerns financial information; but “general” data does not enjoy the same protections. This may place US entities at a disadvantage as they may need to have several procedures in place to correctly handle personal information depending on whether it originates from the EU or the US.

The need to implement, staff, and run parallel systems may introduce too much complexity and drive costs too high for US based organizations to continue offering their services to the EU market. A potential strategy may be for US based actors to adopt an “all or nothing” approach that protects “general” data in a way currently reserved for “sensitive” data. This may allow the same system to be used to comply with both HIPAA, for example, and the GDPR. As of now, it is unclear whether many US groups will attempt this strategy.

Transferring Data Outside of the EU

The GDPR places strict controls on data transferred to non-EU countries or international organizations. These are detailed in Chapter V of the Regulation. Data is allowed to be transferred only when the EU Commission has deemed that the transfer destination “ensures an adequate level of protection”.

Data transfers can also occur in situations where the receiving entity can demonstrate that they meet this “adequate level of protection”, subject to periodic review every four years. The necessary protections may include:

– Commission approved data protection clauses

– Legally binding agreements between public authorities

– Commission approved certification

– Binding corporate rules that are enforced across different entities within the same corporate group

The transfer of data is strictly regulated so as to offer each individual in the EU the same protections and rights under EU law regardless of the location of data storage or processing.

What Does GDPR Mean for Me?

Above, we have seen a brief description of the data concerned by the GDPR – personal data of an individual located within the EU. We have also touched upon who is affected and how groups in some non-EU countries may approach GDPR compliance in an efficient manner. Now, we will outline why compliance is important: the maximum fine for violating the GDPR can be as high as €20 million, or 4% of annual turnover, whichever is higher. Compliance is, therefore, a very important issue.

While some groups will need to adapt their methods of processing data to be GDPR compliant, a common EU legislation will make it easier to deal with data originating from different EU countries.

With the introduction of the GDPR fast upon us, groups must use the time they have left to ensure they will be compliant on May 25. They will need to audit their data and verify that the methods of collecting, processing, and storage – as well as the nature of the data itself – are GDPR compliant.

If the necessary systems are not in place by May 25, organizations run the risk of non-compliance, sanctions, and losing business from their European partners.

The post What Countries are Affected by the GDPR? appeared first on HIPAA Journal.