Wednesday, December 2, 2015

Segmentation Checking for PCI Requirement 11.3.4

PCI 3.0 introduced Requirement 11.3.4: “If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.” The PCI DSS v3.0 Requirements and Security Assessment Procedures Testing Procedures specified for Requirement 11.3.4.a also states “Examine segmentation controls and review penetration-testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from in-scope systems.” 

This requirement is intended to verify that network segments documented as out-of-scope are truly out-of-scope and that this has been verified by someone with a degree of technical expertise. The scary parts of this standard are the “All segmentation methods” and "all out-of-scope systems from in-scope systems.” That could be quite a task depending on the number of methods used to provide segmentation and the number of out-of-scope systems.

Fortunately, the Special Interest Group on Penetration Testing, of which I was honored to be the co-proposer and a lead contributor,  was in the midst of finalizing its guidance. Recognizing that, as written, this requirement could place an unrealistic burden on Merchants and Service Providers, we were able to work with the Council to provide the option for sampling. This excerpt from the guidance addresses 11.3.4:

Segmentation Checks
"PCI DSS Requirement 11.3.4 requires penetration testing to validate that segmentation controls and methods are operational, effective, and isolate all out-of-scope systems from systems in the CDE. Therefore, a robust approach to penetration testing is recommended to satisfy this requirement by actively attempting to identify routes and paths from networks outside the CDE into the CDE. All segmentation methods need to be specifically tested. In very large networks, with numerous internal LAN segments, it may be infeasible for the penetration tester to conduct specific tests from every individual LAN segment. In this case, the testing needs to be planned to examine each type of segmentation methodology in use (i.e., firewall, VLAN ACL, etc.) in order to validate the effectiveness of the segmentation controls. The level of testing for each segmentation methodology should provide assurance that the methodology is effective in all instances of use. In order to effectively validate the segmentation methodologies, it is expected that the penetration tester has worked with the organization (or the organization’s QSA) to clearly understand all methodologies in use in order to provide complete coverage when testing."

As long as the testing provides assurances that the segmentation methodology is effective, testing from every individual LAN segment is not necessary. My recommended approach is to perform testing from network segments where privileged users securely access the CDE and sample a reasonable number of all other segments for each type of segmentation methodology in use. This will meet the requirement without putting undue burden on the client while providing the assessor  or auditor with sufficient information on which to base a determination of segmentation effectiveness.

Friday, June 5, 2015

Do you need to do an internal pen test when the CDE is in the Cloud?

We have a Cloud based, virtual data center that we access and manage using a 2-factor, on-demand VPN to a remote jump-box from anywhere in the world. As a result, our corporate network and admin machines are considered out-of-scope for PCI. Do we still need to do an internal penetration test?

Our experience is that these tests are limited and quick, however they must be done.  While it’s true that in this case the in-scope systems could just as easily be administered from a Starbucks, the administrator’s workstation in a Starbucks cannot easily be compromised by exploiting other systems in the coffee shop, whereas in the corporate network the administrator's system is often joined to a domain and can be affected by other systems in the domain. The environment where users routinely access in scope systems will present an attacker with a unique opportunity to steal those credentials or manipulate that traffic.  Such an opportunity would not be afforded to an attacker in a Starbucks. The interrelationship of systems inside the corporate network creates a unique set a threat vectors that must be tested.

So for PCI Pen Testing, a corporate network is defined as having a common network connect AND localized common resources such as file shares and authentication mechanisms.

Monday, May 11, 2015

SharePoint Resource Monitoring

Testing a SharePoint application? Worried that your tests could knock the server over? (Want to knock the server over? This applies to you too.)

One of the new features of SharePoint 2010+ is resource throttling when the system is a bit busy handling requests. This can be tuned on at Web Application level in Central Admin. That throttling uses the health score value. If the value becomes 10 or above it will go into throttling mode. At that point it will give GET requests a lower priority than other types like POST. So people can finish the form they are filling in, but new request will be denied.

Enter the X-SharePointHealthScore HTTP Header.

It's a header that returns the systems health based on 3 performance counters:

Memory - Available MBytes
ASP.NET - Requests Queued
ASP.NET - Request Wait Time

Monitoring the headers of the SharePoint application can tell you if you're hammering the server too much or if it needs that little push more to go dark.

Just seem like a really bad idea for an Internet facing app. 

Random Example:

HTTP/1.1 401 Unauthorized
Content-Length: 16
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
SPRequestGuid: 6dcb9a95-61a8-4817-bfd8-65ad55b5d1fa
X-SharePointHealthScore: 4
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-MS-InvokeApp: 1; RequireReadOnly
Date: Sun, 19 Jan 2014 18:40:11 GMT

Example of SharePoint application used by the PCI Council:

Content-Length: 13
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
SPRequestGuid: 1569c27d-f2cd-4c58-a299-07116dff3154
X-SharePointHealthScore: 0
X-MSDAVEXT_Error: 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.
X-Powered-By: ASP.NET

Shodan search:

Further details:

Secure the Headers: