Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Modeling and Utilizing Security Knowledge for Eliciting Security Requirements

9 474 vues

Publié le

Presented at MReBa 2015
http://dx.doi.org/10.1007/978-3-319-25747-1_24

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Modeling and Utilizing Security Knowledge for Eliciting Security Requirements

  1. 1. Modeling and Utilizing Security Knowledge for Eliciting Security Requirements Tatsuya Abe, Shinpei Hayashi, and Motoshi Saeki Department of Computer Science, Tokyo Institute of Technology, Japan 1
  2. 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. 3. Threats and Objectives Login Send password Request password Notify login succeeded SystemUserMis-actor Confirm password mitigate Eavesdropping Objective: password protection Realized by: Encryption 3 An Example
  4. 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. 5. Used Knowledge Login Send password Request password 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. 6 Our Approach  How 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
  7. 7. Our Approach 7 Describe Req. analyst Pattern DB Threat Detecting Threats Deriving Negative Scenario Embedding Objectives Scenario Negative scenario Fixed scenario Threat pattern Threat pattern Objective pattern OUTPUT OUTPUT
  8. 8. 8 Sec. Knowledge in ST  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. 9. Security Target 1. ST Introduction … 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. 10. System User 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
  11. 11. Threat Pattern Subject S2 RESPOND(Data d) Mis-User Install a 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
  12. 12. System User 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 Intercept Threat Pattern✔ Intercept detected 12
  13. 13. System User 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}} Deriving Negative Scenario Mis-User Install a device Intercept (password) Intercept mis-scenario embedded 13
  14. 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. 15. Requesting Data d System Responding Data 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. 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. 17. 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. 18. 18 Experimental Setup  6 scenarios 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. 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. 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. 21. 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

×