In the context of intrusion detection and prevention, PCI DSS requires implementation/configuration of Firewalls (Req 1), Anti-virus (Req 5) and Intrusion detection systems (IDS) (Req 11.4). Optionally, organizations are invited to consider the use of Intrusion Prevention Systems (IPS) in place or in addition to IDS (Req 11.4) as well as Web Application Firewalls (Req 6.6).
The first group of required protection systems is known as static systems. They do not dynamically modify their behavior. They maintain consistent, static behavior based on rules or signatures. One may compare them to the egyptian sphinx. Impressive, proud, but indifferent to the context.
Example of static protection systems:
- Intrusion detection systems (IDS) that log events, track context or have a multifaceted approach to detecting attacks, but action is limited to alerting (there is no intervention)
- Firewalls that are configured to block certain ports all the time but keep other ports open all the time
- VPN servers that reject entities with invalid credentials but permit entities with valid credentials
- Antivirus that blocks, quarantines, or deletes all known malware based on a database of defined “signatures” but permits all other perceived clean files
- Logging/monitoring systems, event and log aggregators, reporting engines.
The optional IPS and Web Application Firewalls are considered to be active systems. They dynamically modify their behavior based on information gathered traffic patterns.
One may compare them to profilers scrutinizing the crowd. Other examples of active protection systems:
- Firewalls that shun/block an IP address upon detection of a port scan from that IP address
- Next generation firewalls that shun/block IP address ranges based on previous network traffic patterns
- Spam filters that blacklist a sending IP address based on certain previous SMTP commands originating from that address.
- Anti-virus that uses patterns/behavior recognition
What Impact is there on quarterly scans?
11.2.2 requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). The intent is to identify all potential vulnerabilities from the hacker perspective. There is however a huge distinction between ASV scans and real attacks. The objective of real attackers is to intrude networks without being noticed. They take their time and use various stealth techniques to counter static protection systems and evade active mechanisms. The objective of the ASV scans is more humble: Identify the majority of potential issues in the shortest, and therefore most economical, time window. They can't afford the use of stealth techniques and don't bypass static protection systems. Like an elephant in a porcelain shop they awake all active mechanisms along their route, with an obvious impact on the accuracy of their reports.
To ensure a clear scanning path, PCI SSC asks organizations to ensure that their whatever static or active protection devices do not interfere with the ASV scans. More specifically they are required to configure intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) so they do not interfere with the ASV's scan. This obligation generates quite some discussions between ASV's and their customers. In an attempt to calm down the game, PCI SSC brought them around the table in order to find a way to perform quarterly scans that do not unnecessarily expose the scan customer's network but also do not limit the final results of the scans.
New rules for ASV's and their customers
As a result, PCI SSC has published a new version of its ASV Program Guide (V2.0 - May 2013) including new rules for ASV's and organizations in regards to blocked or filtered scans making the distinction between static and active protection systems.
ASV's must continue validate that scans have not been blocked or filtered but this time only by active protection system. Filtering or blocking actions by static protection systems should be discarded.
Would a scan be filtered or blocked through the action of an active device, ASV's are required to fail the scans, report the scan as “inconclusive” and clearly describe the conditions resulting in an inconclusive scan under "Exceptions, False Positives, or Compensating Controls”. Detection of such filtering/blocking events it's kind of hard. There are no clear defined techniques. It depends on the type of devices in place and their configurations. So without clarification from PCI SSC one could expect more complaints and discussions.
Organizations subjected to compliance must continue to ensure that their protection devices do not interfere with the ASV scan but only for active protection devices. Static protection systems or static rules would not have to be changed. Of course, applied changes would only be required for the duration of the scan. PCI SSC encourages organizations to work with the ASV to:
- Determine proper temporary configuration changes to prevent or remove interference during a scan.
- Agree on a time for the scan window each quarter to minimize how long changed configurations are in place.
- Conduct the scan during a maintenance window under the scan customer's standard change control processes, with full monitoring during the ASV scan.
- Configure the active protection systems to monitor and log, but not to act against, the originating IP address(es) of the ASV.
- Reapply the standard secure configurations as soon as the scan is complete.
In case of inconsistent scans (failed) due to blocked or filtered traffic, the scan customer may work with the ASV to implement one or more of the following options until a complete scan is achieved.
- Scan customer provides the ASV with sufficient written supporting evidence to support their assertion that the scan wasn't actually blocked. Scan customer and ASV work together to resolve scanning issues and schedule additional scan(s), as necessary, in order for the scan to complete.
- Scan customer and ASV agree on a method that allows the ASV scan solution to complete a scan without interference. For example, through implementation of a secure connection between the ASV and scan customer (such as an IPsec VPN tunnel), or installation of ASV scan solution (such as an appliance or agent) at the scan customer's site.
What kind of active protection devices are you using?
Are you concerned by the obligation to provide a clear path to the ASV's?
Did you read our previous newsletter: PCI 30 second newsletter #26 - PCIP is it worth it?