PCI DSSWhy so many unsupported systems?
One of the things we often come across in risk and compliance assessments is that of unsupported operating systems or applications – more than we ever should be really. It’s a given (or I should probably say an assumption) that we all understand how important patching can be to keep systems up to date with vendor-supplied security patches in order to protect systems from known vulnerabilities. But how do you do that if the application or operating system is no longer supported?
Unsupported systems are a really big red flag when it comes to security risk or compliance assessments.
For example PCI DSS Requirements 6.1 and 6.2 is all about identifying vulnerabilities and then patching them. As the PCI SSC put it in the Guidance for requirement 6.2 “There is a constant stream of attacks using widely published exploits, often called “zero day” (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. If the most recent patches are not implemented on critical systems as soon as possible a malicious individual can use these exploits to attack or disable a system, or gain access to sensitive data.”
So again patching is important. But how do you patch what isn’t supported and is there an alternative solution if you find yourself in this predicament? No doubt there will be an occasional case of a critical application that only works on what is now an unsupported operating system. To be honest, if that is the case its a pretty good chance the application is no longer supported either. At this stage, I am hoping if you find yourself in this situation, you already have a roadmap to update, retire or replace that application – if not make one. In the interim you will need to conduct a risk assessment of the environment and conduct some threat modelling to determine what your risk and attack vectors may be. You can then develop some compensating controls to make up for the “holes” left by systems or applications that cannot be patched.
Word to the wise though, not everything will be able to be covered by a compensating control.
It then becomes a decision based on your company’s risk appetite as to whether or not the risk to continue to use such systems will be accepted. If the systems in question contains data that relates to privacy, or things like credit card data, it probably shouldn’t be an acceptable risk. In the case of such data, if the compensating controls are inadequate you may find yourself non-compliant against standards like Payment Card Industry Data Security Standard (PCI DSS) or General Data Protection Regulation (GDPR).
There are other compliance issues you may face, especially if an unsupported operating system is Internet-facing, because it will be detected and reported as an automatic failure by an Approved Scanning Vendor (ASV) scan. In which case your PCI DSS compliance is in jeopardy again.
As the PCI SSC states in FAQ 1130 “The use of compensating controls should be considered a temporary solution only, as the eventual solution is to upgrade to a supported operating system, and the entity should have an active migration plan for doing so.”
Often application and operating system vendors will have detailed roadmaps that highlight the end-of-life or a product and when it will no longer be supported. Often that information is known well beforehand, so it seems somewhat inexcusable to find ourselves in this type of scenario. However the cost of upgrades can play a role, and sometimes the hardware is the limiting factor – think manufacturing machines or even ATMs. Such hardware can be unyielding to new operating systems and alike. But either way, anything that poses a risk as a result of an unsupported operating system or application should already be on an active migration plan, or retirement plan, somewhere. Don’t let it slide because the longer you do, the bigger your risk.
_______________________
SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.
CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.
_______________________
Written by Brian Odian
Brian Odian is the Director of Asia Pacific Global Compliance & Risk Services Consulting at SecureTrust, based in Sydney. He has over 32 years IT industry experience including roles as a Security Delivery Manager and Global Security and Transformation Lead for large worldwide information technology corporations. During his career he has been across a wide range of industries and roles, including global management experience across multiple cultures and business environments.
Experienced in running global security programs, and some of the largest regional projects in Asia Pacific, Brian brings a mix of project management, security and compliance credentials together (CISM, CRISC,PMP, QSA, ISO27001 IA) to achieve the best results in delivering security solutions and compliance programs. He has been published by the Project Management Institute (PMI) and MSSP Alert along with conducting webinars on the General Data Protection Regulation (GDPR) and Compliance Intelligence. He has also presented on PCI Compliance for some of the “big four” banks and the Customer Owned Banking Association (COBA).