modeling and utilizing security knowledge for eliciting security requirements

Modeling and Utilizing Security Knowledge

for ElicitingSecurity Requirements

Tatsuya Abe, Shinpei Hayashi, and Motoshi SaekiDepartment of Computer Science, Tokyo Institute of Technology, Japan

1

2

Security Req. Elicitation Elicit requirements to security functions

as early as possible – To reduce the development cost– To develop systems of higher quality

Process ofsecurity requirements elicitation:– Detection of potential threats to consider– Elicitation of security objectives– Achievement of security objectives by security

functions

Threats and Objectives

Login

Send password

Request password

Notify login succeeded

SystemUserMis-actor

Confirmpassword

mitigate

Eavesdropping

Objective: password protectionRealized by: Encryption

3

An Example

4

Difficulty inSecurity Req. Elicitation Requires detecting all of potential threats

– Exceptional events do not happen so frequently and analysts might miss them

Requires special security knowledge

Challenges– How to obtain such security knowledge?– How to detect threats and elicit functional requirements

against such threats?

Used KnowledgeLogin

Send password

Request password

Notify login succeeded

SystemUserMis-actor

Confirmpassword

mitigate

Eavesdropping

Encrypting password

5

Passwords are the assets to be protected Eavesdropping threat can happen when sending

data without protection Eavesdropping can be mitigated by encryption

6

Our ApproachHow to obtain such security knowledge? Usage of Security Target / Common Criteria

How to detect threats and elicit functional requirements against such threats? Usage of pattern matching and

graph transformation technique

Our Approach

7

Describe

Req.analyst

PatternDB

Threat

DetectingThreats

DerivingNegativeScenario

EmbeddingObjectives

Scenario Negative scenario

Fixed scenario

Threatpattern

Threatpattern

Objectivepattern

OUTPUT

OUTPUT

8

Sec. Knowledge in ST Includes the relationships between threats,

objectives, and security function components

SecurityTarget

O.C

omm

unic

ate

_Pro

tect

ion.

T.Intercept_......

✔

O.C

omm

unic

ate_

Erro

r_D

etec

tion

…

✔

O.C

omm

unic

ate_

Erro

r_D

etec

tion

…O.C

omm

unic

ate_

Prot

ectio

n

FCS_COP.1FPT_RVM.1FDP_UCT.1

…

✔✔✔

(threat)Intercept

(objective)

O.Communicate_Protection

(objective)

O.Communicate_Error_Detection

(SFC)

FCS_COP.1(SFC)

FPT_RVM.1(SFC)

FDP_UCT.1

3.3 ThreatsT.Intercept_Communicate_Data...

4. Security Objective- O.Communicate_Protection....

- O.Communicate_Error_Detection...

8.2 Security RequirementsRationale

8.1 Security ObjectiveRationale

mitigates

realizes

Security Target 1. ST Introduction…2. TOE Description…3. Security Problem Definition3.1 Assets

IC chipPersonal data

3.2 Assumption…3.3 Threats

T.Intercept_Communicate_DataChip_Identification: identifying passport's IC chip.T.Skimming: skimming the passport data via imitated communicationinterface. …T.Eavesdropping: eavesdropping to the radio communication between

' IC hi d i i

ST Desc. to Pattern

9

T.Eavesdropping: eavesdropping the communication between TOE and the inspection systemAn attacker is listening to the communication between the MRTD’s chip and an inspection system to gain the logical MRTD or parts of it. · · · · · ·

Inspection System

IC chip

requesting MRTD data

MRTD dataMRTD data

listeningFinding

Attacker

SystemUser

sd <<trusted>>

1: Login()

Send input(password)

3:Confirm(password)4:Notify login succeeded

2: Request input()password: {read= {User, System}, write= {System}, exec={User, System}}

<<verify, direct>>

<<login, indirect>>

<<request, indirect>>

<<respond, indirect>>

<<respond, indirect>>

10

Describing Scenario Use of special UML profile

– attached stereotypes and tagged values

Stereotypes

tagged values

Threat Pattern

Subject S2

RESPOND(Data d)

Mis-User

Installa device

Intercept(Data d)

Subject S1

Data d :{read ≠{public}}

Subject S2

Data d :{read ≠ {public}}

RESPOND(Data d)

Subject S1

<<respond>>

<<respond>>

11

Left hand side:Condition when the threat can happen

Right hand side:Negative scenario

SystemUser

sd<<trusted>>

1: Login()

Send input(password)

3:Confirm(password)

4:Notify login succeeded

2: Request input()password: {read= {User, System}, write= {System}, exec={User, System}}

<<verify, direct>>

<<login, indirect>>

<<request, indirect>>

<<respond, indirect>>

<<respond, indirect>>

Threat Detection

InterceptThreat Pattern✔

Interceptdetected

12

SystemUser

1: Login()

Send input(password)3:Confirm(password)

4:Notify login succeeded

sd

2:Request input()

<<trusted>>

<<verify, direct>>

<<login, indirect>>

<<request, indirect>>

<<respond, indirect>>

<<respond, indirect>>password: {read= {User, System}, write= {System}, exec={User, System}}

DerivingNegative Scenario

Mis-User

Install a device

Intercept(password)

Intercept mis-scenario embedded 13

SystemUser

sd<<trusted>>

KEY :{read= {User, System},write= {}, exec={User, System}}

1: Login()

Send input (password)

3:Confirm(password)4:Notify login succeeded

2: Request input()

password : {read= {User, System}, write= {System}, exec={User, System}}

<<verify, direct>>

<<login, indirect>>

<<request, indirect>>

<<respond, indirect>>

<<respond, indirect>>

Deriving Fixed Scenario

DECRYPT(password, key)ENCRYPT(password, KEY)

<<direct>><<direct>>

14

Requesting Data d

System

Responding Data d

<<trusted>>

<<request, indirect>>

sd

<<respond, indirect>>

15

Implementation Pattern detection and application using AGG

AGG

User(human)

Systemtrusted=TRUE

REQUESTDIRECT=FALSE SendReceive

Data d

READpermission

READpermission

Send Receive

Target

Next

RESPONDDIRECT=FALSEData d:

{read= {User, System}…}

User

16

Preparing Patterns Composed 9 types of threat patterns

from STs of different domains– ST: 3 from IC chip domain, 1 from C/S domain– Extracted threats:

• Violate Access• Abuse Command• Intercept• Powerdown• Spoofing

• Skimming• Eavesdropping• Forgery•Hijack

17

Preliminary Evaluation [Evaluation Question 1]

To what extent does the proposed technique accurately detect threats in the given scenarios and introduce objectives based on the detected threats?

[Evaluation Question 2]Do the differences of the problem domains of the given scenarios affect the accuracy of the detection?

Accurately detected (F-measure = 89%)

Accurately detected for all systems(though only 2 domains)

18

Experimental Setup 6 scenarios on 2 domains

– IC Card:2 scenarios of gating system1 scenario of document issuing system

– C/S system:3 scenarios of online shopping system

Evaluation scheme– Comparing to the oracle prepared by us

19

Results

Accurate detection (F-measure = 0.89) Included some FPs and FNs

– Could avoid by refining patterns

Domain #oracles

#detected

Prec. Recall F

IC Card 20 16 1.00 0.80 0.89e-Shop 35 31 0.97 0.83 0.89

Total 55 47 0.98 0.83 0.89

False Negative Example Failed to detect Spoofing

– Gaps between the pattern and the actual scenario

2015/3/12

S2

Request (ID)

S1

Response (Data)

ID Data

PatternS2

Request (Data)

S1

Respond (Data)

ID Data

Actual scenario

Respond (ID)

Request (ID)

<<request>>

<<respond>>SeparatelyDescribed

20

Conclusion A technique for eliciting security

requirements– Usage of ST as security knowledge– Detecting threats by pattern matching and graph

transformation– Obtained accurate detection results

Future work– CASE tool for describing attributed seq. diag.– Case study++

21