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.

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. • 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. Agenda
• Introduction
• Security patterns
• TESEM: testing models
• TESEM: testing code
• Conclusion and discussion
4

4. Appropriate
design
Inappropriate
design
What’s the problem?
5
Role-based access control (RBAC) pattern

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. Agenda
• Introduction
• Security patterns
• TESEM: testing models
• TESEM: testing code
• Conclusion and discussion
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. 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. • 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. 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. 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. 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. Agenda
• Introduction
• Security patterns
• TESEM: testing models
• TESEM: testing code
• Conclusion and discussion
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. 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. Apply SDPUML
UML
Incorrect pattern
application
Vulnerabilities
are not resolved
Conventional problematic process
Identify assets, threats,
and countermeasures
Select SDP
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. • Nine types of security properties
• E.g. “Access Control”
Security property at requirements level
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. 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. 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. 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. • 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. 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. Actor can execute “delete” function without access right !
Model may contain vulnerability causing Privilege Escalation.
Case Study: Test failed
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. Model does not satisfy security design requirements.
TESEM detected incorrect applications of design patterns
Case Study: Test failed, again
28

28. Case Study: Model fixing
29
Fix design model until the tests successfully pass.
Correct designIncorrect design
Refactoring

29. Agenda
• Introduction
• Security patterns
• TESEM: testing models
• TESEM: testing code
• Conclusion and discussion
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. 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. Agenda
• Introduction
• Security patterns
• TESEM: testing models
• TESEM: testing code
• Conclusion and discussion
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. 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. 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. 37
Mar 13-18 (due Sep 2016)
aster.or.jp/conference/icst2017/
10th IEEE International Conference on
Software Testing, Verification and Validation