Pentesting vs Vulnerability Scanning: What’s the Difference?

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. And, business owners sometimes purchase one when they really need the other. 

A vulnerability scan is an automated, high-level test that looks for and potential vulnerabilities. A penetration test is an exhaustive, live examination designed to exploit weaknesses in your system.  Both types of testing can be performed on systems exposed to the Internet or only exposed on your internal network.

This post will dive deeper into the differences between the two tests.

What is a vulnerability scan?

pentest, pen testing, penetration test, vulnerability scanAlso known as vulnerability assessments, vulnerability scans assess computers, systems, and networks for security weaknesses. These scans are typically automated and give a first look into what vulnerabilities are present and could possibly be exploited.

High-quality vulnerability scans can search for over 50,000 vulnerabilities and are required by some cyber security mandates (PCI DSS, FFIEC, and GLBA, etc.) but regardless of requirements, this type of scanning is a mainstay of cybersecurity threat prevention for any company wanting to protect their digital data.

Vulnerability scans can be instigated manually or scheduled on an automated basis, and will complete in as little as several minutes, to as long as several hours.  These scans should be conducted at a minimum on all systems exposed to the Internet (for example, web servers, mail servers, etc. living in a DMZ).  To be thorough they should also be conducted on all systems exposed on your internal network to detect vulnerabilities that could be exploited by data thieves if they happen to get past your edge defenses.

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 be conducted by a skilled team or well-known vulnerability scanning company. In the case of PCI DSS compliance you must use a PCI Approved Scanning Vendor, or ASV.

See Also: Spotting Vulnerabilities – Is Vulnerability Scanning Antiquated?

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
See Also: Picking Your Vulnerability Scanner: The Questions You Should Ask

What is a penetration test?

pentesting, pen test, penetration test, vulnerability scanA 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.
Follow for more data security articles like this

Penetration testing of both external and internal systems is a very effective approach to finding vulnerabilities that need to be removed and is considered an essential element of any good security program. This type of testing is required as per PCI DSS, FFIEC, and GLBA regulations.

The cost of a penetration test can run between $5,000 to over $70,000, but it depends on how many IPs are tested and the size of tested web applications. 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. True penetration tests are conducted by real people.

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 and detailed look into the data security of an organization.

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

Benefits of a penetration test
  • Live, manual tests mean more accurate and thorough results
  • Rules out false positives
  • Usually performed annually or after a significant change
Limitations of a penetration test
  • Time (1 day to 3 weeks)
  • Cost ($5,000 to $70,000)

Which is better? A vulnerability scan or penetration test?

Both tests work together to validate optimal network security. Vulnerability scans are for weekly, monthly, or quarterly insight into your network security, while penetration tests are a more 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.

The difference is comparable to that between a fuzzy x-ray image and a clear, 3-D MRI. X-rays are great for small, quick problems (V/A scan) but an MRI (PenTest) is needed for deeper, more complicated problems. Get an MRI for your network.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Senior Vice President of Assessments at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Trek quoting skills. Live long and prosper as you visit his other blog posts.

PCI vs. GDPR: What’s the Difference?

Learn the important differences between the two security standards.

Jonas De Oliveira
If you are a merchant and already deal with PCI compliance, you’ve probably heard about the recently implemented EU mandate: General Data Protection Regulation (GDPR). You may be wondering: Does the GDPR apply to me if I only take credit cards? If I comply with PCI DSS, does that make me GDPR compliant? Do GDPR and PCI DSS do the same thing?

Remember that the GDPR applies to any organization that processes or holds the personal data of persons residing in the European Union, whether or not the organization itself is located in the EU. It applies to data processors and controllers.

PCI, GDPR, PCI complianceLearn about data processors and controllers in our GDPR blog series: Part 1, Part 2, Part 3.

The PCI Data Security Standard (DSS) applies to organizations that handle credit cards from the major card brands. Both are mandates that contain best practices for securing personal data and protecting the privacy of individuals.

Here are some of the main differences between PCI DSS and GDPR:

1. Scope of relevant data

First, one of the most important aspects to understand about PCI and GDPR is scope. Because GDPR encompasses all personally identifiable data (PII) of persons in the EU, its scope is much, much larger than the PCI DSS. Compared to GDPR, the PCI DSS applies to a very small subset of data: cardholder data. Cardholder data--while still considered PII--is a small portion of all the personal data covered by the GDPR.

So, if all you take is credit cards, but some of those credit cards are of EU citizens, then yes—the GDPR applies to you. With all the types and subsets of EU citizen personal data, it’s likely that your business may store, transmit, or process some GDPR-relevant data.

Follow for more data security articles like this

The graph below illustrates the difference between the PCI DSS scope and the GDPR scope.

2. The processes covered by PCI DSS and GDPR

The PCI DSS is intended to prevent merchant data breaches and protect cardholders, customers, and the payment ecosystem. To do so, it is used to regulate the storage, processing, and transmission of cardholder data.

Compare that to the GDPR, which aims to protect individual data subject rights by regulating the processing of personally identifiable information in a much broader sense, not just the actual charging of a payment card. The GDPR defines processing as “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction,” article 4, paragraph 2.

Where PCI DSS is concerned with a few major data elements, GDPR is concerned with any non-personal use of personal information.


3. Security vs. Privacy

At the heart of GDPR is the duty to protect the privacy of data subjects by preventing misuse, theft, or unlawful disclosure of their sensitive personal data. GDPR puts the individual in charge of their own data and grants them specific, legal rights to protect and control it. GDPR requires that organizations provide persons in the EU the means to exercise those rights.

At the heart of the PCI DSS is a duty to protect cardholder data from hackers and cybercriminals and keep the entire payments ecosystem safe. This data security standard, first put forth by major card brands in 2006, is concerned with the day-to-day practices of data security: firewall management, encryption, anti-virus, and the like.

The following table outlines more of the important differences between GDPR and PCI:


If you have questions about GDPR, PCI compliance, HIPAA, or general data security, please contact us here.

Jonas De Oliveira is a Security Analyst for SecurityMetrics. He holds CISSP, QSA, CPA and CISA certifications. Jonas has over 12 years’ experience in the data security industry. In addition to assessing companies’ level of PCI compliance, Jonas has been integral in assisting clients prepare to demonstrate GDPR compliance. He graduated with a master’s from University of Utah in accounting with an emphasis in information systems.

Network Diagrams: Key to Compliance and Security

Three tips for PCI compliance network documentation.

Nathan Cooper, CISSP
If you were to ask network architects and engineers about their favorite part of the job, I doubt any of them will respond with “creating and maintaining network documentation.” It’s not the most glamorous task—yet requirements 1.1.2 and 1.1.3 of the Payment Card Industry Data Security Standard (PCI DSS), along with general good security hygiene, render it a necessary one.

Part of this requirement involves creating network infrastructure and data-flow diagrams related to the Cardholder Data Environment (CDE). Although the diagramming process can be tedious and time-consuming—preventing many companies from diagramming at all, much less taking adequate time to make diagrams accurate and keep them up to date—you can’t overstate the importance of network documentation. Accurate documentation leads to accurate scoping and an assurance, for both your company and your QSA, that your network has been set up securely.

Follow these three tips to keep your network well-documented, in turn making your life and your QSA’s life easier.

SEE ALSO: IT Checklists for PCI Compliance 

1. Find a program to streamline the process

If you found yourself nodding in agreement as we mentioned the tedium of network documentation, you need to find a program that removes at least some of the hassle. Solutions like Lucidchart or Visio can simplify the diagramming process greatly.
network diagram, data flow diagram, pci compliance
For example, Lucidchart has created shape libraries specific to many different network types, including Cisco networks, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and general network infrastructure. Instead of tracking down or drawing crude sketches of network shapes, you have professional stencils representing a wide variety of network components, reducing the overall time it takes to build an accurate and professional-looking network diagram.

Lucidchart’s platform also offers an AWS architecture import. Users can simply enter their AWS credentials or run a bash script to import data and automatically generate a completed AWS diagram. Internally, this feature has saved us thousands of dollars a year in assessments and compliance.

This makes it easier to keep your documentation up to date because you simply add new components, lines, or segments whenever you add them to your network.


2. Create a single source of truth

In an ideal world, only one person would be responsible for keeping a given piece of documentation up to date and accurate. However, multiple people are typically involved with maintaining network infrastructure, handling card data, and completing other work that affects your PCI compliance. As a result, numerous (and conflicting) versions of the same documentation are commonly found in emails, network shares, and individual machines, making it difficult to nail down the most recent and complete document.

Maintain a single source of truth—with permission-based controls for viewing, commenting, and editing—so you can easily share documentation as you gather input and make changes to your infrastructure.

Selecting the right diagramming solution can help you collaborate more effectively with others and manage storage and version control of your network documentation in a secure, accessible way. Whichever platform you choose should include access rights and revision history, so you can limit access to authoritative documents, see who changed what, access previous diagrams to correct errors, and get a historical view of the system.

As you create this collaborative network documentation workspace, keep in mind that you can leverage the network documentation for more than just evidence of PCI compliance—you can create diagrams with different levels of complexity to share externally with your vendors, customers, partners, etc.

Follow for more data security articles like this

3. Review and update documentation quarterly or after any infrastructure changes

Businesses constantly evolve, scale, and look to become more efficient. These efforts often bleed into the way business networks are set up and the different methods companies use to accept, process, and store credit cards. For example, many companies have moved their network infrastructure into the cloud using services like AWS, Azure, and GCP to better accommodate fluctuating bandwidth demands, offload system maintenance, and transfer the compliance burden.

Once you’ve created your initial network documentation, review and update your diagrams when changes are made to ensure that your document reflects an accurate representation of your current network and business processes. This practice will keep you aware of potential network security vulnerabilities and provide the required documented information your auditor will need in order to validate your PCI compliance during your next assessment.

Network documentation will always be necessary—but it doesn’t have to be a necessary evil. With these tips, you can streamline the process for creating professional diagrams that meet compliance and help you manage your network through growth and change.

Lucidchart allows users to build high-quality network infrastructure and data-flow diagrams related to the Cardholder Data Environment (CDE). These diagrams help to define and visualize the entire PCI DSS scope or the CDE. If your business uses Amazon Web Services (AWS) for your network infrastructure, see how our company saved nearly 12 hours while documenting our network.

Nathan Cooper has been working to protect Lucid and Lucid's customers since he joined the team in 2015. He obtained his Masters of Information Systems Management from Brigham Young University and is a current Certified Information Systems Security Professional (CISSP).

5 Tips to Improve HIPAA Compliance in 2018

The state of HIPAA security this year, plus tips to focus your efforts.

Brand Barney

What’s new in HIPAA in 2018?

In general, organizations don’t seem to be keeping up with mounting vulnerabilities. Breaches have increased in frequency, and I anticipate that next year the number of breaches and penalties assessed in healthcare will continue to increase.

Hackers have wised up to the lack of compliance and the lack of security in the healthcare industry. They utilize gaps to attack healthcare organizations and hurt their systems. The FBI has reported an increase in discovered and reported attacks against all organizations, with 83% of ransomware attacks against healthcare.

We’ve all heard of ransomware, where hackers encrypt organizations’ systems and then demand large ransoms of bitcoin in exchange for the decryption of their data. As we look forward to more ransomware this year, we want to make sure to talk about how these types of breaches occur.

SecurityMetrics HIPAA Compliance Research

We surveyed HIPAA officials about their patient data and patient security. These officials were primarily from organizations with 0-500 employees. It’s important to remember that whether you’re a mom-and-pop practice or a large covered entity—big or small—hackers want your data. It’s not just the big targets that experience breaches.

According to our data, at least 20% of respondents report that their organizations do not encrypt stored protected health information (PHI). This fact, coupled with the prevalence of malware and hacking, presents a major threat to the healthcare industry and business associates.

If you’re thinking, “well we encrypt our data, so we’re protected,” the question is, are you encrypting ALL your data: flat files, spreadsheets stored locally or on network shares, USB thumb drives, and data being transmitted? Make sure any stored electronic PHI (ePHI) is protected using AES-256 (or other industry accepted/strong) encryption and any data in transit is moved on an encrypted connection (HTTPS, TLS, etc.)

Top Organizational Vulnerabilities

Interestingly enough, the vulnerabilities we’re seeing this year are the same ones we saw last year. Hackers all always advancing, but they will continue to attack and take data with proven methods for as long as they work.

Currently, the biggest issues we see are:

  • Insecure remote access: Make sure you use multi-factor authentication. The long-trusted combination of username and password (and too often passwords are weak, e.g., 123456) will no longer suffice to protect all of your data. You need to make sure that you have a strong and unique username and password combined with other accepted and secure factors. An example of this would be if your privileged access login requested two or more factors (e.g., it asked for username and password/PIN, and then prompted you to enter a security token, One Time Password token, or some other accepted factor). Failure to properly secure all of your remote access is one of the main reasons for breaches today.

  • Employees: The “human element” can be a big problem, and quite honestly, may always remain a large problem in the healthcare industry. In my experience, employees are almost always trying their best—but if they’re not properly trained, they won’t know any better and might open a phishing email or click on a malicious link. Training your employees properly and frequently will pay dividends when your employees stop an attacker or malware dead in their tracks.

  • BYOD policies: When we think of a bring your own device (BYOD) policy, we might think of privately owned cell phones brought into a sensitive network, but there’s more to it than that. It includes the devices used at a company: work laptops and work phones--that go home and are connected to home networks or airport Wi-Fi--and then are brought back to your sensitive data environment. We see devices stolen which had no disk encryption. Remember all of your PHI and ePHI needs to be properly encrypted. 

  • Third parties: Some of you reading this are likely a third-party. Maybe you’re a business associate performing a duty like development, platform as a service, infrastructure as a service, billing, or something like that. We see a lot of vulnerabilities coming through third parties. As a third-party, you need to make sure security and compliance is a top priority as it will directly affect the growth of your business. Doing business with a business associate is often necessary to provide proper care to patients, but it is not without risks. I work with many vendors who diligently take care to ensure all patient data they access or are provided is secure, and that they are compliant. However, this is not the case for all business associates in the industry. It’s important to remember that you should engage business associates with proper due diligence. Make sure that all BAAs are in place and obtain assurances that your data and systems will be secure and compliant when shared or accessed by any third party.

HIPAA data security updates

I don’t see HIPAA compliance requirements as a whole changing drastically anytime soon. Not to be confused with the healthcare industry, HIPAA itself hasn’t really changed much from year to year.

In the cybersecurity realm, we did see new clarification from NIST  regarding what are considered strong passwords or passphrases. OWASP re-released their updated top 10 most critical web application security risks of 2017. Keep in mind that it has been re-released, but that it hasn’t changed all that much. Since far too many businesses and vendors haven’t drastically improved their security, most attackers are using the same methods they have in years past.

Issues with a compliance mentality

Far too many entities are just “check listing” their compliance efforts (this is not unique to the healthcare industry)—which will continue to lead to data breaches. It’s easy to think of attackers as part of an extensive and organized network, or even as nation states--and certainly those things exist. But, the source of a data breach at your organization could be as simple as your own employees or patients accessing a system or application on your unsecured Wi-Fi.

Negligence of security can lead to:

  • Unauthorized use or disclosure of PHI (i.e., loss of data).

  • Patient harm (loss of data, physical/emotional harm), especially if it has to do with sensitive medical information (mental health, drug use, etc.).

  • Network medical device loss of integrity. As technology advances, we’ll see more devices affected and the possibility of harm to patients (physical or emotional).

These types of problems are going to continue to happen until we make a big shift into real security and not just checking boxes.

5 tips to improve HIPAA compliance in 2018

1. Focus on policies and procedures 
We often see that entities have completed some portion of their policies and procedures—usually their privacy policies. We also see policies and procedures that are just a few pages in total, if they exist at all. Of course, not all policies and procedures are going to apply to every employee, however, a 2- or 3-page document will not be enough.

Also remember that your policies and procedures document is not just a paperweight. You may have sufficient documentation, but if you need to find information about your firewalls or about authorized uses and disclosures, and your document isn’t usable, it’s not going to do you or your employees a lot of good.

If your organization receives a complaint or has a breach, the first thing HHS and OCR will likely ask to see is your complete policies and procedures. If you don’t have sufficient policies and procedures in place, it’s likely to lead to further investigation into your organization and compliance.

Think about implementation: where are the gaps in your policies and procedures? Do you use a cloud vendor? Do you have policies and procedures for your firewall and router configurations? For encryption of data at rest and data in transit?

Are your staff trained in the policies and procedures that apply to them? If not, it’s time to get our documentation in order and then train your staff on them. It’s not uncommon for me to go into an organization and ask employees to show me where their policies and procedures are, and they can’t find them.

Lastly, you need to regularly update your policies and procedures. As your organization changes, your roadmap (i.e., policies and procedures) should adapt and change with it. Your policies and procedures shouldn’t be an afterthought. They are there to help you and your staff ensure proper security and compliance in your organization and for your patients.

SEE ALSO: HIPAA Security Policy Free Download

2. Incident response plan
Even if you haven’t been breached yet, it’s likely you will at some point: whether it’s a small incidental breach or a major event where the contents of your database have been exfiltrated outside of your network. The size and severity will vary depending on the amount of time and resources you’ve put into your security. But, regardless of the size of the breach, if you haven’t prepared for the aftermath, it’s going to be significantly more painful and expensive.

First, you need to document your incident response plan, (and do so before a breach, rather than after). Second, you need use the incident response plan to minimize potential impact. This will help you to reduce fines and any negative effects on your business and customers. Make sure you’re identifying all the potential risk and vulnerabilities. This can be done through a risk analysis.

It’s not uncommon for health organizations to engage a third-party service provider to contain and respond to the breach. The use of that third party needs to be documented in your plan.

You will need to set up a breach response team and make sure they understand their responsibilities. Make sure you have a team leader, scribe, timeline leader, and HR or legal representatives. Oftentimes people wrongly assume a person or group knows their responsibilities related to a data breach. If they aren’t included in incident response planning and training, there’s no way for them to know their responsibilities.

Sell the incident response plan to your executives. Whatever you do after a breach will greatly affect the fines and bad press your practice could face.

Finally, you need to test your incident response plan. Start by performing tabletop exercises at least once a year. Doing so will not only keep you in compliance, but it will also help you find gaps in your plan. Whether your incident response team has twenty people or two, you need to test the plan for efficacy and communication. Bring up all aspects and details, like how physicians will communicate with communicate to IT, HR, and legal, and how legal will communicate with the courts. Document what you learn during your tabletop exercises—I’ve never seen an incident response exercise where someone didn’t learn something new to help improve security and protect privacy.

SEE ALSO: 6 Steps to Making an Incident Response Plan

3. Risk analysis
If you haven’t done a risk analysis, get started on one today. A risk analysis is the identification of the risks, threats, and vulnerabilities to your organization. Those risks, threats, and vulnerabilities can be digital or physical, internal or external, negligent or willful. A risk analysis takes into account your systems, as well as the human and environmental elements which affect your organization.

  • Risk: The potential for a threat to exploit a vulnerability and the loss, damage, or destruction it would cause. 

  • Threat: Anything that could exploit a vulnerability, whether intentionally or unintentionally. 

  • Vulnerability: A weakness, flaw, or security gap in an environment. 

If you have done a risk analysis, you should review and update it at least annually. Significant events, like mergers or acquisitions, would also affect your risk analysis, so you’d need to review and update yours at that time.

To start on a risk analysis, you need to first understand where your PHI is stored, received, maintained, and transmitted. If you don’t understand which systems are touching PHI and how they interact with it, it’s going to be incredibly challenging, if not impossible, to identify risks, threats, and vulnerabilities in a thorough and accurate manner.

SEE ALSO: How to Start a HIPAA Risk Analysis

It is not uncommon for organizations to use tools like vulnerability scans (internal and external), penetration tests (internal and external), and virus scanning, to assist in the identification of some of the many risks and vulnerabilities in your PHI/ePHI environment. However, these tools are not the only component to your risk analysis. It’s important to consider the physical, administrative, and technical risks, threats, and vulnerabilities that may be present in your organization. It’s your responsibility to make sure that the accurate and thorough identification of all potential risks, threats and vulnerabilities is performed. There is no shame in seeking the help of an experienced third-party service provider to simplify this process and help close any gaps you may have in experience.

Don’t forget to to interview employees during this process. Your employees have valuable insights into how they interact with your systems and sensitive data. You might believe that staff are doing things one way, only to discover that they don’t because they found a better way. Here are a few questions you might ask in this process: How do employees interact with patients and PHI/ePHI? Who has access to what data? What are the policies and procedures around access and data usage. Where do they send data, and how is that transmission performed? What do your employees do when a process or technology isn’t working? Do they find a new, creative way of interacting with that PHI/ePHI?

Whatever you do, do not delay in your risk mitigation. Properly addressing risks will require time and resources, but know that the risks, threats and vulnerabilities in your organization will not address themselves, and hackers are always looking for access to your systems and data.

4. Train staff properly
Training can’t be emphasized enough. Your staff can either be your greatest asset or your greatest vulnerability.

Training staff just at the time of hire is not sufficient. You need to hold monthly meetings where you review the Security, Privacy, and Breach Notification Rules. All staff should be included: nurses, doctors, receptionists, assistants, developers, system administrators, network administrators, etc. Each job role will experience different issues.

Make trainings fun. If you include games or food, staff will be more likely to engage with and retain the information presented. Here are some example training topics: acceptable uses and disclosures of PHI, social media compliance, phishing, social engineering, and physical security.

You should also test staff: quiz them and give them reviews. Find out if your trainings are effective. You could even hire someone to perform an email phishing tests on your staff to determine if your training is working in a real-world situation. Security should be first of mind. If your staff introduces security risks due to ignorance, it is highly likely that they will think it’s acceptable for future situations and you will remain vulnerable.

5. Security best practices
We are constantly looking at how to best bulk up security and protect data. We sat down with our forensic team to find out the top vulnerabilities that allow attackers to break into systems. These are the most common areas with which they noted security concerns:

  • Logging

  • Encryption

  • Intrusion Detection/Prevention System (IDS/IPS)

  • File Integrity Monitoring (FIM)

  • Edge Firewall Security

    • External Vulnerability Scan

  • Remote Access Security

Keep in mind the many tools and services available to help you test your systems and protect PHI:

  • Wireless Network Security

  • Web Application Security

  • Physical Security

  • Penetration Testing

  • System Hardening

  • System Patching

  • Internal Vulnerability Scan

A less technical, but just-as-important, aspect of security, is encouraging the right kind of culture. Many companies do not maintain a good and ubiquitous security culture. Management in these organizations may be touting that they have an awesome security culture, but in reality their security culture, or lack thereof, is causing their patient data many risks, threats, and vulnerabilities. It is not uncommon see healthcare companies pour time and money into systems or outside assistance, but then fail to protect or maintain those systems, because it just isn’t a priority internally. In those cases, their efforts are more like a Band-Aid.

Also understand that security comes from the top down, not vice versa. If security is not handled with a top-down approach, things can get frustrating for staff members. Many times, employees will even leave an organization if it doesn’t seem to care about security.

Security does not have to be overly challenging. Create an environment where employees aren’t afraid to report suspicious behavior or anything that could be a security problem. A great security culture will facilitate openness and empower employees to bring up the security issues you need to know about.

Live and breathe security

To better protect yourself and your organization, you should live and breathe security. Make compliance and security year-long practices. HIPAA compliance is often treated as a “single-point-in-time” event, but in reality, security and compliance are never ending. That fact on its own can be enough to make you want to throw your hands up and call it quits, but don’t. Your patients rely on you to protect their sensitive information. It’s up to you to make sure that your organization has complete and secure processes in place.

Also remember that healthcare workers are busy, and their main concern is taking care of patients. If you conduct a thorough, annual risk analysis, (as well as anytime there is a big change in your processes or in your PHI/ePHI environment), you can feel better knowing about the vulnerabilities working from an action plan.

We’ve only listed 5 tips in this blog post, but there are so many excellent processes and tools you can implement to help safeguard your patient data. And you don’t have to do it alone: get your organization on board and engage a third party if you need to.

If you are interested in a HIPAA audit, or would like to learn more about HIPAA, PCI, GDPR, or data security, please contact us here.

Brand Barney (CISSP, HCISPP, QSA) is Senior HIPAA 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.

IT Checklists for PCI Compliance

Detailed checklists for teams working on PCI compliance.

We created our PCI Guide to help businesses get compliant with PCI standards and avoid data breaches. While C-level executives and compliance officers may oversee a PCI compliance program at the highest levels, it’s the IT managers and teams who are tasked with the day-to-day details of what “compliance” really means.

That’s why we include PCI Guide IT checklists to go along with each PCI DSS requirement.

IT pros keep businesses running: they often manage networks, field support requests, give trainings, oversee deployments, and serve as database admins—all in the course of a day. Data security and compliance are added responsibilities on top of maintaining basic business operations, so separate and thorough tracking methods can help make the entire organization more secure. 

Download our PCI Compliance IT Checklists here.

Information technology team management

IT pros have told us that they love our PCI guides specifically for the checklists. They use them to PCI Report on Compliance (ROC) or prepare for a PCI audit. The lists provide a starting point and help keep teams and individuals on task.
manage everyday security tasks, as well as to fill out their

Some IT departments print off the checklists for every member of their team to make sure no one is missing anything.

SEE ALSO: The 12 Requirements of PCI DSS

Interactive PCI compliance checklists

There are twelve lists—one to cover each requirement—and within each are interactive fields and checklists. Managers and team members can enter to whom the requirement list is assigned, its assigned completion date, and actual completion date.

As interactive PDFs, the checklists can be checked and unchecked. So, teams can keep track of progress on the PDF versions, or just print them out and take them on the go. This feature also doubles as a way to easily document general PCI compliance efforts at your organization.

INFOGRAPHIC: 2017 Data Breaches

IT data security tasks

These lists are based specifically on PCI DSS requirements, and they are designed to help managers make sure that even the smallest tasks are covered. Each list includes subsets of “things you will need to have,” “things you will need to do,” and “things you may need to do.”

 We reference the specific PCI DSS requirement that goes with each task. For instance, on the checklist for “Requirement 4: Transmitting Cardholder Data,” we match up tasks with their specific requirement found in the PCI DSS: 4.2b, 4.1, 4.1.1, etc.

The SecurityMetrics Guide to PCI DSS Compliance

For even more information and tips about PCI DSS compliance, check out our PCI guide. Our 2018 version includes the interactive checklists as well as PCI auditor insights, forensic data breach statistics, and more in-depth information on each of the requirements.

SEE ALSO: Top 5 PCI Blog Posts for SMBs

The SecurityMetrics PCI Guide protects businesses

We help businesses avoid data breaches because for us, data security is personal. Our CEO Brad Caldwell founded SecurityMetrics in 2000, two years after a data breach at his small business left him without affordable options for remediation.

We create content like our PCI Guide and Checklists to help businesses protect themselves from hackers and cybercriminals who want to steal data or collect ransoms.

If you'd like to learn more about PCI compliance or are interested in a PCI audit or HIPAA audit, contact us here.