![](bg4.png)
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, satisfied 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 satisfied without security
related functionalities, thus we have to find 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 confirm the usefulness of our tool, e.g., whether our
tool contributes to identify requirements and threats
and to find 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 find 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 identified by obstructing
existing requirements or goals. Thus, threatening
requirements in this paper is not easy to be identi-
fied 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 specific 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