Security Architecture for Federated Cooperative Information Systems Pierre Bieber, Dominique Raujol, Pierre Siron ONERA-CERT 2 av. E. Belin, BP 4025, 31055 TOULOUSE CEDEX, France
[email protected],
[email protected] Abstract The paper describes the design and implementation of a security architecture for a Cooperative Information System implemented with CORBA technologies. We first define a role-based policy for a specific case study. We then show how this policy is enforced by an architecture made of a selection of commercial off the shelf components and a small number of developed components. Finally, we focus on the interoperability of the security architecture we have designed.
1.
Introduction
During the last decade, a great number of companies have developed their information system on a client-server basis. With the advent of Internet, companies are willing to allow clients outside the company network to contact their servers. These clients could work on behalf of company employees that want to remotely use the information system. Clients could also work on behalf of members of other companies. In that case, there should exist a partnership contract between the two companies allowing an employee from one company to use the other company information system. As server interactions were supposed to be limited to clients inside a company network, these information systems were not necessarily developed with security in mind. It is obvious that, once an information system is open, it is no longer possible to trust every client to act without malice (actually, even in a closed system it is no a good idea to trust everybody). Hence, companies should secure their information systems before they let outside clients contact their servers. We have investigated ways to secure this kind of distributed system. We focused on systems with existing software architecture documentation. By software architecture documentation we mean a description of the components the system is made of and a description of how these components interact. We assume that we cannot modify components of the original architecture to guarantee security. So the existing software architecture
has to be extended with new components in order to guarantee security. As information systems we are interested in are already running we should limit the impact of security on legitimate users. Hence, it is important that the extended architecture retains the main functionality of the original system. In this paper we describe the security architecture we designed for a collaborative information system. This system let users locate relevant resources to perform a requested service. We followed a technique for designing security architecture that is made of three steps: 1. The first step is the analysis of the software architecture in order to find out what threats could be applied to the system. 2. The second step is the definition of the security policy that lists the security objectives that should be satisfied. 3. The third step is the selection of components that enforce the security objectives. For economical reasons we will try to use SCOTS (Security Components Off-The Shelf) when possible and try to limit the development of ad-hoc security components. In the first part of the paper we present the CIDRIA Workflow tool. In the second part we describe the design of a security architecture for CIDRIA. Then we study the impact on our security architecture of the interconnection of several CIDRIA servers.
2.
CIDRIA: a Workflow server
CIDRIA is a workflow tool described in [1] that can be used to develop Cooperative Information Systems. CIDRIA is implemented as a CORBA [2] server that handles various objects: Agent objects that represent users or resources and a Cooperator object that supervises Agent objects. One benefit of using CORBA to implement CIDRIA is that each class is associated with an IDL interface that lists the methods it provides. In the following, we illustrate how these methods can be used. For that purpose, we suppose that CIDRIA is used to implement a
119
flight planning system of an airline called AirOne. Pilots would use this system to prepare their flight. A weather forecast resource called meteo is connected to CIDRIA as well as a chief pilot that decides what is the flight plan of a pilot. A flight plan contains the name of the airports the flight should connect as well as the number of passengers that check in or the weight of freight loaded. We suppose that the weather forecast provider is a public organisation whereas pilots and chief pilots belong to AirOne.
pilot
chief
Agent
meteo
Agent
CIDRIA
Agent
Cooperator Figure 1.
CIDRIA architecture
First of all, when a resource or a user client logs on CIDRIA, it invokes method connect of object Cooperator. This creates an object of class Agent, then the client interacts exclusively with this object. When a pilot wants to prepare a flight, it will invoke method request of its agent with parameter weather to request a weather forecast. The agent submits this request to the cooperator that tries to locate an agent that could provide a weather forecast. The Cooperator is able to locate resource meteo if meteo previously used method provide of its agent to register its ability to provide weather forecasts. Then the request is sent to meteo that can decide to answer it (and provide the requested forecast) or not using methods reply or reject of its agent. If the request is rejected the Cooperator will try to locate another resource providing weather forecasts. Pilot
Coop
Agent
request
Agent
meteo provide
provide request request reply
3. 3.1.
Security Architecture for CIDRIA Threat Analysis
The first class of threats is made of attacks directed at the communication link between CIDRIA and its clients. During their transit on the communication links, messages are subject to possible eavesdropping or even worse blocking, replaying or forging. In the case of CIDRIA, messages exchanged between CIDRIA and the clients contain requests, responses or object localisation information. Hence, these attacks could allow an intruder to invoke any method of CIDRIA. The communication link between a client and CIDRIA server should be protected. The second class of threats is made of attacks directed at CIDRIA services. We suppose that a CIDRIA server is operated by a company that does not trust all its clients to behave correctly. A malicious client could try to use its services in order to gain knowledge about a private data or to provide erroneous information. For instance, a malicious client could claim to be a chief pilot using method provide then the normal behaviour of CIDRIA is to forward the pilot requests for flight plan. So a malicious client could reply to these requests and provide erroneous flight plans to the pilots. A malicious client could also send a request for flight plan using method request with parameter plan. CIDRIA would forward the request to the chief pilot. If the chief pilot replies to the request, then a malicious client could learn what is the flight plan. This is a threat because the flight plan contains data as the number of passengers or the weight of freight that a company is unlikely to share freely with competing airlines. We should control that a client is authorised to provide a service. For instance, a client that does not work for an employee of AirOne should not be authorised to provide flight plans. We should also control that a client is authorised to request a service. For instance, a client that does not work for a pilot should not be authorised to ask for flight plans.
3.2.
CIDRIA Security Policy
reply reply
Figure 2.
Request resolution scenario
A security policy lists the security objectives that should be satisfied. An obvious security objective is that all the attacks should be appropriately countered. So we have to define what information disclosure or modification are authorised with respect to the application under consideration. Although in previous papers ([13], [14]), we have considered security policies in the context of multi-company co-operation where the main security objective is the protection of "Intellectual Property" and hence a confidentiality concerns. In this paper we also
120
include an integrity requirement: clients should not introduce erroneous information in AirOne information planning systems. We selected "Role-based Access control" RBAC policy (see [3] and [4]) to describe CIDRIA security objectives. In a RBAC policy, a set of roles is associated with each user according to the tasks this user should perform within the organisation. A role is the set of operations that a user playing this role is authorised to perform. In order to define CIDRIA roles we consider that CIDRIA operations are methods that appear in the interface of classes Cooperator or Agent with their parameters. Example of methods is provide or request, and examples of parameters are plan or fcast. We define the following roles: Pilot, Chief and Weather. A client playing role Pilot is authorised to invoke method request with parameter plan or fcast. A client playing role chief is authorised to invoke method provide with parameter plan. And a client playing the weather role is authorised to invoke method provide with parameter fcast. AirOne policy authorises clients with identifier ‘Ch Lindbergh’ or ‘J Glenn’ to play role chief, and client with identifier ‘Ch Yeager’ to play role pilot.
Yeager
pilot
plan
chief
Glenn
fcast weather
Figure 3.
meteo
Lindbergh
AirOne role based policy
We describe roles in a Prolog database using predicate rsj(P,R,S) that means that policy P authorises subject S to play role R and predicate rop(P,R,O) that means that policy P authorises operation O for R. /* role - subject associations */ rsj(air1,pilot, ’Ch Yeager’). rsj(air1,chief, ’J Glenn’). rsj(air1,chief, ’Ch Lindbergh’). rsj(air1,weather, ’Meteo’). /* role - operation associations */ rop(air1,pilot, [request,plan]). rop(air1,pilot, [request,fcast]). rop(air1,chief, [provide,plan]). rop(air1,weather, [provide,fcast]). Figure 4.
Prolog description of AirOne policy
Once a security officer has described its company policy, it can test it by using predicate rok(P,S,O) that
is true whenever policy P authorises subject S to perform operation O. rok(P,S,O) :- rop(P,R,O),rsj(P,R,S). As usual in a role-based policy, the actual prolog database allows to describe a hierarchy of roles. For instance, we could define two top-level roles: a user role that would authorise to invoke method request with any parameter and a resource role that would authorise to invoke method provide with any parameter. Role pilot would inherit from role user and roles chief and weather would inherit from role resource.
3.3.
Security Components
3.3.1. Principles. When designing CIDRIA security architecture we followed some basic principles as existing components reuse, or transparent and modular modification of CIDRIA original software architecture. In particular we wanted to have a clear separation between application components (CIDRIA server and client codes) and security components that we have to add. CIDRIA server code should not be modified, it should not be aware of the security extensions. CIDRIA clients might need some modifications as some method invocation might fail due to security controls. The main problem is to find a trade-off between using existing SCOTS (Secure Off The Shelf Components) and developing ad-hoc security components. The CORBA standardisation body has defined a set of security services that include access-control, identification and authentication functions [5]. We could rely on a CORBA implementation of these services to secure CIDRIA The threat analysis showed that components that protect communications between a client and CIDRIA should be added. We could select existing Object Request Brokers (for instance, Orbacus [6]) that include a secure association protocol such as Secure Socket Layer. So we do not study the protection of communication links for CIDRIA and we decided to focus on access control components. We choose not to rely on CORBA services to implement CIDRIA access control components. This decision is based on several security and ease of development reasons. With respect to CIDRIA security, CORBA access controls do not provide an appropriate granularity level. The role-based policy we have defined implies controls operating both on method names and on parameter values. CORBA access control services only operate at method invocation level. The need for finegrained control in a Workflow context was also discussed in [7]. Another security drawback of CORBA security services implementation is that it is unlikely that an ORB will be evaluated according to CC [8] evaluation criteria
121
in the near future whereas a limited and small access control component might be evaluated more easily. With respect to the implementation deadlines of CIDRIA security architecture, CORBA access control services implementations were not ready. In 1999, these services were not available in the most common ORB implementations. Furthermore the definition of security services allow some variations in the implementation, this might cause portability problems. Hence we cannot select an alternative ORB implementing these services because it is not certain that this implementation will be fully compatible with future implementations by other ORB makers. For all these reasons we preferred to add access control components between CIDRIA server and its clients rather than to rely on ORB access control services.
Pilot
Chief
meteo CIDRIASecu
AgentS
AgentS
AgentS
Agent
Agent
Agent
Role
CIDRIA
Cooperator
Figure 5.
Secure Components added to CIDRIA
3.3.2. Role-based Access Control Server. We defined a new server called CIDRIASecu that manages two new classes CooperatorS and AgentS. The interfaces of these classes are similar to class Cooperator and class Agent interfaces. Our goal is that clients invoke methods of the new CIDRIASecu component instead of CIDRIA server methods. When a client invokes method connect of CooperatorS, it has to provide the role name it is willing to play. If that client is authorised to play the requested role, then the method connect of class Cooperator of server CIDRIA is called. When a client invokes a method of AgentS such as request, reply or provide, this method first checks that the method and parameter names is an authorised operation according to the role that the client is playing. If the operation is authorised then the synonymous method of server CIDRIA is called, otherwise an exception is generated. Access controls performed by the methods of class AgentSecu are based on the description of the roles. The Prolog database described in section 3.2 is used. The prolog database is encapsulated within a C++ object that can be used by all the AgentS components. An interesting feature of Prolog is that it is possible to dynamically
reconfigure the database thanks to assert and retract built-in predicates. Hence the current access control policy may be modified without stopping the servers. This limits the impact of the access control components on the behaviour of CIDRIA. This is a fast and flexible prototyping that is portable and satisfactory for our applications. Many alternatives are possible. For instance, CORBA interceptors as used in [9] could be useful when security components should have a small impact on performances. Another close approach is the reflective one described in [10] where the authors analyse how to use this approach to integrate an authorisation system into a distributed object-oriented framework. Reflection is defined as the activity performed by an agent when doing computation about itself. A reflective system is logically structured in two or more levels: the basic level that defines the basic system behaviour and the meta-level that performs reflective actions. For security applications, access control mechanisms could be implemented at the meta-level. The reflection mechanisms can be implemented in Java where the byte-code of an unsecure application is automatically modified to invoke appropriate access control methods. 3.3.3. Border Access Control: Firewall and Wonderwall. In the last section, we made the assumption that clients would invoke the methods of server CIDRIASecu rather than the methods of CIDRIA. Of course a malicious client would certainly try to bypass the controls performed by CIDRIASecu and try to invoke directly the methods of CIDRIA. To avoid this situation, we propose that CIDRIA and CIDRIASecu servers run in a protected area called an enclave. Inside the enclave all the components are trusted and outside the enclave the components such as the clients are supposed to be malicious. So we should add functions that protect the border of the enclave (i.e. interactions between clients and components inside the enclave). We want to forbid clients to invoke methods of server CIDRIA. For that purpose, we used a SCOTS called Wonderwall [11] (produced by IONA). Wonderwall controls what objects are accessed on a server and what methods are invoked on these objects. In our security architecture, Wonderwall will allow accesses to objects in classes AgentS and CooperatorS and it will forbid accesses to objects in classes Agent and Cooperator. Wonderwall also enforces a part of the role-based policy. It controls that clients invoke methods according to their top-level roles (user or resource). For instance, Wonderwall will not allow a user client to invoke method provide or reply and it will not allow a resource client to invoke method request. The CIDRIASecu server could perform these controls, but this
122
improves the efficiency of the security architecture. Illicit invocations blocked by Wonderwall are not received and controlled by CIDRIASecu server, hence this decreases CIDRIASecu workload. One drawback of this approach is that the security officer should manage both CIDRIASecu role description database and Wonderwall configuration file. The security architecture we have designed so far could be extended with existing firewalls that usually protect a company Intranet. The firewalls should be configured in such a way that they redirect all incoming CORBA traffic (i.e. IIOP messages) to Wonderwall. This slight modification of the firewall configuration should be acceptable for a majority of companies.
Pilot
Com Firewall Wonderwall CIDRIASecu CIDRIA
Figure 6.
IGN
Role
CIDRIA Security Architecture
The previous figure shows the interaction between a client, CIDRIASecu and CIDRIA. A request from the client proceeding from Internet goes through the firewall then Wonderwall filters it. If the request is authorised, Wonderwall forwards it to CIDRIASecu. If the request passes the role controls, CIDRIASecu forwards it to CIDRIA. The response to this request takes the same path in the reverse way. We selected IIOP (Internet Inter ORB Protocol) communications in order to fulfil two objectives : we needed to allow clients and servers to communicate even if they were developed with different ORB implementations, and we wanted to be able to easily configure a firewall to authorise client-server communications. IIOP is a standard way to communicate between clients according to CORBA standards so clients written with various ORB implementation were able to communicate with our servers. As IIOP is based on TCP/IP it was possible to authorise incoming connections towards the Wonderwall component. In order to use CIDRIA services an external client needs a reference for object CooperatorS. For interoperability reasons we choose to use references in the IOR format (Interoperable Object Reference) rather than proprietary references. An IOR for an object is a record that contains the object type, the IP address of the host where the object is running, the port number of the corresponding server and a key. The key format is proprietary as it is not described in the CORBA standards.
Nevertheless this has no negative impact on interoperability as the key is generated and used only by a server to identify locally an object, a client does not use the key part of an IOR. Care should be taken when the CIDRIASecu server builds an IOR reference for the object CooperatorS as it should not contain the IP address and port number of the Wonderwall rather than the IP address and port number of CIDRIASecu. We do not detail how to generate and send this reference as tools are provided by IONA to help users generate “public” IOR references. Using IIOP and IOR we experienced no problems with clients implemented in Java with JDK1.2 built-in ORB and servers implemented in C++ with IONA Orbix ORB. Other tests should be performed to check that our solution works correctly for other ORB implementations. An alternative to using the Wonderwall product would be to write an application with similar goals than Wonderwall but based on the use of CORBA dynamic invocation. This would give us a better knowledge of this sensitive security component and might facilitate possible extensions of the security architecture as the integration of new security protocols.
4. 4.1.
Security Architecture CIDRIA servers
for
Federated
Federation of CIDRIA servers
To increase the number of resources or users cooperating thanks to CIDRIA services, CIDRIA developers thought it would be interesting to interconnect several instances of CIDRIA servers. User or resources would just need to connect to their local CIDRIA server, yet a user request could be forwarded by the federation of CIDRIA servers to relevant resources connected to any CIDRIA server. Federation of CIDRIA servers might be useful to interconnect information systems of various companies. Let’s consider that company AirOne has a partner company called AirUn. As shown in the next figure, we suppose that one instance of CIDRIA exists for each partner company (CIDRIA One is AirOne server, and CIDRIA Un is AirUn server). Furthermore we suppose that on both CIDRIA servers there exist, a chief pilot, several pilots and weather resources. The basic behaviour of CIDRIA should allow pilots from AirOne to receive their flight plan from AirOne Chief pilot, and similarly pilots from AirUn should receive their flight plans from AirUn Chief pilot.
123
pilo t CIDRIA One
Figure 7.
ch ief
Tran s l a tor ag e n t
Chief
pilot
CIDRIA T ranslation CIDRIA One agent Un provide provide list_prov
CIDRIA Un
request
request request
request
A federation of CIDRIA servers.
The partnership contract between the two companies could state that, in the case of transatlantic flights, pilots from AirUn can get their flight plans directly from AirOne Chief pilot. In this case, the federation of CIDRIA servers should forward a pilot request for a plan from CIDRIA Un server to AirOne server. In the current version of CIDRIA, there is no provision for request forwarding between CIDRIA servers. We were asked to study extensions to CIDRIA architecture that would enable to federate servers and that would be compatible with the security architecture we designed for a standalone CIDRIA server. To limit modifications to CIDRIA current architecture we proposed that CIDRIA servers should be interconnected through a class of specialised clients we called translator agents. These clients are connected to both CIDRIA servers. Hence they have the ability to receive request on one server and forward them onto another one. To illustrate how interconnection works we explain how a pilot from AirUn can receive flight plans from AirOne chief pilot. A translator agent should first forward AirOne chief pilot ability to provide flight plans on CIDRIA Un server. The translator agent invokes method provide of CIDRIA Un with parameter plan. So according to CIDRIA behaviour described in section 2, when a pilot from AirUn sends a request for a flight plan, CIDRIA Un will send this request to the translator agent. Once it has received the request from the pilot the translator agent forwards the request by using method request of CIDRIA One with parameter plan. Then CIDRIA One will send this request to AirOne chief pilot. The chief pilot reply can flow back from AirOne to AirUn thanks to the translator agent. The only modification we had to perform to implement this scenario was to add a list_provide method in the Agent interface of CIDRIA that lists all the services that are offered on a CIDRIA server. The translator agent periodically invokes this method in order to know whether it should forward services offers on other CIDRIA servers.
pilot
Figure 8.
Request resolution scenario in a federated system
Furthermore the new agents are called translator because they should be able to translate action names from one server to action names of another as it is possible that a pilot from AirUn will request a “prevision météo” rather than a “weather forecast”.
4.2.
Impact of interconnection on CIDRIA security architecture
In this section we assess whether the security architecture defined for CIDRIA standalone servers could be used for federated CIDRIA server. As shown in the following figure, we consider that two CIDRIA security architectures are interconnected through translator agents. We suppose that both information systems have defined their own security policy. We first have to check if the interconnection scenario we defined in the previous section is authorised by the access controls performed by the security components.
Chief
Role air1
Firewall Wonderwall CIDRIASecu CIDRIA One
Figure 9.
transl.
Pilot Firewall Wonderwall CIDRIASecu CIDRIA Un
Role airU
CIDRIA Security Architecture
We focus on translator agent operations as this is the main novelty of federated CIDRIA servers. It is obvious that the interconnection scenario will not work since nor AirOne neither AirUn policies associate a role to translator agents. So the security policies of the federation need to be modified to allow translator agents to perform their request forwarding tasks.
124
Bleriot Mermoz
pilote
plan
chef
StEx
prevision temps
Figure 10.
meteo F
AirUn role based policy
/* role - subject associations */ rsj(airU,pilote, ’Bleriot’). rsj(airU,pilote, ‘Mermoz’). rsj(airU,chef, ’St Ex’). rsj(airU,temps, ’Meteo F’). /* role - operation associations */ rop(airU,pilote, [request,plan]). rop(air1,pilote, [request,prevision]). rop(airU,chef, [provide,plan]). rop(airU,temps, [provide,prevision]). Figure 11.
Prolog description of AirUn policy
4.2.1. Interconnection Policy. As stated earlier, when an federation of companies information systems is built a partnership contract should be defined. This contract should say what are the authorised flows from one company to the other. For instance in the case of the transatlantic contract between companies AirOne and AirUn, we already wrote that AirUn pilots could get their flight plans from AirOne. We could add that conversely AirOne pilots are not authorised to receive plans from AirUn but they are free to get their weather forecast from any information system. AirOne does not authorize its weather service to provide forecast to AirUn pilots. We propose that an interconnection policy be written whenever a federation is created. The first part of this contract is a set of translation rules that defines how an action from one system is translated into another one. For instance, in the case of the federation of AirOne and AirUn information systems, we could have two rules: the first states that action plan from AirUn has the same name in AirOne, the second rule states that action fcast of AirOne is translated into prevision in AirUn. tra(transat,r1,airU,plan,air1,plan). tra(transat,r2,air1,fcast,airU,previsio n). Figure 12. Translations rules For each rule, a translation agent can be created that would be devoted to forwarding requests including the translated action. So we now have to define what roles could play translating agents r1 and r2. We propose to extend the role-based policies of both systems in order to allow agent r1 to receive request for flight plans on AirUn and send them on AirOne. For that purpose, we add ad-
hoc roles ofr(plan) in AirUn policy and rqt(plan) in AirOne. Similarly we add roles rqt(prevision) in AirUn policy and ofr(fcast) in AirOne. rsj(airU,ofr(plan), r1). rsj(airU,rqt(prevision), r2). rop(airU,ofr(plan), [provide,plan]). rop(airU,rqt(prevision), [request,prevision]). rsj(air1,rqt(plan), r1). rsj(air1,ofr(fcast), r2). rop(air1,rqt(plan), [request,plan]). rop(air1,ofr(fcast), [provide,fcast]). Figure 13.
Extensions to AirOne and AirUn policies
These extensions could be automatically generated from the translation rules of the interconnection contract. Furthermore, as roles are described in a Prolog database these extensions could be performed dynamically without stopping the systems. weather ofr(fcast)
fcast
pilot
plan
plan
fcast r2
rqt(previ)
chief
previ previ temps
Figure 14.
rqt(plan)
r1
plan pilote
plan
ofr(plan) chef
Federation role based policy
We can also take into account more complex interconnection contracts. For instance, AirUn could state that only a subset of its pilots is participating to the transatlantic partnership with AirOne. Pilots that do not participate to the partnership are not allowed to request flight plans to the chief pilot of AirOne. The role extensions we have just proposed would not be adequate with respect to this new requirement. For instance, all the pilots of AirUn are authorised to play role pilote, hence they can emit a request for a flight plan that CIDRIA Un will send to translation agent r1 that will emit it on CIDRIA One, the request will finally reach an AirOne chief pilot. We propose to make the distinction between a local and a remote request. We add the name of an interconnection contract to operations that may be forwarded according to that contract. For instance, the operation that pilots participating to the transatlantic partnership is described by the list [[request,plan],transat] whereas the same operation for pilots that do not participate to the partnership is [request,plan]. We then define a new
125
pilote role for that is authorised to participate to the transatlantic partnership it is called [pilote,transat].
For instance, a security officer in charge of the AirOne and AirUn federation may use this predicate to test what subjects are authorised to exchange flight plans. The query would be:
/* role - subject associations */ rsj(airU,ofr(plan), r1). rsj(airU,rqt(prevision), r2). rsj(airU,[pilote,transat], ’Bleriot’). rsj(airU,pilote, ‘Mermoz’). rsj(airU,chef, ’St Ex’). rsj(airU,temps, ’Meteo F’). /* role - operation associations */ rop(airU,ofr(plan), [[provide,plan],transat]). rop(airU,rqt(prevision), [request,prevision]). rop(airU,pilote, [[request,plan],transat]). rop(airU,pilote, [request,plan]). rop(airU,pilote, [request,prevision]). rop(airU,chef, [provide,plan]). rop(airU,temps, [provide,prevision]).
? flow([air1,airU],S1,S2,plan).
Figure 15.
New extensions of AirUn Policy
Security policy AirUn can be extended in such a way that pilot Bleriot is authorised to request flight plans from Chief pilot Lindbergh, whereas pilot Mermoz can only request its plans from Chief pilot St Exupéry. Once again the modification of the security policy does not require to stop server CIDRIA Un. We might also modify AirUn policy in such a way that Bleriot can only receive flight plans from an AirOne Chief pilot.
4.3.
Policy consistency verification
Care should be taken when modifying the role based policy, as the security officer could define inconsistent policies that would not counter the threats that were considered for CIDRIA standalone server. We have investigated ways for a security officer to check the consistency of the modified policy. A first approach consists in defining prolog predicates that help a security officer to test what permission clients of a federated system might obtain. Predicate flow(LP,S,S’,A) is true whenever the interconnection of policies LP (i.e. a policy list) authorise S to send a request for action A to subject S’: flow(P,S,S’,A) :rok(P,S,[request,A]),rok(P,S’,[provide, A]) flow([P1,P2],S,S’,A) :flow(P1,S,T,A),tra(_,T,P,A,P’,A’),flow( P2,T,S’,A’).
We are also investigating the possibility to formally prove that extensions are correct. To define a correct extension we use the security preservation property defined in [12]. This property states that a policy P' preserves policy P security if for all subject S all operation O, if P does not authorise S to invoke operation O, P' does not authorise S to invoke O. As stated in [12] the general problem securely composing policies is very complex, but we think if we limit ourselves to a small set of predefined role extensions we might be able to prove that the extension related to an interconnection contract preserves a policy security.
5.
Conclusion
In this paper we have explained how an existing architecture could be modified in order to enforce security requirements. Furthermore, we showed that the security architecture we have defined could still be valid in the case of a federation of servers. The system we have considered could be regarded as a rather simple instance of distributed system. It was designed in an objectoriented way, hence we could use an appropriate description of their software architecture. Furthermore, partners developed the system so we could get all the details we needed to know on the behaviour of the components. Nevertheless, we applied our approach to secure systems according to the rules stated in the introduction: we did not modify any existing components nor did we use our knowledge of the component implementation. We mainly added new components. We used several SCOTS: a firewall and the Wonderwall CORBA messages filtering tool. So we believe, that our approach could be valid in less forgiving cases. For instance, our approach would still be valid if we totally ignored the source code of components. In the past few years, a lot of new technologies that facilitates the development or extension of components based distributed systems appeared. For instance, we should investigate how we could use the Java framework to implement a new version of our security architecture. Another area of future investigations is the management of role based policies for distributed systems. We have written a set of Prolog predicates that can assist a security officer when defining a security policy. It would be interesting to extend this set of predicates in order to
126
offer more sophisticated services as policy visualisation, policy composition and consistency verification.
6.
Acknoledgments
The study of CIDRIA security architecture was partially funded by France Telecom/CNET contract CTI n°97IB552. Special thanks to Anne Lille, Eric Malville, Michel Milhau and Tiberiu Stratulat.
7.
References
[1] Bruno Dillenseger, François Bourdon, « Modélisation cooperation et synchronisation dans systèmes information – Une expérience Workflow basée sur nouvelles technologies », Calculateurs parallèles, volume 9, n 2, 1997.
http://www.iona.com/products/orbix/wonderwall.html [12] Li Gong, Xialei Qian, “The Complexity and Composability of Secure Interoperation”, in proceedings of the IEEE Symposium on Security and Privacy, Oakland, 1994. [13] P. Bieber, J. Cazin, P. Siron, G. Zanon,"Security extensions to ONERA HLA RTI Prototype", the Fall Simulation Interoperability Workshop, 1998. [14] P. Bieber, P. Siron, “Design and implementation of a distributed interactive simulation security architecture”, 3rd IEEE Int. Workshop on Distributed and Real-Time Applications, Washington, October 1999.
[2] OMG, "The Common Object Request Broker: Architectures and Specification ". http://www.omg.org, Dec. 1991. [3] Ravi Sandhu, Edward Coyne, Hal Feinstein, Charles Youman, « Role-based Access Control Models », Computer, February 1996, IEEE Computer Society Press. [4] D. Ferraiolo, J. Cugini, R. Kuhn, « Role Based Access Control: Features and Motivations », Proceedings 10th Annual Computer Security Applications Conference, IEEE Computer Society Press, 1994. http://waltz.ncsl.nist.gov/rbac/rbac/newpaper/rbac.html [5] OMG, "CORBA Services, Security Specification". http://www.omg.org Nov 1996. [6] Object Oriented http://www.ooc.com
Concepts,
Service
"Orbacus",
[7] D.L. Long, J. Baker, F. Fung, “A Prototype Secure Workflow Server”, in proceedings of the 15th ACSAC 1999. [8] Common Criteria, http://csrc.nist.gov/cc [9] C. Namprempre, J.Sussman, K. Marzullo, "ImplementingCausal Logging Using Orbix Web Interceptors", 5th USENIX Conference on ObjectOirented Technologies and Systems, May 1999. [10] M. Ancona, W. Cazzola, E.B. Fernandez, "Reflective Authorization Systems: Security Issues for Mobile and Distributed Objects", LNCS 1603, Springer Verlag, 1999. [11] IONA, “Wonderwall”,
127
