FAQ

No. HHS does not endorse or otherwise recognize private organizations’ certifications regarding the Security Rule. It is important to understand that such certifications do not absolve covered entities of their legal obligations under the Security Rule. The evaluation standard § 164.308(a)(8) requires a periodic technical and non-technical assessment is conducted to establish the extent to which an entity’s policies and procedures meet the security requirements. This assessment can be performed internally by the covered entity or by an external organization.

Compliance is different for each organization and no single strategy will serve all covered entities. Understanding your organization’s state of compliance generally requires:

• a thorough, up to date risk analysis;
• a review of current policies and security measures in place;
• up to date documentation and training to support policies and procedures;
• and other appropriate documentation as needed.

Compliance is not a one-time goal but, rather, an ongoing process. Meeting the requirements set out in the evaluation standard at § 164.308(a)(8), performing periodic technical and non-technical assessments, is the first step to maintaining substantial compliance and ensuring the security of ePHI.

As part of the Security Management Process within the Administrative Safeguards of the Security Rule, organizations should conduct periodic risk assessments. The assessment can be conducted internally or by engaging a third party. This assessment process may include interviews, vulnerability testing, process walkthroughs, and/or a review of documented processes. Larger organizations should consider a more formalized review while smaller organizations may consider less formal means of evaluation. If this process is to be conducted internally, the individuals who conduct these evaluations should not be the same as those responsible for carrying out the process and they should be reasonably qualified to make the necessary evaluations.

No. The standards of the Security Rule are specific to electronic protected health information (ePHI) including telephone voice response and fax back systems (because they can be used as input and output devices for electronic information systems.) ePHI does not include paper-to-paper faxes, video teleconferencing or messages left on voice mail (because the information being exchanged did not exist in electronic form before the transmission). However, the requirements of the HIPAA Privacy Rule apply to all forms of PHI, including written and oral.

No. The Security standards are “technology neutral.” Any mandate regarding technology to be used would only bind organizations to specific systems and/or software that may be superseded by rapidly developing technologies and improvements. Allowing healthcare organizations to determine the best tools to suit their needs encourages them to use the latest and most innovative technologies to best meet their individual needs along with those of their business associates and subcontractors.

As you would expect, required implementation specifications must be implemented. The additional category of addressable implementation specifications was developed to provide organizations a degree of flexibility in compliance with the security standards. In meeting standards that contain addressable implementation specifications, the organization may implement the addressable implementation specifications or alternative security measures to accomplish the same purpose – but no action is necessarily required. The organization’s decision must be appropriately documented. The organization must determine whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, an entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate and if a reasonable and appropriate alternative exists. This decision will depend on a variety of factors unique to the organization. Considerations may include the entity’s risk analysis, risk mitigation strategy, what security measures are already in place and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.

No, the Security Rule is not suspended during a national or public health emergency. If the President declares an emergency or disaster and the Secretary of HHS declares a public health emergency, the Secretary may waive sanctions and penalties arising from certain provisions of the Privacy Rule under the Project BioShield Act of 2004 (PL 108-276) and section 1135(b)(7) of the Social Security Act. These provisions, however, have no application to the Security Rule. The Security Rule includes requirements for business entities to ensure the confidentiality, integrity, and availability of all electronic protected health information they create, receive, maintain or transmit. The rule further requires that entities protect against any reasonably anticipated threats or hazards to the security or integrity of such information. Other provisions of the Security Rule require organizations to implement security measures that specifically contemplate emergency conditions.

The HIPAA Privacy and Security Rules are enforced by the Office for Civil Rights (OCR) within the Department of Health and Human Services. OCR may conduct complaint investigations and compliance reviews. The Office of E-Health Standards and Services within the Centers for Medicare & Medicaid Services (CMS) enforces the Transactions and Code Sets and National Identifiers (Employer and Provider identifiers) regulations of HIPAA. CMS also enforces the insurance portability requirements under Title I of HIPAA.

No. The final Security Rule made the use of encryption an addressable implementation specification. This means that it must be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity, and availability of ePHI. If the entity decides that this addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, an organization may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision.

Physical safeguards are physical measures, policies, and procedures instituted to protect an entity’s electronic information systems and related buildings and equipment from unauthorized intrusion as well as natural or environmental hazards. The standards under physical safeguards include facility access controls, workstation use, workstation security, and device and media controls. The Security Rule requires entities to implement physical safeguard standards for their electronic information systems whether such systems are housed on the organization’s premises or at another location.

Risk analysis is the assessment of the risks and vulnerabilities that could negatively impact the confidentiality, integrity, and availability of the ePHI held by a covered entity or its business associates and the likelihood of occurrence. The risk analysis may include taking inventory of all systems and applications that are used to access and house data and classifying them by level of risk. A thorough and accurate risk analysis would consider all relevant losses that would be expected if the security measures were not in place, including loss or damage of data, corrupted data systems, and anticipated ramifications of such losses or damage. Risk management is the actual implementation of security measures to sufficiently reduce an organization’s risk of losing or compromising its ePHI and to meet the general security standards.

The risk analysis process will identify potential threats and vulnerabilities that may affect systems containing ePHI. The risks an entity decides to address, and how the entity decides to address the risks, will depend on the probability and likely impact of threats affecting the confidentiality, integrity, and/or availability of ePHI. Threats may affect information (data) and systems. The National Institute of Standards and Technology (NIST) provides information security guidance materials. NIST Special Publication (SP) 800-30, Risk Management Guide for Information Technology Systems categorizes threats into three common categories: Human, Natural, and Environmental.

45 CFR § 164.304 defines security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. The Security Incident Procedures standard at § 164.308(a)(6)(i) requires an entity to implement policies and procedures to address security incidents. The associated implementation specification for response and reporting at § 164.308(a)(6)(ii) requires organizations to identify and respond to suspected or known security incidents, mitigate (to the extent practicable) harmful effects of security incidents that are known to the covered entity, and document security incidents and their outcomes. In order to maintain a flexible, scalable and technology neutral approach to the Security Rule, no single method is identified for addressing security incidents that will apply to all entities. As stated in the preamble to the Security Rule, 68 Fed. Reg. 8350, an entity should be able to rely upon the information gathered in complying with the other security standards (for example, its risk assessment and risk management procedures and the Privacy Rule standards) to determine what constitutes a security incident in the context of its business operations. In addressing the Security Incident Procedures standard, organizations may consider some of the following questions:

What specific actions would be considered security incidents?
How will incidents be documented and reported?
What information should be contained in the documentation?
How often and to whom should incidents be reported?
What are the appropriate responses to certain incidents?
When considering the requirements of § 164.306(a) and (b) and its risk analysis, the entity may decide that certain types of attempted or successful security incidents or patterns of attempted or successful incidents warrant different actions.

The Security Rule standards allow any covered entity (including small providers) to use any security measures that help the covered entity to reasonably and appropriately implement the standards to protect electronic health information. In deciding what security measures to use, a covered entity can take into account its size, capabilities, and costs of security measures. A small provider who is a covered entity would first assess their security risks and vulnerabilities and the mechanisms currently in place to mitigate those risks and vulnerabilities. Following this assessment, they should determine what additional measures, if any, need to be taken to meet the standards; taking into account their capabilities and the cost of those measures.

Yes. Entities that allow employees to telecommute or work out of home-based offices with access to ePHI must implement appropriate safeguards to protect the organization’s data. The automatic logoff implementation specification in the Security Rule is addressable, and must, therefore, be implemented if, after an assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its environment. If the entity decides that the logoff implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision. The information access management and access control standards, however, require organizations to implement policies and procedures for authorizing access to ePHI and technical policies and procedures to allow access only to those persons or software programs that have been appropriately granted access rights.

The Security Rule does not expressly prohibit the use of email for sending ePHI. However, the standards for access control (45 CFR § 164.312(a)), integrity (45 CFR § 164.312(c)(1)), and transmission security (45 CFR § 164.312(e)(1)) require entities to implement policies and procedures to restrict access to, protect the integrity of, and guard against unauthorized access to ePHI. The standard for transmission security (§ 164.312(e)) also includes addressable specifications for integrity controls and encryption. This means that the entity must assess its use of open networks, identify the available and appropriate means to protect ePHI as it is transmitted, select a solution, and document the decision. The Security Rule allows for ePHI to be sent over an electronic open network as long as it is adequately protected.

No, the Security Rule does not require the use of electronic or digital signatures. However, electronic or digital signatures could be used as a security measure if the entity determines their use is reasonable and appropriate.

No. The Security Rule was written to allow flexibility for entities to implement security measures that best fit their organizational needs. The Security Rule does not specify minimum requirements for personal computer operating systems but it does mandate requirements for information systems that contain ePHI. Therefore, as part of the information system, the security capabilities of the operating system may be used to comply with technical safeguards standards and implementation specifications such as audit controls, unique user identification, integrity, person or entity authentication, or transmission security. Additionally, any known security vulnerabilities of an operating system should be considered in the organization’s risk analysis (e.g., does an operating system include known vulnerabilities for which a security patch is unavailable, e.g., because the operating system is no longer supported by its manufacturer).

No. Covered entities may use any of the NIST documents to the extent that they provide relevant guidance to that organization’s implementation activities. While NIST documents were referenced in the preamble to the Security Rule, their use is not required by the Security Rule.

No. Under the Security Rule, entities, regardless of their size, are required under § 164.312(a)(2)(i) to “assign a unique name and/or number for identifying and tracking user identity.” A “user” is defined in § 164.304 as a “person or entity with authorized access.” Accordingly, the Security Rule requires entities to assign a unique name and/or number to each employee or workforce member who uses a system that maintains ePHI, so that system access and activity can be identified and tracked by each individual user.

There is nothing in the Security Rule that prohibits the networking of computers whether inside the same company or between two unrelated companies who conduct business together. However, the entity must demonstrate that it has evaluated the risks associated with a network connection and document that it has established all of the safeguards (technical, physical and administrative) that would serve to reasonably protect the information that is exchanged over the network. The necessary documentation will include an assessment of everything from the firewall to the designation and training of the individuals who have access to the data.

Administrative Safeguards include incorporating the following into your compliance initiatives:

Security Management Process: As explained previously, organizations must identify and analyze potential risks to ePHI and implement security measures that reduce risks and vulnerabilities to a reasonable and appropriate level.
Security Personnel: An entity must designate a security official who is responsible for developing and implementing security policies and procedures.
Information Access Management: Consistent with the Privacy Rule standard limiting uses and disclosures of PHI to the “minimum necessary,” the Security Rule requires organizations to implement policies and procedures for authorizing access to ePHI only when such access is appropriate based on the user or recipient’s role (role-based access).
Workforce Training and Management: An entity must provide for appropriate authorization and supervision of workforce members who work with ePHI. Organizations must train all workforce members regarding their security policies and procedures and must have and apply appropriate sanctions against workforce members who violate those policies and procedures.
Evaluation: An entity must perform a periodic assessment of how well its security policies and procedures meet the requirements of the Security Rule.

Physical Safeguards include incorporating the following into your compliance initiatives:

Facility Access and Control: An entity must limit physical access to its facilities while ensuring that authorized access is allowed.
Workstation and Device Security: Organizations must implement policies and procedures to specify proper use of and access to workstations and electronic media. An entity also must have in place policies and procedures regarding the transfer, removal, disposal, and re-use of electronic media, to ensure appropriate protection of ePHI.

Technical Safeguards include incorporating the following into your compliance initiatives:

Access Control: An entity must implement technical policies and procedures that allow only authorized persons to access ePHI.
Audit Controls: An entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use ePHI.
Integrity Controls: An entity must implement policies and procedures to ensure that ePHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that ePHI has not been improperly altered or destroyed.
Transmission Security: An entity must implement technical security measures that guard against unauthorized access to ePHI that is being transmitted over an electronic network.

Organizations must adopt reasonable and appropriate policies and procedures to comply with the provisions of the Security Rule. An entity must maintain (for six years after the date of their creation or last effective date – the later of the two) written security policies and procedures and written records of required actions, activities or assessments. An entity must periodically review and update its documentation in response to environmental or organizational changes that affect the security of ePHI.

In general, State laws that are contrary to the HIPAA regulations are preempted by the federal requirements, which means that the federal requirements will apply. “Contrary” means that it would be impossible for a covered entity to comply with both the State and federal requirements, or that the provision of State law is an obstacle to accomplishing the full purposes and objectives of the Administrative Simplification provisions of HIPAA. However, where State laws are not contrary but actually provide more stringent standards, the State laws will apply over (in addition to) the Federal security standards.

Security of payment card data is the responsibility of every business that participates in payment processing. Single industry-level security standards supported by the members of the PCI Security Standards Council eliminate confusing, competing, and overlapping brand-specific requirements to simplify compliance for businesses that store payment card data.

If I am deemed compliant with the PCI DSS today by one of the payment card brands, will the other brands in the PCI Security Standards Council recognize this designation of compliance and if so, what information must be put forth to achieve such recognition?

Since the individual payment brands are responsible for their own PCI DSS compliance programs, organizations should follow each brand’s specific compliance processes and procedures. Satisfying the requirements of one member of the PCI SSC should not be construed as compliance that will satisfy all other member payment card brands.

Since the individual payment brands are responsible for their own PCI DSS compliance programs, organizations should follow each brand’s specific compliance processes and procedures. Satisfying the requirements of one member of the PCI SSC should not be construed as compliance that will satisfy all other member payment card brands.

To minimize changes to the standards, the PCI Security Standards Council (PCI SSC) has established a lifecycle approach for PCI DSS and PA-DSS, where version changes to the standards will occur every 3 years. The 3-year standards lifecycle also allows for changes “out-of-cycle” as needed to address critical issues. To ensure that organizations have time to achieve compliance with new versions of the standards, certain new requirements may be phased in with future effective dates.

Because PCI SSC does not have a contractual relationship with merchants, financial institutes, processors, etc., PCI SSC cannot be the central repository for this information. The Council’s focus is to define effective payment-related security standards, as well as to educate and provide resources to the marketplace to drive awareness and adoption of these standards. The payment brands define and manage the compliance programs for these security standards, and entities will continue to send their compliance validation documentation to the payment brands, financial institutions (such as acquirers or merchant banks), or other agents as applicable for each payment card brand compliance program.

No. QSAs and ASVs do not send reports of compliance or scanning results to the PCI Security Standards Council. They should continue to follow the payment brand specific procedures.

No. In the event of a suspected account security breach, the business entity should follow existing, brand-specific processes and procedures for notifying the affected payment brand(s) and law enforcement officials.

The PCI Security Standards Council does not provide information on the status of breach investigations or PCI DSS compliance efforts. The PCI Security Standards Council receives guidance from the payment brands, the PFI community, and advisory groups regarding emerging threats and forensics trends. However, the PCI Security Standards Council does not a participate in forensics investigations or compliance reporting and does not receive information on specific forensic investigation cases or a specific organizations’ PCI DSS compliance status.

The PCI Security Standards Council will not conduct forensics investigations either directly or through a third party in the event of an account compromise.

The PCI Security Standards Council (PCI SSC) is not able to approve specific configurations or compensating controls since they are not onsite doing the assessment and are therefore not able to understand and review the total security environment.

Each individual approved as a Qualified Security Assessor (QSA) is trained by the PCI SSC regarding the underlying intent of PCI DSS requirements and the evaluation of compensating controls. QSAs are responsible for determining whether a compensating control is sufficient to meet the intent of a requirement during their review of all other controls in place to satisfy PCI DSS requirements. We recommend that you contact a QSA to review your environment and assist in evaluating any compensating controls you may have in place for meeting the intent of PCI DSS requirements.

PCI DSS stands for Payment Card Industry Data Security Standard. This standard (also referred to simply as “PCI”) outlines a set of security practices that help ensure the safe handling of payment card data. Created by the five major card companies (American Express, Discover JCB, MasterCard and Visa) that make up the Payment Card Industry Security Council, this standard includes 12 distinct requirements that are designed to:

• Build and maintain a secure network
• Protect (cardholder) data in transit or at rest
• Maintain a vulnerability management program
• Implement strong access control measures
• Regularly monitor and test your IT infrastructure
• Maintain an information security policy.

Any entity (merchant or service provider) that stores, processes, and/or transmits cardholder data must be PCI DSS compliant – regardless the size of the entity and volume of transactions made. However, PCI DSS requirements do not only apply to electronic data. Businesses are expected to dispose of printed material which contains payment card details and credit cardholder data in an appropriate way. In large environments where waste management is outsourced to subcontractors such as paper-shred companies, the entities that request such services must make sure that their “service providers” are PCI DSS compliant as well.

The PCI DSS defines “payment cards” as all credit/debit/cash cards that are issued with any American Express, Discover, JCB, MasterCard or Visa branding.

Payment card data is information pertaining to credit/debit cards and their owner. This data is classified in 2 categories “Cardholder Data” and “Sensitive Authentication Data.” PCI DSS imposes some storage restrictions on data elements making part of these categories.

Cardholder data refers to all information from a credit card or debit card that is used in a transaction. Cardholder data can include the Primary Account Number (PAN), Cardholder Name and Expiration Date displayed on the front of the card, etc. Cardholder data is digitally stored on the magnetic stripe at the back of the card.

Sensitive Authentication Data is security related information used to authenticate the cardholder’s identity and authorize card transactions. Sensitive Authentication Data elements include Magnetic Stripe data and the Card Validation Code – the three or four digit number security code found either on the front or on the back of a card (a.k.a. CVV, CVV2).

PCI DSS defines a “merchant” as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.

A self-assessment questionnaire (SAQ) is a reporting requirement of PCI DSS compliance for merchants and service providers. It can be completed in-house without contracting with a 3rd party. Businesses must complete this security-related questionnaire that examines the current and past state of network security.

PCI DSS requirement 8.3 is intended to apply to users that have remote access to the network, where that remote access could lead to access to the cardholder data environment. In this context, remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an “untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer. Internal company LAN-to-LAN access (e.g. between two offices via VPN) is not considered remote access for the purposes of this environment.

If the corporate network has appropriate segmentation such that remote users cannot access the cardholder data environment, two-factor authentication during remote access to the corporate network is not required by PCI DSS. However, two-factor authentication is required for any remote access to the cardholder data environment, and is recommended for remote access to the corporate network.

Payment Gateways connect a merchant to the bank or processor that is acting as the front-end connection to the Card Brands. They are called gateways because they take many inputs from a variety of different applications and route those inputs to the appropriate bank or processor. Gateways communicate with the bank or processor using dial-up connections, Web-based connections or privately held leased lines.

The point of sale (POS) environment refers to a transaction that takes place at a merchant location (i.e. retail store, restaurant, hotel, gas station, convenience store, etc.). An Internet protocol (IP)-based POS is when transactions are stored, processed, or transmitted on IP-based systems or systems communicating via TCP/IP.

The National Cyber Security Alliance estimates that one in five small businesses will be a victim of cybercrime this year.  Despite this reality, surveys reveal a dangerous lack of concern among small business owners about their own security and a widespread failure to plan and to implement policies to protect their systems and critical data. While it may seem that your risk of attack is lower than the larger companies this is not supported statistically. Furthermore, when a small business suffers a breach or cyberattack, it is much more likely to be catastrophic for the business.

A 2012 survey reported by CIO Magazine (2012 Global State of Information Security Survey) showed nearly equal responses (10%-18% each) for exploitation of data, mobile devices, applications, systems, networks, and humans (social engineering). Many companies go to great lengths to secure networks but fail to address the simpler threats. This is a lot like locking the front door but leaving all the windows open.

Cloud computing is not new. It is now a widely accepted solution for most businesses. But the question still remains – it is safe? While the answer is different from one company to the next, and the types of cloud services or tools used will vary by industry and by company, with appropriate safeguards in place, cloud computing can be a very secure, economical, and practical solution for most businesses.

Remote access can be great for productivity, work-life balance, and employee satisfaction but it does not come without risks.  These risks can be mitigated, however, with proper employee training and technical safeguards in place, your company can provide your employees a degree of flexibility.

Every Business Continuity Plan is different but the answer for virtually every business is, yes, you need a BCP. Smaller, more agile companies may think their need for a formal plan is less than that of a larger corporation. While the plan may not need to be as extensive, smaller companies should realize the risk from an event impacting business operations could be more severe and they may be less able than larger companies to recover without having a good plan in place ahead of time.

In general, a BCP speaks to the recovery of normal operations for the entire company. This would take into consideration factors such as physical asset recovery, getting employees to the work site during a disaster or event, safety considerations, absorbing and covering financial losses from down time, public relations issues, and so much more. A DRP is more often the term used for the IT Department’s contingency plan in the event of a disaster, cyberattack, outage, or anything that could impact the normal operation of the network or systems that employees need.

A combination of upper/lower case letters, symbols, and numbers, but not a word found in the dictionary or connected to the user personally (names, dates, and places). At least 12 characters long. Idea: take the first letter of each word in a sentence that is easy for you to remember. Use long password phrases, rather than single words or hard to remember combinations of characters.

Various authentication methods can be used to verify the identity of a user attempting to access or log into a system or network. See also Two Factor Authentication (TFA).

A programmer or developer of software or hardware (like medical devices, routers, etc.) may create a back door into the system or tool whereby they can gain access at a later date to make updates or perform maintenance. While a back door is usually created with good intentions, to ensure the product can be maintained once it is in use, a back door can also create vulnerability or an additional access point that is subject to exploitation and can increase the risk of a breach.open.

A data or security breach involves any unauthorized access or dissemination of information. A security incident which exposes sensitive data may or may not result in a breach.  But a breach can occur and data can be exposed due to a malicious attack on the system, theft, or by simple carelessness or failure to follow appropriate procedures. See also Incident.

An exhaustive strategy by a hacker to try every potential access point and password combination to gain access to the system; given enough time and a dedicated computer set to the task, a brute force attacker may eventually succeed in converting cipher text to plain text to find the key and gain access to the network.

Business Continuity is the ability of an organization to withstand a natural or malicious event that impacts operations. A Business Continuity Plan must be created before an incident arises to determine appropriate emergency response, backup operations, and disaster recovery steps to be taken under a variety of possible scenarios..

A Business Impact Analysis (BIA) seeks to predict the consequences of any incident that could disrupt business function and processes. A risk assessment should be conducted as the foundation for the BIA which is essential for a solid Business Continuity Plan.

“Bring Your Own Device” and refers to employees who use their own personal mobile devices, smartphones, or laptops to work and to access secure employer networks. BYOD has become an unavoidable part of operations and an issue that virtually all employers will have to address by policies and procedures to avoid the security issues that can arise if employees’ personal devices are not properly managed.

Industry-wide government regulations (like HIPAA and HITECH) or widely accepted industry-standards (such as PCI) require companies and organizations to demonstrate that they have complied with the specific requirements of the regulations or standards. Compliance is an on-going process and, failure to maintain appropriate compliance on an ongoing basis can leave the organization vulnerable to attack or breach and can ultimately result in penalties or fines.

A Denial of Service or DoS attack is a relatively simple hack designed to prevent authorized users from accessing or using the network or system by flooding it with useless traffic. Similarly, a Distributed Denial of Service (DDoS) attack uses multiple compromised systems to simultaneously flood a network. Because there are multiple sources of the traffic, the DDoS attack can be even more difficult to stop. See also Telephony Denial of Service (TDos).

A dictionary attack uses software to try every possible combination of words to breach a password-based system. This automated process can also be used to generate and try possible email addresses to launch a phishing scam to potentially reach a small percentage of real accounts.

Encryption is a method of converting original data of regular text into encoded text. The text is encrypted by means of an algorithm. If information is encrypted, there would be a low probability that anyone other than the receiving party who has the key to the code or access to another confidential process would be able to decrypt (translate) the text and convert it into plain, comprehensible text.

HIPAA stands for the Health Insurance Portability and Accountability Act. Passed in 1996, the act established national standards to protect the privacy and personal health information (PHI) of patients.

The Health Information Technology for Economic and Clinical Health Act was passed in 2009 within Title XIII of the American Recovery and Reinvestment Act to increase spending by the US Dept. of Health and Human Services (HHS) for the expansion and promotion of health information technology.

An IT Security Incident is any malicious, accidental, technical, or natural event that potentially impacts operations and may expose or cause the loss of critical or secure data. It is important to note that a breach always begins with an incident but every incident does not necessarily lead to a breach.

Malware is malicious software designed to damage or disrupt a system. Types of malware include adware, bots, bugs, ransomware, spyware, viruses, trojan horses, worms, etc.

A network is a group of two or more computer systems linked together.

NIST stands for the National Institute of Standards and Technology, a federal agency within the US Department of Commerce. NIST publishes industry standards and best practices related to Information Technology, Health IT, and many other subject areas. Visit www.nist.gov for more.

Similar to a pharming attack, a phishing scam sends mass emails that appear to come from legitimate companies or organizations to lure or trick the recipient into divulging personal, financial, or login information.

PII stands for Personally Identifiable Information. PII is any piece of information that can be used to identify, locate, or contact a single person. PHI stands for Protected Health Information. ePHI stands for Electronic Protected Health Information. Both PHI and ePHI are protected by the HIPAA Privacy Rule.

Remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an “untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer.

Social engineering is any tactic designed to obtain secure information (login, customer, patient, or corporate data) by conning a person into revealing the information. Social engineering relies on the overly trusting nature of most people or a lack of appreciation for the value of the information they may possess.

Like a DoS or DDoS attack, a TDoS attack floods a company or organization’s phone system with incoming calls so that the system becomes completely unusable. This tactic has often been seen targeting hospitals, emergency rooms or other healthcare facilities.

In general, authentication is still primarily based on what you know – your username and password, for example. Increasingly, systems requiring more secure authentication are turning to “two-factor authentication” (TFA) which usually relies upon something you know, your password, plus something you have – like a special, one time pin or code texted to the user’s cell phone.

A zero day exploit is an attack that takes place on the very day that vulnerability in a system, tool, or piece of software is made public or becomes generally known. This is an opportunistic attack that attempts to take advantage of the newly identified vulnerability before the company or developer is able to release a patch to correct it.