formal specification of software architecture … pdfs/formal specification... · for different...

FORMAL SPECIFICATION OF SOFTWARE ARCHITECTURE DESIGN TACTICS FORTHE SECURITY QUALITY ATTRIBUTE

Andrew Michael WyethB.S., University of Victoria, Victoria, Canada, 2002

PROJECT

Submitted in partial satisfaction ofthe requirements for the degree of

MASTER OF SCIENCE

in

COMPUTER SCIENCE

at

CALIFORNIA STATE UNIVERSITY, SACRAMENTO

SPRING2009

c 2009

Andrew Michael WyethALL RIGHTS RESERVED

11


A Project

by

Andrew Michael Wyeth

Approved by:

, Committee ChairDr. Cui Zhang

Date I

Dr. William Mitchell

Date

, Second Reader

Ž4S ) 3p

iii

s-// 3 / >V--C8

V�k' - yu�v'�V

Student: Andrew Michael Wyeth

I certify that this student has met the requirements for format contained in the University format

manual, and that this project is suitable for shelving in the Library and credit is to be awarded for

the Project.

IDr. Cui Zhang, Graduate Coordinator

Department of Computer Science

iv

Date

Abstract

of


by

Andrew Michael Wyeth

Designing the software architecture of a system is an important step in creating a systemthat will meet both the functional and non-functional requirements. Bass, Clements andKazman in "Software Architecture in Practice" propose a method to use design tactics tocreate the Software Architecture of a system. For each quality attribute a set of designtactics were developed. Security is one such quality attribute.

The security requirements of a system must be taken into account from the start. Addingsecurity adversely affects, the other quality attributes so it is difficult to add security to aproduct after it has been designed. When defining the security tactics of a system, thereis currently no way to formally prove the implementation of the tactics. There is asemantic gap between the software architecture, high level design and implementation ofa system. One way to bridge this gap is to use formal specifications. The formalspecifications can be used as a template when designing new systems and to analyze thearchitecture more rigorously.

This project provides a Z specification for the Software Architectural Tactics for theSecurity Quality Attribute. A model of a system is created and each tactic is defined withrespect to the model. Each tactic is independent however, the system encompasses all therequired functionality for all the tactics.

Committee ChairDr. Cui Zhang

:f/ / 31 -

v

Date /

ACKNOWLEDGMENTS

I would like to thank my wife, Greta and my son Rowan for all their love and support in helpingme to complete this project. I would also like to thank my advisor, Dr. Cui Zhang for all of herguidance and support and finally, I would like to thank my second reader, Dr. William Mitchellfor all his help.

vi

TABLE OF CONTENTSPage

Acknowledgments................................................................................................................... vi

List of Figures ......................................................... viii

Chapter

1. INTRODUCTION............................................... I

2. BACKGROUND AND RELATED WORK ....................................................... 3

3. FORMAL SPECIFICATION OF THE DESIGN TACTICS ............................................. 9

3.1 Construction of Tactic Specification ............................ ............................. 9

3.2 Base System Model Specification ........................ ................................ 10

3.3 Authentication Tactic Model Specification ........................................................ 14

3.4 Authorization Tactic Model Specification ........................................................ 19

3.5 Data Confidentiality Tactic Model Specification ................................................. 25

3.6 Data Integrity Tactic Model Specification ........................................................ 29

3.7 Auditing Tactic Model Specification ................................... ..................... 33

3.8 Intrusion Detection Tactic Model Specification ................................................... 40

3.9 Limit Access, Limit Exposure and Availability Tactics ....................................... 44

3.10 Combined Authorization and Authentication Model Specification . . 46

4. DISCUSSION.................................................................................................................. 50

4.1 Conclusion ........................................................ 50

4.2 Applications and Uses ........................................................ 50

4.3 Future Work ........................................................ 52

Appendix A. Base System Model Specification ........................................................ 55

Appendix B. Authentication Tactic System Model Specification . ....................................... 63

Appendix C. Authorization Tactic System Model Specification . ........................................ 74

Appendix D. Data Confidentiality Tactic System Model Specification .............................. 99

Appendix E. Data Integrity Tactic System Model Specification ....................................... 108

Appendix F. Auditing Tactic System Model Specification . ............................................... 118

Appendix G. Intrusion Detection Tactic System Model Specification .............................. 133

Appendix H. Combined Authorization and Authentication System Model Specification. 150

References ........................................................ 183

vii

LIST OF FIGURES

Page

1. Figure 1. Construction of Tactic Specification ................................................ 10

2. Figure 2. Base System Specification ........... 1..................................... 1

3. Figure 3. Process Specification ................................................ 12

4. Figure 4. Add User Specification ................................................ 13

5. Figure 5. Change File Specification ................................................ 14

6. Figure 6. Revised System Specification to Include Authentication ............................... 15

7. Figure 7. Authenticate User Specification ................................................ 16

8. Figure 8. Add Authentication Specification .................. .............................. 17

9. Figure 9. Revised Add User and Change File Specifications to Include Authentication 18

10. Figure 10. Revised System Specification to Include Authorization .20

11. Figure 11. Add User ACM Specification .22

12. Figure 12. Revised Add User Specification to Include Authorization .23

13. Figure 13. Revised Start Process Specification to Include Authorization .24

14. Figure 14. Revised System Specification to Include Data Confidentiality .26

15. Figure 15. Revised Read File Specification to Include Data Confidentiality .27

16. Figure 16. Revised Add File Specification to Allow Multiple Secrets per Filename .... 27

17. Figure 17. Revised Change File Specification to Include Data Confidentiality .28

18. Figure 18. Revised File Properties Specification to Include Data Integrity .30

19. Figure 19. Check Integrity Specification .31

20. Figure 20. Revised Read File Specification to Check Data Integrity .32

21. Figure 21. Revised System Specification to Include Auditing .34

22. Figure 22. Log Element Specifications .35

23. Figure 23. Change in File and Process Properties Function Specifications .36

24. Figure 24. Revised Read File Specification to Include Auditing Using Lets .37

25. Figure 25. Revised Read File Specification to Include Auditing with Local Variables in the

Schem a Declaration................................................................................................................ 38

26. Figure 26. Revised StopProcess_ProcesslDNotExists Specification to Include Auditing 39

27. Figure 27. Revised System Specification to Include Intrusion Detection .41

28. Figure 28. IDSAlert, IDSNoAlert and IDS_System Specification .42

viii

29. Figure 29. Revised Add User Specification to Include Intrusion Detection ......... ......... 43

30. Figure 30. Combined Authorization and Authentication System Specification ............. 47

31. Figure31.AddAuthenticationACMSpecification ......................................................... 48

ix

I

Chapter 1

INTRODUCTION

An important step in creating a system that meets the users functional and non-functional

requirements is the design of the software architecture. During this phase of

development, special attention must be paid to the non-functional requirements. Bass,

Clements and Kazman [2] create that emphasis through the use of quality attributes, those

requirements on the system that dictate the software architecture of the system. To

achieve those qualities, the authors recommend the use of software architecture design

tactics. Software architecture design tactics are high level design decisions. Each design

tactic will satisfy one or more quality attributes and may adversely affect others [2].

Security is one set of quality attributes. As most applications work in an online

environment, they must be secure to prevent compromise of the entire system [2]. There

are three classes of tactics for security. The first class is Resisting Attacks which consists

of: Authenticate Users, Authorize Users, Maintain Data Confidentiality, Maintain Data

Integrity, Limit Exposure, and Limit Access. Second, Detecting Attacks which consists

of using Intrusion Detection Systems. Lastly, Recovering From Attacks which consists

of Auditing and Restoration. However, when defining the security tactics of a system,

there is currently no way to formally prove the implementation of the tactics. One way to

establish confidence in the implementation of the tactics is to use formal methods to

define the system. The formal definition can be used to show that it achieves the tactics

[2].

2

Formal methods are mathematical logic based procedures used to precisely define system

requirements. These definitions enable us to rigorously analyze the system to prove

certain properties, such as the confidentiality of the systems data. To accomplish these

procedures, formal languages are used. A formal language is a language based on a

mathematical model that can be used in formal methods. One such language is Z which

is based on typed set theory [5]. Z is a language specifically designed to describe

computer system models and as such is a very concise and powerful way to describe the

high level constructs of a system.

The formal analysis to prove a system correctly implements the various security tactics

has two parts. First, the security tactics need to be formally defined. Second, the

proposed system must be formally defined and then shown to be equivalent to the

security tactic definition. This project will define the security tactics with respect to a

generic system.

The Software Architectural Security Tactics need to be defined with respect to a system

so the first step in this project is to define the basic but generic system model. Then, each

tactic will be defined in natural language and then formally as an extension to the basic

system. The new extended system will be proven to be consistent with the original

system. Finally, all the tactics will be combined to show the formal specification of a

system model that has all the security quality attributes.

3

Chapter 2

BACKGROUND AND RELATED WORKS

In 1996 Shaw and Garlan in their book "Software Architecture Perspectives on an

Emerging Discipline" show the feasibility and usefulness of writing formal specifications

for different aspects of Software Architectural components or patterns [12]. This

formalization is an important step in turning Software Architecture into an engineering

discipline. Formal specifications allow the architecture to be rigorously modeled,

analyzed and reused. Modeling is important to determine the feasibility of the system or

to determine which of several models is the best option. Analysis of the formal

specifications leads to a deeper understanding of the foundations of Software

Architecture [12]. This analysis will lead to a "theory of software architecture" [12].

Also, having formal specifications of various software architectures allows for easy

reuse; the template of the architecture can be used as a starting point for the design [12].

Shaw and Garlan in [12] demonstrate the above principles through three examples written

in Z. First, they formally define the architecture of an oscilloscope, a tool for analyzing

wave patterns and show how it implements the pipes and filters architectural style. This

shows how a simple architecture can be written concisely and precisely and at the right

level of abstraction.

Second, they define the pipes and filters architectural style and show how building on it

would be easier than defining the oscilloscope from scratch. Also, in defining the pipes

4

and filters architectural style Shaw and Garlan [12] emphasize how an architectural style

needs to be general and abstract enough to capture the essence of the style without

enforcing too many constraints. They also show how easily a refinement to an

architectural style can be defined. By adding a single constraint to the system they

convert the pipes and filters architectural style to the pipeline style (where each filter is

connected to only one input and one output pipe).

Finally, Shaw and Garlan [12] define the implicit invocation architectural style. The

formalization of implicit invocation emphasized the need for the correct level of

abstraction in the architecture. Specifically, it is not defined whether the events

generated in the implicit invocation architectural style can contain data but, depending on

the system being created, it might be necessary for the events to carry data. When the

style is refined, one of the refinements will be to define exactly what an event is.

Since Shaw and Garlan published their book, significant advances have been made in

Software Architectural Methodologies. During the architectural design of a system, the

focus is on achieving the required quality attributes. Quality attributes are the properties

of a system that do not affect what it does, only how it performs its task. Security,

modifiability, usability, performance and reliability are all quality attributes [2]. The

software architecture is essential to obtaining the quality attributes for any given system

because it is the first place in the design cycle that quality attributes can be addressed.

5

The quality attributes that a system needs are defined through scenarios. A scenario

consists of a source, a stimulus, an artifact, a response and a response measure [2].

The source is the initiator of the request, the stimulus is the request itself, the artifact is

the portion of the system that is accessed, the response is what the system should do and

the response measure is how to determine to what degree the system achieves the quality

attribute. Once the quality attribute requirements have been defined for the system

through the scenarios, they can be achieved through the use of software architectural

tactics [2].

Software architectural tactics are design decisions [2]. Each tactic affects one or more

quality attributes. For example, adding confidentiality to the systems data adds to the

security of the system but reduces performance as the data must be decrypted before use.

The selection of the architectural tactics for a system will help determine its architecture

as the tactics will constrain what architectures are possible [2].

Security, as previously stated, is a system quality. There are various tactics to achieve the

different types of security that systems require. According to [2], the tactics can be

categorized based on whether they resist attacks, detect attacks or recover from attacks.

The tactics that resist attacks are: authenticate users, authorize users, maintain data

confidentiality, maintain integrity, limit exposure and limit access. The first four tactics

correspond to their associated intuitive definitions. The idea of limit exposure is to

6

provide only a few services on each host, like not allowing the President and Vice-

President of a company to fly on the same jet. The idea of limit access is to restrict what

external entities can access the system, like a lock for a door.

While formal methods have been associated with software architecture since the mid-

nineties, formal methods have been associated with security for even longer. Since

computer security became an issue, people have looked at formal models of the security

of a system. This is in part because without a formal definition of security, there is no

way to precisely determine if a system is secure or not [6].

Network security is one area that has seen a significant amount of research into

formalizing and analyzing its security properties. There are two complementary

approaches to analyzing security protocols, determining the protocol requirements and

proving the correctness of an existing protocol [4] [7]. CSP (Communicating Sequential

Processes) is used to define authentication and confidentiality, two aspects of security,

over a network. In doing so they explore the various types of authentication that are

available for communication such as sender authentication and intent to send a message

[4]. Z is used to define the Needham-Schroeder Public Key Protocol and prove it is

insecure. This work is based on a flaw in the protocol. The Needham-Schroeder Public

Key Protocol is then fixed and proved correct [7].

7

Another avenue of research is specifying the security components required to meet the

Common Criteria. The Common Criteria is an international standard security evaluation

system which defines several levels of security that systems can achieve [3]. The

Common Criteria consists of 251 different security requirements written in natural

language [8]. Morimoto et al. [8] have written Z templates for all 251 elements. This

enables people to use the templates and makes it easier to achieve the desired Common

Criteria security level.

Specifying the properties and models for aspects systems rather than for the whole

system is another approach. Abdallah and Khayat [1] create a Z specification for role

based access control models (RBAC). RBAC is a model that controls access based on

what role or roles the user is currently employing.

Song et al. [13] create a system model and prove that an intrusion detection system can

detect unauthorized access to the password file. Using ACL2 (a formal language), a unix

like system model is defined and logging is explicitly added. Then the intrusion

detection systems detection rules are defined and they are proved to be correct. The

approach this paper uses is similar to the approach Song et al. took in proving the

correctness of their system.

Z is a formal language based on typed set theory [5]. It is a good language to describe

software architectures because it "allows a concise expression of the functional properties

8

of computer systems" [5]. There are also several powerful tools which work with Z.

There are programs that convert Object Z to Java or Spec # [9] [11] [10] and a tool which

allows integration of Z specifications into Microsoft Word documents [16].

9

Chapter 3

FORMAL SPECIFICATION OF THE DESIGN TACTICS

3.1 Construction of Tactic Specification

The specification for each design tactic is built upon a simple base system model which is

explained in Section 3.2. Each tactic's model except intrusion detection is built upon the

base system model. Intrusion detection is built upon the auditing system model. The

operations for each design tactic build upon the extended system model and modify the

base system operations. Figure 1 shows how the tactics will be constructed. Starting

with the base system model, the base system operations are specified and then each tactic

is built upon the model and operations below it. The integrity tactic does not extend the

base system model, it only refines the specification.

AuthenticationOperations andModifications

AuthorizationOperations andModifications

ConfidentialityOperations andModifications

Intrusion DetectionOperations andModifications

Auditing IntrusionOperations and Detection ModelModifications Extensions

Authentication Authorization Confidentiality Integrity Auditing ModelModel Model Model Operations and Extins

Extensions Extensions Extensions Modifications

Base System Operations

Base System Model

Figure 1. Construction of Tactic Specification

There is extensive use of the Z formal language, for a good introduction to Z see [5] and

[14].

3.2 Base System Model Specification

This section presents the base system model specification. The full specification is in

Appendix A.

The base system is a very simple, high level definition of a software system. The system

is described in terms of an operating system as this makes it easier to understand and

provide a ready source of examples. The specification can be applied to applications or

10

11

other systems by a simple mapping. The base system consists of three elements: a

userlist, a filelist, and a processlist as shown in Figure 2. USER, FILENAME, and

FILEPROPERTIES are undefined sets, they depend on the system to be implemented.

-SYSTEMfilelist: FILENAMiE,-+*FILEPROPERTIESuserlist: P USERprocesslist: P PROCESS

VpI, p2 : processlist * p1 .process _id = p2.process id X p1 =p2Vp : processlist * pfilename E dom flelist A p. owner E user!ist

Figure 2. Base System Specification

The filelist is a partial function from a filename to a file property. Thus, each filename is

unique in the system and filenames do not have to map to a file property.

The basis of the process is that it is a file run by a user. Figure 3 shows the process

specification, it consists of the user running the process, the file being run, the current

state of the process and the processes id. PROCESSID and PROCESSSTATE are

undefined sets. The PROCESSSTATE represents the current state of the process. As

specified in Figure 2, the system requires the processid is unique and that the file being

executed and the user running the process both exist. This model does not consider the

sharing of resources, each operation is considered atomic. If concurrency is required then

the model would need to be extended to include a concurrency mechanism.

12

PROCESS

filename: FILENAME

owner: USER

process id: PROCESSID

state: PROCESS-STATE

Figure 3. Process Specification

There are many operations on even this simple system: adding and deleting users; adding,

deleting, reading, and changing files; starting, stopping and changing processes. Two

representative operations are discussed here: AddUser and ChangeFile.

The AddUser operation, shown in Figure 4, consists of two possible cases: AddUserOK

- a user is successfully added to the set of users and AddUserExists - the user already

exists so an error is returned.

13

AddUserOK

ASYSTEM

newUser?: USER

r! : Response

newUser? E userlist

userlist' = userlist U {newUser?}r! = OK

_AddUserExistsESYSTEM

newUser?: USER

r!: Response

newUser? E userlist

r! = UserExists

AddUser AddUser OK V AddUser Exists

Figure 4- Add User Specification

ChangeFile, shown in Figure 5, is slightly more complicated but still consists of two

cases: ChangeFileOK, where the filelist mapping is changed to reflect the new file

properties (A ED B is the relational override operation where the mappings in A are

overwritten by the mappings in B.) ChangeFileNotExists returns an error because the

file does not exist.

14

jChangeFileOKASYSTEM

filename?: FILENAME

properties?: FILE PROPERTIES

r!: Response

filename? E domfilelist

filelist'= filelist e {fflename?-* properties?}

r! = OK

iChangeFile NotExists

ESYSTEM

filename?: FILENAME

properties?: FILE PROPERTIES

r!: Response

filename? ( domfilelist

r! = FileNotExists

ChangeFile - ChangeFileOK V ChangeFileNotExists

Figure 5. Change File Specification

This specification describes the parts of a system that are monitored or extended to

provide the various security tactics. The system as defined here has no security

properties whatsoever, so any entity can manipulate the system.

3.3 Authentication Tactic Model Specification

This section presents the authentication tactic model specification. The full specification

is in Appendix B.

15

Authentication is the first security tactic to be added to the base system. Authentication

is the act of verifying a users identity [3]. In software systems, authentication is achieved

by having the user provide their name and a piece of information that uniquely identifies

them [3]. This unique information is provided through the

AUTHENTICATIONCONTROL set. Thus, the base system is extended to include a

partial function from USER to an AUTHENTICATIONCONTROL set as shown in

Figure 6. Note that each user can have any number of authentication controls and thus

there can be users in the userlist that are not authenticated. This means the creation of a

user is a two step process, first the user is created, then the user is mapped to an

authentication control. This allows the system to provide separation of concerns, which

is one of the secure design principles [3].

SYSTEMfilelist: FJLENAMiE-+*FILE-PROPERTIESuserlist: P USERauthenticated: USER -++ PA UTHENTICA TIONCONTROLprocesslist: P PROCESS

Vp 1, p2 : processlist *pl .processid = p2.process-id X pl =p2Vp : processlist * pfilename E dom filelist A p. owner E userlistdom authenticated 5 userlist

Figure 6. Revised System Specification to Include Authentication

There are three new operations for the authenticated system. The first, consists of two

parts: AuthenticateUser and AuthenticateUserFail. AuthenticateUser, shown in

Figure 7, provides the authentication tactic. It verifies that a user is allowed to access the

16

system by making sure the username, authenticationcontrol pair is in the authenticated

function. The second, AuthenticateUserFail, also shown in Figure 7, returns the

appropriate error message if the username, authentication control pair does not exist.

-Authenticate-User_.ESYSTEM

u?: USERac?: A UTHENTICA TIONCONTROLr!: Response

ac? E authenticated(u?)r! = OK

_AuthenticateUserFailESYSTEMu?: USERac? A UTHENTICA TIONCONTROLr!: Response

ac? X authenticated(u?)r! = InvalidUserAuthenticationControlPair

Figure 7. Authenticate User Specification

The other two new operations added are AddAuthentication and DeleteAuthentication.

They control how the authentication set is modified. Figure 8 shows AddAuthentication.

AddAuthenticationOK confirms the user exists before adding the user,

authenticationcontrol pair to the authenticated set. If the user doesn't exist,

AddAuthentication NotExists returns an error. AddAuthentication checks the user

17

adding the authentication pair is authenticated, then attempts the add.

DeleteAuthentication is similar.

_AddAuthentication_OK_ASYSTEMuser?: USERac? : A UTHENTICA TIONCONTROLr! : Response

user? e userlist

authenticated'(user?) = authenticated(user?) U {ac?}r! =OK

_AddAuthenticationNotExistsESYSTEMuser?: USERac? : AUTHENTICATIONCONTROLr! : Response

user? X userlist

r! = UserNotExists

AddAuthentication - (Authenticate_User A (AddAuthenticationOK VAddAuthenticationNotExists)) V AuthenticateUserFail

Figure 8. Add Authentication Specification

AddAuthentication shows how all the operations on the system need to be modified to

add authentication, the user performing the task must first be authorized, then the

operation is performed or the authorization fails. Figure 9 shows how AddUser and

ChangeFile have been modified.

18

Add User - (AuthenticateUser A (AddUserOK v AddUserExists))

V AuthenticateUserFail

ChangeFile - (Authenticate User A (ChangeFile_OKV ChangeFileNotExists))


Figure 9. Revised Add User and Change File Specifications to Include Authentication

There are several important features that this specification emphasizes. First, the user is

authenticated and then the action is performed, this prevents covert channels where

different responses from the system can be used to determine properties of the system.

Second, the system as specified performs complete mediation. Complete mediation,

where every action is authenticated, is one of the secure design principles [3]. Third, the

system, while requiring complete mediation, allows for a Kerberos style authentication

scheme where the user is provided with a ticket or authenticationcontrol. This scheme

allows the user a simpler access control, insead of having to provide their main

authenticationcontrol for every action. Fourth, the authentication scheme is only as

good as the authenticationcontrol, if the authenticationcontrol is easily compromised,

then the system will not be secure. This is a feature of all authentication schemes and this

specification make the association explicit. As this system model is refined, the designer

will have to determine what constitutes a sufficiently strong authenticationcontrol for

their system. For example, a system for the military would need stronger authentication

than a system for a university. Fifth, the ACM must be created in an appropriate manner,

if a user is given rights that they should not have, the information within the system could

19

be compromised. Finally, the system does not provide authorization. If an entity knows

a correct user, authenticationcontrol pair then that entity can perform every operation in

the system.

3.4 Authorization Tactic Model Specification

This section presents the authorization tactic model specification. The full specification

is in Appendix C.

Authorization is the determination of whether an entity is allowed to perform an action or

not. The access control matrix, which describes the rights every user has with respect to

every object in the system [3], is one way to implement the authorization tactic. For this

system, the access control matrix (ACM) consists of four separate sets, one for each type

of object in the base system: userlist, filelist and processlist and one set that controls

access to the ACM itself.

Each access control set is a mapping from the user performing the operation and the

object being operated on to a set of rights. The rights are defined to coincide with all

possible actions on the system. Access to the ACM must also be controlled. Access

control for the ACM is defined for each of the four sets, the user is either granted access

to a set in the ACM or not. This level of granularity was chosen for the specification

because additional granularity, such as controlling whether a user can only add or delete

20

entities from a given set in the ACM makes the specification more verbose without

adding meaningfully to the specification. Figure 10 shows the new system and additional

types.

UserAuthorization ::=AddUserlDelete UserFileAuthorization ::=Add FilelDeleteFile IRead File lChangeFileProcessAuthorization ::= Start _ProcesslStopProcesslChangeProcessACMAuthorization::= UserlFilelProcessoACM

SYSTEMfilelist: FILENAME--4FILE_PROPERTIESuserlist: P USERprocesslist: IP PROCESSuserACM: USER x USER -+-> PUserAuthorizationfileA CM: USER x FILENAME -> PFileAuthorizationprocessACM: (USER x (USER x FILENAME))--" PProcessAuthorizationacmACM: USER -- 4 PACMAuthorization

Vpl, p2 : processlist * pl .process id = p2.processjid - pl = p2Vp: processlist * pfilename E domfilelist A p. owner E userlistdom (dom userACCM) 5 userlist

dom (domfileACCM) 5 userlist

dom (dom processA CM) 5 userlistdom (ran (dom processAICM)) 5 userlist

ran (ran (dom processACCM)) 5 dom filelist

dom acmACM5 userlist

Figure 10. Revised System Specification to Include Authorization

The domains of the four parts of the ACM are subsets of the userlist, a user that doesn't

exist does not have rights within the system. However, a user that doesn't exist can be an

21

object in the ACM, in fact, users and files that don't exist must be objects in the ACM,

otherwise creation of objects would not be controlled by the ACM.

The system has four new elements, the sets in the ACM and each element needs to be

modifiable, therefore there are eight new operations, an add and a delete for each set in

the ACM. Access to these operations is authorized through the acmACM set of the

ACM. Figure 11 shows AddUserACMNewUser. AddUserACMNewUser takes three

users, the first user is the user modifying the UserACM, the second user is the user being

granted the right and the third user is the object that the right is being granted for. For

example, AddUserACMOK(ul, u2, u3, (Add-User}) would, assuming ul has the right

to modify the UserACM, allow u2 to add u3 to the userlist. The other operations for

adding and deleting entries in the userACM, fileACM, processACM and acmACM are

similar.

22

AddUserACM OK

ASYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights?: P UserAuthorization

r!: Response

User E acmACM(user?)

newUser? E userlist

userACM = userACM U ((newUser?,addUser?)-4rights?}

r! =OK

_AddUserACM IncorrectRights

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER


r!: Response

User G acmACM(user?)

r! = IncorrectRights

_AddUserACM New UserNotExists-

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights? : PUserAuthorization

r!: Response

User E acmA CM (user?)

newUser? E userlist

r! = UserNotExists

Figure 11. Add User ACM Specification

AddUserACM AddUserACMOK v AddUserACM IncorrectRights V

AddUserACM NewUserNotExists

23

Most of the revised operations of the base system are modified in a similar way to

authentication, except each operation requires a check that the user has the correct rights,

not that the user has the correct authenticationcontrol. Figure 12 shows the modified

AddUser.

_AddUser Authorization OKESYSTEMuser?: USERnewUser?: USERr!: Response

AddUser E userACM(user?,newUser?)r! =OK

_AddUser Authorization Fail-SYSTEMuser?: USERnewUser?: USERr! : Response

AddUser X userACM(user?,newUser?)r! = IncorrectRights

AddUser (AddUserAuthorizationOK A (AddUserOK V AddUser-Exists)) VAddUser AuthorizationFail

Figure 12. Revised Add User Specification to Include Authorization

The operations on processes have been modified to include a runAs user. The idea

behind this is a user might want to start a process that has fewer rights than they do, for

example, root on a Unix system starting the mailer daemon should not run the mailer

24

daemon as itself. Figure 13 shows the modified StartProcess operation.

StartProcessAuthorizationOK and StartProcessAuthorization-Fail are virtually

identical to the corresponding AddUser operations.

StartProcessOKASYSTEMprocess?: PROCESSrunAs?: USERr!: Response

process?.owner runAs?process? filename E domfilelistVp:processlist Oepprocess id s process?.process-idprocesslist' = processlist U {process?}r! = OK

_StartProcessUserNameslnconsistentESYSTEMprocess?: PROCESSrunAs?: USERr!: Response

process?.owner • runAs?r! = UserNamesInconsistent

StartProcess - (StartProcess_Authorization OK A (StartProcessOK VStartProcessFileNotExists V StartProcessUserNamesInconsistent))V StartProcessAuthorization-Fail

Figure 13. Revised Start Process Specification to Include Authorization

The authorization of a system operates similarly to the authentication of a system, it

wraps the existing system so a user must be authorized before they can try and perform

any action. There are several features of authorization that this specification emphasizes.

25

First, it does not perform authentication, which is a separate tactic. This does mean that

if a system only implements authentication, if someone can imitate a user, they would

immediately have that users rights. This is like having a Unix system where all the

passwords are empty. In practice, authentication and authorization will almost always be

used together. Second, like authentication, this specification performs complete

mediation; every operation is checked to make sure the user attempting the operation is

allowed to perform that action. Finally, the ACM is capable of representing any style of

access control: Roll Based Access Control, Discretionary Access Control or Mandatory

Access Control by defining constraints on how the ACM is modified.

3.5 Data Confidentiality Tactic Model Specification

This section presents the data confidentiality tactic model specification. The full

specification is in Appendix D.

"Confidentiality is the concealment of information or resources" [3]. Therefore, the date

confidentiality tactic requires that the data, or information is hidden. If the information is

hidden, then a piece of information is needed to retrieve it. The base system is modified

to provide data confidentiality by introducing a new set, SECRET and the mapping to the

fileproperties is redefined so it is now from a filename and secret to the fileproperties.

Figure 14 shows the revised system specification. The additional constraint at the bottom

26

of the specification eliminates the possibility of mapping a filename to different

properties depending on the secret while still allowing multiple secrets for each filename.

[SECRET]

SYSTEM

filelist: FILENAME x SECRET ->FILEPROPERTIES

userlist: P USERprocesslist: P PROCESS

VpI, p2: processlist * p1 process id = p2.process-id X p1 = p2

Vp: processlist p filename E dom (domnfilelist) A p. owner E userlist

Vf: dom (domfilelist) * VAsl, s2: (domfilelist) ( {/} [ *filelist(fsl) =filelist(fs2)

Figure 14. Revised System Specification to Include Data Confidentiality

There are no new operations for confidentiality and it does not modify the user

operations. All the ReadFile and process operations are changed to include the secret

being passed in. If the filename, secret pair is not in the mapping, an error is returned.

The system does not return different errors depending on if the filename exists or not.

This is important because the existence of the file could be used as a covert channel.

Figure 15 shows how ReadFile has been modified.

c

27

ReadFileOKESYSTEM

filename?: FILENAME

secret?: SECRET

fileproperties!: FILEPROPERTIES

r!: Response

(filename?,secret?) E domfilelist

fileproperties! =filelist(filename?,secret?)

r! = OK

Figure 15. Revised Read File Specification to Include Data Confidentiality

AddFile is modified to check to see if the filename exists and if it does, if the

fileproperties are the same. If the fileproperties are the same, then AddFile is adding an

additional way to access the file through the new secret. Figure 16 shows how AddFile

has been modified.

AddFileOKASYSTEM

filename?: FILENAME

secret?: SECRET

fileproperties?: FILEPROPERTIES

r!: Response


filename? X doom (dom fielist) V (Vs: (dom fielist) ( filename?} 0

fileproperties? =filelist(filename?,s))

filelist' =filelist U {(filename?,secret?) "fileproperties?}

r! = OK

Figure 16. Revised Add File Specification to Allow Multiple Secrets per Filename

28

DeleteFile is modified to remove all references to the filename, not just delete the one

way to access the file. ChangeFile is modified to change all filename references to the

correct revised fileproperties, see Figure 17.

ChangeFileOKASYSTEM

filename?: FILENAME

secret?: SECRET

properties?: FILEPROPERTIES

r!: Response

(filename?,secret?) E domnfilelist

(let secretlist == ((domtfilelist) 1 {filename?)} D)D

filelist'= filelist (d (({filename?} xsecretlist)x {properties?}))

r! = OK

Figure 17. Revised Change File Specification to Include Data Confidentiality

There are several features the specification for data confidentiality emphasizes. First,

cryptography is not required by this definition, anything that maintains the mapping from

the filename, secret pair to the fileproperties will provided confidentiality. The key here

is that the mapping is the only way to access the fileproperties. Cryptographic protocols

are sufficient, but not necessary. Secure storage mechanisms, such as those proposed by

the Trusted Computing Group [15] are an example of a system that provides

confidentiality without cryptography. Second, the confidentiality provided is dependant

on the quality of the secret, if the secret can be easily guessed or derived, then the

29

strength of the tactic will be weak. Third, there can be multiple secrets to access a single

file. This is useful to prevent users from using the common secret to communicate in any

way except through the file.

3.6 Data Integrity Tactic Model Specification

This section presents the data integrity tactic model specification. The full specification

is in Appendix E.

The more trustworthy the information, the more integrity it has [3]. Thus, for a system to

provide data integrity, the system should be cognizant of any modifications to the

information. The data must only be modified by authorized entities and any other

modifications to the data must be detected. To provide data integrity, the base system

specification needs to be extended; there needs to be two new undefined sets:

INTEGRITYCONTROL and [NTEGRITYCHECK. The integritycontrol set is used

to make sure only authorized users change a file's properties. The integritycheck is

used to determine if a file has been illegally modified. The integrity check is stored in

the fileproperties along with the fileinformation. The fileinformation and an

integritycontrol element are mapped to the integritycheck value. The function,

integritymap, needs to be an injective function to prevent multiple file_info and

integritycontrol pairs mapping to the same integritycheck. This would prevent the

30

integritycheck from guaranteeing there has been no unauthorized change. See Figure 18

for the integrity_rnap and refined file_properties specifications.

INTEGRITY MAP: FILEINFO x INTEGRITY CONTROL

| a> INTEGRITY CHECK

-FILEPROPERTIES

info: FILE_INFO

integrity: INTEGRITY CHECK

:ic: INTEGRITYCONTROL * INTEGRITY MAP(info, ic) = integrity

Figure 18. Revised File Properties Specification to Include Data Integrity

There are two new operations for the system CheckIntegrity and CheckIntegrityFail,

shown in Figure 19. Check-Integrity checks to make sure the integritycontrol provided

in the operation maps the fileinfo to the integritycheck. CheckIntegrity Fail returns

the error message if the integrity check is unsuccessful. Note that CheckIntegrity has no

return value because it will be included in the successful cases. All the operations

include CheckIntegrity in the successful case and IntegrityCheck Fail will be an

additional error case.

31

_CheckIntegrityESYSTEM

filename?: FILENAME

ic?: INTEGRITY CONTROL

filename? E dom (filelist)

INTEGRITY MAP((filelist(filename?)). info, ic?) = (filelist(filename?)).integrity

_CheckIntegrity Fail

ESYSTEM

filename?: FILENAME


r!: Response

filename? e dom (filelist)

INTEGRITY MAP((filelist(filename?)). info, ic?) # (filelist(filename?)).integrity

r! = InvalidIntegrityCheck

Figure 19. Check Integrity Specification

The only operations that change are ReadFile, ChangeFile, StartProcess, StopProcess and

ChangeProcess. These are the operations that use or modify an existing file and they all

change in the same way. The successful access to the file includes the IntegrityCheck

specification and the overall operation includes Integrity-CheckFail. This is different to

the way authentication and authorization is specified because the integrity is only

checked if the file exists whereas authentication and authorization are always performed.

The revised ReadFile specification is shown in Figure 20.

32

ReadFileOK

ESYSTEM

CheckIntegrity

filename?: FILENAME


r!: Response


fileproperties! =filelist(filename?)

r! = OK

ReadFile ReadFileOKV ReadFileNotExists V Check Integrity Fail

Figure 20. Revised Read File Specification to Check Data Integrity

AddFile and ChangeFile check the integrity of the incoming fileproperties. If these two

operations did not perform the integrity check, the system could end up in an inconsistent

state.

There are several noteworthy features of the data integrity specification. First, the

requirement that the integrity check be injective is very restrictive. However, without

that requirement, it is possible to have multiple fileinfo and integritycontrol pairs map

to a single integritycheck. This would violate the systems ability to guarantee that only

authorized users modify the files. In most systems, this requirement could be relaxed to

insist on a high difficulty in finding the multiple mappings. Second, as with data

confidentiality and authorization, the quality of the integritycontrol directly affects the

quality of the integrity provided. The easier it is to obtain the integritycontrol value for

a file, the easier it is to circumvent the security mechanism. Third, DeleteFile does not

33

perform an integrity check. This means that any user can delete files. Implementation of

the authorization tactic allows the the system to control who deletes files. Finally, the

three process operations confirm the integrity of the file at every step thus if the file is

ever modified, the execution of that file is halted. This does not prevent buffer overflow

attacks as those attacks don't modify the files, just the information in dynamic memory.

To prevent this class of attacks, the system needs to link the file representation in

memory to the file representation on the hard disk.

3.7 Auditing Tactic Model Specification

This section presents the auditing tactic model specification. The full specification is in

Appendix F.

Auditing a computer system is the process of recording sufficient information for each

event so the sequence of events is reproducible [2]. If a system is then compromised, the

audit log can show the source of the compromise and what was done. Auditing every

operation in a computer system is usually infeasible, the performance impact can be too

large. Therefore, it is important that an audit policy exist which determines the

operations to be logged.

Two elements are added to the base system: the audit policy and the log. The audit

policy consists of three parts, the userauditpolicy, the fileauditpolicy and the

34

processauditpolicy. Each policy determines what actions on the user, file or process

portion of the system needs to be audited. Figure 21 shows the extended system

specification.

-SYSTEMfilelist: FILENAME-+~FILEPROPERTIES


userauditpolicy: P(USER x UserAction)

fileauditpolicy: P(FILENAME x FileAction)

processauditpolicy: P(USER x FILENAME x ProcessAction)

log: seq LogElement

Vp 1, p2 : processlist * p1 .process id = p2.process-id #> pI = p2

Vp: processlist * pfilename e domfilelist A p. owner e userlist

Figure 21. Revised System Specification to Include Auditing

The second element added to the system model is the log. The log is a sequence of log

elements. Each log element includes the result of the operation performed, and either a

UserLogElement, a FileLogElement or a ProcessLogElement depending on the operation.

Both successful actions and unsuccessful actions need to be logged because it is

important that a system report failures such as logins using incorrect usernames or

passwords. The log also needs to keep all operations in a single sequence. If separate

sequences are kept for the user, file and process operations, then a timestamp or some

other coordination mechanism is required so operations on different parts of the system

35

are reproduced in the correct order. The log element specifications are shown in Figure

22.

- UserLogElement

user: USER

action: UserAction

_FileLogElement

filename: FILENAME

action : FileAction

filechange: FILECHANGE

_ProcessLogElement


filename: FILENAME

owner: USER

action : ProcessAction

processchange: PROCESSSTATECHANGE

jLogElementu: PDUserLogElement

f: IPFileLogElement

p: PProcessLogElement

r: Response

#u+#f+#p =

Figure 22. Log Element Specifications

The file and process log elements keep track of changes to files or processes. This is

done through two mappings. The first mapping is from the new and old properties to the

change. The second mapping is from the old properties and the change to the new

36

properties. These two mappings allow the changes to be determined and then repeated.

Figure 23 contains the specification for the mappings.

FILECHANGE_MAP: FILEPROPERTIES x FILECHANGE- FILEPROPERTIES

FILEPROPERTIESMAP: FILEPROPERTIES x FILEPROPERTIES- FILE_CHANGE

PROCESSSTATE_CHANGEMAP: PROCESSSTATE xPROCESSSTATECHANGE -* PROCESSSTATE

PROCESSSTATE_MAP: PROCESSSTATE x PROCESSSTATE-> PROCESSSTATE_CHANGE

Figure 23. Change in File and Process Properties Function Specifications

All operation cases, including the failure message reports, are modified. Each operation

checks if the audit policy requires the operation be logged. If so, the log entry is created

and appended to the log. The modified operation case specifications require local or

temporary variables, and in Z there are two ways to do this. The first, shown in Figure

24, uses the let expression. Unfortunately, the let expression in Z Word Tools can only

evaluate to a set which makes the definition awkward as there are sets of 1 element where

the element needs to be added to a sequence. The second, shown in Figure 25, lists the

local variables as part of the schema declaration. The local variables have neither a! or ?

so they are neither input nor output. The second definition, while not standard is

37

acceptable as demonstrated in [5] on page 248. The second specification is easier to read

and determine the intent of the specification so it is used. Every operation case except

StopProcessProcessIDNotExists and ChangeProcessProcessIDNotExists is modified in

virtually the same way.

ReadFileOKASYSTEM

filename?-: FILENAMEfileproperties!: FILEPROPERTIESr!: Response

filename? e domfilelistfileproperties! = filelist(filename?)r! = OK(filename?, ReadFile) i fileauditpolicy V(letfl == {f- FileLogElement If filename =filename? Af action = Read File }@

(#fl = I A (let 11 == {l:LogElement I I.u = 0 A lf =fl A l.p = 0 A l.r = r!} !(V z: 11 * log' = log 7z>) A #11I = 1)))

Figure 24. Revised Read File Specification to Include Auditing Using Lets

38

_ReadFileOK

ASYSTEM

filename?: FILENAME


filelogelement: FileLogElement

logelement: LogElement

r!: Response



r! = OK

(filename?, Read File) i fileauditpolicy V (filelogelement. filename= filename? A

filelogelement.action = Read File A logelement.r = r! A

logelement. u = 0 A logelementf = {filelogelement} A

logelement.p = 0 A log' = logA-logelement))

ReadFileNotExists

ASYSTEM

filename?: FILENAME

fileproperties! : FILEPROPERTIES



r!: Response

filename? X domfilelist

r! = FileNotExists

(filename?, ReadFile) efileauditpolicy V (filelogelement.filename= filename? A



logelement.p = 0 A log' = logelogelement))

ReadFile - ReadFileOK v ReadFileNotExists

Figure 25. Revised Read File Specification to Include Auditing with Local Variables inthe Schema Declaration

StopProcessProcessIDNotExists and ChangeProcessProcessIDNotExists are not

modified in the same manner as the other operation cases because the process referenced

39

does not exist so there is no user, file pair to determine if the case should be logged or

not. The specification uses the security principle of fail safe defaults and if there is any

user, filename pair that requires logging, then the failure is logged. Figure 26 shows the

revised StopProcessProcessIDNotExists specification.

_StopProcess-ProcessIDNotExistsESYSTEMprocess id?: PROCESSIDprocesslogelement: ProcessLogElementlogelement: LogElementr!: Response

Vp:processlist * p.processid • process id?r! = ProcesslDNotExists(V owner: USER * (Vfilename: FILENAME S

(owner,fllename, Stop Process) 6i processauditpolicy)) V(processlogelement.action = Stop Process A

logelement. r = r! A logelement. u = 0 A logelementf = 0 A

logelement.p = {processlogelement} A log' = logelogelement>)

Figure 26. Revised StopProcessProcessIDNotExists Specification to Include Auditing

There are several important features of this specification. First, there is no way to delete

or modify the log. If log elements can be modified or deleted, users can hide their

actions. Second, the audit could log every change to a process or file, this could lead to a

severe performance impact therefore the audit policy is very important. It is essential to

find the correct balance between logging sufficient information to recreate all critical

processes and files and keeping the performance of the system satisfactory. Third, the

specification does not allow for the audit policy to be modified while the system is

40

running, it is set up from the start of the system. If the log policy requires customization,

it is a straightforward exercise to add the operations. The operations will be similar to

those defined for authorization. Fourth, there can be additional granularity added to the

audit policy so logging depends on the result of the operation. This is a straightforward

refinement of the system, which is not shown here as it only serves to make the

specification more difficult to interpret.

3.8 Intrusion Detection Tactic Model Specification

This section presents the intrusion detection tactic model specification. The full

specification is in Appendix G.

An intrusion detection system (IDS) analyses the events in a system to determine if they

constitute an attack [3]. An intrusion detection system requires two sets of information to

make this determination. First it needs a policy to define an attack, second it needs a

record of the events occurring within the system. The audit tactic provides a record of

the events, so the intrusion detection system specification will extend the audit system

specification.

The system is modified by adding three new elements: the IDS Policy, the alertlist and

the lastlDSAnalysis number. The IDS policy is a set of log element sequences where

each sequence represents an attack. The alertlist is a set of log element sequences where

41

each sequence represents a detected attack. The lastIDSAnalysis number represents the

last log entry analyzed by the IDS. See Figure 27 for the extended system specification.

-SYSTEMfilelist: FILENAME-"FILEPROPERTIES

userlist: P USER

processlist: P PROCESS

userlogpolicy: P(USER x UserAction)

filelogpolicy: P(FILENAAE x FileAction)

processlogpolicy: P(USER x FILENAME x ProcessAction)

log: seq LogElement

idspolicy: P(seq1 LogElement)

idsalertlist: seq(seq, LogElement)

lastlDSAnalysis: N

Vp 1, p 2 : processlist pl .process id = p2.processid X pl = p2Vp : processlist pfilename e domfilelist A p. owner E userlist

Figure 27. Revised System Specification to Include Intrusion Detection

There are three new operations in the specification, IDSAlert, IDSNoAlert and

IDSSystem, shown in Figure 28. IDSNoAlert requires that if the log does not change,

then there can be no new attacks detected. IDSAlert analyzes the entire log and if any

sequence can be extracted from the log that meets the following two requirements then an

alert will be generated: first, the sequence is in the IDSPolicy and second, it contains at

least one log element that has not been previously analyzed. This second requirement is

to make sure no duplicate alerts are generated. IDSSystem is either IDSAlert or

IDSNoAlert. If IDSAlert is the only option included, then every operation fails if log'

42

= log. The combined operation is therefore required because an operation should not fail

because the operation is not logged.

IDS AlertASYSTEMsublog: IF (P N1)newalertlog: seq (seq1 LogElement)

log' logVsl: sublog * slllog' e idspolicy A (sljlog') in newalertlog A

(Bp: N1 * (lastlDSAnalysis < p < #log' A p E sO))

idsalertlist' = idsalertlisC'newalertloglastIDSAnalysis' = #log'

IDSNoAlert-SYSTEM

log' = logidsalertlist' = idsalertlist

IDS System IDSAlert V IDSNoAlert

Figure 28. IDSAlert, IDSNoAlert and IDS_System Specification

Every operation is modified to include the IDS-System. If the operation is logged, then

IDSAlert will determine if any new attacks have occurred. See Figure 29 for the revised

AddUser specification. All other operations are similarly modified.

43

_AddUserOKASYSTEM

IDS System

newUser?: USER

userlogelement: UserLogElement


r! : Response

newUser? e userlist

userlist' = userlist U {newUser?}

r! = OK

(new User?, AddUser) i userlogpolicy V (userlogelement.user new User? A

userlogelement.action = AddUser A logelement.r = r! A

logelement.u = {userlogelement} A logelement.f= 0 A

logelement.p = 0 A log'= log(logelement~)

AddUserExists

ASYSTEM

IDS System

newUser?: USER



r!: Response

newUser? E userlist

r! = UserExists

(new User?, AddUser) E userlogpolicy V (userlogelement.user new User? A

userlogelement.action = Add User A logelement.r = r! A

logelement.u = {userlogelement} A logelement.f = 0 A

logelement.p = 0 A log' = log(logelement~)

Figure 29. Revised Add User Specification to Include Intrusion Detection

There are several important features of this specification. First, IDS-Alert is called every

time the log is modified to provide complete mediation. Second, the intrusion detection

system only monitors logged operations, if an attack contains operations that are not

44

logged, that attack will not be detected, thus the log policy is a crucial part of the

intrusion detection system. Third, the intrusion detection policy is predetermined. The

system can be extended to allow changes in the policy by following the same pattern as

the authorization system. Finally, the intrusion detection policy contains a list of all

attacks. This corresponds to the definition of a misuse based IDS. There are two other

types of IDS, specification based and anomaly based IDS. These two IDS specify

allowable behavior, the opposite of a misuse based system. In theory, the conversion

between the two types of IDS is not difficult, however, in a real system specifying all

allowable behavior or all illegal behavior is infeasible.

3.9 Limit Access, Limit Exposure and Availability Tactics

Availability is a quality attribute like security [2]. As such, there is a set of tactics that

can be used to improve the availability of a system. This report is focused on security

tactics and does not investigate availability tactics.

The limit exposure and limit access tactics do not require separate specifications because

they can be achieved through a combination of the other tactics. The idea behind the

limit exposure tactic is to reduce the number of services on a given host so that there are a

limited number of ways to get into the system. This tactic has two possible

interpretations. The first is that the system being defined is the system containing

multiple services. Under the limit exposure tactic, the services need to be kept separate.

45

This is sandboxing, separating the services therefore they cannot interact. This tactic can

be achieved by using authentication and authorization and constructing the access control

matrix of the system so that it partitions the files, processes, and users so the services

cannot interact. It can be further strengthened by using confidentiality and integrity

where each service has its own secrets and integritycontrols unbeknownst to the other

services, thus if one service is compromised, it cannot access the other services and if it

indeed accessed them, it would not be able to modify or access the other services files.

The second interpretation of the limit exposure tactic is that the system being defined is

within another system. In this case access control would not be helpful, however

confidentiality and integrity would prevent other services from reading or manipulating

the files of this service. The best way to get this separation is to have the system

sandboxed, however, if that is not possible, then using the confidentiality and integrity

tactics can provide some protection.

The idea behind the limit access tactic is to limit the locations or access points able to

connect to the system. An example of a mechanism that implements the limit access

tactic is a firewall. A firewall is outside of the system being defined, so this specification

does not define the properties of the firewall. However, the definition of

authorizationcontrol can be extended to include the location of the user and proof of that

location. Authorization can then be used to limit system access to users in permitted

locations.

46

Both of these tactics are primarily meant for the deployment stage of the system being

defined, therefore in general it is not something that the software architecture will deal

with. However, if they are important, there are mechanisms that can be implemented in

the software system to make these tactics stronger.

3.10 Combined Authorization and Authentication Model Specification

This section presents the combined authorization and authentication tactic model

specification. The full specification is in Appendix H.

Most software systems employ more than one security quality attribute thus most

software architectures require more than one security tactic. The formal specifications

facilitate combining. As a representative example, the merged authentication and

authorization specification will be developed. In this specification, the order of

operations is important; authorization needs to be performed before authentication

otherwise it is possible for an unauthorized entity to map out the rights of the authorized

users. The system is the combination of the authentication system and the authorization

system. Furthermore, access to this new authorization set is controlled by the access

control matrix. Figure 30 shows the combined authorization and authentication system

specification.

47

-SYSTEMfilelist: FILENAMiE-+*FILE-PROPERTIES

userlist: P USER


authenticated: P(USER x AUTHENTICATION CONTROL)

userACM: USER x USER ->+ PUserAuthorization

fileACM: USER x FILENAME -+-+ PFileAuthorization

processACM: (USER x (USER x FILENAAME))-14 PProcessAuthorization

authenticationACM: USER x USER -±> PAuthenticationAuthorization

acmACM: USER -- * PACMAAuthorization

Vp1, p2 : processlist * p1 .processid = p2.processid > pI = p2

Vp : processlist * pfilename E domnfilelist A p. owner E userlist

dom authenticated 5 userlist

dom (dom userACAM) 5 userlist


dom (dom processACCM) S userlist

dom (ran (dom processACCM)) 5 userlist

ran (ran (dom processA CM)) 5 dom filelistdom (dom authenticationACCM) S userlist

dom acmACMC userlist

Figure 30. Combined Authorization and Authentication System Specification

The new portion of the ACM, the authentication ACM, needs to be modified similar to

all the other ACM components. The two operations, AddAuthenticationACM and

DeleteAuthenticationACM are virtually identical and show how authorization and

authentication are combined. First, the user is authenticated and then the user's right to

modify the ACM is corroborated. See Figure 31.

48

_AddAuthenticationACMOK

ASYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights?: NAuthenticationAuthorization

r!: Response

Authentication E acmACM(user?)

newUser? E userlist

authenticationACM = authenticationACM U {(newUser?,addUser?)F-4rights?}

r! = OK

_AddAuthenticationACM IncorrectRights

Z SYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights?: PAuthenticationAuthorization

r! : Response



AddA uthenticationACM New UserNotExists

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights? : NAuthenticationAuthorization

r! : Response


newUser? E userlist

r! = UserNotExists

AddAuthenticationACM- (AuthenticateUser A (AddAuthenticationACM OKV

AddAuthenticationACM IncorrectRights V AddAuthenticationACM New UserNotExists))


Figure 31. AddAuthenticationACM Specification

49

All operations are defined in the same manner as AddAuthenticationACM, where first

the user is authenticated then authorized. The complete specification is a matter of

constraining the new system with both tactics. The system now authorizes and

authenticates every operation, it performs complete mediation using both security tactics.

50

Chapter 4

DISCUSSION

4.1 Conclusion

The correct architecture for a system is essential for its successful implementation.

Creation of the software architecture is the first and most important stage for realization

of the qualities that a system must possess. Security is one of the quality attributes of a

system. This project provides Z specifications of architectural tactics that can be used to

achieve the security goals of a system. A base system model, with no security is

specified and each tactic is defined as constraints on the extended base system model. An

example is created which shows how the tactics can be combined into a single

specification. This project demonstrates the power of creating Z specifications of

architectural tactics and formal languages capacity to capture high-level abstract

concepts.

4.2 Applications and Uses

Formal specifications of software systems provide myriads of benefits [12]. The formal

specification of the design tactics for the security quality attribute is no exception. First,

it provides a template or building block for creating systems that make use of the various

tactics. For example, if a system requires confidentiality, then the specification described

herein can be used as a base or guide for the architecture of the new system. The generic

51

nature of the tactic specifications allows them to be integrated into the specification of

any type of software system. The ease of adding a specific tactic to a new system allows

the software architect to concentrate on the overall design rather than being concerned

with the specifics of each tactic.

The formal specifications of the tactics clarify the requirements of each tactic. A tactic is

a design decision and requires certain mechanisms or components to be effective. For

example, for an intrusion detection system to be effective, there needs to be both a

logging policy and an intrusion detection policy both of which capture the security

critical behavior of the system. The tactics also require specifications of the quality of

the mechanisms. For confidentiality, what the secret is affects how confidential the data

is. When the system specification is refined the secret will need to be precisely defined,

will it be a password, a digital certificate or something else. A password that acts as the

key for a cryptographic algorithm may be sufficient for the system being designed, or a

more complex secret such as information on a smartcard may be required. The

specification makes explicit the decisions the architect will make regarding the security

of the system.

A formally defined system can also be rigorously analyzed. The analysis for potential

weaknesses is strengthened with the security aspects of a system precisely defined. As

the system specification is refined, the refinements are proven to be consistent with the

higher level specifications providing a high level of confidence that the system correctly

52

implements the tactic. The refinement also exposes the assumptions made about the

system. Analysis of the assumptions can then determine if they are acceptable for the

system being developed.

The tactic specifications create a framework in which to analyze specific security

mechanisms. The mechanism can be proven to correctly capture one or more of the

tactics. For example, the Role Based Access Control models specified in [1] can be

shown to correctly implement the authorization and authentication tactics.

4.3 Future Work

There are several avenues of additional research that have become apparent during this

project. First, it is necessary to formally specify the other quality attributes. As the

tactics are formally defined, all that is necessary to create a formal model of a new

architecture is to decide what tactics the new system should implement. Further, the

formal specification of other quality attributes tactics allows a rigorous analysis of the

interactions and compromises that come from combining the tactics.

Second, the tactics can be refined to create a framework or skeleton of a system using

programs like those defined in [9], [10] and [11]. This framework will allow the

architecture of a system to be implemented quickly and easily. It will drastically shrink

53

the semantic gap between the architecture, high level design and implementation of the

system.

Finally, as many of the tactics require policies such as an intrusion detection or logging

policy, there is an area of additional work to create templates for the aforementioned

policies should be created. These policies would define various levels of security, from

the highest or most strict policies (e.g. for military and other high security applications) to

more relaxed policies suited for home or typical business applications. These templates

will help to reduce the errors in system development that are caused because of

inadequate analysis or definition.

54

APPENDICES

55

APPENDIX A

Base System Model Specification

[USER]

[FILENAME]

[FILE-PROPERTIES]

[PROCESS ID]

[PROCESS STA TE]

Response::= OK UserExistsl UserNotExistslFileExistslFileNotExistsl

ProcessIDNotExistsl UserRunningProcesslFileBeingExecuted

PROCESS

filename: FILENAME

owner: USER

process_id: PROCESSID

state: PROCESSSTATE

SYSTEM

filelist: FILENAME-+*FILE_PROPERTIES

userlist: P USER


Vpl , p2: processlist * p1 .process id = p2.process id X pI = p2

Vp : processlist * pfilename E domnfilelist A p. owner E userlist

InitSYSTEM

system: SYSTEM

#system.filelist= I

#system.userlist = I

#system.processlist= I

56

AddUserOK

ASYSTEM

newUser?: USER

r! : Response

newUser? X userlist


r! =OK

AddUser Exists_ESYSTEM

newUser?: USER

r! : Response

newUser? E userlist

r! = UserExists

AddUser E- AddUserOK V AddUser-Exists

DeleteUserOK

ASYSTEM

user?: USER

r!: Response

user? E userlistVp : processlist p. owner • user?

userlist' = userlist \ {user?}

r! = OK

57

Delete UserNotExists

ESYSTEM

user?: USER

r!: Response

user? X userlist

r! = UserNotExists

Delete User RunningProcess

-SYSTEM

user?: USER

r!: Response

user? e userlist

3p: processlist * p. owner = user?

r! = UserRunningProcess

Delete Use - Delete UserOK V Delete User NotExists V Delete User RunningProcess

AddFileOKASYSTEM

filename?: FILENAME


r! : Response


filelist' =filelist U {filename? -*fileproperties?}

r! = OK

58

AddFile_Exists_

_SYSTEM

filename?: FILENAME


r!: Response


r! = FileExists

AddFile - AddFileOK V AddFile Exists

ReadFileOKESYSTEM

filename?: FILENAME


r!: Response

filename? e domfilelist


r! = OK

ReadFileNotExistsESYSTEM

filename?: FILENAME


r!: Response

filename? i domfilelist

r! = FileNotExists

ReadFile - ReadFileOK V ReadFileNotExists

59

_DeleteFileOKASYSTEM

filename? FILENAME

r! Response


Vp processlist * pfilename • filename?

filelist'= filelist \ {filename? -4filelist(filename?)}

r! = OK

_DeleteFile NotExists-SYSTEM

filename? FILENAME

r! Response


r! = FileNotExists

_DeleteFile FileBeingExecutedESYSTEM

filename? FILENAME

r! Response


3p processlist * p. filename =filename?

r! = FileBeingExecuted

DeleteFile - DeleteFileOK V DeleteFileNotExists V

DeleteFileFileBeingExecuted

60

jChangeFileOKASYSTEM

filename?: FILENAME


r!: Response


filelist'= flelist 0 {filename?-) properties?}

r! = OK

ChangeFileNotExistsESYSTEM

filename?: FILENAME

properties?: FILE-PROPERTIES

r!: Response


r! = FileNotExists

ChangeFile -ChangeFile-OK v ChangeFileNotExists

_StartProcessOK

ASYSTEM

process?: PROCESS

r!: Response

process?.owner E userlistprocess?filename e domfilelist

Vp:processlist *p.process id # process?.process id

processlist' = processlist U {process?}

r! = OK

61

StartProcessFileNotExists

-SYSTEM

process?: PROCESS

r!: Response

process? filename X domfilelist

r! = FileNotExists

StartProcessUserNotExists__ESYSTEM

process?: PROCESS

r!: Response

process?.owner X userlist

r! = UserNotExists

StartProcess -StartProcessOK V StartProcessFileNotExists V

StartProcess_ UserNotExists

StopProcessOKASYSTEM

process id?: PROCESSID

r!: Response

9p:processlist * p.processid = process-0?

processlist' = processlist\ {p:PROCESSp.process-id = process-id?}

r! =OK

StopProcessProcessIDNotExists

ESYSTEM

process U? : PROCESSID

r!: Response

Vp:processlist * p.processid • process_id?

r! = ProcessIDNotExists

62

StopProcess - StopProcessOK v StopProcessProcessIDNotExists

jChangeProcessOKASYSTEM

processid?: PROCESSID

newstate?: PROCESSSTATE

r!: Response

(let p {p 1: processlist I p1 .processid = process id?} -(Vp2:p * p2.state = newstate?) A #p = 1 A

processlist' = processlist\ {p2: processlist I p2.process id = process-id?} A

processlist' = processlist' Up A

r! = OK)

jChangeProcessProcessIDNotExists

-SYSTEM



r! : Response

ChangeProcess - ChangeProcessOK V ChangeProcessProcessIDNotExists

Vp:processlist * p.processid • process id?


63

APPENDIX B

Authentication Tactic System Model Specification

[USER]

[FILENAME]

[FILEPROPERTIES]

[PROCESSID]

[PROCESSSTA TE]

[AUTHENTICATION CONTROL]

Response ::= OKI UserExistsl.UserNotExistsIFileExistsIFileNotExistsI

ProcessIDNotExistslInvalidUserA uthenticationControlPairl

UserRunningProcesslFileBeingExecuted I UserStillA uthenticated

_PROCESS

filename: FILENAME

owner: USER


state: PROCESSSTA TE

_SYSTEM

filelist: FILENAME-t->FILE_PROPERTIES

userlist: P USER

authenticated: USER -'-t PA UTHENTICATIONCONTROL


VpI , p2 : processlist * pI .process_id = p2.process_id * pl = p2

Vp : processlist * pfilename E domfilelist A p. owner E userlist


64

AuthenticateUser

ESYSTEM

u?: USER

ac? : AUTHENTICATIONCONTROL

r!: Response

ac? E authenticated(u?)

r! = OK

AuthenticateUserFailESYSTEM

u?: USER

ac?: AUTHENTICATION CONTROL

r!: Response

ac? X authenticated(u?)

r! = InvalidUserAuthenticationControlPair

AddAuthentication OKASYSTEM

user?: USER

ac? : A UTHENTICATIONCONTROL

r! : Response

user? e userlist

authenticated'(user?) = authenticated(user?) U {ac?}

r! = OK

AddAuthenticationNotExists

ESYSTEM

user?: USER


r!: Response

user? X userlist

r! = UserNotExists

65

AddAuthentication (Authenticate_User A (AddAuthenticationOKV

AddAuthenticationNotExists)) V Authenticate User Fail

DeleteAuthenticationOKASYSTEM

user?: USER

ac? : A UTHENTICA TIONCONTROL

r! : Response

ac? E authenticated(user?)

authenticated'(user?) = authenticated(user?)\{ac?}

DeleteAuthenticationNotExists

ESYSTEM

user?: USER

ac? : A UTHENTICA TIONCONTROL

r!: Response

ac? E authenticated(user?)


DeleteAuthentication (AuthenticateUser A (DeleteAuthenticationOKV

DeleteAuthenticationNotExists)) V Authenticate_UserFail

InitSYSTEM

system: SYSTEM

#system.filelist = I

#system.userlist= I

#system.processlist = I

3u: system. userlist * #(system. authenticated(u)) > I

66

AddUserOK

ASYSTEM

newUser?: USER

r!: Response

newUser? X userlist

userlist'= userlist U {newUser?}

r! = OK

AddUser ExistsESYSTEM

newUser?: USER

r!: Response

newUser? E userlist

r! = UserExists

Add User - (AuthenticateUser A (AddUserOK V AddUserExists)) V

Authenticate User-Fail

DeleteUserOKASYSTEM

user?: USER

r!: Response

user? E userlist

Vp: processlist * p.owner t user?

user? X dom authenticated


r! = OK

67

Delete UserNotExistsBSYSTEM

user?: USER

r!: Response

user? X userlist

r!= UserNotExists

Delete User RunningProcess

-SYSTEM

user?: USER

r! : Response

user? E userlist


r!= UserRunningProcess

Delete UserStillAuthenticatedESYSTEM

user?: USER

r! : Response

user? E userlist

Vp : processlist *p. owner • user?

user? E dom authenticated

r! = UserStillAuthenticated

DeleteUser (AuthenticateUser A (DeleteUserOKV DeleteUserNotExists

V Delete UserRunningProcess V Delete UserStillAuthenticated))

V Authenticate User Fail

68

AddFileOKASYSTEM

filename?: FILENAME


r!: Response


filelist' =filelist U {filename? '-*fileproperties?}

r! = OK

_AddFileExistsESYSTEM

filename?: FILENAME


r!: Response

filename? E dom flelist

r! = FileExists

AddFile - (AuthenticateUser A (AddFileOK v AddFile Exists)) V

AuthenticateUserFail

_ReadFileOKESYSTEM

filename?: FILENAME

fileproperties! :FILEPROPERTIES

r!: Response



r! = OK

69

_ReadFile_NotExists_

ESYSTEM

filename?: FILENAME


r!: Response


r! = FileNotExists

ReadFile (AuthenticateUserA (ReadFileOK V ReadFileNotExists)) V


DeleteFileOKASYSTEM

filename?: FILENAME

r!: Response

filename? E domfilelistVp: processlist p. filename •filename?

filelist'= filelist \ {filename?-*filelist(filename?)}

r! = OK

DeleteFile NotExists

E-SYSTEM

filename?: FILENAME

r!: Response


r! = FileNotExists

70

_DeleteFileFileBeingExecuted

ESYSTEM

filename?: FILENAME

r!: Response




DeleteFile - (AuthenticateUser A (DeleteFileOK V DeleteFileNotExists VDeleteFileFileBeingExecuted)) V AuthenticateUserFail

_ChangeFileOK

ASYSTEM

filename?: FILENAME


r!: Response


filelist'= filelist e {filename? e- properties? }r! = OK

_ChangeFile NotExists2SYSTEM

filename?: FILENAME


r!: Response


r! = FileNotExists

ChangeFile - (AuthenticateUser A (ChangeFileOKV ChangeFile_NotExists))v Authenticate User Fail

71

_StartProcessOKASYSTEM

process-id?: PROCESSID


r!: Response

(let p = {p : processlist I pl .processid = processid?a} -(Vp2:p * p2.state = newstate?) A #p = I A


processlist' = processlist' U p A

r! = OK)

_StartProcessFieNotExists_-

ESYSTEM

process?: PROCESS

r!: Response

process? filename e domfilelist

r! = FileNotExists

_StartProcessUserNotExists__

ESYSTEM

process?: PROCESS

r!: Response

process?.owner E userlist

r! = UserNotExists

StartProcess - (Authenticate User A (StartProcessOKV

StartProcessFileNotExists V StartProcessUserNotExists))


72



r!: Response

3p:processlist p.processid = process-id?

processlist' = processlist\ {p:PROCESSlp.process id = processid?}

r!= OK

_StopProcessProcessIDNotExists

ESYSTEM

process id?: PROCESSID -

r!: Response

Vp:processlist * p.process_id • process-id.?


StopProcess -(AuthenticateUser A (StopProcessOK V

StopProcessProcessIDNotExists)) V AuthenticateUserFail

-ChangeProcess OKASYSTEM



r!: Response

(let p = {p 1: processlist I pl .processid = process-id?} -(Vp2:p * p2.state = newstate?) A #p = I A



r! = OK)

73

ChangeProcessProcessIDNotExistsESYSTEMprocess-id?: PROCESSIDnewstate?: PROCESSSTATEr!: Response

Vp:processlist * p.processid • process id?r! = ProcesslDNotExists

ChangeProcess - (AuthenticateUser A (ChangeProcessOKVChangeProcessProcessIDNotExists)) V AuthenticateUserFail

74

APPENDIX C

Authorization Tactic System Model Specification

[USER]

[FILENAME]

[FILE-PROPERTIES]

[PROCESS-ID]

[PROCESS-STA TE]

Response ::= OKI UserExistslUserNotExistsIFileExistsIFileNotExistsI

ProcessIDNotExistslIncorrectRightsl UserNamesInconsistent

UserRunningProcessIFileBeingExecuted4 UserStillAuthorizedl

FileExecutionStillAuthorized

UserAuthorization ::= AddUserlDelete User

FileAuthorization :: = Add FilelDeleteFile IRead File IChangeFile

ProcessAuthorization :: = StartProcesslStop ProcessIChange Process

ACMAuthorization ::= UserlFilelProcesslACM

PROCESS

filename: FILENAME

owner: USER


state: PROCESSSTATE

75

-SYSTEM

filelist: FILENAME-i->FILE-PROPERTIES


userACM: USER x USER -++ PUserAuthorization

fileA CM: USER x FILENAME --> PFileAuthorization

processACM: (USER x (USER x FILENAME))-÷> PProcessAuthorizationacmACM: USER -14 PACMAuthorization

Vpl, p2: processlist * p1 .process id = p2.processid - p1 = p2Vp: processlist * p filename E domrfilelist A p. owner E userlistdom (dom userACAM) 5 userlist

dom (domnfileACCM) 5 userlist

dom (dom processA CM) S userlist

dom (ran (dom processA CM)) 5 userlist

ran (ran (dom processA CA)) 5 domfilelist


_InitSYSTEM

system: SYSTEM

#systemfilelist= I


#system.processlist = 1

# system.processACM = I

_AddACMACM OKASYSTEM

user?: USER

newUser?: USER

rights?: PACMA uthorization

r! : Response

ACME acmACM(user?)

newUser? E userlist

acmACM' = acmACMU {newUser? -4rights?}

r! =OK

76

AddACMACM UserNotExists

7-SYSTEM

user?: USER

newUser?: USER

rights?: PDACMAuthorization

r!: Response

ACME acmACM(user?)

newUser? X userlist

r! = UserNotExists

AddACMACM IncorrectRightsE-SYSTEM

user?: USER

newUser?: USER

rights?: PACMAuthorization

r! : Response

ACMe acmACM(user?)


AddACMACM - AddACMACM OK V AddACMACM UserNotExists V

AddACMACM IncorrectRights

DeleteACMACM OKASYSTEM

user?: USER

deleteUser?: USER

r! : Response

ACME acmACM(user?)

deleteUser? E userlist

acmACM' = acmACM\ {deleteUser? -* acmACM(deleteUser?)}

r! = OK

77

DeleteACMACM UserNotExistsESYSTEM

user?: USER

deleteUser?: USER

r! : Response

ACMe acmACM(user?)

deleteUser? X userlist

r! = UserNotExists

DeleteACMACM IncorrectRightsESYSTEM

user?: USER

delete User?: USER

r!: Response

ACME acmACM(user?)


DeleteACMACM - DeleteACMACM OK v DeleteACMACM UserNotExists

V DeleteACMACM IncorrectRights

AddUserACM OKASYSTEM

user?: USER

newUser?: USER

addUser?: USER


r! : Response

User E acmACM (user?)

newUser? e userlist

userACM = userACM U {(newUser?,addUser?)-)rights?}

r! =OK

78

AddUserACM IncorrectRights_

ZSYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights? : P UserAuthorization

r!: Response



AddUserACM New UserNotExists_

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights? : P UserAuthorization

r!: Response


newUser? X userlist

r! = UserNotExists

AddUserACM- AddUserACM OK V AddUserACM IncorrectRights V

AddUserACM NewUserNotExists

79

DeleteUserACM OK

ASYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! : Response


newUser? e userlist

userACM = userACM\ {(newUser?, addUser?)-*

userACM(newUser?, addUser?)}

r! = OK

DeleteUserACM IncorrectRights

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! : Response

User X acmACM(user?)


Delete UserACM NewUserNotExists_ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! : Response

User e acmACM (user?)

newUser? E userlist

r! = UserNotExists

80

DeleteUserACM DeleteUserACMOKV DeleteUserACM IncorrectRights v

Delete UserACM New UserNotExists

AddFileACM OK

ASYSTEM

user?: USER

newUser?: USER

file?: FILENAME

rights? : PFileAuthorization

r! : Response

File E acmACM(user?)

newUser? E userlist

fileACM =fileACMU ((newUser?file?)"rights?}

r! = OK

AddFileACM IncorrectRights

ESYSTEM

user?: USER

new User?: USER

file?: FILENAME

rights?: PFileA uthorization

r! : Response

File X acmA CM (user?)


81

AddFileACM UserNotExists

-:SYSTEM

user?: USER

newUser?: USER

file?: FILENAME

rights? : PFileAuthorization

r!: Response


newUser? E userlist

r! = UserNotExists

AddFileACM AddFileACM OK V AddFileACM IncorrectRights V


_DeleteFileACM OK

ASYSTEM

user?: USER

newUser?: USER

file?: FILENAME

r! : Response


newUser? E userlist

fileACM =fileACM\ {(newUser?,file?)-fileACM(newUser?file?)}

_DeleteFileACM IncorrectRights

:SYSTEM

user?: USER

newUser?: USER

file?: FILENAME

r! : Response

File X acmACM(user?)


82

DeleteFileACMUserNotExists

ESYSTEM

user?: USER

newUser?: USER

file?: FILENAME

r! : Response


newUser? X userlist

r! = UserNotExists

DeleteFileACM - DeleteFileACMOK V DeleteFileACM IncorrectRights V

DeleteFileACMUserNotExists

AddProcessACM OK

ASYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME

rights? : PProcessAuthorization

r!: Response

Process E acmACM(user?)

newUser? E userlist

processACM =processACM U {(newUser?,(runAs?,file?))-~rights?}

r! = OK

83

AddProcessACM IncorrectRights

ESYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME

rights?: PProcessAuthorization

r! : Response

Process X acmACM(user?)


AddProcessACM UserNotExists_E-SYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME


r! : Response


newUser? X userlist

r! = UserNotExists

AddProcessACM -AddProcessACM OKv AddProcessACMIncorrectRights v

AddProcessACM UserNotExists

84

DeleteProcessACM OK

ASYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME

r!: Response

Process e acmACM(user?)

newUser? E userlist

processACM = processACM \ {(newUser?,(runAs?,file?))-

processACM(new User?,(runAs?file?))}

r! = OK

DeleteProcessACM IncorrectRightsBSYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME

r! : Response



DeleteProcessACM UserNotExistsESYSTEM

user?: USER

newUser?: USER

runAs?: USER

file? : FILENAME

r! : Response

Process E acrnACM(user?)

newUser? X userlist

r! = UserNotExists

85

DeleteProcessACM - DeleteProcessACM OK v DeleteProcessACM IncorrectRights

V DeleteProcessACM UserNotExists

AddUser Authorization OK

E SYSTEM

user?: USER

newUser?: USER

r!: Response

AddUser E userACM(user?,newUser?)

r! = OK

AddUserAuthorizationFail_ESYSTEM

user?: USER

newUser?: USER

r! : Response

AddUser X userACM(user?,newUser?)


Delete User_A uthorization OK

ESYSTEM

user?: USER

newUser?: USER

r!: Response

DeleteUser E userACM(user?,newUser?)

r! = OK

86

_Delete UserAuthorizationFailESYSTEM

user?: USER

newUser?: USER

r! : Response

DeleteUser i userACM(user?,newUser?)


_AddFile Authorization-OK

ZESYSTEM

user?: USER

file?: FILENAME

r!: Response

Add File e fileACM(user?,file?)

r! = OK

_AddFileAuthorizationFailZSYSTEM

user?: USER

file?: FILENAME

r!: Response

Add File efileACM(user?,file?)


_DeleteFileAuthorizationOK

ESYSTEM

user?: USER

file?: FILENAME

r! : Response

DeleteFile EfileACM(user?,file?)

r! =OK

87

_DeleteFile_AuthorizationFail

ZSYSTEM

user?: USER

file?: FILENAME

r!: Response

DeleteFile EfileACM(user?, file?)


_ReadFile_AuthorizationOKESYSTEM

user?: USER

file?: FILENAME

r! : Response

Read File E fileACM(user?,file?)

r! = OK

_ReadFileAuthorizationFail

BSYSTEM

user?: USER

file?: FILENAME

r!: Response

ReadFile EfileACM(user?,file?)


ChangeFileAuthorizationOK=SYSTEM

user?: USER

file?: FILENAME

r!: Response

Change-File E fleACM(user?,file?)

r! = OK

88

ChangeFileAuthorizationFail

-SYSTEM

user?: USER

file? : FILENAME

r! : Response

Change-File X fileACM(user?,file?)


StartProcessAuthorization OKESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r!: Response

StartProcess e processACM(user?, (runAs?,file?))

r! = OK

StartProcessAuthorization Fail

,SYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r!: Response

StartProcess X processACM(user?, (runAs?, file?))


89

StopProcessAuthorization OK

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r! : Response

Stop Process E processA CM(user?, (runAs?file?))

r! = OK

StopProcess_Authorization Fail

=SYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r!: Response

Stop.Process X processACM(user?, (runAs?file?))


ChangeProcess Authorization OK

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r! : Response

ChangeProcess e processA CM(user?, (runAs? file?))

r! =OK

90

jChangeProcess Authorization Fail

-SYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r! : Response

Change-Process X processACM(user?, (runAs?,file?))


AddUser OK

ASYSTEM

newUser?: USER

r!: Response

newUser? X userlist


r! = OK

AddUserExistsESYSTEM

newUser?: USER

r! : Response

newUser? E userlist

r! = UserExists

AddUser (AddUserAuthorizationOK A (AddUserOK v AddUser-Exists)) V

AddUser Authorization Fail

91

Delete UserOKASYSTEM

deleteUser?: USER

r!: Response


Vp : processlist * p. owner se delete User?

deleteUser? £ dom (dom userACM)

delete User? £ dom (domfileACM)

delete User? £ dom (dom processACM)

delete User? £ dom (ran (dom processA CM))

deleteUser? £ dom acmACM

userlist' = userlist \ { delete User?}

r! = OK

-Delete UserNotExists

ESYSTEM

delete User?: USER

r! : Response

deleteUser? £ userlist

r! = UserNotExists

_Delete User RunningProcess_

E-SYSTEM

deleteUser?: USER

r!: Response


3p: processlist * p. owner = delete User?


92

-Delete UserUserStillAuthorizedESYSTEM

deleteUser?: USER

r! : Response


Vp : processlist * p. owner • delete User?

deleteUser? E dom (dom userACCM) V

deleteUser? E dom (dom fileACM) v

delete User? E dom (dom processACM) V

delete User? E dom (ran (dom processACAM)) V

delete User? E dom acmACM

r! = UserStillAuthorized

Delete User - (Delete User_A uthorization OK A (Delete UserOK V

DeleteUserNotExists V Delete UserRunningProcess V

Delete UserUserStillAuthorized)) V Delete UserAuthorizationFail

AddFileOKASYSTEM

filename?: FILENAME


r! : Response

filename? e dom filelist

filelist' =filelist U {filename? F-fileproperties?}

r! =OK

93

_AddFileExistsESYSTEM

filename?: FILENAME


r!: Response


r! = FileExists

AddFile^- (AddFile Authorization OK A (AddFileOK v AddFileExists)) V

AddFileAuthorizationFail

ReadFileOK

ESYSTEM

filename?: FILENAME


r!: Response



r! = OK

ReadFile NotExistsESYSTEM

filename?: FILENAME

fileproperties! :FILEPROPERTIES

r!: Response

filename? r dom filelist

r! = FileNotExists

ReadFile - (ReadFile_AuthorizationOK A (ReadFileOK V ReadFileNotExists))

V ReadFileAuthorizationFail

94

DeleteFileOKASYSTEM

filename?: FILENAME

r!: Response


Vp: processlist pfilename • filename?

filename? X ran (ran (dom processA CM))

filelist' = flelist \ {filename?"filelist(filename?)}

r! = OK

DeleteFile NotExists

_SYSTEM

filename?: FILENAME

r!: Response

filename? ; domfilelist

r! = FileNotExists


ESYSTEM

filename?: FILENAME

r!: Response


3p: processlist * p. filename = filename?


95

_DeleteFileFileExecutionStillAuthorized

.SYSTEM

filename?: FILENAME

r!: Response


Vp: processlist * p.filename • filename?

filename? e ran (ran (dom processA CM))

r! FileExecutionStillAuthorized

DeleteFile - (DeleteFile AuthorizationOK A (DeleteFile OK V

DeleteFileNotExists V DeleteFileFileBeingExecuted V

DeleteFileFileExecutionStillAuthorized)) V

DeleteFile Authorization-Fail

_ChangeFileOKASYSTEM

filename?: FILENAME


r!: Response


filelist' =filelist e {filename? " properties?}

r! = OK

ChangeFileNotExistsZ-SYSTEM

filename?: FILENAME


r! : Response


r! = FileNotExists

96

ChangeFile - (ChangeFile_Authorization_OK A (ChangeFileOK v

ChangeFileNotExists)) v ChangeFile Authorization Fail

StartProcess OKASYSTEM

process?: PROCESS

runAs?: USER

r!: Response

process?.owner = runAs?

process? filename E domfilelist

Vp:processlist op.process id • process?.process id


r! = OK

StartProcess FileNotExistsESYSTEM

process?: PROCESS

runAs?: USER

r!: Response

process?filename X domfilelist

r! = FileNotExists

StartProcessUserNamesInconsistent

ESYSTEM

process?: PROCESS

runAs?: USER

r!: Response

process?.owner t runAs?

r! = UserNameslnconsistent

97

StartProcess - (StartProcess_A uthorizationOK A (StartProcessOK V

StartProcessFileNotExists V StartProcessUserNameslnconsistent)) V

StartProcess_AuthorizationFail

_StopProcessOKASYSTEM


runAs?: USER

r!: Response

3p:processlist * p.process id = processid? A p.owner = runAs?

processlist' = processlist\ {p:PROCESSLp.process id = process-id?}

r! = OK

_StopProcessProcessIDNotExists__ESYSTEMprocessid?: PROCESSID

runAs?: USER

r!: Response

Vp processlist * p.process id • process-id?

r! = ProcesslDNotExists

_StopProcessUserNameslnconsistent

.SYSTEM


runAs?: USER

r!: Response

3p:processlist * p.process id = process_id?

Vp:processlist * p. owner # runAs?

r! = UserNamesInconsistent

98

StopProcess -(StopProcess_Authorization OK A (StopProcess OK V

StopProcessProcessIDNotExists V

StopProcessUserNamesInconsistent)) V

StopProcess Authorization Fail

_ChangeProcessOKASYSTEM



r!: Response

(letp = {pl: processlist I pl .process id = process-id?} *

(Vp2:p * p2.state = newstate?) A #p = I A

processlist' = processlist\ {p2: processlist I p2.process id = processid'?} A


r! = OK)

_ChangeProcessProcessIDNotExistsESYSTEM



r! : Response

Vp:processlist * p.process id • process-id?


ChangeProcess ̂- (ChangeProcessAuthorization-OK A (ChangeProcessOK V

ChangeProcessProcessIDNotExists)) v

ChangeProcess_AuthorizationFail

99

APPENDIX D

Data Confidentiality Tactic System Model Specification

[USER][FILENAME][FILE PROPERTIES][PROCESS-ID][PROCESS-STA TE][SECRE7IResponse ::= OK UserExistslUserNotExistslFileExistslFileNotExistsI

ProcessIDNotExistslInvalidFileSecretPairIFileExists Differentl

UserRunningProcessIFileBeingExecuted

PROCESSfilename: FILENAMEowner: USERprocessid: PROCESSIDstate: PROCESSSTATE

-SYSTEMfilelist: FILENAME x SECRET -+-FILEPROPERTIESuserlist: P USERprocesslist: P PROCESS

Vppl, p2 : processlist * pl .process id = p2.processid <> pI p2Vp : processlist * pfilename e dom (domfilelist) A p. owner E userlistVf: dom (domfilelist) * V/s], s2: (domfilelist) W[D *filelist(fsl) =filelist(fs2)

100

InitSYSTEM

system : SYSTEM

#system.filelist= I

#system.userlist= I


AddUserOK

ASYSTEM

newUser?: USER

r! : Response

newUser? e userlist

userlist' = userlist U {new User?}

r! =OK

AddUserExists

- SYSTEM

newUser?: USER

r! : Response

newUser? e userlist

r! = UserExists

AddUser AddUserOK V AddUser Exists

DeleteUserOK

ASYSTEM

user?: USER

r! : Response

user? E userlist

Vp : processlist * p. owner - user?


r! =OK

101

-Delete User_NotExists_

ESYSTEM

user?: USER

r!: Response

user? E userlist

r! = UserNotExists

_Delete UsereRunningProcess_

ESYSTEM

user?: USER

r!: Response

user? E userlist



Delete Use - Delete UserOKV Delete User NotExists V Delete User RunningProcess

_AddFileOKASYSTEM

filename?: FILENAME

secret?: SECRET


r! : Response


filename? E dom (domfilelist) V (Vs: (domfilelist) Q {filename?D} S

fileproperties? =filelist(filename?,s))

filelist'= flelist U {(filename?,secret?) "fileproperties?}

r! = OK

102

AddFileExists

ESYSTEM

filename?: FILENAME

secret?: SECRET


r!: Response

(filename?, secret?) E domfilelist

r! = FileExists

AddFile Exists Diff

_SYSTE'M

filename?: FILENAME

secret?: SECRET


r! : Response

filename? E dom (domfilelist)Vs : (domfilelist) @ {filename?} I * s t secret?

9s: (domfllelist) q {filename?} D *filelist(filename?,s) •fileproperties?

r! = FileExists-Different

AddFile - AddFileOK V AddFileExists V AddFile ExistsDiff

_ReadFileOKESYSTEM

filename?: FILENAME

secret?: SECRET

fileproperties! : FILEPROPERTIES

r!: Response


fileproperties! =filelist(filename?,secret?)

r! = OK

103

_ReadFileNotExists_ESYSTEM

filename?: FILENAME

secret?: SECRET


r!: Response


r! = InvalidFileSecretPair



filename?: FILENAME

secret?: SECRET

r!: Response

(filename?, secret?) e domfilelist

Vp: processlist * p.filename •tfilename?

(let secretlist = = ((dom filelist) ( {filename?} I) -

filelist'= filelist \ ({filename?} xsecretlist) <filelist)

r! = OK

_DeleteFileNotExistsFSYSTEM

filename?: FILENAMEsecret?: SECRET

r!: Response

(filename?, secret?) X domfilelist


104

_DeleteFile FileBeingExecuted

ESYSTEM

filename?: FILENAME

secret?: SECRET

r!: Response

(filename?, secret?) E domfilelist

3p processlist 0 p. filename =filename?

r! FileBeingExecuted



_ChangeFile OK

ASYSTEM



r!: Response

(filename?,secret?) e domfilelist

(let secretlist = = ((dom filelist) J {filename?} I)S

filelist' =filelist e (({filename?} xsecretlist)x {properties?}))

r! = OK

_ChangeFileNotExists

ESYSTEM



r!: Response

(filename?,secret?) r dom filelist


105

ChangeFile - ChangeFile_OK v ChangeFile NotExists


process?: PROCESS

secret?: SECRET

r!: Response


(process? .filename,secret?) E domfilelist

Vp:processlist *p.process id • process?.process id

processlist'= processlist U {process?}

r! = OK

_StartProcessFileNotExists-

ESYSTEM

process?: PROCESSsecret?: SECRET

r!: Response

(process? filename, secret?) i domfilelist


_StartProcess_ UserNotExists__FSYSTEM

process?: PROCESS

r!: Response

process?.owner i userlist

r! = UserNotExists

StartProcess - StartProcessOK V StartProcessFileNotExists V

StartProcessUserNotExists

106

_StopProcessOK

ASYSTEM


r!: Response

3p:processlist * p.process id = process id?

processlist' = processlist\ {p:PROCESSlp.process id = process id?}

r! = OK

_StopProcessProcessDeNotExists_ESYSTEM


r!: Response

Vp:processlist p.processid f process-id.?


StopProcess s- StopProcessOK V StopProcessProcesslDNotExists

_C/rangeProcess_OK_

ASYSTEM



r!: Response

(let p = {p I: processlist I pl .processid = process id?} -


processlist' processlist\ {p2: processlist I p2.process-id = process-id?} A


r! = OK)

107

_ChangeProcessProcessIDNotExists.SYSTEM



r!: Response

Vp:processlist * p process__id • process id?



108

APPENDIX E

Data Integrity Tactic System Model Specification

[USER]

[FILENAME]

[FILE-INFO]

[INTEGRITY CHECK]

[PROCESS-ID]

[PROCESSSTATE]

[INTEGRITY CONTROL]

Response :: = OK UserExistsl UserNotExistslFileExistslFileNotExistsl

ProcessIDNotExistsIlnvalidIntegrityCheckI UserRunningProcess

IFileBeingExecuted

INTEGRITYMAP: FILEINFO x INTEGRITY CONTROL

>|H INTEGRITY CHECK

FILE PROPERTIES

info: FILE-INFOintegrity: INTEGRITY CHECK

1ic: INTEGRITY CONTROL * INTEGRITY MAP(info, ic) = integrity

PROCESS

filename: FILENAME

owner: USER

process-id: PROCESSID

state: PROCESSSTATE

109

-SYSTEM

filelist: FILENAME-++FILEPROPERTIES

userlist: P USER

processlist: PD PROCESS

Vpl, p2 : processlist * p .process id = p2.processid - p1 = p2Vp: processlist * p filename E domfilelist A p. owner E userlist

Check Integrity

ESYSTEM

filename?: FILENAME

ic?: INTEGRITYCONTROL


INTEGRITY MAP((filelist(filename?)). info, ic?) = (filelist(filename?)).integrity

_CheckIntegrityFailESYSTEM

filename?: FILENAME


r!: Response


INTEGRITY MAP((filelist(filename?)).info, ic?) •1 (filelist(filename?)).integrity


_InitSYSTEMsystem: SYSTEM

#system filelist = I

#system.userlist= I


110

_AddUserOK __

ASYSTEM

new User?: USER

r! Response

newUser? i userlist

userlist'= userlist U {newUser?}

r! = OK

_AddUser Exists __ -

ESYSTEM

newUser?: USER

r!: Response

newUser? E userlist

r! = UserExists

AddUser ̂ - AddUserOK V AddUser Exists

_DeleteUser OKASYSTEM

user?: USER

r! : Response

user? E userlistVp : processlist * p. owner • user?

userlist' = userlist \ {user? }r! = OK

ill

Delete User_Not Exists_

ESYSTEM

user?: USER

r! : Response

user? E userlist

r! = UserNotExists

Delete User RunninProcess__

E-SYSTEM

user?: USER

r!: Response

user? E userlist



Delete Use - Delete UserOK V Delete UserNotExists V Delete User RunningProcess

AddFile OKASYSTEM

filename?: FILENAME

fileproperlies?: FILEPROPERTIES

r!: Response


3ic : INTEGRITYCONTROL * INTEGRITY MAP(fileproperties?. info,ic)

-fileproperties?. integrity

filelist'= filelist U {filename? -fileproperties?}

r! = OK

112

_AddFileExists

ESYSTEM

filename?: FILENAME


r!: Response


r! = FileExists

_,AddFileIntegrityFail,_ESYSTEM

filename?: FILENAME


r!: Response

filename? G domfilelist

-(Iic: INTEGRITY CONTROL * INTEGRITY MAP(fileproperties?. info,ic)

= fileproperties?. integrity)


AddFile - AddFileOK V AddFileExists V AddFileIntegrityFail

ReadFileOKESYSTEM

CheckIntegrity

filename?: FILENAME


r!: Response



r! = OK

k

113

_ReadFileNotExists__ _

ESYSTEM

filename?: FILENAME


r!: Response


r! = FileNotExists

ReadFile ReadFileOK V ReadFileNotExists V Check IntegrityFail


filename?: FILENAME

r!: Response

filename? e dom filelistVp: processlist * p.filename •filename?

filelist' =filelist \ {filename?" filelist(filename?)}

r! = OK

_DeleteFileNotExists

ESYSTEM

filename?: FILENAME

r!: Response


r! = FileNotExists

114

_DeleteFile FileBeingExecuted

ESYSTEM

filename?: FILENAME

r!: Response

filename? E dom filelist




DeleteFile FileBeingExecuted


CheckIntegrity

filename?: FILENAME


r!: Response

filename? c dom filelist

3ic: INTEGRITYCONTROL * INTEGRITY MAP(properties?.info,ic)

= properties?. integrity

filelist' =filelist 9 {filename? -4 properties?}

r! = OK

_ChangeFileNotExistsESYSTEM

filename?: FILENAME


r!: Response


r! = FileNotExists

115

_ChangeFile-Integrity_Fail

-SYSTEM

filename?: FILENAME


r!: Response


-(3ic: INTEGRITY CONTROL * INTEGRITY MAP(properties?.info,ic)= properties?. integrity)

filelist' =filelist e {filename? " properties?}


ChangeFile ChangeFileOK V ChangeFileNotExists V CheckIntegrityFail

V ChangeFileIntegrityFail


CheckIntegrity

process?: PROCESS

r!: Response

process?.owner E userlistprocess?Jfilename e domflelist

Vp:processlist op.process id t process?.process id


r! = OK

StartProcessFileNotEixists

ESYSTEM

process?: PROCESS

r!: Response

process?filename E domfilelist

r! = FileNotExists

116

StartProcess-UserNotExists_

.ESYSTEM

process?: PROCESS

r!: Response


r! = UserNotExists

StartProcess - StartProcess OK V StartProcessFileNotExists V

StartProcessUserNotExists v CheckIntegrity.Fail

StopProcessOK

ASYSTEM

CheckIntegrity


r!: Response

3p:processlist * p.processid = process-id?

processlist' = processlist\ {p:PROCESS~p.process id = process id`?}

r! = OK

StopProcessProcessIDNotExists_ESYSTEM


r!: Response

Vp:processlist * p.processid # processid?

r! = ProcessiDNotExists

StopProcess StopProcess OK V StopProcess ProcessIDNotExists V

Check IntegrityFail

117

ChangeProcessOK

ASYSTEM

CheckIntegrity



r!: Response

(let p = {p 1: processlist p pl .processid = process-id?} -

(Vp2:p * p2 .state = newstate?) A #p = I A

processlist'= processlist\ {p2: processlist I p2.process-id = process-id?} A


r! = OK)

ChangeProPrc eProcessIDNotExists_-SYSTEM



r! : Response

Vp:processlist * p.processid • process id?



V CheckIntegrity.Fail

118

APPENDIX F

Auditing Tactic System Model Specification

[USER]

[FILENAME]

[FILE PROPERTIES]

[FILE-CHANGE]

[PROCESS-STA TE]

[PROCESS STATE CHANGE]

[PROCESS ID]

UserAction = Add UserlDeleteUser

FileAction = Add FilelDelete File |Read File IChange File

ProcessAction ::= StartProcessIStop ProcessIChange_Process

Response ::= OK] UserExistslUserNotExistslFileExistslFileNotExistsl

ProcessIDNotExistsl UserRunningProcessIFileBeingExecuted

FILECHANGEMAP: FILEPROPERTIES x FILECHANGE- FILEPROPERTIES

FILEPROPERTIESMAP: FILEPROPERTIES x FILEPROPERTIESFILECHANGE

PROCESSSTATECHANGEMAP: PROCESSSTATE x

PROCESSSTATECHANGE-* PROCESSSTATE

PROCESSSTATEMAP: PROCESSSTATE x PROCESSSTATE

-* PROCESSSTATECHANGE

119

-UserLogElement

user: USER

action: UserAction

FileLogElement

filename: FILENAME

action : FileAction

filechange: FILE-CHANGE

ProcessLogElement


filename: FILENAME

owner: USER

action : ProcessAction


jogElement

u: PUserLogElement

f: PFileLogElement


r : Response

#u+#f+#p = 1

PROCESS

filename: FILENAME

owner: USER


state: PROCESSSTATE

120

SYSTEM

filelist: FILENAME--+-FILEPROPERTIES

userlist: P USER

processlist: P. PROCESS

userauditpolicy: P(USER x UserAction)

fileauditpolicy: P(FILENAME x FileAction)

processauditpolicy: P(USER x FILENAME x ProcessAction)

log: seq LogElement

Vp 1, p2 : processlist * p .processid = p2.process id ,> p1 = p2

Vp : processlist * p.filename E domfilelist A p. owner c userlist

InitSYSTEM

system: SYSTEM

#system.filelist= I

#system.userlist= I

#system.processlist=

system. log= =

AddUser OKASYSTEM

newUser?: USER



r!: Response

newUser? E userlist


r! = OK

(new User?, Add User) i userauditpolicy V (userlogelement.user = new User? A

userlogelement.action = AddUser A logelement.r = r! A

logelement.u = {userlogelement} A logelementf = 0 A


121

_AddUserExistsASYSTEM

newUser?: USER



r! : Response

newUser? E userlist

r! = UserExists

(newUser?, AddUser) E userauditpolicy V (userlogelement.user newUser? A



logelement.p = 0 A log' = log (logelement~)

AddUser - AddUser OK v AddUserExists

_DeleteUserOK

ASYSTEM

user?: USER



r! : Response

user? E userlist

Vp : processlist * p. owner • user?


r! = OK

(user?, Delete User) i userauditpolicy V (userlogelement.user user? A

userlogelement.action = DeleteUser A logelementr = r! A

logelement. u = {userlogelement} A logelementf = 0 A

logelement.p = 0 A log' = log logelementl)

122

Delete UserNotExistsASYSTEM

user?: USER



r!: Response

user? ( userlist

r! = UserNotExists

(user?, Delete User) i userauditpolicy V (userlogelement.user = user? A

userlogelement.action = Delete User A logelement.r = r! A

logelernent.u = {userlogelement} A logelementf = 0 A

logelement.p = 0 A log' = log^<logelement>)

_Delete UserRunningProcess

ASYSTEM

user?: USER



r!: Response

user? E userlist


(user?, Delete User) E userauditpolicy V (userlogelement.user user? A

userlogelement.action = Delete User A logelement.r = r! A


logelement.p = 0 A log' = log(logelementl)


Delete Use - Delete UserOKV Delete UserNotExists V Delete UserRunningProcess

123

_AddFile_OK __ASYSTEM

filename?: FILENAME




r!: Response

filename? c domfilelist

filelist' =filelist U {filename? "fileproperties?}

r! = OK

(filename?, Add File) t fileauditpolicy V (filelogelement.filename=filename? A

filelogelement.action = AddFile A logelement.r = r! A

logelement.u = 0 A logelementf = {filelogelement} A

logelement.p = 0 A log' = loge(logelement>)

AddFile ExistsASYSTEM

filename?: FILENAME




r! : Response


r! = FileExists

(filename?, Add File) t fileauditpolicy V (filelogelement. filename= filename? A

filelogelement.action = Add File A logelement.r = r! A

logelement.u = 0 A logelement.f = {filelogelement} A

logelement.p = 0 A log' = log-(logelement>)

AddFile - AddFile_0K V AddFileExists

124

_ReadFileOK

ASYSTEM

filename?: FILENAME

fileproperties! FILEPROPERTIES

filelogelement FileLogElement


r!: Response



r! = OK

(filename?, ReadFile) itfileauditpolicy V (filelogelement.filename= filename? A

filelogelement.action = ReadFile A logelement.r = r! A


logelement.p = 0 A log' = log(logelement))

_ReadFileNotExists_ASYSTEM

filename?: FILENAME




r! : Response


r! = FileNotExists

(filename?, ReadFile) izfileauditpolicy V (filelogelement.filename= filename? A



logelement.p = 0 A log' = log (logelement>)

ReadFile - ReadFileOKV ReadFile NotExists

125

_DeleteFileOK

ASYSTEM

filename?: FILENAME



r!: Response


filelist' =filelist \ {filename? -filelist(filename?)}

r! = OK

(filename?, DeleteFile) i fileauditpolicy V (filelogelement.filename= filename? A

filelogelement.action = DeleteFile A logelement.r = r! A


logelement.p = 0 A log'= loge'logelementl)

_DeleteFileNotExists-

ASYSTEM

filename?: FILENAME



r!: Response


r! = FileNotExists

(filename?, DeleteFile) fileauditpolicy V (filelogelement. filename= filename? A



logelement.p = 0 A log' = logelogelement~)

126

DeleteFileFileBeingExecutedASYSTEM

filename?: FILENAME



r!: Response


3p processlist Op. filename = filename?

r!= FileBeingExecuted

(filename?, DeleteFile) e fileauditpolicy V (filelogelement.filename= filename? A




DeleteFile - DeleteFileOK v DeleteFileNotExists V


127


filename?: FILENAME


filechange: FILE CHANGE


logelement!: LogElement

r! : Response


filelist'= filelist eD {filename? -+ properties?}

r! = OK

(filename?, ChangeFile) £ fileauditpolicy V (filelogelement filename = filename? A

filelogelement.action = ChangeFile A

filechange = FILEPROPERTIES MAP(ftlelist(filename?), properties?) A

FILE_CHANGE_MAP(filelist(filename?),filechange) =properties? A

filelogelement.filechange =filechange A logelement!.r = r! A

logelement!. u = 0 A logelement!f= {filelogelement} A

logelement!.p = 0)


ASYSTEM

filename?: FILENAME




r! : Response

filename? £ domfilelist

r! = FileNotExists

(filename?, Change_File) efileauditpolicy V (filelogelement.filename= filename? A

filelogelement.action = ChangeFile A logelementr = r! A

logelement.u = 0 A logelement.f = tfilelogelement} A

logelement.p = 0 A log' = log ( logelement>)

ChangeFile - ChangeFileOK V ChangeFileNotExists

128


process?: PROCESS

processlogelement: ProcessLogElement


r!: Response



Vp:processlist Op.process id • process?.process id


r! = OK

(process?. owner, process?filenameStartProcess) ; processauditpolicy V

(processlogelement.process id = process?.process id Aprocesslogelement filename = process?filename A

processlogelement. owner = process?.owner A processlogelement. action = StartProcess Alogelement. r = r! A logelement. u = 0 A logelementf = 0 A

logelement.p = {processlogelement} A log'= log (logelement>)

_StartProcess FileNotExists

ASYSTEM

process? PROCESS



r!: Response

process? filename 6 domfilelist

r! = FileNotExists

(process?. owner, process?filenameStartProcess) e processauditpolicy V

(processlogelement.processid = process?.process id A

processlogelement filename = process?.filename A

processlogelement. owner = process?.owner A processlogelement. action = StartProcess A

logelement.r = r! A logelement.u = 0 A logelement j = 0 A

logelement.p = lprocesslogelement} A log' = log(logelement))

129

StartProcessUserNotExists--SYSTEM

process?: PROCESS



r! : Response


r! = UserNotExists

(process?. owner, process?filenameStartProcess) e processauditpolicy v

(processlogelement.process id =process?.process id A

processlogelement filename = process?.filename A

processlogelement. owner = process?.owner A

processlogelement. action = StartProcess A


logelement.p = {processlogelement} A log'= logelogelement~)

StartProcess - StartProcessOK V StartProcessFileNotExists V

StartProcess_ UserNotExists

I

130

_StopProcessOK

ASYSTEM



process: PROCESS


r! : Response

3p:processlist p.processid = process id?processlist' = processlist\ {p:PROCESSlp.processid = process-id?}

r! = OK

]p1: processlist * process = p1 ApI .process id = process id.?(process. owner, process filename, Stop Process) e processauditpolicy V(processlogelement.processid = process.processid Aprocesslogelement filename = process filename A

processlogelement. owner = process.owner A processlogelement. action = StopProcess Alogelement. r = r! A logelement. u = 0 A logelementf = 0 A

logelement.p = {processlogelement} A log' = loge'logelement>)

StopProcessProcesscDNotExists_

ESYSTEM




r! Response

Vp:processlist p.processid # process-id?


(V owner: USER * (Vfilename: FILENAME -

(owner, filename, Stop Process) e processauditpolicy)) V(processlogelement. action = StopProcess A

logelement.r = r! A logelement. u = 0 A logelementf = 0 A

logelement.p = {processlogelement} A log' = logelogelement))

131

StopProcess - StopProcess OK V StopProcessProcessIDNotExisis

_ChangeProcessOK

ASYSTEM


newstate?: PROCESS STATE

processchange: PROCESSSTATE_CHANGE



r!: Response

(let p ={p 1: processlist I p Lprocessid = processidI} *


processlist' = processlist\ {p2 : processlist I p2.process-id = process id?} A


r! = OK/A

(Vp l: p * ((p 1. owner, p lfilename, Change Process) i processauditpolicy V

(processlogelement.processid = process id? A

processlogelement filename = p1 .filename A

processlogelement. owner = pl .owner A

processlogelement.action = Change Process A

processchange = PROCESSSTATEMAP(pl.state, newstate?) Anewstate? = PROCESSSTATECHANGE_MAP(pl .state, processchange) Aprocesslogelement.processchange = processchange A

logelement.r = r! A logelement.u = 0 A logelementf = 0 A

logelement.p = {processlogelement} A log'= loge(logelement>))))

132

ChangeProcessProcessIDNotExistsWSYSTEM





r!: Response

Vp:processlist * p.processid s processid?


(V owner: USER * (Vfilename: FILENAME a

(owner,filename, ChangeProcess) S processauditpolicy)) V

(processlogelement.action = Change Process A


logelement.p = {processlogelement} A log'= loge(logelement>)


133

APPENDIX G

Intrusion Detection Tactic System Model Specification

[USER][FILENAME][FILE PROPERTIES][FILE_CHANGE][PROCESS STATE][PROCESSSTA TECHANGE][PROCESS-ID]UserAction = Add UserlDelete UserFileAction = AddFilelDelete File IRead File lChange FileProcessAction ::= StartProcesslStopProcesslChangeProcessResponse ::= OK1 UserExistslUserNotExistslFileExistslFileNotExistsl

ProcessIDNotExistsl UserRunningProcesslFileBeingExecuted

FILECHANGEMAP: FILEPROPERTIES x FILECHANGE- FILEPROPERTIES

FILEPROPERTIESMAP: FILEPROPERTIES x FILEPROPERTIES| FILECHANGE

PROCESSSTATECHANGE_MAP: PROCESSSTATE xPROCESSSTATECHANGE-* PROCESSSTATE

PROCESSSTA TEMAP : PROCESSSTA TE x PROCESSSTA TE-| PROCESSSTATECHANGE

134

-UserLogElement

user: USER

action: UserAction

FileLogElementfilename : FILENAME

action: FileAction

filechange: FILE-CHANGE

ProcessLogElement


filename: FILENAME

owner: USER

action: ProcessAction

processchange : PROCESSSTATECHANGE

JLogElement

u: PUserLogElement

f: PFileLogElement


r: Response

#u+#f+#p= I

135

IDSAlert

ASYSTEM

sublog: P (P N.)

newalertlog: seq (seq, LogElement)

log'; log

Vsl: sublog * sll log' E idspolicy A (sll log') in newalertlog A

(Bp: N. * (lastJDSAnalysis < p #log' A p E sO)idsalertlist' = idsalertlisC'newalertlog

lastIDSAnalysis' = #log'

IDSNoAlert

ESYSTEM

log' = log

idsalerilist' = idsalertlist

IDS System J IDS Alert V IDSNoAlert

PROCESSfilename: FILENAME

owner: USER

processid: PROCESSID

state : PROCESSSTATE

136

SYSTEMfilelist: FILENAME-÷-FILEPROPERTIES

userlist: P USER


userlogpolicy: P(USER x UserAction)

filelogpolicy: P(FILENAME x FileAction)

processlogpolicy: P(USER x FILENAME x ProcessAction)

log: seq LogElement

idspolicy: P(seq, LogElement)

idsalertlist: seq(seq, LogElement)

lastlDSAnalysis: N

Vpl, p2 : processlist * pl .processid = p2.process id X pl = p2

Vp : processlist * pfilename E domfilelist A p. owner c userlist

_InitSYSTEM

system: SYSTEM

#systemfilelist = I

#system.userlist= I


system. log = )

system. idsalertlist = ()system. lastlDSAnalysis = 0

137

_AddUserOK

ASYSTEM

IDSSystem

newUser?: USER



r! : Response

newUser? 6 userlist

userlist' = userlist U {new User? }r! = OK

(new User?, AddUser) E userlogpolicy v (userlogelement.user = new User? A



logelement.p = 0 A log' = log^(logelement))

_AddUser ExistsASYSTEM

IDS System

newUser?: USER



r! : Response

newUser? e userlist

r! = UserExists

(new User?, AddUser) E userlogpolicy v (userlogelement.user = newUser? A


logelement.u = { userlogelement} A logelementf = 0 A

logelement.p = 0 A log' = log(logelement))

AddUser AddUser-OK V AddUser Exists

138

-Delete UserOK

ASYSTEM

IDSSystem

user?: USER



r! : Response

user? e userlist

Vp : processlist * p.owner # user?


r! = OK

(user?, Delete User) i userlogpolicy v (userlogelement.user = user? A

userlogelement.action = DeleteUser A logelement.r = r! A


logelement.p = 0 A log' = log (logelement))

_Delete UserNotExistse _

ASYSTEM

IDSSystem

user?: USER



r! : Response

user? e userlist

r! = UserNotExists

(user?, Delete User) e userlogpolicy v (userlogelement.user = user? A



logelement.p = 0 A log' = log:h'logelement~)

139

-Delete UsereRunningProcess_

ASYSTEM

IDSSystem

user?: USER



r!: Response

user? E userlist


(user?, Delete User) i userlogpolicy V (userlogelement.user user? A



logelement.p = 0 A log' = log (logelement~)


Delete Use - Delete UserOK V Delete User NotExists V

Delete UserRunningProcess

AddFileOK

ASYSTEM

IDSSystem

filename?: FILENAME

fileproperties? : FILEPROPERTIES



r! : Response

filename? v domfilelist

filelist'= filelist U {filename? e-fileproperties?}

r! = OK

(filename?, Add File) Efilelogpolicy V (filelogelement.filename= flename? A

filelogelement.action = AddFile A logelement.r = r! A



140

AddFileExists __ _ _____ _

ASYSTEM

IDSSystem

filename?: FILENAME

fileproperties? FILE PROPERTIES

filelogelement FileLogElement


r!: Response

filename? E dom filelist

r! = FileExists

(filename?, Add-File) X filelogpolicy V (filelogelement.filename= filename? A

filelogelement.action = Add File A logelement.r = r! A



AddFile - AddFileOK V AddFileExists

_ReadFile _OKASYSTEM

IDS System

filename?: FILENAME




r!: Response



r! = OK

(filename?, Read File) Efilelogpolicy V (filelogelement.filename= filename? A

filelogelement.action = Read_File A logelement.r = r! A

logelement. u = 0 A logelemenl.f = {filelogelement} A

logelement.p = 0 A log' = log-'(logelement))

141

ReadFileNotExists

ASYSTEM

IDS System

filename?: FILENAME




r!: Response


r! = FileNotExists

(filename?, ReadFile) 6 filelogpolicy V (filelogelement. filename= filename? A

filelogelement.action = ReadFile A logelement.r = r! A


logelement.p = 0 A log' = log^<logelement>)



IDS System

filename? : FILENAME



r!: Response


Vp : processlist * pfilename • filename?

filelist' = flelist \ {filename? -- filelist(filename?)}

r! = OK

(filename?, DeleteFile) e filelogpolicy V (filelogelement. filename=filename? A

filelogelement.action = Delete File A logelement.r = r! A


logelement.p = 0 A log' = loge(logelementf)

142

_DeleteFileNotExists_

ASYSTEM

IDS System

filename?: FILENAME



r!: Response


r! = FileNotExists

(filename?, DeleteFile) E filelogpolicy V (filelogelement. filename= filename? A

filelogelement.action = Delete File A logelement.r = r! A


logelement.p = 0 A log' = logA-logelement~)

_DeleteFileFileBeingExecuted

ASYSTEM

IDS System

filename?: FILENAME



r!: Response


3lp processlist *op. filename = filename?


(filename?, DeleteFile) E filelogpolicy V (filelogelement. filename= flename? A



logelement.p = 0 A log' = logelogelement~)


DeleteFile FileBeingExecuted

143

_ChangeFileOK

ASYSTEM

IDSSystem

filename? FILENAME


filechange: FILE CHANGE


logelement!: LogElement

r!: Response


filelist' =filelist e tfilename? - properties? }r! = OK

(filename?, ChangeFile) efilelogpolicy V (filelogelement.filename =filename? A

filelogelement. action = ChangeFile A

filechange = FILEPROPERTIESMAP(filelist(filename?), properties?) A

FILECHANGE_MAP(filelist(filename?),filechange) = properties? A

filelogelementfilechange =filechange A logelement!.r = r! A

logelement!.u = 0 A logelement!.f = {filelogelement} A

logelement!.p = 0)

ChangeFileNotExists

ASYSTEM

IDSSystem

filename?: FILENAME




r!: Response

filename? L domfilelist

r! = FileNotExists

(filename?, ChangeFile) i filelogpolicy V (filelogelement. filename= filename? A

filelogelement.action = ChangeFile A logelement.r = r! A


logelement.p = 0 A log' = loge(logelement~)

144

ChangeFile - ChangeFile_0Kv ChangeFileNotExists


IDSSystem

process?: PROCESS



r! : Response

process?.owner e userlist

process? filename E domfilelist

Vp:processlist p.process id • process?.process id

processlist' = processlist U {process? }r! = OK

(process?. owner, process?.filename,StartProcess) E processlogpolicy V

(processlogelement.process id = process?.processid A

processlogelement filename = process?filename A


processlogelement.action = StartProcess A


logelement.p = {processlogelement} A log' = log (logelement~)

145

StartProcess FileNotExists __

ASYSTEM

IDSSystem

process?: PROCESS



r!: Response


r! = FileNotExists

(process?. owner, process?.filenameStartProcess) E processlogpolicy V


processlogelement.filename = process?filename A

processlogelement. owner =process?.owner A


logelement.r = r! A logelement. u = 0 A logelement.f = 0 A

logelement.p = {processlogelement} A log'= logelogelement~)

_StartProcess UserNotExists__

ASYSTEM

IDSSystem

process?: PROCESS



r! : Response

process?.owner r userlist

r! = UserNotExists

(process?. owner, process?filenameStartProcess) E processlogpolicy V


processlogelementifilename =process?filename A




logelement.p = {processlogelement} A log' = logelogelement))

146

StartProcess StartProcessOK V StartProcessFileNotExists V

StartProcessUserNotExists

StopProcessOK

ASYSTEM

IDS System



process: PROCESS


r!: Response

3p:processlist * p.process id = processid?

processlist' = processlist\ {p:PROCESS~p.processid = process-id.}

r! = OK3pl : processlist * process = pl A p .processid = processid?

(process. owner, process filename, StopProcess) - processlogpolicy V

(processlogelement.process id = process.process id A

processlogelement filename = process filename A

processlogelement. owner =process.owner A,

processlogelement. action = Stop_Process A


logelement.p = {processlogelement} A log'= loge(logelement))

147

StopProcessProcesslDNotExists

ASYSTEM

IDS System



process: PROCESS


r!: Response

Vp:processlist * p.process id • process id?


(V owner: USER * (Vfilename: FILENAME -

(owner, filename, Stop.Process) X processlogpolicy)) V

(processlogelement.action = Stop Process A

logelement.r = r! A logelement.u = 0 A logelementf = 0 A

logelement.p = {processlogelement} A log' = logClogelement>)

StopProcess ̂ - StopProcessOK V StopProcessProcesslDNotExists

148


IDSSystem

process iad?: PROCESSID





r!: Response

(let p = {p l: processlist I pl .processid = process-id?} 0


processlist' - processlist\ {p2: processlist p2.process id = process id? } A


r! =OKA

(VpI :p * (p1. owner, pl .filename, ChangeProcess) V processlogpolicy V

(processlogelement.process id = processid? A

processlogelement filename =pl filename A

processlogelement. owner =p .owner A

processlogelement.action = ChangeProcess A

processchange = PROCESSSTATEMAP(pl.state, newstate?) A

newstate? = PROCESSSTATE_CHI4NGE MAP(p .state, processchange) A

processlogelement.processchange = processchange A

logelement.r = r! A logelement. u = 0 A logelement.f = 0 A

logelement.p = {processlogelement} A log'= logelogelement>)))

149

ChangeProcessProcessIDNotExists_ASYSTEM

IDS System


newstate?: PROCESS_STATE


process: PROCESS


r!: Response

Vp:processlist p.processid • process id?r! = ProcessIDNotExists

(V owner: USER * (kfilename: FILENAME a

(owner,filename, Change Process) X processlogpolicy)) V

(processlogelement.action = Change Process A


logelement.p = {processlogelement} A log' = log (logelement))

ChangeProcess - ChangeProcessOK V ChangeProceyssProcessIDNotExists

150

APPENDIX H

Combined Authorization and Authentication

System Model Specification

[USER]

[FILENAME]

[FILEPROPERTIES]

[PROCESS ID]

[PROCESS STATE]

[AUTHENTICATIONCONTROL]

Response : = Ok UserExistsl UserNotExistslFileExistslFileNotExistsI

ProcessIDNotExistslIncorrectRightsI UserNamesInconsistentj

InvalidUserA uthenticationControlPairl UserRunningProcessl

FileBeingExecutedl UserStillAuthenticatedl UserStillA uthorizedl

FileExecutionStillA uthorized

UserAuthorization ::=Add UserlDeleteUser

AuthenticationAuthorization ::= AddA uthenticationIDeleteAuthentication

FileAuthorization :: = Add FilelDeleteFile IReadFile JChangeFile

ProcessA uthorization::= StartProcess StopProcessl ChangeProcess

A CMAuthorization :=: UserlFilelProcesslA uthenticationlACM

PROCESS

filename: FILENAME

owner: USER


state: PROCESSSTATE

151

-SYSTEMfilelist: FILENAME-+*FILEPROPERTIES

userlist: P USER


authenticated: USER -+* PA UTHENTICA TIONCONTROL

userA CM: USER x USER -+> PUserAuthorization

fileA CM: USER x FILENAME -±> PFileAuthorization

processACM: (USER x (USER x FILENAAME))-++ PProcessAuthorization

authenticationACM: USER x USER -+-> PAuthenticationAuthorization

acmACM: USER -+ PACMAuthorization

Vp1, p2 : processlist * pI .process id = p2.process-id = pI =p2Vp * processlist - pfilename E dom filelist A p. owner E userlist


dom (dom userACCM) S userlist


dom (dom processA CM) S userlist

dom (ran (dom processA CM)) 5 userlist

ran (ran (dom processACAM)) 5 dom filelistdom (dom authenticationACCM) 5 userlist


_AuthenticateUser

ESYSTEM

u?: USER

ac? : A UTHENTICA TION CONTROL

r! : Response

ac? E authenticated(u?)

r! = OK

152


ESYSTEM

u?: USER

ac?: AUTHENTICATIONCONTROL

r! : Response

ac? X authenticated(u?)


InitSYSTEMsystem: SYSTEM

#systemfilelist= I

#system.authenticated= I



# system.processACM= I

AddACMACMOKASYSTEM

user?: USER

new User?: USER

rights? : ACLCM4uthorization

r!: Response

ACMc acmACM(user?)

newUser? E userlist

acmACM' = acmACMU (newUser?"rights?}

r! = OK

153

_AddACMACM_ UserNotExistsZ-SYSTEM

user?: USER

newUser?: USER


r! : Response

ACMe acmACM(user?)

newUser? e userlist

r! = UserNotExists

_AddACMACM IncorrectRights7-SYSTEM

user?: USER

newUser?: USER


r! : Response

ACMEx acmACM(user?)


AddACMACM - (Authenticate User A (AddACMACMOK vAddACMACM UserNotExists V AddACMACM IncorrectRights)) v

Authenticate_UserFail

_DeleteACMACM OKASYSTEM

user?: USER

deleteUser?: USER

r! : Response

ACMe acmACM(user?)


acmACM' = acmACM\ {deleteUser?-4 acmACM(deleteUser?)}

r! = OK

154

DeleteACMACM UserNotExistsBSYSTEM

user?: USER

deleteUser?: USER

r!: Response

ACME acmACM(user?)


r! = UserNotExists

DeleteACMACM IncorrectRightsESYSTEM

user?: USER

delete User?: USER

r!: Response

ACME acmACM(user?)


DeleteACMACM (AuthenticateUser A (DeleteACMACM OK V

DeleteACMACM UserNotExists V

DeleteACMACM IncorrectRights)) V AuthenticateUserFail

155

AddUserACM OK

ASYSTEM

user?: USER

newUser?: USER

addUser?: USER


r! : Response

User E acmA CM(user?)

newUser? E userlist

userACM = userACMU f(newUser?,addUser?)"rights?}

r! = OK

AddUserACM IncorrectRights_

Z-SYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights?: PUserAuthorization

r! : Response



AddUserACM New UserNotExists_ESYSTEM

user?: USER

newUser?: USER

addUser?: USER


r!: Response

User E acmA CM(user?)

newUser? t userlist

r! = UserNotExists

156

Add UserA CM -(AuthenticateUser A (AddUserAGCMOK V

AddUserACM IncorrectRights V

AddUserACM NewUserNotExists)) V


DeleteUserACM OK

ASYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! * Response


newUser? E userlist

userACM = userACM\ {(newUser?, addUser?)-

userACM(newUser?, addUser?)}

r! = OK

Delete UserACM IncorrectRights7SYSTEM

user?: USER

newUser?: USER

addUser?: USER

r!: Response



157

Delete UserACM New UserNotExists__

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! : Response


newUser? E userlist

r! = UserNotExists

DeleteUserACM- (Authenticate User A (Delete UserACM OK V

DeleteUserACM IncorrectRights V

DeleteUserACM NewUserNotExists)) V

Authenticate User Fail

AddAuthenticationACM OK_ASYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights? : PA uthenticationAuthorization

r! : Response

Authentication e acmACM(user?)

newUser? E userlist

authenticationACM = authenticationACM U {(new User?,addUser?)f-4rights?}

r! = OK

158

AddA uthenticationACM IncorrectRights

ESYSTEM

user?: USER

new User?: USER

addUser?: USER

rights?: PAuthenticationAuthorization

r!: Response

Authentication X acmACM(user?)


AddAuthenticationACM New UserNotExists_

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

rights? : PAuthenticationAuthorization

r! : Response


newUser? X userlist

r! = UserNotExists

AddAuthenticationACM ̂ - (Authenticate User A (AddAuthenticationACM OK V

AddAuthenticationACM IncorrectRights v

AddAuthenticationACM New UserNotExists)) V


159

DeleteAuthenticationA CMOK

ASYSTEM

user?: USER

newUser?: USER

addUser?: USER

r!: Response


newUser? E userlist

authenticationACM = authenticationACM \ { (new User?, add User?) >

authenticationACM(newUser?, addUser?)}

r! = OK

_DeleteA uthenticationA CM IncorrectRights_

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! : Response

Authentication i acmACM(user?)


_DeleteAuthenticationACM New UserNotExists_______ __

ESYSTEM

user?: USER

newUser?: USER

addUser?: USER

r! : Response


newUser? E userlist

r! = UserNotExists

160

DeleteAuthenticationACM - (AuthenticateUser A (DeleteAuthenticationACM_ OK

V DeleteAuthenticationACM IncorrectRights V

DeleteAuthenticationACM New UserNotExists)) V

AuthenticateUser Fail

_AddFileACM OKASYSTEM

user?: USER

newUser?: USER

file?: FILENAME

rights?: PFileAuthorization

r!: Response


newUser? c userlist

fileACM =fileACMU {(newUser?file?)"rights?}

r! = OK

_AddFileACM IncorrectRights7SYSTEM

user?: USER

newUser?: USER

file?: FILENAME


r! : Response

File e acmACM(user?)


161


ESYSTEM

user?: USER

newUser?: USER

file?: FILENAME


r!: Response


newUser? X userlist

r! = UserNotExists

AddFileACM - (Authenticate_User A (AddFileACM OK v

AddFileACM IncorrectRights V AddFileACM UserNotExists)) V


DeleteFileACM OKASYSTEM

user?: USER

newUser?: USER

file?: FILENAME

r! : Response


newUser? E userlist

fileACM =fileACM \ ((new User? file?)-~fileACM(new User?,file?)}

162

DeleteFileACM IncorrectRights

ESYSTEM

user?: USER

newUser?: USER

file?: FILENAME

r!: Response

File X acmACM(user?)


DeleteFileACM UserNotExistsESYSTEM

user?: USER

newUser?: USER

file?: FILENAME

r! : Response

File e acmACM(user?)

newUser? X userlist

r! = UserNotExists

DeleteFileACM (Authenticate User A (DeleteFileACMOKV

DeleteFileACM IncorrectRights V

DeleteFileAC.M UserNotExists)) V AuthenticateUserFail

163

_AddProcessACM OK _ASYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME


r! : Response


newUser? E userlist

processACM = processACMU {(newUser?,(runAs?file?))-rights?}

r! = OK

AddProcessACM IncorrectRights

E SYSTEM

user?: USER

newUser?: USER

runAs?: USER

file? : FILENAME


r! : Response



164

AddProcessACM UserNotExists_

ESYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME


r! : Response


newUser? X userlist

r! = UserNotExists

AddProcessACME- (Authenticate User A (AddProcessACM OKV

AddProcessACM IncorrectRights V

AddProcessACM UserNotExists)) V


DeleteProcessACM OK

ASYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME

r!: Response


newUser? E userlist

processACM1 = processACM \ {(newUser?,(runAs?file?))F-*

processACM(new User?,(runAs? file?))}

r! = OK

165

DeleteProcessACM IncorrectRights

ESYSTEM

user?: USER

newUser?: USER

runAs?: USER

file?: FILENAME

r!: Response



DeleteProcessACM UserNotExists

.SYSTEM

user?: USER

newUser?: USER

runAs?: USER

file? : FILENAME

r!: Response


newUser? E userlist

r! = UserNotExists

DeleteProcessACM E (AuthenticateUser A (DeleteProcessACM OKv

DeleteProcessACM IncorrectRights V

DeleteProcessA CM UserNotExists)) V


166

AddUserAuthorizationOK

ESYSTEM

user?: USER

newUser?: USER

r!: Response

AddUser E userACM(user?,newUser?)

r! = OK

AddUserAuthorizationFail_-SYSTEM

user?: USER

newUser?: USER

r! : Response

AddUser X userACM(user?,newUser?)


DeleteUser Authorization OK

ESYSTEM

user?: USER

newUser?: USER

r! : Response

DeleteUser E userACM(user?,newUser?)

r! = OK

DeleteUserAuthorization FailESYSTEM

user?: USER

newUser?: USER

r! : Response

DeleteUser X userACM(user?,newUser?)


167

AddAuthenticationAuthorizationOK

ESYSTEM

user?: USER

newUser?: USER

r!: Response

Add Authentication E authenticationACM(user?,newUser?)

r! = OK

AddAuthentication Authorization FailZ-SYSTEM

user?: USER

newUser?: USER

r!: Response

Add Authentication S authenticationACM(user?,newUser?)


DeleteAuthenticationAuthorization OK:SYSTEM

user?: USER

newUser?: USER

r! : Response

DeleteAuthentication E authenticationACM(user?,newUser?)

r! = OK

DeleteAuthenticationAuthorization_FailZ-SYSTEM

user?: USER

newUser?: USER

r!: Response

Delete_Authentication X authenticationA CM(user?,new User?)


168

_AddFileAuthorizationOK

ESYSTEM

user?: USER

file?: FILENAME

r!: Response

AddFile efileACM(user?,file?)

r! = OK

AddFileAuthorizationFailESYSTEM

user?: USER

file?: FILENAME

r!: Response

Add-File i fileACM(user?,file?)


_DeleteFileAuthorizationOK

ESYSTEM

user?: USER

file?: FILENAME

r! : Response

DeleteFile efileACM(user?,file?)

r! = OK

_DeleteFileAuthorizationFailESYSTEM

user?: USER

file?: FILENAME

r!: Response

DeleteFile fifleACM(user?,file?)


169

_ReadFileAuthorizationOK

ZSYSTEM

user?: USER

file?: FILENAME

r! : Response

ReadFile efileACM(user?,file?)

r! = OK

ReadFileAuthorizationFail

--SYSTEM

user?: USER

file?: FILENAME

r!: Response

ReadFile EfileACM(user?,file?)


_ChangeFile_AuthorizationOK

ZESYSTEM

user?: USER

file?: FILENAME

r!: Response

Change-File e fileACM(user?, file?)r! =OK

ChangeFile_Authorization-Fail

E-SYSTEM

user?: USER

file?: FILENAME

r! : Response

ChangeFile EfileACM(user?,file?)


170

StartProcess Authorization OK

E SYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r!: Response

StartProcess E processACM(user?, (runAs?,file?))

r! = OK

StartProcessAuthorization Fail

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r!: Response

StartProcess X processACM(user?, (runAs?, file?))


StopProcessAuthorizationOK

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r!: Response

Stop.Process E processACM(user?, (runAs? file?))

r! = OK

171

StopProcessAuthorization Fail

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r! : Response

Stop.Process X processACM(user?, (runAs?,file?))


ChangeProcess Authorization-OK__ _

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r! : Response

ChangeProcess c processA CM(user?, (runAs?,file?))

r! = OK

_ChangeProcess_Authorization-Fail

ESYSTEM

user?: USER

runAs?: USER

file?: FILENAME

r! : Response

ChangeProcess i processACM(user?, (runAs?,file?))


172

AddAuthenticationOK ___

ASYSTEM

user?: USER

ac?: AUTHENTICATION CONTROL

r! : Response

user? c userlist

authenticated'(user?) = authenticated(user?) U {ac?}

r! = OK

AddA uthentication NotExistsESYSTEM

user?: USER


r!: Response

user? X userlist

r! = UserNotExists

AddAuthentication (Authenticate_User A ((AddAuthentication Authorization OK

A (AddAuthentication OK v AddAuthenticationNotExists)) V

AddAuthenticationAuthorization Fail)) V AuthenticateUserFail

DeleteAuthenticationOK

ASYSTEM

user?: USER


r! : Response

ac? c authenticated(user?)

authenticated'(user?) = authenticated(user?)\ {ac?}

173

DeleteAuthenticationNotExists__SYSTEM

user?: USER

ac? : A UTHENTICA TION CONTROL

r!: Response

ac? X authenticated(user?)

r! = InvalidUserA uthenticationControlPair

DeleteAuthentication - (Authenticate User A

((DeleteAuthentication AuthorizationOK

A (DeleteAuthenticationOKV DeleteAuthentication NotExists)) V

DeleteAuthenticationAuthorization Fail)) V


AddUserOKASYSTEM

newUser?: USER

r! : Response

newUser? i userlist

userlist' = userlist U {new User? }r! = OK

AddUserExistsESYSTEM

newUser?: USER

r! : Response

newUser? E userlist

r! = UserExists

174

Add User - (AuthenticateUser A ((AddUserAuthorizationOK A

(AddUserOK V Add UserExists)) v AddUserAuthorizationFai)) V


_DeleteUserOKASYSTEM

deleteUser?: USER

r!: Response


Vp : processlist * p.owner • deleteUser?

delete User? E dom authenticated

deleteUser? e dom (dom userACAM)

deleteUser? i dom (domfileACM)

delete User? i dom (dom processA CM)

deleteUser? E dom (ran (dom processACCM))

deleteUser? e dom acmACM

userlist' = userlist \ { delete User?}

r! = OK

-Delete UserrNotExists_

ESYSTEM

deleteUser?: USER

r! : Response

deleteUser? e userlist

r! = UserNotExists

175

_Delete UserRunningProcess

ESYSTEM

deleteUser?: USER

r!: Response


]p : processlist * p.owner = delete User?


_Delete UserStillA uthenticatedESYSTEM

deleteUser?: USER

r!: Response


Vp : processlist * p. owner # delete User?

delete User? E dom authenticated

r! = UserStillAuthenticated

Delete User UserStillAuthorized

ESYSTEM

deleteUser?: USER

r! : Response


Vp : processlist * p. owner • delete User?

deleteUser? e dom (dom userACAM) V

deleteUser? E dom (domfileACM) V

deleteUser? E dom (dom processACCM) v

delete User? E dom (ran (dom processACAM)) V

deleteUser? E dom acmACM

r! = UserStillAuthorized

176

Delete User - (A uthenticateUser A ((Delete User_A uthorizationOK A

(Delete User OKV Delete UserNotExists V

Delete User RunningProcess V Delete UserStillAuthenticated V

Delete User_ UserStillAuthorized)) V Delete UserAuthorization-Fail))


_AddFileOKASYSTEM

filename?: FILENAME


r!: Response


filelist' = filelist U {filename? -fileproperties?}

r! = OK

AddFileExistsESYSTEM

filename?: FILENAME


r!: Response


r! = FileExists

AddFile - (AuthenticateUser A ((AddFile Authorization-OK A

(AddFileOKV AddFile Exists)) V AddFile Authorization-Fail)) V

Authenticate_ UserFail

177

_ReadFileOK

E-SYSTEM

filename?: FILENAME


r!: Response



r! = OK

_ReadFileNotExists

ESYSTEM

filename?: FILENAME


r!: Response


r! = FileNotExists

ReadFile (AuthenticateUser A ((ReadFileAuthorizationOK A

(ReadFileOK V ReadFileNotExists)) V

ReadFile Authorization Fail)) V AuthenticateUserFail

DeleteFile OK

ASYSTEM

filename?: FILENAME

r!: Response


Vp: processlist * pfilename •filename?

filename? L ran (ran (dom processACCM))

frlelist'=filelist \ {OfilenameKflelist(filename?)}

r! = OK

178

DeleteFileNotExists

ESYSTEM

filename?: FILENAME

r!: Response


r! = FileNotExists

DeleteFileFileExecutionStilluthorized

ESYSTEM

filename?: FILENAME

r!: Response


Vp: processlist * pfilename • filename?

filename? E ran (ran (dom processA CM))r! = FileExecutionStillAuthorized

DeleteFileFileBeingExecutedESYSTEM

filename?: FILENAME

r!: Response

filename? E domfilelist3p processlist 0 p. filename = filename?


DeleteFile (Authenticate_User A ((DeleteFileAuthorizationOK A

(DeleteFileOK v DeleteFileNotExists V DeleteFile FileBeingExecuted

V DeleteFileFileExecutionStillAuthorized))

v DeleteFileAuthorizationFail)) V AuthenticateUserFail

179

ChangeFileOKASYSTEM

filename?: FILENAME


r! : Response

filename? c dom filelist

filelist' =filelist D {filename? -properties?}

r! = OK


-SYSTEM

filename?: FILENAME


r! : Response

filename? X dom filelist

r! = FileNotExists

ChangeFile - (Authenticate-User A ((ChangeFile AuthorizationOK A

(ChangeFile OK V ChangeFileNotExists)) V

ChangeFile AuthorizationFail) V AuthenticateUser Fail

_StartProcessOK

ASYSTEM

process?: PROCESS

runAs?: USER

r! : Response

process?.owner = runAs?process?fJilename E domflelist

Vp:processlist *p.process id s process?.process id

processlist'= processlist U {process?}

r! = OK

180

StartProcess_FileNo t Exists_ESYSTEM

process?: PROCESS

runAs?: USER

r!: Response

process? filename X domfilelist

r! = FileNotExists

StartProcessUserNameslnconsistent

ESYSTEM

process?: PROCESS

runAs?: USER

r!: Response

process?.owner # runAs?

r! = UserNameslnconsistent

StartProcess - (AuthenticateUser A ((StartProcess_AuthorizationOK A

(StartProcessOK V StartProcessFileNotExists

V StartProcessUserNamesInconsistent)) V

StartProcessA uthorization Fail)) VAuthenticateUserFail



runAs?: USER

r!: Response

9p:processlist * p.process id = processidU? A p.owner = runAs?

processlist'= processlist\ {p:PROCESSlp.process id = process id?}

r! =OK

181

_StopProcessProcesstiDNotExists__

ESYSTEM


runAs?: USER

r!: Response

Vp:processlist * p.processid • processid?


StopProcess_ UserNamesInconsistentESYSTEM


runAs?: USER

r! : Response

3p:processlist * p.process id = process-id?

Vp:processlist * p. owner # runAs?

r! = UserNamesInconsistent

StopProcess - (AuthenticateUser A ((StopProcessAuthorizationOK A

(StopProcess_OK V StopProcessProcessIDNotExists V

StopProcessUserNamesInconsistent)) v

StopProcessAuthorization Fail)) V Authenticate User Fail




r!: Response

(let p = {p1: processlist I pl processid = process-id?) -


processlist' = processlist\ {p2: processlist I p2.process-id process-id?} A


r! = OK)

182

ChangeProcessProcessIDNotExists7SYSTEM

process id? : PROCESSID

newstate?: PROCESS-STATE

r!: Response

Vp-processlist * p.process_id X process id?


ChangeProcess - (AuthenticateUser A ((ChangeProcessAuthorization-OK A

(ChangeProcessOK V ChangeProcessProcessIDNotExists)) v

ChangeProcessAuthorization Fail)) V AuthenticateUserFail

183

REFERENCES

[1] A. E. Abdallah and E. J. Khayat, "Formal Z Specifications of Several Flat Role-Based Access Control Models," in Proc. of Software Engineering Workshop,2006, pp. 282-292.

[2] L. Bass, P. Clements and R. Kazman, "Software Architecture in Practice, " 2nded., Addison-Wesley, 2003.

[3] M. Bishop, "Computer Security Art and Science," Addison-Wesley, 2003.

[4] Christopher Dilloway and Gavin Lowe, "Specifying Secure Transport Layers," inProc. of Computer Security Foundations Symposium, 2008, pp. 210-223.

[5] D. C. Ince, "An Introduction to Discrete Mathematics, Formal SystemSpecification, and Z," 2nd ed., New York: Oxford University Press, Inc., 1993

[6] Carl E. Landwehr, "Formal Models for Computer Security," ACM ComputingSurveys (CSUR), vol. 13, issue 3, pp. 247-278, Sep. 1981.

[7] Benjamin W. Long, Colin J. Fridge and Antonio Cerone, "A Z Based Approach toVerifying Security Protocols," in Proc. of ICFEM, 2003, pp. 375-395.

[8] S. Morimoto, S. Shigematsu, Y. Goto and J. Cheng, "Formal Verification ofSecurity Specifications with Common Criteria," in Proceedings of SAC, 2007,pp.1506-1512.

[9] Xiufeng Ni and Cui Zhang, "Converting Specifications in a Subset of Object-Z toSkeletal Spec# Code for Both Static and Dynamic Analysis", Journal of ObjectTechnology, vol. 7, issue 8, pp. 165-185, Nov. 2008.

[10] S. Ramkarthik and Cui Zhang, "Generating Java Skeletal Code With DesignContacts from Specifications in a Subset of Object Z", in Proc. of IEEE/ACISInternational Conference on Computer and Information Science, 2006, pp. 405-411.

[11] S. Sanders and Cui Zhang, "Object-Z to Java/Perl: A Conversion from Object-Zto Executable Skeletal Code with Dynamically Checkable Design Contracts", inProc. of International Conference on Software Engineering and KnowledgeEngineering, 2008, pp. 824-829.

[12] M. Shaw and D. Garlan, "Software Architecture Perspectives on an EmergingDiscipline," New Jersey: Prentice Hall, 1996.

184

[13] T. Song, J. Alves-Foss, C. Ko, C. Zhang, and K. Levitt, "Formal Reasoning aboutIntrusion Detection Systems", in Proceedings of the International Symposium on RecentAdvances in Intrusion Detection, 2004, pp.278-295.

[14] J. M. Spivey, (2009, January 10). The ZNotation: A Reference Manual. (2nd ed.)[Online]. Available: http://spivey.oriel.ox.ac.uk/-mike/zrm/

[15] "Trusted Computing Group: FAQs" Internet:www.trustedcomputinggroup.org/faA/, [April 03, 2009].

[16] "Z Word Tools" Internet: sourceforge.net/projects/zwordtools/, [January 11,2009].

formal specification of software architecture … pdfs/formal specification... · for different...

Documents