Seriously, it’s a big deal. And so far it’s much adieu about nothing.
I don’t know what the actual hold-up has been. A draft of the new guidance was leaked online last year (ironic, don’t you think) and heavily circulated a while back but no one in any position of authority has offered word one as to whether or not that’s close to what the official document will look like. But here’s my question to stakeholders throughout the banking industry: Why are you waiting for the FFIEC to spell out what you need to do?
I suppose if you’re committed to doing the bare minimum expected by the examiners and not interested in extending your solutions to adequately protect your customers that’s a sound strategy. But why do you need anyone to tell you what to do? Shouldn’t you be continually assessing your environment, keeping current with existing and emerging threats and designing controls to reign them in? That’s not only a solid business practice it’s also heavily implied by, wait for it, FFIEC guidance. That’s right folks, if you’re supervised by any of the FFIEC sponsoring agencies they’re already expecting you to conduct periodic assessments and modify your infrastructure to mitigate and manage identified risks. But that’s really more theory than practice. All too often management is willing to wait and see what their annual exam reveals and only address those things that the examiner cares about. And because examiners typically operate under the constraints of limited hours they look at what they can and the rest just has to wait (and sometimes wait and wait and wait). So while a key requirement may not be satisfied, if the examiner didn’t have time to look into it the gap remains unchanged. Again, why does that happen?
I recently brought up this very topic during an internal meeting within my practice and one of our subject matter experts laughed at my naivete. As he pointed out so matter of factly, the only reason most of the FFIEC-centric activities ever really happen is because financial institutions don’t want to fail an exam. Rare is the management team that builds out their controls in an attempt to address the so-called “industry best practices” and instead does what they believe necessary to keep their examiners happy. And so if the FFIEC doesn’t spell out minimum requirements to authenticate and protect online banking solutions there’s little chance the industry will move in the right direction.
But what if the guidance falls short of what’s necessary to get the job done? What if it only frames the problem but doesn’t actually tell you how to solve it? Remember, the primary purpose of guidance is to raise awareness to the issue but not necessarily how to fix it.
I offer as a for-instance the most recent publication from the PCI folks. They just released a new document providing guidance for virtualized infrastructures (which is really a fancy term for cloud computing). I’ve been somewhat outspoken on this very topic because I’m not confidant that in-scope infrastructures have done enough to address traditional PCI guidance in a somewhat homogeneous environment – now these same companies are chomping at the bit to move things into the Cloud. If you couldn’t properly secure and monitor a configuration where each device could be identified and configured how are you going to be able to do it on a platform where you never really know where your information passes through? But the leadership atop the PCI council at least decided to try and frame not only the challenge but also provide some direction on what to do about it. And their guidance boiled down to this: No one can tell you how to secure relevant parts of the Cloud configuration so the only way to be properly compliant is to make the entire configuration compliant. I’m sure that when the audience first downloaded the document they were hoping to find directions for a clear path to being able to leverage the latest and greatest technology without having to boil the ocean. Instead they were told that you have to assess the environment and introduce PCI-related controls anywhere there’s a possibility in-scope data might pass. With that one broad stroke of a digital pen they pretty much made Cloud computing a much more costly investment for those who need to comply. Their guidance didn’t solve the problem, it just defined it more clearly and delivered the bad news that there would be no shortcuts available in effort or cost. And while it may not be popular guidance it is, ultimately right.
As for the FFIEC guidance I’d offer this as food for thought: If you have weak or deficient controls around online authentication your examiner is not going to give you a free pass because the new guidance is delayed. They’re not going to let you off the hook if you’re missing something significant simply because no one told you it was missing. You’re supposed to figure these things out for yourself, they’ve told you that time and time again. And while I won’t know for sure until I know for sure, I’m expecting their guidance will be somewhat similar to the PCI Cloud publication where they frame the problem and summarize by telling you that you need to figure things out based on your own unique infrastructure.
Seriously, don’t wait for the industry to tell you what you need to do when you should already know what that is. As Dr. Seuss advised many years ago in the great childrens book “Oh the Places You’ll Go”; Your mountain is waiting so get on your way!]]>
Which begs the question, why bother supporting ineffective controls when they fail to control anything?
I wish it was rare that I encountered similar situations with my clients but it’s not. My favorite ineffective control is the manual visitor sign-in sheet I often find when auditing/assessing my clients physical data center controls. My hosts often make a big deal out of asking me to sign-in before allowing me access to their data center or server room and I typically play along. However, I’m fond of using an alias to see if they validate the information I provide (usually they don’t). The manual sign in sheet falls under the category of “better than nothing” but in its own special sub-category I call “but not by much.” The list is always a bit lite and is often missing sufficient evidence to prove that it’s consistently relied upon. Another favorite of mine centers on production change control. Some of my clients have fairly robust processes to track changes to application software but ask them for evidence of system software updates or hardware configuration changes and I’m met with blank stares as they try and figure out how to tell me they don’t really track those things formally. So you have to wonder why you’d even bother to track some of the changes if you’re not tracking all of them? If something went wrong within a clients infrastructure how would they know if any recent changes might explain it if they don’t know about everything that changed?
Here’s a bit of a radical thought; stop supporting ineffective controls and save the time and effort required to support them.
Seriously, even though a control might appear critical in nature, if it’s poorly designed, poorly supported or just flat out ineffective, just kill it altogether. No decent examiner or auditor is going to be tricked into thinking it’s providing value and it’s likely going to call into question the validity and reliability of all your other (hopefully) effective controls. If you feel strongly that the control needs to be in place and doing its job than do something about it. Either redesign things so that it’s viable and effective or scramble like crazy to identify compensating controls that render the control unnecessary.
We live in an age where compliance rules all. There are all manner of controls that are required in order to satisfy our oversight agencies and auditors and that’s a list that will only continue to grow. No one has the luxury of wasting time or the precious few resources they have to work with and so it’s that much more critical that these things be thought through and validated. Expecting people to support control related activities that ultimately fail to satisfy their objective is flat out wrong. And because this is the age of regulatory enlightenment those who toil within the financial services industry are a bit more savvy about how these things work. They have an idea of whether or not what they’re being asked to do makes sense and will resist or defer participating if they think it’s a waste of time. The only thing worse than an ineffective control is one that’s poorly supported.
It’s why I often wonder what would happen if I simply drove across the lawn closest to my Mom’s building and completely avoided the main gate. I’m thinking that if it’s after sunset when there are no golfers walking the links I could probably pull it off. Of course I’d have to deal with the compensating control of an angry mother once she figured out what I did but perhaps, just to prove a point it might be worth it.]]>
While I’m no expert on the subject I have plenty of experience working in organizations that either have successfully implemented ERM practices or who are attempting to do so. I am routinely amazed by what I discover along the way, how some have a firm grasp on what needs to be done and how others simply rebrand a group or function as Enterprise Risk but do little else to further the initiative. There are some core activities that need to be in place and functioning in order for management to achieve any measure of success and ultimately they’re either there or they’re not.
My entire perspective is a bit tainted. I first learned about ERM at the hands of a master practitioner. A few years back I attended a two-day workshop taught by Tim Leech who has been often referred to within my circle of associates as the “Godfather of ERM”. Tim has been assisting companies of all sizes, complexities and verticals for decades in building out programs to first define their risks and figure out what to do about it. His approach is so effective that to the casual observer it would almost seem simple, even easy to implement. However what I learned after two days of listening and learning was that there was a right way and a wrong way to build out ERM programs, that the approach needed to be tailored to the organization and that if the wrong people are leading the way it could cause more harm than good. A few months later I had the pleasure of participating in an actual ERM engagement where Tim applied his theories to assist a healthcare company in designing the foundation of an ERM program. It was fascinating how much information he was able to collect from an audience comprised entirely of the “C” suite, how he engaged them in a lively dialogue which resulted in a frank and honest identification of risks and allowed them to begin building out a framework. What was key to the early success of the newly forming program was that it resonated with management because it echoed their sentiments and incorporated their thoughts and concerns. The risks that they were being asked to address made sense to them because they were the ones who helped identify them to begin with.
Unfortunately what I didn’t realize at the time was that I might never have a reason to feel as good about ERM ever again.
In the time since my introduction to Enterprise Risk I have routinely encountered approaches where a team of really smart people sit in relative isolation and come up with a list of risks they perceive as being relevant to the organization. They then try and figure out what to do about it so that they can provide direction to management. Management often receives the information more as a directive rather than guidance and attempts to operationalize it. People in the proverbial trenches are often attached to activities as a result, struggle to implement new controls and associated processes and report on progress. And in the end no one really even knows if the work was either necessary or useful. I’ve encountered several variations of this approach, sometimes where external experts are brought in, sometimes where internal audit leads the way but almost always with the same general limitations; no one talks to the people who live with the risks.
I’m reminded of a phrase I encountered years ago and have always liked: “It is not the same to speak of bulls as to be in the ring”.
Rare is the ERM approach where the approach incorporates an active dialogue with the people “in the ring”. How can you identify any measure of risk without first talking to the people who have to deal with it every day? Sure there are frameworks that predefine some of what needs to be done but any regulation, any guidance that currently exists advocates for an organization to identify and measure risk as it exists within their world, their infrastructure. And the only reliable way to begin such an exercise is to talk to the experts, the people who know how things really get done. And how do you even know which people to talk to without first starting atop the organization and finding out what management is committed to doing, what their business goals and objectives are? This information isn’t found in a document or in a spreadsheet, it only exists in the minds of those people who help run the organization. Without knowing what they know and understanding what they’re concerned about you don’t really have a meaningful clue about what or where the risks are.
Doing what I do for a living you get pretty good at forming qualifying questions that quickly frame a clients environment. Recently I asked a network manager about his institutions vendor management program and he wasn’t sure if they had one; I told him they didn’t because in his role, if they did, he would have to know about it. And so when I ask someone serving in a critical role about their institutions ERM efforts I can more or less assess its effectiveness based on the answer. If I hear anything along the lines of “I’m not really involved” or “I think it’s covered as part of our audit process (a popular misconception)” I know that ERM is just a buzzword and not a true discipline. Because if it existed in any meaningful way they would have needed to contribute somehow. And thus my reason for being frustrated.
I really don’t want to hear about ERM or talk about it unless it’s contextually effective. If the “E” in ERM doesn’t represent “Enterprise” but rather “Executive” or “Existential” or some other unrelated perspective I’ll take a pass. It’s like when Cobit-based became the defacto standard and everyone wanted to know if your framework was Cobit-based as if that somehow conveyed something akin to pedigree. There’s real work behind the discipline and all because you label a group or project ERM doesn’t mean it is. And I’ll promise you this, if you’re applying some or all of ERM’s most basic tenets there’s no way you’ll ever speak of it in conceptual terms ever again. Because once you’ve been in that ring you’ll never look at a bull the same way.]]>