Semantics for incident identification and resolution reports

[14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 916 916–932 Semantics for incident identification and resolution reports JOAQUÍN BORREGO-DÍAZ, ANTONIA M. CHÁVEZ-GONZÁLEZ, JOSÉ L. PRO-MARTÍN and VIRGINIA MATOS-ARANA Department of Computer Science and Artificial Intelligence – University of Seville, Spain. Abstract In order to achieve a safe and systematic treatment of security protocols, organizations release a number of technical briefings describing how to detect and manage security incidents. A critical issue is that this document set may suffer from semantic deficiencies, mainly due to ambiguity or different granularity levels of description and analysis. An approach to face this problem is the use of semantic methodologies in order to provide better Knowledge Externalization from incident protocols management. In this article, we propose a method based on semantic techniques for both, analyzing and specifying (meta)security requirements on protocols used for solving security incidents. This would allow specialist getting better documentation on their intangible knowledge about them. Keywords: Incidents, security, semantic technologies, knowledge management. 1 Introduction A key organizational activity in Security for Information Systems (SIS) is the document generation, spreading and management, for both employees and clients (see e.g. Microsoft document [24]). The documents meet several purposes: spread information within and outside the organization, facilitate self-learning within the organization, make explicit tacit knowledge on incident management, isolate emergent security concepts, etc. Documentation service provides robust strategies and secure solving methods to face a wide range of situations. Among the documents, these related with reports on incidents, protocols and information on systems can play a structural role in the SIS paradigm. Their role is not limited to Document Engineering (DE) as it covers several levels, for example, documentation, diffusion and self-learning among employees. However, as it is said in Mace et al. [19], reports generally describe information security policies by mixing professional opinion, staff experience, technology manufacturer advice and external security standards or regulations. Therefore, it is natural to think that traditional and successful methods and policies have to be documented in order to get better knowledge externalization (KE) in the sense of the classic framework introduced by Nonaka and Takeuchi [23]. KE represents a clever strategy in SIS documentation since reports are useful mainly for organization members (which share the same tacit knowledge about this), and it is frequent that new paradigms force them to conciliate knowledge. This scenario of deficient KE contrasts with the current ubiquitous role of SIS, which has evolved from a technical discipline to a strategic concept (see e.g. US National Academic briefing [22], Smith and Spafford [34] and, in the cloud paradigm, Catteddu and Hogben [9]). The world’s growing dependence on a powerful but vulnerable Internet—combined with the disruptive capabilities of cyberattackers—now threatens national and international security. Thus, it is even necessary to think on the problem from the point of view of Complex Systems Science (Sadvandi et al. [28]). [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 917 916–932 In Geer’s book [13], influence factors in security incidents are summarized, showing the complexity and hardness of the problem. Author juxtaposes cyberattack advantages and mitigation strategies according to their level of influence of one to the other. He presents different features of attacks at general level, and also considers SIS vulnerabilities and defences classified in different categories. The study suggests that a clear and robust classification could provide a better defence position. Robust classifications have to be stable under comparisons with other approaches. Therefore, a scientific approach to cybersecurity is indispensable, even as a target for (e-Semantic) Science, covering seven interrelated themes (see Riley [32]): Common Language, Core Principles, Attack Analysis, Measurable Security, Risk, Agility and Human Factors. All of these themes converge in document representation in SIS. The other challenge associated with SIS documentation is the potentially vast number of disparate information sources, which makes the management of SIS information complex and time-consuming (cf. also Mace et al. [19]). Although KE consolidates the knowledge within individual organizations, it is typically kept ‘in-house’ and the interoperability among different organizations could be a challenge. That is to say, it may suffer of interoperability issues, most of them of semantic nature. This gap makes harder to exploit SIS documentation of an organization by others or its effective spreading, a problem related with the global nature of SIS challenges. 1.1 Semantic methods for SIS Semantic web technologies (SWT) can provide an unified point of view solving the aforementioned problems. It is important to point out that SWT can be viewed as both, a technology and a scientific discipline for knowledge representation and reasoning (KRR), which facilitates knowledge extraction, representation, management and even reasoning, instead of a discipline focused only on Ontology Engineering. The last viewpoint is very useful to face the above challenges by considering those as Knowledge Management Problems grounded on DE (cf. Glushko and McGrath [14]). By focusing on the theme of this article, two related tasks matter. On the one hand, the attempt to formalize the information described in the reports provides knowledge emergence. On the other hand, SWT naturally solve interoperability problems by means of KE. Consensus efforts to represent document’s knowledge by means of ontologies and data allow engineers and employees getting a sound understanding of ideas (which can be externalized), represented by means of concepts, properties and axioms of the ontology. Therefore, the problem of understanding the structure of concepts to anticipate potential issues of document information may be solved by the joint work of KRR specialists and security experts. Such solutions could be provided during activities driven to ontology creation, instead of only exploiting the final product, i.e. the ontology. Additionally, SWT provide tools for analysing important features as, for instance, consistency, compliance with current Security Standards, as well as the fidelity with the intended model (see e.g. Aranda et al. [3] in SIS, and Alonso et al. [2] in general). The latter feature is based on a sound representation of some concepts, i.e. to say, whether the specification represents the intentions of security experts and whether there are axioms (or properties) clearly incompatible with real concepts. Therefore, the ontology-based approach enables the definition of security concepts and their dependencies in an understandable way for both humans and software agents (see Pereira et al. [27]). [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 918 916–932 1.2 Aim of the article The aim of the article is to exploit SWT and associated methods, in the analysis and refinement of knowledge from security reports. The idea is to get better documentation by means of a semantic evaluation and improvement proposals. The idea bases the process of ontology creation on information contained in the documents. The document set published by Spanish INTECO–CERT institution1 has been selected as running example: INTECO’s identification and report of security incident for strategic operators [36] and The operator console. A Basic Guide to Critical Infrastructure Protection [37]. The first one aims to be a guide intended to serve as a manual for action reporting and management related to Critical Infrastructure and Strategic Operators incidents through the INTECO–CERT. The second one describes the actions that operators have to perform in order to provide an effective and efficient response to security incidents. The documents provide a standardized protocol effort for both, effectively solving and documenting security incidents in a SIS scenario. 1.3 Structure of the article The structure of the article is as follows. The next section is devoted to analyse relevant features in security documentation, with particular emphasis on the use of flowchart descriptions as main tool in processes description. In Section 3, the strategy we propose is described. In Section 4, some relevant results on the application of the strategy to a specific case (an Incident Report and Identification document) are reviewed. Section 5 provides some hints about the evaluation of the strategy within Knowledge Management Framework. Lastly, some conclusions on both the strategy and its applications are discussed (Section 6). This article is an extended version of the work by Borrego et al. [8]. 2 Semantic features of security documentation The analysis of SIS documents has to be performed from different points of view, by distinguishing between classification of SIS elements (e.g. identification of incidents) and the description level of security protocols (for reporting or solving incidents). The representation of different features will provide essential elements (classes and particular individuals) for the ontology in a natural way. Due to the modular nature of the ontology, it should be allowed to extend or modify these elements without a general reconsideration of ontological commitments. To achieve this modularity, the top level of the ontology have to conciliate both points of view (identification and reporting), while low-level classes will represent a set of particular elements (usable actions, specific protocols, a set of possible identifications and classifications, etc.). Identification and protocol descriptions have different ontological nature although they share some common features allowing to articulate the ontology in two sub-hierarchies. Although it would be possible to specify identification and resolution protocols by means of standard service ontologies (e.g. OWL-S or WSMO), a specific flowchart-based light ontological description of protocols is created instead. The reasons of this choice are justified by the particular features of SIS documents as well as by the details of protocol description within them: • Description (at operator level) is simpler than that of standard service ontologies: a succinct and clear specification is better to understand protocols than a complete one. It is also more adequate for pragmatic representation of solutions. 1Acronym of Spanish Incident Response Center Security http://www.inteco.es/home/national_communications_ technology_institute/ [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 919 916–932 •The representation of protocols in documents is very similar to their natural (graphical) descriptions, making them easily understandable by operators and, in general, by any SIS organization member. • A concise semantic description of the protocols which does not add complexity to reasoning services is provided. • Because of natural mapping between actions and their corresponding ontological representation, the addition of new actions/description elements does not require SWT experts. A secondary goal of the formalization of flowcharts is that the insertion of a new flowchart in the systems will be guided by the requisites flowchart ontology has (which can be understood as questions to be completed by the user). Since the flowchart ontology will be used, it is interesting to briefly describe it. 2.1 A view on the flowchart ontology Flowcharts are the standard way to represent processes, or, in general, almost every kind of protocols involving dynamics in terms of state changes. Flowchart is designed as a directed graph in which nodes are represented by boxes and edges (arcs) are represented by arrows showing the process flow in the diagram. The dynamic dimension of semantic analysis of SIS guides will be obtained by means of a flowchart-based representation of protocols. The version of the basic concept on the ontology is depicted in INTECO terms in Figure 1 from [36]. A singular feature of the ontology is the identification between AtomicAction and FlowchartAction classes. This non-orthodox equivalence is the result of a group discussion among authors. Ontological distinction between action and representation of the action within flowcharts is discarded. In this way action class is used in both levels, and non-experts in Ontology Engineering will understand the flowchart better. There are multiple variants of flowcharts (Petri nets, ASM charts and so on). The simplest one only uses two types of nodes (boxes): Action boxes and Decision boxes. The first ones contain a set of actions that the user should execute in that state, therefore an action box must have one and only one output path. They are represented by the class ActionBox in our ontology. The second kind of boxes are the Decision ones, where the inner text is a condition to be verified. The next current state depends on the value at which the condition may be evaluated (the condition is not a logic formular to be evaluated within the ontology, it is represented as a simple text). This kind of nodes can have multiple output paths. Decision boxes are modelled by the class DecisionBox in our ontology. Figure 1 shows the hierarchy of classes of the sub-ontology. It can be understood that ActionBox and DecisionBox are subclasses of a more generic concept, which we have called InnerBox (representing the internal nodes of a flowchart). In this way some restrictions on FIG. 1. Flowchart box element class. [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 920 916–932 the classes can be added, as for instance: ActionBox(=1 hasOutputPath.Path), DecisionBox(≥1 hasOutputPath.Path) Some types of flowcharts have two special nodes. Those that do not have an input path (i.e. input degree in the graph is equal to zero) and those that do not have an output path (i.e. ouput degree is zero). These nodes are represented in our flowchart ontology by means of StartBox and EndBox classes, respectively. We can enforce these constraints making these classes subtypes of OutputPathBox and InputPathBox: InputPathBox∃ hasInputPath.Path, OutputPathBox∃ hasOutputPath.Path Thus, an instance of InnerBox must inherit both restrictions: InnerBox∃ hasInputPath.Path, InnerBox∃ hasOutputPath.Path Some other key concepts and classes of this ontology are Condition and Path with the natural associated semantics. As it was already mentioned, there exists a number of ontologies that could be used for flowchart semantic representation. Among them, similar approaches to be presented here are related with the representation of industrial/business processes. Also the flowchart concept appears in biotechnology ontologies as, e.g. in the National Cancer Institute Thesaurus,2 Semanticscience Integrated Ontology3 and SWEET Governance Ontology4, among others approaches. 3 A strategy for KE from incident reports The goal is to enrich KE processes by means of Ontology Extraction processes. In this article, we propose a strategy for ontology extraction to accomplish this aim. The strategy consists of four stages (Figure 2): Stage 1: Preliminary analysis: In this stage, activities are closely related with the rough understanding of goals and reports structure of the organization: 1. To state the scope and intended use of SIS document. A first distinction between descriptionoriented and solution-oriented protocols and methods is made. 2. Document analysis. Ontology engineers analyse the logical structure of the document and isolate main concepts used within it. 3. To determine the ontological nature of different concepts. Elaboration of a first categorization (possibly by building several hierarchies). 4. To find potential ambiguities or deficiencies in elements to be included in the ontology. The Results expected in Stage 1 are related with the above analysis; formal and specific definitions are still not required. These are focused on the understanding of: • Scope and Intended use. • A high-level categorization, a first set of concepts extracted from document analysis and a first approach on the relationship structure among the different elements. 2http://bioportal.bioontology.org/ontologies/NCIT 3https://code.google.com/p/semanticscience/wiki/SIO 4http://wiki.esipfed.org/index.php/SWEET_Governance [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 921 916–932 FIG. 2. Strategy applied to SIS documents. • Above results may reveal potential errors. They are compiled to be solved later. Stage 2: Ontology creation activities: The adoption of a pre-existent security ontology to formalize and clarify the SIS documentation, does not seem a sound approach, given the goals. The main reason is that it describes an approach to SIS report/classification that could be incompatible with the tacit knowledge (in particular intangible assets) of the organization. Since the main goal is KE instead of the production of a stable ontology, the activities to be performed in this stage are classic steps in ontology building: • Hierarchies and properties implementation (e.g. using Protégé). • Design of axioms (classes specification) for the key concepts. • Study of relationships between sub-hierarchies devoted to different KRR problems (e.g. descriptions and methods). Results expected in this stage are: • An explicit representation of Hierarchy and Properties • Axiom design (only natural axioms are added here), some of them devoted to describe properties between hierarchies Stage 2 produces a first formal approach of tacit knowledge from SIS organization through the documentation. This approach allows SWT experts confronting this issue with other known representations (mainly ontologies). Representability of security issues. The proposed bottom-up approach is the natural choice as it is not primarily intended to build a (other) security ontology. The aim is to build an explicit representation of tacit consensual knowledge (concepts, methods, relations) in reports documentation within an organization (this ontology may be a consensus on concepts and terms). Since bottom-up ontology building strategy is grounded on security information resources, and, since these kind of resources have not been designed to fit ontological structures, several deficiencies of representation [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 922 916–932 TABLE 1. Representational problems in Information Security [P1:] No concepts for some kind of vulnerabilities [P2:] Vague connections between threats and controls [P3:] No relationships between threats [P4:] Inconsistent granularity of information [P5:] Redundancy and overlapping of information arise. In [11], Fenz and Ekelhart detect a number of representational problems when enriching a security ontology by means of Information Security (see Table 1). The bottom-up process aids to solve most of these problems (P1,P2,P4,P5), while problem P3 rests explicitly posed (to be solved by SIS experts). It is worthy to note that the adaptation of a general security ontology for this task is hard to automate, because some revision criteria cannot be fully formalized. Stage 3: Comparison with standard security ontologies: The activities are driven to repair, refine and enrich the knowledge extracted in the above stage. The comparison strongly depends on a number of KRR issues. Likewise it is worth to note that the task has to be made both automatic (e.g. by merge-ontology tool of Protégé) and manually (by discussing other non-directed relationship among classes). In this case, manual comparison is essential because engineers attempt to redefine security concepts for standardizing emergent concept with previously established ones in other ontologies. Results expected are encompassed in an analysis on the relationship between the prototype ontology and well-known Security Ontologies, Security Categorizations and in general other ICT Standards [6, 11, 16, 19, 26, 27, 30, 33]. Stage 4: Semantic evaluation report (with improvement proposals): Each step requires some discussion on features of key concepts. Such discussion has to be documented in the final report. The use of the ontology as a semantic reference of future SIS documents has to be taken into account. Activities: SWT engineers have to document all the tasks and decisions of the strategy, concluding with a document on recommendations. Results expected are oriented to the client (SIS organization), by documenting the strategy and results: a semantic evaluation report which includes improvement proposals. Finally, an ontology prototype documentation is provided, if experts consider that it is interesting to publish the ontology. 4 A case study: Applying the strategy to Incident Report and Identification documents This section is devoted to summarize some observations about the selected stages of the strategy, as well as to discuss the main conclusions on the application of the presented strategy to (Incident Report and Identification) IRD documents [36, 37]. 4.1 Phases of incident response. Some results from Stage 1 According to [36], the description of the main phases in incident response and mitigation of risk are (see Figure 1, from the document [36]): Identification (classification), contention and mitigation, evidence preservation and legal considerations, documentation and recovery. The elements of these phases have different nature. On the one hand, classification and identification have static nature while actions correspond to protocols (non-complex plans). [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 923 916–932 4.2 Static versus Dynamic dimension (from Stage 1, activity 2) Preliminary analysis of documents (stage 1) shows that two particular ontological dimensions are combined. The first one refers to (statical) identification of main elements. This fact is important due to the fact that solving/repairing/mitigation methods strongly depend in the secure identification of the incident, which depends on turn of the classification of them. Despite that, it is hard to state the complex relationship among different categories. SIS documents often enumerate elements appearing in a particular organization, and the methods often depend on such classification. However, refinements of the categorization aid to specify the methods. 4.3 Ontology creation activities (from Stage 2) Stage 2 includes the description of dynamic elements, e.g. protocols and methods. A protocol description is more precise than risk identification. This observation suggests building a flowchart-based sub-ontology in order to describe them. This ontology was described in Section 2.1. Likewise, an ontology on the incidents and processes described in the document was built. As it was already mentioned, such ontology represents a formal description, useful to compare intangible knowledge from the document with other well-established formal representations from the following stage. 4.3.1 Logical specification of meta-security in IRD (from Stage 2) Specification of the ontology opens the possibility of including constraints that would be included in the SIS documentation (in natural language). Some of them would allow to monitor integrity/safety constraints. For example, the system only considers as detected incident the one for which it has an evidence: Detection≡∃hasEvidence.Evidence Likewise, flowchart semantic specification allows instantiating protocols, making each one a complete and consistent representation of a security method. In particular, only flowcharts representing approved methods can be included: FlowChart(≥1represents.Action) where Action≡AtomicActionProceduralAction. The absence of classification of an incident is prevented by a restriction axiom on the property originIn: Incident(=1originIn.Risk) 4.4 Analysing features by comparison with other ontologies (Stage 3) This step includes evaluating the compatibility of implicit knowledge within INTECO–CERT document with other formalized approaches. The semantic description of SIS has a great advantage that allows comparing the INTECO–CERT approach to risks with other related classifications and/or ontologies, in order to evaluate its soundness—specifically by ontological mapping with other preexistent risk hierarchies. This way analysis can be benefited from the comparison in order to: detect important absences in risks catalogue, isolate redundancies, explicitly reflect about particular risks as well as the possibility to propose other ontologies enrichment. It is worth to note that concept [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 924 916–932 FIG. 3. Risk class and its relationship with categories from Smith et al. [33]. mapping between these general categories and the INTECO–CERT ones provides insights useful to enrich the description of action classes related with them. Those indications could be incorporated in the final documentation. It is particularly interesting to consider its relationship with the following six general categories of information technology risk (according to Smith et al. [33]). The relationship among both categories is depicted in Figure 3. This relationship has to be understood as a set of incipient refinements of the ontology. Nevertheless, it is interesting to highlight some of them: •Malicious code and programs: The concept contains MalwareInfection. Thus, the ontology could be expanded by adding classes to prevent risks. It requires protection at the individual and system level. •Malicious hacking and intrusion: contains Hacking and InvasionAttack. However, INTECO classification also considers malicious hacking without intrusion (RefusalOf Service). •Fraud and deception: According to Smith et al. [33] various forms of attacks in the form of spoofing, masquerading or salami attacks have been used to damage privacy. Common electronic forms of fraud include phishing and credit card theft. The first type corresponds to SocialMalware and part of Hacking while the second one correspond to Social Engineering. In this case the ontology is more specific than the category from [33]. In Figure 3, dashed line indicates that: HackingFraudAndDeception≡⊥ •Misuse and sabotage: Closely related with Vulnerability. It also contains the class Policy Violation. The first class is one of the underspecified concepts in INTECO–CERT. The [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 931 916–932 [12] S. Fenz, G. Goluch, A. Ekelhart, B. Riedl and E. R. Weippl. Information security fortification by ontological mapping of the ISO/IEC 27001 standard. In Proceedings of the 13th IEEE Pacific Rim Int. Symp. Dependable Computing (PRDC 2007), pp. 381–388, 2007. [13] K. Geers. Strategic Cyber Security. CCD COE Publication, 2011. [14] R. J. Glushko and T. McGrath. Document Engineering - Analyzing and Designing Documents for Business Informatics and Web Services. MIT Press, 2008. [15] A. Herrero, M. Navarro, E. Corchado and V. Juli´an. RT-MOVICAB-IDS: addressing real-time intrusion detection. Future Generation Computer Systems,29, 250–261, 2013. [16] A. Herzog, N. Shahmehri and C. Duma. An ontology of information security. International Journal of Information Security and Privacy,1, 1–23, 2007. [17] Hanh H. Hoang, Jason J. Jung and Chi P. Tran. Ontology-based approaches for cross-enterprise collaboration: a literature review on semantic business process management. Enterprise Information Systems,8, 648–664. Taylor & Francis, 2014. [18] W. Kim, O-R Jeong, C. Kim and J. So. The dark side of the internet: Attacks, costs and responses. Information Syst.,36, 675–705, 2011. [19] J. C. Mace, S. Edward Parkin and A. P. A. van Moorsel. A collaborative ontology development tool for information security managers. In Proceedings of the 4th ACM Symp. Comp. Human Interaction for Management of Information Technology, CHIMIT 2010, p. 5, 2010. [20] Microsoft Inc. Enterprise Risk Management Models. Microsoft, 2010. [21] C. Minonne and G. Turner. Evaluating knowledge management performance. Electronic Journal of Knowledge Management,7, 535–662, 2010. [22] National Academy of Sciences and Royal Society. Cybersecurity Dilemmas: Technology, Policy, and Incentives: Summary of Discussions at the 2014 Raymond and Beverly Sackler U.S.- U.K. Scientific Forum. National Academic Press, 2015. [23] I. Nonaka and H. Takeuchi. The knowledge-creating company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press, 1995. [24] D. L. Olson and D. Wu. Information Security Management System for Microsoft’s Cloud Infrastructure. Springer Berlin Heidelberg, 2010. [25] J. Park, W. Cho and S. Rho. Evaluating ontology extraction tools using a comprehensive evaluation framework. Data & Knowledge Engineering,69, 1043–1061, 2010. [26] S. Edward Parkin, A. P. A. van Moorsel and R. Coles. An information security ontology incorporating human-behavioural implications. In Proceedings of the 2nd International Conference on Security of Information and Networks, SIN 2009, pp. 46–55, 2009. [27] T. S. Mendes Pereira and H. M. Dinis Santos. An ontology based approach to information security. In Proceedings of the 3rd International Conference Metadata and Semantic Research, pp. 183–192, 2009. [28] S. Sadvandi, N. Chapon and L. Pi`etre-Cambac´ed`es. Safety and security interdependencies in complex systems and sos: Challenges and perspectives. In Complex Systems Design & Management - Proceedings of the 2nd International Conference on Complex Systems Design & Management, pp. 229–241, 2011. [29] S. Sadvandi, N. Chapon and L. Pi`etre-Cambac´ed`es. Safety and security interdependencies in complex systems and sos: Challenges and perspectives. In Proceedings of the 2nd International Conference on Complex Systems Design & Management, CSDM, pp. 229–241, 2011. [30] A. Sarmah, S. M. Hazarika and S. Kumar Sinha. Security pattern lattice: A formal model to organize security patterns. In 19th International Workshop on Database and Expert Systems Applications (DEXA 2008),1-5 September 2008, Turin, Italy, pp. 292–296, 2008. [14:47 14/11/2016 jzw055.tex] Paper Size: a4 paper Job: JIGPAL Page: 932 916–932 [31] N. Shadbolt, K. O’Hara and L. Crow. The experimental evaluation of knowledge acquisition techniques and methods: history, problems and new directions. International Journal of Human-Computer Studies,51, 729–755, 1999. [32] Shawn Riley. Science of Cybersecurity Developing Scientific Foundations for the Operational Cybersecurity Ecosystem. Centre for Strategic Cyberspace + Security Science, 2015. [33] G. E. Smith, K. J. Watson, W. H. Baker and J. A. Pokorski II. A critical balance: Collaboration and security in the it-enabled supply chain. International Journal Production Research,45, 2595–2613, 2007. [34] S. W. Smith and E. H. Spafford. Grand challenges in information security: Process and output. IEEE Security & Privacy,2, 69–71, 2004. [35] M. C. Su´arez-Figueroa, A. G´omez-P´erez and M. Fern´andez-L´opez. The neon methodology for ontology engineering. In Ontology Engineering in a Networked World, pp. 9–34. Springer, Berlin, Heidelberg, 2012. [36] J. Díaz Vico, D. Fírvida Pereira and M. A. Lozano Merino. Identification and Reporting of Security Incidents for Strategic Operators. A Basic Guide for the Protection of Critical Infrastructures. NICT, 2014. [37] J. Díaz Vico, D. Fírvida Pereira and M. A. Lozano Merino. The Operator Console. A Basic Guide to Critical Infrastructure Protection. NICT, 2014.