1

WORKERS WERKS CREDIT UNION (WWCU) IT SECURITY RISK MANAGEMENT PLAN

Version Number: 1.0 Version Date: 10/20/2015

2

TABLE OF CONTENTS 1 Introduction …………………………………………………………………………………………………………………………………………….. 3

1.1 Document overview ……………………………………………………………………………………………………………………….. 3

1.2 References ………………………………………………………………………………………………………………………………………. 3

1.2.1 Document References …………………………………………………………………………………………………………… 3

1.2.2 Standard and Regulatory References ………………………………………………………………………………….. 3

1.2.3 Definitions ………………………………………………………………………………………………………………………………. 3

1.2.4 Conventions ……………………………………………………………………………………………………………………………. 3

2 Roles and Responsibilities ……………………………………………………………………………………………………………………… 3

3 Escalation Process …………………………………………………………………………………………………………………………………… 4

3.1 TIER 1—Team Managers ……………………………………………………………………………………………………………….. 4

3.2 TIER 2—Senior Managers ………………………………………………………………………………………………………………. 4

3.3 TIER 3—Executive Leadership ………………………………………………………………………………………………………. 4

4 Risk Management Process …………………………………………………………………………………………………………………….. 4

4.1 Context Establishment …………………………………………………………………………………………………………………… 5

4.2 Risk Assessment ……………………………………………………………………………………………………………………………… 6

4.2.1 Identification ………………………………………………………………………………………………………………………….. 6

4.2.2 Analysis ……………………………………………………………………………………………………………………………………. 7

4.2.3 Evaluation ……………………………………………………………………………………………………………………………….. 8

4.3 Risk Treatment ……………………………………………………………………………………………………………………………….. 8

4.4 Risk Acceptance………………………………………………………………………………………………………………………………. 8

4.5 Risk Communication ………………………………………………………………………………………………………………………. 9

4.6 Post-Production Monitoring and Review …………………………………………………………………………………….. 9

5 Ranking System, Security Risk Analysis ………………………………………………………………………………………………… 9

5.1 Probability of Occurrence ……………………………………………………………………………………………………………… 9

5.2 Severity …………………………………………………………………………………………………………………………………………. 10

5.3 Risk Priority Number ……………………………………………………………………………………………………………………. 10

3

1 Introduction

1.1 Document overview

This document contains the security risk management plan for software and hardware implementations throughout WWCU. It covers the management of all security-related risks during the implementation life cycle, including solutions from design, development, testing, and maintenance.

1.2 References

1.2.1 Document References

# Document Identifier Document Title

R1 NIST SP 800-30 Risk Management Guide for Information Technology Systems

1.2.2 Standard and Regulatory References

# Document Identifier Document Title

ST01 ISO 31000:2018 Risk Management

ST02 ISO/IEC 27005:2018 Information technology — Security techniques — Information security risk management

1.2.3 Definitions

Risk: A risk is an event or condition that, if it occurs, could have a positive or negative effect on a project’s objectives. Risk management: This is the process of identifying, assessing, responding to, monitoring and controlling, and reporting risks. Information security risk: This is risk associated with the impacts to an organization and its stakeholders that could result from the threats and vulnerabilities related to the operation and use of information systems and the environments in which those systems operate.

1.2.4 Conventions

Security risk and cybersecurity risk are used interchangeably in this document as synonyms of information security risk according to the definition above.

2 Roles and Responsibilities

Determining how to handle risk is always a management decision that requires identifying key stakeholders with defined roles and responsibilities. It is important to keep in mind that risk management is far more than a technology issue, and it requires the direct involvement of business process owners, IT personnel, and cybersecurity. Each has a role to play in risk management. WCCU has identified the following roles as critical to the management and mitigation of information security risks throughout the company. The table indicates the roles and their areas of responsibility.

4

Role Responsibility

Information Security Officer ● Accountability and responsibility for the information security risk management plan at WWCU

Project Manager (Project Management Office)

● Manages the risk management process throughout the program life cycle

Solution Architect ● Develops and maintains the system design framework used across WWCU that includes security risks assessment and mitigation standards

Development Manager ● Identifies software security risks and impact, and develops mitigation plan

Quality Manager ● Independently reviews overall risk management approach and control procedures

Deployment Manager ● Interfaces with IT support services throughout the branches

Customer Service Manager ● Interfaces with end users of banking and investment applications

3 Escalation Process

To empower executives and managers at all levels within the credit union and to support the individuals above, we have established the following tiers to allow for appropriate oversight and escalation.

3.1 TIER 1—Team Managers

Authorized to decide on risk treatment options for LOW risks and: o May decide on a risk treatment plan or decide to accept the risk o Should develop a plan to incorporate remediation actions within a reasonable period

3.2 TIER 2—Senior Managers

Authorized to decide on risk treatment options for MEDIUM risks and: o May decide on a risk treatment plan or decide to accept the risk o Should develop a plan to incorporate remediation actions within a reasonable time

period

3.3 TIER 3—Executive Leadership

Authorized to decide on risk treatment options for HIGH risks and: o May decide on a risk treatment plan or decide to accept up to high risk o Must develop a plan to incorporate remediation actions within a reasonable time period

4 Risk Management Process Risk management is the coordinated activities that optimize the management of potential opportunities and adverse effects. The alternative to risk management is crisis management. Risk management provides a way of realizing potential opportunities without exposing WWCU to unnecessary peril. The risk management process outlined below is an iterative process allowing increase of the depth and details of risk assessment at each iteration. Figure 1 illustrates the iterative risk management process adopted at WWCU.

5

Figure 1: Iterative Risk Management Process

4.1 Context Establishment Establishing the context consists of defining the scope and boundaries, and describing the following items, as appropriate:

● The technology solution ● Associated accessories ● Implementation environment

o Branch or corporate office o Server room, cloud

● Other connected devices o Mobile devices o Thin clients

● The processes involved in the life cycle of technology solutions o Internal processes o Outsourced processes o Client/user processes

● The users and user profiles o Client users o Users at the manufacturer (e.g., customer support)

● The level of education of users

6

● The use cases associated with the users and user profiles ● The types of data handled in the system

o Personally identifiable information o Data from mobile devices o Configuration data o System logs

● The hardware network interfaces o Bluetooth, Wi-Fi, etc.

● The software network interfaces and protocols o HTTP, TCP, UDP o SOAP, REST o Network ports

● The data input/output sources ● The constraints affecting the solutions

o Manufacturer processes o User processes (e.g., required scrubbing by medical professionals is not governed by

IT requirements, but should be considered when designing a risk plan) o Regulatory requirements: GDPR, SOX, etc.

All items listed above in second-level bullets are practical examples; other cases may be applicable depending on the technology solution.

4.2 Risk Assessment Based on the context documented in the previous step, the risks shall be identified, analyzed, and evaluated according to the objectives of the risk management process and the ranking system for security risk analysis. A preliminary risk assessment may be documented at the beginning of the design project, or before design (e.g., in feasibility/mock-up, etc.) and reviewed in the design input data.

4.2.1 Identification The steps of security risk identification are the following:

Assets An asset is anything of value associated with the technology solution or being utilized by consumers/customers. Assets can be:

● Hardware and software ● Data ● Other tangible or intangible assets

Examples:

● Teller client stations ● Servers (cloud and on-premise) ● Client/customer data ● Other data

Identification of assets

Identification of threats

Identification of existing controls

Identification of

vulnerabilities

Identification of

consequences

7

Knowing the assets contributes to identifying the magnitude of the consequences of an adverse event. For example, the consequences won’t have the same order of magnitude if the asset is client data verses publicly available data. Threats A threat is anything (human, phenomenon, accidental, deliberate) likely to result in damage of one or more assets. For example:

● Denial of service attack ● Unauthorized access ● Criminal organizations ● Hacker, cracker ● Natural events

Existing controls Existing or planned controls should be identified. They can be identified inside the manufacturer’s organization or in the target environments or other environments (healthcare provider, data center service supplier). Existing controls should be assessed to determine whether they are effective, sufficient, and justified in accordance with WWCU’s information security policies and standards. Vulnerabilities Vulnerabilities should be identified. They may result from design decisions, misuse of devices, software, organizational processes, etc. The Common Vulnerabilities and Exposures (CVE) list at https://cve.mitre.org/index.html should be leveraged. (The CVE list is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA), and is available from The MITRE Corporation.) Consequences The consequences that loss of confidentiality, integrity, and availability may have on the assets should be identified. The consequences on consumer data loss and impact on the credit union shall also be identified. Records Assets, threats, vulnerabilities, existing controls, and consequences shall be recorded in the security risk assessment report.

4.2.2 Analysis The risk analysis is performed with the use of the ranking system described in section 4 of this document, and with the data collected in the previous steps:

● The identification of the consequences on assets will determine the impact magnitude of the risk.

● The identification of threats, vulnerabilities, and incident scenarios will determine the likelihood of a risk.

8

Records For each incident scenario: probability of occurrence, severity, and risk priority number (RPN) are recorded in the risk assessment report.

4.2.3 Evaluation The RPNs are compared against risk acceptance criteria described in section 4.4. Legal and regulatory requirements shall be included in the evaluation of the acceptance of risks. Records For each incident scenario: risk acceptance and decision.

4.3 Risk Treatment The term risk treatment is defined in ISO 27005; it is broader than risk control or risk mitigation, commonly used in the IT industry. In this document, risk treatment refers to risk mitigation and control. Risk treatment options are:

● Risk modification or risk control ● Risk retention ● Risk avoidance ● Risk sharing

Risk controls shall be sought in this order of precedence:

● Security by design ● Security measures implemented in production or servicing ● Information for security

Risk control should be carried out to decrease the RPN of the residual risk to as low as reasonably possible (ALARP), with economic considerations. If the risk has an impact on consumer or employee safety, the risk treatment (risk control) shall be carried out with acceptance criteria related to employee safety. The security vulnerabilities or impacts on safety arising from risk treatment shall also be assessed. Records For each incident scenario: the risk treatment plan.

4.4 Risk Acceptance The reevaluation of the risk is performed with the use of the ranking system described in section 5 of this document, and with the risk treatment plan. A security risk may be deemed acceptable even if it doesn’t match the risk acceptance criteria of section 4.4, with justification to override the acceptance criteria. The information security officer is responsible for approving the override/waiver. Records For each incident scenario: the risk acceptance and justification as appropriate.

9

4.5 Risk Communication The risk assessment report is communicated internally to the department heads and project teams. The risk assessment report shall be an agenda item of design reviews and validation reviews. Parts of the risk assessment report may also be communicated externally to service providers or suppliers, as appropriate. When a supplier requires knowledge of the risk assessment report, a determination should be made if this supplier shall be placed on the list of critical suppliers.

4.6 Post-Production Monitoring and Review The security risk management document is systematically reviewed and updated, especially when:

● The solution is modified. ● Context changes. ● Assets, threats, vulnerabilities change. ● Analysis of data of post marketing surveillance triggers a reevaluation (internal defects,

customer requests, maintenance, vigilance bulletins, security incidents, field information from any source).

The review of post-marketing data is performed quarterly. Reviews and updates to any risk will be documented, approved, and included within the security risk management document. The review includes an evaluation of the relevance of the ranking system and the need to update it based on business or regulatory context.

5 Ranking System, Security Risk Analysis This section of the security risk plan describes how the risk priority number is deduced from the following risk characteristics:

o Probability of occurrence o Severity of consequences

5.1 Probability of Occurrence The probability of occurrence is a quantitative or qualitative criterion to deduce how often the identified risks might occur. WWCU leverages the below ranking to assess IT risk:

Ranking Definition Probability (P)

5 Often occurs, once a week Frequent (very high probability)

4 Could easily happen, once a month Probable (high probability)

3 Could happen or known to happen, once a year

Occasional (moderate probability)

2 Hasn’t happened yet but could, once in device lifetime

Unlikely (low probability)

1 Conceivable but only in extreme circumstances, less than once in device lifetime

Very unlikely (very low probability)

10

5.2 Severity The table below outlines the severity ranking used within WWCU for all IT system risk analysis.

Ranking Definition Severity

5 Significant loss of confidentiality or data integrity. Threatens financial impact to the credit union.

Catastrophic

4 Some loss of confidentiality or data integrity. Some financial consequences.

Critical

3 Small, isolated loss of confidentiality or data integrity. Minimal financial or business impact.

Moderate

2 Isolated, limited leak of non-sensitive data. May incur costs to recover leaked data.

Minor

1 Recoverable data loss, non-sensitive data leak. Negligible cost.

Negligible

5.3 Risk Priority Number

Cross Table for Risk Priority Number Risk priority number (RPN) = Severity x Occurrence

Negligible 1

Minor 2

Moderate 3

Critical 4

Catastrophic 5

Frequent

5

5 acceptable

10 tolerable 15 un-

acceptable

20 un-acceptable

25 un-acceptable

Probable

4

4 acceptable

8 tolerable 12 un-

acceptable 16 un-

acceptable 20 un-

acceptable

Occasional

3

3 acceptable

6 tolerable 9 tolerable 12 un-

acceptable 15 un-

acceptable

Unlikely

2

2 acceptable

4 acceptable 6 tolerable 8 tolerable 10 tolerable

Very Unlikely

1

1 acceptable

2 acceptable 3

acceptable 4

acceptable 5

acceptable