QID 86725 “F5 BIG-IP Load Balancer Internal IP Address Disclosure”
QID 86725 “F5 BIG-IP Load Balancer Internal IP Address Disclosure Vulnerability” will be marked as a PCI Fail as of May 1, 2018 in accordance with its CVSS score.
15 posts
PCI DSS v3.2 & Exposing Session ID in URL
Passing the session ID in the URL such as QID 150068 “Session ID in URL” will be marked as a Fail for PCI as of April 15, 2018 in accordance with PCI DSS v3.2.
If You Think File Integrity Monitoring is Boring, Think Again
You’ll be hard pressed to find file integrity monitoring on any list of cool, emerging, cutting-edge cybersecurity technologies. But if you choose to ignore this mature, foundational technology, it’ll be at great risk.
File integrity monitoring, or FIM, plays a key role in critical security and compliance scenarios. An effective FIM system can help you to promptly detect a variety of changes stemming from normal IT activity, compliance and change control violations, or malicious acts such as ransomware/malware attacks and configuration tampering. FIM can be your last line of detection for complex and evasive rootkits or mobile code. It is also invaluable in making sure validated scripts and configurations are not changed by insiders, malicious or not.
In this blog series, we’ll address the major uses for FIM, starting with regulatory compliance, and specifically the PCI DSS (Payment Card Industry Data Security Standard) mandate.
While FIM is an implicitly required control in many regulations for ensuring information integrity, it is explicitly mentioned in PCI DSS for any system handling personally identifiable information. The best practices and insights from those monitoring systems with FIM for PCI compliance are just as applicable to other regulations and mandates, such as HIPAA, GDPR and Sarbanes-Oxley.
PCI DSS v3.2 & Private IP Address Disclosure
Private IP addresses disclosure such as QID 86247 “Web Server Internal IP Address/Internal Network Name Disclosure Vulnerability” will be marked as a Fail for PCI as of February 1, 2018 in accordance with PCI DSS v3.2.
PCI DSS v3.2 & Migrating from SSL and Early TLS v1.1
SSL & Early TLS vulnerabilities such as QID 38628 “SSL/TLS Server supports TLSv1.0”\ will be marked as a Fail for PCI as of May 1, 2017 in accordance with the PCI DSS v3.2. For existing implementations, merchants will be able to submit a PCI False Positive / Exception Request and provide proof of their Risk Mitigation & Migration Plan, which will result in a pass for PCI until June 30, 2018.
Checklist: Qualys Top 10 Tips for a Secure & Compliant 2017
With 2017 still in its infancy, plenty of time remains for InfoSec practitioners to make concrete strides toward better security and compliance in their organizations. That’s why to help you start off the year on the right foot, we’ve shared best practices, ideas and recommendations in our Qualys Top 10 Tips for a Secure & Compliant 2017 blog series.
Slash Vendor Risk and Sharpen Compliance with Policies, Standards and Regulations
As we continue our Qualys Top 10 Tips for a Secure & Compliant 2017 blog series, we zoom in on the all important area of compliance and risk monitoring, a key element of any comprehensive security program.
IT compliance and risk managers don’t have it easy. You face an increasingly complex regulatory landscape, constantly evolving industry standards and a technology environment that’s changing at a dizzying pace. It falls on your shoulders to make sure your organizations follow rules, regulations, laws, standards and practices in areas of IT across all business functions.
In this post, we’ll offer tips 5 – 7 on our list, to help you:
- Ensure internal and external IT compliance
- Assess procedural and technical controls among vendors to reduce the risk of doing business with them
- Comply with the Payment Card Industry Data Security Standard (PCI DSS)
Qualys PCI Compliance Now Supports PCI DSS 3.1
The out-of-band release of Qualys PCI Compliance that adds support for PCI DSS 3.1 is out! The primary intention of this release is to address SSL and TLS encryption issues that have evolved recently. Effective immediately merchants are prohibited from implementing new technologies that rely on SSL or early TLS. SSL and early TLS cannot be used in any way as standalone security control after June 30, 2016. So basically merchants have about 14 months to remove SSL and early TLS from their environments. ‘Early TLS’ is TLS version 1.0 and in some cases 1.1 depending on where it’s used and how it’s implemented.
Qualys Adds Support for PCI DSS 3.0 in Qualys Policy Compliance
Comply with PCI DSS 3.0 using Mandate-Based Reporting in Qualys Policy Compliance
We are excited to announce an ‘out-of-box’, ready-to-use mandate-based policy for PCI DSS 3.0 consisting of security checks which automate assessment of ‘In-scope’ PCI assets. This policy will greatly simplify the process merchants have to go through to validate PCI compliance for a key set of technical controls that need to be validated across a wide set of different technologies. Qualys Policy Compliance can now automatically scan for all these PCI controls and provide you a detailed report that you can use to demonstrate ongoing compliance.
Meeting PCI Requirement 11.2 with QualysGuard
Your PCI 11.2 Checklist and Toolbox
Merchants are getting ready for the upcoming changes to the internal scanning requirements for PCI compliance. This blog post provides a checklist on what you should have ready and will review some of the tools Qualys provides for these requirements.
There are four core areas to focus on in preparation for your compliance to PCI 11.2, taking into account the changes from PCI 6.2 regarding risk ranking of vulnerabilities.
- Your documented PCI scope (cardholder dataenvironment)
- Your documented risk ranking process
- Your scanning tools
- Your scan reports
Merchants will need to complete each of these elements to be prepared to pass PCI compliance.
1. Your documented PCI scope (cardholder data environment)
All PCI requirements revolve around a cross-section of assets in your IT infrastructure that is directly involved in storage, processing, or transmitting payment card information. These IT assets are known as the cardholder data environment (CDE), and are the focus areas of the PCI DSS requirements.
These assets can exist in internal or external (public) networks and may be subject to different requirements based on what role they play in payment processing. These assets can be servers, routers, switches, workstations, databases, virtual machines or web applications; PCI refers to these assets as system components.
QualysGuard provides a capability to tag assets under management. The screenshot below shows an example of PCI scope being defined within the QualysGuard Asset Tagging module. It provides the ability to group internal assets (for 11.2.1), external assets (for 11.2.2), and both internal and external assets together (for 11.2.3).
This allows you to maintain documentation of your CDE directly, and to drive your scanning directly from your scope definition.
2. Your documented risk ranking process
This is the primary requirement associated with the June 30th deadline; this is the reference that should allow someone to reproduce your risk rankings for specific vulnerabilities.
The requirement references industry best practices, among other details, to consider in developing your risk ranking. It may help you to quickly adopt a common industry best practice and adapt it to your own environment. Two examples are the Qualys severity rating system, which is the default rating as per the security research team at Qualys; or, the PCI ASV Program Guide, which includes a rating system used by scanning vendors to complete external scanning. QualysGuard is used by 50 of the Forbes Global 100, and spans all market verticals; it qualifies as an industry best practice. Additionally, the QualysGuard platform is used by the majority of PCI Approved Scanning Vendors and already delivers rankings within the PCI ASV Program Guide practices.
The core rules of your risk rankings should take into account CVSS Base Scores, available from nearly all security intelligence feeds. These scores are also the base system used within the PCI ASV Program Guide. Your process should also account for system components in your cardholder data environment and vendor-provided criticality rankings, such as the Microsoft patch ranking system if your CDE includes Windows-based system components.
The process should include documentation that details the sources of security information you follow, how frequently you review the feeds, and how you respond to new information in the feeds. QualysGuard provides daily updates to the vulnerability knowledgebase and now offers a Zero-Day Analyzer service, which leverages data from the iDefense security intelligence feed.
3. Your scanning tools
After you have your scope clearly defined and you have your process for ranking vulnerabilities documented, you will need to be able to run vulnerability scans. This includes internal VM scans, external VM scans, PCI ASV scans (external), internal web application scans and external web application scans. It is thefindings in these scans that will map against your risk ranking process and allow you to produce the necessary scan reports.
You will need to be able to configure your scanning tools to check for “high” vulnerabilities, which will allow you to allocate resources to fix and resolve these issues as part of the normal vulnerability management program and workflow within your environment.
QualysGuard VM, QualysGuard WAS and QualysGuard PCI all work together seamlessly to provide each of these scans capabilities against the same group of assets that represent your PCI scope or CDE.
4. Your scan reports
You will want to produce reports for your internal PCI scope, as defined in #1 of this checklist, both quarterly and after any significant changes. If you have regular releases or updates to your IT infrastructure, you will want to have scan reports from those updates and upgrades. Quarterly scan reports need to be spaced apart by 90 days. In all cases, these reports need to show that there are no “high” vulnerabilities detected by your scanning tools.
Each report for the significant change events will also need to include external PCI scope. QualysGuard VM makes it easy to include both internal and external assets in the same report. QualysGuard VM also provides a direct link to your QualysGuard PCI merchant account for automation of your PCI ASV scan requirements.
QualysGuard WAS allows you to quickly meet your production web application scanning requirement (PCI 6.6) as well as internal web application scanning as part of your software development lifecycle (SDLC), by scanning your applications in development and in test.
If you follow these guidelines you will be well prepared to perform and maintain the required controls for PCI 11.2.