GLBA Compliance: Tips for Building a Successful Program

Board Involvement, Documentation of Programs Key to Favorable Reviews
GLBA Compliance: Tips for Building a Successful Program
Editor's Note: This is the second in a series of stories that will appear throughout July, focusing on GLBA compliance. Future installments will showcase GLBA compliance elements such as Board of Director education, Information Security programs, GLBA privacy decisions, Incident response plans, and vendor management programs.

When an institution's focus turns to compliance with the Gramm-Leach-Bliley Act (GLBA), questions always pop up -- What should the institution's core GLBA program include; who should be involved; what kind of information is needed, and what should be prepared for an assessment?

Aside from examiners' increased focus on GLBA and its related core activities, there are even more reasons to focus on how well an institution is meeting GLBA compliance. As more data breaches hit the headlines, the news media increasingly focus on what companies are doing (or not doing) to protect consumer information, as mandated by GLBA.

We've asked industry thought-leaders for their insights on GLBA program essentials, including board member involvement, key components of an information security program, as well as the keys to a successful GLBA compliance examination - and how to avoid a bad one.

It Begins with the Board
Any institution's GLBA program begins and ends with its board of directors -- this is where the strong management has to be embedded as a real indicator of success, says Nathan Johns, Executive with Crowe Chizek and Company LLC, and former Chief of Information Technology at the FDIC.

"Everything must be driven by the board. Otherwise, if it isn't coming from the top down, it's going to be another item on their 'to do' list that is pushed down to the bottom of the list or forgotten because they're busy doing their normal jobs," Johns says.

According to GLBA, the board of directors or an appropriate committee of the board of each bank shall:

Approve the bank's written information security program;
Oversee the development, implementation and maintenance of the bank's information security program, including assigning specific responsibility for its implementation and reviewing reports from management.

This does not mean day-to-day monitoring of an information security program, which is considered the responsibility of management. The board members simply need to take full accountability for privacy and the security of information.

The Board is also responsible to define the key components of a 748 A&B/501(b) program, including defining:

Protection -- how to protect customer data (NPPI)
Detection -- how to detect abnormal network activity that could indicate an attack or compromise is in progress
Response -- the steps taken to respond to the abnormal activity
Governance -- how the information security function is managed and enforced

David Schneier, a veteran information security assessor, agrees about robust board involvement. "It is key; the level of board involvement determines the institution's compliance posture," says Schneier, who is Director of Professional Services at Icons Inc., a New Jersey-based information security services firm. "When I'm asked what the key points are for GLBA, I always, always, always start with board of director involvement. We've all used the term 'tone at the top,' but for financial institutions it's essential."

The ultimate survival of an institution is on the shoulders of its board of directors observes Davi Ottenheimer, former Global Manager of Communications Security at one of the world's largest fund managers. He led development of an overall infrastructure security strategy, including operations and compliance management while at the fund manager. "It is absolutely essential to have board member involvement, including notification," he notes. Important decisions will be made regarding customer privacy and customer data (non-public personal information, or NPPI), which "could lead to fines, imprisonment or even an order to cease operations."

The Information Security Program
A GLBA-compliant information security program should develop, implement and maintain a written plan using the following five steps, Ottenheimer says:

Designate a plan coordinator;
Perform a risk assessment;
Design and implement safeguards to control identified risk;
Oversee service providers;
Periodically re-evaluate the plan.

Before the board approves an institution's written information security program, a great deal of effort goes into shaping and refining it. At the highest level, an institution's information security program should define roles and responsibilities, including key stakeholders. "There should be acceptable use language governing how information is created and managed," says Schneier. Placeholders for all the key regulatory components including incident response and vendor management should be in the program.

For an information security program to be successful, it needs its thresholds set by the board. The information security program should, in the best situation, be driven by the board, says Johns. Other key parts that need to be included are:

Employee education -- "Controls are only as good as the people implementing them," Johns says. "Education really helps employees understand the importance of the institution's information security program." People really are the weakest link in the chain, he adds. "They'll do silly things when they don't realize that it's not appropriate. They will give out information that they shouldn't if they aren't educated about the different schemes that try to get that information."

Testing of the program -- just having a written program in place with controls isn't enough, Johns explains. "It is essential that it is tested. Even though the risk assessment shows where the risk is, and controls are in place, a test will show how effective the controls are."

The Incident Response Plan
By GLPBA standards, an incident response plan should:

Have clear decision guidelines and associated actions;
Be usable, not overly complex;
Be tested regularly (at least once a quarter), and have improvements solicited from IR test participants;
Not be overly intrusion oriented, but all types of data loss incidents;
Outline how to help customers;
Outline plan to deal with law enforcement's "no public notification" requests.

The best incident response plan should include clear decision guidelines with associated actions, including who to contact, says Schneier. Rounding out a solid incident response plan would be guidelines on how to capture key information and how to manage the institution through the incident. Training staff on managing an incident is also crucial, he adds. Unfortunately, the IR plan described isn't always the case.

"I've encountered incident response plans that were more of a policy and didn't contain actionable steps. Many of the plans I've reviewed would provide little direction or assistance in the event of either a suspected or confirmed incident," Schneier says. "This is a nightmare waiting to happen."

Ottenheimer also sees data gathering as part of a good incident response plan. He also points out that people need to know where and how to report incidents. Users, system administrators, automated software and external sources are examples of four primary categories of information that could initiate an investigation. "I am often surprised to find managers who believe that a lack of input (no one knows where or how to report anything) should give them comfort," Ottenheimer notes.

The focus on system intrusion in many incident response plans, with no answer to how to handle a lost data tape or laptop, is what Johns often sees. Though the incident response plans he reviews are getting better in terms of customer notification. In certain data breaches, law enforcement tells an institution to hold off notification during its investigation, Johns notes. "The institution then doesn't have in its plan any action to request a written notification from law enforcement to back up their request." This can hurt the institution when later its regulator or customers come back to ask why customers weren't notified. "Ask law enforcement what information you can tell customers about the breach and when you can release it," Johns says.

Keys to a Successful Exam
There isn't an institution that doesn't want to have a successful examination. Even the best prepared institutions often are caught by examiners on points that they weren't looking at, says Johns. However, being able to explain from a risk-based approach "why they did what they did, and be able to justify and show that they thought it through," he adds, will often allow examiners to see the success of the program and not just the faults.

Documentation is crucial during an examination, adds Schneier. "Have it organized and ready for review. If you are doing something within scope for compliance make sure it's documented properly and that you're both doing what you say you do and that you can provide evidence where applicable." The biggest mistake he sees is "Where there are policies/procedures that are documented, but which aren't being adhered to -- big mistake."

He also advises clients to answer questions directly and honestly. "Good examiners are smart and know when they're being mislead or lied to (and most of the exams I encounter indicate that there are many good examiners out there)," Schneier adds. The key to a successful exam is to know what the institution's strengths and weaknesses are and be able to discuss the details, "And make sure the appropriate people are answering the questions."

Signs of Failure
GLBA compliance is similar to other efforts in information security, so the measure of success does not need to be unique, says Ottenheimer, who is now Director of Compliance Solutions at ArcSight, an information security vendor.

What are some of the indicators to look for if an institution is off track on its GLBA compliance efforts? "One of the biggest signs that you are headed for failure is when senior management does not want to be bothered or involved with information security and encourages profit-making efforts over compliance," Ottenheimer explains.

Here are some other signs that an institution is headed for GLBA failure:

Lack of direct board and/or senior management involvement;
Ineffective auditors - repeat audit findings;
Ineffective risk management - limited assessments;
Lack of balance between prevention, detection and correction;
Emphasis on technology alone rather than on measured solutions;
Security assessments not mapped to business/process risk;
Manual processes, or none at all, for security metrics.

In general, security managers need to demonstrate coverage and then measure overall progress of each area. They also must work closely with senior management, as well as with audit and financial risk, to ensure that business processes are considered as part of the assessment. "The bottom line is that you know when you are on track because you will have mapped control gaps by priority and been given senior management support to remedy issues involving customer privacy and/or NPPI," Ottenheimer explains.


About the Author

Linda McGlasson

Linda McGlasson

Managing Editor

Linda McGlasson is a seasoned writer and editor with 20 years of experience in writing for corporations, business publications and newspapers. She has worked in the Financial Services industry for more than 12 years. Most recently Linda headed information security awareness and training and the Computer Incident Response Team for Securities Industry Automation Corporation (SIAC), a subsidiary of the NYSE Group (NYX). As part of her role she developed infosec policy, developed new awareness testing and led the company's incident response team. In the last two years she's been involved with the Financial Services Information Sharing Analysis Center (FS-ISAC), editing its quarterly member newsletter and identifying speakers for member meetings.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.eu, you agree to our use of cookies.