Software security risk mitigation using object oriented design patterns

IJRET: International Journal of Research in Engineering and Technology eISSN: 2319-1163 | pISSN: 2321-7308

__________________________________________________________________________________________

Volume: 02 Issue: 07 | Jul-2013, Available @ http://www.ijret.org 71

SOFTWARE SECURITY RISK MITIGATION USING OBJECT

ORIENTED DESIGN PATTERNS

Rehman S1, Mustafa. K

2

Department of Information Technology, Salman bin Abdul Aziz University, KSA, [email protected]

Department of Computer Science,Jamia Millia Islamia, India, [email protected]

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


__________________________________________________________________________________________


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

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].

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. Vulnerability Classes Common Keywords

1. Authentication Authentication; Non Repudiation; User Attribute; Specification of

Secrets; Data Identification; User-Subject Binding; Event

Selection

Secured

Storage

Access Control at

Storage Level


__________________________________________________________________________________________


2. Authorization 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. Secure Information

Flow

Information Flow; Data Export; Data Import; Data Transfer;

Data Consistency; Confidentiality and integrity of Data

6. Secure Session

Management

Session Management; Replay Detection; State Synchronization;

Data Consistency; Availability of Data

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

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’.

Table 3.2 Availability matrix of vulnerability class and the CC security requirement class

S.No. Requirement Classes

Authen

-

ticatio

n

(Au)

Autho

ri-

zation

(Ao)

Audit

and

Loggi

ng

(At)

Secured

Storage

(S)

Secur

e

Infor

m-

ation

Flow

(If)

Secure

Session

manage

ment

(Ss)

Tota

l

Max

=6

1. 8.1 Security audit automatic

response (FAU_ARP)

0 0 1 0 0 0 1

2. 8.2 Security audit data generation

(FAU_GEN)

0 1 1 0 0 0 2

3. 8.3 Security audit analysis

(FAU_SAA)

0 1 1 0 0 0 2

4. 8.4 Security audit review

(FAU_SAR)

0 1 1 0 0 0 2

5. 8.5 Security audit event selection (FAU_SEL)

0 1 1 0 0 0 2

6. 8.6 Security audit event storage

(FAU_STG)

0 1 1 1 0 0 3

7. 9.1 Non-repudiation of origin (FCO_NRO)

1 1 1 0 0 0 3

8. 9.2 Non-repudiation of receipt

(FCO_NRR)

1 1 1 0 0 0 3

9. 10.1 Cryptographic key management (FCS_CKM)

0 1 0 1 1 0 3

10. 10.2 Cryptographic operation

(FCS_COP)

0 0 0 0 1 0 2

11. 11.1 Access control policy (FDP_ACC)

1 1 0 0 0 0 2


__________________________________________________________________________________________


12. 11.2 Access control functions

(FDP_ACF)

1 1 0 0 0 0 2

13. 11.3 Data authentication (FDP_DAU)

1 0 0 1 0 0 2

14. 11.4 Export from the TOE

(FDP_ETC)

1 0 0 0 1 0 2

15. 11.5 Information flow control policy (FDP_IFC)

1 0 0 0 1 1 3

16. 11.6 Information flow control

functions (FDP_IFF)

1 0 0 0 1 1 3

17. 11.7 Import from outside of the TOE (FDP_ITC)

1 1 0 0 1 0 3

18. 11.8 Internal TOE transfer

(FDP_ITT)

1 1 0 0 1 0 3

19. 11.9 Residual information protection (FDP_RIP)

1 1 0 1 0 0 3

20. 11.10 Rollback (FDP_ROL) 0 0 1 1 0 0 2

21. 11.11 Stored data integrity

(FDP_SDI)

0 1 1 1 0 0 3

22. 11.12 Inter-TSF user data

confidentiality transfer protection

(FDP_UCT)

0 1 0 0 1 0 2

23. 11.13 Inter-TSF user data integrity transfer protection (FDP_UIT)

0 1 0 0 1 0 2

24. 12.1 Authentication failures

(FIA_AFL)

1 0 1 1 0 0 3

25. 12.2 User attribute definition (FIA_ATD)

1 1 0 0 0 0 2

26. 12.3 Specification of secrets

(FIA_SOS)

1 1 0 1 0 0 3

27. 12.4 User authentication (FIA_UAU)

1 0 0 1 0 0 2

28. 12.5 User identification (FIA_UID) 1 1 0 1 0 0 3

29. 12.6 User-subject binding

(FIA_USB)

1 1 0 0 0 0 2

30. 13.1 Management of functions in

TSF (FMT_MOF)

1 1 0 1 0 0 3

31. 13.2 Management of security

attributes (FMT_MSA)

1 1 0 1 0 0 3

32. 13.3 Management of TSF data

(FMT_MTD)

1 1 0 0 0 0 2

33. 13.4 Revocation (FMT_REV) 1 1 0 0 0 0 2

34. 13.5 Security attribute expiration (FMT_SAE)

1 1 0 0 0 0 2

35. 13.6 Specification of Management

Functions (FMT_SMF)

1 1 0 0 0 0 2

36. 13.7 Security management roles (FMT_SMR)

1 1 0 0 0 0 2

37. 14.1 Anonymity (FPR_ANO) 1 1 0 0 0 0 2

38. 14.2 Pseudonymity (FPR_PSE) 0 1 1 0 0 0 2

39. 14.3 Unlinkability (FPR_UNL) 0 1 1 0 0 0 2

40. 14.4 Unobservability (FPR_UNO) 0 1 0 0 0 0 1

41. 15.1 Fail secure (FPT_FLS) 0 0 1 0 0 0 1

42. 15.2 Availability of exported TSF

data (FPT_ITA)

0 1 0 1 1 0 3

43. 15.3 Confidentiality of exported TSF data (FPT_ITC)

0 1 1 0 1 0 3

44. 15.4 Integrity of exported TSF data

(FPT_ITI)

0 1 1 0 1 0 3

45. 15.5 Internal TOE TSF data transfer (FPT_ITT)

0 1 1 0 1 0 3

46. 15.6 TSF physical protection

(FPT_PHP)

N/A N/A N/A N/A N/A N/A N/A

47. 15.7 Trusted recovery (FPT_RCV) 0 0 1 1 0 0 2

48. 15.8 Replay Detection (FPT_RPL) 0 0 0 0 1 1 2

49. 15.9 State Synchrony Protocol

(FPT_SSP)

0 0 0 0 1 1 2


__________________________________________________________________________________________


50. 15.10 Time stamps (FPT_STM) 0 0 0 0 1 1 2

51. 15.11 Inter-TSF TSF data

consistency (FPT_TDC)

0 0 0 1 1 1 3

52. 15.12 Testing of external entities (FPT_TEE)

1 1 1 0 0 0 3

53. 15.13 Internal TOE TSF data

replication consistency (FPT_TRC)

0 0 1 1 0 0 2

54. 15.14 TSF self test (FPT_TST) 1 1 0 1 0 0 3

55. 16.1 Fault tolerance (FRU_FLT) 0 1 0 0 0 0 1

56. 16.2 Priority of service (FRU_PRS) 0 1 0 0 0 0 1

57. 16.3 Resource allocation

(FRU_RSA)

0 1 0 0 0 0 1

58. 17.1 Limitation on scope of selectable attributes (FTA_LSA)

0 1 0 0 0 0 1

59. 17.2 Limitation on multiple

concurrent sessions (FTA_MCS)

0 1 0 0 1 1 3

60. 17.3 Session locking and

termination (FTA_SSL)

0 1 0 0 0 1 2

61. 17.4 TOE access banners (FTA_TAB)

0 1 0 0 0 0 1

62. 17.5 TOE access history

(FTA_TAH)

0 1 1 1 0 0 3

63. 17.6 TOE session establishment

(FTA_TSE)

0 1 0 0 0 1 2

64. 18.1 Inter-TSF trusted channel (FTP_ITC)

0 0 0 0 1 0 1

65. 18.2 Trusted path (FTP_TRP) 0 0 0 0 1 0 1

Total 27 46 21 18 20 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:

Total number of cells= 64 x 6 = 384

Total Occurrence of Ones =141

SFC = (OSR /Total Number of Occurrences) x 100

= (OSR/141) x 100

Where,

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

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

4. Secure Storage 18 12.76596

5. Secured Information

Flow

20

14.1844

6. Secured Session

Management

09

6.38297

Total 141 100


__________________________________________________________________________________________


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

Features

TSFC

1. 8.1 Security audit automatic response (FAU_ARP) (At) 14.89362

2. 8.2 Security audit data generation (FAU_GEN) ( Ao, At ) 47.51773 3. 8.3 Security audit analysis (FAU_SAA) (Ao, At ) 47.51773 4. 8.4 Security audit review (FAU_SAR) (Ao, At) 47.51773 5. 8.5 Security audit event selection (FAU_SEL) (Ao, At ) 47.51773 6. 8.6 Security audit event storage (FAU_STG) (Ao, At ) 47.51773 7. 9.1 Non-repudiation of origin (FCO_NRO) (Ao, At) 47.51773 8. 9.2 Non-repudiation of receipt (FCO_NRR) (Au, Ao, At ) 66.66667 9. 10.1 Cryptographic key management (FCS_CKM) (Ao, S, If ) 59.57447 10. 10.2 Cryptographic operation (FCS_COP) ( If) 14.1844 11. 11.1 Access control policy (FDP_ACC) ( Au, Ao) 51.77305 12. 11.2 Access control functions (FDP_ACF) ( Au, Ao) 51.77305 13. 11.3 Data authentication (FDP_DAU) ( Au, S) 31.9149 14. 11.4 Export from the TOE (FDP_ETC) ( Au, If) 33.33334 15. 11.5 Information flow control policy (FDP_IFC) ( Au, If, Ss ) 39.71631 16. 11.6 Information flow control functions (FDP_IFF) ( Au, If, Ss ) 39.71631 17. 11.7 Import from outside of the TOE (FDP_ITC) ( Au, Ao,If,) 65.95745 18. 11.8 Internal TOE transfer (FDP_ITT) ( Au, Ao,If,) 65.95745 19. 11.9 Residual information protection (FDP_RIP) ( Au, Ao, If) 65.95745 20. 11.10 Rollback (FDP_ROL) ( At, S,) 27.65958 21. 11.11 Stored data integrity (FDP_SDI) ( Ao, At, S ) 60.28369 22. 11.12 Inter-TSF user data confidentiality transfer

protection (FDP_UCT)

(Ao, If) 46.80851 23. 11.13 Inter-TSF user data integrity transfer protection

(FDP_UIT)

(Ao, If ) 46.80851 24. 12.1 Authentication failures (FIA_AFL) ( Au, At, S) 46.80852 25. 12.2 User attribute definition (FIA_ATD) ( Au, Ao,) 51.77305 26. 12.3 Specification of secrets (FIA_SOS) ( Au, Ao, S ) 64.53901 27. 12.4 User authentication (FIA_UAU) ( Au,S ) 31.9149 28. 12.5 User identification (FIA_UID) ( Au, Ao, S ) 64.53901 29. 12.6 User-subject binding (FIA_USB) ( Au, Ao ) 51.77305

30. 13.1 Management of functions in TSF (FMT_MOF) ( Au, Ao, S ) 64.53901 31. 13.2 Management of security attributes

(FMT_MSA)

( Au, Ao, S) 64.53901 32. 13.3 Management of TSF data (FMT_MTD) ( Au, Ao ) 51.77305 33. 13.4 Revocation (FMT_REV) ( Au, Ao) 51.77305 34. 13.5 Security attribute expiration (FMT_SAE) ( Au, Ao) 51.77305 35. 13.6 Specification of Management Functions

(FMT_SMF)

( Au, Ao) 51.77305 36. 13.7 Security management roles (FMT_SMR) ( Au, Ao) 51.77305 37. 14.1 Anonymity (FPR_ANO) ( Au, Ao ) 51.77305 38. 14.2 Pseudonymity (FPR_PSE) ( Ao, At) 47.51773 39. 14.3 Unlinkability (FPR_UNL) ( Ao, At ) 47.51773 40. 14.4 Unobservability (FPR_UNO) ( Ao ) 32.62411 41. 15.1 Fail secure (FPT_FLS) ( At) 14.89362 42. 15.2 Availability of exported TSF data (FPT_ITA) (Ao, S, If) 59.57447 43. 15.3 Confidentiality of exported TSF data

(FPT_ITC)

( Ao, At, If ) 61.70213 44. 15.4 Integrity of exported TSF data (FPT_ITI) (Ao, At, If) 61.70213 45. 15.5 Internal TOE TSF data transfer (FPT_ITT) (Ao, At, If ) 61.70213


__________________________________________________________________________________________


46. 15.7 Trusted recovery (FPT_RCV) (At, S) 27.65958

47. 15.8 Replay Detection (FPT_RPL) ( If, Ss ) 20.56737 48. 15.9 State Synchrony Protocol (FPT_SSP) ( If, Ss ) 20.56737 49. 15.10 Time stamps (FPT_STM) (If, Ss ) 20.56737 50. 15.11 Inter-TSF TSF data consistency (FPT_TDC) ( S, If, Ss ) 33.33333 51. 15.12 Testing of external entities (FPT_TEE) ( Au, Ao, At ) 66.66667 52. 15.13 Internal TOE TSF data replication consistency

(FPT_TRC)

( At, S) 27.65958 53. 15.14 TSF self test (FPT_TST) ( Au, Ao, S) 64.53901 54. 16.1 Fault tolerance (FRU_FLT) (Ao ) 32.62411 55. 16.2 Priority of service (FRU_PRS) ( Ao ) 32.62411 56. 16.3 Resource allocation (FRU_RSA) (Ao ) 32.62411 57. 17.1 Limitation on scope of selectable attributes

(FTA_LSA)

(Ao ) 32.62411 58. 17.2 Limitation on multiple concurrent sessions

(FTA_MCS)

( Ao, If, Ss ) 53.19148 59. 17.3 Session locking and termination (FTA_SSL) (Ao, Ss ) 39.00708 60. 17.4 TOE access banners (FTA_TAB) ( Ao ) 32.62411 61. 17.5 TOE access history (FTA_TAH) ( Ao, At, S ) 60.28369 62. 17.6 TOE session establishment (FTA_TSE) ( Au,Ss ) 25.53191 63. 18.1 Inter-TSF trusted channel (FTP_ITC) ( If ) 14.1844 64. 18.2 Trusted path (FTP_TRP) ( If ) 14.1844

Total 2857.447

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.

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.

(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. MVSFC Sloth Class Risk

Mitigation

Level

- 714.361 Undefined N/A

714.36 -

1428.724

General L1

1428.724 -

2143.085

Secured L2

2143.085 -

2857.447

Very Secured L3


__________________________________________________________________________________________


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 (0-

100). 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:

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

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


__________________________________________________________________________________________


Table 4.1 Risk Analysis of Security Feature

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.

0 33.3 66.6 100

Level 1 Level2 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 Buschmann’s 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

S.No

.

Attribute

Values

Security

Features

SC=

severity

*10

OSR

PSR=

(OSR/M

axOSR)

* 100

RFS=

SC*PSR/

100

MaxRF=

SC*MaxPSR

/100

APRf=RF

*100/Max

RF

Max

value=

100

MaxOSR

=No. of

Desired

Requirem

-ents

Max

value=10

0

Max

value

=100

Max value

=100

Max value

=100

Authentication 70

Authorization 85

Audit &

logging

40

Secure Storage 60

Secured

Session

Management

50

Secured

Information

Flow

65


__________________________________________________________________________________________


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],

[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

ID

UML

Security

Pattern Name

Brief description Reference

1. PAu1

Password

Design and

Use

This pattern describes security best practice

for designing, creating, managing, and

using password components

[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

[Berry,2002], pp. 203; [Yoder and

Barcalow, 1997], p. 4; [Wassermann

and Betty, 2003], p. 18

4. PAu4 Security

Provider

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.

[Romanosky, 2002], p. 11

5. PAu5

Biometrics

Design

Alternatives

This pattern aids the selection of

appropriate biometric mechanisms to satisfy

I&A requirements


6. PAo1 Check point A structure for checking incoming requests

and handling violations

[Berry], p. 204; [Yoder and

Barcalow1997], p.7;[OpenGroup,

2002], p. 47; [Wassermann and

Betty, 2003], p. 27

7. PAo2 Role-Based

Access

Control

This pattern describes how to assign rights

based on the functions or tasks of people

in an environment in which control of

access to computing resources is required


8. PAo3 Roles Organizing users with similar security

privileges.

[Berry, 2002], p. 205; [Yoder and

Barcalow, 1997] p.11

9. PAo4 Limited View Allowing users to only see what they have

access to

[Yoder and Barcalow, 1997] p.19

10. PAo5 Security

Context

This pattern provides a container for access

to security attributes, such as effective user

ID and group ID.

[OpenGroup,2002], p. 40


__________________________________________________________________________________________


11. PAo6 Secure Chain

of

Responsibility

The intent of the Secure Chain of

Responsibility pattern is to decouple the

logic that determines

user/environment-trust dependent

functionality from the portion of the

application requesting the functionality

[Dougherty, 2009] p.48

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

information and prevent its disclosure.


14. PAt1 Audit

Interceptor

the Audit Interceptor pattern enables the

administration and manages the logging and

audit in the back-end.

[Steel et al., 2005] C.8

15. PAt2 Security Event

Logging

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.

[Romanosky, 2001], p. 8;

[Romanosky, 2002], p. 4; [Amos,

2003], p. 4; [Berry,2002], p. 205

16. PAt3 Log for Audit The Log for Audit pattern ties logging to

auditing, to ensure that logging is

configured with audit in mind and that

auditing is understood to

be integral to effective logging.

[Kienzle et al., 2006] p.141

17. PSs1 Client Data

Storage

The Client Data Storage pattern uses

encryption techniques to protect data that

this stored on the client.


18. PSs2 Information

Obscurity

Obscure the more sensitive

items of data using an encryption

mechanism in situations in which it might

be exposed

to attack, while leaving the bulk of the

application data unencrypted


19. PSm1 Session Localizing global information in a multi-

user environment.

[Yoder and Barcalow, 1997] p. 14

and [Amos, 2003] p.3

20. PSm2 Secure Session

Manager

This pattern defines how to create a secure

session by capturing session information.


21. PSm3 Directed

Session

The Directed Session pattern ensures that

users will not be able to

skip around within a series of Web pages.



__________________________________________________________________________________________


22. PSm4 Secure Session

Object

This pattern defines ways to secure session

information in EJBs facilitating distributed

access and seamless propagation of security

context.


23. PSm5 Secure

Association

This pattern shows how to make secure

interactions between two entities; for

example, protecting the session between the

browser and Web server using SSL

[Open Group], p. 32.

24. PSm6 Front Door It identifies users and keeps track of user

sessions.


25. PSi1 Authoritative

Source of Data

This pattern verifies the data source for

authenticity and data integrity.


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

2002], p.206

26. PSi2 Secure

Message

Router

This pattern facilitates secure XML

communication with multiple partner

endpoints that adopt message-level security

and identity-federation mechanisms.


27. PSi3 Secure

Channels

Create secure channels for sensitive data

that obscure the data in transit.


28. PSi4 Third-Party

Communicatio

n

This pattern helps identify the risks of the

third-party relationship and applies relevant

security protection measures for the third-

party communication.


[Romanosky, 2002], p. 6

29. PSi5 Known

Partners

Ensure that access to system functionality

and data is restricted to known partners who

must authenticate themselves in a secure

manner.


30. PSi6 Network

Address

Blacklist

A network address blacklist is used to keep

track of network

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. [Schumacher et al., 2006] p.457

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).



__________________________________________________________________________________________


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

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

factor’s significance but value‘1=general’ is used when the

design pattern is applicable to all kind of conditions under

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:

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

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

Sensitivity

Location of

data

Potential

Location

of

transferred

data

Sector No. of

users

User role in

organization

Level

1. PAu1 1 1 N/A 1 1 1 1

2. PAu2 2 2 1 2 3 3 2

3. PAu3 1 2 2 3 N/A N/A 2

4. PAu4 1 3 3 3 N/A N/A 3

5. PAu5 3 3 3 3 3 3 3

6. PAo1 1 2 N/A 1 1 1 1

7. PAo2 1 2 2 1 1 1 1

8. PAo3 1 1 N/A 1 2 1 1

9. PAo4 1 1 1 1 1 1 1

10. PAo5 2 2 N/A 2 2 2 2

11. PAo6 3 3 3 3 3 3 3

12. PAo7 3 3 3 3 N/A N/A 3


__________________________________________________________________________________________


13. PAo8 3 3 3 3 3 3 3

14. PAt1 1 1 1 1 1 1 1

15. PAt2 2 2 2 3 2 2 2

16. PAt3 3 3 3 3 3 3 3

17. PSs1 1 1 1 1 1 1 1

18. PSs2 2 2 3 3 3 3 3

19. PSm1 1 2 2 1 1 1 1

20. PSm2 2 2 2 3 3 2 2

21. PSm3 3 3 3 3 3 3 3

22. PSm4 3 3 3 3 3 3 3

23. PSm5 3 3 3 3 3 3 3

24. PSm6 3 3 3 3 3 3 3

25. PSi1 1 1 1 2 N/A 1 1

26. PSi2 1 1 1 1 N/A N/A 1

27. PSi3 2 2 3 2 2 N/A 2

28. PSi4 2 2 3 2 2 2 2

29. PSi5 3 3 3 3 3 3 3

30. PSi6 3 3 3 3 3 3 3

31. PSi7 3 3 3 3 3 3 3

32. PSi8 3 3 3 3 3 3 3

33. PSi9 3 3 3 3 3 3 3

34. PSi10 3 3 3 3 3 3 3

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

1 Authentication PAu1; PAu2

PAu1; PAu2;

PAu3

PAu1; PAu2;

PAu3; PAu4;

PAu5

2nd

2 Authorization PAo1; PAo2;

PAo3; PAo4

PAo1;PAo2;

PAo3; PAo4;

PAo5

PAo1; PAo2;

PAo3; PAo4;

PAo5; PAo6;

PAo7; PAo8

2nd

3 Audit & logging PAt1 PAt1; PAt2 PAt1; PAt2;

PAt3

1st


__________________________________________________________________________________________


0 33.3 66.6 100

Level 1 Level2 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:

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:

Table 6.1 Security feature and their occurrences in example

S.No. Security Feature No. of

Occurrences

Authentication 16

Authorization 17

Audit & logging 11

Secure Storage 10

Secured Session Management 4

Secured Information Flow 13

4 Secure Storage PSs1 PSs1; PSs2 PSs1; PSs2 1st

5 Secured Session

Management

PSm1 PSm1;PSm2 PSm1; PSm2;

PSm3; PSm4;

PSm5; PSm6

1st

6 Secured Information

Flow

PSi1; PSi2 PSi1;PSi2

PSi3; PSi4

PSi1; PSi2;

PSi3; PSi4;

PSi5; PSi6;

PSi7; PSi8;

PSi9; PSi10

2nd


__________________________________________________________________________________________


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

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 value

=100

Max value

=100

Max value =100

Authentication 70 16 38.09524 26.66667 44.8 59.52382

Authorization 85 17 40.47619 34.40476 54.4 63.24404

Audit &

logging

40 11

26.19048 10.47619 25.6 40.92262

Secure

Storage

60 10

23.80952 14.28571 38.4 37.20237

Secured

Session

Management

50 4

9.52381 4.761905 32 14.88095

Secured

Information

Flow

65 13

30.95238 20.11905 41.6 48.3631


__________________________________________________________________________________________


c. Security Feature Percentage Calculation:Use

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:

Table 6.3 Risk Mitigation of Security Feature

S.NO. MVSFC

Sloth

Security

Class

Risk

Mitigation

Level

Check

point

- 714.361 Undefined N/A

714.36

- 1428.724

General L1

1428.724 -

2143.085

Secured L2 √

2143.085 -

2857.447

Very

Secured

L3

d. Mitigation Level Selection: Select the mitigation

level required under each class of security attribute as shown

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

Table 6.4 Risk Mitigation using Security Pattern Levels

S.

No.

Security

Features

Level1 Level2 Level3 Level to be used

1 Authentication PAu1;

PAu2

PAu1;

PAu2;

PAu3

PAu1;

PAu2;

PAu3;

PAu4;

PAu5

2nd

2 Authorization PAo1;

PAo2;

PAo3;

PAo4

PAo1;PAo2;

PAo3;

PAo4;

PAo5

PAo1;

PAo2;

PAo3;

PAo4;

PAo5;

PAo6;

PAo7; PAo8

2nd

3 Audit & logging PAt1 PAt1; PAt2 PAt1; PAt2;

PAt3

1st

4 Secure Storage PSs1 PSs1; PSs2 PSs1; PSs2 1st

5 Secured Session

Management

PSm1 PSm1;PSm2 PSm1; PSm2;

PSm3; PSm4;

PSm5; PSm6

1st

6 Secured

Information Flow

PSi1; PSi2 PSi1;PSi2

PSi3; PSi4

PSi1; PSi2;

PSi3; PSi4;

PSi5; PSi6;

PSi7; PSi8;

PSi9; PSi10

2nd


__________________________________________________________________________________________


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. 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] 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.

[2] Yoder, J. and Barcalow, J. (1997). Architectural

patterns for enabling application security. In

Proceedings: Conference on Pattern Languages of

Programming (PLoP), 1997.

[3] Fernandez, E.B. and Pan, R.(2001). A pattern language

for security models. In Proceedings: 8th Conference on

Pattern Languages of Programs.

[4] 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-470-

85884-2).

[5] Robert, S. (2008). The CERT C Secure Coding

Standard. Addison-Wesley. The CERT C Secure

Coding Standard.

[6] 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).

[7] 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.

[8] Wassermann, R. and Betty H. C.(2003). Security

Patterns.MichiganStateUniversity (MSU-CSE-03-23).

Retrieved April, 2009 from

http://www.cse.msu.edu/cgi-

user/Web/tech/document?ID=547

[9] Monzillo, R and Roth, M. (2001). Securing

Applications for the Java 2 Platform, Enterprise Edition

(J2EE). In proceedings: Java One 2001 Conference.

[10] The Open Group (2002). Guide to Security Patterns.

The Open Group, Retrieved Feb, 2008 from

http://www.opengroup.org/security/gsp.htm

[11] 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

[12] Romanosky, S. (2001). Security Design Patterns, Part

1" Version 1.4. Retrieved 2 Feb, 2009, from

http://www.romanosky.net/papers/securityDesignPatt

[13] Romanosky, S.(2002) "Enterprise Security

Patterns."Retrived April 19, 2004, from

http://www.romanosky.net/papers/securitypatterns/Ente

rpriseSecurityPatterns.pdf

[14] Dougherty, C., Sayre, K., Robert C.S., Svoboda,D. and

Togashi, K. (2009). Secure Design Patterns.

TECHNICAL REPORT. CMU/SEI-2009-TR-

010.Retrived 15, Jan 2010 from

‘www.cert.org/archive/pdf/09tr010.pdf’.

[15] M. Stuart Perkins .(2004).Design From a Distance:.

February 01, 2004GSEC Practical Assignment, v. 1.0

(Initial Release). An Introduction to Security Design

Patterns.

[16] The Open Group. Guide to Security

Patterns.http://www.opengroup.org/security/gsp.htm,

2002.

[17] 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

[18] 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

[19] 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.

[20] 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.

http://www.romanosky.net/papers/securitypatterns/EnterpriseSecurityPatterns.pdf

http://www.romanosky.net/papers/securitypatterns/EnterpriseSecurityPatterns.pdf


__________________________________________________________________________________________


[21] 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

[22] Jurjens, J. (2004). Secure Systems Development with

UML Springer Academic Publishers, Germany 2004.

[23] Braber, F., Dimitrakos, T., Gran, B.A., Lund, M.S.,

Stølen, 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. 332–357.

[24] 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

[25] 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.

[26] 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.19-

26.IEEE Press.

[27] Wiesauer, A and Sametinger, J. (2009). A Security

Design Pattern Taxonomy based on Attack Patterns.In

proceedings: International Joint Conference on e-

Business and Telecommunications, 7-10 July 2009,

Milan, Italy.

[28] 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

[29] NATO Research and Technology Organisation. (2008).

Final Report of Task Group IST-049. Common Criteria

and Risk Analysi. Chapter 4. ISBN 978-92-837-0045-

6.Retrived 4 july, 2010, from

http://www.rta.nato.int/pubs/rdp.asp?RDP=RTO-TR-

IST-049

[30] Common Criteria Security Standard. (2009). Retrived

30 May 2010, from

http://www.commoncriteriaportal.org/.

[31] 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

[32] 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] Rehman, S and Mustafa, K. (2011).Software Design

Level secuirtyVulnerabilities.International Journal of

Software Engineering. Vol.4 No.2, July 2011.

Software security risk mitigation using object oriented design patterns

Engineering

Transcript of Software security risk mitigation using object oriented design patterns