F E A T U R E

Feds Reach Out and Touch IT

July 10, 2003
By Sean Doherty

>> continued from previous page

Whip Out the Crystal Ball

	Issue TOC
	Print full article
	Print this page
	Download as PDF
	E-Mail this URL
	Discuss this article
	Flame the author

	In this article
	Introduction
	All in the Implementation
	Gramm-Leach-Bliley
	Whip Out the Crystal Ball
	HIPAA
	An Open Door Policy
	Sarbanes-Oxley
	Executive Summary
	Law vs. Regulation
	FYI
	With 1386, California Leads the Way
	Hospitals Get HIPAA
	Web Links
	Epoll Results

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.