In the days since that conversation I’ve put some thought into the frameworks because in the end the aforementioned CISO was committed to finding the NIST experience and eventually did.  But what did that really mean?  Having fairly recently had the occasion to have both NIST 800-53 and the ISO 27000 documents  in front of me it was striking how similar they both were with only a few obvious distinctions to be made between the two.  Essentially the differences reflected more on the cultures that created them than the risk factors they were focused on (NIST = U.S.A and ISO = European).  But information technology architectures fundamentally are identical the world over so despite formatting and spelling they both are addressing the same challenges whether or not they realise it. And for those of us who have familiarity with both, to know one is to know both, even if those who are committed to either one disagree.  If you’ve worked on audit/assessment projects leveraging ISO 2700o material you’re immediately qualified to work on projects using the corresponding NIST framework and vice versa.   And if you have experience working with PCI standards guess what?  You can pretty much step in and work with either NIST or ISO content (except of course you have to expand your sights to include the entire infrastructure, not just on whatever touches PAN data).

My preference is that we would consolidate globally into the ISO frameworks where applicable and maybe even fit that in to the SSAE 16 process.  I’ve read enough toothless SAS 70/SSAE 16 reports to know that it’s easy enough to rig the system to your advantage.  And unless you’re a government agency that has to comply with NIST there’s little meaningful value to using NIST whereas being ISO 27000 certified carries a great deal of weight within the audit/assurance community.  Plus there’s the added benefit of having InfoSec practitioners all getting trained and practiced at both building out ISO 27000 compliant solutions and also knowing how to test the related controls.  Think about that, a single global security standard regardless of where you enter into the profession.  Having run a few practices in my career and way more than my fair share of engagements I can tell you that has great appeal.  Plus it would help eliminate awkward dialogues where my sixteen years of real and relevant experience is at least partially marginalized because it hasn’t all been with one particular standard.

Ultimately in the end a frameworks only meaningful advantage is that it theoretically ensures consistency in how controls are identified and assessed.  If you have someone who knows a framework but doesn’t really understand the details within that sort of defeats the process anyway, no matter how robust or thorough it may be.  Perhaps that’s why I consider it a non-issue when it comes to which frameworks a practitioner has used.  I’d much rather work with someone who understands the technology and has a good feel for the details rather than someone who knows that SDLC is addressed in SA-3 for NIST or Section 12.5 for ISO 27002.  But than again, I’ve always been more concerned with real risk, not perceived risk so this shouldn’t be surprising to anyone who’s read my content in the past.

A security framework by any other name would be just as comprehensive, you know what I mean?

Which is why I don’t much care for any manner of compliance-based assessments that are self-administered.

Companies have had this crazy notion for more than a decade now that the best way to identify and address risks inherent within the infrastructure is to ask key stakeholders a somewhat generic set of questions and use their responses to figure out what’s what.  Most of the time the people driving these initiatives are either information security professionals or corporate compliance people who either believe they already know where the problems are or are looking for the simplest and easiest way to satisfy some requirement.  But what they often fail to grasp is that it’s almost impossible to draft a common set of questions that either apply to the vast majority or worse, will be interpreted consistently across the stakeholder population.  Plus the perceived benefit of using a self-assessment approach to reduce effort and required support resources is almost always an illusion.  Most of the time saved in not having someone ask the questions and record the answers is instead consumed by needing to explain the format, explain the questions or trying to clarify and clean up the responses.  While supporting one such program recently each assessment required a kick-off meeting, a follow-up meeting to review the status of the assessment, a third meeting to review the initial draft of the questionnaire, a fourth meeting to review the resulting report(s) and a largely untracked number of hours to help generate all of the related support documentation.  Regardless of the size of the entity being assessed each one consumed somewhere close to eight hours.  While that might seem like a scary large number, the really scary part was that based on which risk analyst was responsible for the assessment and the personality/mindset of the stakeholder completing it the results looked very different from one another.  It was almost impossible to generate meaningful metrics across the assessment population because a “Yes” answer for one question might mean the same as an “N/A” in another; there was no way to know that.

Another issue I’ve always had with the self-assessment approach is that while some stakeholders take it seriously and do a remarkably thorough job, others race through it with little hesitation just to fill in the blanks and get it off their desk.  Sometimes you can detect which is which, sometimes you can’t.  Plus the approach fails to capture much of the rich and relevant information related to each question and the underlying risk behind it.  I recall conducting a team-driven risk assessment years ago where one stakeholder after the next covering a very broad sampling of the infrastructure kept lamenting on the lack of a proper disaster recovery plan.  They had something to show auditors/examiners but to a person no one believed it was a truly viable plan.  All but the CIO brought it up as a concern and when pressed a bit about why that was they all shared a common concern: If their main office was closed unexpectedly for twenty-four hours, regardless of the reason, they were likely out of business.  A related self-assessment question would ask “Do you have a current and recently tested DR plan?” – most respondents on that engagement would simply have selected “Yes” and moved on to the next question without ever being challenged to share their concerns.  Where’s the value in having a repository of questions and answers when it fails to capture the true essence or dimension of risk? 

And the biggest issue I’ve always had with self-assessment questionnaires and their related templates is that they’re so often poorly designed.  I can guarantee you that each of them has at least one question which makes zero sense to anyone who reads it.  They either answer it based on what they think it’s asking, answer with an “N/A” or require follow-up with the people managing the process to have it explained.  And you’d be amazed how many times even the author is challenged to provide a meaningful answer (including this guy).  One thing’s for certain, a self-anything needs to be designed and written so that everyone understands what they need to do without having their hand held.  Plus it’s rare that questionnaires are customized so that each stakeholder is only asked those questions that truly make sense.  An application owner should never be asked if their anti-virus solution is current and up-to-date.  A business process owner should never be asked about software change management.  Yet seldom have I encountered a self-assessment process which does anything like this and so the audience is burdened with time consuming yet unnecessary questions.

Really though in the end my overriding problem with the self-assessment approach is that it fails to capture the expertise and guiding hand of true risk and assurance people.  The process is often supported by analysts who don’t really have a feel for conducting assessments and are satisfied that all of the blanks are filled in.  I have a nose for when there’s something beyond a simple answer and know when to scratch at the surface to bring it to light.  By not allowing expert hands to guide the process potentially huge amounts of valuable and possibly critical details are being missed thus undermining any perceived value of the process.  When you consider that all tolled and tallied the self-assessment approach versus the guided assessment approach doesn’t really save you much time (if any) and that it results in a weaker finished product, why would you elect to use it?   One answer is that regulators push for it because perhaps it’s better than nothing (I can’t get any of those I know to comment).  Another is that the people sponsoring these initiatives lack the fundamental comprehension to understand their options and chose what they perceive as the less complicated approach (again, I don’t know for sure it’s just a theory).  What I do know is that when done right a risk assessment is managements best friend, a fundamental belief behind the recent spike in ERM activity.

While recently having my car serviced the mechanic discovered a nest of some sort in the engine block, he thinks it was probably squirrels.  Because of this discovery he went searching for all the wired connections to make sure they weren’t chewed up and destroyed, quite a few were as it turns out (the car had been idle for several months).  The bill only added the cost of the replacement wires but nothing significant for the time it took to first find which were affected and then replace them.  Had I attempted the repair myself I might have noticed the nest and likely would’ve cleared it but know for certain I never would’ve thought to check the wires, where to look for them or what to look for.  I was smart enough to rely on a professional with a nose for that sort of thing and it saved me time, money and best of all the aggravation of having the car break down somewhere unexpectedly.  Good thing I didn’t go the self-repair route.

Of course the truth is much more complicated.  I don’t just focus on computers, my scope expands to include anything that involves sensitive information.  While that always includes a variety of devices it also includes paper-based and people processes as well.  I frequently share stories about the enormous amount of printed content that’s to be found throughout an institutions physical locations.  I occasionally tell stories about how careless people can be when on the phone or in conversation and sharing all manner of sensitive information.  It’s never just about computers, it is however always about information and how it needs to be protected.

Truthfully though what I really do is search for controls that protect information, identify those that I find and try and measure their effectiveness and more importantly identify where controls are missing and work with my clients to remedy that.  At the heart of the regulatory requirements I focus on it’s all about the risk introduced by the presence of information, from personally identifiable (PII) to non-public personally identifiable (NPPI).  Risk: It’s what drives every single project I work on, it’s what drives every product and process I help develop.  And really, if you take the time to read through the literature, it’s what’s behind just about every piece of regulation known to the banking world.  Risk, risk, risk and risk.

One of the reasons I’ve enjoyed spending so much time working with the community banking and credit union sector over the past few years is that it’s a simple enough argument to make with fewer people to convince; everything you do to comply with the regulations should be risk-based.  It doesn’t really make a difference if it’s complicated to do or time consuming, you prioritize based on where they are found and make decisions accordingly.  But that gets much more difficult to do as the institutions grow in size and complexity.  Over the fifteen years I’ve been building and supporting compliance initiatives I’ve worked with Fortune 50′s, 100′s and 500′s and a whole lot of financial institutions that merely read Fortune magazine.  But while their overall size varies widely risk is still risk and that never changes.

I wish more practitioners embraced this simple concept.  While some do, many still don’t.  There’s often a rush to come up with a standard set of decision criteria to drive the work based on factors not necessarily aligned with risk factors.   Those who have worked with or for me will tell you that when presented with questions about which vendors or applications to assess or what to look for when conducting any type of assessment my first line of logic is to try and figure out where the greatest possible exposures to be found.   Assessing a low risk application yields little value  no matter how complete it may be.  And reviewing a vendor where the dollar spend is high but the risk factors are low does little to protect the institution.

Beware the practitioner who wields a hammer for they only know to look for nails.

Your regulator doesn’t want you to blindly implement compliance programs, they want you to identify and manage risks, real risks.  They want to be able to understand the logic and approach being used and find credible evidence that you’re focusing your efforts on the right things.   Go back and read through the library of FFIEC documentation and pay close attention to the hooks inserted throughout where they talk about conducting assessments and talk about using approaches which are appropriate for the size and complexity of your institution.  Then scan through your related program inventory and figure out if you’ve designed things accordingly.  Are they actually protecting your institution from credible threats and risks or are they just filling binders on your compliance officers shelves?

For me, professionally I’d prefer to always only do meaningful work and in the audit and assurance world meaningful is code for risk-based.

Right there on the front page of today’s News and Observer was a story about how a recent audit claimed corruption at a local college (North Carolina Central University).  I’m sort of trained in a Pavlovian sort of way to notice anything having to do with audit and so I gave it a cursory read.  Cursory turned into focused when I reached the part about how the school’s chancellor Charlie Nelms called the report draft “sloppy” and went on to say that some of its harshest accusations might not be true.

One of the oldest tricks in the business book when it comes to audits is to start questioning the quality and veracity of reports that are perceived as not being favorable.  Instead of focusing on the audits findings and trying to validate them (because a good audit is your best friend if you really want to do things right) the auditee goes into a series of tactical maneuvers to deflect attention away from the report’s contents and feigns disgust and outrage.

The school chancellor went on to say that, after firing the auditor who produced the report, he “ordered his staff to gather more information before he releases a final version to the public.”   He went on to say that the “draft audit was so poor that he doesn’t trust it, and he does not want to damage the reputations of people who might not have done anything wrong”.

A few years ago, I conducted a risk assessment for a client with an odd configuration of infrastructure pieces that clearly defied anything close to typical, so it was difficult to measure them against the norm.  Just the same, I tried.  I took a step back after conducting all of my interviews and gathering as much information as was available and filtered it through the lenses of an examiner.  I surfaced gaps and issues that were likely to be viewed in a negative light, explained why that was and offered clear and concise remedial steps.  Senior management went bonkers (for lack of a better word) when they received the report.

They were outraged because the report was delivered a week late (which was true), they were insulted that there were typos (not factual errors, just a few grammatical/spelling hiccups which are common in draft versions) and charged that some of the issues listed were completely false.  In summary, they called into question the accuracy and reliability of the entire report.  It was startling for me because in my more than two decades working in the business world with more than 10 years conducting audits and assessment, I’d never had a client react anywhere near this way before.

But it was really more about using diversionary tactics intended to gain a negotiating advantage.  Their end game was to soften the report’s contents so that it looked better when the examiners came back around; by pushing us back into a defensive position, they were almost successful.  Fortunately, I’m stubborn when it comes to standing behind my findings and need incontrovertible proof that I was wrong about something before changing or removing things.  I may not be the best auditor but I have well honed instincts around IT, the myriad processes necessary to support the infrastructure, and I know good from bad.  I never put anything into my reports that doesn’t resonate with me and my peers (and typically the report’s audience).

So you can imagine where my head was at while reading the story today.  Mr. Nelms also said, “I want to see the source documents, and I want to see the field notes from the audit, because I want it to be accurate.  I don’t want it to be hearsay, because some of the allegations are just mind-boggling.”

Well that’s good to hear because any audit worth its weight in paper needs to be supported by solid work papers.  But considering that he fired the auditor, I’m hoping someone in his office thought to secure that beforehand.  And I’d need to understand why he’s gathering more information when all he really needs to do is use the work papers and have another independent auditor re-perform the tests.

Oh and another thing, who hired the auditor to begin with?

Also, now that the report’s findings are semi-public (it’s available despite not having been formally released), where’s the value in conducting a follow-up audit?  Anyone involved with any alleged wrongdoings now has a clear roadmap in front of them on how to cover their tracks.

Here’s my thinking on all of this: The audit is likely somewhere close to 100% accurate but far from perfect (I know that’s a contradiction).  If the chancellor was really interested in handling this properly, he’d quietly set about having independent people digging into the findings, not as a CYA exercise but simply to get to the bottom of things and deal with whatever is found.  I’m not saying that where there’s smoke there’s always fire but unless Mr. Nelms can offer a credible explanation why he would think that the fired auditor would fabricate stories or offer poorly formed conclusions I’d have no choice but to question his position on all of this.  I guess what I’m asking for is a credible explanation as to where the smoke is coming from and an explanation why he thinks it’s benign.

What I’d like is to hear the auditor’s side of the story.  I’m betting that would be an enlightening conversation.  But if Mr. Nelms was successful in his very public tongue lashing of this auditor, he/she will do anything and everything to avoid having their name outed.  And so the diversionary tactics score another point.

And the best part of this?  I almost never read the paper.