Action Summary

Information Security Strategy

An information security strategy is a plan to mitigate risks while complying with legal, statutory, contractual, and internally developed requirements.  Typical steps to building a strategy include the definition of control objectives, the identification and assessment of approaches to meet the objectives, the selection of controls, the establishment of benchmarks and metrics, and the preparation of implementation and testing plans.

The selection of controls is typically grounded in a cost comparison of different strategic approaches to risk mitigation.  The cost comparison typically contrasts the costs of various approaches with the potential gains a financial institution could realize in terms of increased confidentiality, availability, or integrity of systems and data.  Those gains could include reduced financial losses, increased customer confidence, positive audit findings, and regulatory compliance.  Any particular approach should consider: (1) policies, standards, and procedures; (2) technology design; (3) resource dedication; (4) training; and (5) testing. 

For example, an institution’s management may be assessing the proper strategic approach to the security monitoring of activities for an Internet environment.  Two potential approaches are identified for evaluation.  The first approach uses a combination of network and host sensors with a staffed monitoring center.  The second approach consists of daily access log review.  The former alternative is judged much more capable of detecting an attack in time to minimize any damage to the institution and its data, albeit at a much greater cost.  The added cost is entirely appropriate when customer data and institution processing capabilities are exposed to an attack, such as in an Internet banking environment.  The latter approach may be appropriate when the primary risk is reputational damage, such as when the only information being protected is an information-only Web site, and the Web site is not connected to other financial institution systems.

Key Concepts

Security requires the integration of people, process, and technology.   Each of the three components should be managed considering the capabilities and limitations of the other components.  When the components are considered in total, they should provide for adequate overall risk mitigation.

Security strategies include prevention, detection, and response, and all three are needed for a comprehensive and robust security framework.  Typically, security strategies focus most resources on prevention.  Prevention addresses the likelihood of harm. Detection and response are generally used to limit damage once a security breech has occurred.  Weaknesses in prevention may be offset by strengths in detection and response.

Security strategies should establish limitations on access and limitations on the ability to perform unauthorized actions.  Those limitations derive from concepts known as security domains, least permissions, and least privileges.

The creation of security domains involves designing a network so that users and network resources are grouped in a logical or physical manner, and control sets are established to mitigate the risks relevant to each individual domain.  At the network level, connectivity between network areas may be disabled, or tightly controlled through perimeters.  Tools could include firewalls, virtual local area networks (VLANs), router access control lists (ACLs), and directories.  The tools allow for restrictions on access and authorizations at the network and application layers.

The concepts of least permissions and least privileges are used to provide functionality while limiting potentially harmful actions.  They generally involve restricting authorizations at the network, server, and client level. For example, a user could be allowed access to only certain network resources and denied access to others.  A user could be allowed access to some program functions or file areas and not allowed access to others.  A program could be allowed access to some of a computer’s or network’s resources and disallowed access to others.  Authorization for users most often is managed by assigning a user to a group, and granting permissions to the group.

Financial institutions should design multiple layers of security controls to establish several lines of defense between the attacker and the asset being attacked.  The layers should be at multiple control points throughout the communication and transactional flow and should include both systems and manual processes. To successfully attack an asset, each layer must be penetrated.  With each penetration, the probability of detecting the attacker increases.

Architecture Considerations

Financial institutions can gain valuable insights into the development of a security architecture and the integration of that architecture into their other technology processes by referencing one or more widely recognized technology standards.  Examples of the standards include

• Control Objectives for Information and Related Technology (CobiT) – provides a broad and deep framework for controls.
• IT Infrastructure Library (ITIL) – provides a list of recognized practices for IT service management.
• ISO 17799 – provides a library of possible controls that can be included in an architecture and guidance in control selection.
• BITS (Bank Information Technology Secretariat) and other industry publications for discrete controls, such as vendor management.

Primary considerations in a network security architecture are the policies, standards, and procedures employed as a part of the governance structure and the technology design.  Other considerations are the necessary resources, personnel training, and testing.  Each should be appropriate for the size and complexity of the institution and sufficiently flexible to allow for timely and necessary updates to keep pace with changes in technology and the overall environment. 

Policies and Procedures

Policies are the primary embodiment of strategy, guiding decisions made by users, administrators, and managers and informing those individuals of their security responsibilities.  Policies also specify the mechanisms through which responsibilities can be met, and provide guidance in acquiring, configuring, and auditing information systems.

Key actions that contribute to the success of a security policy are

• Implementing through ordinary means, such as system administration procedures and acceptable-use policies;
• Enforcing policy through security tools and sanctions;
• Delineating the areas of responsibility for users, administrators, and managers;
• Communicating in a clear, understandable manner to all concerned;
• Obtaining employee certification that they have read and understood the policy;
• Providing flexibility to address changes in the environment; and
• Conducting annually a review and approval by the board of directors.

Institutions are required to establish an information security program that meets the requirements of the 501(b) guidelines.  Information security polices and procedures are some of the institution’s measures and means by which the objectives of the information security program are achieved.

Technology Design

A financial institution can significantly mitigate the risk of security events by an appropriate technology design that provides for effective network-level monitoring, limits an intruder’s ability to traverse the network, offers the minimum level of services required for business needs, and is updated in a timely manner to mitigate newly discovered vulnerabilities.

An effective means of accomplishing those goals is through the use of security domains.  A security domain is a part of the system with its own policies and control mechanisms.  Security domains for a network are typically constructed from routing controls and directories.

Domains constructed from routing controls may be bounded by network perimeters with perimeter controls. The perimeters separate what is not trusted from what may be trustworthy.  The perimeters serve as well-defined transition points between trust areas where policy enforcement and monitoring takes place.  An example of such a domain is a demilitarized zone (DMZ), bounded by a perimeter that controls access from outside and inside the institution.

Domains constructed from directories may limit access to network resources and applications based on role or function.  Directory-driven domains may allow access to different network-driven domains.  For example, a network management domain may use the same cabling and network interface cards as other domains, allow access to all computing devices in all domains, but limit the allowed access based on the user’s role or function.

The selection of where to put which control is a function of the risk assessment.  Institutions generally should establish defenses that address the network and application layers at external connections, whether from the Internet or service providers. Internally, perimeters can be established at higher-risk security domains, such as wire transfer, and to segregate at a network level those areas of the institution that work with customer information from other areas.  Internal perimeters also may be used to create security domains based on geography or other logical or physical separations.

Hosts may also include security perimeters. Those perimeters are enforced through authorizations for users and programs.  The authorizations can be a part of applications, the file system, and the operating system. 

Outsourced Security Services

Security services may be outsourced to obtain greater expertise, a greater range of services, or to decrease cost.  Should security services be outsourced, the institution retains the same responsibilities for security as if those services were performed in-house.  The “Outsourcing Technology Servicing” booklet in the FFIEC IT Examination Handbook, provides additional information relevant to outsourcing.

Institutions should ensure they have sufficient expertise to oversee and manage an outsourced security service relationship.  The expertise applied to monitor the outsourced security service relationship should be both contract-related, and security-related.  The contract-related oversight addresses contract compliance.  The security-related oversight entails understanding the scope and nature of the service sufficiently to identify and appropriately react when the services provided are not at the level indicated in the service level agreement, no longer appropriately coordinate with the security controls at the institution, or no longer provide the risk mitigation desired.

Institutions should monitor outsourced security service providers appropriate to the level of risk to ensure the service provider fulfills its responsibilities.  Monitoring tools include reports from the service provider, independent reviews of the service provider’s performance, and independent tests of the service provided.