Healthcare and Technology news
51.5K views | +1 today
Follow
Healthcare and Technology news
Your new post is loading...
Your new post is loading...
Scoop.it!

The HIPAA Security Rule and Vulnerability Scans

The HIPAA Security Rule and Vulnerability Scans | Healthcare and Technology news | Scoop.it

Under the HIPAA Security Rule, covered entities must implement safeguards to protect the confidentiality, integrity, and availability of electronically protected health information (ePHI).

 

ePHI is any protected health information that is created, stored, transmitted, or received in any electronic format. 

 

To this end, the HIPAA Security Rule requires covered entities to perform a security risk analysis (also known as security risk assessment), which the Security Rule defines as an “accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.” Scans known as vulnerability scans may be performed to identify known vulnerabilities in applications, networks, and firewalls. 

What are Vulnerability Scans?

Vulnerabilities are weaknesses which, if triggered or exploited by a threat, create a risk of improper access to or disclosure of ePHI.

 

 Vulnerability scans are scans designed to identify vulnerabilities, or weaknesses, that have the potential to cause a security incident. 


Under the HIPAA Security Rule, a security incident is defined as:

  • The attempted or successful unauthorized access, use, disclosure, modification, or destruction of information in an information system; or
  • The attempted or successful unauthorized access, use, disclosure, modification or interference with system operations in an information system. 

In plain English, a HIPAA security incident is an attempt (which can be successful or not) to do something unauthorized.

 

The “something” that is unauthorized, is an unauthorized access, use, disclosure, modification, destruction, or interference.

 

A HIPAA security incident may occur when:

  1. The unauthorized attempt to access, use, disclose, modify, destroy, or interfere, targets an organization’s information system.
  2. The unauthorized attempt is made to access, use, disclose, modify, or interfere with that information system’s system operations.

What are Examples of HIPAA Security Incidents?

Examples of a HIPAA security incident include:

  • Theft of passwords that are used to access electronic protected health information (ePHI).
  • Viruses, malware, or hacking attacks that interfere with the operations of information systems with ePHI.
  • Failure to terminate the account of a former employee that is then used by an unauthorized user to access information systems with ePHI.
  • Providing media with ePHI, such as a PC hard drive or laptop, to another user who is not authorized to access the ePHI prior to removing the ePHI stored on the media.

How Do Vulnerability Scans Identify Weaknesses?

HIPAA vulnerability scans to test for holes and flaws in information systems, and for incorrect system implementation and configuration.

Common flaws that can be revealed through a vulnerability scan include:

  • Flaws in software. Such flaws can be found in computer operating systems, such as Microsoft 7. Such flaws can also be found in software programs, such as Microsoft Office, Google Chrome, or Internet Explorer. 
  • Flaws in hardware. Vulnerability scans can reveal vulnerabilities that exist on hardware devices. Hardware devices include network firewalls, printers, or routers.  

If a vulnerability scan identifies a vulnerability, the vulnerability may be remediated if the software or network vendor at issue has released a security patch. Installation of the patch may eliminate the security weakness.  

 
 
Technical Dr. Inc.s insight:
Contact Details :

inquiry@technicaldr.com or 877-910-0004
www.technicaldr.com

No comment yet.
Scoop.it!

Information Security Risk Management

Information Security Risk Management | Healthcare and Technology news | Scoop.it

Information security risk management is a wide topic, with many notions, processes, and technologies that are often confused with each other.

 

Very often technical solutions (cybersecurity products) are presented as “risk management” solutions without process-related context.

 

Modern cybersecurity risk management is not possible without technical solutions, but these solutions alone, when not put in the context of correct risk management processes (and in the context of information-related processes) of an organization might not be enough to properly manage risks of information processing or might even cause a false sense of security.

 

In this new series of articles, I will explain some basic notions related to risk management, introduce and describe the phases of cyclic high-level process risk management, give more details on each of the phases and introduce the NIST and ISO standards related to risk management.

 

In this article, I will review the definition of risk, goals of risk management and list the main NIST and ISO standards related to information security risk management.

Cybersecurity risk management vs information security risk management

First of all, let’s discuss shortly the difference between “cybersecurity risk management” and “information security risk management”. Before “cybersecurity” became a buzzword, professionals dealing with information security used only “information security” and “IT security” notions.

 

Obviously “information security” is a wider term. It concerns the security of information, stored, processed or transmitted in any form (including paper). Information security also concerns people, processes, legal/regulatory matters and insurance. (Yes, insurance is also a way to reduce risk – by transferring it – and is thus a security measure.)

 

“IT security” is a term concerning “IT”, that is Information Technology. So it concerns information processed in IT systems. Sometimes these notions (“information security” and “IT security”) were used (and still are used!) interchangeably, but formally this is wrong because IT system is a part of information processing system.

 

“Cybersecurity” is a nice buzzword of recent years. Almost everything is “cyber” these days. Unfortunately this word has different meanings, depending on who uses it. The “cyber” part of this word suggests it concerns technology, so in my private opinion this word, “cybersecurity” is a younger brother of “IT security” (or, to be more precise, a younger clone  ). What is wrong with this word in my opinion is that it is often used to describe (or in) high-level documents like policies or process descriptions that have nothing to do with lower-level technology. But this is the trend we cannot change – the “cybersecurity everything” approach has been present in information/IT security world for some time already and it is doing very well. So we have to adapt and adjust.

 

But at the same time we have to be very careful when using the word “cybersecurity” (do we really mean what we are saying?) and also when reading it (what does this word really mean in the context of other information it is “served” with?).

The goal of information security risk management

The main goal of information security risk management is to continuously address the risks to information processed by an organization. These risks are to be addressed according to the organization’s risk management policy.

 

The information security risk management is a part of general risk management of an organization, so it should be aligned with general, high-level risk management policy.

 

The realization of the above-mentioned goal of information security is dependent on the following elements:

  • the information security risk management methodology;
  • the information security risk management policy and procedures;
  • the information security risk management process;
  • the information security risk management stakeholders.

I will be addressing all these in next articles in this series.

NIST and ISO standards

There are important (and practically applicable) NIST guidelines and ISO standards available on information security risk management.

The main high-level ISO standard on risk management is ISO 31000 (namely ISO 31000:2009: “Risk management — Principles and guidelines”; it is currently under review).

(It belongs to the same line of ISO standards as ISO 27000 line of standards, which I touched in my previous series of articles in Komunity.)

 

ISO 3100 introduces the risk management cycle that is applicable to (and should be used for) information security management, independent of risk analysis methodology used. I will use this cycle to introduce information security risk management process.

But before that, let me mention also other standards and guidelines on information security risk management:

  • ISO/IEC 27005: “Information technology — Security techniques — Information security risk management”;
  • NIST Special Publication 800-39: “Managing Information Security Risk: Organization, Missions and Information System View”;
  • NIST Special Publication 800-30 Rev 1: “Guide for Conducting Risk Assessments”.

I will come back to these standards after I describe the risk management cycle and its elements.

Risk definition

Let’s touch on another subject that is important and sometimes misunderstood – the notion of risk itself.

 

In common language, we often mix up all notions related to risk management: the risk itself, vulnerability, threat etc. We can’t do that if we want to run the risk management properly. It is not only the matter of notion mix-up. These notions are used in any risk analysis methodology and shouldn’t be mixed up, otherwise one will not be able to perform risk analysis correctly or understand and implement its results into the risk management process cycle.

 

ISO 31000 defines risk as “effect of uncertainty on objectives” (please remember that this standard is a high-level standard). This effect can be positive or negative, which means that in terms of this standard (and other risk-related standards, as you will see) risk is neutral. This, as can easily be seen, is not consistent with the common language, in which risk is almost always a negative notion.

 

I’ll come back to this definition and to the definitions o terms that are related to risk notion: vulnerability, threat etc.

Technical Dr. Inc.s insight:
Contact Details :

inquiry@technicaldr.com or 877-910-0004
www.technicaldr.com

No comment yet.
Scoop.it!

Are you doing your security framework right?

Are you doing your security framework right? | Healthcare and Technology news | Scoop.it
It turns out many healthcare organizations get more than a few things wrong about their information security frameworks – big time. Whether it's about properly integrating a framework or even appropriately tailoring a framework, there's a list of items organizations should pay attention to. 
 
If done right, information security frameworks can be used to meet an organization's risk analysis requirements under the HIPAA Security Rule, in addition to helping define a "baseline of protection," said Bryan Cline, senior advisor at HITRUSTAlliance, but that's only if they're properly selected and implemented. And many organizations don’t necessarily do this successfully. 
 
Cline, who will be speaking at the Healthcare IT News Privacy and Security Forumthis March in a session on data security framework need-to-knows, says the biggest oversight he sees organizations make "is in not tailoring the framework appropriately." Added Cline, "organizations either rely on the framework without tailoring the requirements to address all reasonably anticipated threats, or they tailor the framework's requirements – usually by removing some of them – without fully understanding the additional risk that's incurred."
 
Sure, a security framework will help in the compliance arena, but improper tailoring and failure to keep it updated will inevitably lead to information-related risks being inadequately addressed, he said. This up-to-date piece is crucial, Cline said, because "frameworks also grow stale over time, as it can take several years for most frameworks to be updated and released."
 
Another big oversight, as Cline pointed out? Failing to integrate the framework into everyday operational processes. "For example," he said, "personnel with security responsibilities – whether in the security organization or elsewhere (e.g., HR or IT) – should be tied to the framework's controls and the security services that support their implementation." This, he added, would allow organizations to manage risk through managing the security services.
 
Cline, who is also the managing partner for Cline & Shiozawa Professional Services and previously the chief information security officer at Catholic Health East and The Children’s Hospital of Philadelphia, at his forum session will go over security risk management frameworks and how they can be leveraged and used in an organization's data protection programs. This includes, as Cline pointed out, how they can use these frameworks to meet risk analysis requirements under the HIPAA Security Rule. 


No comment yet.
Scoop.it!

What to Include in Your Incident Response Plan

What to Include in Your Incident Response Plan | Healthcare and Technology news | Scoop.it

Cybersecurity data breaches have almost become a way of life. We hear about businesses impacted by security incidents and data breaches every day. 

 

As the adage goes, it’s not “IF”, but rather “WHEN” a security incident will take place at your business. 

 

It is therefore a best practice for every business to create an incident response plan. An incident response plan delivers two cybersecurity benefits to your business:

 

  1. Systematic response to incidents which helps to minimize information loss or theft and service disruption.
  2. Use of the information gained from an incident to help prevent future threats by strengthening system protections and to be better prepared for handling future incidents.

 

A breach of your information is always stressful. Don’t compound that stress by not having a plan to address a successful cyberattack. 

 

Before creating an incident response plan, you must create an incident response policy.

 

Create an Incident Response Policy

The National Institute of Standards and Technology (NIST) recommends in its Computer Security Incident Handling Guide that an organization should create a policy before building an incident response program.

This policy:

  • Defines which events will be considered incidents
  • Establishes the structure for incident response
  • Defines roles and responsibilities
  • Lists the requirements for reporting incidents

Develop your policy to include all applicable regulations and laws under which your business operates. Compliance requirements such as those associated with HIPAA and HITECH, Gramm-Leach-Bliley Act, and Sarbanes-Oxley (SOX) will drive your policy requirements. 

The 4 Phases of the NIST Incident Response Lifecycle

Once the policy has been created, NIST outlines four broad phases an incident response plan should include.

NIST identifies four phases in an incident response lifecycle:

  1. Preparation
  2. Detection and Analysis
  3. Containment, Eradication, and Recovery
  4. Post-Event Activity

 

Each of the four phases includes a number of actions. Here’s an outline of what you can include in your organization’s incident response plan.

Preparation and Prevention

“Prevention” in the context of incident response is essentially your information security strategy and the software tools used to implement your strategy. It is your layered defense against cybercriminals -- firewalls, encryption, antivirus software, data backup, user training, etc. 

 

Part of being prepared is having a complete list of your information security tools (including any portions of your IT infrastructure managed by a third-party managed service provider). 

 

Effective response is based on communication. Smartphones are an excellent way to communicate with and coordinate team members while responding to an incident.

 

It may be a good idea to have some of the information below as hard copy or on devices not connected to an organization’s network (it will be difficult to coordinate a response if, for example, you are victimized by a ransomware attack and cannot access your plan):

  • Contact information for primary and backup contacts within your organization plus relevant law enforcement and regulatory agencies that may need to be alerted
  • An incident reporting mechanism so users can report suspected incidents (phone numbers, email, online forms, or secure messaging systems)
  • Issue tracking system
  • Space to respond. Identify a permanent “war room” or temporary location where team members can centralize their response to the incident
  • Secure storage facility to keep evidence if needed

Detection and Analysis

Attacks can come from anywhere and take many forms - a denial of service attack, ransomware, email phishing, lost or stolen equipment (such as a laptop, smartphone, or authentication token), etc.

 

Once an incident is positively identified, follow defined processes to document the response (which can be helpful in showing a good faith effort to limit the impact of the breach on customer data should you end up in litigation or are investigated as the result of a breach).

 

Identify your affected networks, systems, and/or applications and determine the scope of the incident. From there, the response team can prioritize next steps from containment to further analysis of the incident. Recommendations for making analysis more effective include:

 

  • Profile networks and systems so changes are more readily detectable
  • Understand normal behavior so abnormal behavior is more easily spotted
  • Create a log retention policy
  • Perform event correlation
  • Keep all host clocks synchronized
  • Filter data to investigate the most suspicious data first
  • Run packet sniffers to collect additional data

 

These techniques should be used in conjunction with one another. Relying on a single method will be ineffective.

 

Document incidents as they are found. A logbook is one way to do so as are laptops, audio recordings, or a digital camera. 

 

Those affected by the incident need to be notified as well. For an incident that affects customers, a message on your website, email notification, or other communication will be needed. 

 

Often, breach notification procedures are driven by laws applicable to your industry, your state or your country, or a combination of these.

Containment, Eradication, and Recovery

Develop containment strategies for different incident types as containment for malware entering your network from an email will be different than for a network-based denial-of-service attack.

 

Document your strategies for incident containment so you can decide the appropriate strategy for the incident (e.g., shut down a system, disconnect it from the network, disable certain functions).

Once an incident is contained and all affected elements of the IT infrastructure have been identified the eradication and recovery process begins.

 

For larger systems, this could take months to move from high-priority to lower priority systems. Systems may be able to be restored from backup or may need to be rebuilt from scratch. As eradication and recovery proceed, steps can also be taken to tighten security measures. 

Post-Event Activity

Information security is an ongoing, iterative process. A key part of any incident response should be to learn from it:

  • Were the procedures followed? Were they effective?
  • Did we do anything that slowed the recovery process?
  • What could we have done differently?
  • Are there steps we can take to prevent a similar attack?
  • Were there indicators of the attack that we can use to prevent/detect a similar incident?
  • Do we need more resources to detect, analyze, and mitigate future events?

Apply what you learn to improve your cybersecurity defenses and response to the next incident.

Testing, Testing

Test your plan once per year. EIther working with an independent third-party or internally, create a scenario and walk your team through it.

 

This not only allows team members to understand their roles, but will also help you identify gaps or weaknesses in your plan. 

Technical Dr. Inc.s insight:
Contact Details :

inquiry@technicaldr.com or 877-910-0004
www.technicaldr.com

No comment yet.
Scoop.it!

Cybersecurity in the Spotlight 

Cybersecurity in the Spotlight  | Healthcare and Technology news | Scoop.it

Once again, cybersecurity issues will be in the spotlight at the Healthcare Information and Management Systems Society Conference, to be held Feb. 11-15 in Orlando, Florida.

 

This year's event at the Orange County Convention Center promises 1,300-plus exhibitors, including more than 70 vendors in the show's dedicated Cybersecurity Command Center.

 

The conference is expected to draw more than 45,000 attendees and offer more than 300 educational sessions spanning 24 topics - including cybersecurity and privacy as well as related regulatory updates.

Cybersecurity sessions will be weaved in throughout the week, with many taking place at the Cybersecurity Command Center. But the topic will also get special treatment on Monday, Feb. 11. A Cybersecurity Forum that day geared to CISOs and other health IT security leaders is among a handful of pre-show workshops before HIMSS19 officially opens on Tuesday.

Cybersecurity Forum

The Cybersecurity Forum has several key learning objectives for its attendees, HIMSS says, including:

  • Explain the types and details of recent cyberthreats;
  • Discuss what's new, what's different, what to look out for, and the impact on administrative, clinical operations and patient safety;
  • Describe how organizations can work better and smarter to enhance their cybersecurity program, despite resource and financial constraints.

Featured speakers at the forum include Ron Mehring, CISO at Texas Health Resources; Kevin McDonald, director of clinical information security at Mayo Clinic; Jason Hawley, director of information services and security at Yuma District Hospital & Clinics; Mitch Parker, executive director, information security and compliance at Indiana University Health; and James Brady, CIO of the Los Angeles County Department of Health Services.

Regulatory Updates

As usual, the HIMSS conference will provide opportunities to hear from government officialsabout the latest policy plans and other developments. Agencies to be featured include:

  • The National Institute of Standards and Technology, offering a session on Monday, Feb. 11, about its cybersecurity framework;
  • The Food and Drug Administration, which will describe its digital health software precertification program on Tuesday, Feb. 12;
  • The Office of the National Coordinator for Health IT, which will be featured in a number of sessions, including a standards and technology update slated for Thursday, Feb. 14.

I predict one of the best attended government sessions will be the HIPAA enforcement and compliance update on Tuesday, Feb. 12, featuring Roger Severino, director of the Office for Civil Rights at the Department of Health and Human Services.

Technology Spotlight

Among the emerging technologies to be spotlighted at the show is blockchain, which will be showcased at a four-hour forum on Wednesday, Feb 13, including a session about blockchain's privacy, security and compliance considerations in healthcare.

Machine learning and artificial intelligence are buzzwords that are guaranteed to be used by many of the exhibitors showcasing their health IT gear. But ML and AI will also be discussed at a variety of educational sessions, including a special all-day pre-show forum.

 

Many of the sessions at that forum appear to be heavily focused on the application of ML and AI for clinical applications. But the use of AI and ML for securing health data will also be showcased in a separate session, "AI in Healthcare: Ethical and Legal Considerations", at the Cybersecurity Command Center .

 

As usual, I'll be at the conference attending sessions as well as meeting with numerous healthcare CISOs, government leaders and other privacy and security experts. I'll share their insights in audio interviews, articles and blogs, so be on the lookout for daily updates on our HIMSS19 news site.

Technical Dr. Inc.s insight:
Contact Details :

inquiry@technicaldr.com or 877-910-0004
www.technicaldr.com

No comment yet.