Latest SSL Vulnerability: Logjam

SSL Vulnerability Logjam

What does Logjam mean for your business?

Follow up investigations on the FREAK vulnerability have led to the discovery of yet another SSL encryption protocol vulnerability: Logjam. According to researchers at Johns Hopkins University, the flaw has been around for almost two decades, but was just recently discovered. It weakens the encrypted connection between user and web/email server. About 8% of the top one million HTTPS sites are estimated to be vulnerable.
SSL Vulnerability Logjam

Affected browsers

  • Google Chrome
  • Mozilla Firefox
  • Internet Explorer
  • Apple Safari

How does Logjam work?

The problem is, the encryption protocol called Diffie-Hellman lets hackers downgrade connections to crackable 512-bit security (if an attacker can get man-in-the-middle access). It’s unknown if malicious entities have exploited the weakness.

SEE ALSO: PCI DSS 3.1: Stop Using SSL and Outdated TLS Immediately

Our recommendations

Luckily, we aren’t waiting around for browser patches for this vulnerability. It’s already been patched. Here are our recommendations. 
  • Don’t use SSL version 2.0 or 3.0. (Use TLS 1.1 or 1.2)
  • Don’t use export-level cyphers.
  • If you haven’t upgraded your email server after FREAK, do so now.
  • If you’re an admin, you need to change the Diffie-Hellman cipher settings on your server. 
  • If you’re a casual browser, install the latest version of your browser…and browse on.
SecurityMetrics vulnerability scan customers can check if their systems are vulnerable by running a SecurityMetrics vulnerability scan. If you've been running your regular scans and fixing vulnerabilities as they arise, you should already be covered on a server level basis.

If you have any questions, please contact SecurityMetrics support, 801.705.5700.

Subscribe to
Prioritizing HIPAA: 101

Prioritization: the best HIPAA security strategy.

Tod Ferran, SecurityMetrics
By: Tod Ferran
This article was originally written for, and distributed to the members of AAPC.

Taking a prioritized approach to HIPAA compliance is the best strategy to accurately assess your organization’s security posture, not to mention comply with HIPAA. So many healthcare organizations are unsure where to begin on their HIPAA efforts, and either give up or focus on the not-as-important to do’s. 

I want to address the methodology behind a successful HIPAA Risk Analysis and Risk Management Plan to make sure you feel prepared to tackle HIPAA at your organization. 
How to prioritize HIPAA compliance

Start Your Risk Analysis

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. Specifically, it’s a way to assess the potential vulnerabilities, threats, and risks to protected health information (PHI) at your organization. 

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

Let’s dive into the methodology of how to conduct a risk analysis the HHS would be proud of.
Looking for a risk analysis template?

Step 1: Define scope by defining protected health information flow in your environment 

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

There are four main locations to consider when defining your scope. 

Where PHI enters your environment
In the protected health information lifecycle, identify all inputs. By doing this, you can make sure to 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 with patients filling out their own information on copy paper, to business associates faxing you asking for more information about a current or former patient.

SEE ALSO: 7 HIPAA Myths and Misunderstandings, Debunked

What happens to protected health information 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, record all hardware, software, devices, systems, and data storage locations that touch PHI in any way. 

Where protected health information leaves your environment
A lot of workforce members forget they must protect PHI throughout its entire lifecycle. 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. 

Where does protected health information 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. A PHI flow diagram isn’t a requirement, but it is a lot easier to understand PHI trails when looking at a diagram.

Step 2: Identify vulnerabilities, threats, and risks to your patient data

Now that you know where PHI is stored, how PHI flows in your organization, and can better understand your scope, you have to find the problems within that scope. You must identify:
  • What vulnerabilities exist in the system, applications, processes 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 risk.
What are your vulnerabilities?
A vulnerability is a flaw in components, procedures, design, implementation, or internal controls. Vulnerabilities can be fixed.

Examples of vulnerabilities I’ve seen while conducting a HIPAA risk analysis:
  • Unpatched operating system software
  • Website coded incorrectly
  • Lack of office security policies, or failure to follow established policy
  • 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.

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
  • Well-meaning and malicious 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 vulnerabilities, threats, and risks 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 probability of a hacker exploiting this weakness.

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.
Should you get an onsite HIPAA audit? Read the pros and cons.

Analyze HIPAA risk level and potential impact
Now you’ve identified any possible security problems in your organization.
It’s time to decide what risks could and will impact patient security at your organization.Tweet: Time to decide what risks could and will impact patient security at your organization.
To analyze your risk level, you must first consider the following:
    HIPAA priority
  • 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 or Vermont could be struck by a tornado. However, the likelihood of a tornado striking Texas is much higher than Vermont. So, the Texas-based organization’s tornado risk level will be higher than Vermont. Here’s another example. Two organizations, one a large hospital group in New York City, and the other a single provider office in Utah, have remote access through the Internet without two-factor authentication and set up with a weak password. The risk is the same for both – Extremely high!
  • 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 high, medium and low. By documenting this information, you’ll have a prioritized list of all security problems at your organization. 

For more examples on how to start a HIPAA risk analysis, read this blog post.

Subscribe to SecurityMetrics Blog

Create Your Risk Management Plan

The Risk Management Plan is the compliance step that works through issues discovered in the risk analysis and provides a documented instance proving your active acknowledgement (and correction) of PHI risks and HIPAA requirements.

What should be included in a Risk Management Plan?
Although the risk analysis outcome should directly feed into a Risk Management Plan, plans should also include all HIPAA Security, Privacy, and Breach Notification requirements. For example: identification and documentation of job roles is a HIPAA requirement, but doesn't necessarily come from a risk analysis. As a general rule, including all risks and HIPAA requirements, your plan will likely have 100-200 to do’s. 

Although specific items included in a Risk Management Plan vary, here are a few industry best practices to include.  
  • Each HIPAA rule and its corresponding resolution.
  • Risk level assigned in your Risk Analysis.
  • Date completed (for both HHS documentation and your own records.) 
  • Completed by section (great for practices where two or more people are completing a Risk Management Plan together.)
  • Notes section, just in case you want to jot a reminder for later.
I also like defining my HIPAA goals in my Risk Management Plan, such as:
  • When do you want to complete your Risk Analysis?
  • When do you want to complete your Risk Management Plan?
  • When do you plan to train employees?

Identify top security measures based on top HIPAA risks
The most important part of the Risk Management Plan is planning what you’re going to do about the risks you identified in your Risk Analysis. Starting with the top-ranked risks first, identify the security measure that fixes that problem. For example, if your risk is employees throwing protected health information in the trash, your security measure could be quarterly employee security training and replacing trashcans with shredders. 

You might also be interested in: A Buyer’s Guide to HIPAA Compliance

Implement, Rinse, Repeat

After you make your plan for risk management, it’s time to implement. A prioritized HIPAA compliance plan is truly a rinse and repeat process. One of the most important parts of HIPAA is documentation. If you don’t document, you can’t prove to the HHS that you’ve performed 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.

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 Compliance To Total HIPAA Compliance
Pentesting vs Vulnerability Scanning: What’s the Difference?

Pentesting vs Vulnerability Scanning

Two very different ways to test your systems for vulnerabilities. 

Gary Glover, Dir of Security Assessment at SecurityMetrics
By: Gary Glover
Penetration testing and vulnerability scanning are often confused for the same service. The problem is, business owners purchase one when they really need the other. Let me explain how they differ.

Pentesting vs Vulnerability Scanning A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. A penetration test is an exhaustive, live examination designed to exploit weaknesses in your system. 

Let’s dive a little deeper.

What is a vulnerability scan?

Also known as vulnerability assessments, vulnerability scans assess computers, systems, and networks for security weaknesses, also known as vulnerabilities. These scans are typically automated and give a beginning look at what could possibly be exploited. 

High-quality vulnerability scans can search for over 50,000 vulnerabilities and are required as per PCI DSS, FFIEC, and GLBA mandates.
Vulnerability Scanning
Vulnerability scans can be instigated manually or on an automated basis, and will complete in as little as several minutes, to as long as several hours. 

Vulnerability scans are a passive approach to vulnerability management, because they don’t go beyond reporting on vulnerabilities that are detected. It’s up to the business owner or his/her IT staff to patch weaknesses on a prioritized basis, or confirm that a discovered vulnerability is a false positive, then rerun the scan. 

To ensure the most important vulnerabilities are being scanned for, vulnerability scans should only be conducted by a PCI Approved Scanning Vendor, or ASV. 

After scan completion, a report will generate. Typically, vulnerability scans generate an extensive list of vulnerabilities found and references for further research on the vulnerability. Some even offer directions on how to fix the problem. 

The report identifies any identified weaknesses, but sometimes includes false positives. A false positive is when a scan identifies a threat that’s not real. Sifting through real vulnerabilities and false positives can be a chore, especially if many are falsely identified.

Benefits of a vulnerability scan
  • Quick, high-level look at possible vulnerabilities
  • Very affordable (~$100 per IP, per year, depending on the scan vendor)
  • Automatic (can be automated to run weekly, monthly, quarterly, etc.)
  • Takes minutes
Limitations of a vulnerability scan
  • False positives
  • Businesses must manually check each vulnerability before testing again
  • Does not confirm that a vulnerability is possible to exploit

What is a penetration test?

A penetration test simulates a hacker attempting to get into a business system through the exploitation of vulnerabilities. Actual analysts, often called ethical hackers, try to prove that vulnerabilities can be exploited. Using methods like password cracking, buffer overflow, and SQL injection, they attempt to compromise and extract data from a network. 
Penetration Test, pentest
Penetration tests are an extremely aggressive approach to finding and removing vulnerabilities. They are also required as per PCI DSS, FFIEC, and GLBA regulations.

The cost of a penetration test is usually between $5,000 to over $70,000…but it depends on the extent of IP’s tested and the size of a web application.  Learn more about the cost of penetration testing.  

The main aspect that differentiates penetration testing from vulnerability scanning is the live human element. There is no such thing as an automated penetration test. All penetration tests are completed by very experienced, very technical, human beings.

Penetration testers are well versed in:
  • Black hat attack methodologies (e.g., remote access attacks, SQL injection)
  • Internal and external testing (i.e., perspective of someone within the network, perspective of hacker over Internet)
  • Web front-end technologies (e.g.,Javascript, HTML)
  • Web application programming languages (e.g., Python, PHP)
  • Web APIs (e.g., restful, SOAP)
  • Network technologies (e.g, firewalls, IDS)
  • Networking protocols (e.g., TCP/UDP, SSL)
  • Operating systems (e.g., Linux, Windows)
  • Scripting languages (e.g., python, pearl)
  • Testing tools (e.g., Nessus, Metasploit)
In short, penetration testers provide a deep look into the data security of an organization. 

Typically, penetration test reports are long and contain a description of attacks used, testing methodologies, and suggestions for remediation. 

Benefits of a penetration test
  • Live, manual tests mean more accurate and thorough results
  • Rules out false positives
  • Annual test, or after any significant change
Limitations of a penetration test
  • Time (1 day to 3 weeks)
  • Cost (around $4,000 to $20,000)
Subscribe to SecurityMetrics Blog!

Which is better? A vulnerability scan or penetration test?

Both tests work together to encourage optimal network security. Vulnerability scans are great weekly, monthly, or quarterly insight into your network security, while penetration tests are a very thorough way to deeply examine your network security. Yes, penetration tests are expensive, but you are paying a professional to examine every nook and cranny of your business the way a real world attacker would, to find a possibility of compromise.

I’d be happy to schedule some time to discuss a penetration test for your business.
Tweet this!Tweet: Which is better? A vulnerability scan or penetration test?
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 Things the Payments Industry Should Watch for in 2015
Business Associates and HIPAA: Who’s Really Responsible?

Either manage your business associate security, or prepare for a data breach.

Tod Ferran Security Analyst SecurityMetrics
By: Tod Ferran
With new Health Insurance Portability and Accountability Act (HIPAA) regulations in place, healthcare compliance for both covered entities and business associates (BA) is more confusing than ever. Monitoring the compliance details of every business associate seems an overwhelming task for compliance and risk managers.

Business associate agreements

HIPAA Business Associate AgreementsAccording to an analysis of breaches reported to the U.S. Department of Health and Human Services (HHS), ~30% of patient records breached have involved a business associate from 2009-2014.

That is why the HIPAA Final Omnibus Rule requires covered entities to implement or update a business associate agreement (BAA) for all relationships wherein the business associate creates, receives, maintains, or transmits electronic patient information.

Get a summary on business associate agreements in this short video.

Shared responsibility for security…and fines

In these new or revised agreements, covered entities, business associates, and subcontractors agree to share responsibility for patient data protection and breach notification. However, it’s still the primary responsibility of the covered entity to ensure protected health information (PHI) safety happens.

The HHS makes it clear that covered entities must ‘obtain satisfactory assurance’ that each BA safeguards the patient data it receives or creates on behalf of the covered entity. That means covered entities must put forth a good faith effort to assist their business associates in achieving HIPAA compliance.

Whether compromised from within your system or the system of a business associate, your organization can be liable for up to $50,000 per violation per day as a result of any breach of your patient data. And that’s just HHS penalties. That doesn’t include civil action, cost of mitigation, and loss of patient trust.

Now that HIPAA requirement stakes are raised, covered entities should do all they can to reduce risks by implementing a BA compliance program. Such a program should gauge your liability, help you locate BAs, discover what BAs do with your PHI, and help work towards compliance.

What’s your business associate plan?

It’s crucial to your reputation (and patient data security) that your BAs’ security stands firm against an attack. Your business associate plan should evaluate all existing BA security practices in order to help you address the riskiest vendors first. Then, risk and compliance managers would do well to design, implement, and monitor a mass risk evaluation of business associate networks.

SEE ALSO: You Can’t Hide Behind a Business Associate Agreement

Subscribe to

A plan that starts with the highest risk BAs and tracks related progress will help you prove your good faith efforts to address BA compliance if the HHS decides to audit your organization.

Prioritize your riskiest business associates

According to recent Privacy Rights Clearinghouse data, reported medical data breaches occur every 4 days on average, with more than 5,000 records per breach. How many breaches could be avoided through a contractual expectation of basic business associate compliance?

The first step in your action plan should identify all parties (business associates and subcontractors) that must become HIPAA compliant. After pinpointing responsible individuals within each party, it’s time to begin eating the BA compliance elephant.

This can be accomplished through a simple survey that classifies business associates per their use of electronic PHI data. Determine how much liability each BA holds by asking a set of risk-evaluating questions such as:
    HIPAA Business Associate Security
  • Is the BA internal system connected to the Internet? If yes, are those external IPs scanned for vulnerabilities?
  • How does the BA obtain protected health care data from you and what data is received?
  • What is the quantity of the data received?
  • How is the data stored, protected, backed up and destroyed by the BA?
After this quick risk snapshot you will clearly be able to categorize individual risk levels that determine which BAs put your patient data at highest risk. Based on the risk ranking from the preliminary risk analysis, you can then start to customize compliance measures to enable BA HIPAA compliance.

What’s your risk status?

The HHS states that “doing a thorough and professional risk analysis that will stand up to a compliance review will require expert knowledge that could be obtained through services of an experienced outside professional.”

Ask your BAs for proof that they’ve completed a risk analysis. If not, recommend a trusted source to help.

SEE ALSO: How to Start a Risk Analysis

It’s also important your BAs are up to date with their risk management plans and working towards compliance.

Put your foot down with business associate security

Many large covered entities are concerned their business associates will financially take advantage of them if forced to sign new agreements. Not willing to rock the boat, these entities intentionally ignore HIPAA regulations. That’s what the HHS calls ‘willful neglect’, and each violation is punishable with fines of up to $1.5 million.

Simply writing a separate BA agreement or agreement addendum that amends or supersedes the previous agreement will solve this common problem. Updated business associate agreements should specify the BA’s shared responsibility for proper use of data, breaches, misuse, and/or noncompliance.
Remember that HIPAA regulations require you to take action if you know or believe one of your BAs are not HIPAA compliant. This means either assisting the BA with correcting the issues, or terminating the relationship.Tweet: If one of your business associates isn't HIPAA compliant, either fix issues or terminate the relationship.

Track your business associates

As your business associates progress towards compliance, track their success to ensure an approved level of compliance. As the riskiest BAs reach compliance, begin to reach out toward medium-risk BAs to start the process with them. Don’t forget to reevaluate every BA’s plan and associated vulnerabilities each year.

Keeping business associates in touch with updated HIPAA requirements and data protection is a crucial part of monitoring BA compliance. Encourage continual education and training programs such as regular HIPAA security webinars or even an email newsletter. These friendly ways of reminding them about their obligation to PHI protection also keep you in the loop.

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.

How to Leverage HIPAA for Meaningful Use Ebook

10 PCI Security Standards Myths

The underlying security principles of PCI are alive and well.

Brand Barney, HCISPP, CISSP, QSA
By: Brand Barney
10 PCI security standard mythsThere is a lot of great information about PCI out there. But there are also a lot of misconceptions. Here are the 10 worst myths I’ve heard about PCI compliance. 

Myth 1. I’m already PCI compliant because my _______ says I am.

I hear versions of this myth every single day.
  • My hosting provider is PCI compliant, so my site is compliant.
  • I outsource my credit card processing, so I’m compliant.
  • My point-of-sale device says it’s PCI compliant, so I’m compliant.
  • My merchant services provider does my PCI for me.
  • My IT guys says I’m PCI compliant.
  • My network is PCI compliant. 
  • I use PA-DSS tools, so I’m PCI compliant.
Don’t believe everything you’re told. Just because a vendor says (or product packing claims) you, or the product you use, is PCI compliant, doesn’t mean it’s true.

SEE ALSO: 7 Questions to Ask Your POS Installer

Many don’t understand that PCI compliance applies to organizations, not just the tools or services the organization employs. Yes, the tools you use should have the capability of being PCI compliant (e.g. your hosting provider should provide an environment that's capable of being PCI compliant), but having compliant tools in and of themselves won’t make you compliant.

Besides your PCI compliance vendor, the only entity truly able to determine your PCI compliance is you. 


Myth 2. We don’t need to worry about PCI compliance because _______.

Many are under the impression that PCI simply doesn’t apply to them. Here are a few common examples:
  • We only take a few credit cards a year.
  • We’re too small.
  • We’re exempt from PCI.
  • We’re a university.
  • We outsource.
  • We are HIPAA compliant.
  • Our IT team is worrying about our PCI compliance.
  • We’re a non-profit.
  • We already completed an SAQ, so we’re compliant. 
  • We already had a penetration/vulnerability scan, so we’re compliant.
These excuses are rubbish, and won’t exempt you from fines if you are breached, or found by the PCI Council to be non-compliant. 

PCI applies to you if you “accept, capture, store, transmit, or process credit and debit card data.” Period. It doesn’t matter your business size, type, or how many transactions you process per year. The only thing that could exempt you from PCI compliance is if you take ONLY cash (and you never have or never will take credit, or debit cards.)

Myth 3. PCI is irrelevant. Just look at all the breaches happening lately! 

PCI DSS security practices aren’t the ceiling of your security, they’re the floor. The requirements determined by the PCI DSS are the fundamental basics of security! 

Besides, many of the big breaches in the last few years occurred because the organization wasn’t fulfilling their PCI compliance requirements. Even if they were “certified” as PCI compliant, the vulnerabilities that lead to their breach could (and should) have been addressed with PCI compliance. Like Target, for example. 

Target didn’t segment their card data environment properly, which is considered a basic security principle, especially for a large organization. Target’s cardholder data network was on the same network as their HVAC systems. Hackers got hold of the HVAC system password, got access to the entire network (including cardholder data), and the rest is history.

Myth 4. If I get breached, it doesn’t really matter

Many hear about companies that get breached, but continue to stay in business, and wonder why they should worry about PCI compliance. 

Before you discount PCI, think of the fines, lawsuits, breach disclosure costs, investigation costs, credit card rate increases, credit monitoring, etc, that results after a data breach. If a business stays in business after a data breach, I guarantee they didn’t walk away without some serious financial suffering and brand degradation. 

Target announced that they expect a $148 million loss from their 2013 data breach. In 2015, Target settled their class-action lawsuit for $10 million.

Let me breach down the cost of a data breach:
  • Merchant processor compromise fine: $5,000 – $50,000
  • Forensic investigation: $12,000 – $100,000
  • Onsite QSA assessments following the breach: $20,000 – $100,000
  • Free credit monitoring for affected individuals: $10-$30/card
  • Card re-issuance penalties: $3 – $10 per card
  • Lawyer fees: $5,000+
  • Breach notification costs: $1,000+
  • Technology repairs: $2,000+
  • An increase in monthly card processing fees: +
  • Federal/municipal fines: +
  • Legal fines: +
If you also lose healthcare information in a breach:
  • HHS fines: up to $1.5 million/violation/year
  • Federal Trade Commission fines: $16,000/violation
  • Class action lawsuits: $1,000/record
  • State attorney generals: $150,000 – $6.8 million
  • Patient loss: 40%
As I’m sure you can see by this list, most businesses can’t survive a data breach.

Myth 5. Once I’m PCI compliant, I’m good! 

PCI is not a moment in time. Your PCI DSS compliance does not end when your QSA leaves your office or your SAQ is submitted. Not only are you required to assess your compliance each year, you are required to maintain PCI compliance every second of every day.

SEE ALSO: PCI Compliance Maintenance – You’re Not Done Yet

Myth 6. If I’m PCI compliant, I’m protected from hackers.

For many organizations PCI compliance gets treated like a one time event (see Myth 5.). In truth, businesses must stop thinking of compliance as a giant checklist. Your business, your systems, and your employees all have weaknesses and vulnerabilities that have to be treated with a healthy on-going security mind-set. 

For example, you need to run vulnerability scans quarterly and each time you make changes to your network. You should also be scanning your systems for unencrypted credit card data, and removing it or properly protecting it. 

These are just a few basic examples. PCI does protect your organization from hackers if you maintain real security, but being “attested” or “certified” as compliant won’t save you.

Myth 7. I’ll just outsource PCI and never worry about compliance. 

While you can hire third parties to help you with compliance, it’s still your responsibility to become PCI compliant. The merchant always holds the responsibility for PCI compliance, especially if they are hacked. 

Even if you use a PCI compliance vendor like SecurityMetrics, you are still in charge of making sure security requirements are put into practice at your organization.

SEE ALSO: Free PCI Compliance Demo

Myth 8. PCI is so easy! All we have to do is say yes!

PCI compliance isn’t just saying yes to all the Self-Assessment Questionnaire questions, even though I strongly suspect many merchants apply this method when going through PCI compliance. You must do all the requirements in PCI, take the SAQ, scan your systems (if appropriate) and be able to prove it!

If your SAQ asks if you have a firewall in place with inbound and outbound traffic restricted to only that which is necessary for the cardholder data environment; are you just answering yes, or is your firewall configured to actually restrict the appropriate traffic?

Anyone can fill out their SAQ with "yes" checkboxes, but that won't actually make them compliant unless they’re actually doing everything they’ve checked "yes" to. Lying by checking “yes” when you know you’re compliant can open you to penalties, including loss of credit card privileges. 

Myth 9. I passed my vulnerability scan, so I’m compliant.

PCI compliance is more than an SAQ or vulnerability scan(s). Depending on your organization and the way you process credit cards, you may be required to attest to more or less PCI requirements.

Myth 10. PCI is too hard and confusing.

Yes, PCI is hard, but not too hard. PCI is basic common sense baseline security. If PCI was easy, it wouldn’t be doing anything to protect you from malicious attackers looking to steal your credit card data. 

If you find the PCI requirements too difficult to understand, hire an IT and security professional to help you, or consult with your PCI security vendor. 
Share these 10 PCI Myths!Tweet: 10 PCI DSS Myths:


Whining is much easier than securing. That’s why these myths are so popular. It’s easier to make excuses than actually start securing your data. Your goal and mindset shouldn’t be “passing PCI compliance with as little work as possible.” It should be “being secure through PCI compliance, whatever it takes.”

Brand Barney (CISSP, HCISPP, QSA) is a Security Analyst at SecurityMetrics, has over 10 years of data security experience, and will totally geek out if you mention Doctor Who. Brand loves to play jazz piano and daydreams about being as great as Dave Brubeck or Thelonious Monk. Connect with him on Twitter or check out his other blog posts.

5 Things the Payments Industry Should Watch for in 2015