text: COMMUNICATIONCOMMUNICATION INTER-OPERABILITYINTER-OPERABILITY

text: between between between systemsbetween systems people and organisationspeople and organisations

text: SYSTEMS ENGINEERINGSYSTEMS ENGINEERING

text: Reusability ReliabilityReusability Reliability SpecificationSpecification

text: Figure 1: Uses for ontologies

text: Figure 2: Visualisation of the definition of a taxonomy

text: Security “System”

text: Broad Intentions (What): Security Security Security - Realistic Objective Objective Objective - Achievable - Measurable - Relevant

text: Existing Standards Existing Standards

text: Behavioural Building Blocks: Functional Functional Functional Functional Functional Functional - New and/or existing Requirement Requirement Requirement Requirement Requirement Requirement features - Act together to meet the defined Objective(s) - May relate to more than one Objective

text: Detailed Detailed Detailed Detailed Detailed Detailed Requirement Requirement Requirement Requirement Requirement Requirement Implementation Details (How): Detailed Detailed Detailed Detailed Detailed Detailed - Atomic Requirement Requirement Requirement Requirement Requirement Requirement - Structured: - Preconditions - Stimulus - Response - Categorized: - Mandatory - Recommended - Optional

text: Perform TVRA

text: Specify Specify Specify Specify Operational Specify Detailed Operational Security Start Objectives Security Requirements End Functional Functional (User Requuirements Objectives Requirements (Operational & Requirements) Security) Stage 1 Stage 2 Stage 1 Stage 2 Stage 3

text: Process primary flow Process iteration flow TVRA information flow

text: class Requirements

text: «Requirement» «Objective» Priv acyRequirements

text: Obj ectiv es

text: «Requirement» «Requirement»

text: AssuranceRequirements SystemRequirements

text: Serv iceRequirements

text: «Requirement» «Requirement» «Requirement»

text: ReliabilityRequirements MaintainabilityRequirements Av ailabilityRequirements

text: Figure 5: Structure of requirements to be considered in network design

text: Table 1: Stakeholders (actors) in the NGN and their roles

text: Actor Role in resilience Has relationships with …

text: End user Receiver of service (push) Content provider Initiator of service (pull) Service provider Regulatory authority Manufacturer Content owner Provides content for distribution by the content Content provider provider Regulatory authority Content provider Distributes content Content owner  On demand End user  Broadcast/Multicast Service provider Service provider Provides services Service provider  On demand (Pull) End user  On event (Push) Content provider Regulatory authority Provides legal framework for such items as Service provider privacy, data protection, safety Content owner Content provider Manufacturer End user Law enforcement Recipient of data (LI/DR) Service provider authority Manufacturer Provides the software/hardware that enables the Regulatory authority network or service Service provider End user System integrator Brings content, software, hardware and service Content provider together to supply to the service provider Manufacturer Content provider

text: class Netw ork Simple Taxonomy

text: Netw ork technology

text: Access Core technology Interconnection technology technology

text: Wireless Wired Connection Connectionless oriented

text: Isochronous Asynchronous

text: Cellular Netw ork access Ad-hoc mode mode

text: SDH Ethernet

text: Access Method

text: OFDMA CDMA TDMA FDMA

text: Operational band

text: System bandw idth

text: Figure 6: Taxonomy of networks based on shared characteristic classification

text: class ThreatTree

text: Interception Manipulation Repudiation DenialOfServ ice

text: UnauthorisedAccess Masquerade Forgery InformationCorruption InfornationLoss

text: Figure 7: Taxonomy of threat

text: class ThreatThree2

text: Threat ThreatAgent

text: +Is performed by +Enacts 0..* 1..*

text: Automated Manual

text: Scripted Controlled Autonomous

text: Figure 8: Taxonomy of threat agent showing link to threat taxonomy

text: class Resilience

text: Resilience Degrading Measure Resilience Improv ing Measure

text: Figure 9: Resilience measures in the security domain

text: class Resilience

text: SystemResilience Av ailability

text: Figure 10: Resilience expression through metrics

text: DisastersDisasters Interaction ConflictsInteraction Conflicts Fault ManagementFault Management Supply ChainSupply Chain CooperationCooperation Integrity ManagementIntegrity Management DependabilityDependability ChangesChanges ThreatsThreats RiskRisk Trust ManagementTrust Management ManagementManagement Supply ChainSupply Chain MeansMeans Security ThreatsSecurity Threats AttacksAttacks GovernanceGovernance

text: ThreatsThreats ByBy SecuritySecurity AvailabilityAvailability ledled nabnab isEisE Cognitive andCognitive and confrontsconfronts Self-ManagementSelf-Management ReliabilityReliability isExpressedByisExpressedBy SafetySafety Metrics (ref)Metrics (ref) ResilienceResilience ConfidentialityConfidentiality isThisThrearea edByedBy tenten eedeed edByedBy isnisn IntegrityIntegrity MaintainabilityMaintainability DomainDomainDomain ThreatAgentThreatAgent

text: NetworkNetworkNetwork ServiceServiceService HumanHumanHumanHuman MachineMachineMachineMachine

text: CustomerCustomerCustomer BusinessBusinessBusiness NatureNatureNatureNature

text: Figure 11: High level overview of resilience ontology

text: Security ThreatsSecurity Threats

text: InterceptionInterception DenialOfServiceDenialOfService

text: ManipulationManipulation RepudiationRepudiation

text: Figure 12: Security Threats

text: ErrorsErrors FaultsFaultsFaults

text: Figure 13: Dependability Threats

text: Fault RemovalFault Removal Fault PreventionFault Prevention

text: Figure 14: Fault Management

text: AnalyzeAnalyze PlanPlan LearningLearning

text: Figure 15: Cognitive and Self-Management Management

text: Trust ManagementTrust Management

text: Figure 16: Trust Management instruments

text: Security PoliciesSecurity PoliciesSecurity Policies

text: Figure 17: Security instruments

text: isAttackedByisAttackedBy areConfrontedByareConfrontedBy

text: MeansMeans DomainDomain ThreatsThreats attackattack confrontconfront yy BB ss eded rmrm rmrm fofo fofo attackattack erer pp tt arePerarePer enen gg tAtA rearea hh TT

text: Figure 18: Resilience classes and relationships (without the intervention of class "Resilience")

text: NOTE: In this study, "Customer" is treated as a member of "Business" domain.

text: CustomerCustomer isis BusinessBusiness isis ICTICT isis isis isis ManufacturersManufacturers isis isis Software vendorsSoftware vendors Telecom OperatorsTelecom Operators UserUser Service providersService providers System IntegratorsSystem Integrators produce/usesproduce/uses produce/usesproduce/uses usesuses produce/usesproduce/uses usesuses Integrate/usesIntegrate/uses

text: ICT productsICT products manage/coordinatemanage/coordinate

text: belong tobelong to

text: Figure 19: Business domain

text: BusinessBusiness hashas ScopeScope isLargeisLarge isSmallisSmall Small MediumSmall Medium IndustryIndustry Enterprise (SME)Enterprise (SME) isAttackedByisAttackedBy isProtectedByisProtectedBy ThreatsThreats MeansMeans induceinduce RisksRisks havehave Severity LevelSeverity Level

text: Figure 20: Business scope and risks

text: ThreatsThreatsThreats induceinduceinduce leadToIfTrueleadToIfTrueleadToIfTrue RisksRisksRisks IncidentsIncidentsIncidents havehavehave affectaffectaffect areConfrontedByareConfrontedByareConfrontedBy Severity LevelSeverity Level Risk ManagementRisk ManagementRisk Management DomainDomainDomain

text: Figure 21: "Threats" and "Risks"

text: ICT productsICT products isis isis isis

text: HardwareHardware MiddlewareMiddleware SoftwareSoftware isis isis isis isis User DevicesUser Devices Network ElementsNetwork Elements isis ApplicationsApplications AlgorithmsAlgorithms

text: PlatformsPlatforms isis isis

text: RoutersRouters Access PointsAccess Points

text: Figure 22: ICT products

text: NOTE: In the area of business development where a large market can only be served by many different manufacturers or operators cooperation through standardisation is often used to allow a market to develop. In some cases regulatory constraints also encourage standardisation such as for use of licensed radio spectrum or to prevent markets being dominated to the detriment of customers by single corporations.

text: protectprotect BusinessBusiness isAttackedByisAttackedBy isAttackedByisAttackedBy isAttackedByisAttackedBy Supply ChainSupply Chain InteractionInteraction ChangesChanges AttacksAttacks ConflictsConflicts

text: areConfrontedByareConfrontedBy areConfrontedByareConfrontedBy Supply ChainSupply Chain Integrity MeansIntegrity Means CooperationCooperation protectprotect

text: Cooperation exists Cooperation exists NetworkNetwork among different not among different not only businessesonly businesses but also networks…but also networks…

text: Figure 23: "Business" domain "Threats" and "Means"

text: NMSNMS NMSNMS

text: EMSEMS EMSEMS EMSEMS

text: Network ElementsNetwork Elements Network Elements Network Elements Network Elements Network Elements Network Elements Network Elements Network Elements Network Elements with EMS with EMS

text: Figure 24: "Network" domain w.r.t. Operator organization levels

text: 802.16e802.16e802.16e Mobile WIMAXMobile WIMAXMobile WIMAX

text: EDGEEDGEEDGE HSPA+HSPA+HSPA+ EvolutionEvolutionEvolution

text: UMBUMBUMB LTELTELTE cf 802.20 cf 802.20 cf 802.20 E-UTRAE-UTRAE-UTRA

text: 802.11802.11 3.9G3.9G3.9G WiBROWiBRO a, b, g, h, na, b, g, h, n

text: IS-95CIS-95CIS-95CIS-95C CDMA2000CDMA2000CDMA2000CDMA2000 IS-95CIS-95CIS-95C CDMA2000CDMA2000CDMA2000 1xEV-DO1xEV-DO1xEV-DO1xEV-DO (Release 0, A, B)(Release 0, A, B)(Release 0, A, B)(Release 0, A, B) E-GPRSE-GPRSE-GPRS EDGEEDGEEDGE 3.5G3.5G3.5G WirelessWireless 3G3G3G HSDPAHSDPAHSDPAHSDPA (FDD, TDD)(FDD, TDD)(FDD, TDD)(FDD, TDD) WCDMAWCDMAWCDMA (FDD, TDD)(FDD, TDD)(FDD, TDD) HSUPAHSUPAHSUPAHSUPA (FDD, TDD)(FDD, TDD)(FDD, TDD)(FDD, TDD) TD-SCDMATD-SCDMATD-SCDMA LCR-TDDLCR-TDDLCR-TDD

text: 2G2G2G 2.5G2.5G2.5G

text: IS-95AIS-95AIS-95A IS-95BIS-95BIS-95B GSMGSMGSM HSCSDHSCSDHSCSD CDMACDMACDMA CDMACDMACDMA

text: IS-136IS-136IS-136 PDCPDCPDC GPRSGPRSGPRS iModeiModeiMode TDMATDMATDMA

text: NOTE: The terms 2G, 2.5G, 3G, 3.5G and 3.9G are in common use but only 2G and 3G are officially recognised. 2G refers to those cellular networks that use digital transmission and that replaced the first generation of analogue cellular technologies (i.e. the AMPS and TACS systems) introducing security features including terminal authentication and encryption of the speech channel. 3G refers to the succeeding generation offering wider bandwidth than necessary for solely voice communication. The interim generations such as 2.5G by introducing GPRS to the GSM model moved from voice centric cellular communication to a model supporting data transmission. The interim extensions of 3G have in like manner extended the data carrying capacity of cellular networks by extensions of frequency band, channel bandwidth, and by extending the data encoding of bits per symbol increased the available data transmission rate.

text: Figure 25: "Wireless" access technologies

text: enablesenables WirelineWireline consistsOfconsistsOf HeterogeneousHeterogeneous consistsOfconsistsOf NetworksNetworks isis BackhaulBackhaul consistsOfconsistsOf consistsOfconsistsOf EthernetEthernet isis WirelessWireless WirelessWireless WIMAXWIMAX isis isis CDMA (UMTS)CDMA (UMTS) TDMA (GSM)TDMA (GSM)

text: Figure 26: "Heterogeneous Networks"

text: isAttackedByisAttackedBy isAttackedByisAttackedBy InteractionInteraction ChangesChanges ConflictsConflicts areConfrontedByareConfrontedBy areConfrontedByareConfrontedBy areConfrontedByareConfrontedBy

text: Cognitive andCognitive and GovernanceGovernance CooperationCooperation Self-ManagementSelf-Management

text: isAchievedByisAchievedBy usesuses usesuses usesuses

text: Policies Policies Context Context Profiles Profiles

text: Figure 27: "Network" domain "Threats" and "Means"

text: Learning Learning Policies Policies feedsfeeds feedsfeeds usesuses feedsfeeds usesuses Context Context Monitor Monitor Monitor ExecuteExecuteExecute

text: usesuses feedsfeeds ordersorders Profiles Profiles feedsfeeds AnalyzeAnalyzeAnalyze PlanPlanPlan

text: ServiceService hashas Quality Levels Quality Levels

text: isAttackedByisAttackedBy isAttackedByisAttackedBy isAttackedByisAttackedBy

text: DependabilityDependability Security ThreatsSecurity Threats ChangesChanges ThreatsThreats

text: areConfrontedByareConfrontedBy areConfrontedByareConfrontedBy areConfrontedByareConfrontedBy

text: isAchievedByisAchievedBy Cognitive andCognitive and SecuritySecurity Fault Management Fault Management Self-Management Self-Management Figure 29: "Service" domain "Threats" and "Means" "Service" domain has mainly three kinds of "Threats", namely "Security Threats", "Dependability Threats" and "Changes". The first two are depicted in Figures 12 and 13. "Security Threats" are confronted by "Security", using the instruments described in Figure 17. "Dependability Threats" are confronted by "Fault Management", which is depicted in Figure 14. "Changes" are confronted by "Cognitive and Self-Management", which is depicted in Figure 15 and achieves in an automatic way "Fault Management".

text: NOTE: The material presented in this clause has close relationships with the work published by ETSI in the domain of User Profile Management (UPM) and in the domain of Universal Communications Identifier (UCI).

text: 6.5.1.1 User Profile

text: User device Profile

text: Access Point Profile

text: User device_ID Access Point ID

text: User Profile

text: ServiceService QualityLevel Service QualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevel

text: User_ID ServiceIDServiceID QualityLevelQualityLevelIDQualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevel TRXProfile ServiceID QualityLevelIDQualityLevelIDQualityLevelIDQualityLevelQualityLevelQualityLevel TRXContext ServiceName QualityLevelIDQualityLevelIDQualityLevelIDQualityLevelID TRXContext NetworkOperator_ID ServiceNameServiceName QualityLevelID Profile type

text: UserClass TRXProfile TRX Profile

text: TRXProfileTRXProfile TRX ID UserClassID TRX ID TRX ID le UserClassName TRX ID Frequency Frequency fi le Frequency

text: Frequency Frequency

text: FreqBandFrequencyFrequencyFrequencyFrequency fi fi FreqBand Service QualityLevel Frequency ro FreqBandFreqBand ServiceServiceService QualityLevel o ServiceIDServiceService QualityLevel FreqBandFreqBandFreqBand o P ServiceIDServiceService QualityLevelID FreqBandFreqBand ServiceNameServiceIDService QualityLevelID FreqBand ServiceName QualityLevelID r RAT ServiceName RAT rPr rPr RATRAT RAT ID RAT ID se se RAT ID se RAT name User Preferences RAT ID U RAT name U RAT nameRAT name U l Utility Values per Profile type, Frequency Frequency Service , QoS level FrequencyFrequencyFrequency FreqBandFrequencyFrequency FreqBand

text: FreqBandFreqBandFreqBand FreqBandFreqBandFreqBand

text: 6.5.1.2 User device Profile

text: 6.5.1.3 Access Point Profile

text: 6.5.2.1 User device Status

text: Access Point Context

text: Access Point ID Access Point Config

text: User device Status TRX Context Access Point ID

text: User device_ID TRX ID User_ID Aggregate Load TRXConfig Operator_ID

text: User Class

text: Service QualityLevel TRX Config

text: UserClassName ServiceID

text: QualityLevelID TRX ID ServiceName

text: ServiceService QualityLevel Allocated Uplink BW

text: Service QualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevel

text: ServiceIDServiceID QualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevelQualityLevel Allocated DownlinkBW

text: ServiceID QualityLevelIDQualityLevelIDQualityLevelIDQualityLevelIDQualityLevelQualityLevelQualityLevel ServiceName QualityLevelIDQualityLevelIDQualityLevelIDQualityLevelID UserClassLoad CoverageArea ServiceNameServiceName QualityLevelID

text: UserClass Frequency FreqBand

text: TRXConfig UserClassID

text: TRX ID UserClassName RAT

text: AllocatedDownlinkBW QualityLevelLoad RAT ID AllocatedUplinkBW QualityLevelLoadQualityLevelLoad RAT name

text: Frequency FreqBand QualityLevel Frequency

text: QualityLevelIDQualityLevelID QualityLevelID RAT FreqBand

text: Frequency Frequency User

text: RAT ID Frequency UserUserUserUserUser FreqBand UserIDUserUser

text: RAT name FreqBandFreqBand UserIDUserIDUserIDUserIDUserIDUser xGeographicalCoordinatexGeographicalCoordinatexGeographicalCoordinateUserIDUserID Service xGeographicalCoordinatexGeographicalCoordinatexGeographicalCoordinateUserID ServiceService yGeographicalCoordinateyGeographicalCoordinateyGeographicalCoordinatexGeographicalCoordinatexGeographicalCoordinate ServiceID Service yGeographicalCoordinateyGeographicalCoordinateyGeographicalCoordinatexGeographicalCoordinate ServiceIDServiceID ServiceServiceService QualityLevel yGeographicalCoordinateyGeographicalCoordinate ServiceName ServiceIDServiceServiceService QualityLevelQualityLevel yGeographicalCoordinate ServiceNameServiceName

text: ServiceIDServiceIDServiceService QualityLevelID QualityLevelIDQualityLevelID QualityLevelQualityLevel ServiceNameServiceName QualityLevel

text: ServiceName QualityLevelID QualityLevelID QualityLevelID

text: 6.5.2.2 Access Point Context

text: 6.5.2.3 Access Point Configuration

text: 6.5.3.1 Business level entries

text: 6.5.3.2 High-level policies (associations)

text: Application ID Application Name

text: User Class

text: User Class ID User Class Name

text: Quality Level

text: Quality Level ID Quality Level Name

text: Quality Level Parameters

text: Parameter ID Parameter Name Parameter reference values

text: 6.5.3.3 Configuration Policies

text: CompoundPolicyCondition or

text: PolicyCondition PolicyCondition

text: PolicyExpression: e.g. : equals, greater, less, lessequal, greaterequal etc

text: PolicyConfig PolicyArgument

text: TRX ID (optional)

text: RAT mentment LogicalExpression: e.g. : and, or, xor

text: Frequency etc Priority

text: Service ID Service Name

text: UserClass Location Timezone

text: Quality Level UserClassID LocationID StartTime QualityLevelID UserClassName LocationName EndTime Cost

text: NOTE: The Taxonomies & Controlled Vocabularies Special Interest Group (SIG) is a networking and educational forum for those in the indexing profession who are involved in creating or editing taxonomies, thesauri, or controlled vocabularies used for indexing. The Taxonomies & Controlled Vocabularies SIG is an affiliate of the American Society for Indexing. [i.14] G.C. Bowker and S.L. Star. Sorting things out: classification and its consequences. Cambridge, MA: MIT Press, 1999. Role of categories and standards in shaping the modern world.

text: NOTE: Source: United Nations International Strategy for Disaster Reduction; Available at: http://www.unisdr.org/ residual risk: risk remaining after risk treatment resilience: concept associated with resisting to the loss of capacity of a failure or foreseen overload, optimizing the availability and quality of service of telecommunications systems and support resources enabling a system to return to a previous normal condition. risk: potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization threat: potential cause of an incident that may result in harm to a system or organization

text: NOTE 1: A threat consists of an asset, a threat agent and an adverse action of that threat agent on that asset. NOTE 2: A Threat is enacted by a Threat Agent, and may lead to an Unwanted Incident breaking certain pre-defined security objectives. threat agent: an entity that can adversely act on an asset unwanted incident: incident such as loss of confidentiality, integrity and/or availability

text: NOTE: A Vulnerability, consistent with the definition given in ISO/IEC 13335, is modelled as the combination of a Weakness that can be exploited by one or more Threats.

text: Table C.1: Classification examples from biology

text: Taxon Example – Modern man Example – domestic horse

text: Kingdom Animalia Animals Animalia Animals Phylum Chordata (subphylum Animals with a Chordata (subphylum Animals with a Vertebrata) backbone Vertebrata) backbone Class Mammalia Mammals Mammalia Mammals Order Primates Primates Perissodactyla Odd-toed ungulates Family Hominidae Hominids Equidae Horse-like mammals Genus Homo Humans Equuus Horses and their kin Species Homo sapiens. Modern human Equus ferus caballus Domestic horse

text: NOTE: The references are shown in annex A that came out of a simple search. In [i.3], the main definitions relating to dependability and security are first given. Dependability is examined with regard to such attributes as reliability, availability, safety, integrity, maintainability, etc., while security brings in concerns for confidentiality. After these basic definitions, the threats to dependability and security (faults, errors, failures), their attributes, and the means for their achievement (fault prevention, fault tolerance, fault removal, fault forecasting) are addressed. The major part of this analysis is given in the form of ontologies. These dependability and security ontologies intend to explicate a set of general concepts, of relevance across a wide range of situations and, therefore, helping communication and cooperation among a number of scientific and technical communities, including ones that are concentrating on particular types of system, of system failures, or of causes of system failures. In this concept, the defined ontologies are also concerning resilience, since dependability and security are prerequisites for resilience. The major new contributions of [i.3] with regard to existing literature, as summarised by the authors, are:  The relationship between dependability and security is clarified.

identifier: Ontology and taxonomies of resilience

nummer: ontology-taxonomies

title: Ontology and taxonomies of resilience

text: Ontology and taxonomies of resilience I Template for further reports and deliverables

text: Contributors to this report

text: Authors of the report:  Panagiotis T. Vlacheas – University of Piraeus Research Centre  Vera Stavroulaki – University of Piraeus Research Centre  Panagiotis Demestichas – University of Piraeus Research Centre  Scott Cadzow – Cadzow Communications Consulting Ltd

text:  Slawomir Gorniak – ENISA  Demosthenes Ikonomou – ENISA

text: Acknowledgements

text: ENISA would like to thank the contributors and reviewers of this study.

text: Ontology and taxonomies of resilience II

text: About ENISA

text: The European Network and Information Security Agency (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

text: Contact details

text: For contacting ENISA or for general enquiries on resilience, please use the following details:  E-mail: resilience@enisa.europa.eu  Internet: http://www.enisa.europa.eu

text: For questions related to this paper, please use the following details:  E-mail: sta@enisa.europa.eu

text: Legal notice

text: Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA

text: Regulation (EC) No 460/2004

text: as lastly amended by

text: Regulation (EU) No 580/2011

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. Reproduction is authorised provided the source is acknowledged. © European Network and Information Security Agency (ENISA), 2011

text: Ontology and taxonomies of resilience IV

text: Ontology and taxonomies of resilience 1

text: 1 Executive Summary

text: The present report provides an ontology of resilience alongside and embedding a taxonomy of resilience. Telecommunications networks have been extended from the original circuit switched model where reliability and availability were often simply stated as five nines, i.e. uptime should be 99.999% over a year and availability was to give service at five-nines to all subscribed users. How big the system had to be was most often simply determined using Erlang's traffic modelling taking account of call attempts per hour and call hold time. As networks have become increasingly more complex and more critical to business their reliability and resilience have themselves become more critical to understand and engineer into the network design. The present report introduces two tools for understanding resilience as a network design target and the output of those tools when applied to resilience. The tools introduced are classification using taxonomy, and relationship modelling using ontology with taxonomy at its core. The following key elements that are addressed by the ontology design presented the document:  Application at multiple implementation levels (hardware, middleware, software), network layers (network, application layers) on both the network and the user side.  Application to the aggregation of cloud computing, real time detection and diagnosis systems, sensor networks, future wireless networks and supply chain integrity.  Extension of means to derive definitions in standardization.

text:  Identification of the use of metrics for resilience measurement and compliance.

text: The ontology presented in this document offers an open, interoperable and scalable framework, which is intended to lead to further development in standardization. The document addresses ontology and taxonomy as methods that extend the role of standards in complex areas by allowing more complex scenarios to be addressed than are normally considered by standardisation. Resilience falls into this class of complex scenarios as the solution set covers many different technologies and strategies than many simpler though complex protocols. The target audience consists of specialised audience of stakeholders involved in resilience and the standardisation bodies that may contribute to resilience solutions. This report was prepared for ENISA by a consortium formed by Cadzow Communications Consulting Ltd. (UK) and the University of Piraeus Research Center (Greece) under the leadership and guidance of the "Resilience of public Communication Networks and Services" group at ENISA.

text: Ontology and taxonomies of resilience 2

text: 2 Introduction

text: The ENISA report on gaps in standardisation related to resilience of communication networks [3] stated that there is no consistent taxonomy for cyber security that identifies the role of resilience. The purpose of the present document is to address this gap for resilience. The document defines an ontology of resilience in order to address a behavioural dimension of the topic with a taxonomy of resilience, network and security terms at its core. In was shown in [3] that existing standards in the field of networks and network security have so far only addressed resilience indirectly if at all and thus without detail definition of the role of resilience as an objective in making networks secure (in the meaning of availability from the conventional Confidentiality Integrity Availability (CIA) paradigm). However whilst in the CIA paradigm the success of a measure is often directly measurable and thus a set of metrics exist for comparison of 2 or more approaches, for say integrity verification, the existence of such metrics in resilience is mostly lacking. As such metrics play a significant role in giving meaning to any comparison of system resilience the identification of them is addressed within the ontology developed and proposed in the present document. The primary purpose of the ontology and its contained taxonomy defined in this document is to use the results as the basis of definitions and processes in future work. The current approach to definition in most Standards Development Organisations (SDOs) is to separate definition from use and assume terms are always understood. For example the term threat is defined as "potential cause of an incident that may result in harm to a system or organization" but this approach doesn't put threat into context whereas using the approach of taxonomy and ontology introduces the additional contextual dimensions, in other words the additional concepts that a threat is enacted by a threat agent and leads to attack on the system objectives. Ultimately the intent is to use the ontology within standards that have to be followed for all network based resilience measures. This is not to state that ontologies are not used in development of standards or of networks although it is hard to find explicit use of the terms in existing standards. In practice it can be shown that many existing standards, particularly in the security domain, tend towards ontologies in their structure (but not in their terminology). Before defining an ontology or a taxonomy it is essential to define what they are and why they are of benefit. Supporting the definitions and rationale given in this document a complete analysis can be found in [14] that also presents a methodology for developing and evaluating ontologies (a summary of research in the field is given in Annex D). Where stakeholders, i.e. the people, organisations, and software systems, are required to communicate among themselves to achieve some specific objective they often misinterpret the same subject matter due to a desire or imperative to translate to their personal context. The misinterpretation leads to lack of a shared understanding that then leads to a number of unwanted consequences that include:  poor communication between these people and within their organisations,

text: Ontology and taxonomies of resilience 3

text:  difficulties when identifying requirements and defining a specification of an IT system,

text:  lack of interoperability, reliability, re-use and sharing capabilities, which lead to much wasted effort (in common terminology leading to endless cycles of re-inventing the wheel) because of different methods, sector specific terminology (jargon) and tools.

text: Without shared understanding acting as a unifying framework for the different viewpoints the problems that arise from misunderstanding will continue, and exaggerate conceptual and terminological confusion. Ontology is the term used to refer to the science and methods of developing a shared understanding of some domain of interest which may be used as a unifying framework to solve the above problems. An ontology entails or embodies a set of concepts (e.g. entities, attributes, and processes), their definitions and their interrelationships with respect to a given domain. This is referred to as a conceptualisation and may be implicit or explicit, depending on whether a subjective or objective analysis is undertaken. Note however that the aims of standardisation and of both, ontologies and taxonomies, is the same even if the practice is different. To this end a standard defines only the minimum requirements for a product or service that implements it to work safely and dependably with other products implementing the same (or associated) standards, i.e. if 2 mobile phones each implement the GSM standards they will be able to communicate with a standards compliant GSM base station and make calls to each other. The key matter than distinguishes those areas where taxonomy and ontology will give gain over conventional approaches to standardisation is where complex multi-factor environments are brought together to achieve new objectives. This is the case for resilience where conventional requirements for availability do not address resilience directly but address the more readily understood areas of reliability, maintainability and availability discretely rather than as they would by consideration using ontology: In combination. The following quote taken from the Shared Re-usable Knowledge Bases (SRKB) electronic mailing list summarises what an ontology is and the various forms and contexts it arises in.

text: QUOTE: "Ontologies are agreements about shared conceptualizations. Shared conceptualizations include conceptual frameworks for modelling domain knowledge; content-specific protocols for communication among interoperating agents; and agreements about the representation of particular domain theories. In the knowledge sharing context, ontologies are specified in the form of definitions of representational vocabulary. A very simple case would be a type hierarchy, specifying classes and their subsumption relationships. Relational database schemata also serve as ontologies by specifying the relations that can exist in some shared database and the integrity constraints that must hold for them."

text: Ontology and taxonomies of resilience 4

text: In [14], the domains or subject areas for use of ontologies is subdivided into the following categories:  Communication:

text: - Ontologies enable shared understanding and communication "between people with different needs and viewpoints arising from their particular contexts" [14].  Interoperability:

text: - Many applications of ontologies address interoperability in which different users need to exchange data either in a practical deployment environment or in development between different software tools. A major theme for the use of ontologies in domains such as enterprise modelling and multiagent architectures is the creation of an integrating environment for different software tools.  Systems engineering:

text: - Specification:  In the specification of software systems, ontologies facilitate the process of identifying the requirements of the system and understanding the relationships among the components of the system among distributed teams of designers working in different domains and provide a declarative specification of a software system, which allows to reason about what the system is designed for, rather than how the system supports this functionality.

text: - Reliability:  Ontologies enable the use of (semi-)automated consistency checking of the software system with respect to the declarative specification and can be used to make explicit the various assumptions made by different components of a software system, facilitating their integration.

text: - Reusability:  Ontologies in order to be effective must also support reusability, so that the modules can be imported and exported among different software systems and are used to provide a framework for determining which aspects of an ontology are reusable between different domains and tasks. To be useful, these ontologies must be customisable through extension, both to the class of problems and the class of users, allowing the incorporation of new classes of constraints and the specialisation of concepts and constraints for a particular problem.

text: Ontology and taxonomies of resilience 5

text: Taxonomies have a close relationship to ontologies. Taxonomy is derived from 2 Greek words: taxis, meaning the arrangement or ordering of things; and, nomos meaning anything assigned a name, and the usage addressed by the thing. Taking an almost literal interpretation of this suggests that taxonomies give structure to the naming of things and this is clearly the approach used in biology and similar sciences. It has been suggested that there are three characteristics that define a taxonomy:  A taxonomy is a form of classification scheme

text: - Classification schemes are designed to group related things together and to define the relationship these things have to each other.  Taxonomies are semantic

text: - Taxonomies provide a vocabulary to describe knowledge and information assets. The vocabulary must be controlled to ensure that each entry in the taxonomy is unambiguous and to also ensure that alternate or less precise terms are excluded.  A taxonomy is a kind of knowledge map

text: - A user of the taxonomy should immediately have a grasp of the overall structure of the knowledge domain covered by the taxonomy. The taxonomy should be comprehensive, predictable and easy to navigate.

text: Ontology and taxonomies of resilience 6

text: In many instances a taxonomy is considered 2-dimensional (which could be presented as a simple table) whereas ontologies are often considered as 3-dimensional although by using a taxonomy in an ontology as it proposed in this document the boundary between taxonomy and ontology is blurred.

text: Ontology and taxonomies of resilience 7

text: 3 An ontology for defining resilience requirements in network design

text: The design of a network has to balance a number of competing requirements. There are a number of models that can be presented to express requirements but the one that is

text: prevalent in the security standards work presented at ETSI is that found in TR 187 011 and in

text: TS 102 165-1 in which requirements are derived from objectives as shown in figure 1 (taken from TR 187 011).

text: Figure 3: Security objectives and requirements

text: This hierarchy of objectives and requirements is related to the Threat Vulnerability Risk Analysis approach to security design shown in figure 2 (taken from TR 187 011). However it should be noted that by some additional modelling it can be shown that this approach to requirements specification is ontological in structure:  An objective is satisfied by a functional requirement(s), the corollary or ontological reverse relationship is that a functional requirement contributes to the satisfaction of one or several objectives

text: Ontology and taxonomies of resilience 8

text:  A functional requirement is satisfied through one or several detailed requirements, corollary or ontological reverse relationship is that a detailed requirement contributes to the satisfaction of one or several functional requirements

text: Figure 4: Standards development process including security aspects

text: The set of requirements that is to be considered in networks covers a broad area with many dependencies between requirements classes.

text: Ontology and taxonomies of resilience 9

text: The addition of a specific class of "Resilience Requirements" which are themselves a composition of requirements for reliability, maintainability and availability brings the concept of resilience into the network design. Related to this is a requirement to have resilience objectives for the system that are themselves realistic, achievable, measurable and relevant as defined in ETSI TR 187 011 []. Underlying the introduction of resilience is the introduction of requirements that relate directly to the 3 main metrics considered in [3] for the test and

text: Ontology and taxonomies of resilience 10

text: measurement of resilience: Reliability; Maintainability; and, Availability. Availability is already explicitly described in the ontology for cyber-security described by ITU-T and by ETSI in TR 187 010 []. The characteristics of resilience have been explored in earlier work in ENISA and there is a degree of uncertainty over the point at which a system maintains availability and reliability but fails to be resilient. Resilience can be perceived as a measure of ability to work through stress and recover to the same initial condition when the stress is removed. In telecommunications and information processing networks where the input conditions typically tend towards chaotic identifying the stable point to return to after a stress event has a degree of uncertainty. As such resilience is not a very straightforward item to define by requirements. Using the model for specifying detail requirements in TR 187 011 of preconditions, stimulus and response the precondition of resilience is the steady state, the stimulus is the load that leads to stress, and the response is (eventually) a return to the steady state. The problem from a requirements point of view is that if the initial response to stress is to stop but the eventual response is to restart in the same initial state this could be argued to be "resilient" but it is not as it is more correctly simply recoverable. A truly resilient network has to maintain operation throughout the stress event (i.e. availability should not be degraded) and also return to a state as if unaffected by the stress when the stress is removed.

text: EXAMPLE: A longbow has to be stressed to perform and as such the material of the bow has to be designed to be sufficiently rigid such that when the bowstring is drawn the bow itself does not fold but has to "give" at the ends of the bow to allow the bowstring to be extended. When the arrow is released the bow returns to its initial resting state. A failure of this stress-recovery cycle would break the longbow so the entire bow as a system has to be designed to be resilient.

text: Ontology and taxonomies of resilience 11

text: 4 Stakeholder model in network resilience

text: In the modelling of the ontology the key stakeholders in network resilience are identified. The stakeholder model for resilience is similar to that in development at ETSI TISPAN for TS 187

text: 001 but extended to the business domain.

text: The stakeholder model for resilience therefore covers the same actors as for conventional network design. However the role of the stakeholders in managing network resilience is somewhat different from those considered in conventional network design.

text: Ontology and taxonomies of resilience 12

text: 5 Taxonomy of resilience

text: A taxonomy that allows for classification of a network technology may for example state that TETRA is an example of a 25KHZ bandwidth, 400MHz band, TDMA cellular technology operating as a wireless access network. Unfortunately as TETRA can also operate at 900MHz it would be necessary for a taxonomy to distinguish the two modes as separate types. A taxonomy of networks where the classifications (taxoms) are based on shared characteristics is shown in part in Figure 6. The aim of the taxonomy is to ensure that there is no ambiguity in classification. In modern ICT systems however a single entity may have multiple characteristics in parallel. This is best evidenced in a smartphone that holds characteristics of a cellular phone but also contains characteristics of a personal computer. The classification schema of Figure 6 may lead to a single entity such as a smartphone having multiple entries which is potentially unsafe as it could lead to ambiguity.

text: Ontology and taxonomies of resilience 13

text: If we take the model presented by Lacy in [8] the relationships in this simple hierarchical taxonomy should represent "is a" relationships, so from the model given in Figure 6 we should be able to state that "CDMA is an Access Method is a Cellular is a Wireless is an Access Technology is a Network Technology" which doesn’t in fact make a lot of sense when written back in this form although it could be argued that the diagram itself is meaningful. So for use

text: Ontology and taxonomies of resilience 14

text: in a semantic network (such as advanced telecommunications) that uses taxonomies and ontologies illustrative approaches such as in Figure 6 may need to be re-thought to be more amenable to machine processing. The alternative to a shared characteristic classification of an evolutionary classification scheme is similar to the one adopted in Figure 7 for the countermeasures and threat modelling in the security domain.

text: Here we can state that "Forgery is a Manipulation" and of course "Manipulation is a Threat" (more correctly the "is a" relationship should be seen as "is a specialisation of", allowing the reverse relationship to be written as "is a generalisation of"). Another example of describing threat agents is given in Figure 8 although in this case each leaf requires additional definition text to make it clear why for automated threat agents there is a distinction between "scripted", "controlled" and "autonomous".

text: Ontology and taxonomies of resilience 15

text: Resilience can be expressed in the security model as shown in Figure 9. In this case 2 aspects of resilience are shown:  Resilience degrading measure is a specialisation of a threat agent; and,

text:  Resilience improving measure is a specialisation of a security countermeasure.

text: Ontology and taxonomies of resilience 16

text: When expressed as a threat agent the resilience degrading measures may be considered as leading to a denial of service therefore the threat family attacked by the threat agent is denial of service. In general however resilience is not a tangible asset in that providing resilience to a system does not of itself guarantee a working model that the system will be invulnerable to denial of service. If this is considered in the manner ENISA's report [] and the more recent work on metrics there is a requirement to be able to express resilience by those system elements we can control. This is shown in Figure 10.

text: Ontology and taxonomies of resilience 17

text: To move this towards the grammar favoured by Lacy in [8] we may state:  System resilience is expressed by the combination of the system's availability, reliability and maintainability.

text: This allows further expression of how to give assurance of availability, of reliability and of maintainability. The further development of the taxonomy is moved into the development of the ontology in the next clause where the ontology described so far is used in the root of the definitions and resulting associations.

text: Ontology and taxonomies of resilience 18

text: 6 Ontology of resilience 6.1 Towards an ontology for network resilience

text: As identified in Annex D, there is a need for an ontology which will address the end-to-end resilience, considering a heterogeneous mix of different implementation levels, network technologies, human factors, and application domains. Figure 11 shows the model for the end-to-end resilience ontology that is further decomposed and examined in the remainder of this clause. "Resilience" is the main class located at the centre of the ontology and is considered as the root for this analysis. It has direct relationships with the classes "ThreatAgent", "Domain", "Metrics", "Threats" and "Means" where all the relationships are defined based on the root, i.e. network resilience. "Threats" are what "Resilience" confronts, namely the potential attacks against network assets. In this concept, "confronts" is the relationship, while the inverse relationship may be defined as "are confronted by". The "Threats" class has also its subclasses. Therefore, there are "Security Threats", "Dependability Threats", "Disasters" as physical threats caused by natural events, "Interaction Conflicts" as implicit threats due to incompatibilities/conflicts among interacting network assets, "Changes" with respect to threats due to dynamic conditions and "Supply Chain Attacks" (attacks being performed throughout the supply chain, until the delivery of the equipment or service). A "ThreatAgent" denotes the entity that threatens "Resilience", namely the agent who performs the "Threats". In this concept, "is threatened by" is the relationship, while the inverse relationship is "threatens". A "ThreatAgent" may be a "Human", a "Machine" or the "Nature" itself. "Domain" is by which "Resilience" is required, namely the domain where resilience applies. In this concept, "is needed by" may be considered as the relationship and "needs" the inverse relationship. Four domains can be distinguished in order to have an end-2-end consideration of resilience, namely "Network", "Service", "Customer" and "Business". "Metrics" are the attributes by which "Resilience" is expressed, since network resilience is an integrating concept that encompasses such attributes. So, "is expressed by" is the relationship and "express" the inverse relationship. There are mainly six resilience metrics [i.3], namely "Availability", "Reliability", "Safety", "Confidentiality", "Integrity" and "Maintainability". Confidentiality has a great prominence especially when addressing security, in the sense that it represents the absence of unauthorized disclosure of information. In general, security is considered as a concurrent composite of confidentiality, integrity and availability. The "Means" class represents the means which have been developed to attain the various resilience metrics and intend to either eliminate threats or fix vulnerabilities. Therefore, "is enabled by" is the relationship and "enables" the inverse relationship. In this ontology, the resilience means are kept at a high level representing management functions, since one of the objectives, as also found out in Annex D, is to target an audience consisting of resilience

text: Ontology and taxonomies of resilience 19

text: stakeholders and mainly industry stakeholders. Of course, these management functions manage some instruments/tools to which we will refer later. Resilience "Means" consist of "Fault Management", "Trust Management", "Supply Chain Integrity Management", "Cooperation" when "Interaction Conflicts" exist, "Risk Management", "Governance", "Security" in terms of security standards and tools, "Cognitive and Self-Management".

text: Each class is connected to its subclasses with an "is" relationship. Inverse relationship may be "is a kind of". For simplicity, these relationships are only referred to when absolutely necessary.

text: Some of the classes existing in Figure 11 are analysed in more detail in succeeding clauses. The relationship and inverse relationship remain "is" and "is a kind of", respectively.

text: "Security threats" consist of "Interception", "Manipulation", "Repudiation" and "Denial Of Service", to which we have also referred to in subsection 3.3 and which are depicted in Figure 12.

text: Ontology and taxonomies of resilience 20

text: "Dependability threats" include "Failures", "Errors" and "Faults" as analysed in [i.3] and can be found in Figure 13. "Supply Chain Attacks" are presented in the ENISA study [4] and "Disasters" in the ENISA study [3]. DependabilityDependabilityDependability ThreatsThreatsThreats

text: "Supply Chain Integrity Management" is presented in the ENISA study [4]. "Fault Management" is analysed in [i.3] and consists of "Fault Forecasting", "Fault Removal", "Fault Prevention" and "Fault Tolerance" as depicted in Figure 14. Fault ManagementFault Management Fault ForecastingFault Forecasting Fault ToleranceFault Tolerance

text: "Cognitive and Self-Management" corresponds to the well-known MAPE cycle [15]-[17], namely Monitor, Analyse, Plan, Execute enabled with Learning (Knowledge) capabilities, and is depicted in Figure 15. Cognitive andCognitive and Self-ManagementSelf-Management MonitorMonitor ExecuteExecute

text: The "Means" are supported by specific instruments, which make their effectiveness possible. The relationship between "Means" and "Instruments" is "use" and the inverse relationship "are used by". Therefore, the "Trust Management" uses mainly "Certification" (Figure 16).

text: Ontology and taxonomies of resilience 21

text: "Security" requires mechanisms, services and policies according to [i.12]. Generic security services include authentication, authorization, non-repudiation, privacy, intrusion-tolerance, etc., while security mechanisms include specific techniques like encryption, digital signatures, traffic padding, routing control, access control, firewall, redundancy, etc." [i.12] Security policies define high level of assumptions and rules, such as the Bell-LaPadula confidentiality model in military systems and the Clark-Wilson integrity model in commercial systems. "Security" instruments are depicted in Figure 17. SecuritySecuritySecurity usesuses usesuses SecuritySecuritySecurity Security ServicesSecurity Services usesuses MechanismsMechanismsMechanisms

text: "Cognitive and Self-Management" uses "Policies", "Context", "Profiles", which are analysed later. At this point, the definition of relationships and inverse relationships of the several classes without the intervention of the root class "Resilience" is shown (the relationships are shown in bold). Therefore:  "Domain" is attacked by "Threats" (relationship) - "Threats" attack "Domain" (inverse relationship).  "Means" confront "Threats" (relationship) - "Threats" are confronted by "Means" (inverse relationship)  "Means" are attacked by "Threats" (relationship) - "Threats" attack "Means" (inverse relationship).  "ThreatAgent" performs "Threats" (relationship) - "Threats" are performed by "ThreatAgent" (inverse relationship).  "Domain" is protected by "Means" (relationship) - "Means" protect "Domain" (inverse relationship).

text: Ontology and taxonomies of resilience 22

text: The previous classes and relationships are depicted in Figure 18.

text: Using the classes and relationships defined so far, an attempt will be made to combine them and see how they interact in an end-to-end resilience concept. By this way, interactions can be built such as the following examples:  "Cognitive and Self-Management" confronts "changes" (e.g. context changes, traffic changes, KPI degradation) which are performed by "Human" (e.g. mobility, profile change) and which ("changes") attack "Network".

text:  "Risk Management" confronts "changes" (e.g. outstanding business plans) which are performed by "Human" (e.g. competition) and which ("changes") attack "Business".

text:  "Security Mechanisms" (e.g. protocols, DNSSEC) confronts "Security threats" which are performed by "Human" (e.g. malicious user) and which ("Security threats") threaten "Service" (e.g. DNS application) BUT "Security Mechanisms" (e.g. protocols, DNSSEC) are threatened by other "Security threats".

text: In order to build all these interactions, an analysis per domain will be followed.

text: 6.2 Ontological examination of the Business Domain

text: Ontology and taxonomies of resilience 23

text: First, the definition of business with respect to network resilience is investigated. As depicted in Figure 19, a business could be one of "ICT manufacturers", "Software vendors", "Service providers", "System integrators" or "Telecom operators". This set comprises the target audience of the derived resilience ontology, since they are the main stakeholders affected by resilience. Furthermore, the "Customer" domain may be a business and "User" is an instantiation of "Customer". The relationships of these businesses with the "ICT products" and "Network" domain are also presented.

text: Ontology and taxonomies of resilience 24

text: A business may have either a large or a small/medium scope (Figure 20). By this criterion, it may be distinguished to "Industry" and "Small Medium Enterprises" (SME). The relative impact of an attack will always depend to an extent on the defences of the thing under attack. As organisations grow and particularly as they diversify in their behaviour the risk presented by any one attack to the whole is reduced, whereas an organisation that remains small and focussed is much more susceptible to a focussed attack. Thus SMEs, when under attack would tend to exhibit higher risk than larger or more diversified industries.

text: The "Risks" and the relationship with "Threats" are depicted in Figure 21 and "ICT products" are presented in Figure 22.

text: Ontology and taxonomies of resilience 25

text: The "Business" domain has mainly three kinds of "Threats", namely "Supply Chain Attacks", "Changes" in the business environment and "Interaction Conflicts" in the synergy with other businesses (Figure 23). "Supply Chain Integrity Means" confront "Supply Chain Attacks", while "Cooperation" between businesses helps confronting all these three kind of "Threats". "Cooperation" is a kind of "Means", which protects both "Business" and "Network" domain, since it confronts "Threats" corresponding to conflicting businesses and network assets, relatively.

text: Ontology and taxonomies of resilience 26

text: 6.3 Ontological examination of the Network Domain

text: "Network" is described in Figure 5. However, in Figure 24, the network domain is depicted according to Operator organization levels. First, in the top of the hierarchy, there is the Operational Support System (OSS) and the Business Support System (BSS). Then, Network Management System (NMS) follows, which controls one or more management domains. Each management domain has its Element Management System (EMS) that has the responsibility for some Network Elements. However, an NMS can directly control a Network Element with an incorporated EMS, that is with embedded capabilities. Network Elements were described in Figure 22.

text: Ontology and taxonomies of resilience 27

text: Another interesting aspect is presented in Figure 25, where all the wireless technologies used so far are depicted.

text: Figure 26 presents an example of a heterogeneous network and the role of "Cooperation" as the mean to federate and negotiate among the different networks.

text: Ontology and taxonomies of resilience 28

text: In Figure 27, a description of "Network" domain "Threats" and "Means" is presented. The main "Threats" of "Network" are "Changes" (e.g. traffic changes, mobility pattern changes, KPI degradation, user profile changes) and "Interaction Conflicts" between network assets. The current and future trend of networks will be to have different network segments and even different networks (heterogeneous networks) to interact with each other. Moreover, some management functions, located into different network assets, may be conflicting. This case is enforced when autonomic functions are spread over the network layout (Self-Organizing Networks (SON)) but also over all the Operator organization levels. "Governance", "Cooperation" and "Cognitive and Self-Management" are the "Means" to confront both "Interaction Conflicts" and "Changes". "Governance" provides rules and policies to fix network instabilities caused by either "Changes" or "Interaction Conflicts". "Cooperation" resolves "Interaction Conflicts", but also helps confronting "Changes". Finally, "Cognitive and Self- Management" monitors the network, identifies any instability and triggers the appropriate actions. Therefore, it is the main self-diagnosis and self-healing mechanism. Furthermore, the learning capability enables to acquire knowledge, so that the next time similar trigger events will be confronted more immediately. "Trust Management" is a more horizontal process, encompassing all these means, although it is not included in Figure 27. This is because in such an environment with autonomic and self-x processes, there is an urgent need to build trust (trust in autonomics).

text: Ontology and taxonomies of resilience 29

text: "Cognitive and Self-Management" has some instruments, namely "Policies", "Context" and "Profiles" and "Governance" is achieved by "Policies". "Policies", "Context" and "Profiles" will be analyzed later. However, in Figure 28, the relationships among the functions of "Cognitive and Self-Management" (Figure 15) and "Policies", "Context" and "Profiles" are presented. In the functions of MAPE cycle, arrows are used to identify the direction of the information, that is when a relationship exists without an inverse relationship. "Monitor" feeds "Analyze" and "Learning" with data, acquired through the use of "Policies", "Context" and "Profiles". "Learning" builds knowledge, while "Analyze" analyzes/diagnoses the situation, derives the specific configuration policies and feeds "Plan". "Plan" is the decision making function, which decides also based on the knowledge, acquired so far by "Learning". "Plan" also feeds "Learning" with the decision, in order to build knowledge on what solution has been given to which problem for future use. Then, "Plan" orders the enforcement of the decision to "Execute". Finally, "Execute" feeds "Learning" about the enforcement result.

text: Figure 28: MAPE cycle functions and Policies, Context, Profiles

text: Ontology and taxonomies of resilience 30

text: 6.4 Ontological examination of the Service Domain

text: In Figure 29, the "Service" domain "Threats" and "Means" are presented.

text: 6.5 Ontological examination of the domain Information Exchange

text: This section describes in some detail the information exchanged between various components of a wireless communication network (WCN), i.e. user devices, Access Points and the Network Management System. The type of information exchanged between the components is first presented, followed by an overview of indicative interactions among the WCN components. This is categorised in Profiles, Context and Policies. The first two categories allow for the perception/awareness of users, devices, infrastructure elements and the networks status, while the third category facilitates governance of the network according to certain requirements or goals.

text: 6.5.1 Profiles

text: The User Profile (Figure 30(a)) comprises information on the user subscription and user preferences regarding service provisioning. Such information includes the services that the user has subscribed to and the corresponding Quality of Service (QoS) levels for each of these

text: Ontology and taxonomies of resilience

text: services. Moreover, the User Profile contains information on user preferences per Service and

text: QoS level in the form of a so-called Utility value. This information is obtained and updated

text: dynamically, following a process such as the one described in [i.13].

text: (a) (b) (c)

text: Figure 30: Profile information

text: The user device Profile (Figure 30(b)) comprises information regarding the capabilities of the

text: device and is associated with a specific User Profile, i.e. of the user currently using the device.

text: More specifically, the user device Profile includes the set of services that are supported by a

text: specific device. Furthermore, it includes information on the number of transceivers (denoted

text: as TRX in Figure 30) that the device can operate. Each transceiver (TRX) can operate at a set of

text: RATs, at various frequencies.

text: This is similar to the user device Profile. An Access Point can comprise one or more

text: reconfigurable Transceivers (TRXs) which can operate at various frequency bands and sets of

text: RATs. Therefore the Access Point Profile (Figure 30(c)) comprises one or more TRX Profiles,

text: which in turn include the details of a specific transceiver, i.e. its ID and information on the

text: frequency bands and the RATs at which it can operate.

text: 6.5.2 Context

text: The user device functionality for deciding on the optimal device configuration takes into

text: account policies as well as the information obtained through learning on context and user

text: preferences and selects the optimal device configuration. In case this decision results in a

text: modification of the configuration of the device (e.g. in terms of RAT, QoS level, Services, etc)

text: the user device informs the network side (Access Point and/or CNMS) by sending a user

text: Ontology and taxonomies of resilience 32

text: device Status message. The user device Status (Figure 31 (a)) contains information on the current configuration of the device, the running services, the active user profile and the most recently acquired preferences of the user of the device. Essentially, this is a sub-set of the user device Profile.

text: (a) (b) (c) Figure 31: Context information

text: This represents the context encountered by a specific Access Point. More specifically, it comprises information on the current load of each active transceiver of an Access Point (TRX Context in Figure 31 (b)), per User Class, Service and QoS level. This information is exploited for the decision making on the optimal configuration of a specific Access Point or a certain service area of the network.

text: This information specifies the current configuration of an Access Point (Figure 31 (c)). In a way it represents a part of the Access Point profile that is currently activated. More specifically, the Access Point Configuration holds information on the transceivers that are (or should be) activated on a specific Access Point, the corresponding RATs and Frequency bands, and the services and QoS levels that can be supported (TRX Config).

text: Ontology and taxonomies of resilience 33

text: 6.5.3 Governance policies

text: Business level entries are information provided at the business level related to the number of users anticipated for an application, user class, in a certain location and time zone. In more detail, as can be observed in Figure 32, business level entries comprise information on the Number of users, the Traffic percentage, i.e. the number of concurrently active users anticipated, the Location (e.g. Piraeus, Athens-center, …), the Time Zone (e.g. 08:00-11:00, 21:00-22:00, …), the Application (e.g. IPTV, …), User Class (e.g. Gold, Silver, Bronze, …), Quality Level (e.g. High, Medium, Low), Quality level parameters (e.g. Bit rate, delay, jitter, …) and the Mobility pattern (e.g. High, low, train, car, …).

text: Figure 32: Business level entry structure

text: High-level policies/Associations specify rules related to the relationship of applications with user classes and quality levels, the relation of a certain application with other applications and the relations between user classes. As can be observed in Figure 33 an association comprises information on a set of applications. Each application may be associated with one or more User Classes. Each User Class may be associated with one or more QoS levels. Each QoS level is associated with one or more QoS parameters.

text: Ontology and taxonomies of resilience 34

text: Figure 33: Structure of high-level policies (associations)

text: Configuration policies specify rules or constraints that should be taken into account for the selection of the optimal configuration of a service area, Access Point or Device. In this sense, configuration policies refine the set of information comprised in the Profiles and Context information. Configuration policies should be derived from business level entries and highlevel policies/associations. A policy is formulated as a set of a Compound Policy Condition and a Policy configuration (Figure 34). A Compound Policy Condition comprises a Logical Expression (e.g. AND, OR, XOR) and one or more Compound Policy Conditions or Policy Conditions. A Policy Condition encompasses a Policy Expression (e.g. "equals", "greater than", "greater equal", and "less than", "less equal", etc) and a Policy Argument. A Policy Argument includes User Class, Location, and Time zone information and basically indicates the devices that are affected by the specific policy. A Policy Configuration indicates the RATs that can be operated by transceivers of Access Points, as well as certain frequency bands per RAT in a certain service area. Moreover it also may specify the services and corresponding QoS levels that can be provided over certain RATs.

text: Ontology and taxonomies of resilience 35

text: Figure 34: Configuration Policies structure

text: Ontology and taxonomies of resilience 36

text: 7 Next steps 7.1 Standardisation

text: It has been suggested that a goal of this document is to encourage the use of ontologies in standards development and in particular for the definition of approaches in standards to provide resilience as a core attribute of a system. It is not suggested that ontologies and taxonomies replace the existing approaches to developing standards but rather that the approach outlined in this report is used to augment existing best practices. The aim of standards developed in most SDOs is to achieve interoperability and interworking of many different approaches to implementation. The approach defined in TR 187 011 is indicative of best practice in this regard but when extended by use of tools such as message sequence charts, validated state machines, formally specified data objects (say by using ASN.1) many of the aims of ontologies and taxonomies to achieve shared understanding will already have been met. Where ontologies and taxonomies have greatest impact is in the specification of shared understanding where the context is unclear and it has been shown that these tools may be used as a stepping stone to achieving that shared understanding. Therefore it is recommended that further work is done to ensure that the methods for standardisation are extended to include the use of taxonomy and ontology. This should address the work of ETSI's Methods for Testing and Specification (MTS) group in particular. In terms of standardisation it is not clear if either a taxonomy or an ontology will become normative as its purpose is to gain shared understanding as such it is proposed that such techniques are used primarily in the context of informative or guidance documents (i.e. ETSI Technical Reports, ETSI Guides).

text: 7.2 Other ontologies and taxonomies in support of resilience

text: The bulk of this report has examined and decomposed the ontology of resilience and has along the way had to consider ontologies and taxonomies for security analysis, and the interaction of business with ICT but in order to address resilience some of these avenues have been uncovered but not explored. It is therefore recommended that rather than leaving these incomplete and unexplored that further work is undertaken (for example by standardisation bodies) to complete these with a view to closing the gaps in ontological understanding.

text: Ontology and taxonomies of resilience 37

text: Annex A: References and bibliography

text: The following referenced documents are cited in the main body of the text or have been added by the authors as essential background for readers in interpretation or achieving further insight to the topics raised in the main body of the text.

text: Cited references

text: [1] ENISA Stock Taking Report on "The Technologies Enhancing Resilience Of Public Communication Networks In The EU Member States", 2009. http://www.enisa.europa.eu/act/it/library/deliverables/stock-tech-res/

text: [2] ENISA study: "Resilience Features of IPv6, DNSSEC and MPLS and Deployment Scenarios", 2008. http://www.enisa.europa.eu/act/it/library/deliverables/res-feat

text: [3] ENISA study: "Gaps in standardisation related to resilience of communication networks", 2009. http://www.enisa.europa.eu/act/it/library/deliverables/gapsstd

text: [4] ENISA study: "Priorities for Research on Current and Emerging Network Technologies ", 2010. http://www.enisa.europa.eu/act/it/library/deliverables/procent

text: [5] ENISA study: "Enabling and managing end-to-end resilience", 2011. http://www.enisa.europa.eu/act/it/library/deliverables/e2eres

text: [6] ENISA study: "Resilience Metrics and Measurements: Technical Report", 2011. http://www.enisa.europa.eu/act/res/otherareas/metrics/reports/metrics-tech-report

text: [8] Lee W Lacy: "Owl: Representing Information Using the Web Ontology Language", ISBN-10: 9781412034487, ISBN-13: 978-1412034487, ASIN: 1412034485; ASIN: B000PY45UW

text: [9] Andrew Cox, Fynnwin Prager, Adam Rose: "Transportation security and the role of resilience: A foundation for operational metrics" Transport Policy Volume 18, Issue 2, March 2011, Pages 307-317

text: [10] Mike Uschold and Michael Gruninger, "Ontologies: principles, methods and applications", The Knowledge Engineering Review, Vol. 11:2, 1996, 93-136.

text: [11] J. Li, S. Liu, Z. Lin, C. Wen, "A Real-Time Information Gathering Agent Based on Ontology", Advances in Web-Age Information Management, Lecture Notes in Computer Science, 2004, Springer, pp. 696-701

text: Ontology and taxonomies of resilience 38

text: [14] IBM Corporation, "Automating problem determination: a first step towards self-healing computer systems", www.research.ibm.com/autonomic, 2003

text: Bibliography

text: [i.1] Algirdas Avižienis, Jean-Claude Laprie, Brian Randell and Carl Landwehr, "Basic concepts and taxonomy of dependable and secure computing", IEEE Transactions of Dependable and Secure Computing, Vol. 1, No. 1, Jan-Mar 2004, pp. 11–33.

text: [i.2] Jean-Claude Laprie, "From Dependability to Resilience", LAAS-CNRS — Université de Toulouse — 7, Avenue Colonel Roche 31077 Toulouse, France laprie@laas.fr.

text: [i.3] T. Anderson (Ed.), "Resilient Computing Systems", Collins, 1985.

text: [i.4] Jean-Claude Laprie, "Resilience for the Scalability of Dependability", in Proceedings of the 2005 Fourth IEEE International Symposium on Network Computing and Applications (NCA’05), 2005.

text: [i.5] ReSIST project website, http://www.resist-noe.org/overview/summary.html.

text: [i.6] ReSIST project, Deliverable D34: Resilience ontology: final, December 2008.

text: [i.7] V. Stavroulaki, N. Koutsouris, K. Tsagkaris, P. Demestichas, "A Platform for the Integration and Management of Cognitive Systems in Future Networks", in Proc. IEEE International Workshop on Management of Emerging Networks and Services (MENS) – IEEE GLOBECOM 2010 Workshop on Management of Emerging Networks and Services, Miami, Florida, USA, 6th -10th Dec 2010.

text: [i.8] Rubén Darío Franco, Guillermo Prats, Rubén de Juan-Marín, "An Ontology Proposal for Resilient Multi-plant Networks", Enterprise Interoperability IV, Part III, pp. 169-178, Springer 2010.

text: [i.9] REMPLANET project website, http://www.remplanet.eu/web/

text: [i.10] Xiangyang Li, Charu Chandra, Jiun-Yan Shiau, "Developing Taxonomy and Model for Security Centric Supply Chain Management", International Journal of Manufacturing Technology and Management, Vol. 17, No.1/2, pp. 184 - 212, 2009

text: Ontology and taxonomies of resilience 39

text: [i.11] V. Stavroulaki, Y. Kritikou, P. Demestichas, "Acquiring and learning user information in the context of cognitive device management", In Proc. IEEE International Conference on Communications 2009 (ICC 2009), Dresden Germany, June 2009 [i.12] Cox, A., Prager, F., & Rose, A. (2011). Transportation security and the role of resilience: A foundation for operational metrics Transport Policy, 18 (2), 307- 317 DOI:10.1016/j.tranpol.2010.09.004 [i.13] http://www.greenchameleon.com/gc/blog_detail/defining_taxonomy/

text: [i.15] J. Bryar. "The Value of organized knowledge." CMS Watch (January 1, 2002) Last checked 11/16/08.

text: [i.16] R. Cover. "Resource description and classification." OASIS, last modified February 12, 2003. Last checked 11/16/08. Collection of references on matters of Subject Classification, Taxonomies, Ontologies, Indexing, Metadata, Metadata Registries, Controlled Vocabularies, Terminology, Thesauri, Business Semantics. Part of the XML Cover Pages.

text: [i.17] T. Craven. "Thesaurus Construction." London: University of Western Ontario, last updated January 25, 2008.

text: [i.18] M. Denny. "Ontology Tools Survey, Revisited." XML.com (July 14, 2004)

text: [i.19] B. Doyle. "TaxoTips: Resources to help with your taxonomies and controlled vocabularies."

text: [i.20] S. Dumais and H. Chen. "Hierarchical classification of web content." Proceedings of SIGIR 2000, pp. 256-263.

text: [i.21] "Information intelligence: Content classification and enterprise taxonomy practice." Delphi Group. 2004.

text: [i.22] H. Hedden. The Accidental taxonomist. Medford, NJ: Information Today, 2010.

text: [i.23] P. Lambe. Organising knowledge: Taxonomies, knowledge and organisational effectiveness. Oxford: Chandos Publishing, 2007.

text: Ontology and taxonomies of resilience 40

text: [i.24] B. Lutes. "Web thesaurus compendium." Last modified June 1999. Last checked 11/16/08. [i.25] L. Ramos. "Taxonomy, thesaurus, tagging: Balancing automation and editorial review." Giga Information Group, March 2002. Provides excellent definitions of these terms. [i.26] S.L. Roberts-Witt. "Practical taxonomies." Knowledge Management (January 1999) p. 46-54. [i.27] "Taxonomy & content classification: market milestone report." Delphi Group. 2002. [i.28] "Ten taxonomy myths." The Montague Group. (Nov. 2002) [i.29] A. Warner. "A taxonomy primer." Ann Arbor, Mich: Lexonomy, 2002.

text: Ontology and taxonomies of resilience 41

text: Annex B: Definitions and abbreviations Definitions

text: For the purposes of the present document, the following terms and definitions apply: asset: anything that has value to the organization, its business operations and its continuity authentication: ensuring that the identity of a subject or resource is the one claimed availability: property of being accessible and usable on demand by an authorized entity (from ISO/IEC 13335-1) confidentiality: ensuring that information is accessible only to those authorized to have access Identifier: series of digits, characters and symbols used to identify uniquely subscriber, user, network element, function or network entity providing services/applications impact: result of an information security incident, caused by a threat, which affects assets integrity: safeguarding the accuracy and completeness of information and processing methods mitigation: limitation of the negative consequences of a particular event preparedness: activities, contingencies and measures taken in advance to ensure an effective response to the impact of hazards

text: Ontology and taxonomies of resilience 42

text: user: person or process using the system in order to gain access to some system resident or system accessible service vulnerability: weakness of an asset or group of assets that can be exploited by one or more threats

text: Abbreviations

text: For the purposes of the present document, the following abbreviations apply: BSS Base Station Subsystem CDMA Code Division Media Access DNSSEC Domain Name System Security ECN&S Electronic Communication Networks and Services ENISA European Network and Information Security Agency ETSI European Telecommunications Standardisation Institute FDMA Frequency Division Media Access ICT Information and Communication Technology IPTV Internet Protocol Television IPv6 Internet Protocol version 6 MIMD Multiple Instruction Multiple Data MISD Multiple Instruction Single Data MPLS Multi-Protocol Label Switching NGN Next Generation Networks NO Network Operator OFDMA Orthogonal Frequency Division Media Access QoS Quality of Service RAT Radio Access Technology SDH Synchronous Digital Hierarchy SDO Standards Development Organisation SIMD Single Instruction Multiple Data SISD Single Instruction Single Data SM Shared Memory SME Small or Medium Enterprise SM-R Shared Memory - Read SM-RW Shared Memory – Read Write SM-W Shared Memory - Write SRKB Shared Re-usable Knowledge Bases TDMA Time Division Media Access TETRA Terrestrial Trunked Radio TRX Transceiver TVRA Threat Vulnerability and Risk Analysis

text: Ontology and taxonomies of resilience 43

text: Annex C: Existing taxonomies in resilience

text: This annex contains the results of a routine search of existing papers in the field with a view to find the terms "taxonomy" and "resilience". NOTE: The references are shown in annex A that came out of a simple search. The development of taxonomies has been the source of much debate and many instances has led to scientists falling out for many years. Traditionally taxonomy development has been on the basis of shared characteristics with more modern taxonomy development, particularly in biology, development has been based by classification based on evolutionary descent. The latter approach is best characterised by modern biological classification and shown in Table C1 with examples of using the classification schema.

text: In computing the first major taxonomical classification was made by Flynn [] and consisted of 4 categories following the rule of classification by shared characteristics:  SISD: Single Instruction Single Data

text:  SIMD: Single Instruction Multiple Data

text:  MISD: Multiple Instruction Single Data

text:  MIMD: Multiple Instruction Multiple Data

text: These have been extended for each of the MIMD and SIMD classes with the additional categories listed below:  SM-R: shared memory multiple reads to same location allowed

text:  SM-W: shared memory multiple writes to same location allowed

text:  SM-RW: shared memory, both multiple reads and writes allowed

text:  SM: shared memory, both multiple reads and writes disallowed

text:  TC: tightly coupled

text: Ontology and taxonomies of resilience 44

text:  LC: loosely coupled  UC: uncoupled This approach reinforces a classification of shared characteristics. In the area of transport a number of taxonomies have been written with a view to improvement of response to terrorist threats as considered by Cox et al [9]. Resilience is considered in this area as having two dimensions: Static; and, Dynamic.

text: Ontology and taxonomies of resilience 45

text: Annex D: Existing ontologies in resilience

text: This annex contains the results of a routine search of existing papers in the field.

text:  A quantitative definition of dependability is introduced.

text:  The criterion of capability is introduced in the classification of human-made nonmalicious faults, enabling the consideration of competence.  The discussion of malicious faults is extensively updated.

text:  Service failures are distinguished from dependability failures: The latter are recognized when service failures over a period of time are too frequent or too severe.  Dependability issues of the development process are explicitly incorporated into the taxonomy, including partial and complete development failures.  The concept of dependability is related to dependence and trust, and compared with three recently introduced similar concepts, including survivability, trustworthiness, high-confidence systems.

text: Moreover, the authors state that the major strength of the concept formulated in [i.3] is its integrative nature, which enables the more classical notions of reliability, availability, safety, confidentiality, integrity, and maintainability to be put into perspective. The fault-error-failure model is central to the understanding and mastering of the various threats that may affect a system, and it enables a unified presentation of these threats, while preserving their specificities via the various fault classes that can be defined. The model provided for the

text: Ontology and taxonomies of resilience 46

text: means for achieving dependability and security is extremely useful, as those means are much more orthogonal to each other than the more classical classification according to the attributes of dependability, with respect to which the development of any real system has to perform tradeoffs since these attributes tend to conflict with each other. Finally, the refinement of the basic definitions leads to a refined dependability and security tree. Concerning what is intended to be done as future elaboration of [i.3], the authors identify six main points:  Expanding the discussion of security, for example to cover techniques for protecting confidentiality, establishing authenticity, etc.  Analyzing issues of trust and the allied topic of risk management.

text:  Searching for unified measures of dependability and security.

text:  New technologies (nanosystems, biochips, chemical and quantum computing, etc.) and new concepts of man-machine systems (ambient computing, nomadic computing, grid computing, etc.) will require continued attention to their specific dependability issues.  The problems of complex human-machine interactions (including user interfaces) remain a challenge that is becoming very critical—the means to improve their dependability and security need to be identified and incorporated.  The dark side of human nature causes to anticipate new forms of maliciousness that will lead to more forms of malicious faults and, hence, requirements for new defences as well.

text: In [i.4], the definitions of resilience and the technologies for resilience are introduced. According to the authors’ view, the adjective "resilient" has been in use for decades in the field of dependable computing systems, essentially as a synonym of "fault-tolerant", thus generally ignoring the unexpected aspect of the phenomena the systems may have to face. A noteworthy exception is the preface of [i.5], which says: "The two key attributes here are dependability and robustness. […] A computing system can be said to be robust if it retains its ability to deliver service in conditions which are beyond its normal domain of operation". Fault-tolerant computing systems are known for exhibiting some robustness with respect to fault and error handling, in the above sense, i.e., for situations exceeding their specification. A total change of scale is needed when moving to the future large, networked, evolving systems constituting complex information infrastructures — perhaps involving everything from super-computers and huge server "farms" to myriads of small mobile computers and tiny embedded devices. Such systems are in fact the dawning of ubiquitous systems, with which, what is at stake is to maintain dependability, i.e., the ability to deliver service that can justifiably be trusted, in spite of continuous changes.

text: Ontology and taxonomies of resilience 47

text: In this concept, [i.4] intends to make the step from dependability to resilience by considering not only the fault but also the change tolerance and adaptation. Therefore, the definition of resilience builds on the definition of dependability with the insertion of facing changes in addition to faults and errors confrontation. So, briefly, resilience is seen as the persistence of dependability when facing changes. A classification of changes and a respective diagram is given. It is also emphasized, in the context of dependability that the changes can concern, or induce changes in the threats the system is facing. Moreover, the changes can themselves turn into threats, as in the case of mismatches between the modifications that implement the changes and the former status of the system. Finally, the relationship between the technologies for resilience, namely evolvability, assessability, usability, diversity, and the means for dependability, that means fault prevention, fault tolerance, fault removal, fault forecasting, is depicted. Furthermore, in [i.6], the relationships among the changes, resilience scalability properties and resilience scaling technologies, i.e. technologies for resilience, are depicted through an ontology diagram. The concept is as follows. Accommodating functional, environmental and technological changes at a satisfactory level of dependability and security induces the need for scalability, which in turn drives the requirement for resilience policies, algorithms and mechanisms to be extensible, composable, adaptive, and consistent with respect to the assumed threats. The satisfaction of these scalability properties clearly requires that the resilience policies, algorithms and mechanisms are evolvable, assessable, usable and diverse. The work reported previously in [i.4] has been performed in the framework of the European Network of Excellence ReSIST (Resilience for Survivability in Information Society Technologies). ReSIST [i.7] addresses the strategic objective "Towards a global dependability th and security framework" of the 6 Work Programme, and responds to the stated "need for resilience, self-healing, dynamic content and volatile environments". It has integrated leading researchers active in the multidisciplinary domains of Dependability, Security, and Human Factors, in order that Europe has a well-focused coherent set of research activities aimed at ensuring that future "ubiquitous computing systems", the immense systems of ever-evolving networks of computers and mobile devices which are needed to support and provide Ambient Intelligence (AmI), have the necessary resilience and survivability, despite any residual development and physical faults, interaction mistakes, or malicious attacks and disruptions. The objective of ReSIST project, as denoted in [i.8], a public document of ReSIST, named "Resilience ontology: final", intends to create a structured representation of the resilience concepts, in the form of a thesaurus and an ontology, which is to be able to use natural language processing tools to perform computer-aided identification and classification of existing documents concerned with resilience and to classify new documents as they are generated. More explicitly, a hierarchical thesaurus is first created based on the terminology extraction, then the thesaurus is employed to do automatic indexing of documents, followed by the identification of a number of clusters by means of automatic clustering analysis, and finally the resulting from the thesaurus final ontology will be compared with the ontology existing in [i.3]. Resilience in [i.8] is defined as "the persistence of dependability in the

text: Ontology and taxonomies of resilience 48

text: presence of changes" in consistency with [i.4]. However, the term "dependability" is used as an abbreviation for the definition given above, that is, for "resilience". With respect to resilience ontology, an effort to create an ontology corresponding to [i.3], within the ReSIST activity, is initially carried out in [i.8]. The first analysis of the ontology in [i.3] dealing with the various types of faults, conducted by ReSIST, has instantly revealed that this hierarchy contained almost no multiple inheritance, i.e., that the sub-fault relationship spanned a tree rather than a graph. This results in an inappropriate and sometimes misleading categorization of faults. Concerning the categorization of faults, [i.3] accounts for eight basic viewpoints (whose possible combinations lead to 31 fault classes), which lead to various overlapping groupings. A more detailed investigation of the distribution of potential faults with respect to their viewpoints showed that this ontology implicitly encodes several subsets, that is sub-fault relationships. Therefore, a new resulting fraction of the fault hierarchy is proposed in [i.8], which explicitly considers some of the sub-fault relationships that [i.3] misses. Since every knowledge-aware processing method can only take explicitly modelled (or implicit but entailed) facts into account, it is important to represent even the supposedly obvious. The ENISA report on gaps in standardisation related to resilience of communication networks [3] summarises and presents the following key elements:  the definition applied to resilience in the context of standardisation,

text:  the identification and presentation of the major activities undertaken in the standards developing organizations (SDOs) in either security or architecture that have a focus on resilience,  the identification where should work be undertaken in standardisation activity in either security or architecture, there will be a positive impact on the resilience of networks, in light of the current lack of specific activity on resilience as identified in the SDOs,  the provision of recommendations for future standardisation activities.

text: In this context, several isolated ontologies for resilience are introduced in the report. The first ontology is given when discussing resilience against a network model, which derives from the security analysis of systems under attack. Therefore, the electronic communications networks and services (ECN&S) model is considered alongside the model of systems under attack, i.e. the generic system security and attack model, which models a system as an aggregation of assets which may be attacked in isolation or in combination with the aim of defeating the system objectives. Whilst traditionally threats can be classified as one of four types (interception, manipulation, repudiation of sending, and repudiation of receiving), and whilst traditionally security objectives can be classified as one of four types (confidentiality, integrity, accountability, and availability), it is the purpose of the report to explicitly consider only those aspects that impact resilience as a composite of the typical security objectives. Thus, the ITU-T

text: Ontology and taxonomies of resilience 49

text: ontological model of cyber security stressing resilience is depicted, where a resilient infrastructure is one of the protection measures in the cyber security model. Other resilience ontologies are given when identifying the requirements for a taxonomy covering metrics and risk categorisation to be applied to resilience. Firstly, an illustration of a threat hierarchy is presented as an alternative model for considering both ontologies and taxonomies. Then, an ontology of cyber-security, identified by the ITU-T and ETSI in TR 187 010, is illustrated and simplified, where it has been revised slightly to show that ‘resilient infrastructure’ is one of the capabilities that enables protection. In this view, resilience is shown to include measures to assure both availability and network integrity. In addition to taxonomies and ontologies for the assessment of cyber security, there is a need to develop metrics that allow an instantiation of a system to express its resilience. In this case, system resilience may be measured or expressed in terms of its metrics. In this scope, a model illustrating the metrics, used to express system resilience, is presented. Finally, when referring to the theory of network resilience and basically identifying the areas of interest for the SDOs, a hierarchical taxonomy of Hazards is given. Another report for ENISA [2] is evaluating the effectiveness of three key technologies, namely IPv6, DNSSEC, and MPLS, in improving the resilience of public eCommunication networks. This study analyses the characteristics of those technologies and highlights their effect on the resilience of the network. An overview of the characteristics of IPv6, DNSSEC, and MPLS is given, and the resilience assisting features, as well as other properties that one has to aware of to make an educated decision about their deployment are enumerated. When studying resilience provided by DNSSEC, an ontology model presents the main threats against DNS. The points shown on the left side of the model are discussed in more detail, while security issues on the right side cannot be addressed by DNSSEC. At a network level, [i.9] presents an open, scalable platform for the integration and management of cognitive systems (IMaCS) that aims at both comprising various cognitive management schemes, thus enabling efficient end-to-end operation, and abstracting the complexity of the underlying infrastructure. The success of future generation networks will be driven by the provision of ubiquitous, personalized services that can offer an enhanced user experience. In order to support the provision of more and better services to users, and at the same time deal with the complexity of the infrastructure of network operators (NOs), advanced management functionality needs to be introduced in wireless systems, both on the network as well as on the user device side, which will enable optimum, end-to-end operation. In this direction, the IMACS platform introduces cognitive and self-management features in the B3G world, with the aim of evolving current heterogeneous wireless system infrastructures into an integrated, efficiently managed and scalable framework. Based on the features of cognitive systems, cognitive systems can determine and configure their operation not only in a reactive manner, i.e. responding to the detection of problematic situations, but also proactively, so as to prevent issues undermining the optimal system function. In this manner, cognitive management is an ideal mechanism in order to achieve network resilience.

text: Ontology and taxonomies of resilience 50

text: The information flow, presented in [i.9], has been formulated as ontology. This ontology gives many advantages. Firstly, it offers interoperability and a shared vocabulary, which is crucial for the integration of the different, proprietary, implemented platforms and test beds and for smoothing the progress of introducing various cognitive schemes in future networks. This possibility is enforced since the implementation of a ubiquitous communications environment entails a great complexity of the underlying infrastructure that increases as networking technologies continue to evolve and new ones emerge. Secondly, the ontology can be easily extended or modified, which facilitates the integration of various software and hardware components and thus allows the realization of validation, exploitation and demonstration activities in a wide range of test cases and application areas. Future work plans include the refinement and extension of the information flow ontology as well as the enhancement of "plug and play" features. In [i.10], an ontology proposal for the REMPLANET FP7 project [i.11], which aims at developing methods, guidelines and tools for the implementation of the Resilient Multi-Plant Networks in non-hierarchical manufacturing networks, characterized by non-centralized decision making, is presented. In manufacturing and distribution networks, the traditional concept of static Supply Chains is changing towards the operation and management (O&M) of heterogeneous, dynamic and, geographically distributed partners. This new environment is making enterprises changing the way they manage their trading relationships. Interoperability is a critical issue to take into consideration when such collaboration needs appear due to the importance of information exchange and distributed coordination needs. The European Project REMPLANET is intended to create methods and tools in supporting resilient organizational models. The project defines the concept of a resilient organization as the capacity to respond rapidly to unforeseen change, even chaotic disruption. It is the ability to bounce back — and, in fact, to bounce forward — with speed, determination and precision. A resilient organization effectively aligns its strategy, operations, management systems, governance structure, and decision-support capabilities so that it can uncover and adjust to continually changing risks, endure disruptions to its primary earnings drivers, and create advantages over less adaptive competitors. Due to structural heterogeneity of REMPLANET integration scenarios, an ontological approach is provided, intended to define a unified and commonly agreed understanding of main domain concepts, and their relationships. This ontology will facilitate partners to understand how concepts are interrelated and the information sharing, and to avoid interoperability problems identified in an inter-operational environment such as conceptual barriers. The ontology has been divided into three simpler views in order to facilitate understanding, namely Resilient Organization, ICT Platform and Members and its related processes. The ICT platform incorporates interoperability functionalities, to facilitate the supply network member’s systems integration and allow each new member a fast connection to the network. Moreover, this platform is considered a basis for the non-centralized decision making and allows facilitating communication, achieving flexibility and preparedness to environments changes. The ontology also allows the knowledge to be reused, shared, and enriched with more

text: Ontology and taxonomies of resilience 51

text: knowledge using templates and automated procedures. The authors also identify some issues for further discussion, mainly concerning members and relationships.

text: The study of existing bibliography on resilience ontology has identified the following key elements:  There is need for an ontology which will address the end-2-end resilience. This ontology will cover issues at different implementation levels (hardware, middleware, software), network layers (network, application layers) including human factors, both on the network as well as on the user side.  There are several areas of interest, which are pointed in [4], namely cloud computing, real time detection and diagnosis systems, sensor networks, future wireless networks and integrity of supply chain. The derived ontology should be applicable to the aggregation of them as much as possible.  The ontology will bridge the gap existing in standardization. Actually, it intends to be a form of guidelines for stakeholders, e.g. operators, policy makers etc., drawing the direction for resilience and moreover for quality except availability.  This ontology and the corresponding taxonomy will address also the metrics for resilience.  The ontology should offer an open, interoperable and scalable framework, which is desirable to lead to standardization. The target audience consists of all the involved in resilience stakeholders and mainly the industry stakeholders.

text: Ontology and taxonomies of resilience 52

text: Annex E: Ontology language files

text: The ontology examined in the core of the document is presented in an electronic attachment to the document.

text: Ontology and taxonomies of resilience 2

text: P.O. Box 1309, 71001 Heraklion, Greece www.enisa.europa.eu