TraceRiskSecurity

Security

Debit Cards

Use Case for Assessing Risk on Debit Cards

Why assess the risk?   Online debit cards use a PIN for customer authentication and online access to account balance information. At present, financial institutions authenticate customers by matching the PIN with the account number directly through a merchant’s terminal. Banks engaged in retail payment systems should establish an appropriate risk management process that identifies, measures, monitors, and limits risks. Management and the board should manage and mitigate the identified risks through effective internal and external audit, physical and logical information security, business continuity planning, vendor management, operational controls, and legal measures. Risk management strategies should reflect the nature and complexity of the institution’s participation in retail payment systems, including any support they offer to clearing and settlement systems. Management should develop risk management processes that capture not only operational risks, but also credit, liquidity, strategic, reputational, legal, and compliance risks, particularly as they engage in new retail payment products and systems.  Management should also develop an enterprise wide view of retail payment activities due to cross-channel risk. These risk management processes should consider the risks posed by third-party service providers.
Who should assess the risks? Electronic Banking Officer, Operations Administrator, Cash Management/ACH Officer, Chief Financial Officer, Information Technology Officer, Data Security Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.

 

TraceRisk Demo Button

Correspondent Bank Concentrations

Use Case for Assessing Risk on Correspondent Bank Concentrations

Why assess the risk? Financial institutions should implement procedures for identifying correspondent concentrations so that there is no over-reliance on or disproportionate deposit balance at a single depository bank. For prudent risk management purposes, these procedures should encompass the totality of the institution’s aggregate credit and funding concentrations to each correspondent on a standalone basis, as well as taking into account exposures to each correspondent organization as a whole. In addition, the institution should be aware of exposures of its affiliates to the correspondent and its affiliates.

Who should assess the risks? Chief Financial Officer, Controller, Accounting Mgr., Chief Operating Officer, ALCO

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.
TraceRisk Demo Button


Assessing Risk on Cybersecurity

Use Case for Assessing Risk on Cybersecurity

Why assess the risk? Banks must create, provision, and operate a formal incident response capability and report all incidents consistent with an incident response policy. Establishing an incident response capability should include the following actions:

  • Creating a cybersecurity incident response policy and plan
  • Developing procedures for performing incident handling and reporting
  • Setting guidelines for communicating with outside parties regarding incidents
  • Selecting a team structure and staffing model
  • Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)
  • Determining what services the incident response team should provide
  • Staffing and training the incident response team

Banks should reduce the frequency of incidents by effectively securing networks, systems and applications.Preventing problems is often less costly and more effective than reacting to them after they occur. Thus, incident prevention is an important complement to an incident response capability. If security controls are insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for response, which would result in delayed or incomplete recovery and possibly more extensive damage and longer periods of service and data unavailability. Incident handling can be performed more effectively if organizations complement their incident response capability with adequate resources to actively maintain the security of networks, systems, and applications. This includes training IT staff on complying with the bank’s security standards and making users aware of policies and procedures regarding appropriate use of networks, systems, and applications.

Banks should document their guidelines for interactions with other organizations regarding incidents. During incident handling, the bank will need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and victim organizations. Because these communications often need to occur quickly, banks should predetermine communication guidelines so that only the appropriate information is shared with the right parties.

Banks should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors. Incidents can occur in countless ways, so it is not feasible to develop step-by-step instructions for handling every incident. Different types of incidents merit different response strategies. The attack vectors are:

  • External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a peripheral device
  • Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks or services
  • Web: An attack executed from a website or web-based application
  • Email: An attack executed via an email message or attachment
  • Improper Usage: Any incident resulting from violation of a bank’s acceptable usage policies by an authorized user, excluding the above categories
  • Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop or smartphone.
  • Other: An attack that does not fit into any of the other categories.

Banks should emphasize the importance of incident detection and analysis throughout the organization. In a bank, millions of possible signs of incidents may occur each day, recorded mainly by logging and computer security software. Automation is needed to perform an initial analysis of the data and select events of interest for human review. Event correlation software can be of great value in automating the analysis process. However, the effectiveness of the process depends on the quality of the data that goes into it. Banks should establish logging standards and procedures to ensure that adequate information is collected by logs and security software and that the data is reviewed regularly.

Banks should create written guidelines for prioritizing incidents. Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Effective information sharing can help an organization identify situations that are of greater severity and demand immediate attention. Incidents should be prioritized based on the relevant factors, such as the functional impact of the incident (e.g., current and likely future negative impact to business functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and availability of the bank’s information), and the recoverability from the incident (e.g., the time and types of resources that must be spent on recovering from the incident).

Banks should use the lessons learned process to gain value from incidents. After a major incident has been handled, the bank should hold a lessons learned meeting to review the effectiveness of the incident handling process and identify necessary improvements to existing security controls and practices. Lessons learned meetings can also be held periodically for lesser incidents as time and resources permit. The information accumulated from all lessons learned meetings should be used to identify and correct systemic weaknesses and deficiencies in policies and procedures. Follow-up reports generated for each resolved incident can be important not only for evidentiary purposes but also for reference in handling future incidents and in training new team members.

Who should assess the risks? Information Technology Officer, Data Security Officer, Electronic Banking Officer, Operations Administrator, Cash Management/ACH Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.

Schedule a Demo

Automated Clearinghouse (ACH)

Use Case for Assessing Risk on Automated Clearinghouse (ACH)

Why assess the risk? Banks that participate in the ACH network, as well as their service providers, should have in place systems and controls to mitigate the risks associated with ACH activities. A strong risk management program begins with clearly defined objectives, a well-developed business strategy, and clear risk parameters. Both the board of directors and management are responsible for ensuring that the ACH program does not expose the bank to excessive risk. The board’s role is to establish the bank’s overall business strategy and risk limits for the ACH program and to oversee management’s implementation of the program. Bank management is responsible for establishing effective risk management systems and controls and regularly reporting to the board on the results of the ACH program. The bank’s ACH program should include an ongoing process that evaluates whether ACH activities are conducted within the risk parameters established by the board of directors. This process should also determine whether existing policies, procedures, and controls effectively address all aspects of the bank’s ACH activities.

Who should assess the risks? Electronic Banking Officer, Chief Operating Officer, Cash Management Officer, Information Technology Officer, Security Officer, Data Security Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.
Special Note: NACHA provides its own risk assessment which is very specific to the types of customers and transactions handled by the member bank. Tracerisk users are encouraged to perform the NACHA risk assessment as well.  


Assessing Risk on Cybersecurity

Use Case for Assessing Risk on Cybersecurity

Why assess the risk? Banks must create, provision, and operate a formal incident response capability and report all incidents consistent with an incident response policy. Establishing an incident response capability should include the following actions:

  • Creating a cybersecurity incident response policy and plan
  • Developing procedures for performing incident handling and reporting
  • Setting guidelines for communicating with outside parties regarding incidents
  • Selecting a team structure and staffing model
  • Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)
  • Determining what services the incident response team should provide
  • Staffing and training the incident response team

Banks should reduce the frequency of incidents by effectively securing networks, systems and applications. Preventing problems is often less costly and more effective than reacting to them after they occur. Thus, incident prevention is an important complement to an incident response capability. If security controls are insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for response, which would result in delayed or incomplete recovery and possibly more extensive damage and longer periods of service and data unavailability. Incident handling can be performed more effectively if organizations complement their incident response capability with adequate resources to actively maintain the security of networks, systems, and applications. This includes training IT staff on complying with the bank’s security standards and making users aware of policies and procedures regarding appropriate use of networks, systems, and applications.

Banks should document their guidelines for interactions with other organizations regarding incidents. During incident handling, the bank will need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and victim organizations. Because these communications often need to occur quickly, banks should predetermine communication guidelines so that only the appropriate information is shared with the right parties.

Banks should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors. Incidents can occur in countless ways, so it is not feasible to develop step-by-step instructions for handling every incident. Different types of incidents merit different response strategies. The attack vectors are:

  • External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a peripheral device
  • Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks or services
  • Web: An attack executed from a website or web-based application
  • Email: An attack executed via an email message or attachment
  • Improper Usage: Any incident resulting from violation of a bank’s acceptable usage policies by an authorized user, excluding the above categories
  • Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop or smartphone.
  • Other: An attack that does not fit into any of the other categories.

Banks should emphasize the importance of incident detection and analysis throughout the organization. In a bank, millions of possible signs of incidents may occur each day, recorded mainly by logging and computer security software. Automation is needed to perform an initial analysis of the data and select events of interest for human review. Event correlation software can be of great value in automating the analysis process. However, the effectiveness of the process depends on the quality of the data that goes into it. Banks should establish logging standards and procedures to ensure that adequate information is collected by logs and security software and that the data is reviewed regularly.

Banks should create written guidelines for prioritizing incidents. Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Effective information sharing can help an organization identify situations that are of greater severity and demand immediate attention. Incidents should be prioritized based on the relevant factors, such as the functional impact of the incident (e.g., current and likely future negative impact to business functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and availability of the bank’s information), and the recoverability from the incident (e.g., the time and types of resources that must be spent on recovering from the incident).

Banks should use the lessons learned process to gain value from incidents. After a major incident has been handled, the bank should hold a lessons learned meeting to review the effectiveness of the incident handling process and identify necessary improvements to existing security controls and practices. Lessons learned meetings can also be held periodically for lesser incidents as time and resources permit. The information accumulated from all lessons learned meetings should be used to identify and correct systemic weaknesses and deficiencies in policies and procedures. Follow-up reports generated for each resolved incident can be important not only for evidentiary purposes but also for reference in handling future incidents and in training new team members.

Who should assess the risks? Information Technology Officer, Data Security Officer, Electronic Banking Officer, Operations Administrator, Cash Management/ACH Officer

How to assess the risk: Rate the KRIs to determine if a threat would successfully exploit a vulnerability and to justify expenditures to implement countermeasures to protect the bank’s assets or reputation. Use the “Focus Risk Assessment” tool for in-depth analysis of risks and mitigation techniques.