Security - Telenor

tems as category B, with only a one point difference,
using very different approaches. When
questioned informally, the meticulous user said
that they learned a lot about their system and its
environment, and that the resulting report would
be used as part of the system documentation.
The other user reported that the classification
procedure was acceptable, but that they did not
learn very much from the exercise and that the
main benefit was that their security officer was
satisfied.
Risk Analysis During Product
Development and Introduction
The product development and introduction process,
or P3 as it is more commonly referred to in
Telenor, calls for risk analysis both of the project
risks and a security risk analysis of the
future product or service.
The project risk analysis follows an intuitive
process, and is quite straightforward.
On the other hand, the security risk analysis
begins with a security categorisation which
decides the depth of analysis. A review of the
security risk analysis is required for each formal
phase evaluation the project is subjected to.
Given enough time and that the product or service
is categorised A or B, the security risk analysis
is repeated one or more times before the
product or service is launched.
Risk Analysis in Practice
All risk analyses are company confidential in
Telenor. Confidentiality is necessary because
one is very vulnerable after a risk analysis. Not
only has the analysis uncovered weaknesses, it
has also exposed and documented the mechanisms
that can be used to exploit the weakness.
Instead of looking into specific risk analysis, this
article will highlight the methodology behind
Telenors Minimal Risk Analysis and some of the
lessons learned.
The Minimal Risk Analysis
Users complained that the previous corporate
risk analysis framework was too demanding,
time consuming, inflexible and too focused on
security risk analysis. Informal discussions with
disapproving users pinpointed problems such as
untrained analysts using semi-formal analysis
methodologies, guidelines written by experts for
expert use and too voluminous template files. In
addition to this, the users had little or no chance
of performing a risk analysis within real-world
time constraints. In short; they felt the corporate
risk analysis standard was impractical and theoretical.
Telektronikk 3.2000
The Minimal Risk Analysis (MRA) was developed
as a response to these complaints. The primary
objective was to propose a generic risk
analysis framework that would give a methodical
user a high success rate. The secondary objective
was to have the Minimal Risk Analysis
take less than one week to plan, execute and
document. This contrasts the then current corporate
methodology requiring a specialist analyst
using perhaps 200 – 300 man-hours in a two to
four month time scale.
The resulting design of the MRA is three-part:
1 A process guide; directing the user through
a proven sequence of activities;
2 A template file; giving the user a skeleton
report;
3 Threat assessment guidelines; assisting the
user in uncovering threats.
The Minimal Risk Analysis is object oriented.
The TOE is described as an object consisting
of sub-components which interact with and are
influenced by external objects. As a minimum,
each object or sub-component will be described
by its internal structure, its function and its interaction
with other objects or sub-components.
The following threat identification phase systematically
explores each object to identify
threats.
The Minimal Risk Analysis differs from the
Standard Risk Analysis in three areas:
• Formal methods are not mandatory in a Minimal
Risk Analysis. This means that risk analysis
expertise is not required, though it is helpful.
However, the lack of formal methods does
not mean that the analysis is unstructured. The
user has a guideline for the work process, a
template file for the report and structured aids
to the security threat identification.
• Acceptance criteria are not developed before
the risk exposure is written. With a finalized
risk exposure the decision-maker quickly sees
which risks are acceptable or unacceptable.
• Causal analysis is omitted from the threat
analysis phase since the causal analysis is not
very useful for the acceptable threats. A causal
analysis is occasionally necessary to identify
cost-effective treatment strategies for unacceptable
threats, but treating an unacceptable
risk is often quite straightforward.
Practical use shows that a Minimal Risk Analysis
of acceptable quality can be performed with-
73