a secure policy framework for the descartes specification

A Secure Policy Framework for the Descartes Specification Language

By

Venkata Narasimha Rao Inukollu

A DISSERTATION

In

COMPUTER SCIENCE

Submitted to the Graduate Faculty

of Texas Tech University in

Partial Fulfillment of

the Requirements for the Degree of

DOCTOR OF PHILOSOPHY

Approved

Dr. Joseph E Urban

Committee Chairman

Dr. Yong Chen

Dr. Mayukh Dass

Dr. Mark Sheridan

Dean of the Graduate School

December, 2015

Texas Tech University, Venkata N Inukollu, December 2015

i

ACKNOWLEDGEMENTS

First and foremost, I would wish to convey my sincere appreciation and thanks to my

advisor Dr. Joseph E Urban for his continuous guidance, reinforcement, and encouragement

during these past years. It has been a great accolade to be his Ph.D. student. I am very grateful

for all the time he invested in making my Ph.D. experience rich and stimulating. Dr. Urban

has always created a lively, enthusiastic, and energetic environment during our research

meetings and I desire to do the same in my career. His delight, passion, and enthusiasm for

research has been contagious and motivational for me. During certain tough times in my

Ph.D. pursuit, Dr. Urban’s insights helped me to lighten my perspective. His scientific advice

and knowledge and many insightful discussions and suggestions have been instrumental in

my research. I strongly believe that over these past few years, Dr. Urban has helped me

emerge as a quality research scientist by providing his valuable feedback, advice, and

encouragement.

I gratefully acknowledge the members of my Ph.D. committee, Dr. Yong Chen and

Dr. Mayukh Dass for their time and valuable feedback on this dissertation. I am thankful to

the committee for their brilliant and constructive comments and suggestions that have helped

me to further ameliorate my research. Many insightful discussions with Dr. Mayukh Dass

have helped me to think about other research topics pertained to data sciences. The constant

academic support and inputs of the committee were greatly appreciated.

I would like to offer my gratitude to all the faculty at Texas Tech University who

played a crucial part in my academic calling. The outstanding coursework along with the

assistance and guidance of the professors have provided me with the foundation for becoming

a research scientist. I feel extremely privileged to have been a student of Computer Science

department at Texas Tech University.

A strong support system is important to enduring in the Ph.D. program. I gratefully

acknowledge the funding sources that made my Ph.D. work possible. I owe a great debt of

gratitude to the Senior Associate Dean of Graduate School, Dr. Clifford Fedler, who hired me

as a graduate student assistant and constantly believed in my endeavor for success. Dr. Fedler,

has been really helpful in offering his valuable advice and opinions many times during my

grad school career. He has always been persistent and encouraging. His intellect and

knowledge of the dissertation process was priceless to me. He is one of my best role models

for a leader, mentor, and instructor. My experience at the graduate school was also enriched

by all my colleagues and the staff of the graduate school. Without their support and assistance

we would not have attained remarkable success in our projects. I would also like to extend my


ii

gratitude to the National Wind Institute, Texas Tech University, for funding my Ph.D.

education.

My time at Texas Tech University was made enjoyable in large part due to the many

friends and groups that became a part of my life. In particular, I would like to thank Mr. &

Mrs. Ronanki, Mr. & Mrs. Thirumula, Anvesh Puli, Hari Inukollu, Manikanta Inukollu,

Kiran Pedada, Divya Spandana, Advithi Pedada, Vinitha Subburaj, Anitha Subburaj, Harsh

Gazula and Lakshmi Sindhuri Juturu, for their unconditional love, support, and

encouragement during my stay at Texas Tech University. I can always count on them for their

valuable and instrumental suggestions. They are altogether a fun bunch with loads of

exuberance and optimism. I can never forget all the wonderful and fun activities that we have

done together. Advithi Pedada, Ira Ronanki, Mila Ronanki and Cheryl Phebe are little angels

who always brighten up my days with their beautiful and cute smiles. I am really happy to

have found a family aside from my home township. Kiran Pedada and Harsh Gazula who are

also doctoral students have invariably been a tremendous help no matter the task or

circumstance. The insightful discussions with them fed me an opportunity to arrive up with

different research ideas. I am very thankful to them for helping me with proofreading my

documents which greatly assisted me in improving my academic writing. Anvesh Puli and

Hari Inukollu are two young people who have constantly surprised and motivated me with

their passion, hard work and expertise in their respective domains. These two young guys

have taught me that passion, hard work and perseverance will serve us to cut through any

hurdles in life. I greatly appreciate the personal rapport that we have formed over the long

time.

I would like to thank my parents & family members without whom this thesis effort

would not have been possible. My family has taught me about hard work, self-respect, and

perseverance. I am profoundly grateful for their constant support in all my pursuits. I cannot

thank them enough for their strong faith in me and for permitting me to be ambitious.

Last, but not least, I greatly appreciate my loving, supportive and encouraging wife

Divya Keshamoni. Our friendship began 10 years ago and has continued thus ever since. Our

friendship continuously evolved and we got married 4 years ago. This dissertation journey

would not have been possible without her unconditional love, patience, faithful support and

unfaltering belief in me. She is my greatest fan and friend. She has taken care of everything

needed without complaining, simply so I could focus on my thesis. She has patiently endured

many, many long hours alone while I worked on my dissertation. During this Ph.D. journey

we have gathered several beautiful memories. This journey could not have been completed

without Divya by my side. She has given me confidence and motivation during my good and

bad times. Divya has been instrumental and fundamental to the completion of my


iii

dissertation. She was constantly by my position during every stride of my Ph.D program and

never complained about my mood changes. She greatly helped me with proofreading my

documents and I am sure that she recognizes the material as well as I make out as she had

read the documents several number of times. Her optimism has always helped me keep things

in perspective. She constantly made things seem less onerous. Her presence in my life has

changed me for the better. I deeply appreciate her with all my heart and soul. Thank You.

Venkata Narasimha Rao Inukollu

Texas Tech University


iv

TABLE OF CONTENTS

ACKNOWLEDGEMENTS ............................................................................................................. i

LIST OF TABLES ......................................................................................................................... ix

LIST OF FIGURES ........................................................................................................................ x

ABSTRACT ................................................................................................................................. viii

1. INTRODUCTION ...................................................................................................................... 1

1.1 Motivation ............................................................................................................................. 1

1.2 Problem Statement ................................................................................................................. 2

1.3 Research Goals ...................................................................................................................... 2

1.4. Software Requirements Specification and Formal Methods ................................................ 3

1.4.1 Functional Requirements ................................................................................................ 4

1.4.2 Non Functional Requirements ........................................................................................ 4

1.4.3 Security Requirements vs Security Policy ...................................................................... 5

1.4.4 Formal Methods in Specification Languages ................................................................. 6

1.5 Summary ................................................................................................................................ 6

2. RELATED WORK ..................................................................................................................... 8

2.1 A Policy Specification Language Design .............................................................................. 8

2.1.1 Define Policy .................................................................................................................. 9

2.1.2 Policy Components/Entities/Constructs ......................................................................... 9

2.1.3 Policy Specification Prototype ....................................................................................... 9

2.1.4 Requirements for a Policy Framework ......................................................................... 13

2.2 Policy Languages and Frameworks ..................................................................................... 14

2.2.1 S-Promela ..................................................................................................................... 14

2.2.2 Ponder ........................................................................................................................... 15

2.2.3 XACML ........................................................................................................................ 15

2.2.4 KAoS ............................................................................................................................ 16

2.2.5 REI ................................................................................................................................ 16

2.2.6 GBPF ............................................................................................................................ 17


v

2.2.7 SPL ............................................................................................................................... 17

2.2.8 TPL ............................................................................................................................... 17

2.3 Evaluation of Policy Languages and Frameworks .............................................................. 18

2.3.1 Evaluation Metric ......................................................................................................... 18

2.3.2 Evaluation Based on Specification Language/Framework ........................................... 19

2.3.3 Evaluation Based on SANS Critical Security Controls ................................................ 23

2.4. Overview of the Descartes Specification Language ........................................................... 34

2.4.1 Syntax and Semantics ................................................................................................... 34

2.4.2 Different Nodes ............................................................................................................ 36

2.4.3 Module Definition ........................................................................................................ 37

2.4.4 Different Trees .............................................................................................................. 38

2.4.5 Example Specifications ................................................................................................ 39

2.4.6 Extensions ..................................................................................................................... 41

2.5 Summary .............................................................................................................................. 41

3. FRAMEWORK TO SPECIFY SECURITY POLICIES .......................................................... 43

3.1 Security Policy and Policy Combinations ........................................................................... 43

3.2 Types of Security Policies ................................................................................................... 44

3.3. Analysis of Existing Frameworks to Specify Security Policies ......................................... 45

3.4 Framework to Specify Security Policies ............................................................................. 46

3.4.1 Policy Entities/Components ......................................................................................... 47

3.4.2 Policies/Rules ............................................................................................................... 47

3.4.3 Policy Applications ....................................................................................................... 47

3.4.4 Policy Knowledge Base ................................................................................................ 48

3.4.5 Policy Manager ............................................................................................................. 48

3.5 Summary .............................................................................................................................. 50

4. SECURE DESCARTES - SECURITY EXTENSIONS TO THE DESCARTES

SPECIFICATION LANGUAGE .................................................................................................. 51

4.1 Introduction ......................................................................................................................... 51

4.2 Abstract/High Level View of a Secure Policy .................................................................... 52


vi

4.3 Policy Type .......................................................................................................................... 53

4.4 Policy Entities ...................................................................................................................... 54

4.4.1 Subject .......................................................................................................................... 55

4.4.2 Object ............................................................................................................................ 56

4.4.3 Actions .......................................................................................................................... 57

4.4.4 Constraints .................................................................................................................... 58

4.5 Secure Descartes Policies .................................................................................................... 60

4.5.1 Authorization Policy ..................................................................................................... 60

4.5.2 Prohibition Policy ......................................................................................................... 63

4.5.3 Obligation Policy .......................................................................................................... 66

4.5.4 Delegation Policy.......................................................................................................... 69

4.5.5 User-defined Policy ...................................................................................................... 73

4.6 Policy Manager Operations ................................................................................................. 77

4.7 Secure Descartes Language Processor ............................................................................... 83

4.7.1 Agent based Descartes Specification Language Processor .......................................... 84

4.7.2 Language Processor Enhancements to Support Security Policies ................................ 85

4.7.3 Secure Policy Validation using Extended Language Processor ................................... 90

4.8 Summary .............................................................................................................................. 91

5. EVALUATION OF EXTENSIONS MADE TO THE DESCARTES SPECIFICATION

LANGUAGE ................................................................................................................................ 92

5.1 Evaluation based on Specification Language/Framework Features .................................... 92

5.2 Evaluation based on SANS 20 Critical Controls ................................................................. 94

5.3 Evaluation based on IEEE std. 830-1998 ............................................................................ 99

5.3.1 Correct .......................................................................................................................... 99

5.3.2 Unambiguous .............................................................................................................. 100

5.3.3 Complete ..................................................................................................................... 100

5.3.4 Consistent ................................................................................................................... 101

5.3.5 Ranked for Importance and/or Stability ..................................................................... 102

5.3.6 Verifiable .................................................................................................................... 102


vii

5.3.7 Modifiable................................................................................................................... 102

5.3.8 Traceable..................................................................................................................... 103

5.4 Summary ............................................................................................................................ 105

6. APPLICATIONS OF THE EXTENSIONS MADE TO THE DESCARTES

SPECIFICATION LANGUAGE ................................................................................................ 106

6.1 Specifying Role Based Access Controls Using Secure Descartes .................................... 107

6.1.1 Role Based Access Controls ....................................................................................... 107

6.1.2 Different Representation of Role Based Access Controls .......................................... 107

6.1.3 Specifying Role Based Access Controls Using Secure Descartes.............................. 108

6.2 Representation of Software Process Modeling Operations Using Secure Descartes ........ 113

6.2.1 Software Process Modeling ........................................................................................ 113

6.2.2 Representations of Software Process Modeling ......................................................... 113

6.2.3 Specifying Software Process Modeling Policies Using Secure Descartes ................. 114

6.2.4 Case Study: Library Management System ................................................................. 114

6.3 Translating Secure Descartes Policies into High Level Programming Code .................... 120

6.3.1 Applications of Secure Software Development Life Cycle ........................................ 120

6.3.2 Secure Descartes Policies into High Level Programming Code ................................ 121

6.4 Summary ............................................................................................................................ 126

7. SUMMARY AND FUTURE WORK ..................................................................................... 127

7.1 Research Results and Achievement of the Research Objectives ....................................... 127

7.2 Contributions of the Research ........................................................................................... 129

7.3 Summary ............................................................................................................................ 131

7.4 Future Research ................................................................................................................. 133

REFERENCES ............................................................................................................................ 135

APPENDIX ................................................................................................................................. 141


viii

ABSTRACT

With increase in demand for the security aspects of software, every phase of the

Software Development Life Cycle (SDLC) is experiencing major changes with respect to

security. Security designers, developers, and testers are keen on improving various security

aspects of a system. Specification of security requirements propagates to different phases of

an SDLC and there exist different techniques and methodologies to specify security

requirements. Business level security requirements are specified using policy specification

languages. The current literature has specification languages that are domain based, web

based, network based, syntax based, semantics based, predicate based, and protocol based. In

this research effort, a generic secure policy prototype and components of the generic secure

policy were defined using formal methods. The Descartes specification language, a formal

executable specification language, has been developed to specify software systems. The

development of a secure policy framework along with extended constructs of the Descartes

specification language for specifying secure policies are some of the deliverables of this

research effort. Tool support was developed in Java for executing a secure policy, which was

written using the extended Descartes specification language in order to validate a

specification. Concepts of secure policies were adopted from the S-Promela, Ponder, and REI

methodologies for secure policy specification, analysis, and design. The applications of

security policies, such as conversion of a secure specification into high level programming

languages, and representation of role based access controls will bridge the gap among the

specification, design, and the implementation phases of secure software development.


ix

LIST OF TABLES

Table 1: Policy Prototype ............................................................................................. 10

Table 2: Evaluation Metric........................................................................................... 18

Table 3: Evaluation of Policy Languages Based on Specification Language Features 23

Table 4: Evaluation of Policy Languages Based on SANS Critical Security Controls 32

Table 5: Results of Authorization Policy Specification ............................................... 63

Table 6: Results of Prohibition Policy Specification ................................................... 66

Table 7: Results of Obligation Policy Specification .................................................... 69

Table 8: Result of Delegation Policy Specification ..................................................... 73

Table 9: Results of User-defined Policy Specification ................................................ 77

Table 10: Results of Policy Operations Specification.................................................. 83

Table 11: Evaluation and Comparison of Secure Descartes Language Features with other

Specification Languages .............................................................................................. 93

Table 12: Evaluation of Secure Descartes Based on SAN Critical Security Controls. 95

Table 13: Comparison of Policy Specification Languages .......................................... 97

Table 14: Evaluation Based on Std. IEEE 830-1998 Characteristics ........................ 104

Table 15: Results of Role Based Access Controls Specification ............................... 112

Table 16: Results of Process Modeling Policies ........................................................ 120

Table 17: Results of Java Class .................................................................................. 125


x

LIST OF FIGURES

Figure 1: Relation Between Secure Components [16] .................................................................... 5

Figure 2: Pick Number Game Specification ................................................................................. 39

Figure 3: Complex Number Specification .................................................................................... 40

Figure 4: Addition of Two Complex Numbers ............................................................................. 41

Figure 5: Secure Policy Framework .............................................................................................. 46

Figure 6: Abstract/High Level View of a Secure Policy............................................................... 53

Figure 7: Representation of Policy Type ...................................................................................... 53

Figure 8: Example of Policy Type Representation ....................................................................... 54

Figure 9: Representation of Policy Entities .................................................................................. 54

Figure 10: Subject Specification ................................................................................................... 56

Figure 11: Object Specification .................................................................................................... 57

Figure 12: Actions Specification ................................................................................................... 58

Figure 13: Constraints Specification ............................................................................................. 59

Figure 14: Representation of Authorization Policy ...................................................................... 60

Figure 15: Example of Authorization Policy Specification .......................................................... 63

Figure 16: Representation of Prohibition Policy ........................................................................... 64

Figure 17: Example of Prohibition Policy Specification .............................................................. 66

Figure 18: Representation of Obligation Policy ........................................................................... 67

Figure 19: Example of Obligation Policy Specification ............................................................... 69

Figure 20: Representation of Delegation Policy ........................................................................... 70

Figure 21: Example of Delegation Policy Specification ............................................................... 72

Figure 22: Representation of User-defined Policy ........................................................................ 74

Figure 23: Example of User-defined Policy Specification ........................................................... 76

Figure 24: Representation of Policy Manager Operations ............................................................ 78

Figure 25: Example of Policy Manager Operations Specification................................................ 82


xi

Figure 26: Language Processor to Support Security Polices ........................................................ 87

Figure 27: Example of XML Parse Tree ...................................................................................... 89

Figure 28: Specification Results Using Language Processor ....................................................... 90

Figure 29: Specification of Role Based Access Controls ........................................................... 111

Figure 30: Library Management Process Model [21] ................................................................. 115

Figure 31: Specification of Process Modeling Policies .............................................................. 119

Figure 32: Example of Java Class Representation ...................................................................... 122

Figure 33: Java Class Equivalent to Role Based Access Control Case Study ............................ 125


1

CHAPTER 1

1. INTRODUCTION

1.1 Motivation

Security is a critical aspect of the software development life cycle, starting

from the requirements phase to the deployment phase. The software development life

cycle is an interdependent process, where each phase depends on the previous phase as

per the traditional software development methodologies, such as waterfall and iterative

approaches. Software development typically starts from the requirements phase, where

functional and non-functional requirements are described. Security requirements are

considered either functional or non-functional requirements based on the context and

software system to be specified. In this research effort, Security requirements are

represented as policies and are derived from business rules that can be represented in

two different ways [1], either by task level (i.e., low level) or business level (i.e., high

level).

In a web system, a security policy can be defined as “a set of rules and

practices describing how an organization manages, protects, and distributes sensitive

information at several levels” [1]. The rules are defined by humans (business analysts)

and so there is a high risk of ambiguity, false interpretation, and errors, which

sometimes cannot be detected. If the errors in business rules are not detected and

corrected in the early stages, problems would be faced in the later stages in terms of

cost and time. Hence, formal specification languages help to specify, create, analyze,


2

maintain, and protect the business rules from ambiguity and false interpretation. There

are hundreds of specification languages in the literature [2, 3, 4, 5, 6, 7, 8, 9], but only

some of them support formal methods. The Descartes specification language is a

formal specification language that has a formal method based syntax, semantics, and

data structures.

1.2 Problem Statement

In a software system, element safety is a critical issue and has a vital role in

system operations. The specification of secure systems demands a more concise and

precise description of a system [2, 3]. There are several specification languages that

exist in the literature [2, 3, 4, 5, 6, 7, 8, 9], which represent secure aspects of a system,

but these specification languages are developed on various factors, such as domain,

web, network, syntax, semantics, predicate, and protocol. There is no secure policy

specification language that uses the full extent of formal methods, which help to

specify secure aspects of the system. Hence, there is a need for a formal secure

specification language that represents, analyzes, and validates the secure policies

effectively.

1.3 Research Goals

The primary goal of this research effort is to create a secure policy framework

for the Descartes specification language that defines, analyzes, and validates the

policies effectively by adding required extensions to the existing work.


3

The objectives of the research effort were to:

I. analyze the Descartes specification language;

II. analyze existing secure policy specification languages;

III. develop a framework to specify security policies;

IV. develop extensions to Descartes to specify security policies;

V. develop a language processor to support extensions to Descartes that specify

security policies;

VI. develop evaluation criteria and compare the extended Descartes specification

language with other secure policy specification languages; and

VII. develop case studies for applications in secure Descartes.

The remainder of the section is organized as follows. Section 1.4 discusses software

requirement types. Section 1.4.1 discusses specification of functional requirements.

Section 1.4.2 discusses specification of non-functional requirements. Section 1.4.3

discusses the relationship among security requirement, security policy, and security

goal. Section 1.4.4 discusses the role of formal methods in software specifications.

1.4. Software Requirements Specification and Formal Methods

Software requirements describe the business level description of the needs of

stakeholders, which can be specified either by using standard methods (i.e., IEEE

STD. 830-1998) [10] or non-standard methods (i.e., organization pre-defined).

Software requirements are divided into functional and non-functional requirements.


4

1.4.1 Functional Requirements

Functional requirements are used to describe the functionality of a software

system. Functional requirements are specified using numerous techniques, such as

formal methods [11], informal methods [12], template based [10], and model based

[12].

1.4.2 Non Functional Requirements

Definitions of non-functional requirements (NFRs) vary based on the context

of the system and different views of authors [13, 14]. IEEE std. 830-1998 described

NFRs in terms of external interfaces such as interacting with other components and

systems, and software attributes, such as constraints, performance, compatibility

portability, and security. Project requirements, such as schedule and cost, are not

included in NFRs as per IEEE std. 830-1998 [10]. As per Jacobson, Booch, and

Rumbaugh, NFRs describe system performance, maintainability, extensibility,

reliability, and constraints [15]. In general, NFRs describe a complete system in terms

of various factors such as behavior, performance, flexibility, usability, and security.

Hence, the representation and validation of non-functional requirements are hard in

comparison to functional requirements. In order to handle the NFRs effectively,

researchers subdivide the NFRs into small groups, such as usability requirements,

reliability requirements, performance requirements, and security requirements. NFRs

are broadly categorized into operational NFRs and non-operational NFRs. System

performance, security, and reliability are examples of operational NFRs and

portability, technology standards, and maintainability are examples of non-operational


5

NFRs. Security requirements are either functional or non-functional requirements

based on the context. In this research effort, security requirements are gathered during

business process modeling. A policy defines operational behavior of a software

system, i.e., the same software system could respond differently for authorized and

unauthorized users. The policy requirements define the security aspects of a software

system.

1.4.3 Security Requirements vs Security Policy

A security requirement is a high level description of business rules, which

needs to be specified using a security policy that will achieve a final security goal. The

relation between a goal, policy, and requirement is as shown in Figure 1 [16]. Security

requirements describe the vulnerabilities associated with an asset, security policy

represents security requirements, and secure goal is established using a secure policy

[16].

Security Goal

Security Policy

Security Requirements

Figure 1: Relation Between Secure Components [16]


6

1.4.4 Formal Methods in Specification Languages

Formal methods are based on mathematical notations, which help to specify

and validate software systems. The level of formalism in specification languages,

varies such as informal, low, and medium to fully formal specification languages.

Researchers argue the benefits of formal methods, which include better

comprehension of the problem, effective validation, clear and consistent specification

while the engineers find formal methods to be inefficient in regards to time and

resources [11, 17, 18].

1.5 Summary

Chapter 1 presented the research problem and the research objectives. Both

functional and non-functional requirements are specified with various methods. In this

research effort, security requirements are considered as non-functional and are derived

from business rules. The policy languages are introduced to represent the security

policies at the specification level. The next section describes various policy

specification languages in the literature.

The remainder of the dissertation document is organized as follows. Chapter 2

discusses the policy components, policy specification languages/frameworks and

evaluation of existing policy frameworks based on language features and SANS

critical security controls. Chapter 3 discusses policy types, policy combinations, and a

generic secure policy framework. Chapter 4 describes extensions made to the

Descartes specification language to define, specify, and validate the security policies.


7

Chapter 5 describes evaluation of extensions made to the Descartes specification

language. Chapter 6 describes the development of applications in secure Descartes,

and Chapter 7 describes research results, research contribution, summary, and future

research work.


8

CHAPTER 2

2. RELATED WORK

This chapter discusses the existing work done in the field of policy

specifications to represent security policies. Section 2.1 discusses the policy language

components and policy representation prototype. The related work on policy

specification languages/frameworks is discussed in Section 2.2. Section 2.3 discusses

the evaluation of policy languages and frameworks. The Descartes specification

language syntax, semantics, and extensions are discussed in Section 2.4. Section 2.5

concludes the chapter with a summary.

2.1 A Policy Specification Language Design

In general, a business level security requirement is described at a high level

using both standard and non-standard methods, which can lead to an ambiguous,

incomplete, and inconsistent security requirement. Researchers introduced different

methodologies and frameworks to specify security requirements. The frameworks,

methods, and methodologies that support these security policies are described as

secure policy specification languages [1, 2, 3, 4, 5, 6, 7, 8, 9]. There are numerous

secure policy specification languages based on modeling, semantics, domain, and

architecture.


9

2.1.1 Define Policy

A security requirement can be described as a policy. Policy language authors

define policy in distinctive sorts of terminology focused around the language and their

perspectives. Garcia et al. define policy as “a set of rules and practices describing how

an organization manages, protects, and distributes sensitive information at several

levels" [1]. Damianou et al. noted that “a policy is a rule that defines a choice in the

behavior of a system” [2]. Despite the different preferences for the definition of

policy, the main intention behind these security policies is to provide confidentiality,

integrity, and availability [2]. Confidentiality confines the information access to

authorized users/systems/software, integrity is responsible for accuracy and

correctness of information, and availability guarantees provision of the right

information at the right time.

2.1.2 Policy Components/Entities/Constructs

A policy component/entity/construct helps to describe a policy clearly and

effectively. A policy specification language uses these four mandatory components,

i.e., subject, object/target, constraints/conditions, and actions/permissions [1, 2, 3, 4, 5,

6] to describe a policy. Few languages [4, 5] use extra constructs to describe more

components depending on the complexity of a security policy.

2.1.3 Policy Specification Prototype

A policy specification contains three significant steps: 1) define the policy

type; 2) specify the policy name; and


10

3) specify the policy components/entities / constructs. A generic prototype

shown in Table 1 is described below.

Description, definition, and specification of the three steps are based on the language

syntax, semantics, features, and extensions. Policy type is a predefined construct in a

policy specification language and describes the characteristics of a security

requirement. The following are some commonly used policies [1, 2, 3, 4, 5, 6] in

specification languages (authorization, prohibition, obligation, delegation, information

filtering, and refrain policies):

Table 1: Policy Prototype

Policy Type Policy Name Policy

components/entities/constructs

Subject

Object/Target

Constraints/Conditions

Actions/Permissions

a) Authorization policy: An authorization policy grants access to resources by

evaluating and validating a given request. For example, consider ATM transactions,

where a client is requesting to either withdraw or deposit money. The request will be


11

served only when the client provides a valid card number and pin number. For this

transaction, an authorization policy is applied.

b) Prohibition policy: A prohibition policy is the negation of an authorization policy.

A prohibition policy prevents access to the resources by validating a set of attributes.

For example, when a client requests the account details of other clients or tries to

perform unauthorized operations, such as withdraw, then the request will be denied.

c) Obligation policy: An obligation policy performs certain immediate actions that are

forced to perform with the occurrence of a specific event in a system. For example, in

ATM banking, users should change their PIN/password on the beginning of the month

to protect from fraud.

d) Delegation policy: A delegation policy grants privileges/rights from a higher level

to a lower level hierarchy. For example, in a company, when a team member wants to

read and write certain security files, the team member needs to get permission from

the team manager.

e) Information filtering policy: An information filtering policy is used to filter

information based on the constraints [7]. For example, a payroll clerk is only permitted

to read personnel records of employees below a particular grade.

f) Refrain policy: A refrain policy [7] rejects the actions that a subject needs to

perform on a target even though a subject is permitted to perform the action. For

example, in a development team, test engineers must not disclose the test results to


12

developers or analysts when the testing is in progress. Analysts and developers would

probably not object to receiving the results.

Authorization, prohibition, obligation, and delegation policies are specified in

Ponder [2], KAoS [3], Rei [4], XACML [5] and S-Promela [6]. Information filtering

and refrain polices are specific to ponder specification language [2].

Policy name describes the nature and context of a policy, which is similar to a

function, method, or module name in high level programming languages, such as C,

C++, and Java. Restrictions on the representation of a policy name, such as the length

of the name depends on syntax and semantics of a particular policy specification

language. Policy components/entities/constructs are defined as follows:

Subject: Any active entity in a system is termed as a subject. For instance, an

employee is attempting to access the resources of the organization, thus employee

performs all operations and therefore the employee acts as a subject.

Object/Target: Any passive entity in a system is termed as an object. In the employee

example, company resources respond whenever a request arrives, hence company

resources act as an object.

Constraint/Condition: A restriction on a subject or an object in order to perform

certain actions. In the employee example, in order to access the company resources,

user should be an employee, which represents a constraint.


13

Action/Permission: Task, process, or method that takes place on an object when a

subject satisfies all the required conditions/restrictions. In the employee example,

access rights, such as read, write, and update are represented as actions.

2.1.4 Requirements for a Policy Framework

A policy specification language should possess certain qualities to specify,

validate, and maintain policies effectively. The requirements for any policy

specification language that helps to create, analyze, and maintain policies are

identified from secure policies in web systems [1], Ponder [2], KAoS [3], Rei [4],

XACML [5] and S-Promela [6] and are as mentioned below.

A policy specification language is:

well defined using proper syntax or semantic structures in order to specify any

policy [1 2, 3, 4, 5, 6];

able to represent the policies in a simple and an unambiguous manner [1, 2, 3,

4, 5, 6];

able to specify access control policies [1, 2, 3, 4, 5, 6];

extensible to represent different domain based policies [1, 2, 3, 4, 5, 6];

flexible and scalable to represent new types of policies in the future [1, 2, 3, 4,

5, 6];

able to resolve the conflicts between similar policies [2, 4, 6]; and

able to validate the existing policies in the framework [6].

A policy can be simple, clear and unambiguous with well-defined syntax or semantic

structure [1, 2, 3, 4, 5, 6]. Analysis and validation of policies determine the correctness


14

and completeness of the secure polices. Extendibility and scalability helps to represent

new policy types and features in the framework. Access control policies are basic

secure policies that need to be addressed [1, 2, 3, 4, 5, 6].

2.2 Policy Languages and Frameworks

Secure aspects are represented in the form of high level rules, which formally

constitute a policy. The specification languages which support different kinds of

policies are called policy specification languages. Several authors have proposed

policy specification languages, each language has its own assets and drawbacks that

need to be improved. The security policies are represented in different formats

depending on the syntax and semantics of the specification language.

2.2.1 S-Promela

S-Promela [6], stands for Security-based Promela, which is an executable

policy specification language, has been built on concepts and rules. S-Promela uses

both syntax and semantic patterns as that of a regular programming language, such as

C, C++, and Java. S-Promela defines the security policy as a "formal statement of the

rules by which people that are given access to an organization technology and

information assets must abide" [6]. The prime assets of the S-Promela language are the

three generic entities (i.e., Subject (S), Object (O), and S-Promela communication

channel (SP)) and effective handling of the three rule types (i.e., authorization,

obligation, and delegation). The communication between Subject to Object should go

through SP using S-to-SP and O-to-SP methods in read and write modes. SP validates


15

the policies and communicates using SP-to-S, SP-to-O methods in read and write

modes. Policy validation and easy portability to a high-level programming language

are notable features in S-Promela.

2.2.2 Ponder

Ponder [3] and XACML [5] are non-semantic based policy specification

languages. Ponder is a simple and declarative language and it adapts object oriented

features while representing security policies. Ponder has a set of policies that address

different domain specific applications, such as networks and distributed systems.

Subject, target, actions, and constraints are the four major components of Ponder,

which describe domain specific services. Ponder classifies the policies as access

control policies, obligation policies, group policies (i.e., policy for a group for better

policy organization and reusability), and meta policies (i.e., policies about policies).

Ponder was designed with access control policies using policy components to restrict

access by illegitimate users. Ponder specification policies can be extended using the

concept of inheritance in an object oriented language. The framework of Ponder

validates the policies effectively and also identifies and resolves the conflicts.

2.2.3 XACML

XACML (Extensible Access Control Markup Language) [5], is a specification

language to address web services. XACML is a context based specification language

and the context is represented in XML using an XML schema. Context contains

different attributes and may have arbitrary Boolean logic. The key attributes that are


16

used to describe access control policies are subject, target, actions, and conditions.

XACML context is based on a request and response query language.

2.2.4 KAoS

KAoS [6] and Rei [4] are semantic based policy specification languages.

KAoS is a goal oriented specification language and is popular for behavioral

specifications. KAoS defines policies, actions, actors, groups, and entities using pre-

defined ontologies. The KAoS architecture consists of three layers, i.e., human

interface, policy management, and enforcement. The human interface layer generates

an ontology based vocabulary from natural language sentences. The policy

management layer analyzes policies, identifies conflicts, and resolves policy conflicts.

The enforcement layer, translates policies and connects to instances at run time. KAoS

contains a set of services and tools to create and manage security policies.

2.2.5 REI

Rei [4] is a policy framework and has three simple language constructs: policy

objects, meta policies, and speech acts to specify, create, and analyze security policies,

respectively. Rights, prohibitions, obligations, and dispensations are the core concepts

of the Rei specification language. Rei uses a “has” predicate to connect the core

concepts to language constructs. The Rei policy objects include subject, action,

conditions, and policy object. The Rei framework is flexible, domain independent, and

extendable. Rei includes meta-policies and modality preference to resolve conflicts.


17

2.2.6 GBPF

The Graph Based Policy Framework (GBPF) [7] defines the policy as a set of

rules that describe individual or collective behavior of a software system. In GBPF,

security policies are represented using graphs. A graph, positive and negative

constraints, and a set of rules are the components of the GBPF. A graph consists of a

set of nodes and edges, constraints define the conditional behavior, rules describe

valid and invalid states of a system. GBPF represents access control polices using

authorization and prohibition rules.

2.2.7 SPL

The Security Policy Language (SPL) [8] is an event based policy language.

SPL is composed of entities, sets, rules, and policies. SPL entity represents objects,

which can have properties, sets represent group of entities, and rules represent

relationship between entities and sets. SPL policy is a group of rules and sets that

represent domain specific events. SPL represents role based access controls and

discretionary access controls using positive and negative constraint rules. Polices and

constraints are combined using "and", "or", and "not" logical operators.

2.2.8 TPL

The Trust Policy Language (TPL) [9] maps entities to roles using predefined

business rules in electronic commerce (e-commerce) applications. Entities represent

active processes in the system, such as users and subsystems. TPL validates entities

using a digital certificate issued by a certificate provider, where the digital certificate


18

is an electronic document used to validate authorization of the entities. Access controls

were implemented using certificate authorization between roles and policies. TPL

syntax was adopted from extensible markup language.

Each policy specification language has its own assets in a specified domain

and drawbacks in other domains. The next section evaluates the effectiveness of these

policy specification languages using various factors.

2.3 Evaluation of Policy Languages and Frameworks

Section 3.2 mentioned several policy specification languages and frameworks.

To evaluate the effectiveness of these languages, this research effort adapted two

approaches. The first evaluation approach was based on language features, such as

syntax, semantics, data structures, policy representation, and policy validations [1].

The second method was based on critical security controls, such as inventory of

authorized software, devices, and users, secure configuration of software & hardware,

and controlled use of administrative privileges suggested by SANS [19].

2.3.1 Evaluation Metric

To evaluate the policy specification language features, the following metric as

shown in Table 2 has been adopted.

Table 2: Evaluation Metric

Representation Meaning Description

NS Not Satisfied Policy specification language


19

does not addresses the

property/feature

PS Partially Satisfied Policy specification language

addresses the property/feature,

but still lacks issues with the

property / feature

S Satisfied Policy specification language

addresses the property/feature

2.3.2 Evaluation Based on Specification Language/Framework

Garcia et al. [1] proposed necessary requirements, such as policy representation,

policy extendibility, policy portability, and policy conflicts for a policy specification

language/ framework to specify, validate, and maintain secure policies. All the policy

specification languages that were mentioned in Section 3.2 are evaluated with the

Garcia et al. proposed characteristics.

Policy Representation: Policy representation differs from one policy

specification language to an other policy specification language. Policy

specification languages XACML [5] and S-Promela [6] use a high level

language syntax for defining the specifications. The access control policy rules

in the Ponder specification language are defined in a high level object oriented

language, which can create a barrier between a developer and customer, as

customers might not be aware of the language, thus resulting in a customer not


20

understanding the requirements. A specification language should be defined in

such a way that secure specifications are understandable both by stakeholders

and developers. To produce a successful product, developers or the organization

should consider the interests of the stakeholders. Therefore, the representation of

the requirements should be understood by the stakeholders in the first place.

Representation of requirements is a main issue in specification languages, so as

to define the requirements in a language that can be understandable by a

customer, as well as a development team. The KAoS [3] and Rei [4] used natural

language with pre-defined policy structure to represent policies.

Define Policies: A policy language should be well-defined with clear and

unambiguous syntax and structure. A policy architecture needs to have a well-

defined independent interface. Policy specification languages should be able to

represent any kind of secure policies/rules that are associated with software. For

some specific behaviors of a system, developers of various specification

languages could not categorize the passive entities for the software, did not know

how to maintain active entities, did not know what actions to perform, and did not

know how to define and implement constraints of a system's behavior.

Validation of Policies: Defining a policy is an easy aspect compared to other

aspects of policy specification languages. Each entity in a policy needs to be

validated. In order to validate a policy, policy specification frameworks need to

collect the information from policy data. The validation of constraints


21

/restrictions/conditions is a critical phase as constraints are validated using policy

entities, such as subject and object. Security policies can be validated internally

within the framework or externally by implementing tool support using high level

programming languages. The Ponder, KAoS, Rei, XACML, and TPL policy

specification languages do not support validation of polices within the

framework. S-Promela supports validation of policies within the framework.

Policy Extendibility: Policy extendibility is an important issue as this feature

describes new policy definitions and implementations. Flexibility of policy

specification languages in terms of adding a new policy. Ponder, KAoS, Rei,

XACML, and S-Promela have common policies, such as authorization,

prohibition, and obligation. Ponder [2] has information filtering and refrain

policies in addition to the common policies that are in use. Even though

specification languages define policies, not all of the policies are applicable or

enough to represent every environment, hence extendibility becomes an important

issue in specification languages. Ponder, KAoS, Rei, XACML can represent

domain specific policies with the help of meta and group based policies. S-

Promela, KAoS, and XACML do not have the capability to represent domain

specific policies.

Portability of Policy: There are several languages that can be used in different

domains to express similar policies. Portability can be defined as flexibility of a

policy that is being applied to different domains. Ponder, KAoS, Rei, S-Promela,


22

GBPF, SPL, and XACML are developed or created, based on specific domain

problems. Hence, the policy languages partially support specification of other

domain policies.

Policy Conflicts: Specification languages should have a conflict detection

technique, which should be able to check that a given policy does not conflict

with any other existing policy. Most of the specification languages ignore this

functionality. For example, in an organization, if an IT team wants to restrict the

“controlled use of the administrative privileges” then the IT technicians may get

confused as to which policy needs to be assigned to get the task done, i.e., either

authorization, prohibition, or delegation raises a policy conflict issue. KAoS

resolves policy conflicts by policy types, REI resolves policy conflicts by

prioritizing policies, and S-Promela resolves policy conflicts by maintaining

precedence between two events. Ponder, GBPF, SPL and XACML do not support

policy conflicts.

Priority of Policies: Prioritizing policies is another feature to consider. When

specification languages do not handle policy conflicts, at least there should be

prioritization of policies. There is no implication that, if policies do not handle

policy conflicts, then policies handle policy prioritization. Policy specification

languages should handle both policy conflicts and policy priorities. When there is

a situation, such as checking the inventory of authorized and unauthorized

devices/software, which policy needs to be applied, whether authorization or


23

prohibition, to handle such scenarios, policy specification languages need to have

a prioritization of policies. The REI and KAoS prioritize policies by policy types.

The Ponder, S-Promela, TPL and XACML do not support the priority of polices.

Table 3 shows, not one of the policy specification languages satisfies all the

criteria that are mentioned by Garcia et al. Each policy specification

language/framework was designed to accomplish the needs of specific targeted

systems, such as web systems, distributed systems, and wireless networks. Future

development of these policy specification languages might add more features to the

existing language/framework.

Table 3: Evaluation of Policy Languages Based on Specification Language Features

Language features S-

Promela

Ponder XACML KAoS Rei GBPF SPL TPL

Policy Representation PS PS PS S S PS PS PS

Define Policies PS PS S S PS PS PS S

Validation of policies S NS NS NS NS PS S NS

Policy Extendibility NS PS NS NS PS S S NS

Portability of Policy PS PS PS PS PS PS PS PS

Policy Conflicts PS NS NS S S NS NS PS

Priority of Policies NS NS NS S S PS PS NS

Formal method based PS NS NS NS NS PS PS NS S - Satisfied, NS - Not Satisfied, PS - Partially Satisfied

2.3.3 Evaluation Based on SANS Critical Security Controls

There are twenty critical security controls (version 5.0) called as SANS critical

security controls that are published by the Center for Strategic International Studies

(CSIS) to improve cyber security and are prioritized mitigation steps [19]. Tracking


24

and precise automation of these top 20 critical security controls has demonstrated more

than a 90% reduction [19] in measured security risk within the U.S. State Department.

The SANS 20 critical security controls have different levels of impact on attack

mitigation ranging from very high to low (shown in Table 4). The SANS critical

security controls were derived from most common attacks for reducing cybercrime.

The SANS 20 critical security controls are described as follows.

Critical security control 1: Inventory of Authorized and Unauthorized Devices [19]

Attackers can take advantage of hacking into any system or network all over the

world by continuously scanning for unprotected systems, networks, and devices. New

hardware devices, outdated devices, guest networks, and temporary systems are

examples of unprotected devices. Critical security control 1 can be achieved by creating

and maintaining updated lists of authorized systems, networks, and devices, so that the

unauthorized device access can be prevented.

Critical security control 2: Inventory of Authorized and Unauthorized Software [19]

Attackers continuously search for vulnerable versions of software that can be

exploited. Attackers use various techniques, such as website phishing, installing

backdoor programs, outdated versions of the software, and previously unknown

vulnerabilities. Critical security control 2 can be achieved by creating and maintaining

an updated list of authorized software and installing regular updates, so that the

unauthorized software installation and execution can be prevented.


25

Critical security control 3: Secure Configurations for Hardware and Software on

Mobile Devices, Laptops, Workstations, and Servers [19]

Default configurations or factory defaults for software and hardware devices

provide ease of use, however, opens the door for hackers to exploit software and

hardware devices. Default user accounts, passwords, account settings, and outdated or

older versions of software are examples of default configurations. Critical security

control 3 can be achieved by creating, updating, and actively maintaining security

configurations on all the respective software and hardware devices, so that the

unauthorized software or hardware access can be prevented.

Critical security control 4: Continuous Vulnerability Assessment and Remediation [19]

Security is continuous assessment and remediation to prevent unauthorized

software, hardware devices, and users. Activities such as identifying and managing

vulnerabilities are continuous processes, which take a considerable amount of time,

attention, and resources. Attackers take advantage of time gaps between new

vulnerabilities and assessment risks. Critical security control 4 can be achieved by

continuous learning, assessing, and performing the required actions on updated

information to identify new vulnerabilities.

Critical security control 5: Malware Defenses [19]

Hackers use malicious software to attack software systems. Malware uses

different techniques to enter into systems, such as email attachments, web pages, cloud


26

services, and user actions. Malware attacks can be prevented by installing automation

systems at multiple locations.

Critical security control 6: Application Software Security [19]

Examples of application software are web-based banking systems, library

systems, and e-commerce applications. Vulnerabilities in application software are due

to several reasons, such as incomplete requirements, coding mistakes, incomplete

testing, and logical errors. Critical security control 6 can be achieved by incorporating

security aspects in all the phases of the software development life cycle, so that security

threats are analyzed and rectified.

Critical security control 7: Wireless Access Control [19]

Hackers often use wireless access to gain control into organizations. Wireless

clients, such as laptops, phones, and PDAs associated with temporary officials or

guests or clients, can be infected through public and unsafe networks. Such devices are

then used as back doors when those devices are reconnected to the network of a target

organization. Critical security control 7 can be achieved by incorporating organization

based security methods and tools to track, identify and prevent unauthorized wireless

clients.

Critical security control 8: Data Recovery Capability [19]

When an organization’s servers are compromised, then hackers can take

advantage of accessing secure data, modifying records, and changing configurations.


27

Hence, organizations need methods, tools, and processes to recover data and erase the

attacker’s presence.

Critical security control 9: Security Skills Assessment and Appropriate Training to Fill

Gaps [19]

Critical security control 9 can be explained with an example. A hacker sent an

email attachment to a team in an organization and some team members opened it

immediately, some team members verified with a security team, and some team

members determined that the attachment has a threat. The above example shows the

importance of assessment because even a single team member’s mistake will open the

door for the hacker. Hence, all the members of the organization must be aware of their

roles and the necessary skills to prevent security threats. The skill gaps can be filled

with appropriate training.

Critical security control 10: Secure Configurations for Network Devices such as

Firewalls, Routers, and Switches [19]

Factory defaults for all the network devices provide for an easy deployment and

use, however from a hacker's point of view, the factory defaults are easy for getting

into network devices. Critical security control 10 can be achieved by establishing and

managing secure configurations based on organizational needs.


28

Critical security control 11: Limitation and Control of Network Ports, Protocols, and

Services [19]

Attackers continuously search for vulnerable network services, such as mail

servers, web servers, domain name systems, and file services. Software packages for

network services install services without informing a user or administrator, which leads

to back door entry of attackers. Critical security control 11 can be achieved by tracking

and controlling network ports, protocols, and services.

Critical security control 12: Controlled Use of Administrative Privileges [19]

An attacker can get the administrative privileges by using two common

methods. In the first method, an attacker sends an email attachment or malicious script

or malicious executable code to administrators, and the attacker gets all the information

of the user whenever the user accesses email attachment or malicious script or

malicious executable code. In the second method, attackers get the information by

guessing random usernames and passwords. Critical security control 12 can be

achieved by tracking and controlling the use of administrator privileges.

Critical security control 13: Boundary Defense [19]

In an organization, flow of information restricted from various levels, such as

within the network, between networks, and outside of networks. An attacker can still

take advantage of architectural weaknesses to attack deeper parts of a network. Critical

security control 13 can be achieved by monitoring, identifying, and preventing

information flow between different trust levels.


29

Critical security control 14: Maintenance, Monitoring, and Analysis of Audit Logs [19]

To identify whether a particular system is attacked or not can be determined by

analyzing the system logs. Security logs have all the information about an attack, such

as time, ports attacked, accessed data, and operations performed. An attack can be

unnoticed without proper security logs. Critical security control 14 can be achieved by

collecting, analyzing, and managing security logs to identify the attacks and recover

from the attacks.

Critical security control 15: Controlled Access Based on the Need to know [19]

Organizations need to identify and separate critical assets from less sensitive

information on their internal networks. An attacker can easily access the information by

exploiting any user if every user in the organization has access to sensitive information.

Hence, organizations need to allow users to access the sensitive information based on

their roles and responsibilities. Critical security control 15 can be achieved by

identifying and separating critical assets, then by controlling access based on a user’s

role.

Critical security control 16: Account Monitoring and Control [19]

An attacker can search for inactive users, such as contract employees that have

left the organization over a certain period of time. Attackers can take advantage of

attacking inactive accounts. Critical security control 16 can be achieved by monitoring,

identifying, and deleting inactive accounts, so that attackers can be prevented.


30

Critical security control 17: Data Protection [19]

In organizations, data are distributed in different places with various

hierarchical levels. Protection of an organization's data is throwing more challenges by

moving the data over to cloud computing and mobile access. Critical security control

17 can be achieved by using the combinations of encryption methods, security tools,

and data loss prevention techniques.

Critical security control 18: Incident Response and Management [19]

When an attack occurs, an organization needs to have an incident response plan.

Without a response plan, an attack may not be identified in the first place. An

organization needs to have plans to identify, analyze, and erase an attacker’s presence

if an attack occurs.

Critical security control 19: Secure Network Engineering [19]

Attackers take advantage of missing security requirements, design, and

development features, and time gaps between new threats and identification process.

Critical security control 19 can be achieved by making security as an inherent attribute

of the software by specifying design and development features.

Critical security control 20: Penetration Tests and Red Team Exercises [19]

An attacker can take advantage of a new vulnerability during the time between

the availability of an updated software package and the installation of the updated

software package. Penetration testing helps in designing and executing tests to identify


31

and assess vulnerabilities. Red team exercises to work with organizational policies,

processes, and defense to improve the overall security features of the organization.

The Ponder [2], KAoS [3], Rei [4], XACML [5], S-Promela [6], GBPF [7],

SPL [8], and TPL [9] languages were assessed on the SANS 20 critical security

controls using the evaluation metric presented in Section 2.3.1. The results are

presented in Table 4 and justified below.

Critical security controls 1 and 2 (in Table 4) can be specified using positive

and negative authorization policies in Ponder and KAoS. In Rei, XACML, S-Promela,

GBPF, SPL, and TPL. The critical security controls 1 and 2 can be specified using

authorization and prohibition policies. Critical security control 4, 9, and 20 cannot be

implemented with any of the policies in Ponder, KAoS, XACML, Rei, S-Promela,

GBPF, SPL, and TPL.

Table 4 shows the status of 20 SANS critical security controls with respect to

each policy specification language [2, 3, 4, 5, 6, 7, 8, 9]. Not one of the policy

specification languages, handles all 20 critical security controls, as the policy

specification languages are designed to represent specific systems. For example, the

KAoS [3] policy specification language was designed to represent security policies in a

web system, hence critical security control 3 (shown in Table 4) i.e., secure

configurations for hardware and software on mobile devices, laptops, workstations, and


32

servers are not handled by KAoS specification language, as there is no policy that will

be able to specify these critical security control.

Table 4: Evaluation of Policy Languages Based on SANS Critical Security Controls

SANS Critical Security

Controls [19]

Impact on

Attack

Mitigation

Policy Specification Languages

S-Promela

Ponder

Rei

XACM

L

KAoS GBPF SPL TPL

1) Inventory of

authorized and

unauthorized

devices.

Very high S S S S S S S S

2) Inventory of

authorized and

unauthorized

software.

Very high

S S S S S S S S

3) Secure

configurations for

h/w and s/w on

mobile devices,

laptops, work

stations, and

servers.

Very high NS S S S NS NS S S

4) Continuous

vulnerability

assessment and

remediation.

Very high NS NS NS NS NS NS NS NS

5) Malware defenses. High/Medium PS S PS PS NS PS S PS

6) Application

software security. High PS S S S PS PS S S

7) Wireless device

control.

High NS S PS NS NS NS S NS

8) Data recovery

capability.

Medium NS S PS NS PS NS S NS

9) Security skills

assessment and

appropriate training

to fill gaps.

Medium NS NS NS NS NS NS NS NS

10) Secure

configurations for

network devices

such as firewalls,

High/Medium PS S PS PS PS NS PS PS


33

routers, and

switches.

11) Limitation and

control of network

ports, protocol, and

services.

High/Medium NS

S PS NS PS NS PS NS

12) Controlled use of

administrative

privileges.

High/Medium PS S S S S S S S

13) Boundary defense. High/Medium S S S S S PS S S

14) Maintenance,

monitoring, and

analysis of audit

logs.

Medium

NS NS PS NS PS PS PS NS

15) Controlled access

based on the need

to know.

Medium S S S S S PS S S

16) Account

monitoring and

control.

Medium S S S S S PS S S

17) Data loss

prevention.

Medium/Low NS NS PS NS PS NS PS NS

18) Incident response

and management.

Medium NS NS S S S PS S S

19) Secure network

engineering.

Low NS NS PS NS PS NS PS NS

20) Penetration test and

red team exercises.

Low NS NS NS NS NS NS NS NS

S - Satisfied, NS - Not Satisfied, PS - Partially Satisfied

Ponder, KAoS, Rei, XACML, S-Promela, GBPF, SPL, and TPL were evaluated using

two methods. The first method is based on the language features such as policy

representation, policy extendibility, policy validation, policy conflicts, and policy

portability. The second method is based on SANS 20 critical security controls. The

next sections introduce the Descartes formal specification language, syntax, data

structures, semantics, and previous extensions made to Descartes to represent various

systems such as real-time, process modeling, and agent systems.


34

2.4. Overview of the Descartes Specification Language

The Descartes specification language is a formal specification language

developed by Urban [11] along with a language processor to execute specifications

with abstract execution. The Descartes specification language is simple and has a well-

defined syntax and semantics to write specifications effectively.

2.4.1 Syntax and Semantics

Basic syntax and semantics of a Descartes specification are derived from a

“Hoare tree” [11]. The Descartes specification language specifies a functional

relationship between input and output, by specifying output data as a function of input

and hence inputs and outputs are key aspects of the Descartes specification language.

The core data structuring methods of Descartes are direct product, discriminated

union, and sequence [11]. Every statement in Descartes is termed as a node. Nodes are

created with meaningful names. Node names may use the underscore ("_") to create

more meaningful names or to differentiate from other nodes. Indentation is used to

represent sub nodes of a node in a tree.

A direct product node [11] is used to concatenate data elements, data sets, or

nodes in the Descartes specification language. An example of a direct product in

Descartes is:

full_name

first_name

last_name


35

The example shows two nodes in the form of a tree denoted by indentation. The

"full_name" node has two sub trees.

A discriminated union node [11] is used to select one element/node out of a set

of choices. The discriminated union is represented using '+' (plus) after the node name.

The data structuring method of discriminated union is similar to an if-then-else in a

high level programming language. An example of a discriminated union in Descartes

is as follows:

test_result+

'pass'

'fail'

The “test_result" tree is a discriminated union node, which has to select either "pass"

node or "fail" node, but not both, or none.

A sequence node [11] is used to specify a repeated occurrence of an

element/node. The lower boundary for a sequence is zero (0) and there is no restriction

on the upper boundary. A sequence node can be represented using an ’*' (asterisk)

after the node name. The sequence data structuring method is similar to the while and

for loop control structures in a high level programming language. An example of a

sequence in Descartes is as follows:

email_msg*

character

In the example, "email_msg" is a sequence of characters and "email_msg" does not

have an upper boundary.


36

An example of lower and upper boundaries in a sequence node in Descartes is:

mobile_text_msg (0..90)

character

The example indicates that "mobile_text_msg" should not exceed 90 characters, the

lower boundary is 0 (zero) and the upper boundary is 90.

Direct product, discriminated union, and sequence can all be used together or can be

used individually. An example of using all three data structures together in Descartes

is as follows:

specific_message*

letter+

'a'

'b'

'c'

symbol

‘$’

The example indicates that the "specific_message" node contains a sequence of letters

that can be 'a' or 'b' or 'c' are separated by symbol ‘$’. In Descartes, single quotes

denote a string literal [11]. An example of a string literal is as follows:

'Descartes'

2.4.2 Different Nodes

Every statement in Descartes is termed as a node and the nodes are broadly

divided into two types, match and reference nodes. Match nodes are represented by


37

lower case letters and reference nodes are represented by upper case letters. A

reference node acquires a value in several ways, such as from a match node that has

acquired a value. A terminal reference node acquires a value of the previously

matched node with the same name.

Examples of reference nodes in Descartes are as follows:

SUBJECT

OBJECT

ACTIONS

CONSTRAINTS

Corresponding match nodes are as follows:

subject

object

actions

constraints

2.4.3 Module Definition

A module in Descartes has two major components, the first one being the name

of the module, which should be represented using upper case letters and underscore ( _

) may be used to create meaningful names. The name of a module describes the

expected result from the module. The second component is the input arguments, which

should also be represented in upper case letters. A module can take any number of

arguments and a module itself acts as an argument to other modules. An example of a

module title in Descartes is as below:


38

SERVER_ACCESS_ GRANTED_OR_DENIED_WITH_( POLICY_INPUTS)

The example indicates that SERVER_ACCESS_GRANTED_OR_DENIED_WITH_

is the name of the module, and POLICY_INPUTS is the input argument.

2.4.4 Different Trees

A module can be declared using a module definition in Descartes. The modular

expansion consists of analysis and synthesis trees. A synthesis tree provides a value to

the module using the "return" statement. If the root node of a Hoare tree is a reference

node, then the Hoare tree is an analysis tree. Similarly, if the root node of a Hoare tree

is a match node, then the Hoare tree is a synthesis tree. Any number of synthesis and

analysis tress can appear in a specification module.

An example of an analysis and synthesis tree in Descartes are as shown in

Figure 2. HIT_OR_MISS_IN_PICK_NUMBER_GAME_ is the name of the module,

the synthesis tree “return” has a value either hit or miss message and PICK_NUMBER

expansions indicate the analysis tree.

HIT_OR_MISS_IN_PICK_NUMBER_GAME(PICK_NUMBER) PICK_NUMBER+ winning_number '9' losing_number+ '0' '1' '2' '3' '4' '5' '6' '7' '8'


39

return+ WINNING_NUMBER 'Hit.. you won the game' LOSING_NUMBER 'Miss..you lost the game'

Figure 2: Pick Number Game Specification

2.4.5 Example Specifications

In this section, two problems are specified using the Descartes specification language.

The two examples are related to complex numbers, and a complex number consists of

real and imaginary portions. Examples of complex numbers are 2+4i, and 3-7i .

The first example specification inputs a complex number and returns the real portion

of a complex number as shown in Figure 3. REAL_PORTION_OF_A_ is the name of

the module, COMPLEX_NUMBER is an input argument, and the synthesis tree

“return” has a value of REAL_NUMBER .COMPLEX_NUMBER expansions

indicate the analysis tree.

REAL_PORTION_OF_A_(COMPLEX_NUMBER)

COMPLEX_NUMBER

real_number+

'1'

'2'

'3'

'4'

'5'

'6'

'7'

'8'

'9'

operator+

'+'


40

'-'

imaginary_number+

'1'

'2'

'3'

'4'

'5'

'6'

'7'

'8'

'9'

‘i’

return

REAL_NUMBER

Figure 3: Complex Number Specification

The second example specification inputs two complex numbers and returns the

addition of two complex numbers as shown in Figure 4. ADDITION_OF_( )_AND_( )

is the name of the module, COMPLEX_NUMBER_1 is an input argument,

COMPLEX_NUMBER_2 is another input argument. The ( )_PLUS_( ) primitive

returns addition of two numbers.

ADDTION_OF_(COMPLEX_NUMBER_1)_AND_(COMPLEX_NUMBER_2)

COMPLEX_NUMBER_1

real_number_1

DIGIT

imaginary_number_1

DIGIT

COMPLEX_NUMBER_2

real_number_2

DIGIT

imaginary_number_2

DIGIT

return

(REAL_NUMBER_1)_ PLUS _(REAL_NUMBER_2)

(IMAGINARY_NUMBER_1)_PLUS_(IMAGINARY_NUMBER_2)


41

Figure 4: Addition of Two Complex Numbers

2.4.6 Extensions

The Descartes specification language has been extended to real-time systems

by introducing a new primitive, “parallel”, to represent the concurrent execution

between two processes, and each process is represented with a Descartes module [20].

The object oriented features, such as abstraction, inheritance, and aggregation were

introduced using a “class” primitive [21]. Two keywords “abstract” and “interface”

were introduced to the Descartes specification language to represent real-time object

oriented features [22]. Agent features are represented with an “agent” keyword [23],

and the process modeling features, such as activity, human actor, and tools are

represented with extensions “activity”, “actor”, “role”, and “tools” [24].

2.5 Summary

Chapter 2 described related work on policy specification language/frameworks.

Each policy specification language/framework has set of components to represent,

validate, and maintain policies. Policy specification languages, Ponder, KAoS, Rei,

XACML, S-Promela, GBPF, SPL, and TPL were evaluated using language features

and SANS critical security controls. The Descartes specification language is a formal

specification language based on a “Hoare Tree” notation [11]. Descartes specifies the


42

output data as a function of input. The Descartes specification language has various

extensions such as object oriented, real-time systems, real-time object oriented, agent

systems, and process modelling to represent the specification effectively. The next

section describes policy types, policy combinations, and secure policy framework.


43

CHAPTER 3

3. FRAMEWORK TO SPECIFY SECURITY POLICIES

This chapter discusses the policy types, policy combinations, and framework to

specify security policies. Section 3.1 discusses different types of policy combinations.

Section 3.2 discusses policy types. Section 3.3 discusses analysis of existing policy

frameworks. Section 3.4 discusses a generic framework to define, specify, and validate

security policies. Section 3.5 concludes the chapter with a summary.

3.1 Security Policy and Policy Combinations

Security policy is a set of rules to control the system behavior and system data.

System behavior describes the state of a system, and system data represents

information assets in a system. Policies are developed on domain specific applications,

such as web based applications, network applications, and electronic commerce

applications.

Kanada [25] combined two or more policies based on mutual dependency or

independency of policies. Concatenation, parallel, selection, and repetition were the

four combinations of policies. Concatenation represents sequential execution of two

policies, and parallel represents parallel execution of two policies if they do not

conflict. Repetition represents iteration of a policy, and selection represents choosing a

policy from multiple policies.


44

3.2 Types of Security Policies

A security policy describes the behavior of a system using a set of rules. Based

on the characteristics of a security policy, policies are categorized into different types,

i.e., meta policy, group policy, role based policy, and compound policy [2, 3, 25]. The

policy types are described as follows.

Meta policy:

A meta policy specifies policy about polices or policy on policies.

Group policy:

A group policy describes a set or a group of policies for various reasons, such

as policy organization, policy reusability, and policy extendibility.

Role based policy:

A role based policy describes a set of rules based on the role of an entity. Role

is assigned with permissions. In an organization, employees are assigned with

permissions based on their roles, manager has read and write permissions, and team

member has read only permission.

Compound policy:

A compound policy describes a set of combined policies to achieve a specific

task or purpose. A compound policy is divided into homogeneous compound policy

and heterogeneous compound policy.

Homogeneous compound policy:


45

In a homogeneous compound policy, if all the polices have the same type of

conditions and the same type of actions, then the policy is called as a homogeneous

compound policy.

Heterogeneous compound policy:

In a heterogeneous compound policy, if the polices have different types of

conditions and different types of actions, then the policy is called as a heterogeneous

compound policy.

3.3. Analysis of Existing Frameworks to Specify Security Policies

Policy specification languages KAoS [3], Rei [4], and XACML [5] were not

based on formal methods, hence they need a special tool to validate the policies

externally. Ponder [2] and S-Promela [6] policy specification languages use the syntax

and semantics of high level programming languages such as C, C++, and Java, which

makes it difficult for the stakeholders to understand. The high level programming

language representation creates a communication barrier among stakeholders,

specification engineers, and design engineers. Also, Ponder [2], KAoS [3], Rei [4],

XACML [5], and S-Promela [6] cannot integrate security requirements in functional

requirements due to the differences between policy specification languages and

functional specification languages. In order to avoid these problems, this research

effort created a framework for Descartes specification language, which is completely

based on formal methods. The new framework can validate the policies in the


46

framework using abstract execution, which can also be able to integrate the security

requirements into functional requirements.

3.4 Framework to Specify Security Policies

The secure policy framework, consists of five major components as shown in

Figure 5 i.e., Policy entities/components, policies/rules, policy manager, policy

knowledge base, and policy applications. The secure policy framework and

components of the framework have been considered for extending the Descartes

specification language to specify security policies. Each component in the framework

has its own functionality and has a unique role. Each component is described in

detailed in subsequent sections.

Figure 5: Secure Policy Framework


47

3.4.1 Policy Entities/Components

Policy entities/components are basic building blocks of the policy framework.

Subject, object, actions, and constraints are the entities of secure policy framework.

The concept of policy entities was adapted from Ponder [2], KAoS [3], Rei [4],

XACML [5], and S-Promela [6]. Each entity describes the specific behavior of a

system/component. The entities provide inputs to the different security policies. The

secure policy framework is flexible in terms of adding a new entity to the existing

entities. The facts and details of the entities exist in the policy knowledge base. Policy

manager and entities interact with each other to create, configure, and maintain

effective entities.

3.4.2 Policies/Rules

The second and a key component of the secure policy framework is defining

secure policies with the help of policy entities/components. A policy/rule in the secure

policy framework must be defined with the help of subject, object, actions, and

constraints as show in the Figure 5. SPF is flexible in terms of adding a new policy to

the existing policies. Authorization, delegation, prohibition, obligation, and user-

defined are the basic policies.

3.4.3 Policy Applications

The policies/rules are extendable to represent access control policies, such as

role based and group based policies. Applications of a policy/rule can help to improve

software quality in a secure software development life cycle.


48

Secure software development life cycle: Applications of a secure policy can be

extendable to a software development life cycle by writing secure specifications

effectively, such as providing inputs to secure design, conversion of secure policy

specification into high level programming code, and generating security test cases

from a secure policy specification.

Access control policies: Role based access controls (RBAC) [26, 27] are used in both

industry and research efforts. RBAC is a procedure to restrict the permissions/access to

authorized users with the help of different roles. Secure policies can be extendable to

represent access control policies.

Application based security policies: Secure policies can be capable of handling

different domain applications, such as web applications, network applications, and

embedded systems by introducing domain specific extensions.

3.4.4 Policy Knowledge Base

A policy knowledge base contains entities, data, and details about the policies.

Policy history, such as policy conflicts, and priority of policies will be stored in the

policy knowledge base. The term knowledge base resembles a database/data store in

database management systems. A policy knowledge base will be a key component in

validating secure policies using a Java compiler.

3.4.5 Policy Manager

A policy manager acts as a moderator in a secure policy framework.

Maintaining policies, assigning priorities to policies, resolving conflicts in the policies


49

are the key functionalities of the policy manager. Policy manager resolve the conflicts

by assigning priorities to each secure policy and also consider the order of policies.

A secure policy is represented with subject, object, actions, and constraints.

Each policy entity represents a specific entity of a policy. Entities information, policy

priorities, and policy conflict information are stored in the policy knowledge base. The

policy knowledge base could be an external file or stored internally in the policy

specification. The Descartes specification language stores information in the terminal

nodes. Policy types should be identified using pre-defined keywords. Policy conflict

occurs when one policy is trying to perform an operation and another policy is trying

to prohibit from performing the same operation. Policy conflicts can be generated by

domain specific rules, policies, and operations. Policy conflicts can be resolved using

two ways, either static or dynamic. In the static resolution technique, all the possible

conflicts are identified, computed, and stored in a pre-defined place, such as a policy

knowledge base or policy history. Static conflict resolution techniques consider the

amount of time, resources, and money due to pre computation. Dynamic conflict

resolutions technique act at run time and resolve the conflicts.


50

3.5 Summary

This chapter described policy types, the combination of polices and a secure

policy framework to define, specify, and validate security policies. The secure policy

framework consists of five components: policy entities, policies/rules, application of

secure policies, policy manager, and policy knowledge base. Each component has

specific roles and responsibilities. Concatenation, parallel, selection, and repetition

were the four combination of policies. The next chapter describes the extensions made

to the Descartes specification language to specify security policies.


51

CHAPTER 4

4. SECURE DESCARTES - SECURITY EXTENSIONS TO THE

DESCARTES SPECIFICATION LANGUAGE

This chapter introduces and describes extensions made to the Descartes

specification language to specify security policies. This section also provides case

study examples to describe security policy concepts. Section 4.1 describes the added

concepts to the Descartes specification language to define, specify, and validate

security policies. Section 4.2 describes the high level view of secure polices. Section

4.3 describes policy types and policy representation. Section 4.4 describes policy

entities, representations, and specification examples. Section 4.5 describes secure

Descartes polices, representations, and case studies. Section 4.6 describes policy

manager operations, such as policy conflicts and conflict resolution methods. Section

4.7 describes the extended language processor to execute secure Descartes policies.

The extensions made to the Descartes specification language follow the same syntax,

semantics, and execution of the original Descartes specification language.

4.1 Introduction

The Descartes specification language is a simple yet powerful formal

specification language used to specify various systems, such as object oriented, real-

time systems, real-time object oriented, agent systems, and process modelling.

Existing work on the extensions available to the Descartes specification language do


52

not define, specify, analyze, and validate the secure polices. The existing work was

enhanced by this research effort.

In order to describe the security policies, basic entities/elements of security

policies must be modeled. The policy type, subject, object, actions, and constraints are

the basic entities of a security policy. To specify and validate security policies in the

Descartes specification language, three concepts have been added in the form of

extensions. The added concepts are: 1) policy entities; 2) policy type; and 3) policy

manager operations. These extensions represent domain specific statements,

expressions, or methods.

4.2 Abstract/High Level View of a Secure Policy

Abstract representation of a security policy consists of three parts: policy type,

policy entities, and policy manager operations. Each part will be defined, described,

and represented in the subsequent sections. A security policy is represented as shown

in Figure 6.

POLICY_TYPE POLICY_NAME

policy_entities

subject

object

actions

constraints

policy_manager_operations

policy_priority

policy_conflicts_validation


53

policy_conflicts_resolution

Figure 6: Abstract/High Level View of a Secure Policy

4.3 Policy Type

A security policy describes the set of rules to protect a software system, and

those rules are represented with the help of policy entities such as subject, object,

actions, and constraints. A security policy is represented as shown in Figure 7.

POLICY_TYPE POLICY_NAME_WITH

Figure 7: Representation of Policy Type

Policy type represents the type of policy and valid policy types are

authorization, prohibition, delegation, obligation, or user-defined. These are new

extensions introduced in the Descartes specification language in the form of primitives

to represent the policy types. Authorization defines the access rights to resources by

validating the received requests. Prohibition, also called negative authorization [2],

prevents access to the resources by validating a set of attributes. Delegation grants

rights or permissions or privileges from a higher level authority to a lower level in the

hierarchy. An obligation policy describes the immediate actions that take place after a

specific set of events in a system. A policy that cannot be considered as authorization,

prohibition, delegation, or obligation, can be defined as user-defined policy. Policy

name could be any meaningful name as per the Descartes specification language


54

naming standards, which describes the output of a secure policy. Finally,

POLICY_INPUTS represents one or more inputs for a given security policy. An

example representation of a policy type is specified as shown in Figure 8.

Consider a security policy, an organization consisting of technical and non-

technical staff, where authorized staff should be given access to organization

resources. The goal of the security policy is to grant access rights to authorized people.

Hence, policy type is specified as authorization.

authorization ALLOW_RESOURCE_ACCESS_WITH

Figure 8: Example of Policy Type Representation

4.4 Policy Entities

Subject, object, actions, and constraints are policy entities. The reserved

keyword “policy_entities” is used to specify entities in a given security policy. Policy

entities are represented as show in Figure 9.

policy_entities

subject

object

actions

constraints

Figure 9: Representation of Policy Entities


55

4.4.1 Subject

Subject describes an active entity in a system, i.e., users, components, and

subsystems. A user is a human actor who uses a software system, component is any

software or hardware device which seeks information, and subsystem is part of a

complex system which performs independent operations. Active entities are domain

specific information. The reserved keyword “subject” is used to specify active entities

in a given security policy. An example specification of a subject can be represented as

shown in Figure 10.


technical staff, where authorized technical staff should be given access to organization

resources. Here, subject specifies the active entities, such as technical and non-

technical staff.

authorization ALLOW_RESOURCE_ACCESS_WITH_(POLICY_INPUTS)

POLICY_INPUTS

user_status

employee_type+

tech_staff

‘technical staff’

non_tech_staff

‘non technical staff’

unknown_role

STRING

policy_entities

subject

EMPLOYEE_TYPE


56

Figure 10: Subject Specification

4.4.2 Object

Object describes passive entities in a system. Passive entities are independent

and have no processing capabilities, such as resources and service providers.

Resources are assets in software system and assets are distributed through service

provider The Ponder specification language refers to an object as a target [2]. The

reserved keyword “object” is used to specify passive entities in a given security

policy. An example specification of an object can be represented as shown in Figure

11.


technical staff, where authorized technical staff should be given access to a data

server. Here, subject specifies active entities in a system, such as technical staff and

non-technical staff, and object specifies a passive entity, such as a data server.


POLICY_INPUTS

user_status

employee_type+

tech_staff


non_tech_staff


unknown_role

STRING

policy_entities

subject


57

EMPLOYEE_TYPE

object server_type

‘data server’

Figure 11: Object Specification

4.4.3 Actions

Actions describe tasks, processes, or methods that take place on an object

when a subject satisfies the existing constraints in the policy. Tasks represent an

activity, process represents a series of steps to achieve a goal, and methods define a

procedure. The actions are domain specific tasks. The reserved keyword “actions” is

used to specify the tasks, operations, or methods in a given security policy. An

example specification of actions can be represented as shown in Figure 12.

Consider a secure policy, an organization consisting of technical and non-

technical staff where authorized technical staff should be given access to data server

with both read and write operations. Subject specifies active entities in a system, such

as technical staff and non-technical staff, object specifies a passive entity, such as data

server, and actions specify operations, such as read and write.


POLICY_INPUTS

user_status

employee_type+

tech_staff


58


non_tech_staff


unknown_role

STRING

policy_entities

subject

EMPLOYEE_TYPE

object server_type

‘data server’

actions read_operation

‘read data from data server’

write_operation

‘write data to data server’

Figure 12: Actions Specification

4.4.4 Constraints

Constraints describe conditions or restrictions on existing policies. Constraints

are inferred from subject, object, and actions. The reserved keyword “constraints” is

used to specify conditions or restrictions in a given secure policy. An example

specification of constraints can be represented as shown in Figure 13.

Consider a secure policy, an organization consisting of technical and non-

technical staff, where authorized technical staff should be given access to a data server

with both read and write operations, and non-technical staff can read data from the

data server. Subject specifies active entities in a system, such as technical staff and


59

non-technical staff. Object specifies a passive entity, such as a data server. Actions

specify operations, such as read and write, and constraints specify restrictions on read

and write operations, such as only technical staff can perform both read and write

operations, and non-technical staff can perform read only operation.


POLICY_INPUTS

user_status

employee_type+

tech_staff


non_tech_staff


unknown_role

STRING

policy_entities

subject

EMPLOYEE_TYPE

object server_type

‘data server’

actions read_operation

‘read data from data server’

write_operation

‘write data to data server’

constraints

constraint_selection+

read_operation_constraint

NON_TECH_STAFF

read_and_write_operation_constraint

TECH_STAFF

Figure 13: Constraints Specification


60

Actions take place in sequential, parallel, or iteration modes of the same action.

Sequential actions are represented with a direct product [11] data structure in the

Descartes specification language. Parallel actions are represented with the key word

“parallel" that was introduced by Sung in real time Descartes [20]. Iterations of the

actions are represented with the sequence data structure in Descartes [11].

4.5 Secure Descartes Policies

4.5.1 Authorization Policy

Authorization defines the access rights to resources by validating the received

request with a set of attributes. In secure Descartes, authorization represents the type

of actions a subject can perform on a specified object by satisfying defined constraints.

Authorization grants permission to perform the actions only if constraints are satisfied.

The reserved keyword “authorization” is used to specify the secure policy type. An

authorization policy is represented in secure Descartes as shown in Figure 14.

authorization POLICY_NAME_ (POLICY_INPUTS)

Figure 14: Representation of Authorization Policy

‘authorization’ is a keyword in secure Descartes and is followed by any meaningful

policy name. The following case study provides a better understanding of the

authorization policy.


61

Case study:

In an organization, employees could be distinguished as technical staff and

non-technical staff. Technical staff could have the permissions or rights to access the

data of the company for processing company documents. Hence, the technical staff

will be able to create, update, and delete the documents to effectively handle the

operations of the company. Whereas, non-technical staff could have limited access to

organizational documents, for example reading documents. Non technical staff are

prohibited from updating or deleting documents. A secure Descartes specification for

the case study is as shown in Figure 15.

ALLOW_RESOURCE_ACCESS_WITH_ is a policy name in which subject

specifies the employee role, and object is the data server. Create, update, and delete

services represent actions, and constraints validate user role. POLICY_INPUTS

consists of user role. If the employee type is either a technical staff or non-technical

staff, then the policy is granted along with associated actions, otherwise the policy is

denied.


POLICY_INPUTS

user_role

employee_type+

tech_staff


non_tech_staff


unknown_role

STRING


62

policy_validation

validation_status+

policy_granted

‘Authorization policy granted’

policy_denied

‘Authorization policy denied’

policy_entities

subject

EMPLOYEE_TYPE

object

server_type

‘data server’

actions

create_service

'create a document'

read_service

‘read a document’

update_service

'update a document'

delete_service

'delete a document'

constraints


read_service_constraint

NON_TECH_STAFF

read_and_write_service_constraint

TECH_STAFF

return

EMPLOYEE_TYPE+

TECH_STAFF

READ_AND_WRITE_SERVICE_CONSTRAINT

ACTIONS

CREATE_SERVICE

READ_SERVICE

UPDATE_SERVICE

DELETE_SERVICE

POLICY_GRANTED

NON_TECH_STAFF

READ_ SERVICE _CONSTRAINT

READ_SERVICE


63

POLICY_GRANTED

UNKNOWN_ROLE

POLICY_DENIED

Figure 15: Example of Authorization Policy Specification

Table 5 presented the execution results of the specification shown in Figure 15

using the language processor. For valid inputs, corresponding actions are executed

along with the policy granted message, and policy returns denied message for invalid

inputs. If the input is ‘technical staff’, then create a document, read a document,

update a document, and delete a document actions are executed along with

authorization policy granted message. Authorization policy is denied if the input is

‘consultant’.

Table 5: Results of Authorization Policy Specification

Input to the specification Output from the specification

user_role: technical staff create a document

read a document

update a document

delete a document

Authorization policy granted

user_role: non technical staff read a document


user_role: consultant Authorization policy denied

4.5.2 Prohibition Policy

Prohibition, also denoted as negative authorization [2], prevents access to the

resources by validating a set of attributes. In secure Descartes, prohibition represents


64

the type of actions a subject cannot perform on a specified object by satisfying the

defined constraints. The reserved keyword, “prohibition” is used to specify the secure

policy type. A prohibition policy is represented in secure Descartes as shown in Figure

16.

prohibition POLICY_NAME_ (POLICY_INPUTS)

Figure 16: Representation of Prohibition Policy

‘Prohibition’ is a reserved keyword in secure Descartes and is followed by a

meaningful policy name. The following case study provides a better understanding of

the prohibition policy.

Case study:

In internet banking, customers can perform operations, such as money

transfers, paying bills, and updating customer information, such as mobile number and

addresses. Customers can access their own accounts, but cannot modify or delete the

pre-defined data, such as account holder name, SSN, and account number. The main

objective of the case study is to explain the restriction of access on user accounts to

unauthorized clients. A secure Descartes specification for the case study is shown in

Figure 17.

DENY_UNAUTHORIZED_USERS_WITH_ is a policy name in which subject

specifies user types in the internet banking, and object is the bank data server. Update

and delete services represent actions, and constraints validate user role.


65

POLICY_INPUTS consists of user type. If the user type is technical staff then the

policy is granted along with associated actions, otherwise the policy is denied.

prohibition DENY_UNAUTHORIZED_USERS_WITH

_(POLICY_INPUTS)

POLICY_INPUTS

user_type+

customer

'bank customer'

tech_staff


policy_validation

validation_status+

policy_granted

‘policy granted’

policy_denied

‘policy denied’

policy_entities

subject

USER_TYPE

object

server_type

‘bank data server’

actions

update_service

'update pre-defined data such as SSN'

delete_service

'delete an account'

constraints

update_and_delete_service_constraint

TECH_STAFF

return

USER_TYPE+

TECH_STAFF

UPDATE_AND_DELETE_SERVICE_CONSTRAINT

ACTIONS

UPDATE_SERVICE

DELETE_SERVICE

POLICY_GRANTED


66

CUSTOMER

POLICY_DENIED

Figure 17: Example of Prohibition Policy Specification

Table 6, presented the execution results of the specification showed in Figure

17 using language processor. For valid inputs, corresponding actions are executed


inputs. If the input is ‘technical staff’, then update_service and delete_service actions

are executed along with policy granted message. Policy is denied if the input is

‘customer’.

Table 6: Results of Prohibition Policy Specification


user_type: technical staff update pre-defined data such as SSN

delete an account

policy granted

user_type: customer policy denied

4.5.3 Obligation Policy

An obligation policy describes the immediate actions that take place after a

specific set of events in a system. An event represents change in a system, and action

represents a task. In secure Descartes, an obligation represents the type of actions a

subject is forced to perform on the object due to certain events in a system. The

reserved keyword “obligation” is used to specify a secure policy type. An obligation

policy is represented in secure Descartes as shown in Figure 18.


67

obligation POLICY_NAME_ (POLICY_INPUTS)

Figure 18: Representation of Obligation Policy

‘obligation’ is a reserved keyword in Descartes and is followed by a

meaningful policy name. POLICY_INPUTS describes the inputs to a policy. The

following case study provides a better understanding of the obligation policy.

Case study:

In ATM banking, ATM customers can perform deposit, withdrawal, balance

transfers, pin modification, and mini statement generation. These operations can be

performed based on customer interests, however, customers should change a debit

card PIN number on the first day of every month to protect themselves from malicious

users as per the bank’s mandatory policies. The main objective of the case study is to

pursue a user to change the PIN number every month. A secure Descartes

specification for the case study is shown in Figure 19.

UPDATE_DEBIT_PIN_EVERY_MONTH_ is a policy name, subject specifies user

type, and object specifies user account. Update_debit_pin represent actions,

constraints validate user role, and verify whether the current day is the first day of the

month or not. EXTENDED_DIGIT returns any number between 1 to 31. Primitive

EQUAL returns true if the inputs to the primitive are equal, else primitive returns


68

false. If constraints are validated successfully, the obligation policy is triggered with

associated actions, otherwise the obligation policy is not triggered.

Obligation UPDATE_USER_DEBIT_PIN_EVERY_MONTH_(POLICY_INPUTS)

POLICY_INPUTS

user_type+

customer

‘ATM customer'

others

STRING

current_date

day

EXTENDED_DIGIT

first_day_of_month

‘1’

policy_validation

validation_status+

policy_granted

‘obligation policy triggered’

policy_denied

‘obligation policy not triggered’

policy_entities

subject

USER_TYPE

object

account_type

‘user account’

actions

update_debit_pin

'update debit pin number'

constraints

update_debit_pin_service_constraint

CUSTOMER

(DAY)_EQUAL_(FIRST_DAY_OF_MONTH)

return


69

USER_TYPE+

CUSTOMER

UPDATE_DEBIT_PIN_SERVICE_CONSTRAINT

UPDATE_DEBIT_PIN

POLICY_GRANTED

OTHERS

POLICY_DENIED

Figure 19: Example of Obligation Policy Specification



along with the policy granted message and policy returns denied message for invalid

inputs. If the input is the first day of the month and the user type is ATM customer,

then update_debit_pin is executed along with an ‘obligation policy triggered’ message.

Obligation policy is not triggered if the user_type is unknown.

Table 7: Results of Obligation Policy Specification


user_type: ATM customer

day: ‘1’

update debit pin number

obligation policy triggered

user_type: unknown

day: ‘1’

obligation policy not triggered

4.5.4 Delegation Policy

Delegation grants the rights or permissions or privileges from a higher level

authority to a lower level in the hierarchy. In secure Descartes, delegation represents

the type of actions a subject can grant to another subject to be performed on a


70

specified object. The reserved keyword “delegation” is used to specify secure policy

type. A delegation policy is represented in secure Descartes as shown in Figure 20.

delegation POLICY_NAME_ (POLICY_INPUTS)

Figure 20 : Representation of Delegation Policy

'delegation' is a keyword in secure Descartes and is followed by a meaningful

policy name. The following case study provides a better understanding of the

delegation policy.

Case study:

In an organization, all the employees do not have the same privileges. In order

to attain a few privileges, a team member should contact the team manager because,

only a team manager has the rights to grant the privileges to team members based on

their roles and responsibilities. For example, only technical staff have the right to

create, update, and delete data files, whereas non-technical staff are restricted to read

only access. The main objective of the case study is to show that certain privileges can

be granted only by higher level authorities to the team members. A secure Descartes

specification for the case study is shown in Figure 21.

GRANT_OR_DENY_PRIVILEGES_TO_TEAM_MEMBER_WITH_ is

a policy name, subject specifies employee roles in the organization, object specifies

data server, and the constraint determines either the user is technical staff or non-

technical staff. Based on the employee role, technical staff is assigned with both read


71

and write access, and non-technical staff is restricted to read only access. Policy is

denied for other user roles.

delegation GRANT_OR_DENY_PRIVILEGES_TO_TEAM_MEMBER_WITH_

(POLICY_INPUTS)

POLICY_INPUTS

employee_role_1+

team_manager

‘team manager’

tech_staff

'team member'

staff

'not a team member'

other_role

STRING

employee_role_2+

team_manager

‘team manager’

tech_staff

'team member'

staff

'not a team member'

other_role

STRING

policy_validation

validation_status+

policy_granted

‘delegation policy granted’

policy_denied

‘delegation policy denied’

policy_entities

subject

EMPLOYEE_ROLE_1

EMPLOYEE_ROLE_2

object

server_type


72

‘dedicated data server for team’

actions

grant_read_permission

'granted read permission on data server'

grant_write_permission 'granted write permission on data server'

constraints

constraint_selection+ grant_read_permission_constraint

EMPLOYEE_ROLE_1

STAFF

EMPLOYEE_ROLE_2

TEAM_MANAGER

grant_read_and_write_permission_constraint

EMPLOYEE_ROLE_1

TECH_STAFF

EMPLOYEE_ROLE_2

TEAM_MANAGER

return+

EMPLOYEE_ROLE_1+

STAFF

GRANT_READ_PERMISSION_CONSTRAINT

GRANT_READ_PERMISSION

POLICY_GRANTED

TECH_STAFF

GRANT_READ_AND_WRITE_PERMISSION_

CONSTRAINT

ACTIONS


GRANT_WRITE_PERMISSION

POLICY_GRANTED

OTHER_ROLE

POLICY_DENIED

POLICY_DENIED

Figure 21: Example of Delegation Policy Specification


73



along with the delegation policy granted message and delegation policy denied for

invalid inputs. If the inputs are ‘team member’ and ‘team manager’ then

grant_read_premission and grant_write_premission actions are executed along with

delegation policy granted message. Delegation policy is denied if one of the input is

not a ‘team manager’.

Table 8: Result of Delegation Policy Specification


employee _role_1: team member

employee _role_2: team manager

granted read permission on data server

granted write permission on data server

delegation policy granted

employee _role_1: consultant

employee _role_2: team member

delegation policy denied

4.5.5 User-defined Policy

A policy that cannot be defined as authorization, prohibition, delegation, or

obligation, can be defined as a user-defined policy. Any security policy can be

represented as a user defined policy. User-defined policy creates custom policies. The

reserved keyword “user-defined” is used to specify secure policy type, and user-

defined policy is represented in secure Descartes as shown in Figure 22.


74

user-defined POLICY_NAME (POLICY_INPUTS)

Figure 22 : Representation of User-defined Policy

'user-defined' is a keyword in secure Descartes and is followed by a

meaningful policy name. The following case study provides a better understanding of

the user-defined policy.

Case study:

In an organization, employees status could be distinguished as active and

inactive. Employees who are working as full time are considered active and employees

who are working as part time are considered in-active. Active empolyees could access

and modify the company records from anywhere including both within the

organization network and outside the organization network. In-active employees could

have limited access if they are outside the organization network. In this case study, the

status and location of an employee are the key aspects for granting permissions. The

main objective of the case study is to show that certain privileges can be granted only

based on access location. A secure Descartes specification for the case study is shown

in Figure 23.

ACCESS_RIGHTS_WITH_ is a policy name in which subject specifies the

employee status, and object is the data server. Read and write permissions represent

actions, and constraints validate user position and user status. POLICY_INPUTS

consist of employee position and employee status. If the employee status is active or


75

in-active then the policy is granted along with associated actions, otherwise the policy

is denied.

user-defined ACCESS_RIGHTS_WITH_ (POLICY_INPUTS)

POLICY_INPUTS

employee_status+

active

'active status’

in_active

'passive status '

unknown_status

STRING

access_position+

local

'within company network'

global

'outside of company network'

policy_validation

validation_status+

policy_granted

‘user-defined policy granted’

policy_denied

‘user-defined policy denied’

policy_entities

subject

EMPLOYEE_STATUS

object

server_type

‘dedicated data server for team’

actions

grant_read_permission

'grant read permission on data server'

grant_write_permission

'grant write permission on data server'

constraints



76

grant_read_permission_constraint

IN_ACTIVE

GLOBAL


LOCAL

return+

EMPLOYEE_STATUS +

ACTIVE

GRANT_READ_AND_WRITE_PERMISSION

_CONSTRAINT

ACTIONS



POLICY_GRANTED

IN_ACTIVE

ACCESS_POSITION+

GLOBAL


_CONSTRAINT


POLICY_GRANTED

LOCAL

GRANT_READ_AND_WRITE_

_PERMISSION_CONSTRAINT

ACTIONS

GRANT_READ_

PERMISSION


POLICY_ GRANTED

UNKNOWN_STATUS

POLICY_DENIED

Figure 23: Example of User-defined Policy Specification


77

Table 9 presented the execution results of the specification showed in Figure

23 using the language processor. For valid inputs, corresponding actions are executed

along with the user-defined policy granted message and user-defined policy denied for

invalid inputs. If the inputs are ‘active status’ and ‘within company network’ then

grant_read_premission and grant_write_premission actions are executed along with

user-defined policy granted message. User-defined policy is denied if one of the inputs

is ‘unknown’ and the user position is ‘outside of company network’.

Table 9: Results of User-defined Policy Specification


employee_status: active status

access_position: within company network

granted read permission on data server

granted write permission on data server

user-defined policy granted

employee_status: unknown

access_position: outside of company

network

user-defined policy denied

4.6 Policy Manager Operations

The policy manager assigns priorities to policies, validates policy conflicts,

and resolves policy conflicts. The reserved keyword “policy_manager_operations” is

used to specify operations of a secure policy. Policy priority describes rank of the

secure policy in the system. Policy conflict occurs when one policy is trying to

perform an operation and another policy is trying to prohibit from performing the

same operation. In the secure Descartes specification language, conflicts are resolved


78

by assigning priorities to policies. Policy manager operations are represented as

follows.


policy_priority

INTEGER


…


…

Figure 24: Representation of Policy Manager Operations

The policy manager operations are described in detailed with a case study. In

an organization, employees could be distinguished as technical staff and non-technical

staff. Technical staff could have the permissions or rights to access the data of the

company for processing company documents. Hence, the technical staff will be able to

create, update, and delete the documents to effectively handle the operations of the

company. Whereas, non-technical staff could have limited access to organizational

documents, such as reading documents. Non technical staff are prohibited from

updating or deleting documents. A policy conflict occurs when technical staff are

updating data while non-technical staff are trying to access the same data from another

policy. A secure Descartes specification for the case study is as shown in Figure 25.

ALLOW_RESOURCE_ACCESS_WITH_ policy has POLICY_INPUTS and

POLICY_ CONFLICT_ DATA passed as arguments. POLICY_INPUTS consists of


79

user status. POLICY_CONFLICT_ DATA consists of policy conflict data and priority

of conflicted policy. In the case study, the policy reads conflict data from policy

knowledge base, then checks if there is conflict or not, using the IS_TRUE primitive,

policy checks employee role and proceeds with associated actions if there are no

conflicts, policy compares priorities using LESS_ THAN primitive then proceeds if

the current policy priority is greater than the conflicted policy priority, else the current

policy waits until the conflicted policy completes its actions.

Case 1: No policy conflict

If both technical and non-technical staff are not trying to access the services at

the same time then is_it_a_policy_conflict returns false. If there is no policy conflict

then ALLOW_ RESOURCE_ACCESS_WITH determine EMPLOYEE_TYPE and

executes associated ACTIONS.

Case 2: Policy conflict, current policy priority is greater than conflict policy

If both technical and non-technical staff are trying to access the services at the

same time then is_it_a_policy_conflict returns true. If there is policy conflict then

ALLOW_ RESOURCE_ ACCESS_WITH determine which policy executes first by

comparing CURRENT_ POLICY_PRIORITY and CONFLICT_POLICY_PRIORITY

using Descartes primitive GREATER_THAN. In this case, primitive returns true and

current policy executes first by determining EMPLOYEE_TYPE and followed by

associated ACTIONS.


80

Case 3: Policy conflict, current policy priority is less than conflict policy

If both technical and non-technical staff are trying to access the services at the

same time then is_it_a_policy_conflict returns true. If there is policy conflict then

ALLOW_ RESOURCE_ ACCESS_WITH determine which policy executes first by

comparing CURRENT_ POLICY_PRIORITY and CONFLICT_POLICY_PRIORITY

using Descartes primitive LESS_THAN. In this case, primitive returns true and

conflict policy executes first and current policy wait until conflict policy completed.

authorization ALLOW_RESOURCE_ACCESS_WITH_(POLICY_INPUTS)_ HAVING

_(POLICY_CONFLICT_DATA)

POLICY_INPUTS

user_status

employee_type+

tech_staff


non_tech_staff


other_type

STRING

POLICY_CONFLICT_DATA

is_it_a_policy_conflict

BOOLEAN

conflict_policy_priority

INTEGER

policy_validation

validation_status+

policy_granted


policy_denied



81

policy_entities

subject

EMPLOYEE_TYPE

object server_type

‘data server’

actions

create_service

‘create a record from data server’

read_service

‘read a record from data server’

write_service

‘write a record to data server’

delete_service

‘delete a record from data server’

constraints


read_service_constraint

NON_TECH_STAFF

read_and_write_service_constraint

TECH_STAFF


current_policy_priority

INTEGER


policy_conflicts_status+

policy_conflict

(IS_IT_A_POLICY_CONFLICT)_IS_TRUE

policy_no_conflict

(IS_IT_A_POLICY_CONFLICT)_IS_

FALSE


policy_ resolution _status +

current_policy_executes_first

(CONFLICT_POLICY_PRIORITY)_LESS_

THAN_(CURRENT_POLICY_PRIORITY)

‘current policy executes first’


82

conflict_policy_executes_first

(CONFLICT_POLICY_PRIORITY)_GREATER_

THAN_(CURRENT_POLICY_PRIORITY)

‘conflict policy executes first’

return

POLICY_CONFLICTS_STATUS+

POLICY_NO_CONFLICT

EMPLOYEE_TYPE+

TECH_STAFF

READ_AND_WRITE_SERVICE_

_CONSTRAINT

ACTIONS

CREATE_SERVICE

READ_SERVICE

WRITE _SERVICE

DELETE_SERVICE

POLICY_GRANTED

NON_TECH_STAFF

READ_ SERVICE _CONSTRAINT

READ_SERVICE

POLICY_GRANTED

OTHER_TYPE

POLICY_DENIED

POLICY_CONFLICT

POLICY_ RESOLUTION _STATUS +

CURRENT_POLICY_EXECUTES_FIRST

CONFLICT_POLICY_EXECUTES_FIRST

Figure 25: Example of Policy Manager Operations Specification

Table 10 presents the execution results of the specification shown in Figure 25



83


inputs. If the input is ‘non technical staff’ and ‘is_it_a_policy_conflict’ is false, then

read a record from data server action is executed along with authorization policy

granted message. If the input is ‘non technical staff’ and ‘is_it_a_policy_conflict’ is

true, then policy manager compares ‘current_policy_priority’ and

‘conflict_policy_priority’ then which ever policy has higher priority will get executed

first. Authorization policy is denied if the input is ‘consultant’, which is an invalid

input.

Table 10: Results of Policy Operations Specification


user_status: non technical staff

is_it_a_policy_conflict:false

conflict_policy_priority:42

current_policy_priority:52

read a record from data server


user_status: non technical staff

is_it_a_policy_conflict:true



conflict policy executes first

user_status: consultant




Authorization policy denied

4.7 Secure Descartes Language Processor

This section describes the agent based Descartes specification language

processor and the enhancements that were made to extend the tool to support secure

policies. Tool support overcomes manual step by step execution time, errors


84

associated with syntax and semantics. The extended tool verifies the syntax and

semantic of a secure policy and produce results based on the policy inputs.

4.7.1 Agent based Descartes Specification Language Processor

The agent based Descartes specification language processor [28] was adopted

to analyze, validate, and extend secure policies. The agent based language processor

was analyzed and validated with different sample Descartes specification data, such as

module based specification and agent based specification. The agent based language

processor consists of six phases, i.e., lexical analysis and parsing, symbol table

creation, knowledge/belief base, agent module, semantic analysis, and output

generation phases [28]. The roles and responsibilities of each phase are described as

follows:

Lexical analysis and parsing: The Descartes specification language processor parses

and converts the input specification into small tokens based on the language syntax

and semantics. The interpreter creates the syntax tree from the tokens and passes the

syntax tree as an input to the next phase. The new extensions, such as policy type,

subject, object, actions, and constraints, will be added to support secure policy

execution and validation.

Symbol table creation: The syntactic structure of the Descartes specification language

is checked in this phase. The parser rules for the Descartes specification language,

such as match and reference node concepts were used in the symbol table creation

which stores the outcomes corresponding to those rules.


85

Knowledge/belief base: The knowledge/belief base consists of the initial beliefs

associated with agent goals, attributes, and plans. The interpreter reads beliefs from

the knowledge base, while validating agent goals. The knowledge base will be used to

represent policy history, such as static policy conflicts in secure Descartes.

Agent module: The agent module helps to identify the ‘agent’ keyword in the

specification module following which the agent goals, attributes, and plans are

segregated. Then the agent specification is analyzed and validated. The agent module

will be replaced with secure policy module by defining policy types such as

authorization, prohibition, delegation, obligation, and user-defined.

Semantic analysis: Semantic structure of the Descartes specification language is

checked in this phase. The grammar and semantic rules for policy types will be added

in the interpreter which ensure the checking analysis and synthesis trees are

semantically correct.

Output generation: The output is generated depending on the input specification. The

interpreter generates syntax or semantic error messages if the input specification

consists of syntax or semantic issues. The agent goals and corresponding events are

displayed if the input specification is free from syntax and semantic issues.

4.7.2 Language Processor Enhancements to Support Security Policies

The goal of the language processor enhancements were to validate the secure

Descartes specification language policies. Additional compiler elements, policy syntax


86

and semantics, policy notations, and grammar were added to the existing language

processor to support secure Descartes entities such as subject, object, actions, and

constraints. An extended language processor was developed using Java modules to

process grammer and syntax tree [29], Another Tool for Language Recognition

(ANTLR) create grammer for secure policies [30], and eXtensible mark of language

(XML) parser creates syntax tree [31]. An extended language processor takes a secure

policy as input, executes the secure specification, and outputs the results based on the

syntax and semantics of a secure policy.

The enhanced language processor framework has four major modules as

shown in the Figure 26 i.e., Descartes Java compiler, XML parser, secure Descartes

core module, input module, and output module. The roles and responsibilities of each

module are described as follows.

Secure Descartes core module:

The secure Descartes core module consists of three sub modules i.e., policy

module, policy manager module, and policy knowledge base module. The policy

module represents the syntax and semantics of the policy entities, such as subject,

object, actions, and constraints. The policy knowledge base and policy manager are

the key functionalities of the core module. The policy knowledge base module stores

information of POLICY_INPUTS, policy priorities, policy conflict status, and

information associated with the policy entities and policy types. The policy manager

module validates policy conflicts and resolves conflicts based on policy priorities. The


87

policy manager uses IS_TRUE and IS_FALSE primitives to identify the policy

conflicts, GREATER_THAN and LESS_THAN primitives to compare the policy

priorities. These primitive were added to the XML parser to identify and parse the

specification. More implementation details are presented in Appendix A.

Figure 26: Language Processor to Support Security Polices

XML parser:

The XML parser takes the input specification from the input module then parse the

input specification and construct a parse tree as show in Figure 27. The XML object


88

model contains the policy organization structure, policy entities, policy manager

operations, and primitives to support policy manager operations. The XML object

model represents information associated with a secure policy in a tree structure, which

is called as parse tree.

In Figure 27, authorization (policy type) is the root node and POLICY_INPUTS,

policy_entities, and policy_manager_operations are child nodes. Subject, object,

actions, and constraints are the child nodes to policy_entities. Each node is associated

with a value field which stores the terminal node information. Constraints are stored in

the value field, and refer to the parse tree when a reference node occurs.

Input module:

An input module reads input specification and performs primary validation,

such as verify syntax, file format, and policy type. Input specification syntax confirm

the input specification as the Descartes specification. Input module accept text files

which restrict invalid file types. The input specification should be specified as per the

rules of the secure Descartes syntax and semantics. More implementation constraints

are presented in Appendix A.


89

Figure 27: Example of XML Parse Tree

Output module:

Writing the result to the external files, recording the logs, such as syntax or

semantic error messages are functionalities of the output module. Policy actions

corresponding to policy inputs are displayed along with grant messages for valid

POLICY_INPUTS, and policy denied messages, and these results can be written to

external text files or can be displayed in user console as shown in Figure 28.


90

Figure 28: Specification Results Using Language Processor

4.7.3 Secure Policy Validation using Extended Language Processor

The specification examples in Sections 4.5, 4.6, 5.1, and 5.2 were validated using

the enhanced language processor and presented the results using different input test

data. More details of test bed configurations are presented in Appendix A. The

features of the extended tool are described as follows.

accept input specification as text file;

verify syntax and semantics of the secure Descartes specification;


91

validate policy constraints;

identify policy conflicts and resolve policy conflicts; and

generate results.

4.8 Summary

This chapter described extensions made to the Descartes specification language.

Extensions for policy types, subject, object, actions, and constraints were introduced to

the Descartes specification language to specify secure policies. Policy type represents

the type of policy and valid policy types are authorization, prohibition, delegation,

obligation, or user-defined. Assigning priorities, validating policy conflicts and

resolving policy conflicts were the operations of a policy manager. The extended

language processor supports execution of a secure policy. The next section describes

evaluations of extensions made to the Descartes specification language to specify

security policies.


92

CHAPTER 5

5. EVALUATION OF EXTENSIONS MADE TO THE DESCARTES

SPECIFICATION LANGUAGE

This chapter describes validation techniques to evaluate the effectiveness of

extensions made to Descartes specification language. Section 5.1 describes the evaluation

approach based on language features such as syntax, semantics, data structures, policy

representation, and policy validations. Section 5.2 describes the evaluation approach

based on critical security controls provided by the SANS Institute. Section 5.3

describes the evaluation approach based on the IEEE std. 830-1998 characteristics.

5.1 Evaluation based on Specification Language/Framework Features

Garcia et al. [1] proposed necessary requirements, such as policy

representation, policy extendibility, policy portability, and policy conflicts for a policy

specification language/ framework. The specification language/framework features are

shown in Table 11. The Ponder [2], KAoS [3], Rei [4], XACML [5], S-Promela [6],

GBPF [7], SPL [8], and TPL [9] language features were validated and presented in

Section 2.3.2. The evaluation metric presented in Section 2.3.1 has been adopted to

validate the extensions made to the Descartes specification language and the results

are presented in Table 11 and justified below.

The policy representation uses simple syntax and semantics adopted from the

Descartes specification language. Policy representation consists of three components,


93

i.e., policy type, policy name, and policy inputs. In secure Descartes, every policy is

interpreted with unique reserved key words assigned with unique significance, which

ensure to read and understand the specification in only one way. The unique keyword

feature and formalism ensure to define and resolve any ambiguous specification. The

secure Descartes specification language introduced a new policy type called ‘user-

defined’, which specify different policies apart from authorization, prohibition,

delegation, and obligation in various environments, such as process modeling, e-

commerce application, and agent systems. The secure Descartes specification

language assigns priorities and resolves the conflicts based on defined priorities.

Abstract execution, match and reference node concepts of the Descartes specification

language enables to validate secure policies.

Table 11: Evaluation and Comparison of Secure Descartes Language Features with

other Specification Languages

Language

features

S-

Promela

Ponder XACML KAoS Rei GBPF SPL TPL Secure

Descartes

Policy

Representation

PS PS PS S S PS PS PS S

Define Policies PS PS S S PS PS PS S S

Validation of

Policies

S NS NS NS NS PS S NS S

Policy

Extendibility

NS PS NS NS PS S S NS S

Portability of

Policy

PS PS PS PS PS PS PS PS S

Policy Conflicts PS NS NS S S NS NS PS S

Priority of

Policies

NS NS NS S S PS PS NS S

Formal Method

Based

PS NS NS NS NS PS PS NS S



94

5.2 Evaluation based on SANS 20 Critical Controls

SANS 20 critical security controls [19] were proposed by the SANS Institute

in order to provide a list of controls that would protect software from real world

threats. The SANS 20 critical security controls describe the policies that any software

system must follow to prevent the advanced targeted threats, such as exploit critical

infrastructures, tampering of financial and health care systems. The SANS 20 critical

security controls help in improving the overall quality of software by measuring

different aspects of the software, such as differentiating between authorized and un-

authorized users, differentiating between authorized and un-authorized software,

access controls, boundary defense, vulnerability assessment, and data recovery

capabilities.

The Ponder [2], KAoS [3], Rei [4], XACML [5], S-Promela [6], GBPF [7],

SPL [8], and TPL [9] languages were validated and presented in Section 2.3. The

evaluation method presented in Section 2.3.1 was adopted to validate the secure

extensions made to the Descartes specification language. The secure extensions were

validated with the help of the SANS 20 critical controls as shown in the Table 12,

comparison with other policy languages in Table 13. Representation of the critical

security controls in the specification phase propagates to other phases, which helps

with an easier integration of the controls in the design and development phases.

In Table 12, the SANS 20 critical security controls except control 9 and 10 are

able to be specified with secure Descartes policies. Critical security controls 1 & 2


95

specified with authorization policy, security controls 3, 4, 5, 6, 7, 8, 10, 17, 18, & 19

specified with user-defined policy, security controls 12, 13, & 15 specified with

combination of authorization and prohibition policies, and security controls 11 and

14 specified with the combination of authorization and user-defined policies. Critical

security controls 9 and 20 are unable to specify by any of the existing secure Descartes

polices as these controls deal with training and team exercise, which are out of the

scope of the secure Descartes framework.

Table 12: Evaluation of Secure Descartes Based on SAN Critical Security Controls

SANS 20 Critical Security Controls

[19]

Impact on

Attack

Mitigation

Secure

Descartes

Policy Type

1. Inventory of authorized and

unauthorized devices.

Very high

Authorization

2. Inventory of authorized and

unauthorized software.

Very high

Authorization

3. Secure configurations for h/w and

s/w on mobile devices, laptops,

work stations, and servers.

Very high

User-defined

4. Continuous vulnerability

assessment and remediation.

Very high User-defined

5. Malware defenses. High/Medium

User-defined


96

6. Application software security. High User-defined

7. Wireless device control. High

User-defined

8. Data recovery capability. Medium

User-defined

9. Security skills assessment and

appropriate training to fill gaps.

Medium

10. Secure configurations for network

devices such as firewalls, routers,

and switches.

High/Medium

User-defined

11. Limitation and control of network

ports, protocol, and services.

High/Medium

User-defined,

Authorization

& Prohibition

12. Controlled use of administrative

privileges.

High/Medium

Authorization

& Prohibition

13. Boundary defense. High/Medium Authorization

& Prohibition

14. Maintenance, monitoring, and

analysis of audit logs.

Medium

User-defined,

Authorization

& Prohibition

15. Controlled access based on the need

to know.

Medium

Authorization

& Prohibition

16. Account monitoring and control. Medium

User-defined

&

Authorization

17. Data loss prevention. Medium/Low

User-defined

18. Incident response and management. Medium

User-defined

19. Secure network engineering. Low User-defined

20. Penetration test and red team

exercises. Low

X- Not supported by any policy types


97

The Ponder [2], KAoS [3], Rei [4], XACML [5], S-Promela [6], GBPF [7], SPL

[8], TPL [9], and the secure Descartes specification languages were assessed on the

SANS 20 critical security controls using the evaluation metric presented in Section

2.3.1. The results were presented in Table 13 and justified below.

Critical security controls 1 and 2 can be specified using positive and negative

authorization policies in Ponder and KAoS. In Rei, XACML, S-Promela, GBPF, SPL,

TPL, and the secure Descartes specification language. The critical security controls 1

and 2 can be specified using authorization and prohibition policies. Critical security

control 4, 9, and 20 cannot be implemented with any of the policies in Ponder, KAoS,

XACML, Rei, S-Promela, GBPF, SPL, TPL, and the secure Descartes specification

language.

Table 13: Comparison of Policy Specification Languages

SANS Critical

Security Controls

[19]

Impact

on Attack

Mitigatio

n

Policy Specification Languages

S-

Promel

a

Ponder

Rei

XAC

ML

KAo

S

GBP

F

SPL

TPL

Secure

Descart

es

1. Inventory of

authorized and

unauthorized

devices.

Very high S S S S S S S S S

2. Inventory of

authorized and

unauthorized

software.

Very high

S S S S S S S S S


98

3. Secure

configurations

for h/w and s/w

on mobile

devices,

laptops, work

stations, and

servers.

Very high NS S S S NS NS S S S

4. Continuous

vulnerability

assessment and

remediation.

Very high NS NS NS NS NS NS NS NS PS

5. Malware

defenses.

High/Med

ium

PS S PS PS NS PS S PS S

6. Application

software

security.

High PS S S S PS PS S S S

7. Wireless device

control.

High NS S PS NS NS NS S NS S

8. Data recovery

capability. Medium NS PS PS NS PS NS PS NS PS

9. Security skills

assessment and

appropriate

training to fill

gaps.

Medium NS NS NS NS NS NS NS NS NS

10. Secure

configurations

for network

devices such as

firewalls,

routers, and

switches.

High/Med

ium

PS S PS PS PS NS PS PS S

11. Limitation and

control of

network ports,

protocol, and

services.

High/Med

ium

NS

S PS NS PS NS PS NS S

12. Controlled use

of

administrative

privileges.

High/Med

ium

PS S S S S S S S S

13. Boundary

defense.

High/Med

ium

S S S S S PS S S S

14. Maintenance,

monitoring, and

analysis of

audit logs.

Medium

NS NS PS NS PS PS PS NS S

15. Controlled

access based on

Medium S S S S S PS S S S


99

the need to

know.

16. Account

monitoring and

control.

Medium S S S S S PS S S S

17. Data loss

prevention. Medium/L

ow

NS NS PS NS PS NS PS NS PS

18. Incident

response and

management.

Medium NS NS S S S PS S S S

19. Secure network

engineering.

Low NS NS PS NS PS NS PS NS S

20. Penetration test

and red team

exercises.

Low NS NS NS NS NS NS NS NS NS


5.3 Evaluation based on IEEE std. 830-1998

The secure extensions made to the Descartes specification language were

evaluated on IEEE std. 830-1998 [10]. The IEEE std. 830-1998 describes the

characteristics of a good software requirement specification and the characteristics are

described as follows.

5.3.1 Correct

The IEEE std. 830-1998 [10] states that “An SRS is correct if, and only if,

every requirement stated therein is one that the software shall meet”.

In the secure Descartes specification language, every requirement is specified

using secure entities such as subject, object, actions, and constraints. The correctness

of secure entities are validated through the top-down modular approach of the

Descartes specification language. The top-down approach validates the correctness of


100

the top module requirements before moving to lower module requirements. The case

study examples in Chapter 4 were specified using secure entities keywords, then the

correctness was validated using the top-down modular approach.

5.3.2 Unambiguous

The IEEE std. 830-1998 [10] states that “An SRS is unambiguous if, and only

if, every requirement stated therein has only one interpretation”.

In the secure Descartes specification language, every policy is interpreted with

unique reserve words assigned with unique significance, which ensures to read and

understand the specification in only one way. The Descartes specification language is

based on formal methods, secure polices were an extension to the Descartes

specification language, which follows the same syntax and semantics of original the

Descartes specification language. The unique keyword feature and formalism helps to

resolve any ambiguous specification.

5.3.3 Complete

The IEEE std. 830-1998 [10] states that “An SRS is complete if, and only if, it

includes the following elements:

a) All significant requirements, whether relating to functionality, performance, design

constraints, attributes, or external interfaces. In particular, any external requirements

imposed by a system specification should be acknowledged and treated.


101

b) Definition of the responses of the software to all realizable classes of input data in

all realizable classes of situations. Note that it is important to specify the responses to

both valid and invalid input values.

c) Full labels and references to all figures, tables, and diagrams in the SRS and the

definition of all terms and units of measure”.

The secure Descartes satisfies a and b clauses as 1) the secure Descartes

specification language has various entities to deal with specified requirements, such as

subject, object, actions, and constraints; 2) secure polices were an extension to the

Descartes specification language, which follows the same logic of representing output

as a function of input of the original Descartes specification language; and 3) secure

Descartes validates the requirements at various levels and then respond to both valid

and invalid inputs. The secure Descartes specification language does not have any

feature to support last clause i.e., references to all figures, tables, and diagrams in the

SRS.

5.3.4 Consistent

The IEEE std. 830-1998 [10] states that “An SRS is internally consistent if,

and only if, no subset of individual requirements described in it conflict”.

The secure Descartes used standard terminologies and definitions that are

adopted from various specification languages [1, 2, 3, 4, 5, 6]. The formalism in the

Descartes specification language ensures consistency. The “Hoare tree” notation

ensures that the requirements can be specified without conflicts.


102

5.3.5 Ranked for Importance and/or Stability

The IEEE std. 830-1998 [10] states that “An SRS is ranked for importance

and/or stability if each requirement in it has an identifier to indicate either the

importance or stability of that particular requirement”. In secure Descartes, policies

are assigned with a priority to resolve the policy conflicts. A keyword

“policy_priority” is used to specify the priority of a policy and hence secure Descartes

satisfied the ranked for importance and/or stability feature.

5.3.6 Verifiable

The IEEE std. 830-1998 [10] states that “An SRS is verifiable if, and only if,

every requirement stated therein is verifiable. A requirement is verifiable if, and only

if, there exists some finite cost-effective process with which a person or machine can

check that the software product meets the requirement”. The secure Descartes

specification language follows the same mechanism as Descartes specification

language, i.e., by representing the output in terms of input by a function. In secure

Descartes, the output can be verified by following the synthesis tree in which there

exists a match node for every reference node. The secure Descartes policy output can

be verified using the tool support.

5.3.7 Modifiable

The IEEE std. 830-1998 [10] states that “An SRS is modifiable if, and only if,

its structure and style are such that any changes to the requirements can be made

easily, completely, and consistently while retaining the structure and style”.


103

The secure extensions to the Descartes specification language follows the

Hoare tree structure while describing the specification. A requirement can be divided

and specified with different sub trees of a Hoare tree, and all subtrees in the same level

are independent, hence a requirement change or modification can be easily identified

and modified without effecting the complete specification. For example, any change in

the policy object specification will not affect other sub trees in the case study

presented in Section 4.5.1.

5.3.8 Traceable

The IEEE std. 830-1998 [10] states that “An SRS is traceable if the origin of

each of its requirements is clear and if it facilitates the referencing of each requirement

in future development or enhancement documentation”.

In this research effort, the traceability feature was discussed in two aspects,

i.e., traceability of each requirement in software requirement specification document,

and traceability of a requirement in the Descartes specification language. The forward

and backward traceability of a requirement in the Descartes specification language is

achievable using match and reference nodes concepts. There is no mechanism to trace

each requirement in software requirement specification document.

The evaluation metric presented in Section 2.3.1 has been adopted to validate

the extensions made to the Descartes specification language and the results are

presented in Table 14 and justified below.


104

In secure Descartes, every requirement is specified using secure entities, such

as subject, object, actions, and constraints. The correctness of secure entities are

validated with a top-down modular approach to developing Descartes specifications.

The unique key word feature and formalism ensures to resolve ambiguous and

inconsistent specification. The secure Descartes specification language ranks the

policies by assigning priorities to secure policies. In the secure Descartes specification

language, the output can be easily verified by following the synthesis tree and also the

output can be verified using the language processor. A requirement can be divided and

specified with different sub trees of a Hoare tree, and all subtrees in the same level are

independent, hence a requirement change or modification can be easily identified and

modified without effecting the complete specification. A requirement can be traced

using match node and reference node concepts in a secure Descartes specification, but

there is no mechanism to trace the list of requirements in the specification document.

The secure Descartes specification language partially satisfied the completeness

property, as there is no mechanism to handle labels, table, and figure references in

SRS document.

Table 14: Evaluation Based on Std. IEEE 830-1998 Characteristics

Evaluation based on std. IEEE 830-1998 [7]

Extended Descartes

specification language

Correct S

Unambiguous S

Complete PS

Consistent S

Ranked for importance and/or scalability S

Verifiable S

Modifiable S


105

Traceable PS


5.4 Summary

This chapter described evaluation methods to validate the extensions made to

the Descartes specification language to specify security policies. Three methods were

used to validate the secure extensions made to the Descartes specification language.

The first method was based on policy language features, the second method was based

on the SANS critical security controls, and the third method was based on the IEEE

Std. 830-1998. This chapter also presented evaluation criteria to compare policy

specification languages. The next chapter describes applications of the secure

Descartes specification language.


106

CHAPTER 6

6. APPLICATIONS OF THE EXTENSIONS MADE TO THE

DESCARTES SPECIFICATION LANGUAGE

This chapter describes the application of extensions made to the Descartes

specification language to specify security policies. This section also provides case

study examples to describe applications of security policy concepts. Section 6.1

describes the role based access controls and representation of the role based access

using the secure Descartes specification language. Section 6.2 describes the software

process modeling and representation of secure polices associated with the software

process modeling. Section 6.3 describes the process of translating the secure Descartes

specification policies into high level programming code.

Ponder [2], KAoS [3], Rei [4], XACML [5] and S-Promela [6] define, specify,

analyze, and validate secure policies. However, the policy specification languages do

not address the application of secure policies, such as representing domain specific

policies, representing role based access controls, and the role of secure policies in

other phases of the software development life cycle. This chapter presents three case

studies that describe the application of the secure Descartes specification language: 1)

representation of role based access controls, 2) representation of domain specific

policies, and 3) generation of high level code.


107

6.1 Specifying Role Based Access Controls Using Secure Descartes

6.1.1 Role Based Access Controls

Role Based Access Controls (RBAC) is a procedure to restrict the

permissions/access to authorized users. In role based access control, the permissions

are correlated with roles and, authorized users are responsible members of appropriate

roles. In RBAC models, roles and permissions regulate access to data and resources.

Access control represents the fact of determining whether a user is able to perform an

operation on resources. The role-based access control has generated tremendous

interest in the security community as a flexible approach to access control. RBAC

regulated the access of users to both information and system resources based on the

activities that a user has to execute on a system.

6.1.2 Different Representation of Role Based Access Controls

RBAC models were represented using the unified modeling language (UML)

[32]. Use case modeling in UML provides functional requirements of systems that are

specified with use cases and actors. Static modeling provides a structural view of the

information in a system and dynamic modeling shows a behavioral view of a system.

Role based authorization constraints were specified with the Object Constraints

Language (OCL) [33], which is part of the Unified Modeling Language. Graphical

Representation of RBAC policies was specified with conceptual graphs. Conceptual

graphs describe forward and backward chaining capabilities in a graph, which help to

represent a function hierarchy, rules for modeling access controls, and reasoning on


108

policies [34]. The spatio-temporal RBAC model used a graph-theoretic notation to

represent user-role assignment, permission-role assignment, permission-object

assignment, and role hierarchy [35].

6.1.3 Specifying Role Based Access Controls Using Secure Descartes

Specification of users, roles, and permissions are part of security policies,

which are known as access controls. Access controls can be represented in various

ways, well known among them are the role based access controls and attribute based

access controls [36, 37]. A user is a human actor, who uses a software system, role is a

title associated with a set of functions, and permission is a right or ability to perform a

function.

The active entities in the RBAC model are users and roles, passive entities in

the RBAC model are resources, permissions represents a task or function, and

permissions are assigned by roles. Secure extensions made to the Descartes

specification language are used to specify the entities of role based access controls.

Users and roles are specified with subject, passive entities are specified with object,

permission are specified with actions, and restrictions/access conditions are specified

with constraints. The secure Descartes specification language entities are used to

specify role based access controls as follows:

subject: represents roles;

object: represents resources;

actions: represents permissions associated with roles; and


109

constraints: validates role.

A case study is presented in Section 6.1.4 to specify role based access controls using

secure Descartes specification.

6.1.4 Case Study: Employee Roles in an Organization

In an organization, an employee privileges can be assigned to the role of the

employee. A manager could have the right to create, read, write, and delete data files.

A team member could have the right to read and write data files, whereas staff could

have restricted to read only access. The main objective of the case study is to show

that certain privileges can be granted only by the role of the employee. A secure

Descartes specification for the case study is shown in Figure 29.

A secure Descartes specification for the organization case study represents the

access rights, hence policy type is represented as authorization.

GRANT_OR_DENY_PRIVILEGES_BASED_ ON_ROLE_WITH is a policy name,

POLICY_INPUTS consists of the user status. The employee roles, such as manager,

team member, and staff are represented as subjects. Operations create, read, write, and

delete a data files are represented as actions. Constraints validate the role of the input

user. If the user role is a manager then, then associated actions execute. If the user role

is not in the subject specification, then all the constraints returns false and the policy is

denied.


110

authorization

GRANT_OR_DENY_PRIVILEGES_BASED_ON_ROLE_WITH_

(POLICY_INPUTS)

POLICY_INPUTS

user_role

employee_role+

manager

‘team manager’

tech_staff

'technical member'

staff

'non-technical member'

unknown_role

STRING

policy_validation

validation_status+

policy_granted

‘policy granted’

policy_denied

‘policy denied’

policy_entities

subject

EMPLOYEE_ROLE

object

server_type

‘data server’

actions

create_operation

'create a data file'

read_operation

'read data from a data file '

write_operation 'write data to a data file '

delete_operation 'delete a data file'

constraints


grant_read_permission_constraint

STAFF


TECH_STAFF

grant_all_permissions_constraint


111

MANAGER

return

EMPLOYEE_ROLE+

STAFF

GRANT_READ_PERMISSION_CONSTRAINT

READ_OPERATION

POLICY_GRANTED

TECH_STAFF

GRANT_READ_AND_WRITE_PERMISSION_

CONSTRAINT

ACTIONS

READ_OPERATION

WRITE_OPERATION

POLICY_GRANTED

MANAGER

GRANT_ALL_PERMISSIONS_CONSTRAINT

ACTIONS

CREATE_OPERATION

READ_OPERATION

WRITE_OPERATION

DELETE_OPERATION

POLICY_GRANTED

UNKNOWN_ROLE

POLICY_DENIED Figure 29: Specification of Role Based Access Controls

Table 15 presented the execution results of the specification shown in Figure



inputs,. If the input is ‘technical member’, then read_operation and write_operation

actions are executed along with authorization policy granted message. Authorization

policy is denied if the input is ‘consultant’, which is an invalid input.


112

Table 15: Results of Role Based Access Controls Specification


user_role: non-technical member read data from a data file

policy granted

user_role: technical member read data from a data file

write data to a data file

policy granted

user_role: team manager create a data file

read data from a data file


delete a data file

policy granted

user_role: consultant policy denied

The GRANT_OR_DENY_PRIVILEGES_BASED_ON_ROLE_WITH_ policy

specification satisfies the following:

organization operations are assigned to the role of the employee;

at a given point, an employee should be either a manager or team member or

staff, but not all at a given point of time;

only a manager has the right to create and delete the organization records; and

staff members are clearly prohibited from create, update, and delete

operations.


113

6.2 Representation of Software Process Modeling Operations Using Secure

Descartes

6.2.1 Software Process Modeling

The sequence of events that are used to create, modify, and maintain software

is defined as software process modeling. An activity, products, role, and tool are the

basic entities of software process modeling [24]. An activity is a major event in a

software process. Each activity is carried out by a specific actor, and actors represent

different roles, such as designer, developer, and tester [24].

6.2.2 Representations of Software Process Modeling

Software process modeling languages were developed using programming

languages, object modeling, and state transitions [38]. The syntax and semantics of

programing languages are used to model the software process. Decentralized Process

enactment Language, JIL, and Little JIL are examples of programming language based

process modeling languages. Object process modeling uses features of object oriented

concepts, such as class, abstraction, instances and inheritance. The unified modeling

language for software project management and the process oriented modeling and

enactment of software developments are examples of object process modeling

language. The state transition model is used for modeling software processes in a state

based software process modeling language. The virtual reality process modeling

language, abstract process engine language, and abstract process engine language are

examples of state transition process modeling [38].


114

6.2.3 Specifying Software Process Modeling Policies Using Secure Descartes

In software process modeling, tasks are represented with an activity, each

activity has an actor who is responsible to perform the tasks. Activity conflicts occur

when one activity is trying to perform certain operations and another activity is trying

to prohibit from performing the same operation. The secure Descartes specification

language entities are used to specify the policies associated with software process

modeling as follows:

subject: represents the role of an actor in an activity;

object: represents software products in an activity;

actions: represents duties assigned to a role; and

constraints: validates actor role in an activity.

6.2.4 Case Study: Library Management System

A library management system was adopted from software process modeling

extensions to the Descartes specification language [21] to represent the secure policies

associated with the software process modeling. A library system consists of two

activities: design subsystem1 and design subsystem2. Each activity designs a

subsystem and will get reviewed by a review engineer using review subsystem1 and

review subsystem 2 as shown in Figure 30.


115

Figure 30: Library Management Process Model [21]

A secure Descartes specification for the library management system process

model as shown in Figure 31, DESIGN_OR_REVIEW_SUB

_SYSTEMS_BASED_ON_ROLE_WITH policy has POLICY_INPUTS, and

POLICY_CONFLICT_ DATA passed as arguments. POLICY_INPUTS consists of

user status. POLICY_CONFLICT_ DATA consists of policy conflict data and priority

of conflicted policy. In the library management system, the policy reads conflict data

from policy knowledge base, then checks if there is a conflict or not, using the

IS_TRUE primitive. The policy checks the user role and proceeds with associated

actions if there are no conflicts, policy compares priorities using LESS_ THAN

primitive then proceeds if the current policy priority is greater than the conflicted


116

policy priority, else the current policy waits until the conflicted policy completes its

actions.

Case 1: No policy conflict

If both design_engineer and design_reviewer are not trying to access the

services at the same time then is_it_a_policy_conflict returns false. If there is no

policy conflict, then ALLOW_DESIGN_OR_REVIEW_SUB_SYSTEMS_ BASED

_ON_ROLE_ WITH determine USER_ ROLE and executes associated ACTIONS.

Case 2: Policy conflict, current policy priority is greater than conflict policy

If both design_engineer and design_reviewer are trying to access the services

at the same time, then is_it_a_policy_conflict returns true. If there is a policy conflict,

then ALLOW_ DESIGN_OR_REVIEW_SUB_SYSTEMS_BASED_ON_ROLE_

WITH determine which policy executes first by comparing CURRENT_POLICY_

PRIORITY and CONFLICT_POLICY _PRIORITY using the Descartes primitive

GREATER_THAN. In this case, the primitive returns true and the current policy

executes first by determining ACTOR_ROLE and followed by associated ACTIONS.

Case 3: Policy conflict, current policy priority is less than conflict policy

If both design_engineer and design_reviewer are trying to access the services

at the same time then is_it_a_policy_conflict returns true. If there is a policy conflict

then ALLOW_DESIGN_OR_REVIEW_SUB_SYSTEMS_BASED_ON_ ROLE_


117

WITH determines which policy executes first by comparing CURRENT_

POLICY_PRIORITY and CONFLICT_POLICY_PRIORITY using Descartes

primitive LESS_THAN. In this case, primitive returns true and conflict policy

executes first and current policy waits until conflict policy is completed.

authorization DESIGN_OR_REVIEW_SUB_SYSTEMS_BASED ON

_ROLE_WITH_(POLICY_INPUTS)_ HAVING_(POLICY_CONFLICT_DATA)

POLICY_INPUTS

user_role

actor_role+

design_engineer

‘design engineer’

design_reviewer

'technical team member'

unknown_role

STRING

POLICY_CONFLICT_DATA

is_it_a_policy_conflict

BOOLEAN

conflict_policy_priority

INTEGER

policy_validation

validation_status+

policy_granted


policy_denied


policy_entities

subject

ACTOR_ROLE

object

software_products

‘input document for design and review’

actions

design_sub_system

‘design sub system’


118

review_sub_system

‘review sub system’

constraints


grant_design_permission_constraint

DESIGN_ENGINEER

grant_review_permission_constraint

DESIGN_REVIEWER


current_policy_priority

INTEGER


policy_conflicts_status+

policy_conflict

(IS_IT_A_POLICY_CONFLICT)_IS_TRUE

policy_no_conflict

(IS_IT_A_POLICY_CONFLICT)_IS_

FALSE 'no policy conflict'


policy_ resolution _status +

current_policy_executes_first

(CONFLICT_POLICY_PRIORITY)_LESS_ THAN_(

CURRENT_POLICY_PRIORITY)

‘current policy executes first’

conflict_policy_executes_first

(CONFLICT_POLICY_PRIORITY)_GREATER_ THAN_(

CURRENT_POLICY_PRIORITY)

‘conflict policy executes first’

return

POLICY_CONFLICTS_STATUS+

POLICY_NO_CONFLICT

ACTOR_ROLE+

DESIGN_ENGINEER


119

GRANT_ DESIGN


ACTIONS

DESIGN_SUB_SYSTEM

POLICY_GRANTED

DESIGN_REVIEWER

GRANT_ REVIEW


ACTIONS

REVIEW_SUB_SYSTEM

POLICY_GRANTED

UNKNOWN_ROLE

POLICY_DENIED

POLICY_CONFLICT

POLICY_ RESOLUTION _STATUS +

CURRENT_POLICY_EXECUTES_FIRST

CONFLICT_POLICY_EXECUTES_FIRST

Figure 31: Specification of Process Modeling Policies

Table 16 presented the execution results of the specification shown in Figure



inputs. If the input is ‘design engineer’ and is_it_a_policy_conflict is false, then

design_sub_system


120

action is executed along with an authorization policy granted message. If the input is

‘design engineer’ and is_it_a_policy_conflict is true, then the policy manager

compares current_policy_priority and conflict_policy_priority then which ever policy

has higher priority will get executed first. Authorization policy is denied if the input is

‘consultant’, which is an invalid input.

Table 16: Results of Process Modeling Policies


user_role: design engineer




design sub system


user_role: design engineer

is_it_a_policy_conflict:true



conflict policy executes first

user_role: consultant




Authorization policy denied

6.3 Translating Secure Descartes Policies into High Level Programming Code

6.3.1 Applications of Secure Software Development Life Cycle

Security demands are equally treated as functional requirements, hence security

aspects are being integrated into every stage of the software development life cycle,

denoted as secure software engineering. The security-aware software development life

cycle [39], Microsoft security development life cycle [40], and lightweight application

security process [41] are examples of secure software development tools.


121

Secure specification has various uses in a software development life cycle, such as a

specification automatically translated into design [42], generating high level code from

specification, automatically generating test cases, and test data from specification [43,

44, 45]. These uses reduce time and cost of overall software development process.

6.3.2 Secure Descartes Policies into High Level Programming Code

Java is a high level class based object oriented programming language and

consists of a rich set of language features to support functional, object-oriented,

concurrent, parallel, and real time systems. A major component of the Java

programming language is class, where a class is represented with a keyword ‘class’ and

consists of fields and methods [46, 47]. A class represents an entity, field represents

attributes of an entity, and method represents an operation of an entity. An example of

a Java class is represented as shown in the Figure 32.

car_operations is an abstract representation of a Java class to represent car

operations. The attributes of a car are represented as class fields, such as gearStatus and

fuelStatus. Methods helps to perform certain operations, such as moveFarward,

moveBackward and stopMoving with the help of class fields, main method returns the

final results.

class car_operations

{

// fields

gearStatus;

fuelStatus;

// methods


122

moveFarward( ) { … }

moveBackward( ) { … }

stopMoving( ) { … }

// main method

main ( )

{ return final results}

}

Figure 32: Example of Java Class Representation

The secure Descartes specification language policies can be translated into high

level Java classes. A case study from Section 6.1 is translated into a high level Java

class by the following steps.

Algorithm:

Step 1: Policy name is translated to a Java class name.

i.e., Class grant_or_deny_privileges_based on _role

Step 2: Policy entities, subject and object are translated to class fields.

i.e., manager =’team manager’, server_type=’data server’

Step 3: Policy actions are translated to class methods.

i.e., create_operation ( ) { ‘create a data file' }

Step 4: Policy constraints are translated to class methods which return a Boolean

value.

i.e., bool grant_read_permission ( user_role)


123

{ if (user_role==staff) return true; else false; }

Step 5: Policy return is translated to a main method in the class and policy inputs are

passed as arguments to the main method.

i.e main ( user_role)

{

if ( …)

policy_granted;

else

policy_denied;

}

The complete Java class equivalent to the role based access control case study

in Section 6.1 after applying the step by step process of the algorithm is shown in the

Figure 33. grant_or_deny _privileges_based_on_role is the name of the Java class.

Manger, tech_staff, staff, and server_type are the Java class fields. Create_operation,

read_operation, write_operation, and delete_operation are the Java class methods.

Grant_read_permission, grant_write_permission, and grant_all_permissions are

Boolean Java class methods. The Java main method returns policy results.

public class grant_or_deny_privileges_based_on_role { // policy subject static String manager ="team manager"; static String tech_staff ="technical team member"; static String staff="non-technical team member"; // policy object String server_type="data server"; // policy actions public static void create_operation () { System.out.println("create a data file"); }


124

public static void read_operation () { System.out.println("read data from a data file "); } public static void write_operation() { System.out.println("write data to a data file "); } public static void delete_operation() { System.out.println("delete a data file"); } // policy constraints public static boolean grant_read_permission(String user_role) { if (user_role==staff) return true; else return false; } public static boolean grant_read_and_write_permission(String user_role) { if (user_role==tech_staff) return true; else return false; } public static boolean grant_all_permissions(String user_role) { if (user_role==manager) return true; else return false; } // policy return public static void main (String[] args) { String user_role=args[0]; if (grant_read_permission(user_role)) { read_operation (); System.out.println("policy granted"); } else if(grant_read_and_write_permission(user_role)) {


125

read_operation (); write_operation(); System.out.println("policy granted"); } else if(grant_all_permissions(user_role)) { create_operation(); read_operation (); write_operation(); delete_operation(); System.out.println("policy granted"); } else { System.out.println("policy denied"); } } }

Figure 33: Java Class Equivalent to Role Based Access Control Case Study

The test data results are presented in Table 17 for various input test data after

executing grant_or_deny_privileges_based on _role Java classas shown in Figure 33

using a Java compiler. The Java class returns associated actions for the valid employee

role, such as staff has read only access, manager has all the access rights and program

returns policy denied for invalid employee role. Tester is not a valid role in the

organization hierarchy presented in Section 6.1.

Table 17: Results of Java Class

Test data/Input Test results/Output

user_role: non-technical team member read data from a data file

policy granted

user_role: technical team member read data from a data file



126

policy granted

user_role: team manager create a data file

read data from a data file


delete a data file

policy granted

user_role: tester policy denied

6.4 Summary

This chapter described applications of the extensions made to the Descartes

specification language to represent security policies. This chapter also presented case

study examples to provide applications of the secure entities and policies. Section 6.1

described representation of role based access controls with a case study associated with

an organization. Section 6.2 described the representation of secure policies associated

with software process modeling through a case study of the library management

system. Section 6.3 described the algorithm to translate secure policies into Java class.

The next chapter describes research results, research contributions, summary, and

future research work.


127

CHAPTER 7

7. SUMMARY AND FUTURE WORK

This chapter describes a summary of the dissertation, research results, research

contributions, and proposed future research work. Section 7.1 describes research

results and the achievement of the research objectives. Section 7.2 describes the

contributions of the research towards policy specification languages and the Descartes

specification language. Section 7.3 describes a summary of the dissertation. Section

7.4 describes future research directions.

7.1 Research Results and Achievement of the Research Objectives

The primary goal of this research effort was to create a secure policy

framework for the Descartes specification language that defines, analyzes, and

validates the policies effectively by adding required extensions to the existing work.

To achieve the primary goal, the following objectives were achieved.

I. The Descartes specification language, a formal specification language,

was analyzed and developed sample specifications by studying the

syntax and semantics of the Descartes specification language. Existing

extensions made to Descartes specification were reviewed.

II. The policy specification languages that support secure aspects of

software were identified, as well as the syntax and semantics of the


128

language were analyzed. The policy language features were reviewed

and validated.

III. Designed and implemented a framework to specify, analyze, and

validate secure polices, and defined roles and responsibilities of each

entity in the framework.

IV. New extensions were introduced to specify secure policies in the

Descartes specification language. The new primitives of authorization,

prohibition, delegation, obligation, and user-defined were added to

represent policy types. New keywords were added to specify policy

entities, subject, object, actions, constraints, and priority.

V. The agent based Descartes specification language processor was

extended to analyze, validate, and extend secure policies. The agent

based language processor was analyzed and validated with different

sample Descartes specification data, such as module based specification

and agent based specification. A new XML parser was developed to

parse the secure Descartes specification policies.

VI. The extended Descartes specification language was evaluated using

three methods: 1) based on language features [1]; 2) based on critical

security controls suggested by SANS [19]; and 3) based on IEEE Std

830-1998 characteristics of a good software requirement specification

[10]. In each method, the extended Descartes specification was

validated and compared against The Ponder [2], KAoS [3], Rei [4],


129

XACML [5], S-Promela [6], GBPF [7], SPL [8], and TPL [9]. An

evaluation metric was designed for comparing the secure Descartes

specification language with the existing policy specification languages.

VII. Three case studies were described and specified using the secure

Descartes to illustrate the applications of new extensions added. The

applications were; 1) representation of role based access controls, 2)

representation of domain specific policies, and 3) generation of high

level code.

7.2 Contributions of the Research

This section discusses the research contributions to policy specification

languages and the Descartes specification language.

Contribution towards policy specification languages:

Designed and developed a generic policy framework to represent,

analyze, and validate the secure policies. The Ponder [2], KAoS [3],

Rei [4], XACML [5], S-Promela [6], GBPF [7], SPL [8], and TPL [9]

policy specification languages were developed on various factors, such

as domain, web, network, syntax, semantics, predicate, and protocol.

Introduced a new policy type called “user-defined” to specify custom

needs and user defined policies.

The policy specification languages, Ponder [2], KAoS [3], Rei [4],

XACML [5], S-Promela [6], GBPF [7], SPL [8], and TPL [9], defined,


130

specified, analyzed, and validated the policies, but do not explore the

application of secure policies, such as representing domain specific

polices, representing role based access controls, and role of secure

policies in other phases of software development life cycle.

Contribution towards Descartes specification languages:

To specify and validate security policies in the Descartes specification

language, three concepts have been added in the form of extensions.

The added concepts are: 1) policy type; 2) policy entities; and 3) policy

manager operations.

The secure Descartes specification language introduced pre-defined

primitives to represent the policy types i.e., authorization, prohibition,

delegation, obligation, and user-defined.

The secure Descartes specification language introduced pre-defined

keywords to represent the policy entities i.e., subject, object, actions,

and constraints.

Policy conflicts validation and resolution of policy conflicts using

policy priorities.

Tool support implemented using XML parser in this research effort to

execute the secure Descartes specification language policies.


131

7.3 Summary

This section describes a summary of each chapter in the dissertation.

Section Chapter 1: Introduction

Chapter 1 described the motivation of the research, the problem statement, and

the research objectives along with the organization of the dissertation proposal.

Chapter 1 also described the representation of functional requirements and non-

functional requirements, relations among security requirements, security policy, and

security goal, as well as explained the role of formal methods in specification

languages.

Chapter 2: Related Work

Chapter 2 described the concepts of policy language frameworks, such as a

generic prototype of policy, policy components, and requirements of a policy

framework. Research results on the existing policy specification languages, Ponder

[2], KAoS [3], Rei [4], XACML [5], S-Promela [6], GBPF [7], SPL [8], and TPL [9],

was presented. Evaluation of these languages based on language/framework constructs

and SANS critical security controls were presented in Section 2.3. Section 2.4

introduced the Descartes specification language syntax, data structures, and semantics.

Extensions made to the Descartes specification language and sample specifications

developed using Descartes specification language were included.


132

Chapter 3: Research Objectives and Proposed Methodology

Chapter 3 discussed different kinds of policy types and policy combinations.

The secure policy framework consists of five components and each component has

specific roles and responsibilities.

Chapter 4: Secure Descartes - Security Extensions to the Descartes Specification

Language

Chapter 4 discussed extensions made to the Descartes specification language.

The secure Descartes specification language introduced four policy entities i.e.,

subject, object, actions and constraints, and five policy types i.e., authorization,

prohibition, delegation, obligation, and user-defined. Each extension was described

with case study examples.

Chapter 5: Evaluation of Extensions made to The Descartes Specification

Language

Section 5 discussed evaluation of extensions made to the Descartes

specification language. Secure Descartes has been evaluated based on four different

methods. The first method was based on policy language features, the second method

was based on critical security controls proposed by the SANS Institute. The third


133

method was based on IEEE std. 830-1998. The fourth method was based on an XML

language processor.

Chapter 6: Applications of the Extensions made to Descartes Specification

Language

Chapter 6 described applications of the extensions made to the Descartes

specification language. Three applications in the secure Descartes specification

language were described with case studies. In the first application, role based access

controls were specified using the secure Descartes specification language. In the second

application, secure policies associated with software process modeling were specified.

In the third application, the secure Descartes specification language policy was

translated into high level Java code.

Chapter 7: Summary and Future Work

Chapter 7 described research results, research contributions towards policy

specification languages and the Descartes specification language. Chapter 7 also

presented achievement of the research objectives and future research directions.

7.4 Future Research

Security extensions were added to the Descartes specification language to

support secure policies. This section discusses some future research directions from

this research effort.


134

Generating security test cases and test data from the secure Descartes

specification language polices;

Generating secure design models from the secure Descartes

specification language policies;

Specifying secure polices using the object-oriented Descartes

specification language extensions;

Development of policy conflict resolution methods for various

application environments; and

Update the existing language processor to generate automatic code

from secure polices;


135

REFERENCES

1. García, F. J., Martínez, G., Botía, J. A., and Skarmeta, A. G., “Representing

Security Policies in Web Information Systems,” Proceedings of the

14th International World Wide Web Conference, 2005.

2. Damianou, N., Naranker, D, Emil, L., and Morris, S., "The Ponder Policy

Specification Language," Proceedings of the International Workshop on

Policies for Distributed Systems and Networks, 2001, pp. 18-38.

3. Kagal, L., Finin, T., and Joshua, A., "A Policy Language for Pervasive

Computing Environment," Proceedings of the International Workshop on

Policies for Distributed Systems and Networks, 2003, pp. 63-74.

4. Kagal, L., Rei: A Policy Language for the Me-Centric Project, HP Labs

Technical Report, 2002.

5. Godik, S., Anderson, A., Parducci, B., Humenn, P., and Vajjhala, S., OASIS

eXtensible Access Control 2 Markup Language (XACML) 3, Technical Report,

2002.

6. Abbassi, R. and El Fatmi, S.G., "S-promela: An Executable Specification

Security Policies Language," Proceedings of the First International

Conference on Communications and Networking, 2009, pp. 1 - 8.

7. Koch, M., and Parisi-Presicce, F., “Describing Policies with Graph

Constraints and Rules,” Proceedings of the First International Conference on

Graph Transformation, 2002, pp. 223-238.


136

8. Riberio, C., and Guedes, P., “ An Access Control Language for Security

Policies with Complex Constraints,” Proceedings of Network and Distributed

System Security Symposium, 2001.

9. Herzberg, A., Mass, Y., Mihaeli, J., Naor, D., and Ravid, Y., “Access Control

meets Public Key Infrastructure, or: Assigning Roles to Strangers,”

Proceedings of IEEE Symposium on Security and Privacy, 2000, pp. 2-14.

10. ANSI/IEEE, IEEE std. 830-1998 Recommended Practice for Software

Requirements Specification, (ANSI/IEEE), 1998.

11. Urban, J. E., A Specification Language and Its Processor, Ph.D. Dissertation,

University of Louisiana at Lafayette, 1977.

12. van Lamsweerde, A., “Goal-oriented requirements engineering: A guided

tour,” Proceedings of Fifth IEEE International Symposium on Requirements

Engineering, 2001, pp. 249-262.

13. Glinz, M., "On Nonfunctional Requirements," Proceedings of 15th IEEE

International Conference on Requirements Engineering, 2007, pp. 15-19.

14. IEEE, Standard Glossary of Software Engineering Terminology. IEEE

Standard 610.12-1990.

15. Jacobson, I., Rumbaugh, J., and Booch, G., The Unified Software

Development Process. Reading: Addison Wesley, 1999.

16. Firesmith, D., “Specifying Reusable Security Requirements,” Journal of

Object Technology, 2004, pp. 61-75.

17. Hall, A., "Seven Myths of Formal Methods," Software, IEEE , 2002, pp.11-19.


137

18. Clarke, Edmund M., and Jeannette M. Wing. "Formal Methods: State of the

Art and Future Directions." Journal of ACM Computing Surveys, 1996, pp.

626-643.

19. SANS Critical Security Controls. Critical Security Controls for Effective Cyber

Defense: http://www.sans.org/critical-security-controls accessed June 12, 2015.

20. Sung, K. Y. and Urban, J. E., "Real-time Descartes: a Real-Time Specification

Language," Proceedings of the Third Workshop on Future Trends in

Distributed Computing Systems, 1992, pp. 79-85.

21. Wu, Y., A Methodology for Deriving a Booch Object Oriented Design from

Extensions to the Descartes Specification Language, MS Thesis, Arizona State

University, Dec, 1994.

22. Horne, B., Subburaj, V. H., and Urban, J. E., "Extensions to the Descartes

Specification Language for the Development of Real-time Object Oriented

Systems," Proceedings of the International Conference on Computing,

Networking and Digital Technologies, 2012, pp. 225-236.

23. Medina, M.A. and Urban, J.E., "An Approach to Deriving Reactive Agent

Designs from Extensions to the Descartes Specification Language,"

Proceedings of the Eighth International Symposium on Autonomous

Decentralized Systems, 2007, pp. 363-367.

24. Urban, J. E., Subburaj, V. H., and Ramamoorthy, L., "Extending the Descartes

Specification Language Towards Process Modeling," Proceedings of the


138

Federated Conference on Computer Science and Information Systems, 2011,

pp. 337-340.

25. Kanada, Y., “Taxonomy and description of policy combination methods,”

Proceedings of a Conference on Policies in Distributed Systems and Networks,

2001, pp. 171-184

26. Wei, Q. and Adams, C., "Exploring User-to-Role Delegation in Role-Based

Access Control," Proceedings of the Eighth World Congress on Management

of eBusiness, 2007, pp. 21-31.

27. Bai, Q. and Zheng, Y., "Study on the Access Control Model," Proceedings of

the Cross Strait Quad-Regional Conference on Radio Science and Wireless

Technology, 2011, pp. 830 – 834.

28. Subburaj, V. H. and Urban, J. E., “An Agent Based Formal Specification

Language Processor,” Proceedings of the Third International Conference on

Informatics Engineering and Information Science, 2014, pp. 181-190.

29. Sabharwal, C. L., "Java, Java, Java," IEEE Potentials, 1998, pp. 33-37.

30. ANTLR , Tool for Language Recognition : http://www.antlr.org/, June, 2015.

31. XML Parsing , https://msdn.microsoft.com/en-us/library/bb387059.aspx, June,

2015.

32. Shin M.E. and Gail-Joon A., "UML-Based Representation of Role-Based

Access Control," Proceedings of the IEEE 9th International Workshop on

Enabling Technologies, 2000, pp. 195–200.

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4285290

http://www.antlr.org/

https://msdn.microsoft.com/en-us/library/bb387059.aspx


139

33. Gail-Joon A. and Shin M.E., "Role-Based Authorization Constraints

Specification Using Object Constraint Language," Proceedings of the 10th

IEEE International Workshops on Enabling Technologies, 2001, pp. 157–162.

34. Thion R. and Coulondre S., "Representation and Reasoning on Role-Based

Access Control Policies with Conceptual Graphs." Proceedings of the 14th

International Conference on Conceptual Structures, 2006, pp. 427-440.

35. Toahchoodee M., Ray I., and McConnell R.M., "Using Graph Theory to

Represent a Spatio-Temporal Role-Based Access Control Model,"

International Journal of Next-Generation Computing, 2010.

36. Sandhu, R. S., Role-based access control. Advances in computers, 1998, pp.

237-286.

37. Hu, V. C., Kuhn, D. R., and Ferraiolo, D. F., Attribute-based access

control. Computer, 2015, pp. 85-88.

38. Ramamoorthy, L., Extensions to the Descartes Specification Language for

Software Process Modeling, MS Thesis, Texas Tech University, 2011

39. Talukder A.K., Maurya V.K., Santhosh B.G., Jangam E., Muni S.V., Jevitha

K. P., Saurabh S., and Pais A.R., "Security-Aware Software Development Life

Cycle- Processes and Tools," Proceedings of the International Conference on

Wireless and Optical Communications Networks, 2009, pp. 1-5.

40. Howard M. and Lipner S., "The Security Development Life-cycle: SDL: A

Process for Developing Demonstrably More Secure Software," Microsoft

Press, 2006.

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4939175


140

41. OWASP. Comprehensive, Lightweight Application Security Process,

http://www.owasp.org, 2006

42. Gajski, D. D., Zhu, J., Domer, R., Gerstlauer, A., and Zhao, S., “SPECC:

Specification Language and Methodology”, 2000.

43. Chen, M., Qiu, X., Xu, W., Wang, L., Zhao, J., and Li, X., “UML Activity

diagram-based Automatic Test Case Generation for Java Programs. The

Computer Journal, 2009, pp. 545-556.

44. Nebut, C., Fleurey, F., Le Traon, Y., and Jezequel, J. M., “Automatic Test

Generation: A use case Driven Approach,” IEEE Transactions on Software

Engineering , 2006, pp. 140-155.

45. Kalva, V., An Improved Descartes Specification Language Interpreter. MS

Thesis, Texas Tech University, 2011.

46. Gosling, J., The Java Language Specification. Addison-Wesley Professional,

2000.

47. Gosling, J., and McGilton, H., The Java Language Environment. Sun

Microsystems Computer Company, 1995.


141

APPENDIX

The language processor to execute security policies in the secure Descartes

specification language was developed using Java, ANTLR, and an XML parser.

Implementation details of the XML parser, implementation constraints, and test bed

configurations are discussed in this Appendix.

Implementation Details

The implementation details of important modules are presented in the Java

programming language. The below source code describes creating tree structure for

policy entities, policy manager operations, and traversing tree to validate the

constraints. Java HashMap class was used to store the tree nodes. Analysis and

synthesis trees of the secure Descartes specification are stored in different Java

HashMap classes. The policy manger operations uses various Descartes specification

language primitives, such as EQUAL, LESS_THAN, GREATER_THAN, and

IS_TRUE. ANTLR grammar identifies the equivalent Java programming operators,

and process the primitive and resulting value is stored in Java HashMap class. XML

parser process the synthesis tree and verify the match node values in Java HashMap

class.

public ArrayList<String> build_Policy_Entities_Tree(String[] aryLines,int startNode,HashMap<String,String> policy_inputs){ HashMap<String, HashMap> policy_entities = new HashMap<String, HashMap>(); HashMap<String,String> policy_entities_data = new HashMap<String,String>();


142

ArrayList<String> final_matched_policies = new ArrayList<String>(); int policy_inputs_start_node = startNode; int policy_inputs_end_node = 0; HashMap<Integer,HashMap> policy_entiti_starting_tree1 = new HashMap<Integer,HashMap>(); HashMap<Integer,HashMap> policy_entiti_starting_tree2 = new HashMap<Integer,HashMap>(); HashMap<String,HashMap> policy_entities_final_nodes = new HashMap<String,HashMap>(); int i = policy_inputs_start_node ; int find_last_nodes=0; int number_tabs = 0; for(;i<aryLines.length;i++) { String[] parts = aryLines[i].split("\t"); number_tabs = parts.length; int last_node_position = parts.length-1; boolean end_node = false; String node = parts[last_node_position]; if(parts.length==2) { policy_inputs_end_node = i-1; break; } String[] parent_node = aryLines[i-1].split("\t"); int last_parent_node_position = parent_node.length-1; HashMap<String,String> policy_entiti_starting_chid_tree = new HashMap<String,String>(); policy_entiti_starting_chid_tree.put(parent_node[last_parent_node_position], node); policy_entiti_starting_tree1 = new HashMap<Integer,HashMap>(); policy_entiti_starting_tree1.put(number_tabs, policy_entiti_starting_chid_tree); policy_entiti_starting_tree2.put(i, policy_entiti_starting_tree1); if(number_tabs > find_last_nodes ) { find_last_nodes = number_tabs; } } for(Map.Entry m:policy_entiti_starting_tree2.entrySet()){ for(Map.Entry m1:((HashMap<String,String>)m.getValue()).entrySet()){


143

if(find_last_nodes == Integer.parseInt(m1.getKey().toString()) ) { for(Map.Entry m2:((HashMap<String,String>)m1.getValue()).entrySet()){ HashMap<String,Boolean> policy_entiti_matching_status = new HashMap<String,Boolean>(); policy_entiti_matching_status.put(m2.getValue().toString(), false); policy_entities_final_nodes.put(m2.getKey().toString(),policy_entiti_matching_status ); } } } } ArrayList<String> temp_policy_input = new ArrayList<>(); int index = 0; for(Map.Entry m3:policy_inputs.entrySet()){ temp_policy_input.add("("+m3.getKey().toString().toUpperCase() +m3.getValue().toString().toUpperCase() +")"); } for(Map.Entry m4:policy_entities_final_nodes.entrySet()){ for(Map.Entry m5:((HashMap<String,Boolean>)m4.getValue()).entrySet()){ if(temp_policy_input.contains(m5.getKey().toString())) { HashMap<String,Boolean> policy_entiti_matching_status = new HashMap<String,Boolean>(); policy_entiti_matching_status.put(m5.getKey().toString(), true); policy_entities_final_nodes.put(m4.getKey().toString(), policy_entiti_matching_status); final_matched_policies.add(m4.getKey().toString()); } } }


144

return final_matched_policies; } public HashMap<String,String> build_Policy_validation_Tree(String[] aryLines,int startNode){ HashMap<String, HashMap> policy_entities = new HashMap<String, HashMap>(); HashMap<String,String> policy_entities_data = new HashMap<String,String>(); int policy_inputs_start_node = startNode; int policy_inputs_end_node = 0; HashMap<Integer,HashMap> policy_entiti_starting_tree1 = new HashMap<Integer,HashMap>(); HashMap<Integer,HashMap> policy_entiti_starting_tree2 = new HashMap<Integer,HashMap>(); HashMap<String,String> policy_entities_final_nodes = new HashMap<String,String>(); int i = policy_inputs_start_node ; int find_last_nodes=0; int number_tabs = 0; for(;i<aryLines.length;i++) { String[] parts = aryLines[i].split("\t"); number_tabs = parts.length; int last_node_position = parts.length-1; boolean end_node = false; String node = parts[last_node_position]; if(parts.length==2) { policy_inputs_end_node = i-1; break; } String[] parent_node = aryLines[i-1].split("\t"); int last_parent_node_position = parent_node.length-1; HashMap<String,String> policy_entiti_starting_chid_tree = new HashMap<String,String>(); policy_entiti_starting_chid_tree.put(parent_node[last_parent_node_position], node); policy_entiti_starting_tree1 = new HashMap<Integer,HashMap>();


145

policy_entiti_starting_tree1.put(number_tabs, policy_entiti_starting_chid_tree); policy_entiti_starting_tree2.put(i, policy_entiti_starting_tree1); if(number_tabs > find_last_nodes ) { find_last_nodes = number_tabs; } } for(Map.Entry m:policy_entiti_starting_tree2.entrySet()){ for(Map.Entry m1:((HashMap<String,String>)m.getValue()).entrySet()){ if(find_last_nodes == Integer.parseInt(m1.getKey().toString()) ) { for(Map.Entry m2:((HashMap<String,String>)m1.getValue()).entrySet()){ policy_entities_final_nodes.put(m2.getKey().toString(), m2.getValue().toString()); } } } } return policy_entities_final_nodes; }


146

Implementation Constraints

Java and XML were the two programming languages used for the implementation.

Text files were used for input specification and output generation. The major

implementation constraints were associated with either programming languages or

files sytems. Below mentioned are the noted constraints in the implementation phase.

Descartes compiler supports Java 6 and higher versions, as most of the features

were developed based on Java 6.

Used the Java runtime environment 7 (JRE 7) for execution of the secure

specifications.

Input and output modules support only text based file formats and do not

support other file systems, such as web, client-server, and distributed file

formats.

Policy definitions were predefined. The secure Descartes specification

language compiler and implementation framework needs to be updated

whenever there is a change in policy definitions/syntax/semantics of a secure

policy.

Tested Bed Specification

Various testing methodologies were used to test the implementation framework, such

as unit testing, module testing, and functional testing. The following approaches were

used in testing: Unit testing to test code level, module testing to test the compiler


147

modules with the Java run time environment, and functional testing to test the secure

policies. The test bed specification that was used for all the testing is as shown below.

Testing was carried on Windows 7, 64 bit operating system.

Eclipse IDE for Java Developers(Version: Indigo Service Release 1,

Build id: 20110916-0149) was used for developing and testing the code.

Code has been developed and tested in Java 6 and Java runtime

environment 7 (Jre7).

a secure policy framework for the descartes specification

Documents