Skip to main content

Resources

FFIEC IS Booklet – Focus on Security Operations

FFIEC IS Booklet – Focus on Security Operations

One of the most important and anticipated components of the FFIEC’s recent update to the Information Security Booklet involves an area that has been lacking in FFIEC guidance for some time: Incident Response. For essentially the first time, the FFIEC outlines major components around Incident Response in the Security Operations section of the Information Security Booklet. The Security Operations section provides financial institutions four (4) major components to include in a documented Incident Response Plan:

A. Threat Identification and Assessment
B. Threat Monitoring
C. Incident Identification and Assessment
D. Incident Response

Security Operations requires a financial institution to document processes and appropriate governance around Security Operations activities, report security incidents, determine escalation triggers, and document response actions. An issue tracking system should be used to log evidence, to serve as a repository of current and historical security information, and to assist management. Management should coordinate Security Operations across all lines of business with a goal to ensure there is sufficient security capability across the entire institution.


 

A.  Threat Identification and Assessment

Threat identification and assessment involves understanding current threats and vulnerabilities and analyzing the potential for exploitation. Threat identification and assessment should be used in risk management processes to drive decisions around protective and detective controls and strategies. 
 
Management should develop procedures for obtaining, monitoring, assessing, and responding to evolving threat and vulnerability information. Examples include FS-ISAC, US-CERT, other industry sources, third parties, or from within the institution.
 
Tools for analyzing vulnerabilities may include attack trees, event trees, and kill-chains; all of which may be new terms to many institutions. Attack and event trees are conceptual diagrams that show how an asset or target may be attacked. A kill-chain was originally a military concept for identifying the structure of an attack. Once one can identify the attack, one can determine where and how to stop the attack or potentially even counter-attack. There is obvious applicability to a cyber-attack as well.

Attack Tree and Kill Chain Examples

 


 

B.  Threat Monitoring

Threat monitoring addresses the continued ongoing monitoring of institution systems and networks for indicators of vulnerabilities, attacks, compromised systems, suspicious users, or users not in compliance with security policies. Management should assign and give proper authority to security personnel and system administrators for monitoring the institution’s threat environment. Independent monitoring of administrators and other users with escalated privileges should be established and documented.

 

C.  Incident Identification and Assessment

While Threat Identification and Monitoring encompasses keeping an eye out for the things that can cause harm to the institution, Incident Identification and Assessment focuses on indications of network compromise. 
 
Incident Identification and Assessment should include the following areas:
 
  1. Incident Identification is the process of determining whether or not a compromise has taken place. Indicators of compromise may be internal or external. Some organizations have deployed “hunt teams” dedicated to compromise identification. Processes for identifying indicators of compromise and reporting should be documented. 
  2. Incident Classification should classify the incident based on the level of incident severity and identifying appropriate response actions and personnel based on the incident severity. In addition to incident classification, escalation procedures should be established to determine the process of an incident that progresses in severity. 
  3. Incident Escalation should address at which point different personnel within the institution are contacted and identify the responsibilities of those personnel during the incident analysis and response processes. Escalation procedures should also include the use of external assistance, information, or expertise to resolve an incident, such as digital forensics. 
  4. Incident Reporting should address internal and external reporting, including coordination with third parties, law enforcement, regulatory agencies, or other external organizations. 
This section focuses heavily on identifying the indicators of a network compromise. Examples of technology-based compromise indicators include unexpected:
  • Processes
  • Changes to files
  • Packet source or destination
  • Protocols
  • Ports
  • Encryption
  • Log-ins
  • Packet content

The Incident Identification and Assessment section also lists out potential technology-based intrusion identification tools including IDS/ISP, DLP, malware detection, and network behavior analysis systems, among others.


 

D. Incident Response

Management must document a formal Incident Response Program that defines the institution’s protocols for declaring, responding to, and recovering from an identified incident. The Incident Response Program should be integrated into the institutions existing policies, procedures, and training. 

The Incident Response Program should include procedures for:

  • Under what circumstances to invoke the Incident Response Plan
  • How to notify proper personnel
  • When to involve third party expertise and assistance
  • Coordinating with law enforcement and third parties
  • Notification procedures for regulators, customers, and law enforcement
  • Documentation and maintenance of evidence
    • Containing the incident
    • Isolation of compromised systems or enhanced monitoring of intruder activities
    • Identification of additional compromised systems
    • Collection and preservation of data and evidence
  • Determining system restoration priority (which systems should be kept online and which should be taken offline or disconnected)
  • Responsibilities and authorities for performing specific actions regarding the containment of the incident and restoration of systems
  • Restoration and follow-up
    • Elimination of intruder’s access or attack vector
    • Restoration of systems, programs, and data to a known safe state
    • Monitoring to detect similar or further incidents
  • Providing Assistance to customers
  • Facilitating operational resilience of the institution
  • Criteria to be met before compromised systems, equipment, and software may be returned to the network
  • Filing a Suspicious Activities Report (SAR)
  • Incident follow-up activities to improve the Incident Response Plan
    • Lessons-learned
    • Testing results
    • Actual incident results and documentation

The Incident Response Plan should be tested to ensure adequacy and to improve the plan. Testing methods include:

  • Scenario Planning
  • Tabletop Testing
  • Functional Testing
  • Participation with outside entity (vendors, FS-ISAC) IRP testing activities

Institutions may consider the creation of a Security Incident Response Team (SIRT). A SIRT is typically tasked with performing, coordinating, and supporting responses to security incidents and intrusions. The SIRT may include internal employees with a range of backgrounds and expertise from different areas of the institution, or components of the SIRT may be outsourced to an external party (i.e. digital forensics).


 

Plan to Fail Well

Crisis Ahead SignThe Information Security Booklet’s Security Operations section does a solid job of outlining processes that your regulators will use to evaluate your Incident Response Plan. It’s the first significant guidance around Incident Response that covers more than “incident notification.” There is more to Incident Response than is contained in this booklet (see industry best-practices), and more than we can fit in this short article (see the actual IS Booklet for more detail), but it’s certainly moving Incident Response in the right direction.

At SBS, we like to call the Incident Response Planning process “planning to fail well.” Bad things are going to happen; it’s inevitable. Make sure your institution has a plan in place to respond, recover, and improve from today’s cyber threats.

If you are looking for some additional details on Incident Response and what you can do to protect yourself, the SBS Institute has developed a specialized certification program on incident response: the Certified Banking Incident Handler. Click here to check out all of the SBS Institute certification programs.

 


JonWaldmanWritten by: Jon Waldman, CISA, CRISCPartner - Secure Banking Solutions
Vice President of Business Development - SBS Institute

 


Hacker Hour webinars are a series of free webinars hosted by SBS CyberSecurity. Unlike paid webinars, Hacker Hours are aimed to meet on a monthly basis to discuss cybersecurity issues and trends in an open format. Attendees are encouraged to join the conversation and get their questions answered. SBS will also offer products and services to help financial institutions with these specific issues.

Posted: Wednesday, October 26, 2016
Categories: Blog