Quest For Compliance
Searching for products that will help satisfy government regulations? Many vendors claim to have all the answers, but just try to find a marketing rep willing to get into specifics about how the technology maps to particular elements of Gramm-Leach-Bliley, the Health Insurance Portability and Accountability Act, and Sarbanes-Oxley.
In the end, assessing your organization's compliance needs must be done in-house. It's never going to be easy, but information security professionals can count on a few things: You'll be responsible for determining which technology deployments meet which requirements, and it starts with an understanding of your business needs and organizational structure, not with technology itself.
 |  |
|
Compliance means tough security, Allstate's Van Nostern says.
Photo by Jeff Sciortino | |
|
|
The good news--such as it is--is that a given technology deployment might help with adherence to more than one regulation, Van Nostern says. The bottom line is tough security. "Every piece of legislation requires the same kind of controls, especially security controls," she says. "They require you to have a robust security environment. Each of them requires similar things, they just put a different kind of filter on them."
That said, experts are quick to point out that none of the Big 3 regulations is explicit about the types of technologies companies should deploy to achieve compliance. Some regulations, such as the EU Data Directive, are, in fact, prescriptive when it comes to technology, and IT security pros who dig deep into HIPAA might find recommendations related to authentication technology, for example. But overall, when it comes to Sarbox, HIPAA, and Gramm-Leach-Bliley, deciding which applications to put in place and which aren't necessary is something each organization must tackle on its own.
"If you look at section 404 [of Sarbanes-Oxley], the section that sort of started it all, it says only that you have to have 'effective business controls,'" says Diana Kelley, senior analyst at the Burton Group. "But how you interpret 404 down on the bits and bytes level is where you're going to find different interpretations of how to achieve compliance."
Kelley recommends you first determine which systems and applications are necessary for the business to continue running. This exercise helps organizations find their vulnerabilities. A financial-services firm, for instance, must get a handle on its risks when it exchanges data with other banks or the Federal Reserve. Only business-side executives are going to have a true grasp of which applications are critical to operations, and security staff will do well to turn to those individuals first, even before bringing on an audit team, Kelley says.
"That's the key: understanding your business," Kelley says. "Do that first. Then you can figure out what your risks are, what your vulnerabilities are."
Allstate's Handiwork
Allstate had its legal officers, privacy officers, and CISO Van Nostern review each regulation in detail and then work together to formulate steps the company should take to achieve compliance. Eventually, that process came down to specific technologies. HIPAA doesn't explicitly require firms to encrypt E-mail going to or from third-party partners, for example. But Allstate decided compliance required doing so when E-mails contained medical data. And the same technology can help secure credit-card or financial information that isn't relevant to HIPAA but is germane to other regulations. Technologies that audit or log security events, or those that manage access control, can apply to more than one regulation as well. With most regulations, even those beyond Sarbox, HIPAA, and Gramm-Leach-Bliley, document retention plays a role.
Allstate takes particular care when it comes to the third-party partners with which it exchanges data. The company carried out a discovery process, first determining who those vendors were and then what types of information they have. Allstate ran on-site audits with those providers to ensure that they had the proper controls in place.
"If they don't meet our requirements, they'll work with us to put controls in place," Van Nostern says. "Otherwise, we might decide not to do business with them." The discovery exercise proved enlightening for Allstate, which hadn't carried out a detailed examination of how and with whom it trades data. "It's an eye-opener to see how many exchanges you have," she says.
The dynamics around the way data is used must also be understood before a company can get down to the specifics of which technologies it should deploy, and where. This means learning where data is stored, where it's moved internally, which apps use it, and how it's shared or exchanged. Data discovery also requires determining which sets of information are relevant to each regulation. Data-retention policies that include automatic deletion after the applicable retention regulations expire are important as well. After Allstate got a grasp on the ins and outs of its data, it got specific about the technological controls it would put on its access and the ways data is transmitted.
Allstate's approach falls in line with advice from Dick Mackey, principal at consulting firm Systems Experts. Mackey suggests organizations keep their regulatory compliance as narrow as possible, worrying only about the systems and applications relevant to a particular regulation. For example, Sarbanes-Oxley is essentially about financial reporting, Mackey says. He recommends trying to segregate internal systems so those related to Sarbanes-Oxley are cordoned off from systems that are irrelevant to it, such as company informational Web sites. Once an information security team has done that, it has isolated a smaller environment to deal with.
"Otherwise," Mackey says, "you're trying to boil the ocean."
With Sarbanes-Oxley, the highest level of compliance requires a control framework with a design Mackey breaks into a small set of general components. First, organizations must determine if their systems are as secure as they should be. Second, systems must be configured to maintain security. Next, systems and apps should be accessible only to those who need to use them. That framework is a good starting point for getting into specific technologies, which might include identity-management applications, workflow tools, records and documentation tools, and technologies that control which employees can make changes to code. Obviously, core security functions such as patch management, encryption, virus detection, and firewalls are critical and relevant to more than just one regulation.
In today's interconnected enterprise, compliance also means keeping tabs on suppliers, vendors, and other partners. One privately held investment-management company, which asked not to be identified, keeps tabs on third parties ranging from payroll vendors and boutique dot-coms to data processors, marketing firms, and application service providers. The company designed a process under which it evaluates its own business needs related to the services each partner provides. It then assigns a compliance risk level to each third party, based on the type of data it shares with the partner. If the firm deems shared data as either "confidential" or "highly confidential," then the partner receiving that data is categorized as "high risk."
"It's important to note their category isn't based on their controls but the amount and type of our data they have in their possession," an IT exec at the investment-management firm says. "With third parties, it's really all about the data itself."
The company hires security firms and external auditors to assess partners' technological infrastructures. These architecture reviews take place annually. Audits determine whether each third party has security best practices in place and whether it has developed its services with security in mind.
Across The Miles
Other organizations are so far flung, both geographically and in terms of interrelated networks, that building a foundation for compliance can require several infrastructure assessments. That's the case at the Indiana University School of Medicine, which must comply with HIPAA across 36 departments.
"If a department, such as anatomy, doesn't do clinical work, but it has a computer system that's compromised within the network, that's my weak link," says Eric Schmidt, the school's CSO. "If I don't pay attention to those systems, if I don't have security measures and policies and procedures in place, that's still a compromise in the network."
|
|
||||||||
|
|
In 2003, the school found a tool built by North Carolina Health and Human Services that would serve as the baseline for its compliance initiative. The simple spreadsheet application is basically a questionnaire, Schmidt says. Each department performed its own assessment, answering 95 questions related to HIPAA. Questions might relate to whether third parties, such as hospitals, have adequate security in place or whether each department has an individual assigned to security responsibilities. Schmidt designed the questionnaire so that each department would have to answer only the questions relevant to its own operations and infrastructure.
The school has performed gap analyses for all departments and notified them about where they need to beef up compliance. Schmidt carried out a risk assessment for each department, too, so each would know which shortfalls to tackle first. Schmidt also wants to make sure that the same applications are applied across the various departments whenever possible. That will make overall compliance efforts easier, he says.
Also important is that technologies deployed to improve compliance have minimal interference with existing business processes, Schmidt adds. Physicians at the school have explicitly requested that processes in place change as little as possible. Moreover, doctors want new technologies to be as transparent to their work as possible. Generally speaking, this means new applications that have to be installed on the desktop will be avoided.
The school is investigating E-mail encryption tools that come equipped with a "HIPAA dictionary" to check E-mails against keywords and automatically encrypt pertinent messages without any effort by the user. Of course, if text analysis were perfect, we'd have no spam. So with any such system, each security manager must determine his or her organization's threshold for false positives and, even worse, false negatives, given compliance requirements. And that threshold should be gauged by IT security--you don't want users making that determination.
Still, Schmidt understands the doctors' sentiments. "I'm going to alter some of their processes, no matter what. Security awareness training, by itself, is going to alter proces- ses. But I have to minimize it," he says. "I don't want them to have to do my job. I don't want them trying to figure out if stuff is secure or not. I just want them to be doctors."
In all organizations, new transparent processes will be welcomed by users, possibly resulting in fewer calls to the help desk. And HIPAA is never going away, Schmidt says. As the school alters its technological infrastructure, it will re-evaluate whether it's staying compliant. Regulatory-compliance work evolves over time.
Tailored Effect
Schmidt's experiences at Indiana University School of Medicine illustrate how each technology that comes into play for an organization's compliance efforts must be tailored to avoid interfering with specific business processes. And his story dismisses the idea of packaged applications that can manage compliance across the board.
That fact applies to regulations beyond Sarbox, as well. Asked if there's any such thing as software that can serve as a catch-all for bringing a firm into compliance on any given regulation, Dave Stampley, general counsel and compliance specialist at IT consulting firm Neohapsis, doesn't mince words. "Absolutely not," he says. "When you say 'compliance software,' the image that pops into my head is not software that manages security or customer information, but software that helps you track the processes around compliance."
By that, Stampley means software that tracks exceptions--the areas in which organizational controls are insufficient--and manages things such as regulating which staff members are in charge of which security activities. It also can help test processes and run reports that track adherence to a regulation's elements, much as Schmidt has done at Indiana University.
"When I think of compliance software, I'm really thinking of management software," Stampley says. To the extent that regulations require the documentation of controls, such software could fulfill that need on its own.
Understand The Problem
Brooke Paul, CISO of American Financial Group, agrees with Allstate's Van Nostern that IT must first understand internal processes and then turn toward the technologies relevant to those processes. The insurance company is publicly traded and must comply with Sarbox. "Sarbanes-Oxley isn't a technology problem," Paul says. "You shouldn't be looking to a vendor to provide you with a technology until you understand your own processes."
Paul recommends working with senior management teams and both internal and external auditors to first grasp the business' processes. At American Financial, the technologies that mapped to those processes were chiefly of two kinds: application and data security, and change-management and change-control tools.
For application and data security, the focus is on the data, Paul says. Identity-management tools proved important at American Financial because the firm decided it needed to limit the number of people who can access any given pool of data. Such authorization tools ensure that people can access only the applications and data relevant to their jobs.
Change management and change control comprise a broader set of tools than application and data security, Paul says. Process-management tools, workflow tools, and the like come into play. The relevant changes might be as broad as the installation of a new administration system that deals with insurance policies or as narrow as making changes to insurance rates or terms relevant to policies. The alteration of a workflow process within a system--alterations to business rules or software coding--would also qualify as a relevant change.
Before Sarbanes-Oxley, immature IT shops might have let just any application designer go into a system and make changes, Paul says. American Financial uses identity management to tightly control which developers can alter "systems of record" such as actual operational systems.
Paul also advises taking a compliance approach based on risk management. The level of rigor that an organization should put in place, the number of preventive controls, for example, should be based directly on business risk. The first step in that process is risk analysis.
"It's got to be based on how the business operates and where the risks are," Paul says. "I don't have to put a big identity-management system in place for the intranet that posts the weekly cafeteria menu."
Above And Beyond
AARP, the advocacy group for senior citizens, isn't explicitly required to conform to any regulations but does so because it supports the spirit of the regulations, particularly the privacy of personal data. Suzanne Hall, director of IT operations and security at AARP, was recently nominated for an Information Security Executive of the Year award by the Executive Alliance, partly as a result of her compliance-related work and advocacy.
"We benchmark ourselves against many of the regulations. Our security program is based on corporate value and protecting our members' privacy," Hall says. "We take a unique approach to membership. We don't sell the AARP membership list. We never have. And we offer our members several different options on how we use their data, if we use it at all, based on their preference."
In 2001, AARP performed a gap analysis against the requirements of Gramm-Leach-Bliley, which is focused on the privacy of personal data. Soon after, the association developed a formal information-security program and created its first information security officer role. AARP improved privacy monitoring and network perimeter security, and IT security began reporting to the AARP board about the organization's data-protection efforts on an annual basis.
AARP deployed antivirus and anti-spyware software, encryption tools, and spam filters. It took on the services of an outsourced managed security service. Currently, Hall is looking at AARP's security around outbound communications, especially E-mail and Web-based chat.
|
|
So, where will regulatory compliance and picking the tools relevant to the job go from here? Like many others, Allstate's Van Nostern sees compliance becoming a bigger job in the future, not a smaller one. And hitting all the right marks will require keeping track of moving targets that stretch beyond the walls of the enterprise.
"Since Sarbanes-Oxley, the regulations have just started escalating, and we're going to continue to see that, especially around the privacy of information," Van Nostern says. "You're going to see that some of these regulations require that companies not only look at how they protect information, but also who they exchange data with and what kind of controls third-party providers have around data."
Essentials For Succeding At Compliance