Common Compliance Hurdles Part 1: Increased PCI Scope

Looking over the findings of the last few dozen PCI gap assessments that NetSPI has performed, I am struck by the fact that today, well into version 1.2 of the Payment Card Industry Data Security Standard (PCI DSS, or just DSS), one of our most common findings remains increased scope due to lack of network segmentation.  For example, we have seen numerous merchants with relatively simple payment processing environments that have a very large and complicated PCI scope and must bear the associated costs (e.g., develop and apply hardened system configurations, pay for external scanning services, etc.).  In some cases, the merchant may not even have a real business need to store cardholder data (i.e. they could simplify their business processes and complete a Self Assessment Questionnaire C rather than the much longer SAQ D) but, even if they do, the scope of compliance is often far larger than necessary.  Limiting the scope of the systems that are required to meet PCI DSS compliance gives merchants and service providers the best “bang for their buck” in terms of reaching their compliance goals, yet it seems that many merchants struggle with defining and implementing the controls necessary to do just this.  The first step in reducing the PCI scope through segmentation is to determine exactly which systems store, process, or transmit cardholder data.  While this may be very straightforward for some organizations, it may be helpful to create a cardholder data flow diagram for more complex environments.  Once cardholder data systems have been identified, a process of isolation and segmentation can begin.  Ideally, cardholder data systems should be segregated off in a “PCI island” by a stateful firewall; Internet-facing systems should be placed in a separate DMZ segment.  Once these major changes have occurred, locking down and documenting the firewall ruleset, implementing the necessary management processes, and other items detailed in Requirement 1 are much easier to address. Though this process may look simple on paper, it can often involve the rearchitecture of not just the network but also individual systems, as PCI-related applications and functions should be isolated from other business functions (e.g., a database containing a parts inventory along with invoicing and payment information should be separated into individual databases in isolated network zones).  However, through proper segmentation, merchants and service providers can significantly reduce the cost and scope of compliance and need only apply the DSS to systems and devices that store, process, or transmit PCI data.


Penetration Testing: Stopping an Unstoppable Windows Service

Every penetration tester has a toolkit they use for escalating their privileges on the network. In some cases, the tester will copy the toolkit over to a target system once it has been compromised. However, anti-virus software has gotten pretty good at catching tools commonly included in such toolkits. To get around this problem, many penetration testers simply disable the anti-virus services prior to copying over their toolkit. Usually, disabling  Windows services is trivial, but some don’t shutdown as easy as we would like. This blog describes a relatively simple way to stop those resistant services.

Windows Services

Before we jump into it, let’s talk a little bit about Windows Services. Windows Services are applications that run quietly in the background and perform tasks that don’t usually require any user interaction (like anti-virus software). Each service is configured with a number of different settings that control how it operates. Service configurations could easily take up their own blog entry, but for the purpose of this blog I will be focusing on the “Startup Type” and “Service Type” settings. Being the intuitive readers that you are, you may have already guessed that the “Startup Type” dictates how each service is started. Below are the startup types used by most Windows services:

Startup TypesDescription
AutomaticIf a service startup type is set to automatic it will automatically start each and every time the computer is restarted. It will start the service even if a user is not logged on.
ManualIf a service startup type is set to Manual it must be manually started by the user or application.
DisabledIf a service is Disabled it cannot be started until its start type has been changed to another option.

Each Windows service is also assigned a Service Type, which specifies how each service runs on the system. I’ve listed the two most common Windows service types below:

Service TypeDescription
Win32_OWN_PROCESSWin32 services that run as a stand-alone process.
Win32_SHARE_PROCESSWin32 services that are capable of sharing address space with other services of the same type.

Additional configurations can also be set on the Service Type that determines how users and applications are allowed to control the service. Some of those configurations include:


If you’re wondering how the services are configured on your system issue the following command from the command line.


However, if a service is running as under its own process and configured as NOT_STOPPABLE it doesn’t always go down quite so easily. The standard method used to stop that type of service is to set its “Startup Type” to “Disabled” and then restart the system. That may be an option for a systems administrator, but it’s typically considered bad form to shutdown, or restart a system during a penetration test.Stopping Windows Services Most of the services in Windows are configured to startup automatically as part of a shared process. Typically those services are also configured with the STOPPABLE, PAUSABLE, and ACCEPTS_SHUTDOWN settings so they can be managed by users and other applications. Those services can be easily stopped using the Services Management Console, the “SC” command, or the “NET STOP” command. For example:

Stopping NOT_STOPPABLE Windows Services

Since I’m guessing most of you don’t want to restart the target server I am happy to provide an alternative. Corny as it may be, stopping a NOT_STOPPABLE service is as easy as 1-2-3.

1. First set the Startup Type to “Disabled”. This will prevent the service from restarting once it has been stopped. This can be done via the Services Management Console, “SC” command, or the registry. Just for fun I’ve provided an example of how to disable a service via the registry using the reg.exe application that comes with Windows.

reg add HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices /V start /T reg_dword /D 4 /F

For reference, I’ve also provided the other relative states and their associated registry values.

Registry ValueStartup Method

However, if you want to take the easy route you can also set the service state to “Disabled” via the following “SC” command:

SC CONFIG start= disabled

2. Next identify the executable that the target service is running. Use the “SC” command to get the executable:

SC qc

You should be able to see it running as an active task using the TASKLIST command:


3. Finally use TASKKILL to terminate the process using the known executable: 


Please keep in mind that you may have to be running as administrator or LocalSystem to stop the target service. There are a number of ways to get LocalSystem on a Windows system, but that’s a story for another day. However, if you’re interested in further reading on the subject I’ve provided links to some of my previous blogs in the references section below.


Killing  some services can be be a pain, but  the next time you run across a service that doesn’t want to stop for you, remember that you have options that don’t include restarting the server.



Observations from HIMSS

I was at the Healthcare Information and Management Systems Society (HIMSS) national conference last week in Atlanta. Overall, the conference wasn’t much different than past years. From an information security perspective the presentations and conversations were limited, but there were a number of interesting things that I took away from the conference.  First and foremost, healthcare is still very far behind other industries in addressing security concerns at the application provider, hospital and insurer levels. It appears that the larger application providers have begun to address certain concerns; e.g., most healthcare software companies are beginning to address compliance. What’s interesting is that PCI and PCI PA-DSS are the main drivers forcing these organizations to at least review their products. This is obviously backwards, since any healthcare organization would claim that patient information is more important than credit card information, but it’s a testament to how important the stick of strong regulations and standards are when it comes to affecting change in a specific industry. Healthcare software companies still don’t view security or third-party review of their applications as important, but having seen the findings after many of these applications have gone through review, it’s something they will realize that they need to do. Hospitals and insurers are similarly behind in developing strong information security programs, however many organizations are doing the right thing. It appears that it is mainly larger organizations (revenues $5B+) that have well developed security programs that address risk and compliance programmatically. These organizations generally have the funding and executive support to develop programs that are essentially what you would find in a similarly sized and well-managed Fortune 500 firm. The smaller firms ($5B and less) are generally much farther behind other similarly sized organizations in other industries. Many are just addressing PCI and are just starting to think about how they are going to truly address securing protected health information (PHI). Based on these observations, there is a lot of work to be done to improve information security within healthcare. One would hope that the discussion surrounding this would take place at a conference like HIMSS. While security was not a main track at the conference, there were some discussions on security at HIMSS within the context of the American Recovery & Reinvestment Act (ARRA) and electronic medical records (EMR) security, including a daylong ARRA seminar on Sunday before the formal conference opening. However, since ARRA isn’t focused on security, the coverage of information security within these presentations tended to be somewhat limited. It was very interesting that the Health Information Trust Alliance (HITRUST) was not discussed much at the conference. As the most comprehensive and usable solution for healthcare security, there weren’t any sessions on the topic and even conversations surrounding it were heavily overshadowed by discussions about ARRA. As one of the most valuable new initiatives for enhancing healthcare information security, hopefully this will change next year as the industry begins to understand how the HITRUST security framework can be of value to them. With all the focus and money targeting healthcare IT, the next year will be very interesting and addressing security should be a high priority. Ideally, with the massive amounts of new funding available, more organizations will adopt a risk-based approach to their businesses, backed up by a strong information security program. As illustrated by the success of PCI (even within healthcare), it will probably take a combination of drivers to achieve this, including a strong dose of regulation to force changes within the healthcare industry. Hopefully, the outcome will incorporate standards such as HITRUST to ensure consistency, maturity, and higher levels of security within the healthcare industry.

Discover why security operations teams choose NetSPI.