Archive for April, 2010


Password Complexity

Passwords are always a sensitive subject.  Most people find them annoying, particularly when you bring in complexity.  Most people struggle remembering their children’s cell phone numbers and now you want them to remember something at least eight characters long comprised of upper and lowercase alphabetic, numeric and special characters?  And you want me to change it at least every 90 days?  In the immortal words of John McEnroe, “You cannot be serious?”

Complex passwords are the bane of users’ lives.  Most users need to remember on average at least three passwords, so anything you can do to make password complexity easier on users, the easier your life will be.  While I would like to take credit for this idea, it is not mine.  I attended an IP3 information security conference a number of years ago.  Ken Kousky was the instructor and passed along this idea that the more I thought about it, the more sense it made.

The premise is that most security standards require that a password be comprised of a minimum of eight characters.  Those eight characters need to include upper and lowercase alphabetic, numeric and special characters.  In addition, a lot of standards go further and require that no alphabetic, numeric or special character be repeated in the password.

Mr. Kousky said, “What if you make the first four characters something everyone in your organization knows and you leave the last four as numeric digits that your users randomly select?  Make the first set of four characters hit the upper and lowercase alphabetic and special characters requirement.  You can tape this onto everyone’s keyboards or displays because it is common knowledge.  All your users have to remember is their unique four digits.  It is no more difficult than them remembering their PIN for their ATM.”

Think about this statement for a while before you blow it off as being too easy to be true.  A lot of life’s complexity is introduced because people charge ahead without thinking things through to come up with a sane way to accomplish what was asked.  After all, the simpler you make something; the more likely people will comply with what you are asking them to do.

To be fair, there are a couple of other parameters that need to be in place in order for this concept to work.  First, you need to only allow a user three attempts to logon before you fail them.  Since you are only relying on a four digit number for uniqueness, you cannot offer more than three logon attempts without creating an environment where someone guessing a password gets too many attempts at any one time.  Next, you need to lock the account for a minimum of 60 minutes after three failed logon attempts.  Such a long timeout will frustrate and defeat most people trying a brute force password attack.  You need to force the user to call the help desk and properly identify themselves in order to get their user identifier re-enabled and their password reset if they wish to logon before the 60 minute wait time.  And finally, any password reset requires the changing of the password at the first logon.

I just wanted to share this simple yet effective way of achieving password complexity without creating a nightmare for your users.


More On The Coming PCI DSS Changes

Walt Conway has a great article on the coming changes to the PCI DSS. Apparently there were two presentations given at last week’s ETA conference by the PCI SSC on the changes that will be implemented in October to the PCI DSS.


Managed Networks And PCI Compliance

Here is a subject that keeps coming up, particularly with organizations that manage networks for merchants.  If I manage an organization’s network, is my organization in-scope for PCI compliance?  The answer is yes, the services you are providing are placing your organization and its relevant services in-scope.

The first response from the network management company is usually, “How can that be, all other telecom companies are out of scope, why not us?”  Quickly followed by, “No other QSA has ever asked us to go through this.”  Remember, the QSA is just the messenger.  Everything stated in this post is from the PCI DSS, the DSS Glossary and other PCI SSC and card brand publications.  This is what the PCI SSC is asking all QSAs to do as part of their PCI assessment work.  If you do not agree, talk to the PCI SSC as they are the only ones that can change the standards.

To answer, “How can that be, all other telecom companies are out of scope, why not us?”

It is very simple. Your organization is not providing just a circuit.  The PCI SSC has been very clear on this.  If all you are providing is a circuit and no other services, then you are out of scope.  The moment your service to a merchant or service provider goes beyond just providing a basic method of transport, you cross into PCI compliance territory.  Basically, the PCI SSC’s interpretation is that if the merchant or service provider has outsourced all or part of a role to your organization, it stands to reason that your organization has assumed that responsibility and, by default, also assumed the relevant PCI compliance responsibility.

But, what if the data is encrypted before it gets to our equipment?  As long as your organization does not have the ability to decrypt the data stream, then your services are out of scope.  However, if the cryptographic process involves your equipment or you manage cryptographic keys, then you are in-scope and must comply with the PCI DSS.

What are your compliance obligations?  Based on my analysis, your organization is involved or responsible for at least the following PCI DSS requirements; 1, 2, 4, 6, 7, 8, 9, 10 and 12.  Here is my high-level take on what you need to be prepared to document, discuss and/or prove you are doing.

  • Provide policies, standards and procedures for device management.
  • Provide policies, standards and procedures for physical and logical security.
  • Provide a copy of your incident response plan.
  • Provide access control definitions for groups and roles that manage the devices.
  • Provide job descriptions for the personnel that manage the devices.
  • Document all protocols/services that are used for managing the devices including a business reason for each of the protocols/services.
  • Provide configurations of a sample of physical devices.  Sampling is allowed as long as the service provider can prove that it has implemented a standard process for managing the devices in question.
  • Provide documentation that supports that device configurations are properly backed up and secured.
  • Provide documentation that supports that device configurations that are running and those that are stored are one in the same.
  • Verification that all relevant policies, standards and procedures are followed in configuring new devices.
  • Verification that documented protocols/services are the only ones configured on the managed devices.
  • Verification that security is properly implemented on all managed devices.
  • Verification that appropriate access control systems are implemented on the managed devices.
  • Verification that remote access is secure.
  • Verification that all user accounts are appropriate managed and controlled.
  • Verification that all logging is implemented and logs are reviewed at least daily.
  • Verification that log information is properly secured.
  • Verification that the time management is properly implemented on each device.
  • Verification that some form of critical file monitoring is being performed.
  • Verification that there is a formal change management process in place including testing.
  • Verification that any cryptographic keys are properly managed and secured.
  • Verification that all devices have been appropriately patched and that there is a patch management process in place.
  • Verification that appropriate physical security controls are in place.
  • Verification that logs are maintained for any backups stored off-site.
  • Verification that alerts are responded to as documented in the incident response plan.

Now for the second comment, “No other QSA has ever asked us to go through this.”  If no other QSA has asked you to go through this, shame on them.  This is why the PCI SSC implemented its Quality Assurance program so that all QSAs start doing the same level of work.  This is also why there is such a variance in QSA costs.  We are finding that the QSAs that are the cheapest are the ones that are not being appropriately rigorous with their assessment of an organization against the PCI DSS.  As the PCI SSC takes more QSAs through the QA process and puts them through remediation, things will change and assessment costs will become more consistent.


Open Source PA-DSS Certification

I got the following comment regarding open source solutions.

“Is it correct to assume that open source e-Commerce solutions like Magento Community, VirtueMart, Ubercart, Zen Cart, etc. will never be PA-DSS compliant since, by their very nature, they are modifiable and extensible via plug-ins?

Does it mean that a commercial e-Commerce solution will need to be “locked down” with encrypted code to be PA-DSS compliant?”

Now before all of you open source “bigots” out there send me tons of nasty comments and flame mail, keep in mind that I am a big fan of open source code and rely on a lot of it in my network security practice.  The problem is not with open source solutions but with the practices used to create those solutions that typically create the compliance issues with the PA-DSS.  I am not implying that these issues cannot be overcome.  Just that given the state of open source at the moment, I just do not see these issues being overcome in the near future.  That is not to say that open source solutions cannot be used for payment processing.  It is just that they will need to be individually assessed as part of the merchant’s PCI Report On Compliance (ROC) assessment process.

Let us remind everyone about the 14 points that the PA-DSS covers.

  • Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
  • Protect stored cardholder data
  • Provide secure authentication features
  • Log payment application activity
  • Develop secure payment applications
  • Protect wireless transmissions
  • Test payment applications to address vulnerabilities
  • Facilitate secure network implementation
  • Cardholder data must never be stored on a server connected to the Internet
  • Facilitate secure remote software updates
  • Facilitate secure remote access to payment application
  • Encrypt sensitive traffic over public networks
  • Encrypt all non-console administrative access
  • Maintain instructional documentation and training programs for customers, resellers, and integrators

In my opinion, none of the aforementioned solutions will ever likely be PA-DSS certified.  Here are the highlights of my rationale for that assessment.

Requirement 5 – develop secure payment applications is where I think the majority of the issues with PA-DSS certification occur.  Requirement 5 deals with the development practices used to develop the solution.  The problem here is in the PA-QSA reviewing all documentation, interviewing the developers and observing elements of the development process.

Open source documentation is typically only available online and can be very spotty at best.  Usually the focus is on installation and basic operation.  The PA-DSS and PCI DSS require documentation on how to properly install the solution so that it complies with the PCI DSS.  Documentation for open source solutions that I have evaluated have not included such information.

One of the biggest stumbling blocks for open source solutions will be in documenting the system development life cycle (SDLC) that is used.  In my experience, while documentation on the application can be scarce, documentation on the development life cycle typically is non-existent with open source.  As a result, it will be impossible to get around the requirement of an SDLC.

Then there is the whole process around change control.  How changes are managed from the initial request through implementation is a big part of the PA-DSS assessment process.  These communities usually do not have a change control process that can be audited let alone meet the rigor required by the PA-DSS.  There is also the question of who approves the changes.  These open source solutions usually do not have a documented organizational structure, so who is the person that approves the changes for development, approves the changes for production?

As with change control, testing is another big part of the PA-DSS certification process.  While open source communities conduct testing before releasing their products, the testing they perform is usually not documented in a way that it would meet the requirements of the PA-DSS assessment.  Testing also requires documented approvals, so the issues with change control approval exist with testing.

While all of these requirements can be met with compensating controls, without a control environment to start with, just how one would develop compensating controls is a big hurdle to overcome.

Besides the problems in meeting Requirement 5, here are some other items that I also think preclude a PA-DSS certification for open source solutions.

Who would be the organization of record that certifies the application?  Most of these open source projects and communities do not exist in a legal sense.  As a result, they technically cannot legally represent the application in question which is required for PA-DSS certification.  And for those instances where there is a legal entity, would such an entity be willing to assume the risk entailed in certifying their solution?

Then there is who would pay for the certification?  Most of these projects and communities exist on the goodness of the people who devote their time to the software solutions in question.  There is little if any money involved and it would be difficult for most to raise the kind of money to pay for a PA-DSS assessment.  For those of you wondering, most PA-DSS certifications cost at least $30,000 or more depending on the complexity of the application and the number of platforms involved.  When you are structured like most open source projects, such an amount of money is daunting to raise.

And finally, assuming that your open source solution gets PA-DSS certified, how would you know that your version of the open source is untouched?  .  This basically means that the solution now needs to be distributed in a secure manner.  So, the community will need to have a known, secure distribution point for the software, not distributing it from any outlet that wants to provide it for downloading.  Yes, you can use MD5 or similar hash algorithms to confirm that the version is the correct, certified version.  However, given the requirements of the PA-DSS regarding distribution of the solution and any updates, open source communities will have to invest in a bit better distribution system.

The bottom line is that the PA-DSS is skewed to commercial software, not the open source community.  That is not to say that open source solutions will not get certified as I believe there may be some that do get certified.  I think what you will see is organizations spring up that offer a certified version of the open source solution but you will have to purchase that version, you will not be able to download it for free.  Very similar in concept to how Red Hat and Novell operate with their versions of Linux.  However, based on the current certification process, in my humble opinion, PA-DSS certified open source solutions will be the rarity not the rule.


Patching Human Vulnerabilities

This is an excellent post from David Emm on human vulnerabilities, likely the biggest threat to your cardholder data.


PCI For Dummies

Is it just me, or is there a move afoot to make security idiot proof?  The reason I ask is that I keep getting emails from various sources indicating that they have developed a white paper entitled ‘PCI for Dummies’, ‘PCI for Idiots’ or ‘Making PCI Compliance Easy’.  Hello!  Get a clue out there!

To paraphrase Tom Hank’s character in ‘A League of Their Own’, “There’s a reason security is hard.  If it wasn’t hard, everyone would do it.”  Security is not always simple, it is not always easy.  Security usually requires thought, diligence and consistent execution.  And in some cases, security may require a lot of thought and a lot of effort.  The reason?  The bad guys are hoping that people are complacent in their protection of their data.  They hope that we “drink the Kool-Aid” and believe the hype of the white papers.  The bad guys hope that you think because you have the latest and greatest security widget that PCI compliance has been knocked off your to-do list and you can move on to ‘real’ work.

The thing that a lot of people get wrong about security is that they think that it has a start and an end.  And that is the problem with security; it has never been a destination, it is a journey.  Security is a never ending struggle between the “haves,” in the case of PCI those organizations that have cardholder data, and the “have nots,” in this case the “bad guys” that want cardholder data.   Just when you think you are done, a new threat or risk pops up and the process of securing your organization starts all over.  And if it is not a new threat or risk, then it is someone that gave away their password, was polite and violated your physical security protocol by opening a secured door for someone, borrowed their access card to someone or left their netbook unsecured in their hotel room while they were at dinner or the room was cleaned.

PCI compliance is no different.  Your preventative and detective controls such as firewalls, intrusion detection and monitoring typically work fine as long as they are maintained and your users do not circumvent them.  However, monitoring also involves corrective controls and that is usually where people slip up.  It is the correction process that is so important.  While you can rely on vendor patches and maintenance to keep the widgets working, if you are not correcting problems, your security will gradually get weaker and weaker.

There is a great t-shirt out that says, “Just when you think you have made something idiot proof, someone goes out and makes a better idiot.”  Some users are better than others.  Some users are never going to get it.  It is the users that never get it that will hurt you.  However, we all have days where we get suckered for one reason or another.  With the sophistication of some of the attacks these days, it’s surprising that more people are not affected.  However, without an active security awareness program, you will never get people trained to suspect “odd” requests, stop opening attachments and falling for all of the obvious scams.  There is no security awareness program that is 100% successful.  But if you do not have a program, all of your other security efforts will be wasted.

That said one of the biggest “dummies” is likely in that large corner office.  It is not that your CEO/CFO/COO/CIO does not care, they really do care.  It is just that they likely have no idea how to approach the problem of security and how to address it.  Even more likely, they do not realize that it is a never ending effort.  As a result, the first thing you need to do is educate the C-level people in the ways of security.  You do not need to teach them the nuts and bolts, just the 50,000’ view.  But they are also likely users, so do not pass up the teaching moment.  Make sure they participate in your security awareness program which is another opportunity to train them.

As a lot of you have commented, I really do have a thing about security not being perfect.  It is an important message that needs to be delivered.  However, that message needs to be delivered carefully.  Security may not be perfect, but without peoples’ diligence there is no hope of coming close.  And that is the message today.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

April 2010