Now we have GRC software solutions that oddly enough promise to automate GRC-related tasks.

The first problem with any such assertion is that GRC is too broad a spectrum of activities and disciplines – most solutions are focused on addressing subsets therein.  On one end you have the security-centric solutions, on the other end you have the risk-centric platforms and somewhere in the middle is a crowd of offerings that try and touch on everything but none particularly deeply.  So the first thing a stakeholder needs to understand is what they’re looking to accomplish before they set out to select a product.  You can select ten different GRC vendors and discover ten different interpretations of the discipline.  And within those ten solutions there are vastly different approaches.  Some are similar to ERP packages where their approach is somewhat hard-coded and you have to do things their way (or spend big bucks to customize).  Some are remarkably configurable and can be made to fit your processes like a glove (but that requires a steep learning curve and expanded time frames).

The second problem is that because most vendors selling to the GRC market tend to use common terms their internal definitions can be quite different.  Some solutions pitch risk assessments which are little more than questionnaires (e.g. very little to no risk-related elements such as inherent and residual risk) whereas others provide questionnaires that are absolutely risk assessments but only appear as such upon inspection.  If you’re looking for a true risk-oriented solution you might go with the former when it’s the latter you truly need.  But the terminology is so similar it’s hard to differentiate and the only way you’ll get to realizing that is after you take the software out for a test drive, not something every vendor is willing to provide (and I’m not talking about a two hour demo, I’m talking about a true trial period).  You think you’re comparing apples to apples and it may turn out that you were comparing apples to car batteries without knowing it.

The third problem is that after a while it’s easy to become snow-blind during the selection and evaluation process.  Because of the common language, because of apparently similar functionality you start looking for factors unrelated to what you really need to focus on as a way to separate out the solutions from one another.  You’ll consider solutions as prequalified because a competitor is using it thinking that their needs are similar to yours.  But they may be focused on information security activities where your institution is looking for automated risk assessment capabilities.  You’ll start shopping on price and contract terms thinking that competing solutions are so similar it really comes down to who offers the best deal.  But software vendors usually know their market and the correct price points based on what their solutions offer – if two or more products appear evenly matched on functionality but one is much cheaper there’s usually a reason.  The more expensive solution may come pre-loaded with all the related content you’ll need to effectively use it whereas the cheaper solution might require you to obtain your own licenses.  It’s not intentionally misleading but that’s a detail easy to overlook during the vetting process.

GRC is an awesome concept working towards one day becoming an awesome discipline but it’s not quite there just yet (a point I routinely beat to death, I know).  It’s spread out too far and wide and depending on who you’re talking to about it can get widely (if not wildly) varying definitions of what it is.  So it’s no wonder that trying to find an automated GRC solution is equally challenging, the vendors are trying hard to figure out what nail to hammer as well.   They all do some things remarkably well but at the expense of doing some things either partially or not at all.  Thus the reason that it’s not uncommon in larger companies to find multiple GRC solutions installed; different business functions have unique needs and they purchase whichever is closest to meeting those needs.  It’s an expensive approach but for the foreseeable future an necessary evil.

I think we’re getting closer to a point in time where a common dialogue will be accepted by the audit and compliance community.  The OCEG folks have poured the foundation and it just needs a little more time to harden in terms of broad acceptance.  When I see their content displayed prominently next to all the COBIT binders at my clients I’ll know that time has come.  I predicted in 2007 that once we’re in the midst of a full-blown economic recovery GRC will quickly rise in prominence due to increasing regulatory pressures, almost identical to the way COBIT soared into the forefront of the industry fueled by SOX.  I see no reason to alter that prediction, I’m just not sure when the recovery will officially begin.

In the meantime keep participating in the dialogue, keep trying to define what GRC means to you and to your organization and every now and again share those ideas with some of the decision makers who are shaping the discipline, they need to hear from everyone as they mature the thing.  As long as we in the audit and compliance domain keep moving things forward we’ll get GRC to where we need it to be, I’m certain of it.

The very first prediction was that the Iomega Zip Drive was going to accelerate the push into portable mass storage devices.  For about two years it blazed the trail soon followed by others but I knew the first time I laid eyes on the device I was looking at the future.

The second prediction was that Borland was going to be bought by either Microsoft or IBM.  They had launched their new Delphi development software and it was blindingly fast and easy to use and clearly set them apart from the competition in the client-server domain.  For reasons still unknown it never happened and so while I was wrong I still think I read things correctly (it’s my ego, it won’t let me be wrong for too long).

The third prediction changed my career direction.  As Y2K was nearing I outlined a concept where companies could leverage all the repositories they developed and maintained to ensure a smooth transition into the new millennium and convert it into an ongoing management tool.  It was a discipline that eventually matured into what we now call portfolio management.  While I wasn’t in a position to pursue my theory I knew I was onto something and as it turned out I was right.  Why this prediction changed my career is because it gave me the confidence to both trust my instincts and pursue new ideas even when no one else thought it would work.

Which leads me to my fourth prediction.  Back in 2002 while with Metlife I was put in charge of a bizarre project that came to be referred to as “Server Consolidation”.  After working with a vendor not of my choosing for six months and with nothing to show for my time I discovered VMware about ten minutes after they went public and knew this was what the company needed.  I immediately brought it to my bosses attention and instead of trusting me to make us all look brilliant I was instead admonished for not doing what I was told and VMware had to wait another five years before the company embraced the technology.  But while it indirectly cost me my job (I was laid-off six months later) I knew I was right and still believe it was worth taking the risk.

My instincts are screaming at me again and so allow me to share my fifth bold prediction.

My readers know that I’m a huge believer of GRC as a concept.  I write about it almost monthly and at least quarterly and track its progress closely.  I’ve participated in several related projects and constantly try and insinuate myself into newly emerging GRC-based initiatives.  The idea that each of the three core disciplines break out of their silo’s and work together is just flat out the right approach.  But that’s not the prediction.

Almost all of GRC-related activity now is driven by regulatory and/or industry compliance requirements.  While most companies would publicly reject that statement and insist that their approach is based on risks that they identify and manage, the truth is most of those risks are already being targeted by one of the many compliance requirements they operate under and need to comply with.  And after nearly a decade of dealing with one new set of requirements after another quite literally every company I’ve encountered has multiple frameworks and related initiatives to ensure compliance.  It’s resulted in massive duplication of effort and wasted time, money and bandwidth.  And because those same companies can barely keep up  with supporting these activities there’s little chance they’ll ever find a way to reorganize and consolidate their efforts so that they can reuse steps to satisfy multiple requirements.

And so here comes the prediction.  Network Frontiers Unified Compliance Framework will become to GRC what COBIT became to SOX.

For those of you who aren’t familiar with the UCF it’s a series of documents that basically maps every single regulation, requirement and framework known to man (including coincidentally COBIT) and reveals the many points of intersection that exist but are almost impossible to identify while on the ground.  While there’s more to their library than just the mapping it’s really  where their bread gets buttered.  I first discovered UCF in 2009 while working on a governance project and have been a fan ever since continuing to follow their progress and trying to spread the word about what they’re doing.

Here’s what they ‘re doing: They examine every regulation and requirement and map them to a set of generic control activities so that they identify where one activity satisfied multiple requirements.  They follow a fairly extensive process in doing so and all of their work is vetted through legal review to ensure they’re not overreaching during the process.  And they’re constantly updating the framework to make sure that as existing regulations change and newer ones emerge the UCF captures it.  Considering the accelerated pace at which regulations are being enacted these days that’s no small task.  The way the framework is leveraged is by finding the appropriate control activity that matches what you’re working on and reading across the line (it’s delivered in spreadsheet format) to find out which regulations or requirements it satisfies.  So if you’re reviewing application access in support of SOX it’s possible that same test would also satisfy GLBA requirements.  Imagine how much time and effort can be reclaimed if your GRC program was whittled down to testing a control only once and using it many times?  Also imagine how that might look to senior management.

So why am I making my bold prediction now?  Last week I learned that Network Frontiers is making their content more readily available in an online format and for free.  This will allow a broader audience to begin accessing their impressive content without first having to get someone in their management food chain to approve its purchase.  I’ve tinkered with it a bit and while I still prefer the spreadsheet format (I’m a geeky kind of guy) I love knowing that someone can read this blog post and immediately signup at their website and begin exploring.  By making it easier for the masses to access their content it will likely accelerate broader acceptance throughout the corporate world – once that happens, once program offices start relying on the content provided there will be no turning back.

I realize that GRC is way more than testing controls but consider that the UCF will also allow a company to identify where risk assessments, policies, procedures  and programs hit multiple targets as well.  It truly allows for economies of scale to be realized in ways that were just never as easy to pursue in the past.  While the framework doesn’t tell you how to build or manage a GRC initiative it will become one of its primary tools, I’m certain of it.   I’ve pointed several people in the direction of the UCF over these past two years and almost to a person their initial reactions is “wow”.  They all immediately saw its value and started considering how best to exploit it’s offerings.  And until I meet someone who upon viewing the framework shrugs their shoulders and says something along the  lines of “I don’t get it” you’ll find me standing behind my prediction. ]]> http://itknowledgeexchange.techtarget.com/regulatory-compliance/grc-is-about-to-see-its-future/feed/ 0 http://itknowledgeexchange.techtarget.com/regulatory-compliance/can-you-be-partially-compliant/ http://itknowledgeexchange.techtarget.com/regulatory-compliance/can-you-be-partially-compliant/#comments Mon, 29 Nov 2010 15:19:24 +0000 David Schneier http://itknowledgeexchange.techtarget.com/regulatory-compliance/?p=567 I recently decided to establish an automatic link between my personal checking account and a mutual fund account that was established for my son years ago when he was a baby.  The account was originally funded with a gift from a family member and while it’s grown reasonably well percentage-wise, its overall numbers remain low because we’ve never added to it.  So I thought now would be a good time to do something about it.

It’s a custodial account because of his age and my wife is designated as the custodian of record.  As a result, I’m not supposed to be able to conduct any manner of business with the account because my name doesn’t appear anywhere.  However, of the five phone calls I’ve needed to make to the fund company’s offices over the past few weeks, I’ve only been asked to have my wife authorize the conversation twice.  That means that in 60% of my calls, I was able to present myself as someone with legitimate privileges to conduct business with the account and was successful.  And while you can slice and dice the numbers and draw the conclusion that the fund company’s compliance efforts are partially effective, the truth is that they’re completely useless.

Being a little bit compliant is akin to being a little bit pregnant; you either are or you aren’t.  There’s no gray area in between to take credit for.

Now take into account that I didn’t go looking for this; it just fell into my lap.  I wasn’t researching anything, trying to test a theory or uncover a topic for a new blog post — I was just trying conduct a simple transaction.  And so my first thought upon reflection was that this was too easy.  What if I was really trying to do something I wasn’t supposed to be doing?  What if I’d found a neighbor’s statement in my mailbox and decided to try and access their account?  What if I did some good old-fashioned dumpster diving around town and found a few discarded statements (trust me on this, that’s easier to do than you’d ever believe) and tried to get money out of someone’s account?  Statistically you’d have to figure I could get pretty far without getting caught.

What I find truly amazing is that we’re in the age of compliance.  I receive pamphlets and inserts in my mailings all the time from banks, credit card companies and anyone else I share PII with about how they have an obligation to protect my information.  Every time you visit a doctor for the first time, half the paper work is specific to HIPAA.  And yet in the middle of this sand storm of compliance activity, I was able to bypass the rules three times in five attempts and I wasn’t even trying to break any rule.

They say a chain is only as strong as its weakest link.  The same is true of compliance; if it fails in any measurable way it fails — pure and simple.  And if the compliance folks at these companies can’t keep up, how are they going to adjust as we keep moving more and more onto the lightning fast pathways of the Internet?

The data on the server included mammogram results from across the state, patient information that was harvested without the patients’ knowledge and included their Social Security numbers (can someone say HIPAA breach?).  The vulnerabilities on the server that allowed the breach had existed since 2006.  The breach occurred sometime in 2007 but wasn’t discovered until 2009.  Although the IT team could determine that a breach had occurred, they had no way of knowing if any information had even been stolen.

So UNC didn’t know for at least three years that it had a vulnerable box plugged into the network and was in possession of illegally obtained information.  It turns out the only thing UNC did know was who to blame. But in the end they got that wrong too.

There’s no worse precedent to set than to make business owners, regardless of the vertical, responsible for their own technology.  They don’t know anything about ports, settings, patches or upgrades; they only know they sign on and use what they use.  And because of economies of scale, it doesn’t ever really make sense for an individual department to hire its own resources.  It’s why IT became a centralized resource decades ago and why it makes sense still today.

So why didn’t UNC’s IT department do its job?  Why didn’t the group responsible for plugging servers into the network configure the machine properly?  How did IT let the machine sit out there for not one, not two but for three years without detecting there was a problem?  What sort of scanning tools do they use?  Don’t they have antivirus or anti-malware software installed?  I mean honestly, how did UNC’s IT people let this situation not only come into existence but also to remain for so long?

I don’t always go out on a limb like this, but UNC is wrong for blaming anyone other than the IT staff responsible for configuring and securing the network.  What UNC has right now is a scapegoat, which just seems silly for so esteemed an institution.

Oh and the university also justified its punitive actions by claiming that the data on the server was obtained improperly.  UNC is right; it was.  But what it failed to realize is that the HIPAA violation falls mostly on the shoulders of the doctors who provided that information.  They’re the ones who assume the obligation of protecting their patients’ data and while the professor should have been more on top of that element, it wasn’t her primary obligation; it was the original caregivers’.

Really in the end what this whole mess boils down to is a great big bowl of wrong.  Wrong person blamed, wrong handling of the server, and wrong message sent.  Wrong, wrong, wrong!

In an industry where there are standards that define how standards should be written and websites dedicated to dissecting each standard so that everyone can understand what the definition of “the” is, I’m often amazed by the broad range of solutions employed to achieve compliance.  You’d think that from one solution to the next there would be obvious commonalities that would immediately identify what you’re looking at.  But that’s generally not the case.  I’ve seen so many flavors of SOX solutions you’d be amazed (at one client they have two very different and unconnected systems installed, one for IT and one for the business).  At least in general terms, all of the systems I’ve encountered more or less wind up at the same logical meeting point, which is where a determination is offered as to whether or not the necessary controls are in place and functioning as expected.

What drives me crazy, though, isn’t the disparity in compliance solutions but rather in the broader interpretation of compliance.  It’s somewhat binary; you’re either compliant or you’re not.  Regardless of the method you use to attain and maintain it, once you reach the point where you’re compliant with a regulation you can stop adding to the framework.  With SOX, I remember how the very first challenge that every company faced was in figuring out scope.  The loosely defined guidance specified that only those controls directly connected to the most significant financial processes and applications needed to be tested.  It was a constant struggle to get this done and one in which a clear dividing line eventually was drawn: those who used common-sense and those who didn’t.

It’s a dynamic I’ve encountered many times over my career that is regulation-agnostic.  At what point do you stop implementing controls because all significant risks have been properly addressed?  The common-sense side of the debate will identify areas that are at greatest risk either because of design or content; the other side, the literal side, will identify everything that’s even remotely related and pull it into scope.  I’m a common-sense kind of practitioner.  I prefer compact, efficient and relevant compliance frameworks.  I hate “made” work; I hate doing something simply because someone said I had to even though there’s no apparent value or need for it.  I’m of the “work smarter, not harder” mindset and that shows itself in all my work.

However, I encounter all too often the other side of the debate: Those controls and related activities inspired by people who will test everything and anything even remotely in-scope simply because it’s there.  Some of my best and most significant regulatory work is found not in framework design but rather in my redesign.  I have a bit of a reputation for coming into an institution and effectively ripping out all the waste, the redundancies and overlaps and whittling things down to a size that makes more sense for the size of the operation and then selling it to the examiner/auditor.  I take great satisfaction in this sort of work because I’m saving my clients time and effort which translates into money at some point.  One of the nicest compliments I can be paid is to be told that the most recent round of testing took only a fraction of the time and the auditor/examiner was happy with the results.

And so it’s maddening to me to find out that a solution I’ve worked on, one that was working beautifully and is running lean and efficient has been tinkered with because a new set of people have been brought in and are reexamining things in the absence of a credible reason to do so.  That’s what happened recently and that’s what has left a bad taste in my mouth.

It wasn’t a solution of my design; I was simply supporting it to conduct the current year’s testing.  It had been created previously by a team of people who had intimate knowledge of what was necessary to prove compliance with the regulation that required it, was well thought out and extended itself just far enough without going too far.  It was one of those rare instances where I didn’t really see a need to make changes myself and instead only looked for opportunities to consolidate testing with related compliance activities.  Along the way, I validated the work by bouncing things off associates of mine who are responsible for testing similar frameworks to make sure it made sense to them.  They confirmed what I’d suspected: that the framework was solid, the scope appropriate and the degree of testing more than sufficient.  So how is it that a year later that’s no longer true?

The justification appears to be that there was residual risk that wasn’t originally in-scope and should have been.  Knowing what I do about the client’s infrastructure, the regulation requiring the work, and the way things happen in the industry, it just doesn’t hold up under scrutiny.  Nothing significant changed in their environment; there was nothing from the industry side of things driving a reevaluation and in two-plus years of having their framework there wasn’t a single reported incident that would have made them non-compliant.  I’m sure if you get all those involved into a room they’ll point to some relatively benign residual risk factors and pitch a really scary “what if” scenario.  Because even in a sufficiently secured and controlled environment there remains risk.  But someone needs to challenge how likely that risk is of ever reaching the point where it could actually cause harm to the organization.   If they don’t, management will feel the need to take action and fund work that probably doesn’t need to be done.

Remember that despite the best efforts associated with SOX, most of the final financial numbers are crunched in spreadsheets where just about anyone can fudge or transpose a number without detection (or maybe even by accident).  Regardless of all the work undertaken to beef up security and application controls, map all manner of business processes and document and test the heck out of all of it, the risk still remains that someone can step in at the very last minute and pretty much do as they wish.

I just think that there’s a better way to spend time and money, all the more so in this economy.  It’s an old adage but it’s still very true today: “If it ain’t broke don’t fix it.”

I’m not sure if I can legally mention the institution’s name and so I won’t, but I wish I could.  I wish I could because from working there just over two years ago, I know it was not an institution being mismanaged or poorly run.  Quite to the contrary.  I met with roughly half of the firm’s management team while conducting an information security risk assessment and what I recall is an institution that was well managed and took regulatory compliance seriously.  The people responsible for the infrastructure were on top of things, smart and capable.  As a matter of fact, I developed a new technique to frame risk-related information for them so that they could continue to use the information to guide their compliance activities after the engagement concluded.  They didn’t want only a point-in-time assessment but also the ability to track related activities to ensure ongoing compliance.  Does that sound like an institution that would be ripe for closure?

I don’t understand enough of what goes into the balance sheet to assess their overall management and business strategy.  These are tough times and previously viable institutions are being caught in the still tightening grip of the real estate crisis all the time.  But I’ve come across financial institutions that were not nearly as organized, where the people I interviewed didn’t present nearly as well. If I was asked to pick five banks I’ve work with that might be closed I’m not sure the one shut down Friday would have even crossed my mind.

Now that the banking crisis has a face (or two) I can associate with it, I’m pretty much certain I won’t have any clever quips to make when the next round of FDIC bank closing announcements lands in my inbox.

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!