A Declarative Approach for Easy Specification and

60

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

A Declarative Approach for Easy Specification and Automated Enforcement of Security Policy Hédi Hamdi† , Adel Bouhoula†† and Mohamed Mosbah† University of Bordeaux 1, France† , Sup’COM , 2083, Ariana Tunisia †† involves low-level configuration to face. This paper introduces a new programming language [1] [2], named Summary A security policy presents a critical component of the overall PPL(Policy Programming Language), for specifying and security architecture and an essential basis on which an effective enforcing a security policy on a given computer network. and comprehensive security program can be developed. This language enables high level and declarative Although, this necessity and this criticality, little progress has specification and enforcement of security policies without been made to improve tools of specification and compromising efficiency. Several verifications are enforcement of security policy. Too often, existent performed on PPL specifications to enhance their approaches have been restrictive in many ways. This paper robustness. presents a declarative approach based on domain specific Lately, many attempts of proposing new approaches or languages to overcome these problems. We define a adapting existing ones to deal with security problem have language, named PPL (Policy Programming Language), been proposed. Particularly, the idea of a language dedicated to systematically specify and to automatically dedicated to security policy has already been discussed in enforce security. Unlike a general-purpose language, PPL the literature. Nevertheless, existing approaches are offers high-level and declarative constructs, it allows a limited to introducing a language for only security policy specification to be checked for consistency, it reduces specification level. The mapping of specification to human error, it simplifies policy analysis, it reduces policy implementation usually involved ad-hoc specific solutions conflicts. developed each time from scratch and hardly reusable. This paper makes the following contributions: Key words: • We have identified common aspects and key Input here the part of 4-5 keywords. concepts used in the security policies, based on a close examination of various examples of security policies specification as well as some 1. Introduction policies implementation. • We present the definition of PPL, a high-level So far, research into Security Policy specification and and declarative language dedicated to the refinement tools has focused on low-level implementation specification of security policies. The language is details. One of the main factors contributing to their lack strongly typed and enables various consistency of adoption is that comparatively little work has been done checks. The resulting degree of robustness of a on developing high-level domain specific Security Policy PPL program goes beyond what can be achieved specification languages [2]. Recently, the development of with an equivalent program written in a generaltools for security policy specification is becoming an purpose language. increasingly important software activity to account for • We show that PPL is highly expressive. It has frequently changing requirements. More and more new been used to describe a wide range of security mechanisms compete to oppose new risks, creating an policy specification. explosion in security policy implementation tools. The equipment failures are not only considered like • We have implemented a compiler for PPL hardware breakdowns but also software breakdowns has programs. The generated enforcement shifted an increasing part of security implementation from mechanisms are as efficient as equivalent manual hardware to software. Fortunately, the specification and configuration. We think that with the PPL implementation of a security policy relies on well compiler, the gap between specification and understood libraries of atomic and composite actions for implementation of policies has to be resolved, traffic filtering, permission, obligation and interdiction. consistently with the capabilities and features of Yet, due to the lack of programming language support, the each target policy enforcement environment. specification and implementation of security policy tends to be labour-intensive, encumbering and error-prone: it Manuscript received February 5, 2008 Manuscript revised February 20, 2008

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008 Section 2 presents the difficulties involved in specifying security policies. Section 3 presents reasons for using Domain specific language. Section 4 introduces the PPL language, focusing on the main language abstractions. Section 5 gives an overview of the automatically enforcing security policy process, and Section 6 lists the main verifications performed on a PPL program. Section 7 presents the related work, and Section 8 concludes the paper and discusses future work.

2. Difficulties in Specifying Security Policies In this section, we discuss the issues involved in specifying and implementing a security policy and illustrate them with a working example, IPSec and Virtual Private Network (VPN) Policy. We first briefly introduce this example. The Internet Protocol Security architecture (or IPSec) is developed by the Internet Engineering Task Force (IETF). It is a suite of protocols designed to enable secure IP connections over the Internet. It provides integrity, confidentiality and authentication of data communications over IP networks. The goal of the IPSec designers was to define protocols that can provide a solution to the lack of security features in IPv4. They define the "IP Authentication Header (AH)" protocol and[11] and the "IP Encapsulating Security Payload (ESP)" protocol[12].These protocols specify two header types that can be used separately or together, depending on what security services are required, and they are used to provide security services in IPv4 and IPv6. To ensure the traffic security requirements, security protocol (AH or ESP) and mode (tunnel or transport) should be specified. In order to verify integrity and authenticity, on any IPSec device, the outgoing IP packets are typically encrypted and encapsulated, while they are decapsulated and decrypted on the receiving devices. To define IPSec protection operations for each specific traffic, an IPSec security policy is written at each device interface.

2.1 The Specification and enforcement of policies is complex The specification and refinement of a security policy is subject to numerous, sometimes contradictory constraints such as security requirements and backward compatibility. As a result, the specification of security policy is often embarrassing: rules conflicts, specification anomalies, etc.

61

2.2 The inaccuracy of the documentation of security policies Security policies are based on the documentation made available to the administrators by the organizations. This documentation is not easy to read since low-level and high-level concepts are generally intertwined: organizations, communications, location, semantics. The terminology used also changes from one policy to another. Moreover, any documentation still is informal because it is written in a subset of natural language. Consequently, a policy specification is often ambiguous, incomplete, or even inconsistent. In fact, there is no systematic way for the organization to validate a security policy specification.

2.3 Mapping security policy documentation into enforcement mechanisms is not straightforward Extracting the security policy from the documentation and expressing it in a program that can generate enforcement mechanisms for policy, requires a significant work, that is also tedious and error-prone. On the one hand, the policy specification is expressed in terms of policy, rules, actions, etc. On the other hand, manipulating a enforcement mechanisms of a policy requires the use of low-level operations.

2.4 The Difficulty of Mapping a security policy Specification into a Program A Security policy is often specified informally as plan, outlining what the network’s critical assets are, and how they must (and can) be protected. It consists of a set of collection of content-free statements, named rules that provide network’s users an overview of the "acceptable use" of any of the information assets, as well as to determine what is deemed as allowable and what is not. Although this notation is convenient at the highest level of abstraction, it can be difficult to map such a specification into an implementation of the bottom level, which is composed of mechanisms such as computing hardware, the cryptographic primitives, tamper resistant enclosures and seals as well as procedural items such as biometric scanning of individuals for purposes of authentication. While a specification typically describes some rules as being enforced in cascade, an implementation needs to invoke the corresponding actions sequentially. This mapping needs to take into account the implementation details of the rules involved, such as the possibility of rules conflicts. Example: IPSec security policy rules define the requirements of the protection offered by IPSec to certain traffic. It’s written at each device interface and the

62

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

interaction between different IPSec policies, such as cascaded protection, can lead to inefficient or incorrect data protection. Also, another problem might be posed by the existence of various action types (e.g., bypass, discard, encrypt/tunnel, authenticate/transport, etc.) when specifying and analyzing IPSec policies. IPSec misconfiguration within a single policy or due to the inconsistency between policies in different devices can cause rule conflicts. These conflicts may result in incorrect operation of IPSec and can lead to serious security threats including transmitting traffic insecurely, dropping legitimate traffic, and allowing undesired traffic into secure networks. it is neither systematic nor uniform: many literal constants are hardwired in the code and definitions are often scattered into different source files without apparent reason.

2.5 The Need of human intervention in a security policy deployment The security policy is a set of high-level rules that state precisely what goals the protection mechanisms are to achieve. It specifies at high-level the security properties that a given network should possess. It is driven by the understanding of threats, and in turn drives the network design and deployment. When the security policy is all drawn up, revised, updated and agreed upon, the implementation process will follow. This is usually harder than the creation of the policy itself, due to the fact that at this stage there is a need to coach and educate the users to behave in a "secure" manner, following each of the core elements pointed in the security policy. Proper implementation requires not only educating staff on each of the core elements flagged as critical in the Security Policy, but also a human intervention from designers, domain experts and implementers. Example: IPSec policy rules can be deployed at many hosts and gateways. This fact provides flexibility for customizing the appropriate protection mechanisms for different applications and network requirements. However, the lack of automated verification of IPSec security policies significantly increases the potential of policy inconsistency and conflicts. Therefore, successful deployment of IPSec security is highly dependent on the availability of IPSec policy analysis techniques with human intervention.

2.8 Principal observations The complexity of security policies, the inaccuracy of the documentation, the complex mapping from a security policy specification to enforcement mechanisms and the unsuitability of language support all have a significant impact on the software engineering of security policy specification and refinement. As a matter of fact,

specifying and enforcing security policy is not an efficient process and often leads to miss-configuration, which impedes maintenance and evolution. Yet, security policy specification and refinement is a repetitive process and is built on patterns of code that are specific to the domain: actions translation, packets manipulations, etc. This observation calls for re-use, to improve both productivity and safety. However, as mentioned above, generalpurpose languages offer little support. First, it’s so difficult to usefully abstract code patterns. Second, typing rules, that are about the only validation mechanism offered by GPLs (General Purpose Language), are too loose to detect bugs and conflicts early in the development process. Domain specific languages[13], [14], [15], [16], [17] offer a solution to all these problems. Because they offer suitable built-in abstractions, they capture domain expertise and systematize reuse, regardless of the programmer’s practice. Moreover, they provide additional safety guarantees as they allow domain specific properties to be automatically checked. Next, we further present a domain specific language for specifying and enforcing security policy.

3. Reasons for using Domain specific language (DSL) A domain-specific language (DSL) [2] is a programming or specification language tailored specifically for a particular domain or problem: rather than being general purpose, it is often small, more declarative than imperative, and less expressive than a general-purpose language; it captures precisely the domain’s semantics and provides appropriate abstractions and notations. Domainspecific languages allow the concise description of an application’s logic reducing the semantic distance between the problem and the program. A DSL provides appropriate built-in abstractions and notations. DSLs have been used in various domains. This profusion shows the recent attention that DSLs have received from both the research and industrial communities. The following two distinct advantages explain why DSLs are more attractive design choice than GPLs for specifying and implementing security policy.

3.1 Concrete Specification of Security policies Security policy is not specified into the system or stored in an arcane file format; it is captured in a concrete human readable form. Security policy expressed in the DSL can be scrutinized, split, combined, shared, published, put under release control, printed, commented, and even be automatically generated by other applications.

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

3.2 Direct Involvement of the Security Expert The DSL expression style can often be designed so as to match the format typically used by the security expert. This results in keeping the experts in a very tight software lifecycle loop where they can directly specify, implement, verify, and validate, without the need of coding intermediaries. Even if the DSL is not high-level enough to be used as a specification language by the security expert, it may still be possible to involve the expert in code walkthroughs far more productive than those over code expressed in a general purpose language.

4. Design of PPL Language The design of PPL has been guided by a thorough study of the domain of computer security in general, and specially security based policies. This section gives a summary of our domain analysis of the security policy specification. For each identified concept, we present the corresponding PPL language construct.

4.1 Domain analysis To perform our domain analysis, we exploited a variety of information sources. We thoroughly examined a wide spectrum of various kinds of security policy specification tools. These tools mainly include specifications of known security policies, specification for typical security policy (e.g., IPSec policy [18]) as well as more dedicated ones (e.g., web services security Policy [19], Security Policy for web semantic [20] and Security Policy for Clinical Information Systems[21]) , frameworks and tools for security policy specification (e.g. Ponder[3], PDL[8]). Based on this domain analysis, we have identified the following key requirements for a language dedicated to this domain. The language should be composed of five basic blocks: entities, scopes, rules, actions and policies to describe the appropriate operation performed for ensuring security of a given system; it should include block-specific declarations to enable dedicated verifications and analysis to be performed; it should be modular to enable a security policy specification to be decomposed into manageable components and also policies can also be composed into more complex policies until it forms a global and single policy; it should include an interface language to enable disciplined re-use of existing security actions libraries.

4.2 An Overview of PPL A PPL program essentially defines a list of blocks. blocks

63

declarations describe which subjects (e.g. users or processes) may access which objects (e.g. files or peripheral devices) and under which circumstances. A block can either be a policy, a rule, an action or a entity, a scope. Scope represent a list of entities involved in policy. Policies correspond to a sequence rules to determine specific configuration settings for some protection of system; they can be either simple or compound. A simple policy refers to a list of protection action implemented in some other programming language. This facility enables existing actions libraries to be re-used. A compound policy is defined as a composition of simple policies. Rule consists of a set of constraints on a set of actions; they can be either a single-trigger where only one action is triggered for a given object or a multi-trigger where multiple different actions may be triggered for the same object. Action can be atomic or compound In the following we present in details each of the basic blocks comprising PPL and show how they are used in writing PPL security policies.

4.3 Entities PPL entities are typed objects with an explicit interface by which their properties can be queried. Entities can be an object or a subject or a collection of them. They have identification and can be a source and destination of rules.

4.4 Scopes Entities can be collected into Scopes. Scopes are essential in any policy considering that they provide the necessary abstraction to achieve compactness, generalization and scalability. Without Scopes, each rule has to be repeated for each entity to which the rule applies.Scopes have a name and they are used in rules for simplified management of large numbers of entities. PPL offers two types of scopes: classes and domains. Classes are sets of entities that are classified according to their properties, e.g. all TCP packets, and domains are sets defined by explicit insertion and removal of their elements. Figure 1 provides the simplified syntax of a scope in Backus-Naur form. scope ::= scope: ident {entites } entities ::= entity; | entity;entities entity ::= entity; | entity;entities entity ::= name:ident,IP=IPadr Fig. 1. BNF syntax for scope

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

64

4.5. Policies A PPL policy is a group of rules and scopes that govern a particular domain events. These rules are used to define the right behaviour of a system. PPL supports an extensible range of policy types: • Authorisation policies are essentially security policies related to access-control and they specify whether a sequence of actions, a subject, is permitted or forbidden to perform to a set of target objects. They are designed to protect target objects, so they are interpreted by access control system. • Obligation policies specify what a sequence of actions, a subject must perform to a set of target objects, on response to particular events and define the duties of subjects in scope of policy. Obligation policies are normally triggered by events. • Delegation policies specify which actions and rights subjects can delegate to others. A delegation policy thus specifies an authorization to delegate. • Compound policies are used to group a set of related policy specifications within a syntactic scope with shared declarations in order to simplify the policy specification task for large distributed systems. Figure 2 describes the BNF syntax of a policy. • policy ::= type-pol policy ident ((params))? { policy-def } type-pol ::= auto | deleg | oblig | noblig | nauto | compound policy-def ::= scope-def body-def scope-def ::= scope:{ entities } | scope: { dom; } entities ::= entity; | entity;entities entity ::= ident dom ::= ident body-def ::= body: rules rules ::= rule; | rule;rules Fig. 2. BNF syntax for policy

4.6 Rules A rule, consists of a set actions that subjects can perform on target objects when a set of constraints are satisfied. In

single-trigger rule, only one action is triggered when condition is satisfied. In a multi-trigger multiple different actions may be triggered for the same object when condition is satisfied. For example IPSec crypto-access rule is a single-trigger. In fact, once a traffic matches a certain condition, its action is triggered and no further matching is performed. This is in contrast to crypto-map rules where a particular traffic may match multiple constraints causing multiple actions to be triggered. Figure 3 describes the BNF syntax of a rule. rule ::= rule ident ((params))? { rule-def } rule-def ::= {subjects-def subjects-def constraints-def} subjects-def ::= subject:entities objects-def ::= object:entities constraints-def ::= constraint | constraintconstraints-def constraint ::= if (expr ) then actions actions ::= action; | action; actions Fig. 3. BNF syntax for rule

4.7 Actions Actions represent the operations triggered when a constraint match. Actions can be either atomic for example in IPSec filtering policy, actions are protect, bypass, discard, or composite such as a service implementation. Figure 4 describes the BNF syntax of an action. action ::= action ident ((params))? { exprs } exprs ::= expr; | expr;exprs Fig. 4. BNF syntax for action

5. Automatically Enforcing Security Policy A PPL specification rigorously describes permissions, interdictions and obligations without changing feather or requiring the consent or cooperation of the entities being governed. It does not assume any particular environment, and can therefore be used for many target platform. As a matter of fact, using the language only requires some security expertise. Compiling a PPL description provides a set of policy enforcement mechanisms for monitoring both applicationlevel and environment-level conditions, for activate and carry out policy enforcement as required. The PPL

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008 compilation process consists of the following steps. First, dependencies between blocks are collected and represented as a list. Second, this list is annotated with actions information. Third, the resulting list is used to extract adequate rules. Lastly, enforcement mechanisms are generated. Figure 5 shows the general PPL development process.

Enforcement engine

Policy specification

Enforcemrnt engine

Target specification

verification

Policy definition

Policy verification and translation

Compilation

low−level actions/enforcement mechanisms

Target1

Target2

Targetn

Policy translation

Fig. 5. The PPL development process

6. Verifications 1. Conflicts and Anomalies detection Because of its domain-specific nature, the PPL compiler can perform a number of verifications that are beyond the reach of a compiler for a general-purpose language. These verifications focus on the detection of the conflicts that can arise between rules due to a specification containing rules that have opposite modalities, with the same subjects and targets, but they both permit and forbid the same actions. In [7], authors present classification of policy conflicts, which discussed both modality conflicts and application specific conflicts. They categorize modality conflicts as follow: • Authorization conflicts arise when both a positive and a negative authorization policy are defined for the same tuple (subjects, objects, actions). • Obligation conflicts arise when one policy obliges a subject to perform a given action and at the same time another policy forbids the action from being performed.

65

•

Unauthorized obligation conflicts arise when a subject is obliged to perform an action that it does not have the authorization to do. Application specific conflicts are those that arise because of constraints defined for the particular application in which the policies are being used. For example, a system that enforces the principle of separation of duties would define a conflict if the same person who passes an examination is also allowed to note it. The verification process enables also anomalies detection. We present hereafter an example of distributed firewalls which shows how they will be detected with PPL.

2. Example: Distributed Firewalls In the following section, we will consider an example a very common network architecture with a given security policy. The network architecture includes three segments, each with its Firewalls. Then, we specify the security policy on PPL in order to generate filtering tables and to detect anomalies within the distributed Firewalls of the network architecture. For example, a university’s network has three network segments. The first segment, called LAN1, is the network of the external servers. These servers offer services for external users. The second and third segments, called LAN2 and LAN3 respectively, are the networks for the internal servers and hosts. For example, the segment LAN2 is the network of the professor. However, the segment LAN3 is the network of the students. The segment LAN1 includes four servers, namely the DNS, email, Web and FTP servers, a number of hosts. The segment LAN2 includes one FTP server and a number of hosts. Security policy: This section proposes an example of a security policy for the above network architecture, namely: 1) The DNS server is allowed to access only the external DNS server of an FSI. 2) The email SMTP server is allowed to access only the external email server of an FSI 3) The Web and FTP servers can be accessed by any external user 4) The users in the LAN2 are allowed to access the Web server in the LAN3 5) The users in the LAN3 are not allowed to access the FTP server in the LAN2 6) The users in the LAN3 are not allowed to Ping the hosts in the LAN2 7) The users in the LAN2 are allowed to Ping on the hosts in the LAN1 and LAN3. 8) External hosts are not allowed to Ping any host in the three segments LAN1, LAN2 and LAN3. 9) All hosts from internal and external networks are not allowed to Ping the LAN2’s hosts, except the LAN1’s

66

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

hosts. 10) All ICMP control traffic coming from external hosts should be denied. 11) All LAN3’s hosts are not allowed to send ICMP error traffic. 12) All LAN1, LAN2 and LAN3’s hosts are allowed to send ICMP error traffic of type 3. 13) All hosts in LAN3 are allowed to send ICMP control traffic of type 13 to external hosts. 14) All hosts in LAN1, LAN2 and LAN3 are not allowed to send ICMP control traffic to external hosts. The implementation of this policy in PPL generates the filtering tables for each Firewall (PPL specification of distributed firewall security policy and generated filtering tables are given in appendix) and with the list of the detected anomalies. We present thereafter that list. • The rule 8 should be removed of the set of the filtering rules of the LAN1’s Firewall. • The rule 9.1 is generalized by the rule 8, and consequently rules 9.1 can be removed. • The rule 9.1 is generalized by the rule 10, and consequently rules 9.1 can be removed. • The rule 11 is shadowed by the rule 12, and consequently the network administrator should be alerted to revise the security policy. • The rule 14 is shadowed by the rule 13, and consequently the network administrator should be alerted to revise the security policy.

8. Conclusions and Future Works Computer security is a rapidly evolving field which requires much software development with highcorrectness expectations. To address these requirements, we have developed a domain-specific, high-level and declarative language, named PPL, for specifying security policy. We have used PPL to write a variety of typical security policies as well as special-purpose ones. These specifications have experimentally validated the expressiveness of our language. We have implemented a compiler for PPL. Preliminary experiments show that compiled PPL programs have performance that is roughly comparable to manually compiled equivalent specification. Our implementation of the PPL compiler is easily extensible, and there is a number of verifications end analysis that need to be explored. In particular, we plan to optimize process of conflicts detection and corrections. We also want to study to optimize the refinement process

by determing, at specification level, the resources that are required to enforce the policy. These ideas are examples of highly domain-specific compiler optimizations that can be enabled by the presence of more explicit information at the language level, and can be factorized into a compiler. Another track of research aims to go beyond security policy specification and enforcement to tackle others aspects like security policy test and automatic proof of security properties. To do so, we are studying ways of automatic derivation of tests from a PPL specification of a security policy.

References [1] C. Consel and R. Marlet, “Architecturing software using a methodology for language development,” in Proceedings of the 10th International Symposium on Programming Language Implementation and Logic Programming,ser. Lecture Notes in Computer Science, C. Palamidessi, H. Glaser, and K. Meinke, Eds., no. 1490, Pisa, Italy, Sept. 1998, pp.170–194. [2] A. V. Deursen, P. Klint, and J. Visser, “Domain-specific languages: An annotated bibliography,” ACM SIGPLAN Notices, vol. 35, no. 6, pp. 26–36, June 2000. [3] P. R.V., “Specification and verification of security policies.” Ph.D. dissertation, The University of Virginia, School of Engineering and Applied Science, January 1996. [4] A. R. and H. T.A., “Computer-aided verification: An introduction to model building and model checking for concurrent systems,” in Draft, ser. sv. lncs, 1999, pp. 179–196. [5] M. Z. and P. A, “Temporal verification of reactive systems: Safety.” Springer-Verlang, New York, 1995. [6] C. L. and C. F., “Analyzing consistency of security policies,” in In Proceedings of the IEEE Symposium on Security and Privacy, 1997, pp. 103–112. [7] N. C. Damianou, “Policy framework for the management of distributed systems.” Ph.D. dissertation, Imperial College. London, U. K., February 2002. [8] S. Jajodia, P. Samarati, and V. S. Subrahmanian, “A logical language for expressing authorizations.” [9] Z. Fu, S. F. Wu, H. Huang, K. Loh, F. Gong, I. Baldine, and C. Xu, “IPSec/VPN security policy: Correctness, conflict detection, and resolution,” in POLICY, 2001, pp. 39–56. [10] J. A. Hoagland, R. Pandey, and K. N. Levitt, “A graph-based language for specifying security policies.” [Online]. Available: citeseer.ist.psu.edu/144987.html [11] H. J., “Specifying and implementing security policy using lasco, the language for security constraints on objects,” Ph.D. dissertation, The University of California Davis, Department of Computer Science, March 2000. [12] Lobo and all., “A policy description language,” in AAAI, Orlando, FL,USA, July 1999. [13] A. G. Ganek and T. A. Corbi, “The dawning of the autonomic computing era,” IBM Syst. J., vol. 42, no. 1, pp. 5–18, 2003. [14] T. F. Lalana Kagal and A. Joshi., “A policy based approach to security for the semantic web,” in ISWC, Sanibel Island, Florida, USA„ October.2000. [15] S. Kent and R. Atkinson, “Ip authentication header,” Internet Engineering Task Force, RFC 2402, Nov. 1998, http://www.ietf.org/rfc/rfc2402.txt. [16] “Ip encapsulating security payload (esp),” Internet Engineering Task Force, RFC 2406, Nov. 1998, http://www.ietf.org/rfc/rfc2406.txt. [17] S. Thibault and C. Consel, “A framework of application generator design,” in Proceedings of the Symposium on Software Reusability, M. Harandi, Ed., Boston, Massachusetts, USA, May 1997, pp. 131–135, software Engineering Notes, 22(3).

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008 [18] S. Thibault, C. Consel, and G. Muller, “Safe and efficient active network programming,” in 17th IEEE Symposium on Reliable Distributed Systems, West Lafayette, Indiana, Oct. 1998, pp. 135–143. [19] S. Thibault, R. Marlet, and C. Consel, “A domain-specific language for video device driver: from design to implementation,” in Proceedings of the 1st USENIX Conference on Domain-Specific Languages, Santa Barbara, California, Oct. 1997. [20] L. Réveillère, F. Mérillon, C. Consel, R. Marlet, and G. Muller, “A DSL approach to improve productivity and safety in device drivers development,” in Proceedings of the 15th IEEE International Conference on Automated Software Engineering (ASE 2000). Grenoble, France: IEEE Computer Society Press, Sept. 2000, pp. 101–109. [21] F. Mérillon, L. Réveillère, C. Consel, R. Marlet, and G. Muller, “Devil: An IDL for Hardware Programming,” in 4th Symposium on Operating Systems Design and Implementation (ler OSDI 2000), San Diego, California, Oct. 2000, pp. 17–30. [22] G. Wolfien, “Network ipsec specification,” in Pan-European Harmonisation of Vehicle Emergency call Service Chain. Information Society Technologies (IST), 25. October 2002. [23] T. F. Lalana Kagal and A. Joshi., “Web services security.” in http://www-106.ibm.com/developerworks/webservices/library/wssecure/. [24] L. Kagal, T. W. Finin, and A. Joshi, “A policy based approach to security for the semantic web.” in International Semantic Web Conference, 2003,pp. 402–418. [25] R. J. Anderson, “A security policy model for clinical information systems,” in 1996 IEEE Symposium on Security and Privacy. IEEE Computer Society Press, 1996, pp. 30–42.

67

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

68

APPENDIX FILTERING RULES FOR THE LAN1’S FIREWALL: Trafic TCP : Règle

Direction

IP source

IP destination

Port source

Port destination

action

1

Outgoing

193.95.30.1

193.95.60.10

Any

53 (DNS)

Allow

2

Outgoing

193.95.30.2

193.95.60.20

Any

25 (SMTP)

Allow

3

Incoming

Any

193.95.30.3 193.95.30.4

Any

21(ftp) 80(http)

and

or

Allow

Trafic ICMP : Règle

Direction

IP source

IP destination

type

code

action

8

incoming

Any of external hosts

any

8

0

Deny

10

incoming

Any of external hosts

any

0,8, 9,10,13,14,15,16,17,18

Any number

Deny

12

outgoing

Any of external hosts

any

3

0

Accept

14

Outgoing

Any of external hosts

any

0,8, 9,10,13,14,15,16,17,18

0

Deny

FILTERING RULES FOR THE LAN2’S FIREWALL Trafic TCP : Règle

Direction

IP source

IP destination

Port source

Port destination

action

4

Outgoing

any

172.16.16.X

Any

80(http))

Allow

Trafic ICMP : Règle

Direction

IP source

IP destination

type

code

action

7

Outgoing

Any

Any IP of LAN1 and LAN3

8

0

Allow

9.1

incoming

Any of external hosts

Any IP of LAN2

8

0

Deny

9.2

incoming

Any of LAN1

Any of LAN2

8

0

Allow

Any of LAN3

Any of LAN2

8

0

Deny

9.3

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

69

FILTERING RULES FOR THE LAN3’S FIREWALL Trafic TCP : Règle

Direction

IP source

IP destination

Port source

Port destination

action

5

Outgoing

any

172.16.50.1

Any

21

Deny

Trafic ICMP : Règle

Direction

IP source

IP destination

type

code

action

6

Outgoing

Any

Any IP of LAN2

8

0

deny

11

outgoing

Any

Any

3, 4, 5, 9, 11,12

any

deny

13

outgoing

Any

Any

13

Any

Accept

PPL SPECIFICATION OF SECURITY POLICY OF DISTRIBUTED FIREWALL rule R1 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = TCP && direction= outgoing && src_ip = 193.95.30.1 && dst_ip src_port = any && dst_port = 53 && ) then allow; }

=

193.95.60.10 &&

rule R2 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = TCP && direction= outgoing && src_ip = 193.95.30.2 && dst_ip 193.95.60.20 && src_port = any && dst_port = 25 ) then allow; }

=

rule R3 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = TCP && direction= incoming && src_ip = any && dst_ip = (193.95.30.4 && 193.95.30.3 && src_port = any && dst_port = (21 || 80) ) then allow; } rule R8 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = ICMP && direction= incoming && src_ip = any && dst_ip code = 0 ) then deny; }

= any && type = 8 &&

rule R10 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = ICMP && direction= incoming && src_ip = any && dst_ip ={0,8, 9,10,13,14,15,16,17,18} && code = any ) then deny;}

= any && type

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

70

rule R12 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = ICMP && direction= outgoing && src_ip = any && dst_ip code = 0) then accept; }

= any && type = 3 &&

rule R14 () { subject : firewall1 ; /* firewall du LAN1 */ object: packet; if (protocol = ICMP && direction= outgoing && src_ip = any && dst_ip ={0,8, 9,10,13,14,15,16,17,18} && code = 0 ) then

= any && type deny; }

rule R4 () { subject : firewall2 ; /* firewall du LAN2 */ object: packet; if (protocol = TCP && direction= outgoing && src_ip = any && dst_ip && src_port = any && dst_port = 80 ) then allow; }

=

172.16.16.X

rule R7 () { subject : firewall2 ; /* firewall du LAN2 */ object: packet; if (protocol = ICMP && direction= outgoing && src_ip = any && dst_ip 172.16.16.X) && type = 8 && code = 0) then Allow; }

= (193.95.30.X &&

rule R91 () { subject : firewall2 ; /* firewall du LAN2 */ object: packet; if (protocol = ICMP && direction= incoming && src_ip = any && dst_ip = 8 && code = 0) then deny; }

= 172.16.50.X && type

rule R92 () { subject : firewall2 ; /* firewall du LAN2 */ object: packet; if (protocol = ICMP && direction= incoming && src_ip = 193.95.30.X && 8 && code = 0) then allow; }

dst_ip = 172.16.50.X && type =

rule R93 () { subject : firewall2 ; /* firewall du LAN2 */ object: packet; if (protocol = ICMP && src_ip = 172.16.16.X && dst_ip = 172.16.50.X && deny; } rule R5 () { subject : firewall3 ; /* firewall du LAN3 */ object: packet;

type = 8 && code = 0) then

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.2, February 2008

if (protocol = TCP && direction= outgoing && src_ip = any && dst_ip = = any && dst_port = 21 ) then allow; }

71

172.16.50.1 && src_port

rule R6 () { subject : firewall3 ; /* firewall du LAN3*/ object: packet; if (protocol = ICMP && direction= outgoing && src_ip = any && dst_ip = 172.16.50.X &&type = 8 && code = 0) then deny; } rule R11 () { subject : firewall3 ; /* firewall du LAN3*/ object: packet; if (protocol = ICMP && direction= outgoing && src_ip = any && dst_ip = any {3,4,5,9,11,12} && code = any then deny; }

&&type =

rule R13 () { subject : firewall3 ; /* firewall du LAN3*/ object: packet; if (protocol = ICMP && direction= outgoing && src_ip = any && dst_ip = any = any then accept; }

&&type = 13 && code

policy UnivPolicy{ scope = {F1; F2; F3; all packets} //Fi : Firewalli body = { R1;R2;R3;R4;R5;R6;R7;R8;R91;R92;R93; R10; R11; R12; R13; }

R14}