How to Find Time for HIPAA Compliance

Simple patient data security doesn’t have to be time consuming.

Find time for HIPAA complianceTime-wise, HIPAA compliance is about maximizing the little time you have. Here are a few things you can do at your organization that will help you maintain patient data security. 

(If you’d like all of my suggestions for HIPAA time management, watch this 70-minute recorded presentation.)

Perform an office physical.

Generally, doctors don’t perform physicals on themselves. It’s the same with an office security physical. This is a great opportunity to bring in a third party (this one, for example) to examine any irregularities with your data security.

That being said, if you’re a small provider with only a few staff members, you can probably perform a simple version of this yourself. 

Look at your office from the eyes of a patient. Can they look down on the receptionist counter and see patient information? If they can, that’s a problem. Look for devices that are unattended and logged in, especially in exam rooms. Patients left alone in exam rooms with logged-in devices could easily start browsing and inadvertently see other patient’s information. 

Your office physical obviously doesn’t replace a HIPAA risk analysis, but should give you a very attainable place to start. Based on what you see, make goals like, “Talk to workforce staff about leaving their computers unlocked,” and “Buy more document shredders for the office.” 

Update your systems and applications.

When I audit healthcare organizations, I see a lot of out-of-date EHR systems, computer operating systems, and anti-virus programs. These out-of-date systems and applications aren’t being protected with the latest security updates, and therefore make your organization vulnerable to data breach, not to mention out of compliance with HIPAA regulations.

A single aspect of security, like anti-virus, doesn’t render other security requirements useless. You can easily break a single stick over your knee, but put 10 sticks of the same size in a bundle and it’s near impossible to break. Security is the same way.
Security has layers, which is why it’s so important that when one layer is out of date, it gets fixed or replaced.Tweet: HIPAA security has layers: http://bit.ly/1EkhZs2Tweet
So, update your EHR! Pay that annual $60 license fee to keep your anti-virus up and running. 

If you’re looking for an easy HIPAA compliance plan, check out our 21-day plan for HIPAA compliance.

Learn how to protect against social engineering

Social engineering is a way of manipulating someone to trust you enough to divulge important information. Because medical data is so valuable on the black market, I wouldn’t be surprised to see a rise in social engineering in the coming years.

The following is a true story from one of our customers about social engineering: 

A small provider had just trained their staff on social engineering. Two days later, a well-dressed guy showed up. He said he was from their insurance company and needed to look at a particular medical device. The receptionist told him she didn’t have a record of him coming, and tested him by asking how many particular medical devices they had. He said four. They only had one. She told him that without proper authorization, she couldn’t let him back to see that device. He left. A quick call to the insurance company verified they had not sent anyone out to visit. We don’t know for sure what he was after, but you can bet it was PHI.

That is a great example of why staff security training is absolutely crucial! That receptionist was able to stop a social engineer armed simply with a little information.

Separate user accounts for all staff

Each workforce member should have different access to patient information based on their jobs and roles within your organization. The receptionist shouldn’t have the same access as the nurse. In your Windows active directory, Windows server, and EHR systems, create access control roles for each type of staff you employ. Be sure to give everyone their unique own account. Individual accountability (exactly who access PHI and when) is a basic HIPAA requirement.

Read more about role-based access here: Everyone Is Not Created Equal in Healthcare

Subscribe to blog.securitymetrics.com

Make security a habit

Try to work on these small HIPAA compliance/data security actions for at least 10 minutes per day for an entire month. Set a reminder on your phone’s calendaring system. It doesn’t matter if you are researching phishing, doing an inventory of your systems, or looking at your notice of privacy practices (NoPPs) to make sure they’re up to speed; you are working diligently to be more secure as an organization. 

What have you done in the past to help manage the time involved with becoming HIPAA compliant?

Tod Ferran (CISSP, QSA) is a Mensa aficionado, Cancun expert, and Security Analyst for SecurityMetrics with over 25 years of IT security experience. In addition to his many speaking engagements and webinars, he provides security consulting, risk analysis assistance, risk management plan support, and performs security, HIPAA, and PCI compliance audits. Connect with him for recommendations on excellent places to stay, activities, and restaurants in Cancun, or check out his other blog posts here.

From EHR HIPAA Compliance to Total HIPAA Compliance
PCI 3.1: Stop Using SSL and Outdated TLS Immediately

“SSL has been removed as an example of strong cryptography in the PCI DSS, and can no longer be used as a security control after June 30, 2016.”

Gary Glover, Director of Security Assessments
By: Gary Glover
The PCI DSS has released an unscheduled and important update to PCI DSS requirements: PCI 3.1.  While it does include minor clarifications and additions, PCI version 3.1 was primarily released to address the insecurity of Secure Sockets Layer (SSL) and some Transport Layer Security (TLS) encryption protocols. 

Still catching up changes from PCI 3.0? Check out our Ultimate Guide to PCI DSS 3.0.

Effective immediately, all SSL and early TLS versions are no longer considered to be strong cryptography.
PCI 3.1 SSL TLS
SSL and TLS encrypt the information sent between web browsers and web servers. Since the release of SSL v3, unfixable vulnerabilities were identified. You may have heard of some of these vulnerabilities in 2014, including FREAK, POODLE, and WinShock

The point is, the PCI Council has deemed that SSL and early TLS will no longer protect cardholder data.PCI Council: SSL and early TLS will no longer protect cardholder data. http://bit.ly/1ERO1KqTweet
From April 15, 2015 on, merchants must not implement new technology that relies on SSL or early TLS (version 1.0 and sometimes 1.1, depending on use and implementation). Merchants already using systems and devices that utilize SSL and TLS must discontinue the use of those systems and devices before June 30, 2016. 

The PCI DSS v3.1 requirements directly affected are:
  • Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons considered insecure.
  • Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
  • Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
SSL No Longer SecureEach of these requirements will have additional sub requirements or guidance provided in the new PCI DSS 3.1 version.

How will PCI 3.1 affect SecurityMetrics customers?

SecurityMetrics has been scanning for SSL vulnerabilities for over a decade. Specifically, we have been scanning for SSL version 3 vulnerabilities, such as the POODLE vulnerability, since October 2014. 

  • SecurityMetrics vulnerability scans do not currently fail merchants using TLS 1.0, but this will happen before the June 30, 2016 deadline.
  • Merchants using SSL version 3 will fail their SecurityMetrics vulnerability scan(s). If there is a hardware or software limitation preventing you from disabling SSL 3.0 or TLS 1.0 and you would like to dispute these vulnerabilities found on your scans, you’ll need to submit documented confirmation that you have implemented a risk mitigation and migration plan, and are working to complete your migration by June 30, 2016. Please contact SecurityMetrics Support if you need to dispute a failing vulnerability.
Read the entire summary of changes from 3.0 to 3.1


What about HTTPS and ecommerce?

Because virtually all ecommerce websites have SSL/TLS enabled for their cryptography, they are at the highest risk from SSL/TLS vulnerabilities. New e-commerce websites must not use or support SSL/early TLS.

The PCI Council also stated that web browsers will begin prohibiting SSL connections in the near future, preventing users from accessing web servers that haven’t migrated to a more modern protocol. 


What about my POS/POI terminal?

The PCI Council decided that Point of Sale (POS) or Point of Interaction (POI) devices that aren’t susceptible to all known exploits of SSL and early TLS may be used, even after June 30, 2016. 

Merchants who continue using old POS or POI devices should understand that because SSL is outdated technology, it may be subject to future security vulnerabilities. The PCI Council recommends that POI environments update to TLS v1.1 or greater if possible.

How do I know if I’m using SSL/TLS?

SSL and TLS are widely used, so I recommend contacting your terminal providers, gateways, service providers, vendors, and acquiring bank to determine if the applications and devices you use have this encryption protocol. If you’re writing your own software, please check with your development department.

Examples of applications that likely use SSL/TLS
  • Virtual payment terminals
  • Back-office servers
  • Web/application servers

What if I’m using SSL/TLS?

The PCI Council offered great guidance on migrating from SSL and TLS, as well as examples and recommendations on how to deal with this requirement in their Migrating from SSL and Early TLS information supplement.

If you use SSL/TLS, but don’t need to:
If you have existing implementations of SSL and early TLS that you don’t need for regular business operations, immediately remove or discontinue all instances of SSL/TLS. Do not use any new technologies that use SSL/TLS.

If you use SSL/TLS, and need to continue using:
First, remember not to use any new technologies that use SSL/TLS. If you need to continue using SSL/TLS to continue regular business operations, here are some examples of what you can do to replace use of SSL/early TLS:
  • Upgrade to a current, secure version of TLS configured to not accept fallback to SSL or early TLS. 
  • Encrypt data with strong cryptography before sending over SSL/early TLS (for example, use field-level or application-level encryption to encrypt the data prior to transmission) 
  • Set up a strongly-encrypted session first (e.g. IPsec tunnel), then send data over SSL within the secure tunnel 
  • Check firewall configurations to see if SSL can be blocked
  • Check all application and system patches are up to date
  • Check and monitor systems to ID suspicious activity that may indicate a security issue
Please note that organizations with existing implementations of SSL and early TLS must have a Risk Mitigation and Migration Plan in place. According to the PCI Council, this document will “detail [your] plans for migrating to a secure protocol, and also describes controls [you have] in place to reduce the risk associated with SSL/early TLS until the migration is complete.”

You will need to provide your Risk Mitigation and Migration Plan to your PCI assessor as part of the PCI DSS assessment process.

Learn more about the Risk Mitigation and Migration Plan in the PCI Council’s migrating from SSL and Early TLS information supplement.

Will more information about PCI 3.1 be revealed in the future?

More about PCI 3.1 (including new SAQs) will be revealed in the near future. 

According to an email I received from the PCI Council, “Corresponding changes to PA-DSS are in progress, and PA-DSS 3.1 will be published shortly. Information on how PA-DSS submissions will be addressed will also be made available at that time.”

In the meantime, merchants have until June 30, 2016 to comply with PCI 3.1.

Need help discontinuing the use of SSL/TLS? Contact our PCI support team.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.

Current Hacking Trends Ebook
 How Much Does Penetration Testing (Pen Test) Cost?

How much does a penetration test cost?

Ethical hacking. It’s a great way to discover where your business security fails.

Gary Glover, Director of Security Assessments at SecurityMetrics
By: Gary Glover
Your company may have the technology in place to prevent data theft, but is it enough? How do you prove it? The most accurate way to know if you’re safe from a hacker is through live penetration testing, also called pen testing, or ethical hacking. 
How much does a penetration test cost? 

What is penetration testing?

To beat a hacker, you have to think like a hacker. Penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors) just like a hacker would. In simpler terms, they try to break into your company’s network to find security holes. 

The Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 requires both an internal and external penetration test (What is PCI?), so most companies regularly receive penetration tests to comply with that requirement. But penetration testing isn’t limited to the PCI DSS. Any company can request a penetration test whenever they wish to measure their business security.
The time it takes to conduct a pen test varies based on the size of a company’s network, the complexity of that network, and the individual penetration test staff members assigned. Tweet: How much time (and money) does a penetration test require? http://bit.ly/1Nyn4kH #PCITweet
A small environment can be done in a few days, but a large environment can take several weeks.

Vulnerability scanning and penetration testing are different

Some people mistakenly believe vulnerability scanning or antivirus scans are the same as a professional penetration test. Even some companies tout ‘penetration testing services’ when in fact, they only offer vulnerability scanning services. As a general rule, any ‘pen test’ that is listed for less than $3,000 is probably not a real penetration test.

An external vulnerability scan is an automated, affordable, high-level test that identifies known weaknesses in network structures. Some are able to identify more than 50,000 unique external weaknesses. Don’t get me wrong, vulnerability scans have their place. In fact, I highly recommend them as weekly, monthly, or quarterly insight into your network security. 
penetration testing
Here are the two biggest differences. A vulnerability scan is automated, while a penetration test includes a live person actually digging into the complexities of your network. A vulnerability scan only identifies vulnerabilities, while a penetration tester digs deeper to identify, then attempt to exploit those vulnerabilities to get access to secure systems or stored sensitive data.

Understand the difference?

Learn about SecurityMetrics’ vulnerability scanning services.

So what’s the actual cost of a penetration test?

With any business service, cost varies quite a bit based on a set of variables. The following are the most common variables with regard to penetration testing services:
  • Complexity: the size and complexity of your environment and network devices are probably the biggest factors of your penetration test quote. A more complex environment requires more labor to virtually walk through the network and exposed web applications looking for every possible vulnerability. 
  • Methodology: each pen tester has a different way they conduct their penetration test. Some use more expensive tools than others, which could jack up the price. That’s not necessarily a bad thing. More expensive tools could reduce the time of your test, and produce higher quality results. 
  • Experience: pen testers with more experience will be more expensive. Just remember, you get what you pay for. Beware of pen testers that offer prices that are too good to be true. They probably aren’t doing a thorough job. I suggest looking for penetration testers with credentials behind their name like CISSP, GIAC, CEH, or OSCP.
  • Onsite: most penetration tests can be done offsite, however; in rare cases that involve very large/complex environments, an onsite visit could be required to adequately test your business security. Onsite visits are also required if you request a physical security or social engineering penetration test. 
  • Remediation: some pen testers include remediation assistance and/or retesting in their price. Others provide test results and disappear. 
Learn more about SecurityMetrics’ penetration testing

With everything above accounted for, typically penetration tests start around $4,000 but can rise well above $20,000.


Penetration tests are worth it, every time

If you think that price is unreasonable, think of this. A hacker only has to find one hole to get into your network and steal data. A pen tester works hard to find as many holes as possible that could allow you to be compromised. You are paying a professional to look through every nook and cranny of your business to find each possibility of compromise. There is no better way to test the actual effectiveness of your security systems than by the skills of an experienced penetration test team.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.

5 payment industry trends in 2015
How to Start a HIPAA Risk Analysis

A step-by-step process and template to help you start along your risk analysis journey.

Tod Ferran HIPAA Security Analyst
By: Tod Ferran
Looking for the HIPAA risk analysis template

A risk analysis is the first step in an organization’s Security Rule compliance efforts. It’s the "physical” that ensures all security aspects are running smoothly, and any weaknesses are addressed. And unlike popular belief, a HIPAA risk analysis is not optional.
HIPAA Risk Analysis Worksheet
The HHS issued guidance for risk analysis requirements that explains in additional detail the purpose of a risk analysis. 

“Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is foundational…”

A risk analysis is foundational to your security! You can’t be HIPAA compliant without one!

What is a HIPAA risk analysis?

A risk analysis is a way to assess the potential vulnerabilities, threats, and risks to protected health information (PHI) at your organization. Though the HHS did not specify an exact risk analysis methodology, they do require certain elements be present in a risk analysis, which we’ll talk about later, namely:
  • Scope analysis
  • Data collection
  • Vulnerabilities/threat identification
  • Assessment of current security measures
  • Likelihood of threat occurrence
  • Potential impact of threat
  • Risk level
  • Periodic review/update as needed

Risk Analysis Methodology

There are a variety of methods to conduct a HIPAA risk analysis, but I’ve described the method I’ve found to work best below. This is a condensed version of the method I use during the HIPAA onsite Risk Analysis that I conduct. 

Please understand, conducting a complete and thorough risk analysis is extremely difficult to do yourself. I recommend contracting with a HIPAA auditor to help you. The problem is, most people just simply don’t know where to look, or bypass things because they don’t understand data security. If the Risk Analysis is foundational to your security, then you don’t want to overlook key Risk Analysis elements. (Learn the pros and cons of a HIPAA audit)
So let’s dive a little deeper into the methodology of how to conduct a risk analysis.Tweet: Dive a little deeper into the methodology of how to conduct a HIPAA risk analysis. http://bit.ly/1IzvV2cTweet

Step 1: Define scope by defining PHI flow in your environment 

To identify your scope (scope meaning: the areas of your organization you need to secure), you have to understand how patient data flows within your organization. If you know all the places PHI is housed, transmitted, and stored, you’ll be able to better safeguard those potential vulnerable places.  

There are four main parts to consider when defining your scope. 
  • Where PHI starts or enters your entity
  • What happens to it in your system
  • Where PHI leaves your environment
  • Where potential or existing leaks are
Where PHI enters your environment
In the PHI lifecycle, it’s important to identify all PHI inputs. By doing this, you can make sure you identify exactly where security should begin at your organization. 

When considering the origination of PHI, think of both new and existing patient records. PHI can begin from patients filling out their own information on physical paper, to business associates faxing you asking for more information about a current or former patient.

Here’s a list of places to get you started in the documentation of where PHI enters your environment.
  • Email: How many computers do you have, and who can log on to each computer?
  • Texts: How many mobile devices do you have, and who owns them?
  • EHR entries: How many staff members do you have entering in data?
  • Faxes: How many fax machines do you have?
  • USPS: How is incoming mail handled?
  • New patient papers: How many papers are patients required to fill out, and where? Front desk? In the examination room?
  • Business associate communications: How do business associates communicate to you?
  • Databases: Do you receive marketing databases of potential patients to reach out to?

What happens to PHI in your environment, including where it is stored
It’s not just enough to know where PHI begins. You must know exactly what happens to it once it enters your environment. Does it go directly to accounting? Is it automatically stored in your EHR? If it is emailed, is it encrypted?

To adequately understand what happens to PHI in your environment, you must record all hardware, software, devices, systems, and data storage locations that touch PHI in any way. 

Here’s a list of places to get you started.
  • Filing cabinets
  • Mobile devices
  • EHR/EMR systems
  • Calendar software
  • Email
  • Servers
  • Workstations
  • Networked medical devices
  • Laptops
  • Computers
  • Operating systems
  • Applications
  • Encryption software
How does PHI leave your environment?
A lot of workforce members forget that they must protect PHI throughout its entire lifecycle. And that includes when it leaves your hands. If PHI leaves your organization, it is your job to ensure it is transmitted or destroyed in the most secure way possible. You, along with your business associate, are responsible for how the business associate handles your PHI.

Here are some things to consider when PHI leaves your environment.
  • Business associates
    • Encrypted transmission
    • Minimum necessary
    • Lifecycle with the BA
  • Recycling companies
  • Trash bins on computers

Where does PHI leak?
Now that you are the expert on what happens during the PHI lifecycle, it’s time to find the gaps. These gaps in security and environment weaknesses are the whole reason we define scope. Weaknesses provide the ability for unsecured PHI to leak in or outside your environment.

The best way to find all possible leaks is by creating a PHI flow diagram. Essentially, a PHI flow diagram documents all the information you found above, and lays it out in a graphical format. It’s a lot easier to understand PHI trails when looking at a diagram.

We’ll discuss environment weaknesses further in Step 2.

Step 2: Identify Vulnerabilities, Threats, and Risks to Your Patient Data


Now that you know how PHI flows in your organization, and can better understand your scope, you have to find the problems within that scope. For each of the identified areas above, you must identify:
  • What vulnerabilities exist in the system, application, process or people
  • What threats, internal, external, environmental and physical, exist for each of those vulnerabilities
  • What is the probability of each threat triggering a specific vulnerability? This is the risk.
As you think about your vulnerabilities, threats, and risks, keep in mind these categories in particular:
  • Digital: (e.g., setting a weak password on an EHR system)
  • Physical: (e.g., not shredding PHI, inaccessibility of facility)
  • Internal: (e.g., employee checks personal email and downloads malware)
  • External: (e.g., hacker trying to breach your remote access software)
  • Environmental: (e.g., fire destroys the building your backups are kept in) 
  • Negligent: (e.g., employee accidentally leaving patient data visible in an examination room computer)
  • Willful: (e.g., employee snooping on celebrity, ex-spouse/companion, or family member)
Feel free to download and print this HIPAA Risk Analysis worksheet to help you jot down your ideas. 

What are your vulnerabilities?

A vulnerability is a flaw in components, procedures, design, implementation, or internal controls. Vulnerabilities can be fixed.

The HHS explains further, “Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a security incident, such as inappropriate access to or disclosure 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.”

Examples of vulnerabilities I’ve seen while conducting a HIPAA risk analysis:
  • Unpatched operating system software
  • Website coded incorrectly
  • No office security policies
  • Misconfigured or no firewall
  • Computer screens in view of public patient waiting areas
What are your threats?
A threat is the potential for a person or thing to trigger a vulnerability. Generally, it’s difficult for threats to be controlled. Even though most remain out of your control to change, they must be identified in order to assess the risk. Physical location, organization size, and systems all have the potential to be a threat.

According to the HHS, “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 threats I’ve seen while conducting a HIPAA risk analysis
  • Geological threats, such as landslides, earthquakes, and floods
  • Hackers downloading malware onto a system
  • Inadvertent data entry or deletion of data
  • Power failures
  • Chemical leakage
  • Workforce members
  • Business associates
What are your risks? 
Risks are the probability that a particular threat will exercise a particular vulnerability, and the resulting impact on your organization.

Let me explain with an example. 

In a system that allows weak passwords, the vulnerability is the fact that the password is vulnerable to attack. The threat is that a hacker could crack the password and break into the system. The risk is the unprotected PHI in your system. 

According to the HHS, “risk is not a single factor or event, but rather it is a combination of factors or events (threats and vulnerabilities) that, if they occur, may have an adverse impact on the organization.”

Examples of risks I’ve seen while conducting a HIPAA risk analysis
  • Remote access to a PHI system with a weak password. There is an extremely high probability (“high” risk) that an external hacker will brute force the password and gain access to the system.
  • Windows XP machine with access to the Internet. There is an extremely high probability (“high” risk) that an external hacker will exploit security flaws (there is no longer support for WinXP) using malicious software and gain access PHI.
As we talk about vulnerabilities, threats, and risk, I want to reiterate my plea with you to consult a security professional. Even above-average compliance superstars only have a minimal understanding of vulnerabilities and threats. It’s crucial to ask a professional for help with your risk analysis. 

Step 3: Analyze HIPAA Risk Level and Potential Impact

Now that you’ve identified any possible security problems in your organization (and there should be a lot), you need to bring that list back to reality. It’s time to decide what risks could and will impact your organization. This risk and impact prioritization is a crucial part of your risk analysis that will eventually translate to your risk management plan.

To analyze your risk level, you must first consider the following:
  • Likelihood of occurrence: Just because you are threatened by something, doesn’t necessarily mean it will have an impact on you. For example, an organization in Texas and an organization in Vermont technically could both be struck by a tornado. However, the likelihood of a tornado striking Texas is a lot higher than Vermont. So, the Texas-based organization’s tornado risk level will be a lot higher than the Vermont-based organization.
  • Potential impact: What is the effect the particular risk you are analyzing would have on your organization? For example, while a computer screen might accidentally show PHI to a patient in the waiting room, it probably won’t have as big of an impact as a hacker attacking your unsecured Wi-Fi and stealing all your patient data.
Every vulnerability and associated threat should be given a risk level. I typically assign mine a number as ‘high’, ‘medium’ and ‘low’. By documenting this information, you’ll have a prioritized list of all security problems at your organization. 

Download this risk analysis template worksheet to help you start documenting your risks.

Step 4: Identify Top Security Measures Based on Top HIPAA Risks

Now that you have a prioritized list of all your security problems, it’s time to start mitigating them! Starting with the top-ranked risks first, identify the security measure that fixes that problem. 

For example, if your risk is employees throwing PHI in the trash, your security measure could be quarterly employee security training and replacing trashcans with shredders. 

Technically, once you’ve documented all the steps you’ll take, you’re done with the Risk Analysis! The implementation phase of fixing your security problems is actually part of your risk management plan (another crucial step towards HIPAA compliance.)

Step 5: Rinse, Repeat

A risk analysis is truly a rinse and repeat process. One of the most important parts of your risk analysis is documentation. If you don’t document steps 1-4, you can’t prove to the HHS that you’ve completed a complete and thorough risk analysis. They will want to see documentation, your risk management plan, and monthly progress on addressing the items identified in that risk management plan.

There is a lot to do, and it can be overwhelming. Don’t try to do it all at once, but start now and schedule time each week or at least once per month to work on your HIPAA compliance.

Reading this article is a great start, keep the ball rolling!

Tod Ferran (CISSP, QSA) is a Mensa aficionado, Cancun expert, and Security Analyst for SecurityMetrics with over 25 years of IT security experience. In addition to his many speaking engagements and webinars, he provides security consulting, risk analysis assistance, risk management plan support, and performs security, HIPAA, and PCI compliance audits. Connect with him for recommendations on excellent places to stay, activities, and restaurants in Cancun, or check out his other blog posts here.


PCI Audit Alphabet Soup: De-Jumbling the Jargon

What do all those acronyms stand for anyway?

Gary Glover, Director of Security Assessments
By: Gary Glover
Acronyms in the payment card industry are pervasive, to say the least. You may come across them in actual PCI DSS documents created by the PCI Council, hear them in a conversation with your PCI auditor, or find them online during security research.

SEE ALSO: PCI FAQ

Here’s the lingo you should understand to grasp PCI security requirements.


AES (Advanced Encryption Standard): government encryption standard to secure sensitive electronic information.

AOC (Attestation of Compliance): a declaration of a merchant’s adherence to the PCI DSS.

APT (Advanced Persistent Threat): network attack in which a hacker breaks into a network undetected and harvests information over a long period of time. IDS/IPS and FIM are used to detect these attacks.

ASV (Approved Scanning Vendor): a company approved by the PCI SSC to conduct vulnerability scanning tests.

BCP (Business Continuity Plan): identifies an organization’s exposure to internal and external threats.

CDE (Cardholder Data Environment): any individual, software, system, or process that stores, processes, transmits, or handles cardholder data.

CERT (Computer Emergency Response Team): designated group to handle computer security incidents.

CHD (Cardholder Data): sensitive data found on payment cards, such as an account holder name or primary account number (PAN) data.

CISSP (Certified Information Systems Security Professional): a globally recognized certification that confirms an individual’s knowledge about information security.

CVV/CSC/CVC/CAV (Card Verification Value): element on a payment card that protects information on the magnetic stripe. Specific acronym depends on card brand.

CVSS (Common Vulnerability Scoring System): standardized method for rating and describing IT vulnerabilities.

DLP (Data Loss Prevention): a piece of software or strategy used to catch unencrypted data being exfiltrated or sent outside the network.

DMZ (Demilitarized Zone): neutral zone between a private and public network, providing an additional buffering layer of security, typically where web servers are hosted.

DNS (Domain Name Server): a way to translate URLs to IP addresses.

DSS (Data Security Standard): (see PCI DSS)

FIM (File Integrity Monitoring): a method to watch for changes in software, systems, and applications in order to detect potential malicious activity.

FTP (File Transfer Protocol): an insecure way to transfer computer files from computer to computer using the Internet. (see SFTP)

FW (Firewall): system designed to screen incoming and outgoing network traffic.

GPG (GNU Privacy Guard): the free version of PGP (a file encryption standard).

HTTP (Hypertext Transfer Protocol): A method of communication between servers and browsers. (See: HTTPS)

HTTPS (Hypertext Transfer Protocol Over Secure Socket Layer): A secured method of communication between servers and browsers.

HSM (Hardware Security Module): a physical computing device that safeguards and manages digital keys for strong authentication.

IDS/IPS (Intrusion Detection System/Intrusion Prevention System): a system used to monitor network traffic and report potential malicious activity.

IMAP (Internet Message Access Protocol): a communication protocol used to access email from your mail server.

IP (Internet Protocol): defines how computers send packets of data to each other.

IRP (Incident Response Plan): policies and procedures to effectively limit the effects of a security breach.

IT (Information Technology): anything relating to networks, computers, and programming, and the people that work with those technologies.

LPAR (Logical Partition): partitioning a computer’s resources, processors, memory, and storage into a smaller unit, normally a term associated with mainframe computers.

MAC (Message Authentication Code): information used to authenticate a message to ensure its authenticity.

NAC (Network Access Control): restricts data that users, apps, and programs can access on a computer network.

NVD (National Vulnerability Database): a repository of all known vulnerabilities, maintained by NIST.

NIST (National Institute of Standards and Technology): federal agency that measures standards and maintains the NVD.

OWASP (Open Web Application Security Project): a non-profit organization focused on software security improvement. Often heard in the context of “OWASP Top 10”, a list of top threatening vulnerabilities.

PAN (Primary Account Number): the 14 or 16 digits that identify a payment card. Also called a bank card number.

PA DSS (Payment Application Data Security Standard): validation standard for software applications that store, process, or transmit cardholder data.

PA QSA (Payment Application Qualified Security Assessor): individual or organization qualified by the PCI SSC to conduct PA DSS audits.

PCI SSC (Payment Card Industry Security Standards Council: established in 2006 by Visa, MasterCard, American Express, Discover Financial Services, and JCB International to regulate cardholder data security.

PCI DSS (Payment Card Industry Data Security Standard): requirements put together by the PCI SSC, required of all businesses that process, store, or transmit payment card data, to prevent cardholder data theft.

PGP (Pretty Good Privacy): data encryption computer program that provides privacy for encrypting emails, files, directories, and disks.

P&P (Policies and Procedures): guidelines and principles adopted by an entity with respect to organizational security.

P2PE (Point-To-Point Encryption): credit/debit card data encryption from the point of interaction to a merchant solution provider.

QIR (Qualified Integrator or Reseller): third party qualified by the PCI SSC to use security best practices while installing or maintaining payment systems.

QSA (Qualified Security Assessor): the individuals and firms certified by the PCI SSC to perform PCI compliance assessments.

RBAC (Role-Based Access Control): the act of restricting users’ access to systems based on their role within the organization.

ROC (Report on Compliance): a report documenting a company’s results from their PCI assessment, usually written by a QSA.

ROV (Report on Validation): a report on a company’s security that must be submitted to the PCI SSC.

SAQ (Self-Assessment Questionnaire): a collection of documents used to document an entity’s PCI DSS assessment results, based on their processing environment.

SFTP (Secure File Transfer Protocol): a secure way to encrypt data in transit.

SSL (Secure Socket Layer): Internet security standard for encrypting the link between a website and a browser to enable the transmission of sensitive information (predecessor to TLS).

TCP (Transmission Control Protocol): (see IP)

TFA (Two-Factor Authentication): two out of three independent methods of authentication are required to verify a computer or network user. The three possible factors are:
  • Something you know (such as a username and password)
  • Something you have (such as an RSA token or cell phone which gives you a new code for each login)
  • Something you are (such as fingerprint or iris scan)
TLS (Transport Layer Security): (See SSL)

VLAN (Virtual Local Area Network): computers, servers and networks on the same LAN, even though they may be geographically dispersed.

VPN (Virtual Private Network): a strategy of connecting remote computers to send and receive data securely over the Internet as if they were directly connected to the private network.

WEP (Wired Equivalent Privacy): an outdated and weak security algorithm for wireless networks.

WLAN (Wireless Local Area Network): network that links to two or more devices wirelessly.

WPA (Wi-Fi Protected Access): security protocol designed to secure wireless computer networks.

WPA2 (Wi-Fi Protected Access II): a more secure version of WPA (see WPA)

XSS (Cross-Site Scripting): An attack that enables hackers to inject code into public-facing web pages and gain access into a system.

3DES (Triple Data Encryption Standard): a secure encryption standard that encrypts data three times.

Did I miss any PCI acronyms?



Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.