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.
Determining whether to fine tune or buy
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.
This was first published in May 2006