Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TESEM: A Tool for Verifying Security Design Pattern Applications

532 views

Published on

Because software developers are not necessarily security experts, identifying potential threats and vulnerabilities in the early stage of the development process is often insufficient. Even if these issues are addressed at an early stage, it does not guarantee that the final software product actually satisfies security requirements. To realize secure design and implementation, we propose extended security patterns, which include requirement- and design-level patterns as well as a new model testing and model-based code testing process. Our approach is implemented in a tool called TESEM, Test Driven Secure Modeling Tool, which supports pattern applications by creating a script to execute model testing automatically (ARES'13, IJSSE'14, ICST'15). Moreover we recently extended the tool to support testing of security design patterns implementation by preparing testcase templates (ARES'14). By using the tool, developers can specify threats and vulnerabilities in the target design and implementation according to security design patterns, verify whether the security patterns are properly applied, and assesses whether these vulnerabilities are resolved.

Published in: Software
  • Be the first to comment

TESEM: A Tool for Verifying Security Design Pattern Applications

  1. 1. A Tool for Verifying Security Design Pattern Applications Hironori Washizaki Waseda University, Tokyo, Japan Collaborators: Takanori Kobashi, Masatoshi Yoshizawa, Yoshiaki Fukazawa (Waseda University) Takao Okubo (Institute of Information Security) Haruhiko Kaiya (Kanagawa University) Nobukazu Yoshioka (National Institute of informatics) InSTA 2016, Chicago, Apr 10, 2016
  2. 2. • Prof., Head, Global Software Engineering Laboratory, Waseda University • Visiting Assoc. Prof., National Institute of Informatics • Chair, IEEE CS Japan Chapter • Chair, SEMAT Japan Chapter • Convenor, ISO/IEC/JTC1/SC7/WG20 • Co-Chair, IEEE ICST’17 Toyo 2 “Hiro”nori Washizaki
  3. 3. Agenda • Introduction • Security patterns • TESEM: testing models • TESEM: testing code • Conclusion and discussion 4
  4. 4. Appropriate design Inappropriate design What’s the problem? 5 Role-based access control (RBAC) pattern
  5. 5. TESEM: Test Driven Secure Modeling Tool • Security design/implementation guided by testing pattern applications [ARES’13][ARES’14][IJSSE’14][ICST’15] 6 Security pattern Problem Solution Context Test design as requirement ! create Actor ! create UI : ! create Subject.. Constraint, script Test case Testing [ARES’13] Validating Security Design Pattern Applications Using Model Testing, Int’l Conf. Availability, Reliability and Security [ARES’14] Verification of Implementing Security Design Patterns Using a Test Template, Int’l Conf. Availability, Reliability and Security [IJSSE’14] Validating Security Design Pattern Applications by Testing Design Models, Int’l J. Secure Software Engineering 5(4) [ICST’15] TESEM: A Tool for Verifying Security Design Pattern Applications by Model Testing, IEEE ICST’15 Tools Track
  6. 6. Agenda • Introduction • Security patterns • TESEM: testing models • TESEM: testing code • Conclusion and discussion 7
  7. 7. Security for every phase • Security concerns must be addressed at every phase 8 Requirement Design Implementation Test Security concerns Security requirements Security design Threat modeling Secure coding and review Security testingSecurity design review
  8. 8. Patterns are promising at any phase 9 Requirement Design Implementation Test Security concerns SecurityTesting Security Requirement Patterns Security Design Patterns Patterns • Recurrent problems and solutions under specific contexts • For requirements definition, design, implementation and testing!
  9. 9. • Name: Role-based access control (RBAC) • Problem: How do we assign rights to people based on their functions or tasks? • Solution: Assign users to roles and give rights to these roles so they can perform their tasks. • Related patterns: Authorization, ... User id name ProtectionObject id name * *Authorization_rule Right access_type predicate copy_flag checkRights Role id name **MemberOf Example of security pattern
  10. 10. 11 T. Heyman, “An Analysis of the Security Patterns Landscape,” 2007 Number of well described security patterns is increasing Security patterns landscape [Heyman’07]
  11. 11. Pattern-oriented test architecture • Security by proven patterns – Security requirements, secure design and implementation • Patterns as abstract test cases – Possible to prepare abstract “constraints” and “templates” for testing model and code – Necessary to concretize patterns against concrete requirement/design/code 12 Security patterns Problem Solution Context Abstract constraints, templates Concrete constraints, test cases
  12. 12. Security pattern researches [PLoP’15] 13 [PLoP’15] Systematic Mapping of Security Patterns Research, Conf. Pattern Languages of Programs Conference Application 46% Case studies 13%Modeling 7% Detection 7% Validation 7% Selection 7% Others 13%
  13. 13. Agenda • Introduction • Security patterns • TESEM: testing models • TESEM: testing code • Conclusion and discussion 14
  14. 14. TESEM: Test Driven Secure Modeling Tool [ARES’13][IJSSE’14][ICST’15] 15 Security Design Pattern Problem Solution Context Test design as requirement ! create Actor ! create UI : ! create Subject.. Test Script Test case Testing [ARES’13] Validating Security Design Pattern Applications Using Model Testing, Int’l Conf. Availability, Reliability and Security [IJSSE’14] Validating Security Design Pattern Applications by Testing Design Models, Int’l J. Secure Software Engineering 5(4) [ICST’15] TESEM: A Tool for Verifying Security Design Pattern Applications by Model Testing, IEEE ICST’15 Tools Track
  15. 15. Application of Security Design Patterns (SDP) Role Based Access Control ・Context ・Problem ・Solution ・Structure Apply Model not considering security Model that realizes access control based on Role 16
  16. 16. Apply SDPUML UML Incorrect pattern application Vulnerabilities are not resolved Conventional problematic process Identify assets, threats, and countermeasures Select SDP 17
  17. 17. Security patterns with OCL constraints 18 Access control ・Context ・Problem ・Solution ・Structure Security Requirement Patterns Security Design Patterns ・Asset ・Threat ・Countermeasure: Security property OCL trace Role-based access control ・Context ・Problem ・Solution ・Consequence: Security property OCL
  18. 18. • Nine types of security properties • E.g. “Access Control” Security property at requirements level 19
  19. 19. 1 2 Conditions access permission is given to <Role> which an <UserData> belongs Yes No Actions considers that actor has access permission × consider that actor does not have access permission × execute subject function × not execute subject function × context subject_controller inv access_control: if self.RBAC.Right->exists(p | p.right = true and p.role_id = p.Role.id and p.role_id = p.Role.User_Data.role_id ) then self.Subject_UI.User.Right = true else self.Subject_UI.User.Right = false Security property at design level 20 •E.g. “Role-based access control (RBAC)”
  20. 20. Test Script Our tool “TESEM” • Class structure modeling • Behavior modeling • Application of security design patterns • Generation of test cases 1 2 Conditions access permission is given in <Role> to which an <UserData> belongs Yes No Actions considers that an actor have access permission × consider that an actor does not have access permission × execute subject function × not execute subject function × Test cases for “RBAC” Create instances and check OCL constrains on USE [*] [*] F. Büttnera, et al., “USE: a UML-based specification environment for validating UML and OCL,” SCP, vol.69. 2007.
  21. 21. Identify assets, threats, and countermeasures Apply SDP and bind pattern elements Execute test to verify how model satisfies security requirements Execute test to verify how model satisfies security design requirements Security requirements (OCL) Security design requirements (OCL) UML UML Select SDP Design process using extended patterns 22
  22. 22. Case study: Setting ・Threat: Privilege Escalation ・Countermeasure: Access Control ・Target: Delete function of StudentController → Any user can delete student’s data ・Selected Pattern: Role-based access control →Realize access control based on role’s right 23
  23. 23. • Security Properties are in the Test cases Add test cases Confirm tests fail Fix model Confirm tests pass Test-driven secure design 24 Find vulnerability Eval. of mitigation
  24. 24. 1 2 Conditions “Actor” has access right Yes No Actions execute “delete” function × cannot execute “delete” function × context StudentController inv SecurityRequirement : if self.DeleteUI.Actor.right = true and self.delete = true else self.delete = false endif Security requirements as OCL expression Verify whether model satisfies security requirement Security requirement as decision table Case study: Initial test for security requirement 25
  25. 25. Actor can execute “delete” function without access right ! Model may contain vulnerability causing Privilege Escalation. Case Study: Test failed 26
  26. 26. Verify whether model with RBAC satisfies security design requirements Case Study: Test for security design Verify whether model satisfies security design requirement 27
  27. 27. Model does not satisfy security design requirements. TESEM detected incorrect applications of design patterns Case Study: Test failed, again 28
  28. 28. Case Study: Model fixing 29 Fix design model until the tests successfully pass. Correct designIncorrect design Refactoring
  29. 29. Agenda • Introduction • Security patterns • TESEM: testing models • TESEM: testing code • Conclusion and discussion 30
  30. 30. TESEM: Test Driven Secure Modeling Tool [ARES’14] 31 Security pattern Problem Solution Context Test design as requirement ! create Actor ! create UI : ! create Subject.. Test Script Testcase Testing [ARES’14] Verification of Implementing Security Design Patterns Using a Test Template, Int’l Conf. Availability, Reliability and Security
  31. 31. 32 Security design pattern Problem Solution Context Instrumentation template in Aspect J Testcase template in Java SUT Concrete aspect in AspectJ Concrete testcase in Java Specify parameters Instrumentation Testing Preparation Template for creating testcases
  32. 32. Agenda • Introduction • Security patterns • TESEM: testing models • TESEM: testing code • Conclusion and discussion 33
  33. 33. Controlled experiments • Target: EMSec [*], 24 use cases, 31 classes • Ex 1: Pattern application to design – 8 of 10 students applied patterns incorrectly without TESEM. – All students confirmed incorrect applications by TESEM. – Few students successfully fixed design. • Ex 2: Fixing code with incorrect pattern application – All 4 students found more defects in shorter time per defect by using TESEM. – All 4 students successfully fixed most of defects by using TESEM, but required little longer time. 34 [*] EMSsec http://lab.iisec.ac.jp/~okubo_lab/Members/okubo/wiki/index.php?EMSSec TESEM is useful for identifying incorrect applications. Further fixing support is expected.
  34. 34. A tool called TESEM that supports pattern registration, application and verification Pattern-oriented test architecture and extended security patterns using OCL-based constraints and templates, which include requirement- and design-level patterns A new model/code-testing process based on TDD to verify appropriate pattern applications and the existence of vulnerabilities using these extended patterns Conclusion 35 [ARES’13] Validating Security Design Pattern Applications Using Model Testing, Int’l Conf. Availability, Reliability and Security [ARES’14] Verification of Implementing Security Design Patterns Using a Test Template, Int’l Conf. Availability, Reliability and Security [IJSSE’14] Validating Security Design Pattern Applications by Testing Design Models, Int’l J. Secure Software Engineering 5(4) [ICST’15] TESEM: A Tool for Verifying Security Design Pattern Applications by Model Testing, IEEE ICST’15 Tools Track
  35. 35. Discussion • Pattern-oriented test architecture – Efforts for preparing constraints/templates paid off? – Correctness of patterns and concretization process? – Need more appropriate or different architecture? • Security pattern ecosystem – Zero-day attack? – Common Vulnerabilities and Exposures (CVE) -> patterns -> concrete tests -> … • Fixing / refactoring support – Automated fixing/refactoring ? 36
  36. 36. 37 Mar 13-18 (due Sep 2016) aster.or.jp/conference/icst2017/ 10th IEEE International Conference on Software Testing, Verification and Validation

×