2023 IT Examiner School

IT Examiner School

Ju ly 18-27 , 2023 Live Virtual

@ www.csbs.org � @csbsnews

CONFERENCE OF STATE BANK SUPERVISORS 1 300 I Street NW / Suite 700 / Washington, DC 20 005 / (202) 296-2840

IT Examiner School Live Virtual July 18-27, 2023

Week 1 Tuesday, July 18, 2023 12:30 pm – 1:30 pm

Introduction & Pre-Course Review/Terminology

Regulations/Guidance

1:30 pm – 2:15 pm

Break

2:15 pm –2:30 pm

IT Examination Work Programs

2:30 pm – 3:00 pm

Audit

3:00 pm – 4:00 pm

Wednesday, July 19, 2023 12:30 pm – 12:45 pm

Prior Day Review

Audit (continued)

12:45 pm – 1:30 pm

Risk Assessment

1:30 pm – 2:00 pm

Break

2:00 pm – 2:15 pm

Risk Assessment (continued)

2:15 pm – 2:45 pm

Development & Acquisition

2:45 pm – 4:00 pm

Thursday, July 20, 2023 12:30 pm – 12:45 pm

Prior Day Review

Third-Party Risk

12:45 pm – 1:30 pm

Support & Delivery

1:30 pm – 2:30 pm

Break

2:30 pm – 2:45 pm

Support & Delivery (continued

2:45 pm – 4:00 pm

Week 2 Tuesday, July 25, 2023 12:30 pm – 1:00 pm

Prior Day Review

Cybersecurity – FFIEC CAT Tool

1:00 pm – 2:00 pm

Break

2:00 pm – 2:15 pm

Business Continuity Planning/Disaster Recovery (BCP/DR)

2:15 pm – 4:00 pm

Wednes day, July 26, 2023 12:30 pm – 12:45 pm

Prior Day Review

Management

12:45 pm – 2:00 pm

Break

2:00 pm – 2:15 pm

Management

2:15 pm – 2:45 pm

Composite Rating Discussion & Exercise

2:45 pm – 3:15 pm

Breakout Rooms

3:15 pm – 4:00 pm

Thursday , July 27, 2023 12:30 pm – 1:30 pm

Composite Rating Exercise Discussion

Emerging Issues

1:30 pm – 2:00 pm

Break

2:00 pm – 2:15 pm

Emerging Issues (continued)

2:15 pm – 3:30 pm

Final Assessment & Course Wrap Up

3:30 pm – 4:00 pm

Virtual IT Examiner School

Zoom

Schedule This week:

• Tuesday, July 18: 12:30 PM – 4:00 PM ET • Wednesday, July 19: 12:30 PM – 4:00 PM ET • Thursday, July 20: 12:30 PM – 4:00 PM ET Next Week • Tuesday, July 25: 12:30 PM – 4:00 PM ET • Wednesday, July 26: 12:30 PM – 4:00 PM ET • Thursday, July 27: 12:30 PM – 4:00 PM ET

NYS DFS Disclaimer The views expressed are those of the speaker and do not represent the official views of New York State or the NYS Department of Financial Services, aka DFS. Anything said during this training shall not bar, estop, or otherwise prevent DFS, or any federal or other state agency from taking any action different from anything said during this training. Participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.

Introductions

Name

State

IT Exam Experience

Fun fact

Something you hope to learn

Go to www.menti.com and enter Game PIN provided

Regulations & Guidance

The Gramm Leach Bliley Act (GLBA) - 1999 Title V, Subtitle A of the Gramm-Leach-Bliley Act (“GLBA”) governs the treatment of nonpublic personal information (NPPI or NPI ) about consumers by financial institutions. • Section 501 – protection of nonpublic personal information

"It is the policy of the Congress that each financial institution has an affirmative and continuing obligation to respect the privacy of its customers and to protect the security and confidentiality of those customers’ nonpublic personal information" (Section 501(a))

• Section 502 – prohibits financial institutions from disclosing nonpublic personal information about a consumer to non-affiliated third parties, unless (i) the institution satisfies various notice and opt-out requirements; and (ii) the consumer has not elected to opt out of the disclosure • Section 503 - institutions to provide notice of its privacy policies and practices to its customers 501(b) requires each agency or authority to establish appropriate standards for the financial institutions subject to their jurisdiction relating to administrative, technical, and physical safeguards: 1. To ensure the security and confidentiality of customer records and information; 2. To protect against any anticipated threats or hazards to the security or integrity of such records; and 3. To protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.

In 2000, the Board of Governors of the FRS (“Board”), the FDIC, the NCUA, the OCC, and the former OTS, published regulations implementing provisions of GLBA governing the treatment of nonpublic personal information about consumers by financial institutions.

Regulatory Authority Examples: Depository Institutions

Regulators / Licensure FDIC, FRB, OCC, States, CFPB

Laws, Regulations, or Guidance Related to IT, InfoSec, Privacy, etc. 12 CFR 364, Appendix B; Section 501(b) of GLBA; FFIEC; State Laws/Regulations (e.g., Part 500, CCPA)

Type of Entity

Banks (state-member, national, state non-member, credit union)

Bank Holding Companies, Trust Companies, US Branches of FBOs Credit Unions (Federal or State)

FRB, States

Generally, the same as banks (above)

NCUA, States

12 CFR 748 (Appendix A & B)

Regulations & Guidance - FDIC Appendix B, including Supplement, to Part 364 of the FDIC Rules and Regulations – Interagency Guidelines Establishing Information Security Standards

Regulations & Guidance - FRB Appendix D-2, including Supplement, to Part 208 of the FR Rules and Regulations – Interagency Guidelines Establishing Standards for Safeguarding Customer Information

Regulations & Guidance - NCUA Appendix A (“Guidelines for safeguarding member information”) & Appendix B (“Guidance on Response Programs for Unauthorized Access to Member Information and Member Notice”) of 12 CFR 748 (“Security Program”)

Regulatory Authority Examples: Non-Depository Institutions

Regulators / Licensure CFPB, FTC, States

Laws, Regulations, or Guidance Related to IT, InfoSec, Privacy, etc.

Type of Entity

Mortgage Originators and Servicers

16 CFR 314; 501 and 505(b)(2) of GLBA; State Laws and Regulations (e.g., Part 500 and CCPA).

Money Service Businesses / Money Transmitters

FTC, States

Consumer Finance

CFPB, FTC, States

Regulations & Guidance – Non-Depository

16 CFR Part 314 of the FTC Rules and Regulations – “Standards for Safeguarding Customer Information”

• The “Safeguards Rule”, which took effect in 2003, is designed to ensure that covered entities maintain safeguards to protect the security of customer information • It applies to financial institutions subject to FTC jurisdiction and that aren’t subject to enforcement authority of another regulator under Section 505 of the Gramm-Leach-Bliley Act, 15 U.S.C. § 6805. • In December 2021, the FTC amended the Safeguards Rule to keep pace with current technology.

Source: https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know

Regulations & Guidance – Non-Depository Section 314.4 of the Safeguards Rule identifies 9 elements that a company’s ISP must include: • Designate a qualified individual to implement & supervise the InfoSec program • Conduct a risk assessment • Design & implement safeguards to control risk identified by the risk assessment • Regularly monitor & test the effectiveness of those controls • Train staff

• Monitor Service Providers • Keep the program current • Create a written Incident Response Plan • Require the qualified individual to report to the Board

Examination Approach Examples: Depository Institutions

Type of Entity

IT Exam Approaches/Rating Systems

Banks

Information Technology Risk Examination (InTREx); UFIRS/CAMELS, FFIEC Uniform Rating System for IT (URSIT); CAMEL, where “M” includes a review of information systems

Credit Unions

Trust Companies

FFIEC Uniform Interagency Trust Rating System (UITRS)

Foreign Banking Organizations & Bank Holding Companies

FRB, States; ROCA Rating System – where “O” is operational controls

Examination Approach Examples: Non-Depository Institutions

Type of Entity

IT Exam Approaches/Rating Systems

Mortgage Originators and Servicers

FFIEC Uniform Interagency Consumer Compliance Rating System (CC Rating System)

Money Service Businesses / Money Transmitters

CSBS Non-Bank Cybersecurity Exam Program; MTRA Workprogram (multi-state exams); FILMS rating system

Regulations & Guidance

Good reference, but remember the booklet does not specifically apply to FIs not regulated by the FFIEC FFIEC IT Booklet Handbooks:

Your Turn!

Tell us about the exam approaches and/or the rating systems you use regularly.

Do you like using one approach more than the other? If so, please explain briefly?

IT Examination Work Programs

Components of CSBS Nonbank Cyber Exam Programs Pre-Examination Resources Work Programs

Baseline Nonbank Workprogram

Exam Notification Letter

Enhanced Nonbank Workprogram

Pre-Exam Document Request List (DRL)

Pre-Exam Document Request List

Used for the Baseline Nonbank Cybersecurity Exam Program (V1.0) and the Enhanced Nonbank Cybersecurity Exam Program (V1.0)

Covers 15 Different Program Areas and defines specific documents to be provided

Includes space for State specific requests

Nonbank Cybersecurity Exam Programs Baseline

Enhanced • More comprehensive, for larger and more complex institutions • Includes all baseline questions (light blue shading) plus additional questions in areas requiring a deeper dive • Targeted for use by examiners with more specialized knowledge of IT & Cyber

• Based on the pilot program released in December 2020 • Covers same content as pilot in a streamlined version (based on 2021 examiner feedback) • Easier to use and half the questions with no loss of coverage • Covers 4 URSIT component areas

Note: The Baseline and Enhanced Nonbank Cybersecurity Exam Programs were added to SES and are available for mortgage origination, mortgage servicing, and consumer finance exams.

Baseline Nonbank Cybersecurity Exam Program

Source: https://www.csbs.org/sites/default/files/2022-08/Baseline%20Nonbank%20Exam%20Program%20V1.0.pdf

Enhanced Nonbank Cybersecurity Exam Program

Source: https://www.csbs.org/sites/default/files/2022-08/Enhanced%20Nonbank%20Exam%20Program%20V1.0.pdf

Components of InTREx ITP

Work Program

Information Technology Profile

Core Modules

Risk Profile

Expanded Modules

Qualitative Adjustment

Supplemental Workprograms

InTREx Workprogram Core Modules

Support & Delivery

Audit

Management • Risk Assessment • Vendor Management (Ongoing) • Information Security Standards (GLBA) • ID Theft Red Flags

Development & Acquisition • Vendor Management (Acquisition)

• BCP • Information Security • Operations • Incident Response • Network Security (IDS, Firewall) • EFT/E-Banking

InTREx Framework

Based on URSIT components

ED Module concept used for each component

ED Module core decision factors were derived from URSIT assessment factors

InTREx Features Incorporates baseline cybersecurity into procedures Requires conclusion on cybersecurity preparedness Requires conclusion on GLBA Information Security Standards (Part 364 Appendix B) Enhances focus on transaction/control testing

Allows for tracking of deficiencies noted in any decision factor

InTREx Procedures Core Modules Audit, Management, D&A, S&D • All procedures must be completed, but not all bullets need to be addressed • Do have flexibility to scope down, just not scope out

InTREx Procedures

Cybersecurity Workpaper • No stand-alone workprogram • Applicable procedures are marked with • Requires summary comment

InTREx Procedures

Information Security Standards (GLBA) Workpaper • No stand-alone workprogram • Applicable procedures are marked with • Requires summary comment

InTREx Additional Procedures Expanded Modules • Available for Management and S&D • Provide additional procedures for IT products/ services not covered in Core or that may need additional analysis

InTREx Additional Procedures Supplemental Workprograms (ED Modules/FFIEC IT Handbook) • ED Modules available for a variety of areas (EFT, Mobile Banking, Merchant Acquiring, etc.) • FFIEC IT Handbook provides in-depth procedures • FDIC Risk Advisories and Technical Examination Aids provide guidance • Should be completed to assess specific products not covered in the Core or Expanded Modules, or areas of higher complexity that require more in-depth review

InTREx Control Testing

Control Tests • Core Modules identify potential control tests • Control tests are marked with • Use discretion in determining which tests to perform • Not all control tests need to be performed, and conversely, examiners can do own control tests

InTREx Control Testing

Control Tests • If a control test was performed, the results should be noted in the comments to that procedure • May leverage control testing performed by internal and external auditors • Sufficient testing should be performed to validate the effectiveness of controls

Audit

Objectives

Provide tools to assess the effectiveness of the IT Audit Program

IT Audit Component Rating

Types of IT Audits/Reviews

IT Auditor Expertise

IT Audit Scope

Audit/Independent Review

Performed by independent personnel

Documented Findings/ recommendations

Knowledgeable individuals conduct

Risk assessment/ complexity based

IT scope & frequency based on inherent or residual risks

Conducted separately or all at once

Board/Committee reported results

Assessment Areas for IT Audits

• Audit risk assessment, plan and scope • Appropriate coverage of the entity’s IT environment and activities • Quality of written IT reports • Audit independence • Auditor qualifications • Findings and recommendations reporting and follow-up

The IT Audit program should be assessed for the following:

Guidance for IT Audit FFIEC IT Examination Audit Handbook

Federal Agency Rules and Regulations  Interagency Policy Statement on the Internal Audit Function and its Outsourcing  Interagency Policy Statement on External Auditing Program of Banks and Savings Associations  Interagency Guidelines Establishing Information Security Standards (GLBA) Information Systems Audits and Control Association (ISACA)

IT Audit Engagement

Engaged & signed by an individual or committee not responsible for IT operations (preferably signed by a member of the Board or Audit Committee) The scope, timeframes, and cost of work to be performed

Expectations and responsibilities

Institution access to audit workpapers

IT Audit Risk Assessment

Universe of auditable entities

Risk assessment = audits

Reasonable scale

Relevance of controls

Effectiveness of Controls

Inherent risk

The only scale where cyber risk should be rated second lowest

IT Audit Scope

Identifies areas to be reviewed consistent with risk assessment/ risk level

Describes how the audit will be performed and tools to be used

Provides the timeframe for completing the audit

Firms may provide engagement letter specifying this information including costs

Example – Risk Assessment ≠ Audit Scope

Risk Assessment / Audit Schedule

• Network Penetration and Vulnerability Assessment • Wire Transfer Audit • Internet Banking/Social Media Audit • IT Audit • Vendor Management Audit

List of IT Audits

Scope from IT Audit

IT Audit Coverage

IT General Controls

Information Security Program (GLBA)

EFT (ACH/Wires/RDC)

NACHA Compliance

Penetration Testing/ Vulnerability Assessment

Identity Theft Red Flags Program

Regulation GG/Unlawful Internet Gambling Enforcement Act

IT Audit Coverage

Business Continuity Planning

Change/Patch Management

Vendor Management

Cybersecurity

Management

Internet/ Online Banking Network

Third-Party Outsourcing

Disaster Recovery

Strategic Planning

Project Management

Architecture (Firewalls & IDS/IPS)

BIA

Incident Response

GLBA Compliance

Social Engineering

Red Flags/ ID Theft Prevention

Security Monitoring

Written IT Audit Reports

Describe scope & objectives

Identifies deficiencies/ weaknesses

Suggests corrective action(s)

Management’s response/timing for corrective action(s)

Provides information on prior audit findings

• Identifies repeat findings

Complies with audit plan & schedule

Types of IT Audits

Internal Audits/ Certifications

IT General Controls

Penetration Tests

Vulnerability Assessments

Statement on Standards for Attestation Engagements (SSAE-16/18)

IT General Controls (ITGC)

• Logical access controls over infrastructure, applications, and data • System development life cycle controls • Program change management controls • Data center physical controls • System and data back-up & recovery controls • Computer operation controls

ITGC:

ITGCs should be performed annually

Wire Transfer/ACH Audits These services are critical to many financial entities

• Particularly in small to medium community banks, CUs, and MTs Usually included in with ITGC audit • Could occur in financial entities with significant wire/ACH activity • Usually in large community financial entities Can be a separate audit

Vulnerability Assessment vs Penetration Tests High-level comparison: • Vulnerability Assessments identify where facilities or networks are at risk • Penetration Tests subject network(s) to “real life” cyber events internally and externally Both should be performed, at least annually.

Vulnerability Assessments

• Requires specific skills/knowledge • Audit team tries to find weak points • Tools used simulate a variety of attacks • Results are used in Penetration Testing for potential exploitation Testing: • Checking building windows and doors to see if they are secured • Checking if building is susceptible to other events, e.g. natural catastrophes Basic Vulnerability Assessment description:

Vulnerability Assessment vs. Risk Assessment

Assist in mitigating or eliminating vulnerabilities for key resources

Assigning quantifiable value and importance to a resource

Identifying the vulnerability or potential threat(s) to each resource

Cataloging assets and capabilities (resources) in a system

FI will sometimes use vulnerability assessment to aid in completing the risk assessment process

Penetration Test (Pen Test)

Pen Test “tests” systems to find & exploit known vulnerabilities that an attacker could exploit

Determine if there are

Pen Test report will describe any weaknesses as “high”, “medium” or “low”

Require management’s knowledge & consent

Require a high degree of skill to perform

weaknesses and if able to access system functionality and data

Are intrusive as actual “attack” tools are used

Pen Test Strategies

Targeted Testing

External Testing

Internal Testing

mimics an insider attack by an authorized user with standard access privileges (what can happen with a disgruntled employee)

targets externally visible servers or devices (seen by anybody on Internet) to see if they can get into internal systems and how far

performed by the entity’s IT team and external testing team

Pen Test Value Ascertain the likelihood of gaining system access

Detecting vulnerabilities not easily found using standard system protective means Ability of current security methods to detect or repel an attack

Likelihood of exploiting a low-risk vulnerability to gain higher level access

List of vulnerabilities needing patching

Measure of risk for a cyber attack

Additional efforts needed to protect the network(s)/ system(s)

External Technology Service Provider (TSP) Reports

• FFIEC TSP Reports • Public/open section that is available to FI clients • Confidential section is available to regulatory agencies • Service Organization Control (SOC) Reports • AICPA standard for reviews of service providers • A type of control assessment provided to a service providers clients

FFIEC TSP Reports

SOC Reports SSAE 18 SSAE 16 (2011-2016) SAS 70 (pre-2011)

Service Organization Control (SOC) Reports

• SOC I • Focus on internal controls over financial reporting (ICFR) • This is the client’s financial reporting • SOC II • Auditor review of internal controls related to: • Security, Availability, Processing, Integrity, Confidentiality, Privacy • Service provider gets to choose the scope of the review • SOC III • Includes a description of the system and the auditor’s opinion • Most abstract, does not include the results of testing

Three Levels of Service Organization Control (SOC) Reports:

Service Organization Control (SOC) Reports

• Type I • Describes the servicer’s descriptions of controls at a specific point in time • Auditor performs no testing of servicer’s controls attesting to controls based on servicer’s account of controls- no opinion • Type II (preferred) • Includes information from a Type I Report • Detailed testing of the servicer’s controls over a minimum consecutive six-month period • Auditor expresses an opinion based on their testing

Two types of Service Organization Control (SOC) Reports:

Audit Reporting/Follow-up

Similar to Safety & Soundness:

o IT Audit reporting channels  What is being reported and to whom o Senior Management Responses  Are they reasonable and corrective timeframe is appropriate o Exception Tracking  Show all IT audit findings, both Internal and External, and regulatory along with corrective action(s)

Auditor Independence & Qualifications Independence : Whether or not there are conflicting duties, e.g., involved in auditing areas they have responsibilities or oversight Auditor should be reporting to Board or Audit Committee Whether or not the Auditor has a debt with the entity (may have some influence)

Type of IT experience and training • Some IT audits require specific skill sets

Current IT certifications the auditor maintains

List of references from entities with similar IT activities

Qualifications :

These qualifications provide some assurances, but don’t guarantee a quality audit

IT Audit Review

• Audit scope and objectives • Pertinent areas for improvement based on results of testing • Reasonable and appropriate recommendations • Findings and observations consistent with your examination results

Audit Reports include:

Audit Report Review

• Be wary of auditors who rely solely on checklists • Using only regulatory workprograms is not an audit • Absence or lack of workpapers could indicate a poorly performed audit  Especially if there are no workpapers showing how ITGCs were reviewed/tested

Signs of a questionable audit:

Audit Findings Tracking & Resolution

A formal tracking system that assigns responsibility and target date for resolution

Timely and formal status reporting

Tracking and reporting of changes in target dates or proposed corrective actions to the Board or Audit Committee

Process to ensure findings are resolved

Independent validation to assess the effectiveness of corrective measures

Issues & corrective actions from internal audits and independent testing/assessments are formally tracked to ensure procedures and control lapses are resolved in a timely manner.

Auditor Interview Areas to focus on with auditor interview: • Knowledge of the IT environment and risks • Understanding of systems they are reviewing • Understanding of the basic controls (of these systems) • Verify training and/or certifications (as necessary)- certifications require specific training and number of hours/year (usually 40) • Why auditor used a checklist or FFIEC IT work-program and audit work didn’t fit entity’s activity

InTREx - Audit

InTREx – Audit

Audit Component Rating Areas to focus on when rating IT Audit component adequacy:

• Independence and quality of oversight • Audit risk analysis methodology/resources applied • Scope, frequency, accuracy, and timeliness of audit reports • Extent of audit participation in SDLC to ensure effectiveness internal controls and audit trails • Audit plan in providing appropriate coverage of IT risks • IT auditor’s adherence to code of ethics/professional standards • Qualifications of IT auditors • Timely and formal follow-up and reporting on management’s resolution of identified issues/weaknesses • Quality and effectiveness of internal and external audit activity related to IT controls

Conclusion

Learned basics for IT Audits

Minimum scope in risk focused examination process must review the entity’s audit program

If audit program is deficient or lacking • Don’t need to dig deeper • Describe the deficiencies & record in your WP • Notify the Safety & Soundness EIC If audit program is satisfactory • Can risk focus areas recently audited

Summary • Audits are a necessity whether performed by in-house and/or external resources • Must be performed by independent and qualified individuals/companies • Based on a current risk assessment • Must provide written, detailed, stand-alone reports • Results must be reported to the Board’s Audit Committee or a related Board Committee in a timely manner • Audits can aid in exam scope reduction

Internal Use Only

Risk Assessment

Internal Use Only

Risk Assessment Overview • Purpose • Risk Appetite

• Risk Identification • Risk Assessment • Risk Response • Risk Monitoring

Internal Use Only

Why have a Risk Assessment? Helps organizations identify inherent business risks and provide measures, processes and controls to reduce the impact of these risks to business operations • Without a Risk Assessment: • Not in compliance with GLBA (Appendix B of Part 364 of the FDIC Rules and Regulations) • Protection of information assets are not aligned with business objectives or regulatory requirements • Loss (or compromise) of critical information can be catastrophic • Loss of trust between a financial institution and its customers • Harms the safety and soundness of institution

Internal Use Only

Information Security “CIA TRIAD”

• Confidentiality. Only authorized entities, have access to the data. • Integrity. There are no unauthorized modifications of the data. • Availability. Authorized entities can access the data when and how they are permitted to do so.

Internal Use Only

IT & Cyber Risk are Business Risks • IT can provide significant benefits to an enterprise, but it also involves risk • IT provides value to enterprise • IT-related events could potentially impact the business • IT creates challenges in meeting strategic goals and objectives and uncertainty in the pursuit of opportunities • IT goals must align with business goals and objectives (Grow, Run, Change) • IT/Cyber risk is operational risk and should be treated like other key business risks • Other Operational Risks are people, process, external events, legal & compliance • Many executives tend to relegate IT risk to technical specialists outside the boardroom • Transfer responsibility

Internal Use Only

Risk Governance

Board of Directors

Risk Appetite

Senior Management

Risk Reporting

Risk Reporting

Risk Management

Business Units

Risk Guidance

Risk Monitoring

Business Operations & Processes

Internal Use Only

Risk Appetite

Risk appetite is the amount of risk, on a broad level, an organization is willing to accept in pursuit of its mission.

How much risk is an organization willing to accept to achieve its objectives?

Risk appetite is not just a part of risk and risk management discussions, it is a key component in strategic planning and day-to-day decision making.

Internal Use Only

Cycle of IT Governance

Test and Update: • Policies • Procedures • Controls

Identify and prioritize gaps: • Policies • Procedures • Controls

Risk Assessment: • Assets • Threats • Vulnerabilities • Mitigating controls

Internal Use Only

Risk Assessment Types & Methodologies

Internal Use Only

Risk Assessments Process used to identify and understand risks to the confidentiality, integrity, and availability of information and systems. Consists of the identification and valuation of assets and an analysis of those assets in relation to potential threats and vulnerabilities, resulting in a ranking of risks to mitigate. Results are used to develop strategies to mitigate those risks.

Internal Use Only

Types of Risk Assessments

Gramm-Leach-Bliley Act (GLBA) / Information Security

Business Continuity Planning

Audit

Authentication

Encryption, Awareness Training, etc.

Automated Clearing House (ACH)

Cybersecurity

Third Parties

Internal Use Only

Risk Assessment Methodologies

Quantitative

Qualitative

• Based on Judgment • Simple to implement • Flexible, cover all business risks • Quick to identify risks • Subjective/Bias • Delphi technique/expert opinions • Decision trees • Probability/Consequence • Relies on organizational expertise

•Data Driven! •Objective and accurate •Realistic and measurable •Requires data for analysis •More complex = more time •Data can be difficult to collect

Internal Use Only

Risk Assessment Process & Walkthrough

Internal Use Only

Risk Assessment Process

Identify and value information assets

Identify potential internal/external threats and/or vulnerabilities

Assess likelihood & impact of threats/vulnerabilities

Risk Response (Accept, Transfer, Reduce, Ignore)

Assess sufficiency of risk control policies, procedures, information systems, etc.

Internal Use Only

Risk Assessment Process

Identify and value information assets

Identify potential internal/external threats and/or vulnerabilities

Assess likelihood & impact of threats/vulnerabilities

Risk Response (Accept, Transfer, Reduce, Ignore)

Assess sufficiency of risk control policies, procedures, information systems, etc.

Internal Use Only

Identifying Assets Electronic (Network maps, hardware/software, systems, databases, computers, media) Paper-Based (Policies, reports, contracts, financial records)

Outsourcing arrangements Cloud computing

Internal Use Only

Examples of Assets to be Protected

People • Expertise, corporate memory

Hardware • CPU, routers, drives

Software • OS, applications, source code

Data • Database, files, email, backups

Documentation • Loan & deposit documents • Disclosures • Signature cards

Third Parties • Processors • Aggregators

Cloud • AWS • Salesforce • Jira

Internal Use Only

Identifying Asset Sensitivity

Once the assets are identified, their criticality & sensitivity must be valued

It is critical to differentiate the importance of assets so that institutions can assign priorities & appropriate controls

It is the firm’s responsibility to provide definitions for the classifications they use in their risk assessment

Management should be able to define all terms used in the risk assessment

Internal Use Only

Example Bank Topology

Internal Use Only

Risk Assessment: Identification & Valuation

Internal Use Only

Risk Assessment: Identification & Valuation

• Institutions may value assets in a variety of ways. • Asset’s replacement value • Revenue loss • Reputation • Sensitivity of the data, etc. • No right or wrong way, but it makes sense and retain an internal consistency.

Internal Use Only

Risk Assessment Process

Identify and value Information assets

Identify potential internal/external threats and/or vulnerabilities

Assess likelihood & impact of threats/vulnerabilities

Risk Response (Accept, Transfer, Reduce, Ignore)

Assess sufficiency of risk control policies, procedures, information systems, etc.

Internal Use Only

Threats, Vulnerabilities, and Risks

Vulnerability

Risk

Threat

• Any circumstance or event with the potential to adversely impact organizational operations

• Hardware, firmware, or software flaw that leaves an information system open to potential exploitation • Weakness in automated procedures, controls, layout, etc., that could be exploited to gain unauthorized access or disrupt processing

• Level of impact on operations, assets, or individuals given the potential impact of a threat and the likelihood of that threat occurring

Internal Use Only

Types of Threats

Internal Use Only

What are you afraid of?

• Ransomware • Configuration errors • Spear Phishing

• Website Defacement • Social Engineering • Remote access risks • Bring Your Own Device • Third Parties • Employees “insider threats” • Regulators

Internal Use Only

Risk Assessment: Threats & Vulnerability & Risk

Internal Use Only

Risk Assessment Process

Identify and value information assets

Identify potential internal/external threats and/or vulnerabilities

Assess likelihood & impact of threats/vulnerabilities

Risk Response (Accept, Transfer, Reduce, Ignore)

Assess sufficiency of risk control policies, procedures, information systems, etc.

Internal Use Only

Weighing Threats

• Institutions may choose between • Qualitative Assessment • Quantitative Assessment • Combination of both, but Qualitative

• Management may place more weight on one type of threat than another.

• When reviewing the institution's risk values, interact with management if something does not make sense.

Internal Use Only

Risk Assessment: Weighing Threats

Internal Use Only

Risk Assessment Process

Identify and value information assets

Identify potential internal/external threats and/or vulnerabilities

Assess likelihood & impact of threats/vulnerabilities

Risk Response (Accept, Transfer, Reduce, Ignore)

Assess sufficiency of risk control policies, procedures, information systems, etc.

Internal Use Only

Risk Assessment: Risk Response

Internal Use Only

Risk Mitigation is Not Risk Elimination!

• Impossible to eliminate threats 100%

• Risk response is to reduce the impact or consequence of the vulnerability

• Exposure is in line with Risk Appetite

• Board aware and agree to the outcomes

One needs a process to ensure you are implementing countermeasures that actually limit risk.

Internal Use Only

Risk Assessment Process

Identify and value information assets

Identify potential internal/external threats and/or vulnerabilities

Assess likelihood & impact of threats/vulnerabilities

Risk Response (Accept, Transfer, Reduce, Ignore)

Assess sufficiency of risk control policies, procedures, information systems, etc.

Internal Use Only

Risk Assessment: Control Testing

Internal Use Only

Risk Assessment: Control Testing • Assurance testing or self-assessments on controls if documented, demonstrates risk monitoring. • Metrics reporting provides evidence of conformance with policies and procedures. • Independent review to test controls reduce bias, increase capabilities, and increase knowledge about threats and technologies. • Independence gives credibility to the test results. • The reports generated from the tests should be prepared by individuals who similarly are independent.

Internal Use Only

Risk Assessment Review & Key Points

• Purpose • Risks • Risk Appetite

• Risk management • Risk Assessment

Internal Use Only

Risk Assessment Review

The risk assessment must identify: • Information and technology assets of the organization • Assess likelihood and impact of threats & vulnerabilities (inherent risk) • Risk Response (Accept, Transfer, Reduce, Ignore) • Audit controls/provide assurance

Internal Use Only

Expanding the Depth of Review

Plan to expand the depth when:  A risk assessment has not been reviewed at least annually.  There have been changes in management and/or environment.

 Risks identified do not incorporate Technical, Human, Environmental risks.  The risk assessment has been completed with limited input from other departments.  There are discrepancies between the services/ topology and assets identified in the risk assessment.  Significant audit and independent review findings are evident.  You are not confident in management's responses.

Internal Use Only

Reducing the Depth of Review May be able to significantly reduce the depth of the risk assessment review when:  The risk assessment was recently reviewed by a qualified auditor and found to be adequate.  There have been no changes in management or the environment since the last examination.  The quality of the risk assessment process has been validated.

Internal Use Only

Risk Assessment: Management Responsibilities  Effective risk assessments are done by qualified personnel, have executive-level ownership & are enterprise-wide.  Risk assessments should be done annually or when significant changes occur.  An effective risk assessment process includes identification of assets, threats & vulnerabilities.  Management should be able to explain rationale for security devices they use and for not including devices that would further mitigate risk.

Internal Use Only

Risk Assessment: Board Responsibilities  The Board is responsible for communicating their risk tolerance to management.  Board should review and approve the risk assessment annually.  Risk decisions (acceptance/exceptions) should be made at the Board and/or executive management level and be documented.  Board minutes should support for answers provided by management during discussions (approval/discussion of risk assessment findings, risk acceptance decisions, etc.).

Internal Use Only

Development and Acquisition

Module Objectives • Analyze an institution's project management process. • Understand the aspects of the development, acquisition, and maintenance activities. • Assess management’s ability to effectively deploy appropriate technology solutions from initial contract to end of life (EOL). • Identify weaknesses and draw meaningful conclusions about an institution's process and practices.

System Development Life Cycle • A project management technique that divides complex projects into smaller, more easily managed segments or phases.

• Segmenting projects allows managers to verify the successful completion of project phases before allocating resources to subsequent phases. • SDLC can be conveyed in 5-6-7 phases. • Phases may be divided differently depending on the organization involved.

SDLC: The glue that holds Development & Acquisition together SDLC Framework

Project Management Process

Development In-house

Acquisition

Third Party

SDLC: The glue that holds Development & Acquisition together

• Initiation

• Planning & Analysis

• Initiation

1

1

1

• Planning

• Design

2

• Planning

2

2

• Design

• Development

3

• Execution

3

3

• Development

4

• Testing

4

• Monitoring

4

• Testing

5

• Deployment

5

• Closing

• Implementation

5

6

• Maintenance

6

• Maintenance

7

SDLC: The glue that holds Development & Acquisition together

Initiation

Planning

Design

Develop

Test

Implement

Maintenance

• Key tasks in initiation & planning include: – Begins when an opportunity to add, improve or correct a system is requested. A business need is identified (requires stakeholder involvement) – Feasibility study outlines scope, cost/benefit, functional requirements, Project factors. – Creation of Project Plan that refines initiation phases further identifying specific activities for the project. – Creation of Business Requirements Document – Key areas include Project Overview, Requirements, Roles and Responsibilities, Communication, Management, Budget, Testing, Deliverables.

SDLC: The glue that holds Development & Acquisition together

Initiation

Planning

Design

Develop

Test

Implement

Maintenance

• Key tasks in design & develop include: – Begins converting informational, functional, and network requirements into design that programmers can use to script an application. – Design document focuses on how to deliver the required functionality based on business requirements document (BRD). – Development starts when stakeholders agree on design, converting design specifications into an executable program. – Development includes, acquiring and installing system environment, databases, test case procedures, and coding.

SDLC: The glue that holds Development & Acquisition together

Initiation

Planning

Design

Develop

Test

Implement

Maintenance

• Key tasks in test & implement include: – Testing phase should test to ensure accuracy of programmed code, inclusion of expected functionality, and interoperability with other applications and network components. – Good Project management practices will have test plans & test environment prior to development – Various testing methodologies include acceptance testing, functional, integration, stress testing. – Implementation involves approving, installing or moving test code into production. (Separation of duties is key) .

SDLC: The glue that holds Development & Acquisition together

Initiation

Planning

Design

Develop

Test

Implement

Maintenance

• Key tasks in maintenance include: – Configuration Management with baselines versions or “gold image” of approved application or system. – Change Management documented procedures for ensuring all changes are approved and documented. – Procedures for Upgrades, patches, security fixes and emergency updates. – Decommissioning and End-of-Life.

Project Management

Project Management • Project management is simply planning and completing a task which includes one-time or ongoing operational activities. • Project Management practices are formalized. • Characteristics of a project management include: • Roles and Responsibilities • Project Plans • Standards & Procedures

Roles and Responsibilities Responsibilities Key Roles

Board of Directors (BoD)

Approve funding (major projects) and should understand project plans and monitor progress against plan. Set risk tolerance levels within which the project manager must operate. Establish and approve major project deliverables and coordinate activities. The committees often include the project manager, a board member, and executives from all organizational departments. Approve & promote projects within their authority and ensuring adequate resources are available to complete projects. Ensuring projects support business objectives, project goals and expectations are clearly defined, and project tasks are identified, scheduled, and completed. Project managers are also responsible for monitoring and reporting a project's status to senior management. Maintaining the technology resources used by project teams and assisting in the testing and implementation phases. User departments assist in defining and testing functional requirements (system features). End-user involvement throughout a project is critical to ensuring accurate definitions and adequate tests. Identify and design security requirements and testing the features during development and after implementation. Validate project assumptions and ensure the quality of deliverables. Assurance personnel should be independent of the development process and use predefined standards and procedures. Identify system control requirements and testing the controls during development and after implementation.

Technology Steering Committee Senior Management Project Manager (PMO)

Technology Department

User Departments

Information Security Quality Assurance

Auditors

Project Plans • Project plans are detailed with clearly defined expectations, realistic budgets, and communication structure ensures the organization's ability to manage projects successfully. • Boards, or board-designated committees, should formally approve project methodologies, and management should approve and document significant deviations from approved procedures. • Project Plans must be carefully managed to ensure they meet organizational needs on time and within budget. • Ineffectively managed projects often result in late deliveries, cost overruns, or poor-quality applications. • Regardless of the SDLC method used, it should be tailored to match a project's characteristics and risks.

Project Standards

Organizations should establish appropriate methodologies that govern project management activities:

• Configuration Management • Quality assurance • Risk management • Testing • Documentation

Project Management Tools

Management (PMs) should have appropriate tools to schedule and monitor project tasks and estimate project costs and completion dates.

• Project Trackers • Gannt Charts • Kanban (Agile tool) • Collaborative Software

Examiners should verify accuracy of trackers, charts and diagrams to assess the effectiveness of project management tools.

Project Management Process

Initiation

Planning

Execution

Monitoring

Closing

• Scope & Budget • Business Requirements Document • Work Breakdown Schedule • Gantt Chart

• Deployment • Upgrades • Infrastructure

• Tracking & Status • KPIs • Technology Steering Committee • BoD Reporting • Scope Creep

•Conclude activities •Policy & Procedures • Independent Review •BCP & DR Testing

• Business Need • Feasibility Study • Project Plan • Risk assessment

• Test Environment • Quality Assurance • Change requests • Updates to plan

Information Security & Audit

Project Management Communications Adequate level of oversight and support provided by management & the board relating to development, acquisition, and maintenance activities.

• Policies establish committee and Board reporting requirements. • Risk reporting and monitoring procedures. • Examiners need to determine the frequency and quality of technology related reporting to committees and board are satisfactory.

Development

What is Development? • Development projects involve the creation of software applications or integrated application systems. • May include “internally developed” scripts or spreadsheets and database reports for cases where organization rely on the spreadsheets and reports to make important budgeting and accounting decisions. • Software development projects can be completed in-house, through outsourcing, or by a combined approach. • Organizations typically manage development projects using systematic methodologies that divide large, complex tasks into smaller, more easily managed segments or phases (SDLC).

Development Standards

• Project management standards should address issues such as project management methodologies, risk management procedures, and project approval authorities. • Roles & responsibilities that establish SoD Separation of duties within the development team controls for “test” and “production” environments. • System control standards should address items such as an application's functional, security, and automated control features. Organizations should have written development standards that, at a minimum, address project management, roles and responsibilities, system control, change control, testing and documentation.