## 5 Data Model  
As an example of an SIEM system component, which can use the ontological data model, the Attack Modeling and Security Evaluation Component (AMSEC) was chosen [21]. AMSEC generates  
Figure 2: Example of vulnerability description represented by Common Vulnerabilities and Exposures (CVE). Figure 3: Example of vulnerability representation as a row in a table. graphs of attacks using the models of the network and malefactors and the list of known vulnerabilities. Further, on the basis of the constructed graphs, the AMSEC evaluates the common security level for the network, and for each host of the network identifies weaknesses and assesses possible countermeasures aimed at increasing the security level of the network. The AMSEC also allows calculating the likely characteristics of the malefactor, predicting possible attack routes, and reconstructing malefactor actions performed before the current action. The SCAP protocol has chosen as the base for the AMSEC data model. On this basis we have built a relational and ontological parts of data model. Let us describe the ontology of security vulnerabilities, which has allowed to speed up the retrieval of data from the repository, and to increase the performance of the AMSEC. The fragment of the ontology, describing concepts, vulnerabilities, attacks, software/hardware manufacturers, and other concepts, is shown in Figure 4. It includes such concepts as _Vulnerability_, _IT_Vendor_, _Product_, _Reference_, _Smic metrics_, _CWE_, _CVSS_, and others. The concept _IT_Vendor_ is designed to represent software and hardware manufacturers. Based on the concept _Product_, a hierarchy of software and hardware, that can include vulnerabilities, is constructed. The concept _Vulnerability_ is for the specification of vulnerabilities. The concept _Reference_ is designed to link the vulnerability to its description in various public vulnerability databases. The concept _Vulnerability_Product_ is used to reason about the inclusion of vulnerabilities in software and hardware. A subclass of this concept is created for each vulnerability. It establishes the necessary links between subclasses of concepts _Product_ and _Vendor_. For example, _VP_1_ describes a vulnerability CVE-2003-0497 (subclass of _Vulnerability_), which is derived for the software _Cache_database_ (subclass of _Product_), developed by Intersystem (subclass of _IT_Vendor_). Thus, the property _hasEdition_ of the concept _Cache_database_ must be equal to five. More complex vulnerabilities (such as _CVE-2009-3115_), presented in Figure 4, are specified by the relationships of more concepts _Product_ and _IT_Vendor_. An example of the basic vulnerability affecting only one software product (Cache database version 5 of the Intersystem Company) is shown in Figure 5. This is the relationship between the concept _CVE-2003-0497_ (from the CVE database) and the concept _VP_1_. Developed ontology consists of a data schema called TBox (Terminology box) and the data themselves--ABox (Assertion box). The description of a vulnerability is a sequence of program-hardware components connected by Boolean operators (AND, OR, NOT, AND, NOT, OR). As it is shown in this figure, in the presented model the relationships between software and hardware components, which generate the vulnerability, are specified using the description logic. Connections between the concepts are represented, mainly, by the subclasses (depicted as \"is-a\"), rather than through the properties of the objects. Thus, the logical reference here is confined to the task of classification, which increases the processing speed. In our work we sought to reduce the expressiveness of the description logic to reduce the complexity of reasoning over the knowledge base, while expressing all the necessary properties and relationships. The expressivity of the description logic corresponds to the _ALEQ(D)_ language. Figure 4: Ontological model for vulnerability representation. Figure 5: An example of ontological representation of vulnerabilities.