Conference of Electronic Security in the Payments System

March 17, 1997

Leslie Tortora
Managing Director
Goldman, Sachs & Co.

Managing Security for a Global Investment Banking Firm


Introduction

I am responsible for the technology at Goldman Sachs on a worldwide basis. The topic of security and how to effectively manage the firm's global network and data flows is a key challenge of my position. I have found its significance to have expanded fairly dramatically over the 14 years that I have been at GS.

Before going further, I need to warn you that my topic has been changed from the printed agenda of "Implementing Cross-Border Electronic Security" to the broader topic of "Security Issues Facing a Global Investment Bank." After speaking to Adam and Theo, we agreed that we should focus on the fundamental security issues facing Goldman Sachs on a strategic and daily basis. These issues primarily concern the management of our internal data and processing network, and the policies and procedures surrounding it. It was also clear from the agenda that there would be extensive technical security expertise at this symposium today. I thought, therefore, that I would focus primarily on the types of security issues confronting senior technology managers as they attempt to roll out technology within a global firm .

My discussion will focus more upon the issues and not as much on the technical responses to these issues. As I stated before, these issues have changed dramatically over the past 14 years that I have been engaged in technology at Goldman Sachs. They have evolved as our firm's information flow, processing flow, and organizational emphasis have evolved along with the accompanying increased technology capabilities that we have deployed.

Today, I will begin with a brief description of Goldman Sachs' businesses and technology infrastructure in order to provide a context for the bulk of the discussion, which will center upon the business requirements and resulting security requirements. I will conclude with a brief review of how we have set up our internal security organization in order to be responsive to those requirements.

Background Information

Before plunging into the main topic, I would like to give some background information in order to place later comments into a context. I will briefly describe:

  • Goldman Sachs' business structure
  • Goldman Sachs' technology infrastructure and approach
  • the security elements we tend to worry about within that infrastructure

I have taken the liberty of extracting a description of the Goldman Sachs business structure from our public web site. It states that :

"Goldman Sachs is headquartered in New York, has regional headquarters in London, Tokyo, and Hong Kong, and has offices throughout the Americas, Europe, and the Asia-Pacific region. Our firm serves its clients through teams of professionals who provide state-of-the-art services and products in local markets and have distinctive capabilities to help them capitalize on opportunities world wide."

That simple paragraph has led to tremendous challenges from a technology perspective. Our business goals do require team coverage across location and product. They have led to demanding a fairly seamless flow of information to our "virtual" worldwide organization in order to give our clients the most efficient and effective service.

These objectives have significantly shaped the evolution of our application suite and supporting technology computing network, which, in turn, has led to most of the challenges in the security arena.

  1. Application Development: During 1990, we began to reengineer information flows to a more streamlined information and processing model. This led to an approach that:
    • established global development teams by function
    • established focus by business division
    • moved toward reengineering the workflows in order to provide accurate data and real-time information and input by originator of information

This entailed moving from a mainframe centric processing to a more distributed processing paradigm. Today, 80% of the application development resources are working within a client server model.

  1. Centralized Infrastructure (all areas outside application development): Important in order to control management, stability, and security of the firm's computing network.
  2. Empowered Security Function: Hired high caliber security experts. Redefined role from previous "password permissioning group" to include strategy and engineering role.

This group is responsible for overseeing the core security elements of our technology strategy:

Authentication: Who are you (password, pin, smart card)

  • Authorization: What can you do
  • Audit: What did you do
  • Encryption: Prevent others from detecting or changing what you are doing

Description of Business Environment and Resulting Security Issues

Now onto the main topic, which is the Goldman Sachs business environment and its resulting security challenges.

In thinking about today's agenda, I tried to crystallize in my mind why the security challenges during 1997 seem so much more significant than those of five years ago. I believe their consideration is relevant to most strategic initiatives in our technology deployment. At first I placed a technical bias on security's current significance. There is no question that the movement toward distributed computing, as well as the introduction of mobile computing and the tremendous growth of web technology, has made security a cornerstone of all technology strategies. Yet the pressure to deploy these technical strategies has been primarily driven by the firm's consistent focus on being a truly global player, with integrated information and workflows across its various offices. Today, I would like to review some of the security challenges that have come out of our global business strategy. They spring from several areas, which I will attempt to highlight: the creation of international offices, the business strategy of allowing site-independent access and processing of information, the introduction of mobile computing, and the increased information flow being provided to the firm's clients.

Security Issues Emerging From Setting Up Different Physical Sites (New Offices)

On the most basic level, our firm's desire to develop a global business has led to the creation of full-service offices in most major financial centers. This has led to requiring our security areas to become familiar with the different local and international requirements as they relate to encryption software implementations as well as specific implementation of cross-border processing. Some of these issues have been murky and have required "interpretation," while others have been quite clear but have required adjusting our computing architecture to accommodate the different requirements. Two examples of these types of issues that come to mind center upon complying with the U.S. Encryption Export Restrictions and the implementation requirements we experienced in setting up our Frankfurt office.

Example 1: Dealing within the US Encryption

As part of our global security strategy, we have selected a software vendor that offers encryption software to enable us to transfer files to and from clients and vendors through the Internet as well as within our internal network. We had developed this strategy originally for our U.S. clients and internal needs. When we attempted to deploy this same software for either international clients or our own offices, we discovered that it had not been "permissioned" by the U.S. Commerce Department (or the State Department prior to Jan. 1). This kicked off a research process to determine what needed to be done to deploy the software. We discovered that as a U.S. bank, we could file for permission to use this software within Goldman Sachs' internal network. Our international clients cannot purchase the software from the vendor since the government administration has not allowed non U.S. residents to purchase the strongest encryption software. But though they cannot purchase it, they can pull it off the Internet, as it is also available as freeware. It is true that this area is in flux and that the rules will be changing; but its very tenuous state has required us to do quite a bit of research to navigate our security policies appropriately.

Example 2: Setting up an international office

Our second example centered around our creation of a full-service office with trading and sales and investment banking transactions in Frankfurt. In this case, the local requirements for establishing the office from a security perspective were well documented by the German regulators. Nonetheless, quite a bit of coordination was required to set up the office to fulfill the German government's objectives as well as GS's business objectives.

The German regulations are intended to protect the privacy of information and center upon how the processing environment should accomplish that intent. When we set up our Frankfurt office our business objective centered upon a need to manage our processing environment efficiently. It was clearly preferable from our perspective to operate our processing within our London data center rather than from a stand-alone unit in Frankfurt.

In order to fulfill both the German government's and Goldman Sachs' business objectives, we had to implement security solutions that were slightly different from those deployed at other locations. We did this through the following steps:

1. We installed a hardware encryption device between the London and Frankfurt internal network links in order to comply with the cross border encryption requirements (and yes we had to receive permission from the State Department to deploy that encryption device in our international offices).

2. We deployed Sun's "C2" security on our servers in order to produce logs of all activity on the relevant servers. Those logs are now reviewed on a daily basis by someone in our internal audit department in our Frankfurt office.

The design and implementation of the Frankfurt office required knowledge of the German regulations, a slight redesign of our encryption methodology for our internal network, and the implementation of policies and procedures to monitor loads as well as the engagement of an external auditor to assess our environment for compliance with the German regulations.

Neither of these examples was impossible to work through, and their significance lies primarily in their illustration that the implementation of a global network and strategy requires constant attention to external requirements as well as business requirements. They also highlight the effort it requires to research and correctly comply with the various local requirements for managing cross-border software and data transfer.

The next area I would like to focus on revolves around the security issues that have resulted from streamlining the firm's internal information and workflows. These changes highlighted the need to establish application standards and to move toward common directory services across platforms for authentication and authorization by business function.

In the process of developing full service offices in most major financial centers, we have also been changing how the firm manages its information and workload. Real-time networks and processors of information have enabled the business and support units to organize their workloads to create a virtual 24-hour day, where the business cycles are defined by their needs as opposed to a physical location, batch window, or arbitrary technology-created restrictions. It is not uncommon today to have trading and sales teams that span the globe, as well as securities processing units that are managing settlements and client servicing areas based upon time zone efficiencies rather than the original transaction's location.

This flexibility, though much more efficient, presents much more risk from an internal security perspective. In the past, we knew that if users did not practice careful login and password management, the fragmentation of our information flow and workload would naturally bring more cross-checks into the system. Dual keying did have its benefits. With a more streamlined flow and management of a transaction's life cycle in multiple locations, it is critical to assure that only the appropriate individuals have access to the transaction. We have concluded that we need to permission the individual across all functions he is allowed to perform and be capable of enabling management to easily audit what functions he has been permissioned to perform. This is currently very difficult, as the various systems we operate do not share a common directory. We are now deeply involved in a fairly large security infrastructure effort to create and enforce this directory; our emphasis will be on simplifying the authorization process and hence encouraging explicit permissioning of individuals to perform specific functions by transaction type.

In order to move in this direction, we have had to create a universal directory database that can be easily populated by the appropriate systems and easily accessed by applications developed in house as well as by vendors. We have chosen to comply with the emerging Microsoft-backed LDAP (lightweight directory access protocol) for APIs to get at the information. We have decided to move forward aggressively on the implementation of the directory as opposed to waiting for vendors to implement it. We resolved this as it is a long process to migrate the various applications into this environment. The security group's role in this process is to support and create the database, integrate it with the emerging LDAP standards, and coordinate its implementation as a standard into all of the application and engineering groups.

As our workflows have changed, we have added risk assessment steps prior to design and implementation. This has led to a recognition that different authentication/authorization practices are appropriate for different functions. Along with better directory services and monitoring, we have implemented more sophisticated authentication techniques for those functions that warrant the additional level of security. We have chosen to move toward a "security token" environment for our payment authorization systems, as well as for mobile computing and external access to our internal systems. Just as in the directory services implementation, the security group has needed to act as technology implementers and internal consultants to encourage the application groups to uniformly use the proper authentication and authorizations procedures.

It is important to note that no matter how cleanly our security technology is implemented, it clearly can be easily broken if the business areas are not setting up their workflows and policies and procedures around areas where the security risks in their flows exist. We have embedded that accountability within the organization responsible for the business function, and we perform security audits against those procedures. For our higher-risk business flows, we regularly retain outside firms to perform security audits.

A third security focus has been on the need for external access of information within the firm's internal network: mobile computing and client access.

We have been fairly conservative in permissioning access to information for mobile computing. We have tended to restrict access fairly narrowly to market information, email, and documents. The business pressure to expand this access is continuing, and we are in the process of developing our infrastructure to support this increased access. This is a complicated area in that it leads to the requirement to diligently authenticate and audit who is accessing the system, since location is meaningless.

On a mundane level it has been complicated because we have asked users who desire access to utilize a security token methodology that is slightly different from the process they use for accessing information from some location within the firm. More difficult has been the effort to establish strong firewalls to prevent unauthorized access to the firm's information. We have tended to be fairly conservative in permissioning access to the

firm's information, since we feel that the remote access technology is very much in flux and we prefer to curb its use until it is more mature. We are very interested in the emerging public/private key technology, as it is built into digital certificates that will enable a strong encryption method as well as strong authentication through the same technology. Once again, this is an evolving standard and we are juggling our external access policies until it permeates the marketplace.

The last major area of security focus that I wanted to highlight today is the increased demand to provide timely open access of information to our clients. The access capabilities being unleashed through the phenomenal expansion of web technology is significantly influencing our focus on strengthening and examining our security infrastructure. It's important for us to have these capabilities to serve our client base, but they require careful consideration of the appropriate encryption, authentication, authorization, and auditing software and procedures. Authorizing access requires the same type of techniques as mobile computing, and it involves the same drawbacks and challenges.

Role of the Security Organization

Before concluding, I would like to spend a minute on the role of the security organization. We have tried to define the role and governance of the security group around the business and technical characteristics that we described previously.

Organizational Structure:

Global team with security officer/technicians in London, New York, Tokyo, and Hong Kong

Direct accountability for password monitoring and login administration across all platforms

Direct accountability for Master Directory that drives user authorization and authentication for email, Kerberos, fax, and in-house applications

Direct accountability for security of overall environment (though not always accountable for implementation), relying heavily on other engineering areas within the IT organization. In fulfilling this responsibility, the group assists in providing consulting services to engineering and application organizations through their development cycles. It also sets security standards and performs security audits against those standards.

We have found that the group's dual consulting and policy-setting role is critical to assure that systems are being implemented and maintained effectively; this role is far more important than that of playing exclusively an auditing and operational function.

Conclusion

I was advised that one of the primary goals of this symposium was to stress the importance of creating careful security processes and policies. If nothing else, I hope my discussion has confirmed the emphasis Goldman Sachs places on this area as well as its inherent complexity. As I stated at the beginning of this discussion, the question of security has begun to influence all of the strategic technical directions we take.

By continuing to use our site, you agree to our Terms of Use and Privacy Statement. You can learn more about how we use cookies by reviewing our Privacy Statement.   Close