Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Mix of Frameworks and GRC Satisfy Compliance Overlaps

Three organizations reveal how they use a combination of frameworks such as COBIT or ISO 27001 along with GRC tools satisfy overlapping industry and federal regulatory demands.

Companies are finding innovative, all-encompassing ways to satisfy multiple regulations.

If you're responsible for security, risk management and/or compliance for a global pharmaceutical distributor, a large data provider or a small municipality, you're at the cross-section of federal and industry regulatory compliance.

Regulation bombards you from every direction. Failure to meet federal and state mandates such as Sarbanes-Oxley and state data breach notification acts threatens the reputation of your corporate brand and the personal freedom of your executive officers. Falling short on industry requirements such as HIPAA, PCI, the Fair Credit Reporting Act or even state law enforcement accreditation puts in jeopardy your company's ability to do business as well as your customers' personally identifiable information.

As an information security and risk professional, you've been thrust during the last half-decade into the crosshairs of an increasingly regulated business environment. Frame-works, audits, automation and GRC are the fabric of your being.

Redundancy cannot be.

"What you don't want to do is implement or test the same control three, four, five times over," says Marc Othersen, senior analyst in the security and risk management practice at Forrester Research.

So how are businesses managing multiple regulations without a massive duplication of efforts? Is there a catch-all framework that satisfies all the overlap?

Three enterprises servicing three different markets are building their version of a compliance "easy button," drawing on a multitude of resources to create a repeatable set of processes that would satisfy the grumpiest auditor.

"It's definitely our approach to create a strategy that will be all-encompassing," says John Sapp, senior manager, IT governance, risk and compliance at McKesson Corp., the country's largest pharmaceutical distributor. "Whether it's regulatory compliance or compliance with our own internal policies, it's basically building that big picture first, and then deciding how we're going to approach it and ensure that we're doing it in a way that allows us to be really integrated across-enterprise and move away from the siloed approach that we so often see."

McKesson, with $101.7 billion in revenue in FY2008, has a mature Sarbanes-Oxley compliance program, and this is the model Sapp and his team are following to build a one-stop enterprise-wide compliance program.

Sapp, who has a development and project management background, says his organization isn't unlike much of the Fortune 500 in wanting to develop a set of repeatable processes to address compliance. He has taken steps to identify and understand McKesson's IT environment, map out and automate the testing of controls, assess and report on risk and increase the overall maturity of the organization's risk and compliance program. Right now, he says, McKesson is in an ad-hoc state, moving toward repeatable, and eventually standardized and optimized, processes.

"In three years, I would expect that we are at a standardized state," Sapp says. "That, for me, has us where we have a set of standards, processes and controls that are applied across the enterprise universally and consistently, moving toward optimized where we really almost get to a plug-and-play environment where regardless of who we acquire, we can plug them in, or if we choose to sell off an entity, it makes it an easy process for us."

Formerly, as McKesson's senior consultant for risk services (see "What's in a Title?," below), Sapp was business unit SOX coordinator in charge of the IT controls for the SOX program. Upon moving to his broader role, he quickly discovered how McKesson's numerous acquisitions had created a situation where the company operated in silos, with precious little in the way of standardized processes or a lifecycle approach for addressing regulatory mandates. His goals quickly became clear: overcome the siloed approach and build a program that will allow him to drive corporate performance through these activities.


IT GRC may be suffering from some hype overload, but McKesson's John Sapp doesn't see it that way. In fact, he buys into the concept so much, he baked it into his title: senior manager, IT governance, risk and compliance.

Sapp is one of the first to hold a senior GRC title, though Colgate-Palmolive has a manager in a similar position, and Apple Computer is advertising to fill a similar role.

Sapp formerly was senior consultant for risk services at McKesson, but as the company dedicated more resources to GRC and its overall compliance initiatives, it needed a senior manager in the role.

"Working with our VP of IT risk management, I wrote the job description and title two months ago in response to the GRC movement," Sapp says. "We found we wanted to create a single point of contact for all compliance and risk management activities, and be able to deliver some level of reporting--the governance piece--to be able to monitor the entire program across the enterprise."


McKesson's SOX program leverages the ISO 27001 standard for information security management and the COBIT framework for IT management and metrics.

Sapp says his organization has deployed Brabeion IT GRC suite to manage policies and map multiple regulations, such as PCI and HIPAA, to control frameworks. But he believes a collaboration of tools will ultimately meet McKesson's needs to get to integrated GRC and he is evaluating several other tools such as asset management and configuration management databases (CMDB). SOX, PCI and HIPAA are McKesson's three largest compliance issues, and the company's SAP environment, which it uses for its financials, is the primary area of concern.

"We found many parallels where one piece of ISO will satisfy parts of each one of those regulations," Sapp says. Access controls, for example, are codicils of each of those regulations. "ISO allows us to map across that and ensure by meeting that one ISO objective, I can test once, and certify many [times]. If I'm using the same access control process across each one, then I can reduce the amount of testing I do. That's what I've been able to do with our SOX program. I can drastically reduce the amount of time we spend in audits because we have improved our process so much. We're getting through audits in what I would call record time and within our budget."

Sapp's current evaluation of GRC tools, he hopes, will further put out to pasture the tedious, laborious manual processes in place for collecting data from business units, testing and mapping controls to particular regulations. With 200-plus controls applicable to the SOX program, Sapp says that was his first target for automation with the Brabeion tool.

"We looked to an automated tool to help us be able to test the controls, attach the evidence and keep the user from going to the next step," he says. "I had one user tell me we've improved the quality of life here. We actually used SharePoint prior to automation, but the workload isn't there that you get in these tools."

Sapp says the GRC tools he's seen do a fine job of defining the assets and entities of an organization. He says they are solid for analyzing workflow and creating dependencies; this kind of intelligence can be applied outside of GRC as well. He adds that the tools are sound for collecting asset information (e.g., identifying unsupported or expiring versions of software), which helps in a risk assessment. Finally, he says the dashboard facilities are a strong means of providing a risk picture to the C-level.

In contrast, he says some tools try to do too much, and don't do very much very well. Products billed as turnkey, full-enterprise GRC programs sometimes suffer from poor workflow because of misguided focus. "Vendors sell hard on the tool rather than getting you to step back and look at process and strategy," Sapp says. "They don't think process and strategy first; they throw this toolset at you and say this will solve all your problems."

Forrester's Othersen says the tools at their core address compliance well, mapping sources, automating manual tests and providing solid reporting. Where they fail is in not linking IT risk to business risk.

"They don't have a business perspective in their risk engines," Othersen says. "All of them are IT focused, yet most risk happens in the line of business. If you lose credit card numbers, the line of business pays, not IT. Translating IT control failures into business risks is one of the biggest failings of those packages."

He adds that they don't address governance, either. "It's up to you as a CIO or security manager to use the tool to collect and analyze data on your own."

The vagaries of regulatory compliance have left many information security professionals on an island. Your interpretation of regulation is often as important as the controls you implement to meet the intent and rigor of a federal law or industry mandate.

Isabelle Theisen, chief security officer for First Advantage Corp., deals with these vagaries with a homegrown concoction of established frameworks, processes and automated tools that implement not only a solid compliance program, but sound business practices (see "Consistency Counts," below).

Consistency Counts
By Richard E. Mackey

Organizations of all shapes and sizes face compliance requirements from all sides, whether from regulations like HIPAA, state privacy laws or the Payment Card Industry's Data Security Standard (PCI DSS).

The most efficient and effective way to deal with the diverse set of requirements stemming from the growing array of regulations is to establish a framework of consistent processes and mechanisms. The individual processes can then be adjusted to meet specific regulatory requirements. Here are five best practices that can help organizations fulfill compliance goals across multiple regulations.

Establish an information cataloging and classification process. At the heart of all regulatory requirements lies information. The information governed by regulations such as HIPAA, PCI and Gramm-Leach-Bliley needs to be protected from leakage and unauthorized access. To successfully protect information, an organization has to know where it is, what makes it sensitive, and who should have access to it. Information cataloging identifies data sets and assigns ownership. Classification defines and documents what makes information sensitive and how it must be handled. These allow an organization to define processes for data handling (e.g., encryption), define process and mechanisms for access control, and establish bounds for what needs to be audited to prove compliance.

Establish a risk management process. Many regulations require organizations to formally assess and manage risk to protected information and systems. This process needs to be applied at a high level when businesses change (e.g., in a merger or acquisition) and at a small scale (e.g., when new software or systems are installed). Having a risk assessment and management framework based on a recognized model, like OCTAVE from Carnegie Mellon University, can help organizations meet requirements from multiple regulations and justify strengthening (or weakening) controls.

Develop a consistent identity and access management process. Every regulation (and auditor) requires organizations to prove they have strong processes controlling who is permitted access to protected information and systems. While this may seem like a largely technical problem, it is primarily a process requirement. Regulations tend to emphasize the requirement that the appropriate people are involved in approving access requests and that there be an audit trail for all requests and approvals. Identity and access management technologies can help with these activities, but they depend on you to develop the appropriate workflows and involve the appropriate players.

Develop a log review process and mechanism. All regulations require organizations to maintain and monitor logs. Done correctly, logging allows a company to track and prove which users had access to which information, and provides evidence that regular maintenance took place, procedures were followed according to documentation, and certain protections were in place (e.g., firewalls and antivirus). Unfortunately, the challenges facing organizations trying to build and maintain a consistent logging scheme are many. Logs from different products have different formats, are stored in disparate systems, and may include too little or too much information. Organizations need to analyze their logging needs, confront the complexity problem and evaluate event and log management products on the market. The best of these understand log formats from multiple platforms and products, can integrate logs from distributed locations, and can provide powerful analysis tools.

Document your administrative processes. All regulations require thoroughly documented administrative procedures. However, while many organizations view this requirement to be a compliance burden, it just makes sense. Your organization cannot afford to be placed at risk because the knowledge of how to complete critical administrative functions exists only in the heads of your administrators. There's no shortcut here; the key is to document what you do and then make improvements. There will be a temptation to improve all your processes as you document. That way lies madness. If you want to achieve compliance, document, document, document.

Richard E. Mackey is vice president of SystemExperts.
Send comments on this article to [email protected].

"Business sees anything having to do with compliance as a necessary evil; they need it because they're being told they need it," Theisen says. "I'm trying to turn that around and say, 'No, you can also use IT governance, self compliance, business operations compliance and security to actually be a market differentiator against your competitors. You can turn it around and use it as a way of doing a better job against your competitors."

First Advantage is a data provider, servicing car dealers, mortgage services and employers with credit reports, background checks, skills assessments and more. The California-based company is subject to Sarbanes-Oxley, the Federal Credit Report Act, Gramm-Leach-Bliley, PCI and state data breach notification laws and privacy laws. Some of the regulations' requirements overlap, and prescriptive advice is minimal.

In response, Theisen architected what she calls the FERM (First Advantage Enterprise Risk Management) program to identify controls to cover as many regulations as possible. The framework is a blend of COBIT, ISO and NIST recommendations and a mix of manual processes to identify risk and controls and ultimately feed them into a GRC tool from ControlPath, which the company purchased 18 months ago.

"We implemented the tool across business units to perform assessment, identification, testing and remediation work to ensure we meet compliance for all of our business units," she says.

Theisen compared the manual processes in place prior to automation to typical audit work--lots of face-to-face interviews, surveys and questionnaires to determine what was in place in the different business units and inventory security, risk management, IT governance and other regulatory processes. This information was kept in a spreadsheet--not practical, Theisen says. Now it is updated into the ControlPath tool.

"I would always recommend an automated tool," Theisen says. "You do have to have a repository of that information, even if you build an easy Access database. Otherwise, you're going to ask the same questions every year to the businesses. How would you build a baseline?

It would be a nightmare to manage your compliance levels manually."

Automation also helps with trending and tracking of progress against control objectives.

Identification is the first of four deployment phases of the FERM process. Inventory such as service offerings and business unit assets are gathered and uploaded to the tool.

Assessment is the next phase. Threats, vulnerabilities and risk that could impact a particular service offering are assessed. Business impact analysis, data classification and threat modeling are done against every application that applies to a service offering in a business unit. "Because we do a data classification, we can focus only on high-risk applications for a service offering," Theisen says. "Business management has been extremely supportive because they know we are focusing on what is critical to them--high-risk applications within their service offering--and we don't have to do everything."

Those two phases are the most time consuming, she says, but are absolutely necessary.

The third phase is testing. Having established what the high-risk issues are, Theisen's group can focus on what is critical to a business unit. Application and infrastructure assessments are conducted prior to a controls analysis questionnaire. The questionnaire is tailored to the service offering in question, Theisen says. ControlPath builds a master controls library mapped to all the controls relevant to First Advantage, enabling it to build customized questionnaires for each business unit.

"It's where automation matters," she says.

Remediation is the final phase. Based on the results of testing, Theisen has a list of remediation items prioritized based on risk--all flowing from the organization's business impact analysis and data classification.

Theisen says a major challenge involves keeping up with the fluid changes in regulations where very little automation exists on the front end to gather data. Often organizations are forced to wait for vendors to update their control libraries, or do it manually.

Another challenge is the narrow focus on compliance versus doing what is right for the business by implementing sound business practices to manage data.

"I try to stay away from talking about regulations," Theisen says. "This is about sound business practices."

Public agencies may be exempt from the whims of Wall Street, but that doesn't ease the regulatory demands placed upon them. Their compliance pressures just come from different sources. For example, the city of Miami Beach is bound to Florida Department of Law Enforce-ment (FDLE) accreditation, which is the barometer by which police in the city may apply for federal funding. And then there's PCI. With Joe Citizen paying his taxes, driver's license fees and parking tickets with credit cards, the municipality, like most others, is bound to the industry's payment card security standard.

Nelson Martinez, systems support manager for the city, tackles the intersection of these demands by centralizing the city's IT infrastructure and applying ITIL as a service management platform and NIST standards to address security. This centralization becomes more important in the coming months as the city implements its egovernment initiative, which essentially creates a virtual city hall online.

"Being public funded, there's an ethical issue there. We hold ourselves to a degree of responsibility. We like to be in line with certain industry-wide security policies," Martinez says. "We're pretty much an ITIL shop and we do everything with change controls like private industry. We track everything. We have SLAs."

Martinez's organization is responsible for the city's infrastructure--networks, servers, desktops, gateways, and even disaster recovery. It supports departments with largely mobile workforces such as public safety, which must securely connect, for example, to state and federal databases for background checks during traffic stops.

There are strict FDLE configuration guidelines to which Martinez's systems must adhere, otherwise an incident could not only jeopardize sensitive public information, but endanger the department's ability to procure funding should it fail accreditation.

Standardization under ITIL is crucial, Martinez says. There is one IT department for all city agencies in Miami Beach. "It's truly the only way I want to run an IT shop. Standards are in place. There's a unified security policy that dictates how things are done," Martinez says. "It's the only way we have adequate controls in a heterogeneous environment."

Change controls are the biggest win ITIL affords the security of Martinez's shop.

"You still have to take the initiative to do your scanning and your pen-tests, see where your issues are and fix those," Martinez says. "Once you have established a baseline where you can say, 'I'm for the most part secure,' the change control processes that ITIL says you need to have in place allow you to track changes in your environment."

Martinez says Miami Beach deployed Symantec Enter-prise Security Manager to handle its vulnerability scanning and monitor for policy deviations. The tool comes with templates for NIST and NSA standards, for example. Martinez relies on these security templates to map compliance with industry regulations such as PCI and internal policies for mobile connectivity. The city also uses eEye's Blink for real-time IPS and IDS monitoring.

"Symantec ESM is very good at creating our policy templates for servers and tells us whether we're in or out of compliance," Martinez says. "The tool is a good way of showing an auditor that we're doing quarterly audit compliance runs against our machines and remediating."

In the event a security issue threatens the safety of data (and compliance), Martinez says he can resolve it by examining the root cause. Using ITIL, he can determine whether changes in a server or firewall setting, for instance, led to the particular issue.

"It helps you troubleshoot and get back to square one and figure out where this problem was introduced," he says. "If you've got an SLA, how can I guarantee to my customer that I'm going to meet 5 9s for that service?

I need to make sure I am controlling proactively the changes in the environment or making sure those changes are reviewed prior to being implemented."

Martinez says it's vital that risks associated with any change area assessed prior to implementation.

"Change has to be well thought-out," he says. "I believe it's critical to the security and availability of production environments. If you do not have adequate change control strategies in place, it's a matter of time before you have a major outage."

Forrester's Othersen says most organizations are in similar straits to these three where they're in the process of adopting frameworks and on their way toward a normalized compliance environment.

"About 10 percent have achieved that nirvana state where they're normalized, their frameworks are rationalized and automated," Othersen says. "The rest are putting down frameworks, getting budgets. There's no procurement or engineering yet, but everyone is getting there. It's just cost inefficient to run things the way they are today."

Dig Deeper on Security audit, compliance and standards