SOX

Regulatory compliance bits and bytes

Many years ago I found myself in one of those awkward moments where I needed to pay for something but didn’t have enough cash on hand to cover the bill. Rather than do the smart thing and find an ATM I instead elected to rip through my car and dig up all of the change that had been accumulating over the months and miles. After about five minutes and some disturbing encounters (food can morph into some bizarre forms when left under a car seat for too long) I somehow managed to come up with enough change to cover the shortfall. It’s amazing what you can pull together when you scavenge around and piece together disparate parts into one coordinated effort.

And so it goes with this week’s post. Here are some nuggets that I’ve gathered over time:

Policy and procedure: I was talking to a client today about password reset lengths. Turns out for one of their products they changed the password frequency to expire after 1,000 days. Their logic was that it was low risk because the application didn’t store NPPI and the security was really only necessary to ensure proper segregation of duties. So I asked them if they had a password policy (they did) and if so were they in compliance with the policy (they weren’t). After a momentary silence, their quiet reply was “good point.” Being the auditor that I am I couldn’t help point out that the worst thing any institution could do was to deviate from a documented policy or procedure, regardless of the reason. Once an examiner discovers something like that, they figure it’s an indication of related issues and wind up digging a bit deeper. Document what it is you do and than make sure you’re doing it; while it may seem simple enough, you’d be surprised how many companies fail on that point.

Pandemic planning: There’s still heightened concern regarding the swine flu and my industry continues to beat the drum about needing to have a pandemic response plan in place. While it’s a valid point, I’ve been polling my clients over the past few months regarding their first hand experiences with the flu epidemic. Only a few have been confronted with any legitimate outbreaks and none of them have experienced an absentee rate that required unusual planning or intervention. While I’m not advocating that a pandemic response plan is superfluous, I am questioning my peers who are pushing this as a top of the list agenda item. For my money I’d rather spend time making sure that a properly vetted and tested business continuity plan is in place and spend less time and effort getting caught up in the hype.

SOX: Banks that are required to be SOX compliant need to take some time to make sure that they’re thinking things through. GLBA is a fairly rigorous and encompassing regulation and extends deeply into a financial institution’s infrastructure. To a certain extent, it serves to drive a bank’s general controls framework, be it informal or otherwise, and as a byproduct goes a long way towards establishing controls typically associated with SOX. So when I encounter clients who are tackling SOX as if though it’s its own separate set of requirements I throw up the caution flag and try and force a reset. While it may be true that larger institutions need to extend significantly from GLBA to controls around financial reporting within the infrastructure, that would only represent a subset. Before doing anything different, the bank should bring in someone who has experience working with both SOX and GLBA to identify the (many) commonalities and produce a consolidated framework so that efficiencies are both identified and realized.

Year-end activities: In my last post I discussed how there’s an uptick in services work this time of year when many banks and credit unions remember that they still need to conduct a wide range of audits and assessments in support of GLBA/NCUA regulations. If you spend some time reading through FFIEC guidance (seriously, it’s not nearly as dry and boring as you might think) there are multiple references to “your most recent audit or assessment.” For those of you who think that the need to conduct this work is suggested rather than required, consider how it looks to your examiner(s) when they discover that your most recent risk assessment was either conducted several years ago or not at all. Do you really think it reflects well on your institution that you haven’t taken a serious look at the myriad risk factors swirling about your infrastructure for any considerable length of time? In a day and age when new threats emerge almost daily if not hourly how can you justify neglecting such a critical task? The examiners expect a current set of reports not only because it’s required but also because it’s a clear indication of solid management and oversight activities.

And on a final note, I’d like to share this link to the FDIC website. You’ll find a video message from Chairman Bair on the current state of both the FDIC and the banking industry. It’s really more of a “happy recap” (with all due respect to Mets fans) of similar messages she’s released over the last year. But I think it’s worth your time (about four minutes total) to hear it for yourself and gain a sense of calm about the security of your own deposits. And for those of you who might think I’m keeping to some sort of schedule regarding Sheila Bair references, as long as she keeps doing the right things I’m going to keep bringing her name up.

The COBIT framework isn’t an audit solution

I have an associate who has an addiction to certifications. He’s one of those “too smart for his own good” geniuses who often decides to change his career course and starts by obtaining whatever accreditation or cert is needed to do so. When he lists all of these accreditations and certs after his name it looks as if though someone tossed their alphabet soup lunch. But his logic is that having the appropriate governing body’s seal of approval is akin to knowing the secret password needed to gain access to the right job.

Sometimes I think COBIT is used much the same way.

For those of you who aren’t familiar with COBIT, it’s a framework that has revolutionized the world of governance and compliance for the better. It was the only beacon in the vast, dark ocean of SOX insanity a few years back, providing much needed guidance for corporate America to follow and continues to serve as the best source when designing controls within the infrastructure. It’s comprehensive, well organized and when understood and applied properly, it can be very effective.

But it’s not akin to the Bible and it’s definitely not an IT audit framework or program.

And yet I often hear fellow practitioners dropping COBIT references like it somehow validates them as legitimate members of the IT audit club (which by the way is called ISACA and only requires an annual membership fee).

Just this week, I heard that someone discussed conducting a COBIT-based audit when asked about their approach to conducting an IT general controls (ITGC) audit. Two weeks ago, my partner asked me about an RFP we received in which the institution wanted to know if we based our ITGC audit on COBIT or any other recognized framework. It’s gotten to the point where the term “COBIT-based” has become ubiquitous within the IT audit domain. Years ago during the aforementioned SOX insanity, there was a running joke with a client in which every sentence was laced with a SOX reference (e.g. Good SOX morning, Happy SOX New Year, etc.). Now it seems as if though COBIT has replaced SOX in that regard.

Um, has anyone actually read the framework? I mean actually sitting down and reading it from executive summary through to ME4 (the last of the control objective areas in the PDF). And how many people have actually tried to implement COBIT as it’s intended to be used? It’s a mountain of information that requires a ton of analysis and customization prior to being implemented. And it’s not intended for organizations both big and small. For many of the community banks and similarly sized credit unions that I commonly work with, it’s simply overkill.

But again, it’s not an audit framework and it’s not an audit program. And it’s entirely possible to build out an IT controls framework and never once rely upon COBIT to do so.

By the way, for those of you who aren’t familiar with the IT Governance Institute (ITGI), it’s a research think tank that exists to be the leading reference on IT governance for the global business community. In the time since COBIT made its inroads into corporate America and the audit vernacular, ITGI has amped it up a notch. Now they also publish Val IT and more recently Risk IT.

So now I’m bracing for the onslaught of risk assessments that are “Risk IT” based. But I never had a problem conducting a risk assessment before this standard existed and I doubt I’ll crack it open when conducting one in the near future. Did we really need this? And how will this drive the audit and compliance industry?

Frameworks have a place in this world, don’t get me wrong. But it’s like when I bought my Roto Zip hand saw a few years back; I walked around my house looking for things I could use it for rather than simply using it when it made sense. COBIT is awesome and it’s helped provide clarity in many, many ways. But it isn’t the official book of record for audit and compliance within IT; it’s just another tool in the toolbox. I realize that on the planet of ISACA that’s akin to blasphemy, but I offer no apologies. I refuse to build an audit program for a community bank that’s supported by two IT resources based on the 200 plus control objectives in COBIT.

And on that note I bid you a good COBIT day.

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.

How’s about a federally mandated Information Security Assessment?

I had a eureka moment recently that I’d like to share.

In considering the implications of the recently announced changes by MasterCard that will now require PCI Level 2 merchants to be assessed by a Qualified Security Assessor (QSA) it occurred to me that they may be onto something. Why would the credit card industry restrict who needs to be assessed based on size? Why not simply require any business entity that either issues, accepts or processes credit cards to be regularly assessed against the PCI standard by a properly trained practitioner? The size factor could come into play based on the frequency of these assessments but in general everyone would need to have one conducted.

That wasn’t the eureka moment.

It wasn’t until a day or two later, while reading about newly emerging state data privacy laws, that the clouds parted and the sun shone through. With the MasterCard news kicking around in the back of my mind, I started thinking about how these state-based laws were going to come into play, and when I tried to tie all of this back to the Obama administration’s cybersecurity plan, it happened.

What if all business entities that issue, accept or process personal information, regardless of their vertical, are required to have an information security assessment conducted (think GLBA meets NERC CIP meets PCI) by a Certified Information Security Auditor? Think about it; ISACA could be broken up with the subset that oversees the CISA process becoming federally chartered to both manage the framework and issue the certification (think PCI on steroids). The framework would include portions that are of the one-size-fits-all variety and others that are specific to an industry and would be scalable based on the size of an entity. The CISA practitioners would all be trained on the framework and how to apply it properly and would need to attend agency-sponsored seminars at least annually.

Rather than have multiple frameworks to wrestle with, business entities would be able to distill information security regulations down to a single, stronger entity (and reduce all the redundant activities that so many of my clients are forced to struggle with). It would bump the IT general controls audit up a level to encompass more than just bits and bytes and allow the entity to tie together related activities that are assessed through a single pass. And the icing on the cake is that the resulting report could also be used in place of a SAS 70 (and finally provide a modicum of consistency to the SAS 70 process as well).

But the best part of my idea is that the business entity could staff up with their own certified assessors that would not only conduct the required work, but also serve as internal advisors year-round. They’d still need to be properly certified and maintain that certification, but there would be no need to constantly pay premium prices for external firms and/or resources.

Maybe the idea was inspired by the fact that I’m just burned out a little from working on multiple compliance initiatives or maybe it stems from my concerns that true IT governance is a generation away. However, after my eureka moment and after sharing the idea with a few associates of mine I’m still liking it.

Does anyone have a direct line to the White House I can use?

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.

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.

Keep an eye on Shared Assessments.

About thirty seconds after I posted my last blog an item on the SearchFinancialSecurity.com homepage caught my eye.  It was an interview conducted by Marcia Savage with Michelle Edson and Charlie Miller from the Sante Fe Group about the Shared Assessment Program.

For those of you who aren’t already familiar with the Shared Assessment Program it’s a framework to assess third-party service providers that has been gaining in popularity over the past few years.  Created by BITS, “ a non-profit industry consortium whose members are 100 of the largest financial institutions in the United States”, it’s fast becoming synonymous with vendor management.  I’m hard pressed to recall a recent conversation with someone in the industry where, when the subject of vendor management was brought up, didn’t make reference to Shared Assessment somehow.

I’ve grown fond of saying that what CobIT became to SOX, the Shared Assessment Program  is becoming to vendor management.  Now, I’m an experienced hand with vendor management and some might even consider me an expert (though not for me to say about myself) and I’m hard-pressed to think of a better framework or approach to use when actually trying to determine what controls are in place and functioning at someone else’s company.  Conceptually it presents itself as a SAS 70 process but unlike a SAS 70 this has clear, concise and repeatable steps that remove any ambiguity from the process.  While it’s certainly true that the results are only as good as the people using it, the Shared Assessment approach at least serves as a relevant and comprehensive baseline.

I’m not going to offer a deep dive into the components of the program, feel free to check it out yourself.  What I will tell you is why you should be at least familiar with it and likely be using it for your own purposes.

First, it covers everything you’d want or need to within the virtual four walls of any company.  Take a look at what’s covered via the FFIEC guidance and related handbooks, take a look at any reasonable IT general controls audit program, read any SAS 70 report done for a technology service provider and map it back to the related Shared Assessment Program elements; it’s all in there.

Second, the language is clear and concise with almost no room for misinterpretation (I say “almost” only because I’ve learned never to underestimate or overestimate peoples ability to complicate the simple things).  Anyone can pick up the templates and start using them immediately with no direction or instruction.

Third, it’s great to use as a self-assessment guideline.  If you work for any organization in any business vertical and want to quickly get a snapshot of where your infrastructure is in terms of controls and their related activities open up the Standard Information Gathering questionnaire (SIG spreadsheet) and use the Lite version.  As a matter of fact, pass out copies to stakeholders in other areas of your infrastructure and ask them to fill it out and see what things look like from multiple perspectives.

Fourth, if you’re in an industry with strict regulatory oversight, particularly within the banking sector, this will help you standardize on not only what information you’ll need from your vendors but also what you want to be able to share with those external to your own organization.  When the examiners or external auditors show up to conduct their work and find that you’re using the Shared Assessment Program to measure and test yourselves it should engender confidence and reduce the amount of time necessary for them to conduct their own fieldwork.  That’s sort of what CobIT did during the early and insane days of SOX.  When the auditors showed up and discovered that you documented your controls so that they aligned with CobIT they tended to ease up a bit and place a greater dependency on management testing thus reducing time and (billable) expenses.  This is a similar opportunity and in this economy who can easily ignore the chance to potentially lower costs.

To be clear, Shared Assessments is not a vendor management program, it’s part of one.  You still have to conduct all of the other related activities involved (e.g. due diligence, contract compliance, etc.).  But for that all-important element where you need to obtain proof that the necessary controls are in place and functioning effectively at your third-party service providers (HEY BANKING COMMUNITY, PAY ATTENTION ‘CAUSE THIS IS IMPORTANT FOR GLBA) this is what you should require the vendor to be using.

Oh, and did I mention it’s free?

Why do you need policies and procedures? I’ll tell you why.

I once heard a parent say that they wished they had a dollar for every time their teen-aged child rolled their eyes at them.  I’m a parent so I get it.  But what I really wish for is to have a dollar for every time a client rolls their eyes at me when I tell them they need to have all their policies and procedures documented.

It happened twice last week, two different clients in two different states.  And it was a slow week.

A corporate lifetime ago policies and procedures were a nuisance put in place by management as a way to standardize business practices and attempt to use a single set of rules for everything everywhere they did business.  And it was a drag.  I have clear memories of my formative years on Wall Street with a seemingly endless row of binders on my cubicle shelf that appeared best suited to gather dust rather than provide anyone direction because in the end, well, all they did was gather dust.  So the irony isn’t lost on me that here I am a decade or two later standing on my soapbox explaining why having things documented is a good thing.

Twenty years ago there really weren’t enforceable regulatory standards such as SOX or GLBA.  Frameworks and assessment guidelines such as CobIT and NIST and ISO 17799 were either in their infancy or not yet developed.  And so outside of a very few pockets of industry there wasn’t a whole lot of good reason to have to put down on paper what you did, why you did it and how you got it done.  Sure there were the auditors that came around every now and again but things were simpler in those days and much of what they needed could either be found in the occasional dusty binder or grabbed from the data center operations library.

Today we live in a different world.  There are a seemingly endless number of regulations in place that are tested monthly, quarterly, semi-annually and annually.  There are rules as to how you must configure your network, your applications, your data (electronic and hard-copy), secure your facilities, your desktops, your laptops, your handheld’s.  The only thing left is the kitchen sink and technically even that’s covered if the kitchen is located within the secured perimeter of a data center.  The amount of work that must be done to be in compliance, to properly configure and secure your infrastructure is maddening. And so on top of all that work you’re now being told that doing the right things isn’t enough, you also need to document what you’re doing as well.

And so I get that rolled eye look which is often accompanied by the question “why do I have to document everything I do even if I can prove I’m doing the right things?”

I’ll tell you why; examiners and auditors are human.  Some are smart and savvy humans, some are sensible and knowledgeable humans and some are just humans.  Or rather, not everyone does their work the same way.  The only way to ensure that you can get credit for doing the right things is by documenting what you’re doing so that anyone coming in and trying to gain an understanding of how things run within your four walls has it laid out for them.  See here’s the problem, if you let an examiner/auditor wander logically and physically through your infrastructure they’re going to look for what they’d expect to find thus leaving you and your organization opened up to greater scrutiny.  They pull out lists that include everything they could ever hope, expect or dream to find and start asking for items on that list.  If you give them your road map explaining at the policy level what your organization is committed to doing and follow that with supporting procedures breaking out into detail exactly how those policies are supported you’re paving the path to be followed.  You get to steer the examiner in the direction that you want them to go, the direction that your organization follows.

Last week I had one client operating under two regulatory frameworks, another operating under three frameworks plus PCI; that’s a whole lot of audit activity to have to deal with.  Do you really want to have to repeatedly answer the same questions, conduct the same walk-throughs and explain yourself over and over and over again?  Wouldn’t it simplify your life if you set aside the time to document everything so that anyone can walk in, be handed the (gulp) binders and figure out for themselves how things work within your world?

I’ll admit, this concept is a bit self-serving though sincere.  If everyone had their documentation in order my job would be that much easier when I’m conducting the fieldwork.  But if you knew what I looked for and often found you’d also see where you’d benefit; I’m a former technologist who used to break every rule in the book and figure out how to circumvent every control that was thrown at me and so I’m the last person you’d want left up to his own devices while conducting an audit.

Oh and one more reason why you should do it; GLBA and SOX both require you to do so, so there!