April 2017, Volume 2, Issue 1, JSEIS, CAOMEI Copyright © 2016-2017
Validation of applied security design patterns using test templates in secure aware SDLC
A. Rama Mohan Reddy,
K.V. N. Sunitha
Department of IT, Vardhaman College of Engineering
SVU College of Engineering, Tirupathi, India
BVRIT for Women, Hyderabad, India Email: 
Security patterns are security knowledge encapsulated tools, they have significant contributions for supporting the software developers as all the software developers need not to be a security specialists. If the applied  patterns are inappropriate, this will create vulnerabilities in the product implementation. Here we proposed a method for validation of applied security design patterns in the implementation phase of software development life cycle (SDLC). In this paper, we are verifying the security pattern by creating reusable test case. As a case study, we are validating the applied security patterns for Patient Monitoring System (PMS) application. We  believe, the applied security patterns structure is verified in implementation phase. With this we achieve, the security patterns are successfully structured and verified in design and implementation phase. Thus, we can rename SDLC as secure aware SDLC.
secure software; design patterns; software development; patient monitoring system;
Currently, resolving the security critical issues are vital because most of the e-services are provided by  public and private clouds. Preventing the security issues are mandatory to avoid the big loss due to security threats and vulnerabilities [1]. Security must be considered in every aspect of software development process [2]. Fernandez et al. [3] proposed a methodology for integrating security patterns into each one of the software development stages. All the software developers are not security specialists to deal with the security issues that arise during the product development process. As per the latest research, there are 400 security patterns, these security patterns are reusable, based on the existing classification we can select the pattern based on the domain specific or life cycle phases. Chris Steel et al designed 23 core security patterns for J2EE applications such as Web Tier(9), Business Tier(7), Web Service Tier(3) and Identity Tier(4) patterns[4].Schumacher et al proposed 25 design-level security patterns [5]. More  patterns and pattern catalogs were developed for different types of security objectives, threats, vulnerabilities [6 - 13]. Security patterns alone are not enough for supporting the development lifecycle, since they do not have the systematic procedures for an application throughout the complete software lifecycle. A security design  pattern is a reusable security knowledge encapsulated tool that can be frequently applied to recurring security  problems. During the requirement phase, for the identified security required asset, we must design that asset along with the security patterns. Here the security pattern is security deriving tool to security properties for the identified security critical asset. Security design pattern template consists of Problem, Forces, Solution (structure and strategies), Consequences, security factors and risks, reality checks and related patterns [14]. A pattern can be frequently used as a structure in design phase, behavior or active process in implementation phase. Due to enormous number of security patterns, there are more number of different classifications. Due to abstract description of security patterns, to pick and use the pattern is burdensome. If the  patterns are appropriately selected or applied during design phase, consequently this lead to vulnerabilities in the development. Thus, that we must validate the applied patterns are appropriate or not, whether this will exhibit the correct output for the input during the implementation since all the developers are not security specialists. Many researchers proposed to represent the security design patterns representation in the model during Architecture phase [30]. This will give structure of the design pattern. Due to abstract descriptions of patterns, this is a burden for developers to know the behavior of the pattern during the implementation phase. Due to poor coupling between representation and implementation of security patterns developer cannot be able to predict the impact of pattern on software that we must verify the applied pattern in the model in implementation  phase to make, pattern support to software developers. This paper is organized as related work in Section II, implementation process of our proposed method as a test case in Section III, case study in Section IV, conclusion and future work in Section V.
 April 2017, Volume 2, Issue 1, JSEIS, CAOMEI Copyright © 2016-2017
Several research practitioners focused on the verification of security patterns. Abramov et al. (2009)  proposed a novel approach that utilizes security patterns for enforcing security over database applications design and injecting security constraints to the database. But this approach lacks in expressiveness of security constraints for low level elements such as attributes. The research study in [15] proposed stereotype. Peng et al. (2008) presented a formal verification method to analyze the behavioral correctness of a design pattern implementation. Their method proposed the partial order relationship between the sequence diagram of a general design pattern and that of its implementation. However, this method does not verify the structural  behaviour of the implementation. Therefore, there is a need to develop an approach to automatically and fully validate the implementation of patterns [16]. Dongs et al. (2010) proposed a method to verify the compositions of security pattern using model checking. This approach formally defines the behavioral aspect of Security patterns but it does not conduct analysis at the implementations level even though it is verified at model level [17]. Hamid et al. (2012) proposed a method to validate the applications of patterns at the model level by UML and OCL but this is also not applicable implementation level analysis [18]. Jan Jurjens (2005) proposed UMLsec tool in the form of a UML profile using standard UML extension mechanisms. Stereotypes are used to formulate the security requirements, while constraints are used to verify whether the security requirements hold during a specific type of attack [19]. Lodderstedt et al. (2002) proposed secureUML that focuses on modeling access control policies and how these policies can be integrated into a model-driven software development process. It is based on RBAC model and uses RBAC as a meta-model to specify and enforce security. RBAC lacks support to express access control conditions that refer to the state of a system, such as the state of a protected resource. In addressing this limitation, secureUML introduces the concept of authorization constraints. Authorization constraints are preconditions for granting access to an operation [20]. Both secureUML and UMLsec techniques are supporting modeling security-related concerns in UML models, they cannot be directly used to check the correctness of security pattern applications at the implementation level. Masatoshi et al. (2016) proposed a TESEM tool, that is used to create a reusable test case template, which is derived from in the consequence of Test Driven Development model (TDD), Object Constraint Language (OCL), Aspect Oriented Programming (crosscutting concerns such as pointcut and advice pair), Junit tool to test the test case. Using this method, a supporting reusable test template is created, which is useful for the developers as a concrete test template for testing the applied security pattern in the implementation phase [21]. But, in this method the designer/researcher must have knowledge of OCL to verify the structure of the design patterns.
To implement our method, we used decision table testing, Aspect-Oriented Programming, Junit testing Tool. Our proposed method adopts decision tables to describe the specifications of target security design  patterns [22], most of the decision table testing is used for web applications [23]. Aspect-oriented Programming is used to improve the modularity of the software product in terms of crosscutting concerns [24, 25]. JUnit tool for testing Application, once the template is created, then is tested using the JUnit tool [26, 27]. In our method, we created the reusable test template as follows: 1.
Select the appropriate security pattern from the available catalogs, we are suggesting to select the  pattern based on the annotations of Koen
 proposed classification [28, 29]. During requirements phase, select the pattern for each type of security concern. 2.
Represent the selected patterns in the model during architecture phase. 3.
Verify the structure of the pattern and analyze the pattern behavior with respect to security required assets. 4.
Create a decision table for every security concern provided by pattern, based on true positive and false negative values that is conditions and actions. 5.
Use aspect oriented programming, for each condition to analyze the internal processing of the pattern without omitting all the possible escape artifacts based on decision table. 6.
Create a test case based on the behavior of the pattern with aspect programming crosscutting concerns. 7.
Run the test case with all the possible cases using JUnit tool, fix the bugs. 8.
Revalidate the tool by retesting, if the process is successful stop the process. 9.
If the test is failure, then repeat the steps from 4 to 7.
 April 2017, Volume 2, Issue 1, JSEIS, CAOMEI Copyright © 2016-2017
We are implementing the above proposed method to electronic health domain application named as Patient Monitoring System [30]. In this application, a doctor is monitoring the patient remotely using the sensors. A wearable unit of the patient is continuously measuring the patient condition such as a pulse rate, blood pressure. These readings are collected and stored in the PMS device (smart phone). The stored PMS database, analyzes and alerts the doctor about the patient health condition if it comes to abnormal condition. When it analyzes and indicates as an emergency, it notifies the emergency services. The same system is accessible by the doctor,
 patient care taker as well as the patient relatives. They can review the patient’s status.
 The same system is also connected to the hospital information system (HIS) [30]. In this application, in order to access the patient information by the doctor, the doctor has to authenticate himself by providing the user ID and Password. Step 1, 2: In this context, we are using the Password Design and Use pattern, Prevent SQL Injection Patterns. The Password Design and Use pattern describes the best security practice to design, create, manage, and use password components [5, 30].
Figure. 1
 Login portion of the doctor to access patient data. Step 3, 4: in this step, we are analyzing the pattern behavior based on the decision table as shown in Table 1.
Table. 1
 Decision Table
1 2 3 4 Conditions Given ID agrees with User Data Y Y N N Given PW agrees with User Data Y N Y N Actions Considered as Doctor
 Can Access Patient sensitive data
 Considered as a Malicious User
Can’t Acce
ss Patient sensitive data
 Based on the decision table, we are configuring the aspect oriented crosscutting concerns in the next step.
 April 2017, Volume 2, Issue 1, JSEIS, CAOMEI Copyright © 2016-2017
4 Step 5, 6: creation of aspect template such as crosscutting concerns in terms of pointcut and advices based on the step 3 & 4.
Pointcut LoginCheck(); Call(* *.password_design_and_use.check_identification(..));
Figure. 2
 Pointcut considering for authorization doctor after() returning(Boolean right):
EscapeCheck() { setTemporary(“LoginCheck”, right);}
Figure. 3
 Advice to differentiate the two types of users
Pointcut AssetAccess(); Call(* *.Subject_Controller.subject_function(..));
Figure. 4
 Pointcut judging access to patient sensitive data
after() returning(Boolean right):
AssetAccess() { setTemporary(“AssetAcess”, right);}
Figure. 5
 Advice to allow access patient sensitive data Figures 2, 3, 4 and 5 show the aspect oriented crosscutting concerns for modular based pointcuts and corresponding advices.  Now we create the test template based on above points without omitting any security aspect. Step: 7, 8, 9: With JUnit tool run the test case by providing the input, if the results are failure, then retest the template and revalidate until the test case is going to produce the correct outputs for inputs.
Figure. 6
 Results of the failure test case
of 7