|
|||||
VU
Information
System (CS507)
Control
Analysis
This
phase includes assessment of controls
already been implemented or planned,
probability that
they
can be broken, assessment of
potential loss despite such
controls existing. Controls are
also
classified
as non-technical controls also
called management controls
and technical controls
software,
hardware controls. The
output of this step is
current or planned controls used
for the IT
system
to measure the likelihood of
vulnerability being exercised
and reduce the impact of
loss.
37.1
Likelihood
Determination
· This
phase determines that a
potential vulnerability could be
exercised by a given
threat-source.
Following table will help us
to define and understand the
likelihood
definitions.
Likelihood
level
Likelihood
Definition
The threat
source is highly
High
motivated
and sufficiently
capable
and
controls to prevent
the
vulnerability
from being exercised
are
ineffective
The threat
source is motivated
and
Medium
capable
but controls are in
place
that may
impede the successful
exercise of
the vulnerability.
The threat
source lacks
motivation
Low
or capability or
controls are in
place to
prevent or at least
significantly
impede the
vulnerability
from being exercised.
The
input to this phase
is
· Threat
source motivation
· Threat
capacity
· Nature
of vulnerability
· Current
Controls
The
output to this phase is a
likelihood rating to be used
further in the risk assessment
process.
37.2
Impact Analysis
This
phase determines the adverse
impact resulting from a successful
threat exercise of
vulnerability.
Following information is required before
conducting an impact analysis.
1.
System mission e.g. the
process performed by IT
system.
2.
System and data criticality
e.g. the system's value or
importance to an organization
3.
System and data
sensitivity
The
information can be obtained from existing
organizational documentation.
156
VU
Information
System (CS507)
Impact
needs to be measured by defining certain
levels. E.g. high medium low
as qualitative
categories
or quantifying the impact by using
probability distribution.
· Mission
Impact Analysis
· Assess
criticality assessment
· Data
criticality
· Data
sensitivity
The
output of this phase is impact
rating.
37.3
Risk Determination
The
purpose of this step is to assess
the level of risk to the IT
system. The determination
of
particular
threat can be expressed as a
function of
1. The
likelihood of a given threat-source's attempting to
exercise a given vulnerability
(system
flaw)
2. The
magnitude of the impact should a threat
source successfully exercise a
vulnerability
3. The
adequacy of planned or existing security controls
for reducing or eliminating risk.
This
phase also presumes the
definition of risk levels in order to
classify the risks. The is
more of a
discretionary
act on part of the
management. Levels can be defined as
high medium low
and
allocating various
probability ranges. Risk
levels are made to compare
them with the ranges
of
impact.
Level of Impact
Low Rs.
Medium
High Rs.
10,000
Rs.
100,000
50,000
Low
10,000
5,000
10,000
Threat
10%
x10% =
Likelihoo
1,000
d
Medium
3,000
15,000
30,000
30%
High
6,000
30,000
60,000
60%
Once
the risk of loss has been
determined using probability of occurrence and
level of impact,
such risk
amounts may then be
classified at the discretion of
management.
1.
Risk scale Low if loss is
less than Rs.
1,000
2.
Risk scale medium if loss is
less than > Rs. 1,000
but < Rs. 5,000
3.
Risk scale high if loss is
less than > Rs.
5,000
The
inputs of to this phase are
1.
Likelihood of threat
exploitation
2.
Magnitude of impact
3.
Adequacy of planned and current
controls
157
VU
Information
System (CS507)
The
output is the determination of risk
and associated risk
levels.
Control
Recommendations
In
this phase, controls that
could mitigate or eliminate the
identified risks appropriate to
the
organization's
operations. The control recommendations
are the results of the risk
assessment
process.
The control recommendations is actually
the risk mitigation
process.
37.4
Results Documentation
In
this phase, results should be documented
in a report or briefing.
Example-Risk
Management
The IS
security manager carries out a risk
assessment. The company employs 18
computer
terminals
in a two-storey building, containing
typical office furniture and
equipment. The focus
of
the
security manager is to see how the
computer assets can be protected
against possible threats.
The
approach followed by the
manager may include
searching the web pages,
organizational leaflet
and
more general publications, to learn where
hazards can occur. He may
walk around the
office
observing
what might pose a risk. He
may choose to talk to
supervisors and staff to learn
from
their
more detailed knowledge of areas
and activities, and to get concerns
and opinions about
IT-
related
issues.
After
the initial information
seeking phase, the manager
then wrote down how
computer
equipment
could be harmed by the hazards
and how. For each hazard,
the manager recorded
what
controls,
if any, were in place to manage
these hazards. She then
compared these controls to
the
good
practice guidance commonly
available on web or followed by
other organizations. Putting
the
risk
assessment into practice,
the manager decided and
recorded who was responsible
for
implementing
the further actions and
when they should be done.
When each action was
completed
it was
ticked off and the date
recorded.
At an
office meeting, the security manager
will discuss the findings
with the staff and
gave out
copies
of the risk assessment. The
manager decided to review
and update the assessment at
least
annually,
or straightaway when major
changes in the workplace occurred. This
example of risk
assessment
is intended to show the kind of
approach we expect a small business to
take. Every
business
is different and there is a
need to think through the
hazards and controls required in
that
particular
business.
37.5
Implementation
Once
the controls for managing
risk have been devised, reported
and accepted, the next
phase is to
prepare
for implementation. Making
controls part of the
information systems is a challenging
task
as it
requires the display of a
sense of ownership and
priority to the task in hand
by the
management
who act as the drivers for
the implementers and the
users.
37.6
Monitoring and
evaluation
Once
the controls have been
implemented, their effectiveness needs to
be monitored. An
evaluation
should also be made on regular
basis to see no. of threats neutralized,
threats not
properly
dealt with and the threats
identified but not taken
action against. Analyses like
these can
be
conducted so as to determine, whether the
cycle needs to be
repeated.
158
Table of Contents:
|
|||||