31-01-2013, 04:34 PM
Use Case Oriented Development of Security-Critical Systems
1Use Case Oriented.pdf (Size: 70.87 KB / Downloads: 21)
Abstract
Since the connection of computers over the Internet and the expansion of distributed
systems, they are confronted with more and more attacks. To counteract this
circumstance, we have to consider security requirements fromthe beginning of the system
development. In early phases of system development, it is common to use a twopart
process for the elaboration of the application core and the functional specification
in use cases. In this paper, we show an extension of this process for security-critical
systems. We show a methodical concept for the development of security-critical systems
and the modelling of security aspects in the application core with an extension
of the Unified Modelling Language, here UMLsec. Furthermore, we introduce security
use cases for the development of security aspects in conjunction with behavioural
modelling.
Introduction
Developers and customers think both about objects (e.g. an account) and about tasks or activities
(e.g. selling a book) in the early phases of a software development process. Whereas
objects can be modelled in a data model, experience in the field of software engineering
shows that the operational concept, i.e. specifying the behaviour with function signatures in
the data model, does not meet the requirements on behavioural modelling. For this case, the
application of Use Cases (see [JCJO92, JBR99]) for the modelling of the dynamic aspects
is widely accepted.
Methodical Concept for Specifying Security-Critical Systems
The common process in the object-oriented software development establishes a class diagram
for the data model. In this diagram, the static data of the domain is collectively
modeled with the associations between the data structures. Whereas the class diagram represents
only the data structures, the interaction sequences where the user is confronted with
the system are initially described by text in the requirements specification (see [Som00]).
After a closer specification for each function, use cases are elaborated, which describe,
group, divide and extend the functions in a moderate way. After the elaboration of the domain
model and the behaviour in use cases, they are connected to an object-oriented system
specification.
Static Security Data Modelling with UMLsec
We recall the fragment of UMLsec [J¨ur02b, J¨ur02a, J¨ur03] which concerns static data modelling.
UMLsec allows one to express security-related information within the diagrams in
a UML system specification. The extension is given in form of a UML profile using the
standard UML extension mechanisms. Stereotypes are used together with tags to formulate
security requirements and assumptions on the system environment; constraints give criteria
that determine whether the requirements are met by the system design.
Security Use Case Modelling
In the part about non-functional requirements of the requirements specification, the security
requirements are described in plain text for the complete system. These security requirements
affect both the data structure, as we have seen above, and the behavioural specification.
In the use case specification the functions of the system have been elaborated to use
cases. Now we have to map the overall security aspects to the use cases and extend them
if necessary. After the mapping we can decide between the following three different use
cases.
Outline of Integration and Further Development Steps
After the integration of the security aspects into both the application core and the use case
specification, the two views will be connected before the design process can begin. We extend
the class diagram with a class for every use case. This class later holds the behavioural
sequence functions.
Furthermore, the mapping of the security aspects takes place in the integration step.
Every use case has input and/or output data. If the data structure of this data is not part of
the class diagram, we have to add the necessary new classes. Additionally, we have to map
the security aspects of the input and output data. For each attribute or the whole class we
have to test whether the security specification is the same as in the class diagram. Otherwise
we have ignored some security aspects in the preceding static security data modelling or in
the security use case modelling. This adjustment brings the opportunity to add missing
security aspects and helps therefore to avoid important security problems in both the data
model and the functional specification.
For the example given in Section 4 we need a data type for the phone number and one for
the return message in the domain model, if the classes do not exist yet. The phone number,
as well as the return message are classified as security-critical in Figure 5. For this reason,
the added classes have to be classified critical, too. During the design the attributes of the
phone number class and the message class must be specified according to the classification
of the class. If e.g. the phone number class existed before the integration process started,
then we have to check the class whether it is classified critical. If not, we have detected a
disagreement and we have to adapt the domain model.