Tag Archives: PCI

Cisco Targets Wireless Security to Step Beyond PCI Compliance

Cisco is looking to bolster wireless security with an eye towards going above and beyond compliance with Payment Card Industry (PCI) requirements.

Part of that starts with the addition of new PCI compliance reporting capabilities for the Cisco Wireless Control (WCS). On top of its previous PCI reporting functionality, WCS now offers a PCI summary report and the ability to filter and focus on individual locations or devices.

Reports and logging are great if you read the logs… You do read the logs daily, don’t you?

via Cisco Targets Wireless Security to Step Beyond PCI Compliance – Security – News & Reviews – eWeek.com.

Hacked Laptop Causes Data Breach at Pentagon Federal Credit Union

An infected laptop was used to access the systems at the Pentagon’s credit union, exposing the financial records of the members of the United States military, according to a Kaspersky Lab report.

[…]

This isn’t the first time PenFed has been targeted. The credit union posted an alert on its Web site notifying users that a person who was calling members to say their mortgages were being sold and requesting personal information was fraudulently masquerading as a PenFed underwriter.

I wonder if the laptop had PCI-mandated firewall and anti-virus software.

via Hacked Laptop Causes Data Breach at Pentagon Federal Credit Union – Security – News & Reviews – eWeek.com.

Building httpd-2.2.17 RPM from a tarball

I have a few CentOS 5.4 webservers to upgrade from httpd 2.2.3 to 2.2.17, but 2.2.17 isn’t available as an RPM from in any repository that I can find, so I’m making my own.  Here’s how I did it.

First, I built a new CentOS 5.4 x64 virtual machine on a spare 64-bit VMware vCenter server using the same ISO as my production machines.  This VM will have a plethora of build and development tools that I don’t need or want in production.

Then, I googled around and found some helps on setting up an RPM build environment, including wiki.centos.org, and OwlRiver.com.

Next, I logged in as root, and:

# yum update
# yum groupinstall "Development Tools"
# yum install rpmdevtools rpm-build  redhat-rpm-config  openssl-devel

Create a user to run the build process, and then become that user:

# /usr/sbin/useradd rpmbuilder
# su - rpmbuilder

Set up rpmbuilder’s environment, using the Owl River’s tips:

$ wget http://www.oldrpm.org/hintskinks/buildtree/RPM-build-tree.txt
$ chmod 755 RPM-build-tree.txt
$ ./RPM-build-tree.txt

Then wget httpd-2.2.17.tar.gz from one of the Apache mirrors, and try a build and see what else is needed. (NOTE: httpd includes an httpd.spec file in the root of the tarball, which greatly simplifies building an RPM from the source — we do not need to create a .spec file to guide the creation of the RPM. If you want to modify the build parameters of the RPM, extract the .spec file (tar zxvf httpd-2.2.17.tar.gz httpd.spec), modify it, and then specify your .spec file with rpmbuild --rmspec httpd.spec.)

$ rpmbuild -tb httpd-2.2.17.tar.gz
error: Failed build dependencies:
apr-devel is needed by httpd-2.2.17-1.x86_64
apr-util-devel is needed by httpd-2.2.17-1.x86_64
openldap-devel is needed by httpd-2.2.17-1.x86_64
db4-devel is needed by httpd-2.2.17-1.x86_64
expat-devel is needed by httpd-2.2.17-1.x86_64
pcre-devel >= 5.0 is needed by httpd-2.2.17-1.x86_64
/usr/bin/apr-1-config is needed by httpd-2.2.17-1.x86_64
/usr/bin/apu-1-config is needed by httpd-2.2.17-1.x86_64

When you weren’t looking, I added rpmbuilder to the sudoers file. If you didn’t do that, switch back to root and install the missing packages, but as for me, I sudo-install them as my rpmbuilder

$ sudo /usr/bin/yum install apr-devel apr-util-devel openldap-devel db4-devel expat-devel pcre-devel

And try, try, again:

$ rpmbuild -tb httpd-2.2.17.tar.gz

(Lots of text scrolls past, ending with:

configure: error: distcache support failed: can't include distcache headers
error: Bad exit status from /var/tmp/rpm-tmp.71094 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.1844 (%build)

Install distcache, then try again.
$ sudo yum install distcache distcache-devel
$ rpmbuild -tb httpd-2.2.17.tar.gz

It builds and builds and builds… it’s working! And you are rewarded with this output:

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.55847
+ umask 022
+ cd /home/rpmbuilder/rpmbuild/BUILD
+ cd httpd-2.2.17
+ rm -rf /var/tmp/httpd-2.2.17-1-root
+ exit 0

Look in the RPMs/arch/ dir for the product of your (or my) hard work:

$ ls rpmbuild/RPMS/x86_64/
httpd-2.2.17-1.x86_64.rpm httpd-devel-2.2.17-1.x86_64.rpm mod_ssl-2.2.17-1.x86_64.rpm
httpd-debuginfo-2.2.17-1.x86_64.rpm httpd-manual-2.2.17-1.x86_64.rpm

Copy httpd-2.2.17-1.x86_64.rpm to a test/dev/QA machine, install it, test your websites, and then repeat in production.

Welcome to 2.2.17!

Network Security Blog » A PCI Christmas Wish List

Martin gives his PCI Christmas Wish List:

So what would I wish for from the industry and the PCI Council this Christmas if I knew they couldn’t turn me down?  Like I said in the beginning, I’d shoot for the stars; I want a complete rewrite of the PCI requirements that focuses on the desired outcomes, not the specific technical steps that need to be used to accomplish them.  Josh Corman had a good suggestion about this; keep the current requirements as an example of how to implement the new requirements, but we’d have a list that focuses more on the outcomes we want and less on the technology that is needed to make them happen.  The problem with this solution is that it would introduce a lot more wiggle room in DSS and would require a more mature, knowledgeable group of QSA’s, but it would also give merchants and service providers the ability to be more flexible in their solutions and maybe even allow them to concentrate on security first, compliance second.

Personally, I’d like a set of tools that make it very easy to generate checklists of compliance issues to accomplish.  I do this manually, using an automated scanner that presents me with a list of vulnerabilities, and then copy / paste them into trouble tickets, or from the self-assessment questionnaire I answer the questions and then copy out the items to work on.  But in the SAQ, the current NOs are scattered randomly throughout the questionnaire, rather than summarized together for reference.

via Network Security Blog » A PCI Christmas Wish List.

Anton Chuvakin Blog – “Security Warrior”: PCI_Log_Review

Dr. Chuvakin nobly provides a multi-part series on PCI DSS log review procedures. Follow along for fun and profit!

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company. As I am preparing to handle more of such engagements (including ones not focused on PCI DSS, but covering other compliance or purely security log reviews), I decided to publish a heavily sanitized version of that log review guidance as a long blog post series, tagged “PCI_Log_Review.”  It was written to be a complete and self-contained guidance document that can be provided to people NOT yet skilled in the sublime art of logging and  log analysis (a key requirement for this project – guidance was to be useful to such people) in order to enable them to do the job and then grow their skills. It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation (or without any compliance flavor – of course!)

This is the first post in the long, long series… prepare to see lots of process flow charts

via Anton Chuvakin Blog – “Security Warrior”: PCI_Log_Review.

How to Define “Connected Systems” to the PCI Cardholder Data Environment (CDE)

Jeff Lowder delves into defining “connected systems” per PCI:

While the Payment Card Industry (PCI) Data Security Standard (DSS) arguably does a better job than most standards in defining scope, there is one part of the DSS that needs to be clarified. The DSS determines scope in terms of “system components,” which it defines as follows.

via How to Define “Connected Systems” to the PCI Cardholder Data Environment (CDE) | BlogInfoSec.com.

How to Safeguard Your Printing Environment

Michael Howard gives some excellent reminders on the vulnerabilities of printers in an organization.  Remember that printers used in a financial environment can be in-scope for PCI, and to protect the data-in-motion and data-at-rest.

Data breaches are big business of the worst kind but, despite their costliness, such breaches are all too common. We have all heard the horror stories of hackers accessing secured networks or of thieves stealing laptops to gain unauthorized access to confidential information, sensitive intellectual property (IP) and financial data—viable threats that every IT manager works diligently to defend against.

However, there are often hidden security risks that organizations need to address. One vulnerability that is too often overlooked—and may be leaving you susceptible to attack—is your network of printing and copying devices.

via How to Safeguard Your Printing Environment – Printers – News & Reviews.

More PCI encryption, tokenization options emerge for compliance

Personally, I am looking forward to tokenization of cardholder data and the elimination of local PAN storage greatly simplifying DSS compliance.

The use of tokens to mask sensitive data is taking hold in the payment industry, with merchants now having the option to use third-party service providers or install their own tokenization server to protect credit card data.

The market for a combined tokenization and encryption package has been simmering, buoyed by merchants trying to find ways to simplify the payment process and meet PCI encryption requirements. The latest guidance from the PCI Security Standards Council suggests that the market for tokenization and point-to-point encryption for PCI compliance is still in its infancy.

More PCI encryption, tokenization options emerge for compliance.

PCI SSC finalizes PCI DSS 2.0

One year should be plenty of time to get caught up on DSS 2.0, although those who are still not compliant with 1.2 have a lot of catching up to do.

The Payment Card Industry Security Standards Council (PCI SSC) issued version 2.0 of the Payment Card Industry Data Security Standards (PCI DSS) this week, making widely available the new document, which contains 12 minor changes.

PCI DSS 2.0 takes effect on Jan. 1, but merchants won’t have to become fully compliant with the new version until Dec. 31, 2011. The release of PCI DSS 2.0 also begins a new three-year lifecycle of the development cycle. The document won’t undergo any further changes until 2014.

via PCI SSC finalizes PCI DSS 2.0.