1.
Identify the business and the resources that need to be protected.
2.
Determine what your “crown jewels” are.
3.
Assign business priorities for recovery.
4.
Document how your system works and keep this documentation up to date:
■
network scheme
■
equipment and services inventory
■
account and access lists.
Figure 18.1 presents a theoretical, stylized example of a risk-based architecture,
with data locations and levels of protection aligned with sensitivity levels. In practice,
however, all types of data can be found throughout the system.
A S S E S S M E N T : S U R V E Y S , R C S A S A N D S C E N A R I O S
R i s k A s s e s s m e n t S u r v e y
Information is everywhere, part of everything, handled by everyone. It is a diffuse pres-
ence not well suited to point-in-time, circumvented risk and control self-assessments.
To mitigate this issue, we designed a flash questionnaire that would take a maximum of
200
RISING OPERATIONAL RISKS
five minutes to complete. After testing and adjusting the questionnaire with several peo-
ple, we sent it firm-wide. Two-thirds of the firm responded, which was a representative
and successful outcome.
The results gave the risk function a fairly good insight on the level of information
security experienced day to day, both collectively and individually – something that is
impossible to achieve through RCSAs. The responses to whether people had personally
lost or disclosed information, or if they had witnessed data incidents, were particularly
useful. Figure 18.2 presents the questionnaire.
R i s k a n d C o n t r o l S e l f- a s s e s s m e n t s
Based on the questionnaire results and a number of interviews across different depart-
ments and business lines – including IT, naturally – members of the risk function and
I plotted the assessment of the various information security risk types in the RCSA
matrix. Figure 18.3 presents an anonymized version of this exercise. Both the matrix
and the position of the dots have been modified to protect the firm’s confidentiality, but
the interpretations are accurate, if fictitious.
Since the firm at the time was rolling out some additional control measures, it felt
sensible to also present the expected impact of these controls on the new risk assess-
ment. Figure 18.4 displays a modified example of this representation.
C y b e r S c e n a r i o A s s e s s m e n t
Tail risk events, like data breaches or cyberattacks, are well suited for scenario analy-
sis. For the assessment of rare events and cyberscenarios in particular, market practice
is evolving toward scenario modelling using fault trees, Bayesian networks and other
methods, as presented in Chapter 7. Figure 18.5 displays a stylized example of a struc-
tured scenario, where three preventive controls are layered between attackers and the
data server. Those three controls will be, for instance, two firewalls and human suspi-
cion regarding unknown links or attachments sent through emails. All three controls
need to fail simultaneously for the attack to be successful.
The joint probability of failure of these three controls is the scenario probabil-
ity. If controls are independent and expected to fail in a range of L(ow) to H(igh), the
joint probability of failure ranges between the product of three L(ow) cases of fail-
ure L
×
L
×
L, and the three H(igh) cases of failures H
×
H
×
H. Simple models can be
manually calculated for discrete probabilities. Slightly more complex models generate
probability distributions from Monte Carlo simulations, possible to create only with
spreadsheets and add-on features.
Drivers of impacts are also decomposed and quantified, and simulations are made
on the range of value. In the case illustrated: impact of data leak
=
time to detection
×
data corrupted (or stolen) per unit of time
×
data value. There again, Monte Carlo
simulations lead to continuous distributions of losses per scenario type. Additional
Do'stlaringiz bilan baham: |