Information Security

Defending the digital infrastructure


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Secure Configuration of Windows XP Desktops

DESKTOP SECURITY 5 steps to properly configure desktop security.

Having trouble with PCI compliance? You're not alone. Auditors and audit survivors offer tips for how to achieve it.

By all accounts, compliance with the Payment Card Industry Data Security Standard (PCI DSS) is on the upswing. According to Visa USA, compliance among the largest merchants shot up dramatically, from about 12 percent in March 2006 to 77 percent by the end of last year. And media reports indicate the standard is gaining ground in the European Union, where many countries--the U.K. in particular--are stepping up compliance efforts.

Yet successful PCI Report on Compliance (RoC) completion remains a confusing venture and elusive to many. Some of the confusion stems from the convoluted path of accountability. Although the PCI DSS is often touted as a one-stop standard, each of the five major card brands continues to maintain separate compliance programs. Some brands have announced heavy noncompliance fees in the form of penalties and higher transactions rates, but it is the acquiring banks that decide when and how to pass on these fees to their retail and merchant customers. And despite the prescriptive nature of PCI, the standard changes when updates are issued, and Qualified Security Assessors (QSAs) have room to interpret the standard. It's not uncommon for a QSA's interpretation of the standard to differ from that of the company under review.

Still, while PCI DSS compliance may not always be easy, it's definitely achievable.

data points

ships Windows XP on October 25, 2001 in two versions, Professional and Home Edition. Features include a built-in firewall, and the Professional version includes file encryption and other security functions.

First-year fixes
the first year of Windows XP's availability, Microsoft issues 30 security bulletins with corresponding patches for 65 vulnerabilities.

Security Campaign
Bill Gates
announces Microsoft's Trustworthy Computing initiative in an internal email to employees on Jan. 15, 2002. Company reorganizes its code development around a secure development lifecycle program.

announces the release to manufacturing of Windows XP Service Pack 2 on Aug. 6, 2004. The software giant touts the update's security features, including stronger default security settings.

reports that 34 percent of the 193 security advisories it issued for Windows XP Professional between 2003 and 2008 were highly critical. Four percent were extremely critical and 23 percent were ranked as moderate, according to the Danish vulnerability tracker.

to Windows XP, Vista is released to business users on Nov. 30, 2006. In Vista's first year, Microsoft releases 17 security bulletins addressing 36 security vulnerabilities.

The first step to tackling PCI DSS compliance is to understand who's who in the PCI accountability chain; an organization may be surprised to learn who actually does what. The five card brands that constitute the payment card industry are American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa. Each brand had its compliance program before PCI DSS, and each continues to maintain those programs and exert final decision control over compliance. However, all of the PCI brands have agreed to use the PCI DSS as a baseline for compliance evaluation to simplify the process for members.

In December 2004, the card brands issued the first version (1.0) of the Data Security Standard. The standard is not intended to replace the individual brand compliance programs; rather, it is meant to be a single set of guidelines for entities that store, process or transact credit card data. The assumption is that if an organization receives a successful PCI DSS RoC, it's compliant with any of the card brand programs.

So that there would be one central point of contact for PCI DSS matters, the five brands formed the PCI Security Standards Council (PCI SSC) in September 2006. The council is led by a five-member executive committee (one from each brand) and owns the official document repository for all things PCI DSS. This includes the standard, as well as collateral such as the self-assessment questionnaire, audit procedures, and since April, the Payment Application Data Security Standard (PA DSS) (see "App Lockdown," below). The council also maintains governance over training and approval for QSAs and Approved Scanning Vendors (ASVs).

App Lockdown
New standard focuses on commercial payment applications.

Released in April, the first version of the Payment Application Data Security Standard outlines requirements that payment applications, such as point-of-sale systems, must adhere to. For those familiar with Visa's Payment Application Best Practices (PABP) program, which provides guidance on how to create payment applications that protect cardholder data in accordance with the PCI DSS, there won't be many surprises in the PA DSS.

The majority of changes were renumbering and wording clarifications. However, some notable enhancements have been added such as listing code-analysis tools as an alternative option for testing.

Compliance to the PA DSS applies to COTS payment applications that are sold to more than one customer and don't receive significant customization. At this point, the payment card brands still hold final determination on whether the PA DSS is mandatory for all payment applications. However, Visa has announced a phased PA DSS compliance program that will require its merchants and processors to use only PABP-compliant applications.

Single customer payment applications and applications developed in-house aren't subject to the PA DSS, though they must meet the PCI DSS. The wealth of information in the PA DSS can help any team develop more secure payment applications, even if those applications aren't required to be PA DSS compliant.


Something many retailers find confusing is that the council is not responsible for compliance or decisions relating to compliance. The council has no control over fees or penalties issued to retailers or processors, nor does it have any involvement in the service-level agreements between the card brands, the banks and their members. That's why David Hogan, CIO of the National Retail Federation, was shooting at the wrong target when he asked the council last October for changes in primary account number (PAN) storage requirements. The PCI DSS is the standard on how to protect PANs if they're stored, but doesn't address whether they need to be stored in the first place. That's between the retailers/merchants, acquiring banks and card brands.

Organizations that need to validate PCI DSS compliance, such as Level 1 merchants with more than 6 million Visa or MasterCard transactions annually, work with QSAs for validation. Prescriptive though the PCI DSS is, there's still room for disagreement on specific controls and their implementation. For example, one end user reports that for requirement 3.4 (render the PAN unreadable), his QSA refused to validate solutions that were not FIPS 140-2 certified. Though this federal certification provides a much higher value of assurance from a data protection standpoint, it is not specifically required for compliance by the PCI DSS Security Audit Procedures.

In cases like this, it may seem that the council is a good place to turn for answers, but it's not. The council has QSA feedback forms that companies are encouraged to fill out after audits, but these are used to determine if the QSA is performing audits properly. Finding a company out of compliance for not using FIPS 140-2 certified products is an interpretation issue. And sometimes even QSAs feel a little lost when looking for guidance. William Lynch, a manager and QSA at IT consulting firm CTG, says he's tried to go to the card brands and the council for help with interpretation: "They're generally very reluctant to provide specifics, and their responses can be somewhat slow. If I have an interpretation question, I usually discuss it with other QSAs first and contact the council as a last resort" (see "Chain Reaction," below).

Chain Reaction

CLICK HERE for a guide to understanding who's who
in the PCI chain of accountability (PDF).

As the person who issues the Report on Compliance (RoC) to the acquiring banks and card brands, the QSA has quite a bit of power. Working effectively with the QSA can mean the difference between attaining compliance and not. The first place to go when looking for a QSA is the council's site. For external validation, only council-approved QSAs may submit RoCs. Another option is to ask colleagues with whom they've worked, or ask for a QSA reference from your acquiring bank. Evaluate acquiring bank recommendations carefully, though. Some acquiring banks have relationships with assessor organizations that pay referral fees--which may indicate the bank is motivated to make the recommendation simply to receive the fee.

Many organizations that have successfully completed PCI audits recommend treating the QSA search like any hiring process. Include requests for references and price quotes in the assessment criteria. And keep in mind that you'll be working closely with the assessment company, so it's important to have a good comfort level with its methodology. Another great tip from the trenches: consider two QSA firms, one for pre-assessment and one for the validation work.

Even if an organization does not wish to pre-assess with a QSA, it should conduct its own pre-assessment. The PCI SSC Self-Assessment Questionnaire (SAQ) and the PCI DSS Security Audit Procedures are excellent resources. An IT professional who completed a PCI validation cycle for his company said, "By pre-assessing, we knew where the holes were and could fill them before getting beat up in front of upper management by the QSA." Though not getting "beat up" can be a benefit of pre-assessment, it's important to keep in mind that most QSAs aren't aiming for humiliation and failure. Pre-assessment gives organizations key knowledge regarding what is important to QSAs during an assessment, especially with regard to documentation. By understanding where the QSA is coming from, IT professionals can engage in a more col- laborative relationship.

SIMs Stand Out

PCI requires daily log reviews, spurring a boom in SIMs sales.

PCI compliance is "a process, not a product," says Michelle Dickman, president and CEO of security information management (SIM) vendor TriGeo Network Security. Yet, there's no denying that a lot of product has been sold in the name of PCI.

Many of these purchases were a result of shoring up security controls in areas where they did not exist. For example, most companies have firewalls (Requirement 1) in their data centers, but many did not have one at every retail site. Now, thanks to PCI, many do.

One product category, however, does stand out as particularly helpful, according to those who have undergone PCI DSS audits: SIMs and log management tools. Requirement 10 calls for monitoring and testing of networks, and 10.6 specifies: "Review logs for all system components at least daily." For a major retailer with thousands of components in the cardholder data environment, meeting those requirements just wasn't feasible without a log aggregation solution.

But simply centralizing all logs and alerts isn't the end of the story, warns William Lynch, a manager and Qualified Security Assessor at IT consulting firm CTG. "Make sure the review process, accountable parties and documentation are in place to ensure that the review happens," he says.


Documentation may not be exciting but reviewing documents is a cornerstone of the QSA audit process. So be sure to include documentation review while working on a gap assessment. This is particularly important for areas where there may be interpretation or where compensating controls have been implemented. If a risk assessment process has been completed before implementing a control, be sure the supporting documentation is there so the QSA can assess it properly. Otherwise, the QSA may fail your control.

A money-based "gotcha" to watch out for when working with a QSA is when the QSA claims a company won't be validated as compliant if it doesn't buy a specific vendor product from the assessor's reseller. The tactic can be a softer sell, recommending the customer make the purchase rather than demanding it, but either way it's all wrong. QSAs that attempt to increase profits by requiring product purchases should be reported to the council.

An important step for a successful PCI assessment is to simplify the process by narrowing the scope of the audit with zoning, experts say. Allan Carey, senior vice president of research at IANS, which has advised a number of companies on PCI, stresses that "one of the most important things an entity can do is to reduce scope with proper network segmentation, including VLANs, air gaps and physical separation." When data must travel over public networks, such as the Internet and wireless LANs, Carey advises companies to secure the transmission using encryption protocols such as SSL.

Segmentation was a key part of the National Aquarium in Baltimore's strategy. As part of its PCI pre-assessment work, the aquarium reviewed two merchant functions that were operationally outsourced to third parties--the aquarium gift store and food services--and decided to physically separate the outsourced merchant networks from the aquarium. This resulted in a significant reduction in audit scope during the aquarium's PCI validation work.

Another tip on the simplification front--one we've all heard--is don't store what you don't need. But as Hogan's plea to the PCI SSC illustrated, many retailers--due to their service level agreements--are required to store PANs in a retrievable format for up to 18 months. Companies that don't have that requirement have simplified their PCI compliance by eliminating PAN storage. Others don't have to hang on to the PAN for months but hold it for hours during authorization. Brady Decker, network engineer at the aquarium, suggests that banks and card brands "take the merchants out of the security loop" by not having them store the PAN, even during the authorization phase. If a company must hold on to PANs for any length of time, Carey recommends "leveraging native database encryption capabilities to meet [requirement] 3.4 before layering on a third-party solution that may degrade performance or increase management complexity."

In addition, make sure to really know what's in your environment. Stories abound of large organizations that found untracked spreadsheets with thousands of credit card numbers when beginning their PCI assessment work. "Map the credit card data flow" for the entire lifecycle of the data's existence in your organization, says Michael Gavin, security strategist for application security company Security Innovation. That means answering these questions: Where does the information come in? Where is it being stored? Who has access along the way?

Although PCI DSS is an internationally applicable standard, most of the PCI DSS noise has been coming out of the U.S. That's no longer the case. Since late last year, there has been a significant increase in PCI awareness in the U.K. and parts of Europe. Some European countries still believe that the standard doesn't apply or is less important because of the use of a smart chip and PIN (personal identification number) in European credit cards. Chip and PIN does change the threat model, but not the PCI DSS requirement. Whether the PAN was read from a magnetic stripe, off of a smart chip, or typed into a Web form, the PAN protection requirements are the same.

Bob Russo, general manager of the PCI council, notes that organizations in some countries, like Japan, have spent a lot of time complying with security frameworks--such as the Information Security Man-agement Systems (ISMS) approach of ISO 27001 and 27002--and don't want to spend time complying with an additional standard. The card brands, along with the council, are working to raise awareness that DSS is not optional and not replaceable by any other certification work.

If an organization has been concentrating only on U.S. operations, it's time for it to start thinking globally and assessing all sites where card information is transacted. And if you are using a compliance framework, consider mapping the controls and documentation in place to those needed for the PCI assessment. Many companies report that "careful compliance recycling" can reduce overhead when certifying to new and emerging standards.

PCI compliance may not be a simple art, but there are ways--like leveraging compliance frameworks--to make it simpler. There are a lot of rules and requirements for PCI, but the core goal is simple: protect credit cards on those digital "mean streets."

IN THE know

PCI Security Standards Council
Provides information on standards, QSAs and more.

PCI Knowledge Base
Offers tips from research community.

Includes list of validated payment applications.

5 BASIC steps to properly configure desktop security.

Since its release in 2001, Microsoft Windows XP has received sharp criticism for being insecure. Although the operating system has had its share of security problems, there are five important steps organizations can take to lock down Windows XP desktops and make them less vulnerable.

It's important to note that security is something that seems to get a little bit better with each new Windows operating system. Consequently, Windows XP offers some security features that are not supported by earlier versions of Windows such as Windows 95, 98, ME and NT 4.0. These steps assume that Windows XP will not be required to connect directly to an older version of the OS; some of the settings shown here may interfere with that. Therefore, if Windows XP is required to connect to legacy Windows operating systems, some security may have to be sacrificed in order to maintain connectivity.

These steps also assume that the workstations you are securing are running Windows XP with Service Pack 2 or higher (Microsoft released Service Pack 3 for Windows XP in May). Many of the security settings that will be discussed here were introduced in SP2.

data points

Microsoft releases Windows Server 2003 on April 24, 2003, the first major platform release since Redmond announced Trustworthy Computing. CEO Steve Ballmer stresses that "security has been a job one issue with our customers. It has really been an area of focus."

Service Pack 1, released on March 30, 2005, introduces the Server Configuration Wizard, which allows users to configure and edit policy settings, from services and ports to audits.

A Secunia study published Dec. 1, 2006 says "Windows Server 2003 is consistently lower risk than Red Hat ES 3 or Red Hat ES 4," largely based on total vulnerabilities and unpatched vulnerabilities.

Microsoft releases Service Pack 2 without notice on March 12, 2007. In addition to a number of fixes, SP2 includes a tool for testing hotfixes, support for Wi-Fi Protected Access 2, and firewall per port authentication.

Another Secunia report, based on 162 vulnerability advisories from 2003 to 2008, rates 4 percent of the vulnerabilities extremely critical, 37 percent highly critical, 30 percent moderately critical, 23 percent less critical and 6 percent not critical.

Windows Server 2008, released Feb. 27, is packed with security tools and features, including tight control over services, disk encryption, network access control and improved log management.

Keeping Windows up-to-date with the latest secu-rity patches is by far the most important thing an organization can do to make desktops more secure. Fortunately, Windows XP contains a setting to apply the latest updates automatically. The technique used for enabling automatic updates varies, depending on whether the computer in question is a member of a domain.

If the Windows XP computer is not a domain member, then open the Control Panel and click the Performance and Maintenance link, followed by the System link. Windows will display the System Proper-ties sheet. Select the properties sheet's Automatic Updates tab (see Step 1, below) and then choose the Automatic (recommended) option. Finally, click OK to close the System Properties sheet.

  1. Enable Automatic Updates
    Windows XP has a setting to apply the latest security patches automatically. Use the System Properties sheet's Automatic Updates tab to allow for automated updates.

You might have noticed in Step 1 that the automatic updates options were grayed out. That's because the screenshot is of a computer that is a domain member, and automatic updates are being controlled by some group policy settings.

If the computer is a domain member, then group policy settings are the preferred way of enabling automatic updates. Do so by opening the Group Policy Object Editor and then navigating to Computer Configuration | Administrative Templates | Windows Components | Windows Update (see Step 2, below).

  1. Use Group Policy Settings
    For computers that are domain members, group policies are the preferred method for enabling automatic updates.

Most enterprise environments use a centralized update server that is responsible for downloading updates, so each machine on the network does not have to download the updates individually. The client workstations then get their updates from this distribution server. Microsoft offers a free Windows Update server product called Windows Server Update Service, or WSUS. You can download WSUS for free at

If implementing a WSUS Server or a third-party product, point the client machine to the update server through the Specify Intranet Microsoft Update Service Location group policy setting.

Windows XP allows local hard disks to be formatted using the FAT, FAT-32 or NTFS file systems. Of these, only NTFS supports file level security; FAT and FAT-32 do not allow you to set permissions on individual files or folders. The result is that if a volume is formatted with FAT or FAT-32, it is basically the same as assigning the Everyone group the Full Control permission for the entire volume.

To ensure the NTFS file system is used, open My Computer, right click on the system's hard drive, and choose the Properties command from the resulting shortcut menu. Doing so will display the drive's properties sheet, which will indicate which file system is in use (see Step 3, below).

  1. Verify all volumes are formatted with NTFS
    Windows XP allows hard drives to be formatted using the FAT, FAT-32 or NTFS file systems. Only NTFS supports file level security, so it's important to ensure the NTFS file system is used.

Hopefully, you will find that the NTFS file system is being used, but if not, there is a way to convert your current file system to NTFS. To do so, open a Command Prompt window and enter the following command:

    Convert C: /FS:NTFS
The command assumes the C: drive is being converted. If you need to convert another drive, substitute that drive's letter for the C: used in the command above.

In an enterprise environment, workstation security is typically controlled by group policies. This is a reasonable approach since the group policies can be applied at the domain, site or organizational unit (OU) level of the group policy hierarchy. At the same time, though, group policies can also be applied at the local computer level.

Many administrators make the mistake of neglecting to use local computer level group policies. The reason these policies are seldom used is because as soon as a user logs on, the settings in a local security policy are typically overwritten by policy settings contained in the domain, site and OU level policies. Even so, it is important to use local security policies because otherwise the computer is left unprotected until a user logs in to a domain and the Active Direc- tory level policies are applied.

The good news is that configuring the local security policy for Windows XP clients is easier than one might expect. In fact, Microsoft even offers some free security templates that are available via download at These templates are designed to automatically implement various security settings such as password length or complexity requirements to comply with Microsoft's recommended best practices. All an administrator has to do is pick the security template that best meets the company's needs, make any desired modifications to it, and apply it to the workstations.

To use the security templates, which are part of the Windows XP Security Guide, download the guide and extract its contents to your My Documents folder. Next, open My Computer and then choose the Folder Options command from the window's Tools menu. Then clear the Hide Extensions for Known File Types check box, and click OK.

Now, open the My Documents folder and navigate to the Windows XP Security GuideTools and TemplatesSecurity GuideStand Alone Clients folder. Note that each of the template files ends in the .TXT extension. This is a safeguard to prevent an administrator from accidentally applying a security template. Now, remove the .TXT extension, and copy the template files to a safe location where they will not be accidentally executed. For example, the SA Enterprise XP Client--Desktop.cmd.txt file could be renamed SA Enterprise XP Client--Desktop.cmd.

To apply a security template, log on to the machine that you want to apply the security settings to--with administrative permissions--and then double-click on the preferred template file. Keep in mind that there are several different security template files, and each applies a different level of security. It is extremely important to read the full descriptions of these files in the Windows XP Security Guide and figure out which template is right for your organization prior to applying one. Odds are that no one template is going to be a perfect fit, but the guide shows how to modify the template files to better meet an organization's needs.

It may seem obvious, but antivirus software is absolutely critical to a computer's security, and it must be kept up-to-date. Also check to see whether your antivirus application provides comprehensive protection against spyware and other malware. Many antivirus applications claim to protect against spyware but guard only against a handful of the more common varieties.

If a machine is a member of a domain, it's best to run different antivirus brands on the workstations and network servers. When new viruses are discovered, antivirus companies eventually develop detection signatures, but it's impossible to know which one will first, or how long it will take. By using different brands of antivirus at different layers of the network, an organization increases the odds new malware will be caught. If one antivirus product doesn't have a signature, the other might.

This might seem like another obvious step in securing a computer, but it is extremely important to either enable the Windows Firewall or install a third-party personal firewall. A network's perimeter firewall protects against malicious traffic coming in from the outside world, but not against attacks from within the network perimeter. With insiders often at the root of network breaches, it's tremendously important to use a firewall on each PC.

To manually enable the Windows Firewall, open the Control Panel and click on the Security Center link. Next, click on the Windows Firewall link. When the Windows Firewall properties sheet appears, click the On button (see Step 4, below), and then click OK.

  1. turn on the Windows Firewall
    While a network firewall defends an enterprise from outside attacks, it can't protect a computer from attacks coming from within the network perimeter. Enabling the Windows Firewall is critical.

An administrator also can enable and configure the Windows Firewall at the group policy level. Open the Group Policy Object Editor, and then navigate through the console tree to Computer Configuration | Administrative Templates | Network | Network Connections | Windows Firewall.

There are two different firewall profiles that can be configured (see Step 5, below). There is a domain profile that is in effect any time the machine is logged in to a domain, and a standard profile that is in effect at other times.

  1. Enable the firewall through Group Policy
    You can use group policy settings to turn on and configure the Windows Firewall.

Unfortunately, it's impossible to include every trick for hardening Windows XP here. However, if an organization takes these five critical steps, it will have a better chance at fending off threats targeting the desktop.

IN THE know

Windows XP Security Guide
Provides detailed technical information about securing desktops and laptops running Windows XP with SP2.

Guidance for Securing Microsoft Windows XP Systems for IT Professionals
Developed by NIST, this guide discusses Windows XP and various application security settings in technical detail.

Article 2 of 16

Dig Deeper on Information security policies, procedures and guidelines

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All