Security data can be generated by different sources, such as access systems logs, firewall logs, vulnerabilities alerts, and statistics of processors or memory use. Due to this great volume of information, the security administrators face out a difficult problem, which is efficiently generate knowledge about security to make decisions and solve security incidents.
Besides this volume of information, the security tools generate data in different formats, making the security management even harder. Some research institutes, such as CVE Project (Common Vulnerabilities and Exposures) [1] and CERT/CC (Computer Emergency Response Team/Coordination Center) 1have made efforts to classify and store security data using a unique standard. However, these institutes do not attribute semantic to the data stored and published. Without the semantic meaning, the software agents or the administrators are unable to automatically make implicit correlations among security incidents.
To ease and make it possible to automatically correlate different security data from different sources, and also to ease information management about security incidents, we propose to use ontologies, defining a unique vocabulary of concepts and relations related to security incidents 2 .
According to Gruber [2], ontology is explicit formal specifications of the concepts in a domain and the relations among them. Ontology defines a common vocabulary for a community of people, such as researchers and security administrators, and for software agents that need to share information and need to have a common understanding about a domain knowledge. Ontologies consist of a set of concepts, relations, and axioms that formalize a field of interest, with detail and structure that enable computers to process its content.
Some reasons to develop and to use ontologies are [3,4]:
-Sharing common understanding of the structured information among people or software agents. For instance, suppose that several Web sites contain information about vulnerabilities. If these Web sites share and publish the same ontology of the concepts and relations they use, software agents can extract and aggregate information from these different sites, using them to answer queries about vulnerabilities or as input data to other applications. -Reusing knowledge. If one group of researchers develops an ontology, others can simply reuse it, saving efforts. For instance, the Computer Security Incident Ontology (OntoSec) [5,6] developed and described in this paper reuses some concepts and relations of the Vulnerability Ontology developed by Brandão [7]. Or, a network management ontology could reuse and extend the class Asset defined by OntoSec to represent the assets that can be attacked in a computational system. -Interoperability. Different applications can use the concepts and the relations defined by an Ontology (e.g. OntoSec) to extract and infer useful information to deal with vulnerabilities, easing the interoperability that allows sharing data among different applications.
The remainder of this paper is organized as follows. Section 2 presents some security issues. Section 3 briefly presents the related works. Section 4 presents the Security Incident Ontology developed and its main features. The ontology validation process is presented in Section 5. Section 6 presents the main benefits of using ontology to help security management. And, finally, Section 7 presents final remarks and future works. that only authorized people or systems access the information, and it is related to the Authentication, which ensures that the user is really who he/she says. Integrity ensures that the information is not modified accidentally or maliciously. Availability ensures that the system works with no degradation and provides resources whenever authorized users need. The satisfaction grade is defined by a security policy, which creates the rules of what is and what is not allowed in the system.
Along the years, the volume of security data that the security administrators have to manage has grown exponentially. Unfortunately, managing these data and information has became more and more difficult, because different security tools generate alerts in a different standard and with different kinds of data, and the administrators, using their tacit knowledge, have to correlate and analyze these data.
In this sense, it is important to define a way to generate the security data in a unique standard, including a unique vocabulary of concepts and their relations. This unique vocabulary allows the security administrators to manage and correlate different security incidents automatically, and also make it possible to implement countermeasures to solve security incidents more efficiently and to ensure the important features already mentioned, namely confidentiality, integrity, availability and authentication.
Howard and Longstaff [9] developed a common language for security incidents. This common language is a high-level taxonomy of security incidents concepts. The taxonomy was based primarily on security incident theory, but the experience in incidents classification of CERT was used to refine and expand the taxonomy. Basically, the incident taxonomy defines concepts as attacker, tool, vulnerability and security incident. OntoSec reuses some of the concepts defined in the security incident taxonomy.
Two relevant works are the ones conducted by Raskin et al. [10] and Schumacher [11]. Raskin et al. proposed the use of natural language to define, in an unique way, the meaning of the main concepts about security incidents. Basically, the ontology is composed by two parts: a set of high-level concepts and a method of classifying them as a taxonomy. Schumacher proposed the Core Security Ontology to represent a conceptual mapping of security policies. The ontology represents the top-level security concepts and how they related themselves. Depending on the organization and its security policies, these concepts can be specialized and new ones can be created. Both works propose an abstract and high level vision of security management.
OntoSec, on the other hand, represents not only the concepts but also the relations among the concepts of the security incident domain. It also proposes a more concrete vision of security management, because it specializes these main concepts.
To develop the OntoSec, two methodologies were used: the Methontology, developed by Fernández et al. [12], and the methodology developed by Noy and McGuinness [3]. The Methontology was used to guide all the ontology development process, because it was developed taking IEEE standard for developing Software Life Cycle Processes (IEEE 1074-1995) [13] as a starting document, and it has its roots in a methodology for developing Knowledge-Based Systems (IDEAL [14]) [15]. The methodology developed by Noy and McGuinness was used to guide the conceptualization phase because it defines clearly what should be done, and how it should be done.
Most of the concepts in the OntoSec were compiled using security incident glossaries and taxonomies [16,9,17]. Besides these sources, the CSIRT/USP (Computer Security Incident Response Team/Universidade de São Paulo)3 was also used.
After defining the concepts and the relations among them, the OntoSec was formalized using the W3C4 standard language for modeling ontologies -OWL (Web Ontology Language) [18] and the Protégé tool, which is a free, open-source ontology editor and knowledge-base framework 5 .
OntoSec has four levels of classes (or concepts). These four levels represent the main concepts related to the security incident domain. The first level has 13 classes, which are presented in Figure 1, the second one has 11 classes, which are the subclasses of the main level, the third one has 14 classes, which are the subclasses of the second level, and the fourth one has 11 classes, which are the subclasses of the third level, summing up 49 classes. Besides these classes, the OntoSec has 36 non-hierarchical relations and 58 attributes, summing up 94 properties. The first level represents the "core" of the OntoSec.
Figure 1 presents the main concepts and relations, which are: an Agent performs an Attack that can cause a Security Incident. To perform an Attack, an Agent can use a Tool, which can explore a Vulnerability, to get Access. The Security Incident implies to a Consequence and acts on an Asset. The Security Incident also can have a PreCondition, and this PreCondition can be related to a Vulnerability. A Consequence can be related to an Asset and a Security Incident can precede or/and proceed another one 6 . A Vulnerability can be explored with other ones, it can has another vulnerability as precondition, or it can be precondition to other vulnerabilities. It also has a Correction, which is developed by a Supplier, a Type and a Range.
The vulnerabilities are represented by the Vulnerability Ontology. The Vulnerability Ontology models the main concepts and relations about the vulnerability domain. These concepts and relations were defined based on CVE Project and the NVD (National Vulnerability Database) 7 . And, some of these concepts and relations are imported by OntoSec8 . The main concepts imported are: Vulnerability, Type, Correction, Range and Supplier.
Some classes represent a taxonomy, with isA relations, which are specialization and can be also called hyponymy relation. For instance, the class Asset has as sub-classes: Data, Hardware, Port, Resource, RootAccount, Software and UserAccount. The isA relations are represented using two constructors, one in OWL and the other in RDF Schema (Resource Description Framework Schema) [19]: owl:class and rdfs:subClassOf, respectively. To identify a security incident, some attributes were defined: hasip source (computers from where a security incident begins), hasip destination (computer being attacked), hassecurity incident type (27 security incidents types are represented in OntoSec), has date (the date the security incident oc-curred), has time (the time the security incident occurred), has description (describe the security incident), has reference (any Web site with information about the security incident), has weekday (week day in which the security incident occurred), has severity (how serious is the security incident). This last attribute can have the following predefined values: Low, Medium or High.
All attributes are represented in OWL as a Datatype Property. This property also defines which are the Domain Resource and the Range Resource. In this case, the Domain Resource is the class which has the attribute and the Range Resource is the type of attribute. Similarly to the Object Property, the Datatype Property also can have a restriction as cardinality, representing how many instances the property can have. It is also possible to predefine instances. For example, the attribute has severity can have only one of the following instances: Low, Medium or High.
The ontology evaluation process is the problem of assessing the quality of a given ontology, either to aid in the selection of an ontology for the needs of a particular task or organization, or to evaluate or guide an ontology constructing effort [20].
Several approaches have been developed to evaluate an ontology, depending on what kind of ontologies are being evaluated and for what purpose. Some approaches are: to use the ontology in an application [21], to compare the ontology to a "golden standard" of the domain [22], to compare the ontology with a source of data or documents about the domain that is represented by the ontologythe "data driven" approach [23,24], and to assess how well the ontology meets a set of predefined criteria, standards and requirements, etc. [25].
To validate the OntoSec, the approach defined by [23,24] was used, because this approach defines a way to check if the ontology is representing the concepts of such a domain knowledge. In this sense, security alerts from SNORT was used to check how well OntoSec cover the security incident domain. SNORT is an open-source network intrusion prevention and detection system based on a rule-driven language9 .
The main aim of the validation process is to show that OntoSec represents important information about security incidents correctly. Besides that, it is also important to show that OntoSec can help the security administrators to deal with security incidents problems more efficiently, querying the ontology about security incidents. The validation process has been carried out in two phases:
1. Mapping security incident data into OntoSec, which has been done.
from OntoSec, which is under development.
Mapping Security Incident Data. Security alerts generated by SNORT were used to validate the OntoSec. SNORT generates intrusion alerts based on rules according to signatures of attacks. The following example shows an alert generated by SNORT. Line 1 presents the alert description and line 2 presents its classification and priority (severity) according to SNORT configuration. Line 3 presents when (date and time) this alert occurred and which are the source IP, source port, destination IP and destination port used. Lines 4 to 8 present URLs 10 where it is possible to find information about the alert. To support OntoSec validation process, a tool was developed using Java and Jena 11 . This tool does the mapping of the security alerts generated by SNORT into OntoSec, creating a security knowledge base that is used in the next phase of the validation process (query and inference). As RDF has a simple data model that is easy for applications to process and manipulate and RDFt's generality offers greater value from sharing, it is used to store the security incident knowledge base instead of storing the base inside the ontology itself.
The following RDF code represents the information about the "SNMP AgentX/tcp request" alert. For each rdf:description, RDF creates a nodeID. The nodeIDs are also used to relate a security incident to the logical ports (rdf:nodeID=A5151) and to the protocols (rdf:nodeID=A3989) used during the attack. <j.0:has_sourceportnumber>111</j.0:has_sourceportnumber> <j.0:has_destinyportnumber>705</j.0:has_destinyportnumber> </rdf:Description> <rdf:Description rdf:nodeID="A3989"> <rdf:type rdf:resource="http://a.com/SecurityIncidentOntology#Protocol"/> <j.0:hasprotocol_name>TCP</j.0:hasprotocol_name> </rdf:Description> </rdf:Description>
The tool is composed by two parts: one responsible to collect and structure the SNORT alerts, and another to do the mapping into the ontology. As the tool was developed using a modular structure, the task of integrating new security tools is easier, only the interface between the mapping tool and the security tool has to be modified. As SNORT generates security alerts using a standard (text files), to get the security data was an easy task to be done. A security alert file of 600KBytes were use. This alert file generated a security incident knowledge base of 20MBytes. This knowledge base is stored in a MySQL12 database13 . Jena framework was used to store the RDF file in the database. Herein, it is important to point out that not necessarily the security alerts generated by SNORT are really security incidents, many of these alerts are false-positives. But the security alerts were used to know how well the OntoSec models security incidents. Some data could be directly mapped into OntoSec, such as description, date, time, source and destination IP, source and destination port. But others, as the incident type, could not be because SNORT uses its own standard types of incidents. In this case, a previous task was done in which a type of incident in SNORT was mapping into a type of incident in OntoSec. For instance, the types Attempted Information Leak and Detection of a Network Scan were mapping as type Scanning in OntoSec, the types A Network Trojan was detected, A suspicious string was detected and Executable code was detected were mapped as Malicious Code.
Some attributes, such as source and destination port, and protocol, are mapped as relations between SecurityIncident and Asset classes, because in OntoSec a protocol and a port are modeled as potential targets (assets) of such a security incident. Table 1 shows an example of how some attributes were mapped into the attributes of the SecurityIncident class, the Port and the Protocol classes in OntoSec. From the date, the day of the week is calculated and the has weekday attribute in OntoSec is used to represent it.
It is possible to notice that OntoSec models important information about security incident domain. On the other hand, it is also possible to see that the ontology is modeling information that a security tool does not represent, such as the consequences of a security incident. In this sense, according to the type of the security incident, the ontology can be used to infer which are the consequences. For instance, a Dos (Denial of Service), DDos (Distribuited Denial of Service) or Querying and Inference Application. Once the security alerts have been stored in RDF using a MySQL database, it is possible to ask questions to the ontology. This task allows to check how well the ontology can answer important questions about security incidents. To perform this task, Jena and a specific RDF querying language, SPARQL 14 , have been used. SPARQL is a SQL-like 15 language that uses the basic clause SELECT FROM WHERE.
Using the querying and inference application, the security administrators can ask questions like:
-How many security incidents have happened because of such a vulnerability? -Which are the most common types of security incidents? -Which are the assets that have more security problems and must to receive more attention concerning patches? -Which security incidents have happened after a previous security incident (looking for correlation)? -Which are the most common ports used to perform a security incident?
The following two examples show how a query is done using SPARQL.
(i) Which security incidents happened on January The results of these queries allow the administrators to know which incidents happened in a specific day and which incidents were caused by a malicious code, respectivelly. If many incidents happen because of malicious codes, such as viruses or worms, the administrators can update the computational systems more frequently. Combining both queries, it is also possible to know in which date security incidents caused by malicious codes happen. Using the results, the administrators can prevent attacks that happen on specific periods.
We can point out the following advantages of using ontologies to assist the information security management:
-The development of ontologies creates a conceptual model that makes it possible to the organization to know better its security incidents domain. -The ontologies can facilitate the interoperability among different security tools, creating a unique way to represent security data and, for instance, allowing that security alerts from any security tool is mapped into an ontology. -The Security Incident Ontology imports the Vulnerability Ontology, allowing the reuse of knowledge and information. Other ontologies about security domain could be imported, such as a Virus Ontology or a Worm Ontology. The same reuse can be scaled up in such a way that security information can be treated in a more abstract level. -The querying and inference process helps the security administrators to be more confident of the decisions made about the security information management, because the ontology developed is knowledge bases about security incidents. The ontology allows the security administrators to learn from previous security problems, assisting them in solving and preventing new problems.
Not only ontologies can fundamentally change the way in which systems are constructed, as stated by Swartout and Tate [26], but they also will change the way people and systems can communicate to each other about a domain knowledge.
Using a security incident ontology, the organization can improve its ability to manage and to control security incidents problems. Besides that, the administrators can learn more about security and can prevent the computational systems from previous problems efficiently.
The mapping process shows that the ontology models important information about security incidents. The querying and inference process helps the security administrators to be more confident of the decisions made about the security management, because OntoSec allows to create a knowledge base about security incidents.
The next steps of the validation process are: (i) to use real security incidents (security incidents from the CSIRT/USP will be used), (ii) to map security alerts from other security tools, and (iii) to develop a security incident management system based on the ontology, making it easier the interoperability among different security tools.