PCI Requirement 6: Updating Your Systems

See why updating and patching your systems is crucial to security.  

George Mateaki
Security Analyst
CISSP, QSA
Requirement 6 deals with consistently updating your systems and patching any vulnerabilities that appear.

Here are a few things you should know about requirement 6.

Why patch and update systems?  

PCI requirement 6Requirement 6.1 states merchants must “deploy critical patches within a month of release” to maintain compliance. 


Application developers are not perfect, which is why updates to patch security holes are frequently released. Once a hacker knows he can get through a security hole, he passes that knowledge on to the hacker community, who then exploit this weakness until the software has been updated.
Quickly implementing security updates is crucial to your security posture.
You should patch all critical components in the card flow pathway, including:
  • Internet browsers 

  • Firewalls 
  • Application software 

  • Databases 

  • POS terminals 

  • Operating systems 

This is especially true for Windows systems. Older Windows systems can make it difficult for merchants to remain secure, especially when the manufacturer no longer supports a particular operating system or version (e.g., Windows XP). Operating system updates often contain security patches to exposed vulnerabilities. If you use an unsupported operating system that doesn’t receive updates and patches, the vulnerability potential increases exponentially.

Be vigilant and consistently update the software associated with your system. Don’t forget about critical software installations like credit card payment applications and mobile devices. To help keep up to date, ask your software vendors to put you on their patch/upgrade email list. 


SEE ALSO: Security Patches in Your Business: Complying with PCI Requirement 6.1

Establish software development processes

If you develop payment applications in-house (e.g., E-commerce websites, POS applications) you must use very strict development processes and secure coding guidelines as outlined in the PCI DSS.

Don’t forget to develop and test applications in accordance with industry accepted standards like the Open Web Application Security Project (OWASP). This will guide you in your application development process by enforcing secure coding practices and keep software code safe from malicious vulnerabilities (e.g., cross-site scripting, SQL injection, insecure communications, CSRF, etc.).

Use web application firewalls

Requirement 6In addition to updating and securing applications, web application firewalls (WAFs) should be implemented in front of public-facing web applications to monitor, detect, and prevent web-based attacks. They can also be used to perform application security assessments. Even though these solutions can’t perform the many functions of an all-purpose network firewall (e.g., network segmentation), they specialize in one specific area: monitoring and blocking web-based traffic.

A WAF can protect web applications visible or accessible from the Internet, including outward facing or intranet applications that involve payment card acceptance. As per PCI DSS regulations, your WAF must be up to date, generate audit logs, and either block cyber-attacks or generate a cyber security alert if an attack is suspected.

Migrate away from SSL and TLS

SSL and TLS 1.0 are no longer considered acceptable forms of encryption when data is transmitted over open, public networks. The PCI Council has recently extended the migration deadline from June 30, 2016 to June 30, 2018 because so many companies require more time to migrate their systems to at least TLS 1.2 or higher. It’s crucial that you move away from these versions to more secure versions as soon as possible.

SEE ALSO: DROWN Attack and SSL: What You Need to Know

While you work towards this goal, you are required by the PCI Council to write a Risk Mitigation/Migration Plan, which details how you will mitigate this risk until you’ve completed the migration.

Need help with PCI compliance? Talk to us!

George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.

SecurityMetrics 2017 Guide to PCI DSS Compliance
TRANSACT17 Conference: Wrap-up

Successful show, awesome people, great discussions!

Once again, TRANSACT17 was a remarkable conference! We met some fantastic people, saw some awesome booths, attended some inspirational presentations, and had a great time with our QSAs.

If you attended, hopefully your experience was a success. If you managed to visit our booth, thanks for stopping by! (Tell us what you thought of our booth in the comments below!)

If you didn’t get a chance to get your burning data security and PCI DSS questions answered at TRANSACT, please feel free to reach out to our data security experts who can help with your questions.

In addition to exhibiting, SecurityMetrics also sponsored this year’s TRANSACT golf tournament at the TPC Las Vegas Golf Course, and the weather could not have been more beautiful.

Congratulations to those that won prizes and got to take home some neat swag, including DJI Phantom 3 drones, “PCI Hero” t-shirts, and custom SecurityMetrics edition socks!

Here are some of our favorite pictures from the show and golf tournament!

Loved the setup

Thanks for stopping by our booth!


Having a great time at the golf tournament! 

Russ Stay with his team 

The best part is, we can’t wait to do it all again next year. See you at TRANSACT18 in Las Vegas in 2018!

WannaCrypt Ransomware Attacks: What You Should Do

Learn more about the recent ransomware attacks and how you should respond. 

By: Steve Snelgrove
Security Analyst
CISSP
You may have heard about the massive cyber-attack that happened on Friday, involving ransomware and Windows systems. Many organizations were affected by this attack and many more are still vulnerable.

Here are a few answered questions about the WannaCrypt attack and what your business should do to combat it.

What happened?

On May 12, WannaCrypt, also known as WannaCry, was used in a very large cyber-attack that that affected over 150 countries. Victims were told they could free their machines by paying the equivalent of US $300 in Bitcoin. The ransomware threatened to delete the files within 7 days if no payment is made.

Since then, the situation has been stabilized and the feared second wave of attacks has failed to happen.

The attack was contained by Marcus Hutchins, also known as Malware Tech, who registered a domain name to track the virus, which then stopped it from spreading. Since the malware relied on making requests to domains and ransoming the system when the connection wasn’t made, registering the domain essentially stopped the ransomware from spreading further. 


This sinkholing of the malware has stopped the rate of infection, though Hutchins warns that it may be only a temporary fix.

How does WannaCrypt spread?

The ransomware spreads through a vulnerability in the Server Message Block in Windows systems. The creators of WannaCrypt used the EternalBlue exploit and the DoublePulsar backdoor to create an entry in Windows systems.

Additionally, the malware was also spread through social engineering emails that tricked users to run the malware and activate the worm-spreading functionality with the SMB exploit. The malware itself was delivered in an infected Microsoft Word file that was sent in the email.

Who is affected?

Organizations that use Windows systems and have not yet patched the vulnerability are vulnerable to this attack.

Over 230,000 computers in 150 countries were crippled worldwide. Healthcare organizations in particular were affected by this ransomware, including many National Health Services hospitals in England.

What should organizations do?

WannaCrypt affects all Windows systems that haven't been updated to the latest version, or haven't had the vulnerability patched.
If you have a Windows system, update it as soon as possible.
You should stop using older versions of Windows right away.

If you have been attacked, experts advise that you don’t pay the ransom, since there is no guarantee that the hackers can even decrypt the encoded files after receiving the ransom payment.

It’s important to know that this attack likely won’t be the last one of its kind. This strand of ransomware attacks was released about two weeks ago, and it’s expected to increase through copycats.

SecurityMetrics is working on a solution that helps its customers identify whether or not their networks have communicated with known bad sites, which may lead to malware like ransomware. If you’re interested in learning more about this solution, email beta@securitymetrics.com

Need help with data security? Talk with one of our consultants!

Steven Snelgrove (CISSP) has been a Security Analyst at SecurityMetrics for over 7 years. Since 1980, Snelgrove has worked in the computer and telecommunications industry, and has familiarity with programming, software engineering, and network security. His current responsibilities includes the manual assessment of web applications and corporate networks, conducting ethical hacking to analyze security architecture, and consulting with organizations to help remediate issues. Snelgrove received a degree in Computer Science from Brigham Young University, and holds a CISSP (Certified Information Systems Security Professional) certification.

SAQ C-VT: The Basics You Should Know

Learn who qualifies for SAQ C-VT and what requirements apply.

By: Michael Simpson
Principal Security Analyst
QSA, CISSP
SAQ C-VT addresses requirements applicable to merchants who process cardholder data only through isolated virtual payment terminals on a personal computer connected to the Internet.

A virtual payment terminal is web-browser-based access to an acquirer, processor, or third-party service provider website to authorize payment card transactions, where the merchant manually enters payment card data through a securely connected web browser.
SAQ C-VT merchants may be brick-and-mortar or mail/telephone-order merchants.
Note: SAQ C-VT doesn’t apply to e-commerce only merchants. 

SEE ALSO: Updating PCI DSS SAQs to 3.2: The Changes You Should Know

Who qualifies for SAQ C-VT?

Not sure if you should fill out this SAQ? Here’s what qualifies you to fill out SAQ C-VT
  • Your company’s only payment processing is through a virtual payment terminal accessed by an Internet-connected web browser
  • Your company’s virtual payment terminal solution is provided and hosted by a PCI DSS validated third-party service provider
  • Your company accesses the PCI DSS-compliant virtual payment terminal solution through a computer that is isolated in a single location, and is not connected to other locations or systems within your environment 
  • Your company’s computer does not have software installed that causes cardholder data to be stored 
  • Your company’s computer does not have any attached hardware devices that are used to capture or store cardholder data 
  • Your company does not otherwise receive or transmit cardholder data electronically through any channels 
  • Any cardholder data your company retains is on paper and these documents are not received electronically
  • Your company does not store cardholder data in electronic format 

Which requirements does this SAQ cover?

The requirements you will address in SAQ C-VT include:
Remember that while this SAQ covers specific requirements, it’s important that you are compliant with all aspects of PCI compliance where applicable.

What questions will I address?

Here are some sample questions that you’ll answer while filling out this SAQ:
  • Is outbound traffic from the cardholder data environment to the Internet explicitly authorized?
  • If wireless networks are used, are default passwords/passphrases on access points changed at installation?
  • Is administrator access to web-based management interfaces encrypted with strong cryptography?
  • Are systems hardened using a configuration standard based on an industry-standard hardening guide?
  • Is sensitive authentication data deleted or rendered unrecoverable upon completion of the authorization process?
  • Are only trusted keys and/or certificates accepted?
  • Is anti-virus software deployed on all systems commonly affected by malicious software?
  • Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches?
  • Is access assigned based on individual personnel’s job classification and function?
  • Are all users assigned a unique ID before allowing them to access system components or cardholder data?
  • Is media classified so the sensitivity of the data can be determined?
  • Do security policy and procedures clearly define information security responsibilities for all personnel?

Additional tips

Getting compliant can be a complex process. Here are a few extra things to keep in mind while you fill out this SAQ:
  • Document everything: Make sure all processes and changes are properly documented. It keeps your business organized and reduces potential liability
  • Consider getting a vulnerability scan: while not required by this SAQ, it may be a good idea to scan your networks for potential vulnerabilities
  • Train employees: Your policies will do you no good if your employees aren’t following them
  • Work with an expert: If you don’t know much about security, or aren’t technically savvy, getting help from an expert will help make sure you’re protecting your data correctly
Remember, to determine your exact PCI DSS requirements, speak to a professional.

Need help getting PCI compliant? Talk to us! 

Michael Simpson (QSA, CISSP, CCNP) is a Principal Security Analyst at SecurityMetrics and has been in the IT Security industry for 15 years. He has a Bachelor of Science in Computer Science and a Masters in Business Administration.

New 3.2 Requirements for Service Providers: What You Should Know

Learn what new requirements service providers will need to fulfill.  

By: Christopher Skarda
Security Analyst
CISSP, QSA
PCI DSS 3.2 introduced several new requirements for service providers. Until January 31, 2018, these new/revised requirements will be considered best practice and will become requirements starting February 1, 2018.

Here’s a quick look at the new requirements and what service providers are expected to do.

Cryptographic architecture (3.5.1) 

service provider requirements
Service providers need to maintain a documented description of cryptographic architectures,
including:
  • Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date 

  • Description of the key usage for each key 

  • Inventory of any HSMs and other SCDs used for key management 

You should keep up with evolving threats to your architecture by planning for and documenting updates (e.g., different algorithms/key strengths changes). Maintaining documentation helps you detect lost or missing keys or key-management devices, and identify unauthorized additions to your cryptographic architecture. 


Timely detection and reporting (10.8, 10.8.1) 


Service providers are required to implement a timely detection and alerting process to identify failure of a critical security control systems.

Examples of critical security control systems include: 

  • Firewalls 

  • IDS/IPS 
  • FIM 

  • Anti-virus 

  • Physical access controls 

  • Logical access controls 

  • Audit logging mechanisms 

  • Segmentation controls (if used) 

Service providers need to respond to failures of any critical security controls in a timely manner.
Processes for responding to failures in security controls must include:
Restoring security functions 

  • Identifying and documenting the duration (date and time start to end) of the security failure 

  • Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause 

  • Identifying and addressing any security issues that arose during the failure 

  • Performing a risk assessment to determine whether further actions are required from the security failure 

  • Implementing controls to prevent cause of failure from reoccurring 

  • Resuming monitoring of security controls 


Establish responsibilities for PCI and Data (12.4.1) 

3.2 requirementsExecutive management needs to establish responsibility for the protection of card-holder data and a PCI DSS compliance program to include:
  • Overall accountability for maintaining PCI DSS compliance 

  • Defining a charter for a PCI DSS compliance program and communication to executive management 

Smaller organizations should add these roles to an individual’s job responsibilities, while larger organizations might need to establish a PCI compliance team (e.g., a compliance team made up of IT, accounting, and management).

Whichever is the case, management should give their PCI officer/team power to act and implement necessary changes to become PCI DSS compliant, as well as have at least monthly  meetings with executive management to report on progress. 


SEE ALSO: What are Service Provider Levels and How Do They Affect PCI Compliance?

Quarterly Personnel Reviews (12.11, 12.11.1) 


Service providers need to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes: 

  • Daily log reviews 

  • Firewall rule-set reviews 

  • Applying configuration standards to new systems 

  • Responding to security alerts 

  • Change management processes: In addition, you need to maintain documentation of quarterly review process, including: 

  • Documenting results of the reviews 

  • Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program 

These reviews help to ensure that security policies and procedures are being followed as expected. Keep records, including dates and findings of these quarterly reviews.

Penetration testing (11.3.4.1)

By February 1, 2018, service providers who use segmentation to isolate the cardholder data environment from other networks must perform penetration testing on segmentation controls at least every 6 months and after any changes to segmentation controls/methods.

This penetration testing should be performed by a qualified internal resource or third party. If an internal resource is used, the tester should have organizational independence (though they aren’t required to be a QSA or ASV). The purpose of penetration testing segmentation controls/methods is to verify that the cardholder data environment is protected from unauthorized access.

SEE ALSO: New 3.2 Requirements for Penetration Testing and Segmentation: What You Don’t Know

Need help with PCI compliance? Talk to one of our experts! 

Christopher Skarda (CISSP, QSA, CCNA) is a Security Analyst at SecurityMetrics and has worked in data security for thirteen years and the PCI sector for three years. He has a Bachelor of Science in Information Technology from BYU.