Security Architectures for Model Driven Web
Requirements – Financial Application Case
Study
A.V.Krishna Prasad* Dr.S.Rama Krishna1
*
Associate Professor Department of Computer Science MIPGS Hyderabad A.P. India Email: [email protected]
1
Professor Department of Computer Science S.V.University Tirupathi A.P. India Email: [email protected]
Abstract
MDA with executable UML offers an approach that embodies all the key ingredients of the process for developing dependable systems, by offering: A uniform strategy for preserving investment in existing models built using unsupported tools, by automatically migrating them to profiled UML models for subsequent maintenance and development using state of the art UML tools; A clean separation of application behavior from the platform specific implementation using technologies such as Integrated Modular Avionics (IMA), allowing the full potential of IMA to be realized in a consistent and dependable way; A semantically well defined formalism that can be used a basis for modular certification of safety related systems; The ability to generate not only the components of the target system, but components of development tool chain, providing scope for model translation and offering “executable specifications” that can be tested early and mapped reliably onto the target, leading to greater levels of dependency. MDA is a new approach for most organizations, and therefore carries additional training and learning curve costs and also currently the availability of production quality code generators is currently limited. MDA requires developers to work at a more abstract level than code although experience shows that most do not have any difficulty making the adjustment, there will be some who find this change of emphasis difficult to achieve. Building upon the initial success of MDA deployment so far, work is now proceeding on the enhancement of Ada code mapping rules to cover the entire xUML formalism. Work is also underway to develop a generic “adapter/router” component to provide a standard component to provide a standard way to interface re-engineered xUML components with pre-existing components. These techniques are now being applied to another avionics system in the same organization, in response to the customers need for a faster and cheaper upgrade capability. While we consider systematically all actions within a use case and analyze how they could be subverted, it produces all (or most) of the threats to a given application. While all this could be done in textual version of the use case, the use of UML activity diagrams produces a clear and more intuitive way to analyze these attacks. From the threats we derive necessary policies to stop or mitigate them.
1. INTRODUCTION
Defining Security Requirements through Misuse Actions: Defining security requirements is difficult and there is no generally accepted way. An important aspect of security requirements is the listening of the possible threats to the system. Only then can we decide what specific defense of information. Most approaches consider only the effect of low level attacks; e.g., taking control of the database system through a buffer overflow attack. There are two problems with this approach: the number of such threats is very high, and we need to make assumptions about a system that has not yet been built. A way to avoid the first problem is the use of sets of generic attacks, but this approach cannot avoid the second drawback.[1]
We believe that we should look at the higher levels of the system. An attacker has an objective or goal that he wants to accomplish, e.g., steal the identity of a customer, transfer money to his own account, etc. Security requirements should define the needs of the system without committing to specific mechanisms. We show here an approach to list threats by considering each action in each use case and seeing how it can be subverted by an internal or external attacker. We assume that the functional use cases have already been defined or are being defined concurrently from the list of threats we can deduce what policies are necessary to prevent or mitigate the attack. The proposed method is extendable to include formal design notations for validation and verification; we explore some possibilities. While there is no guarantee that out approach produces all possible threats, it appears superior to other approaches with similar objectives.
A related approach is the concept of misuse cases. Misuse cases are independent use cases initiated by external attackers to the system. That approach, by itself, lacks completeness because it is not clear what misuse cases should be considered? Another related approach is risk analysis. In risk analysis, threats to the successful completion and use of the system are identified and analyzed. Threat likelihood and consequences are considered in a cost benefit analysis, and plans are made to address them. Risk analysis per se, lacks a method of systematically identifying the threats; it concentrates on the effect of threats on the system.
In previous work we introduced a methodology for secure systems design that uses architectural layers and security patterns. An important aspect of that methodology is the emphasis on approaching security at all stages. The approach presented here would be one of the first stages in using that methodology.[2-4]
2. USE CASES, THEATS AND POLICIES
Use cases are interactions of a user with the system. The set of all use cases is described by a UML Use Case diagram. Each use case is described by a textual template identifying actors (or stakeholders), preconditions, post conditions normal flow of execution, and alternate flows of execution. For example, in a use case to borrow a book from the library one must check if the user has a valid account (first action), she is not overdue (second action), the copy of the book is set to not available (third action), etc. complex use cases may have many actions. Since use cases identify the actor that performs the use case, we can also identify who is the possible attacker.[5-8]
As indicated earlier an attacker has an objective or goal that he wants to accomplish. To accomplish his purposes, he must interact with the system trying to subvert one or more actions in a use case (he might do this indirectly). Low level actions, such as attacking a system through a buffer overflow, are just waste to accomplish these goals but not goals in themselves. Looking at use cases is a consistent with the idea that security must be defined at the highest system levels, a basic principle for secure systems.
There is a large variety of possible security policies and it is not clear in general, which ones are needed in a given system. Once we understand the possible threats, we can define policies to stop them. These policies are used in turn to guide the selection and implementation of security mechanisms; for example where in the system we should use authentication and the type of the authentication required. If the threads indicate we require authorization we can then find the specific authorization rules that are needed. In an earlier paper we proposed a way to find all the rights needed by the actors of a set of use cases in an application. The idea is that all the use cases of an application define all the possible interactions of actors with the application. We need to provide these actors with the rights to perform their functions if we give these actors only those rights; we are applying the basic principle of least privilege. If we define appropriate rights, attacks can be prevented or mitigated.
2.1 THREATS AND ACTIONS
(broker), who carries out the orders of the customers. Customers send orders to their brokers by e-mail or by phone. A government auditor visits periodically to check for application of laws and regulations. Refer to Figure 1 which shows the use case diagram for this institution.
Customer
Auditor
Check Trade Info Open Account
Mannager
Close Account
.Recieve Trade Order
Broker
Perform Trade
Figure 1. Use Case Diagram of Financial institution application case study
Refer to Figure 2 which shows the class diagram for the Customer, Manager, Auditor, and Broker operations.
M a nag e r
m anagerId : s tring
openA c c ount() c los eA c c ount(ac c No) provideA c c ountDetails (ac c No)
C usto m e r
c us tNam e : s tring ac c No : num ber am ount : int openDate : date c los eDate : date tradeId : s tring
openA c c ount() c los eA c c ount() getA c c ountNum ber() getA c c ountDetails (ac c No) getTradeO rder(tradeId) perform Trade() *
1
A ud ito r
t radeId : s tring
c hec kTradeInfo(tradeId)
B ro ke r
tradeId : s tring
getTradeO rder(tradeId) perform Trade() 1
*
Refer to Figure 3 which shows the accurate diagram for the use case “open account” in this institution, indicating the typical actions required to open an account for a new customer. These actions result in new information, including objects for the new customer, her account, and her card based authorization.
Figure 3. Sequence Diagram for Customer to "Open Account”.
Potentially each action is susceptible to attack, although not necessarily through the computer system.
E x t e r n a l A t t a c k s
C u s t o m e r M a n a g e r E x t e r n a l A t t a
c k e r
1 : P r o v i d e p e r s o n a l i n f o r m a t i o n If c u s t o m e r
i s Im p o s t e r o r
p r o v i d e s F a l s e i n f o r m a t i o n
2 : 2 . 1 C h e c k c r e d i t
3 : 2 . 2 C r e a te S p u r i o u s C a r d a n d d e l i v e r s to c u s to m e r If m a n a g e r
i s Im p o s t e r
4 : C r e a te A c c o u n t ( i f 2 . 1 c a s e i s tr u e )
5 : C r e a t e S p u r i o u s A m o u n t w i t h A c c o u n t ( i f 2 . 2 c a s e i s t r u e )
6 : A c c o u n t d e ta i l s a r e g i v e n a n d a s k s f o r In i t a i l d e p o s i t
9 : G e t t h e d e p o s i t
1 0 : 8 . 1 C r e a t e A u t h o r i z a t i o n d e p e n d i n g o n A c c o u n t N u m b e r
1 1 : 8 . 2 C r e a t e S p u r i o u s C a r d a n d u s e d b y t h i s Im p o s t e r m a n a g e r i t s e l f T h r e a t o f m i s u s e o f c a r d
1 2 : Is s u e t h e C a r d
7 : T r i e s t o p r e v e n t t h e c u s t o m e r t o a c c e s s t h e i r r e a l a c c o u n t s ( d e n i a l o f s e r v i c e )
8 : T r i e s t o m o v e m o n e y f r o m a n a c c o u n t t o h i s / h e r o w n a c c o u n t
Figure 4. Sequence diagram for customer to “open account” showing Misuse action. For this use case we could have the following threats.
i. A1. The customer is an impostor and opens an account in the name of another person. ii. A2. The customer provides false information and opens a spurious account.
iii. A3. The manager is an impostor and collects data illegally. iv. A4. The manager collects customer information to use illegally.
v. A5. The manager creates a spurious account with the customer’s information. vi. A6. The manager creates a spurious authorization card to access the account.
vii. A7. An attacker tries to prevent the customers to access their real accounts (denial of service). viii. A8. An attacker tries to move money from an account to her own account.
In the sequence diagram in Figure 4 the attacks are shown as misuse actions (notes). With these annotations, the attacks and vulnerabilities presented by the use case become part of our understanding of the use case and are explicit in its analysis. Note that
1. We can identify internal and external attackers. The actors in these attacks could be external attackers (hackers), acting as such or hackers impersonating legitimate roles. It is also possible that a person in a legitimate role can be malicious (internal attacks). For example A1, A3 are performed by external attackers; A2, A4, A5 and A6 are performed by insiders, while A7 and A8 are performed by either internal or external attackers.
possible attacks. The threats that we postulate come from our experience from the knowledge of the application, and from the study of similar systems (banking systems have similar threats).
3. We can later identify the target of the low level attacks. Starting from the threats to actions we can look at the lower levels of the system already designed and search for possible realizations of the threats, e.g. a buffer overflow, by passing entry points of a procedure, etc.
4. Note that we only consider attacks to our system. Attacks to system that collaborate with our system are beyond our control. For example, credit checking is normally performed using an external service. If that service was compromised we could receive erroneous information about a potential customer and make a wrong decision about his account.
5. We are not restricted to analyze each use case in isolation. Some workflows require several use cases, e.g. “Approve a purchase order” can be followed by “send a purchase order”. We can consider attacks that advantage of this sequence, for example, by bypassing some steps that perform checks. These threats, in general, are harder to find.
6. The sequence used in the example to open an account in a financial institution is very similar to opening an account in a bank, in a club, or in a library. In fact, we can think of it as a pattern and it could be an addition to a pattern for building the corresponding software. Having threat patterns simplifies finding threats for new systems.
2.2 STOPPING OR MITIGATING ATTACKS
We can now find out what policies are needed to stop these attacks. For this purpose, we can select from the typical policies used in secure systems. This selection should result in a minimum set of mechanisms instead of mechanisms piled up because they might be useful. For example, to avoid imposters we can have a policy of I&A (Identification and Authentication) for every actor participating in a use case.
To stop or mitigate the attacks in the example we need the following policies:
a. A1, A3 mutual authentication. Every interaction across system nodes is authenticated. b. A2. Verify source of information.
c. A4. Logging. Since the manager is using his legitimate rights we can only log his actions for auditing at a later time.
d. A5. A6. Separation of administration from use of data. For example, a manager can create accounts but should have no rights to withdraw or deposit money in the account.
e. A7. Protection against denial of service. We need some redundancy in the system to increase its availability. Intrusion detection and filtering policies should also be useful.
f. A8. Authorization. If the user is not explicitly authorized he should not be able to move money from any account.
The lower levels of the system should enforce these policies. If they are properly designed we don not need to identify every low level threat.
2.3 FORMALZATION
The pre-conditions for undesired consequences are presented in comments. For the analysis we focus only on sufficient pre-conditions that should not normally be present at that point in the execution of the use case. In some cases the conditions are simple conjunctions, where all conditions must be present. In other cases, the pre-conditions may involve more complicated more logical relationships among the pre-pre-conditions .[9-12]
To express relationships among pre-conditions, we have adopted the concise notation from RSML. Pre-conditions are represented in tabular form as disjunctions of conjunctions (disjunctive normal form). Each column in the table is a sufficient set of pre-conditions. Within each column, the role of the pre-condition literal (true, false, or don’t care) is given by the letters T, F, or X. For example a spurious account could be created either when a malicious manager acts without customer approval, or when there is an error (intended or unintended) in the customer information.
receiving notification. Similarly, alternative pre-conditions for a malicious person acting in the role of manager could be explored.
In analyzing this risks and their prevention, it is important to make distinctions between actual desired condition, and the mechanism that is used to achieve it. For example, a good manager is a desired condition for secure transactions. Authorization is a mechanism to reduce the likelihood of a bad manager being able to accomplish his purposes. But authorization is, itself, not the desired goal, and may, in fact, be neither sufficient nor the only means of achieving the goal condition. In this sense, our analysis approach is consistent with the spirit of goal oriented practices.
In the formalized analysis the defense policies and the mechanism must be shown to reduce the probability of each sufficient set of pre-conditions to an acceptable level of risk. An actual formal analysis is beyond the scope of the present paper. However, we can give a sense of how such analysis could be performed using fault tree and model checking techniques.
Fault tree analysis can assess the effectiveness of chosen defense mechanisms for achieving desired levels of assurance. Fault tree notation is similar to attack tree notation, but is more appropriate for risk-benefit analysis and is widely supported by commercial available tools. Probability values are estimated, where needed, and then combined to compute a probability for the occurrence for an insecure or unsafe combination of conditions and events. Continuing the example from above, a fault tree analysis would assign a non-zero value to the likelihood of a dishonest manager receiving authorization.
3. CONCLUSION & FUTURE WORK
Further work includes Designing of Dependable Security Requirements for Service Oriented Web Services Architectures.
4. REFERENCES
[1] “Define Security Requirements through Misuse Actions”, International Federation for Information Processing” (IFIP), in Book Advanced Software Engineering: Expanding the Frontiers of Software Technology, pp. 123-137 ISBN 978-0-387-34828-5, Springer Boston
[2] Sami Baydeda, Matthias Book, Volker Gruhn (Eds.), “Model-Driven Software Development”, © Springer-Verlag Berlin Heidelberg 2005, pp. 18-22.
[3] Model Driven Architecture – An Industry Perspective, Chris Raistrick and Tony Bloomfield, Kennedy Carter Ltd., Hatchlands, East Clandon, Surrey GU4 7RT, UK and BAE Systems (Avionics) Ltd., Sensor Systems Division, Crewe Toll Ferry Road, Edinburgh EH5 2XS, UK, pp. 330-350.
[4] Model Driven Engineering for Distributed Real-Time Embedded System, “From MDD Concepts to Experiments and Illustrations”, Edited by Jean-Philippe Babau, Joel Champeau, Sebastien Gerard, © ISTE Ltd, 2006, pp. 111-129.
[5] “Linking Model-Driven Development and Software Architecture: A Case Study”, Anders Mattsson, Member, IEEE, Bjorn Lundell, Member, IEEE, Brian Lings, and Brian Fitzgerald, IEEE Transactions on Software Engineering, Vol. 35, No. 1, January/February 2009, pp. 83-93.
[6] “DeMIMA: A Multilayered Approach for Design Pattern Identification”, Yann-Gael Gueheneuc, Member, IEEE, and Giuliano Antoniol, Member, IEEE, IEEE Transactions on Software Engineering, Vol. 34, No. 5, September/October 2008, pp. 667-684. [7] “NDT. A Model-Driven Approach for Web Requirements”, Marıa Jose Escalona and Gustavo Aragon, IEEE Transactions on
Software Engineering, Vol. 34, No. 3, May/June 2008, pp. 370-390.
[8] “Real-Time Agility, the Harmony/ESW Method for Real-Time and Embedded Systems Development”, Bruce Powel Douglass, Addison Wesley, Copyright at 2009 Pearson Education, Inc., pp. 1-31.
[9] “Defining Security Requirements through Misuse Actions”, Eduardo B. Fernandez, Michael VanHilst, Maria M. Larrondo Petrie, and Shihong Huang, Department of Computer Science and Engineering, Florida Atlantic University, pp. 123-136.
[10] “Dependable Layered Security Architectures – Web Services Mining Case Study”, M. Upendra Kumar,Dr.D.Sravan Kumarand B.Naveena Devi, Research Scholar JNTUH and Associate Professor, CSE, MGIT, Hyderabad.
[11] “Agile Software Development”, The Wikipedia.
