Utilizing Unidirectional Security Gateways to Achieve Cyber Security for Industrial Environments
Modeling and Utilizing Security Knowledge for Eliciting Security Requirements
-
Upload
shinpei-hayashi -
Category
Software
-
view
939 -
download
2
Transcript of 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