A SUPPORTING TOOL TO IDENTIFY BOTH SATISFIED

REQUIREMENTS AND TOLERANT THREATS FOR A JAVA

MOBILE CODE APPLICATION

Haruhiko Kaiya, Kouta Sasaki, Chikanobu Ogawa and Kenji Kaijiri

Shinshu University

4-17-1 Wakasato, Nagano, 380-8553 JAPAN

Keywords: Security Policy, Security Requirements, Java, Requirements Analysis.

Abstract: A mobile code application can be easily integrated by using existing software components, thus it is one of the

promising ways to develop software efﬁciently. However, using a mobile code application sometimes follows

harmful effects on valuable resources of users because malicious codes in such an application can be activated.

Therefore, users of mobile code applications have to identify both beneﬁts and risks by the applications and

to decide which beneﬁts should be gotten and which risks should be tolerated. In this paper, we introduce a

tool to support such users. By using this tool, the users can identify security related functions embedded in

each mobile code automatically. The users can also relate these functions to each beneﬁt or risk. By deﬁning

a security policy for mobile codes, some functions are disabled, thus some beneﬁts and risks are also disabled.

By adjusting the security policy, the users can make decision about the beneﬁts and the risks.

1 INTRODUCTION

Mobile code technology is useful because it is easy to

integrate a software service on the ﬂy. It is also easyto

maintain and update mobile code components in such

a service because codes are basically downloaded

and linked in its runtime. In addition, alternative

codes can be easily selected for meeting requirements

changes because we can reuse ﬁne-grained software

components in ad hoc manner. For example, suppose

there are many alternative codes for data communica-

tion, and their efﬁciency and license cost are different

with each other. An integrator will select a code that

is not so fast but cheap normally, but he/she in urgent

situation can replace the code into another that is very

fast but expensive on the ﬂy.

However, there are several problems in using mo-

bile codes, and one of the signiﬁcant problems is

about malicious codes. If behaviors of malicious

codes are not restricted, valuable resources can be

leaked and/or destroyed. For example, your credit

card information could be stolen. We call such harm-

ful effects by malicious codes as threats in this pa-

per. Therefore, we have to identify which require-

ments should be satisﬁed and which threats should

be avoided when we integrate a mobile code appli-

cation. In addition, we think it is impossible both to

satisfy all requirements and to avoid all threats com-

pletely. In fact, we have compromised with software

systems with unsatisﬁed requirements and tolerant

threats. Therefore, we have to also decide trade-offs

between satisﬁed requirements and tolerant threats.

We have already proposed a method to identify

trade-offs between them caused by Java mobile code

applications (Kaiya et al., 2003; Kaiya et al., 2004).

However, we cannot effectively examine our method

without supporting tools, because the methodrequires

tiresome but systematic tasks. In this paper, we will

introduce a supporting tool and the plan to apply the

tool into security education.

The rest of this paper is as follows. In the next

section, we brieﬂy introduce the mechanism of Java

security architecture. In section 3, we will explain

how to use our tool. In section 4, we will explain why,

where and how to apply our tool. Finally, we conclude

our current results and summarize future plan.

2 JAVA SECURITY

Java security architecture is based on the sandbox se-

curity model (Java, 1998). There are many security

related features in Java security architecture, but we

only focus on the permission and the security policy.

444

Kaiya H., Sasaki K., Ogawa C. and Kaijiri K. (2006).

A SUPPORTING TOOL TO IDENTIFY BOTH SATISFIED REQUIREMENTS AND TOLERANT THREATS FOR A JAVA MOBILE CODE APPLICATION.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 444-448

DOI: 10.5220/0002445604440448

 SciTePress

Player.class

Judge.class

ObjectJanken.class

Property

File

Client Machine

Application

yamada

murata

Download

Read

Write

Security Policy

Download

Code Provider A

Code Provider B

Code Provider C

Other Machine

Network

Connection

Establish

Figure 1: Environment for a Java application.

Each permission correspond to the right to access sys-

tem resource(s) such as ﬁles, network connections,

running processes and so on. To grant the pieces of

the right to a Java application, the security policy is

given to the application. Figure 1 shows an example

of the environment for a Java application. An appli-

cation in this ﬁgure consists of three pieces of codes

and it accesses a ﬁle and a property, and establishes a

network connection to another machine.

When inadequate policy is given to an applica-

tion, malicious codes can be activated, thus security

threats can be made. For example, data can be ille-

gally leaked because the policy inadequately grants

the right for ﬁles and network connections.

To avoid the threats caused by malicious codes,

codes are distinguished with respect to both the site

where a code is placed and the signature, and re-

stricted in different ways. If a code is downloaded

from a trusted site or a trusted agent signed the code,

we may believe the code does not cause any threats.

However, we cannot or do not always use only

trusted codes in fact, e.g., some kinds of free soft-

ware. In addition, even the trusted codes cause se-

curity threats because of their bugs or our inadequate

usage. Therefore, application integrators have to in-

vestigate which requirements are satisﬁed and what

kinds of threats can be caused by a mobile code ap-

plication by themselves.

3 USAGE OF OUR TOOL

This tool supports application integrators to identify

which requirements are satisﬁed by a mobile code ap-

plication. In addition, the tool also supports to iden-

tify threats caused by the application. Because reuse

of mobile codes is intended, threats can be avoided by

tightening up the security policy and/or by replacing

a mobile code including malicious parts with another

compatible code. In some cases, some requirements

cannot be satisﬁed because of the tightened policy,

thus we have to sometimes giveup some requirements

or to accept the threats. This tool also supports to ﬁnd

such trade-offs.

3.1 Major Functions

Our tool provides the following six functions. By us-

ing such functions in a requirements analysis process,

integrators can identify the achievement of require-

ments and threats, and decide trade-offs between re-

quirements and threats.

3.1.1 Network Deployment Function

Our tool consists of several internal windows as

shown in Figure 2, and a top left window called “Vir-

tual Network Window” is an analogical model of a

deployment of computers each of which provides mo-

bile codes. In addition, permissions that are required

by such codes are automaticallyextracted from source

codes or byte codes, and listed in a middle window

called “Permission Table”. XML based representa-

tion for Java source codes (JavaML) and its support-

ing tool

and Java decompiler

are used in this func-

tion. By using this function, users can understand

what kinds of security related functions could be acti-

vated by each mobile code.

3.1.2 Policy Edit Function

Based on the deployment of mobile codes shown in

the “Virtual Network Window”, our tool can automat-

ically generate a security policy that grants all permis-

sions required by all codes. The generated policy is

shown in the right top window in Figure 2, and users

can freely edit the policy. Users may also edit a policy

from scratch, but users can easily arrive at intended

policy by removing the granted permissions from the

generated policy.

3.1.3 Policy Check Function

According to the policy in “Policy Editor”, each

permission in “Permission Table” is automatically

checked whether it can work or not under the policy.

The column labeled by “Check” in “Permission Ta-

ble” shows the results.

3.1.4 Requirements Edit Function

Users can list their requirements on the left bottom

window called “Requirements Window” in Figure 2.

The requirements are simply itemed as shown in the

ﬁgure. Each requirement is basically categorized into

the following four types.

http://www.badros.com/greg/JavaML/

http://jode.sourceforge.net/

A SUPPORTING TOOL TO IDENTIFY BOTH SATISFIED REQUIREMENTS AND TOLERANT THREATS FOR A

JAVA MOBILE CODE APPLICATION

445

Requirements

Window

Information

for each Requirement

Information

for sub Requirements

Virtual Network Window Policy Editor

Permission Table

Figure 2: A Snapshot of Our Tool.

1. Unrelated: A requirement which is not related to

security related permissions.

2. Granted: A requirementwhich requires security re-

lated permissions, and the permissions are granted

in a current situation, i.e., code deployment and

policy.

3. Revoked: A requirement which requires security

related permissions, but the permissions is not

granted. As a result, the requirement is given up.

4. Threatening: When there are some granted per-

missions that are not required by requirements and

such permissions could enable some mobile codes

to perform unintended and harmful functions, we

call such functions as threats or threatening require-

ments. Threats are also listed in the “Requirements

Window”.

The graphical icon for each requirement on “Require-

ments Window” is decided according to the type of

the requirement.

3.1.5 Requirements Check Function

Users can decide the types of each requirement. If

users identify that a requirement requires permis-

sion(s) on the “Permission Table”, users can make

relationship between the requirement and the permis-

sion(s). Related requirements for each permission can

be found in the right most column on the “Permission

Table”. Related permissions for each requirement can

be found in a window called “Information for each

Requirement”.

A requirement is regarded to be satisﬁed when its

related permissions are all granted. On the other hand,

a requirement is regarded to be revoked one when

there is a permission that is required by the require-

ment but is not granted in the current situation.

3.1.6 Threat Check Function

Some granted permissions sometimes do not relate to

any requirements. Users can explore the possibility

of threats by examining such permissions and their

effects. If a threat can be activated by such permis-

sions, users can add a threat on the “Requirements

Window”, and make relationship between the require-

ment and the permissions. The threat is regarded to be

satisﬁed when current permissions enable the threat to

be made.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

446

3.2 Typical Process

By removing some lines from a policy e.g., in “Pol-

icy Editor” in Figure 2, granted permissions are de-

creased in general, and vice versa. When granted

permissions are changed, satisﬁed requirements and

threats are also changed. The requirements, threats

and the policy are decided by repeating such changes.

Finally, integratorshave to decide which requirements

may be abandoned and which threats can be tolerable

with respect to the users’ needs.

4 APPLICATION IN EDUCATION

Even though we frequently meet real threats for com-

puters thanks to the Internet, there are few educa-

tional exercises for security threats and their avoid-

ance at least in our country. Consequently, students

do not clearly understand the importance of security

requirements. On the other hand, our requirements

for software can be rarely satisﬁed without security

related functionalities, thus we have to ﬁnd trade-offs

between our requirements and threats that should be

accepted.

By using Java, we can easily implement and ac-

tivate malicious mobile codes, and also avoid such

threats by using Java security policy mechanism. In

fact, a bootstrap program for Java mobile code appli-

cation can be written in less than 150 lines of code.

Thus, Java mobile codes and security system seems

to be suitable for students to learn the importance of

security requirements.

We have planed to put a course into practice for stu-

dents. The objective of the course is to make our stu-

dents to understand the importance for analyzing se-

curity requirements and threats. Another objective is

to conﬁrm the usefulness of our tool, e.g., whether our

tool contributes to identify requirements and threats

and to ﬁnd tradeoffs among them.

5 CONCLUSIONS

In this paper, we introduced a supporting tool to iden-

tify both the achievement of requirements and threats

for Java mobile code application. We have applied

our tool in security requirements education.

Mobile codes seem to be a little bit singular, but we

can ﬁnd important application areas for mobile codes.

For example, embedded systems normally have only

limited resources, such as disks, thus, mobile codes

can be applied to such domain. Currently, we mainly

intended to use our tool in educational settings. How-

ever, we believe our tool can be also applied to prac-

tical software integration.

There are several limitations of our tool. One lim-

itation comes from the intended platform, Java. Java

security policy is too simple to specify complex se-

curity policy, e.g., we cannot write revoke rules in a

policy. Because of such simplicity, we cannot apply

our tool to generic software systems. Another limita-

tion is its usability. Users of our tool do not have to

know Java language itself, but they have to know the

syntax of security policy, even though the policy syn-

tax is much easier than Java’s. Finally, our tool does

not explicitly support the selection of alternative mo-

bile codes now. This is a problem when we apply our

tool into practice, thus we will extend our tool from

this point. However, we do not think it is a problem

in our educational setting mentioned in 4 because one

of the objectives of our educational course is to make

our students to understand the importance of analyz-

ing security requirements and threats.

Threatening requirements mentioned in 3.1.4 are

very similar to obstacles in KAOS (van Lamsweerde,

2004). Their difference is that threatening require-

ments do not have to obstruct existing requirements

but obstacles are basically identiﬁed by obstructing

existing requirements or goals. Thus, threatening

requirements in this paper is not easy to be identi-

ﬁed by KAOS approach. Misuse case approach is

also useful method to identify security requirements,

but its weakness was argued in (Sindre and Opdahl,

2005). Our tool can partially overcome such weak-

ness, for example, the process navigated by our tool

is not open-ended but systematically terminated if the

user can compromise on a speciﬁc policy and its con-

sequences; giving up requirements and/or accepting

threats. Software Fault Tree (Helmer et al., 2002)

is also systematic approach, but it is specialized for

the requirements analysis of intrusion detection sys-

tems. A system called SoftwarePot (Kato and Oyama,

2003) can be also applied to the problems we focused.

In SoftwarePot, applications are executed in some

kind of sandbox, and users have to decide whether

an access to the valuable resources should be granted

or not in each time. We think SoftwarePot approach

seems to be practical, but it does not contribute to

improving users’ understanding about security prob-

lems.

REFERENCES

Sun Microsystems, Inc. (1998). Java Security Architecture

(JDK1.2). Version 1.0.

Helmer, G., Wong, J., Slagell, M., Honavar, V., Miller, L.,

and Lutz, R. (2002). A Software Fault Tree Approach

to Requirements Analysis of an Intrusion Detection

System. Requirements Engineering, 7(4):207 – 220.

Kaiya, H., Sasaki, K., and Kaijiri, K. (2004). A Method

A SUPPORTING TOOL TO IDENTIFY BOTH SATISFIED REQUIREMENTS AND TOLERANT THREATS FOR A

JAVA MOBILE CODE APPLICATION

447

to Develop Feasible Requirements for Java Mobile

Code Application. IEICE Trans. Inf. and Syst., E87-

D(4):811–821.

Kaiya, H., Sasaki, K., Maebashi, Y., and Kaijiri, K. (2003).

Trade-off Analysis between Security Policies for Java

Mobile Codes and Requirements for Java Application.

In 11th IEEE International Requirements Engineering

Conference, pages 357–358.

Kato, K. and Oyama, Y. (2003). SoftwarePot: An En-

capsulated Transferable File System for Secure Soft-

ware Circulation. Lecture Notes in Computer Science,

2609:112 – 132.

Sindre, G. and Opdahl, A. L. (2005). Eliciting security

requirements with misuse cases. Requirements Engi-

neering, 10(1):34 – 44.

van Lamsweerde, A. (2004). Elaborating Security Require-

ments by Construction of Intentional Anti-Models. In

Proceedings of ICSE’04, pages 148–157.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

448