Policy-based Security Management using a Multi ...

Policy-based Security Management using a Multiagent System K. Boudaoud University of Geneva Phone: (41) 22 705 76 35 Fax: (41) 22 705 77 80 [email protected]

Z. Guessoum University of Paris 6 Phone: (33) 1 44 27 87 43 Fax: (33) 1 44 27 70 00 [email protected]

C. McCathieNevile W3C-INRIA –Sophia Antipolis Phone: (33) 4 92 38 79 89 Fax: (33) 4 92 38 78.22 [email protected]

P. Dubois Institut EURECOM Phone: (33) 4 93 00 26 38 Fax: (33) 4 93 00 26 27 [email protected]

1 Introduction Networks become more complex particularly in terms of offered services (such as e-services and mservices). Moreover, the number of users is continuously increasing. Networks are therefore more and more subject to various kinds of complex security attacks. So, security management of these new networks, particularly intrusion detection, requires more intelligence and sophistication. However, existing solutions are developed for well-defined networks and systems and are not adapted to dynamical environments and to the increasing complexity of user behaviors. Particularly some recent aspects like the mobility of users, enhance this complexity. Classical security solutions cannot easily deal with these aspects. To deal with these requirements, multi-agent systems (MAS) provide interesting characteristics. MAS provide a powerful paradigm for the modeling and the development of complex systems. They are based on the decomposition of systems into several interacting and autonomous entities called agents. An agent refers to an entity that acts continuously and autonomously in a dynamic and unpredictable environment. Recent applications show the growing interest of this paradigm in the network management domain [1] [2]. In deed, we apply this paradigm to security area and propose a MAS-based model for network security management. To manage security of a network, we need: 1) on one hand, to manage security policies specified by the administrator; and 2) on another hand, to analyze security-relevant events, occurring in the network, that characterize security attacks. Security policies play an important role in our model of security management because they guide the behavior of the MAS. These policies permit to specify: •

attack profiles to detect,

•

actions to execute when an attack is detected.

This paper is organized as follows. We first present our multi-agent system-based model for network security management. We describe then our model of security policies management. Finally, we conclude with some remarks and future work.

2 Agent-based model for network security management To model the problem of security management, we have to deal with: •

the distributed nature of the network to secure,

•

the network variation and complexity in terms of application and offered services,

•

the increase of users number and diversity of profiles that change continuously, particularly in the case of mobility,

•

the diversity and complexity of security attacks,

•

the variation of security policies.

To fulfill these requirements, we propose an intelligent agent-based solution. Moreover, to manage the security of a network, we need to: •

manage security policies specified by the administrator,

•

analyze security events characterizing security attacks occurring in the network.

Based on these three elements (security policies, security events and intelligent agents), we propose to decompose the network security management in three plans: user plan, intelligence plan and kernel plan. The user plan evolves two entities: the administrator and the security policies. In this plan, the administrator defines and specifies security policies to apply to the network. He also modifies these policies when the network configuration changes or when he would like to detect new attacks. In addition to manage security policies, the administrator receives and analyzes security reports. He could also ask for specific information such as the network security state or the current profile of a particular user. The intelligence plan symbolizes the "intelligent" part of our system. It is represented by: the multiagent system and the information model used by the MAS, which is based on the BDI (Beliefs, Desires and Intentions) concepts [3] [4]. The kernel plan represents the lowest level of our system and is constituted by: the network to secure and the security events occurring in the network. These events, which represent an important element in our model, are analyzed in order to detect attacks and to make sure that the security policies, specified by the administrator are respected. Based on these three viewpoints, we can identify the information elements that our security management system has to handle. If we analyze the previous plans, we can identify the following information elements: security policies, security events and BDI-based information model. In fact, when a security policy is defined, it allows to specify the attacks that the system has to detect. These attacks are mainly characterized by events that have to be analyzed by the MAS, particularly by more abstract information elements (beliefs, goals,…). From these information elements, we decomposed the information model handled by our system in three layers (see Figure 1): •

the security policies managed by the administrator,

•

the BDI model used by the agents,

•

the event-based model, which permits to formalize security attacks using a set of operators [5]. These operators are then used to filter events.

Security Policies Model

BDI-based Information Model

User plan

Plan intelligence Intelligence plan

Event-based Model Kernel plan

Instrumentation

Figure 1: The different layers of the network security management information model The security policies represent the guidelines of the BDI model. This model drives, at an abstract level, the underlying model that is a concrete model. In fact, we match the entities of the abstract model with those of the event-based model. The latter has to collect events that occur in the network by using a set of instrumentation tools (RMON ,TCP Dump, etc.), that we regroup in a fourth layer, named instrumentation. This layer contains both of collect tools and tools that the system could use to act on the network (for example: a firewall).

In the next section, we will focus on the model of security policies.

3 Management Model of Security Policies In this section, we describe the user plan of our model of security management. This plan implements security policies that translate the security rules and procedures of an enterprise network. Security Policies

Obligation / Authorization Policy

Parameters for instancianting attack schemas

Schema Policy Identified Actions

Instances of identified schemas

Geographical scope of detection of instanciated attack schemas

Detection / Monitoring Goals

Selection of observable events

Figure 2: The security policy role Security policies play an important role in our model because they guide the behavior of our MAS. They act at three levels (see Figure 2) and allow to: •

select and instanciate security attack schemas to detect,

•

create goals to concerned agents for detecting these security attack schemas,

•

select events to filter for recognizing instanciated security attack schemas.

After identifying the role of security policies in our model, we need now to represent and manage them. Managing security policies is not an easy task. In fact, several works have been carried out, generally on management policies [6][7][8]. Moreover, some works have been done on security policies [9][10]. From these works, several points of view have been used to represent and integrate policies in a computer science system [11]. To represent a security policy, we need to: 1) identify the different abstraction levels and 2) to specify it in a formal language. Based on existing works, we have proposed a new model of refinement and representation of a security policy. Consequently, in this section, we first present our hierarchy and refinement model of a security policy. We describe then the used formalism.

3.1

Hierarchy and refinement of a security policy

Several models of hierarchy and refinement have been proposed [6][8][11][12][13][14]. Based on the models of [6] and [8], we have proposed a new model. The aim of this model of security policy management is:

• •

to permit the administrator to specify the rules to apply to the enterprise net work, i.e.: to define what is authorized and prohibited, to implement these rules and to ensure that they are respected.

Degree of detail in the definition of a policy

An attack is a violation of one of these security rules. The role of the MAS is then to identify these violations and recognize the attacks that can occur in the network. To make our MAS able to detect these attacks, the security policies must be implemented in a language that can be interpreted by the intelligent agents. In [5], we proposed a language for defining and representing attack schemas in order to be interpreted by our agents. Thus, the role of security policies is to be able to specify at a lowest level, the attack schemas expressed in the proposed language. Consequently, we have identified three abstraction levels for security policies (see Figure 3):

High level Security Policies

Obligation / Authorization Policies

Schema / Monitoring Policies

Figure 3: Hierarchy and refinement of a security policy 1. 2.

the high level security policies that specify the general rules of the enterprise. These policies are described in a natural language, the obligation/authorization policies that specify the obligation and authorization rules. In this level of abstraction are defined:

• • 3.

• •

the different entities on which these rules are applied. These entities could be the workstations and domains to protect and the internal or external users. These users could be not defined precisely but they can be identified by the domain to which they belong, the authorized / denied actions and the temporal / geographical constraints.

the schema policies and the monitoring policies: the schema policies specify the attack schemas to detect. We focus on this policy level because they represent the policies that are finally implemented in our system, the monitoring policies specify the monitoring tasks. By these policies, the administrator could monitor specific activities concerning a part of the network or a particular user.

This work is limited to the specification of schema policies. The aim of a policy hierarchy is to automate the best possible refinement process between the different levels of abstraction of a security policy. So, we will now describe how these levels interact.

3.1.1 High level policy and obligation / authorization policy The refinement process between the high level policies and the obligation / authorization policies is done manually and consequently is carried out by the administrator. This is the case in all existing models [6][8][11][12]. The administrator has, then, to translate the high level policies in the formalism used to write the obligation / authorization policies.

3.1.2 Obligation / authorization policy and schema policy To derive automatically the obligation / authorization policies in schema policies, they must be expressed into further details. This means that from the formalism used for the obligation / authorization policies, the different operators used for defining an attack schema [5] must be deduced. Therefore, security policies must allow us to identify:

• •

what we want to protect and against what we want to do it, what we want to do when an attack is detected.

In deed, we define two schema policies: policies of instanciation of attack schemas and policies of response to attack schemas. Policies of instanciation of schemas These policies permit to define attack schemas. Depending on the policy of the superior level, which can be an obligation or authorization policy, the instanciation of the attack schema is not done in the same manner. Case of an authorization policy The authorization policies define what it is authorized or denied in a network (or part of a network) with regard to persons, network entities and/or geographical places. Moreover, they permit us to define and to create new attack schemas. Given a kind of authorization policy, that could be positive or negative, the process is different:

• •

from a positive authorization (A +), we must deduce the attack schemas that deny the authorized actions, from a negative authorization (A -), we must deduce the attack schemas that are defined directly in the authorization policy.

Case of an obligation policy The obligation policies permit us to detect specific attacks by instanciating existing schemas in order to precise what we want really to deny. The instanciation of a schema is done:

• •

either nominatively, i.e. with regard to a user, a particular source /destination network, or anonymously without precising the source and/or destination.

Moreover, the detection zone of an attack could be delimited by the administrator:

• •

either to the whole enterprise network, or to a part of the network, when he wants to protect strongly this zone.

Thus, the obligation policy acts on:

• •

the instance itself of an attack schema, or on the schema instance and the geographical zone of detection.

The negative or positive mode of an obligation policy has no influence on the instanciation process. The mode acts precisely on the policy of response to attack schemas in order to specify to the system how to react against an attack. Policies of response to attack schemas These policies permit to implement system reactions when an attack is detected. They define the actions that the administrator and the agents must do or not in this case. The administrator and/or agents can:

• •

close or not a connection, filter the source or the destination addresses by modifying the parameters of a filter or a firewall.

These policies are specified by obligation policies (positive or negative) in the superior level. This work is limited to the identification of this kind of policies without formalizing them. The corrective actions against detected attacks are not considered here. However, in our system, we define simple actions such as: inform administrator / agents, send alarm, etc.

3.2

Specification of a security policy

Our goal is not to propose a new formalism to express the obligation / authorization policies but to use existing formalism and to extend them to adapt them to our model. In the literature, several formalisms have been defined. In this work we use the formalism of Sloman [14][16] and Heilbronner [6] that we refine in order to derive obligation / authorization policies in schema policies. The proposed formalism must permit to create and to instanciate attack schemas. To create an attack schema, we need to:

• • •

identify the attack schema (to name it), specify the list of event types that represent the attack schema, specify the constraints on events. The specification of these constraints is done by using the operators defined in the language of expression of events and representation of attack schemas [5].

Moreover, to instanciate an attack schema, we need to:

• • • •

select a schema, parameterize the schema by forcing the free parameters (non specified attributes), for example the source or the destination of the event defined in the schema, specify new constraints in case of modification of some attributes such as the number of repetitions of an event or an event series, define the zone of detection of the attack schema. This information is used in order to select the group of agents that have to detect this attack schema.

SecurityPolicy SchemaPolicy

•SchemaPolicyId •AutObliPolicy •activatedAttackSchema

• ApplyPolicy() • GetPolicyType() • GetPolicyMode () • PositiveObligationPolicy() • NegativeObligationPolicy() • PositiveAuthorizationPolicy() • NegativeAuthorizationPolicy()

Is defined by

•PolicyId •PolicyBehavior •PolicyOwner •PolicyType /*general policy, monitoring policy, detection policy */ •Mode /*authorization, obligation : A+ A- O+ O - */ •LifeTime •Status /* activated, deactivated */ •AttackName •EventList •Subject •Target •DetectionDomain •Actions •Constraint /* constraints on events */ •Date

• InitPolicy() • UpdatePolicy • DeletePolicy() • ActivatePolicy() • DesactivatePolicy()

Figure 4: The security policy classes

Consequently, the obligation / authorization policies are defined by a set of attributes, which we regroup in the class SecurityPolicy (see Figure 4 To define a schema policy, which we represent by the class SchemaPolicy (see Figure 4), we need:

• • •

a unique identifier, the reference of the obligation / authorization policy from which the schema policy derives, the attack schema to create or instanciate.

Now, we illustrate the derivation of schema policies by two examples. Example 1: Creation of an attack schema by deriving a negative authorization policy In this example, we want to create an attack schema from a negative authorization policy. We have an authorization policy P1 that is defined by the following parameters: PolicyId PolicyBehavior Policy Owner Policy Type Mode Life Time Status Attack Name Events List Subject Target Detection Domain Constraints

Date

P01 detection of repeated login failure coming from the Site A and going to the Web server of the local network B. Karima Boudaoud detection policy negative authorization from 10-10-2000 to 31-12-2000 activated Doorknob Rattling e same anyone indifferent window observation = 120 seconds e.ObservationPoint = network traffic e.EventType = connection e.EventName = telnet e.Event Source = same e.EventDestination = anyone e.EventResult = failure e.Activity = extranet operators.frequency (e, 5) 10-10-2000

From this authorization policy, we obtain the attack schema "Doorknob Rattling". A simplified version is represented by the following parameters: Schema Name Window Observation Event Description List

e(

Series Attribute Operator List (

Doorknob Rattling 120 seconds Observation Point Event Type Event Name Event Source Event Destination Event Result Activity Operator Type Event Description Frequency

network traffic connection telnet same anyone failure extranet ) Iteration e 5)

Example 2: Instanciation of an attck schema by deriving an obligation policy In this example, we want to instanciate, from an obligation policy, the schema created previously (see Figure 4).

P2 (P02,….,Sch1, Site A , Web server C, Local Network B ………)

Sch1(…., same, anyone,………) Sch1 (…., Site A, Local Network B, Web server C ,………)

Figure 4: Instanciation of an attack schema We have an obligation policy P2 that is defined by the following parameters: PolicyId PolicyBehavior Policy Owner Policy Type Status Attack Name Subject Target Detection Domain Actions Date

P02 detection of repeated login failure coming from the Site A and going to the Web server of the local network B. Karima Boudaoud from 10-10-2000 to 31-12-2000 activated Doorknob Rattling SITE A Web Server Local Network B inform administrator 10-10-2000

From this policy, the attack schema "Doorknob Rattling" is instanciated with the parameters specified in the obligation policy. Schema Name Window Observation Event Description List

Doorknob Rattling 120 seconds e( Observation Point Event Type Event Name Event Source Event Destination Event Result Activity Series Attribute Operator List (Operator Type Event Description Frequency

network traffic connection telnet SITE A local network B.Web server failure extranet) Iteration e 5)

4 Conclusion In this paper, we presented the main components of our model of security management : the security policies. In the introduced model, security policies permit essentially to instanciate attack schemas to detect. To represent them, we had:

• •

on one hand, to study existing models, on another hand to consider the language of representation of attack schemas that we defined.

Therefore, we proposed a new model, where we identified two main levels of abstraction:

• •

a level for representing obligation / authorization policies, a level for representing schema policies.

The schema policies allow to instanciate attack schemas that are then sent, as goals, to the MAS. The goal of the agents is therefore to detect attacks specified by the received attack schemas. This work has been implemented in JAVA with the multi-agent plateform DIMA [17]. We are now working on the experimental validation of the realized system. To improve the human interaction interface, we plan to introduce an interface to deduce the formal specification from a natural language description of the management policy.

References [1] R. F. Teixeira de Oliveira. Gestion des Réseaux avec Connaissance des Besoins: Utilisation des Agents Logiciel. Thèse de l’ENST de Paris, 1998. [2] A. S. Rao and M. P. Georgeff. Intelligent Real-Time Network Management. Technical report 15, Australian AI Institute, Carlton, Australia, 1991. [3] A. S. Rao and M. P. Georgeff. Modelling Agents within a BDI – Architecture. In R. Fikes and E. Sandewall, editors, Proc. of the Second International Conference on Principles of Knowledge Representation and Reasoning (KR’91), pp. 473-484, April 1992. [4] A. S. Rao and M. P. Georgeff. BDI – agents: from theory to practice. Proc. of the First International Conference on Multi – Agent Systems, San Francisco, 1995. [5] K. Boudaoud. Intrusion Detection: a new approach using a multi-agent system. PhD thesis, Institut Eurecom/ EPFL, Sophia Antipolis, 2001. [6] S. Heilbronner. Requirements for Policy-Based Management of Nomadic Computing Infrastructures. Proc. of the Sixth Workshop of the HP Openview University Association (HPOVUA’99), Bologna, Italy, June 1999. [7] E. Lupu and M. Sloman. Conflict Analysis for Management Policies. Proc. of the Fifth IFIP/IEEE International Symposium on Integrated Network Management (IM’97), San Diego, USA, May 1997. [8] R. Wies. Policies in Integrated Network and Systems Management: Methodologies for the Definition, Transformation and Application of Management Policies. [9] N. Yialelis and M. Sloman. A Security Framework Supporting Domain Based Access Control in Distributed Systems. Imperial College Research Report Doc 1995/14, Department of Computing, Imperial College of Science Technology and Medicine, University of London, England, 1995. [10] N. Damianou, N. Dulay, E. Lupu and M. Sloman. A Language for Specifying Security and Management Policies for Distributed Systems. Imperial College Research Report Doc 2000/1, Department of Computing, Imperial College of Science Technology and Medicine, University of London, England, 2000. [11] D. A Mariott. Policy Service for Distributed Systems. PhD thesis, Department of Computing, Imperial College of Science Technology and Medicine, University of London, England, 1997. [12] T. Koch, C. Krell and B. Krämer. Policy Definition Language for Automated Management of Distributed Systems. Proc. of the Second International Workshop on Systems Management, IEEE Computer Society Press, 1996. [13] B. Meyer, F. Anstötz, and C. Popien. Towards Implementing Policy-based Systems Management. IEE/IOP/BCS Distributed Systems Engineering Journal, 3(2), pp. 78-85, 1996. [14] D. A. Mariott and M. Sloman. Implementation of a Management Agent for Interpreting Obligation Policy. Proc. of the Seventh IEEE/IFIP International Workshop on Distributed Systems Operations and Management (DSOM'96), L’Aquila, Italy, October 28-30, 1996. [15] J. D. Moffett and M. Sloman. Policy Hierarchies for Distributed Systems Management. IEEE Journal on Selected Areas in Communications, 11 (9), pp. 1404-1414, December 1993. [16] E. Lupu, M. Sloman and N. Yialelis. Policy Based Roles for Distributed Systems Security. Proc. of the Fourth Workshop of the HP Openview University Association (HP -OVUA’97), Madrid, Spain, April 1997. [17] Z. Guessoum and J.-P. Briot. "From Active Object to Autonomous Agents", IEEE Concurrency, volume 7 N° 3, pp. 68-78, July/September, 1999.