SecurityMetrics Blog

Cloud Security: What Businesses Need to Know

2018-07-17T15:16:00.001-07:00

Top Cloud Security Controls Organizations Should Be Using.

Adnan Raja

Because securing data within the Cloud is complex, having a standard set of protective controls is pivotal to keep your customers safe and avoid expensive data breaches.

In this post, we’ll review an incident from last year to demonstrate the breadth of controls that should be established, as well as the difficult position in which any security event can place you. Reviewing key controls gives you a specific path forward to secure your critical Cloud data.

Human error exposes personal data

In July 2017, Verizon experienced a security incident that made national headlines in the United States. While no hack took place and no customer information was taken, the data was publicly exposed. A partner of the organization was using a data set from the telecommunications company to test and suggest changes to a self-service portal. A member of the third party's staff mistakenly set up the data’s cloud storage to permit external access.

As far as security events go, this one may not seem important. Forensic analysis determined that only one unauthorized user viewed it – a researcher at UpGuard, who immediately alerted someone to the problem. However, Verizon still had to spend time and resources responding to the incident. Plus, thrust into the security news spotlight, Verizon may have lost some credibility by reporting that "there was a limited amount of personal data included." The notion of the personal data as “limited” was also used by the third-party provider, NICE systems, which called the data “limited information for a specific project."

Despite these descriptions, the data was that of 6 million unique customers, including their names, phone numbers, addresses, and account PINs. UpGuard noted that this information would’ve enabled a nefarious party to transfer a phone number to a new SIM card, among other possibilities.

This story is important because it demonstrates the effects of security incidents, regardless of whether the information is taken or not. Plus, as indicated by Fahmida Y. Rashid, the incident highlighted the fact that both cloud service providers (CSP) and companies must hold themselves accountable for cloud security.

Key cloud security controls

Misconfiguration is not the only issue that can arise when attempting to keep cloud systems secure. These six controls are key to protecting your customer data, as well as any other information, in cloud environments:

#1. Understand your responsibilities.

One initial concern is that organizations don’t understand their role in protecting customer data. For example, most infrastructure cloud service environments place responsibility on the customer to properly safeguard the information, configure the operating system, and manage apps. Ask your cloud hosting provider what your responsibility is related to each of these security controls.

#2. Audit business and operational processes.

Audits are critical to ensuring compliance with standards from your own policies and procedures, as well as those from government regulators and industry groups (think PCI compliance or HIPAA-compliant Hosting). You want to see a third-party auditor's report from your cloud provider; a typical report is a “Statement on Standards for Attestation Engagements 18” (SSAE 18, formerly SSAE 16) from the American Institute of Certified Public Accountants (AICPA).

The Cloud Standards Customer Council noted that "the level of access to essential audit information is a key consideration of contracts and SLA terms with any cloud service provider." Your expectation should be that you can quickly get access to audit logs, events, and documentation pertaining to your apps and data.

#3. Set up access controls.

Use the identity and access control mechanisms that are available through your CSP.

Keep permissions for users as low as you possibly can when you set up your access and identity control policies, temporarily bumping them up as needed. Tighten the focus of security groups, and utilize reference security groups IDs when you can.

#4. Protect the data.

Risk is the key consideration for data safeguards in the cloud, including the following:

risk of retaining data beyond the necessary timeframe;
risk of unauthorized changes to data;
risk of data unavailability or loss; and
risk of unauthorized disclosure or theft.

To explore this issue through prominent standards, see ISO/IEC 27002 and ISO/IEC 27017 from the International Organization for Standardization and International Electrotechnical Commission.

#5. Optimize your visibility.

You want to leverage all the monitoring and logging tools that are offered by your cloud service provider to give you immediate knowledge of unauthorized access. The information you can get from these tools typically includes: records of API calls, source IP addresses, times placed, and contents of the requests.

#6. Safeguard your keys.

Keep your cloud services access keys protected. Train developers so that leaks are avoided through forums such as source code repositories, Kubernetes dashboards, and public websites. You want a unique key for each cloud service, with access restricted to the minimum permissions possible.

Controlling cloud security

While it might seem complicated to protect cloud systems, it is possible to properly safeguard your ecosystem with the right set of controls. The importance of considering various controls is highlighted every time an organization exposes critical information. To bolster your defensive posture and avoid various costs and hits to your credibility that arise following a cloud security incident, focus on the above six controls.

Adnan Raja has been the Vice President of Marketing at atlantic.net for 14 years. During Raja’s tenure, the Orlando-based, privately held hosting company has grown from having a primarily regional presence to garnering and developing attention nationwide and internationally. In collaboration with a skilled and dedicated team, Raja has successfully led a full spectrum of marketing campaigns, as well as handling PR work with major news outlets and the formation of key strategic alliances.

Pentesting vs Vulnerability Scanning: What’s the Difference?

2018-07-12T12:25:00.000-07:00

Two very different ways to test your systems for vulnerabilities.

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?

Also 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?

Reporting
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.

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.

Reporting

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.

Interested in a penetration test for your business?

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?

2018-07-03T12:53:00.000-07:00

Learn the important differences between the two security standards.

Jonas De Oliveira
CISSP, QSA, CPA, CISA

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.

Learn 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

2018-06-22T10:26:00.001-07:00

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.

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.

SEE ALSO: PCI FAQs

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

2018-06-20T06:53:00.003-07:00

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

Brand Barney
CISSP, HCISSP, QSA

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.)

Follow for more data security articles like this

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

2018-06-13T08:14:00.001-07:00

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.

PCI 3.1: Stop Using SSL and Outdated TLS Immediately

2018-06-05T12:53:00.000-07:00

“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
SVP, Assessments

UPDATE: As of May 2017, PCI DSS 3.2.1 is the latest standard. Read more about the 3.2.1 updates.

June 30, 2018 is the deadline for merchants to disable SSL/early TLS and implement a more secure encryption protocol. TLS 1.1 or higher is required (TLS v1.2 strongly encouraged).

 In April of 2015, the Payment Card Industry Security Standards Council (PCI SSC) released an unscheduled and important update: PCI DSS version 3.1. While it did include minor clarifications and additions, PCI 3.1 was primarily released to address the insecurity of Secure Sockets Layer (SSL) and some Transport Layer Security (TLS) encryption protocols.

After the release of PCI 3.1, all SSL and early TLS versions were not (and still are not) considered strong cryptography.

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 back 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.

Tweet

Since the April 2015 update, merchants were not allowed to implement any new technology relying 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.

Each of these requirements will have additional sub-requirements or guidance provided in the latest version of the PCI DSS.

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 SSL or TLS 1.0 as long as they have provided documentation showing they have a TLS Mitigation and Migration plan.
This exception will expire when the June 30, 2018 deadline hits. Customers that have not disabled SSL and Early TLS and rescanned by that date may be knocked out of compliance due to a failing scan contact SecurityMetrics Support if you have questions.

Follow for more data security articles like this

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 continue to be used, even after the deadline.

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 later if possible.

How do I know if I’m using SSL/early 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/early TLS

Virtual payment terminals
Back-office servers
Web/application servers

What if I’m using SSL/early TLS?

The PCI Council has released 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/early 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/early TLS, and need to continue using:

First, remember not to implement any new technologies that use SSL/TLS. But, if you need to continue using SSL/early TLS to continue regular business operations, here are some examples of what you can do:

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.

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

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Senior Vice President of Security Assessments 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.

Lessons from Data Breaches in 2017 and What to Expect in 2018

2018-05-28T21:47:00.001-07:00

Which data breach predictions came true in 2017 and what to expect for 2018.

David Ellis
SVP, Investigations
GCIH, QSA, PFI, CISSP

This blog is based on Dave Ellis’s Webinar, “Lessons Learned from 2017 Forensic Investigations." You can download and watch the webinar here.

SecurityMetrics' Forensic Investigations Team has been helping business recover from data breaches and theft for over eighteen years. We analyze the data from those investigations and use it to inform our customers, predict breach trends, and better protect merchants.

How did our predictions for 2017 play out?

Insecure remote access will continue to plague organizations

Yes; continues to be the most common problem we see.

Large-scale POS breaches will decrease, but employees will remain high-risk

This certainly happened. We’ve seen the large-scale breaches decline, and employees were the most common weak point (e.g., opening phishing emails).

Overall number of breaches will temporarily decrease

This is proven true according to our investigations. POS breaches have declined with the advent of EMV.

Ecommerce breaches will increase

In 2017, 56% of the payment card investigations we performed were in ecommerce, up from 38% in 2016.

Increased attacks against healthcare targets

Yes; we saw near-two-fold increase in healthcare breaches last year.

A resurgence of ransomware

According to Malware Bytes, ransomware was the most prolific gainer of 2017. Ransomware rates tripled in number from 2016; 60% of malware payloads installed on commercial systems were ransomware.

INFOGRAPHIC: 2017 PCI Data Breach Trends

Many of our readers want to know: what does a cyberattack typically look like? How does an attacker gain access to a system in the first place? How do they steal the information, and what do they do with it?

It pays to understand the steps and patterns of a hacker—plus, it brings to light how important it is to comply with security standards regarding password complexity and secure remote access.

An attacker’s activities will typically include:

Scan internet for open remote access ports. The majority of attacks are not specifically targeted. More commonly, an attacker will start by launching a port scan over a large range of IP addresses looking for open ports that correspond to remote access applications. If they see the company is running remote access software, they will likely attempt to breach through that software.  
They will enter ‘administrator’ or ‘admin’ for the username, and now they just need to “bruteforce” a password using an online password list.  
Test remote access credentials. 
If successful, they gain system access and ascertain where they are (e.g., whether they have gained access to a healthcare organization, retail business, or home network). 
At this point, an attacker might monitor your activity by installing a keylogger. 
Download malware onto the system or encrypt critical files.  
Attacker will capture confidential information or contact the owner of the system and levy ransom demands.

Follow for more data security articles like this

How does stolen data turn into money for hackers?

Attackers might personally use the credit card numbers online or to buy gift cards or prepaid cash cards.

Or—they could be a part of a large organization made up of talented individuals. Organized hacking is like the “new mafia.” These operations are highly systemized, and their employees are probably more motivated than you or I at our jobs. Widespread across the globe, hacking organizations post their offerings on the dark web, and aim to sell the credit card information per number or in bulk.

Most common security failures in 2017:

Firewalls: About 52% of the cases we investigated had inadequate firewall configurations. In some cases, there were no firewalls at all, but most often they weren’t properly configured.
Passwords: Similar to when firewalls are left on default configurations, passwords can be left on default settings as well. Or the password might be too simple, like “password” or “12345.” A few years ago, there was a large breach where more than one billion passwords were “lost.” They weren’t actually lost because the hacker that stole them had cleverly inserted them into a brute-force hacking tool (which he made available for sale to others) that can fly through a system and quickly attempt different passwords. To mitigate these attacks, we recommend that your system lock down after three failed password attempts.
Antivirus: In many of the data breaches we investigated, there was no antivirus installed, or it was expired on some or all of the key systems. And in cases where it was installed, inconsistency was often a problem. The antivirus software wasn’t always installed on all endpoints. We found that 72% of breached companies had adequate antivirus running. But antivirus still makes the list because in the close to 30% of the other cases that inadequacy was a direct contributor to the data breach.
Secure access: Determines who is and is not allowed to access information on your system. Secure access could be compromised with a weak authentication password but is usually due to a lack of multi-factor authentication. There should not be any areas with sensitive or protected information to which someone could log in without multi-factor authentication. Multi-factor authentication will prove to be a crucial security principle as time goes on.

Other security issues:

More than one primary function per server. If you have a device that’s used to take patient info or process credit card info, the more you can segment and separate that device from devices that are used to conduct more routine day-to-day activities, the easier it will be for you to provide high-level security for just a few key devices in your critical data environments, rather than across your entire network. 
Application security updates. Ignoring patches continues to be a problem. For example, when payment applications discover security flaws, they will issue security patches. But we see many investigations where organizations failed to update with current patches, even though they had been supplied months (and in some cases, years) before.

How did healthcare do with security in 2017?

The FBI reports(link) increased attacks against healthcare organizations in 2017: 88% of ransomware attacks last year targeted healthcare organizations. The other 12% were targeting individuals or non-healthcare businesses. Hackers recognize that if they can hold hostage patient information or doctors’ notes, the healthcare industry has to act immediately and is more likely to pay a ransom.

89% of studied healthcare organizations reported a breach involving the loss of patient data in the past two years. In our investigations, we found that 78% were compliant with the HIPAA requirement to encrypt patient data, 55% complied with reviewing firewall rules at least yearly, and only 26% complied with using multi-factor authentication for remote access. 
Top organizational vulnerabilities

In our opinion, the top vulnerabilities organizations should focus on are:

Insecure remote access

Tip: Insist on multi-factor authentication with strong passwords and tokens for all environments containing high value data.

Employees

Tip: Train employees on identifying phishing emails and social engineering attacks.

BYOD procedures

Tip: Bring Your Own Device (BYOD) can be a problem. For example, an employee that uses their work computer on a home network inadvertently downloads a virus. The employee then introduces the virus into the work environment when they log back into the work network. Your work environment should scan devices for viruses when it detects a new login.

3rd Parties

Tip: Know where your data flows and is stored. Conduct risk assessments that include 3rd-party service providers. Do your due diligence with service providers, making sure you have policies, procedures, and agreements on file regarding their security.

Top 10 Tips to avoid data breaches

Educate staff employees: Hold regular trainings with special focus on phishing/spoof emails. 10% of phishing email links are clicked on. Also train your staff to recognize and guard against social engineering. Teach them to question what seem like unusual requests for information (like W2s or personal data). 
Install updates and patches: Consistently monitor application updates and watch for flaws and subsequent patches.  
Develop secure code, then test: Enforce a secure software development lifecycle. For example, follow NIST 800-115 or the OWASP Testing Guide.  
Vulnerability Scans and Penetration Tests: Schedule scans often and regularly (e.g., quarterly) and after any significant network changes. Conduct penetration tests on critical systems at least yearly and after any significant network changes. Be sure to include social engineering tests.  
Configure and review logs: The best way to find out about a breach is from your own internal review. Someone in your organization needs to have eyes on security logs daily. Create and implement a process to respond to intrusion detection system (IDS) and file integrity monitoring (FIM) alerts in real time.  
Risk assessments: Hold a risk assessment at least annually and after any significant network changes.  
Control admin access: Update default usernames like “admin.” Implement multi-factor authentication and restrict access to sensitive data.  
Segment your network: (link) Implement network segmentation by isolating less-secure networks from high-security networks. Ensure that a breach of the less-secure network cannot affect the high-security network.  
Hide sensitive data: (link) Chances are you need to store some sensitive data at your business, so at a minimum, sensitive data should be encrypted and properly secured. Be certain to test your backups to ensure that you will be able to restore from them after a data breach. (This will be your greatest defense against a successful ransomware attack.) 
Develop and test an incident response plan: (link on how to do one) Creating a thorough incident response plan (IRP) (and testing it annually) will help coordinate your response during and after a security incident, minimize an incident’s impact, and restore your operations as quickly as possible.

2018 Forensic Predictions

Ecommerce breaches will continue to increase, as will attacks against healthcare. Ecommerce increased last year, and it will continue to do so. We will probably settle in at a rate of about 80% of investigated breaches that occur in ecommerce environments.  
Smaller merchant breaches will come under greater scrutiny. It used to be that virtually all merchant breaches were investigated. But about five years ago, the card brands softened their mandates to reduce the financial burden for smaller merchants. While a breach of a single small merchant doesn’t typically expose a large number of credit card accounts, the collective total of several small merchant data breaches does. As the number of point-of-sale (POS) card-present breaches decreases, you will start to see increased pressure for small merchants to take more definitive actions when they’re under the suspicion of a data compromise.  
Coordinated attacks that start with your cell phone. We had an attack last year that started with a breached cell phone, which led to the personal computer in the home, then on to the owner’s business (which was n the healthcare industry), then the breach spread to all of the devices in that environment. You may also see more attacks aimed at individuals—and those may be likely to start with a cell phone.  
Passwords may not be the security you’re looking for. We will start to see next year—and more so in the coming years—that passwords will no longer be considered an element of security. There is present technology that can search and break password hashes at the rate of 600 billion attempts per second. This means that attackers could span every possible combination of keys possible, in most languages, in just a few days. As developers put more steam behind this tool, the time and resources needed to break passwords will greatly reduce, regardless of password complexity level.  
Artificial intelligence (AI): on your side and against you. We will likely start to see security tools with artificial intelligence that can detect and adapt to data breaches. But we will also likely see AI on the attackers’ side—with malware that can self-move, self-manipulate, and self-hide in response to what it sees a user do. AI will start to show up with increasing frequency, and it’s going to make the future of data security very interesting.

Learn more about our Incident Response Services or inquire about a PCI or HIPAA Audit.

David Ellis (GCIH, QSA, PFI, CISSP) is Director of Forensic Investigations at SecurityMetrics with over 25 years of law enforcement and investigative experience. Check out his other blog posts.

PCI Council Releases PCI DSS 3.2.1: What You Need to Know

2018-05-22T13:27:00.001-07:00

Learn what’s changed in the latest version of the PCI DSS.

PCI DSS version 3.2.1

The Payment Card Industry Security Standards Council (PCI SSC) recently announced the release of the PCI Data Security Standard version 3.2.1.

The Council previously released version 3.2 in April of 2016 to replace version 3.1, which brought with it some big changes, among which were new requirements for service providers and additional guidance about multi-factor authentication.

So what has changed between versions 3.2 and 3.2.1?

Changes to standard characterized as "clarifications"

All of the changes in this latest version 3.2.1 are characterized by the PCI Council as clarification—as

opposed to additional guidance or actual changes in requirements. The intent of clarification from the PCI Council is to ensure that “concise wording in the standard portrays the desired intent of requirements.”

Many of the changes involve simply removing requirements’ effective dates which have passed or correcting minor punctuation and format issues. However, there are a few items of clarification regarding SSL/early TLS and multi-factor authentication that are worth noting:

“Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS” has been renamed “Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS for Card-Present POS POI terminal connections.”  
In Appendix A2, requirements A2.1 – A2.3 were updated to focus only on the allowance for POS POIs that are not susceptible to known exploits and their service provider termination points to continue using SSL/early TLS. 
In “Appendix B: Compensating Controls,” Multi-factor authentication was removed from the compensating control example, as MFA is now required for all non-console administrative access. The use of one-time passwords (tokens) as an alternative potential control for this scenario was added.

Stay updated to maintain compliance

While these changes are not likely to affect your day-to-day data security routines or require much extra time or money, it’s important to use the latest version of the PCI DSS to avoid misunderstandings and potential gaps in security.

You can read a full and detailed summary of changes between PCI DSS version 3.2 and 3.2.1 here.

If you need help with PCI compliance or would like to know more about PCI audits, contact us here.

How Much Does HIPAA Compliance Cost?

2018-05-21T09:29:00.000-07:00

Realistic HIPAA security budgets vs. wishful thinking.

Jen Stone
MCSIS, CISSP, QSA

HIPAA compliance is rarely allocated the resources it requires. And this trend extends beyond just small organizations with limited security budgets. Lack of budget is a plague that affects risk and compliance officers at health organizations of all sizes.   

This post will give you the information you need to more accurately plan your HIPAA budget.

SEE ALSO: Five Things to Consider When Making a HIPAA Security Budget

What does the HHS think HIPAA compliance costs?

The HHS gave an interesting estimation (see Table 1) of how much HIPAA compliance might cost, shortly after they released the HIPAA Final Rule in 2013.

Per organization, they estimated:

$80 for an updated Notice of Privacy Practices
$763 for breach notification requirement updates
$84 for business associate agreement updates
$113 for security rule compliance

Grand total per organization: $1,040

This estimate is likely inaccurate, especially when considering the complexities of the Security Rule. When the Security Rule was added back in 2003, it included 75 new requirements and 254 points for organizations to validate to, most of which are quite technical.

Follow for more data security articles like this

The following is an example of a "validation point:"

164.308 – Acquire IT Systems and Services (1 requirement)
Based on the OCR audit protocol, here are the validation points:

Interview management to verify that Policy and Procedures exist (P&P)
Determine if the P&P are approved and updated on a periodic basis
Obtain and review the documented policy (what is required) and procedure (how we are supposed to accomplish the task)

Where are P&P stored?  How is it disseminated to staff?
How do we document staff have read, understand and agree to abide by the policy?

Determine if the P&P are approved and updated on a periodic basis

In this one example you can see that this single requirement (1 of 75) has three core validation points (3 of 254) with several more minor validation points.

Looking at the math, and the HHS’ estimated $113 allotted to the security rule, that means only $4 is allowed per requirement. It would be a stretch for healthcare entities to accurately validate each new security point for only $4 worth of labor, technology, and implementation. That’s not even taking into account that you will likely need to add (or, at the very least, upgrade) hardware and applications.

Variables that affect HIPAA compliance cost

The cost of HIPAA compliance depends on your organization. Here are a few variables that will factor into the cost of your overall compliance.

Your organization type: Are you a hospital, business associate, HIE, healthcare clearinghouse, or another type of healthcare provider? Each will have varying amounts of protected health information (PHI) and risk levels.
Your organization size: Typically, the larger the organization, the more vulnerabilities it has. More workforce members, more programs, more processes, more computers, more PHI, and more departments add up to more HIPAA cost.
Your organization’s culture: If data security is one of upper management’s top priorities, you have probably already invested in a cybersecurity program. If management has been hesitant to dedicate budget to security, compliance with HIPAA will cost more because you will have more distance to make up.
Your organization’s environment: The type of medical devices, the brand of computers, the kind of firewalls, the model of backend servers, etc. can all affect HIPAA compliance cost. If cybersecurity was considered when purchasing, implementing and maintaining these devices, the costs to comply with HIPAA at this point will be lower. If security was not considered, costs to get in line with HIPAA will be greater.
Your organization’s dedicated HIPAA workforce: Without a dedicated HIPAA team, you might not know how far you are from closing the HIPAA gap. Even with a dedicated HIPAA team, organizations usually require outside assistance or consulting to help them meet HIPAA requirements.

The cost of a data breach

Costs related to a HIPAA program can seem daunting, but they are small in comparison with not protecting PHI. Here are a few data breach costs, fines, and penalties you may not have considered.

HHS fines: up to $1.5 million/violation/year
FTC fines: $16,000/violation
Class action lawsuits: $1,000/record
State attorneys general: $150,000 – $6.8 million
Patient loss: 40%
Free credit monitoring for affected individuals: $10-$30/record
ID theft monitoring: $10-$30/record
Lawyer fees: $2,000+
Breach notification costs: $1,000+
Business associate changes: $5,000+
Technology repairs: $2,000+

SEE ALSO: How Much Does a Data Breach Cost Your Organization?

When you look at the high costs paid by organizations found in violation of HIPAA, it’s obvious the consequences are meant to penalize those who don’t adequately protect patient information.

So, how much does HIPAA compliance cost?

Tweet

If you are a large provider, you’ll probably benefit most from an onsite HIPAA compliance audit. Security experts examine your organization for security risks, provide guidance as you remediate any problems, and consult on the implementation of any outstanding HIPAA requirements.

Your onsite auditor should work with you to complete both your HIPAA risk analysis and risk management plan. Learn the pros and cons of a HIPAA audit here.

If you don’t have the budget for an onsite audit, you’ll need to find a HIPAA expert to help you get through the risk analysis and risk management plan process. Look for an expert who offers technical support when you have questions. Experts will likely recommend you receive external vulnerability scans to find weaknesses in your systems, and hire penetration testers (ethical hackers) to test your system. If you haven’t already, you’ll likely need to purchase HIPAA policy templates and start your employee training.

Taking all the above into consideration, and remembering that this estimate depends on various factors at your organization, here’s how much HIPAA compliance might cost you:

If you are a small covered entity, HIPAA should cost:

Risk Analysis and Management Plan ~$2,000
Remediation ~ $1,000 - $8,000
Training and policy development ~ $1,000-2,000

Total: $4,000 - $12,000

If you are a medium/large covered entity, HIPAA should cost:

Onsite audit ~ $40,000+
Risk Analysis and Management Plan ~ $20,000+
Vulnerability scans ~ $800
Penetration testing ~ $5,000+
Remediation ~ Varies based on where entity stands in compliance and security
Training and policy development ~ $5,000+

Total: $50,000+, depending on the entity’s current environment

Jen Stone (MSCIS, CISSP, QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.

GDPR 101 Part 3: What Should I Do Now?

2018-05-15T15:51:00.002-07:00

Three tips to get the ball rolling on your GDPR efforts.

Gary Glover
SVP, Assessments
CISSP, CISA, QSA

This post wraps up the final installment in our 3-part GDPR 101 blog series. This series is based on our GDPR 101 Webinar and is meant to help frame your understanding of the GDPR, educate you on the terms and definitions you need to know, as well as give you practical tips to start your GDPR compliance journey.

If you are a merchant, or any organization that handles the personal data of European Union citizens, you will need to comply with the GDPR. Here are three ways you can make progress today towards your GDPR compliance.

1. Learn and understand

The first step you should take is to educate yourself. Learn about the GDPR requirements and seek out reliable resources. The Information Commissioner’s Office in the UK has a website and blog dedicated to educating the public about this upcoming data security mandate.

Here are some more GDPR resources to get you started:

2. Assess and plan

In any kind of security effort, the first thing you’ll need to do is create a data-flow diagram. This will help you discover and clearly document where personal data flows. You’ll need to show where sensitive data comes in and out of systems, and how it moves inside the organization.

Determine the security controls you don’t yet have in place. There are worksheets available, like these checklists from the ICO office in the UK, to help you comply with GDPR. At this point, make a plan for how your organization will integrate and complete all the documentation that will be required.

If you already follow other data security standards, like the Payment Card Industry Data Security Standard (PCI DSS), you may find there is some crossover between the data security controls. It’s important to realize that just because you’re certified compliant with PCI DSS or have had a HIPAA audit, that doesn’t mean you’re GDPR compliant.

Even though there are crossovers between data security standards, GDPR has a much larger scope because it includes many types of information that fall under “personal data,” like names, addresses, and telephone numbers. However, if you only handle credit card data, your scope may remain similar to what it already is under the PCI DSS.

You can use online management tools like GDPR Defense to manage your GDPR compliance efforts, securely store documentation, and track important tasks.

SEE ALSO: What's the Difference Between GDPR and PCI?

3. Assign a DPO or similar position

You may or may not be legally required to appoint a Data Protection Officer (DPO), depending on your “core activities,” or the primary business activities of your organization. According to the UK’s ICO website, if your core activities consist of either of the following, you will be required to appoint a DPO:

Processing activities which require the regular and systematic monitoring of individuals on a large scale; or 
Processing on a large scale of special category data, or data relating to criminal convictions and offenses.

So basically, if your core business activity is data processing on a large scale, or the processing of special or sensitive data, you will be required to have a DPO.

Even if you are not legally required to appoint a DPO, you should assign someone in your organization to serve as a GDPR officer. Assign one person to learn about, delegate, and oversee GDPR efforts at your organization.

WHITE PAPER: GDPR 101

Take steps sooner rather than later

The GDPR becomes enforceable on May 25, 2018. Take these 3 steps now to be as prepared as possible. Small actions now will help you avoid fines and penalties and better protect sensitive data at your organization. If your organization does experience a data breach involving EU citizens' personal data, you'll fare better in the aftermath if you have made a good faith effort to comply with mandates and laws.

SMB? GDPR Defense can help you organize and manage GDPR efforts.

Large Organization? Contact us for GDPR consulting.

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.

ETA TRANSACT 2018 Wrap Up

2018-05-11T14:13:00.000-07:00

The quality of our connections made 2018 our best year yet.

From our annual golf tournament on Monday to tasty drinks and good conversation on the show floor, TRANSACT 18 was a huge success.

Mix and Mingle with a QSA

Our theme for 2018, “Mix and Mingle with a QSA,” was complemented by our unique mixed soda bar featuring security-themed flavor options.

Attendees flowed through our booth to grab drinks and chat with QSAs about data security and PCI compliance. The most popular drink was the “Penetration Test,” with Dr. Pepper, coffee, coconut, and cream.

Matt Brown ready to demo our latest PCI compliance tools.

Mixing and mingling with our QSAs.

PCI DSS Compliance Done Right.

Visitors standing in line for yummy sodas!

Bird's-eye view of SecurityMetrics' booth.

Data Breach Panel with Gary Glover

On Tuesday, our Senior VP of Assessments, Gary Glover (CISSP, CISA, QSA, PA-QSA), participated in the Data Breach Panel sponsored by Fortner. He and other panel members related that when organizations are breached, they are almost never PCI compliant. They also reported investigators see hundreds of compromises at small retailers which we never hear about on the news.

Gary specifically advised retailers to stop looking for an “easy button” to solve data breaches. Many merchants look for a piece of hardware or software to solve the problem. “But there isn’t,” he said during the panel. “Some of the solutions don’t cost much; it’s processes. It’s procedures. It’s figuring out who is really looking at your remote access. Who is really doing your internal scans? Who is really configuring your network to try and keep people out of certain zones? We’re still seeing all kinds of architecture mistakes.”

You can read more about the Data Breach Panel here.

Annual Golf Tournament at TPC Summerlin

The Las Vegas wind didn’t stop our golf teams from showing up on Monday. As part of the pre-conference roster, this annual tradition is the perfect time to get to know our partners and friends in the payments industry.

Our winners are as follows:

Start your engines.

Closest to the Pin
Front nine winner: Wally Mylnarksi 
Back nine winner: Jerry Nelson

Longest Drive
Front nine winner: Marc Roberts
Back nine winner: Joe Benson

Golf Tournament Winners
1st: Wally Mlynarski, Ian Stuttard, Chris Taylor, Al Echamendi
2nd: Don Kissock, Scott Kim, Daniel Shin, Shawn Dalton
3rd: Mike Fox, Thad Sheffield, Eric Woodson

Golf team ready to win.

Lining up the put.

Windy but beautiful day on the course.

A great put.

We can’t wait to see everyone again next year!

If you weren’t able to visit with our QSAs or sales team or still have questions, please reach out to us anytime.

For information about PCI audits, HIPAA audits, or other data security services, please visit us here.

How Prepared are UK Businesses for GDPR?

2018-05-08T15:22:00.003-07:00

Learn about the General Data Protection Regulation and how UK businesses are preparing.

The EU General Data Protection Regulation (GDPR) will come into effect on May 25, 2018. This government mandate introduces tougher laws about processing and handling personal data of EU citizens, tightens the timeline for breach reporting, and protects numerous individual rights.

Some businesses in the UK have researched and made preparations for the GDPR. Other still do not know what the GDPR is. Fines for data breaches and non-compliance can range between 4% of a business’s annual global turnover (aka revenue) or €20 Million—whichever is greater.

There are two major parties when it comes to GDPR: Data Controllers and Data Processors. It’s important that organizations determine which group they belong to, so they can understand the scope of their responsibility. Data Controllers are entities or individuals that need to process personal data in order to do business. They determine the purposes for which and the manner in which the personal data is processed. Data Processors take and process personal data on behalf of the Controller.

SEE ALSO: GDPR FAQs

We interviewed over 250 management and IT professionals in the United Kingdom about GDPR and their GDPR compliance efforts. This infographic is an analysis of their collected responses.

GDPR priority levels among UK businesses

While 44% of UK organizations we interviewed consider GDPR a high priority, 35% still do not know what GDPR is. What does this mean? Sometimes companies are simply busy or they don’t realize how significant the GDPR is to them. There could also be a lack of reliable education and resources.

For those companies that consider GDPR a high priority, there are few GDPR management tools on the market. But, using such a tool is a good way to stay organized and avoid fines down the road. Check out SecurityMetrics GDPR Defense for more tracking options.

How ready are UK businesses for GDPR?

With the May 25th implementation date looming near, organizations report varying levels of readiness. Nearly 50% of companies that we surveyed say they are 50% ready or less for GDPR.

If businesses already follow security standards like the PCI DSS or HIPAA, there may be some overlap in the security controls they already have in place. However, GDPR has a much larger scope and protects data subjects’ rights to a greater extent.

Download our GDPR 101 Webinar

Resource planning for GDPR

We asked businesses how they plan to meet GDPR requirements. Again, a large chunk of respondents report not knowing what GDPR is. For those with a plan, most expect to handle the requirements of GDPR themselves and only 17% will hire someone to help.

It’s difficult to say yet exactly how much GDPR compliance will cost businesses. The true amount will depend on many factors, including company size, current security controls, the amount of data processed, and the handling methods.

We asked companies what they estimate to spend annually on GDPR compliance. Over half reported that they expect to spend less than $200 annually. Only 9% reported planning for $3000 or more.

Again, the appropriate budget for each company is dependent on many factors and will likely change as time goes on and businesses are more familiar with GDPR compliance. But as of a few weeks before implementation, it appears that companies plan to spend a very minimal fraction of their budget on GDPR compliance.

SEE ALSO: GDPR 101 Part 1 Blog, GDPR 101 Part 2 Blog

What we’ve learned about GDPR readiness in the UK

We found that 62% our respondents already work toward compliance with the PCI DSS. This can be seen as a strength or a weakness, depending on how a company handles its data security overall. While we mentioned that yes, there are overlaps between PCI and GDPR, the scope and breadth of each compliance mandate are different. GDPR applies to all personal data—also known as personally identifiable information (PII)—and its intent is to protect the privacy rights of individuals.

UK respondents were on average only 54% ready for GDPR implementation and 57% consider GDPR a medium-to-high priority. This means that there is still plenty to be done. The key is to find reliable resources and tools that provide a starting point and a map for the GDPR compliance journey.

SecurityMetrics GDPR Defense

If you have questions about data security mandates or standards like GDPR, PCI DSS, or HIPAA, contact us here.

Resources from the PCI Council: Payment Data Security Essentials

2018-04-23T11:54:00.003-07:00

Series of infographics and videos to help merchants with common security issues.

The Payment Card Industry Security Standards Council (PCI SSC) recently announced the release of their “Payment Data Security Essentials” video and infographic series to help merchants with the most common causes of data breaches. These three issues: insecure remote access, weak passwords, and insufficient patching, represent much of the “low hanging fruit” that hackers can leverage to successfully attack and steal data from businesses.

Too often, organizations miss these problems and leave their data vulnerable. And it’s not just the companies with massive, highly publicized data breaches that make these critical errors. Smaller businesses actually tend to be more at risk, usually due to a lack in resources for security—we just don’t hear about them as often.

INFOGRAPHIC: 2017 PCI DSS Data Breach Trends

The PCI Council notes that these factors represent the “bad news,” but the good news is that education in these areas can help merchants better focus their resources to tasks that will provide the most “bang for their buck.” Each video is under three minutes and gives actionable tips for merchants. Infographics are printable, illustrate the risk associated with each security issue, plus they outline additional resources for each problem.

Insecure Remote Access

The SecurityMetrics Forensic Team found that in 2017, 45% of breached organizations were accessed by attackers through remote access. Remote access remains one of the most common hacking attack vectors because businesses often configure their remote access application insecurely.

In addition to proper configuration, organizations should limit employees’ access to remote access and implement multi-factor authentication.

WEBINAR: Understanding the New Multi-Factor Authentication Supplement

Check out the PCI Council’s remote access informational video and infographic to learn more about how you can implement these security practices at your business.

WHITE PAPER: Configuring Your Remote Desktop

Weak Passwords

Passwords remain a weak point overall for cybersecurity. It’s not out of reach for a hacker to “brute force” a password, especially if it's simple or common. Online, there are readily available lists of default vendor passwords, including extremely common ones like: 1234, guest, user, pass, access, admin, pass, password, [name of product/vendor], root, anonymous, sa, database, or secret.

To minimize the risk of a breach, you should change vendors’ default passwords, make the new passwords sufficiently complex, and never share them.

Check out the password informational video and infographic to learn how maintaining proper password practices will protect your organization.

SEE ALSO: PCI Requirement 8: Combatting Weak Passwords

Insufficient Patching

Recent high-profile hacks like Equifax and others have hinged on unpatched software. Most software will have flaws or need to be updated at some point, so most vendors will regularly send out updates to their customers. These updates include “patches” that fix vulnerabilities, and if businesses don’t stay on top of them, these well-known (in the hacker world) vulnerabilities can make your business an easy target.

Whether you are an e-commerce business or use point-of-sale hardware, you need to keep your patch updates timely and thorough. To do that, you should know who makes your software and devices, and then make sure you subscribe to their update lists and emails. Find out if they run automatic updates, or if running them is your job.

LEARN MORE: 2018 SecurityMetrics Guide to PCI DSS Compliance

Some installers and resellers have actually been trained by the PCI Council to address critical security controls while installing merchant payment systems. They are known as Qualified Integrators and Resellers (QIRs), and you can find a list of them here.

Searching for vulnerabilities that may need patches can be done with scanning software. The Council’s patching informational video and infographic include tips for communicating with vendors, as well as resources to find PCI Approved Scanning Vendors (ASVs) to perform your vulnerability scans.

SEE ALSO: PCI Requirement 11: Vulnerability Scanning and Penetration Testing

GDPR 101 Part 2: What are the Requirements of GDPR?

2018-04-16T14:37:00.001-07:00

Learn the basics about the EU’s General Data Protection Regulation.

Gary Glover
VP of Assessments
CISSP, CISA, QSA, PA-QSA

Part 2 of our 3-part GDPR 101 blog series is based on our GDPR 101 Webinar and will cover the “what” of the GDPR: its terms, requirements, and the individual data subject rights it names and protects.

GDPR 101 Part 1: Should I Be Worried? helped set up a framework for your approach to GDPR compliance. Our 3rd installment in this blog series will offer practical tips to get you started on your own GDPR compliance journey.

Terms and Definitions in the GDPR

First up, the difference between data controllers and data processors.

Not all organizations involved in the processing of personal data have the same roles or levels of responsibility.

Data Controllers: Entities or individuals that need to process personal data in order to do business. They determine the purposes for which and the manner in which the personal data is processed. The data controller must exercise control over the data processing and ultimately carries the responsibility for its security. 
Data Processors: Processors take and/or process personal data on behalf of the Controller.

Other important GDPR terms to know:

Supervisory Authority: An independent public authority established by a member state to represent the people and oversee/monitor businesses. 
Personally Identifiable Data (PII)/Personal Data: any information relating to a data subject, which could identify them directly or indirectly. Besides names, addresses, etc., personal data can refer to identification numbers, or even to one or more factors specific to physical, physiological, mental, economic, cultural or social identity. 
Pseudonymisation: amending data so that it is no longer identifiable except with a key. Sometimes takes the form of a coded data set and works a bit like encryption. Does not apply to data that is rendered anonymous. Pseudonymisation may not always put data out of scope for GDPR, but it can allow the relaxing of some provisions for using data for secondary purposes, like historical or research purposes.  
PII/Personal Data Breach: A security breach leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

What are the requirements of the GDPR?

Data Mapping and Tracking
The first step in GDPR compliance is to discover and clearly document all of the PII/personal data that flows into and out of your organization. To do this, you will need to understand the processes that use PII and conduct internal interviews. Once you know where and what you’re looking for, a good data discovery tool can help. The next step is to document what the personal data is, where it comes from, and where it flows. Documentation includes data flow and network diagrams, as well as process descriptions.

INFOGRAPHIC: How to Find and Secure Unencrypted PII

Communicating Privacy Information
GDPR has core principles about communicating with those you get personal data from. This communication could occur between you and the data subject themselves, or you and an entity providing you with previously collected personal data.

Privacy notices must be more transparent, using clear and plain language, and be easily accessible and easy to understand for any of your customers. This communication will need to explain things such as your lawful basis for getting their data, how long it will be kept, and what their rights are regarding the data you are processing or storing.

Subject Access Requests
The time limit to comply with data subject access requests (DSAR) has been reduced from 40 days to one month. If you handle a large number of access requests, consider how to deal with requests more quickly.

In most cases, you’ll not be able to charge the customer for the time you use to complete the request. You can refuse or charge for requests that are manifestly unfounded or excessive. If you do refuse a request, you must tell the individual why and that they have the right to complain to the supervisory authority and to a judicial remedy. You must do this without undue delay and at the latest, within one month

Processing Data Lawfully
You will need to explain your company’s need to obtain the personal data, including the lawful basis for gathering and processing it. Document this information and update your privacy notice to explain it.

Consent to Process Data
Gathering data needs to include a clear “opt-in” step from data subjects. You will not be able to inform customers through an automatic pop up or “fine print” only. Consent must be obtained. Review how you seek, record, and manage consent, and maintain clear privacy notice documentation.

Consent for Children
Organizations must have processes in place to verify data subjects’ ages. For children, your privacy notice must be written in simple language the child can understand. At present, the GDPR states that you must obtain parental or guardian consent for any data processing activity of a subject younger than 16 in the EU.

Data Breaches
Establish policies and procedures to detect, report, and investigate a personal data breach (e.g., Incident Response Plan.) You must report personal data breaches to your SA within 72 hours after awareness of the breach. If individuals face an adverse impact, contact individuals directly. Failure to report a breach when required to do so could result in a fine in addition to the fine for the breach itself.

Data Protection Officers
You will need to designate a Data Protection Officer (DPO) to be responsible for data protection compliance if your organization is:

A public authority or body (except for courts acting in their judicial capacity) 
An organization carrying out regular and systematic monitoring of data subjects on a large scale 
An organization processing a large scale of special data categories—health records—(as detailed in Article 9) and personal data relating to criminal convictions and offenses (as detailed in Article 10)

But even if you don’t fall into one of these categories, we highly recommend designating a DPO. Your DPO will need knowledge, support, and authority to carry out their role effectively.

SEE ALSO: GDPR Frequently Asked Questions

Data Protection by Design
GDPR makes “data protection by design and default” an express legal requirement. This one statement itself can create a myriad of data protection and security requirements that are not specifically defined by the GDPR but are well known in the data security industry.

You may already be familiar with many of them if you undergo PCI DSS, ISO 27000, SOC, or other security assessments.

Data Protection Impact Assessments
Data Protection Impact Assessments (DPIAs) are essentially a formal Risk Assessment process like that defined in NIST 800-30. You will need to conduct DPIAs when specific risks might affect the rights and freedoms of data subjects. For example, when a new technology is deployed, a profiling operation will impact individuals significantly, or when there’s a large-scale processing of special categories of data.

This impact assessment will use information gathered from your data mapping exercise as well as information about all the systems and networks used to process data. This process is critical to implementing the “data protection by design and default” philosophy.

Security Considerations
The concept of “data protection by design and by default” leads to the need for a lot of security controls to be applied to your systems, processes and people involved in dealing with sensitive personal data.

Based on our experience in the security industry, here are a few of the major areas that will need attention. Each of these bullets could be expanded into more system or process requirements, but we will not go into that here. If you want to be GDPR compliant, you will need to have documented evidence that your systems embody the principle of “data protection by design and by default.”

Remote Access Security 
Web Application Security 
Edge Firewall Security

External Vulnerability Scan

Wireless Network Security 
Password Policies 
Malware Prevention 
Physical Security

WEBINAR: Understanding the New Multi-Factor Authentication Supplement

What rights does GDPR name and protect?

Right to erasure: Individuals may request to have personal data erased. This right is also sometimes called “the right to be forgotten.” Other data security standards (such as HIPAA) may overrule the right to erasure in certain circumstances; it’s best to consult with a legal advisor regarding these possible scenarios.

Right to be informed: Keeping data subjects informed is key to transparency under the GDPR. You must let them know your purposes for processing their personal data, your retention periods for that personal data, and who the data will be shared with. This is known in the GDPR as “privacy information.”

Right of access: Data subjects have the right to access their personal data and supplementary information. The right of access also states that individuals should be aware of and verify the lawfulness of the processing.

Right to rectification: The GDPR includes a right for individuals to have inaccurate personal data rectified or completed if it is incomplete.

Right to restrict processing: In certain circumstances, individuals have the right to request the restriction or suppression of their personal data. Restricted processing means the data can be stored, but not used.

Right to data portability: You may be required to provide the personal data in a structured, commonly used and machine-readable format. This right only applies to personal data an individual has provided to a controller, where the processing is based on the individual’s consent or for the performance of a contract, and when processing is carried out by automated means.

Right to object: Individuals may object “on grounds relating to their particular situation” to data processing—even if it’s based on legitimate interests or the performance of a task in the public interest/exercise of official authority (including profiling). They have a right to object to direct marketing (including profiling), as well as to processing of their data for purposes of scientific/historical research and statistics.

Rights related to automated decision making including profiling: this right includes additional rules to protect individuals if a data controller is carrying out solely automated decision-making that has legal or similarly significant effects on them. You can only carry out this type of decision-making where the decision is: necessary for the entry into or performance of a contract; or authorized by Union or Member state law applicable to the controller; or based on the individual’s explicit consent.

SEE ALSO: What's the Difference Between GDPR and PCI?

Who enforces GDPR?

There are general supervisory authorities (SA), for example the Information Commissioner’s Office in the UK, but it’s a good idea to start finding out who your specific SA is. The SAs are responsible for issuing fines.

GDPR 101 blog series
Watch for our third and final installment of our GDPR 101 blog series. In it, we will cover the “how” of GDPR: the important steps you’ll need to take and the resources to help you take them.

Also check out our “GDPR 101 Part 1: Should I Be Worried” blog post. It’s an important introduction that will helps set the stage for how you should think about and approach GDPR compliance.

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.

What are the 12 requirements of PCI DSS Compliance?

2018-04-10T17:13:00.001-07:00

The 12 PCI Requirements, plus resources to help address them.

The PCI DSS (Payment Card Industry Data Security Standard) is a security standard developed and maintained by the PCI Council. Its purpose is to help secure and protect the entire payment card ecosystem.

Breaches and data theft are unfortunately common, and negatively impact all payments parties in different ways—from retailers to consumers to banks—so the need for PCI compliance has never been greater.

INFOGRAPHIC: A Quick Look at PCI DSS Compliance

No matter where you are in your PCI compliance journey, you'll need a reference to help organize your thoughts and get headed in the right direction. We hope this article will serve as your “jumping off point” as you start to address the requirements of the PCI DSS.

For more detailed information and interactive IT task checklists, check out our 2018 Guide to PCI DSS Compliance.

Before diving into the PCI requirements, you will want to start by determining which SAQ applies to your business. While most requirements will stay the same, there are some differences in the work you’ll need to do based on your SAQ.

1: Protect your system with firewalls

The first requirement of the PCI DSS is to protect your system with firewalls. Properly configured firewalls protect your card data environment. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by your organization.

You’ll want to install both hardware firewalls and software firewalls. Both provide a first line of defense for your network. Hardware firewalls are the more robust security option. They can protect an entire network and segment its internal areas. Hardware firewalls are typically more expensive, take time to properly configure, and need to be maintained and reviewed regularly.

Software firewalls are cheaper and easier to maintain. They are meant to protect a single host from internal threats—commonly those from employees’ mobile devices, which can move in and out of the secure environment. If an employee clicks on a link in a phishing email, a software firewall should prevent malware infection.

SEE ALSO: Compliance with PCI Requirement 1: Basics of Managing Your Firewall

2: Configure passwords and settings

You shouldn’t keep vendor-supplied defaults around. Out-of-the-box devices, such as routers or POS systems, come with factory settings like default usernames and passwords. Defaults make device installation and support easier, but they also mean that every model originates with the same username and password. Default passwords are simple to guess, and most are even published on the Internet.

The problem is that third parties sometimes install hardware or software and leave merchants unaware that their entire system is protected by an easy-to-find/crack password. Vendors might also purposely leave weak or default passwords to make service easier. But, that’s like leaving your front door unlocked just to make life more convenient.

Fulfilling requirement 2 involves inventorying and then properly configuring all security settings on all systems and devices. You will need to assign someone to compile and review this information.

SEE ALSO: PCI Requirement 2: How to Get Compliant

3: Protect stored cardholder data

According to requirement 3, stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). The problem is many merchants don’t know they store unencrypted primary account numbers (PAN).

Not only must card data be encrypted, the encryption keys themselves must also be protected. For example, using a solid PCI DSS encryption key management process will help keep you from storing the key in the “lock” itself.

To fulfill this requirement, you need to create and document a current cardholder data (CHD) flow diagram for all card data flows in your organization. A CHD flow diagram is a graphical representation of how card data moves through an organization (see example). As you define your environment, it’s important to ask all organizations and departments if they receive cardholder information, and then document how their answers may change card data flows.

You should regularly run a data discovery tool like PANscan or PIIscan. These tools help identify the location of unencrypted PAN and other sensitive information, so you can securely delete or encrypt it.  

SEE ALSO: PCI Requirement 3: What You Need to be Compliant

4: Encrypt transmission of cardholder data across open, public networks

For requirement 4, you need to know where you send cardholder data. Here are common places where primary account numbers (PAN) are sent:

Processors   
Backup servers   
Third parties that store or handle PAN   
Outsourced management of systems or infrastructure   
Corporate offices

You then need to use encryption and have security policies in place when you transmit this cardholder data over open, public networks.

A note about SSL and early TLS web encryption: based on vulnerabilities in web encryption, the PCI Security Standards Council has released policy stating that you need to transition from SSL and early TLS to secure versions of TLS by June 30, 2018.

SEE ALSO: PCI Requirement 4: Securing Your Networks

5: Use and regularly update anti-virus software

Anti-virus software needs to be installed on all systems commonly affected by malware. Make sure anti-virus or anti-malware programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent known malware from infecting systems.

Be sure you or your POS vendor are regularly running your software’s anti-virus scans.

You should also keep up to date on current and existing malware threats. Using outside sources, such as vendor/anti-virus threat feeds, merchants can find out about emerging malware and attacks on systems. Then you can configure systems to alert and report on suspicious activity, such as new files added to known malware directories or unauthorized access attempts.

SEE ALSO: PCI Requirement 5: Protecting Your System with Anti-Virus

6: Regularly update and patch systems

Applications will never be perfect, which is why manufacturers frequently release updates to patch security holes. These patch updates can also be time sensitive. Once a hacker knows they can get through a security hole, they pass that knowledge on to the hacker community, which will then exploit the weakness until the patch has been updated.

Quickly implementing security updates is crucial to your security posture. Patch all critical components in the card flow pathway, including:

Internet browsers   
Firewalls   
Application software   
Databases   
POS terminals   
Operating systems

Be vigilant and consistently update the software associated with your system. Requirement 6.2 states merchants must “install critical patches within a month of release” to maintain compliance. Don’t forget to update critical software installations like credit card payment applications and mobile devices. To stay updated, ask your software vendors to put you on their patch/upgrade notification list.  

SEE ALSO: PCI Requirement 6: Updating Your Systems

7: Restrict access to cardholder data by business need-to-know

To fulfill requirement 7, you need a role-based access control (RBAC) system, which grants access to card data and systems on a need-to-know basis. Configure administrator and user accounts to prevent exposure of sensitive data to those who don’t need this information.

PCI DSS 3.2 requires a defined and up-to-date list of the roles (employees) with access to the card data environment. On this list, you should include each role, the definition of each role, access to data resources, current privilege level, and what privilege level is necessary for each person to perform normal business responsibilities. Authorized users must fit into one of the roles you outline.

SEE ALSO: Keep Employees on a Need-to-Know Basis: A Look at Requirement 7

8: Assign a unique ID to each person with computer access

According to PCI DSS requirement 8, user IDs and passwords need to be sufficiently complex and unique. You should not use group or shared passwords.

However, your system security should not be based solely on the complexity of a single password. No password should be considered “uncrackable,” which is why, as of February 1, 2018, all non-console administrative access (remote access) to in-scope systems requires multi-factor authentication.

SEE ALSO: Combatting Weak Passwords and Usernames

9: Restrict physical access to workplace and cardholder data

Employees may think physical security only applies after hours. However, most data thefts (e.g., social engineering attacks) occur in the middle of the day, when staff is often too busy with their various assignments to notice someone walking out of the office with a server, company laptop, phone, etc.

You are not allowed to store sensitive information like payment card data out in the open. For example, many hotels keep binders full of credit card numbers behind the front desk, or piled on the fax machine, for easy reservation access. Unfortunately, this collection of files not only makes life easier for employees but gives criminals easy access to this information.

SEE ALSO: Employee Security Training Tips: Social Engineering

Requirement 9 states that you must physically limit access to areas with cardholder data, as well as document the following:

Who has access to secure environments and why they need this access   
What, when, where, and why devices are used   
A list of authorized device users   
Locations where the device is and is not allowed   
What applications can be accessed on the device

You will also need to implement automated lockout/timeout controls on workstations, periodically inspect all devices, and most importantly—train your staff regularly about physical security, policies and procedures, and social engineering.

SEE ALSO: PCI DSS Requirement 9: Upping Your Physical Security

10: Implement logging and log management

We found that in 2017, non-compliance with requirement 10 was the most common contributor to data breaches. Logs are only useful if they are reviewed.

System event logs are recorded tidbits of information regarding actions taken on computer systems like firewalls, office computers, or printers. To fulfill requirement 10, you must review logs at least daily to search for errors, anomalies, and suspicious activities that deviate from the norm. You’re also required to have a process in place to respond to these anomalies and exceptions.

Log monitoring systems, like Security Information and Event Monitoring tools (SIEM), can help you oversee network activity, inspect system events, alert of suspicious activity, and store user actions that occur inside your systems.

SEE ALSO: PCI Requirement 10: Logging and Log Management

11: Conduct vulnerability scans and penetration tests

Your data could be left vulnerable due to defects in web servers, web browsers, email clients, POS software, operating systems, and server interfaces. Yes, fulfilling requirement 6 (installing security updates and patches) can help correct many of these defects and vulnerabilities before attackers have the opportunity to leverage them.   But in order to be sure you’ve successfully patched these vulnerabilities, you need to be able to find them and test them. For that you need to perform regular vulnerability scanning and penetration testing.

A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.

A penetration test is an exhaustive, live examination designed to exploit weaknesses in your system. Just like a hacker, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors). Basically, these analysts attempt to break into your company’s network.

Requirements for frequency and type of penetration test will vary depending on your SAQ, business size, environment, systems, etc.

SEE ALSO: PCI Requirement 11: Vulnerability Scans and Penetration Tests

12: Documentation and risk assessments

The final requirement for PCI compliance is to keep documentation, policies, procedures, and evidence relating to your company’s security practices.

If you perform a PCI audit, you’ll quickly pick up on the fact that there’s a big emphasis on your documented security policies and procedures. During an assessment, QSAs will typically verify that specific requirements are defined in company policies and procedures. Then, they’ll follow predefined testing procedures to verify that those controls are implemented in accordance with the PCI Data Security Standard and with written company policies.

You will need to include the following information in your documentation:

Employee manuals   
Policies and procedures   
Third-party vendor agreements   
Incident response plans

The second part of requirement 12 is to perform an annual, formal risk assessment that identifies critical assets, threats, and vulnerabilities. This requirement will help you identify, prioritize, and manage your information security risks.

SEE ALSO: PCI DSS Requirement 12: Leverage Policy to Improve Security

The process of reaching PCI compliance takes time and can seem like an overwhelming list of demands, but it’s ultimately what will make the difference between a failed cyber-attack on your business and a cyber-attack that sinks your business.

Guides, checklists, and templates will help you and your IT teams complete day-to-day tasks associated with each requirement, and security professionals can advise you on more complicated issues.

If you're interested in a PCI Audit or other security services, contact us here.

Takeaways from Our 2018 PCI Guide

2018-04-03T09:59:00.003-07:00

Important lessons from the SecurityMetrics 2018 Guide to PCI DSS Compliance.

Our 2018 PCI Guide is out and already helping businesses understand the Payment Card Industry Data Security Standard (PCI DSS) and simplify their own compliance journeys.

Merchants use our PCI Guide both as a desk-side PCI reference and as a tool to direct and track their organizations’ internal PCI compliance efforts. But, there’s also another side to the Guide. Our ultimate goal is to help you secure data and protect your business, so we’ve included highlights from our own research in the Guide to give you a clearer picture of how compliance and security work together.

Download the SecurityMetrics 2018 PCI Guide here.

This post will cover some of the most important takeaways from our Guide, so you can apply these lessons to the everyday operations of your business.

Forensic Data from 2017 Investigations

Our PCI Forensic investigators (PFIs) have been helping businesses analyze and recover from suspected data breaches for over 15 years. In the process, they’ve witnessed the rise and fall of popular cyber-attack trends as well as collected a trove of useful forensic data that can be used to inform your data security implementations.

What we found regarding the average breached merchant:

The average organization was vulnerable for 1,549 days.  
Cardholder data was captured for an average of 237 days.  
Cardholder data was exfiltrated for an average of 264 days.  
45% of organizations were breached through insecure remote access.  
39% of organizations had memory-scraping malware installed on their system.

WEBINAR: Lessons Learned from 2017 Forensic Investigations

In general, we see that these trends stem directly from non-compliance with the PCI DSS.

Most organizations will experience system attacks from a variety of sources, and some of these attacks will result in data breaches. Some breaches are due to system or technology weakness, others to internal security process failures (e.g., ignoring patches and updates). Whatever the source of the attack or the ultimate reason for compromise, we’ve found a strong correlation between non-compliance and data breaches.

The PCI DSS is specifically designed to protect merchants and organizations that deal with payment card data and associated sensitive information. Following its requirements exactly will greatly diminish the chances of a successful cyber-attack on your systems.

Our Forensic Investigators track which PCI requirements organizations are—or are not—compliant with at the time of a data breach.

Our PFIs also record whether non-compliance with these requirements directly contributed to the data breach.

You can see that non-compliance with requirements like 10 (logging), 11 (vulnerability scans), and 12 (policy/procedures documentation) frequently contributed to the data breaches themselves.

Further, if there is a successful attack, shrinking the window of compromise will go a long way to lessen the damage a data breach can cause. The longer attackers have access to your data without you knowing, the more they can take and the more profit they stand to make.

Takeaway: You can shrink the window of compromise by properly implementing security measures like PCI requirement 10, “Implement Logging and Log Management,” or PCI requirement 7, “Restrict Access.”

Download our 2017 Forensic Data Breach Trends Infographic here.

Vulnerability scan results

External vulnerability scans performed by a PCI Approved Scanning Vendor (ASV) are just one tool in validating PCI compliance. But, the results can also provide valuable insight into common weak spots you should pay special attention.

These are the top 5 areas SecurityMetrics customers failed in vulnerability scans, and one can surmise that these trends extend to businesses who are both currently and not currently working on their security:

TLS Version 1.0 Protocol Detection
SSL Medium Strength Cipher Suites Supported
SSL 64-bit Block Size Cipher Suites Supported (Sweet32)
SSL Certificate with Wrong Hostname
SSL Self-Signed Certificate

Takeaway: If you haven't already, make sure your cryptographic protocols are in line with the latest PCI Council guidance.

Your PCI compliance journey

When planning and designing your organization’s compliance journey, it helps to understand the bigger picture. PCI DSS requirements were not designed arbitrarily but rather, specifically, to help you avoid data breaches and mitigate their effects if they do happen.

The Security Metrics 2018 Guide to PCI DSS Compliance is a powerful tool for understanding and appreciating the connection between compliance and security.

Let us know what you think about the guide! Email us at pr@securitymetrics.com with your feedback.

Interested in a PCI Audit, HIPAA Audit, or our other security services? Contact us here.

What's Inside Our 2018 PCI Guide

2018-03-27T14:47:00.003-07:00

The 2018 PCI Guide is here. Learn what’s in it and how it will simplify your PCI process.

We’ve officially launched our 2018 Guide to Payment Card Industry Data Security Standard (PCI DSS) Compliance. Inside you’ll find fresh insights, tips from auditors, forensic investigation data, interactive checklists, and a new prioritized chart to guide your reading.

You can download the 2018 SecurityMetrics Guide to PCI Compliance here.

Here’s a list of 5 of the best features from our 2018 Guide to PCI DSS Compliance:

1. A prioritized approach to PCI compliance

If you’re working towards payment card industry compliance this year, you'll want to check out our newly added section that begins on page 5, titled “How to Read This Guide.” We’ve added a chart to guide you through the requirements of the PCI DSS.

The chart gives an overview of the PCI Security Standards Council’s Prioritized Approach. The PCI SSC's Prioritized Approach consists of six milestones based on high-level compliance and security goals. Our chart breaks down requirements into individual IT tasks and assigns them to their related milestone(s).

This chart is especially useful for PCI compliance officers, CISOs, IT managers—anyone whose job requires that they plan, organize, or present on internal PCI compliance efforts. The Prioritized Approach offers organizations a risk-based roadmap to address issues on a priority basis, while also supporting organizational financial and operational planning.

Depending on where you are in your compliance journey, some milestones may be more significant to you than others. Rather than reading our guide cover to cover, we recommend you use this chart to guide your PCI compliance efforts.

2. Forensic data from our 2017 investigations

We believe knowledge is power, which is why we share data from our 2017 forensic data breach investigations on pages 11-13. By learning which PCI requirements were most commonly/not commonly implemented at the time of a data breach, which non-compliant requirements directly contributed to data breaches, as well as the top SAQ failures, you can appreciate the bigger picture of what PCI compliance means for organizations.

Understanding the patterns that typically go along with data breaches empowers you to make informed decisions about allocating your PCI compliance resources.

WEBINAR: Lessons Learned from 2017 Forensics Investigations

We found that 2017 showed significant decreases in compliance levels when compared to previous years and that none of the investigated breached merchants in 2017 were found to be compliant with PCI DSS. And in nearly every case, the vulnerabilities that attackers leveraged to gain access to merchant systems would have been mitigated if the organization had been compliant with the entire PCI DSS.

3. Interactive IT Checklists

PCI compliance comes down to the successful completion of a series of tasks. At the end of each requirement section, we include checklists as a way to help IT teams track and manage these action items.

The IT checklists have been one of the most popular and utilized features of our guides. This year, they are “interactive,” meaning you can actually check off tasks within the PDF document. You can also type directly in the assignment and completion fields.

We added the checklists specifically to give you more options to manage and document your organization’s compliance-related IT tasks. The intent is to simplify compliance for everyone: those who determine the tasks, those who assign the tasks, and those who ultimately perform the tasks. This doesn’t replace our PCI audit management tool, but should enhance the overall process of getting compliant.

Interactive IT checklists are found on the following pages: 40, 44, 48, 51, 53, 58, 60, 64, 69, 73, 81, and 86.

INFOGRAPHIC: How to Discover and Encrypt Sensitive Data

4. Tips from auditors

Our “Tips from Auditors” sections throughout the document give context to the bigger picture of PCI compliance as well as actionable tips from our QSAs, who have years of IT security and audit experience.

We include auditor commentary and best practices for each PCI DSS requirement, as well as in other sections of the guide. If you are looking for an overview of what’s important for data security in the payment card industry, these sections would be a perfect place to start.

“Tips from an Auditor” sections can be found on the following pages: 17, 39, 43, 47, 50, 52, 56, 59, 63, 68, 72, 80, 85, and 106.

5. PCI Data Security Standard updates

Our PCI guide is written in accordance with the latest version of the PCI DSS, and outlines the supplemental guidance released by the Security Standards Council. Pages 24-30 outline and describe recent important changes and supplements to the PCI DSS, including:

• PCI Data Security Standard version 3.2 
• New service provider requirements 
• Updated SSL/early TLS migration dates 
• February 2017 Multi-factor authentication supplement  
• Multi-factor authentication in or out of the CDE (8.3) 
• Clarifying masking criteria (3.3) 
• Change management process (6.4.6) 
• Service provider written agreement (12.8.2) 

SEE ALSO: PCI DSS 3.2 Reminder to Comply

A powerful PCI help

Whether you are brand new to PCI compliance or are a seasoned systems administrator, you will find that the 2018 SecurityMetrics Guide to PCI DSS Compliance is a dynamic, hard-working document. We designed it to be a useful tool in the hands of anyone who wants to achieve compliance with the PCI DSS.

You can download the 2018 SecurityMetrics Guide to PCI Compliance here.

We’d love to hear what you think—do new features like the interactive checklists or “Prioritized Approach” reading guide chart help your compliance managers and IT teams? Are there features of the guide you use more than others? Or are there things you’d like to see included in the next edition?

Email pr@securitymetrics.com with your feedback about the guide.

If you’re interested in a PCI audit or our data security services, contact us here.

No Spreadsheets Needed: Manage HIPAA in SecurityMetrics’ Health Network Portal

2018-03-16T15:09:00.000-07:00

Protect your network, save time on HIPAA, and maintain your reputation.

HIPAA management for large networks

Data security and HIPAA compliance are more important than ever for the healthcare sector. From large health networks to small-town medical practices, protected health information (PHI) remains a high-value target for attackers. Health organizations were hit hard in 2017—the healthcare industry experienced 23.7% of total data breaches that year. This trend of cyber-attacks and data theft in healthcare seems like it’s here to stay, but complying with HIPAA requirements will go a long way to protect your system from attackers.

Download our 2018 Guide to HIPAA Compliance.

If you’re a HIPAA manager, IT Director, or CISO responsible for network-wide HIPAA compliance at your organization, you know that the vulnerabilities of individual members can affect your network as a whole. But, overseeing your network while managing the compliance of each member often amounts to a series of messy, tedious tasks—especially if your main tracking tools are spreadsheets and emails.

All-in-one network HIPAA management solution

We designed the SecurityMetrics Health Network Portal to be an efficient, organizational portal with tools that facilitate HIPAA management, monitoring, reporting, and tracking. No spreadsheets needed. Plus, HIPAA communications and documentation can be kept on one central platform.

Learn more about the SecurityMetrics Health Network Portal here.

Overview dashboard

The network HIPAA compliance journey begins at the overview dashboard. From this main screen, you can see compliance progress across your network, assign tasks, view scan results and risk summaries, and prepare compliance reports for C-level executives or auditors.

SEE ALSO: How Brightsquid Increased Business with HIPAA Compliance

Follow for more data security articles like this

Member Summary

Member summaryView progress based on member or location. The member summary tool shows you in real time how individuals’ compliance progress affects the network. You can see which members make the network safer and which ones increase risk. Monitor members’ HIPAA compliance by viewing each of their:

Breach protection checklist
Risk analysis
Risk management plan
Vulnerability scanning
Policies and procedures

Risk Summary

The overall security of your network is made up of many members’ tasks and efforts. Our risk summary tool calculates a risk level based on the combined data of every member in your network. This lets you see where you’re at and helps determine what your HIPAA goals might be.

SEE ALSO: Health Network Portal Data Sheet

Business associate overview

Covered entities must maintain a signed up-to-date business associate agreement (BAA) for each business associate they work with. Managing these contracts and tracking down business associates is made simple with the business associate overview tool. You can see at a glance how many business associates you work with and pinpoint which ones have yet to sign BAAs.

SEE ALSO: Business Associate Agreements 101

HIPAA tools for every stage and every day

Wherever you are in your HIPAA network compliance journey, the Health Network Portal is an everyday, easy-to-use solution that provides visibility and multi-level views for busy HIPAA managers and compliance officers.

The Health Network Portal guides network-wide compliance efforts and directs attention to potential security gaps, weak spots, and vulnerabilities, which otherwise would have been missed. It’s intended to not only for daily HIPAA management but also to provide reporting resources for meetings, audits, and documentation purposes.

Think the Health Network Portal might be a good fit for your organization? Speak to a specialist or request a quote for your network here.

GDPR FAQs

2018-03-14T08:51:00.005-07:00

Our most common questions about the General Data Protection Regulation.

Ben Christensen
CISA, QSA

If you’re like most business owners, you’re probably wondering if and how the new EU General Data Protection Regulation (GDPR) applies to you. We’ve received many questions about this new security mandate, and here are answers to our most frequently asked GDPR questions.

What is GDPR?

GDPR stands for General Data Protection Regulation. It was designed to harmonize data privacy laws across Europe, protect and empower all EU citizens with data privacy, and to reshape the way organizations across the region approach data privacy. This mandate replaces the 1995 EU Data Protection Directive and was finally approved by EU parliament on April 14, 2016 after four years of preparation and debate. It went into effect 20 days after its publication in the EU Official Journal—in May of 2016—and will be directly applicable in all member states two years after this date (i.e., May 25, 2018).

When will GDPR come into effect?

The effective date for the EU GDPR is May 25, 2018.

Who does the GDPR apply to? Does it apply worldwide or just to the EU community?

The GDPR applies to any organization (operating in or out of the EU) that processes any personal data, also called personally identifiable information (PII), of EU citizens—whether that organization is a cloud-storage service, university, hospital, merchant, etc.

Does the GDPR apply to organizations outside of the EU that have EU citizens inputting data into their database or website?

Yes. Even if the data subject from the EU inputs their own information, the GDPR requirements still apply.

Are payment card details (such as cardholder names and addresses) protected under GDPR?

Yes. Personal data includes things like name, address, email, IP address, etc.—data that can directly or indirectly identify a person. Even the magnetic card stripe (also known as track data) contains the cardholder’s name.

SEE ALSO: GDPR 101 Part 1: Should I Be Worried?

If I’m already PCI compliant, does that cover GDPR?

No, but there are data security controls that will cross over. The GDPR scope will likely be much larger than PCI DSS requirements, as it includes all personal data, not just payment card details.

How does the GDPR impact small businesses? Especially for those with minimal credit card transactions.

There may be some requirements of the GDPR--for instance keeping “records of processing activities” (Article 30)--that will not apply to organizations with less than 250 employees. However, there are stipulations to rules like these, and to be safe, you should consult a data security and compliance expert.

What are the possible penalties for noncompliance with GDPR requirements?

Organizations can be fined up to 4% of annual global turnover (aka revenue) or €20 Million—whichever is greater—for violation of GDPR. These are the maximum fines that can be imposed for the most serious infringements, like insufficient customer consent to process data or violation of the core “Privacy by Design” concepts.

According to article 28, there is a tiered approach to fines. A company can be fined 2% of annual global turnover for not having their records in order, 2% for not notifying the supervising authority and data subject about a breach, and 2% for not conducting an impact assessment.

It is important to note that these fines apply to both controllers and processors, and data 'clouds' will not be exempt from GDPR enforcement.

As a result of Brexit, does the UK (and its citizens) still have to follow the GDPR? If the UK doesn't have to follow the GDPR, how will UK-based organizations be impacted by the GDPR?

Since the GDPR applies to the personal data of all EU citizens, businesses in the UK who process EU citizen data post-Brexit would still need to follow its mandates whether or not the UK retains GDPR after Brexit is complete. UK Prime Minister Theresa May announced that the process for the UK to leave the EU would begin on March 29, 2017 and is expected to take at least two years. The effective data for GDPR is May 25, 2018, which means there will be an overlapping window of time when the UK is a member of the EU and the GDPR is in force.

What is the “Right to Erasure” and how will it impact organizations that are required to keep information for a certain amount of time (e.g., HIPAA requirements)?

The “Right to Erasure” is one of the individual rights named in the GDPR. It states that data subjects can request that their personal data be deleted. There are legal and legitimate reasons that organizations could be allowed to keep data beyond retention periods—even if a data subject exercises their right to erasure. For example, an organization may be required to hold records for the IRS, HIPAA requirements, PCI requirements, or legal cases. In these cases, the organization would obviously need a legal basis for keeping such data. It’s best to consult with legal counsel to understand your business’s unique position.

What other individuals’ rights are set forth in the GDPR?

How long does a controller have to notify their supervisory authority about a data breach?

Supervisory authorities must be told within 72 hours of when the controller becomes aware of a data breach—where feasible, and unless the controller can demonstrate that the breach is unlikely to result in risk to the rights of the data subject. Controllers may also give reasons for delay, if applicable.

How do we retrospectively gain consent from customers that we already market to on our existing database?

Conditions for consent to use data are strengthened overall by the GDPR, and personal data used for marketing purposes must be approved beforehand by the customer in the form of an “opt-in” program. While each business and its operations are different, some may be wondering about old contacts, business cards, or mailing lists with data obtained before GDPR. Depending on your business model, there could be a few ways you might be able to address this problem, however remember that you will need to clear any solutions with legal counsel:

If you have active customers that put data into a system you control (such as a web-based system) and they visit that system regularly, it seems reasonable to place some sort of consent-flag in a database that could then be set the next time they login to the system. But the concept of collecting consent of active visitors after the fact could work. 
If you own and store a large database/collection of personal data (collected pre-GDPR), this could be more difficult to deal with. You may want to consult a legal expert in that case.

Please explain how you advise a US merchant to comply with both SAQ-D and the GDPR standards, specifically the logging requirements of SAQ-D that seem to contradict the “Right to Erasure.”

PCI DSS explicitly requires logging—which is a good thing when it comes to maintaining security, detecting attacks, etc. If you’re in the PCI realm, you should continue to use logging and thorough log management. The “right to erasure” may be a tricky GDPR requirement and tone we feel will need more legal definition and precedence to be established. However, if you foresee this being an issue for your company, you should seek corporate legal counsel.

Does SecurityMetrics offer help with GDPR for small-to-medium businesses?

Yes. SecurityMetrics GDPR Defense is a new product designed to help small-to-medium businesses secure personal data and get on the path to GDPR compliance.

GDPR Defense contains the following tools to help fulfill certain GDPR requirements while also providing a central location to track, maintain, train, and report on those efforts:

SecurityMetrics PIIscan: Scans systems and devices for unencrypted PII. Provides file path so users can easily locate, and then delete or encrypt, sensitive data.
GDPR Checklist: Defines and breaks down individual GDPR requirements into simple “how to implement” steps. Checklist tracks completion dates of items and then displays that information on the GDPR Implementation Report.
Secure Cloud Storage: Provides secure central location for policies and procedures as well as internal data mapping documents. GDPR requires organizations to maintain policies and procedures about encryption, data retention, and data breach response. It also requires knowledge of sensitive data locations.
GDPR Implementation Report: Shows evidence of efforts to reach compliance in the event of an audit or data breach. Report displays percentage of implementation completed as well as progress over time.

What can large organizations do to comply with GDPR?

If you’re part of a large organization and need help with GDPR, learn more about our consulting here.

If you have more questions about GDPR, or would like a PCI audit or HIPAA audit, please contact us.

Ben Christensen (CISA, QSA) has worked in the IT sector for over 19 years. He currently performs security assessments for merchants and service providers looking to become PCI compliant. He is also leading SecurityMetrics' GDPR efforts in developing product offerings and documentation.

2018 PANscan Results: Storage of Credit Card Data on the Rise

2018-03-06T14:32:00.003-08:00

See how much unencrypted card data PANscan® found on business networks in 2017.

Storage of unencrypted PAN on networks is up

Primary account numbers (PAN) are the 14-, 15-, or 16-digit credit card numbers used to identify individual cards. If merchants unknowingly store unencrypted PAN on their networks, they may pose a big risk to their business.

Manually searching for PAN can get tedious and overwhelming, but tools like PANscan® are designed to search quickly and efficiently in the background without slowing down day-to-day operations.

Since 2010, SecurityMetrics PANscan® has discovered over 1.6 billion unencrypted primary account numbers. Our 2018 PANscan study compiles results from PANscan® users in 2017. We found that credit card data storage is up since last year and has been steadily climbing for the last few years. Remember that these results come only from users of our PANscan® tool--merchants who are already security-minded. This could mean that as a whole, businesses that handle credit card data are faring worse.

Download the 2018 PANscan® Data Analysis Infographic here.

The 2018 PANscan® study

We found that in 2017, PANscan® searched 337,118 GBs of data and found over 114 million unencrypted card numbers as well as over 4.5 million track data (i.e., magnetic card stripe data). Sixty-nine percent of users stored unencrypted PAN, and 7% stored unencrypted track data.

In 2016, 67% of PANscan users stored unencrypted PAN, which means credit card data storage is up 2 points since then (a 2.98% increase). Only five percent of these businesses stored track data in 2016, which means there's been a 40% increase. The PCI DSS requires that merchants never store track data, for any reason (Requirement 3.2).

Where did PANscan® find card data?

There are several common places PAN data hides. Whether it’s due to poor process or misconfigured software, unencrypted credit card numbers on a network can be traced to:

Error logs
Accounting departments
Sales departments
Marketing departments
Customer service representatives
Administrative assistants

Learn more about PANscan®.

SEE ALSO: What's Inside Our 2018 PCI Guide

Protecting Customers’ Credit Card Data

Keeping unencrypted data on systems is a security risk but it can also be difficult to avoid. Like we mentioned, PAN data can come from departments like marketing, accounting, sales—but it can also be unintentionally stored due to bad handling process.

Follow for more data security articles like this

Here are seven tips to find and secure credit card data:

Interview Employees: Find out who has access to what card data and how each department interacts with it.
Create a card-flow diagram: Map out where card data enters, leaves, is stored, and interacts with/in your system.
Use a data discovery tool: As previously mentioned, a well-designed software tool can make a world of difference. PANscan® is designed to run light, work fast, and avoid false positives.
Remove or encrypt data: Protect customers’ credit card numbers by properly removing, deleting, destroying, or encrypting them.
Consider data storage: Rethink whether you really need to store credit card data in any form on your systems.
Limit access to data: Only those who absolutely need to access card data for their job should be able to.
Segment your network: Separate your card data environment from other systems, using firewalls or other methods. This way you can reduce the potential for data leakage to unauthorized areas.

For more information about PCI compliance, a PCI audit, or data security, contact us here.

2018 HIPAA Guide: Highlights for Business Associates

2018-02-28T08:51:00.003-08:00

A reference for business associates using the SecurityMetrics HIPAA Guide at their organizations.

We released the SecurityMetrics 2018 Guide to HIPAA Compliance on November 30, 2017.

Business associates (BA) and small entities will benefit from this desk-side HIPAA reference, especially since they may have limited resources and are often self-taught.

Our HIPAA Guide was created to help business associates with some of the more challenging aspects of HIPAA compliance like the minimum necessary rule, secure data deletion, business associate agreements, and network segmentation.

If you’re a BA and in charge of HIPAA, you can use the following page numbers and HIPAA Guide highlights to help guide you through your more common HIPAA concerns and challenges.

Common business associate concerns (PP. 11-12)

Reminder: a BA is a person or entity that performs certain functions that involve the use or disclosure of PHI (e.g., IT provider). Business associates can be from legal, actuarial, consulting, data aggregation, management, administrative, accreditation, and/or financial organizations. Some possible business associate functions include:

Claims processing or administration
Data analysis, processing, or administration
Utilization review
Quality assurance
Billing
Benefit management
Practice management
Repricing

These are some of the most basic questions business associates face when getting HIPAA compliant:

Do Business Associates have to be HIPAA compliant?

When it comes to responsibility, if your organization is considered a business associate, you may think you’re exempt from HIPAA compliance, especially if you don’t consider yourself a part of the healthcare industry. However, the HHS requires any business associates that create, receive, transmit, and/or maintain protected health information (PHI) in any way must be HIPAA compliant.

Are Business Associates responsible for patient data?

Business associates are legally bound to protect PHI. You must comply with all data security requirements in HIPAA and follow the Security and Breach Notification Rules (unless contractually obligated to follow the Privacy Rule). You are required to protect PHI just as a covered entity would: by means of network segmentation, secure data destruction, etc.

SEE ALSO: HIPAA FAQS

Minimum necessary requirement (P. 100-102)

A large portion of the Privacy Rule is based on the minimum necessary requirement, which states that only those who need to see or access PHI to do their jobs should get to see or access it.

BAs often think their covered entity holds the sole responsibility of deciding how much data they receive. This is simply not the case. Both business associates and covered entities have a minimum necessary responsibility under HIPAA.

BAs should only accept and use the minimum amount of data necessary. Even they can face fines from HHS if they accept or demand more data than is necessary from covered entities. As a business associate, if you receive too much data from a covered entity, you are responsible for letting the covered entity know.

Check out page 102 of the HIPAA guide to learn about instances when the minimum necessary rule does not apply.

Permanently destroy or delete PHI (PP. 21, 26-27, 105)

The first step to managing/deleting old data is deciding how long you need to keep it. Many states have requirements about the amount of time that you must keep patient data. This can apply to uses and disclosures and even the patient record. Entities commonly maintain data for a minimum of a decade. If a patient has passed away, there will be additional requirements for data retention that must also be considered.

The second step is to understand how to permanently destroy or delete data. Most people understand that physical sensitive data should be destroyed permanently by shredding, burning, or pulping.
 But when it comes to electronic data, merely deleting or moving sensitive information to the Trash or Recycle Bin on your computer will not permanently remove it. Your computer won’t be able to find that file, but it still exists.

The HHS has determined that for electronic PHI, overriding or clearing (i.e., using software or hardware products to overwrite media with non-sensitive data) is the best way to securely delete sensitive patient data on systems still in use.

When thinking about how to permanently delete files from your network, don’t forget about any archived data, including:

Time Machine backups
Cloud backups
External hard drive backups
CD or DVD backups
Email backups
FTP backups
Server backups
Mirror backups
Offsite backups

If media is magnetic (e.g., tapes, hard drives), it should be degaussed or demagnetized.

But if you don’t plan to use the media again, it’s highly recommended to physically destroy it. Some third-party organizations have industrial-sized shredders to dispose of larger hardware.

Business associate agreements (PP. 110-113)

The HIPAA Final Omnibus Rule requires covered entities to implement or update a business associate agreement (BAA) when a BA creates, receives, maintains, and/or transmits electronic patient data.

In these new or revised BAAs, covered entities, business associates, and subcontractors agree to share responsibility for patient data protection and breach notification. Here are a few examples of what should be included in your business associate agreement:

A minimum necessary policy
Business associate’s permitted use of PHI
Prohibited use of PHI
Covered entity’s responsibility
Appropriate safeguards to protect PHI
Breach reporting guidelines
Contract termination provisions

Covered entities typically will not work with you if you refuse to sign a BAA or to comply with HIPAA regulations. You should know what is in the BAA you sign, and what exactly you’re liable for when it comes to protection of PHI.

SEE ALSO: Business Associate Agreements 101

Network segmentation (PP. 12, 46-47)

Business associates often set up large flat networks, where everything inside the network can connect to everything else. You may have one firewall at the edge of your network, but that’s it. Generally, the more places that have access to patient information, the higher the chances for a HIPAA violation or data breach.

Network segmentation can be achieved through use of specific firewalls and the sectioning off of systems that contain or receive PHI from the rest of the network.

Network segmentation is especially useful for you if you need to protect PHI. If done properly, it can greatly reduce time, energy, money, and potential liability related to HIPAA.

SEE ALSO: PIIscan Searches Systems for Unencrypted Data

HIPAA applies to business associates

Even though as a business associate, you may not deal with patients and their data in the same exact way as covered entities, you are still required to comply with HIPAA rules and regulations.

The SecurityMetrics 2018 HIPAA Guide provides plenty of guidance specifically for business associates to help you keep data safe and move towards HIPAA compliance. Our ultimate goal is to empower individuals at organizations to protect patient data. We want to provide resources that educate employees at all levels about HIPAA rules and regulations.

Have questions about data security, HIPAA compliance, or interested in a HIPAA audit? Contact us.

PIIscan: Find and Secure Unencrypted Personal Data

2018-02-20T20:28:00.001-08:00

SecurityMetrics PIIscan Helps You Comply with Security Standards and Mandates.

What is PII, and why do I need to find it?

Personally Identifiable Information (PII) is data kept by an organization which can be used to “distinguish or trace an individual’s identity,” according to NIST. For example, PII could include names, birth dates, birth places, mothers’ maiden names, or social security numbers. “Linked PII” is any information that is linkable to an individual, like educational, medical, employment, or financial information.

Storing these types of (unencrypted) information on your systems and devices can leave your organization open to fines and make you more vulnerable to data theft.

Organizations can manually search for PII on their systems and devices, but doing so is time-consuming, tedious, and expensive in terms of working hours.

Sensitive Data Discovery Tool: SecurityMetrics PIIscan

PIIscan was created to help organizations quickly find and secure unencrypted PII on their systems. The data discovery tool is now widely available and helps organizations and businesses of all sizes comply with data security mandates and standards in the US and EU.

This scanner runs light, but performs a big job. According to Product Manager Kai Whitaker, “PIIscan is designed to be quick, small, and powerful. Organizations find value and increase their security through the effective scanning that PIIscan provides.”

SEE ALSO: SecurityMetrics Releases PIIscan

Unencrypted PII hides in unexpected places

Of all the organizations that conducted first-time data discovery scans with SecurityMetrics PIIscan, 61% found unencrypted PII in their networks. Many times, this sensitive data shows up in accounting, marketing, or other unexpected areas or departments.

Caches of unencrypted PII are highly valuable to data thieves. PIIscan searches systems, hard drives, and attached storage devices for unencrypted sensitive data. If it does find unencrypted sensitive data, it provides you a path to the file location where the unencrypted information is found.

GDPR, PCI DSS, and HIPAA

If you are fulfilling the requirements of security standards and mandates like the EU’s General Data Protection Regulation (GDPR), the Payment Card Industry Data Security Standard (PCI DSS), or the Health Insurance Portability and Accountability Act (HIPAA), it’s important to know where PII is on your systems and whether it’s encrypted or not.

PIIscan searches not only for PII, but also for payment card data like primary account numbers and magnetic stripe track data. PIIscan finds the following information:

• USA Social Security Numbers (SSN)
• UK National Insurance Numbers (NINO)
• Canada Social Insurance Numbers (SIN)
• Australian Tax File Numbers (TFN)
• Australian Business Numbers (ABN)
• Primary account numbers (PAN)
• Magnetic stripe track data
• Protected Health Information (PHI)

SEE ALSO: GDPR 101 Part 1: Should I Be Worried?

More Tips to help you find and protect PII Data:

1. Monitor your PII data flow
To help find PII flows you might not immediately know about, create and regularly update a PII flow diagram that tracks the processes you go through as you receive, use, store, or transmit sensitive data.

This will help you see where PII enters and exits your organization.   Here are some areas unprotected PII may be hiding:

Printers often store old jobs, which could include sensitive data
Error logs frequently contain sensitive numbers in plaintext during a failed authentication
Accounting and marketing departments may have email or paper forms with PII
Web browser cache may store PII inadvertently

2. Secure and Encrypt PII
When possible, avoid using and storing PII. You can also avoid storing sensitive data by using tokenization or outsourcing sensitive data handling to a third party.

But if you do need to keep data, make sure to find and encrypt PII. All electronic PII that is received, stored, handled, or transmitted in your systems and work devices must be encrypted. Industry best practice would be to use AES-128, AES-256, or better.

3. Segment Your Networks
While not all mandates require network segmentation, it’s considered security best practice to keep your networks that handle sensitive data like PII separate from your other networks.

Whether done physically or through firewall implementation, make sure systems that receive, store, handle, and transmit sensitive data are kept separate from each other. This can be done by regularly doing "segmentation checks.”

Learn more about sensitive data discovery tools or call us about a PCI audit or HIPAA audit at

GDPR 101 Part 1: Should I Be Worried?

2018-02-13T13:41:00.001-08:00

What you need to know now about the EU’s General Data Protection Regulation (GDPR).

Gary Glover
SVP, Assessments
CISSP, CISA, QSA, PA-QSA

With the EU’s GDPR compliance date looming (May 25, 2018), businesses are in varying states of readiness and awareness. Many are likely wondering, should I be worried? What changes do I need to make? What does it mean to be GDPR compliant?

This post is the first of a three-part series in which we will cover basics and requirements of the GDPR. This series is based on our recent “GDPR 101” Webinar. You can watch and listen here.

Who does the EU GDPR apply to?

The EU GDPR applies to any organization that handles the Personally Identifiable Information (PII) of European Union (EU) citizens--whether that organization is in America, Europe, or somewhere else in the world.

Following GDPR guidelines will be very important for such companies or organizations. It’s also important to understand that cloud services will not be exempt from the GDPR.

SEE ALSO: Complying with the GDPR: What You Should Know

What is GDPR?

The GDPR replaces the 1995 EU Data Protection Directive. The new GDPR legislation is meant to unite and harmonize privacy laws across the EU. Before the GDPR, different businesses throughout the EU did slightly different things for data protection.

After four years of preparation and debate, the GDPR was approved by EU parliament on April 14, 2016. It went into effect 20 days after being approved and will be directly applicable for all member states two years later on May 25, 2018. After this date, organizations that are not following the GDPR could potentially face severe fines.

At this time, no one can guarantee how severe fines will be, or what types of businesses may be examined for non-compliance first, but after May 25th GDPR becomes enforceable.

GDPR Compliance

Some aspects of the GDPR are easy to interpret. For example, the GDPR says that data owners are required to have an opt-in choice presented to them before a company can begin storing, processing or transmitting their personal information. This requirement is clear, and one could easily determine whether or not that requirement has been met.

However, other aspects are more difficult to interpret. The GDPR states, “protect your data by design and default.” It’s difficult to know if you are perfectly compliant or meeting a specific GDPR requirement according to this statement.

Even though GDPR compliance isn’t currently as well-defined as Payment Card Industry Data Security Standard (PCI DSS) compliance, it’s important to be aware, be concerned, and be reasonable. It’s impossible to say with absolute clarity that an entity is 100% compliant with GDPR, because associated testing procedures are not specifically defined. Perhaps this will come later; various supervisory authorities are working on checklists and similar guidance, which indicates that there will likely be more specific audit protocols as time goes on.

For the time being, you can actively and carefully address GDPR regulations, document your efforts, collect your results, and show risk analysis/assessment results.

Why Should I Care about GDPR?

GDPR guidelines state that an entity can face fines of up to 20 million Euros or 4% of their Global Annual Turnover (AKA “revenue” in the U.S.), whichever is greater. Note that this is the maximum fine amount, and there doesn’t appear to be additional guidance to describe specific fine structure for various types of data compromise or general lack of preparation, other than the regulation stating that a fine could be less than 4%, (e.g., 2% of revenue or 10 million Euros).

We want to reiterate that we’re not saying the sky is falling. But, you should be aware of these regulations and make plans for any necessary changes.

Part 2 of this blog series will go into more depth on terms and definitions, but it’s important to understand the difference between Data Processors and Data Controllers and know that the GDPR rules and requirements apply to both of them:

Data Controller: Entities or individuals that need to process personal data in order to do business. They determine the purposes for which and the manner in which the personal data is processed.
Data Processors: Processors take and/or process personal data on behalf of the Controller.

When Do I Need to Worry about GDPR?

You have until May 25, 2018 to start complying with GDPR regulations. Right now, we don’t know what types of organizations the governing bodies will go after, or how aggressively. All we know is that after May 25 of this year, they can.

If your company has poor security practices that endanger personal information, it makes sense that you could get in trouble according to these EU laws and regulations. On the other hand, if your company takes data security seriously and is actively moving towards alignment with the GDPR or other data security standards, you will naturally fair better.

Remember, May 25, 2018 is not the end of the world. We all tend to fear the worst when a line is drawn in the sand, but someone has to draw one to get us all moving.

As security professionals, it’s our job to help companies clear up security issues. Our experience shows that addressing security and compliance problems may take time. The community has known about this regulation for two years now, so ignoring these regulations will not make them go away. Get started soon and you will see real progress.

Showing real progress in securing PII is important because this demonstrates you’re working towards compliance. If you were to experience a data breach but couldn’t show any proactive work towards security, enforcement of the regulation could be stricter.

If you’re looking to learn more about the GDPR, the Information Commissioner’s Office (ICO) is a UK organization that was set up to uphold information rights for UK citizens.

SEE ALSO: PIIscan: Find and Secure Unencrypted Personal Data

Part 2 of The GDPR 101 Blog Series

Watch for part 2 of our GDPR 101 blog series, which will cover specific terms, requirements, and details of the GDPR.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Senior VP of Security Assessments 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.

SecurityMetrics Blog

Cloud Security: What Businesses Need to Know

Top Cloud Security Controls Organizations Should Be Using.

Human error exposes personal data

Key cloud security controls

Controlling cloud security

Pentesting vs Vulnerability Scanning: What’s the Difference?

Two very different ways to test your systems for vulnerabilities.

What is a vulnerability scan?

What is a penetration test?

Which is better? A vulnerability scan or penetration test?

PCI vs. GDPR: What’s the Difference?

Learn the important differences between the two security standards.

1. Scope of relevant data

2. The processes covered by PCI DSS and GDPR

3. Security vs. Privacy

Network Diagrams: Key to Compliance and Security

Three tips for PCI compliance network documentation.

1. Find a program to streamline the process

2. Create a single source of truth

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

5 Tips to Improve HIPAA Compliance in 2018

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

What’s new in HIPAA in 2018?

SecurityMetrics HIPAA Compliance Research

Top Organizational Vulnerabilities

HIPAA data security updates

Issues with a compliance mentality

5 tips to improve HIPAA compliance in 2018

Live and breathe security

IT Checklists for PCI Compliance

Detailed checklists for teams working on PCI compliance.

Information technology team management

Interactive PCI compliance checklists

IT data security tasks

The SecurityMetrics Guide to PCI DSS Compliance

The SecurityMetrics PCI Guide protects businesses

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.”

How will PCI 3.1 affect SecurityMetrics customers?

What about HTTPS and ecommerce?

What about my POS/POI terminal?

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

What if I’m using SSL/early TLS?

If you use SSL/early TLS, but don’t need to:

If you use SSL/early TLS, and need to continue using:

Lessons from Data Breaches in 2017 and What to Expect in 2018

Which data breach predictions came true in 2017 and what to expect for 2018.

How did our predictions for 2017 play out?

An attacker’s activities will typically include:

How does stolen data turn into money for hackers?

Most common security failures in 2017:

Other security issues:

SEE ALSO: 5 Steps to Manage a Data Breach

How did healthcare do with security in 2017?

Top 10 Tips to avoid data breaches

2018 Forensic Predictions

PCI Council Releases PCI DSS 3.2.1: What You Need to Know

Learn what’s changed in the latest version of the PCI DSS.

PCI DSS version 3.2.1

Changes to standard characterized as "clarifications"

Stay updated to maintain compliance

How Much Does HIPAA Compliance Cost?

Realistic HIPAA security budgets vs. wishful thinking.

What does the HHS think HIPAA compliance costs?

Variables that affect HIPAA compliance cost

The cost of a data breach

If you are a small covered entity, HIPAA should cost:

If you are a medium/large covered entity, HIPAA should cost:

GDPR 101 Part 3: What Should I Do Now?

Three tips to get the ball rolling on your GDPR efforts.

1. Learn and understand

2. Assess and plan

3. Assign a DPO or similar position

Take steps sooner rather than later

ETA TRANSACT 2018 Wrap Up

The quality of our connections made 2018 our best year yet.

Mix and Mingle with a QSA

Data Breach Panel with Gary Glover

Annual Golf Tournament at TPC Summerlin