Does Your SOC Report Meet PCI Requirements?

“We’ll just shoot you the SOC 2.”

I wish it were that easy.

Many data centers and call centers use the AICPA SOC 2 audits (formerly SAS-70) to provide assurance of their processes and controls. An independent CPA reviews policy and operations to measure controls relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy. If you are not familiar with it, the report provides an overview of the services in scope and then describes the controls expected to be in place and the observation by the auditor. While the attestation process is tightly defined [pdf], the controls themselves are not prescribed specifically as they are in the PCI DSS.

In this time of increased scrutiny of third party security, organizations are receiving an avalanche of requests. It is beneficial for service providers to have an official audit that can respond to as many of these partner requests as possible. As a QSA, having a solid audit to use as evidence may mean avoiding travel to multiple regions to visit professional outsourcing facilities (who, in my experience, take physical security seriously and rarely have a severe deficiencies). However, when I review these reports, I almost always need a little more information. There seems to be disconnect between the audit department requirements proposed and the promises made in the service level agreements to their customers regarding PCI compliance. While some other frameworks or standards might need a large amount of new controls and observations (*cough* FedRAMP), PCI requirements can usually be met by small changes to the language used in the controls.

A few quick examples:

  • Instead of letting the QSA assume that everything is inside the physical perimeter, add a control that verifies that no network connections or telecommunications lines are available from outside the controlled access area.
  • Instead of just reviewing whether there is a visitors log, observe that there is a visitor’s log that contains the visitor’s name, firm, and onsite personnel authorizing physical access.
  • Instead of reviewing whether logs are kept for all access, observe whether logs are kept for all access for 90 days.

Mapping the applicable PCI DSS Requirement 9 controls (as well as wireless detection if applicable) into the SOC Audit will streamline the process and minimize additional requests from the QSA. And then it can be that easy.

Is Your Security On or Off?

The light switch is on or it’s off.

The stereo is on or it’s not.

My child is screaming or he’s not.

Our assets are secure or they are insecure.
Off On by uncoolbob

On the surface, it appears to be an easy call – are you vulnerable, have you been breached, is data being exfiltrated? Most organizations, most of the time, are likely to fall into the insecure column. The information security team is responsible for creating a secure environment, protecting the data, and communicating back to their executives that security has been achieved.

But a light switch isn’t kind of on. Unless you’ve done something silly like install a z-wave dimmer so you can find that perfect amount of illumination for every time and mood through an mobile app…but generally speaking, a switch or a stereo or anything defined as binary doesn’t have grey areas.

Security, however, has grey areas. Big, fat grey areas. Are you secure if attackers haven’t found your vulnerabilities? Are you secure if YOU haven’t found your vulnerabilities? Are you secure if data is unusable once extracted due to encryption? Are you secure if you’re compliant? (Just making sure you were still reading)

Security is not binary.

Risk teams have accepted this. Fraud teams have accepted this. Loss Prevention teams have accepted this.

Yet absolutes still get used when discussing information security. “How can we secure this?” vs. “How can we make this more secure?” “When will the new environment be secured?” “We will be secure once we implement the new, shiny controls framework.” They get used because it’s easy. Actually measuring how secure you are is relatively hard.

As security professionals, we need to begin to set expectations that doing a good job of security means understanding our risks and using the tools at our disposal to reduce them to a pre-established level. Adopting good methods of measuring our security that includes all members of the organization who can help or hinder. Reporting regularly on how our efforts have helped reduce the chance of security incidents to help the organization gain an understanding of the true task at hand. As we get better at providing this explanation, it will help avoid the expectation that we can make everything perfectly secure and allow us to manage the business of security appropriately.

The Three C’s

This week marks the annual sojourn for many of us in North America involved in the payment card industry’s security and compliance efforts. For many attendees, both Assessors and Assessed, the primary topic is the Data Security Standard. The lifecycle for the standard has a three year duration, with many important points throughout, that allow for the development, maturation, and introduction of the next version. Ignoring the official stages and listening to the surrounding discourse, the simplified lifecycle would seem to have three phases:

PCI Lifecycle - 3 C'sCirculate:  Receive information about the newest iteration of the standard, progressively over several months

Complain:  Regurgitate arguments about why compliance isn’t security and specific controls are unnecessary

Comply:  Realize that your acquiring entity still needs your compliance report and get to work addressing the changes

The publication of the newest version was announced at last year’s gathering and we’ve had time to review and digest. It’s now time to begin thinking about the feedback we will provide and how to meet any new requirements being introduced. Are the new controls added effective? Are there any areas of risk that lack sufficient coverage? Can clarity of the requirements be improved? Do you still have to ask your QSA?

There has been no shortage of important news stories around card security in the recent press. There is obviously still room to improve security, decrease fraud, and do so in a way that benefits all parties involved. It will take the cooperation of the entire ecosystem in order to attain that goal. The annual community meetings give us a chance to spark those conversations.

If you’ll be at the CM, I hope we get a chance to catch up and chat.  If you won’t make it, there will be updates from the meeting and posts specifically around PCI DSS 3.0 in the near future.

What’s your mother’s maiden name?

Online logins are proliferating. Passwords abound. Password management has become something that requires more than a sticky pad and a pen. Much has been written about using unique passwords on different sites and rotating them at appropriate periods and whether it’s better to have a complex or compound password. But what about the security questions?

In an effort to provide additional authentication and control fraud, you are asked to enter the answer to some very personal questions.

  • “What was your first car?”
  • “What was the name of your first pet?”
  • “How many times did you sneak out to visit your seventh grade girlfriend?” [ref]Trick question that reports to your parents[/ref]
  • and the ever-present, “What is your mother’s maiden name?”

All of these knowledge-based questions are designed to implement an additional step of password authentication. Choosing from the triumvirate of something you know, something you have, or something you are, they provide another point of identity validation. While not truly two factor, it does provide additional authentication that someone didn’t just find on your sticky note.

But it dawned on me the other day, I don’t really have to respond with the actual answer.  I know it sounds a bit dense. It kind of surprised me that it took this long to even contemplate this level of deception. The site asking doesn’t know if my elementary school was Kennedy or Reagan.[ref]It was neither, for those social engineering at home[/ref] They don’t know that my first car was blue. More importantly, I don’t have to try and remember who I thought my best friend in high school was or where my sixth birthday party occurred.

I’m free to answer the exact same thing on every site. Yes, I graduated from Snuffleupagus High School. Yes, the street I grew up on is named Snuffleupagus Drive.  And yes, my favorite television character is Snuffleupagus.  Ok, so maybe that last one actually makes sense.  This aids in recall and ensures that you don’t get stuck wondering whether your favorite musician when you signed up was Justin Bieber or Harry Styles.

There are a few downsides to this method. You have limited the randomness of your answer. Once someone knows your security question answer, they know all of your security question answers. But while brute force attempts target passwords all the time, it is less likely that the security questions will allow the same repetition of guesses without timing out. There’s also less of a chance that someone is going to assume that you have answered the question with complete nonsense. Imagine the frustration on the face of someone intentionally targeting your account who’s done their homework and knows for sure that you were born at St. Francis in Topeka, KS while you answered with your stock security answer. Also, depending on the answer you choose, you might be making your customer service call more difficult. If you are like me and using a password safe, you might find your self using a generated password. You’ll need apologize in advance to the nice lady on the phone and then read off your 55 character complex passphrase.

Before you call your mom to find out what town her and your dad were in when they met, consider whether it’s necessary to factually answer the security question.

Top 5 Changes in PCI DSS 2.0

Last Thursday brought the second whole version of the Payment Card Industry’s Data Security Standard.  On their newly updated site, the council makes the new version available, accompanied by three updated documents: summary of changes, navigating the DSS, and the glossary.

So what has this new incarnation brought us?  Honestly, not as much as most had hoped.  Then again, it’s not as much as some feared.  Not to say there are things of which to be aware.  While most .0 release versions are major updates, this iteration was named thusly in order to bring it in line with the new three year lifecycle.  I decided to sum up what I feel are the five biggest updates with a little bit of commentary (don’t forget that others might be doing this as well):

  1. Discovery – QSAs reading this will be very familiar with said process.  At the beginning of most PCI assessments (and throughout), the on-site QSA will attempt to ensure that the scope provided by the client is accurate.  They must in order to ensure their sampling is correct and that no major payment flows go unaddressed.  It’s part of the drill when you must cover unlimited liability with due diligence.  And many merchants and service providers have been more than willing to allow the QSA to do this leg work.  Now that it’s a required portion of the scoping, why not perform this internally and save money during your assessment?
  2. Virtualization – Anybody actually think that we would see virtualization-centric requirements?  No?  Good.  While the hypervisor and virtual platform receive mention, the approach currently (until the SIG publishes recommendations) is to assess virtualization with traditional best practices.  This is not a bad thing.  Most virtual environments are mirrors of their physical counterparts (and for the differences, well, that’s another post).  Protect them as you would any other servers and follow industry guidance for hardening and configuration.
  3. Checkmarks – That’s to say, there’s more of them; testing procedures mostly.  However, most are instantiated from the previously existing requirements.  Worst case scenario, your QSA will require a bit of time during the assessment and your year over year metrics will require some tweaking (you are keeping metrics right?).
  4. Clarifications – There are a LOT of them.  Most quality QSAs have been providing interpretations along the line of these clarifications based on security best practices and tenets.  Others may have taken a more literal reading and provided an in place ruling.  Validate each clarification to ensure that past decisions still uphold the requirement and intent.
  5. No NEW requirements – Ok, ok, not really a change.  But as implied up front, this IS your parent’s DSS.  Some bemoan the fact that a three year publication schedule allows new attack vectors to be introduced without a counteracting guidance.  But this is the molding of the standard in order to keep it as just that, a standard.  While the QSA industry is moving towards an audit approach, the Council seems to be trying it’s best to keep itself as a minimum bar with just enough detail to provoke action but not a checkmark mentality.  Surely the next whole version release will be monumental, but for now, enjoy the comfortable form factor.

That’s it!  Nothing too scary.  There’s plenty of fine detail (so quit using WEP already)!  If you are a QSA or accept cards as a merchant or service provider your mileage will vary, so take a look at the summary of changes to see how the new change impact you and yours.


While on the phone with Dad yesterday evening, we ended up discussing that first computer.  My on-ramp to technology was at a very interesting time; one that allowed me to understand the technology and grow at the same pace.  I was forced to use a command line just to start a program.  I saw the internet transform from a bunch of unconnected networks to a global infrastructure.  And I was interested enough to stay part of that process.

However, kids are now thrust into the computing world that has developed it’s own epidermis.  A protective layer meant to help users cope with interfacing with the technology and to keep them from messing it up too bad.  Which can be nice if you work tech support.  But if you want to know what’s actually going on inside the box, it’s a longer trek and one that hasn’t been kid-friendly.

Until now.  Enter HacKid Technology Conference for Kids & their Parents:

HacKid is a new kind of non-profit conference focused on  providing an interactive, hands-on experience for the entire family — kids aged 5-17 & their parents –  in order to raise awareness, excitement and understanding of technology, gaming, mathematics, safety, privacy, networking, security and engineering and their impact on society and culture.

The brainchild of Chris Hoff, this event looks to be the missing piece for anyone whose kids were born after the debut of Windows ’95.  I’d heard blips aobut this and hadn’t connected the dots (mostly because of a lack of progeny), but it sounds like a great deal for a security minded parent.  I’m hoping this year’s inaugural event is a success!

First Post!

Watching reruns as a child, I saw other kids on the shows sitting in front of radios.  Maybe new shows had them sitting in front of TVs.  But I found my childhood self spending time in front of a new technology procured by my dad, the PC.  A few movies I would see later had some semblance of my experience (How about Global Thermonuclear War?).  That IBM PC XT had an EGA screen and dual 5 1/4″ floppies.  No hard drive.  While I would spend hours playing Wheel of Fortune, I also learned to program MS-DOS and manipulate WordPerfect to make grids for crosswords.  Next came upgrades and replacements, faster processors, more memory.  And the modem; a portal to bulletin boards, StarText, Prodigy, etc.  This thing now connected me to the world!

2 x IBM PC XTs by Riggzy, on Flickr

Whether it was helping out in the high school technology center, assisting damsels in distress connect to the university’s systems, or maintaining systems for employers, computers became omnipresent.  Even recording music and doing post production work changed right as I entered the field, relying much more on software and remote recording than ever before.  In early 2005 I caught up with an old friend over beers in Austin and was presented an opportunity to help others again, this time doing information security consulting.  I honed up my skillset and got to work.

I’ve now had the pleasure to work with incredibly large corporations, small service providers that employee one IT guy, and everything in between.  The work has at times leaned technical, at others it’s been more strategic.  I’ve also come into this career in line with the rise of PCI and have benefitted from the breadth of that standard.  Working with companies not just on their firewall configuration or privacy policy deployment but around their entire information security posture has exposed me to an amazing array of experiences.  Every day it’s something new.

Five years later, I find I am still discovering security.

My hope is to share a little of that discovery and make it yours.

This site will focus around the following classes of posts:

  • Links – I’ve been an ardent RSS subscriber and feel that sharing the knowledge that others put out into the ether is imperative.
  • 101s – Short articles focusing on basics that help me form cogent thoughts on infosec and might help others
  • Techinals – More specific articles focusing on security techniques or practical applications
  • Book Reports – Whether good or bad, these monthly (?) columns will hopefully keep my reading on track
  • Op Eds – Longer articles sharing my opinion on infosec topics or industry developments

As my career moves in and out of specializations, those will probably take up more post space than other topics.  However, a view from up high, that 35,000 foot view I enjoy while heading to my next client engagement, will always have space to fill as well.

I welcome feedback, discussion and hope to see many of my colleagues around the country in the near future.  Enjoy the discovery!