Transcript Risk Management

3. Risk Management
2006
Road Safety
An Example of Complex Improvement
Risk Management
Speed control
Supervision
Law enforcement
Protection
Helmet, belt…
Infrastructure
Signal power supply
Process efficiency
Braking system
Recovery
Surgery
2
Event
The Risk Chain
Pre-event
Hazard
• Prevention
• Detection
• Surveillance
Minimise
probability of
event
Exposure
• Risk Control
• Protection
• Insurance
Post-event
Resiliency Contingency
• Reactivity
• Robustness
• Adaptability
Minimise
damage if event
happens
• Restore
• Repair
• Adapt
Cope with the
damage caused
by the event
3
Mis on risk?
Riskina mõistame me ebasoovitava sündmuse ilmnemist.
Riski iseloomustavad tõenäosus ja mõju - seega on riski rahaline väljendus
funktsioon ebasoovitava sündmuse tõenäosusest ja sündmusega kaasnevast
kahjusummast.
Speculative and Hazard Risks
4
Threat and Risk
5
Riskide tüübid
•
•
•
•
Krediidirisk
Tururisk
Operatsioonirisk
...
6
Risk Management Paradigm
7
Function Diagram
8
Example Implementation
9
Continuous Risk Management
Application Roadmap
10
Method and Tool Content
11
What Is Identification?
12
Data Items
13
Data Items
14
Methods and
Tools
15
Operational Risk Is Integral To
Enterprise Risk Management
16
Business Risk
17
Operational Risk
• Operational risk is a form of hazard risk
affecting day-to-day businesses
operations and, as such, is one of the
many facets of business risk.
• Operational risk is the potential failure to
achieve mission objectives
18
Operational Risk Tolerance
• Operational risk
tolerance is the
maximum overall
exposure to
operational risk
that will be
accepted, given
the costs and
benefits involved.
19
Mission assurance
• Mission
assurance is
establishing a
reasonable
degree of
confidence in
mission success.
20
Categories of Operational Threat
21
Mission Threat
• The mission is the cornerstone of a work process and
defines what success looks like. If that picture is skewed
or flawed, the entire system could be out of balance and
produce unexpected, or unwanted, results.
– For example, if the technical objectives of a software
development project are overly ambitious in relation to its
budget, you will have to make difficult choices when beginning
the project.
– Lacking the requisite funds, you might be forced to cut back on
staff allocated to certain tasks, or you might decide to eliminate
certain equipment expenditures.
– Something, somewhere, has to give.
22
Mission Threat
• The consequences of your choices will not be felt
immediately, but somewhere during the course of the
project you will almost certainly encounter a crisis.
– When that crisis occurs, you will have to make some difficult
decisions. You might be forced to adjust the technical objectives
by aligning them more closely with the remaining budget.
– Or you might have to consider assuming a cost overrun for the
project.
– If the former is chosen, you will have the unpleasant task of
informing your customer that the software lacks some of its
promised features.
– If the latter is selected, your management will undoubtedly be
eager to hear your explanation for the budget overrun.
– The imbalance that existed from day one will have come full
circle and will require a change to the mission objectives.
23
Mission Threat
• A mission threat is a fundamental flaw, or
weaknesses, in the purpose and scope of
a work process.
• It injects considerable vulnerability into the
very foundation of a work process and
exposes it to a substantial amount of
operational risk.
24
Design Threat
• While the mission describes the goal, or
objectives being pursued, the design of a
process delineates the roadmap for achieving
the mission.
• It outlines the resources needed to complete the
job as well as all steps, decisions, and handoffs
required to execute the process successfully.
• A design threat is an inherent weakness in the
layout of a work process.
• It can have far-reaching consequences because
it embeds risk within the structure of a process.
25
Design Threat
• A bottleneck is an excellent example of a design
threat, illustrating how inefficiencies can be
designed into a process.
• The presence of a bottleneck means that the
flow of work products exceeds the capacity
designed into the process, which limits the flow
at a particular point in the process.
• Such restrictions cause the process to function
at a lower level of efficiency than required to
meet mission objectives and casts doubt on the
potential for success.
26
Activity Threat
• Whereas the mission and process design provide the
blueprint for operations, activity management is focused
on assembling, organizing, and overseeing the
resources needed to execute that plan.
• An activity threat is a flaw, or weaknesses, arising from
the manner in which activities are managed and
performed.
• This type of threat can result from a variety of sources,
ranging from people’s actions to unreliable performance
of support technologies. In essence, activity threats
occur when actual performance deviates from what was
planned or anticipated.
27
Activity Threat
• For example, think about what happens when
inexperienced people, who also have not
received adequate training and education for
their positions, staff a process.
• Do you expect novices to perform their assigned
tasks seamlessly?
• In all likelihood, they will be prone to making
mistakes and poor decisions, at least initially,
which puts the mission at risk.
28
Environment Threat
• In an ideal world, managers would be able to ignore the
outside world, focusing solely on the tasks at hand.
• However, processes are not executed in vacuums.
• Managers need to be keenly aware of their surroundings
and understand how environmental conditions can affect
their work.
• An environment threat is an inherent constraint,
weakness, or flaw in the overarching operational
environment in which a process is conducted.
• It represents an inherited source of threat, making it
especially difficult to manage in many instances.
29
Environment Threat
• Think about an organization plagued by low morale
among its staff.
• People who work in such environments tend to have
higher rates of absenteeism, often leaving key activities
short staffed.
• They may also take less pride in their work, choosing to
go through the motions each day.
• The end result of such apathy is poor performance,
which, of course, places mission objectives at risk.
• Although the manager of a given work process might not
be responsible for the root causes of low staff morale, he
or she must deal with its effects on process
performance, which will likely not be an easy task.
30
Event Threat
• Because our world is constantly changing, we must be on guard for
sudden events that can immediately derail progress.
• An event threat is a set of circumstances triggered by an
unpredictable occurrence that introduces unexpected change into a
process.
• A computer virus is a good example of an event threat.
• Many vulnerabilities are embedded in the computer systems that we
use every day.
• Some can affect a computer’s performance during routine use by
causing it to crash periodically.
• By contrast, others lie dormant within the computer’s operating
system and applications and do not produce any visible effect on the
computer’s performance during day-to-day operations.
31
Extrinsic and Intrinsic Risk
• Of the five categories of threat, event threats
stand out as being fundamentally different from
the others.
• With event threats, vulnerabilities do not directly
place a mission at risk; they are merely a conduit
for risk and lie dormant during normal business
operations.
• An event must combine with one or more of
these vulnerabilities to actually produce risk.
32
Extrinsic and Intrinsic Risk
• If there is no possibility of the event occurring, there is, by definition,
no risk. In this document, the risk produced by an event threat is
called extrinsic risk because its underlying trigger (i.e., the
occurrence of an event) occurs outside of expected or predictable
operational conditions.
• The mechanism responsible for generating extrinsic risk (i.e., an
event in conjunction with one or more vulnerabilities) also influences
its basic properties, which are measured using probability and
impact.
• In general, the probability associated with extrinsic risk is heavily
influenced by the likelihood that its triggering event will occur.
• As a general rule, events with the potential for producing very high,
often catastrophic, consequences have very low probabilities
associated with them.
33
Extrinsic and Intrinsic Risk
• By contrast, threats from the other four
categories (mission, design, activity, and
environment) do not require an external
trigger to produce operational risk.
• In this case, the mere act of conducting a
work process in combination with certain
vulnerabilities is sufficient.
34
Extrinsic and Intrinsic Risk
• The risk generated by these four
categories is called intrinsic risk because it
is an inherent part of process execution.
• The characteristics of intrinsic risk are
quite different from those of extrinsic risk.
35
Extrinsic and Intrinsic Risk
• For example, intrinsic risks are often more likely
to occur than extrinsic risks because the
stimulus needed to produce intrinsic risks (i.e.,
process execution) is always present.
• In addition, while extrinsic risk often produces
catastrophic consequences, experience shows
that intrinsic risks can cause a variety of
impacts, ranging from negligible to very high.
• Catastrophic impacts triggered by a specific
source of intrinsic risk, although possible, are
rare.
36
OR and Operational Excellence
• From an operating standpoint, these challenges
require a cross-enterprise excellence in at least
3 areas
– technology infrastructure
– business process architecture
– business process integration
• Efficiency and resilience are two sides of the
same coin
– For each $ spend on projects, there is an optimum
balance between efficiency and resilience
improvement objectives
Operational Risk
37
Risk Sources Ordered by
Importance
1. Lack of top management commitment
2. Failure to gain user commitment
3. Misunderstanding of requirements
4. Inadequate user involvement
5. Failure to manage end-user expectations
6. Changing scope and/or objectives
7. ….
38
Greater Risk of IT Failure
– Business transactions are increasingly dependent on IT, so
failures in IT are more likely to impact the business, and that
impact is more likely to be severe.
– The IT environment is increasingly complex, so even if the
environment stays the same size, the number of potential failure
points is rising.
– IT directly controls less of the infrastructure (“virtual IT
environment”), so managing the possibility of failure is more
important because IT has less ability to react after the failure
occurs.
– When an IT failure occurs, there is less time between the failure
and its impact on the business.
– IT failures are increasingly visible outside the data center, so
more people react negatively when a failure occurs.
39
Greater Risk of IT Failure
• IT today has more potential to enable
business than ever before, but failures in
IT have more potential to disable
business.
• At the same time, the traditional risk
management strategy of tight change
control is less often available, and less
often effective.
40
IT Downtime
• IT downtime joins other natural disasters
in business risk management.
• As IT “becomes” the facility, it is going to
raise new, unheard of risks.
– A slow Web site could be as disastrous as a
tornado.
41
IT Downtime
In a Stage 1 enterprise, the
interdependencies of business
processes, IT and external
entities are managed by
manual or non-IT interfaces.
Thus, if an IT system is not
available, it is not apparent to
customers or the supply chain,
and the business can muddle
along until the computers are
fixed.
42
IT Downtime
In Stage 2, IT has permeated
the business processes, so
when the computers are down,
the business processes come to
a halt. This inherently brings
more business risk to the
enterprise. Most large
enterprises have created some
level of dependency between
business processes and IT (any
ERP, HR, integrated financials
or sales management system
creates this business/IT process
interdependency).
43
IT Downtime
In stage 3, where
enterprises will be during
the next five years, the
business risk of IT is
maximum. The cost of
maintaining the integrity of
these systems will be
huge, but the cost of
downtime will be even
greater. There has never
been a more critical time
for massive efficiency in IT
systems.
44
IT Downtime
• IT is permeating the entire business function.
• IT is inextricably linking customers, suppliers,
business partners and government into a
seamless continuum of business activity.
• There are no insulating layers, where a
functional failure in one aspect of the business
can be an isolated incident.
• Not only are business processes interrelated,
they are becoming interdependent.
45
Threats to the Information Systems
• Availability - This is broadly
defined as having the resource
in a given place, at the given
time, and in the form needed
by the user.
• Confidentiality - Some define
this as "The concept of holding
sensitive data in confidence,
limited to an appropriate set of
individuals or organizations".
• Integrity - One can define this
as "The ability of an AIS to
perform its intended function in
a sound, unimpaired manner."
• The replacement cost
• The cost to recreate
intellectual property
• The value of an hour of
computing time.
• Other considerations
(embarrassment, loss of
confidence,…)
46
Implications
• Risk management should be integrated into
operations decision making in every job function
and every role.
• Risk management should be taken seriously and
given an appropriate amount of effort.
• Risk management should be done continuously
to ensure that operations is dealing with the risks
that are relevant today, not just the ones that
were relevant last quarter.
47
Characteristics of Risk
•
•
•
Risk is a fundamental part of operations. The only environment that has
no risk is one whose future has no uncertainty: no question of whether or
when a particular hard disk will fail; no question of whether a Web site’s
usage will spike or when or how much; no question of whether or when
illness will leave the help desk short-staffed. Such an environment does not
exist.
Risk is neither good nor bad. A risk is the possibility of a future loss, and
although the loss itself may be seen as “bad,” the risk as a whole is not. It
may help to realize that an opportunity is the possibility of a future gain.
There is no risk without opportunity, and no opportunity without risk.
Risk is not something to fear, but something to manage. Because risk is
not bad, it is not something to avoid. Operations teams deal with risks by
recognizing and minimizing uncertainty and by proactively addressing each
identified risk. If a loss is one possible future outcome, then the other
possible outcomes are gains, smaller losses, or larger losses. Risk
management lets the team change the situation to favor one outcome over
the others.
48
Principles of Successful Risk
Management
• Assess risks continuously. This means the team never stops
searching for new risks, and it means that existing risks are
periodically reevaluated. If either part does not happen, risk
management will not benefit the company.
• Integrate risk management into every role and every function.
At a high level, this means that every IT role shares part of the
responsibility for managing risk, and every IT process is designed
with risk management in mind. At a more concrete level, it means
that every process owner:
–
–
–
–
–
–
–
Identifies potential sources of risk.
Assesses the probability of the risk occurring.
Plans to minimize the probability.
Understands the potential impact.
Plans to minimize the impact.
Identifies indicators that show the risk is imminent.
Plans how to react if the risk occurs.
49
Principles of Successful Risk
Management
•
•
•
Treat risk identification positively. For risk management to succeed, team
members must be willing to identify risk without fear of retribution or
criticism. The identification of a risk means the team faces one less
unpleasant surprise. Until a risk is identified, the team cannot prepare for it.
Use risk-based scheduling. Maintaining an environment often means
making changes in a sequence, and where possible the team should make
the riskiest changes first. An example is beta-testing an application. If the
company wants 10 features to work, and two of them are so important that
the lack of either would prevent the application’s adoption, test those two
first. If they were to be tested last and either was to fail, then the team would
have lost the resources invested in testing the first eight.
Establish an acceptable level of formality. Success requires a process
that the team understands and uses. This is a balancing act. If the process
has too little structure, people may use it but the outputs won’t be useful; if it
is too prescriptive, people probably won’t use it at all.
50
Risk Management Process
The Risk Management Mindset
Identification
Retirement
2. “Java
skills not
high
enough.”
Project
finish
Project
finish
Risk 2
Risk 2
Risk 1
1. “May not be
possible to
superimpose
images
adequately.”
2. Retirement
by avoidance:
Use C++
Project
start
Risk 1
1. Retirement
by conquest:
Demonstrate
image superimposition
Project
start
52
Likelihood
1-10
Impact
1-10
Retirement cost
1-10
1 = least
likely
1 = least
impact
1 = lowest
retirement
cost
The
highest
priority
risk
10
(most
likely)
10
(most
impact)
The
lowest
priority
risk
1
(least
likely)
1
(least
impact)
Compute
risk
priorities
(example)
1
(lowest
retirement
cost)
10
(highest
retirement
cost)
Priority
computation
Resulting
priority
Lowest
number
handled
first
(11-10)
*(11-10)
*1
1
(11-1)
*(11-1)
*10
1000
53
Sample Risk Analysis
#
1
Risk title
(details given
above)
Superimposing
images
Likelihood
1-10
Impact
1-10
Retirement
cost
1-10
1=least likely
1=least
impact
1=lowest
retirement
cost
3
10
1
Priority
3
.
.
9
6
8
Responsible
engineer
Target
completion
date
lowest
number
handled
first
8
Experiment with
Java images.
P. R.
12.01.05
80
H.T., K.M., V.I. and
L.D. to attend
training course
beginning 1/5/05 at
Ultra Training Corp,
obtain Java level 2
certification by
3/1/05 and level 3
certification by
4/1505
H. L.
14.04.04
S.F.
Continual
2
Deficient
Java skills
Retirement / mitigation
plan
Alan Gray
may be
pulled off
this project
3
7
9
288
Susan Ferris to
inspect all of Alan's
work
...
...
...
...
...
...
...
...
54
Process Overview - the proactive
risk management process
1
2
Identify
Retired
Risk
List
5
Analyze
Risk
Assessment
Document
Control
Top
n
Risks
4
3
Plan
Track
55
Five Steps of Risk Management
•
•
•
•
•
Step 1: Risk Identification
Step 2: Risk Analysis
Step 3: Risk Action Planning
Step 4: Risk Tracking
Step 5: Risk Control
56
Step 1: Risk Identification
• Team identifies the components
of the risk statement:
1
–
–
–
–
–
Condition
Operations consequence
Business consequence
Source of risk
Mode of failure
57
Riskide identifitseerimine
Kui sa ei tea mida pead juhtima, siis sa ei saa ju
juhtida …
-kontrollikeskkond
-tegijad on eksperdid
Kui enda teadmistest jääb puudu, siis kasutatakse
ka väliseid eksperthinnanguid (due diligence, risk
surveys, ...)
58
Source of Risk
• People. Everyone makes mistakes, and even if the
group’s processes and technology are flawless these
human errors can put the business at risk.
• Process. Flawed or badly documented processes can
put the business at risk even if they are followed
perfectly.
• Technology. The IT staff may perfectly follow a perfectly
designed process, yet fail the business because of
problems with the hardware, software, and so on.
• External. Some factors are beyond the IT group’s
control but can still harm the infrastructure in a way that
fails the business. Natural events such as earthquakes
and floods fall into this category, as do externally
generated, man-made problems such as civil unrest,
computer virus attacks, and changes to government
regulations.
59
Risk factors
• Project risks
• System/Technology Risks
60
Project risks
• Scope creep
• Cost/time overruns
• People
61
System/Technology Risks
•
•
•
•
•
•
•
•
Downtime risks
Performance risks
Installation/deployment risks
Support risks
Infrastructure integration/interoperability risks
Standards risks
Communications risks
Training risks
62
Mode of Failure
• Cost. The infrastructure can work properly, but at too
high a cost, causing too little return on investment.
• Agility. The infrastructure can work properly, but be
unable to change quickly enough to meet the business
needs. Capacity problems are the most obvious case.
– For example, someone might have a dozen new servers ready
to support increased processing needs, but forget that the
cooling systems in the data center were already at peak
capacity, and upgrading those systems will take a month.
• Performance. The infrastructure can fail to meet users’
expectations, either because the expectations were set
wrong, or because the infrastructure performs
incorrectly.
• Security. The infrastructure can fail the business by not
providing enough protection for data and resources, or
by enforcing so much security that legitimate users can’t
63
access data and resources.
The risk statement
Operations
Consequence
Source of
Risk
Security
Performance
Agility
Cost
Mode of
Failure
Condition
... then
operations will
suffer this
loss of
performance ...
People
Process
Technology
External
If people do
this ...
Business
Consequence
... which will
harm the
business in this
way...
64
Risk Statement Form
• Role or function. The service
management function most directly
involved with the risk situation.
• Risk context. A paragraph containing
additional background information that
helps to clarify the risk situation.
• Related risks.
65
Step 2: Risk Analysis
• Risk Probability
• Risk Impact
• Risk Exposure - is the
result of multiplying the
probability by the impact
2
1
2
Identify
Retired
Risk
List
5
Analyze
Risk
Assessment
Document
Control
Top
n
Risks
4
Track
3
Plan
66
Riskide analüüs
Kui oled riskid identifitseerinud, siis
- tõenäosuse mõõtmine
- mõju hindamine
67
Step 3: Risk Action Planning
Mitigations
3
– Reduce. Risk reduction minimizes the risk’s probability or its
impact, or both. For example, redundancy generally reduces
the impact of failure. If one component fails there is no impact
because the redundant component is still working. Keeping
track of those components’ expected lifespan and replacing
them before they’re expected to fail reduces the probability of
the failure. Ideally, a reduction method reduces probability or
impact to zero, but this is not always possible.
– Avoid. Risk avoidance prevents the team from taking actions
that increase exposure too much to justify the benefit. An
example is upgrading an unimportant, rarely used application
on all 50,000 desktops of an enterprise. In most cases, the
benefit doesn’t justify the exposure, so IT avoids the risk by
not upgrading the application.
– Transfer. Whereas the avoidance strategy eliminates a risk,
the transference strategy often leaves the risk intact but shifts
responsibility for it to another group. For example, a company
with an e-commerce site might outsource credit verification to
another company. The risks still exist, but they become the
outsource partner’s responsibility. However, if the outsource
partner is better able to perform credit verification, then
transferring the risks can also reduce them.
68
RISKIDE leevendamine
Kui riski rahaline väljendus on leitud, küsime endalt:
- kes teeb otsuse?
- strateegia kujundamine
- kas risk on aktsepteeritav?
- kas tänane riskijuhtimise tase on piisav?
- on veel midagi vaja ette võtta?
- tegevusplaan maandamiseks
- vastavuses defineeritud riskiprofiiliga
- kuluefektiivne
69
Step 4: Risk Tracking
4
This step monitors three main changes:
• Trigger values. If a trigger becomes
true, the contingency plan needs to be
executed.
• The risk’s condition, consequences,
probability, and impact. If any of these
change (or are found to be inaccurate),
they need to be reevaluated.
• The progress of a mitigation plan. If
the plan is behind schedule or isn’t
having the desired effect, it needs to be
reevaluated.
70
Monitooring
Peale riski leevendamise tegevuste elluviimist:
- kas nüüd on risk aktsepteeritaval tasemel?
- kontrollikeskkond - kas saame tegijaid usaldada või
peame auditeerima?
- riskide kontrollide testimine
- riski indikaatorid
- tagasiside
71
Step 5: Risk Control
5
The controlling step executes a planned
reaction to the change:
• If a trigger value has become true, then
execute the contingency plan.
• If a risk has become irrelevant, then retire the
risk.
• If the condition or a consequence has
changed, then redirect to the identification
step to reevaluate that element.
• If the probability or impact has changed, then
redirect to the analyzing step to update the
analysis.
• If a mitigation plan is no longer on track, then
redirect to the planning step to review and
revise the plan.
72
Kontroll
Riski indikaatorid
Riski indikaatorid on ettevõtte erinevaid valdkondi
iseloomustavad arvulised suurused, mis korreleeruvad riski
suurusega.
Me kasutame neid indikaatoreid kui varase hoiatuse signaale.
Siinjuures on tähtsaim mitte mingi näitaja absoluutväärtus vaid
selle trend.
Näited - personali voolavus, motivatsiooni tase, IT süsteemide
maasoleku aeg, mitteresidentidest klientide arv, väljamüüdud
teenuste maht, …
… aga ka makromajanduse näitajad nagu jooksevkonto
defitsiit, tööpuuduse tase, keskmise palga kasv jms
73
Risk Analysis Template
74
Riskide juhtimise meetodid
Information Security Expenditures
•
•
•
•
•
•
•
% of passwords cracked via password cracking tools;
% of production environments not separate from test environments;
number of hours/days needed to recover from an incident;
number of months since last InfoSec policy review;
% of applications/environments with no audit trail;
% of desktops/servers with old virus signature files;
% of access requests received outside of the normal request
process;
• % of user password resets done by help desk;
• % of development personnel having access to production
• % of servers not in physically secure rooms;environment;
76
Metrics information security policies.
• Establish critical effectiveness metrics for
each information security policy.
• Ensure audit logs are in place for all
mission-critical applications and systems.
• Begin moving toward a centralized log
entries.
77
Riskide juhtimise meetodid
78
Riskide juhtimise meetodid
Riskijuhtimise meetodid on praktilised tegevused
ja abinõud mida kasutatakse kokkulepitud
strateegiate elluviimiseks.
Kõige olulisemad ja efektiivsemad meetodid:
- duaalsus
- funktsioonide lahusus
- tehingulimiidid
- varukoopiad
- back-up süsteemid
- dokumenteerimine
- riskiteadlikkuse tõstmine
- kindlustus
79
Riskide juhtimise strateegiad
Riskide juhtimise strateegiad
81
Riskide juhtimise strateegiad
Riskijuhtimise strateegia on sisuliselt otsus selle
kohta, mida me selle riskiga ette peaksime võtma.
On neli peamist strateegiat:
- leevendamine (=optimeerimine)
- aktsepteerimine
- vältimine (=minimeerimine)
- välja müümine (=transfer, finantseerimine)
82
Mitigation Strategy Planning (MSP)
83
Approaches to Risk Management
84
Operational Resilience:
A New Step for Technology
• Increased sophistication of both businesses and systems has
created vulnerabilities in our modern communication, co-operation
and information-based economies.
• We have made our information technology incredibly powerful, fast,
and reliable. Now, in order to contain the risks technology complexity
and dependency have generated within acceptable levels, we need it
to be resilient.
• Operational Resilience is the ability of systems, resources and
processes to effectively support a business under any sudden
adverse or unexpected condition.
• The IBM Operational Resilience SolutionTM is a set of offerings,
techniques and capabilities whose aim is to maximize the
Operational Resilience of organisations, considered within their
network of inter-dependencies.
85
Towards Maximal Resiliency
Availability and Adaptability
Level I
Level II
Level III
Level IV
Protection,
Redundancy, and
Back-up
Static Recovery &
Reconfiguration
Dynamic Recovery
& Reconfiguration
Intelligent
Adaptation
Business Structure
Processes
Systems
Resources
Infrastructure
86
OR as a major challenge for
Institutions
• Improve efficiency
Agility
– Implement end-to-end automation
– Optimise cost structure and effectiveness
– Optimise resource allocation
• Improve “agility” (dynamic differentiation)
Efficiency
– Leverage knowledge and relationships
– Optimise value-chains and value-nets
– Dynamically adapt to environmental and strategic changes
Resilience
• Improve resilience
– Manage operational risks
– Reduce overall business vulnerability
– Develop capabilities to quickly adjust, adapt, or switch operating
mode when circumstances require
… under increased resource constraints
87
Näide: Eesti Ühispank
Operatsioonirisk
•
•
•
Operatsiooniriski all mõistetakse riski, mis sisemiste (ebaefektiivsed protseduurid,
puudulikud infosüsteemid, personali pädevus ja lojaalsus jne.) või väliste
(reputatsiooni langus, kriminaalsed aktid, katastroofid) tegurite mõjul võib häirida
panga äritegevust või viia ootamamtute kahjumite tekkeni.
Ebaefektiivsetest
protseduuridest
tuleneva
riski maandamiseks
kasutab pank standardset protseduuri, mis peab tagama toote igakülgse
kaetuse lepingute (juriidiline risk), kontrolltoimingute ja
tõese
raamatupidamisliku kajastamisega. Peale toote juurutamist viib sisekontrolli
osakond
regulaarselt
läbi kontrolle
kehtestatud protseduurist kinnipidamise
tagamiseks. Operatsiooniriskide kvantifitseerimiseks tulevikus töötab
riskijuhtimise osakond erinevate metoodikate kallal, uurides võimalusi nende
kohaldamiseks kohalikele oludele.
Eesti Ühispanga suhtes kehtivad Skandinaviska Enskilda Banken AB poolt sõlmitud
ja SEB tütarettevõtjatele laienevad kindlustuslepingud, millega on kindlustatud:
–
–
–
–
panga töötaja või kolmanda isiku poolt toime pandud kuriteo tagajärjel (nt. võltsimine,
röövimine, vargus, kelmus) tekkinud varaline kahju;
panga igapäevase majandustegevuse käigus panga töötaja hooletuse, vea või tegevusetuse
tõttu tekkinud varaline kahju;
panga juhatuse liikme või töötaja ebaseadusliku teo tagajärjel tekkinud kahju;
panga tegevuse tõttu kolmandale isikule tekkinud kahju.
89
Infotehnoloogilised riskid
• Infotehnoloogiliste riskide juhtimise eesmärk:
• on Eesti Ühispanga informatsiooni turvalisuse tagamine ning sellega
seoses panga ärikriitiliste protsesside katkemist ja ärikahjude
tekkimist tingivate turvasündmuste vältimine.
• Infotehnoloogiliste riskide juhtimise organisatsioon.
Eesti Ühispanga Operatsiooniriskikomitee on Eesti Ühispanga
turvatööd, tehnoloogilise kvaliteeti juhtimise ning tehnoloogiliste
riskide hindamist suunav ja koordineeriv organ, mis tegutseb Eesti
Ühispanga Juhatuse poolt antud volituste piires.
• ÜP andmeturbe grupp tagab riskide hindamise ja juhtimise IT
valdkonnas.
• Eesti Ühispanga IT infrastruktuur.
• Eesti Ühispanga IT infrastruktuur tagab Eesti Ühispanga andmete ja
infosüsteemide turvalisuse vastavate tehnoloogiliste meetmete
(tulemüürid, ründetuvastus ja –peletus, viirusekaitse, pääsupoliitika
rakendamine jmt) rakendamisega.
90
Infotehnoloogiliste riskide analüüs
•
•
Eesti Ühispanga Operatsiooniriski poliitika realiseerub riskianalüüsi põhjal
kehtestatud turvanõuetele vastavate turvameetmete rakendamise kaudu.
Kõikide uute pangatoodete evitamisele eelneb nende toodete
infotehnoloogiliste riskide analüüs, vajaduse korral modifitseeritakse toote
infotehnoloogilist tuge nii, et toode vastaks tarvilikule turvatasemele.
Infoturbe projekteerimine koosneb järgmistest etappidest:
–
–
–
–
–
–
–
–
–
Infovarade ja nende valdajate määramine
Infovarade turvanõuete määramine
Jäme riskianalüüs
Turvameetmete määramine – vajaduse korral detailne riskianalüüs ja
turvameetmete täsustamine
Jääkriskide aktsepteerimine
Infoturbe käigushoid:
Muudatuste/intsidentide seire/haldus
Infoturbe perioodiline akrediteerimine
Infoturbe intsidentide käsitlemine
91
Kokkuvõte
JUHATUS
Aktsepteeritud
risk
TURVAPROTSESS
otsus
Oht
Nõrkus
Jääkrisk
realiseerub
Vara
TURVAKLASS
Intsident
tõenäosus
Kahju
RISK
Turvameetmed
Valdaja
92