CHAPTER 5

RISK MANAGEMENT

1
 Contents

• Intro to Risk Management

• Functional Requirement
• Examples
• Risk Analysis Activities
• Risk Control
• Risk Assessment Report

2
 Intro to Risk Management
• IT Security Governance vs IT Security Management
▪ IT Security Governance
• Oversight and decision-making related to IT strategic direction.
• IT policies that outline the organisation's IT purpose, values, and
structure.
• Provide IT guidelines for management.

▪ IT Security Management
• Refers to the routine decisions and administrative work related to
the daily IT operations of the organisation.
• Management decisions support or implement goals and values
defined by governing bodies (such as the Board of Directors) and
documents (such as policies) with respect to IT security direction.

3
 Intro to Risk Management -continue
• What is Risk Management?
▪ The identification of Risks and their management by defining:
• The Risk Description.
• The Risk Owner.
• The Probability of the Risk Event occurring.
• The Risk Impact in terms of cost, loss of assets, Reputation.
• Failure to meet a Business Objective.
• The most suitable Mitigations that will prevent or reduce the
Likelihood of the Risk Event occurring with relation to their costs
and the reduction of Risk Exposure.
• The Contingency Plan to recover the Asset once risk is
manifested.
• An understanding of Corporate Risk Appetite and where
appropriate the application of Risk Tolerance.

Stephen Shippey 22nd April 2015 4

 Intro to Risk Management -continue
• Risk Definition: A Risk is a potential or future event that, should
it occur, will have a (negative) impact on the Business Objectives
of an Organisation.
▪ A risk must have Uncertainty, (in terms of Probability or
Likelihood). It might happen.
▪ A risk must have a measurable Impact, (usually measured in
monetary terms, but other criteria are acceptable, reputation for
example). “It May Rain Tomorrow”

• Issue Definition: An Issue is a current event that will

have a
(negative) impact on the Business Objectives of an Organisation
▪ E.g. An Incident, a manifested risk, an Audit Non-Compliance
finding, an Equipment or Supplier failure.
“It is Raining Today”
Source: Stephen Shippey 22nd April 2015
5
 Intro to Risk Management -continue
• Objectives of Generic Risk Management
▪ To ensure that all risks to the Business however they are
derived are managed effectively.
Strategic
Level Strategic Risk Register
Strategic
Risks

This includes:
•Strategic Risks Change
•Programme and Project Risks Level Project Risk
Programme/Project
•Operational Risks (includes Risks
Register
Security and Business
Continuity Risks) Operational
Risk
Operational Level Register
Business as Usual (BAU)
Information
Security
Operational Risks Risk
Register
BAU
Business
continuity

Source: Stephen Shippey 22nd April 2015

6
 Intro to Risk Management -continue
• Objectives of Information Security Risk Management
▪ To ensure that the risks to the Organisation that are derived
from, Incidents, Threats, Vulnerabilities and Audit non-
compliances are managed effectively.

▪ In Security Terms these are those risks that impact the:

• Confidentiality,
• Integrity,
• Availability, and the
• Traceability of Information whilst:
a. At rest
b. Whilst being modified
c. In transit (around a system, e-mail, media device, telephone etc.)

7
 Intro to Risk Management -continue
• A risk may have the same Risk Description but two separate
impacts dependent on the Owner.

• e.g. Risk: Patching may fail to complete in a timely manner

1. Impact on IT Service Provider: Potential Commercial
Penalties, Damage to Reputation.
2. Impact on Client: Loss of Systems, loss of information, loss
of revenue etc.

8
 Intro to Risk Management -continue
• What is NOT Risk Management
▪ Incident Management
▪ Audit Non-Compliances
▪ Problem Management
▪ Threat Management
▪ Vulnerability Management
▪ Exception / Waiver Management

These are Issues, no uncertainty!

However, they can be the Source of Infosec Risks

9
 Functional Requirement
• The Functional Requirements Specification documents the
operations and activities that a system must be able to
perform.
• Functional Requirements should include:
▪ Descriptions of data to be entered into the system
▪ Descriptions of operations performed by each screen
▪ Descriptions of work-flows performed by the system
▪ Descriptions of system reports or other outputs
▪ Who can enter the data into the system
▪ How the system meets applicable regulatory requirements

• The Functional Requirements Specification is designed to be

read by a general audience. Readers should understand the
system, but no particular technical knowledge should be
required to understand the document.
10
 Functional Requirement -continue
• Functional requirements should include functions performed
by specific screens, outlines of work-flows performed by the
system, and other business or compliance requirements the
system must meet.
• Examples of Functional Requirements:
▪ Interface requirements
• Field 1 accepts numeric data entry.
• Field 2 only accepts dates before the current date.
• Screen 1 can print on-screen data to the printer.

▪ Business Requirements
• Data must be entered before a request can be approved.
• Clicking the Approve button moves the request to the Approval
Workflow.
• All personnel using the system will be trained according to internal
SOP.
11
 Functional Requirement -continue
• Examples of Functional Requirements:
▪ Regulatory/Compliance Requirements
• The database will have a functional audit trail.
• The system will limit access to authorized users.
• The spreadsheet can secure data with electronic signatures.

▪ Security Requirements
• Members of the Data Entry group can enter requests but can not
approve or delete requests.
• Members of the Managers group can enter or approve a request
but can not delete requests.
• Members of the Administrators group cannot enter or approve
requests but can delete requests.

12
 Functional Requirement -continue
• Requirements outlined in the Functional Requirements
Specification are usually tested in the Operational
Qualification.

• The Functional Requirements Specification describes what

the system must do; how the system does it is described in
the Design Specification.

• If a User Requirement Specification was written, all

requirements outlined in the User Requirement
Specification should be addressed in the Functional
Requirements Specification.

13
 Functional Requirement -continue
• The Functional Requirements Specification should be signed
by the System Owner and Quality Assurance.

• If key end-users, developers, or engineers were involved

with developing the requirements, it may be appropriate to
have them sign and approve the document as well.

• Depending on the size and complexity of the program, the

Functional Requirements Specification document can be
combined with either the user requirements specification or
the design specification.

14
 Examples
• IT Risks – Entity Level Controls
▪ Lack of IT oversight by management.
▪ Lack of, or informal IT policies on security and operations.
▪ Compliance with laws and regulations regarding information
security and privacy.
▪ Lack of IT infrastructure inventory, including software and
hardware used (both onsite and remotely).
▪ Lack of an incident response plan to respond to any
information security incidents.
▪ Monitoring of third-party service providers.

15
 Examples -continue
• IT Risks – Change Management
▪ Integrity of production environment
• Changes that haven’t been well tested can have an unexpected
impact on systems.
▪ Integrity of the financial information
• Inaccurate data mapping can cause inaccurate reporting.
• Unintended changes to financial data.
▪ Availability of the systems
• Can cause business process disruptions and loss of revenue.

16
 Examples -continue
• IT Risks – Logical Access
▪ Access to financial applications
• Fraud
• Inaccurate information - poor business decisions
• Inappropriate access (e.g., payroll, intellectual property)
▪ Access to key production applications
• Disruption of the business processes
▪ Access to the network
• Disruption of the business processes
• Reputation risk

17
 Examples -continue
• IT Risks – Network Security
▪ Lack of network infrastructure documentation.
▪ Lack of firewalls, intrusion detection systems.
▪ Improper review of the content of internet messages for
appropriateness and to detect misuse of network resources.
▪ Processes over the updating of operating system “patches”.
▪ Use of a reputable anti-virus, anti-spyware and anti-spam
software.
▪ Not performing vulnerability scans and penetration tests of
critical systems.

18
 Examples -continue
• IT Risks – Computer Operations
▪ Problems and Incidents
• Identification
• Recording
• Tracking
• Reporting
▪ Job Processing
• Unprocessed information
• Operations Monitoring
▪ “Not Watching the Store”

19
 Examples -continue
• IT Risks – Backup and Disaster Recovery
▪ Loss of data
• Customer information
• Financial records
• Intellectual property
▪ Failure of key systems
• Hardware failure
▪ Loss of primary site
• Nature disaster
• Human error
• Malicious activity
▪ Access to backup data

20
 Risk Analysis Activities
• Specify the likelihood of occurrence of each identified
threat to asset and the given controls already in place.
• Specify what consequence if the threat does occur.
• Derive overall risk rating for each threat
▪ Risk = (probability threat occurs) x (cost to organization)
• It maybe hard to determine accurate probabilities and
realistic cost consequences therefore it maybe best using
qualitative then quantitative ratings.
• Two basic types of risk analysis
▪ Quantitative Risk Analysis
▪ Qualitative Risk Analysis

21
 Risk Analysis Activities -continue
• Quantitative Risk Analysis
▪ Attempts to establish and maintain an independent set of risk
metrics and statistics.
▪ Some of the calculations used for quantitative risk analysis:
• Annualized loss expectancy (ALE): Single loss expectancy
multiplied by annualized rate of occurrence.
• Probability: Chance or likelihood that an event will occur.
• Threat: An event, the occurrence of which could have an
undesired impact.
• Control: Risk-reducing measure that acts to detect, prevent, or
minimize loss associated with the occurrence of a specified
threat.
• Vulnerability: The absence or weakness of a risk-reducing
safeguard.

22
 Risk Analysis Activities -continue
• Qualitative Risk Analysis
▪ The most widely used approach to risk analysis.
▪ Makes use of a number of interrelated elements:
• Threats: Things that can go wrong or that can “attack” the
system.
• Vulnerabilities: Make a system more prone to attack or make an
attack more likely to have some success or impact.
• Controls: The countermeasures for vulnerabilities.
▪ A risk is real when there is a presence of threat, a vulnerability
that the attacker can exploit, and a high likelihood that the
attacker will carry out the threat.

23
 Risk Analysis Activities -continue
• Analyze Existing Controls
▪ Existing controls used to attempt to minimize threats need to
be identified.
▪ Security controls include:
• Management
• Operational
• Technical processes and procedures
▪ Use checklists of existing controls and interview key
organizational staff to solicit information.

24
 Risk Analysis Activities -continue
• Risk Treatment Vs Cost

25
 Risk Analysis Activities -continue
• Risk Treatment Alternatives
▪ Risk acceptance
• Choosing to accept a risk level greater than normal for business
reasons.
▪ Risk avoidance
• Not proceeding with the activity or system that creates this risk.
▪ Risk transfer
• Sharing responsibility for the risk with a third party.
▪ Reduce consequence
• Modifying the structure or use of the assets at risk to reduce the
impact on the organization should the risk occur.
▪ Reduce likelihood
• Implement suitable controls to lower the chance of the
vulnerability being exploited.

26
 Risk Control
• IT Control – Entity Level Controls
▪ Develop an IT Steering Committee to prioritize, review and
monitor information technology needs.
▪ Formalize IT policies and train staff on their content.
▪ Identify and ensure compliance with laws and regulations
regarding information security and privacy.
▪ Develop an IT infrastructure inventory.
▪ Adopt an incident response plan and establish a team to
respond to any information security incidents.
▪ If relying on third-party service providers, obtain the service
auditor’s (“SOC”) report and ensure all recommended
security, availability and privacy controls are in place.

27
 Risk Control -continue
• IT Control – Change Management
▪ Processes and procedures for changes
• Documented requirements
• Tracking of all requests
• Analysis of systems that will be impacted
• Security implications
▪ Testing
• Developer
• User
▪ Approvals prior to implementation of management
▪ Segregation of duties
• Can’t approve and implement changes
• Developers do not have update access to the production
environment

28
 Risk Control -continue
• IT Control – Logical Access
▪ Approval process for requesting access
• Document approval from HR and/or manager
• Grant access only to appropriate personnel based on business
needs.
▪ Unique user IDs for accountability
▪ Periodic review of access
• Job/function changes
▪ Removal of access
• Timely notification
▪ Encrypt data on servers, workstations, and mobile devices

29
 Risk Control -continue
• IT Control – Logical Access
▪ Passwords
• Complexity, change frequency, reuse, minimum length, lockout
provisions, etc.
▪ Application controls
• Segregation of duties
• File and folder level restrictions
▪ Ensure proper level of physical/environmental controls.
• Access controls to office/server room.
• Ensure cooling, fire suppression, UPS for servers and key
workstations.
▪ Limit administrator access to systems and applications.

30
 Risk Control -continue
• IT Control – Network Security
▪ Develop and maintain up-to-date network diagrams.
▪ Implement firewalls and intrusion detection systems.
▪ Use content filtering controls to review the content of internet
messages for appropriateness and to detect misuse of
network resources.
▪ Implement controls over the updating of operating system
“patches”.
▪ Use a reputable anti-virus, anti-spyware and anti-spam
software and routinely install updates as they become
available.
▪ Perform vulnerability scans and penetration tests of critical
systems.

31
 Risk Control -continue
• IT Control – Computer Operations
▪ Problems and Incidents
• Define and implement a problem management system to ensure
that operational events are recorded, analyzed, escalated and
resolved in a timely manner.
▪ Job Processing
• System processing jobs and batch feeds are documented in the
IT Operations Manual.
▪ Operations Monitoring
• Daily operations checklists are used to assist in monitoring
systems processing.

32
 Examples -continue
• IT Control – Backup and Disaster Recovery
▪ Backup and Disaster Recovery Controls
▪ Develop backup policy and disaster recovery plans
▪ Backups
• Tapes and disk arrays
▪ Testing of backups and disaster recovery plan
• Ensure files can be recovered when needed
▪ Off-site storage
• Tape shipment and replication
▪ Disaster recovery sites
• Hot, cold, other office location
▪ Encrypt backup data and ensure access to media is limited to
authorized personnel

33
Risk Assessment Report

34
Risk Assessment Report -continue

35
 Risk Assessment Report -continue
• Risk Assessment Results:

36
 Summary

• Have considered
▪ Intro to Risk Management
▪ Functional Requirement
▪ Examples
▪ Risk Analysis Activities
▪ Risk Control
▪ Risk Assessment Report

37
Recommended Textbooks and References

Recommended textbooks:
[1] Corey Schou, Steven Hernandez (2014). Information Assurance Handbook:
Effective Computer Security and Risk Management Strategies, ISBN-13:
978- 0071821650, McGraw Hill.
[2] Disaster Recovery (2011). EC-Council | Press. ISBN-13: 9781435488700,
Cengage Learning.

Recommended reference:
[1] Kim, Michael G.Solomon (2013). Fundamentals of Information Systems
Security (Jones & Bartlett Learning Information Systems Security &
Assurance), 2nd Edition, ISBN-13: 978-1284031621, Jones & Bartlett
Learning.

38