Where's the "S" in IT-GRC?

Software suites that integrate governance, risk and compliance tools (usually referred to as IT-GRC) are being hyped by vendors and abetted by analysts as the next great wave of IT management solutions.

Combining these functions under one roof, IT-GRC packages promise to enable corporate management to ensure the organization is meeting enterprise risk-management goals and complying with requirements set by regulators and business partners.

But just as the best financial-management systems and a bevy of auditors have not substantially stopped the flow of financial malfeasance and misconduct, this promise will also fundamentally miss the mark without directly addressing the issue of security.

As evidenced most recently in the Hannaford data breach incident, where an estimated 4.2 million payment card holders had their trust violated through a security flaw, an organization can have a risk-management program and a compliance program and still not be secure.

Hannaford, according to public statements, used an IT-GRC package to manage its risk and compliance program, had undertaken and passed outside assessments and audits, and from all outside appearances, had been doing “the right things.” But if having a risk-management and compliance program nets the organization a very public and costly data breach, what is the point? How many dollars spent on those programs would have been better spent on addressing the fundamentals of security?

After the breach was publicized, Hannaford President and CEO Ronald C. Hodge said in a statement: “We have taken aggressive steps to augment our network security capabilities.”

Section 4.1 of the Payment Card Industry (PCI) Standard reads: "Encrypt transmission of cardholder data across open, public networks," and goes on to say "Sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit.”

Is it “reasonable” to believe that internal networks are significantly less vulnerable to attack than public networks? Yes. Is it actually true in the real world of the large distributed network? Probably not.

Compliance is not security, and risk management does not automatically provide risk reduction.

Many security firms have been telling enterprises for years that the best way to address IT Compliance and Risk is to assess where the organization’s security program is from a maturity standpoint and then use compliance requirements and risk objectives to inform and advise the actions they need to move their security program where it needs to be.

The best IT shops know that the way to optimize the scarce resources at their disposal is to include security in the architecture and design process, make the most of the security features and functions available in the products and tools they are already using, and judiciously apply additional capital and outside assistance for new functionality and the tasks they cannot or would rather not do themselves.

However, without a firm understanding of where their security program stands in terms of IT frameworks such as ISO or CobIT/COSO, and in terms of their industry peers, security efforts tend to be misdirected, piecemeal, wrong-sized or inefficient.

Without the full inclusion of the organizations’ security staff, compliance and risk-management efforts will continue to fall short, and it will only become evident after the fact that carts should not drive horses.

Consider the approach to security of two companies. The companies are in similar industries and have comparable security budgets for their compliance and security program projects. Company "A" spent its time and resources to explicitly prepare for a Sarbanes-Oxley (SOX) audit. All attention on the security controls was designed to make the company more compliant with SOX requirements. Company "B" spent its time and resources in more general management of its overall security program. Attention on its security controls was designed to improve the company’s overall security program.

Both companies achieved their specific goals but received different results. Consider assessment results performed on the two organizations after similar amounts of resources were expended. The table here shows compliance results against a reasonable set of standards after each company completed its project work.

Standard    Company A   Company B

SOX         80%         65%

ISO2005     41%         75%

PCI 1.1     27%         70%

HIPAA       46%         83%

Company “A” achieved good results, becoming about 80% compliant with the appropriate SOX requirements. For the resources and time spent, this was a reasonable result for the company, and it considered the project a success. However, for about the same amount of time and resources, Company “B” came within 20% of the same level of compliance with SOX requirements, but made significant compliance inroads with the other standards. Which of the two companies has the better enterprisewide security program?

IT-GRC packages present an image of a smoothly integrated IT function acting in harmony with the wants and needs of the enterprise. And once this new market segment exits the “Peak of Inflated Expectations” phase of Gartner’s hype-cycle, these types of solutions will present a fine tool that can aid enterprises in managing IT.

But a house is still only as good as its foundation. Many organizations would be better served ensuring that their security program is of a sufficient maturity before trying to add yet another layer of management and technology.

Gray is vice president of technical strategy and Heimerl is director of SecurCompass development for Solutionary, Inc., a provider of managed security solutions, compliance and security measurement, and security consulting services.

Learn more about this topic

 
Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies