Financial institutions are under pressure from regulators, customers, and partners to ensure that information they entrust to service providers is kept secure. Many financial service organizations experience the pressure in two ways: as a consumer of outside services and a provider of services to other organizations. With the industry's heightened awareness of security requirements has come an increase in the expectations from service consumers. As organizations increase their focus on their own security practices, they also expect more from their partners. These days it far more common for financial organizations to ask their service providers to meet a standard of security practice that would have been considered extreme just a few years ago.
Regulatory and competitive forces
Financial organizations faced with privacy laws are required to protect identity and personal financial information from unauthorized parties. The laws require financial organizations project these same requirements on service providers entrusted with this information. In addition to these regulatory measures, companies outsourcing trading-related services are often concerned with protecting their tactical and strategic activities. The concern is that exposure of their trading patterns and positions (particularly to knowledgeable people inside competing financial firms) may allow individuals or organizations to reap the benefit of costly research or undermine the strategy.
The effect: tighter controls
All financial institutions have had to interpret regulatory language to the effect that they must employ appropriate controls to ensure that only people with legitimate business need access to sensitive information. The problem has always been in answering the questions:
In the past, institutions were likely to view the entire information package as a unit that was either accessible or not. Appropriate controls would be considered to allow all operati
To continue reading for free, register below or login
To read more you must become a member of SearchFinancialSecurity.com
ons employees access to the data as long as it resided in an internal protected system or network. The fact that hundreds of administrators, developers, and support personnel had access was not much of a concern.
However, it is more common these days for customers to ask the service provider to meet the most stringent interpretations of the questions above. The service provider needs to define the information to be protected as any that gives individual account holder data as well as an indication of the identity of a security or the client institution.
Appropriate control and legitimate business need are interpreted to mean strict access control that allows only individuals with a need to work with account details to view identity data.
This kind of strict interpretation requires changes to processes and mechanisms throughout an operation. For example, you need to ensure that data available to operations support personnel is masked to avoid displaying both institutional and individual identities. You will need to modify administrative procedures to require specific authorization to gain access to systems and applications.
This model also assumes that day-to-day user access to production systems and databases is prohibited or limited to a small, closely audited group. One of the most challenging areas to address is legacy systems. A customer may require all data fields that identify institutions or individuals to be masked on all screens. This can be accomplished by changing all of the COBOL applications to only display the fields to authorized users. However, most organizations would view this as cost prohibitive.
There are two alternatives: (1) deploy technology that masks data on the screen and (2) significantly reduce the number of users with access to the screens and convince the client to live with certain users having access to protected data. The first is an area of research and the second may be extremely difficult. Service providers faced with this dilemma will need some indulgence by their customers as they revamp their legacy applications to provide tighter controls.
Another area that data exposure has been a problem is development and test. Developers and testers often claim that they need real production data to ensure that their applications will operate correctly. The data used in large financial applications require a complex array of links, so masking information while maintaining referential integrity is no easy task. Fortunately, there are products (e.g., IBM's Optim) that can help hide the identity data while allowing links in databases to continue to function. However, even this activity is not entirely automatic.
Privacy regulations have been a fact of life for some time now. However, it may not be the language of laws that determine how strong financial organizations' security controls must be. The signs are already there that financial organizations are becoming stricter in their interpretations of confidentiality and access control requirements than are the regulatory auditors. There may come a time when status quo of both technical and process controls will suffice, but it hasn't happened yet. We continue to see requirements for tighter controls where organizations used to accept standard industry practice. We're not in Kansas anymore, Toto.
About the author:
Richard E. "Dick" Mackey is a frequent speaker and contributor to magazines and online publications. He has advised leading financial firms on compliance with PCI, GLBA, and SOX. He has also provided guidance to a wide range of companies on enterprise security architecture, identity and access management, and security policy and governance.
