CenITex, the Victorian Government’s shared services IT agency, will adopt a new IT governance, risk and compliance (ITGRC) package to improve its information security function.
Today IBM announced plans to acquire the Fitch Group’s Algorithmics, a heavy-hitter in financial risk management software and services market, for $387 million.
On the heels of Forrester’s GRC Market Overview last month, this week we published my Governance, Risk, And Compliance Predictions: 2011 And Beyond report. Based on our research with GRC vendors, buyers, and users, this paper highlights the aggressive regulatory environment and greater attention to risk management as drivers for change
Together they form what I’d call the “privacy GRC” market, where GRC stands for “governance, risk and compliance.” GRC makes up most of what privacy people do.
It’s not a big market. To put things into perspective, Gartner is only in its third year of analyzing the nascent IT GRC market. The privacy GRC market is at the moment no more than just a subset of that.
via Privacy software: Who are the early leaders? – software, security, privacy, ControlCase, Consult2Comply, brinQa, Avior Computing, Archer, applications, Agiliance – Security & Email – PC World Business.
# The organization must understand which frameworks or framework elements are needed to address, at a minimum, the critical security concerns. When addressing control requirements, more is not necessarily better, and each additional control entity represents an investment in time, money, and effort.
# Choose a base framework to use. An organization should identify a base framework to contain the additional controls. This framework should be as broad as is viable, allowing for only minimal, more specific needs to be addressed.
# Break the identified framework elements down according to functional areas and combine controls into like families or tiers. Different frameworks often contain equivalent controls under different headings or focus areas. By understanding where the controls map to one another, existing controls can often simply be enhanced rather than having to add completely different compliance needs.
# Identify critical controls that address the most restrictive requirements. In many situations, there will be control objectives that must be accomplished, intermingled with additional categories that are simply “good-to-have”. The action items that are required for compliance needs should be categorized as more critical.
# Define control “numbering system” and nomenclature. For ease of evaluation and tracking, the combined framework elements should be indexed in a way that allows them to be viewed as parts of a whole. In addition, a formalized control language should be used to address concepts across the new framework, avoiding confusion as compliance efforts begin.
# Identify affected data. Just as it was necessary in the first step to identify which controls and frameworks were needed, it becomes necessary to reverse the process, ensuring that all elements of data that are subject to the collected controls. The majority of this information was known at the start of the exercise, but a second glance after consolidating the requirements often identifies additional data sources, repositories, and systems.
# Understand data flows. As critical as it is to understand the affected data elements, it is just as important to understand where those data elements reside and why. How the information is collected, processed, stored, and transmitted is essential to determining in-scope systems, applications, and processes that must adhere to the new framework.
# Formally define scope of data controlled by the frameworks. After identifying the data flow patterns and practices, a consolidated list of servers, systems, applications, processes, and governance items must be created and then reviewed against expected values.
# Reduce data scope aggressively. Each data control element is an investment in time, money, and effort. The same can be said for each element of the in-scope data that is addressed by the combined framework. Existing business processes and needs should be used to determine if data is being used or retained in inappropriate or unneeded areas. Where possible, data should be consolidated and purged, reducing the overall scope of control coverage, especially critical control requirements such as those brought on by legal or regulatory provisions. (Editor’s note: see Ben Rothke and David Mundhenk’s guidance on reducing PCI scope.)
# Classify affected data according to impact. Some controls will be identified as more critical, and the data elements associated with these will likewise be viewed as more sensitive. These classes of information assets should be classified and labeled to ensure that adequate attention is applied.
# Define data lifecycle elements based upon classification levels and requirements identified by various standards and practices. Once the combined framework controls are in place; the data is identified, scoped, and minimized; and classification levels have been established, a comprehensive data lifecycle program should be implemented. Through this process, end users can manage data elements, complying with the chosen control framework requirements without having to conduct extensive research into sometimes arcane control sets.
# Review existing infrastructure, policy, and procedure against the consolidated framework and data lifecycle requirements. Governance and operational resources must be reviewed against the newly developed framework and associated lifecycle elements. Where needed, changes should be made to support the new controls system.
# Implement consistent solutions across all data elements located within the tier. The supporting processes that enable the controls effectiveness should be viewed from the perspective of consistent, modular growth. Networks, systems, and management tools should be designed to scale or be replaced easily. Consolidated security programs (such as incident response, vulnerability management, and change management) and scheduled requirements (audits, penetration testing, vulnerability assessments, risk assessments, and reports) should be updated to address all required controls across the entire framework, resulting in a consistent, singular approach to compliance and readiness.
eGestalt has announced the availability of SecureGRC, a solution that provides an end-to-end integration of security monitoring with IT-Governance, Risk Management and Compliance (IT-GRC) management solutions using a cloud-based delivery model.
There is built in framework support for RBI Compliance, NSE, BSE, MCDEX, PCI, ISO, COBiT, SOX, BASEL II, HIPAA, FISMA, and other country specific frameworks which are ready to use. SecureGRC has a not-so-far-seen value-add in terms of integrating, synergizing and transforming information from various sources into alert raising actionable solutions, helping in identifying the source of the attempted attack through pattern and correlation analysis, and plugging the loop hole before it takes major dimensions.
In my ongoing work with clients, I try as often as possible to stress the importance of flexibility in GRC programs. Internal processes and technology implementations must be able to accommodate the perpetually fluctuating aspects of business, compliance requirements, and risk factors. If GRC investments are made without consideration for likely requirements 1 to 2 years down the road, decision makers aren’t doing their job. And if vendors don’t offer that flexibility, they shouldn’t be on the shortlist.
New legislation continues to pass at a fast clip in the US under the new administration, some of the most revealing actions taken so far include:
- May 20, 2009 – President Obama signed the Fraud Enforcement and Recovery Act of 2009.
- June 12, 2009 – United States Congressman Gary Peters introduced his Shareholder Empowerment Act to the House.
- June 17, 2009 – President Obama outlined plans for more sweeping reform of financial regulations that would aim to consolidate supervision over all firms that pose a risk to the financial system as a whole.
Robert Whiteley and Chris McClean
“The GRC Technology Puzzle: Getting All The Pieces To Fit”
via Forrester Research.