![](bg5.png)
receivable is stored in the accounting
database.
5. We assume that the communication paths and
the databases are not protected.
6. The order data is composed of customer
name, credit card number, and total payment.
The receivable consists of order number and
total payment. The credit card information
includes the customer name and credit card
number.
We next code this information in the file
relevant_information.pl, which will be loaded when
running the expert system.
Phase 2: Process the UML and Identify Threats
Using an Expert System
Steps 1 and 2 of Phase 2 (see Section 2) are
executed, identifying the threats shown in Table 1.
Table 1: Threat table, showing the threat identification
results from the demonstration.
Location Asse t
Required
Protection
Threat Mem o
627_1500 credit_card_number no_disclosure trojan_horse_attack
627_1500 total_payment no_modification trojan_horse_attack
664_1510 credit_card_number no_disclosure trojan_horse_attack
664_1510 total_payment no_modification trojan_horse_attack
799_1521 credit_card_number no_disclosure trojan_horse_attack
799_1521 total_payment no_modification trojan_horse_attack
6645_307 credit_card_number no_disclosure trojan_horse_attack
4234_325 credit_card_number no_disclosure trojan_horse_attack
4234_325 total_payment no_modification trojan_horse_attack
4558_343 total_payment no_modification trojan_horse_attack
8160_334 credit_card_number no_disclosure trojan_horse_attack
8160_334 total_payment no_modification trojan_horse_attack
9453_352 total_payment no_modification trojan_horse_attack
664_1510 credit_card_number no_disclosure sql_attack
order data stor ed in order database
664_1510 total_payment no_modification sql_attack
order data stor ed in order database
8160_334 credit_card_number no_disclosure sql_attack
order data stored in accounting database
9453_352 credit_card_number no_disclosure sql_attack
order data stored in accounting database
8160_334 total_payment no_modification sql_attack
order data stored in accounting database
9453_352 total_payment no_modification sql_attack
order data stored in accounting database
8160_334 total_payment no_modification sql_attack
receivable stored in accounting database
9453_352 total_payment no_modification sql_attack
receivable stored in accounting database
116_1087 credit_card_number no_disclosure MITM
Throug h message 4234_325
116_1087 total_payment no_modification MITM
Throug h message 4234_325
116_1087 total_payment no_modification MITM
Throug h message 4558_343
258_1013 credit_card_number no_disclosure MITM
Throug h message 664_1510
258_1013 total_payment no_modification MITM
Throug h message 664_1510
533_1053 credit_card_number no_disclosure MITM
Throug h message 8160_334
533_1053 total_payment no_modification MITM
Throug h message 8160_334
533_1053 total_payment no_modification MITM
Throug h message 9453_352
1657_990 availability DoS
763_1070 availability DoS
289_1104 availability DoS
Our prototype and demonstration give rise to the
following observations:
y UML model diagrams can be exported in XMI
format using the MagicDraw 16.0 UML modeling
tool and loaded into SWI-Prolog.
y XMI files exported by different UML modeling
tools are slightly different, which means that it
may be necessary to write different parsing code
for parsing XMI from different tools.
y Our automated approach appears to parse UML
fairly efficiently, but we did not do any
quantitative studies to confirm efficiency.
4 SOME PRACTICAL ISSUES
UML has been regarded as an informal or semi-
formal modeling language (Glinz, 2000). In
industrial settings, UML is widely used mainly
because it facilitates communication between
humans through visual means. When UML is used
for machine processing in automated processes (as
in this approach) some issues need to be considered,
as follows.
Missing Information
Certain details used in threat identification may not
be captured by UML, and thereby impact the results
of our approach. These include, for example, how a
system is protected for physical safety, what other
applications are running and the risks they pose, who
can access the system and how the system is
accessed. UML also lacks the ability to model
certain external entities and users that may be
critical to threat analysis, e.g. the role of an Internet
service provider. Some information may have been
omitted from the UML model of the system, either
because it was “too obvious” to be included in the
model or because it was considered only relevant to
security and not part of the UML model. One way to
solve this problem is to collect more detailed
relevant system information for the missing or
omitted information. Also the system model should
be more detailed in order to include enough
information for the automated threat identification.
Vague, Inconsistent, or Informal Information
The visualization capability and the informality of
UML provide more flexibility when modeling
software, but at the same time they cause problems
in automatic model processing. This is why UML is
often criticized for its vague semantics,
inconsistency and ambiguity. For example, in the
demonstration web store service, the message “order
data” can also be expressed as “order information”
and both terms sound the same to a human.
However, it is difficult for a machine to know that
they should be considered the same when it
processes the model automatically.
A realistic knowledge base can be developed by
a group of experts, as part of commercializing our
approach. However, building a knowledge base for
threat identification is still a huge task and the
following issues need to be considered.
AUTOMATED THREAT IDENTIFICATION FOR UML
525