Term
|
Definition
|
Adequate Security
|
Security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of ePHI .
|
Adversary
|
Individual, group, organization, or government that conducts or has the intent to conduct detrimental activities.
|
Asset
|
An Asset is a thing (tangible or intangible) that accesses, stores, maintains, or transmits ePHI. Examples include networks, PCs, servers, mobile devices, Information Systems, building, etc.
|
Attack
|
Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy Information System resources or the ePHI itself.
|
Authentication
|
Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an Information System.
|
Availability
|
Ensuring timely and reliable access to and use of ePHI.
|
Confidentiality
|
Preserving authorized restrictions on ePHI access and disclosure, including means for protecting personal privacy and proprietary ePHI.
|
Impact
|
The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of ePHI, unauthorized modification of ePHI, unauthorized destruction of ePHI, or loss of ePHI or ePHI system availability.
|
Individual
|
Individual is synonymous with a workforce member.
|
Information Owner
|
Official with statutory or operational authority for specified ePHI and responsibility for establishing the controls for its generation, classification, collection, processing, dissemination, and disposal.
|
Integrity
|
Guarding against improper ePHI modification or destruction, and includes ensuring ePHI non-repudiation and authenticity.
|
Likelihood
|
A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given Vulnerability or a set of Vulnerabilities.
|
Operations
|
Business processes and workflows that interact with ePHI on a day-to-day basis and which would be negatively impacted should ePHI be corrupted, breached, or otherwise compromised.
|
Operational Controls
|
The security controls (i.e., safeguards or countermeasures) for an Information System that are primarily implemented and executed by people (as opposed to systems).
|
Operational Environment
|
The physical, technical, and organizational setting in which an Information System operates, including but not limited to: missions/business functions; mission/business processes; threat space; vulnerabilities; enterprise and information security architectures; personnel; facilities; supply chain relationships; information technologies; organizational governance and culture; acquisition and procurement processes; organizational policies and procedures; organizational assumptions, constraints, risk tolerance, and priorities/trade-offs.
|
Risk
|
The net mission impact considering (1) the probability that a particular Threat will exercise (accidentally trigger or intentionally exploit) a particular Vulnerability and (2) the resulting impact if this should occur.
Risks arise from legal liability or mission loss due to:
(1) Unauthorized (malicious or accidental) disclosure, modification, or destruction of ePHI;
(2) Unintentional errors and omissions;
(3) IT disruptions due to natural or man-made disasters;
(4) Failure to exercise due care and diligence in the implementation and operation of the IT system.
A Risk is not a single factor or event, but rather it is a combination of factors or events (Threats and Vulnerabilities) that, if actualized, may have an adverse impact on the Organization.
|
Risk Analysis/Assessment
|
Risk Analysis is a process by which an Organization identifies the following:
(1) Threats to the Organizations (i.e., Operations, Assets, or Individuals);
(2) Vulnerabilities internal and external to the Organization;
(3) The harm (i.e., adverse Impact) that may occur given the potential for Threats exploiting Vulnerabilities; and
(4) The likelihood that harm will occur.
The end result of a Risk Analysis is an overall determination of Risk for the Organization (i.e., typically a function of the degree of harm and likelihood of harm occurring).
In order to be useful for an SR implementation, Risks must be aligned with more granular subcategories using Operations, Assets, or Individuals as high level categories that are subsequently further subdivided.
|
Risk Assessment Methodology
|
A risk assessment process, together with a risk model, assessment approach, and analysis approach.
|
Risk Management
|
Risk Management is a comprehensive global Organizational process that contains the following sub-processes:
(1) framing risk-the purpose of the Risk framing component is to produce a Risk Management strategy that addresses how your Organization intends to assess Risk, respond to Risk, and monitor Risk;
(2) assessing risk-See the definition of Risk Analysis;
(3) responding to Risk-this component determines how your Organization responds to risk in accordance with your Risk management strategy by developing, evaluating, selecting, and implementing Risk responses; and
(4) monitoring risk-this component determines how your Organization tracks risks over time by verifying that "reasonable and appropriate" risk responses have been implemented and determining ongoing effectiveness of these responses vis-à-vis a changing operational environment.
The NIST definition of Risk Management incorporates the "analysis/assessment" process whereas the SR has separated Risk Analysis from Risk Management as two separate Implementation Specifications for the first Standard of the Administrative Safeguards.
It should be noted that as part of Risk Management, further Risk Assessments can and will be required over time (e.g. when your Organization's operational environment changes). Also the NIST Special Publications are not HITECH / HIPAA specific; their scope is much broader and therefore don't always align with the SR.
|
Risk Mitigation
|
Prioritizing, evaluating, and implementing the appropriate risk-reducing controls / countermeasures recommended from the Risk Analysis process. A subset of Risk Response.
|
Risk Monitoring
|
Maintaining ongoing awareness of an Organization's Risk environment, Risk Management program, and associated activities to support Risk decisions.
|
Risk Response
|
Accepting, avoiding, mitigating, sharing, or transferring Risk to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, or other organizations.
|
Security Controls
|
The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an Information System to protect the confidentiality, integrity, and availability of the system and its ePHI.
|
Technical Controls
|
Security Controls (i.e., safeguards or countermeasures) for an Information System that are primarily implemented and executed by the Information System through mechanisms contained in the hardware, software, or firmware components of the system.
|
Threat
|
The potential for a person or thing to exercise (accidentally trigger or intentionally exploit) a specific Vulnerability.
There are several types of Threats that may occur within an Information System or operating environment. Threats may be grouped into general categories such as natural, human, and environmental.
Examples of common threats in each of these general categories:
(1) natural threats may include floods, earthquakes, tornadoes, and landslides;
(2) human threats are enabled or caused by humans and may include intentional (e.g., network and computer based attacks, malicious software upload, and unauthorized access to ePHI) or unintentional (e.g., inadvertent data entry deletion and inaccurate data entry) actions; and
(3) environmental threats may include power failures, pollution, chemicals, and liquid leakage.
|
Vulnerability
|
A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security Breach or a violation of the system's security policy.
Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a Security Incident, such as an inappropriate use ordisclosure of ePHI.
Vulnerabilities may be grouped into two general categories, technical and nontechnical. Non-technical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines. Technical Vulnerabilities may include: holes, flaws or weaknesses in the development of Information Systems; or incorrectly implemented and/or configured Information Systems.
|