Formal Techniques for an ITSEC-E4 Secure Gateway Pierre Bieber CERT-ONERA 2, avenue E. Belin 31055 Toulouse France
[email protected]
Abstract In this paper we describe the method used to develop a gateway capable of meeting the ITSEC E4 requirements. The security policy was formally modelled and proven consistent with the functional specifications by means of an interactive theorem prover. The formalisms were used to assist in the design of the security architecture. Keywords : ITSEC, formal methods, security policy
1. Introduction In this paper we describe the use of formal techniques during the development of a secure gateway called FOX. The aim of our work was to enable a security evaluation of the gateway at ITSEC [8] assurance-correctness level E4. At that level, the ITSEC requirements related to the use of formal methods are: “...A formal model of security policy shall be provided or referenced to define the underlying security policy to be enforced by the TOE [Target Of Evaluation]. An informal interpretation of this model in terms of the security target shall be provided...” “...The informal interpretation of the formal security policy model shall describe how the security target satisfies the underlying security policy...” In the first part of the paper, we describe the security policy of FOX. In the second, we present the formal security policy model. The consistency of the model is checked using tools associated with the B-method [1]. The third part describes the formal technique used during the FOX development that provides assistance when performing the interpretation of the security policy model. Finally, we explain the impact of the formal methods work on the design of the FOX gateway.
2. Security Policy of the FOX Gateway FOX [2] is a TCP/IP gateway (see [7], [6]) that interconnects two local area networks (called high LAN and low LAN).
FOX low LAN
high LAN
Figure 1. The FOX Secure Gateway. The aim of FOX is to protect the confidentiality and integrity of the data used by the hosts of the high LAN. Hence, FOX controls both incoming and outgoing messages. FOX contains a set of filters that can analyze and transform every message transmitted from one LAN to the other. Each filter is designed to take into account some kind of security threat. For example, a filter limiting access by foreign hosts to applications on the high LAN could be accomplished by checking the requested port number in the incoming messages. To counter masquerade attacks, a filter can be created that ensures that all incoming messages are signed with a previously established session key. Other filters can be designed that erase parts of the header of outgoing messages when the protocol software high hosts is not trusted. Malicious software might utilize normally empty header slots in order to transmit confidential data in a covert manner. FOX allows a security officer to select and dynamically change a combination of filters. As illustrated in figure 2, every incoming message is first handled by the communication function “comm low” that implements TCP, IP and Ethernet protocols. This function extracts from the received message the various headers and the data and transmits them to the filters that were selected by the security officer (e.g., filter 1 and 2). Once the message is filtered, it may be sent onto the High LAN by the communication function “comm high”. Outgoing
FOX
;; y X XX ;; ;; 9 high LAN
msg high
filtered data
comm high
filter 2
data to be filtered
filter 1
filter management
current filter
comm low
low LAN
msg low
Our goal is to define security levels that could be associated with the objects and subjects of FOX, and determine what kind of information flows between these levels should be authorized in order to enforce the security objectives. We first consider:
high the security level of information originating from
the high network. This information is regarded as highly confidential and of high integrity.
low the security level of information originating from
the low network. This information is regarded as of low confidentiality and of low integrity.
param Figure 2. Main functions of FOX.
messages are treated similarly, received by “comm high”, passed to the filters and transmitted onto the low LAN by “comm low”. Incoming and outgoing messages can be filtered uniquely, along with unique security policies, since each direction contains its own filters. The security policy of FOX contains two kinds of security objectives: external security objectives that deal with how information should flow from one LAN to the other and internal security objectives that deal with how information should flow within the FOX gateway. External security objectives depend on the environment of FOX (i.e. high LAN and low LAN). In order to state these objectives it is important to have some knowledge about the two LANs. The kind of applications running on the high hosts should be known in order to restrict foreign hosts from accessing particular applications. The ITSEC, however, differentiates between a system that is “a specific IT installation with a particular purpose and known operational environment” and a product whose environment is not necessarily known. The intent of the designers was for FOX to be evaluated as a product. Such an evaluation stresses internal security objectives because they do not depend on the environment. In order to show that FOX correctly filtered the exchanged messages and given the aforementioned objectives, formal methods were only applied to the two following objectives: Information Isolation: Within FOX, information originating from the high LAN or the low LAN is isolated. This means that no function should have simultaneous access to information originating from the high LAN and the low LAN. Information Filtration: information that is transmitted by FOX onto the other network has been filtered by the current combination of filters.
the security level of security parameters of FOX as the current combination of filters. This information has a lower confidentiality and a higher integrity than the information originating from the high or the low network.
In order to enforce the information isolation objective, information flows between levels high and low should be forbidden. Information flows from one level to itself and information flows from param to high or low may be permitted. However, information flows from high or low to param should be forbidden, otherwise information could flow indirectly from high to low through param. Figure 3 summarizes the authorized information flows. As “authorized flows” is a reflexive relation we omit the arrows from one level to itself.
high
HY @;;@6 @;;@? HH low
param
Figure 3. Authorized flows for isolation. According to the information filtration objective, filtered information originating from the low LAN should be transmitted onto the high LAN. This means that information would flow from low to high. Hence, the two objectives are inconsistent because isolation does not authorize information to flow from low to high. In order to solve this problem, we refine the security levels. We consider that security levels are made of two components, an isolation level (low, high or param) and a filtration level (in, ok or out). For instance :
hlow ini is the level of information originating from low LAN to be filtered. hlow oki is the security level of filtered information originating from low LAN.
hhigh outi is the security level of filtered information to be transmitted on high LAN. Then, information isolation is enforced if the flow from hlow oki to hhigh outi is the only information flow authorized between levels with isolation level component equal to low and levels with isolation level component equal to high. In this case both objectives are consistent. Figure 4 summarizes the new authorized flows.
high low
in
Y H 6 HH param
out
@;-;@
ok
to hlow f 1fi i, or from hlow f 1tf i to hlow f 1fi i are authorized but the flow from hlow ini to hlow oki is not allowed.
high out
low f1 in -tf -fi
6 J] J param f2 -tf -fi -ok ; ;
Figure 5. Authorized flows for isolation and filtration.
Figure 4. New authorized flows for isolation. In order to enforce the filtration objective information flows from hlow ini to hlow outi should not be authorized, otherwise information that is not filtered might flow freely towards filtered information. We want this information to flow through each of the selected filters. For that purpose, we introduce for each filter f two filtration levels ffi and ftf .
hlow ffi i is the level of the subject implementing the filter f . No other entity may be associated with this level. hlow ftf i is the level of information originating from LAN low that should be filtered by f . In order to let a filter read information to be filtered and filter it, information should be allowed to flow from hlow ftf i to hlow ffi i for each filter f . If the first filter to be applied by FOX is f 1 and the second is f 2 then, in order to achieve information filtration, information flows from hlow ini to hlow f 1 fi i and from hlow f 1tf i to hlow f 1tf i should be authorized. If f 2 is the last filter to be applied then information flows from hlow f 2fi i to hlow oki should be authorized. Filter f 1 cannot be bypassed because the only authorized flow from hlow ini to hlow oki flows through level hlow f 1fi i and the only subject that has this level is the filter f 1. Once it is filtered by f 1, information has to be filtered by f 2 because information is only allowed to flow from hlow f 1fi i to hlow f 2tf i, and f 2 is the only entity that has level hlow f 2fi i. Hence information with level hlow oki was necessarily filtered by both f 1 and f 2 filters. As figure 5 illustrates, the multi-level policy that we built is non-transitive (see [9]), for example, flows from hlow ini
3. Security Policy Formal Model In order to formally define the security policy of FOX, we have selected the Bell-LaPadula security model and the B-method. We chose these two formal techniques because they are very mature. This greatly assisted us in convincing the development team that the use of formal techniques was feasible. The formal model of the FOX security policy is based on the access control rules of the Multics interpretation of the Bell and LaPadula model (see [4]). Similar rules were also used for Trusted XENIX [3]. The B-method was selected because it is used by many companies (mainly in the railway industry) in order to develop large dependable software. The various tools (i.e., interactive prover, syntactic checker, proof obligation generator,...) included in the toolsets associated with the B-method was another reason to select this formal method. The following subsections provide a brief presentation of the B-method followed by an explanation of how we used it to describe FOX’s security policy.
3.1. The B-method According to the B-method (see [1]) a system is modelled by an abstract machine. Such a machine contains a state and operations that change the state. The state is defined using basic states, constants and variables written in the “SETS”, “CONSTANTS” and “VARIABLES” blocks of the machine. Constants and variables values satisfy constraints stated in a formal language based on first-order logic and set-theory (see the annex). Constraints on basic set and constants are grouped in the “PROPERTIES” block. Constraints on variables are grouped in the “INVARIANT”
block. Operations are contained in the “INITIALISATION” and “OPERATIONS” blocks. In this paper, we consider operations opn of the form opn(vl) = b P j S where vl is a list of variables, P is a predicate and S is a generalized substitution. We use five kinds of generalized substitutions:
x := E , simple substitution, where x is a variable and E is a set-theoretic term. x y := E F , multiple substitution, where x and y are two different variables, E and F are two set-theoretic terms.
Q j T , pre-conditioned substitution, where Q is a predicate and T a generalized substitution . opn (vl ), the name of another operation, where vl is 0
0
0
a list of variables. The semantics of these substitutions is provided in section 3.3. Figure 6, summarizes the various blocks of an abstract machine.
MACHINE machine name SETS basic set names CONSTANTS constant names PROPERTIES logical formula VARIABLES variable names INVARIANT logical formula INITIALISATION simultaneous substitution of all variables OPERATIONS list of operations
Figure 6. Blocks of an abstract machine.
3.2. Description in B of the security model In order to formally describe FOX’s security policy, we built the abstract machine model such that its invariant contains Bell-LaPadula security properties and its operations are the access control rules of the Bell-LaPadula model. Machine model uses five basic sets (see figure 7): OBJECT is the set of object names; SUBJECT is the name of subject names; LEV ELi is the set of isolation levels; LEV EL f is the set of filtration levels; and RIGHT the set of access rights (obs denotes observation right and alt denotes alteration right). The definitions of sets OBJECT and SUBJECT are deferred to the moment when the name of the actual objects and subjects is known.
MACHINE model SETS OBJECT SUBJECT LEV ELi = flow high paramg LEV ELf = fin ok out f 1fi f 1tf f 2fi f 2tf g RIGHT = fobs altg CONSTANTS LEV EL, habilt, flow PROPERTIES 1 LEV EL = LEV ELi LEV ELf ^ 2 habilt 2 SUBJECT ! LEV EL ^ 3 flow 2 LEV EL $ LEV EL^ 4 flow = id (LEV EL ) 5 ((fparamg LEV ELf ) LEV EL) 6 f (low in) 7! (low f 1tf ), 7 (low f 1tf ) 7! (low f 1fi ), 8 (low f 1fi ) 7! (low f 2tf ), 9 (low f 2tf ) 7! (low f 2fi ), 10 (low f 2fi ) 7! (low ok), (low ok) 7! (high out) g
Figure 7. Constants of abstract machine model.
This machine also contains three constants. LEV EL is the set of security levels. It is the set of pairs whose first component is an isolation level and the second is filtration level (see line 1 of figure 7). The function habilt associates every subject with a habilitation level (line 2). The relation flow relates a level with levels to which information is authorized by the security policy to flow (line 3). In this paper we do not formalize the possibility to dynamically change the combination of filters. To take it into account we would have to consider flow as a variable. Relation flow contains every pair of identitical levels (line 4), every pair whose first element has isolation level component equals to param (line 5) and pairs that represent the fact the flow from hlow ini to hhigh oki should go through hlow f 1 fi i and hlow f 2fi i. In our transcription of the Bell and LaPadula model, the state of a system is defined by the seven variables described in figure 8. Properties guaranteed by these variables are described in the invariant. The six first lines of the invariant (see figure 9) state that obj active and obj zombie (resp. subj active and
obj active subj active obj zombie subj zombie clasf c level c access
names of active objects names of active subjects names of destroyed objects names of destroyed subjects current classification of objects current security level of subjects current set of access rights acquired by subjects on objects
Figure 8. Roles of abstract machine model variables. subj zombie) are two disjoint subsets of OBJECT (resp. SUBJECT ). Line 7 and 8 state that c level associates every active subject with a unique current level and clasf associates every active object with a unique classification level. Line 9 states that c access is a relation that associates some pairs of (subject object) with an access right. The remaining lines of the invariant describe the security constraints proposed by Bell and LaPadula, i.e. for all triples (ss oo dd) belonging to c access: If dd is equal to obs (i.e., ss has an observation right on oo) then information should be allowed to flow from the classification level of oo towards the habilitation level of ss (“simple security property”). If dd is equal to obs then information should be allowed to flow from the classification level of oo towards the current level of ss (“*-property”). If dd is equal to alt (i.e., ss has an alteration right on oo) then information should be allowed to flow from the current level of ss towards the classification level of oo (“*-property”). In order to transcribe the “simple security property” into the B language we use the relation habilt flow;1 clasf ;1 . That is, the set of pairs (ss oo) such that the flow from object oo classification level to subject ss habilitation level is authorized. Line 10 of the invariant is the transcription of the simple security property. It states that all pairs (ss oo) such that ss was granted access right obs on oo (this is the image of singleton fobsg by relation c access ;1 ), should belong to habilt flow ;1 clasf ;1 . Line 11 represents the first part of the “*-property”. It is the same formula as line 10 with habilt replaced with function c level. Relation c level flow;1 clasf ;1 is the set of pairs (ss oo) such that the flow from object oo classification level to subject ss current level is authorized. Line 12 represents the second part of the “*-property”. It is the same formula as line 11 with obs replaced with alt and flow ;1 replaced with flow Relation c level flow clasf ;1 is the set of pairs (ss oo)
VARIABLES obj active, obj zombie, subj active, subj zombie, clasf , c level,c access INVARIANT 1 obj active OBJECT ^ 2 obj zombie OBJECT ^ 3 obj active \ obj zombie = ^ 4 subj active SUBJECT ^ 5 subj zombie SUBJECT ^ 6 subj active \ subj zombie = ^ 7 c level 2 subj active ! LEV EL ^ 8 clasf 2 obj active ! LEV EL ^ 9 c access 2 (subj active obj active) $ RIGHT ^ 10 c access;1 fobsg] (habilt flow;1 clasf ;1 )^ 11 c access;1 fobsg] (c level flow;1 clasf ;1 )^ 12 c access;1 faltg] (c level flow clasf ;1 )
Figure 9. Variables of abstract machine model.
such that the flow from subject ss current level to object oo classification level is authorized. The machine model contains operations corresponding to Bell-LaPadula rules on object or subject creation and destruction, current level change and access right granting. Figure 10 only shows operations initialisation, get access ok and create object ok. A more comprehensive description of machine model operations may be found in [5]. The initialisation operation sets every variable to the empty set. Operation get access ok(ss OO obs OO alt) represents a successful request from subject ss asking for an observation access right on every object of OO obs, and alteration access right on every object of OO alt. The condition granting access right is similar to the condition of get read and get write access control rules of the Bell-LaPadula model: ss is an active subject, OO obs and OO alt are sets of active objects, the flow from the classification level of objects contained in OO obs to the habilitation level of ss is authorized, the flow from the classification level of objects contained in OO obs to the current level of ss is authorized, the flow from the current level of ss to the classification level of objects contained in OO alt is authorized. If this condition holds then access right obs on every object of OO obs is granted to ss and access right alt on every object
INITIALISATION
obj active obj zombie subj active subj zombie, clasf c level c access :=
OPERATIONS b 1 get access ok( ss , OO obs , OO alt ) = 2 ss 2 subj active ^ 3 OO obs obj active ^ 4 OO alt obj active^ 5 fssg OO obs (habilt flow;1 clasf ;1 )^ 6 fssg OO obs (c level flow;1 clasf ;1 )^ 7 fssg OO alt (c level flow clasf ;1 ) j 8 c access := c access (fssg (OO alt faltg)) 9 (fssg (OO obs fobsg))
that the invariant holds initially and that each operation preserves the invariant (this means that whenever in a state the invariant holds and an operation can be executed then the invariant should hold in states reached after the operation is executed). The proof obligation generator tool associated with the B-method generates formulae corresponding to these two demonstration steps. The formula use the fact that an operation is a generalization of first order logic substitution. This means that formula opn]P , where P is a predicate and opn is an operation name, is equal to predicate P with all variables updated in accordance with operation opn definition. Variables are updated using the following rules: if opn = b Q j S , then opn]P == Q j S ]P .
xx := E kyy := F ]P == xx
;
10 create object ok( ss , OO , nn ) = b 11 ss 2 subj active ^ 12 OO OBJECT ; obj active ^ 13 OO OBJECT ; obj zombie ^ 14 nn 2 LEV EL ^ 15 ss 7! nn 2 (c level flow) j 16 obj active, clasf := obj active OO, 17 clasf (OO f nn g )
Figure 10. Operations of abstract machine model.
OO alt is granted to for ss. Another operation called get access no(ss OO obs OO alt) models a failed reof
quest (i.e. a request when the previous condition does not hold). Operation create object ok(ss OO nn) represents a successful request from subject ss in order to create the set of objects OO with classification level nn. The condition is that ss is an active subject, OO is a set of objects that are neither active nor destroyed, nn is a level, information is authorized to flow from the current level of ss to nn. If this condition holds then objects of OO are created and their classification level becomes equal to nn.
3.3. Verification of the Security Model Internal Consistency The goal of internal consistency verification is to prove that the invariant of the abstract machine is satisfied in every reachable state. For that purpose, it is sufficient to prove
yy := E F ]P
Q j S ]P == Q ^ S ]P . x y := E F ]P == a := E ]b := F ]x := a]y := b]P where a and b are diffrent variables and are different from variables x and y and they are not free in P. v := E ]P denotes the formula obtained when all free occurrences of variable v in P are replaced by E . The proof obligations are of the form: 1. Initialisation]Ij , for each conjunct Ij of the invariant. 2.
P reopn ^ Invariant ) opn]Ij , for each conjunct Ij of the invariant and each operation opn, where Preopn is opn precondition.
For instance, the invariant of machine model contains the conjunct obj active \ obj zombie = . The initialization proof obligation is \ = that trivially holds. The proof obligation for operation create object ok(OO nn) is : OO OBJECT ; obj active ^ OO OBJECT ; obj zombie ^ obj active \ obj zombie = ) create ok(OO nn)](obj active \ obj zombie = ) That is equivalent to : OO OBJECT ; obj active ^ OO OBJECT ; obj zombie ^ obj active \ obj zombie = ) (obj active OO) \ obj zombie =
We used the tools associated with the B-method in order to verify the internal consistency of machine model. About one hundred proof obligations were generated. The automatic theorem prover was used in order to discharge the proof obligations. This tool was able to check around fifty
proof obligations. Then inference rules were added in order to help the interactive theorem prover check the fifty remaining formulae.
4. Interpretation of the Formal of Security Model The goal of the interpretation is to show that security is correctly taken into account in the specifications of FOX. Hence the specification of the functions of FOX should be related to rules of the security model we presented in the last section. Bell-LaPadula model interpretations described [4, 3] use a description of the systems more detailed than the specification of FOX functions that was available to us. In the case of an operating system interpretation, objects are usually files or sockets and subjects are processes or users. Notions of files, sockets or processes did not appear in the specification documents of FOX. These notions were used during later phases of FOX development. The specification documents of FOX contain functional requirements that FOX functions should satisfy. Functional requirements are described in a semi-formal style using data flow diagrams (similar to figure 2 or figure 11) and structured text.
6 6
filtered data
filter 1
data to be filtered
current filter
6
data to be filtered comm low
6
incoming message
Figure 11. F1 and comm low functional requirement.
the functional requirement that has the form: “ Subject function name requires to have access rights dd on objects data flow name1 , ..., data flow namen , where dd is obs, alt, creation object or destruction object”. For instance function “filter 1” should filter incoming messages when it is selected. Hence, the security requirement associated with “filter incoming messages” is subject “filter 1” (noted f 1) should be authorized to observe objects “incoming data to be filtered” (noted d tf ) and “current filter” (noted c filter) and to modify object “incoming data filtered” (noted d ok). Similarly, function “comm low” should receive messages from the low LAN and transmit them to “f1” function. Hence, the security requirement associated with “receive messages from low LAN” is subject comm low should be authorized to observe objects “incoming message from low” (noted msg low) and to modify object “incoming data to be filtered” (noted d tf ).“ MACHINE requirements INCLUDES model PROPERTIES 1 OBJECT = f d tf , d ok,c filter, ... g ^ 2 SUBJECT = f f 1, ... g OPERATIONS b 3 reqt filter = 4 f 1 2 subj active ^ 5 fd tf , d ok, c filter g obj active j 6 get access ok(f 1 fd tf c filterg fd okg)
;
7 reqt comm = b 8 comm low 2 subj active ^ 9 fd tf , msg low g obj active j 10 get access ok(f 1 fmsg lowg fd
tf g)
4.1. From functional requirements to security requirements
Figure 12. Abstract machine requirements.
We relate each functional requirement with access control rules of the model in order to show that the functional specification of FOX is consistent with its security model. For each functional requirement, we search for the name of the function that is supposed to satisfy this requirement. We regard this function as subject function name of the security model. We also look for the names of data flow involved in the requirement. We regard these data flows as objects data flow name1 , ..., data flow namen of the security model. And we determine whether in this requirement data flows are observed, altered, created or destroyed. Then, we associate a security requirement with
A new abstract machine entitled requirements was created (see figure 12). It contains the formal description of FOX security requirements. This machine includes the actual definition of sets SUBJECT and OBJECT . SUBJECT contains FOX function names (line 1) and OBJECT contains the name of the various data flows (line 2). Each operation of machine requirements represents a security requirement. Operation reqt filter (line 3) represents the security requirement associated with “filter incoming messages”. The precondition states that f 1 is the name of an active subject (line 4) and d tf , d ok and c filter are names of ac-
tive objects (line 5). On line 6, operation get access ok from machine model is used in order to state that the request by f 1 to be granted access right obs on objects d tf and c filter and access right alt on object d ok should be successful. Operation reqt comm (line 7) represents the security requirement associated with “receive messages from low LAN”. The precondition states that comm low is the name of an active subject (line 8) and d tf and msg low are names of active objects (line 9). On line 10, operation get access ok is used in order to state that the request by comm low to be granted access right obs on object msg low and access right alt on object d tf should be successful.
4.2. Formal analysis of security requirement In order to analyze the consistency of the security requirements we try to formally verify machine requirements using the technique described in section 3.3. Although machine requirements does not contain an invariant block, proof obligations are generated because in the special case of an operation opn1 using another operation opn2 ( opn1 = b Pre1 j opn2 and opn2 = b P re2 j sub) it should be checked that opn2 precondition is a logical consequence of the invariant and opn1 precondition. This proof obligation is a special case of the formulae described in section 3.3. Every operation of machine requirements is of the form Pre(reqt) j opr model where opr modele is an operation from machine model. So, we have to verify that if the invariant of machine model and P re(reqt) hold then the precondition of opr model should hold. The precondition of operation get access ok(ss OO obs OO alt) is : ss 2 subj active ^ OO obs obj active ^ OO alt obj active^ fssg OO obs (habilt flow;1 clasf ;1 )^ fssg OO obs (c level flow;1 clasf ;1 )^ fssg OO alt (c level flow clasf ;1 ) Hence the proof obligation associated with “filter incoming data” security requirement is: P re(reqt filter) ) ff 1gss 2 subj active ^ fd tf c filterg obj active ^ fd okg obj active ^ ff 1g fd tf c filterg (habilt flow;1 clasf ;1 ) ^ ff 1g fd tf c filterg (c level flow;1 clasf ;1 ) ^ ff 1g fd okg (c level flow clasf ;1 ) So we have to prove that the pairs c level(f 1) 7! clasf (d ok), clasf (d tf ) 7! c level(f 1) and clasf (c filter) 7! c level(f 1) belong to flow. Once these formulae are obtained, it is not, in gen-
eral, possible to prove them due to the lack of information about subject current level and object classification in machine requirements. Hence the formal analysis consists of looking for hypotheses that could help satisfy the formulae rather than directly prove formulae. First suppose that we are able to associate a current level with some subjects. For instance we can associate level hlow f 1fi i with subject f 1, level hlow ini with subject comm low. Then we try to simplify each proof obligation, this helps us associate levels with objects. For instance, we can associate level hlow ini with msg low, hlow f 1tf i with d tf , hlow f 2tf i with d ok and hparam oki with
c filter
Once every object and subject is associated with a level, we add this information into the invariant of machine requirements, generating the proof obligations at a later time. This stage helps to detect inconsistencies between security requirements. Some proof obligations may be discharged automatically, and some others cannot be proved because they are not correct. In this latter case, new constraints may be added in the precondition of the security requirement. This means that the functional requirement is secure only when this constraint holds. The interpretation of the security model added new information about the classification, current level and special security constraints in the specification documents of FOX.
5. Conclusion: Impact of the formal techniques on FOX design We end this paper with several remarks on the impact on FOX developement of the work we performed with formal methods. The first tasks we performed as defining a multi-level policy, building an abstract machine and verifying it did not require a lot of effort. The interpretation of the security model was more time-consuming than we expected. This is mainly due to the fact that this task has required us to analyze in detail a collection of large informal specification documents. But thanks to this detailed analysis, the results of the interpretation could be used for the design of the security architecture of FOX. By grouping together all the functions and data flow with the same isolation level we proposed to the designers a security architecture. In this architecture (see figure 13) every subject and object of a component has the same isolation level hence the component is secure with respect to the information isolation objective. Furthermore, every link between components relates a level with another to which information is authorized to flow. An ideal implementation of this architecture would be to have one computer per isolation level running the corresponding functions and a communication wire for each link in the security architecture.
high component
comm high
param component
I@ @ mngt
@@ low component @ comm low -filter1 -filter2
6. Acknowledgements This work was funded by DGA/STSIE. I want to thank for their cooperation the FOX teams from CELAR, DGA/STSIE and THOMSON. I would also like to thank Eugen Bacic for helping me to improve this paper.
Figure 13. Ideal security architecture. Of course, this security architecture was not implemented in this way because it would have conflicted with other properties that FOX should guarantee (price, performance, ease of developement, ergonomy,...). Hence the implemented architecture of FOX (see figure 14) has three components.
Security Officer Workstation
filter mngt
Low computer
-
incoming filters
6
comm low
6 ?
6 ?
High computer
- comm high outgoing?filters
tion”, low computer data to be journalized on the security officer workstation was flowing almost freely through the high computer. This was contrary to the information isolation objective. To correct that we proposed the addition of a direct link between the low computer and the workstation. This correction was accepted by the designers not only because security was enhanced but also because the resulting architure is symmetrical and this simplified development of the software.
Figure 14. Architecture of FOX. The “security officer workstation” includes every function that needs interaction with the security officer as filter management but also journalization and auditing. The two other components are devoted to communication and filter functions. We compared the security architecture we proposed and the functional architecture proposed by FOX designers in order to help them choose the relevant security functions. For example, it was proposed to use a multi-level operating system on the security officer workstation because it includes data and functions of various level. A reference monitor that would enforce the constraints related to filtration levels was also studied. We helped to correct some aspects of the architecture. Initially there was no direct link between the low computer and the “security officer worksta-
References [1] J. Abrial. The B-book: assigning programs to meaning. Cambridge University Press, 1996. [2] I. Armand and M. Riguidel. FOX, Passerelle Filtrante de S´ecurit´e: Un produit de confiance ITSEC E4. In Conf´erence Canadienne sur la S´ecurit´e des Syst`emes Informatiques, 1995. [3] D. Bell. Trusted Xenix Interpretation: Phase 1. In National Computer Security Conference, 1990. [4] D. Bell and L. LaPadula. Secure Computer Systems: Unified Exposition and Multics Interpretation. Technical Report ESD-TR-75-306, MTR-2997, MITRE, Bedford, Mass, 1975. [5] P. Bieber. Interpr´etation d’un mod´ele de s´ecurit´e. Technique et Science Informatique, 15(4):483–508, 1996. [6] D. Chapman and E. D. Zwicky. Building Internet Firewalls. O’Reilly, 1995. [7] D. Comer. Internetworking with TCP/IP. Prentice-Hall, 1988. [8] E. E. Community. Information Technology Security Evaluation Criteria (ITSEC). Technical report, 1990. [9] J. Rushby. Noninterference, Transistivity, and ChannelControl Security Policies. Technical Report CSL-92-02, SRI International, 1992.
7. Annex : Formula definitions In the following P , Q denote predicates, E and F are expressions, S , T and U are sets, r and t are relations, f is a function. Predicates P ^ Q : conjunction of P and Q. E 2 S : E belongs to S . S T : S is a subset of T . Expressions E 7! F : pair (E,F). Set-theoretic expressions S T : cartesian product of S and T , set of pairs E 7! F
such that E 2 S and F 2 T . S T : union of S and T , set of elements from S or from T. S \ T : intersection of S and T , set of elements from S and from T .
: empty set. Relational expressions S $ T : set of relations from S to T , equal to the powerset of S T . id(S ) : identity of S , set of pairs E 7! E where E 2 S . r t : composition of relations r and t, if r 2 S $ T and t 2 T $ U , set of pairs E 7! F such there exists G such that E 7! G 2 r and G 7! F 2 s. r;1 : Inverse of r, relation obtained by changing the order of pairs belonging to r. rS ] : Image of S by r, set of elements from the codomain that are related to at least one element of S by r. Functional expressions S ! T : Set of total functions from S to T , set of relations from S to T that relates every elements of S with at most one element of T . f (E ) : Value of function f in E , if E 2 dom(f ), element of ran(f ) such that E 7! f (E ) 2 f . Relations and functions are sets of pairs hence settheoretic operators such as , \ may be applied to them. Similarly, functions are relations, hence relational operators such as dom(), ran() may be applied to them.
