An ontology-based approach to react to network attacks Nora Cuppens-Boulahia1 , Fr´ed´eric Cuppens1 , Jorge E. L´opez de Vergara2 , Enrique V´azquez3 , Javier Guerra3 , Herv´e Debar4 1 TELECOM Bretagne, Cesson S´evign´e, France 2 Universidad Aut´onoma de Madrid, Spain 3 Universidad Polit´ecnica de Madrid, Spain 4 France T´el´ecom Caen, France
Abstract
to maintain sufficient quality of service and respect service level agreements. This project has defined the architecture of a ReD node, in charge of finding the best way to react to an attack, both in the short and long terms. Within this node, a main component called policy instantiation engine (PIE) is devoted to the instantiation of new security policies that counteract the network attacks. This node has to deal with the mapping of the alerts about attacks in the network into these security policies, providing the most suitable policy to reduce or even eliminate the problems caused in the network. This paper proposes an ontology-based approach to instantiate these security policies. This technology provides a way to map alerts into attack contexts, which are used to identify the policies to be applied in the network to solve the threat. For this, ontologies to describe alerts and policies are defined, using inference rules to perform such mappings. The use of ontologies for defining policies is not new. For instance, KAoS [1] and Rei [2] are well known policy frameworks based on ontologies. In this paper, we suggest an ontological approach based on the OrBAC security model. A security policy in OrBAC corresponds to a set of contextual security rules corresponding to permissions, prohibitions and obligations. These security rules apply when their associated contexts are activated. As presented in [3], we suggest using OrBAC to define reaction security rules associated with the activation of special contexts called threat contexts. On the other side, attack ontologies have also been described before. Examples of them can be found in [4] and [5], providing a formal modelling of network attacks. However, although we also use ontologies, the approach proposed in this paper is focused on the mapping from attack alerts to threat contexts. In particular, these mappings are used to determine the reaction focus, i.e. on which components the reaction applies, and the reaction strategy, i.e.
To address the evolution of security incidents in current communication networks it is important to react quickly and efficiently to an attack. The RED (Reaction after Detection) project is defining and designing solutions to enhance the detection/reaction process, improving the overall resilience of IP networks to attacks and help telecommunication and service providers to maintain sufficient quality of service and respect service level agreements. Within this project, a main component is in charge of instantiating new security policies that counteract the network attacks. This paper proposes an ontology-based approach to instantiate these security policies. This technology provides a way to map alerts into attack contexts, which are used to identify the policies to be applied in the network to solve the threat. For this, ontologies to describe alerts and policies are defined, using inference rules to perform such mappings.
1 Introduction Currently, Internet has become an attractive mean for service delivery. Network operators and providers are supplying new services such as voice or television based on the Internet Protocol (IP). Unfortunately, this has also increased the number of IP-based attacks to network systems. To address the evolution of security incidents in current communication networks it is important to react quickly and efficiently to an attack. This reaction can range from blocking the traffic to defining new security policies that are applied as long as the attack is happening. The ReD (Reaction after Detection) project is defining and designing solutions to enhance the detection/reaction process, improving the overall resilience of IP networks to attacks and help telecommunication and service providers 1
how to react on the selected components. For this, we adapt in this scope the translation process presented in [6]. One interesting property of ontologies is the ability to deal with several information models, allowing an easy integration of them. The work presented here exploits this capacity to integrate in a same view alert and policy instances, making the mapping process feasible. The rest of this paper is structured as follows. First of all, the technologies used in the ReD project are presented. Then, the mapping steps to perform the policy instantiation are defined. Next, the ontology-based representation of OrBAC and IDMEF are provided, as well as the set of rules that allow the mapping from IDMEF to OrBAC. After this, a case study is provided in which the mapping process is performed. Finally, some conclusions are given.
ReD node
PIE
RDP PDP
ACE
PEP/ REP
Immediate reaction Short-term reaction Long-term reaction
Figure 1. Red architecture
2 ReD description 2.1
level reactions are decided by the PIE, generating new security policies based on the ACE alerts that are passed to the PDP to deploy them in the PEPs.
ReD architecture
To provide the detection and reaction functionalities, ReD proposes an architecture containing a set of elements, depicted in 1:
2.2
• ACE (Alert Correlation Engine): this element is in charge of receiving alerts from network nodes, and enhances the detection of attacks by combining several diagnosis combinations.
Alerts and policies in ReD
To propagate alerts from the PEP to the ACE, and from the ACE to the REP and PIE, messages are sent using the Intrusion Detection Message Exchange Format (IDMEF) [7] using the publish-subscribe protocol as suggested in [8]. The IDMEF format is based on XML and defined to report alerts about events in an Intrusion Detection System. It is composed of a set of tags that describe the different properties that an alert can contain, such as timestamps, source and target of the attack, and its classification. At this point, it is important to remark that the vulnerability exploited is commonly used to classify the attacks, using CVE (Common Vulnerabilities and Exposures) identifiers [9]. Several languages can be used to define the security policy, including Policy Core Information Model (PCIM) [10], Ponder [11], or Organization Based Access Control (OrBAC) [12]. After an analysis of existing policy languages, OrBAC was selected as the policy language to be used in ReD because it is expressive enough to specify a large variety of security requirements. In fact, it has been successfully applied to specify network access control policies and translation mechanisms have been defined to automatically generate firewall configuration rules that are free of inconsistency and redundancy [13]. In OrBAC, security policies are specified as sets of security requirements that correspond to permissions, prohibitions or obligations. Moreover, in OrBAC, these requirements may depend on contexts that express temporal, location or provisional conditions [14], which is very useful to specify new security requirements to be triggered in reac-
• PIE (Policy Instantiation Engine): this element receives the information about attacks from the ACE and instantiates new security policies to react to the attack in a high level reaction loop. This paper is focused on this element. • PDP (Policy Decision Point): this element receives the new security policies defined by the PIE and deploy them in the enforcement points. • RDP (Reaction Decision Point): this element receives the information about attacks from the ACE and decides a reaction in a mid level reaction loop. • PEP/REP (Policy Enforcement Point/Reaction Enforcement Point): This component, outside the ReD node, enforces the security policies provided by the PDP and reaction provided by the RDP. It also performs an immediate low level reaction. As stated when defining the RED components, three type of reactions have been defined, based on level of diagnosis required to apply them: low level reactions are directly decided by the PEP/REP, mid level reactions are decided by the RDP based on the information provided by the ACE and without instantiating new security policies, and finally, high 2
tion to an intrusion. Contexts are used in ReD to express also an attack condition, this is, when an attack happens, a context about that attack, called threat context, is activated. Then, given a threat context and information provided in the IDMEF alert especially the source, target and classification, an OrBAC condition is held, activating new security rules.
2.3
Figure 2 shows the information involved in the policy instantiation if ontologies are used. An inference engine needs the OrBAC and the Alerts ontology, new alert instances as well as SWRL rules to map those alerts into OrBAC hold instances, which are selected thanks to the reasoning process (left side of the figure). These OrBAC hold instances are then used to obtain the security policy rules to activate (right side of the figure). It should be noted that this last operation is obtained directly using MotOrBAC (the OrBAC engine implemented at Telecom Bretagne).
Policy instantiation engine process
Once the ReD main concepts have been introduced, the goal of this section is to describe how the PIE maps IDMEF alerts into OrBAC contexts. For this purpose, the following steps have been defined:
3 Representing information with ontologies 3.1
• Ontological representation of the IDMEF alert. When the PIE receives a new IDMEF alerts, this alert is modelled using an ontological representation of the IDMEF alert in OWL (AO, Alert Ontology). This is further explained in section 3.3.
Ontologies: OWL and SWRL
An ontology is defined in [15] as “a formal specification of a shared conceptualization”. In practical terms, an ontology is a hierarchy of concepts with attributes and relations that defines a terminology to define in consensus semantic networks of inter-related information units. An ontology provides a vocabulary of classes and relations to describe a domain, stressing knowledge sharing and knowledge representation. With the advent of the Semantic Web, OWL [16], the Web Ontology Language has gained relevance. It is a general purpose ontology language defined for the Semantic Web that contains all the necessary constructors to formally describe classes and properties, with hierarchies, and range and domain restrictions. An OWL ontology contains a sequence of axioms and facts. It includes several types of axioms, such as subclass axioms, equivalent Class axioms and property constraints. The Semantic Web Rule Language (SWRL) [17] extends OWL with rule axioms. In the “human-readable” syntax of SWRL, a rule axiom has the form: antecedent → consequent. Informally, a rule may be read as meaning that if the antecedent holds, then the consequent must also hold. Using this syntax, a rule asserting that the composition of parent and sister properties implies the aunt property would be written: F ather(?x, ?y) ∧ Sister(?y, ?z) → Aunt(?x, ?z). In this work, OWL will be used as the ontology language to describe both IDMEF and OrBAC concepts, and SWRL will be used to map information from IDMEF to OrBAC threat contexts. For this purpose, a first step in the policy instantiation process is to define ontologies for both OrBAC and IDMEF alerts. Next sections provide such definitions.
• Ontological representation of the reaction policy. The reaction policy expressed in OrBAC is also modelled in OWL (OO, OrBAC Ontology). This is further explained in section 3.2. • Threat context activation. Based on the alert content, especially the alert classification attribute, the PIE determines which threat contexts are activated by the alert. This is modelled by relationships between AO and OO with OWL properties and SWRL rules to link an attack to a context. • Determination of reaction focuses. Based on the alert content, especially the source and target attributes, the PIE determines which components are the attackers and victims of the intrusion. This is modelled by relationships between AO and OO with OWL properties and SWRL rules that respectively map the source to an attacker subject and the target to a victim subject. • Choice of reaction strategy. Based on the reaction policy specified in OrBAC, the PIE determines on which components to react and how to react on these components. The reaction policy decides of the granularity of reaction. For instance, even if a single host is a victim of the detected intrusion, the reaction policy may decide to react on every host involved in the same local network as the victim. The reaction policy also specifies that the reaction applies at different levels; at the network level, at the system level or at the application level.
3.2
OrBAC ontology representation
. With respect to the OrBAC ontology, the following classes have been defined (see Figure 3):
• Derivation of policy instances. The PIE derives concrete security rules that apply to subject, action and object to be sent to the PDP for deployment. This is modelled by SWRL rules.
• Object, Subject and Action: these classes respectively 3
n itio fin les, e D Ro ies of tivit ws Ac Vie d an
Attack instances OrBAC Ontology
Reasoner
Hold Instances
De f o ini lev f hig tion el h Ru les
Reasoner
Policies Instances
Idmef Ontology
SWRL Rules
SWRL Rules
Figure 2. Policy Instantiation with Ontologies
Figure 3. OrBAC ontology. Role-Subject, View-Object, Activity-Action
3.3
specifies the objects, subjects and actions contained in OrBAC.
IDMEF ontology representation
With respect to the classes of the alerts ontology, the followed approach tries to reduce as much as possible the translation problems from real IDMEF alerts to the alert ontology. Thus, an alert ontology has been defined that maps the IDMEF alerts structure. This means that the alerts ontology is much more complex than the OrBAC ontology, with many more classes and relationships. For instance, the Alert class, as depicted in Figure 6, has relationships with Create time, Analyzer time, Detect time Source, Target, AdditionalData, Assessment, Analyzer, and Classification. Then, Source and Target classes are related to a User, a Process, a Service and a Node, which has an Address (see Figure 7 and Figure 8).
• View, Role and Activity: these classes respectively model the views, roles and activities contained in OrBAC. A view has a relationship with an object, and a view can be derived from another view. Similar relationship exists for a role with a subject and for an activity for an action. • Organization: this class is central in OrBAC and models the views contained in OrBAC. • Hold: this class specifies the OrBAC holds. A hold will have a subject, an object, an action, a context and an organization to be asserted.
4 Logic rules definition
• Context: this class specifies the contexts contained in OrBAC. A context will have a name. Two auxiliary properties have been defined: the first one provides which alerts activate this context, based on the CVE classification of the alert. The second one is used to know if the context is active or not.
Once the ontologies have been defined, it is also important to define the logic rules to be used in the inference engine. Three types of rules have been defined: rules to infer hierarchy information in the OrBAC model, rules to perform the mapping from IDMEF alerts to OrBAC holds, and rules to obtain the security policy. Based on the relationships defined in section 3.2, it is possible to infer information from the hierarchy model of ORBAC:
• Rule: this class models the rules contained in OrBAC. A rule will have a number, a type (permission, prohibition, obligation), and relationships with a context, a view, a role, an activity and an organization. An auxiliary property has been included to know if a rule is active or not.
• Roles and subroles: orbac:Role(?role) ∧ 4
Figure 4. OrBAC ontology. Hold
Figure 5. OrBAC ontology. Security Rule
Figure 6. IDMEF ontology (Alert relationships)
Figure 7. IDMEF ontology (Source relationships)
Figure 8. IDMEF ontology (Target relationships)
5
orbac:role subrole(?role, ?subrole) ∧ orbac:empower(?subrole, ?subject) → orbac:empower(?role, ?subject)
5 Case study This section provides an example based on the mapping steps defined above and a use case devoted to an e-mail attack. For this, first of all, a set of instances has been defined for the ontologies. Then, combining these instances with the SWRL rules in an inference engine, information about the OrBAC contexts and rules has been finally obtained.
Similar rules are defined respectively for subactivities and subviews. To generate a Hold instance of the OrBAC Ontology, the classification part of the IDMEF message is used to map to a context:
5.1
idmef :Idmef M essage(?idmef M essage) ∧ idmef :idmef M essage alert(?idmef M essage, ?alert) ∧ idmef :alert classif ication(?alert, ?classif ication) ∧ idmef :classif ication ref erence(?classif ication, ?ref ) ∧ idmef :ref erence name(?ref, ?ref N ame) ∧ orbac:context(?context) ∧ orbac:context attack mapping(?context, ?attack) ∧ swrlb:equal(?ref N ame, ?attack) → orbac:hold context(?hold, ?context)
Instance definition
The definition of instances for the OrBAC ontology includes Roles and Subjects, Views and Objects, Activities and Actions, and Contexts of the organization. A set of figures illustrate these definitions, where grey boxes are instances and io (Instance Of) grey relationships indicate the instantiated class. With respect to the description of roles and subjects, Figure 9 shows instances related to the e-mail attack use case. Then, a Mail Client is a role of subjects such as Outlook or Thunderbird, Mail User is a role of subject Alice, and MailStation is a role of subject PC-alice (Alice’s desktop computer). With respect to the description of views and objects, Figure 10 shows instances related to the e-mail attack use case. In this case, the view MailService uses the objects Exchange, etc/popd, OWA, etc/sendmail, etc/imapd, the view Mailbox uses the object
[email protected], and the view MailServer uses the object MELI (the name of the mail server). With respect to the description of activities and actions, Figure 11 shows instances related to the e-mail attack use case. As depicted, activities are read, write or access. Then, there are actions related to protocol commands (SMTP HELO, IMAP LOGIN) and protocol ports (TCP 25, TCP 143,...). Finally with respect to the contexts, it is possible to define several sub-contexts for the threat context, the operational context and the minimal context. This approach is similar to the one used in [3]. However, in this case, these contexts have not been defined as subclasses of context, but using the relationship context subcontext to link different context instances. Following this fact, instances are defined for each context level. In this case (see Figure 12), MinimalMail is a minimal context, and PopThreat is a threat context. Finally, in this use case, an IDMEF alert arrives to the PIE. In this case, it is the e-mail attack, that can be represented in the IDMEF ontology as shown in Figure 13.
Note that the helper property orbac:context attack mapping is used for the mapping. It is necessary to populate this property in all context instances. We thus obtain the Hold instances indicating which threat contexts are active due to the detected intrusion. To define the reaction focus, we define two special roles respectively called attacker and victim and a special activity called attack. To assign subjects to these roles and action to this activity, the following information is taken into account: • The attacker subject is mapped with IdmefMessage.Alert.Source.User.UserId.Name • The victim subject is mapped with IdmefMessage.Alert.Target.Node.name • The attack action is mapped with IdmefMessage.Alert.Service.name Other properties of the IDMEF message can be used for the mappings if necessary. For instance, take the address of a source or a target. The SWRL rule in this case is more complex. Note that this complexity is caused by the structure of the IDMEF message. Based on the defined Roles, Activities and Views, next step consists in activating the reaction security rules, specifying permissions, prohibitions and obligations that apply when these threat contexts are active. When more than one context is activated with this alert, both contexts will hold, and possible conflicts between security rules can occur. In this case, these conflicts should be solved before deploying the reaction following the conflict resolution strategy defined in [18].
5.2
Inferences
Based on the set of instances defined above, it is possible to know which context and rules are to be active as a reac6
Figure 9. Role and Subject instances
Figure 10. View and object instances
Figure 11. Activity and Action instances
Figure 12. Context instances and level associations
7
Figure 13. Alert instance tion of a given attack. This attack can be introduced in the system as an IDMEF alert, which classification corresponds to a POP attack. Then, based on SWRL rules, the following inferences are obtained: 1. The hierarchy of OrBAC elements has been performed. 2. The mapping rule identifies the context that deals with a concrete IDMEF alert, based on the context attack mapping property. As a result, a Hold is created, taking into account the information provided in the alert (see Figure 14). 3. The Hold activates a set of OrBAC rules, instantiating the security policy to counteract the attack (see Figure 15). In this case, a prohibition to access Alice mailbox with IMAP is defined.
5.3
Figure 14. Hold inferred
Conclusion
This paper has presented an approach to react to network attacks in which a set of alerts are used to generate new security policies. For this, an ontology approach has been used, in which the alert and the policy information models can be combined to help in the instantiation of the policies. The use of OWL and SWRL provides some advantages: there are existing generic tools for parsing and reasoning. The nature of OWL as a Semantic Web component allows merging distributed ontologies. Moreover, there are many works on mapping different knowledge bases that can be leveraged for our purpose. Some issues have also been found when doing the experimentation. The expressivity of
Figure 15. Activated rule
8
SWRL is limited, not allowing some logic operators, such as OR or NOT. Moreover, SWRL supports only monotonic inference, which means that SWRL rules cannot be used to modify or remove information in the ontology. This fact reduces the possibility to invalidate OrBAC holds when a new hold is asserted. Future works include the validation of the implemented prototype in a test scenario, integrating the PIE with the rest of the components in ReD architecture. Acknowledgement: This paper has been partially funded by the European CELTIC Project ReD (CP3-011).
[8] J. Garca-Alfara, F. Autrel, J. Borrell, S. Castillo, F. Cuppens, and G. Navarro, “Decentralized PublishSubscribe System to Prevent Coordinated Attacks via Alert Correlation,” in 6th International Conference on Information and Communications Security (ICICS), Malaga, Spain, 2004, pp. 223–235. [9] R. A. Martin, “Managing Vulnerabilities in Networked Systems,” IEEE Computer Magazine, vol. 34, no. 11, pp. 32–38, November 2001. [10] B. Moore, E. Elleson, J. Strassner, and A. Westerinen, “Policy Core Information Model - Version 1 Specification,” in IETF Request For Comments 3060, February 2001.
References [1] J. M. Bradshaw, A. Uszok, R. Jeffers, N. Suri, P. Hayes, M. H. Burstein, A. Acquisti, B. Benyo, M. R. Breedy, M. Carvalho, D. Diller, M. Johnson, S. Kulkarni, J. Lott, M. Sierhuis, and R. V. Hoof, “Representation and reasoning for DAML-based policy and domain services in KAoS and Nomad,” in Autonomous Agents and Multi-Agent Systems Conference (AAMAS 2003), Melbourne, Australia, 2003.
[11] N. Damianou, N. Dulay, E. Lupu, and M. Sloman, “The Ponder Policy Specification Language,” in Workshop on Policies for Distributed Systems and Networks (POLICY2001). Lecture Notes in Computer Science, Vol. 1995, 2001. [12] A. Abou-El-kalam, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, R. El-Baida, A. Mige, C. Saurel, and G. Trouessin, “Organization based access control,” in IEEE 4th International Workshop on Policies for Distributed Systems and Networks (POLICY 2003), Lake Como, Italy, 2003.
[2] L. Kagal, T. Finin, and A. Johshi, “A Policy Language for Pervasive Computing Environment,” in IEEE 4th International Workshop on Policies for Distributed Systems and Networks (POLICY 2003), Lake Como, Italy, 2003.
[13] F. Cuppens, N. Cuppens-Boulahia, T. Sans, and A. Mi`ege, “A formal approach to specify and deploy a network security policy,” in Second Workshop on Formal Aspects in Security and Trust (FAST), Toulouse, France, August 2004.
[3] H. Debar, Y. Thomas, N. Boulahia-Cuppens, and F. Cuppens, “Using contextual security policies for threat response,” in Third GI International Conference on Detection of Intrusions & Malware, and Vulnerability Assessment (DIMVA), Berlin, Germany, July 2006.
[14] F. Cuppens and A. Mi`ege, “Modelling Contexts in the Or-BAC Model,” in 19th Annual Computer Security Applications Conference (ACSAC ’03), 2003.
[4] J. Undercoffer, A. Joshi, and A. Pinkston, “Modeling computer attacks: an ontology for intrusion detection,” in Lecture Notes in Computer Science 2820, 2003, pp. 113–135.
[15] T. R. Gruber, “A Translation Approach to Portable Ontology Specifications,” Knowledge Acquisition, vol. 5, no. 2, pp. 199–220, 1993. [16] M. K. Smith, C. Welty, and D. L. McGuinness, “OWL Web Ontology Language Guide,” in W3C Recommendation, February 2004.
[5] D. Geneiatakis and C. Lambrinoudakis, “An ontology description for SIP security flaws,” Computer Communications, vol. 30, no. 6, pp. 1367–1374, March 2007.
[17] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean, “SWRL: A Semantic Web Rule Language Combining OWL and RuleML,” in W3C Member Submission, May 2004.
[6] A. Guerrero, V. Villagr´a, and J. B. J.E. L´opez de Vergara, A. S´anchez-Maci´an, “Ontology-based Policy Refinement Using SWRL Rules for Management Information Definitions in OWL,” in Lecture Notes in Computer Science, Vol 4269, 2006, pp. 227–232.
[18] F. Cuppens, N. Cuppens-Boulahia, and M. B. Ghorbel, “High level conflict management strategies in advanced access control models,” Electron. Notes Theor. Comput. Sci., vol. 186, pp. 3–26, 2007.
[7] H. Debar, D. Curry, and B. Feinstein, “The Intrusion Detection Message Exchange Format (IDMEF),” in IETF Request for Comments 4765, March 2006. 9
