1. INFORMATION
RISK
SECURITY
MANAGEMENT:
A
Model
and
Metrics
By
Vladimir
Jirasek, Information
Risk
Management
Evangelist
Contents
Page
Section
1:
Introduction
2
1.1
The
Security
Governance,
Risk
and
Compliance
(GRC)
model
2
1.1.2 Security
Drivers
2
(i) Laws
and
regulations
2
(ii) Business
objectives
2
(iii) Security
threats
3
1.1.3 Security
Management
3
(i) Policy
framework
3
a. Policies
3
b. Standards
3
c. Artefacts
3
(ii) Processes
framework
3
(iii) Security
metrics
framework
3
1.1.4 Stakeholders
4
Section
2:
Security
Drivers
4
2.1
Business
objectives
4
2.2
Legal
and
regulatory
requirements
4
2.3
Security
threats
4
Section
3:
Security
Management
5
3.1
The
Policy
framework
5
3.1.1
Information
security
policy
5
3.1.2
Data
classification
policy
5
(i)
Public
data
5
(ii)
Company-­‐wide
data
6
(iii)
Restricted
access
data
6
3.1.3
Employee
acceptable
policy
6
3.1.4
Information
technology
security
policy
6
3.2.
Security
standards
7
3.2.1
International
standards
for
security
policy
and
controls
7
3.2.2
Information
technology
standards
7
3.3
Security
architecture
repository
8
3.4
Process
frameworks
and
metrics
8
3.4.1
Security
processes
8
3.4.2
Security
metrics
8
(i)
Value
at
Risk
9
Conclusion
10
About
the
Author
10

2. Section
1:
Introduction
Information
risk
security
management
is
an
area
that
is
constantly
moving
to
respond
to
new
threats,
standards
and
technologies.
Security
is
now
a
part
of
information
risk
management,
which
in
turn
has
a
place
in
the
overall
business
risk
management
strategy.
This
document
explains
a
security
model
that
supports
business
needs,
and
explores
how
security
professionals
could
change
their
mindsets
to
help
ensure
future
job
security.
1.1
The
Security
Governance,
Risk
and
Compliance
(GRC)
model
Figure
1
below
describes
a
security
model
that
introduces
the
topic
of
security
to
business
managers
and
CIOs.
Figure
1:
Security
GRC
model
Feedback:
update
business
requirements
SECURITY
MANAGEMENT
DRIVERS STAKEHOLDERS
Correction
of
security
processes
CEO
&
Board
International
Policy
framework Process framework Metrics
framework Governance
security
standards Information
Information
Information
Line
Security
Security
Security
management
policies
processes metrics
Laws
&
objectives
regulations Information
Product
Drivers Security
Rules Measure Inform management
Technology
standards Security
People
Define
metrics
portal Program
Information
management
Compliance security
requirements architecture
Risk
&
DEFINE
security
EXECUTE
security
MEASURE
security
compliance
Business
controls controls controls
maturity
objectives
Auditors
Security
Security
threats intelligence Security
External
professionals
security
metrics
The
model
describes
three
main
areas:
(1)
Security
drivers;
(2)
Security
management;
(3)
and
Stakeholders.
1.1.5 Security
Drivers
The
three
major
drivers
for
security
are:
(i)
Laws
and
regulations:
A
company
must
comply
with
these
or
face
legal
action
or
a
fine.
For
example,
the
Data
Protection
Act
and
the
Company
Act
are
examples
of
the
legal
drivers;
PCI
DSS
is
an
example
of
a
regulation
driver.
(ii) Business
objectives:
Companies
typically
want
to
generate
profit
and
define
a
set
of
business
objectives.
Security
supports
these
business
objectives
by
protecting
systems
and
information
used
in
the
business
processes.
Think
of
protecting
Microsoft
Windows
source
code:
if
the
source
code
was
not
protected
anyone
could
compile
their
own
operating
system
without
paying
Microsoft
any
license
fee.
Hence,
Microsoft’s
business
objective
to
‘Sell
software’
is
supported
by
the
security
objective
‘Protect
source
code’.
Similarly,
Amazon’s
business

3. objective
is
to
sell
products
in
their
online
shop;
their
business
objective
is
to
have
an
online
shop
up
24/7;
the
security
objective
is
to
keep
systems
free
of
malware
that
could
disrupt
or
slow
down
IT
systems.
(iii) Security
threats:
Security
threats
work
against
laws
and
regulations
and
business
objectives.
However,
they
also
drive
information
security,
and
companies
need
to
respond
to
threats
in
order
to
satisfy
first
two
drivers.
1.1.6 Security
Management
Within
this
area
there
are
three
frameworks
that
enable
a
company
to
achieve
the
objectives
defined
in
the
‘drivers’
section:
(i) Policy
framework
This
is
a
set
of
policies,
standards
and
guidelines
that
describe
how
a
company
addresses
information
security
drivers,
and
define
the
security
controls
available
for
a
company
to
implement.
There
are
also
international
standards
that
can
be
source
of
information
and
control
for
the
Policy
framework.
a.
Policies
–
also
known
as
Security
Control
Objectives,
these
typically
use
words
such
as
‘should’
and
‘must’.
The
key
objective
of
the
security
policy
document
is
alignment
with
the
business
objectives
and
drivers.
b.
Standards
–
detailed
Security
controls
that
should
be
implemented
to
support
individual
policy
statements;
one
policy
statement
can
be
supported
by
multiple
security
controls.
These
should
be
linked
to
a
policy,
otherwise
the
security
professional
will
be
unable
to
justify
why
a
password
needs
to
be
12
characters
and
change
every
45
days,
for
instance.
The
controls
should
be
selected
from
an
internationally
accepted
catalogue
of
controls
(see
section
below
on
‘International
Standards’).
c.
Artefacts
–
Architecture
standardisation
is
the
key
to
the
success
of
any
company,
and
the
same
applies
to
security.
If
a
solution
to
implement
a
security
control
is
found
in
the
‘Standard’,
it
should
be
put
it
into
a
‘Security
Architecture
Repository’.
That
way,
others
can
benefit
and,
more
importantly,
consistent
security
is
achieved.
Many
security
professionals
do
not
document
artefacts
into
a
shared
library,
which
can
often
result
in
problems
when
they
leave
the
company.
(ii) Processes
framework
This
section
in
Security
Management
implements
what
is
stated
in
the
Policy
framework.
Any
security
control
in
a
policy
or
standard
is
a
process,
no
exceptions.
Each
process
is
supported
by
people
and
most
are
supported
by
technology.
However,
there
needs
to
be
a
link
between
any
technology
the
company
has,
its
process,
and
the
corresponding
control
in
the
Policy
framework
up
to
the
business
objective.
This
enables
traceability
of
the
security
investment
and
allows
security
professionals
to
justify
security
budgets.
(iii) Security
metrics
framework
This
is
a
developing
area
of
information
security
management.
The
common
adage
–
‘what
cannot
be
measured,
cannot
be
managed’
–
can
be
applied
equally
well
to
security.
Security
professionals
should
be
able
to
measure
the
status
of
security
controls,
the
compliance
with
their
own
policies,
and
the
effectiveness
of
security
processes.
The
key
metric
is
to
take
a
security
policy
statement
and
measure
each
team
against
it;
this
will
provide
a
balanced
scorecard
for
security.
The
metrics
framework
provides
feedback
to
the
Process
framework,
to
assist
with
security
processes
design.
1.1.7 Stakeholders
Stakeholders
are
the
recipients
of
the
security
metrics
framework
results.
The
stakeholders
need
to
know
that
what
has
been
promised
is
being
delivered.
More
importantly,
the
security
professionals
need
to
show
the
value
of
security
to
the
business.
This
is
an
area
where
security
professionals
need
to
enhance
their
skills;
they
need
to
talk
to
stakeholders,
uncover
their
concerns,
and
show
them

4. that
they
are
being
addressed.
This
should
be
followed
by
a
report
that
relates
to
their
specific
area
and
concerns;
they
need
to
see
that
security
personnel
are
on
their
side!
Section
2:
Security
Drivers
2.1
Business
objectives
Security
professionals
exist
to
support
the
business.
Companies
are
driven
by
their
vision
and
mission
statements,
translated
into
business
strategies
that
describe
how
to
achieve
that
vision.
The
business
objectives
define
how
the
organisation
wants
to
achieve
its
targets.
If
a
business
objective
is
to
‘Supply
customers
with
the
goods’,
the
security
objectives
should
be
to
protect
the
process
of
supplying
the
customer.
This
clear
link
between
business
and
security
objectives
can
sometimes
be
missing.
2.2
Legal
and
regulatory
requirements
Businesses
need
to
comply
with
legal,
regulatory
and
contractual
requirements
(listed
in
order
of
impact).
Legal
requirements
are
typically
related
A
practical
example
to
the
way
the
company
is
governed,
how
it
A
telecommunication
company
sells
mobile
phones
prepares
its
accounts
and
how
it
protects
the
and
call
plans
to
its
customers.
One
of
its
objectives
is
personal
data.
In
the
UK,
the
Company
Act
2006,
to
‘Deliver
outstanding
customer
service,
measured
by
‘part
15
Accounts
and
reports’,
states
clearly
the
customer
satisfaction’.
This
objective
is
supported
by
a
requirements
relating
to
how
accounts
are
business
process
‘Customer
service’,
whereby
customer
created
and
reported.
It
also
includes
penalties
service
representatives
in
shops,
call
centres
and
online
talk
to
customers
to
solve
their
problems
and
answer
for
untrue
and
misleading
accounts.
In
the
USA,
questions.
the
Sox
legislation
was
created
after
major
financial
scandals.
The
Data
Protection
Directive,
Customer
satisfaction
is
dependent
on
a)
speed
to
Principle
7,
states
that
access
to
data
must
be
initial
contact,
and
b)
completeness
of
response.
The
limited
to
the
authorised
persons.
And
although
information
security
risks
identified
are:
1)
information
the
Data
Protection
Directive
does
not
state
systems
unavailable
or
slow
so
the
initial
response
time
is
affected;
2)
information
in
the
knowledge
base
which
security
controls
should
be
implemented,
system
is
inaccurate;
and
3)
the
customer
data
in
the
the
guidance
states
that
there
are
CRM
system
becomes
compromised,
resulting
in
a
fine
internationally
accepted
standards
relating
to
and
bad
PR.
building
information
security
systems
in
a
company.
From
this
quick
risk
analysis,
it
is
easy
to
understand
where
the
information
security
policy
needs
to
focus
and
what
the
security
objectives
should
be.
As
a
result
of
this
legislation,
any
information
security
system
implementation
must
protect
data
and
information
systems
so
that
they
are:
a)
accurate
(in
security
terminology
the
word
‘Integrity’
is
used)
b)
available,
and
c)
access
to
the
content
is
assured
(‘Confidentiality’
in
security
terminology).
2.3
Security
threats
Security
threats
affect
the
level
of
protection
(i.e.
control)
that
is
needed.
Threats
come
from
attackers
who
want
to
either
acquire
information
or
limit
business
opportunities
by
affecting
business
processes.
Microsoft
has
created
a
very
good
methodology
(STRIDE)
for
assessing
threats
and
designing
security
controls
to
prevent
threats
from
harming
business
processes.
The
role
of
the
security
model
is
to
capture
security
threats
and
design
security
objectives
and
controls
to
protect
the
business.
Security
intelligence
is
the
capability
to
analyse
security
threats
and
advise
what
controls
should
be
included
in
the
policy
framework.

5. Section
3:
Security
Management
3.1
The
Policy
framework
This
is
the
first
element
of
the
‘Security
Management’
part
of
the
model.
The
Security
Policy
is
usually
not
a
single
document,
and
rightly
so.
The
documents
in
the
Security
Policy
library
have
different
audiences
and
levels
of
detail;
see
Figure
2
below.
Figure
2:
Information
Security
Policy
framework
CISO Business
and
Information
security
policy security
objectives
Data
classification
Employee
acceptable
policy use
policy
CIO
Information
technology
security
policy Security
objectives
IT
Security
IT
security
standards
[reuse
Architecture
internationally
accepted
controls] Controls
Technology
and
Security
Technical
teams processes
architecture
repository Processes
Security
guidelines
3.1.1
Information
security
policy
The
primary
objective
of
the
Information
security
policy
is
to
state
business
objectives
and
high
level
security
objectives.
The
document
also
sets
accountabilities
for
ensuring
the
security
objectives
are
met.
The
document
should
be
owned
by
CISO
or
CSO
but
approved
by
the
Board;
as
the
Board
is
responsible
for
approval
of
business
strategy
and
objectives,
the
protection
of
these
are
obviously
in
the
Board’s
interest.
3.1.2
Data
classification
policy
The
top
level
policy
should
also
make
provision
for
a
data
classification
scheme,
which
can
then
be
detailed
in
the
Data
classification
policy.
Data
classes
depend
on
the
nature
of
the
business
but
at
the
minimum
should
include:
(i)
Public
data
that
are
in
the
public
domain.
It
is
a
mistake
to
assume
that
public
data
do
not
need
any
protection.
For
example,
take
a
company
homepage;
typically
this
is
information
that
a
company
wants
to
share
with
the
world,
i.e.
it
is
‘Public’.
But
what
happens
if
the
information
on
the
website
changes
without
authorisation?
Examples
can
range
from
defacing
of
the
website,
to
unintentional
mistakes
by
employees,
mixing
the
product
description,
changes
in
prices
of
the
products
etc.
The
public
information
usually
needs
to
be
‘accurate’
and
‘available’,
but
obviously
there
is
no
requirement
to
keep
the
information
‘confidential’.
(ii)
Company-­‐wide
data:
this
type
of
information
can
be
shared
between
employees
and
people
who
have
signed
an
NDA.
This
is
by
far
the
largest
category
of
information
in
most
organisations.
It
is
also

6. referred
to
as
‘semi-­‐public’,
and
the
bigger
the
organisation
the
greater
the
probability
of
leakage
from
employees
or
partners.
(iii)
Restricted
access
data:
some
information
will
be
accessible
on
a
need-­‐to-­‐know
basis,
depending
on
the
type
of
business.
Business
plans,
strategy,
research
data,
and
new
product
details
are
just
some
examples
of
the
information
that
should
be
well
protected.
3.1.3
Employee
acceptable
policy
This
policy
document
should
spell
out
the
most
important
policies
for
employees.
Good
security
and
HR
professionals
do
not
expect
users
to
remember
all
policy
documents.
The
objective
of
this
document
is
to
show
employees
what
is
critical
and
where
to
find
more
information.
3.1.4
Information
technology
security
policy
Most
companies
rely
on
information
technology
to
run
the
business
processes.
The
role
of
CIOs
has
become
to
support
business,
understand
where
the
company
wants
to
expand,
and
suggest
how
to
become
more
agile
and
cost
effective.
IT
can
be
a
saviour
or
a
nightmare,
depending
on
the
abilities
of
the
CIO.
The
security
policy
for
the
CIO
team
needs
to
translate
business
objectives
into
security
objectives
and
controls,
as
shown
in
Figure
3
below.
Figure
3:
Relationship
between
business
objectives
and
security
processes
Provides
response
to
‘Do
we
have
all
business
risks
covered?’
International
standards
Control
C1
Control
C2
Security
Security
objective
SO1 Control
C3 process
P1
Business
Control
C4
objective
BO1 Security
objective
SO2 Control
C5 Security
Business
process
B3
Business
process
B1
Business
process
B2
Business
process
P2
Control
C6
objective
BO2 Security
objective
SO3 Control
C7
Business
Security
Control
C8
objective
BO3 objective
SO4 Security
Control
C9
process
P3
Control
C10
Security
Security
objective
SO5 Control
C11 process
P4
Provides
response
to
‘Why
are
we
doing
this?’
The
figure
shows
how
business
objectives
on
the
left
influence
security
objectives.
Each
security
objective
then
has
several
security
controls
(C1
to
C11)
and
these
are
implemented
by
security
processes.
Lastly,
the
business
processes
are
protected
by
the
security
processes.
Such
a
model
answers
two
critical
questions:
a)
Do
we
have
all
business
risks
covered?
b)
Why
are
we
spending
money
on
the
security
controls?

7. Examples
of
security
objectives
are:
§ Establish
security
governance
§ Provide
security
training
§ Manage
access
to
information
§ Keep
systems
resistant
to
malware
§ Establish
secure
systems/applications
processes
§ Monitor
systems
for
security
events
§ Manage
security
incidents
§ Monitor
security
compliance
Each
security
objective
then
contains
a
number
of
security
controls.
These
are
typically
included
in
more
detailed
documents,
such
as
IT
Security
standards
and
security
artefacts.
Examples
of
security
controls
are:
§ Create
the
training
material;
monitor
attendance
of
security
trainings
§ Review
feedback
from
security
trainings
§ Manage
accounts
in
the
IT
systems
–
create
accounts
for
new
users,
modify
when
role
changes
and
delete/disable
when
account
is
not
longer
needed
§ Install
anti-­‐malware
software;
establish
and
implement
secure
configuration
for
each
operating
system
in
use;
update
configurations
on
systems
as
per
changing
threat
landscape;
patch
systems
with
vendor
patches
within
X
days
Each
control
needs
to
be
linked
to
one
or
more
security
objectives.
A
number
of
security
controls
is
part
of
a
security
process,
and
each
process
must
have
its
owner
and
must
be
measured.
Finally,
each
security
process
contributes
to
the
security
of
a
number
of
business
processes.
For
example,
the
security
process
‘Security
configuration
&
patch
management’
ensures
that
IT
systems
used
in
the
business
process
‘Take
order
from
customers’
runs
smoothly
and
as
expected.
3.2.
Security
standards
3.2.1
International
standards
for
security
policy
and
controls
Figure
3
shows
business
objectives,
which
will
be
specific
to
each
company.
However,
security
objectives,
whilst
supporting
the
Business
objectives,
should
be
selected
from
a
catalogue
of
internationally
recognised
ones,
and
international
standards
can
play
an
important
role.
It
is
important
to
understand
which
objectives,
controls
and
processes
to
take
‘as
is’
and
where
a
customisation
is
needed.
Moreover,
there
might
be
business
objectives
and
business
processes
that
need
controls
that
are
not
included
in
the
international
standards.
Standardisation
is
needed
but
should
not
be
applied
blindly.
Standards
such
as
ISO27001
&
27005,
COBIT
4,
ISF
Standard
of
Good
Practice
(both
2007
and
2011
editions)
are
generally
extremely
useful.
3.2.2
Information
technology
standards
This
document,
or
set
of
documents,
contains
a
list
of
security
controls
related
to
the
technology
used
in
a
company.
As
mentioned
above,
these
controls
are
of
sufficient
detail
to
describe
what
is
required.
Further
implementation
information
is
usually
included
in
‘Guidelines’
or
‘Security
Artefacts’.
The
level
of
detail
included
in
technology
standards
will
range
from
high
level,
such
as
‘Implement
account
creation
process
to
create
account
within
two
days
of
request’,
to
more
detailed,
such
as
‘Use
Windows
2008
R2
server
with
configuration
W2k_DMZ
for
servers
located
in
the
DMZ’.

8. 3.3
Security
architecture
repository
Consistency
is
key
in
information
security.
TOGAF
9
has
a
good
approach
to
standardisation
and
reusability,
as
does
the
SABSA
security
framework.
Standardisation
and
reusability
ensure
higher
maturity
in
information
security.
For
this
reason,
having
a
library
of
reusable
security
architecture
components
(artefacts)
is
extremely
important.
TOGAF
9
defines
artefact
as:
“A
product
that
describes
architecture
from
a
specific
viewpoint.
Examples
include
a
network
diagram,
a
server
specification,
a
use-­‐case
specification,
a
list
of
architectural
requirements,
and
a
business
interaction
matrix.
Artefacts
are
generally
classified
as
catalogues
(lists
of
things),
matrices
(showing
relationships
between
things),
and
diagrams
(pictures
of
things)
…
”
In
the
context
of
an
information
security
model,
artefacts
are
re-­‐usable
for
the
creation
of
information
security
architecture,
either
a
technology
(such
as
‘We
use
Cisco
firewall
and
this
is
how
it
is
configured’)
or
a
process
(such
as
‘We
have
standardised
our
incident
response
process
and
this
is
how
it
is
done’).
The
technology
section
of
the
repository
should
contain,
for
example:
§ Standard
set
of
technologies
used
in
the
company
(related
to
security)
§ Configuration
standards
for
the
technologies
above
(e.g.
Windows
7
laptop
local
security
policy
object)
§ Hardening
configuration
of
Web
servers,
DB
servers
and
other
servers.
The
process
section
of
the
repository
should
contain
standard
descriptions
for
security
processes,
in
a
detail
needed
to
replicate
the
process
in
another
part
of
the
organisation,
subsidiary
or
when
acquiring
another
company.
From
experience,
the
documenting
of
processes
is
not
a
strong
skill
base
of
many
IT
and
information
security
professionals.
3.4
Process
frameworks
and
metrics
3.4.1
Security
processes
As
stated
earlier
in
this
document,
and
shown
in
Figures
1
and
3,
security
processes
are
an
integral
part
of
the
security
model.
For
example,
ISACA,
the
organisation
behind
COBIT,
ensures
that
the
default
view
in
COBIT
is
based
on
processes,
where
each
process
is
defined
by
the
objective,
stakeholders,
maturity
levels
and
controls.
Another
international
standard,
ISM3
–
now
adopted
by
the
Open
Group
–
also
sees
security
processes
as
key
to
having
mature
security
systems.
Processes
in
general
often
have
a
bad
name
due
to
their
rigidity
and
over-­‐complex
set-­‐ups;
however,
it
is
important
to
understand
that
a
process
can
easily
be
made
complex
–
it
takes
skill
to
create
processes
that
are
lean
and
adaptive.
3.4.2
Security
metrics
Measuring
of
processes
in
any
company
is
one
of
the
key
techniques
to
ensure
that
inefficiencies
are
recognised
and
corrected.
Measurement
is
a
product
of
the
industrial
revolution;
Frederick
Taylor
published
Scientific
Management
in
1911,
a
revered
work
on
the
capacity
of
observation
and
measurement
to
improve
productivity.
By
the
same
token,
security
processes
must
be
observed,
monitored
and
measured
to
improve
them.
Security
and
metrics
is
a
largely
neglected
area
in
information
security.
There
are
some
exceptions,
such
as
COBIT,
which
brings
maturity
levels
for
CIOs
and
CISOs.
Another
promising
candidate
is
the
Common
Assurance
Maturity
Model
(CAMM),
which
brings
information
security
maturity
levels
into
the
supply
chain.

9.
Gartner
has
researched
IT
and
security
metrics,
and
the
relationship
between
KPI
and
KRI
(Key
Risk
Indicators).
Furthermore,
what
the
business
leaders
are
interested
in
is:
‘What
impact
do
security
controls
(or
lack
of)
have
on
the
business
processes
and
the
bottom
line?’
Security
professionals
have,
for
long
time,
used
the
FUD
(fear,
uncertainty
and
doubt)
approach
and
are
now
finding
this
does
not
resound
with
their
audiences.
It
is
also
accepted
that
maturity
of
security
controls
and
processes
inversely
affects
risks
to
the
organisation.
The
problem
many
security
professionals
face
is
in
having
to
justify
additional
costs
to
move
from
maturity
level
2
(repeatable)
to
3
(defined)
and
beyond.
With
this
in
mind,
it
would
be
prudent
for
organisations
to
measure:
§ Basic
operational
metrics
to
keep
an
eye
on
processes
(i.e.
do
they
operate
as
expected?)
§ Each
security
process
for
its
maturity
§ Value
at
risk,
expressed
in
£s;
a
business
process
is
exposed
due
to
low
maturity
of
security
controls
(or
lack
of
them,
as
defined
by
COBIT
level
0)
The
first
two
metrics
are
fairly
straightforward
and
well
defined.
The
last
one
is
somewhat
new
to
information
security,
though
used
in
the
financial
arena
and
general
risk
management1.
For
the
purpose
of
this
paper,
it
is
worth
having
a
look
at
it
in
more
detail.
(i)
Value
at
Risk
The
main
problem
that
Value
at
Risk
is
trying
to
solve
is
how
to
quantify
the
exposure
that
an
organisation
is
subject
to.
Further
research
into
VaR
use
in
information
security
is
needed
to
make
the
concept
practical
and
reusable.
However,
the
input
elements
into
the
calculations
should
be:
§ Business
asset
value
–
information
assets
alone
or
the
value
of
a
business
process.
A
company’s
PR
image
is
a
business
asset
and
in
this
case
should
be
assigned
a
value
by
consensus
rather
than
measurement
§ Security
process
maturity
–
measure
the
maturity
of
process
(and
included
controls)
that
protect
the
business
asset
§ Threat
landscape
–
threats
change
over
time;
for
example,
Sony
changed
the
threat
landscape
greatly
by
prosecuting
George
Hotz
for
breaching
the
PlayStation
T&Cs.
In
combination
with
the
vulnerabilities
in
their
systems,
it
cost
them
dearly.
The
high
level
calculation
of
the
VaR
is:
1.
Measure
the
maturity
of
the
controls.
Assume
that
maturity
level
5
provides
99%
(or
lower)
protection;
lower
maturity
levels
provide
less
protection.
2.
Analyse
the
control
to
find
compensating
controls;
two
low
maturity
controls
may
work
together
to
provide
higher
protection.
3.
Analyse
the
threat
landscape
and
derive
the
likelihood
that
the
threat
agents
will
attempt
to
attack.
4.
Use
the
above
and
the
asset
value
to
come
up
with
a
probability
distribution
of
monetary
exposure
The
pound
value
for
each
asset
can
be
collected
and
summarised
in
order
to
calculate
the
total
exposure
probability
distribution.
This
will
give
CIOs
and
CISOs
a
very
useful
tool
to
demonstrate
the
risks
to
the
executive
management
and
thus
justify
the
spending.
Detailed
calculations
of
Value
at
Risk
for
information
security
have
not
yet
been
developed
and
need
further
research.
Value
at
Risk
could
also
be
used
to
justify
security
investments,
i.e.
the
reduction
in
VaR
should
be
higher
than
the
cost
spent.

10. Conclusion
Information
Security
Risk
Management
must
support
the
business
objectives.
Security
professionals
should
have
open
dialogue
with
business
leaders
and
managers,
listen
to
their
concerns,
and
frequently
educate
them
about
risks.
The
security
model
can
help
with
explaining
why
security
is
important,
and
can
support
justifications
for
that
‘rather
expensive’
piece
of
technology,
depending
on
the
point
of
view,
security
policy
and
business
appetite
for
risk.
1
McNeil,
Alexander;
Frey,
Rüdiger;
Embrechts,
Paul
(2005).
Quantitative
Risk
Management:
Concepts
Techniques
and
Tools.
Princeton
University
Press.
ISBN
978-­‐0691122557.
About
the
author
Vladimir
Jirasek
is
a
passionate
information
risk
professional
with
more
than
16
years
of
IT
industry
practise
and
over
11
years
in
Information
Security
and
IT
Security,
Risk
and
Compliance
disciplines.
He
has
both
led
and
managed
global
teams
in
Security,
Risk
and
Compliance
for
multinational
corporations
such
as
Nokia,
Tesco,
and
DTAG.
In
his
own
time
he
tries
to
give
something
back
to
the
security
community
by
participating
in
a
variety
of
key
industry
initiatives,
such
as
the
Common
Assurance
Maturity
Model
(common-­‐assurance.com),
Cloud
Security
Alliance
(cloud-­‐security.org.uk);
and
the
Open
Group’s
Jericho
forum,
working
together
with
industry
experts.
He
can
be
contacted
at
vladimir@jirasek.eu
or
on
+44
(0)
7538
790302