In SEMDA framework, security enhancement phase is one of most important steps during the entire evolution process, whose task is to perform security improvement for the target system on the basis of the abstraction artefacts from the reverse engineering phase in Chapter 4 and in line with the elicited security requirements in Chapter 5. The approach to improve the security level of legacy system in this thesis is security pattern which is defined as “a security pattern describes a particular recurring security problem that arises in a specific context and presents a well-proven generic scheme for its solution [150]”.
3.2.3.1 Security Pattern
Security patterns are the best practices documented to solve the security problems, which make it possible for security novice to solve the security problems with the proven security expert solutions. In order to support the security evolution for legacy system, security patterns need to be formatted in terms of security related information and organised to facilitate the mapping from the elicited security requirement to the corresponding security patterns.
For the security related format, security pattern is represented as 3-tuple <Context,
Problem, Solution>, where Context means the environment the security problems arise, Problem means the threat or attack the security pattern solves and Solution provides the
approach how security pattern solves the security problem in the given security context. In this study, thirty-two well-known security patterns are selected to form the pattern repository and organised by the proposed multi-aspectual classification metric including lifecycle, layer, threat type, application context, domain, and security concerns.
3.2.3.2 Security Ontology
After examining the security risks in the legacy system, a set of security requirements have been elicited. There exist a number of security patterns to solve the security problems in the corresponding context. How to associate security requirements with corresponding security patterns is the key of the proposed SEMDA framework.
Ontology is the formal representation of the entities and relationship that exists in some domain. Ontology is useful for representing and inter-relating many types of knowledge. Security ontology is the application of ontology in information security domain.
In order to relate security requirements with security patterns, ontology is used to represent the concept and relationship among security requirement elements and security pattern elements which forms some kinds of security ontology. The proposed security ontology is written in OWL which is the current recommendation of the World Wide Web Consortium (W3C) for exchange of semantic content on the web. By defining security requirement ontology and security pattern ontology properly, this allows to the correct results of the knowledge that can be inferred from the proposed security ontology by applying the corresponding restrictions and axioms.
3.2.3.3 Security Pattern Integration
Generally speaking, security pattern integration is fairly straightforward. The extracted model from legacy system can be annotated according to the elicited security requirement. Security patterns are represented as UML diagrams. The thing to be done is to integrate these UML models according to the security requirement and security pattern, e.g. user account is a kind of asset treated as an element in UML models and needs authenticator pattern to protect against unauthorised access threat. The more detailed integration will not be discussed in this thesis because the integration techniques can be adopted through existing research.
3.3 Summary
In this chapter, a unified reengineering approach, SEMDA (Security-driven Software
Evolution Using Model Driven Approach), is proposed for software evolution in terms
of security domain.The SEMDA Approach mainly contains three stages, which are security reverse engineering stage, security requirement elicitation stage and security enhancement stage. Some domain analysis and assessment methods, software reengineering methods, and intelligent information process methods and techniques are applied to implement
SEMDA projects:
• Legacy system understanding and extraction. This is the process of assessing whether legacy system needs to be evolved according to current user’s security objectives. It comprises model extraction, model slicing, system partition, and security mechanism detection stages. The acquired results will be prepared to start next stages.
• Security requirement elicitation. This is the process to elicit security requirement systematically. A risk assessment approach is proposed to satisfy the need which consists of asset analysis, threat analysis and vulnerability analysis. Quantification metrics are proposed to measure the security level for each security requirement as well as whole system. The outcome of this stage is a formatted security requirements list which will be satisfied by next stage research.
• Security enhancement. It is the final stage where security patterns will be selected via proposed security ontology according to the elicited security requirement. • The proposed approach has been regarded as a semi-automatic process that involves
a series of manual work on the representation from domain analysis, and automatic transformation with defined rules can be implemented with toolset support.
Chapter 4
Legacy
System Understanding
for
Security
Objectives
__________________________________________________________________
To understand the legacy system To extract models from legacy system
To construct intermediate diagram CSDG for slicing.
To propose a model slicing algorithm based on the CSDG graph
To present system decomposition method according to independence metric To detect existing security mechanisms in the legacy systems
_____________________________________________________________
4.1 Overview
Security concerns usually scatter many aspects of software system, especially for those based on the web called web applications. As mentioned in Chapter 2, such software systems are faced with lots of security problems such as design defects, vulnerability exploit and lack of security mechanisms etc., which increase the maintenance cost, difficulties and cause huge losses not only to the economy but also to the reputation of the corporations where the systems are applied. Evolving these software systems for security purpose conforms to the needs of system designer and customer.
For a legacy system, if adequate system design documents exist at hand, it will do benefits to security redesign. Unfortunately, with the just opposite, in most cases, these documents are lost or not well documented which is insufficient to be used for redesign.
Under such circumstances, reverse engineering for the legacy system is needed to achieve high level design artefacts from the legacy code.
However, legacy system in real world are usually huge in size, ranging from tens of thousands of Lines of Code (LOC) to millions of LOC. Obviously, the UML models generated from it would be huge. Legacy systems have static and dynamic aspects. The static aspects include software elements and their relationships, while the dynamic aspects mainly concern the sequential events that perform the tasks. In static modelling, high-level elements are found and subsystems or other logically connected software elements may be represented. In dynamic modelling, behaviour descriptions that show interactions among high-level static elements are abstracted.
Dependency analysis is an important way to analyse, understand and maintain program. It reflects the execution sequence and call relationships among program statements and modules. Lots of dependency analysis methods for programs have been proposed. However, the program dependency analysis methods cannot be directly applied to dependency analysis for UML models since UML is a modelling language which is independent of programming language.
When considering security concerns on the system model level, it requires the designers to figure out the relationships between a specific security-related model element and other model elements. When facing with such issues, system designers might skim through software design artefacts or even source code to discover the relationships. However, even for good software documentation, it is not easy to accomplish the task. Model slicing as the slicing technique in model level can meet such requirements by concentrating on certain relevant aspects according to corresponding slicing criteria. Figure 4-1 depicts the operational framework for this chapter, and each activity in the framework will be elaborated in the following subsections. System design model in UML static and dynamic diagram can be recovered during the model extraction phase by using reverse engineering tools. An intermediate representation graph called Class Scenario Dependency Graph (CSDG) is constructed based on the dependency analysis of class diagram and sequence diagram and then is computed by model slicing according to the specific slicing criteria. The output slices can be used to decompose the
legacy system based on the proposed decomposition algorithm. A system domain model describing the higher level abstraction of system will be generated after the partition. At last, in order to evaluate the security level of legacy system, security countermeasures in the current design are to be detected with the help of defined security artefact base. The output of Chapter 4 is a system domain model as well as security implementation checklist.
Figure 4-1 Operational Framework for Chapter 4