IT Examiner School

IT Examiner School

November 8-1 0 & November 15-1 7 , 2021

@ www.csbs.org � @csbsnews

CONFERENCE OF STATE BANK SUPERVISORS 1129 20th Street NW / 9th Floor / Washington, DC 20036 / (202) 296-2840

IT Examiner School Live Virtual November 8-17, 2021

WEEK 1 Monday, November 8, 2021

Introductions & Pre-Course Review/Terminology

12:30 pm – 1:30 pm 1:30 pm – 2:15 pm 2:15 pm – 2:30 pm 2:30 pm – 3:00 pm 3:00 pm – 4:00 pm 12:30 pm – 12:45 pm 12:45 pm – 1:45 pm 1:45 pm – 2:15 pm 2:15 pm – 2:30 pm 2:30 pm – 3:30 pm

Regulations/Guidance

Break

Rating System/Exam Process

Information Security Program Framework

Tuesday, November 9, 2021 Prior Day Review

Audit

Audit Rating Exercise

Break

Development & Acquisition

Development & Acquisition Roundtable

3:30 pm – 4:00 pm

Wednesday, November 10, 2021 Prior Day Review

12:30 pm – 12:45 pm 12:45 pm – 1:30 pm 1:30 pm – 2:30 pm 2:30 pm – 2:45 pm 2:45 pm – 4:00 pm

Third Party Risk Support & Delivery

Break

Support & Delivery

WEEK 2 Monday, November 15, 2021

Data Center Controls/Physical Security

12:30 pm – 1:30 pm 1:30 pm – 2:00 pm 2:00 pm – 2:15 pm 2:15 pm – 2:45 pm 2:45 pm – 3:45 pm 3:45 pm – 4:00 pm 12:30 pm – 12:45 pm 12:45 pm – 1:30 pm 1:30 pm – 2:00 pm 2:00 pm – 2:15 pm 2:15 pm – 2:45 pm 2:45 pm – 3:00 pm

Cybersecurity

Break

Cybersecurity

Business Continuity Planning/Disaster Recovery (BCP/DR)

Electronic Funds Transfer

Tuesday, November 16, 2021 Prior Day Review

Electronic Funds Transfer

Management

Break

Management

Composite Rating Discussion & Exercise

Breakout Rooms

3:00 pm – 4:00 pm

IT Examiner School Live Virtual November 8-17, 2021

Wednesday, November 17, 2021

Composite Rating Exercise Discussion Non-Depository/Depository Breakout

12:30 pm – 1:00 pm 1:00 pm – 1:30 pm 1:30 pm – 2:15 pm 2:15 pm – 2:30 pm 2:30 pm – 3:15 pm

Emerging Issues

Break

Final Assessment & Course Wrap Up

Virtual IT Examiner Training Day 1

Disclaimer The views expressed are those of the speaker and do not represent the official views of CSBS, New York State or the NYS Department of Financial Services, aka DFS, or the California Department of Financial Protection and Innovation. 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.”

Microsoft Teams

Introductions

NAME AGENCY AND STATE

YEARS EXPERIENCE AS EXAMINER

NUMBER OF IT EXAMS

SOMETHING YOU HOPE TO LEARN DURING THIS CLASS

Financial Institutions Manager California Department of Finance & Innovation matthew.fujikawa@dfpi.ca.gov Matthew Fujikawa

Supervising IT Examiner New York Department of Financial Services Richard.Atkinson@dfs.ny.gov Richard Atkinson

Cyber Security Examiner New York Department of Financial Services Craig.Farrar@dfs.ny.gov Craig Farrar

Assistant Deputy Superintendent of Cybersecurity Supervision New York Department of Financial Services William.Peterson@dfs.ny.gov William Peterson

Go to www.menti.com and enter PIN provided

Regulations & Guidance

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

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

Regulations & Guidance 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”)

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

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

Regulatory Authority Examples: Depository Institutions

Regulators / Licensure

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

Types of Entities

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

FDIC, FRB, OCC, States, CFPB 12 CFR 364, Appendix B; Section 501(b) of GLBA; FFIEC; State Laws/Regulations (e.g., Part 500, CCPA)

Bank Holding Companies, Trust Companies, US Branches of FBOs

FRB, States

Generally, the same as banks (above)

Credit Unions (Federal or State)

NCUA, States

12 CFR 748 (Appendix A & B)

Regulatory Authority Examples: Non-Depository Institutions

Regulators / Licensure

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

Types of Entities

Mortgage Originators and Servicers CFPB, FTC, States

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

Examination Approach Examples: Depository Institutions

Types of Entities

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

Types of Entities

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

Rating Systems & Exam Process

Components of InTREx ITP

Work Program

Information Technology Profile

Core Modules Expanded Modules

Risk Profile

Qualitative Adjustment

Supplemental Workprograms

InTREx Workprogram Core Modules

Audit

Management

Development & Acquisition • Vendor Management (Acquisition)

Support & Delivery

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

• 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

Information Security Program Framework

Information Security Program Framework “Each insured depository institution shall implement a comprehensive written information security program that includes administrative, technical, and physical safeguards appropriate to the size and complexity of the institution and the nature and scope of its activities.”

Information Security Program Framework • Board of Directors • Assess Risk • Manage & Control Risk • Oversee Service Providers

• Adjust the Program • Report to the Board • Implement the Standards

Cybersecurity vs. Information Security Information Security – “protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide I ntegrity, C onfidentiality, and A vailability.

Cybersecurity (NIST) – “Ability to protect or defend the use of cyberspace from cyber attacks”

Cybersecurity (CISA) - art of protecting networks, devices, and data from unauthorized access or criminal use and the practice of ensuring c onfidentiality, i ntegrity, and a vailability of i nformation.

Key Drivers – ISP Framework

Legislative Compliance • Gramm-Leach-Bliley Act • Sarbanes-Oxley Act • Homeland Security/CISA Critical Infrastructure • Health Insurance Portability and Accountability Act (HIPAA) • Health Savings Accounts • State Regulations

Key Drivers – ISP Framework

• Protect assets, data & information • Ensure continuity of the business by protecting assets • Reduce exposure for legal & financial liability • Ensure integrity for shareholder confidence • Relationship between the need for access & the need for protection

Common ISP Frameworks

• “Blueprint” for building a program • Series of documented processes • Define implementation of program • Ongoing management of risk & controls • Frameworks can be specialized • Industry specific or regulatory

GLBA - ISP Framework

GLBA requires that financial institutions act to ensure the confidentiality , integrity and availability of customers’ “personally identifiable information or PII

Financial Privacy Rule that requires financial institutions to explain their information sharing practices to their customers.

The Safeguards Rule that requires financial institutions to create a written information security program that includes administrative , technical , and physical safeguards appropriate to the size and complexity of the institution and the nature and scope of its activities.”

GLBA & 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.

CIA TRIAD Examples

Confidentiality lock on a safe provides

Integrity version control provides

Availability backups provide

GLBA Safeguards Rule: Types of Controls Administrative Controls support the classic management responsibilities of planning, directing, organizing, and reporting.

Physical Controls protect against environmental, human, and systemic threats.

Technical Controls involve hardware and application or OS software.

42

Review Question 1 What term describes that only authorized individuals have access to information? A. Integrity B. Confidentiality C. Availability

Review Question 2 What type of controls includes the use of policies and procedures to implementation an information security program? A. Administrative

B. Technical C. Physical

ISP Framework

Program implementation

Board oversight and involvement

Management and control of risk

Risk assessment

Service provider oversight

Audit procedures

Board reporting

Program Implementation Chief Information Security Officers

 Designated by Board or senior management.  Responsible/accountable for administration of the Information Security Program.  Manage risk assessment process, development of policies, standards, and procedures, testing, and security reporting processes.

46

Program Implementation Chief Information Security Officers

 Should report directly to the Board or senior management.  Should be risk managers and not an IT resource.  Prevent conflicts of interest.

47

Program Implementation Policy, Standards & Procedures

• Policy : All external business communication via the Internet will provide confidentiality, integrity, and availability. • Standards : We will use an FIPS 140-3 encryption for IPSec VPN with key exchange via IKE using RSA digital certificates. • Procedures : Configure Cisco 3620 with IPSec using AES128 encryption to host…

Policy

Standards

Procedures

Security Policy: The “Why”

• Security policy • Short • Stable • Supports mission statement

• Establish roles & responsibilities “Authority” • Approval from highest level of management • Outline consequences of non-compliance • Must result in a positive cost benefit!

Security Policy

49

Security Standards: The “What” • Content validity measured against security policy • Set specific requirements/quantify the risk • Establish • Key Risk Indicators • Key Performance Indicators • Describe the consequence of non-compliance • Documents may refer to other standards, policies & laws

Security Policy

50

Security Procedures: The “How”

• Step by step process for implementation • Establish roles & responsibility “Accountability” • Event driven • Volatile, change frequently • The “how-to” manual of security compliance

Security Policy

Security Policy Summary

• Policy drives technology • Increases cost-effectiveness • Provide guidelines for uncertain scenarios • Consistency • Change management • The basis for IT Audit compliance

52

Review Question 3 In a small community bank, Jill serves as both an IT and information security officer roles. Jill has admin access to systems including adding and removing accounts and permission to take ownership of objects/data. Jill also the sole person in the company that has the security responsibility of monitoring access, reviewing log files, and reporting to management on security violations. One day management decided to run an independent audit on information security and determined that Jill was accessing data on executive payroll and other strategic plans to which she was not authorized to access. What is the supervisory concern? A. Separation of Duties and independent review B. Lack of procedures C. Not enough resources D. Lack of training

Risk Assessment Basics

 Identify reasonably foreseeable internal & external threats;  Assess the likelihood and potential damage of these threats; and  Assess the sufficiency of countermeasures/controls to determine a residual risk that is acceptable by management and board

Security Definitions Risk Assessment

Threat

Vulnerability

Risk

Deficiency that provides opportunity for threat

Likelihood threat taking advantage of vulnerability

Danger to security

Security Definitions Risk Assessment

Assets

Exposure

Countermeasures

Harm that comes as a result of threat taking advantage of vulnerability

Steps taken to reduce risk – never 100%

People, expertise Hardware Software Data

Countermeasure/Risk Relationship

Risk

Threat

Vulnerability

Leads To

Exploits

Damages

Affects

Exposure

Asset

Mitigated by

Countermeasure

Causing

57

Risk Analysis/Assessment The risk assessment must effectively Gather/Identify: • Data regarding the information and technology assets of the organization • Threats to those assets • Vulnerabilities • Existing security controls & processes • Current security standards and requirements

58

Risk Analysis/Assessment

The risk assessment must effectively Analyze: • Probability & impact associated with the known threats • Vulnerabilities to their assets

59

Risk Analysis/Assessment The risk assessment must effectively Prioritize: • Risks present due to threats & vulnerabilities • Determine appropriate level of training, controls, & assurance necessary for effective mitigation

60

Review Question 5 IT department forgot to apply a security patch. This is an example of a: A. Threat B. Vulnerability C. Countermeasure

Manage & Control Risk

 Train Staff, Executives, and the Board  Test Key Controls  Properly Dispose of Customer Information (electronic and/or paper)

Service Providers/Vendors

 Perform due diligence when selecting service providers  Require service providers to comply with the institution’s ISP, at a minimum  Monitor service providers

Board Oversight & Involvement Proper governance is achieved through management structure and the Board of Directors. Assignment of responsibilities & authority covering the following: • Central oversight & coordination • Risk assessment & measurements communicated to board • Independent monitoring & testing • CISO Reporting • Defined risk appetite & acceptable residual risk

Board Oversight & Involvement • Establishment of policies, standards, and procedures

• Annual review/approval • Allocation of resources • Informed on security breaches & response • Accountability

Annual Board Reporting

 Risk assessment  Risk management & control  Service provider agreements  Results of testing  Security breaches & response  Status of ID theft/red flags program  Recommendations for changes to Information Security Program

66

ISP Framework - Flexible

 Technology  Sensitivity of Customer Information  Internal or External Threats  Institution’s Changing Business Arrangements  Information security program should reflect current information technology environment & practices

Most Common GLBA Examination Issues  Information Security Program stale/outdated  Risk assessment not updated at least annually  Risk Assessment is IT centric & not enterprise-wide  Inadequate Information Security Report to the Board (or a lack of reporting)  Poor vendor/service provider oversight  Lack of training

GLBA Summary

Key Guidelines for Reviewing GLBA:  Review working documents provided by institution

 Determine the Involvement of the Board  Evaluate the Risk Assessment Process

 Evaluate adequacy of the Program to manage & control risk  Assess the measures taken to oversee service providers  Determine whether an effective process exists to adjust the Program  Summarize and communicate findings

Resources

FDIC – FIL-43-2016: • Information Technology Risk Examination (InTREx) Program

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

Knowledgeable individuals conduct

Risk assessment/complexity based

Documented Findings/recommendations

Board/Committee reported results

Conducted separately or all at once

IT scope & frequency based on inherent or residual risk

Assessment Areas for IT Audits

The IT Audit program should be assessed for the following:

• 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

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 and signed by an individual or committee not responsible for IT operations. •Preferably signed by a member of the Board or Audit Committee.

Expectations and responsibilities

The scope, timeframes, and cost of work to be performed

Institution access to audit workpapers

IT Audit Risk Assessment

Universe of auditable entities

Risk assessment = audits

Reasonable scale

Inherent risk Relevance of controls

Effectiveness of Controls

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

Third ‐ party outsourcing

Strategic Planning

Disaster Recovery

Network Architecture (Firewalls and IDS/IPS)

Project Management

BIA

Social Engineering

Incident Response

GLBA Compliance

Security Monitoring

Red Flags/ID Theft Prevention

Written IT Audit Reports Describe scope and objectives

Identifies the deficiencies/wea knesses

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 and 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 and 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 a 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:

Basic Vulnerability Assessment description:

• Checking building windows and doors to see if they are secured • Checking if building is susceptible to other events, e.g. natural catastrophes

Vulnerability Assessment vs. Risk Assessment

Assigning quantifiable value and importance to a resource

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

Assist in mitigating or eliminating vulnerabilities for key resources

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 and 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

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

Detecting vulnerabilities not easily found using

Ascertain the likelihood of gaining system access

standard system protective means

Ability of current security methods to detect or repel an attack

Measure of risk for a cyber attack

List of vulnerabilities needing patching

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

There are 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

There are 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

Whether or not there are conflicting duties, e.g. involved in auditing areas they have responsibilities or oversight Type of IT experience and training • Some IT audits require specific skill sets

Whether or not the Auditor has a debt with the entity (may have some influence)

Auditor should be reporting to Board or Audit Committee

Independence :

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 and 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 and 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 and record them in your WP • Notify the Safety & Soundness EIC

If audit program is satisfactory • Can risk focus areas recently audited

Audit Case Study Review pages 50-60, 83, and 88 in the Case Study materials.

Development and Acquisition

Systems Development – The Good, The Bad and The Ugly

As Time Goes By

• Accordion Folders • The Rise of “Quality” • SDLC Rears Its Ugly Head • The Search for Middle Ground

Two Vital Ingredients

Methodology • Documentation standard and templates • ‘Phase’ structure

Infrastructure • Project Management Office • Testing structure • Change Management/controls for turnover

Lifecycle

“It’s Not A Procedure, It’s A Process”

SDLC Alphabet Soup IPR BRD IPE HLD LLD UTS UTP STP STS ATP ATS TMX

Business Requirements Document The business requirements document (‘BRD’) is, in almost every SDLC, the controlling document for a project. It documents: • all of the goals of the project • all of the details of the final product • all of the agreements that have been made along the way. It typically includes the project’s budget, and details of how much of a variation – in either dollars or time – is allowed in that budget without the project needing to be reapproved.

Business Requirements Document • Careful management of the BRD is one of the vital skills needed in the job. • Once the BRD has been completed and signed off by the stake ‐ holders, it becomes a tool for the PM. • “If it isn’t in the BRD as a requirement, it isn’t getting done!” is a common statement in project status meetings.

The Return of the IT Risk Assessment!

Documentation isn’t always made up of new documents; key existing documents also need review and updates during a project.  Update your Risk Assessment – did the project mitigate some risks, or did it create others?  Update your Disaster Recovery Plan  Update your IT inventory

Post Implementation Review

• How well did we do? • Did we make our deadlines? If not, how badly did we miss it? • How accurate were our estimates? • What was our Burn Rate (how quickly did the money get spent)?

Metrics

Lessons learned

• What pitfalls can we avoid next time?

Disclaimer From this point on, this module is moving away from the specific guidance of the FFIEC, since newer development formats such as Agile Development and DevOps (which we will discuss here) are not a perfect fit in the world of SDLC. How can we deal with this problem until specific guidance comes along?

Development Types Waterfall • Waterfall processing is the name for the processing style that was typical in the mainframe world. • It takes its name from the analogy of a river going from a set point, running through a change (the waterfall) and arriving at an end point. • It’s a single process that runs from the beginning to the end.

Agile • Agile processing is totally different from Waterfall • It’s not addressed in FFIEC handbook – the word ‘agile’ doesn’t even appear in the handbook! • It’s not a natural fit for SDLC, which is geared to structure and repeatability • Agile development can be very prone to ‘scope creep

Waterfall vs. Agile DISCUSSION:

In the absence of specific guidance from the FFIEC, what are some ways or techniques for reviewing an agile development environment?

Software Acquisition

Software Acquisition

• Familiarity with software acquisition process • Compare and contrast Software Development and Software Acquisition • Identify risks of software acquisition • Concepts of software contracts and escrow agreements Goals for this lesson

Similarities

Requirements Definition

Project Plan

Testing

Involvement of end users and a variety of technology personnel

Differences

Vendor selection and review

Contract negotiation and license reviews

Product assessment and gap analysis

Design and development phases of SDLC are replaced or modified by a bid solicitation process

Software product acquisition may be “off the shelf” or may involve customization by vendor

Escrow arrangements

Risks Primary risks of acquisition projects:

• Inadequately defined requirements • Inadequate vendor assessment • Inadequate product assessment • Inadequate product testing • Inadequate review of contract agreements

The risk of software acquisition, and extent of mitigating controls, will vary depending on nature and criticality of the supported business function

Categories of Software

Off the Shelf • A generic software package with no customization

Customized Package • Still mainly a generic package, but one that can and will be customized by the vendor to better meet your requirements

Custom Code • A package that is written by the vendor to specifically meet your requirements

Vendor Management • Vendor management policies apply to the software acquisition process • Organizations should establish vendor selection criteria and review potential vendors' financial strength, support levels, security controls, etc., prior to obtaining products or services. • Additionally, management reviews contracts and licensing agreements to ensure the rights and responsibilities of each party are clear and equitable. • The bank is responsible for ensuring that security, reliability, and functionality are already built into the product before it is acquired.

Feasibility Study • Business objectives; • Technology objectives;

• Functional (business) requirements; • Security requirements; • Internal control requirements; • Reliability requirements; • Documentation requirements; • Performance requirements; • Expandability requirements; • Network requirements; • System interface requirements

more…

Feasibility Study

• Maintenance requirements; • Installation requirements; • Conversion requirements; • Personnel requirements; • Processing requirements; • Product development standards; • Product design standards; • Testing requirements; • Training requirements; • Vendor's financial strength; • Vendor's support levels; • Cost/benefit analysis.

Other issues to be considered

• Confidentiality standards; • Compatible operating systems; • Copyright standards;

• Delivery dates; • Escrow criteria;

Software :

• Liability limitations; • Licensing restrictions; • Maintenance procedures; • Next release date;

Other issues to be considered

•Regulatory requirements; •Software language; •Subcontractor details; •Testing standards; •Training provided; and •Warranty specifications.

Software (Cont.) :

Other issues to be considered

•Backup options; •Maintenance requirements; •Memory capacities; •Performance capabilities; and •Servicing options.

Hardware

Software Acquisition Acquired software is usually licensed, not owned, by the bank. Source code is generally not provided. This is a significant risk, since bank is dependent on the vendor for continuing support. • Limited term of use or perpetual license • Limited number of users or site license

Software Escrow Agreements • Common alternative to source code access.

• Financial institution will by allowed access to source code under very limited specific conditions , which must be specified in the agreement; for example,

• Discontinued product support • Financial insolvency of vendor

Software Escrow Agreements • Typically, an independent third party retains the source code. • Adequate documentation should also be included

• It is important that the current version of the software be the one that is escrowed. The escrowed software and documentation should be updated when the program is changed. This should be specified in the contract and verified periodically. • There are a number of complex legal issues surrounding escrow agreements

Software Contract Agreements • The vendor will want contract provisions which are in its own favor. • Depending on the size of the bank, it may or may not be able to negotiate more favorable terms. • Certain contract provisions may be of such significance that the bank may need to consider alternative vendors. • Exit provisions, data ownership, data conversion all need to be considered in the contract • Regulatory requirements clause • For mission-critical software, clauses that limit vendor liability are a dangerous practice.

Examination Procedures

Identify any major acquisition plans

Examine feasibility studies, requests for proposal, vendor proposals, project plan

Review contracts/escrow agreements

Questions?

Roundtable Discussion

Evaluating Third Party (Vendor) Risk Management IT Examiner School

FFIEC Component Rating Areas of Coverage

The adequacy of controls and the ability to monitor controls at service providers;

The adequacy of customer service provided to clients by service providers;

The ability of the service provider to provide and maintain service level performance that meets the requirements of the client.

Module Objectives

1. Describe the Benefits and Risks Associated with Outsourcing Technology Services

2. Discuss the Components of Comprehensive Third-Party (Vendor) Risk Management Program

Outsourcing Technology Services Examples: • The origination, processing, and settlement of payments and financial transactions; • Information processing related to customer account creation and maintenance; • Other information and transaction processing activities that support critical banking functions

Benefits and Risks of Outsourcing

“ You can outsource the business function, but you can't outsource the risk”

Benefits

Risks

Enables an institution to offer its customers enhanced services without the various expenses

Outsourcing does not reduce the fundamental risks associated with IT or the business lines that use it. Loss of funds, loss of competitive advantage, damaged reputation, improper disclosure of information, and regulatory action remain.

Offers the institution a cost ‐ effective alternative

Gain operational or financial efficiencies or specialized expertise Conserve capital for other business ventures

Components of A TPRM Program 1. Risk Assessment and Business Requirements 2. Service Provider Selection

3. Contract Selection 4. Ongoing Monitoring

• Other Considerations:

• Business Continuity Management • Information Security / Safeguarding • Intra or Intercompany Service Agreements

Vendor Risk Assessment

• Sensitivity of data accessed • Volume of transactions • Criticality to the financial institution’s business

Functional Risks

Service Provider Risks

• Strength of financial condition • Ability to maintain business continuity • Ability to provide accurate, relevant, and timely MIS • Reliance on Subcontractors

• Reliability • Security • Scalability to accommodate growth

Technology Risks

Business Requirement Document (BRD)

• Sets the stage for all outsourcing actions and forms the basis for subsequent management of the outsourced activity. • Developed through a process that identifies the functions or activities to be outsourced, assesses the risk of outsourcing those functions or activities, and establishes a baseline from which appropriate control measures can be identified. • Provides a basis for an understanding between the financial institution and the service provider as to what the risks are and how they will be managed and controlled.

The requirements definition phase should result in a detailed document containing descriptions of the institution's expectations relative to the outsourced service.

Service Provider Selection The Request for Proposal (RFP) should:  Describe the institution's objectives;

 The scope and nature of the work to be performed;  The expected production service levels, delivery timelines, measurement requirements, and control measures; and  The financial institution's policies for security, business continuity, and change control.  Requests for responses addressing those requirements as well as the fees each service provider will charge

Due Diligence

Due Diligence activities should include a review and assessment of: • Existence and corporate history • Financial Status • Strategy and Reputation • Service Delivery Capabilities, Status, and Effectiveness • Technology and Systems Architecture • Internal Controls Environment, Security History, and Audit Coverage • Legal and Regulatory Compliance • Insurance Coverage • Ability to Meet DR/BC Needs A financial institution should perform due diligence on the service provider's response to an RFP as well as the service provider itself.

Contract Issues & Considerations

Service Level Agreements (SLAs)

Pricing Methods

Exit Strategies / Data Deconversion

Contract Inducement

Ongoing Monitoring & Reassessment

Periodic reconciliation of vendor inventory and re ‐ assessment of all vendors regardless of risk or criticality

Monitoring of key SLAs

Monitoring of provider’s financial condition

Periodic re ‐ evaluation of provider’s general control environment and policies (including cybersecurity, business continuity, and insurance coverage)

Any Questions?

Virtual IT Examiner Training Day 3 – Support & Delivery

Module Agenda Define “Support & Delivery”, major component of URSIT

Describe & discuss major elements of Support & Delivery assessed during an exam

Assess effectiveness of an institution’s operations security & risk management practices

Assess effectiveness of an institution’s support & delivery practices

Support & Delivery Component

Question

Which topics come to mind when you think about the phrase Support & Delivery?

What is Support & Delivery?

An organization's ability to provide technology services in a secure environment

Condition of IT operations & factors such as reliability, security, & integrity, which may affect the quality of the information delivery system

Operational risks throughout the organization & service providers

Major Elements of Support & Delivery

Information Security

IT Operations

Business Continuity Management

Third-Party (Vendor) Risk Management

FFIEC IT Handbooks

Business Continuity Management

Information Security

Operations

Outsourcing Technology Services

E-Banking

https://ithandbook.ffiec.gov/it-booklets.aspx

Network Diagrams: Technology Review for Example Bank

Module Objectives

Understand what a network diagram is & its purpose

Identify basic IT infrastructure, concepts & risks

Learn different security zones such as LAN, WAN & DMZ

Example Bank Network Topology

Loan Department Workstations

Loan Network Printer

Loan Documentation Server

Hub/Switches

LAN 1

LAN 1

HR Workstation

LAN 1

Audit Workstation

LAN 1

HR/Audit Server

LAN 1

Router

LAN 1

LAN 2

LAN 2

LAN 1

Switch

LAN 2

LAN 1

Network Topology Review Questions Part 1

1. What is the function of a Workstation? 2. What is the function of a Server? 3. What is the function of a Switch/Hub? 4. What is the function of a Router?

Local Network

LAN 2

LAN 1

Wide Area Network – Branch/Remote

LAN 2

LAN 1

Network Topology Review Questions Part 2 1. What is the difference between a local area network (LAN) and a wide area network (WAN)? Why is it important? 2. What device would you use to connect two LANs? 3. Would a connection between institution and service provider be considered a LAN or WAN connection?

Internet Connectivity

DMZ

Firewalls

IDS

VPN/E-Mail Relay

DMZ

Border Router

DMZ

Internet

Network Topology Review Questions Part 3 1. What is a firewall? 2. What does an intrusion detection system (IDS) do? 3. What does an intrusion prevention system (IPS) do? 4. What is a DMZ? Why is it important? 5. What is a VPN or Virtual Private Network?

Network Diagram Use Cases/Tips

1. Check technical controls in the diagram match controls in policies, procedures & risk assessments. 2. Use as a guide to identify the institution’s hardware, devices & systems. 3. Don’t hesitate to ask questions or explanations on devices & connections.