Looking for something else?
How to influence the C-suite, save your company money, please auditors and secure your data.
Become Compliant (without breaking the bank)
Re-use your existing tools to meet Regulatory demands.
Case Study #1
Sun Shines on SB 1386
Sun's Dennedy tackles SB 1386 compliance by making it part of the corporate culture.
Case Study #2
SureWest Makes the Call on SOX Compliance
SureWest's Dotson meets SOX compliance with tightened password controls.
Case Study #3
Insuring Compliance: Nationwide Tackles GLBA
Data-flow analysis was Nationwide's biggest task for GLBA compliance, Herath says.
Case Study #4
Lake Forest Hospital's Rx for Compliance
Lake Forest Hospital's Morenzoni: Merging networks helped with HIPAA compliance.
(without breaking the bank)
It's a floor wax! It's a dessert topping! It's a compliance tool!
Vendors have tried to cash in on the compliance crush by promising a cure-all to regulation woes. But by now, savvy IT professionals know there's no magic compliance tool--no "SOX-in-a-box" or "HIPAA-in-a-handbasket" to solve all of your enterprise compliance needs.
Rather, the trick is to understand what these tools can and cannot do. From there, you can determine whether to fine tune your existing infrastructure or invest in new technologies to meet the ever-changing regulatory requirements.
Setting Up Frameworks
Before you decide on an approach, you need to fully understand the regulations and what they require you to do.
Much of the regulatory legislation pertains to appropriate risk management and business controls, not to prescriptive security settings or systems. The lack of precise prescription is often by design. In the HIPAA Security Final Rule, for instance, a complete listing of the proposed requirements, public comment and the ruling response are included and provide transparency into the process. But the final rule is very general, lacking specific recommendations for implementation.
The lack of prescription means that companies must perform risk analyses and create their own actionable guidance. Reading through the actual requirements is a great place to start. Then you can review and adopt one of the commonly accepted control frameworks, such as COSO, COBIT, ISO 17799 and ITIL. Remember, more than one of these frameworks can be used. ITIL suggests using COBIT and ISO 17799 for defining "what" should be done, and using ITIL for the "how." The frameworks and legislation can help determine accountability paths, such as who will sign off on risk acceptance decisions. Use these as a starting point from which the key stakeholders--executives, auditors, IT administrative staff and any other employees involved in the compliance process--can obtain guidance and insight.
A word of caution: These frameworks are not entirely prescriptive, nor are they a replacement for decision making and self-definition within the organization. Creating policies and compliance rules for a business or entity is a collaborative process in which all stakeholders should participate.
For many administrators, the idea of working "top down"--from risk assessment and business controls to technical security settings on servers--may seem out of the ordinary.
Historically IT security has often been "bottom up." Technical IT risk decisions, such as which firewall to install and how to configure it, were made without input from business executives. Today, some IT professionals welcome having the business side more involved with risk assessment. However, the lack of technical knowledge of some business executives can cause frustration, even concern, for security professionals. But keep in mind that this is an opportunity to bring security out of the technical closet and make it a cornerstone of the business risk process. IT can help management understand how mitigating technologies work, how much they cost to run and manage, and what level of assurance can be reasonably expected.
Meanwhile, management is responsible for being part of the oversight process by setting acceptable levels of risk and communicating these to the IT staff. From there, the IT staff can determine what technical security policy measures are required and find tools that can meet those requirements.
Communication and collaboration are critical to a successful transition from regulations to control frameworks to technical policies and implementations.
Implementing Technical Solutions Once the framework and policies have been set, it's time to build the security architecture. One way is to translate the control objectives into organizational and IT activities, and then into a technical security architecture.
Case in point: If your organizational objective is to protect personal information from unauthorized access, you'll need to initiate employee training and user awareness. On the technical side, you may need to implement network zoning, configuration management and content controls using a variety of products including firewalls, filtering gateways and vulnerability management software among others. (See "Building Frameworks," at right)
While this process is still fairly high level, it will grow even more detailed as your organization makes additional decisions such as design choices about which firewalls or filtering gateways are selected. Technical security policies and configurations will need to be approved and applied to the various devices in the architecture.
Once architectural and design decisions have been made, the technical policies, controls and configurations must be set and monitored on existing systems, or implemented on new ones.
Here's some good news: For most companies, the lion's share of tools needed to support control objectives for regulatory compliance are already in house. Before investing a single penny in new technology, assess the ability of what you already have.
If there is pressure to purchase a specific technology or vendor solution for compliance work, don't circumvent normal purchasing procedures. Assess every new addition to the compliance architecture with the same comprehensive, strategic approach used throughout the rest of the organization.
"Recycle Existing Technology" (at right) lists tools that most companies own and specifies how the tools can be used as part of the compliance process. As you read the table, think about which of these your company already has in place and whether they are being used in your compliance efforts. If they aren't, can they be? What controls in your company would they support?
While many existing tools can be re-used as part of the compliance process, they may need some tweaking to provide sufficient assurance. A good example of this is the level of data integrity associated with a piece of data. Simple Network Management Protocol (SNMP) is used to exchange management information between network devices. SNMP traps send audit and alert information to centralized network management systems. One problem is that versions 1 and 2 of SNMP don't provide a method for authentication, and the data is not protected in transit. If the SNMP data is being used to manage or report on critical network devices, an upgrade to SNMPv3 with security enhancements is in order.
Firewalls and perimeter devices are another example of tools that could need tweaking to meet compliance objectives. If a company decides a prudent compliance decision is to restrict access to a certain server or database, the firewall or gateway in front of that device could have a new rule, narrowing access to only an approved set of IP addresses or users. Or a content filtering gateway may be configured to block data, such as personal health information, that has been classified as not-for-export during the compliance work.
Something that often catches people off guard is the need to increase storage when there's an increase in logging. To keep log files to a reasonable size, assess in advance what information really has to be logged for compliance. Do all alerts need to be recorded, even if they are duplicates that could be aggregated? If not, trim the log file to only critical information and create a robust backup plan that supports search and retrieval requirements. Many auditors have time limits for presentation of data; if you can't find the correct supporting data in time, it makes little sense to store it in the first place.
While some tools can be tuned, others may need intense customization, or could even justify a new purchase.
Case in point: portals. These tools display centralized views, or network system health or compliance status. Some vendors provide overlay reports that purport to show the company's current compliance level to a variety of the regulations, such as HIPAA, SOX and GLBA. Compliance dashboards are certainly appealing in theory, but in practice they can fall far short of the business mark. Approach dashboards with caution.
If you are planning to use a vendor-supplied template, ask the vendor how the compliance policies were created and how easy it is to customize them. Because the regulations aren't prescriptive, most vendors use one of the control frameworks as a baseline for the compliance templates. They may even augment the template with information from lawyers, auditors and customers. These templates can be a great guide, but don't rely on them out of the box. They will need additional tuning from your IT and security staff.
If the tuning work isn't done upfront, dashboards can quickly become "garbage in/garbage out." Consider a database that stores personal health information and has the admin account password set to the default. If the admin account password setting isn't being monitored by the compliance dashboard, the slick-looking graphic may indicate an all-clear for HIPAA compliance but an auditor won't.
A final thought on compliance dashboards: Make sure resources have been assigned to monitor and maintain the dashboard long-term. There's no sense in spending valuable time to customize a portal only to have the critical log and alert data be ignored.
If your existing infrastructure cannot be tuned to help with compliance, your alternative is to buy a solution. Using products to automate portions of the compliance life cycle, such as system configuration, verification and reporting, helps IT get the job done efficiently. Tools are an essential part of the compliance process, but they must be configured and managed according to sound corporate risk management decisions; without them, the process would be far more costly and labor intensive. While these products won't solve all your compliance problems, they can help make the ongoing process more sustainable and effective.
Unfortunately, there is no quick fix when it comes to compliance. But if you approach it carefully by creating and laying out the policies, and determining what you have and what you can re-use, you'll meet an audit with success without breaking the bank.
Sun Shines on SB 1386
Case Study #1/SB 1386
A California law requiring firms to inform individuals if their personal information is compromised.
As she wrote the job description, Michelle Dennedy knew exactly the type of person Sun Microsystems needed as a chief privacy officer: someone who was sharp, flexible and could "hold hands with the CIO and CSO." Sun knew too: Dennedy.
Moving into the chief privacy officer role from that of senior counsel, she had her work cut out for her. Dennedy mapped out 100 countries' privacy laws with which Sun needed to comply--including the then-draft form of SB 1386--and met with Sun's privacy council, which draws people from human resources, IT and other departments for guidance. Dennedy and her team then worked with trade groups such as TechNet to shape the wording of SB 1386.
This three-pronged approach--"people, process and technology"--is necessary for Sun to adhere to SB 1386's requirements, Dennedy says.
SB 1386 covers a fairly narrow chunk of personal data, which Dennedy cites as a positive. "It's very important [that the information affected be well delineated] for the legislation to be effective, so you know when it is time to act," she says. "That awareness of data segmentation and mapping is the biggest lesson being learned out of all these [privacy] laws."
To bolster its networks against unauthorized access, Sun uses technology it helped develop via the Liberty Alliance: specifications that define open standards for Web services and federation technology to secure personal information. Companies--from product vendors to corporations--that adhere to Liberty Alliance specs in their applications may reduce the number of times users log in to networks and the number of passwords users must remember.
The focus of federation, Dennedy adds, is "sharing as little information as you have to with your partners. It's like booking travel: The car company doesn't care that you like an aisle seat, and the airline doesn't care that you need an economy car. Federation shares exactly what you need, without excess data [being transmitted]."
To help people understand what constitutes a breach that could trigger SB 1386's mandated processes, Dennedy tries to "talk to people all the time," she says.
"If an administrative assistant has her boss's password and she goes into his computer to check something, trying to be proactive, is that a breach?" According to Dennedy, the answer lies in a dialogue. Employees should talk to her about any privacy-related issue such as "a weird e-mail or a gating function in an application that doesn't seem to work. The important thing is that they tell me.
"You don't have to have 100 full-time [people] dedicated to data protection, but you do have that many people owning data, so everyone's input helps," she says.
--Amy Rogers Nazarov
SureWest Makes the Call on
Case Study #2/SOX
Ensuring financial applications, systems and services are secure so financial reports can be trusted.
In almost a century of business, SureWest has morphed from a traditional ILEC to a provider of a full range of telephony, video and data services for customers across metropolitan Sacramento, Calif. Since the Sarbanes-Oxley Act has passed, section 404 in particular, SureWest has worked hard to ensure that its compliance has kept pace with the demands of the rapidly changing telecommunications market.
"We see SOX as a way to heighten the confidence of our investors in the financial information we are providing them," says Tim Dotson, executive director of information technology solutions at the company. "We've had formal policies in place for quite some time, but we had to make significant changes and improvements to those policies as a function of SOX."
SureWest tightened its password controls in response to SOX. Rules about how passwords were handled and the frequency with which they must be changed were not sufficient. "SOX had us get very explicit about the standards we used for each application," Dotson says. SOX mandated that an auditor must be able to easily determine the frequency of the rotation to test its controls. SureWest used "domain-level controls like [those in] Windows Active Directory, integrating them into application-access routines when possible.
"SOX would say you need to ensure that logical access to your systems is adequately controlled [and protected against unauthorized use]," he added. Policy-wise, as with the password-change rules, the details of how these safeguards are put in place must be readily available to an auditor.
Meanwhile, Dotson has put in security monitoring tools to alert him of critical system file changes. Outside scans are important, too, to verify undetected network vulnerabilities.
"The first scan revealed a number of problems in our network," he says, adding that the company devised a five-point scale to rank minor problems. "Now, there are very few items detected" during the semiannual scans, he says; SOX section 404 is part of the precedent for the scans, but so are requirements SureWest faces from state agencies, banks and other organizations.
With time, Dotson and the IT team have been able to work more efficiently on SOX. "In our first year, 11 percent of all staff hours were spent on SOX-related activity," Dotson says. "In the second year, we brought it down to 5 percent, and we want to reduce it further."
Overall, Dotson estimates that SureWest has expended about 150 staff hours developing technology to attain SOX compliance--developing standards for SOX key-control design; developing and implementing automated logging and notification scripts for various system and security events or potential incidents; developing automated SOX testing scripts; and developing and implementing automated document management systems.
Even when it's most onerous, working toward SOX compliance has yielded some unexpected positive outcomes, Dotson reflects. "It has forced us to do a better job on documenting procedures.
"It has been expensive, and it's been a scramble to get things done, but all in all, we are better off for it."
--Amy Rogers Nazarov
Insuring Compliance: Nationwide Tackles GLBA
Case Study #3/GLBA
Requires all financial institutions to design, implement and maintain safeguards to protect customer information.
By the time the Gramm-Leach-Bliley Act passed in 1999, Nationwide Insurance Companies' Kirk Herath was already a privacy veteran studying the European Union's strict privacy laws. Given that the insurer handled more than 16 million policies, any one of which was a potential security liability, that experience was crucial.
Then there were the agents to consider. Nationwide had some 8,000 who collected and maintained private client information. Though the agents operated as independent representatives, "we were the custodians of their data," Herath says.
Nationwide could not take risks. Two years prior to GLBA's passage, Nationwide put in place a working group of departments, all of which touched some issue related to data privacy. Management supported the group's initial efforts with funding, explains Herath, chief privacy officer and associate general counsel at Nationwide.
And two years after GLBA went on the books, Nationwide created an official privacy department with a staff of three--now seven--and operationalized GLBA's privacy and security directives. The company first examined the terms of GLBA, then mapped out a privacy statement that delineated all the actions the company would take to regulate the sharing of private data about Nationwide customers.
The biggest task was conducting a data-flow analysis. The process took six months, with the help of PriceWaterhouseCoopers providing data-collection methodologies, and 30 Nationwide staff assigned to conduct surveys and lead discussions company-wide.
In the first three years since the law passed, Herath erred on the side of sharing no data as Nationwide assessed GLBA's impact. Nor did the company have a customer opt-out system. "We didn't know whether we wanted to go the expense of creating one," Herath says.
In the end, Nationwide did purchase an off-the-shelf database to let consumers opt out, manage other preferences and allow Nationwide to cross-sell their data within GLBA's boundaries.
"We tried managing our do-not-call list ourselves, but we realized it was something we had to outsource" in order to stay abreast of myriad state and federal laws, Herath says.
Like other CPOs, Herath cites the importance of close relationships with peers in the risk-assessment, IT, security and legal departments. He and Jack Jones, Nationwide's CISO, "are the best of friends. I don't know how I would do my job without him, and I don't know how people in my job get their job done in the unfortunate event where they find themselves at odds with their CISO.
"I see privacy as being inherently legal, and security as inherently technological," Herath says. "If there are two of you in separate organizations fighting for the same thing, you have twice the clout--and two sources of funding, too."
Jones agrees. "I firmly believe that technology can and does play an important role in an effective information risk management program, but I believe it's a mistake to view technology as anything more than one of the many necessary tools for solving the problem. The scope of an effective information risk management program must also engage the people and process elements."
--Amy Rogers Nazarov
Lake Forest Hospital's Rx for Compliance
Case Study #4/HIPAA
Mandates that organizations adequately secure all healthcare-related data on an individual.
A few years ago, tracking patient information at Lake Forest Hospital was enough to give any IT manager a heart attack.
"Our cardiac-monitoring system had been on a standalone network. We had no control over who was accessing it. It became the responsibility of [clinicians] to ensure there was not unauthorized access to those records," explains Stephen Morenzoni, senior network engineer at the Illinois hospital. In fact, there were 15 to 20 disparate networks like this--one of the many challenges Morenzoni faced to meet the Health Insurance Portability and Accountability Act (HIPAA). But by consolidating networks and building upon their Y2K efforts, the hospital was able to become compliant and save money.
When preparing for Y2K, the hospital network had to be capable of logging data from its firewalls, servers and other network devices. Having the logs in place positioned it to meet HIPAA's logging requirements. The hospital had also already deployed Microsoft's Active Directory, and its role in making applications available only to authorized users had also advanced Lake Forest Hospital's HIPAA compliance.
The hospital's decision to move to a single network--which took place over about four years--was among the most valuable it made in terms of compliance, Morenzoni says.
"We knew that, if we could get everything put on a single backbone, in the long run, it would be cheaper and a lot easier to track and log everything." In the radiology department alone the cost savings was dramatic. In 2000, the hospital spent $2 million on film to perform 48,000 procedures. In 2005, the hospital performed 160,000 procedures--to the tune of $1.5 million. "Operationally, having a single enterprise network saves us $2.5 to $3 million a year," he says.
One area that has necessitated new capital expenditures was IT's emerging role as a storage facility for all kinds of digital information. HIPAA mandated that the hospital "devise a policy on how to handle and store everything from fetal heart strips to mammograms," Morenzoni says. To manage this vast array of data, the hospital is implementing a NAS solution using EMC's Clariion CX500 and Cisco System's Storage 9216i switches. The hospital plans to use VMware to virtualize its servers, then create a redundant data center at a second campus. Ultimately, SAN-to-SAN replication is the goal, protecting data in the event of an outage and providing the tracking and backup HIPAA requires.
The hospital's IT and corporate compliance groups--comprising about 35 staff members--worked to educate all staff about what HIPAA requires of them and what it means for the collection, storing and release of data, Morenzoni says. Reviewers from the Joint Commission for the Accreditation of Healthcare Organizations (JCAHO) routinely audit the hospital's HIPAA compliance efforts to validate its eligibility for Medicare funding and other federal resources. Preparing for JCAHO audits also helps the hospital monitor and maintain compliance, Morenzoni adds.
In the end, the work to keep patients' information confidential is driven by a HIPAA-flavored application of the Golden Rule, Morenzoni says: "We treat each person's medical information as though it were our own."
--Amy Rogers Nazarov
|The Compliance Spending Surge|
Few issues are driving information security spending these days like regulatory compliance. TheInfoPro, a research firm that investigates technology sectors in six-month intervals, conducted 172 one-on-one interviews with information security professionals in the fall of 2005.
Its findings suggest that most security budgets are increasing due to compliance. "The additional money is being spent on technologies such as identity management and data encryption, which have been identified as effective at addressing compliance requirements, and on additional staff to handle the growing workload," said Henry Nissenbaum, managing director of TheInfoPros' information security practice.
For more information, visit www.theinfopro.net
You have to be a diplomat...be flexible...and deal with different people in different ways. Some of them will get it with just an explanation of why they need to do something to comply with GLBA; others you will have to cajole, and others you will have to pound on the table.
Choose one central person to manage the compliance effort. My group and I created virtual privacy teams and built them around our major business units. I asked all of the leaders underneath those headings to provide me with people to help implement GLBA.
As information went from being paper-based to electronic, it took time to realize that IT would have to store, for instance, the pension report because human resources needed to keep it forever. Comprehensive information management was something we had to embrace.
Y2K taught us very well and early on that HIPAA compliance has to be an organization-wide effort, not just an IT effort.
Know exactly what data is affected. SB 1386 was interesting because affected data was well defined. Having a database with unstructured data where you have not delineated sensitive categories or mapped data to business units was a wake-up call for SB 1386 compliance.
The best decision we made was to communicate with the people who may be impacted [by SB 1386] and offer training for every director who conveyed information about SB 1386 to a team at Sun.
Develop and maintain direct open communication with your auditor. I can't say we started that way. We made assumptions, and they did, too. It didn't work. So now each time we take a major step, we talk. It's not uncommon for us to talk weekly, or at least monthly.
Define the right number of key controls. These are the rules you place on yourself to ensure your financial statements are going to be stated accurately. When SOX first came along, we had 132 key controls. We've been able to refine down to those that are absolutely critical: 32.