kitten, by Clevergrrl

Ahh, everyone loves some good programming humor, right?

RIGHT?!?

Yeah, that’s what I thought.  This month I talk about one of the hardest tech jobs out there… the Application Developer.  I used to be one, and I remember the stress of getting projects completed on time, under budget, and with minimal bugs.  It’s a thankless job.

So go check out this month’s edition of Herding Cats here!

Some corporate citizens might disagree with that basic statement based on conversations like the following: “You mean I have to go to some website to enter a request for paper clips, and then someone in another office can just reject it because they want to?” Sometimes it doesn’t work.  When you are in situations like this, remember this little saying from a very wise man: “Don’t confuse logic with the process.”

by mikebaird

Process in other examples can be a really good thing.  Consider the actions you might take to promote code from a test or Q/A environment into production.  The steps you take to do this should be the same every time, and any deviation from those pre-determined steps should be noted by the developers.  You don’t want to screw this up, so following the checklist of steps is an easy way to make sure you keep the train on the tracks.

Pilots use process (we call them checklists) all the time.  I’ve seen panic in first-time small aircraft passengers when the Pilot In Command (PIC) takes out the Pre-Engine Start checklist and start to read mundane items such as “Passenger safety briefing,” “Fasten seatbelts,” and “Set the Fuel Selector to ‘Both’.”  Those passengers should take solace when the PIC takes out that checklist because he is making sure that every step is completed in the order it was designed, and nothing is missing.  While doing a passenger safety briefing may not be one of those things that seem necessary, checking that all the circuit breakers are in could end up making the difference between a fun first flight, and one that makes you never want to fly again.

Now what happens when you put TOO MUCH process into a particular job?  Process is designed to document and create consistency.  If followed, process can ensure that every code promotion happens as planned.  Of course, too much process can slow cognitive problem solving skills, thus ending in the unfortunate argument/defense mechanism, “But I was just following YOUR process!”

Too much process removes the brains from corporate citizens.  And if the problem is too far gone, questioning the process only lands you in a circular, death-spiral discussion from which even Sully couldn’t pull out¹.  So where is this magical balance where you can achieve documented, predictable results, yet still give people the freedom to think for themselves?

That is the million dollar question for sure.  In the security world, we need procedures to ensure we don’t end up opening up security holes by making changes to support the business.

The trick is to make sure that people working with the policy understand WHY it is there, WHAT it is doing, and HOW and WHEN to get exceptions to the process.

1. Are you tired of the pilot stuff yet?

Stay Classy, San Diego!

Taking a hint from Anton Chuvakin’s blog, I thought I’d start posting the five most popular posts from the previous month.  If you have not had a chance to read everything here, give these five a try!

Here are the five most popular posts from last month:

• MasterCard/Visa Remove Reciprocity. This post details changes made on payment brand websites that appear to remove level reciprocity on merchants.  Regardless of your level, most acquirers (or acquiring functions of payment brands) will accept a higher level of validation.  You should not be forced to complete a ROC and SAQ, submitting only a ROC should suffice.
• The Problem with Logging. Which kind of logging are you guilty of doing most?  Over-logging?  Under-Logging?   Check it out, and also check the external SIEM links at the bottom.
• The Social Media Ban. This is me poking a little bit of fun at the PCI Community Meeting policy of no social media during the conference.  Yes, I realize that some of the Twitter feeds mentioned are merely placeholders or just with basic marketing information, but that’s not the point. The point is that someone thinks social media is important enough to create a space for the company to participate, therefore further legitimizing its existence.
• On Writing: The Funnel vs. the Brain Dump. This post, inspired by Ben Tomhave’s The Writing Funnel post, discusses how I create content, and gives tips for creating some of your own!
• Curious on Visa’s Deadlines? Visa is probably the best at communicating the intent of their CISP program.  None of the other card brands have as much documentation, or communicate over as many mediums, as Visa does.  Here is some information on upcoming deadlines and what they may mean to you!

Thanks for stopping by, San Diego!

One individual asked about the use of Data Discovery tools as a mandate to assist in the scoping of PCI assessments.  Imagine as a QSA walking into a customer, running a tool, and knowing EXACTLY the scope of the PCI assessment you need to perform!  There would be little chance that you under- or over-scoped it, and all those little nooks and crannies that scare the bejeebus out of a QSA would be documented right there for review.

escargot / snail, by OliBac

If you are the entity being assessed, imagine being able to definitively scope out sections of your network by proving to your QSA that cardholder data does not exist there!   No more endless expeditions down rabbit holes by your third party assessor.  Your security team will love it!

Regardless, there was interesting discussion by the TWG on this topic.  Some forensic investigators are using data discovery tools after breaches to understand how far cardholder data propagates through an organization’s infrastructure, then using that data to perform their investigation more quickly.  My guess is that these are home grown or custom applications of existing commercial products that examiners will use.  My experience says that very few products are up to the task of operating solely as a data discovery tool (and not as a component of a full DLP suite).

In order to know how to apply PCI DSS to your environment, you have to know where the data lives and where it goes.

The issue with most data discovery tools lies in the platforms they are written in, and the poor state of most IT environments that have evolved out of necessity and lack of budget, not out of forethought.  Only now have I seen more and more companies looking to ITIL or standardized methods for administering large populations of workstations that are largely homogeneous.  If you have a fairly consistent build and software process, then just find a tool that will work in your environment, then go.

Unix can be scripted, just get fancy with grep.  Operating systems supporting Java may be able to take short cuts and use existing java-based data discovery tools.  But moving outside of that homogeneous environment can cause major software headaches that lead you to drink.

Should the Council mandate their use?  Today, no way.  The technology is not nearly mature enough to have wide applicability across the entire spectrum of users that must comply with PCI DSS.  Once it is mature, mandating data discovery tools would be an excellent mandate from the Council as it would give assessors and their customers a chance to correctly scope the environment, and avoid embarrassing breaches to unknown (or poorly documented) data stores.

I’m heading back state-side after a great PCI Europe community meeting.  I didn’t get the final count, but the meeting had just north of 200 attendees.  It seemed smaller than last year, but that could have been the seating arrangement.  One of my favorite sessions is always the PCI Standards Feedback and Q&A Sessions.  This year was no different!

Blow up ATM, by laverrue

While the questions in the US were definitely more entertaining, I think the questions from the Europe meeting was more interesting.  Last year was the first PCI Europe meeting and the questions were much more basic.  They had a common theme from the first PCI meeting in Toronto, mainly because fines had not forced the issue outside of the US.  This year, however, with fines on the horizon, the questions were focused on the intent of certain requirements, and how they apply to the region.

One of those questions has a much larger applicability, but I don’t remember it being asked at the Community Meeting in Vegas.  Do the recently re-branded PTS standards apply to Automatic Teller Machines (ATMs)?

The Technical Working Group declined to comment in this forum, but it is an interesting question.  Why shouldn’t they be included?

ATMs are payment devices just like the card swipe or chip & pin machines we see at mearchants all over the world.  The only difference is that they typically have larger displays, are heavier and more physically hardened, and they spit out money on request.  They’ve also become a great target for hackers to prey on the trusting human (with a fake ATM), or to add sophisticated skimming devices to steal and take advantage of consumer payment data.

PTS should apply to ATMs, though the enforcement should come from the networks and financial institutions using or enabling these devices.  At a minimum, these standards can be used to remove some of the digital vulnerabilities these devices harbor, and add a little more security to the physical side.

What about you folks out there?  Should ATMs continue to be ignored?  Are we barking up the wrong tree?  Should we focus on PIN-Debit switching and key management instead?  Add your comments below!

That’s all for now.  I’m having a hard time concentrating with the gentleman next to me snoring as loud as he is.  This guy needs to go get that Pillar procedure performed.  Seriously.

Look for many more posts in the next several weeks from the meeting!

1. What do you mean by representative selection (or how many is representative)?
2. What do you consider sufficiently large to gain assurance?

Tease Bubble Tea Samples, by Mr. T in DC

In the audit world, internal auditors that review IT systems will look to statistically valid samples as a method to determine how big the sample size should be.  This is not as cut and dry as it sounds.  Even though there are formulas to calculate statistically valid samples, they rely on variables such as error rate and confidence, and altering either can dramatically affect the ultimate size of the sample.  These settings can also vary between disciplines, leading to spirited debates among auditors and assessors alike.

Google gives us a couple of nuggets, one being several spreadsheets that can help us, and a website that will do the work for us.  I’ve also touched on sampling in the past here in the blog.

The Council trained assessors to use Selective Sampling to determine sample size in the past.  This loosely translates to start with a few, see if they comply.  If so, stop. If not, dig deeper.  This method caused wide variations among assessors—some assessors electing to use a sample size of zero!  Most assessors using this method generally sampled two to three items in each population.

Selective sampling is no longer included in the PCI DSS, meaning that assessors are free to choose the most appropriate sampling methodology for the environment.  In order for ROCs to be complete (and achieve the best possible score during the Q/A review), assessors must describe their sampling methodology.  Some assessors choose to use statistically valid samples, some choose to do selective sampling.  Both are acceptable, it just needs to be documented.

So what should YOU do?  If you are facing a mid-year review of your PCI compliance and need to generate some samples, how should you go about doing this to get a realistic result?

The answer to this depends on your environment and tolerance for risk.  Many of our customers will turn this process over to their internal audit team whereby the corporate standard method of sampling will be used (typically some kind of statistically valid sample).  If you have a large environment and are not confident that you have kept variance inside the population to a minimum, try choosing a statistically valid sample with a higher error rate to boost your sample size.  If you have well defined processes and can say definitively that all machines are built identical and to pre-determined corporate standards (hint, this is PROBABLY not you) or limited resources force you to go with smaller sample sizes, try selective sampling or punching in a lower error rate.

If you choose to use statistically valid samples, use a 95% confidence rate and default to a 5% error rate (fairly common values). The most important part of sampling is to document what you did to determine the sample size, characteristics about the population, and all of your findings for each element in the sample.  If you are in doubt, consult with your internal audit team.  They may already have formulas ready for you to use!

Look for posts next week from the PCI Europe meeting in Prague!

The company’s server logs recorded only unsuccessful log-in attempts, not successful ones, frustrating a detailed analysis.

Logs serve multiple purposes, and for that reason they tend to grow rapidly.  Sure, storage is cheap nowadays, but every company still struggles with this very basic concept.  While I won’t speak specifically to the Wal-Mart incident (Evan Schuman has some great additions), I will address some of what I see with my customers and their struggles with logging.

Back on the Log Train, by Claire L. Evans

Over-Logging

This is more typical than you might believe, especially after reading the Wired article.  For example, we had one customer that installed a commercial logging package, turned everything on, and all the sudden was generating gigabytes of log data every day at every retail location.  What are you supposed to do with that?

Over-logging creates more problems than filling up tons of hard drives, it also causes transport problems.  Many security standards or best practices require that you a) log, and b) centralize those logs for various purposes like correlation, archival, and backups.  So if my satellite location is connected to corporate via a VPN over a business-class DSL, is it feasible to send gigabytes of data back to corporate servers daily?  What about with all the other daily usage and off-hours batch activities?  What if your business internet connection is a satellite VPN and your bandwidth resembles a 256Kbit frame relay (loves me 4 B channels tied together!)?

Log Texture, by Playingwithbrushes

Under-Logging

This is the one we focus on the most.  Logs can be some of the most valuable nuggets when investigating a breach.  One of my colleagues once investigated a breach that required imaging over 7 terabytes of drives before he finally found the source of the breach.  Why?  Because the lack of logging was so significant that there was literally no clues as to where the breach came from.  No sophisticated hacking attempt here where a hacker erased their trail.  This particular victim made it easy for the hacker because there simply was no trail!

Logs provide lots of valuable information regardless of your pre- or post-breach status (no, I did not mistype that).  If you have not had a breach yet, logs can be useful when looking for bugs, capacity planning, and finding ways to optimize your systems or applications.  For example, in next month’s column, I discuss how a development manager found a security problem in some code that I wrote ages ago by watching logging activity.

Those are the two extremes.  Where should we end up?

Right-Logging

Yeah, I couldn’t think of a better title for this last part here, so SSSSHHHHHHhhhhhh…

In order to get the most from your logs where they both add value and satisfy the requirements assessed by various security practices, you have to put the right strategy into play.  You first have to understand what capabilities your systems have.

In some cases (*cough* WINDOWS *cough*) you will probably be creating custom scripts or using third party software to capture what you need.  Be advised, turning ALL LOGGING ON will get you quickly into the Over-Logging category, and that is a spot you don’t want to be.  Instead, review all of the possible things you could capture and log, and choose the ones that make the most sense for your business.  It’s not easy, but the rewards are significant.

Once you are capturing the RIGHT logs, you will need some kind of tool to aggregate all of this stuff so you can make use of it.  Having one system kick out an error is not helpful, but being able to see that similar systems all over your enterprise are simultaneously kicking out the SAME error.  That’s where Security Information and Event Management (SIEM) comes into play.

This is a VERY hot topic in the blogosphere.  Here are a few bloggers (or blogs as it were) with valuable information on SIEM:

• Anton Chuvakin’s Discussions on SIEM
• SIEM Blog
• RSA’s bloggers discuss SIEM
• Andrew Hay’s view on SIEM
• Security Bloggers Network results provided by Lijit

Don’t dismiss logging as unimportant or irrelevant to your security plans.  Go back to those “fortress systems” that you believe to be impenetrable and ensure you are capturing logs to prove it!

WHAT ARE YOU LOOKING AT?, by nolifebeforecoffee

Thanks to a fellow reader for pointing this out!  It appears that MasterCard and Visa (sorta) have removed the reciprocity statements from their level definitions.  Discover still has the reciprocity statement on their levels, American Express and JCB never used reciprocity for their level definitions (to my best recollection).

Several industry insiders have been told that it was never the intent of MasterCard to force a merchant that accepts a single JCB card to go through an on-site assessment if they did not meet the MasterCard threshold.  Now it appears that this is the case as the official merchant level definitions reflect exactly this.

Unfortunately, the road does not end there.  In fact, it starts forking like crazy.

Now that reciprocity is gone, you have to take each card brand’s volume INDIVIDUALLY in order to determine your level and requirements. As you know, each brand may end up with different validation requirements depending on where you fall in the spectrum.  For example, a merchant processing 2,000 Discover, 2 Million MasterCard, and 50,000 non-ecommerce Visa transactions annually is considered a level 2 with MasterCard & Discover, and a level 4 with Visa.  This means they must have an on-site assessment thanks to MasterCard’s program (facing fines if you don’t) and submit a SQL to Discover, yet are not required to submit anything for Visa. WOW! Can it GET any more complex?

Yep.

Visa Canada still uses reciprocity in their merchant levels and still requires QSAs to attest to merchants’ SAQs.  For some strange reason, it appears that Level 1 Visa merchants in Canada must do both an SAQ and a ROC?  I think there is a typo there, but I could be wrong.

Your merchant level discussion just got much more complex.  If all else fails, your best bet is to list out your annual card acceptance rates by brand, and double check the levels on their website to determine what you need to do.  This is an important discussion to have with your QSA (if you use one) to make sure that all of the reporting criteria are met.

In the book, Mal’akh is searching for what he believes is the final piece to a puzzle that will make him an all powerful, deity like creature.  His quest began while imprisoned in a Turkish prison (yes he HAS seen the inside of a Turkish prison, Clarence) with the son of a prominent 33^rd degree Freemason.  From there, he traveled the world, ending up in Washington DC, to find and follow the clues that lead to the “Lost Symbol.”

Compass on deck of derelict fishing ship, by mikebaird

Sometimes I think security and compliance professionals follow a similar path.  Sure, we don’t start our lives imprisoned in a Turkish correctional facility (well, most of us anyway), but we do begin our quest without knowing much about security.  Our curiosity grows with each new nugget of knowledge we net, or with every mistake we make, in the process that leads to a security breach or a dirty scan report.

Deep down, the people passionate about security are all on a quest like Mal’akh. We are compelled to find that single symbol or phrase we can use to get the enlightened view of our security situation, complete with a path to nirvana, laid out in front of us.  Maybe it’s something we need for ourselves to fully grasp our situation, or maybe it’s something we need to use on others, so THEY understand why security and compliance are important.

I truly believe the good apples among us want our companies to fully grasp and understand why security is important, and how they can leverage the seemingly endless assessment and audit activities to their advantage.  A red mark on a report should not be viewed as the event that could cost you your job, but as the leverage you need to do your job better.  Sure, you’ve been hounding your management for months to deploy Wireless IDS/IPS in your satellite locations to help you defend against rogue wireless access points (sometimes installed by Ted in Marketing so he can sit in the conference room and totally work hard on his laptop).  That red mark in a report may just end up as the leverage you need to get it!

The danger lies in abusing this power.  Instinctively, most businesses do not trust their information security group.  They group us into the same hated army as auditors, and live in constant fear that we will be the ones to crush their latest project destined to earn them their bonus or promotion.  We want the business to reach out to us BEFORE they go to production, and help our associates earn that bonus or promotion without potentially bankrupting the company in a breach.

We can’t over assess everything and scream to management with every minute finding those assessments produce.  That’s irresponsible and arguably close to crying wolf.  Instead we should pick the issues carefully that we take to the Chief.  Not every finding is CODE RED DEFCON 1.

The Lost Assessment is that magical mix that security and compliance professionals endlessly search for that would cover all of their compliance needs, as well as apply security to stop the right attack at the right time.  We all know that you can overspend on security trying to prevent a single catastrophic event, but are we spending enough to prevent even basic attacks?  PCI DSS is a great start when looking for The Lost Assessment, but it’s narrowly scoped and does not broadly apply to all systems that may contain mission critical or other sensitive data on them.

Of course, if you are not set to handle the results from an assessment that wide and reaching, what’s the point?

Manager: “Tell me what the date is, and I’ll work toward the date.”

You: “More than a year ago.”

Manager: “I can’t manage to that. Go get an extension and tell me that date.”

Events Calendar, by Yandle

At this point, you pretty much should just make up a date.  Sure, an acquirer can give you a date, as can some payment brands, if you pick up the phone and call them. It does not ultimately mean anything if you are breached tomorrow.

For those dates in the future, Visa has the BEST communication plan and information site for you to reference.  Not all payment brands have quite realized the benefit of allowing their information to flow freely to all of the key stake holders, not just their members.

Visa recently modified their list of dates to clarify that All attended POS PIN acceptance devices must pass testing by a PCI-recognized lab by 7/1/2010.  Are you aware of the other big dates that are coming up?  One that is causing much consternation in the fuel industry is the TDES Mandate for all PIN-Debit transactions to use TDES as the underlying encryption algorithm—also due on 7/1/2010.

One thing to remember, these are ONLY Visa dates (which may or may not include Visa EU), and any other dates communicated or published by other payment brands may be different.  Using the Visa dates as a benchmark may be your best bet.