One of our QSAs accidentally had their QSA certification lapse and had to go back through in-person QSA training. As a result, all of us in the PCI practice got an opportunity to get caught up on the latest and greatest guidance that the PCI SSC is passing along in their current QSA training. Even though QSAs and ISAs have to go through re-certification training and testing annually, having people go through the in-person training is the only way in some cases to get insight into the latest thinking of the Council.
One of the areas we specifically asked the person to ask their PCI trainer about was unsupported operating systems (OSes) and applications. In the past, such unsupported environments were considered automatically non-PCI compliant because of the ASV automatic failure rules documented in the ASV Program Guide v2.0. As a result, most QSAs constantly get push back from some clients when we encounter unsupported OSes and/or applications. However, we were shocked to find out from our colleague that the Council is no longer advising QSAs and ISAs to automatically mark as non-PCI compliant unsupported OSes and application software unless they are externally facing.
Now before you go off telling management that expensive upgrades are no longer necessary for internal systems and yelling “Alleluia” to the PCI Gods, there are, as you should expect, some caveats to all of this.
First, this is not the Council condoning the use of unsupported OSes and application software. The Council will still tell you that organizations should be using current and supported OSes and application software. This is merely a recognition that upgrades to a supported environment are not always an option in all cases. As a result, organizations might only be able to use unsupported operating systems and applications given hardware and/or customization constraints.
And just so we are all on the same page. Externally facing unsupported OSes and/or application software is still an automatic PCI compliance failure per the latest version of the ASV Program Guide.
Second, in order to continue to use unsupported OSes and applications, your organization will have to create compensating control worksheets for relevant PCI DSS requirements. The first problem with compensating controls is that the controls must go “above and beyond” the controls required by the PCI DSS. So any controls you use to compensate for your unsupported environment must either be not required by the PCI DSS or must go beyond the stated PCI DSS requirements. For example, white listing of installed applications is not a PCI DSS requirement, so that can be used as an effective control. An example of going above and beyond is doing near real-time monitoring of log data because log data is only required to be reviewed daily. For more on writing compensating controls, see my post on the subject.
Which brings up an interesting dilemma depending on the unsupported environment. As a prime example, developing a compensating control for Windows 2000 or Windows ME is probably not going to be possible no matter how many compensating controls you can document in the worksheet. The primary issue that will make this impossible is because of what those older operating systems do to a domain in order to be joined in the domain. The resulting downgrades in security create a litany of issues that no amount of compensating controls will be able to address.
Which points out that just because you make an attempt at compensating controls does not mean that effort will result in something effective or even acceptable to your QSA/ISA. All of those compensating controls for all of the requirements must be in place, operating as designed and assessed as part of your PCI assessment. This is not something you can just toss together at the last minute and hope it will pass muster. As a result, you need to be prepared to admit that there will be instances where the older OSes and/or applications just cannot be compensated for no matter how many other controls you think can implement.
Third, if your organization is going to use unsupported OSes and/or application software, then your organization is going to have to mitigate the risks of this practice. So what mitigations would a QSA/ISA expect to see? Here are a few thoughts.
- Severely locking down the OS. This is typically done by a utility that white lists the OS and applications on the system. If anything tries to install on the system, it is stopped and an alert is generated.
- Enabling the generation of all possible log data by the unsupported OS and/or application. Essentially logging all activity from the unsupported OS and/or application. All of this log data feeds the next bullet.
- Conducting near real time analysis of all log data produced by the unsupported OS and/or application. This will require the use of a system incident and event monitoring (SIEM) solution configured with rules looking for anomalies related to threats to the unsupported OS and/or application. And I can hear people asking now, what are the anomalies I should be looking? See the next bullet.
- Identification of new threats to the unsupported OSes and/or applications. Threat identification can come from vendors of the unsupported OSes and/or applications as well as from sources such as US CERT, anti-virus vendors and other recognized threat sources. And this is not going to just be some monthly, quarterly or other “periodic” exercise, this is going to have to be an active daily exercise and you will need to prove that it is conducted as such.
And finally do not bother to go through some sort of Rube Goldberg process of bizarre, twisted and convoluted logic you think will get you can pass. There is nothing worse than sending your QSA/ISA through some sort of circular logic that in the end never gets your unsupported OSes and/or applications any closer to being protected than when you started. I have encountered too many instances of a lot of words, pages and diagrams that have no meaning for PCI compliance other than being a lot of words, pages and diagrams all in the hope of baffling the QSA/ISA with a lot of words, pages and diagrams.
All we as QSAs and ISAs ask is that you be intelligent and judicial in what you choose not to upgrade or update.
PCI Guru 
It seems to me that PCI DSS guidance is clear regarding unsupported OS and application software but I’m not certain how the requirement applies to unsupported application components. What about software written in-house using widely available open-source libraries, for example Apache Struts or OpenSSL? What’s the definition of support in the context of open source libraries? If a component of the in-house application uses a deprecated library is the entire application considered unsupported?
These are some of the questions with which I am struggling as I help my client prepare for the 2016 assessment.
It is assumed that in-house written software is still supported by the entity that had it written. However, even when written in-house, it is not surprising to find that the developers that developed the in-house software are now gone and there really is no more support.
In regards to open source, that is another story. If your application relies on open source that is no longer supported then you have an unsupported application. This is what is going on with some applications that used OpenSSL and baked it into firmware for embedded devices. When the Council killed SSL, there were a lot of embedded systems that got caught because there was no update to their version of OpenSSL. In a number of cases, the vendor’s only option was to tell their customers to buy new embedded systems.
Does anyone know of an instance where compensating controls were accepted in lieu of a supported operating system? Seems like any QSA with half a brain would treat that like the plague.
I have not done one yet. That said, everyone thinks of Windows and Linux when talking about this subject. But what about older versions of MVS, VMS, MPE and the like? That is where I see this being more applicable than with Windows or Linux. As I said in the post, some older versions of Windows are going to impossible to develop a compensating control worksheet for given all of the issues they create.
How would you interpret, in the Brick & Mortar POS industry that my company supports, the difference between EXTERNALLY FACING (OS and Apps) and whatever the “other” is (which I assume would be “internally facing”)?
Or, to put my question a different way, what constitutes an “EXTERNALLY FACING OS” (and Apps) in he Brick & Mortar POS industry?
Do you mean the OS and App, solely in the POS terminal only?
Or would the on premise, back ofice POS Server also be included in that analogy?
Or something entirely different?
“Externally facing” means a system/device that can be accessed via the Internet or other public network. The best example of an externally facing system is obviously an eCommerce Web server.
However, I have encountered POS systems, database servers, firewalls, switches and other devices that were Internet facing and only protected by logon credentials. With the right credentials, you could logon to these systems and do some real damage. And to be clear, just because a system has access to the Internet does not mean that it is “externally facing”. So in the vernacular of PCI, “externally facing” systems are those that can be access from a public network into the private network.
That said, depending on how some corporations structure their networks, the retail network may be externally facing if a third party is directly connected to that network and has access to the retail locations.
Well, as you’ve said, personal training is almost the only way to get Council’s opinion in any matter at this point. E-mails are not replied as soon as they should.
My concern about this kind of things is how a QSA is supposed to use this Council approach for their decisions since there is no documentation at any place that defines this other then the PCI trainer sharing positions with the QSA that attended a course?
At this time, we have, as you said, the “ASV Program Guide v2.0” stating that unsupported OSes are not allowed and an individual sharing positions with no official documentation. In terms of audits, this lack of documented official position on several items always leads to discussions by the time an incident occurs.
I know PCI as a regulation has a lot of flaws but, unless I’m missing some Council resources, I still think that the lack of a central official forum with PCI Council SMEs (Subject Matter Experts) is the biggest one.
Thank a lot, as always, for this invaluable resource you provide for the QSAs community.
All you can do is ask the Council the question and then wait for them to respond.
BTW It’s not entirely the Council’s fault for the time it takes to get a response. Responses must go through not only the appropriate Council resources, but the card brands (i.e., Visa, MasterCard, American Express, Discover and JCB) must also be consulted. As a result, getting concurrence from all of those involved can take some time.
For UK Gov PSN compliance we manage short mitigations for obsolete software against an internal policy and procedure based on any supplier guidance and https://www.gov.uk/government/publications/obsolete-platforms-security-guidance/obsolete-platforms-security-guidance#mitigations-to-reduce-the-likelihood-of-compromise
Might be useful, common themes.