Great, a food fight erupts on one of my favorite topics, and I’m the last guy to reach for the mashed potatoes. Rich Mogul decides that GRC is dead, and Alan Shimel points out some IT security realities (compliance is a big driver) here. Chris Hoff makes a few points as well here.

By way of introduction, I worked for one of the early IT-GRC product vendors (before the analysts decided that IT-GRC was different from enterprise GRC). I have also done consulting work for another vendor in this area, and I have authored a course on IT Risk Management. I have had enough exposure to large end users that I would like to think that I understand where these products provide value and utility, and where there are holes.

First, I think it’s important to draw a distinction between the enterprise GRC crowd (Pasisley, Open Pages, Axentis, and others), and the IT-GRC crowd (I would put Agiliance, Brabeion, ControlPath, Avior, Compliance Spectrum, Relational Security, Modulo, and Archer in this category). The enterprise GRC products tend to be all about workflow, with little depth in the area of IT risk assessment, analysis, and management, and little depth in the IT security-centric compliance regulations and standards (HIPAA, GLBA/FFIEC, NERC/FERC, PCI, ISO27000, BITS, FISMA). By contrast, the IT-GRC products tend to have a lot of depth in terms of very specific controls and requirements that relate directly to these regulations and standards. These two categories are different products, solving different problems, being sold to different audiences.

My 2 cents on the IT-GRC products- they provide a lot of functionality that highly regulated (read financial services) organizations need. They structure security management, providing the means to assess compliance to an external regulation, or to an internal, best practices framework. They also structure the workflow of security and compliance- in one analyst briefing I did a few years ago, the analyst remarked that the IT-GRC product in question was sort of for security & compliance managers like Peoplesoft was to HR managers. In a large organization, managing security and compliance can be overwhelming, and these tools give the manager a better way to manage the overall effort. And there is value for the business units and their management in these tools.

They are not without fault- as I have blogged previously here, few of them do much in the way of true analysis of risk. Most of them stop at helping to gather data about risk, or they use some proprietary method to try and calculate risk, as I have also blogged about previously. But to characterize these products as dead is wrong.

There’s also the familiar dynamic at work here that the analysts have decided that this category will be called IT-GRC, and therefore the vendors will all have to rush to provide more and hopefully better "R”, and even some “G”, irrespective of what their users are asking for, lest the vendors get left off the MQ, Wave, or whatever.

To Chris Hoff's contention that GRC products are "audit driven compliance all tarted up", I think you have to tell us if you're talking about enterprise GRC, or IT-GRC. Many of the IT-GRC products are *highly* asset focused. There is a direction in some of these tools to create direct linkages to data from other security tools- vulnerability management systems, configuration management, etc..

I will agree with Rich on this point- security vendors putting a little GRC lipstick on their favorite pig probably isn’t a great strategy.

Doing what I do in my day job, I sit through a lot of presentations on various aspects of security. I had the pleasure of sitting through a couple of presentations this week (one by a leading analyst on Web 2.0 security issues, and one by a vendor CTO). My short version of the takeaways from the talk were that there are a huge number of security issues related to Web 2.0 technologies, including cross-site scripting and many more. Many of these existed before Web 2.0, but are exacerbated by AJAX and other new technologies.

Without rehashing a lot of the detail from the event, the thing that really struck me was how similar my own internalized summary from the event was to almost every other security presentation I have heard in the last five years or so. You could almost use this as the punch line to every security issues talk: “The security issues are not generally well understood yet, they are going to be very significant, we’re pretty much screwed, and we don’t know where the solutions to the problem are going to come from.“

It’s a depressing conclusion to reach at the end of most talks on IT security. And I'm generally an optimistic person, so it's not like this is my "glass half empty" self talking.

I am also wading through Geekonomics, which appears to do a very good job of describing the big picture of how the IT industry has reached this particular place at this moment.

I was out on vacation (and then at RSA) when much of the interesting detail about the Hannaford breach emerged. Security professionals and probably the general public are growing a little desensitized to security breach news, particularly of the type “company XYZ lost a laptop, and NN,NNN individuals NPI is now at risk”. This stuff is so commonplace that it gets tuned out. I guess it means that the markets for endpoint security technologies, full disk encryption, etc. will be robust for a long time, but beyond this, not much of a big deal.

Then there are the big, cataclysmic security events like TJX, Societe General, or Hannaford. With highly impactful security breaches like Hannaford, it sometimes takes a while to understand not only the “how-what-where-when-why” detail aspects of the breach, but more importantly the likely future impacts.

The future impacts and likely consequences as a result of the Hannaford can be expected to be significant. Consequences to Hannaford will no doubt include fines and a lengthy mandated security program (with external security audit and review) from the FTC. In terms of PCI compliance, it isn’t entirely clear if penalties can be imposed by the credit card payment chain. After all, Hannaford claimed PCI compliance. The bigger long-term impacts will likely be to the future of the PCI standard- once the attack vector and vulnerabilities, whether technical or administrative, are better understood, the PCI standard will have to ratchet up the controls specified so as to prevent these attacks in the future.

To the general IT world, this latest big breach adds more fuel to the fire for a US national law on consumer data privacy. This was a sophisticated attack that should rightfully scare the heck out of IT security execs in all sectors and industries. It is also a reminder that compliance does not equal security.

A recent consulting assignment had me creating a comprehensive, 300 slide course on IT risk management. It was an interesting exercise, and gave me the chance to learn a lot about risk management. I am also exceedingly glad it’s done!

During the development of the course, I worked with a number of the vendors of IT risk management software tools, many of whom graciously allowed me to use screen shots to illustrate various aspects of the risk management process.

One of the things that struck me as I was building the course, and looking for screen shots to illustrate things like threat modeling, was how little functionality there is generally in this area. The IT risk management tools as a category provide a lot of functionality in the area of information gathering (modeling the organization structure, gathering information about controls in place via assessments or via API’s or direct connections). In some cases the tools will calculate risks purely on the basis of the existence and strength of controls (as evaluated). The tools then apply proprietary formulas to decide how much risk exists if a best practices control is lacking on a key asset. In essence, ignoring things like threat modeling, threat capability, loss event frequency, etc.. Many also ignore probable loss magnitude (or impact), and loss frequency.

If you think about some of the formulas and approaches to risk analysis that are drilled into every CISSP candidate…

Annual rate of occurrence (ARO) = number of times the threat can be expected to occur, affecting the asset, annually

Probable loss magnitude (PLM) = expected loss per occurrence

Annual loss expectancy (ALE) = ARO x PLM

… it seems like there’s a disconnect between the functionality in popular IT risk management tools, and the way that IT security practitioners are taught to measure risk. In looking at ten or so different IT risk management tools, I saw just a couple that had any functionality in the area of threat identification and modeling. And the functionality was pretty limited.

Risk analysis still seems to be more art than science, with qualitative versus quantitative debates, and multiple methodologies and frameworks (FIRM, FAIR, Octave, FRAP, and so on) available. Most of these frameworks assess and analyze risk differently, and there is lots of variability on basic things like terms and definitions. Few of the IT-GRC products map to these frameworks, and some of the products use a model that assesses the presence or absence of controls, and the maturity of controls, to determine the level of risk…a sort of best practices approach to gauging risk. The algorithms used to calculate risk are almost always proprietary. Relatively few of the IT-GRC products provide any real threat modeling capability.

My guess is that practitioners using IT risk management tools still end up doing a whiteboard exercise to quantify risk (or to assign a qualitative high-medium-low measurement).

I would love to hear from any users who struggling with this, and who use an ITRM tool. Understanding how you gather data for risk analysis, how much of the data you gather can be done by automated means, and how you then use the information gathered to conduct a risk analysis would be very interesting.

Also, I will post a link and blog entry on the risk management course when it is made commercially available, likely in 6-8 weeks.

Vendors providing software that helps manage the overall IT risk and compliance process now have an official category:  IT-GRC. Several leading analyst firms have now gravitated to this label. Becoming a part of a recognized market segment has obvious benefits for the leading vendors. But the IT-GRC label has some room for improvement….

I have an issue with calling this category IT-GRC. First, having looked at most of the leading products in this area, there is almost no “G” there, just risk and compliance capability and functionality. That’s probably to be expected as most of the tools started out aiming more at compliance or risk management. Most of the vendors are struggling to understand just what governance functionality is required in their products. Having previously worked for one of these vendors, we had very little (as in *no*) customer requests for new features to help with IT governance. The leading analysts in this space are only now starting to define governance functionality requirements for IT-GRC products.

My advice here for analysts and vendors alike is don’t get too carried away on the governance aspect- IT-GRC should not become an IT-focused version of enterprise GRC. Customers have too many painful new problems to be solved related to IT controls, risk and compliance. Problems like mapping multiple compliance regulations, streamlining and automating information collection for risk management and compliance, and adopting more rigorous approaches to risk analysis.

First it was "Clooneygate", when healthcare workers at a hospital in New Jersey improperly accessed the medical records of George Clooney, and where dozens of healthcare workers were suspended.

Now the LA Times is reporting here that a number of healthcare workers at the UCLA medical center also recently improperly accessed the medical records of Britney Spears. UCLA is firing 13 healthcare workers, and disciplining a number of others.

Clearly there are HIPAA violations in both cases. Healthcare organizations are caught in a difficult spot here, as their culture has been first and foremost about providing quality care, which generally means getting clinicians fast (and fairly open) access to patient data. The idea of limiting access to just those with a "need to know" is contrary to the way in which hospitals have operated for the last 100 years or so.

So despite what the HIPAA Security and Privacy rules say about limiting access to EPHI (and they aren't super granular here in specifying need to know on a per patient or per case basis), it goes against the grain in terms of how HCO's have actually operated for a long time.

Michael Rasmussen has a great post on the difference between enterprise GRC and IT-GRC up on his blog. As someone who has previously worked for an early IT-GRC vendor, I have a lot of thoughts on the topic of GRC and IT-GRC.

Michael's fundamental assertion that enterprise GRC is a lot broader than IT-GRC is I think true. I also believe that the IT-GRC products tend to go a whole lot deeper than the enterprise GRC products, meaning that IT-GRC implementations necessarily get into the details of IT assets, and the multitude of controls that affect compliance and risk status.

Both IT-GRC and enterprise GRC are concerned with helping organizations to manage governance, risk and compliance, and there are many similarities between the products that address these markets. Both generally have assessment engines, status dashboards,  and policy management functions. The IT-GRC products tend to have much  less mature governance capabilities.

Both categories seem to be moving quickly towards automated (vs. assessment-based) gathering of control state.

More blog postings to come on the topic of IT-GRC. It is nice to see the large analyst firms come around to recognizing that the IT-GRC products are fundamentally different than the Paisley's, OpenPages, et al of the world.

Jim Hietala
www.compliancefocus.com

Since the passage of SB1386 a couple of years ago, over 30 states have now passed legislation requiring notification in the event of security breaches. What is interesting to me, and what likely causes heartburn among affected organizations, are the outlier cases.

Minnesota, for example, passed HF 1758, which allows banks to recover from merchants the costs incurred as a result of a breach of debit and credit card data retained by the merchant. (Benjamin Wright has a good write-up here describing why the Minnesota law is poorly constructed). 

California amended SB1386 late last year to add medical information to the definition of personal information, so that breaches experienced by healthcare organizations and insurers, which involve medical information on California residents, have to be disclosed.

Maryland recently passed H.B. 208, which requires organizations experiencing a breach to conduct an investigation to determine the liklihood of the breach resulting in personal information being misused, with disclosure required if the organization believes that misuse of the personal information is likely. In addition, the Maryland law starts to touch on a requirement that appropriate security controls be utilized (albeit at a very high level).

As the states start to diverge as to legal responsibility and penalties (Minnesota), definition of what constitutes PII (California), and the requirements of organizations and their service providers regarding security controls (Maryland), it is pretty clear that a comprehensive federal law in this area would be very useful. Imagine the poor privacy officer at a company experiencing a breach having to sort through 30+ states breach notification laws to try and determine what the company is required to do.


Maryland excerpt:

"A business that uses a nonaffiliated third party as a service provider and

discloses personal information about a Maryland resident under a written contract with

the third party must require, by contract, that the third party implement and maintain

reasonable security procedures and practices that are: (1) appropriate to the nature of the

disclosed information; and (2) reasonably designed to help protect the information from

unauthorized access, use, modification, disclosure, or destruction."

CMS has now posted a document entitled Sample - Interview and Document Request for HIPAA Security Onsite Investigations and Compliance Reviews. The document closely mirrors the information that surfaced after the Piedmont audit last year. What is also notable is that there are things in the information request document that are not addressed at all in the HIPAA Security Rule, such as wireless network usage, and "mechanisms to ensure the integrity of data during transmission - including portable media transmission (i.e. laptops, cell phones, blackberries, thumb drives)".  

HIPAA being one of the more mature compliance regulations, wireless access and the USB storage security concern were not yet common when the HIPAA Security Rule came into being.

Time will tell if we are seeing the start of "scope creep" in HIPAA security standards, as has been experienced with GLBA by financial organizations (where the FFIEC has added an enormous amount of detail further defining what affected institutions have to do to comply).

Also on the HIPAA enforcement front, as reported on Rebecca Herold's blog, a HIPAA violation was prosecuted in Oklahoma City. The individual prosecuted was convicted of providing personally identifiable health information to other individuals, apparently in an insider identity theft.

Jim 

In a post entitled Applying Security Standards Like ISO 27002 to Compliance Requirements, Mark Tordoff comments on an article by Richard Mackey in SearchSecurity. The gist of both articles is that using a broad standard like ISO 27002 is a sensible approach to security. Further, combining the controls in ISO with the highly specific requirements of PCI DSS 1.1 can help those organizations subject to PCI to achieve compliance.

Absolutely no argument with any of this, but it leads to a broader discussion of how best to relate the controls found in standards like ISO and PCI, and to determine which controls allow an organization to comply with various requirements in regulations. Mapping of specific, discrete, measurable controls to higher level compliance requirements is still more art than science. It is highly subjective, and it requires a unique depth of understanding of many aspects of IT security, and of the relevant compliance requirements. Then extend the challenge to determining how best to test our actual compliance status. In some cases, there may be “machine data” that can determine whether we’re in compliance, based upon the presence or absence of a given control. Frequently however we will have to develop an assessment question to ask a human being about the control status.

The whole area of mapping regulations, requirements, controls, and assessment questions is a big, big challenge for most organizations. There is some very interesting work being done by a number of vendor organizations in this area, but we are a long way from reaching nirvana in the area of creating relationships between these entities that are useful and easily changeable.