Software Composition by Security Typing under Service ...



A Discussion on Security Typing and Measurement for SOA

Frank Tsui, Andy Wang, and Kai Qian

School of Computing & Software Engineering

Southern Polytechnic State University

Marietta, Georgia, USA 30067

ABSTRACT

In a service oriented environment, using SOA technologies, different business entities and services are combined together. Such an environment introduces various security vulnerabilities. This paper proposes an innovative approach to address SOA application security through security typing. We first define security typing concepts, its declaration and definition, with a simple security type, SST, as an example. We then explore various operations under this concept including type equivalence, type compatibility, and type inference. We show, through unary and binary operational examples, that measuring security characteristics requires a clear understanding of the metric scale level and that often times extending an ordinal scale metric to ratio level can be misleading. Our idea and approach to SST may be generalized in the future to more sophisticated security typing.

Keywords

security typing, measurement, SOA

INTRODUCTION

With the popularity of Service Oriented Architecture, SOA [ 6 ], the expectation of application software growth is increasing. SOA is less of a new technical architecture but is, rather, more of a new business paradigm for building application software from a collection of available services. Many facilities and resources such as Web Service Definition Language and Business Process Execution Language are available under the banner of SOA. Every service deployed as a part of SOA involves a mission-critical application software. Some of the traditional characteristics of software are still, if not more, relevant under this new paradigm. These major attributes include quality, security, maintainability, configurability and a long list of “ities.” Among these attributes, we are very interested in the security attribute because services interact with data, and data are critical. A company must ensure that its services are available around the clock while maintaining the data integrity and privacy, allowing only legitimate users access to the data.

Any one of the service attributes or characteristics may be viewed as a property of the service. An attribute may be represented by a type and a corresponding set of values that defines that type. For example, the security attribute may be viewed through a security type, which is defined by a set of values that the security type may be assigned. The service performance characteristic may also be defined through a performance type, which is in turn made explicit by listing the set of values the performance type may be assigned. In software engineering we have learned that there is no one universal measurement that can characterize a piece of software. Similarly, we would most likely need to use multiple metrics to characterize a computing service in SOA. In this paper, we will focus our effort on the security attribute of a software service. Any investment in SOA must be matched by the right investments in security and business continuity [8]. The openness nature of SOA raises new security issues and calls for new and systematic solutions. Security has been studied extensively using different models. One popular avenue of endeavor is the access models such as RBAC[5,9] and RT[7]. Here, we will explore security as an attribute through the concept and model of typing. In a sense, typing is an implementation mechanism for the abstract attribute of software or service. While there have been considerations of attribute based access control and policy management [1, 11], the study has been limited to designing of and an explication of specific languages for RT.

The rest of the paper is organized as follows. We will first define the general concept of attribute based security typing. An important component of this definition is the set of security values, V. The definition of the set V would be shown to be the key to the determination of measurement scales: i) nominal, ii) ordinal, iii) interval or iv) ratio from measurement theory [4]. We then explore various operations under this concept. To simplify the discussion, this paper is written with a specific security type, SST, as the example to illustrate the various perspectives of a security type. The concepts derived from using this simple SST type approach may be generalized to more complex and sophisticated security types. Security type, may, in turn, be used as a basis for designing security-typed language or security-criteria based systems. Next, we illustrate how to use security typing for SOA objects and services. We conclude with a discussion of future research issues.

SECURITY TYPING

The notion of typing has been studied by programming language experts and is readily available in textbooks such as [2,10]. We propose to utilize this traditional notion of “typing” to explore the attribute of security for software or services. We see two immediate benefits with this approach. First, typing has been thoroughly studied and widely used since 1970s. Therefore the concept and principles of typing have been well known among computing and IT personnel. Second, there is plenty of type checking algorithms and tools available to be adopted for usage in SOA.

We define a type to be a mapping of a type-name to a set of values. More formally, we define a security type to be the following.

- Let STN be security-type-names.

- Let V be a set of values.

- A security type, ST, is a mapping of

STN -> V.

There may be different security types. For example, one may define a security type based on the Common Criteria defined in the international standard ISO/IEC 15408 for computer security. In this case, one may define a security type, named STCC, to map into the 11 values representing the 11 Common Criteria or STCC -> {Common Criteria}. Clearly, the value set, V, plays a key role in defining the security type. A different definition of V will essentially provide a different security type, thus a different denotation of security type.

Here, for illustration purpose, we will propose a relatively simplified-security-type called SST. The value set for SST is defined as SV = {null, identified, authenticated, registered}. SST, for example, may be viewed as a security typing that denotes the traceability of an entity. An entity participating in SOA paradigm may be required to represent this security attribute of traceability by an agreed to variable name, x, of SST type. Thus the security attribute represented by a variable x of type SST may be shown as follows:

STT: x -> SV

It is easily recognizable that SST is just a typical enumerated type. However, the values of SV may contain further semantics. The terms identified in the set SV require further clarification. The set SV has been “declared” as {null, identified, authenticated, registered}, but we need to “define” this set. The value set, SV, will be defined as follows.

- A software or service may be null, meaning we know nothing about it.

- It may be identified, meaning its owner is established.

- It may be authenticated, meaning the identified owner is ascertained to be who he/she says he/she is.

- It may be registered, meaning the authenticated owner has successfully registered the software or service within the business paradigm.

Perhaps, to illustrate the difference between declaration of SST and definition of SST, it may be prudent to use different syntax to show the SV declaration and SV definition. One may use braces, {null, identified, authenticated, registered}, for declaration and brackets, , to stand for SV definition.

We will not discuss how identification, authentication or registration is actually implemented in the SOA, but assume that they are enforced by the security mechanisms provided by the SOA infrastructure. The important point here is that a security type needs not only be declared but must also be defined. With the above definition of SV, we force SST to be a mathematical function. That is, a security variable, y, may be mapped into identified and/or authenticated if it is authenticated. But since authenticated subsumes identified here, we have

SST(y) = authenticated

Note that SV = is an ordered set where the elements are defined in such manner that there is a “subsume” relation. Thus from metric theory [4], we know that the value set, SV, is beyond the nominal level, and is at least at the ordinal level. That is the following ordinal relationship holds for SV.

null < identified < authenticated < registered

Note that one may argue that the “subsume” relation is a partial ordering rather than the total ordering portrayed here. A deeper discussion and definition of the set SV is needed. We will not engage in that direction in this paper, except to comment that here we view “, which is a proper subset of SV. Then consider a variable, x, of type SST and a variable y of type SST’. The casting of x to y, which is like a “downward” casting, such as the following pseudo-code should be allowed, with care, because SV’ is a subset of SV.

y := (SST’) x

In general, we would still admonish against such casting. The reverse, perhaps, should not be allowed. If one chooses to allow “upward” casting, then the rule must be very carefully considered. Type Compatibility is a vital issue that needs to be explicitly articulated.

Even if the value sets are defined with the same number of elements with “syntactically similar” terms, we still need to be wary of the semantics of the elements of the value set. Thus, for service and/or software to operate with an SOA paradigm in multiple industry domains, we need to determine if the security types are compatible and if type coercion [3] is allowed.

While it may be interesting to consider polymorphism, for security typing it is most likely not a good idea to have a service or software to be polymorphic across different security types until a business situation arises that demands such a scenario.

UNARY OPERATIONS WITH SECURITY TYPED VARIABLES

A security type, such as SST, which is defined with the enumerated values forming an ordered metric, also allows us to further expand the definition. Variables, x and y, may be declared and assigned a value as follows:

(declaration) SST y, x

(assignment) y := authenticated

With such a declaration and assignment, several operations may be meaningful for a security variables, x and y. These include unary operators such as “upgrade,” “downgrade,” “least” and “most.”

First, define a label function for the variables of SST type such that it maps to a numeric set {0,1,2,3}, respectively. Then, label(x) = 0 if x has the SV value of null, label(x) = 1 if x has the SV value of identified, etc. The operator rules are as follows.

- least (y) sets label(y) = 0.

- most (y) sets label(y) = 3.

- downgrade (y) = least(y), if label(y) = 0; otherwise set

label(y) = label(y) - 1.

- upgrade (y) = most(y), if label(y) =3;

otherwise set

label(y) = label(y) + 1.

With this definition, then upgrade(upgrade(y)) sets label(y) = label(y) + 2. Note that if label(y) + 2 > 3, then y is, by definition, set to most (y). The successive downgrade operations are defined in a similar manner, but in reverse with a lower bound of label(y) = 0.

One may also consider binary operators. One obvious one is the assignment operator, := (x,y), which we have already utilized above. The value assignment of the security typed variable and the operations on the security variable may carry even a deeper meaning. For example, assigning two SST security variables, x and y, expressed as follows, may carry different meanings.

x := upgrade(y)

In its simplest form, one may interpret this as just “improving” the security value of y and assigning it the result as the value of the security variable x. At a level where x and y may be declared to be SST type but SST type is a type declaration for an Object instead of just a data, then our definition of assignment need to be expanded further. We will also note that there may be much more discussions needed on the earlier mentioned unary cast operator, but in the interest of space that discussion will be a subject of a future paper.

BINARY OPERATIONS AND MEASUREMENT PROBLEMS

Earlier we considered Type Equivalence and Type Compatibility. For binary operators, we need to include the concept of Type Inference. Type Inference addresses the issue of determining the type of some expression based on the types of the constituents. We show the problem of Type Inference from this traditional view with the abuse of the security type in a FOR loop example. However, more interestingly, we show a kind of type inference problem through binary operations used as measurement. Also, note that the “label” function defined above provides us with a measurement of “degree-of-security” or “degree-of-traceability” within the SST type. One may interpret the label function as a measurement of 0, 1, 2, and 3 degrees of security. We will see that while the binary operations may seem to make algebraic sense, once the measurement of degree-of-security is included in the interpretations, there is grave danger of potential misinterpretations.

First, consider the binary operator max(x,y) which is defined as follows.

max(x,y) = x, if label(x) > label(y) ;

= y, otherwise

This binary operation looks innocuous with the interpretation that max operator results in the security variable with a higher degree-of-security measurement; thus allowing us to pick the entity with the higher SST type variable.

Now, consider a more interesting binary operator, the difference operator, diff(x,y), which is defined as follows.

diff (x,y) = | label(x) – label(y) |

Diff is the absolute value of the difference between the label of x and label of y. Earlier, we stated that for SST type, SV values formed an ordered set of values. With the “label” function, we appear to have further extended the measurement from ordinal scale to the next level, the interval scale. The reason why the term, “appear,” is used will become apparent. If diff(x,y) = 2, it would mean that the difference between the security attribute as defined by SST type for the security variables x and y is two degree-of -security apart according to the label function. The semantic of two degrees is not clearly defined here because of the following problem. Consider:

SST x, y, z ;

x := null ;

y := identified;

z := authenticated

Then, diff(x,y) = 1 = diff(y,z). This only means that the difference in degree-of-security is the same. But the real magnitude of the difference is not necessarily the same, even though both yielded the number 1. That is, the difference between null and identified is not necessarily the same as the difference between identified and authenticated. Although, we have extended the measurement with the “label” function into the interval scale, it is really a misinterpretation. For the same reasoning from metric theory, defining a binary operator, ratio(x,y), such as the following would be dangerous.

ratio (x,y) = label(x) / label (y)

Suppose label(x) = 3, and label(y) = 1. Then the ratio operator would say that the degree-of- security for x is 3/1 or 3 times that of degree-of-security of y. This obviously is a misinterpretation of the measurement because while registered is more secure, it is not necessarily three times as secure as identified. One needs to be extremely careful in the definition of operators for the security variables and extending its interpretation to some metric. The basic definition of the security type must be well understood first. Then the measurement function must be used within the context of the measurement scale. We showed how one can, from an ordinal security type SST and using the “label” function, develop an ordinal scaled metric such as the “degree of security.” However, certain binary operation definitions may lead one to dramatically erroneous interpretations of that metric.

Another area of danger is the overloading of typing. In an SOA paradigm, software with most(y) or a service with least(x) may be requested. This is meaningful because SST is defined, and both x and y are security attribute declared as SST type. However, security typed variables should not be loosely used or abused. It may be tempting, but the security typed variable should not be used as an iteration counter. That is, the form of iteration computing represented by the following pseudo-code should not be allowed.

for (SST y := null; y < most(y) ; upgrade(y))

This example illustrates the need for some strong type checking for security typing. The exact rules for type checking have yet to be defined as we gain experience in using security typing in software and services.

SECURITY TYPING FOR OBJECTS IN SOA ENVIRONMENT

In this section we show how the notion of security typed variables may be extended to security typed Objects. We will take some liberty with the syntax and stay at the conceptual level. This is one way to extend the concept, not necessarily the only way. An object may be of certain type. For example, an object X may be of Class type Webserv in an SOA environment. Then what does it mean to say this Class, Webserv, is also security typed? Assume the same, previous SST security type definition; we define Webserv to be SST security typed as follows:

- Webserv includes an attribute y of type SST

- Webserv includes a set of operational methods

- The Constructor of Webserv Objects initializes the attribute y to one of the values of SV.

Most of the concepts of unary and binary operators carry over and may be applied as the methods that need to be implemented for the SST typed Webserv Class. However, the concepts of Type Equivalence, Type Compatibility, and Type Inference need to be re-examined. The notion of Type Equivalence for security typed variable was discussed earlier, and for security typed Object this concept does not differ much from security variables. Similarly, Type Compatibility also extends well with possibly minor modification.

The third notion of Type Inference also carries over rather naturally. In assigning SST typed variable with a value from the set SV to one that is of different value in the same SV is viewed simply as either “increasing” or “decreasing” the value of the security attribute y. In the case of security typed Objects, the assignment of one security typed object to another of the same type, such as SST, could mean more than just adding or subtracting the value of the security variable y. The rules for Type Inference will depend on how the operational methods are defined. For example, the statement, x := successor(y), which was discussed earlier and made sense for security typed variable, now needs a slightly object oriented perspective. If these were Objects X and Y, then Object X is a successor of Object Y would mean that the appropriate method in Object Y is executed and the security attribute y is increased to the next value of SV. We use the term, appropriate method, to purposely allow the definition of the method to be open ended. Consider the following pseudo statements.

public class Webserv{

define the security attribute y

define the methods for operators

}

public class Dosomething {

---

Webserv X := new Webserv (identified)

Webserv Z := new Webserv (null)

Z := Webserv.successor (X)

---

}

In this simple example, the assignment operator must operate as object assignment. The “new” operator is the constructor operator, which initializes the object to the appropriate security “degree-of-security” for the objects and the “successor” method is a method defined in Webserv that increases the “degree-of-security.” Thus the objects of the same security typed Webserv class may operate within the same domain of interest. For SOA, there are many different services offered by multiple enterprises for multiple purposes and with multiple security typing. Thus through WSDL, one will need to tag these Objects with a security typing note for consumption in SOA environment. Clearly, we need to address the issue of Classes with different security types and their operational characteristics. That would be a topic for a future paper.

Conclusion and Discussion

We have proposed security typing as a mechanism to describe the attribute security for software and for services that may be used in an environment such as SOA. The notions of Type Equivalence, Type Compatibility and Type Inference were explored. Also, the significance of metric theory was shown via the definition of the value set, V. There are clearly more to be expanded both on the theoretical and application level. It is our intent to first apply this concept of security typing and model its usage in heterogeneous business domain environment. This allows us to further understand how different security types with different value sets would interplay. We then plan to revisit the theoretical underpinnings of security typing and improve on what we have before embarking on future tasks such as defining a new security-type based language for security management.

Many other topics in this area deserve further research. First, security typing may be application dependent. Different programming languages have different typing systems. A typing system defines how a programming language classifies values and how it can manipulate those types. We need to classify various services in SOA into well-sorted category of services. Second, the semantics of security typing deserves more attention. Typing is a way of abstraction as well as a way to provide meaning to a collection of raw data. For SOA services, we need to investigate appropriate security typing systems for each class of services. Third, traditional type-checking has been implemented at compile time or run time. For SOA, security type checking requires a well-defined typing rules and enforcing mechanism. Automated tools would be essential to apply to security typing theory and models in practice. Finally, strongly-security-types SOA services would secure SOA applications at service request level as well as at SOA package level. We would like to see an SOA application considered if all the services involved are “type-safe.” The security typing operators should help guarantee that the overall system is indeed secure through the right typing operators to bridge a highly fragmented set of authentication and authorization services, databases, and other administrative services in an SOA system.

REFERENCES

[1] Bandhakavi, S., Winsborough, W., and Winslett, M., “A Trust Management Approach for Flexible Policy Management in Security-Typed Languages,” Proceedings of 21st IEEE Computer Security Foundations Symposium, June 23-25, 2008, pp 33-47.

[2] Bruce, K.M., Foundations of Objected Oriented Languages, Types and Semantics, MIT Press, 2002.

[3] Cardelli, L. and Wegner, P., “On Understanding Types, Data Abstraction, and Polymorphism,” ACM Computing Surveys, vol. 17, No. 4, December 1985, pp. 471-522.

[4] Fenton, N.E. and Pfleeger, S.L., Software Metrics A Rigorous and Practical Approach, 2nd Edition, PWS Publishing Company, 1997.

[5] Finn, T., Joshi, A., Kagal, L., Niu, J., Sandhu, R., Winsborough, W., Thuraisingham, B., “ROWLBAC-Representing role Based Access Control in OWL,” Proceedings of Symposium on Access Control Models and Technologies (SACMAT 08), Colorado, USA, June 11-13, 2008.

[6] Glass, R., “SOA Essentials”, DOD SoftwareTech News, Vol. 11, No. 1, June, 2008.

[7] Li, N. and Mitchell, J.C., “RT: A Role-based Trust-management Framework,” Proceedings of the 3rd DARPA Information Survivability Conference and Exposition (DISCEX III), Washington D.C., USA, April, 2003.

[8] Benson, M., et al, Secrets of SOA: An Enterprise View on Service Oriented architecture Deployment Revealed, Larstan Publish Inc., 2006.

[9] Sandhu, R, Coyne, E.J., Feinstein, H.L., Youman, C.E., “Role-Based Access Control Models,” IEEE Computer 29(2), February, 1996, pp. 38-47.

[10] Scott, M.L., Programming Language Pragmatics, Morgan Kaufman Publishers, 2000.

[11] Swamy, N., Hicks, M, Tse, S., and Zdancewic, S., “Managing Policy updates in Security-Typed Languages,” Proceedings of 19th IEEE Computer Security Foundations Workshop (CSFW06), July, 2006.

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

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

Google Online Preview   Download