Author Guidelines for 8



Analyzing Information Flow Control Policies in Requirements Engineering

Khaled Alghathbar

King Saud University

P. O. Box 85373, Riyadh 11691,

Saudi Arabia.

ksa@

Duminda Wijesekera

CSIS & ISE, George Mason University, Fairfax, VA 22030, USA.

dwijesek@gmu.edu

Abstract

Currently security features are implemented and validated during the last phases of the software development life cycle. This practice results in less secure software systems and higher cost of fixing defects software vulnerability. To achieve more secure systems, security features must be considered during the early phases of the software development process. This paper presents a high-level methodology that analyzes the information flow requirements and ensures the proper enforcement of information flow control policies. The methodology uses requirements specified in the Unified Modeling Language (UML) as its input and stratified logic programming language as the analysis language. The methodology improves security by detecting unsafe information flows before proceeding to latter stages of the life cycle.

Introduction

Today, most security requirements such as the information flow control policies are considered only after completing functional requirements. Consequently, less secure systems are developed because security aspects are not properly engineered through the software development life cycle. Considered a non-functional requirement (NFR) security related requirements are considered difficult to express, analyze and test [10, 6]. The consequences of ignoring NFR result in low quality and inconsistent software, unsatisfied stakeholder and more time and cost to re-engineer.

Consequently, the need to formally analyze and validate security requirements during earlier phases of the software life cycle have been proposed earlier [8, 4] to detect and remove design vulnerabilities before proceeding to other phases.

Information flow control policies restrict information flowing between objects. Thus, it prevents unauthorized flows. This paper proposes a high-level methodology to analyze proper enforcement of information flow control policies during the early phases of the software development life cycle so that flow violations can be detected before proceeding to later phases where the cost of fixing them are amplified. Our methodology uses the Unified Modeling Language (UML) [13] as the source of design specification and integration. Also, the methodology uses stratified logic programming language as the language of analysis because it facilitates automated reasoning. Proposed methodology is not restricted to a particular meta-policy, and is flexible to facilitate the enforcement of a particular policy to any subset of the specification.

The remainder of this paper is organized as follows. Section 2 shows information flow specifications embedded in UML’s sequence diagrams. Section 3 describes the methodology. Section 4 describes the larger scope of the methodology. Section 5 describes related work and section 6 concludes the paper.

Specifying flow in the UML

The UML is the de-facto design language for large software projects. The UML uses multiple diagrams (views) to represent requirements and designs. In UML based software design methodologies, requirements are specified using use cases at the beginning of the life cycle. They are textual descriptions of usage scenarios between the system and its intended users [5].

Use cases are refined into interaction diagrams that specify greater detail, such as how objects in the use case interact with each other to achieve system objectives. Interaction diagrams are important for us because they present detailed flow information between different objects of the system. Consequently we take them to be the beginning point for information flow control policies.

Sequence diagrams are specific interaction diagrams that show such interactions as a sequence of messages exchanged between objects and ordered with respect to time. The sequence diagram shown in Figure 1 consists of four objects and two actors, where Actor A initiates the first flow as a request to read information from Obj3 which then returns the requested information. Secondly, Actor A writes information to Obj4 and forwards it to the control object. The control object triggers other flows to other objects. Therefore, information may flow directly from an actor to an object or indirectly flow from an actor to an object through other object(s).

[pic]Figure 1: Sequence diagram

Methodology

Analyzing information flow control policies in the software systems requires two kinds of information:

1. Information flow requirements.

2. Information flow control policies.

Information flow requirements are embedded in general functional requirements. For example, in a functional requirement that allows a customer to place an order, there is an embedded information flow requirement from the customer to the billing department and another to the shipping department.

While information flow requirements are a kind of functional requirements, information flow control policies are not. The later are higher-level statements that must be enforced on functional specifications. Consequently, there can be one or more policies to be enforced on different parts of a design.

Therefore, identifying and separating each one of those information provides flexibility in analyzing the enforcement of the information flow control policies. We can now clearly know which policy to enforce on which information flow.

Steps of the proposed methodology

The methodology consists of four general steps, as shown in Figure 2. The first step starts by transforming information flows implied by each use case that is represented as a sequence diagram into predicates. Because sequence diagrams can be drawn in tools such as Rational Rose, this transformation can be automated. Because this step transforms direct flows, the second step enumerates all possible flows that traverse through several hops. For example, in Figure 1, if Actor A reads information from obj3 then writes it to obj4 then there will be a flow from obj3 to obj4. Also, the second step enumerates all implicit flow that can be implied from the actor hierarchy. For example, if Actor C is a specialized actor of Actor A, then all flows that start or end from/in Actor A will be also start or end from/in Actor C. This step uses the predicates to specify information flows and it uses rules to derive transitive and implied information flows. The following predicates are examples of the predicates used in the first and second steps:

Flow(Initiator, Src_Obj, Dist_Obj,Value, Time)

for direct flow.

mayFlow(Initiator, Src_Obj, Dist_Obj,Value, Time) for transitive flow.

Following is an example recursive rule that derives all possible transitive information flows.

mayFlow(Xa, Xobj, X’obj, Xatt, Xt)(

Flow(Xa, Xobj, X’obj, Xatt, Xt)

mayFlow(Xa, Xobj, X’obj, Xatt, Xt)(

Flow(Xa, Xobj, XBTWobj, Xatt, Xt)

mayFlow(Xa,XBTWobj,X’obj, Xatt, X’t),

Xt < X’t

Previous steps specify information flow requirements. The 3rd step specifies information flow policies in the form of Horn clauses. Examples of policies are: (1) ensuring particular actor must not send information to another particular actor, (2) specific information must not flow from one entity to another. An example of policy written in rules is:

unsafeFlow(Xa,Xobj1,Xobj2 Xatt)(

Flow(Xa,Xobj1,Xobj2, Xatt,Xt),

(dominates(Xobj1,Xobj2)

The previous rule detects any information flowing between two objects where the recipient does not have higher or equal security label as sender.

After building the bases of requirements and policies, the last step is to analyze the information requirements and detects any violation of any specific policy. The process starts by taking the specified policies that are specified in rules and execute those rules on all existing information flow requirements that are specified in predicates. The outcome of this step is classifying each flow to either safe or unsafe flow.

[pic]

Figure 2: Steps of the Proposed Method

The larger scope

This section describes the larger scope and applicability of the methodology. As shown in Figure 3, the first step is to transform the geometric information in UML views to a set of basic predicates of information flow rules written as Horn clauses.

Beside the basic predicates used to capture the geometric information given in the UML sequence diagrams, other Horn clauses constitute the policies that are applicable at the early stages of the software design cycle. Thus, this division of predicate layers shows the clear separation of the basic geometry of the design from policy.

This separation of policy from the application has many consequences. The first is that it facilitates applying any policy to any design. As shown in Figure 3, policies B and C can be separately applied to the sequence diagram of use case A. Similarly, as shown, policies A and C can be separately applied to the sequence diagram of use case B. This shows that more than one policy applies to one design diagram and that one policy applies to more than one diagram.

Secondly, the same process can be used to check the consistency of two design diagrams with respect to a given security policy. That is, if two design diagrams are compliant with a given policy, then as far as that policy is concerned, they are indistinguishable. We propose to develop this concept further in designing a notion of policy based equivalence of design diagrams in UML. Thirdly, if UML policies can be separated from designs as shown here, then a policy composition framework for UML policy compositions along the lines of [14] can be developed. Lastly, by capturing more rules related to geometries of sequence diagrams, one may be able to capture deficiencies in the diagrams. If successful, this may lead to a rule based reverse engineering framework for UML diagrams.

Related work

Although information flow has a rich publication history, most papers concentrate on designing newer and richer flow control models such as [12, 3] that do not address flow policies and verifications techniques that go hand in glove with software design life cycle models.

At the other end, research such as Myers [9] focus on analyzing the information flow during the implementation phase while we propose is to be used during the requirements, design and analysis phases of the software development life cycle.

In the area of logic-based checking of policy violations during the requirement engineering, Alghathbar et al. [1] developed AuthUML, a logic program based framework for that analyzing access control requirements during the requirements engineering phase to ensure consistency, completeness and conflict-freedom. AuthUML approach is similar to this paper approach. However, AuthUML only focuses on the access control policies.

Conclusions

The main objective of this paper is to improve the security of software systems. We propose to do so by presenting a methodology to analyzes information flow requirements and ensures its compliance with specified information flow control polices. This analysis is to be applied at the early phases of the software development process.

Reference

[1] K. Alghathbar, D. Wijesekera. “authUML: A Three-phased framework to analyze access control specifications in Use Cases”. In proc. of the Workshop on Formal Methods in Security Engineering, Washington, DC. Oct. 2003.

[2] D. Bell and L. LaPadula. “Secure computer system: United exposition and Multics interpretation”. Technical Report, , MITRE Corp.. Bedford, MA, 1975.

[3] E. Bertino and V. Atluri. “The specification and enforcement of authorization constraints in workflow management”. ACM transactions on Information Systems Security, February 1999.

[4] B. Boehm. Software engineering economics. Englewood Cliffs, NJ: Prentice-Hall. (1981)

[5] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, MA, 99.

[6] L. Chung, B. Nixon, E. Yu, J. Mylopoulos. Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers (2000).

[7] D. D. Clark, D. R. Wilson. “A Comparison of Commercial and Military Computer Security Policies”. In the proc. IEEE Symposium on Security and Privacy. 1987.

[8] P. T. Devanbu and S. Stubblebine. “Software engineering for security:A roadmap”. The Future of Software Engineering. ACM Press, 2000.

[9] A. Myers. “JFlow: Practical mostly-static information flow control”. In Proc. 26th ACM Symp. on Principles of Programming Languages, San Antonio, TX, Jan. 1999.

[10] B. Nuseibeh and S. Easterbrook. “Requirements engineering: A roadmap”. In A. Finkelstein, editor, The Future of Software Engineering. ACM Press, 2000.

[11] Rational Rose. .

[12] P. Samarati, E. Bertino, A. Ciampichetti, and S. Jajodia. “Information flow control in object-oriented systems. IEEE Transactions on Knowledge and Data Engineering”, July-Aug. 1997.

[13] The Unified Modeling Language version 1.5. . Accessed in September 2003.

[14] D. Wijesekera, S. Jajodia, “Policy Algebras for Access Control - The predicate Case”. In the Proc. 8th ACM Conference on Computer and Communications Security, Washington, DC, November 17-22, 2002.

[15] J. Rushby. “Security Requirements Specifications: How and What?” In the proc. of Symposium on Requirements Engineering for Information Security. Indianapolis, IN. March, 2001.[pic]

-----------------------

[pic]

Figure 3 FlowUML’s scope

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download