Towards a Unifying View on Security Contracts

Transcription

1 Towards a Unifying View on Security Contracts Bart De Win, Frank Piessens, Jan Smans, Wouter Joosen Katholieke Universiteit Leuven Celestijnenlaan 200A 3001 Leuven, Belgium {bartd,frank,jans,wouter@cs.kuleuven.ac.be ABSTRACT A key property of software component technology is predictability, which means that the properties of an overall system can be deduced from the properties of the individual components. One of the crucial building blocks in component technology is the notion of component contract. In order to leverage predictability for the construction of secure systems, security requirements and properties must be adequately supported by component contracts, which is currently a challenging and open problem. This paper provides an overview of the problem domain by presenting an initial taxonomy of security contracts and their representative security properties. Keywords security contracts, component technology, secure software engineering 1. INTRODUCTION Building a (sufficiently) secure system is a challenging task. Besides the inherent complexity of securing a standalone application, additional side-conditions such as distributed execution and untrusted code make this problem even harder. One of the problems in this context is that, due to the increasing size of software, it is no longer possible to develop a secure system with a small, controllable team of (skilled) developers. As a result, security officers that are willing to guarantee the overall security properties of such systems are eager to take risks or just plain ignorant. Component technology can be of help in this context, both as a foundation to structure large software systems as to support the reasoning about security properties of overall systems. After all, one of the core ideas of component technology is to be able to predict the overall properties of a system out of the properties of individual software components, achieved, among others, through the concept of component contracts. For security, this means that it will become easy to reason about the combined system security properties. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Software Engineering for Secure Systems Building Trustworthy Applications (SESS 05) St. Louis, Missouri, USA Copyright 2005 ACM /05/05...$5.00. Consequently, the trustworthiness of developed systems can increase dramatically. Security covers a broad spectrum of problems ranging from buffer overflows to secrecy or privacy issues and, hence, the range of security properties that can be associated with components is considerable. Unfortunately, the contractual support for these properties in commercial component based technologies such as Sun s EJB [8], OMG s CCM [19] and Microsoft s COM+ [5] is fairly limited. Typically, only authentication and authorization is supported, and even then only in a limited form. In the research community on the other hand, a lot of effort has been put in determining system security properties out of individual component properties, but mostly for very specific security properties (such as information flow). In all, a comprehensive solution to this problem, or even a clear overview of the problem is lacking. This paper addresses this situation by elaborating on the impact of security on component technology, in particular on component contracts. We identify different types of security contracts and we discuss security properties that are part of these contracts. This paper is a position paper that is the result of initial research. Rather than providing definitive answers to the aforementioned problems, the goal of the paper is to stimulate discussions on this topic. The remainder of this paper is structured as follows. First, the context of the topic discussed in this paper is sketched by introducing both component technology and security. Next, the main part of the paper elaborates on security contracts in more detail. A substantial set of security properties is discussed in this context. A brief discussion of related work and a summary conclude the paper. 2. SETTING THE SCENE This section introduces the necessary context for this paper, both for component technology and security. Furthermore, assumptions that hold are explicitly stated as well. 2.1 Component technology in a nutshell According to [3], a component is a software implementation that can be executed on a physical or logical device. A component implements one or more interfaces imposed upon it, describing the methods or services offered by the component. A component satisfies certain contractual obligations which ensure that independently developed components interact in predictable ways. A component contract is an agreement between a set of components, which describes the contractual obligations between these components. From the viewpoint of a single

2 component, these obligations are bidirectional: they can relate to requirements as well as to provisions. A contract can be either a single conceptual instance, or it can be conceived as a contract template and instantiations that fill in the parameters which are unspecified in the template. Evidently, the benefit of the explicit specification of a contract is the extra possibility to query and enforce all contractual obligations in a component based system. Beugnard et al. have identified four levels of contracts with increasingly negotiable properties [4]: syntactic, behavioral, synchronization and quality of service. Syntactic contracts can be thought of as simple interfaces describing methods, parameters and exceptions, while behavioral contracts add class invariants and pre- and postconditions to methods. Synchronization contracts specify the global behavior of components in terms of synchronizations between method calls. Finally, quality of service contracts quantify component behavior. As will become clear later, all types of contracts are relevant in the context of security. 2.2 Security in a nutshell Security is from a high-level perspective concerned with the following properties [13]: Secrecy : controlling who gets to read information. Integrity : controlling how information changes or resources are used. Availability : providing prompt access to information and resources. Accountability : knowing who has had access to information and resources, and under what circumstances. In the context of software security, all security issues relate to information to be protected, and the way this information is handled (in contrast to for instance physical security). A wide variety of mechanisms has been proposed to ensure these properties (e.g., cryptography, access control,... ). Some of these mechanisms will be described further in this paper. For the discussion in this paper, we start from a java-like language and execution environment. All security measures that are available in this setting (i.e. type safety, bytecode verification and sandboxing) are assumed given for our discussions as well. 3. SECURITY CONTRACTS AND THEIR PROPERTIES The goal of this section is to broaden the notion of security contracts with regard to the set of supported security properties. As not to restrict initial discussion, a wide range of security properties is presented in the examples. Subsequently, the specification of contracts and their enforcement is briefly addressed. The description of security properties can be structured according to different axes. For instance, one could distinguish between properties that relate to security functionality (e.g., a dedicated non-repudiation protocol) contrary to software quality (e.g., avoiding buffer overflows). Or, the enforcement of some properties lends itself better to monitoring (e.g., denial of service), while other properties are more amenable to third party certification (e.g., information flow assurance). For this research, the authors chose to divide security properties according to their association with different types of contracts. This is based on a conceptual model of a component based system to be described next. This distinction does not relate to the exact manner to specify contracts in practice. Rather, contract types are distinguished based on the conceptual nature of the relation existing during the execution of a system, and linked security properties. Note that this categorization is not fully orthogonal: the intersection of the different contract types is not necessarily empty, and as will become clear later, some security properties associate with multiple contract types. 3.1 Relevant security properties The conceptual model of component based software application and its supporting infrastructure is depicted in Figure 1. An application consists of several functional components (F1 and F2) that invoke each other s services. Furthermore, security components (S1 and S2) are responsible for specific security functionality. Functional components can invoke a security component s service in order to enforce a particular security requirement. Components are deployed in a component container, which hides other supporting infrastructure such as a virtual machine or specific security infrastructure (e.g., a public key infrastructure). 1 Finally, it is important to remark that, although the figure only includes a single component container, a distributed application consists of components that are by nature deployed on different containers. In this setting, we can identify four different types of contracts (numbered 1 4), explained in the next sections: functional interaction, interaction protocol, security-specific interaction and infrastructure Type 1: Functional interaction A first important set of security contracts relates to single dependencies between components (indicated by number 1 in Figure 1). Think of a source component (F1) that outsources some functionality to a target component (F2) through method invocation. In this case, the source component must make sure that any information from the execution context that he provides to the target component is not misused by the latter. And vice versa, the target component must have means available to protect his valuable services from non-relevant or unsafe source components. We distinguish three different targets for security properties: parameter, method and component Type 1a: Parameter-level properties. Security properties can influence the way in which method parameters and return values (i.e. input and output values) are represented during method invocation and subsequently handled. This might be necessary for instance because the communication channel that is used to transport the information cannot be trusted, because the exchanged infor- 1 Security services can be offered either as separate security components or through the container. Within this conceptual model, the distinction is mainly twofold: (1) security mechanisms have or do not have to be constructed as components explicitly, and (2) the use of these security components is available to security-aware components (since they must invoke the component explicitly) or to all components deployed in the container (which can enforce them transparently).

3 sufficient. After all, a piece of information that is marked confidential is freely accessible by the peer component and, hence, can be used at will, for instance by disseminating this information further. Consequently, it is sometimes necessary to restrict the uncontrolled use of parameters values even further, by specifying additional security restrictions. In the community this type of problem is known as information flow security, and it is strongly related to mandatory access control models [17]. The idea is essentially to control and restrict all possible ways to acquire, process and distribute information. Different types of security properties have been studied, including non-deducability, noninterference and perfect security (for an overview see [22]). Recently some of these properties have been implemented as programming language extensions (see [16]). Figure 1: Overview of security contracts mation requires special measures to be protected from distrusted peer components, or simply because the functional activities of the other party require the data to be secured in a certain way. Several security properties are important at the level of method parameters, and a security contract in this context specifies a set of restrictions on parameters and return values. A first set of objectives that immediately comes to mind in this category are standard information security properties that involve techniques such as encryption, digital signature, and so forth. It is evident that security-sensitive parameters need to be protected when a particular component service is actually invoked. For instance, a transfer service on a banking component requires sufficient security guarantees with respect to the specific amount and account number. This can be achieved in several ways. A component contract could include indications describing the sensitiveness of invocation parameters and results. In the banking example, the transfer amount and account number could be marked for instance as confidential and integer. It would then be up to the component container to decide how to enforce properties appropriately, which definitely depends on the specific execution context. A key example of this is the CORBA Security Service [20], which provides as part of the secure association configuration exactly those two parameters that were described before. Alternatively, parameter security properties could also be specified in a more operational fashion, by specifying the way in which information must be transformed for the purpose of security. For instance, confidentiality could be described as well by means of the following label encrypt(algorithm, key, amount ). This example matches the notion of Kahn s security contracts [12] closely (see Section 4). The latter type of description is interesting for instance in case the security properties are fixed by particular external systems requirements. In the case of distrusted peer components, the protection of sensitive information by the beforementioned means is not Type 1b: Method-level properties. Restricting the use of services of a component constitutes a next level of protection. Several restrictions that control the direct use of a service will be discussed first. Indirect restrictions for collaborating with distrusted components follow. A contract in this context specifies a set of restrictions on the level of methods. A first straightforward security property that is relevant at this level is authorization. 2 The idea is to restrict the use of particular methods of a component to a set of privileged principals that are allowed to access the service under certain conditions. Standard access control techniques (e.g., discretionary, owner-based, and so forth) can be used for this purpose. Current component technologies provide this type of feature. Sun s EJB [8] and OMG s CCM [19] for instance provide a means to specify which roles are allowed to execute some particular functionality. However, there are two important observations in this context. Firstly, this is only a limited form of authorization: for instance it is not possible to take attributes of subject or object into account other than the role of the former, nor any other contextual properties (such as time or location). It is clear that substantial progress has to be made to provide support for the specification of these properties as well. Secondly, the contractual support offered by deployment descriptors is limited: there is no way for a peer component to know and take into account the restrictions that apply to the original component. Another example of method-level contracts are so-called permission-preconditions. These preconditions are used in the context of stack inspection and specify the dynamic permission set (by default, the intersection of the static permission sets of all code currently on the call stack) that a method requires the caller to have in order to execute without security exceptions. For instance, consider the permission-precondition (requiresp-clause) on the method Connect in Figure 2. This precondition indicates that callers need WebPermission unless connecting to localhost. Observe how Connect s preconditions propagates to its caller RemoteConnect. In [18], the authors discuss how these preconditions address some of the shortcomings of stack inspection, such lack of declarativeness and run-time performance overhead. A third example is delegation (or in a more limited form 2 Remark that authorization at the level of method parameters is not useful, since they can typically not be accessed separately (besides through getter/setter methods).

4 Class C { void Connect(bool IsLocalhost) requiresp new WebPermission() when! IsLocalHost; { if(! IsLocalhost) { new WebPermission().Demand(); //create connection void RemoteConnect() requiresp new WebPermission(); { Connect(false); Figure 2: Illustration for permission-preconditions. impersonation), targeting scenarios in which a component s service requires the identity of the invoking component to complete its task. Different forms of delegation exist, and the CORBA Security Service specification [20] provides a good overview of several possibilities. In the above examples, component contracts are specified by the component to which the contract is applicable. For instance, access control properties on a service are typically specified by the component that offers the service. On the other hand, in case of collaboration with distrusted components, it can be desirable to specify these contracts for indirect use (i.e. for other components). Consider the following scenario: a banking component offers a service to inspect an account, realized by providing the customer a reference to a general purpose account component. However, at the same time, the banking account wants to enforce the customer component (and to all of its related components) to only use the account component for certain operations (e.g., only for inspection purposes). For this purpose, it could insist on realizing an additional contract between the customer and banking component on the use of the account component. So, method-level contracts can be useful as well for restricting the use of other components. This idea can be implemented perfectly by using restricted proxy references. However, our point is exactly that the same idea can also be enforced by using contracts in a non-standard way, which makes the use of these proxies unnecessary Type 1c: Component-level properties. Security properties at the level of components influence the global cooperation between components, both in the nature of the cooperation, as in what is expected technically. A contract at this level is a set of global security properties. Some concrete examples of security properties that are relevant at this level: Trust in another component is a first relevant security property. This can relate to both the functional implementation of the component, as well as to the quality of the implementation (for instance, such that it does not contain buffer overflows or the like). For instance, a component could demand that all components that he interacts with are signed by certain parties, as to be able to trust the implementation of the component. Alternatively, the functional properties of a component can be guaranteed by some form of proof (for instance, proof carrying code [14]). Liability agreements between components, although more related to the enforcement of security properties than to the properties as such, are also relevant at this level. Liability properties can determine who is responsible for not meeting certain security properties, and under what circumstances. This might be particularly interesting in the case of complex interaction scenarios Type 2: Interaction protocol The secure use of a component s services is not only determined by restrictions on a single method invocation, as was the case for all properties mentioned above. In fact, the implementation of some services requires separate invocations to obey a specific interaction protocol that dictates the exact order and possible repetitions of some set of related invocations. Hereby, the correct execution of the component can only be guaranteed when the interaction protocol is adhered to correctly. While this may seem strongly related to the reliability of a component system, the security properties of the component can be affected as well. For instance, access control rules could require some state of the component, to be initialized by previous invocations in the interaction protocol. Some examples of interaction protocols are given next. Remark that an interaction protocol can involve more than two parties. A network socket is one example component that could operate according to an interaction protocol. In particular, a socket must be used in the following way: 1. The socket must be first initialized, which opens the network connection that is represented by the socket. 2. Afterwards messages can be read from or written to the network socket. 3. Finally the socket must be closed again, which cleans up the open network connection and all related connection state. Another example is a fair payment protocol, ensuring that a single party cannot get the benefit from a payment transaction (i.e. either receive goods without payment, or receiving payment without having sent the goods). This can be achieved for instance by subdividing the transaction in small subtransactions to make sure that when cheating, only a small benefit is gained over the other party. This set of exchanges could be modeled as an interaction protocol. As a final example, a multi-party non-repudiation protocol would be a perfect candidate interaction protocol. In this case, several parties may have to exchange data with a neutral nonrepudiation service, which will then generate some desired proof and provide all parties with this proof. The trend in the software engineering research community to support the explicit specification of interaction protocols (e.g., type states [7], interaction contracts [11] and abstract communication types [2]) substantiates the relevance of this type of contracts. The authors are not aware of the application of interaction protocols for the sake of security contracts in particular. It is interesting to remark that contracts for functional interactions and interaction protocols can interfere in the

5 sense that the specification of one type of contract is influenced by the other type of contract. We give two examples. Firstly, as a result of an interaction according to a protocol contract, the access control invocation rules may change: suppose that all methods have equal restrictions, it then becomes possible to only specify restrictions for the beginning states of the protocol ; the intermediate states can only be accessed by passing through the initial states. Secondly, the access rules may change to incorporate the current state of the interaction protocol Type 3: Security-specific interaction To some extent, the cooperation of a functional and a security component can be treated similar to the cooperation of functional components as discussed above (type 1 as well as type 2). The transfer and use of sensitive data could indeed be secured in a similar fashion, and extra properties with regard to trust apply equally well. However, the invasive character of security, or more correctly of particular security components (see [6]), results in two important differences: obligation-like contracts and additional non-functional interfaces. A contract in this context is an agreement between a functional and a security component on a set of obligations and extra interfaces. Each of those are discussed in more detail. Traditional contracts typically imply an optional use of services: other components can choose whether to invoke a component s service or not. Restrictions on this invocation may apply, for instance in case of interaction protocols where an invocation might require the invocation of other methods first, but the use of the protocol is still a matter of free choice. The situation is sometimes different for functional-security component cooperation: in this case the security component may require the functional component to activate certain behavior in some well-defined place in order to implement a particular security requirement. In that sense, a component might dictate certain obligations for invocation on other components. Take access control for instance: a reference monitor component could enforce an access control policy, under the condition that the functional component activates (i.e. invokes) the reference monitor for all sensitive operations. A contract in this context could state that all sensitive places must be identified, and the reference monitor must be invoked at these places. Auditing is another example. An auditing component could provide secure logging of a system given that all components invoke the auditing component whenever necessary. Remark, again, the interference with previous contracts in the sense that the security properties specified for a method might be deduced from the sensitive places specified in this context, or vice versa. While a security-specific interaction could be modelled as an interaction protocol, type 3 contracts differ from type 2 contracts because of information hiding purposes as well. After all, the client of the to-be-secured component is typically not interested in the technical manner in which some security requirement is enforced: this is purely a matter of implementation. Also, the subject of a type 3 contract is not a multi-component interaction, but rather a dedicated relationship between a security and a functional component. Hence, the use of interaction protocols for security-specific interactions is not appropriate. Besides the specific, obligation-like type of interaction, a security component often requires additional information to complete its task. In the case of access control for instance, all parameters that are involved in the access attempt, or the state of the sensitive resource, might be necessary to evaluate an access control policy. This information can be provided (i.e. pushed) by the functional component when activating the services of the security component. However, often this information is pulled from the functional component as to avoid passing much non-relevant information. In the latter case, a security component will evidently require the peer component to obey an extra (non-functional) information interface through which it can be queried for this information. This problem has been partly addressed in the work on access interfaces [21]. Remark that this extra interface is not necessarily limited to a two party interaction: information from different sources can be necessary and, hence, multiple parties can be involved in this type of contract Type 4: Infrastructure A last category of contracts is related to the underlying infrastructure on which components are deployed, including the component container, the virtual machine and supporting security infrastructure. Contracts of this type are mostly concerned with the security services of the infrastructure that are available to deployed components and with the configuration of these services. We discuss the usefulness on contracts for each of the identified parts of the infrastructure. A component container can offer several security services to a component deployed within this container. For instance, authentication of the principal on whose behalf a component is executing is typically enforced by the container. Or, a secure way of communicating between (possibly distributed) components could be offered. In general, security contracts in this context specify the activation of these services, their configuration and the interfaces that can be used to interact with these services. In the case of authentication, configuration could involve the level of authentication that is used (e.g., weak vs. strong). Some relations with the virtual machine can also be captured in a security contract. In particular, code access security, where the permissions for low level resources (such as files) depend on the specific modules that require these resources, can be made more explicit in a security contract. In this case components could specify the necessity for such permissions. Finally, requirements for extra security infrastructure such as a PKI, some sort of secure storage, or an anonymous networking infrastructure could be specified in a container contract as well. In this case, this specification is probably in the form of a required interface. In case of the anonymous networking infrastructure, statistical properties about the level of anonymity could be relevant as well. 3.2 Contract specification and enforcement In the previous sections, several contract types and specific security properties were discussed. However, it is far from clear what security contracts will look like in practice, and how they should be realized. For this matter, several issues have to be addressed, including: contracts and properties The conceptual model of the previous section has helped the identification of sev-

6 eral contract types from an conceptual point of view. However, in practice security contracts do not necessarily align with this subdivision. It is probably more convenient to structure component contracts according to the interfaces they support. granularity of specification A particular parameter-level property could be specified at the method-level as well, given that it is identical for all parameters of a method. A decision on this matter involves a trade-off between flexibility and applicability. security property levels The description of security properties can be supported by means of various types of metrics or values, ranging from abstract descriptions such as anonymous to concrete mathematical or probabilistic values such as 80% anonymity within this group. specifying entity Some security properties can be specified by the component developer, while others are only known to the system composer or deployer. For each of the properties, it must be clear by whom it must be specified. This closely relates to the stakeholders of the contract: who is interested in it and who benefits from it. contract aggregation The impact of the composition of components on their security contracts must be clear. In particular, contract operations for each of the different security properties must be specified. The workshop might provide a good forum to discuss these matters, but it is out of the scope of this paper to address this further. Likewise, the enforcement of component contracts, which can be achieved using techniques such as component certification, static verification or run-time monitoring is not further discussed. 4. RELATED WORK The notion of security contracts is present in several commercial systems and research prototypes. The support for security in the Enterprise JavaBean model [8] and the CORBA Component Model [19] is very similar. Both support some form of authentication and authorization (basic role based access control), which can be configured in the deployment descriptor of a component. This deployment descriptor can be seen as a security contract between a component and its container. Similarly, components in Microsoft s COM+ technology [5] can be secured using several mechanisms: role-based access control, authentication, impersonation or delegation and software restriction (code access security). This is enabled either programmatically, or declaratively through configuration within the Component Services administration tool. Again, the specifications in the latter case could be seen as a security contract between a component and its container. In [12] Khan and Han propose a framework for the specification of security properties for components. The security properties they address are based on the Common Criteria [1], but it is unclear to which extent the different types of contracts discussed in this paper are supported. Apparently, the main focus is on contracts of type 1 (parameter-, method- and component-level). Furthermore, run-time support for security contracts is offered by means of the notion of active interfaces. Security properties in an active interface are supported in two different manners: statically defined properties that are specified and certified for a component in isolation, and dynamic compositional security contracts (CSCs) that determine security properties for a composition of components and that are negotiated on at composition time. Finally, Components with Quantitative properties and Adaptivity (COMQUAD [10]) offers a component model that supports the specification and enforcement of non-functional properties (NFP), security being one of them. Each component can have different implementations and associated profiles that describe the NFP of a particular implementation. The properties are enforced by the component container, which is responsible for instantiating and connecting components. Hence, profiles are component contract indications towards the container. While type 1 and 4 contracts are targetted (as discussed in [9]), type 3 contracts are out of the scope of this work since security properties are meant to be enforced transparently. Likewise, type 2 contracts are not addressed either. From the perspective of building secure systems, reasoning about the security properties of a composed system can be achieved by means of appropriate contract operators, which can compute security properties for an aggregation of two components (this has not been discussed in this paper). However, other means do exist to defer the overall security properties of a system based on the security properties of individual components. CAESAR [15] for one is an evaluation framework for measuring the security level of a distributed information system. An evaluation consists of two phases: (1) a modeling phase in which a distributed system is modeled according to different dimensions and (2) an evaluation phase in which an algorithm estimates the global properties of the system. Compared to the use of contract operators, this is a more top-down inspired approach of the problem. 5. CONCLUSION This paper has addressed the use of component contracts for describing the security properties of individual components and their interactions. Four different types of contracts have been identified based on the conceptual nature of the relationships in the execution context, and different security properties have been discussed to substantiate and illustrate their existence. As such, a substantial number of component security properties have been categorized in a systematic way. This effort is part of a larger effort to enrich component technology with security in order to better predict and enforce security properties for overall systems. As this is only a premature effort to address this problem, the authors see many topics for future work. Firstly, the set of discussed security properties can be further extended as to gain confidence in the representative coverage of the problem domain. Secondly, the concrete definition and structure of security contracts could be addressed. As discussed before, the contract types discussed in this paper do not necessarily match with specific contracts. Thirdly, the construction of specification languages that support quantifying statements for a large set of security properties is necessary. Finally, the enforcement of security contracts is a totally different problem that requires further attention.

7 6. REFERENCES [1] Common Criteria for Information Technology Security Evaluation, Version 2.1, August [2] M. Aksit, K. Wakita, J. Bosch, L. Bergmans, and A. Yonezawa. Abstracting Object Interactions Using Composition Filters. In R. Guerraoui, O. Nierstrasz, and M. Riveill, editors, Proceedings of the ECOOP 93 Workshop on Object-Based Distributed Programming, volume 791, pages Springer-Verlag, [3] F. Bachmann, L. Bass, C. Buhman, S. Comella-Dorda, F. Long, J. Robert, R. Seacord, and K. Wallnau. Technical concepts of component-based software engineering - volume ii. Technical Report CMU/SEI-2000-TR-008, Carnegie Mellon, Software Engineering Institute, Pittsburgh, PA , May [4] A. Beugnard, J.-M. Jézéquel, N. Plouzeau, and D. Watkins. Making components contract aware. IEEE Computer, 32:38 45, July [5] K. Brown. Programming Windows Security. Developmentor series. Addison-Wesley, 1st edition, July [6] B. De Win. Engineering application-level security through aspect-oriented software development. Phd, Department of Computer Science, K.U.Leuven, Leuven, Belgium, Mar xiv pages. [7] R. DeLine and M. Fändrich. Typestates for objects. In M. Odersky, editor, Proceedings of the 18th European Conference on Object Oriented Technology (ECOOP), volume 3086 of Lecture Notes in Computer Science. Springer Verlag, Nobember [8] L. G. a. DeMichiel. Enterprise JavaBeans Specification Version June [9] E. Franz and C. Pohl. Towards unified treatment of security and other non-functional properties. Report of the AOSD2004 workshop on AOSD Technology for Application-level Security (AOSDSEC), CW387, pages 11 16, to appear. [10] S. Göbel, C. Pohl, S. Röttger, and S. Zschaler. The comquad component model: enabling dynamic selection of implementations by weaving non-functional aspects. In AOSD 04: Proceedings of the 3rd international conference on Aspect-oriented software development, pages ACM Press, [11] H. Jonkers. Interface-centric architecture descriptions. IEEE Computer Society, August [12] K. Khan and J. Han. Composing security-aware software. IEEE Software, 19(1):34 41, January/February [13] B. W. Lampson. Computer security in the real world. Presented at the Annual Computer Security Applications Conference (ACSAC), [14] G. C. Necula. Proof-carrying code. In Conference Record of POPL 97: The 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages , Paris, France, jan [15] M. Peterson. Caesar: A proposed method for evaluating security in component-based distributed information systems. Master s thesis, Linköping University, [16] A. Sabelfeld and A. C. Myers. Language-based information-flow security. IEEE Journal on Selected Areas in Communications, 21(1):5 19, January [17] R. Sandhu. Lattice-Based Access Control Models. IEEE Computer, 26(11):9 19, November [18] J. Smans, B. Jacobs, and F. Piessens. Static verification of code access security policy compliance of.net applications. Submitted to the 3rd International Conference on.net Technologies, [19] The Object Management Group (OMG). Corba components - version 3.0. formal/ , June [20] The Object Management Group (OMG). Corbaservices: Security service specification, version 1.8. formal/ , March [21] T. Verhanneman, F. Piessens, B. De Win, and W. Joosen. View connectors for the integration of domain specific access control. Report of the AOSD2004 workshop on AOSD Technology for Application-level Security (AOSDSEC), CW387, pages 42 48, to appear. [22] A. Zakinthinos and E. S. Lee. A general theory of security properties. In SP 97: Proceedings of the 1997 IEEE Symposium on Security and Privacy, page 94. IEEE Computer Society, 1997.