Modeling and Utilizing Security Knowledge for Eliciting Security Requirements

Modeling and Utilizing Security Knowledge for Eliciting Security Requirements

• 1.
  Modeling and Utilizing SecurityKnowledge for Eliciting Security Requirements Tatsuya Abe, Shinpei Hayashi, and Motoshi Saeki Department of Computer Science, Tokyo Institute of Technology, Japan 1
• 2.
  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 of security requirements elicitation: – Detection of potential threats to consider – Elicitation of security objectives – Achievement of security objectives by security functions
• 3.
  Threats and Objectives Login Sendpassword Request password Notify login succeeded SystemUserMis-actor Confirm password mitigate Eavesdropping Objective: password protection Realized by: Encryption 3 An Example
• 4.
  4 Difficulty in Security 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?
• 5.
  Used Knowledge Login Send password Requestpassword Notify login succeeded SystemUserMis-actor Confirm password 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.
  6 Our Approach  Howto 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
• 7.
  Our Approach 7 Describe Req. analyst Pattern DB Threat Detecting Threats Deriving Negative Scenario Embedding Objectives Scenario Negativescenario Fixed scenario Threat pattern Threat pattern Objective pattern OUTPUT OUTPUT
• 8.
  8 Sec. Knowledge inST  Includes the relationships between threats, objectives, and security function components Security Target O.Communicate _Protection. T.Intercept_... ... ✔ O.Communicate_ Error_Detection … ✔ O.Communicate_ Error_Detection … O.Communicate_ Protection FCS_COP.1 FPT_RVM.1 FDP_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 Threats T.Intercept_Communicate _Data ... 4. Security Objective - O.Communicate _Protection .... - O.Communicate_Error _Detection ... 8.2 Security Requirements Rationale 8.1 Security Objective Rationale mitigates realizes
• 9.
  Security Target 1. STIntroduction … 2.TOE Description … 3. Security Problem Definition 3.1 Assets IC chip Personal data 3.2 Assumption … 3.3 Threats T.Intercept_Communicate_DataC hip_Identification: identifying passport's IC chip. T.Skimming: skimming the passport data via imitated communication interface. … T.Eavesdropping: eavesdropping to the radio communication between ST Desc. to Pattern 9 T.Eavesdropping: eavesdropping the communication betweenTOE and the inspection system An 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 listening Finding Attacker
• 10.
  System User sd <<trusted>> 1: Login() Sendinput(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
• 11.
  Threat Pattern Subject S2 RESPOND(Data d) Mis-User Install adevice 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
• 12.
  System User sd <<trusted>> 1: Login() Send input(password) 3:Confirm(password) 4:Notifylogin 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 Intercept Threat Pattern✔ Intercept detected 12
• 13.
  System User 1: Login() Send input(password) 3:Confirm(password) 4:Notifylogin 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}} Deriving Negative Scenario Mis-User Install a device Intercept (password) Intercept mis-scenario embedded 13
• 14.
  System User 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
• 15.
  Requesting Data d System RespondingData d <<trusted>> <<request, indirect>> sd <<respond, indirect>> 15 Implementation  Pattern detection and application using AGG AGG User (human) System trusted=TRUE REQUEST DIRECT=FALSE SendReceive Data d READ permission READ permission Send Receive Target Next RESPOND DIRECT=FALSEData d: {read= {User, System} …} User
• 16.
  16 Preparing Patterns  Composed9 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.
  17 Preliminary Evaluation  [EvaluationQuestion 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.
  18 Experimental Setup  6scenarios on 2 domains – IC Card: 2 scenarios of gating system 1 scenario of document issuing system – C/S system: 3 scenarios of online shopping system  Evaluation scheme – Comparing to the oracle prepared by us
• 19.
  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.89 e-Shop 35 31 0.97 0.83 0.89 Total 55 47 0.98 0.83 0.89
• 20.
  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 Pattern S2 Request (Data) S1 Respond (Data) ID Data Actual scenario Respond (ID) Request (ID) <<request>> <<respond>> Separately Described 20
• 21.
  Conclusion  A techniquefor 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