1

Security analysis ─basic notions and ideas

October 6, 2006

Ketil Stølen, SINTEF & UiO

2

Acknowledgements

The lectures on security analysis is the result of joint work with a number of colleagues at SINTEF; in particular:

Folker den BraberIda HogganvikMass Soldal LundFredrik Vraalsen

The initial version of CORAS was jointly developed by the 11 partner in the CORAS project

3

Objectives for the three lectures on security analysis

Classify security conceptsIntroduce, motivate and explain a basic apparatus for risk management in general and risk analysis in particularRelate risk management to system developmentDescribe the different processes that risk management involveMotivate and illustrate model based security analysisIdentify relevant standardsDemonstrate the use of risk analysis techniques

4

What is security analysis?

Security analysis is a specialized form of risk analysis focusing on security risks

5

What is security?

security

integrity availability accountabilityconfidentiality

Only authorised actors can

change, create or delete

information

Only authorised actors have access to information

Authorised actors have

access toinformation

they need whenthey need it

It is possible to audit the sequence of

events in the system

6

What is risk analysis?

Determining what can happen, why and howSystematic use of available information to determine the level of riskPrioritisation by comparing the level of risk against predetermined criteriaSelection and implementation of appropriate options for dealing with risk

7

Note: Security is more than technology

From a technical standpoint, security solutions are available – but what good is security if no one can use the systems?

Security requires more than technical understandingSecurity problems are often of non-technical originA sound security evaluation requires a uniform description of the system as a whole

how it is used, the surrounding organisation, etc.

8

Security – part of system development

Security is traditionally added as an “afterthought”Solutions often reactive rather than proactiveSecurity issues often solved in isolationCostly redesignSecurity not completely integrated

Requirements analysis and risk analysis are two sides of the same coin and should be integrated

Focus on desired and undesired behaviour, respectively

9

Model-based risk analysis

Model-based risk analysis

Precise inputat the right levelof abstraction

Graphical models as media for

communication

Documentationof analysisresults and

assumptions

Graphicalmodelling

Risk analysis

10

Model-based risk analysisRisk analysis

Vulerabilities Misusers

MisUse Case-diagram

unauthorized login

misuser customerdatabase

Requirementsanalysis

Features Actors

Use Case-diagram

loginregistered

user customerdatabase

login

unauthorizedlogin

Complete Use Case-diagram

registereduser

customerdatabase

misuser

Oversettelse av terminologiasset aktivum/aktiva (noe med verdi)

threat trussel

unwanted incident uønsket hendelse

risk risiko

vulnerability sårbarhet

consequence konsekvens

probability sannsynlighet

frequency frekvens/hyppighet

treatment behandling

11

12

Conceptual model for risk analysis

13

asset, something of value vulnerability

threat

Risk with respect to security

need to introduce security mechanisms

Terms

reduced securityrisk

14

Terms

Risk

Threat

Vulnerability

Unwanted incident

Internet

- Infected twice per year- Infected mail send to all

contacts

Infected PC

Computer running Outlook

V

Install virus scanner

Treatment

Worm

15

Elements of risk analysis

Context

TargetThreat

Frequency

Consequence

Asset

RiskUnwanted Incident

Vulnerability

Treatment

16

CORAS background

Research and technological development project under the Information Society Technologies (IST) ProgrammeJanuary 2001 -> July 200311 partners from 4 European countries

Goal: Develop an improved methodology for precise, unambiguous, and efficient risk analysis of security critical IT systems

17

CORAS methodology

Risk management process based on AS/NZS 4360Provides process and guidelines for risk analysis

Identify context

Identify risks

Estimate risk level

Evaluate risks

Treat risks

18

Identify Context

Identify Risks

Estimate Risk Level

Evaluate Risks

Treat Risks

Context identification

Characterise target of analysisWhat is the focus and scope of the analysis?

Identify and value assetsAsset-driven risk analysis processBusiness oriented, e.g. availability of services generating revenue

Specify risk acceptance criteriaThere will always be risks, but what losses can the client tolerate?Similar to requirements in system development

19

Identify Context

Identify Risks

Estimate Risk Level

Evaluate Risks

Treat Risks

Risk identification

Identify threats to assets through structured brainstormingHazard and Operability analysis (HazOp)Involving system owners, users, developers, domain experts, riskanalysis experts, etc. (typically 5-7 people)

Identify vulnerabilities of assetsQuestionnaires and checklists

Equipment physical security• Is equipment properly physically protected againstunauthorised access to data or loss of data?

• Are power supplies handled in a manner thatprevents loss of data and ensures availability?

• …

20

Identify Context

Identify Risks

Estimate Risk Level

Evaluate Risks

Treat Risks

Risk evaluation

We cannot completely eliminate all risksDetermine which risks need treatment

We need to know how serious they are so we can prioritise

Risk level is determined based on analysis of the frequency and consequence of the unwanted incident

Quantitative values: e.g., loss of 1M€, 25% chance per yearQualitative values: e.g., high, medium, low

21

Identify Context

Identify Risks

Estimate Risk Level

Evaluate Risks

Treat Risks

Risk treatment

Identify treatments for unaccepted risksEvaluate and prioritise different treatments