Maintaining compliance with PCI DSS requirements for
vulnerability scanning can present a number of challenges for companies. This blog post is aimed at tackling the
challenges of vulnerability scanning and present ideas for managing the
process, as well as evidencing it to your QSA.
The best starting point is to define the process for
vulnerability scanning. PCI DSS requires
the following:
- Scans are performed at least quarterly
- Scans must be performed by a qualified resource for internal scans (not required to be an ASV) and by an Approved Scanning Vendor (ASV) for external scans
- External vulnerability scans must satisfy the ASV program requirements
- Scans must be performed after significant change in the environment
- Scans must achieve a passing score (as defined in ASV requirements for external scans, and by having no vulnerabilities ranked as ‘high’ for internal scans)
These guidelines provide the control requirements for the
vulnerability scanning process within an organisation. Establishing a process
to satisfy those requirements can be difficult, because of size, complexity or
architectures that have been implemented.
When it comes to vulnerability scanning, it is much like any
other job you would rather ignore; the longer you leave it the more time,
effort and interruption it causes when you want or need to be doing something
else. Scanning more regularly, such as
monthly, is often touted by QSAs as being a good way to manage the process (and
it is) but it will not deliver the added benefits unless configurations and
security patching are managed correctly.
In order to perform a scan, you need to have identified what
systems are in scope for your internal and external scans and to have created
the appropriate profiles in the scanning configuration. Implementing network
segmentation can reduce the number of systems which need to be scanned. For the ASV scan, your ASV provider, under
the PCI SSC ASV Program Guidelines requires the following:
- Information about any scoping discrepancies must be indicated on the Attestation of Scan Compliance cover sheet under heading "Number of components found by ASV but not scanned because scan customer confirmed components were out of scope ". This information should NOT be factored into the compliance status:
- Include any IP address or domain that was previously provided to the ASV that has been removed at the request of the customer
- For each domain provided, look up the IP address of the domain to determine if it was already provided by the customer
- For each domain provided, perform a DNS forward lookup of common host-names – like ―www,‖ ―mail,‖ etc. – that were not provided by the customer
- Identify any IPs found during MX record DNS lookup
- Identify any IPs outside of scope reached via web redirects from in scope web-servers (includes all forms of redirect including: JavaScript, Meta redirect and HTTP codes 30x)
- Match domains found during crawling to user supplied domains to find undocumented domains belonging to the customer
I mention this because I can only name a few ASVs that I
have worked with through my clients who have demonstrated the processes
identified above. Just to note the
requirements of the vulnerability scanning processes require the organisation
or scan customer to acknowledge its responsibility to manage scope, and obligation
to properly inform the ASV provider about your environment, including any local
or external load balancers that may impact the scanning process.
For internal vulnerability scanning the chosen solution
should be managed by someone who is able to demonstrate sufficient knowledge to
perform the process. In order to achieve
this, the scope of scanning should be approved within the governance framework
of the organisation, and implemented within the chosen solution. The reports should always be passed back to
the team responsible for the process.
There are a number of tools available, from managed and
hosted solutions to customer implementations and free open source tools. I have been to clients with 100+ servers in
scope for PCI DSS assessment and have observed they are using scanning tools
which do not facilitate ease of issues review or remediation management. If you
want to scan large environments, investing in a tool which provides the
business useable reports is a must as, in the early days of this process,
remediation will likely be rather time consuming. All of the findings within the reports should be considered
for action, even if they are informational issues.
When assets are identified for scanning they
should be assigned an owner; this is the person who investigates the
remediation plan for the identified issue and documents the relevant change
control documentation to ensure the fixes are implemented. This is where functionality of the tools
selected to assist the business in maintaining compliance has to be considered.
I am always amazed at how limited the functionality is of some solutions, such
as only providing a PDF report, or CSV format download. It just makes the job
harder! A solution that can mirror the
internal governance structure of an organisation can save time, meetings and
other resources by just adding some work flow.
Managing the identified issues from a scan is important,
especially when a failure is noted.
Failures, as mentioned above, are in the instance of external scans
anything with a CVSS baseline score over 4.0 and for internal scans any issues
identified as ‘high’. The ASV program
guide suggests organisations attempt to address issues based on the CVSS
scoring. Any issues that have a failure
implication need to have the following:
- Root cause analysis (newly identified issue, security misconfiguration etc
- Action plan for remediation
- Communication and assessment of compensating controls (for external scans this is completed with the ASV)
- Change Management documentation
It is not just the changing security landscape that needs to
be managed for vulnerabilities. Changes
made to the environment, such as addition of new servers, or new applications
should always result in security testing being completed. Prior to any other security testing, a full
vulnerability scan on internal and external changes should be completed. This should be the case even if you are going
to complete penetration testing, as this will ensure that the tester’s time is
spent on harder tasks rather than on the ‘low hanging fruit’.
Where an organisation has established and embedded change
management procedures and governance structures such as a Change Advisory
Board, these should be closely aligned and involved in the vulnerability
scanning process. The ability to manage changes in the environment securely and
in line with company processes will provide key documented evidence to the QSA
that robust processes are in operation.
Part two of this post will cover the following item in more
detail than they have been touched on in this post:
- How do you know you’re doing it right?
- Scan profiles
- False positives
- Compensating controls
Hi,
ReplyDeleteNice thought with this blog I enjoy studying and I conceive this website got some truly utilitarian stuff on it!
Attestation Of Compliance