Feds Reach Out and Touch IT

Under GLBA, banks and financial institutions have a mandate to secure private customer data. They must implement a comprehensive, written information security program with administrative, technical and physical safeguards for customer information. In addition, the institution's board of directors or an appropriate committee of the board must approve the security program and oversee its development. Individual actions to enforce the regulations may reach $1,000, and damages for a class of individuals is available up to $500,000. Beyond that, GLBA regulations link information security safeguards to the overall safety and soundness of an institution and give overseeing agencies, such as the FDIC and the Treasury Department, wide latitude to address unsafe and unsound conditions in institutions under their jurisdiction.

Under HIPAA, enterprises in the health sector must guard PHI (protected health information) and implement policies and procedures to safeguard it in any format, paper or electronic. And as with GLBA, covered entities under HIPAA must identify an official responsible for developing and implementing these privacy and security policies and procedures.

Sarbox holds corporate officers accountable for their financial reporting systems. It requires the management teams of public companies to establish and maintain adequate internal controls and assess the effectiveness of those controls. It even creates a nonprofit organization (Public Company Accounting Oversight Board) to oversee the audit activities of public companies.

In light of recent corporate scandals, you're likely thinking, "Better late than never." But Sarbox is not the SEC's first foray into this regulatory arena: As early as 1979 the agency proposed rules requiring public companies to disclose certain information about their internal accounting controls. For example, the rules required management to state its opinion on whether access to corporate assets and transactions were executed and recorded in accordance with their authorization. But the SEC abandoned its rulemaking, deciding to let voluntary, private-sector initiatives continue to develop. Then came Enron.

Fast forward to today: Industry self-regulation is being replaced with law and government regulation. But though GLBA, HIPAA and Sarbox require corporate accountability in handling transactions, security and data on networks, they do not provide a detailed road map of the hardware and software you'll need to comply. Rather, each provides broad objectives and suggests implementation strategies for compliance (see "Law vs. Regulation,"). This leaves a lot for IT to interpret.Regulatory standards are not linked to specific technologies: Standards address all aspects of security and scale to many types and sizes of organizations. Enterprises are free to implement a program they find appropriate. But you must know what's going on in your network. Ignorance is no defense. For example, a small clinic that maintains all patient data on a standalone PC won't need to go so far as, say, an identity-management package, but it should implement secure password-management practices and control physical access to the machine.Defining standards rather than specific regulations also keeps the door open for technology advancements and lets IT implement best-of-breed systems. For example, providing secure e-mail to transmit protected data under GLBA or HIPAA means using encryption like PGP to protect privacy, digital signatures or digital certificates to authenticate users, and a hashing function to ensure data integrity. Both Lotus Notes and Microsoft Exchange can satisfy these requirements. Newer products like one from Siemens and Sigaba provide securee-mail and a document-delivery service for the health-care industry. There are also outsourced secure e-mail services, like MxSecureMail and Hushmail.

Speaking of outsourcers, choose them wisely. There's no passing the buck when dealing with financial and health information. If your company engages a service that handles data that comes within the scope of these acts, make sure the service provider complies with the law and regulations. Although the Department of Health and Human Services (HHS) would not likely prosecute an offshore transcription service, it would go after an enterprise that intentionally or negligently entrusted PHI to an insecure link.

A commonsense approach to keeping networks secure goes a long way toward complying with these laws (though the government is moving to offer guidelines; see "FYI"). For example, keep your Internet-connected hosts and proxy servers patched at the operating system and application levels, and maintain firewalls, VPNs and other devices that control TCP/IP traffic between the Internet and the intranet. Apply antivirus software to protect data from malicious code.

In addition, maintain logs of system access and keep track of who accesses data and engages in transactions. These requirements are not new for network professionals--in fact, more than two-thirds of readers surveyed say they already audit log data. But now you are required by law to maintain this data and archive it. Treat your logs like business records, complying with your company's data-retention policies. Several vendors are releasing data-archiving tools to help streamline this task. Addamark Technologies provides software to archive large volumes of systems activity, and database vendors like Oracle are shoring up their products' logging features. In addition,e-mail archiving applications, like Re-Soft's EmailXtender, can add e-mail to your data-retention policies and maintain a record of incoming and outgoing messages (if you have yet to set up a data-retention policy, see "The Rules of Electronic Record-Keeping").

Beyond the immediate technical solutions, complying with these laws also requires administrative support for safeguards. In other words, documentation. For IT, though, documentation often is more of a bear than are installation, configuration and maintenance.Both GLBA and HIPAA require written information-security policies, and an individual or a group must be designated as responsible for their creation and implementation throughout the enterprise. Sarbox dictates that the corporate management team assess and maintain controls over financial reporting systems. At the very least, spell out what is where and who has access when. For small organizations, this might be easy. For large, complex enterprises, you may need a policy-management package, such as BindView's bv-Control or ConfigureSoft's Enterprise Configuration Manager. These tools not only help you develop policies to comply with the law, they also help enforce policies for system-access controls, computer configurations, patch levels and more (for information on policy tools and best practices, see "Got Discipline?").

Minding the Ps & Qs

Your written policies must cover more than your systems. They also must address your employees.

Although IT uses firewalls and secure remote-access tools to keep bad guys out, the success of any enterprise security plan begins with the employees who implement it. They are the first to handle customer data and should be considered the first line of defense. Know them well. Check references during the hiring process. Require employees to read and understand your institution's privacy and security policies, and train them to take basic steps to maintain security (see "Start with Staffing").

Next, treat your customer information as a valuable, renewable and reusable asset. Provision rights to handle sensitive information and lock down workstations that access it. In most companies, especially hierarchical organizations such as financial and health-care institutions, employees are not all equal. Their access to information should correspond to their job requirements.For instance, a teller needs read-and-write access to accounts to credit and debit transactions. Does he need rights to a customer's loan history? A cardiologist needs access to the records of patients in her direct care. But does she need to see all the patient records at the hospital? Each institution will have to answer these questions, and based on complexity and size, some may need help from secure-authentication tools, such as smart tokens and smartcards, and employee-provisioning tools from the likes of Business Layers and Waveset Technologies.

Each workstation in the enterprise should authenticate users before granting access to local resources. For further assurances, desktop-management tools, like Novell's ZENworks, enforce policies on workstations to limit access to local and network resources, regardless of the login ID. Location-specific access to resources can be controlled at the server. Some may want to investigate biometric authentication, but this is far from standard industry practice today. If you run Linux or Unix, the venerable and free TCP wrappers should be installed to deny service requests from unknown workstations.

At a minimum, employees must be trained in all aspects of handling customer or patient information. This includes the use of password-activated screensavers and the practice of religiously locking rooms and filing cabinets containing customer information in hard copy. Once a training program is in place for employees, monitor it for compliance and update it as required. This will buttress your weakest link.

If you take your customer information seriously and consider it a valuable asset, you're in the ballpark to complying with the guidelines. Here's a rundown of specific requirements of GLBA, HIPAA and Sarbox.By now, we're all familiar with the privacy notices sent by banks and other financial institutions--those pamphlets printed in small type that appear, seemingly randomly, in our mailboxes. But they are not random: Financial institutions are complying with the Gramm-Leach-Bliley Act, aka the Financial Services Modernization Act of 1999.

GLBA requires banks and financial institutions to alert customers, in writing or electronically, of their policies and practices in disclosing customer information. The alert must provide a procedure to opt out of the disclosure. GLBA also recognizes that financial institutions collect personal information, including names, addresses, and credit card, phone and social security numbers, in many ways--from loan applications to Web cookies. For IT, GLBA puts the onus on banks and other financial institutions to protect the security and confidentiality of a customer's "personally identifiable financial information."Under GLBA, a "customer" is defined as a consumer who has a continuing relationship with an institution. A continuing relationship is established when an institution issues one or more of a consumer's financial services or products. This definition exempts any private information collected from businesses, as well as from consumers who have not established an ongoing relationship.

Personally identifiable financial information is any information a consumer provides a bank to obtain a financial product or service. It can result from a bank transaction to obtain a loan or safety deposit box. It also includes a customer's account balance, payment and overdraft history, and credit/debit card purchase history. GLBA even extends its reach to Web servers and includes information gathered by cookies.

Information not protected includes aggregate information or "blind data" not containing personal identifiers, such as the total number of mortgage applications by county or aggregate account balances by zip code. It also excludes information generally available to the public, such as federal, state and local government data, and information widely distributed to the media. For example, it would exclude a loan secured by a mortgage filed with a county clerk.

Banking on IT

To implement the GLBA, the Department of the Treasury, the Federal Reserve System and the FDIC published the "Interagency Guidelines Establishing Standards for Safeguarding Customer Information." Each agency republished these guidelines in an appendix to their safety regulations for financial institutions (all the agencies agreed on the text of the guidelines with only slight differences). Hence, complying is not only a matter of law, but also directly affects the safety and soundness of the entity as a whole--for example, an organization's status as a depository institution or national bank. Furthermore, each institution is responsible for ensuring that its affiliates and service providers also safeguard customer information.GLBA requires financial institutions to implement a comprehensive, written infosec policy that includes administrative, technical and physical safeguards for customer information. Institutions can consider their size, complexity, and the nature and scope of their activities when drafting and implementing, but security programs must meet some broad objectives in regard to customer information: ensure its security and confidentiality, guard it from anticipated threats or hazards, and protect it against unauthorized access.

IT is not the "last man" for accountability under the GLBA's security policy. A company's board of directors or an appropriate board committee must approve the written infosec program and oversee its development, implementation and maintenance. It must also review reports generated for management at least once a year. The reports must provide the overall status of the infosec program and the institution's compliance with the guidelines.

Affected customer information systems incorporate a litany of devices and mechanisms, including hardware and software for information processing, storage, and search and retrieval; messaging systems; and backup and archival tools. Each system may require administrative, technical and physical safeguards, but banks and institutions have a lot of flexibility when implementing such safeguards. A large consideration involves assessing risk. Specifically, enterprises must identify "reasonably foreseeable" internal and external threats that could result in unauthorized disclosure, misuse, alteration or destruction of customer information or information systems.

What constitutes a reasonably foreseeable threat? Think industry standards: Banks and financial institutions will be expected to use those security measures commonly practiced in the industry, such as implementing firewalls, antivirus programs and intrusion-detection systems. If most other banks implement a secure VPN for remote access and yours does not, you may not be perceived as a victim when you suffer a breach in security from a remote location--especially if customer information is compromised.

Customers demand that their information be treated with respect, integrity and security. To stay competitive, you must meet those demands. Financial institutions not only must know who is accessing their networks, but also what data is being accessed and who is engaging in transactions. This requires OS-, application- and database-level logging. Putting all this information in one viewable console with a tool like TriGeo Network Security's Contego can facilitate security monitoring and make it easy to analyze the sufficiency of policies and procedures to control risks. But scoping out the risk requires constant vigilance.GLBA security programs must also assess the likelihood and potential damage of perceived security threats, taking into consideration the sensitivity of customer information. Assessing these risks is a dynamic process. For each of your systems, define and maintain a secure configuration for user- and application-level access. At the very least, you need procedures for change control to systems as well as policies to add and remove user accounts.Here again, a policy-management package can streamline much of this work. But one piece of code will not satisfy all the requirements of GLBA, or HIPAA for that matter. To ensure compliance, get to the devil in each of the details.

Besides basics--such as allowing only authorized employees access to records in paper or electronic form and keeping paper records under lock and key, safe from environmental hazards such as a fire or flood--electronic records should be stored on a secure server that uses strong encryption methods to authenticate users and passwords. The server should not be directly connected to the Internet. This would expose it to a direct attack and put your data at risk.

When collecting or transmitting customer information over a network, use secure data-transmission methods. Web sites that gather customer information, such as a credit-card number, should require SSL connections. If you must transmit customer information by e-mail, make sure it does not pass over the wire in clear text. Provide and train employees with encryption tools and the capability to employ digital signatures to ensure that data is not modified in transit without detection. Caution customers about sending information by

e-mail, an inherently insecure medium for messages.

At a minimum, engage in regular backups and store the backup media in a safe place--offline and offsite in a physically secure facility. Those old shoeboxes in your closet will not do. Remember: Those tapes hold company assets. Treat them accordingly. Appoint someone to retain and manage the life cycle of customer information records. This person should keep an inventory of the records and their locations on servers and workstations, as well as proper procedures and mechanisms to archive the data and dispose of it after its EOL (end of life). Dispose of customer data at EOL by shredding paper records and removing it from online access. When disposing of computers and storage media, remove all the data from the media or physically destroy it.Under the guidelines, you must use appropriate logging functions to monitor access to customer information and audit changes to user and data security profiles. And you must review and analyze the information received to detect any improper disclosure or theft of customer information. This can be a lot of data to monitor and review. Storing logs on central servers or using a central logging facility can help.

This is only the beginning. An effective security program goes beyond workstations and customer information systems to safeguard the network.

IDSs and IPSs (intrusion-prevention systems) are becoming common in large enterprises, and though systems such as Enterasys Dragon and Cisco Secure IDS may be overkill for you, this is an area to watch. At a minimum, if your institution has an Internet connection and you provide remote access to customers, employees and partners, a firewall and/or a secure VPN become necessary. These intermediate devices serve as the first line of defense. Keep them up-to-date.

Maintain an aggressive stance on vulnerabilities. Monitor security sites like Neohapsis and the SANS/FBI's 20 Most Critical Internet Security Vulnerabilities.

Once your workstations, customer information systems and networks are secure, you will need documentation to comply with the guidelines.Document IT

IT is great at supplying technology solutions to business problems, but we're not always the best at documenting this effort and providing written policies for computer resources and access to those resources. Both GLBA and HIPAA require written documents that evidence the infosec program, and these documents must be approved from the top and implemented all the way down to the operational level.

Say physical and technical safeguards detect an intrusion or compromise to customer information. What next? GLBA requires institutions to implement a response program that specifies actions to be taken when the bank suspects or detects that unauthorized individuals have gained access to customer information. This includes appropriate reports to regulatory and law enforcement agencies. Although GLBA does not require it, institutions should also notify customers promptly when nonpublic personal information is compromised. This was not written into the law because the cost of compliance would have a dramatic effect on these institutions. And how do you enforce it? What type of compromise would trigger the notification and the duty to inform? These and other questions will be answered at the state level (see "With 1386, California Leads the Way," ).

Once your written security program is in place, you must regularly test safeguards. Although the type and frequency of the tests can be based on the institution's risk assessment, they must be conducted by third parties or staff members that are independent from the group that maintains the security programs. The results of the testing should be added to your management reports to the board or an oversight committee.

Finally, institutions must exercise due diligence in selecting service providers. By contract, enterprises must require service providers to implement appropriate measures designed to meet GLBA objectives and protect customer information they handle for the institution. And, depending on potential risks, institutions should monitor service providers to verify their compliance by, for example, reviewing audits or test results done by service providers. Institutions with contracts in existence on or before March 5, 2001, had a two-year grace period to bring their service provider agreements into compliance. That grace period ended on July 1, 2003.The Health Insurance Portability and Accountability Act of 1996 was developed as a two-step dance in health-care reform that puts the Centers for Medicare & Medicaid Services (CMS) in the lead, with the rest of the health-care industry to follow. And if anyone misses a step, HHS Office of Civil Rights will bring them in line. HIPAA's primary aim is to improve the efficiency and effectiveness of the nation's health-care system and promote the widespread use of EDI in health care. But it would be difficult, if not impossible, to accomplish this without assurances that patient health information will be kept secure and private.Title I of HIPAA protects health-insurance coverage for workers and their families. Title II deals with administrative simplification and puts HHS in charge of national standards for electronic health-care transactions and national identifiers for providers, health plans and employers. And for IT, it establishes regulations to ensure the security and privacy of electronic health-care information.

HIPAA applies to health plans, such as HMOs, Medicare and state Medicaid programs, and health-care clearinghouses that process electronic health-care information. Under the administrative simplification requirements, size does not matter. If a provider transmits, for example, health-care claims, eligibility and enrollment information, referral and authorizations for health care, or payment and remittance advice in electronic form, it is subject to the requirements.

Final privacy rules for all but the smallest organizations went into effect on April 14, 2003. For the most part, the rules deal with notifying patients about their privacy rights, training employees to understand privacy procedures, and designating an individual who is responsible for adopting and implementing privacy procedures. But there are sections of the privacy rule that drive the security rules: Particularly, the definition of PHI and securing patient records containing it.

If you define PHI as a patient medical record in any format, paper or electronic, you would not be wrong. But it can be more or less than that, depending on who collects it and what it contains. PHI is any health information collected by a covered entity that identifies an individual and relates to his or her physical or mental health condition, past, present and future. For IT, PHI does not lose its character when stored or transmitted in electronic format. This is true even where the covered entity contracts with third-party business associates to perform essential functions.

HIPAA does not give HHS authority to regulate other types of private businesses or public agencies, outside of the health-care industry. For example, the regulations do not apply to employers, life-insurance companies or some public agencies that deliver government benefits, like Social Security and welfare. Note also that electronic media does not include paper-to-paper facsimile equipment or voice-to-voice telephones. Videoconferencing and voicemail systems also are excluded because these technologies are secure point-to-point transmissions with privacy protections in federal and state wiretap laws.Under the privacy rules, covered entities must implement policies and procedures to safeguard PHI in any format, paper or electronic. As with GLBA, policies and procedures can take into account the size of the enterprise and the types of activities that relate to PHI. For example, a pharmacy will have different privacy policies and procedures than a doctor's office. The policies can be in written or electronic form. Communications between patients and covered entities--such as authorizations to access patient records and requests for records--also can be kept in written or electronic form. These records must be retained for possible retrieval for a period of six years. Here, IT can reduce a paper log to electronic form to facilitate access and reduce storage costs.

When you dig further into the privacy rules you hit a conduit in Section 164.530. There, entities must implement appropriate administrative, technical and physical safeguards to protect PHI. Further, they must guard from any intentional or unintentional use or disclosure of PHI. This opens the door to the security rules where entities must ensure the confidentiality, integrity and availability of all electronic PHI they create, receive, maintain or transmit. HIPAA's security rules are similar to GLBA's. They do not dictate the application of discrete technologies. Instead, they provide general requirements that leave the door open for new technologies to satisfy the rules. Broadly speaking, entities must protect against any reasonably anticipated threats or hazards to the security and integrity of PHI while guarding against unauthorized uses or disclosures. In choosing specific security measures, the rules allow for a flexible approach.

A large health plan, such as BlueCross BlueShield, will have different concerns than a small, self-administered plan. These concerns include the entity's technical infrastructure, hardware, software and security capabilities. Another factor to consider is the cost of the solution in light of the potential risks to electronic PHI.

The security rules for HIPAA are neatly grouped into administrative, physical and technical safeguards. In practice, however, they are not so easily segregated. Safeguarding electronic PHI involves the implementation of technical safeguards with administrative procedures and policies. For example, administrative safeguards should include awareness training for staff. Additional protections can be added with desktop-management tools that lock down systems, prohibit unauthorized downloads and limit the executable applications on desktops. Further assurances can include desktop firewalls, such as those from Sygate Technologies and Zone Labs.

Specific implementations or specifications to achieve each administrative, physical and technical safeguard are either "required" or "addressable." Required specifications mean just that: required. You must implement the specification. For addressable specifications, you must assess whether it is "reasonable" and "appropriate" to implement. As with GLBA, what is reasonable and appropriate will include an analysis of industry-standard practices. If you decide not to use a common technology, document the reasons and implement an equivalent alternative measure. But regardless of the specifications, companies must review and modify plans periodically in light of new threats and new protective technologies.Administrative safeguards are designed to manage the selection, development, implementation and maintenance of security measures across a work force. They require a risk-management assessment and mandatory sanctions against employees who do not comply with security rules. Enterprises also are required to identify an official responsible for developing and implementing security policies and procedures. This can be the same person who is responsible for privacy.

All users should have unique identifiers or login IDs to information systems and electronic PHI. This will enable access-control methods consistent with privacy rules. Under HIPAA, privacy rules will be the impetus to implement security standards in 2005.

You should restrict users' access to only that information they have a legitimate need to see. Ideally, the control mechanism should be based on individual users, but the rules also allow implementation features found in directory services, like NDS and Critical Path's Directory Server. They can include context-based and role-based as well as user-based access. For example, a context base could include a practice group, such as internal medicine or the emergency room, while a role base could specify doctor or nurse.

If context- or role-based authentication is used, organizations will have to determine the appropriate contexts or job categories for their size and complexity. Organizations may allow medical staff full access to all patient records, for example, or limit them to only records for patients under their direct care. Access rules also require procedures to obtain patient information in an emergency as well as addressable specifications, including an automatic logon/logoff at workstations after a threshold of inactivity and encrypting user names and passwords.

Organizations must maintain audit trails that log all access to system information. In conjunction with logins, information-system monitors must record and examine activity in systems that contain electronic PHI. All log data should be in a form that can be retrieved and reviewed easily and should include the date and time of the access, as well as the information or record accessed and the user ID under which access occurred. This will most likely involve the aggregation of logs for system access and application access to specific data. In addition, audit logs should be reviewed regularly for discrepancies and in response to requests from individual patients.Companies must regularly review records of system activity. This includes audit logs, access reports and, where applicable, security incident tracking reports. If you use this information for bed-time reading, you most likely won't get a lot of sleep--this is a lot of data. Again, products that aggregate, search and archive logs from numerous sources can help. If you transfer information via e-mail, an e-mail archiving system will give you a messaging life-cycle solution. But you also must consider the addressable rules for PHI in transit and in storage.

The rules of the road for PHI in electronic media and messages include specifications for encryption and integrity controls. These ensure that PHI is not modified without detection while in transit or storage. Protect sensitive information when transmitting it over external networks, like the Internet, where it can be easily intercepted and viewed by someone other than the intended recipient. To accomplish this, transmit PHI using one of several available encryption schemes. If you cannot meet the requirement, you should transmit electronic PHI only over secure, dedicated lines or limit its transmission to fax or voice telephone.

But security for PHI does not end at the phone jack or the data closet. Organizations must meet certain physical security standards, too, defined as policies and procedures to protect electronic information systems, buildings and equipment from natural and environmental hazards as well as would-be attackers. Computer output devices, such as printers, monitors, fax output trays and even audio if someone were using voice-transcription software, should be placed where they cannot be viewed or accessed by unauthorized users. In addition, procedures should be established for paper output of medical records and any documents that are not incorporated into the patient's record, for example, a prescription or bill. Physical security also includes disaster-recovery plans for backup and recovery strategies and contingency plans to access patient information in an emergency.

In addition to backup and recovery, an entity needs a contingency plan establishing policies and procedures to respond to an emergency, whether natural or man-made, like fire, vandalism or system failure. This requires the entity to enable an emergency mode of operation that continues critical business processes and their security protections following a catastrophe. Although a primary insurer, like Lloyds of London, can protect your investment and even insure you from financial loss due to downtime, it cannot ensure access to records to provide primary health-care or other medical services. The rules require you to test the mechanics of backup, recovery and your emergency mode operations at least once a year.

HIPAA also calls for a security incident and response procedure. Enterprises must identify, respond to and mitigate suspected or known security incidents and must also document security incidents and their outcomes. But these rules fall short of GLBA's requirement to report incidents to a central authority, and HIPAA does not require an entity to notify users when their patient records are accessed without authority. Following on the heels of the Enron and WorldCom debacles last year, legislators fired the first salvos to combat corporate fraud and abuse in securities with the passage of the Sarbanes-Oxley Act of 2002. This year, the SEC is finalizing regulations to implement Sarbox. Contrary to what you might read or hear in the news, the sky is not falling on IT. But it may fall on your corporate directors and officers unless you help.In one sense, Sarbox is a knee-jerk response to corporate abuse. Among other things, it prohibits record tampering with the intent to impair a record's integrity or availability for use in official proceedings. It requires any accountant who conducts an audit of a public company to maintain his or her working papers for a period of seven years after the audit or review is completed. In addition, it mandates directors, officers and principal stockholders to publish beneficial ownership reports of equity securities issued to them by the company. Beyond the reflexive action, Sarbox makes clear that Congress wants some accountability in financial reporting that will involve information systems and IT.

Sarbox aims to protect investors and improve the accuracy of corporate disclosures (read: reporting) by issuers under the Securities and Exchange Act of 1934 (read: public companies). Section 404 requires that management teams of public companies establish and maintain adequate internal controls over their financial reporting systems. In addition, management must assess the effectiveness of these internal controls in their annual reports to the SEC. The company's auditor must also attest to and report on management's assessment of the effectiveness of their internal controls and procedures for financial reporting in accordance with standards established by the Public Company Accounting Oversight Board.

The PCAOB was established by the SEC (pursuant to Sarbox) to oversee the audit of public companies. The PCAOB's mission is to protect investors and secure the public interest in the preparation and publication of informative and accurate audit reports of public securities. The board registers public accounting firms, establishes rules and standards related to audit reports, and conducts investigations and disciplinary proceedings.

Defining internal controls over financial reporting will be the key to satisfying the requirements of Sarbox. These internal controls are largely in the realm of IT, where business processes meet software algorithms. Adequate controls will include processes designed or supervised by the company's principal executives and financial officers that provide reasonable assurances that financial reporting and preparation of financial statements are in accordance with generally accepted accounting principles. The controls include the policies and procedures to maintain accurate records that reflect the transactions and dispositions of assets; ensure that transactions are properly recorded and reported; and safeguard assets against unauthorized or improper use.

Sound familiar? Sarbox's controls are not unlike those in GLBA and HIPAA to safeguard data against unauthorized and improper use--except the SEC is squarely focused on corporate accountability in financial reporting. And blind faith in an IT financial reporting system will not be a good defense. The rules formally acknowledge corporate responsibility to create and maintain controls to identify and manage the risks that result in inaccurate data or fraudulent reporting.The risks associated with accurate reporting are not far removed from the risks identified in industries governed by GLBA and HIPAA. IT security risks are nondiscriminatory and apply equally to banks, financial institutions and medical facilities as well as educational organizations, manufacturing and transportation.

Many IT shops look to a risk-assessment framework from the ISO 17799 standard; 17799 treats IT security as a business issue and covers all the familiar topics, such as system operation and maintenance, backup and restore, document handling and data integrity. Beyond that, many of the same solutions that satisfy GLBA and HIPAA--specifically, policy-management packages, log analyzers and change-control procedures--can apply to Sarbox to assert and monitor controls over financial reporting systems.

Many vendors are updating their products or announcing new ones aimed to comply with Sarbox. For example, Oracle and PricewaterhouseCoopers developed Internal Controls Manager, which works with Oracle's

E-business suite. And Plumtree Software, with HandySoft Corp., released Accelerator, which brings business-process software to Plumtree's portal to create and establish internal controls and reporting procedures while maintaining collaboration tools for corporate officers, directors and their auditors. These and other solutions will bring business processes in line with software logic and put them in plain view for investors' review.

Management also needs to assess the reliability of internal controls and disclose any material weakness in their financial reporting. If one or more weaknesses exist, management will not be able to conclude that the company's internal controls are effective, and this will affect the bottom line. Investors will be leery about supporting a public company without effective controls on its internal financial systems. This may require consultants and service organizations that can supply more than IT security solutions. Public companies can look to full-service consultants such as EDS, Greenwich Technology and PricewaterhouseCoopers for technology as well as financial and legal help. Other providers are vying for a growing market to advise and consult enterprises on IT and government regulations. An example is PeopleSoft's bid to acquire J.D. Edwards.Sarbox will be remembered as the regulation that fights the good fight against corporate fraud and abuse. But for IT, Sarbox means Uncle Sam is demanding corporate accountability in financial reporting systems. If that does not happen, heads may roll. Anyone who falsely certifies that financial conditions and the results of operations are accurate while knowing that they do not reflect financial reality will be fined up to $1 million or imprisoned up to 10 years--or both.

But there is a rhyme to all the government's reasons for Sarbox. Investors will be more confident when reviewing financial reports and more willing to invest. Unfortunately for the public, the reporting requirements do not go into effect for most companies until April 15, 2005.

Sean Doherty is a technology editor and lawyer based at our Syracuse University Real-World Labs®. A former project manager and IT engineer at Syracuse University, he helped develop centrally supported applications and storage systems. Write to him at [email protected].

Post a comment or question on this story.

The Law and IT

It's bottom of the ninth, two outs for the good old days of enterprises exercising sole control over how their sensitive business data was stored, distributed, used and protected (or the not so-good-old days if you worked for Enron or had personal data stolen). The federal government is getting in the game with a vengeance with GLBA, HIPAA, the Patriot Act and the Sarbox Act. For now, only companies that deal with private health and financial data are affected, but others should take note: As Uncle Sam flexes his regulatory muscles--and hands out some fat fines--more types of industries could be affected.Now's the time for IT to step up to the plate: Neither GLBA nor HIPAA designates specific technologies or products that will satisfy security requirements, and though final rules for implementing the Sarbox Act are still in the works, they are sure to follow suit. Instead, agencies responsible for issuing regulations under these acts promulgate guidelines and discuss broad implementation standards. It's your job to take these guiding principles and turn them into strong security policies to protect one of your company's most valuable assets: customer information.

For those affected now, we offer an in-depth look at GLBA, HIPAA and the Sarbox Act with tips on technologies and strategies to stay in compliance. We also examine institutions feeling the weight of HIPAA, including Children's Hospital Boston, St. Vincent Hospital in Indianapolis and North Carolina's Medicaid program, and talk to companies, such as EDS and IBM, that are pitching products and services that may aid in compliance.You might wonder why IT usually has to deal with regulations rather than with laws or statutes. Answer: Federal and state lawmakers delegate their legislative power to administrative agencies--like the Department of Labor--just as CIOs and managers pass tasks down through their chains of command.

Regulations or rules promulgated by these agencies have the same legal effect as laws or statutes. But unlike statutes, rules do not need to go through the legislative process to have the force of law. The public, however, does have an opportunity to participate in the rulemaking process. Agencies are required to publish a notice of their proposed rulemaking in the Federal Register and to give the public a chance to comment. An agency responds to the comments and publishes a final rule.

The Federal Register is published daily on a regular business schedule. All issues in a given year are collected into a single volume with consecutive pagination throughout the year. After rules and regulations are published in the Federal Register, they are brought together by subject matter in the CFR (Code of Federal Regulations). The CFR comprises 50 titles, ranging from agriculture to wildlife and fisheries. For GLBA and HIPAA, the CFR includes all the regulations in force for banks (Title 12) and public welfare (Title 45).

Resources

• Code of Federal Regulations (CFR)

• Cornell Legal Information Institute

• Federal Register (FR)

• FindLaw• Thomas, Legislative Information on the Internet

• US Code (USC)

To help IT comply with new regulations, the government is drawing up guidelines in the form of three Federal Information Processing Standard drafts. The first, FIPS 199, aims to help enterprises classify risks as low, moderate or high for three security objectives: confidentiality, integrity and availability. You can find the draft at csrc.nist.gov/publications/drafts/FIPS-PUB-199-ipd.pdf; NIST is accepting public comments on the matter until August 14, 2003 (see csrc.nist.gov/publications/drafts/FIPS199-FRnotice.pdf). For the second piece of the series, NIST will offer guidelines to help agencies identify the types of information and information system appropriate for each category of data. For the third, NIST plans to specify the minimum sets of security controls for each defined category of information and information system.In most states accountability does not go back to the original source: the patient or customer. Neither GLBA nor HIPAA require enterprises to inform customers if their personal or private information is compromised, and there is no comprehensive federal law protecting privacy in the United States. Such laws have generally fallen to the states.

Some states have responded, with common law providing remedies for intrusions into the private affairs of their citizens and protecting their private facts from public disclosure. Other states continue to be at the forefront of protecting privacy.

California signed SB 1386 into law in 2002, and it became effective on July 1, 2003. SB 1386 protects California citizens' personal information, including social security, driver's license, credit card and financial account numbers. SB 1386 requires any state agency, person, or business with computerized data that includes unencrypted personal data of a California citizen to disclose breaches in security that compromise that information. The law requires the disclosure to be made as speedily as possible, and any company--regardless of location--that does business with California citizens is affected.

Many people will be watching to see if this law will hold up in court and how it will be enforced by the state attorney general. For example, the law is not precise in regard to what security breaches may trigger the notification requirement, and it is also vague as to the time frame to send the notification.But don't be shortsighted. Look into encrypting private information in your databases and files. It makes good business sense, and your customers will be more confident in their relationship with you. Besides, we predict that the federal government will follow California's lead because if it does not, enterprises may face a patchwork of 50 different state laws. That would be bad for business. And at the very least, 1386 shows that one state recognizes who owns personal information and who should be informed when it is compromised. You might expect IT managers to roll their eyes at the mention of new government regulations that force them to retrofit or even overhaul their systems. But some health-care industry IT practitioners say changes mandated by HIPAA are just what the doctor ordered.

The regulations that are part of the Health Insurance Portability and Accountability Act have raised awareness about IT security and privacy best practices, and they're driving transaction-format standards that are sorely needed. They've also forced insurers and health-care providers to set aside their age-old animosity and together devise plans for compliance.

IT pros on both the payer and provider sides of the fence agree that HIPAA has forced a re-evaluation of virtually every system under their control, not just patient databases. For example, Children's Hospital Boston, the largest pediatric medical center in the United States, wants to take advantage of the new HIPAA-inspired standards to swap more X-rays and diagnostic reports electronically with other medical providers, but few provider systems can accommodate the Netscape back end to its iPlanet e-mail system. So the hospital is moving 1,000 users to Microsoft Exchange by October 7. HIPAA "wasn't the only driver," says Children's CTO Scott Ogawa. "But it factors heavily."

Bruce Peck, information security manager at St. Vincent Hospital in Indianapolis, says HIPAA has strengthened his case for security improvements throughout the 1,200-bed facility. Peck's wish list has long included an authentication system that would let physicians sign on once via remote connections to all the applications that handle patient and lab data. Since these doctors are unaffiliated with the hospital and can choose any facility for their patients, it makes good business sense to attract them with such a system.

If the business case wasn't a good enough argument to add SecurID tokens from Security Dynamics Technologies and single sign-on management software from Computer Associates, the clincher was the HIPAA privacy rules that took effect in April. They require that employees have only enough access to patient data to do their jobs, and no more. For St. Vincent Hospital, role-based authentication was the solution.Peck has also added an intrusion-detection system from Internet Security Systems to ensure compliance with HIPAA's data security requirements, which take full effect in two years.

"The HIPAA security regs are the stuff that we should be doing anyway," Peck says. "HIPAA just gives you the hammer to do it now."

The price tag for HIPAA upgrades is steep. Consultants we spoke with estimate that insurers and providers will spend between two and five times what they spent on Y2K remediation. For a large organization, that adds up to at least $4 million; some insurers will spend $10 million.

HIPAA accounts for the fact that not every health-care provider has the resources of a Children's or St. Vincent. Providers are directed to do what they can and then document what they did and why they did it. The key is making sure you have been diligent in the event of a lawsuit.

Even so, many providers, especially small medical practices that relied on their software vendors to provide HIPAA updates, won't be ready when the transaction and security deadlines hit, in October 2003 and April 2005, respectively. Many are expected to revert to paper forms--a nightmare for the insurers, whose work forces and IT systems are calibrated to process claims electronically.Rather than update their software, many practice-management vendors have said they will sunset their packages and provide no further upgrades. "There is a prevailing wisdom that the amount of paper will move sharply upward," says John Dyer, marketing segment manager for health care at IBM, who expects small providers to outsource claims processing to clearinghouses, such as WebMD.

Perhaps the biggest challenge is standardizing the EDI transaction formats that insurers and medical providers use to exchange information about claims. The current systems are designed to send and receive small blasts of information, such as an inquiry into whether a patient is eligible for a certain procedure or a check on the status of a claim. Even though there are standards that define the format of those blasts--for instance, UB92 for Universal Billing--insurance companies such as Aetna, BlueCross and Cigna represent those transactions differently in their own systems.

Under HIPAA, hospital claims can also include up to 999 items called service lines, which are the specific supplies and medical services that make up a single claim for payment. This means accommodating more information packed into fewer transactions. Rather than perform Y2K-like remediation on mainframe applications written in COBOL and assembler--which can't handle files with so many service lines--many payers and providers are placing XML gateways in front of their back ends to turn proprietary formats into standard ones.

Children's Hospital built such a gateway to aggregate the blasts, package them into HIPAA-compliant transactions and route them to the appropriate payers. In reverse, the gateway continuously watches for returning transactions and converts HIPAA-compliant formats back into Children's native formats.

The gateway was implemented in accordance with standards developed by the New England Health Care EDI Network (NEHEN), a group comprised of hospital and insurance company CIOs and CTOs formed in 1998 to address HIPAA, which was passed two years earlier. The goal was to define standard formats and best practices in advance of specific direction from federal regulators, says Ogawa, who is a voting director of the consortium. The standards were developed with help from integrator Computer Sciences Corp.To Ogawa, it was far preferable for Children's to go it alone rather than rely on its software vendors to provide HIPAA updates. It was also important to start early. "We couldn't just rely on what the vendors might do at some point," he says. "Like Y2K compliance, we knew we would be at their mercy if we waited."

Because HIPAA rules sometimes add new information and require new form fields, a gateway isn't enough. Remediation may be necessary so that old back-end systems can address the new fields. New applications are also necessary on the front end. Children's built a separate application to track privacy disclosures throughout the hospital, so that a patient who signs HIPAA forms in the reception area won't have to sign the same forms later. It wasn't optimal to build functions into existing apps for disclosure tracking; not all employees use the same apps, and some vendors prohibit alterations to their code.

North Carolina's Medicaid program chose to migrate to an IBM DB2 relational database from an old VSAM (virtual storage access method), which provided direct access to files. It added a gateway to translate inbound transactions into formats that the existing back end would understand and outbound transactions into standard formats. It also altered the back end because it couldn't accommodate the multitude of transaction types associated with Medicaid. Medicaid covers more treatments than commercial insurers usually do, including social work services, disabled day-care services and long-term care, says Cathy Waters, an EDS systems director who oversees North Carolina's Medicaid systems. EDS processes all of the state's Medicaid transactions, totaling $7 billion last year. Some 38 states contract with fiscal agents for Medicaid processing.

There's a movement afoot to eliminate local codes and standardize on a national system, which would impose a new burden on IT. Meantime, health-care IT managers should pay careful attention to HIPAA lawsuits. Experts say many of the regs leave implementation details open to interpretation. "The litigation piece will drive the next wave of what IT has to do," Peck says. "Until litigation is brought, courts make their decisions and then [Congress] goes back to clarify; it will be a constant change-and-update environment for the next few years. ... People who say they're 100 percent HIPAA-compliant are fooling themselves." --David JoachimRelated Stories

"Complying With the Feds""Secure to the Core"

"Managing Your Digital Rights"

"Employee Provisioning"

HIPAA Web ResourcesDepartment of Health and Human Services

Health Privacy Project (State Law Health Privacy)

HIPAA.org

Strategic National Implementation Process (SNIP)

GLBA Web Resources

EPIC

FTC on GLBA

CERT Coordination Center

Federal Computer Incident Response CenterNational Infrastructure Protection Center

NIST Computer Resource Security Center

SANS Institute

Sarbox Web ResourcesAICPA (American Institute of Certified Public Accountants)

COSO (Committee of Sponsoring Organizations of the Treadway Commission)

ISO 17799 Best Practices in Information Security

ISO 17799 Service and Software Directory

Sarbanes-OxleySEC Final Rules