09
Jun
17

We Need A Change To 2.3.b

I just wanted to give everyone a “heads up” about some guidance we recently received from the PCI SSC regarding jump boxes or out-of-band (OOB) system management solutions and the use of insecure protocols such as SNMPv1/2 and Telnet.

But did everyone know that this solution also requires a compensating control worksheet (CCW)?

For years (at least since the Phoenix Community Meeting years ago), the Council has been recommending the use of firewalls and jump boxes as a way to secure instances where organizations need to use insecure protocols.  These enclaves are firewalled, VLAN’d and configured so that only the jump box can be used to remotely connect to the devices over Telnet and allowing other insecure protocols to be kept away from other networks.  However, I do not recall any of those discussions ever explicitly calling out the need for a CCW.  I suppose the Council just figured we would all be bright enough to write one up.

What led me to this revelation you ask?

When I was going through my QSA Requalification this spring, they had a scenario with a jump box solution.  One of the questions related to the scenario involved how you would create a CCW for the insecure protocols used in the administrative VLAN that the jump box provided access.  While I answered the questions correctly, it triggered a new question regarding why a CCW was needed in the first place.

Then when the question was posed back to the Council, we got a reply indicating that a CCW would be required because of requirement 2.3.b which states:

“Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.”

The problem with the requirement is that it treats all Telnet with equal distain regardless of risk.  Yes, Telnet is always a clear text protocol, but when it is buried two or three layers away from any general network or the internet and requires administrator credentials and MFA, it is hardly as “at risk” as it would be when PCI started over 15 years ago and networks were as flat as a piece of paper.

As a result, I would like to recommend that the Council work to change 2.3.b to take into account the use of network segmentation, firewalls, VLANs, ACLs, MFA and jump boxes to allow the use of Telnet and insecure protocols when in a properly isolated and secure environment.  It seems silly to me that someone goes through all of the right steps to secure their environment only to be told that they still need a compensating controls to meet a requirement that does not reflect the real risk.

The other reason I feel this needs to be addressed is that a lot of banks and processors seem to see CCWs as a huge red flag.  Something to be avoided at all costs because it implies to them non-compliance.  And non-compliance is a “bad” thing.  I cannot tell you the collective hand wringing some banks go through for really simple CCWs all because they do not want to have any PCI assessments with CCWs.

Ultimately I think this all comes down to the fact that those banks and processors have no clue as to the amount of risk any CCW presents.  This is because most banks and processors staff their PCI compliance areas with auditors and compliance professionals, not technicians.  Given that the PCI DSS is predominately all about security technology and its implementation, these auditors and compliance people are not equipped to make the decisions that typically need to be made regarding CCWs.  As a result, they are all high risk in their eyes and treated accordingly.

Hopefully the Council can address this situation and we can avoid needless documentation for a preferred “best practice”.

Advertisements

8 Responses to “We Need A Change To 2.3.b”


  1. October 31, 2017 at 12:11 PM

    As a result, I would like to recommend that the Council work to change 2.3.b to take into account the use of network segmentation, firewalls, VLANs, ACLs, MFA and jump boxes to allow the use of Telnet and insecure protocols when in a properly isolated and secure environment. It seems silly to me that someone goes through all of the right steps to secure their environment only to be told that they still need a compensating controls to meet a requirement that does not reflect the real risk.

    Amen!

  2. June 9, 2017 at 12:20 PM

    Well, the powers that be have their own risks too, such as adding a load of language and subrequirements to the DSS. You’re proposing they add something to the effect that when telnet is buried under a few layers of security, that it be allowed. How exactly do they add that to the DSS? What constitutes adequate protection? How many bullets will it take, and will it be complete? Easier to say currently strong encryption is OK, and anything else, let the QSA do the legwork of a CCW.

    • June 9, 2017 at 1:03 PM

      As I stated, there are still banks that see any CCW as “bad” and should not be included. But I get your point. It’s just do we want a standard that never changes with the “best practices” being followed? Eventually every requirement will require a CCW under that sort of approach.

  3. 4 Felix
    June 9, 2017 at 4:45 AM

    I agree with you, there must be a change to 2.3.b. Although it might be required to enforced documentation, while I can see that this system will come out of compliance during the internal scans and internal penetration testing.

    • June 9, 2017 at 1:06 PM

      If a pen tester or scanner cannot get into the CDE or the admin VLAN, then that should be proof enough. It’s the pen testing and scanning without context that is wrong. If you have to physically move the pen testing and scanning equipment’s network connections because of firewalls and other controls to get them done, that in and of itself should be an indication that controls are in place and working.

      • October 31, 2017 at 12:33 PM

        If a pen tester or scanner cannot get into the CDE or the admin VLAN, then that should be proof enough. It’s the pen testing and scanning without context that is wrong. If you have to physically move the pen testing and scanning equipment’s network connections because of firewalls and other controls to get them done, that in and of itself should be an indication that controls are in place and working.

        And yet … your QSA could insist that you change your FW rules to allow the pentester to access the CDE. I was speechless before blurting out “how do I know he won’t introduce malware or attack the system?”

      • November 11, 2017 at 4:39 PM

        Most pen testers prefer to have the pen testing system moved into the CDE as firewalls can still create issues even when supposedly every port is unblocked.

        BTW You are required to test inside the CDE as well as outside of it to prove segmentation as well as that no exploitable vulnerabilities exist in the CDE systems/devices.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

June 2017
M T W T F S S
« May   Jul »
 1234
567891011
12131415161718
19202122232425
2627282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,899 other followers


%d bloggers like this: