Software Security Risk Mitigation Using Object Oriented Design Patterns

IJRET: International Journal of Research in Engineering and Technology
eISSN: 2319-1163 | pISSN: 2321-7308
SOFTWARE SECURITY RISK MITIGATION USING OBJECT

ORIENTED DESIGN PATTERNS
Rehman S1, Mustafa. K2
Department of Information Technology, Salman bin Abdul Aziz University, KSA, shabana.infosec@gmail.com
Department of Computer Science,Jamia Millia Islamia, India, kmustafa@jmi.ac.in
Abstract
It is now well known that requirement and the design phase of software development lifecycle are the phases where security
incorporation yields maximum benefits.In this paper, we have tried to tie security requirements, security features and security design
patterns together in a single string. It is complete process that will help a designer to choose the most appropriate security design
pattern depending on the security requirements. The process includes risk analysis methodology at the design phase of the software
that is based on the common criteria requirement as it is a wellknown security standard that is generally used in the development of
security requirements. Risk mitigation mechanisms are proposed in the form of security design patterns. Exhaustive list of most
reliable and well proven security design patterns is prepared and their categorization is done on the basis of attributes like data
sensitivity, sector, number of users etc. Identified patterns are divided into three levels of security. After the selection of security
requirement, the software designer can calculate the percentage of security features contribution and on the basis of this percentage;
design pattern level can be selected and applied.
-------------------------------------------------------------------------***------------------------------------------------------------------------------------
1. INTRODUCTION
Mainly software systems are developed without security
requirements in mind, which happen because developers
usually tend to concentrate their efforts in first understanding
systems functional requirements, non-function ones, like
security, on a second plan [Ferraz et al., 2009]. Number of
approaches of security incorporation in software development
life cycle had been proposed, some of the well-known
approaches includes UMLsec [Jurjens,2004]; CORAS
[Braber,
2003];
CLASP
[Chandra,
2006];
SecureTropos[Mouratidis, 2007] ;Goal-Risk [Ansar et al.,
2007] etc. But there is no standard method that is reliable,
well defined and based on security features and design
patterns. Still there is significant need to develop a risk
estimation method in the design phase of the software that can
estimate the need of security feature and guide the designer to
choose appropriate security design pattern accordingly.
In this paper CC (Common Criteria) security requirements
[Common Criteria, 2008] is taken as a reference model and its
all 64 classes (software specific) are accumulated in six basic
security feature classes which include 1).Authentication;
2).Authorization; 3). Audit and Logging; 4).Secured Storage;
5). Secure Information Flow and 6). Secure Session
Management. The percentage of contribution of each security
feature is calculated on the basis of common keywords in the
CC security requirement class and the security feature class
definition. Further the weightage of each requirement is
calculated on the basis of availability of security feature under
each class of security requirement. The risk factor of each

security feature is calculated on the basis of their occurrence
in the requirements and the severity of the feature and finally
mitigation level is proposed according to the risk factor of
each security feature. Each risk mitigation level consist of
various design patterns that are classified on the basis of
attributes like data sensitivity, number of users involved etc.
Rest of the paper is organized as follows, in section 2,
Common Criteria requirements are discussed. In section 3,
security feature class is explained followed by section 4, in
which relationship of common criteria security requirements
and security features is covered. Risk analysis of security
features is presented in section 5.Section 6 covers the risk
mitigation through design patterns and case study is carried
out in section 7 followed by conclusion and future work in
section 8.
2.0 CC STANDARD AND SECURITY FEATURE

CLASS
The Common Criteria (CC) is an internationally recognized
approach to security evaluation of IT products. It provides a
set of criteria, which can be used to set security requirements
of IT products. These requirements serve as a guide for the
development, procurement and evaluation of IT security
features and products [NATO, 2008]. The CC permits
comparability between the results of independent security
evaluations. The CC does so by providing a common set of
requirements for the security functionality of IT products and
for assurance measures applied to these IT products during a
__________________________________________________________________________________________
Volume: 02 Issue: 07 | Jul-2013, Available @ http://www.ijret.org
71
security evaluation. These IT products may be implemented in

hardware, firmware or software. [Common Criteria, part 2].
There are total 65 class of security requirement in common
criteria. After exhaustive review of these requirements, it was
found that out of 65, 64 requirements are applicable to
software. The class that is left out is 15.6 TSF physical
protection (FPT_PHP), as this class is applicable to the
hardware and firmware security only. The reason of choosing
common criteria standard is that it is well proven that it has a
potential to relate Taxonomy of vulnerabilities and can be
used in the risk estimation and mitigation.According to
[Malboeuf, et al. 2004, December] the CC has the potential to
relate to the following:
1) Structured terminology of controls;
2) Qualitative description of safeguards;
3) System architecture model;
4) Applicable threat model, including threat agent attributes
(motivation, capability, opportunity, etc) and threat
scenarios;
5) Taxonomy of relevant vulnerabilities;
6) Classification scheme / sensitivity analysis of information
assets;
7) Impact analysis of information assets, with respect to
confidentiality, integrity and vailability scenarios, and
possibly mode of access;
8) Risk derivation model, the functional relation between risk
and any of the above parameters;
9) Risk mitigation model linking safeguards and controls to
threat scenarios; and
10)Risk acceptance of system operations is assessed based on
CC evaluation results of security components of a system.
In our approach, the common criteria requirement will be used
in the risk analysis of object oriented design and relationship
is created with security feaures classes.
Taxonomy of security features to classify vulnerabilities is
already developed [Rehman and Mutafa, 2010]. Here same
taxonomy of security feature is adapted to perform risk
analysis on security requirements. Due to complexity of
access control at database storage, secured storage was
excluded from the taxonomy, but as accurate risk analysis
cannot be performed without the consideration of secured
eISSN: 2319-1163 | pISSN: 2321-7308
storage, the inclusion of this class is necessary. The first level

software vulnerability taxonomy is shown in figure 2.1.The
whole process of taxonomy creation is explained in [Rehman
and Mutafa, 2011].
Access Control at
Storage Level
Secured
Storage
Figure 2.1: First level hierarchy of security features at

architectural design level
3. RELATING CC REQUIREMENTS AND

SECURITY FEATURE
There are 64 security requirements class of Common Criteria
that are applicable to software. In order to measure security
feature class risk factor, the common criteria requirement
needs to be expressed in terms of security feature classes. The
first steps towards it includes the availability of each security
feature class in each CC requirement security class
definition. To achieve this, common keywords were
identified from security feature of each class and the
description of each CC security requirement class. The table
3.1 is the list of keywords used to relate CC security
requirement class and vulnerability class.
Table 3.1 List of keywords in vulnerability class

S. No.
1.
Vulnerability Classes
Authentication
Common Keywords
Authentication; Non Repudiation; User Attribute; Specification of

Secrets; Data Identification; User-Subject Binding; Event
Selection
__________________________________________________________________________________________
72
2.
Authorization
eISSN: 2319-1163 | pISSN: 2321-7308
Authorization; Authorized users; Access control; Data

Identification, Non Repudiation; Rollback; User attribute;
Specification of Secrets; User-Subject Binding; Management of
Functions Security Attributes and Data; Priority of Service; Event
Selection ; Integrity, Availability, Confidentiality of data
3.
Audit and Logging
Audit; Logging; Rollback; Non Repudiation; Fail Secure;

Authentication Failure; Fault tolerance
4.
Secured Data Storage
Data storage; Residual; Rollback; Management of data;

Revocation; Availability of data
5.
6.
Secure Information
Information Flow; Data Export; Data Import; Data Transfer;
Flow
Data Consistency; Confidentiality and integrity of Data
Secure Session
Session Management; Replay Detection; State Synchronization;
Management
Data Consistency; Availability of Data

Automatic Response (FAU_ARP) and security feature class
Audit and logging have more than one word in common like
audit, logging, response. This makes the value of security
audit automatic requirement, under audit and logging class
equals to 1 all the other values in first row remains 0.
The availability matrix of vulnerability class and the CC

security requirement class is shown in table 3.2. Similar
approach of availability matrix is created in [Berghe,et al,
2010].
The value 1 is assigned when CC security
requirement and security class have more than one common
keyword and value 0 is assigned when no keyword matches
between the two, for example CC class Security Audit
Table 3.2 Availability matrix of vulnerability class and the CC security requirement class
S.No.
1.
Requirement Classes
8.1 Security audit automatic

response (FAU_ARP)
2. 8.2 Security audit data generation
(FAU_GEN)
3. 8.3 Security audit analysis
(FAU_SAA)
4. 8.4 Security audit review
(FAU_SAR)
5. 8.5 Security audit event selection
(FAU_SEL)
6. 8.6 Security audit event storage
(FAU_STG)
7. 9.1 Non-repudiation of origin
(FCO_NRO)
8. 9.2 Non-repudiation of receipt
(FCO_NRR)
9. 10.1 Cryptographic key
management (FCS_CKM)
10. 10.2 Cryptographic operation
(FCS_COP)
11. 11.1 Access control policy
(FDP_ACC)
Authen
ticatio
n
(Au)
Autho
rization
(Ao)
Audit
and
Loggi
ng
(At)
Secured
Storage
(S)
Secur
e
Infor
mation
Flow
(If)
Secure
Session
manage
ment
(Ss)
Tota
l
Max
=6
__________________________________________________________________________________________
73
12. 11.2 Access control functions

(FDP_ACF)
13. 11.3 Data authentication
(FDP_DAU)
14. 11.4 Export from the TOE
(FDP_ETC)
15. 11.5 Information flow control
policy (FDP_IFC)
16. 11.6 Information flow control
functions (FDP_IFF)
17. 11.7 Import from outside of the
TOE (FDP_ITC)
18. 11.8 Internal TOE transfer
(FDP_ITT)
19. 11.9 Residual information
protection (FDP_RIP)
20. 11.10 Rollback (FDP_ROL)
21. 11.11 Stored data integrity
(FDP_SDI)
22. 11.12 Inter-TSF user data
confidentiality transfer protection
(FDP_UCT)
23. 11.13 Inter-TSF user data integrity
transfer protection (FDP_UIT)
24. 12.1 Authentication failures
(FIA_AFL)
25. 12.2 User attribute definition
(FIA_ATD)
26. 12.3 Specification of secrets
(FIA_SOS)
27. 12.4 User authentication
(FIA_UAU)
28. 12.5 User identification (FIA_UID)
29. 12.6 User-subject binding
(FIA_USB)
30. 13.1 Management of functions in
TSF (FMT_MOF)
31. 13.2 Management of security
attributes (FMT_MSA)
32. 13.3 Management of TSF data
(FMT_MTD)
33. 13.4 Revocation (FMT_REV)
34. 13.5 Security attribute expiration
(FMT_SAE)
35. 13.6 Specification of Management
Functions (FMT_SMF)
36. 13.7 Security management roles
(FMT_SMR)
37. 14.1 Anonymity (FPR_ANO)
38. 14.2 Pseudonymity (FPR_PSE)
39. 14.3 Unlinkability (FPR_UNL)
40. 14.4 Unobservability (FPR_UNO)
41. 15.1 Fail secure (FPT_FLS)
42. 15.2 Availability of exported TSF
data (FPT_ITA)
43. 15.3 Confidentiality of exported
TSF data (FPT_ITC)
44. 15.4 Integrity of exported TSF data
(FPT_ITI)
45. 15.5 Internal TOE TSF data
transfer (FPT_ITT)
46. 15.6 TSF physical protection
(FPT_PHP)
47. 15.7 Trusted recovery (FPT_RCV)
48. 15.8 Replay Detection (FPT_RPL)
49. 15.9 State Synchrony Protocol
(FPT_SSP)
eISSN: 2319-1163 | pISSN: 2321-7308
0
0
0
1
1
1
1
1
0
0
0
0
2
3
1
1
1
1
0
0
1
0
0
0
0
0
3
2
1
1
1
1
0
0
0
0
0
0
0
0
2
2
1
0
0
0
0
0
1
1
1
1
0
1
0
1
1
0
1
0
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
0
2
2
2
1
1
3
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
0
1
1
2
2
2
__________________________________________________________________________________________
74
eISSN: 2319-1163 | pISSN: 2321-7308
50. 15.10 Time stamps (FPT_STM)

51. 15.11 Inter-TSF TSF data
consistency (FPT_TDC)
52. 15.12 Testing of external entities
(FPT_TEE)
53. 15.13 Internal TOE TSF data
replication consistency (FPT_TRC)
54. 15.14 TSF self test (FPT_TST)
55. 16.1 Fault tolerance (FRU_FLT)
56. 16.2 Priority of service (FRU_PRS)
57. 16.3 Resource allocation
(FRU_RSA)
58. 17.1 Limitation on scope of
selectable attributes (FTA_LSA)
0
0
0
0
0
0
0
1
1
1
1
1
2
3
1
0
0
0
1
1
1
1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
3
1
1
1
59. 17.2 Limitation on multiple

concurrent sessions (FTA_MCS)
60. 17.3 Session locking and

termination (FTA_SSL)
61. 17.4 TOE access banners

(FTA_TAB)
62. 17.5 TOE access history

(FTA_TAH)
63. 17.6 TOE session establishment

(FTA_TSE)
64. 18.1 Inter-TSF trusted channel

(FTP_ITC)
65. 18.2 Trusted path (FTP_TRP)

Total
0
27
0
46
0
21
0
18
1
20
0
9
Total number of security requirements classes under common

criteria are 64, one class i.e. 15.6 TSF physical protection
(FPT_PHP) is not applicable in the case of software.
Therefore total 64 classes are considered. As total number of
security feature classes are 6, therefore total number of
possible values are 384.Out of which total number of ones in
the matrix are 141.Now in order to find out weightage of each
security Feature in terms of its availability in the security
requirements, the values of Sac (Security Feature Contribution
percentage) can be calculated as follows:
Table 3.3: Security Feature Occurrence in Requirements

S. No.
Security Features
OSR
SFC
1.
Authentication
27
19.14894
2.
Authorization
46
32.62411
3.
Audit & logging
21
14.89362
Total number of cells= 64 x 6 = 384
4.
Secure Storage
18
12.76596
Total Occurrence of Ones =141
5.
Secured Information
Flow
20
Secured Session
Management
09
Total
141
14.1844
SFC = (OSR /Total Number of Occurrences) x 100

6.
= (OSR/141) x 100
Where,
6.38297
100
SFC = Security Feature Contribution

OSR = Occurrence of each Security feature in Requirements
The final values of OSR and SFC are shown in table 4.3
__________________________________________________________________________________________
75
eISSN: 2319-1163 | pISSN: 2321-7308
Now as it can be seen in table 3.2, that several requirements

have more then one security Feature occurrences. Therefore
weight of each security requirement in terms of security
Feature, can be calculated by adding the SFC values of each
Feature. The final weightage of each security Feature is
termed as TSFC (Total Security Feature Contribution under
each Requirement).The TSFC values are shown in Table 3.4.
Table 3.4.CC Requirements Classes with TSFC Values
S. No.
CC. Class No.
CC Requirement Class Title
Subsets of security
TSFC
Features
1.
8.1
Security audit automatic response (FAU_ARP)
(At)
14.89362
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
8.2
8.3
8.4
8.5
8.6
9.1
9.2
10.1
10.2
11.1
11.2
11.3
11.4
11.5
11.6
11.7
11.8
11.9
11.10
11.11
11.12
11.13
12.1
12.2
12.3
12.4
12.5
12.6
13.1
13.2
13.3
13.4
13.5
13.6
13.7
14.1
14.2
14.3
14.4
15.1
15.2
15.3
15.4
15.5
Security audit data generation (FAU_GEN)

Security audit analysis (FAU_SAA)
Security audit review (FAU_SAR)
Security audit event selection (FAU_SEL)
Security audit event storage (FAU_STG)
Non-repudiation of origin (FCO_NRO)
Non-repudiation of receipt (FCO_NRR)
Cryptographic key management (FCS_CKM)
Cryptographic operation (FCS_COP)
Access control policy (FDP_ACC)
Access control functions (FDP_ACF)
Data authentication (FDP_DAU)
Export from the TOE (FDP_ETC)
Information flow control policy (FDP_IFC)
Information flow control functions (FDP_IFF)
Import from outside of the TOE (FDP_ITC)
Internal TOE transfer (FDP_ITT)
Residual information protection (FDP_RIP)
Rollback (FDP_ROL)
Stored data integrity (FDP_SDI)
Inter-TSF user data confidentiality transfer
Inter-TSF user data integrity transfer protection
protection
(FDP_UCT)
Authentication
failures (FIA_AFL)
(FDP_UIT)
User attribute definition (FIA_ATD)
Specification of secrets (FIA_SOS)
User authentication (FIA_UAU)
User identification (FIA_UID)
User-subject binding (FIA_USB)
Management of functions in TSF (FMT_MOF)
Management of security attributes
Management of TSF data (FMT_MTD)
(FMT_MSA)
Revocation (FMT_REV)
Security attribute expiration (FMT_SAE)
Specification of Management Functions
Security management roles (FMT_SMR)
(FMT_SMF)
Anonymity (FPR_ANO)
Pseudonymity (FPR_PSE)
Unlinkability (FPR_UNL)
Unobservability (FPR_UNO)
Fail secure (FPT_FLS)
Availability of exported TSF data (FPT_ITA)
Confidentiality of exported TSF data
Integrity of exported TSF data (FPT_ITI)
(FPT_ITC)
Internal TOE TSF data transfer (FPT_ITT)
( Ao, At )
(Ao, At )
(Ao, At)
(Ao, At )
(Ao, At )
(Ao, At)
(Au, Ao, At )
(Ao, S, If )
( If)
( Au, Ao)
( Au, Ao)
( Au, S)
( Au, If)
( Au, If, Ss )
( Au, If, Ss )
( Au, Ao,If,)
( Au, Ao,If,)
( Au, Ao, If)
( At, S,)
( Ao, At, S )
(Ao, If)
(Ao, If )
( Au, At, S)
( Au, Ao,)
( Au, Ao, S )
( Au,S )
( Au, Ao, S )
( Au, Ao )
( Au, Ao, S )
( Au, Ao, S)
( Au, Ao )
( Au, Ao)
( Au, Ao)
( Au, Ao)
( Au, Ao)
( Au, Ao )
( Ao, At)
( Ao, At )
( Ao )
( At)
(Ao, S, If)
( Ao, At, If )
(Ao, At, If)
(Ao, At, If )
47.51773
47.51773
47.51773
47.51773
47.51773
47.51773
66.66667
59.57447
14.1844
51.77305
51.77305
31.9149
33.33334
39.71631
39.71631
65.95745
65.95745
65.95745
27.65958
60.28369
46.80851
46.80851
46.80852
51.77305
64.53901
31.9149
64.53901
51.77305
64.53901
64.53901
51.77305
51.77305
51.77305
51.77305
51.77305
51.77305
47.51773
47.51773
32.62411
14.89362
59.57447
61.70213
61.70213
61.70213
__________________________________________________________________________________________
76
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
15.7
15.8
15.9
15.10
15.11
15.12
15.13
15.14
16.1
16.2
16.3
17.1
17.2
17.3
17.4
17.5
17.6
18.1
18.2
Trusted recovery (FPT_RCV)

Replay Detection (FPT_RPL)
State Synchrony Protocol (FPT_SSP)
Time stamps (FPT_STM)
Inter-TSF TSF data consistency (FPT_TDC)
Testing of external entities (FPT_TEE)
Internal TOE TSF data replication consistency
TSF self test (FPT_TST)
(FPT_TRC)
Fault tolerance (FRU_FLT)
Priority of service (FRU_PRS)
Resource allocation (FRU_RSA)
Limitation on scope of selectable attributes
Limitation on multiple concurrent sessions
(FTA_LSA)
Session locking and termination (FTA_SSL)
(FTA_MCS)
TOE access banners (FTA_TAB)
TOE access history (FTA_TAH)
TOE session establishment (FTA_TSE)
Inter-TSF trusted channel (FTP_ITC)
Trusted path (FTP_TRP)
Total
Now to calculate the maximum possible values of security

requirements in terms of security Feature, the sum of all the
TSFC values is carried out, as follows:
n
MVSFC = TSFC = 2857.447
i=1
Where,
MVSFC = Maximum Value of Security Feature Contribution
in Requirements
After getting the maximum possible value of security
requirement in terms of security Features, a scale is created to
measure the security requirement weight. The minimum value
is taken as 0 and maximum value is taken as 2857.447. Now
software developer have to select the desired requirements
from a set of available 64 classes of requirements. The sum of
desired security requirements is stored in variable MVSFC.
eISSN: 2319-1163 | pISSN: 2321-7308
(At, S)
( If, Ss )
( If, Ss )
(If, Ss )
( S, If, Ss )
( Au, Ao, At )
( At, S)
( Au, Ao, S)
(Ao )
( Ao )
(Ao )
(Ao )
( Ao, If, Ss )
(Ao, Ss )
( Ao )
( Ao, At, S )
( Au,Ss )
( If )
( If )
27.65958
20.56737
20.56737
20.56737
33.33333
66.66667
27.65958
64.53901
32.62411
32.62411
32.62411
32.62411
53.19148
39.00708
32.62411
60.28369
25.53191
14.1844
14.1844
2857.447
(2143.085-2857.447) is for the very secured requirements.

When the value of MVSFC falls between (0-714.361), then
this indicates that not enough security requirements class are
chosen, therefore there is no need to perform next step of Risk
analysis. When the value of MVSFC falls in the second sloth
then it is a indication that chosen security requirements are too
generic in nature and software have marginal need of security
e.g. security need of simple text processing software for home
users. The third part is for the secured software, when MVSFC
value falls in this slot then designer of the software have to
take extra care of the security and has to choose reliable and
well proven security design pattern i.e. pattern suggested in
Level2 of Table 5.2. The value in the last slot indicates that
utmost care of security should be taken. It is for the software
that handles highly confidential information. Use of Level 3
design pattern of Table 5.2 are suggested in this case. Table
3.5 is showing the MVSFC values and suggested security
design pattern levels:
Table 4.5: MVSFC Sloths and Risk Mitigation Levels
S.NO.
0
714.361
1428.724
2143.085
2857.447
Undefine
General
Secured
Very Secured
Fig. 3.1 Software Security Requirement Scale
The scale is divided into four equal parts as shown in Fig.3.1.
First part i.e. (0 714.361) is for undefined security
requirements, second part i.e. (714.361-1428.724) is for
general security requirements, third part i.e. (1428.724 2143.085) is for secured requirements and the last slot i.e.
MVSFC Sloth
Class
- 714.361
714.36 1428.724
1428.724
2143.085
2143.085
2857.447
Undefined
General
Risk
Mitigation
Level
N/A
L1
Secured
L2
Very Secured
L3
__________________________________________________________________________________________
77
The approach used in this section can be used when the

software developer want to find the overall risk involve by just
selecting the desired requirement from the list. Based on the
MVSFC value mitigation level can be chosen. But there is one
more way through which Security design pattern can be
chosen by the developer based the value of the security
feature. In the next section risk analysis based on security
features values is explained.
4. RISK ANALYSIS OF SECURITY FEATURES

Risk analysis is a process for considering possible risks and
determining which are the most significant for any particular
effort [Ruffin et al., 2007]. In order to incorporate security in
the software, risk analysis should be performed right from the
beginning from software development lifecycle. Developers
are expected to identify, rank, mitigate and manage risk
throughout the software product life cycle [Devis, 2004]. To
attend software security risks at the design level, the security
requirements should be addressed first followed by Risk
calculation which facilitates designer in choosing appropriate
security design pattern. Since available security design
patterns, modeled by various software designers/experts often
cannot be traced back to the security requirement, there is a
need to relate these security patterns to requirements so that
smooth chain of security events in SDLC can be created.
In order to calculate the risk factor of each security feature,
first of all the severity constant is calculated. As explained in
chapter 4, the severity of vulnerability under each security
feature is calculated using design level vulnerabilities of NVD
(National Vulnerability Database). The severity values
assigned are basically calculated by CVSS (Common
Vulnerability Scoring System). The value of severity, assigned
by CVSS is in the scale of 0-10.In order to relate its values
with other variables, we have multiplied it 10, so that the
values of severity can be calculated in terms of percentage (0100). As the process involves the risk analysis of security
feature, the occurrence of each security feature in
requirements (OSR) is calculated next. The maximum value of
OCR i.e. MaxOCR will always be equals to the values
selected in the requirements set, e.g. if designer has selected
40 security requirements from the set of 64 security
requirements then the maximum value of OCR will be 40 for
each security feature. Now using OCR and MaxOCR, the
percentage of each security feature contribution in
requirements (PSR) can be calculated as follows:
eISSN: 2319-1163 | pISSN: 2321-7308
MaxC = Maximum value of the Constant = 100

OSR = Occurrence of each Security Feature in the Desired
Requirement
MaxOSR = Maximum Possible Frequency of Security Feature
in the Desired
Requirements
= Number of Desired Requirements
PSR = Percentage of Security Feature Contribution in the
Desired Requirement
= (OSR / MaxOSR) x 100
RFS = Risk Factor of Security Feature based of the Desired
Requirements
= SC*PSR/100
MaxRF = Maximum value of Risk Factor for each Feature
= SC*MaxPSR /100
MaxPSR = Maximum value of all the Possible Security
Requirement
= 64
APRF = Actual Percent of Risk Factor for each Security
Feature
= RF x 100 / MaxRF
PSR = (OSR / MaxOSR) x 100

All the values that are assigned and calculated in order to
calculate the risk factor of security feature is shown in Table
4.1.
Where,
SC = Security feature Constant
= Severity x 10
__________________________________________________________________________________________
78
eISSN: 2319-1163 | pISSN: 2321-7308
Table 4.1 Risk Analysis of Security Feature

S.No
.
SC=
Attribute
Values
OSR
PSR=
RFS=
MaxRF=
APRf=RF
severity
(OSR/M
SC*PSR/
SC*MaxPSR
*100/Max
*10
axOSR)
100
/100
RF
* 100
Security
Max
MaxOSR
Max
Max
Max
value=
=No.
value=10
value
=100
100
Desired
=100
Features
of
value
Max value
=100
Requirem
-ents
Authentication
70
Authorization
85
Audit
&
40
Secure Storage
60
Secured
50
logging
Session
Management
Secured
65
Information
Flow
The final value obtained is APRF(Actual Percent of Risk

Factor for each Security Feature).Using this value the risl
mitigation level can be selected from Table 6.3 with the help
of Risk mitigation scale, as shown in Fig. 4.1.
33.3
Level 1
66.6
Level2
100
Level3
Fig.4.1: Risk Mitigation Scale
5. RISK MITIGATION MECHANISM IN FORM

OF SECURITY DESIGN PATTERNS
Security patterns document good practices to solve security
problems arising frequently in software development
[Schumacher et al., 2006], [Steel et al., 2005]. A security
pattern is a design pattern that generally describes a group of
participants and their relationships and collaborations, which
achieve some security goals [Steel et al., 2005]. Gamma et al.
(Gamma et al.,1995), first proposed a the basic template of the

design pattern, Buschmann et al. (Buschmann et al., 2007)
then further enhanced that template. The attributes that are
covered in Buschmanns templates are listed as follows:
Name: a name and a short summary of the pattern

Also Known As: other names of the pattern
Example: a real world example that demonstrates the
purpose and the benefit of the pattern
Context: situations in which the pattern may apply
Problem: a description of the problem the pattern
addresses including its associated forces
Solution: a description of how the problem can be
solved
Variants: a reference to other patterns that are
variants or specialization of this pattern
Consequences: an outline of the benefits and
potential tradeoffs of the pattern
__________________________________________________________________________________________
79
A good amount of research work in the area of security design

patterns is reported in the literature. Yoder et al., in [Yoder,
1997] introduced a 7-pattern catalogue which was not
complete set of list but it can be considered as starting point
towards a collection of patterns. Security pattern repository
was developed by [Kienzle, 2010] that contains 29-pattern, it
categorized security patterns as either structural or procedural
patterns. The other significant contributions in the field of
security pattern are [Steel et al., 2005], [Schumacher et al.,
2006], [Brown et al., 1999], [Romanosky, 2001],
eISSN: 2319-1163 | pISSN: 2321-7308
[Wassermann and Betty, 2003], [OpenGroup,2002].Even

though a good amount of research work is available still there
is a need of evaluation and usability measurement of these
available design pattern. According to Wiesauer et al.
[Wiesauer and Sametinger, 2009] there is need of security
design pattern selection criteria that are based on certain well
known attributes. On the basis of existing literature, a list of
most common and reliable security pattern is developed as
shown in Table 5.1
Table 5.1: List of Security Design Patterns

S.No.
UML
Security
Pattern Name
Brief description
Reference
1.
UML
Security
Pattern
ID
PAu1
Password
Design and
Use
This pattern describes security best practice

for designing, creating, managing, and
[Schumacher et al., 2006] p.217
2.
PAu2
Authenticator
pattern
describes a general mechanism for

providing identification and
authentication to a server from a client.
[Brown et al., 1999] p.1
3.
PAu3
Single Access
Point (SAP)
proposes single interface to the system to

improve control
4.
PAu4
Security
Provider
5.
PAu5
Biometrics
Design
Alternatives
This pattern describes what a client should

operate to perform authentication against
the identity service provider for
authentication or authorization assertion. It
is part of the single sign-on process for
enterprise identity management.
This pattern aids the selection of
appropriate biometric mechanisms to satisfy
I&A requirements
[Berry,2002], pp. 203; [Yoder and

Barcalow, 1997], p. 4; [Wassermann
and Betty, 2003], p. 18
[Romanosky, 2002], p. 11
6.
PAo1
Check point
A structure for checking incoming requests

and handling violations
7.
PAo2
Role-Based
Access
Control
This pattern describes how to assign rights

based on the functions or tasks of people
using password components
8.
PAo3
Roles
9.
PAo4
Limited View
10.
PAo5
Security
Context
in an environment in which control of

access to computing resources is required
Organizing users with similar security
privileges.
Allowing users to only see what they have
access to
This pattern provides a container for access
to security attributes, such as effective user
ID and group ID.
[Berry], p. 204; [Yoder and

Barcalow1997], p.7;[OpenGroup,
2002], p. 47; [Wassermann and
Betty, 2003], p. 27
[Berry, 2002], p. 205; [Yoder and

Barcalow, 1997] p.11
[Yoder and Barcalow, 1997] p.19
[OpenGroup,2002], p. 40
__________________________________________________________________________________________
80
11.
PAo6
Secure Chain
of
Responsibility
The intent of the Secure Chain of

Responsibility pattern is to decouple the
logic that determines
eISSN: 2319-1163 | pISSN: 2321-7308
[Dougherty, 2009] p.48
user/environment-trust dependent
functionality from the portion of the
application requesting the functionality
12.
PAo7
Reference
Monitor
this pattern enforces declared access

restrictions when an active entity requests
resources.
13.
PAo8
Multilevel
Security
This pattern describes how to categorize

sensitive
14.
PAt1
Audit
Interceptor
information and prevent its disclosure.

the Audit Interceptor pattern enables the
administration and manages the logging and
audit in the back-end.
15.
PAt2
Security Event
Logging
16.
PAt3
Log for Audit
This pattern is related to the capture and

tracking of security-related events for
logging and audit trail. Logged information
can be used for risk assessment or analysis.
The Log for Audit pattern ties logging to
auditing, to ensure that logging is
[Steel et al., 2005] C.8
[Romanosky, 2001], p. 8;
[Romanosky, 2002], p. 4; [Amos,
2003], p. 4; [Berry,2002], p. 205
[Kienzle et al., 2006] p.141
configured with audit in mind and that

auditing is understood to
17.
PSs1
Client Data
Storage
18.
PSs2
Information
Obscurity
be integral to effective logging.

The Client Data Storage pattern uses
encryption techniques to protect data that
this stored on the client.
Obscure the more sensitive
items of data using an encryption

mechanism in situations in which it might
be exposed
19.
PSm1
Session
20.
PSm2
21.
PSm3
Secure Session
Manager
Directed
Session
to attack, while leaving the bulk of the

application data unencrypted
Localizing global information in a multiuser environment.
This pattern defines how to create a secure
session by capturing session information.
The Directed Session pattern ensures that
users will not be able to
[Yoder and Barcalow, 1997] p. 14

and [Amos, 2003] p.3
skip around within a series of Web pages.
__________________________________________________________________________________________
81
22.
PSm4
Secure Session
Object
23.
PSm5
Secure
Association
24.
PSm6
Front Door
25.
PSi1
Authoritative
Source of Data
26.
PSi2
27.
PSi3
28.
PSi4
29.
30.
eISSN: 2319-1163 | pISSN: 2321-7308
This pattern defines ways to secure session

information in EJBs facilitating distributed
access and seamless propagation of security
context.
This pattern shows how to make secure
interactions between two entities; for
example, protecting the session between the
browser and Web server using SSL
It identifies users and keeps track of user
sessions.
This pattern verifies the data source for
authenticity and data integrity.
Secure
Message
Router
This pattern facilitates secure XML

communication with multiple partner
endpoints that adopt message-level security
and identity-federation mechanisms.
Secure
Channels
Third-Party
Communicatio
n
Create secure channels for sensitive data

that obscure the data in transit.
This pattern helps identify the risks of the
third-party relationship and applies relevant
security protection measures for the thirdparty communication.
PSi5
Known
Partners
Ensure that access to system functionality

and data is restricted to known partners who
must authenticate themselves in a secure
manner.
PSi6
Network
Address
Blacklist
A network address blacklist is used to keep

track of network
[Open Group], p. 32.

[Romanosky, 2002], p. 2; [Berry,
2002], p.206

[Romanosky, 2002], p. 6
addresses (IP addresses) that are the sources

of hacking attempts and other mischief.
31.
PSi7
Validated
Transaction
The Validated Transaction pattern puts all

of the security-relevant validation for a
specific transaction into one page request.
32.
PSi8
Network
Encryption
Protocol
A cryptographic protocol is an orderly

sequence of steps of one ore more parties to
accomplish the protection against threats.
[Schumacher and Roedig, 2001]

p.15
33.
PSi9
Protection
Reverse Proxy
It is used to shields the real Web server.
34.
PSi10
Integration
Reverse Proxy
Use a reverse proxy to integrate all your

Web servers as back-end servers with a
common host address (that of the reverse
proxy).
__________________________________________________________________________________________
82
eISSN: 2319-1163 | pISSN: 2321-7308
specific factor. E.g., Password Design and Use pattern is

applicable to almost all kind of data irrespective to their
sensitivity; therefore data sensitivity factor of password
pattern will be assigned value as 1. There are certain security
patterns, in which the value of context factor does not applied,
e.g. in Password Design and Use pattern, the context factor
Potential Location of Transferred Data will not be applied
therefore we assign N/A to it. The list of values that are
assigned to each context factor is as follows:
Pearson and Shen in their framework [Paerson and Shen,

2010] proposed user-related contextual factors that affect the
degree of privacy protection. They include factors like
sensitivity of data, location of data, sector, contractual
restrictions, cultural expectations, user trust (in organisations,
etc.), trustworthiness of partners, security deployed in the
infrastructure, etc. They proposed the decision based support
system that assesses context and deduces a list of
recommendations and controls. They further declare their
framework as a broad solution that can be used for privacy,
security and other types of requirement. In order to categorize
our security design patterns we have selected six most relevant
context factors from the list proposed by [Paerson and Shen,
2010]. The selected patterns are listed as follows:
1. Data sensitivity
2. Location of Data
3. Potential Location of transferred data
4. Sector
5. Number of Users
6. user role in the organization
Data sensitivity: General=1, High=2, Very High=3

Location of data: General=1, Multiple=2, Multiple
and Variable=3
Potential Location of Transferred Data: General =1,
Multiple=2, Multiple and Variable=3
Sector: General=1, Private or Small Business =2,
Large Business =3
Number of User: General=1, About 50 % users=2,
About 100%=3
User role in organization: General=1, Administrator
only =2, Administrator and End user both=3
On the basis of above mentioned factors, each design pattern

is categorized in three levels level1, level2 and level3. The
values that are assigned to each context factor are also in a
range of 1-3.The values 2 and 3 are in ascending order of the
factors significance but value1=general is used when the
design pattern is applicable to all kind of conditions under
The rating of each security pattern is done on the basis of

weightge of context factors specified in the definition of each
security pattern as shown in Table 5.2.
Table5.2. Ratings of Security Design pattern on the Basis of Context Factor

S.No
S.N
A
Data
Location of
Potential
Sensitivity
data
Location
Sector
No. of
User role in
users
organization
Level
of
transferred
data
1.
PAu1
N/A
2.
PAu2
3.
PAu3
N/A
N/A
4.
PAu4
N/A
N/A
5.
PAu5
6.
PAo1
N/A
7.
PAo2
8.
PAo3
N/A
9.
PAo4
10.
PAo5
N/A
11.
PAo6
12.
PAo7
N/A
N/A
__________________________________________________________________________________________
83
eISSN: 2319-1163 | pISSN: 2321-7308
13.
PAo8
14.
PAt1
15.
PAt2
16.
PAt3
17.
PSs1
18.
PSs2
19.
PSm1
20.
PSm2
21.
PSm3
22.
PSm4
23.
PSm5
24.
PSm6
25.
PSi1
N/A
26.
PSi2
N/A
N/A
27.
PSi3
N/A
28.
PSi4
29.
PSi5
30.
PSi6
31.
PSi7
32.
PSi8
33.
PSi9
34.
PSi10
The average of all the values of context factor is taken as a

final value of the level. For the sake of simplicity the values
after decimal are omitted. After the analysis of security design
patterns, the Table 5.3 is created that classifies all the

identified design pattens in three different levels.
Table 5.3 Risk Mitigation Levels in the form of Security Design Patterns
S. No.
Security Features
Level1
Level2
Level3
Level to
be used
Authentication
PAu1; PAu2
PAu1; PAu2;
PAu3
2nd
Authorization
PAo1; PAo2;
PAo3; PAo4
PAo1;PAo2;
PAo3; PAo4;
PAo5
PAu1; PAu2;
PAu3; PAu4;
PAu5
PAo1; PAo2;
PAo3; PAo4;
PAo5; PAo6;
PAo7; PAo8
Audit & logging
PAt1
PAt1; PAt2
PAt1; PAt2;
PAt3
1st
2nd
__________________________________________________________________________________________
84
eISSN: 2319-1163 | pISSN: 2321-7308
Secure Storage
PSs1
PSs1; PSs2
PSs1; PSs2
1st
Secured Session
Management
PSm1
PSm1;PSm2
PSm1; PSm2;
PSm3; PSm4;
PSm5; PSm6
1st
Secured Information
Flow
PSi1; PSi2
PSi1;PSi2
PSi3; PSi4
PSi1; PSi2;
PSi3; PSi4;
PSi5; PSi6;
PSi7; PSi8;
PSi9; PSi10
2nd
33.3
Level 1
66.6
Level2
100
Level3
Fig. 5.1 Risk Mitigation Scale
6. CASE STUDY
In this section the use of the proposed process is explained.
The whole process of security requirement risk assessment is
shown in Fig 6.1. The steps wise process of security
requirement risk assessment is explained as follows:
S.No.
Choose security requirement standard (here Common

Criteria Standard for security requirement is taken)
a). Requirement Assessment:Select Desired Security

Requirement Classes from the list of all security requirements
and calculate the sum of all the values of selected
requirements, (Use Table 3.4). For example total 42
requirements are selected, in which the occurrence of security
features are as follows:
Security Feature
No.
Occurrences
Authentication
16
Authorization
17
Audit & logging
11
Secure Storage
10
Secured Session Management
Secured Information Flow
13
of
Table 6.1 Security feature and their occurrences in example
__________________________________________________________________________________________
85
eISSN: 2319-1163 | pISSN: 2321-7308
Figure 6.1 Risk Mitigation using security Design patterns
b. Software Security Estimation:Match the obtained

value to the security requirement scale and designer can find
out security category of the software and Mitigation level from
Table 4.3.
The sum of values of all the 42 classes is as follows:
n
MVSFC = TSFC = 1591
i=1
Therefore, the value of security class will be Secured and
Level 2 of risk mitigation will be applicable to this software
design, as shown in Table 6.2
Table 6.2 MVSFC Values and their Risk Mitigation Sloth
S.no.
Security
Features
Authentication
Authorization
Audit
&
logging
Secure
Storage
Secured
Session
Management
Secured
Information
Flow
SC=
severity
*10
OSR
PSR=
(OSR/MaxOSR)
* 100
RFS=
SC*PSR/100
MaxRF=
SC*MaxPSR
/100
APRf=RF*100/MaxRF
Max
value=
100
MaxOSR
(e.g. 42)
Max value=100
Max
=100
Max
=100
Max value =100
70
85
40
16
17
11
38.09524
40.47619
26.66667
34.40476
44.8
54.4
59.52382
63.24404
26.19048
10.47619
25.6
40.92262
60
10
23.80952
14.28571
38.4
37.20237
50
4
9.52381
4.761905
32
14.88095
65
13
30.95238
20.11905
41.6
48.3631
value
value
__________________________________________________________________________________________
86
eISSN: 2319-1163 | pISSN: 2321-7308
c. Security Feature Percentage Calculation:Use
d. Mitigation Level Selection: Select the mitigation
Table 4.1 and identify a mitigation level using scale as shown

in Fig. 3.1.The Risk factor calculations table on the basis of
values that are specified in step 1, are as follows:
level required under each class of security attribute as shown
Table 6.3 Risk Mitigation of Security Feature

S.NO. MVSFC
Security
Risk
Sloth
Class
Mitigation
Level
- 714.361
Undefined
N/A
714.36
General
L1
- 1428.724
1428.724
- Secured
L2
2143.085
2143.085
- Very
L3
2857.447
Secured
in Table 6.3. On the basis of values calculated in Table 6.3,

the risk mitigation levels applicable are shown in Table 6.4
Check
point
Table 6.4 Risk Mitigation using Security Pattern Levels
S.
No.
Security
Features
Level1
Level2
Authentication
PAu1;
PAu2
PAu1;
PAu2;
PAu3
Authorization
PAo1;
PAo2;
PAo3;
PAo4
Audit & logging
PAt1
Secure Storage
Secured Session
Management
Level3
Level to be used
2nd
PSs1
PAu1;
PAu2;
PAu3;
PAu4;
PAu5
PAo1;PAo2; PAo1;
PAo3;
PAo2;
PAo4;
PAo3;
PAo5
PAo4;
PAo5;
PAo6;
PAo7; PAo8
PAt1; PAt2 PAt1; PAt2;
PAt3
PSs1; PSs2 PSs1; PSs2
PSm1
PSm1;PSm2
1st
PSm1; PSm2;
2nd
1st
1st
PSm3; PSm4;
PSm5; PSm6
6
Secured
Information Flow
PSi1; PSi2
PSi1;PSi2
PSi3; PSi4
PSi1; PSi2;
PSi3; PSi4;
PSi5; PSi6;
2nd
PSi7; PSi8;
PSi9; PSi10
__________________________________________________________________________________________
87
I n Table 6.4, only Identification number of security design

patterns are mentioned. The full detail of the pattern is given
in Table 5.1.After selecting the Risk Mitigation Level, the
details of the pattern can be found in Table 5.1 and further full
details of the pattern can be found from the reference provided
in the last column of Table 5.1.
[7]
[8]
7. CONCLUSION AND FUTURE WORK

A proactive approach of paying close attention to security
during the design phase prevents expensive redesign and
yields substantial benefits during all later phases of the SDLC.
Security requirements and security features plays a very
important role in the security integration at design phase of the
SDLC. Prevention of security issues is the best way to deals
with security. In the proposed process of Risk Mitigation
through Security Design Patterns a preventive approach is
taken, in which risk assessment is performed on the security
requirements on the basis of security feature. All the software
specific security requirement of Common Criteria standard is
considered and they measured in terms of security feature. A
measurement scale is created, that can be used to measure the
need of effort required at the design level to integrate security.
The proposed process of risk mitigation through design pattern
is a simplistic and can be adapted by the designer without the
prior knowledge of security. The comprehensive list of
reliable and authentic design patterns is provided that can be
used as simple and easily manageable tool. In future we will
try to automate the process by creating the tool so that process
can be adapted easily by the software designer.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
Brown, F.L., Vietri, J.D., Villegas, G.D. and

Fernandez, E. (1999).The Authenticator Pattern. In
proceedings: Sixth Conference on Pattern Languages of
Programming (PLoP), 1999.
Yoder, J. and Barcalow, J. (1997). Architectural
patterns for enabling application security. In
Proceedings: Conference on Pattern Languages of
Programming (PLoP), 1997.
Fernandez, E.B. and Pan, R.(2001). A pattern language
for security models. In Proceedings: 8th Conference on
Pattern Languages of Programs.
Schumacher, M., Buglioni, E.F., Hybertson, D.,
Buschmann, F., and Peter, S. (2006). Security Patterns:
Integrating Security and Systems Engineering. West
Sussex,UK: John Wiley and Sons. (ISBN-10 0-47085884-2).
Robert, S. (2008). The CERT C Secure Coding
Standard. Addison-Wesley. The CERT C Secure
Coding Standard.
Steel, C., Nagappan, R., and Lai, R.(2005). Core
Security Patterns: Best Practices and Strategies for
J2EE, Web Services, and Identity Management.
Prentice-Hall, 2005 (ISBN-100131463071).
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
eISSN: 2319-1163 | pISSN: 2321-7308
Berry, C.A, Carnell,J., Juric, M.B., Kunnumpurath,

M.M., Nadia Nashi, N. and Romanosky, S.(2002).
J2EE Design Patterns Applied. Wrox Press, 2002.
Wassermann, R. and Betty H. C.(2003). Security
Patterns.MichiganStateUniversity (MSU-CSE-03-23).
Retrieved
April,
2009
from
http://www.cse.msu.edu/cgiuser/Web/tech/document?ID=547
Monzillo, R and Roth, M. (2001). Securing
Applications for the Java 2 Platform, Enterprise Edition
(J2EE). In proceedings: Java One 2001 Conference.
The Open Group (2002). Guide to Security Patterns.
The Open Group, Retrieved Feb, 2008 from
http://www.opengroup.org/security/gsp.htm
Amos, A. (2003). Designing Security into Software
with Patterns. Retrieved : 2, Aug, 2009, from
"http://www.giac.org/practical/GSEC/Alfred_Amos_G
SEC.pdf
Romanosky, S. (2001). Security Design Patterns, Part
1" Version 1.4. Retrieved 2 Feb, 2009, from
http://www.romanosky.net/papers/securityDesignPatt
Romanosky,
S.(2002)
"Enterprise
Security
Patterns."Retrived
April
19,
2004,
from
http://www.romanosky.net/papers/securitypatterns/Ente
rpriseSecurityPatterns.pdf
Dougherty, C., Sayre, K., Robert C.S., Svoboda,D. and
Togashi, K. (2009). Secure Design Patterns.
TECHNICAL
REPORT.
CMU/SEI-2009-TR010.Retrived
15,
Jan
2010
from
www.cert.org/archive/pdf/09tr010.pdf.
M. Stuart Perkins .(2004).Design From a Distance:.
February 01, 2004GSEC Practical Assignment, v. 1.0
(Initial Release). An Introduction to Security Design
Patterns.
The
Open
Group.
Guide
to
Security
Patterns.http://www.opengroup.org/security/gsp.htm,
2002.
Kienzle,
D.M.,
Elder,
M.C.,
Tyree,D.,
Hewitt,J.E.(2006). Security Patterns RepositoryVersion
1.0.
Retrived:
12
April,
2010
from
http://www.modsecurity.org/archive/securitypattern
Schumacher, M. and Roedig, U. (2001).Security
Engineering with Patterns. In Proceedings: PLoP 2001
conference.
Retrieved
16
May,
2010
fromhttp://www.uml.org.cn/sjms/pdf/PLoP2001_mschu
macher0_1.pdf
Ferraz, F.S, Assad, R.E. and Meira, S.R.L. (2009).
Relating Security Requirements and Design Patterns:
Reducing Security Requirements Implementation
Impacts with Design Patterns. In Proceedings:
International Conference on Software Engineering
Advances. DC, USA.
Ruffin, I., Umphress, D., Hamilton, J. and Gilbert,
J.(2007).Qualitative Software Security Risk Assessment
Model. In Proceedings: 3rd ACM Workshop on Quality
of Protection, Alexandria, VA, USA.
__________________________________________________________________________________________
88
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
Davis, Noopur.,Redwine S.T., Zibulski, G., McGraw,

G. and Humphrey, W. (2004). Processes for Producing
Secure Software Summary of US National Cyber
security Summit subgroup Report. IEEE Security &
Privacy May/June 2004
Jurjens, J. (2004). Secure Systems Development with
UML Springer Academic Publishers, Germany 2004.
Braber, F., Dimitrakos, T., Gran, B.A., Lund, M.S.,
Stlen, K. and Aagedal, J.O.(2003). The CORAS
methodology: model-based risk assessment using UML
and UP. In: UML and the unified process. Idea Group
Publishing, pp. 332357.
Chandra, P. (Project Lead) (2006). CLASP Comprehensive, Lightweight Application Security
Process. Version 1.2, Version Date: 31 march 2006.
Retrieved
13
March
from
http://www.owasp.org/index.php/Category:
OWASP_CLASP_Project
Mouratidis, H. and Giorgini, P. (2007): Secure Tropos:
a Security-Oriented Extension of the Tropos
Methodology. International Journal of Software
Engineering and Knowledge Engineering , Volume 17,
2007, pp.285-309.
Ansar, Y., Giorgini, P., Massacci, F. and Zannone, N.
(2007).Trust to Dependability through Risk Analysis. In
Proceedings: The International Conference on
Availability, Reliability and Security.2007, pp.1926.IEEE Press.
Wiesauer, A and Sametinger, J. (2009). A Security
Design Pattern Taxonomy based on Attack Patterns.In
proceedings: International Joint Conference on eBusiness and Telecommunications, 7-10 July 2009,
Milan, Italy.
Pearson, S. and Shen, Y. (2010). Context-Aware
Privacy Design Pattern Selection. Published and
presented at TrustBus 2010, Spain, May 16, 2010. The
original
publication
is
available
at
www.springerlink.com
NATO Research and Technology Organisation. (2008).
Final Report of Task Group IST-049. Common Criteria
and Risk Analysi. Chapter 4. ISBN 978-92-837-00456.Retrived
4
july,
2010,
from
http://www.rta.nato.int/pubs/rdp.asp?RDP=RTO-TRIST-049
Common Criteria Security Standard. (2009). Retrived
30
May
2010,
from
http://www.commoncriteriaportal.org/.
Malboeuf, S., Sandberg-Maitland, W., Dziadyk, W.,
Bacic, E.(2004). Common Methods For Security Risk
Analysis.Prepared for DRDC by Cinnabar Networks
Inc., 22 December 2004.retrived 5 july, 2009 from
http://pubs.drdc.gc.ca/PDFS/unc33/p523100.pdf
Berghe, V.C., Riordan, J.; Piessens, F. (2005).A
Vulnerability TaxonomyMethodology applied to Web
Services. In: Proceedings of the 10th NordicWorkshop
on Secure IT Systems.
[33]
eISSN: 2319-1163 | pISSN: 2321-7308
Rehman, S and Mustafa, K. (2011).Software Design

Level secuirtyVulnerabilities.International Journal of
Software Engineering. Vol.4 No.2, July 2011.
__________________________________________________________________________________________
89

Software Security Risk Mitigation Using Object Oriented Design Patterns

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Security Risk Mitigation Using Object Oriented Design Patterns

Transféré par

Droits d'auteur :

Formats disponibles

IJRET: International Journal of Research in Engineering and Technology

eISSN: 2319-1163 | pISSN: 2321-7308