PCI

In Memoriam: David Taylor

I was shocked and saddened today to learn of the unexpected passing of David Taylor, founder of the PCI Knowledge Base. My deepest sympathy goes to his family.

Dave founded the PCI Knowledge Base, a research community that shares information to help organizations achieve PCI compliance, after a 14-year tenure as an analyst at Gartner Inc. He was a wealth of information for my articles on PCI and provided his expert advice in an article we published this summer. Dave was always ready to help and never shied away from expressing his opinions. I really enjoyed working with him and will miss him, as will the industry.

Is perspective on our regulatory landscape a blessing or a curse?

I was away from the office last week trying squeeze in a family vacation before the kids head back to school. Despite taking the occasional phone call and replying to a number of emails, there was still plenty waiting for me today when I returned to my normal schedule.

It wasn’t until somewhere mid-morning after catching up with my partner that the incongruity of my professional life was revealed in an odd pattern. I’d read about a number of bank closings having been announced on Friday (sort of becoming a weekly ritual at this point) and two new reported credit card breaches (also fast becoming a same old, same old scenario) by the time I called into the office to touch base. Turns out we had a busy week beyond what I’d already knew about and we were discussing one proposal in particular to conduct an IT general controls audit (more on that in a few weeks) when the strangeness of the morning finally dawned on me.

Everyone is still working on trying to keep up with their regulatory compliance obligations, companies that participate in credit card processing are still pushing to obtain/maintain PCI compliance, and it just doesn’t seem to be making much of a difference. Despite our practice being busier than ever and there being a heightened sense of regulatory awareness out on the street there’s a general lack of evidence that it’s making a difference.

I’ve already beaten the PCI horse to death with regards to how the PCI-DSS by itself does not really go far enough (nor was it intended to be an be-all to end-all solution). I’ve long griped about how so much of what matters is missed by regulators due to too few budgeted hours available and lack of appropriately skilled and trained resources. So really nothing new about any of this.

But still, with a reasonably fresh perspective and clear head on this, my first day back to reality, it all seems that much more, I’m not sure what the right word would be…. depressing, frustrating, baffling?

How important can GLBA compliance be to a bank that’s just about out of financial options and on the verge of closing? And really, how much money should a company spend to be PCI compliant if that compliance doesn’t go far enough to actually mitigate the associated risks? I was just reading a story about how Intel turned things around in the 1980’s because their two senior most executives (Andy Grove and Gordon Moore) got together and stepped outside of their roles and imagined what someone new, with a fresh perspective would do with their company to address increasing competition and decreasing market share. Forcing themselves to obtain that perspective lead the way to a change in direction that would transform not only Intel’s fortunes but drive an entire industry into the future. So why can’t we do something similar for our financial institutions?

The short answer is that we can but it would require an act of bipartisan politics typically only observed during a true crisis such as acts of war and natural disasters. Of course it wouldn’t be too hard to make the argument that our banking crisis is a disaster, man-made or otherwise, but somehow when one party can blame the other there’s little chance of forging a common peace even if it benefits the citizens.

I’ll likely lose this perspective as the week moves ahead and get back to less of the “Big Picture” thinking and more of the nuts and bolts focus typically required of me, but still, I’m hoping someone, somewhere is reading this and thinking I’m right.

Does compliance equate to secure?

Despite earning a living in the space, I often question the value of regulatory compliance.

How is it that a business can be PCI-compliant but still have glaring vulnerabilities?  How is it that despite layer upon layer of controls it’s still entirely possible for an executive to fudge numbers in a spreadsheet and alter a company’s financial reports?  How is it possible that a financial institution undergoes an annual exam and, despite not adhering to the most basic tenants of FFIEC guidance, still receives a favorable report?  And how is it that there’s a regulation that made an entire industry jump all at once but has never actually been enforced (can I see a show of HIPAA hands)?

And don’t think these statements are pure hyperbole; these all come directly from the field and from engagements I’ve been on in the last few years.

Why, you may ask, am I feeling a bit down on the regs this week?  A couple of three reasons:

It started on Monday when I was catching up on my industry reading.  There was an article about data leak prevention (DLP) software and how sales have been heating up lately.  Of the reasons given by survey respondents as to why they were considering purchasing a DLP solution, the top two were pretty much pointing the finger at either industry or regulatory demands.  The third reason was to avoid damage to the company brand/reputation, the fourth was to avoid lawsuits and finally, all the way down at number five on the list of reasons: to prevent the theft of proprietary information.  That’s just Depressing (note the capital “D”).  I thought it was embarrassing that the vast majority of survey respondents were looking to prevent data theft not because it was the right thing to do or to protect customers’ or employees’ sensitive data but rather because they’re being made to do so.  And so maybe you can make the case that regardless of the reason, at least companies are being forced to do something about protecting their information.  Sadly, that’s exactly my problem.  When it comes to doing things for the sake of compliance most companies only take things as far as they need to in order to achieve/maintain compliance.  The people on the front lines sort of lack enthusiasm for doing these things and figure their job ends once the auditors and examiners are happy.

My week of regulatory woe continued on Tuesday when while reviewing key activities aligned against one of the aforementioned frameworks, I identified what was a potentially significant gap not in how the client was conducting their work, but rather in what the regulation specifically required.  In other words, despite my client being completely compliant with this stringent, well respected framework, there was still the very real possibility that a vulnerability could exist.  I dug a bit deeper, made some phone calls to associates whom I often consider to be way smarter than I and the result was that I was right, the gap existed.  One of my associates pointed out that in a well-run shop with a hardened infrastructure you would expect the situation I identified to be managed properly, but the reality is that unless they have to, few managers have the ability to go beyond what’s required (either by the business or regulations).  I suppose if ever a day comes to exist when an IT department has finally cleared out their project queue and has money left in the budget they may very well get around to it, but I’m not volunteering to hold my breath.

And finally, my week is closing with news that a former client of mine is on its financial ropes and very likely about to declare bankruptcy.  Really, in the end it’s just a sign of the times and the sad state of our economy.  They appeared to be making the necessary adjustments over the past few years by trimming back staff and scaling back on non-critical projects, but they’re a half-inch to the left of the epicenter of this whole financial mess and in the end I guess there was no way to avoid the inevitable.  But still, I think of all the money they’ve spent on compliance-based initiatives since SOX first hit the scene and I can’t help but wonder if all of that spend could’ve been put to better use.  In the end, despite all of the great work that was done they still weren’t going to be able to prevent someone from massaging the numbers in a spreadsheet (a personal pet peeve of mine)   Thinking about the number of people they’d brought in to size up and conduct the work to bring their controls up to the necessary levels and the fees they’ve paid to their external auditors to conduct the SOX audits is just plain depressing.  Maybe if they’d used that money to fund a project to offer a new product line or enhance an existing one, they’d have found additional streams of revenue that could’ve helped them through this mess.

I suppose it comes down to this: anything worth doing is worth doing right.  But in the regulatory space that’s not the general rule and I’m thinking that until the oversight bodies figure out a way to provide the proper incentives, the work will always be lacking if not deficient.  Until being compliant also means being secure the job isn’t truly getting done.

Along those lines check back next week; I have an idea I’d like to share with you about how to make things better for all of us in the regulatory domain and turn things around.

2 for 1 sale: How governance leads to compliance.

A while back I’d written about the Unified Compliance Framework from Network Frontiers, which takes quite literally every regulation and framework within the IT domain and maps them in such a way where you can identify how a single control addresses multiple requirements. In this day and age, the era of regulatory overload, with even more regulations heading our way I consider the product an essential tool in managing the required work. However there’s in important caveat to throw out there; the benefits of the UCF product can only be fully realized if it serves as the underpinnings of an IT governance program.

Ah yes, IT governance, a favorite topic of mine and one that’s a sure-fire way to get me to whip out my soapbox and fire-up the accompanying rhetoric. I’m a practitioner first and a theorist second and the combined perspective provided by both has forced me to become a huge advocate of governance as not only the best way to achieve regulatory compliance but perhaps the only way. I’ve reached the end of my rope when it comes to the currently popular way to pursue compliance, which is to build silos and assign each its own regulation or industry framework. How does it makes sense to have, for example, two or more groups of people testing user account provisioning when a single test can be used to satisfy both? It doesn’t and by doing so it wastes time, resources and money.

And so now I’m getting to do something about it.

My current “big” project has multiple parts. The client is managing the consolidation of two business entities including their regulatory compliance initiatives. It’s resulted in their needing to build out a plan to merge four sets of existing regulatory compliance frameworks as well as taking over responsibility for another that’s brand new to their mix. Beyond the doubling up of the required work, it’s also resulted in a new compliance team that’s sizable and using headcount within an IT organization doing work that’s not really IT-specific. That’s the bad news.

The good news is that the client had empowered the team responsible for managing compliance to switch to a governance approach a few years back. Rather than serve as an after-the-fact function that tests to make sure controls are working effectively, this group has served as both an adviser to IT, helping strengthen controls and has streamlined the testing process so that stakeholders pass along evidence of their daily activities, thus reducing the need for the typical testing cycle fire drill that most of know. It’s served two purposes for the IT organization: It eased their burden in the compliance process and made them more trusting of the audit and assessment function.

But in the short term, the consolidation has dramatically increased their workload and at a time when management is looking for ways to reduce expenses and get more for less. How do they proceed? How do they consolidate the related frameworks, assume oversight for the new ones and continue delivering the value and efficiencies that they’ve come to be known for? There’s only one way: by taking IT governance to the next stage of its evolution.

They already understand and practice the basic elements of IT governance and so the foundation has been laid. Now it’s time to take it up a notch to the next level. Thus the tie-back to the UCF approach. If you have multiple frameworks to comply with, the commonalities to be found between them are significant. I know this based on my own research and analysis and can now prove it courtesy of UCF. The manager of the IT governance function is also a believer of this approach and the plan is to build out a true IT governance program so that all in-scope frameworks are to be managed via a consolidated approach. All current and effective frameworks will be supported through the end of 2009 but along the way each control and related activity is being reviewed to identify opportunities for consolidation. Once done, all IT-based activity will be viewed through the lenses of the new governance framework so that compliance is maintained and changes to the infrastructure are evaluated for any potential regulatory impact. And the best part is that all of this will likely be done with less effort, thus freeing up resources to focus on more IT-centric tasks.

Imagine that, a world where compliance is achieved through a coordinated proactive governance approach and IT resources are free to focus on technology-based activities. It’s like solving two problems for the price of one with the added benefit of actually spending less money overall.   What CIO/CTO wouldn’t like that?

Financial regulations and my crystal ball.

I had a great piece lined up for this week about a governance project I’m working on but was waylaid by all the news that hit the radar around regulatory reform.

In what may be the understatement of the year, the plans revealed last week by President Obama and his administration to overhaul the financial regulatory domain is stunning.   It was equal parts common sense (dissolution of the Office of the Thrift) , politics as usual (government intervention for distressed larger institutions) and forward thinking (creation of a consumer oversight body).  But for practitioners in the regulatory space such as myself the news was a warning that we all had better pay close attention to what’s about to happen.

The largest percentage of work my practice does has less to do with making sure our clients are in compliance with the broad range of regulations they operate under and more to do with educating them on what that means and how best to achieve it.  The very first step our practice takes with our clients is in understanding their profile, size and risks and then set about designing or assessing them based on what makes sense.  Take for example vendor management; not every vendor needs to be part of your vendor management program but because so many institutions form a baseline based on vendors in their accounts payable system they tend to add an enormous amount of work that’s just not necessary (a particular sticking point for my partner).  Regulatory compliance is not a one-sized-fits-all exercise and after nearly a decade of dealing with the regulatory alphabet soup of GLBA, SOX and PCI (in varying lengths of time) it’s amazing how little is truly understood about each framework and how best to apply their principles.

And now it’s all about to change… again.

Much like what occurred with the last major regulatory step forward with the Identity Theft – Red Flags law that went into effect in 2008, we’re going to need to work hard to get out in front and understand the new rules as they’re being rolled out.  Traditionally, much of what’s necessary to comply with any regulation already exists in large part within any organization.  The work that’s typically required is in identifying where it is and making sure it’s documented sufficiently so the work can be measured and assessed properly.   I’m sure that much of the work that’s going to result from the proposed changes will align with quite a bit of what’s already in place (or should have been in place).  But understanding the new rules is going to be a huge amount of work for those needing to comply and will require time and effort.  And all this at a time when headcount has already been thinned out and staff is working extra time to keep up with their day-to-day workload.

So for my fellow practitioners I’m putting it out there that we need to step it up too.  We need to make sure that we’re engaged in the dialogue early on and that we’re working quickly to interpret the new rules as they’re working their way through the system.  The current regulatory burden has proved to be challenge enough and with the likely musical chairs scenario that’s going to ensue as the rules shift around, it’s incumbent upon us to be prepared to ease the burden, flatten the learning curve, and help the affected institutions fall into line while keeping up with the speed of business.

The sad irony for me in all of this is that despite all the work that’s about to ensue, I’m somewhere close to certain that very little will improve as a result of the exercise.  I was looking through all of what’s been proposed and I mapped it back to the issues I’ve encountered over the years I’ve been toiling in the regulatory space and there’s still a gap.  The biggest problems originated from a lack of proper regulatory oversight resources in terms of both the hours and skills to conduct the necessary work.  You can have a strong set of rules that need to be followed but if the people assessing your performance against those rules either don’t understand what to look for or don’t have the time to conduct the necessary steps, what’s the point?  And consider what happened in the credit union space this year where, due to the onetime assessment, many CU’s fell below required reserve amounts and thus were considered to be at risk.  The NCUA instructed their examination teams to still assign an appropriately adjusted rating but to go easy on the report because there was a new normal (I’m paraphrasing a bit but that was clearly the gist of their message).  The rules were there for a good reason and the measurements tried and true but when circumstances called for it they were pushed to the back-burner; how is that going to change?   And finally, I offer my favorite broken control and one that’s potentially at the heart of this economic crisis we’re struggling with: real estate valuation.  When I bought my last house in New York, the appraiser conducted all his required steps (e.g. physical survey, square footage and finding recent comparable sales, etc.) and when all was said and done he declared the house was worth the purchase priced we’d offered.  I asked our real estate agent how it happened to be that his appraisal and our offer were identical and she told me that with the market so volatile it was impossible to conduct a meaningful appraisal and so they typically just went with the offer price.  How did that add any value to the process?  Will any of the new laws implement the proper checks and balances to assign accountability to lenders and their agents in the field?

Ultimately, I’m thinking the problem hasn’t been with the current regulatory rules but rather their inconsistent application and enforcement.  Regardless, change is a comin’ and it’s going to be an interesting and bumpy ride as we wend our way through it all so strap yourself in and hold on tight.

Risk is at the heart of what matters most.

I had two great conversations this week regarding risk assessments (jeez, does that ever sound geeky).

The first conversation centered on what an associate was expecting  to accomplish via the risk assessment process and the second one was a general conversation about the proper approach to conducting one in support of PCI.  Fundamentally, at some higher level a risk assessment looks like a risk assessment regardless of its intended purpose.  But at the ground level, there are huge swings and variances between different types of assessments and how they’re conducted.

The first go-round centered on GLBA and was with a fellow practitioner I’ve worked with before on audits.  The conversation started because my associate was preparing to conduct an information security risk assessment later this month and was talking about all of the planning effort required before, during and after the fieldwork.  I commented that it sounded more like he was conducting an audit rather than an assessment; his reply “same difference.”  And I thought to myself “funny, it sounded like he just said that an audit and an assessment were the same thing.”  So I asked him to clarify and he did by stating that the only difference between the two was whether or not you needed to create work papers.  I was stunned by this shocking admission and obvious lack of understanding of our trade.  An audit tests in-place controls to determine if they’re working as designed and are sufficient to address the related risks those controls are intended to manage or mitigate.  An assessment examines objectives or assets, identifies risks to either and then looks to see if there are controls in-place to manage those risks.  I can get more granular than that but at its most basic level, that’s how it’s supposed to work.  Risk assessments identify risks and related control activities and audits test to see if the necessary controls are present and that they’re working properly.  He also shared with me that he uses the same general outline of questions and topics for both, that they’re both based on FFIEC guidance and that it’s exactly what the examiners are expecting.

OK, first of all, the examiners are not expecting that the same work is being done for both an audit and an assessment.  I’ve spoken with enough of them to know that plus I’ve heard several of them stand before large audiences and explain the nuances of both and so I know they get the differences.  Second of all, the entire purpose of a GLBA-based assessment is to ensure that at some acceptable frequency (which secretly means annually) each financial institution should conduct a thorough assessment of their infrastructure (not just IT, by the way) and identify and measure risks and threats to the customer data they manage and store.  If you move right past the assessment and conduct an audit you’ll never truly know if you’re missing something because you’re only testing what you can see.  I’ve participated in and conducted enough of these to know this to be true.  And if you conduct an assessment like it’s an audit, you have the same basic issue.  Thus the reason why you typically schedule an assessment first and an audit second.  I was about to explain this to my associate but decided against it; I somehow thought it would’ve fallen on deaf ears.

In the second conversation I participated in around risk assessments it was all about PCI.  This one was much easier because the team running the assessment had built a high-level approach based on guidance from the PCI DSS Council itself and displayed a clear understanding of what they were to do.  While they hadn’t developed any of the templates to be used (it’s not due to be conducted until next month) they were well into the planning stages.  My role was to simply listen and provide any meaningful feedback.   The one potential gap in their intended approach is that they were taking an asset-based approach to the assessment.  What that effectively means is that they only look for and attempt to measure risks around what they can see be it a piece of equipment or a documented process.  But if there’s something that doesn’t appear on an inventory, a network diagram or exist in a binder somewhere, they’ll potentially miss it.  A great PCI for-instance is what happens when a customer service rep writes down sensitive information on a pad because their system is hanging and they’re trying to keep the call within acceptable time frames?  It’s not supposed to happen but I’ve been in a dozen call centers over the past few years and have personally witnessed it happening in almost all of them.  If you were to rely exclusively on what’s documented, you would note that typically erasable whiteboards are to be used for such situations and so you would consider that to be low risk.  But the risk increases significantly if you move past the “thing” you’re looking at and poke around a bit.  Assuming that they do use a scratch pad on occasion, what happens to that piece of paper after the transaction is completed?   Is it thrown out and if so, is it placed in a secured bin or in the regular trash?  And so I advised the client to approach the assessment like it’s an Easter egg hunt.  Deviations and violations are always swirling about (we’re human, we make mistakes) and as part of the assessment process you should be looking for where that might be happening.  But the best part of the Easter egg approach is that it gets everyone involved in the conversation thinking a bit outside the box and that’s where the really neat information is found.  And really, in the end, that’s what a well-run risk assessment should be all about: seeking out and measuring risk wherever it may be hiding.

When the PCI conversation concluded I was feeling a bit energized because in brainstorming with the client I had the ideas flowing freely.   And than I recalled the first conversation and I could almost hear the screeching tires and smell the burning rubber where my creativity came to a complete halt.  It’s amazing to me how the term “risk assessment” can mean completely different things to different people.  I was as impressed with my client asking for guidance and wanting to get it right as I was disappointed in my colleague for having it all wrong.  This wasn’t an issue of principle but rather results; how can you properly manage this thing called risk if you don’t even know how to begin looking for it?

Speaking of risk, check back next week when I jump back onto the GRC train of thought and bring you up to speed with something I’m working on.

Why financial institutions might want to keep an eye on the energy industry.

Through an odd turn of events over the past few months I’ve found myself actively engaged with a group that’s focusing quite a bit of effort on NERC CIP. For those of you not in the know, NERC (North American Electric Reliability Corporation) is to the energy sector what PCI is to the credit card industry and CIP (Critical Infrastructure Protection), like the PCI-DSS, is a set of controls that need to be complied with. My involvement came by way of a relationship I established earlier this year with a security firm that takes a really innovative and interesting approach to helping clients identify risks and vulnerabilities. The firm reached out to me because I have this soapbox and was looking for exposure. In the time since I’ve not only continued the conversation but have become part of group of security and compliance thought leaders that the company’s compiled to help further refine and focus their vision. As luck would have it, I happen to be actively engaged with a client that’s in the energy sector (I was brought in because of my SOX and PCI genius) and so here I am with my worlds converging on me….. again.  As such I’ve been thinking about NERC CIP quite a bit these days despite typically hanging around banks and credit unions.

So why am I bothering to bring this up? I mean, this site is focused on the financial world not energy. And it’s not like there’s ever any shortage of things to discuss with regards to security, compliance and the financial verticals.

Because NERC CIP may prove to be the standard that ultimately becomes the framework used by President Obama’s administration as a baseline for national cybersecurity measures. It’s already federally mandated, courtesy of the Federal Energy Regulatory Commission (FERC) which oversees NERC, it’s high-level enough to work across business verticals (though it would need a reasonably thorough rewrite for which I hereby volunteer to help with), and has already been validated as strong enough to be used to make sure the electric grid is not needlessly exposed. And at this point in the evolution of information security and regulatory compliance, I doubt there’s a need for yet another new framework. So I’m putting it out there right now that I’m betting money that the soon-to-be-announced cyber security czar will eventually find his/her way to NERC CIP and recognize it as a viable baseline.

Here’s the view from up-high:

• CIP-001-1 Sabotage Reporting
• CIP-002-1 Critical Cyber Asset Identification
• CIP-003-1 Security Management Controls
• CIP-004-1 Personnel and Training
• CIP-005-1 Electronic Security Protection
• CIP-006-1 Physical Security Program
• CIP-007-1 Systems Security Management
• CIP-008-1 Incident Response and Reporting
• CIP-009-1 Disaster Recovery

You have to admit, it’s straightforward and pretty much covers what’s needed. And yes, I know, there’s way more detail to be found underneath the section headings but let’s keep it simple for the purposes of this post. What else would you want to include for a federally mandated cybersecurity framework?

As for why this seemed like a good topic for this particular forum, it’s really quite simple: Something like NERC CIP is coming soon to every business vertical and not just those within shouting distance of the financial industry. And it will potentially be here before anyone can even say “Happy New Year’s” again. While most of those in the banking sector are already accustomed to such requirements almost everyone else isn’t. With PCI having been a shocker, I can only imagine how this is going to play out. I’m just using my digital pulpit to try and jolt people into thinking about what’s rolling down the regulatory highway towards them so that when the headlights are upon them they’ll maybe be just a little bit prepared.

As an aside regarding President Obama’s press conference last week discussing the cybersecurity 10-point plan, the only truly great thing to come out of it was the fact that it pushed information security to the front pages for the day. Professionally speaking, I thought it lacked any real bite and while I know these things take time I was expecting that there would at least be dates and names aligned against the bullet points to set expectation and assign responsibility. Considering that the plan was based on a report generated by some pretty sharp minds who were likely ready to begin rolling weeks (if not months) ago I was less than thrilled.

Information security pros (and cons).

Ever since I first started blogging I’ve worried that there would be weeks when I would simply draw a blank when it came to finding a topic worthy of the audience’s time and attention. While I may have hit the occasional bump in the road with posts that weren’t of the “keeper” variety, I’ve been relieved that my day-to-day experiences have never left me short of ideas. But every once in a while I come across a nugget, a relatively minor kernel of an idea that while potentially interesting isn’t by itself enough to fill the page. And so I tend to keep a list on the side that I use to simply jot these things down and review every now and again.

So imagine my surprise that when I added my latest little bit of genius to the list a pattern presented itself to me that hadn’t been there even a week ago.

For those of you plying your skills as Information Security professionals, I need to warn you what follows is potentially inflammatory, insulting or validating; it all depends on how you look at your career.

I was stunned a few months back when I noticed on LinkedIn a new application called “TripIt.” The main idea of the application is to enter and track your trips, be they business or personal, including locations, dates and a general description and then post it on your LinkedIn page. The end result is that everyone who can view your LinkedIn profile can also see where and when you’re traveling. My first thought was that it was just a bad idea within the professional domain. It’s a common rule within the infosec space that you should never send email auto-replies to anyone outside your company indicating that you’re out of the office lest it provide hackers with an opportunity to try and hijack your account while you’re away. That rule also applies to voice-mail greetings for the very same reasons; it’s just too much information. The first five people who I noticed using it were, gulp, infosec pros.

Then two weeks ago, I was conducting fieldwork during which a tremendous amount of pomp and circumstance was placed around physical access controls that were designed and implemented by a group of security folks; they had followed a tried-and-true recipe in designing the related controls. From the outside looking in, everything looked great. From the inside looking out, there were more holes than on a golf course. While at a fundamental level their critical data was exposed to very little risk as a result, the amount of peripheral damage that could’ve been done elsewhere was substantial. I’ve been known to complain in the past about controls that look great but don’t work, but in this instance I was disturbed by how obviously smart people had simply followed a canned recipe without truly thinking things through and validating the effectiveness of what they’d done.

This week I’ve had the opportunity to review two resumes from people who are likely way smarter than I, both are information security consultants. Both individuals listed accomplishments and capabilities within the security domain that pretty much touched on just about every segment of the infrastructure. I believe I have a good nose for legitimate resources and both of these people presented themselves quite well at the bits and bytes level. But neither of them tied their experience back to solving business issues. With all of the well publicized work around mandates and regulations (e.g. PCI, data privacy, NERC, SOX, etc.) you’d think there would be some attempt to connect their experiences back to something someone in the executive suite would appreciate or recognize.

Maybe I’m over thinking things but shouldn’t people who advertise themselves as information security professionals be a little less binary and a bit more aware? While it’s important to have devices and software configured properly, isn’t it that much more important to be contextually aware and understand what’s needed to protect the business and its information assets?

This has become something of an issue for me lately as I’m working with multiple clients who are dealing with a broad range of challenges. I’ve become increasingly aware that there’s more than just a fine line between a security engineer and a security expert. One can tell you all about firewall rules while the other can tell you where to install them and why. One can work their way down a checklist ticking off to-do’s (think PCI self-assessment) while the other considers the applicability and risk of each item before so much as touching the keyboard. And yet both tend to present themselves similarly and they’re not.

If you’re truly an infosec professional you need to display that in how you make choices (restrict the personal information you share with the digital world), in how you conduct your work (design controls, try and break them and then close the gaps) and in how you decide what’s necessary and sensible (encrypt credit card data but also make sure sales people aren’t writing down non-public personal information on scratch pads). Don’t become an expert on tokenization and think that qualifies you to design a complete PCI security plan. Don’t advise your clients/users on proper security practices and then go out and fail to follow your own advice. And don’t ever think that because you’ve satisfied some regulation or framework that you’ve gone far enough to mitigate or manage risk.

In this day and age, with the threats to our digital assets greater than ever and with increasing pressure being brought to bear by government and industry regulations, it’s more important than ever that the right people be put in the right positions to help address these myriad challenges. And it’s more important than ever to understand that not all information security professionals are alike; decide who shall lead and who shall follow and be sure to chose carefully.

Next time out I have some interesting insights to share regarding NERC, so be sure to check back next week.

PCI compliance is not the end all

I was sitting in on a meeting this week during which a security review was being conducted for a proposed software solution for my client. The product was designed and hosted by a third-party vendor.

At first blush I was impressed with the scope and depth of the review; it was a comprehensive security assessment more than anything else. The questions being asked were the right ones, the information collected and reviewed seemed to substantiate the answers and the people participating in the review were all at once curious and knowledgeable.  The sum total of these parts equaled good things.

Until I noticed a comment embedded within one of the vendors’ responses.

In regards to the question “Does the vendor have a recent SAS 70” the response took a sharp left turn and drove straight towards the wrong answer. The vendor ignored the question and instead described how they’re PCI certified. First, that’s not the right answer because PCI is very narrowly focused on a subset of the infrastructure whereas SAS 70, in theory, is much broader when applied to a technology vendor. Second, PCI certified almost always means that a self-assessment questionnaire was completed by the vendor and submitted to their processor for validation. Unless the vendor is Tier 1 (which means they process in excess of six million transactions per year) there’s no external validation of the responses in the questionnaire. So you don’t really know how accurate or reliable the answers are anyway. Third, the vendor they referenced as conducting their quarterly scans was recently placed in remediation status after the PCI police found that they had violated QSA validation requirements. That’s not much of a confidence boost, is it?

In the end I suppose my biggest (and really only) issue with the process was that to the untrained eye the information presented looked great. But I couldn’t get past the fact that they blew right past the SAS 70 question and presented what appeared to those in the room as being a strong answer despite the fact it was the wrong one and fell apart under scrutiny.

Ultimately, I’m hung up on this one wrong answer and my reasons are twofold: Will people confuse PCI as a true security standard and if so, will the majority of the IT community go with the assumption that any framework applied and certified, authorized or approved is as good as the next?

I sure hope not.

Check back early next week because for those of you who dabble in governance I’ve got something really cool to share with you.

The road to PCI compliance is fraught with potholes.

I’m a fan of diversification. Professionally or personally I strive to mix and match and switch things around to avoid falling into a rut and to keep things fresh; I’m hopeful the contents of my blog reflect on that. And yet, here I go again about PCI simply because one of my current projects has pulled it into scope and dropped it tap-dead center on my radar.

I participated in a conversation with a client late last week in which the standard was discussed and I’ve thought about little else since. Why the dramatics you ask? Because it brought to light another issue with the beleaguered framework that for me, comes at a time when it’s already teetering on the edge of credibility.

For all but Level 1 candidates, PCI allows for an organization to conduct their own self-assessment and determine whether or not they’re compliant. And so you don’t really know if the quality of the assessment is up to snuff and even beyond that you don’t really know if it covers enough of the landscape to truly be meaningful. To compound the issues around the self-assessment process is that the people typically responsible for PCI are focused primarily on trying to achieve compliance as if though that by itself is the goal. For them it’s a series of steps to go through and, if there are no significant issues noted, are able to lay claim to the grand prize commonly referred to as being PCI compliant. But is that really what was intended when the credit card companies formed the PCI Council?

If you go to the website (https://www.pcisecuritystandards.org) one of the first things that you notice is where it states that the “PCI Security Standards Council’s mission is to enhance payment account data security by driving education and awareness of the PCI Security Standards.” Where is the awareness when only a select few within a company are even aware of what is required by the standard? And how aware are even they if the focus is on doing what’s necessary to “pass” rather than working to push the related controls deeper into the infrastructure?

It’s not just that so many in-scope organizations fail to apply the standard properly (e.g. TJ Maxx, Hannaford, Heartland, etc.), it’s that they don’t see it as the blueprint that it’s intended to be. Being PCI compliant simply because a small (but representative) subset of your infrastructure passed the test is not the goal, having the proper controls effectively deployed across the entire infrastructure is. The standard was created so that you know where you need to be looking, what you need to be looking at and what the people within your organization need to be aware of in order to support the standard. It truly is intended to be more about education and awareness and less about acing an exam.

I sliced into Visa a few weeks back for their finger-pointing posture related to Heartland and in the past I’ve been known to criticize the PCI Council as well for similar reasons. Stop playing the blame game! Go back to the beginning, back to the basics and remember that the purpose of the exercise is to provide a basic set of controls that are required at a minimum to protect card member data. It’s up to each organization to make adjustments that reflect on their own unique infrastructure. And ultimately that infrastructure shouldn’t be measured by PCI-DSS but rather viewed through its lenses.

The credit card companies and their PCI Council should be incenting businesses towards a time and place where they can claim that they manage in a style consistent with the basic tenets of PCI and away from where they strive to achieve a point-in-time designation whose value expires the moment anything within their infrastructure changes. To quote Michael Douglas in “The American President” movie: “We have serious problems to solve, and we need serious people to solve them.” We need those in positions of influence to not pull back on PCI but rather push forward, make the necessary course corrections and continue getting the word out and providing support to those who need it. When the next breach is made public (because it’s already happened only we don’t know about it yet) I want to see the people in charge come out and tell us they’re committed to understanding what happened, why it happened and how they can adjust PCI to help reduce the risk of it happening again.

And really, in the end, what I want personally is the chance to obsess over something else and send PCI to the back of the blogging line.