consequences of security aspect interactions on aspect-oriented modeling

Consequences of Security Aspect Interactions on Aspect-Oriented Modeling

Dan Matheson

Colorado State University Computer Science Department 211 University Services Center

601 South Howes Street Fort Collins, Colorado, 80523, USA

+1 970 225 9147 +1 970 225 9082 fax

[email protected]

Siv Hilde Houmb

Norwegian University of Science and TechnologyComputer Science Department

Sem Sælands vei 7-9 NO-7491 Trondheim, Norway

+47 735 93 440 +47 7359 4466 fax

[email protected]

Non-functional concerns are present in all software solutions and products. While the functional requirements most often drive the development of models in Model Driven Development (MDD), the modeling of non-functional concerns, such as security, is equally important for a high quality solution. The security concerns within a solution are often crosscutting, non-orthogonal and of a diverse nature. There exist a variety of combinations of security solutions, which in many cases significantly increase the solution complexity. Aspect-Oriented Modeling (AOM) is an MDD approach that helps a software engineer to develop higher quality solutions by considering various requirements independently before composing the separate sub-solution models with the core functionality. This paper looks at some of the possible aspect representations for the common security concerns of authentication, authorization, auditing, and data privacy. The goal is to develop some of the interaction concepts needed for an effective AOM approach. Mechanisms are developed for recording the interactions between the models involved in an AOM solution approach. The original concerns need to be recorded and transmitted across the various model refinement actions, as they provide goals for model analysis checks and eventually code generation tests. The invariant parts of the concerns that need to be maintained throughout the AOM development process exist both within a single aspect and between aspects. Representations of the concerns will vary according to the level of abstraction in the models, as well as the composition techniques used. Some solutions to the variations are presented. Some process guidelines that recommend the appropriate order of composition of the patterns, so that undesirable emergent properties do not occur, are listed. From the specific situations that occur with these models, generalized capabilities needed in any AOM approach are discussed.

1. Introduction

Security concerns are important in all solutions that involve the Internet [Sch00]. While software development in general is concerned with functional requirements and techniques for capturing these requirements, non-functional or quality concerns, such as security, are often only considered after the fact. This might result in systems that do not meet the end-users expectations. Aspect-Oriented Modeling (AOM) [FrR+04] is an MDD approach that helps software engineers to develop higher quality solutions by allowing them to consider various requirements or concerns independently, before composing the separate sub-solution models into a complete solution. Such concerns often appear in the requirements and are often lost during the solution development process as focus is on the functional requirements. In our experience, a major reason for the loss of the non-functional requirements is an inability to capture them in the early design models, as well as being able to track the concerns through the various model transformations.

1 Models2005 Matheson, Houmb

In the general case semi-formal methods are appropriate at early stages in the development process, because of the abstract representation of the solution. Refinement is primarily through human decisions. It is our goal to develop an approach and framework around the semi-formal methods that will lead to applying more formal techniques earlier in the design process. As we gain experience and knowledge from the semi-formal approach, the appropriate formal methods will become clearer.

Knowledge of security techniques and how to apply them effectively is uncommon among the average software engineer. Since the solutions to non-functional requirements often involve additional functionality beyond the basic core functionality, it is useful to express the solutions as security patterns, both at a generic and at a technology specific level. The use of design patterns to raise the effectiveness of a software engineer is well documented [GaH+95]. The security patterns, embodied in aspects, along with characteristics that describe their strengths and weaknesses, can be stored in a repository. This gives the software engineer the ability to make use of domain experience and choose a tested pattern in the form of an aspect model that meets the security requirements.

Even rarer than knowledge of the various security techniques is a good understanding of the interactions and dependencies. This includes the dependencies between security approaches as well as interactions with different solution engineering viewpoints. In order to support the software engineer we need to describe these dependencies and provide a technique that preserves them throughout the development, for different abstraction levels.

The first step in this process is determining a way to express the different security concerns that are present in a solution. At different levels of abstraction different expressions of the concerns and related solution patterns are needed. Requirements are often supplied in a textual form that uses domain specific terms. However, common words and phrases often appear in the requirements, these words will be used to categorize the various security concerns. At the design level the Unified Modeling Language (UML) [Uml04] will be used to specify the design patterns. The design will have both structural elements, such as classes and behavioral elements, such as interaction diagrams. The set of elements then forms a design pattern for that concern. It is possible to have several design patterns for a particular concern, which represent alternative solutions. It is also possible to have the solution represented in concrete form at the code level by using AspectJ [Asj04].

With the development of these design patterns and the translation into aspects, they can be stored in a repository for reuse. The additions of relationships among the patterns, such as a more abstract version to a more concrete version, help the engineer to understand the consequences of picking a particular solution. Solution design patterns and an AOM approach work well together.

Our primary motivation for this work is the desire to improve the quality of software solutions by representing various non-functional requirements and concerns as early as possible in the design models. There are many researcher concerns with the transformations of models into code. We are focused more on the earliest design efforts where the solution space is explored. In addition to capturing the concerns in the model we are also interested in how early the solution can be analyzed with respect to the concerns to discover problems, conflicts and for solution comparison. Since the models are at a high level of abstraction and incomplete, semi-formal techniques will often be required to do the early analysis. The linking of the early abstract representation of a concern to several possible realizations provides both a target for analysis evaluation, as well as capturing domain expertise in a reusable format.

The paper is organized as follows: To set the context of the paper we start by giving a brief introduction of Aspect-Oriented Modeling. Section 3 develops an example based on several security concerns. The next section looks at the impacts on the models that arise from the example. Section 5 explores some possible mechanisms for recording the concerns in UML models. We conclude the paper by putting the work in relation to other work as well as pointing to future research.


2. Aspect-Oriented Modeling (AOM)

Aspect-Oriented Modeling is a type of Model Driven Development (MDD) that composes several models together to create the final solution model. There usually is a primary model that embodies a solution of the most important functional requirements. There can be one or more aspect models, each embodying a solution for a non-functional requirement. The aspect models are composed with the primary model according to a set of composition rules to produce a full solution model. Early work on separation of concerns is by S. Clark [CIH+99] [CHO+99]. Later work in AOM comes from R. B. France [FrR+04] using authorization as an example. AOM extends ideas from aspect-oriented programming (AOP) to the modeling area.

The usual modeling environment is based on the Unified Modeling Language [Uml04]. The models can be from any of the UML views: class, interaction, activity, etc. The same model views in the aspect and the primary model are composed together. The order of composition is as important as the contents of the models, since an incorrect composition order can yield an incorrect solution model. This is of particular importance for the security category of aspects. Improper composition of a confidentiality aspect with an auditing aspect could place private data into an audit log. Access control is dependent on the correct identification and authentication of the user, so that a correct solution would require composition of three aspects with the primary model.

To discover unacceptable composition consequences it is important that an analysis check and testing follow any composition action. In many cases there are emergent properties of the model that are only visible after composition. When these are discovered changes are applied to any of the aspects, primary model or composition directives to correct the deficiencies.

The security concerns often apply to specific sections of a model. Different security concerns will apply to different parts of the model. The AOM approach provides a good mechanism for identifying those places and applying the solution for those concerns.

There can be several aspects that are used to represent the complementary functionality that is needed to fulfill a non-functional requirement. The aspect model can consist of additions, deletions or changes to the primary model or to previously composed aspects. Figure 1 gives an overview of the main components and process of AOM.

Composed model

Composing

Primarymodel

Aspectmodel

Mappingrules

Composed model

Composing

Primarymodel

Aspectmodel

Compositiondirectives

Composed model

Composing

Primarymodel

Aspectmodel

Mappingrules

Composed model

Composing

Primarymodel

Aspectmodel


Composed model

Composing

Primarymodel

Aspectmodel

Mappingrules

Composed model

Composing

Primarymodel

Aspectmodel


Figure 1: Overview of the AOM approach


Work on security patterns provides a reasonable starting point for developing security aspects. This work can be seen as an extension of those ideas to the MDD approach. A general overview on the state of work in security patterns can be found in [Rod03].

The primary power of aspects is that they can uniformly apply a change in specific places scattered across the whole model. Besides the application of change across a model, we find that AOM provides a useful mental approach to a divide and conquer approach to developing a solution. It is also compatible with various agile approaches to solution development.

3. Security Concerns Example

Phrases in requirements like “access is limited to second level managers and up”, “only the approved suppliers can see this information”, or from regulatory sources like “employee compensation data must be transmitted to the IRS intact” are sources of security concerns. Several categories of security concerns can be identified and need to be identified if they are to be handled effectively. The term “security” is too all encompassing to be useful. The typical security categories are:

• Identity and authentication

• Authorization and access control

• Data integrity

• Confidentiality or data privacy

• Auditing

• Data authenticity

• Availability

• Non-repudiation

Identifying users and authenticating them is the basis for handling the other concerns. This typically takes the form of a unique login identifier or name and some unique information, a password, which the user enters at the start of a session with the solution. Sometimes there are shared identifiers for access to public information. There can also be multiple pieces of information that a user must supply to prove his identity. These variations will appear in the requirements and necessitate multiple design solution options. The patterns Single Access Point and Session [YoB97] are solutions for these concerns.

Authorization is concerned with limiting what a user can do. This can apply to initiating actions or accessing data. In looking at requirements expressed in a natural language, authorization is often used to indicate limitations on a user's actions, while access control is most often used to express a user's limit on accessing data. The pattern Check Point [YoB97] is a possibility for this concern.

Data integrity requirements mostly come from two sources: 1) the business valuable data that is needed to run the business and 2) regulatory agencies, such as the FDA and laws, such as Sarbanes-Oxley They generally converge around limiting changes to the data and tracking, when the change was made and who made the change.

In addition to this simple definition data integrity can be expanded to include an understanding of the source of the data and if it is up-to-date [Rom01]. An important issue is whether or not the data comes from an authoritative or authentic source. This also extends the identity concern to servers and applications. Depending on the environment this might lead to authenticating the server or even mutual authentication. Achieving this might require additional functionality to ensure non-repudiation of the data.

The security concerns are not independent from each other. The relationships between them are shown in Table 1. The table is read row label cell text column label, for example Identity used by Authorization.


Table 1 Security Pattern Dependencies

Identity Author. Integrity Privacy Audit Authen. Avail. Non-repud.

Identity Used by Used by Used by Used by Used by Used by

Author. Requires Used by Used by Used by Used by

Integrity Uses Uses

Privacy Requires Requires Conflicts

Audit Requires Uses Requires Conflicts Used by

Authen. Requires Requires Has

Avail. Requires

Non-repud. Requires Requires

As the relationships in Table 1 indicate, there are structural and behavioral dependencies. If there is a concern about authorization, then identification and authentication of the user or principle is needed before the authorization calculation can be performed. The identification and authentication actions add functional actions and data storage requirements to the solution.

Before composition, each aspect model needs to be checked for its fulfilment of the related security requirement by using security verification, and the relation between the other security concerns and solutions need to be determined. These relations determine the order of composition. In general, a concept that is used by other concepts must be composed prior to the dependent concept. We therefore establish a preliminary concept-dependency composition tree.

Currently we have taken a simple view of the problem and present a preliminary concern-dependency tree, as depicted in Figure 2. The notation used are the Boolean logic gates AND and OR and concerns, which are represented as squares. The notation is taken from, and should be interpreted according to the risk analysis method Fault Tree Analysis (FTA) [Lev95].

The AND gate represents concerns that need to be present in order for the concern below to be fulfilled. For example, in order to have access control both authentication and authorization need to be present. Since both these concerns depend on the presence of the concern identity, access control also depends on the concern identity. Furthermore, non-repudiation depends on the presence of auditing, which depends on access control and so forth. An OR gate represent situations where one or more of the above concerns need to be present.

Figure 2 : Security concerns expressed in a tree format


Identity

Authentification Authorization

Access Control

IntegrityConfidentiality/data privacy AuditingAvailability

Non-repudiation

Possible conflicts

Composition direction

Com

position direction

For example, any of the concerns confidentiality, auditing, integrity and availability depend on access

control in order to separate both legal and non-legal users and to distinguish between legal users. Availability is defined as the ability to offer services to legal users on demand. To do this one needs access control, which depends on authentication and authorization, which again depends on identity. Availability does also encapsulate denial of service for non-legal users. However, one might also have situations where availability is handled independent of access control, which is indicated by the OR gate as well.

As indicated in the figure, there might be conflicts between concerns on the same level, and in particular between auditing and confidentiality/privacy, which need to be solved during composition. The tree structure describes the concern composition order. For the lowest level in the tree there might be potential conflicts between the concerns. These need to be resolved before composition. The general rule is that orthogonal concerns might conflict with each other, while non-orthogonal don’t. We consider all concerns at the same level to be non-orthogonal except auditing and confidentiality, which conflict as described by the thick arrow in the figure. There might also be company specific rules that need to be taken into consideration for the conflicting concerns. For example, a company might assign a high priority to auditing and therefore be willing to relax the requirements on confidentiality.

Composition is done from the top down using the relations described in the concern-dependency tree. This means that the identity aspect is composed first, then the authentication and authorization aspects are composed, and finally the access control aspect. As described by the security standard ISO Common Criteria [ISO15408] integrity of data depends on appropriate mechanisms for confidentiality, such as encryption. We therefore compose the confidentiality aspect model before the integrity aspect model.


Then the availability and auditing aspect models are composed with the primary model, and finally the non-repudiation aspect model.

The tree in Figure 2 represents the most abstract expression of the security concerns. As the concerns are refined, it is expected that the relationships expressed in this tree are also refined. These trees become the basis for model analysis that check for conflicts, omissions and that refinement actions have not broken the model invariants or constraints.

In this paper we will only deal with the first level of interactions. Further levels of interaction can be envisioned. For example, the common system login requires integrity on the identities and confidentiality on the passwords. This administration data can be composed with aspects that solve these concerns. Without a careful design process a complex spiral can occur.

The realization of the security concerns results in other concepts emerging. For example, the identity and authentication realization results in the concept of a session. The session data needs to be passed around the software artifacts and the integrity of session data needs to be maintained as well.

A well-designed solution with strong security concerns often takes a layered approach [Rom01]. As the primary model and the aspects are developed, the realization of a particular concern can result in several different mechanisms fulfilling a requirement guided by the layering principle. For example, tests on network addresses can be combined with user identification to restrict access. This can involve solution components outside the immediate software application such as a network router's ACLs.

3.1 Security Aspect Definitions

A common access control mechanism is the Role-Based Access Control (RBAC). Figure 3 presents a class model for RBAC from AOM research by I. Ray [RFL03]. It shows the classes that reflect the basic concepts of RBAC: a user, a role, a session, permissions and object classes. The class model design shows how a high level concern encapsulates a number of data entities and behavior. This emphasizes the realization of many non-functional requirements via functionality.

Figure 3 : RBAC class model

That the UML model presented in the class diagram in Figure 3 is an aspect is a result of the role it plays

with other models. Depending on the design approach one designer's primary model is another designer's aspect. There are corresponding state and interaction models, but these have been left out because of space limitations.


3.2 Security Aspect Relationships

The primary relationship from an AOM perspective is the mapping of the aspect model onto the primary model. From the perspective of security maintaining dependency and refines kinds of relationships will help produce higher quality solutions.

The dependency type relationship is used to construct a more complete security solution pattern that relates the individual security concerns involved in a solution. For example, our security concern is confidentiality. We construct an abstract model of the concern that captures the primary concepts of maintaining confidentiality. We know that supporting concepts of user identity and authentication are key to achieving that goal. The more complete and refined confidentiality aspect model will have the dependency relationship to the identity model created. Figure 4 shows the top-level dependency relationships.

Figure 4 Security concerns dependencies

Confidentiality

Data Integrity

Data Authenticity Identity

Authorization

Authentication

Security Audit

«depends» «depends»

«depends»

«depends»

«depends»

«depends»

«depends»

«depends»

The refines relationship, illustrated in Figure 5, is used to capture refinements of a concern as well as refinements of relationships between the aspect models. For example, the confidentiality concern can be refined by access control, or encryption or any other information hiding technology. If encryption is picked as the general engineering solution approach, then a number of supporting technologies are needed. If a particular encryption technology is picked, such as AES, we will need a number of appropriate supporting technologies for key management, identification, etc. For a single concern this refinement tree can be viewed as a decision consequences tree. Each refinement realization eliminates possibilities, but at the same time introduces potential conflicts or inconsistencies (consequences) with another decision made in the context of other concerns.

Figure 5 : Example of continued concern refinement

Confidentiality

Access Control Encryption Hiding

Concern

RealizationRefinements

«refines»«refines»

«refines»

DAC MAC

ACL RBAC

SymmetricKey

AES

Steganongraphy Chaffing

«refines»

«refines»

«refines»«refines»

The refinement example in Figure 6 shows how the «refines» relationship leads to a set of «depends» between concepts. At the next level of refinement there are multiple depends relationships between the


engineering refinements and domain concepts that support each model as well as newly un-encapsulated entities. This reflects a refinement similar to the viewpoints in an RM-ODP viewpoint [RMODP]. The enterprise viewpoint of the Authorization concern is refined into an engineering viewpoint of Access Control. In order to implement an Access Control solution the domain concepts of Subjects, Objects and Privileges need to be added to the model. The domain concepts also reflect relationships between refinements of fundamental security concerns. Some of the same domain concepts appear in refinements of both the Authorization concern and the Identity concern. Within a domain of interest such as security, the domain concepts must be the same. If there is a disagreement about the meaning of a domain concept it is probably an indication that the same word has been used for 2 separate concepts. Ultimately the different trees produce sets of constraints across the definition that allow for crosschecking and consistency check.

Figure 6 : Refinement relationships and supporting domain concepts

Authorization

Access Control List RBAC Capability

Concern

EngineeringRefinement

Subjects Objects

Sessions Roles Privileges

DomainConcepts

«refines» «refines»«refines»

«depends»

«depends»

Identity

Subjects

Concern

DomainConcepts

Objects

Roles Groups Aliases

«depends»

3.3 Applying Security Aspects

Selecting and applying security aspects properly requires a good understanding of the advantages as well as the risks involved. The dependencies discussed in the previous section show supporting aspects, which must be included in the composition activity between an aspect and a primary model.

Just as important as the individual aspect patterns are process guidelines with recommendations for the appropriate order of composition of the patterns, such that undesirable emergent properties do not occur. We therefore discuss design principles that can be followed to achieve a good composition result.

Schumacher [ScR01] discussed the concept of a security pattern system. The security pattern system considers the set of security patterns that work together. Currently this focuses on structural dependencies but can be extended to cover behavior. The behavioral dependencies can be used to guide the composition directives.

Design philosophy of the pattern Full View with Errors [YoB97] takes the view of showing the user everything, then checking each action. The opposite approach is Limited View [YoB97], which only shows the user what he can do. These are two different philosophies on how to choose what to make an aspect and how to combine them.


The Full View with Errors approach is often best when there are few restrictions on most of the users. The consequence is a simpler user interface, since the same user interface implementation can be used for everyone. However, in the controller section of a Model-View-Controller pattern there would still be an access check on every action. This pattern requires a supporting error reporting mechanism.

The Limited View creates a custom interface for each user at start-up. The access checks are done once. The user is faced with a specific task-oriented interface to the application, which can limit errors. This can be confusing to users if they use the application in different roles as the same application changes appearance.

Aspects can easily control session object proliferation. The session object itself is probably an instance of the singleton pattern. One needs to be careful about which values can be set and the integrity of the session object.

4. Impacts on Models

The ability to record fundamental concerns in the solution design model as early as possible has several benefits. Perhaps the most important is keeping the concerns visible to the design engineer as the solution model develops. Jumping between different documents in different forms, which is the common current practice, invariably leads to forgotten requirements and concerns. When the forgotten concerns are remembered, a significant re-design effort can result.

By recording in some fashion the (usually) non-functional requirements and concerns into the primary model, we can mitigate the problems caused by forgotten requirements. The recording of the concerns should be at an abstraction level approximately equal to the primary model. Depending on the development process it can be that the primary model is refined at a different, quicker pace than the non-functional concerns.

As the security example has shown, there are relationships between models that can be expressed and developed. The dependency and refines relationships exist within the primary model and between the aspect models and the primary model. The primary relationship from an AOM perspective is the mapping of the aspect model onto the primary model. From the perspective of this research maintaining dependency and refines kinds of relationships will help produce higher quality solutions.

The environment of an AOM approach brings additional model management requirements beyond the typical MDD environment that one currently reads about. The major requirement is the management of models that evolve at different speeds but are connected. At higher levels of abstraction the connections are between concerns and concepts, such as a person's medical status and privacy. More specific models will have several connections from an aspect model class to a primary model class. It should be possible to relate the abstract connections to a set of concrete connections.

Another concept that needs support for correct AOM results is critical sections. A critical section of a model is a place where compositions should be prevented or severely limited. In developing the models, either aspect or primary, it must be possible to indicate in the model the places that need to be protected from change. The definition of critical sections can also be placed in the composition directives. For example, auditing actions from an auditing aspect should be disallowed in some places in the encryption aspect, as that would defeat the goal of confidentiality by placing an encryption key in the audit log. The critical sections in a model imply that a simplistic name based AOM composition approach is inadequate in the general case.


5. Realization in UML

We start by assuming that we can express the information and relationships using the current UML 2.0 standard. There is a compromise between the ease of expression for the design engineer and the completeness needed for effective analysis of the models. In many cases the complexity of the solution is greater than the human capacity, and we need tools to support the designer by managing complex relations across the solution design. The test of our assumption will be through the effectiveness of the tools that we build to support this approach.

The UML 2.0 standard offers several mechanisms to handle domain specific modeling, such as stereotypes, tagged values, constraints and profiles. Since we deal with the relations between concerns, we can view the modeling of dependencies, refinements and aspect concerns as a kind of domain specific model or profile. The usages of UML 2.0 mechanisms are potential building blocks for a domain specific language to represent the concepts that we have discovered and which are described in the previous sections.

We see the potential of stereotypes to model the security concerns. This will allow the composition and analysis tools to trace and identify potential conflicts and drive the design by limiting the possible choices accordingly. We would use the stereotype capability on packages and classes to model the categories of security concerns previously identified, such as confidentiality or identity.

The next issue we need to deal with are the relations, for which we see the potential of using stereotypes on associations. The two types of relationships we need to cover at this point are refines and dependency. The refines relationship will deal with the different levels of abstractions, while the dependency relationships show the boundaries of concepts that need to be considered in order to have a complete solution. Each refinement decision bounds and limits the potential solutions, and via the dependency relationships includes concepts needed to support that decision. The reality is that the concerns are not independent, but we want to deal with the most important concerns first and accept the consequences of these decisions that are embodied by the dependency relationship. The dependency relationship is one of the most important constraints for an analysis tool to do an effective job. For a composition tool the dependency relationship provides a framework for deriving the composition rules and verifying correctness of composition directives.

As a way to deal with the different levels of abstractions we can use a tagged value to record that information. From an analysis perspective this value can be used to coordinate checks across like levels of information. We will allow this value to be set by hand, but it will eventually be set as a consequence of a tool action that supports model refinement.

The combination of stereotypes, tagged values and relationships allow a design tool to select a set of possible refinements for a concern. The tool will also be able to select potential additional aspects via dependency relationships that can be presented to the engineer as input for the next refinement decision. The same technique can be used by an analysis tool to check for correct refinement and completeness of the current solution, as well as to identify potential conflicts. Since we are dealing with abstract and incomplete solutions models, the analysis checks will still need validation by the human designer, but we will be able to illuminate conflicts that are often overlooked in a complex solution. Figure 7 shows an example of stereotype and tagged value usage.

An issue we need to deal with is the organization and management of all of these models and relationships. We can create UML packages for each of the previously identified security concerns. At the highest level we can express the dependencies between the packages as an abstraction and summation of all of the specific dependencies between model elements. Within a package we will need to represent models of the different abstraction level for a concern, from the highest level through specific technology implementations. Each of the models within a package will have constraints and invariants that can be used by analysis tools for model checking.

Critical sections can be methods, attributes, class, association and a set of classes and associations. There are generally two types of restrictions for critical sections: 1) cannot change (add, modify or remove)


via composition and 2) cannot compose with type X concern, where X refers to a set of concerns. A critical section is a constraint on the pre- and post-condition on the composition and expressed using OCL.

Figure 7 : UML security refinement and dependency example

We have discussed specific tasks involving tools and the recording of information within a model.

However, when viewed from a developer process perspective, there is a missing component. This is a repository that manages and organizes all of the packages, composition rules and tool results from the development activities. We expect the repository to be able to handle the development of multiple solutions concurrently. Although we can show static dependencies between packages from a definitional standpoint, we also have dynamic dependencies between packages as they are included or used within a solution. The volume and complexity of all of the informational relationships is beyond the capabilities of a simple code revision control application and sets of files. These are the starting points of our experimentation in the future and must be tested against the effectiveness of tools and reality of the process.

Table 2 gives an overview of the modeling components.

Table 2 Overview of realization in UML

Stereotype Base Class Tags Description

identity, authorization, integrity, privacy/confidentiality, audit, authenticity, availability, and non-repudiation

package and class

refinement_id and abstraction level

The stereotype is used to specify the type of security concern.

refines and dependency association The stereotype is used to specify the type of relation.

6. Related Work

Some of the early work on security patterns was done by Joseph Yoder and Jeffery Barcalow [YoB97]. This work predates the AOM approach and its patterns that are close to the code level. Several of the patterns that they developed can be converted to aspects, which make them applicable at higher levels of abstraction.

Security patterns and the concept of a security pattern system are discussed by Schumacher [ScR01]. The security pattern system considers the set of security patterns that work together. He also describes a template for expressing a security pattern but does not go as far as using UML or AOM. Our work extends these ideas to models in UML expressed as aspects.


Most of the work on security patterns to date is often expressed in natural language. There are a few results of recent research that uses UML, both class and interaction models, such as the Open Group [Ope04] and Priebe [PrF+04]. When UML is used, it is often in a descriptive context and as a stand-alone design, rather than as an aspect.

Related work often takes the approach of creating a security framework with pluggable components [YoB97]. At first glance this might seem like a reasonable approach, but it is static in nature. Experience has shown that the algorithm for putting the components together is nearly always custom rather than being a reusable approach. The AOM approach uses composition directives to keep the assembly algorithm more explicit and by that avoids the unnecessary framework code.

There also exists a set of security-related UML Profiles, such as UMLsec [Jur04], the security part of the QoS profile [HBL02] and SecureUML [LBD02]. However, even though these profiles all look at capturing security aspect in models, they do not cover the dependencies between different security concerns as well as how to support a software engineer during development, in terms of the combination of process guidelines, composition rules, tools and a repository. Software development cannot be fully automated, but one can provide better support by capturing experience and knowledge as it is gained. UMLsec targets security verification, which is an interesting aspect of the analysis tool that we have discussed in the paper.

The AOM community often uses security examples for explaining the concepts behind the AOM approach. However, the security examples used are merely for educational purposes. Our use of a complex security example has lead to discovering situations that must be handled in an AOM approach if AOM is to be useful in a real-world situation.

7. Conclusion

We are aware of the many standards that provide more precise definition of security concerns than we have done in this paper. We have chosen to use more casual definitions of security concerns to match the casual language used in text-based requirements. Our terms are consistent with the standards.

To support these ideas in a practical way tool support is needed. We need tools to create the lower-level concept-dependencies trees and information based on our experience. Analysis tools need to be created in order to compare the models to the concept-dependencies trees for conflicts, consistencies and omissions. To manage all this information and the complex relationships a repository is required.

This paper talks about the different security concerns in the context of Model Driven Development (MDD). The MDD context has revealed a set of relationships between the concerns in terms of refinement and dependency. We have documented the first order structure of the dependencies between the security concerns and given examples of refinements. By doing so, we have in the context of AOM, discovered new concepts that need to be handled in order to model real-world situations.

We have also developed an initial set of mappings to UML 2.0 for the expression of the information and relationships that arise from the security example. These mappings need to be validated via real implementations of the repository and AOM based tools.

One of the goals with the repository is to gather the experience and knowledge gained using the initial semi-formal approach. This knowledge provides the basis for the development of more formal methods and the progression of those methods to earlier stages of the development process.

8. Future Work

Future work relates to continue to make AOM complete enough to handle real-world situations. The fact is that still many software engineers need extensive support to be able to handle the complexity of dependent security concerns. The full consequences of all the dependencies between the various security concerns have not yet been fully explored, such as the resolution of conflicting requirements between


auditing and privacy. Improper auditing can defeat the requirement of privacy, and the understanding of when each should have priority is not well defined. The behavior interactions need deeper study, as flaws in behavior are the most predominant source of security holes.

Another issue is to look at how exceptions are handled in aspects. There is the case where too many exceptions, like failed login attempts, result in other actions than anticipated, such as locking an account.

The aspects in this paper have been studied at a high level of abstraction. Further refinement and mapping onto technologies is needed. The important questions in this exercise are related to discovering emergent properties of a real implementation. The development of code related to the design should not introduce weaknesses such as buffer overflow.

The idea of modeling an attack or a threat tree for analysis purposes is yet another extension to supporting real-world complexity and can be viewed as a kind of a constraint.. The composition of the trees and the use of the composition results by analysis tools to evaluate a solution is a future validation approach.

There are currently several projects under way covering the development of the repository, composition directives, composition tools and analysis tools. The results of these efforts will be reported in future papers.

References

[Amo03] Alfred Amos, “Designing Security into Software with Patterns”, SANS Institute, 2003.

[App00] Brad Appleton, Patterns and Software: Essential Concepts and Terminology, http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html, Feb. 2000.

[Asj04] AspectJ definition, http://eclipse.org/aspectj/.

[ClH+99] S. Clarke, W. Harrison, H. Ossher and P. Tarr, “Subject-Oriented Design: Towards Improved Alignment of Requirements, Design and Code”, Proceedings of Object-Oriented Programming Systems, Languages and Applications (OOPSLA), 1999.

[CHO+99] S. Clarke, W. Harrison, H. Ossher and P. Tarr, “Separating Objectives Throughout the Development Lifecycle”, Proceedings of the 3rd ECOOP Aspect-Oriented Programming Workshop, Springer, 1999.

[DeS00] Premkumar T. Devanbu and Stuart Stubblebine, “Software Engineering for Security: a Roadmap”, International Conference on Software Engineering (ICSE 200), 2000.

[FeP01] Eduardo B. Fernandez and Rouyi Pan, “A pattern language for security models”, PLoP Conference, 2001.

[Fer01] Eduardo B. Fernandez, Patterns for Secure System Design, 2001 http://www.cse.fau.edu/~ed

[FrR+04] R. B. France, I. Ray, G. Georg and S. Ghosh, “An Aspect-Oriented Approach to Design Modeling”, IEE Proceedings - Software, Special Issue on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, 151(4):173--185, August 2004.

[GaH+95] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Prentice Hall, 1995.

[GeR+02] Geri Georg, Indrakshi Ray and Robert France, “Using Aspects to Design a Secure System”, Proceedings of the International Conference on Engineering Complex Computing Systems (ICECCS 2002), Greenbelt, MD, ACM Press. December 2002.

[HBL02] Siv Hilde Houmb, Folker den Braber, Mass Soldal Lund, and Ketil Stølen. "Towards a UML Profile for Model-Based Risk Assessment", In Critical systems development with UML - Proceedings of the UML’02 workshop, pages 79–91, September 2002. Part of the UML Profile for Modelling Quality of Service and Fault Tolerance Characteristics and Mechanisms, http://www.omg.org/cgi-bin/apps/doc?ptc/04-09-01.pdf.

[ISO15408] ISO 15408:1999. Common Criteria for Information Technology Security Evaluation, Version 2.1, CCIMB–99–031 edition, August 1999. Part 1: Introduction and general model.

[Jur04] Jan Jürjens. Secure Systems Development with UML. Springer-Verlag, Berlin Heidelberg New York, 2004.


http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html

http://eclipse.org/aspectj/

[Kar04] Maxim V. Karpov, “Code Access Security and Design Patterns”, Microsoft .NET Best Practices, May 2004.

[LBD02] Torsten Lodderstedt, David Basin, and Jørgen Doser. "SecureUML: A UML-Based Modelling Language for Model-Driven Security". In J.-M. Jezequel, H. Hussmann, and S. Cook, editors, In the Proceedings of the fifth international conference on the Unified Modeling Language (UML’02), volume 2460, pages 426–441. Springer, 2002.

[Lev95] Nancy G. Leveson. SAFEWARE, System, Safety and Computers, Addison-Wesley, ISBN: 0-201-11972-2, 1995.

[Ope04] Bob Blackley, Craig Heath and members of the Open Group Security Forum, Security Design Patterns, 2004 http://www.opengroup.org/security/gsp.htm

[Pet01] Razvan Peteanu. “Design Patterns for Security”, SecurityPortal, June 2001.

[PrF+04] Torsten Priebe, Eduardo B. Fernandez, Jens I Mehlau and Günther Permul, “A Pattern System for Access Control”, early draft.

[RaM+03] Awais Rashid, Ana Moreira and João Araújo, “Modularization and composition of aspectual requirements”, Proceedings of the 2nd International Conference on Aspect-Oriented Software Development (AOSD 2003), 2003.

[RFL03] I. Ray, R.B. France, N. Li, G. Georg, “An Aspect-Based Approach to Modeling Access Control Concerns”, 2003.

[RMODP] Open Distributed Processing - Reference Model, ISO/IEC IS 10746 standard, 1995.

[Rod03] Ed Rodriguez, “Security Design Patterns”, Annual Computer Security Application Conference (ACSAC '03), 2003.

[Rom01] Sasha Romanosky, Security Design Patterns: Part 1, version 1.4, 2001.

[Rom02] Sasha Romanosky, Enterprise Security Patterns, June2001.

[SaB97] Ravi Sandhu and Venkata Bhamidipati, “The URA97 Model for Role-Based User-Role Assignment”, Proceedings of IFIP WG 11.3 Workshop on database Security, Lake Tahoe, California, Aug 11-13 1997

[Sch00] Bruce Schneier, Secrets and Lies: Digital Security in a Networked World, Wiley 2000, 0-471-25311-1.

[Sch03] Bruce Schneier, Beyond Fear: Thinking sensibly about security in an uncertain world, Copernicus Books 2003, 0-387-02620-7.

[Sec04] Security patterns web site for interested parties http://www.securitypatterns.org/

[Ses03] Roger Sessions, Software Fortresses: Modeling Enterprise Architectures, Addison-Wesley 2003, 0-321-16608-6.

[Smi00] Rick Smith, Authentication, Patterns of Trust, Information Security, Aug 2000.

[ScR01] Markus Schumacher and Utz Roedig, “Security Engineering with Patterns”, PLoP Conference, 2001.

[Shr02] Doshi Shreyas, Software Engineering for Security: Towards Architecting Secure Software, Information and Computer Science Department, University of California, Irvine, 2002.

[Uml04] Unified Modeling Language 2.0, Object Management Group, http://www.uml.org/#UML2.0.

[YoB97] Joseph Yoder and Jeffery Barcalow, “Architectural Patterns for Enabling Application Security”, PLoP Conference, 1997.


consequences of security aspect interactions on aspect-oriented modeling

Documents