IMPROVING SOFTWARE SECURITY THROUGH AN INTEGRATED

APPROACH

Zaobin Gan and Dengwei Wei

Huazhong University of Science and Technology

Wuhan 430074,PR China

Vijay Varadharajan

Department of Computing, Macquarie University

Sydney, NSW 2109, Australia

Keywords:

System Integration, RBAC.

Abstract:

It has been recognized that the main source of problems with application software security is in most cases

that the software is poorly designed and developed with respect to authentication and authorization. Aim-

ing at preventing the security issues in the course of software design and development, this paper presents a

framework for integrating a security policy speciﬁcation with a system function integration. On the basis of

the Role-Based Access Control (RBAC) model, this framework moves the responsibility of security through a

central authorization management mechanism, Single Sign-On (SSO) access and integration management of

security resources. The design can integrate the enterprise’s multiple new, developing and existing applica-

tion systems, and provide end users access these systems as a single system. An application instance of the

framework is given in a large-sized enterprise information integrated system as well. The results show that the

framework may provide enterprises with uniform and robust enforcement policies to improve the security of

sensitive information systems.

1 MOTIVATION

In order to compete and survive in the information

society, many enterprises have begun to set up some

information management systems, such as account-

ing information systems, human resource manage-

ment systems, product management systems, time-

card management systems, and so on, in the past sev-

eral years. Different systems, autonomously devel-

oped and managed, take advantage of different se-

curity policies and impose different constraints to be

satisﬁed before allowing participants access to data.

These systems, to a large extent, depend on the proper

management of security resources, such as user ac-

counts, passwords, logs, etc., in an enterprise. For

example, user authentication with account and pass-

word is dependent on how well passwords are cho-

sen, stored and managed. Relying on each applica-

tion to perform authentication leads to networks with

multiple disparate authentication policy enforcements

based on application implementation. Users will need

to remember and manage multiple accounts and pass-

words, and have to log in multiple times to access dif-

ferent application systems on the enterprise network.

In addition, these systems do not provide the enter-

prise with a central point of control over authentica-

tion policies and mechanisms, e.g., when an employee

is terminated, his/her access should be cancelled to

all applications on the Intranet. These lead to much

inconvenience for them and threatens the security of

these systems (e.g., if a password is stolen or forgot-

ten). The security issue of these systems is attracting

attention.

Many studies on practical examples show that the

main source of security risk originates from the de-

sign and implementation of these software systems

themselves (Lindqvist and Jonsson, 1998)(McGraw,

2002) and also from inside the enterprises or orga-

nizations (Harmantzis and Malek, 2004). Therefore,

improving software security depends on proactively

managing security associated with software design

and implementation.

In the meantime, the security of existing systems

must be protected and improved as far as possible

with available measures. In addition, developing spe-

ciﬁc security solutions for different systems is usu-

ally very expensive and time-consuming within an

enterprise. Thus, in this paper, we present an inte-

grated RBAC framework that can incorporates multi-

ple new developing systems and existing application

437

Gan Z., Wei D. and Varadharajan V. (2006).

IMPROVING SOFTWARE SECURITY THROUGH AN INTEGRATED APPROACH.

In Proceedings of the International Conference on Security and Cryptography, pages 437-442

DOI: 10.5220/0002096004370442

 SciTePress

systems within an organization, and provide end users

access them with speciﬁc collaborations as a single

system. It can implement a central authorization man-

agement mechanism, single sign-on access and inte-

gration management of security resources of all sys-

tems.

The remainder of the paper is organized as fol-

lows. In Section 2 a brief overview of related work

is presented. The integrated approach and the sys-

tem infrastructure to improve software security are

described in Section 3. Section 4 details the imple-

mentation of the integrated approach. Section 5 eval-

uates the characteristics. Finally, concluding remarks

and further work are provided in Section 6.

2 RELATED WORK

Role-based access control emerged rapidly in the

1990s as a proven technology for managing and en-

forcing security in large-scale enterprise-wide sys-

tems. Its authorization mechanism is concerned with

making decisions on who can access what operations

on which objects and how this can be achieved. Over

the past years, a signiﬁcant body of research on RBAC

models and experimental implementations has devel-

oped (Ferraiolo and Kuhn, 1992),(Sandhu and Sama-

rati, 1994)(Hitchens and Varadharajan, 2000). The

work on access control classiﬁes security models into

three broad categories, namely Discretionary Access

Control (DAC), Mandatory Access Control (MAC)

(Hitchens and Varadharajan, 2000) and Role-Based

Access Control (RBAC) (Sandhu and Coyne, 1996).

In fact, they all make use of the roles for control-

ling access to entities and objects or the mechanism-

oriented approach. It has been claimed elsewhere

that RBAC better suits the needs of some real world

organizations than MAC or DAC based approaches

(Sandhu and Feinstein, 1994).

However, they all fall into the trap of using ac-

cess control mechanisms both for policy expression

as well as in policy enforcement (Hitchens and Varad-

harajan, 2000). It is hardly possible for any given pol-

icy speciﬁcation to be implemented by all of the ex-

isting mechanisms. Some language-based proposals

have been presented. Simon and Zurko (Simon and

Zurko, 1997) discussed the mechanisms they were

implementing to support Separation of Duty and roles

in Adage, a general-purpose authorization language

and toolkit. Jajodia et al. (Jajodia et al., 1997) pro-

posed a logical language for the speciﬁcation of au-

thorizations on which such a model can be based.

These languages often depend upon their users having

a reasonable level of understanding of logical princi-

ples. This is not always found amongst real world

users, even those entrusted with the management of

access control policies for a system. Hitchens and

Varadharajan (Hitchens and Varadharajan, 2000) pro-

posed a language based approach to the speciﬁcation

of authorization policies (called Tower). It is far bet-

ter to provide the user who needs to specify access

control policies with ﬂexible mechanisms and allow

them to build structures for expressing their policies.

But the implementation on top of other access control

list mechanisms is somewhat inefﬁcient. In addition,

they didn’t take into account the security resources

management and integration, and the language-based

speciﬁcations are difﬁcult to understand and imple-

ment for programmers. In this paper, we can deﬁne

RBAC mechanism by means of an integrated graphi-

cal interface in the light of business management poli-

cies. In the meantime, for a new application, we make

use of a set of predeﬁned functions (Application Pro-

gramming Interface: API). These can present a sufﬁ-

cient degree of ﬂexibility and capability.

3 INTEGRATED SECURITY

INFRASTRUCTURE

The integrate security infrastructure is as shown in

Fig. 1. It consists of an Integrated Control Panel

(ICP), an Integrated Security Management compo-

nent (ISM), Application System components (AS

, , AS

). ISM-DB is a database that stores

all relevant security information in the whole inte-

grated management system. AS

-DB is respectively

a database that saves all data corresponding to appli-

cation system.

Uniform user entrance

Inte

rated Control Panel

ISM

…

ISM-DB

-DB

Figure 1: The Integrate Security Infrastructure.

3.1 Integrated Control Panel (ICP)

ICP, as depicted in Fig. 2, seems like the control

panel in Windows. It integrates and manages the ISM

component and AS

(i = 1, 2, . . . , n) components.

These components integrated in the ICP are either

new developing components or any independent exe-

cutable programs, e.g. some existing application sys-

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

438

tems. The ICP is an authentication and authorization

gateway to the application components, all applica-

tion components share the same authentication and

authorization mechanism provided by the ISM. These

components in the ICP can be invoked or loaded in

terms of users’ authorization. When a user clicks the

icon of any component, the ICP ﬁrst prompts the user

to input username and password, communicates with

the ISM, authenticates the user and retrieves autho-

rizations from the ISM-DB. Hence, the user will not

need to authenticate multiple times to access multiple

application components, as shown in Fig. 3.

Figure 2: The Integrate Control Panel Infrastructure.

Inte

rated Control Panel

…

M-DB

Users

(1) Login

ISM

(3) Authorize

(4) Invoke or access

(2) Authenticate

Figure 3: System Workﬂow.

3.2 Integrated Security Management

(ISM)

ISM, as shown in Fig. 4, is the core of the integrated

security infrastructure and the ’back-end’ component

that will be consulted by all the Application Com-

ponents for making access decisions. It is made up

of a graphical authentication and authorization inter-

face and a set of Application Programming Interfaces

(APIs). The graphical authentication and authoriza-

tion interface in the ISM is achieved by using RBAC

mechanisms to group users and enforcing the access

control policies of resources.

Figure 4: Integrated security management infrastructure.

Here, the RBAC mechanism has the following

three essential structures (Sandhu et al., 1994):

(1) Users: which correspond to real world users of

the computing system.

(2) Permissions: a description of the access users

can have to objects in the system.

(3) Roles: a description of the functions of users

within an organization.

In order to accurately model one real world job

description, the RBAC mechanism in the integrated

security infrastructure supports roles inheritance and

constraints, for example, users may not be allowed

to take on one role if another role they already have

speciﬁcally disallows it.

A role table is a triple (RoleID, RoleName,

Ship). RoleID is an exclusive tag of a role, Role-

Name is the name of a role, R

Ship is a set of con-

straints or role inheritance relationships among dif-

ferent roles. R Ship places restrictions on how users

are assigned to roles in the light of an organization’s

business management policies.

Permissions and users are mapped to roles, as

shown in Fig. 5. The relationships are many to

many. For a real world organization, we take two

types of entities to which access is being controlled

in the integrated security infrastructure. One speci-

ﬁes the object that represents all application system

components; another is the function that stands for

speciﬁed business functions, such as application, sig-

nature, read, write, and so on. In the RBAC model,

permissions will therefore specify the object and the

function which access is allowed. They can be ex-

pressed as two triples (RoleID, ObjectID, Permission)

and (RoleID, FuncID, Permission). The objects, the

functions and permissions all can be deﬁned by the

IMPROVING SOFTWARE SECURITY THROUGH AN INTEGRATED APPROACH

439

means of the graphical interface tool as shown in Fig.

4. All future accesses to any subsystems will retrieve

authorization assertions from the database server that

creates the user session. Hence, the user will not need

to authenticate multiple times to access different sub-

systems integrated in the ICP on the network.

Use

Role

Has Has

Permission

Figure 5: The relationship among user, role and permission.

3.3 Application System Components

Application system components integrated in the ICP

include some newly developed systems and some ex-

isting systems. The set of Application Programming

Interfaces (APIs)the ISM is a dynamic link library

(DLL) that is shared by all the application system

components. It includes encryption and decryption

functions, authorization identiﬁcation functions, users

identiﬁcation functions, roles code deﬁnition lists,

some common variables, and so on. While a new ap-

plication system is being developed, the API should

be used so that the new application can seamlessly be

integrated into the ICP. For some existing application

systems, their conﬁguration ﬁles are encrypted and

stored in the database ISM-DB. Therefore, after they

are integrated into the ICP, they cannot independently

work again once they separated from the ICP. They

may have their own authorization mechanism, but the

ICP can control whether a user who only has a certain

role can start up them or not. The security of these

existing systems can be improved greatly. While the

integrated system is installed, these components are

optional according to users’ requirements.

4 SYSTEM IMPLEMENTATION

In this section, we describe our implementation of

a practical application system in Xiaolangdi hy-

dropower plant by the means of the integration ap-

proach. It is made up of an ICP, an ISM, Human

Resources Management System, Power Generating

Management System, Finance Management System,

Worksheet Management System, Real-time Informa-

tion Display System and as well as some other sys-

tems (Gan, 2002), as shown in Fig. 6. The ISM is the

core of system, so we only discuss it in the following.

Figure 6: XLD integration information system infrastruc-

ture.

In order to achieve the goals presented in Sec-

tion 3, more than ten tables were designed in the

ISM database, such as T

User, T Role, T URole,

Object, T Auth, T Ctrl, T Func, T log, and so on.

The schemas are shown in Fig. 7. The implementa-

tion of the ISM supports the following functions:

User_ID

User_Name

Dept_ID

Pswrd

Lifetime

Lock_Flag

FuncID

FuncName

…

T_Func

RoleID

FuncID

Permission

T_Ctrl

ObjectID

ObjectName

…

T_Object

RoleID

ObjectID

Permission

T_Auth

User_ID

RoleID

…

RoleID

RoleName

R_Ship

T_Role

User_ID

Log_time

SubsystemID

…

T_Log

T_URole T_User

Figure 7: Relational schemas for the ISM database.

(1) Users management

Deﬁne users’ detailed information, such as users’

name, account, password, unit, roles, and the like.

Any user can also be locked or unlocked according

to business management policy, e.g. when an em-

ployee is terminated, his/her account will be locked,

and his/her access will be cancelled to all applications

on the Intranet.

(2) Conﬁguration management

Conﬁguration management centrally deﬁnes and

encrypts the system parameters of all application

components in the ICP and stores them in the

database ISM-DB.

(3) Object management

In order to conveniently map the access authoriza-

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

440

tion to roles, object management deﬁnes all applica-

tion system components integrated in the ICP, includ-

ing Human Resources Management System, Power

Generating Management System, Finance Manage-

ment System, Worksheet Management System, Real-

time Information Display System. Here, the object is

in the table T

Object.

(4) Functions management

Here, we deﬁne the function that stands for speci-

ﬁed business functions in the hydropower plant, such

as worksheet application, worksheet signature, work-

sheet permission, worksheet cancel, project audit,

read, write, and so on. The function is in the table

Func.

(5) Roles management

Roles delimit the functions of users within organi-

zations by prescribing the access to objects that users

have. Different roles are deﬁned regarding to the re-

lationships between job descriptions within the prac-

tical hydropower plant. In addition, role constraints

and role inheritance are taken into account as well.

These are saved in a triple table T

Role.

(6) Function and object authorization

By means of function and object authorization,

The management policies in the hydropower plant are

converted into users-roles-authorizations. All future

access to any subsystems will retrieve authorization

assertions from the database server that creates the

user session. User identiﬁcation and privileges deter-

mine the functionality of any application accessible

through the ICP. They are respectively saved in two

triple tables T

Ctrl and T Auth.

(7) Log management

Log management can track and analyse software

behaviour. Record user login time operation, audit

trail. User information, such as login time, logout

time, IP address, application system names and ob-

jects the user accesses during logon period, etc., are

recorded in the table T

Log.

5 EVALUATION

Before the integrated system was implemented, both

the Human Resources Management System and the

Worksheet Management System were independently

executed. A user had to respectively input his/her

username and password twice every time while he/she

needed to log on both the systems. The system ad-

ministrator must maintain two sets of authorization

and user management. However, after both the sys-

tem was integrated in the ICP, everything is becoming

simple. System administrator only needs to maintain

a set of authorization and user management. They can

log on all the systems after users only needs to input

his/her username and password once.

In addition, compared with some Role-based ac-

cess control approaches used in various application

systems (Thomsen et al., 1998)(Apfrlbeck, 2001), the

central security infrastructure presented in this paper

has some characteristics in the following:

(1) Granularity and extensibility

The ISM is able to provide ﬁner-grain resource

access control than existing solutions since all pri-

mary resources (applications, functions, operations

and data) can be separately accessed; and it allows se-

curity policies to be ﬂexibly and extensively deﬁned.

(2) Accountability and auditability

The log management of the ISM provides opera-

tion log in order to track record. A lot of relevant

information can be recorded about actions performed

by users, or processes acting on their behalf, so that

the consequences of those actions can later be linked

to the users in question and, if necessary, users can

be held accountable and auditable for their actions. It

can satisfy requirements for both accountability and

auditability well.

(3) Feasibility and integrity

From Integrated Control Panel, a set of APIs can

deliver enormous value to IT organizations and end

users, enabling centralized access to applications in

order to gain a simpliﬁed infrastructure, faster devel-

opment, and enhanced programmers and users efﬁ-

ciency.

The ICP framework can seamlessly integrate ex-

isting application systems and provide users with dy-

namic authorization into the applications.

(4) Authentication security strengthening

The ICP greatly improves the authentication secu-

rity of application systems by its Single Sign-On ac-

cess. A user can access all authorized applications, on

the basis of a single authentication that is performed

when he/she initially accesses any application inte-

grated into the ICP. Since the user has to remember

only one username/password, and needs to type this

information once, user productivity is improved and

security breaches such as users writing down their

passwords are eliminated.

On the other hand, the ISM is an independent au-

thentication system without user interaction. It does

not only centrally manage and control access to all ap-

plication systems integrated into the ICP but also pro-

vides a highly customizable set of role-based access

control policies and role mappings, which also greatly

improve the security of all application systems.

6 CONCLUSIONS AND FUTURE

WORK

This paper describes a central security infrastructure

to enable SSO for different application subsystems

IMPROVING SOFTWARE SECURITY THROUGH AN INTEGRATED APPROACH

441

via integration mechanisms, role-based access control

and security resource management. A case study of

the central security frame is presented as well.

In the current implementation, mapping of users to

roles and mapping of roles to permissions are created

and maintained in a predeﬁned format in the ISM by

the security administrator. Future work will study a

certain standard format for scripting this related se-

curity information, and automatically implementing

mapping of users to roles and mapping of roles to

permissions so as to improve the security of sensitive

information systems and to provide a more ﬂexible

mechanism. In addition, the API presented in this pa-

per can only support the same development tool. It is

also a future research direction how the API will be

improved to adapt to different development tools.

ACKNOWLEDGEMENTS

This work is supported by Geheyan Hydropower

Station Information Integrated System Project, Xi-

aolangdi Hydropower Station Information Integrated

System Project and China Scholarship Fund. We

thank the anonymous referees for their valuable com-

ments and suggestions to improve the quality of this

paper.

REFERENCES

Apfrlbeck, J. (2001). A role based modelling approach for

the information infrastructure. In Proceedings of the

IEEE International Conference on Communications,

pages 1617–1621. IEEE CS Press.

Ferraiolo, D. and Kuhn, D. R. (1992). Role based access

control. In Proceedings of the 15th Annual Confer-

ence on National Computer Security, pages 554–563,

Piscataway, NJ, USA. IEEE Press.

Gan, Z. B. (2002). The technical report for xiaolangdi

power station information integrated system. Techni-

cal report, Huazhong University of Science and Tech-

nology.

Harmantzis, F. and Malek, M. (2004). Security risk analy-

sis and evaluation. In Proceedings of the 2004 IEEE

International Conference on Communications, pages

1897–1901, Piscataway, NJ, USA. IEEE Press.

Hitchens, M. and Varadharajan, V. (2000). Design and spec-

iﬁcation of role-based access control policies. In IEE

Proceddings Software, pages 117–129, Piscataway,

NJ, USA. IEEE Press.

Jajodia, S., Smarati, P., and Subrahmanian, V. (1997). A

logical language for expressing authorizations. In Pro-

ceedings of the IEEE Symposium on Security and Pri-

vacy, pages 31–42, Piscataway, NJ, USA. IEEE Press.

Lindqvist, U. and Jonsson, E. (1998). A map of security

risks associated with using cots. Computer, 31(6):60–

66.

McGraw, G. (2002). Managing software security risks.

Computer, 35(4):99–101.

Sandhu, R. and Coyne, E. (Feb. 1996). Role-based access

control models. Computer, pages 38–47.

Sandhu, R., Coyne, E., and et al., H. F. (1994). Role-based

access control: A multi-dimensional view. In Pro-

ceeding of the 10th Annual Computer Security Appli-

cations Conference, pages 54–61, Orlando, FL, USA.

IEEE CS Press.

Sandhu, R. and Feinstein, H. (1994). A three tier architec-

ture for role-based access control. In Proceedings of

the 17th national computer security conference, pages

34–46. IEEE CS Press.

Sandhu, R. S. and Samarati, P. (1994). Access control: prin-

ciple and practice. IEEE Comm., pages 40–48.

Simon, R. and Zurko, M. (1997). Separation of duty

in role-based environments. In Proceedings of the

10th Computer Security Foundations Workshop, pages

183–194, Piscataway, NJ, USA. IEEE Press.

Thomsen, D., O’Brien, D., and Bogle, J. (1998). Role based

access control framework for network enterprises. In

Proceedings of the 14th Annual Computer Security

Applications Conference, pages 50–58, Phoenix, Ari-

zona. IEEE CS Press.

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

442