As a citizen of the HPE NonStop community, it is sometimes hard to believe how much my work has changed over 25 years. Compliance frameworks such as PCI DSS now demand as much of my attention as robust performance or maintaining the five nines. Consciously, I realize that adhering to standards isn’t a chore to be marginalized. But I must admit that I’ve allowed this focus to wander. The transformation of this platform combined with the “do more with less” doctrine has influenced me to prioritize higher visibility projects. I am re-considering those priorities. Boosting database performance, patching memory leaks, and leveraging virtualization are terrific, but what will happen to support for these worthy endeavors if we fail audits, lose compliance, or worst of all, suffer a breach?
According to a recent report by SecurityMetrics:
NONE OF THE BREACHED MERCHANTS INVESTIGATED IN 2016 WERE FOUND TO BE FULLY PCI DSS COMPLIANT1
It ain’t that way no more…
The HPE NonStop Server traditionally considers itself a castle: An impregnable island fortress granting access only to a select few. If you didn’t belong inside, you didn’t get in. There was never a need to test the castle walls for weaknesses.
That was arguably true – prior to increased inter-platform communication, widespread acceptance of the internet, WANs, wireless networking, high speed clusters, distributed databases, disaster recovery/business continuity, remote access, BYOD and migration from proprietary to open standards. All of the above introduced NonStop to the possible security vulnerabilities inherent in these constructs. We are reluctantly forced to allow ongoing vulnerability testing – internal and external.
So as a vigilant NonStop sentry, I‘d like recommend two things to reclaim fortress stature :
- Implement what many security pros agree are three essential PCI DSS 3.2 standard aspects which are soon to graduate from best practice status to requirement
- Leverage tools which meet the requirements that are already available to all NonStop users.
Eliminate use of SSL and early TLS versions by June 20 2018 (Requirement 4.1)
Actually, this touches three PCI DSS requirements:
- Requirement 2.2.3: Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
- Requirement 2.3: Encrypt all non-console administrative access using strong cryptography.
- Requirement 4.1: Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
This issue has been well-known for some time. In fact, PCI 3.1 set a deadline for SSL/TLS mitigation by June 30, 2016. Since then, Heartbleed, POODLE, DROWN, FREAK and SWEET32 vulnerabilities forced a re-evaluation of the requirement for PCI DSS 3.2. Current practice is to disallow all SSL versions as well as TLS 1.0x and move towards TLS 1.2. TLS 1.2 supports AES ciphersuites in 128 and 256 bit key lengths.
The difficulty for most implementations will likely be the TLS level on the remote endpoints. Session negotiations are determined by the highest ranked protocol available on both sides.
If one side’s latest available TLS version is 1.0, then the other side will be forced either to allow non-compliant TLS sessions or not connect at all.
SSL/TLS vulnerabilities are being taken so seriously that many organizations are scanning their internal networks to identify SSL/early TLS traffic – some are even blocking such traffic !
Perimeter defenses like firewalls and trusted zones do not exempt servers from Requirement 4.1. Authorized access must protect data in motion with strong cryptography – period.
Req 4.1 permits TLS 1.1 on existing implementations, but new implementations must use TLS 1.2.
Current NonStop OS RVUs are capable of supporting TLS versions through 1.2 and suppression of SSL so we can control our side of the implementation.
One survey of SSL/TLS usage for VPNs as of December 2016 show 77% still allow SSL and/or early TLS, and fewer than 3% are PCI DSS compliant.2
Considering 40% of attacks involve so-called “encryption abuse”2 – meaning attackers usurp victims’ encryption to hide their activities – a quick migration of both endpoints to TLS 1.2 would be a worthwhile effort.
One quick final note on this: SSH is a good alternative, particularly for NonStop. Recent RVUs include SSH capability which is based upon openSSH 7.2p2 or later.
Implementation of Multi Factor Authentication for ALL non-console remote access by February 1 2018 (Requirement 8.3.1)
Right now, this is considered by most security and compliance experts as the best tool for preventing intrusion and subsequent malicious activity. Multi-factor authentication (MFA) offers the best bang for the buck. Every entry point from phones (pardon me – mobile devices) to PCs to web sites to servers either requires MFA or will require it very soon. The Reason: Higher reliability of correctly authenticating access requests. Identity thieves may steal passwords or even fingerprints, but it’s less likely that they can steal 2 or more factors. Even better are factors which are single-use and /or valid for very short durations.
The change from PCI DSS 3.1 to 3.2:
Expanded Requirement 8.3 into sub-requirements, to require multi-factor authentication for all personnel with non-console administrative access, and all personnel with remote access to the Card Data Environment (CDE). New Requirement 8.3.2 addresses multi-factor authentication for all personnel with remote access to the CDE (incorporates former Requirement 8.3). New Requirement 8.3.1 addresses multi-factor authentication for all personnel with non-console administrative access to the CDE. Requirement 8.3.1 effective February 1, 2018
In summary, as of February 1 2018, MFA will be required for ALL administrative/remote access to cardholder data – not just consoles.
I envision many heated discussions regarding where the cardholder data environment (CDE) perimeters are and which users have access to it. Perhaps these could be better described as re-heated discussions. Not only has this issue been the subject of previous debates, but the CDE may have changed since the last time this battle has been fought.
The PCI council foresaw this and has published a document which, along with network segmentation, offers recommendations on how to determine PCI’s definition of CDE in your organization: https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
User acceptance will also be a major issue related to MFA. More affected users mean higher support call volume, lower productivity, and potentially user/customer dissatisfaction and lost revenue. This is why CDE definition and access are contentious topics.
The temptation will be to reduce the number of MFA-required circumstances as much as possible – applying to only those that strictly adhere to the latest PCI DSS defined requirements.
I would counter propose that more MFA – not less – would yield the greatest returns:
- MFA processing consumes very few system resources – network, disk, and cpu
- As mentioned earlier, most users are already experiencing MFA and are quickly adapting, accepting, even demanding MFA for access to sensitive information
- Future PCI DSS standards likely will expand MFA requirements to all access by all users
XYGATE User Authentication (XUA), which is bundled in all current NonStop OS RVUs, provides the necessary functionality for MFA when teamed with RSA or RADIUS security solutions. Once configured, this is as close to “set it and forget it” as there is.
More statistics: Depending on which source you consult, between 63 and 91% of all data breaches involve weak authentication (i.e. passwords/phrases). 3 4
MFA is an inexpensive and readily available countermeasure against intrusion.
Two important items to consider regarding your MFA implementation:
- Engage your RSA/RADIUS team as early as possible. Corporate RSA teams are going to become overwhelmed very quickly as everyone scrambles to meet the February 1 2018 deadline.
- As of this writing, Feb. 1 2018 is 5 months from now. You may want to start developing your strategy now – most MFA implementations take at least 4-6 months to deploy organization-wide before going into production.
Maintain detailed documentation of cryptographic architecture (Requirement 3.5.1)
This requirement is different than the other two. Req 3.5.1 actually applies only to service providers and refers to documentation:
New requirement for service providers to maintain a documented description of the cryptographic architecture. Effective February 1, 2018
If you don’t have a cryptographic architecture, you can’t meet Req 3.5.1.
Requisite 3 is concerned with protecting stored cardholder data, meaning data at rest. Primary Account Numbers (PANs) are the most common data grail; therefore, they garner most of the Req 3 attention. The scope of CDE tends to expand as payment processing gets more complex and interrelated with other sensitive data.
Once again, we can get mired in the CDE jurisdiction argument.
My experience in NonStop has fostered a need to explore worst-case scenarios and how to deal with them. In the case of cardholder data, theft is the worst-case scenario (alongside destruction or deletion of said data).
Cardholder data theft cannot be totally prevented. But we can make the stolen goods useless to the thief. This is the intent of Requirement 3.
This can be accomplished one of two ways: Encrypting data within the CDE or exempting data from the CDE.
Encryption is a well-established and reasonably trusted method of data obfuscation. Most enterprises use a shared encryption engine across all its platforms, thus making the solution simpler and more affordable.
For PCI DSS compliance, encryption does NOT exempt data from being classified as part of the CDE and thus is subject to Requirement 3 scrutiny.
Data tokenization is an increasingly popular way of excluding PAN data from the CDE. Tokenization supplants PANs or other surrogate data with tokens. These tokens have no intrinsic value and cannot be traced to the corresponding source without authorized de-tokenization and authentication.
Under PCI DSS 3.2, tokenized data IS excluded from the CDE, which is why it is becoming so popular.
While encryption or tokenization are not currently required to meet PCI DSS Req 3 standards, Req 3.5.1 is an indication that such a requirement will occur in the future – probably the near future. Not necessarily just for service providers.
HPE SecureData Transparent Data Protection for HPE NonStop offers both encryption and tokenization services without any coding changes.
Re-invent the fortress
Three major PCI DSS requirements. Three readily available tools; HPE SSH, XYGATE User Authentication and HPE Data Security’s SecureData for NonStop allow you to meet those requirements.
XYPRO, along with HPE have dedicated extensive time and resources in evaluating how PCI DSS 3.2 will affect the HPE NonStop Server ecosystem and its customers. These requirements become mandatory in 2018. We recommend the activities to become compliant with the new standard start before the mandatory deadline dates in 2018. This will ensure your organization has enough time for testing and deploying to production. Please visit the www.XYPRO.com to download the latest version of the PCI DSS 3.2 White Paper which describes how to make your NonStop servers PCI DSS Compliant.
- Verizon 2017 Data Breach Investigations Report
About the Author
I’ve been an IT serf since 1989. Worked on Tandem/NonStop since 1993 as an operator, application support tech, system administrator, and security administrator. Currently I am a Security Solutions Specialist for XYPRO.
I graduated from the University of South Florida with a B.A. in US History. During downtime I perform with trumpet/trombone jazz and brass ensembles, indulge in car restoration and enhancement, and dabble in screenwriting / playwriting.
Upcoming hobbies: motorcycling, bicycling, off-road trucking, diesel powered vehicles, and voiceover freelancing for fun and profit. My primary port-of-call is Columbus, Ohio