Development of a Monitoring System for Security

ASMONIA Attack analysis and Security concepts for MObile Network infrastructures, supported by collaborative Information exchAnge

Development of a Monitoring System for Security Risk Reduction Identification of supporting Sensor Systems and Development of Concepts D4.1(i) – 1.0

Contributors:

Cassidian Systems

Editor:

Heiko Kirsch (Cassidian Systems)

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Author(s)

Company

E-mail

Mirko Haustein

Cassidian Systems

[email protected]

Michael Hoche

Cassidian Systems

[email protected]

Paul Kirner

Cassidian Systems

[email protected]

Heiko Kirsch

Cassidian Systems

[email protected]

About the ASMONIA project Given their inherent complexity, protecting telecommunication networks from attacks requires the implementation of a multitude of technical and organizational controls. Furthermore, to be fully effective these measures call for the collaboration between different administrative domains such as network operators, manufacturers, service providers, government authorities, and users of the services. ASMONIA is the acronym for the German name* of a research project that aims to improve the resilience, reliability and security of current and future mobile telecommunication networks. For this purpose the ASMONIA consortium made up of several partners from academia and industry performs a number of research tasks, based on the specific expertise of the individual partners. The project running from September 2011 till May 2013 receives funding from the German Federal Ministry of Education and Research (Bundesministerium für Bildung und Forschung, BMBF). Various associated partners further contribute on a voluntary basis. * The full name is "Angriffsanalyse und Schutzkonzepte für MObilfunkbasierte Netzinfrastrukturen unterstützt durch kooperativen InformationsAustausch" (Attack analysis and security concepts for mobile network infrastructures, supported by collaborative information exchange).

Partners:

Cassidian Systems ERNW Enno Rey Netzwerke GmbH Fraunhofer Research Institution for Applied and Integrated Security (AISEC) Hochschule Augsburg Nokia Siemens Networks GmbH & Co KG RWTH Aachen

Associated Partners:

Federal Agency for Digital Radio of Security Authorities and Organizations (BDBOS) Federal Office for Information Security (BSI) Deutsche Telecom AG (DTAG)

For more details about the project please visit www.asmonia.de. 2

Copyright © 2011 ASMONIA consortium. All rights reserved.

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0

Executive Summary This document is part of the development of a security monitoring infrastructure for a mobile telecommunication system addressing the transition from the current state as is to a to be enterprise architecture. This monitoring infrastructure is designed to control the security measures developed in the ASMONIA project. In this sense it supplements the approached collaboration as a control instance. Especially the document addresses in an intermediate state development advances made so far, and the creation of an initial enterprise architecture as a coordination means and the identification and classification of potential sensors suitable to support the ASMONIA project targets and especially the monitoring goal. Generally, information and services are core assets in today's organizational environments. These are provided by collaborative information systems. As far as these systems are treated as critical for the survivability of nation's society as written in the German National Strategy for Critical Infrastructure Protection, secure and reliable operations of these information systems contribute to social welfare, where social welfare is considered as the value of information security. Information security in terms of confidentiality, integrity and availability needs to be ensured and treated as common economic good. However, the responsibility for ensuring adequate information security is assigned to different domains that are owned by selfish acting parties. These parties naturally follow their economic interests to maximize their payoff for provisioning competitive services inside the covering social-economic system. Since the relation between information security and economic payoff is rather opaque, there is only a weak incentive for increasing information security as social welfare. Additionally, each party is confronted with a wide variety of emerging unforeseeable risks originated by usage of collaborative information systems. It is infeasible for one sole party to protect itself against all these risks. But each party is at least capable to contribute to a risk reduction, if it is compatible with their economic interests. For increasing social welfare as the aggregation of each parties contribution to the value of information security, an incentive compatible mechanism design ensuring true and effective collaboration is required. As a perquisite it seems to be necessary quantifying the economic impact of information security. The first challenge is to quantify information security by defining relevant metrics allowing to analyze measurements and finally to infer their economic impact. The challenge is not primarily the knowledge to secure collaborative systems, it lies in lack of investing in doing so. Budgets generally depend on the manner in which individuals translate investments into outcomes although the security depends on other externalities. Therefore, to properly develop a system assessing economic impact of information security, measurements need to flow through an analytical framework based on a coherent conceptual approach of security, which appreciates the unique characteristics of this subject matter. Metrics in isolation are not sufficient and can be misleading and even counterproductive. In addition the diversity of parties might imply distinctly divergent goals and obligations, which, although they may be aligned, are not identical. These diverging goals and objectives need to be clearly explorable in measuring the impact of information security and the appropriateness of investments. While there is certainly an alignment at one level of abstraction between information security and its value, it is an complex, not well understood correspondence. Indeed, individual businesses may be willing to tolerate far greater amounts of insecurity based on purely economic considerations than governments may tolerate. For instance industry will be far more constrained by issues of cost effectiveness than government. Moreover, within the Copyright © 2011 ASMONIA consortium. All rights reserved.

3

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 private sector, it cannot be assumed that the economic rules acting information security impacts and investment are the same, even among parties classified as portions of the critical infrastructure. Portions of critical infrastructures are governed by social contracts, e.g. laws, in which parties make economic decisions with direct influence by governmental agencies. Thus the meaning and measuring of impact of information security or the appropriateness of an investment could be very different from an party's perspective. The second challenge is to motivate parties to contribute their capabilities to increase social welfare. One of the most common assumptions made is that if impact of security incidents are sever it implies adequate investments to mitigate the according risks. A corollary to this belief is that bad behavior, including inadequate security investments will naturally be sanctioned economically. Such an assumption betrays a misunderstanding of the unique characteristics of security. Today's information security lacks on an appropriate liability assignment. Legal theorists have long known that liability should be assigned to the party that can best manage the risk. The security discipline has so far been scoped toward technology, instead of risk analysis and proactive intelligence gathering. Security investment should shift from the technologyheavy, tactical operation to an intelligence-centric, risk analysis philosophy. It is not sufficient to understand the importance of security, one need to be able to make business and investment decisions based on knowledge of risks and observable impacts. If the consequences can be assigned to a monetary value, organizations will have greater ability and incentive to address information security.

4



Figure 1 Continuous Security Risk Reduction Capability Set The ASMONIA project intends to outline the capability set Continuous Security Risk Reduction used within the ASMONIA project to establish security transparency as social welfare with a collaborative approach. This capability set addresses both challenges and includes: 

Continuous Security Monitoring, defined as ongoing observance with the intent to provide warnings in case of deviations from expected behavior.



Continuous Security Model Adaptation, defined as the ongoing evaluation and adaptation of the underlying behavioral model.



Continuous Security Economics Analysis, defined as the ongoing identification of effective economical impacts associated with behavioral deviations.



Continuous Security Awareness, defined as ongoing presentation of the current and past security status for decision support.



Continuous Security Collaboration, defined as ongoing conflict resolution between parties having divergent economic interests.

This capability set will be generically developed. Its value will be illustrated by an exemplary collaborative information system of a mobile telecommunication network focused by ASMONIA. The applicability of the described capabilities within such a network will be exemplary validated. The development of Continuous Security Monitoring yields to a unifying data model of measurements with well-defined semantic foundations which is the focus of this document. Copyright © 2011 ASMONIA consortium. All rights reserved.

5

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 This allows to observe and compare behavior of services and states of assets provided within a mobile telecommunication network. Its applicability to monitoring such collaborative networks will be exemplary illustrated using available monitoring techniques in a similar setting providing the necessary continuous measurement streams. The development of Continuous Security Model Adoption leverages the application of data mining technologies to enhance the model of expected (secure) behavior and to discriminate abnormal (insecure) behavior. Its applicability to classify the observable behavior of mobile telecommunication network will be exemplary illustrated using data mining techniques in the similar setting based on the continuous measurement streams made. The development of Continuous Security Economics Analysis will address a underlying model of the value of security as well as the allocation of claims resulting form security deficits. Finally an exemplary implementation illustrates the connection between security deficits and value streams. The underlying value stream model is held flexible to ensure the applicability to the mobile telecommunication network context. The applicability in the mobile telecommunication network context will be exemplary illustrated for users and operators of such networks. The development of the Continuous Security Awareness will comprise an intuitive and ambient presentation of the current realized security risks. Additionally interaction metaphors will be developed to allow efficient identification of root causes and their economic impacts based on Continuous Security Economics Analysis. The developed underlying abstract model of security allows to discover relationships among the introduced entities "Agent", "Interaction", "Value", "Behavior" and "Asset". The development of the Continuous Security Collaboration will leverage on game theoretic approaches to gain insights in the information security socio-economic environment among distrusted responsibilities and assigned liabilities. The goal is to develop an incentive compatible mechanism design for motivating collaboration and gaining an adequate level of information security for mobile telecommunication networks as critical information infrastructure. The applicability of the to be defined mechanism will be analyzed with respect to equilibriums and with respect to Mobile Telecommunication Market and the underlying regulations. The potential achievements of an implementation of the capability set Continuous Security Risk Reduction will be translated from an exemplary analogous use case in the context of mobile telecommunication networks.

6



Table of Contents

Executive Summary

3

Table of Contents

8

1 Introduction

11

1.1 Motivation

12

1.2 Objective

13

1.3 Intended Audience

15

1.4 Document Structure

17

2 Basic Concepts

19

2.1 Theory and Methodology 2.1.1 Concept: Emergence 2.1.2 Concept: Intelligence 2.1.2.1 Knowledge 2.1.2.2 Representation 2.1.2.3 Reasoning 2.1.3 Concept: Game Theory 2.1.3.1 Social Choice 2.1.3.2 Game Theory Concepts 2.1.3.2.1 Strategic Game 2.1.3.2.2 Best Response, Equilibrium and Dominance 2.1.3.3 Mechanism Design 2.1.4 Concept: Semantics 2.1.4.1 Behavior 2.1.4.2 Simulation 2.1.4.3 Denotation 2.1.4.4 Decomposition 2.1.5 Methodology: Enterprise Architecture 2.1.5.1 Views 2.1.5.1.1 Module View 2.1.5.1.2 Component-and-Connector View 2.1.5.1.3 Allocation views 2.1.5.2 Service Orientation 2.1.6 Technology: Data Mining 2.1.6.1 Mining Process 2.1.7 Technology: Human Computer Interaction 2.2 Service Orientation, Monitoring and Tracing 2.2.1 Service Orientation 2.2.2 Services 2.2.2.1 Invocation 2.2.2.2 Reconstruction 2.2.2.3 Organization

20 20 20 21 21 22 24 24 25 25 25 26 27 27 29 29 30 32 33 34 34 35 35 37 38 38 39 39 40 41 41 42

8


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 2.3 Behavioral Security 2.3.1 Collaboration and Security 2.3.2 Security Characteristics and Measurements 2.3.3 Measuring Security Characteristics 2.3.3.1 Detection and Recursion 2.3.3.2 Integrity Detection 2.3.3.3 Confidentiality Detection 2.3.3.4 Availability Detection 2.4 Security Economics 2.4.1 Quantifying the Economic Impact 2.4.2 Information Security 2.4.3 Interaction and Economy 2.4.4 Economy and Collaboration 2.4.4.1 Agent 2.4.4.2 Interaction 2.4.4.3 Behavior and Security 2.5 Security Collaboration 2.5.1 Collaboration and Economy 2.5.2 Incentive Compatible Economy

44 44 44 46 46 47 47 48 48 48 49 49 50 50 50 51 52 52 52

3 Continuous Security Risk Reduction

54

3.1 Capabilities

54

3.2 Requirements 3.2.1 Functional Requirements 3.2.2 Non-Functional Requirements 3.3 Constraints

58 60 61 62

3.4 Enterprise Architecture 3.4.1.1 Architecture Vision of ASMONIA 3.4.1.2 Business Architecture of ASMONIA 3.4.1.3 Information Architecture of ASMONIA 3.4.1.4 Procedural View 3.4.1.5 Technology Architecture of ASMONIA 3.4.1.6 Rationale

63 63 64 64 66 66 67

4 Continuous Security Monitoring

68

4.1 Requirements 4.1.1 Sensors 4.1.2 Measurements and Observations 4.1.3 Semantics of Observations 4.1.4 Constructive Semantics 4.2 Module View 4.2.1 Coordination of existing Modules 4.2.1.1 Sensor Ontology 4.2.1.2 Measurement Ontology 4.2.1.3 Measurements 4.2.1.4 Sensor Candidates 4.2.1.4.1 Log Management Infrastructure 4.2.1.4.2 Security Information and Event Management System

68 71 71 71 71 72 72 73 75 78 79 79 81


9

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 4.2.1.4.3 Intrusion Detection System 4.2.1.4.4 Charging System 4.2.1.5 Modules 4.2.1.6 Relations 4.3 Component-and-Connector view 4.3.1 Components 4.3.2 Connectors 4.3.3 Relationships 4.4 Allocation view 4.4.1 Environment 4.4.2 Allocations and Dependencies

82 83 83 84 84 85 86 86 88 88 88

5 Discussion & Summary

89

References

91

Glossary and Abbreviations

98

Glossary

98

Abbreviations

100

Revision History

101

Annex A 3GPP Policy and Charging Architecture

102

A.1 General Requirements

102

A.2 Reference Architecture

103

A.3 Charging Models

104

A.4 Charging Requirements

104

A.5 Charging Information Requirements

105

A.6 Charging Architecture

108

Offline Charging Functions

108

Charging Trigger Function

108

Charging Data Function

108

Charging Gateway Function

109

Online Charging Functions

110

10



1 Introduction The complex relationships among business processes and information systems supporting those require an integrated view for managing risks. The role of information security in managing risks from the operation and use of information systems is critical to the success of organizations in achieving their strategic goals and objectives. Historically, executives have had a very narrow view of information security either as a technical matter or in a stovepipe that was independent of organizational risk and the traditional management and life cycle processes. This extremely limited perspective often results in inadequate consideration of how information security risk affects the likelihood of organizations successfully carrying out their business functions. Effectively managing information security risk requires the following key elements: 

Assignment of risk responsibilities and liabilities



Ongoing recognition and understanding of the information security risks to operations and assets, individuals, other organizations, and nations



Establishing and communicating the risk tolerance



Accountability for effective risk management decisions.

The selection and implementation of appropriate security controls for an information system or system-of-systems have major implications on the operations and assets of an organization as well as the welfare of individuals and the nation. Security controls are the management, operational, and technical safeguards or countermeasures employed within an information system to protect the confidentiality, integrity, and availability. "Continuous Security Risk Reduction" is the means for maintaining ongoing awareness of information security, vulnerabilities, and threats to support risk management decisions. This document specifically addresses conceptually approaches and enterprise architecture for continuous assessment and analysis of security effectiveness. The security status is determined using measures and metrics to best convey the standing of an information system along with resiliency given known threat information. This necessitates maintaining situational awareness of the whole information system across organizations, maintaining an understanding of threats and threat activities, evaluating the security impacts, assessing security controls, collecting, correlating and analyzing securityrelated information and providing actionable communication of the security status. "Continuous Security Risk Reduction" gives executives access to security-related information, enabling timely risk-management decisions. Timely awareness is obtained through methods and tools designed for automated data collection, analysis, and communication. Executives must recognize that explicit, well-informed risk-based decisions are necessary in order to balance the benefits gained from the operation and use of these information systems with the risk of the same systems. Within the ASMONIA every participant and hence every community participating on the mobile telecommunication network in focus in considered as an agent. This approach in is illustrated in an analogous use case targeting on a Voice over Internet Protocol infrastructure where the developed concepts, methodologies and technologies are illustratively applied. The concepts and methodologies targets especially socio-economical and security risk aspects of information security in collaborative information systems allowing consideration of mobile telecommunication networks as critical infrastructure and therefore security as contribution to a nation's social welfare.


11


1.1 Motivation The responsibility for ensuring adequate information security is assigned to different domains that are owned by selfish acting parties. These parties naturally follow their economic interests to maximize their payoff for provisioning competitive services inside the covering social-economic system. Since the relation between information security and economic payoff is rather opaque, there is only a weak incentive for increasing information security as social welfare. Additionally, each party is confronted with a wide variety of emerging unforeseeable risks originated by usage of collaborative information systems. It is infeasible for one sole party to protect itself against all these risks. But each party is at least capable to contribute to a risk reduction, if it is compatible with their economic interests. For increasing social welfare as the aggregation of each parties contribution to the value of information security, an incentive compatible mechanism design must ensure true and effective collaboration. As a perquisite it seems to be necessary quantifying the economic impact of information security. The challenge is not primarily the knowledge to secure collaborative systems, it lies in lack of investing in doing so. Budgets generally depend on the manner in which individuals translate investments into outcomes although the security depends on other externalities. While there is certainly an alignment at one level of abstraction between information security and its value, it is a complex, not well understood correspondence. Indeed, individual businesses may be willing to tolerate far greater amounts of insecurity based on purely economic considerations than governments may tolerate. For instance industry will be far more constrained by issues of cost effectiveness. Moreover, within the private sector, it cannot be assumed that the economic rules acting information security impacts and investment are the same, even among parties classified as portions of the critical infrastructure. These portions are governed by social contracts, e.g. laws, in which parties make economic decisions with direct influence by governmental agencies. Thus the meaning and measuring of impact of information security or the appropriateness of an investment could be very different from a party's perspective. One of the most common assumptions made is that if impact of security incidents are sever it implies adequate investments to mitigate the according risks. A corollary to this belief is that bad behavior, including inadequate security investments will naturally be sanctioned economically. Such an assumption betrays a misunderstanding of the unique characteristics of security. Another aspect is that today's information security lacks on an appropriate liability assignment. Legal theorists have long known that liability should be assigned to the party that can best manage the risk. Incentive compatible transparent risk assignment will lead to collaborative behavior and interoperability which is the foundation of the approached social welfare. It is identified that continuous security risk awareness will promote collaborative behavior and, evolutionary, it is expected that isolated approaches will become extinct. The to be established continuous security risk reduction is designed to maintain a competitive advantage. It is further expected that the developed enterprise architecture patterns, if applied, will create security awareness and will deepen the understanding of the value of information security and will finally lead to increased customer satisfaction and customer success.

12



1.2 Objective The purpose of this document is to assist organizations in addressing the outlined challenges using the developed enterprise architecture patterns and implementations. I. The first challenge is to quantify information security by defining relevant metrics allowing to analyze measurements and finally to infer their economic impact. II. The second challenge is to motivate parties to contribute their capabilities to increase social welfare. To reach this goal a capability set, called "Continuous Security Risk Reduction" is introduced concerning "Continuous Security Monitoring", "Continuous Security Model Adaptation", "Continuous Security Economics Analysis", "Continuous Security Awareness" and "Continuous Security Collaboration". This capability set provides visibility into organizational and social economic assets, awareness of threats and vulnerabilities targeting collaborative information systems, and visibility into the effectiveness of deployed security controls among different domains and parties. It provides ongoing assurance that implemented security controls are aligned with organizational risk tolerance as well as the information needed to respond to risks in a timely manner.


13


Figure 2: Continuous Security Risk Reduction Capability Set This document provides a structured, flexible approach for managing risk that is intentionally broad-based, with the specific details of assessing, responding to, and monitoring risk on an ongoing basis. The capability set is not intended to replace or subsume other risk-related activities, programs, processes, or approaches that organizations have implemented or intend to implement addressing areas of risk management covered by other legislation, directives, policies, programmatic initiatives, or business requirements. Rather, the collaborative approach for continuous reduction of security risk described herein is complementary to and should be used as part of a more comprehensive enterprise risk management. The capability set "Continuous Security Risk Reduction" will be developed: 

To ensure that managing information system-related security risks is consistent with business objectives and overall risk strategy



To ensure that information security requirements, including necessary security controls, are integrated into the organization’s enterprise architecture and system development life cycle processes



To support consistent, well-informed, and ongoing security authorization decisions, transparency of security and risk management-related information, and reciprocity



To achieve a higher level of information security

through the implementation of appropriate risk management by

14


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 

Facilitating a more consistent, comparable, and repeatable approach for selecting and specifying security controls for information systems and organizations



Providing a recommendation for security controls for information systems



Providing an intuitive, transparent security risk presentation to identify current and future organizational protection needs



Creating a foundation for the development of assessment methods and procedures for determining security control effectiveness



Improving communication among organizations by providing a common language that supports discussion of risk



Enabling more consistent, comparable, and repeatable assessments of security controls with reproducible results



Facilitating more cost-effective assessments of security controls contributing to the determination of overall control effectiveness



Promoting a better understanding of the risks to organizational operations, organizational assets, individuals, other organizations, and the socio-economic environment.

The information about the security risk can be used by an organization to: 

Identify potential problems or shortfalls



Identify information system weaknesses and deficiencies



Prioritize risk mitigation decisions and associated risk mitigation activities



Confirm that identified weaknesses and deficiencies in the information system have been addressed



Inform budgetary decisions and a capital investment process.

1.3 Intended Audience This document is intended to serve diverse individuals associated with the design, development, implementation, operation, maintenance, and disposition of collaborative information systems in terms of the "Continuous Security Risk Reduction" capability set. This capability set is broadly applicable to all kinds of collaborative information systems, including industrial and governmental (critical) infrastructures. While not a prerequisite, greater perception of the resulting enterprise architecture will be gained by a broad understanding of the state of the art in risk and information security management. Expected readers of this document include: 

Individuals with business responsibilities (e.g., heads of organizations, chief executive officers, chief financial officers);



Individuals and organizations with responsibilities for risk management (e.g., heads of organizations, chief executive officers, chief operating officers, Computer Emergency Response Teams (CERTs)/ Computer Security Incident Response Teams (CSIRTs), governmental and regulatory institutions);



Individuals with responsibilities for conducting organizational business functions (e.g., business owners, information owners, authorizing officials);


15


16



Individuals with responsibilities for information system development and integration (e.g., program managers, information technology product developers, information system designers and developers, information systems integrators, enterprise architects, information security architects);



Individuals with responsibilities for acquiring information technology products, services, or information systems (e.g., acquisition officials, procurement officers, contracting officers);



Individuals with responsibilities for information system and/or security management/oversight (e.g., senior leaders, risk executives, authorizing officials, chief information officers, senior information security officer, common control providers);



Individuals with responsibilities for information system/security design, development and implementation (e.g., program managers, enterprise architects, information security architects, information system/security engineers; information systems integrators); Historically information security is treated as Information Technology Security which lack covering business aspects such as instantaneously identifying impacts on the systems operations. Recent advances in the standard infrastructure libraries further integrate implementation of security measures with business needs as risk mitigation.



Individuals with information security implementation and operational responsibilities (e.g., information system owners, common control providers, information owners, business owners, information security architects, information system security engineers/officers); and



Individuals with information system and security control assessment and monitoring responsibilities (e.g., system evaluators, assessors/assessment teams, independent verification and validation assessors, auditors, or information system owners).



1.4 Document Structure The document is a first release and will only address the capability framework and especially the identified sensors. In the ongoing project the missing chapters will be developed supplemented as deliverables. The remainder of this document is organized as follows: 

Chapter 2 - "Basic Concepts" presents fundamental concepts that are applied in developing the identified capabilities. The concepts include emergence, intelligence, game theory and semantics. Similarly, the methodology of enterprise architecture and service orientation is presented for developing capabilities governed by the quality attributes usability, simplicity, scalability and flexibility. Adequate technologies like data mining and human computer interaction are identified supporting quality attributes. This collection spans the multi-discipline results that will contribute to information security, security economics and security collaboration to support information security and risk management.



Chapter 3 - "Continuous Security Risk Reduction" describe the development of a capability set encapsulating "Continuous Security Monitoring", "Continuous Security Model Adaptation", "Continuous Security Economics Analysis", "Continuous Security Awareness" and "Continuous Security Collaboration". This chapter develops the functional high level requirements as well as the architecture guiding quality attributes. The concepts introduced so far are referred and compiled to a concise enterprise architecture. Functionally this architecture will support the ASMONIA project target on continuous improvement of the overall security status by means of a collaborative information exchange.



Chapter 4 - "Continuous Security Monitoring" develop the ability to collect sensor measurements and aggregate them into representations that allow to identify weaknesses in security on the uniform abstraction layer in a timely manner. Therefore suitable sensors and metrics are identified and integrated, leveraging existing sensors as much as possible. The outcome is uniformly described in terms of requirements, module view, component-and-connector view and an allocation view.



Chapter 5 - "Discussion and Summary" summarizes challenges and opportunities for Continuous Security Risk Reduction in terms of maximizing social welfare due collaboration in an organizational context as well as future work.

Supporting appendices provide additional information regarding information security and risk management including: (i) general references; (ii) glossary and abbreviations; and (iii) an excerpt of 3GPP standardization focused on the Policy and Charging Architecture.


17


Figure 3: Document Structure

18



2 Basic Concepts This section summarizes and develops the fundamental concepts for information security, security economics and security collaboration as state of the art of information security management in support of risk management and social welfare to be applied. It provides background necessary to understand design decision but can be skipped by readers that are not interested in fundamentals. Security is not considered as a feature, it is regarded as an emergent property of a socioeconomic technical system. This requires a completely new approach in assessing information security invoking expertise and results from several disciplines. The concepts borrowed from these disciplines will be shortly introduced and used throughout the development of the identified capabilities. Service orientation as conceptually outlined to describe behavior of distributed, loosely coupled systems, because it offers platform independence, well-defined interfaces hence allocation, and enables legacy system integration. From a quality attribute point of view, the primary drivers for service orientation adoption are interoperability and modifiability. Security characteristics are developed to classify behavior with respect to security properties for the conceptual model. This allows to infer security properties about instantiations of the abstraction, e.g. the considered mobile telecommunication network, as well as security properties for any service invocation. Security becomes a set of predicates of a service invocation that is dependent on security measurements, only. The underlying knowledge how to classify a service invocation will be subject to applicable data mining and learning techniques, allowing to address various use context of the information system in focus. The concept of economics applies the notions of agents, interaction, business model, payoff, value and assets to transform detected security deficits to an economic value by applying game theoretic concepts. The processes from which emergent properties result occur in either the observed or observing system, and can commonly be identified by their patterns of accumulating change. Emergent behaviors occur e.g. because of intricate causal relations across different scales and feed back, inter-connectivity or any kind of dependency. The emergent property may be either very predictable or unpredictable and unprecedented, and represent a new level of a system's evolution. The complex behavior or properties are not a property of any single entity, nor can they easily be predicted or deduced from behavior in the lower-level entities, but they can be observed and measured. One reason why emergent behavior is hard to predict is that the number of interactions between components or any evolution of a system or its use increases combinatorial, thus potentially allowing for many new and subtle types of behavior to emerge regardless whether the behavior is intended by an attack or by unintended or unexpected use.


19


2.1 Theory and Methodology 2.1.1 Concept: Emergence Within complex systems patterns arise out of many relatively simple interactions. This effect is due to emergence and appears as a crucial effect as integrative means to measure security. Plain specification of interactions has no causal efficacy and serve merely to describe regularities and consistent relationships. Nevertheless often complex patterns appear. These patterns may be very illuminating and important. Complex socio-economic and technical information systems involves more than the rules. They also comprise agencies, i.e. autonomous entities observing and acting upon an environment and directing their activity towards achieving goals. The collective unfolding of moment-by-moment decisions among a large number of available options at each choice can show emergent properties. Emergence describes properties arising in systems as a result of interactions at an elemental level. Emergence is part of a model that is needed to describe behavior. Security is not a quality that is directly traceable to components. If one is willing to accept that an information system supervenes on its components, then it is difficult to account for an emergent property's cause. Security is irreducible to the system's constituent parts. Emergent property can appear when a number of simple entities operate in an environment, forming more complex behaviors as a collective. If emergence happens over disparate size scales, then the reason is expected to be a causal relation across different scales. In other words there is a form of top-down feedback in systems with emergent properties. The processes from which emergent properties result may occur in either the observed or observing system, and can commonly be identified by their patterns of accumulating change. Emergent behaviors occur e.g. because of intricate causal relations across different scales and feed back, inter-connectivity or any kind of dependency. The emergent property may be either very predictable or unpredictable and unprecedented, and represent a new level of a system's evolution. The complex behavior or properties are not a property of any single such entity, nor can they easily be predicted or deduced from behavior in the lower-level entities, but they can be observed and measured. One reason why emergent behavior is hard to predict is that the number of interactions between components or any evolution of a system or its use increases combinatorial, thus potentially allowing for many new and subtle types of behavior to emerge. Security is an emergent property arising as a result from interactions form may entities like users, providers as well as behavior of invoked technical elements. 2.1.2 Concept: Intelligence Extraction of an operational picture requires intelligence. Intelligence, as exhibited by people, is a complex phenomena. One striking aspect of intelligent behavior is that it is clearly conditioned by knowledge: for a very wide range of activities, one makes decisions about what to do based on what is known (or believed) about the world, effortlessly and unconsciously. Using what is known in this way is so commonplace that one only really pay attention to it when it is not there. When we say that a system has behaved unintelligently, what we mean is not that there is something that the system did not know, but rather that the system has failed to use what it knows. Indeed, it is thinking that is supposed to bring what is relevant in 20


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 what we know to bear on what we are trying to do. Intelligence is treated as intelligent behavior achieved through computational means. And knowledge representation and reasoning is that part that is concerned with how to use what is known in deciding what to do. The usual perception of security is dependent on the expertise of the individual. Some will recognize the impacts of botnets and viruses while others percept security as embedded and existent. The domain of security evolves and require an evolutionary knowledge. Knowledge and reasoning is applied especially for deriving interpretation of security properties. 2.1.2.1 Knowledge Knowledge is a relation between a knower and a proposition, that is expressed by a declarative sentence. The relations are expressed by sentences with verbs like "knows" or "observes" or "thinks". The same proposition involved, but with different relationships means different things.

knows observ es ass umes

Knower

Proposition

expressed as

Sentence

Copyright © 2011 ASMON IA Project. All rights reserved.

Figure 4: Schematic visualization of relationships between knower, proposition and sentence That matters about the proposition is its truth. It is wish able that the sentences expressing the proposition are true or false, and that the propositions themselves are either factual or non-factual. 2.1.2.2 Representation Copyright © 2011 ASMON IA Project. All rights reserved.

Representation is a relationship between two domains, where the first is meant to stand for or take the place of the second. The first domain is more concrete, immediate, or accessible in some way than the second. Of special concern is a group of formal symbols stands for a proposition. The symbolic representing sentence is fairly concrete. The proposition, on the other hand, is abstract. Knowledge representation is concerned with using formal symbols to represent a collection of propositions believed by some putative agent. These symbols must represent all the propositions believed. There may very well be an infinite number of propositions believed, only a finite number of which are ever represented.


21


Domain

Representation Domain

repres ented by

Object

Object representation

C opyright © 2011 ASMONIA Project. All rights reserved.

Figure 5: Schematic visualization of relationships between two domains by means of representations It will be the role of reasoning to bridge the gap between what is represented and what is believed. 2.1.2.3 Reasoning C opyright © 2011 ASMONIA All rightsof reserved . representing a Project. collection believed Reasoning is the formal manipulation of the symbols propositions to produce representations of new ones.

Figure 6: Schematic visualization of reasoning Symbols are more accessible than the propositions they represent: They must be concrete enough that one can manipulate them in such a way as to construct representations of new propositions. Why is knowledge even relevant? The first answer is that it is sometimes useful to describe the behavior of sufficiently complex systems using a vocabulary involving terms like "beliefs," "desires," "goals," or "intentions." 22


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Why Knowledge Representation? Observe that the intentional stance says nothing about what is or is not represented symbolically within a system. The hypothesis is to construct a system that contains symbolic representations with two important properties. First is that from the outside one can understand representations as standing for propositions. Second is that the system is designed to behave the way that it does because of representations. The knowledge representation hypothesis implies a systems for which the intentional stance is grounded by design in symbolic representations. This approach emerges in the desire to build a system that can deal with a set of tasks that is open-ended. For any fixed set of tasks it might work to "compile out" what the system needs to know, but if the set of tasks is not determined in advance, the strategy will not work. The ability to make behavior depend on explicitly represented knowledge seems to pay off when it is impossible to specify in advance how that knowledge will be used. Further, from a system-design point of view, the knowledge-based approach seems to have a number of desirable features e.g. 

the system is evolving



one can extend the existing behavior by adding new beliefs.



one can debug faulty behavior by locating the erroneous beliefs of the system.



one can concisely explain and justify the behavior of the system.

The hallmark of a knowledge-based system is that by design it has the ability to be told facts about its world and adjust its behavior correspondingly. This ability to have some of our actions depend on what we believe is called cognitive penetrability. Why Reasoning? The fundamental concept about reasoning is logical entailment which is a relation between propositions. The propositions represented by a set of sentences S entail the proposition represented by a sentence P when the truth of P is implicit in the truth of the sentences in S. In other words, if the world is such that every element of S comes out true, then P does as well.

Figure 7: Schematic visualization of reasoning and representations All that we require to get some notion of entailment is a language with an account of what it means for a sentence to be true or false. If the representation language is to represent knowledge at all, it must come with such an account. So any knowledge representation,


23

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 whatever other features it may have, whatever syntactic form it may take, whatever reasoning procedures may define over it, ought to have a well-defined notion of entailment. A simple answer to what beliefs a knowledge-based system should exhibit, then, is that it should believe all and only the entailment of what it has explicitly represented. The job of reasoning, then, according to this account, is to compute the entailment. What makes this account simplistic is that there are often quite good reasons not to calculate entailment. The reasoning process might be logically incomplete or might be logically unsound because there are conceptual reasons to consider unsound or incomplete reasoning. Where logic really does pay off from a knowledge representation perspective is at the knowledge level. The idea is that one can understand a knowledge-based system at two different levels. At the knowledge level, e.g. questions concerning the representation language and its semantics. At the symbol level, on the other hand, e.g. questions concerning the computational aspects. At the knowledge level, we deal with the expressive adequacy of a representation language and the characteristics of its entailment relation, including its intrinsic computational complexity; at the symbol level, we ask questions about the computational architecture and the properties of the data structures and reasoning procedures, including their algorithmic complexity. 2.1.3 Concept: Game Theory This section gives a gentle introduction into the subject of strategies and economical games. We introduce the concept of best response, equilibrium, dominance, and mixed strategies. To conceive the concept of rationality we consider the relation between iterated elimination of dominated strategies and equilibrium. Finally we introduce the foundations of mechanism design. Mathematical game theory, as launched by von Neumann and Morgenstern followed by Nash's contributions, has become a standard tool in economics for the description of competition, cooperation, collusion, strategic behavior or bargaining. With the advent of the network game theory became increasingly relevant in computer science and especially security engineering. Game theory deals with strategic games. Strategic games form a simple model of interaction between payoff maximizing parties. Each party has a payoff function that he or she aims to maximize and the value of this function depends on the decision taken simultaneously by the participants, introducing a collaborative aspect. 2.1.3.1 Social Choice We exclude an approach following discrete and effective social choice by a categorical nonfeasibility statement. The main message conveyed about general social choice and the strategic approach to it is that there are unavoidable underlying difficulties. Condorcet's paradox shows that in general a social choice cannot be taken simply by a majority vote. Whenever there are more than two alternatives it is required to design some more complex voting method to undertake a social choice. One of the difficulties encountered by voting methods is that they may encourage strategic voting. Such strategic voting is problematic as it is not transparent, depends closely on the votes of the other voters, and the interaction of many strategic voters is complex. The main result in this context is the Gibbard-Satterthwaite theorem stating that this strategic vulnerability is unavoidable. Theorem (Arrow). Every social welfare function over a set of more than 2 candidates that satisfies unanimity and independence of irrelevant alternatives is a dictatorship. Theorem (Gibbard-Satterthwaite). Every incentive compatible social choice function, having more than 2 agents alternatives, is a dictatorship.

24


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 The Gibbard-Satterthwaite theorem seems to quash any hope of designing incentive compatible social choice functions. But payoff values offer an escape route from these impossibility results. 2.1.3.2 Game Theory Concepts It is known that an agents' preference cannot be easy integrated into social welfare. But model the value of each alternative remains feasible. Although it is not possible to resolve preferences using democratic voting in a social context, money as a yardstick allows inferring a value maximizing strategy. Moreover, money can be easily transferred between agents. The existence of money with such properties is a fairly reasonable assumption in many circumstances, including security concerns. 2.1.3.2.1 Strategic Game Let the participants be a set of selfish acting agents. An agent's strategy is a complete plan of interaction for whatever situation might arise; this fully determines the agent's behavior. An agent's strategy will determine the action the player will take at any stage of the game, for every possible history of play up to that stage. A strategy profile or joint strategy is a set of strategies for each player which fully specifies all actions in a game. A move is an action taken by a player at some point during the play of a game. A strategy on the other hand is a complete algorithm for playing the game, telling an agent what to do for every possible situation. A strategic game consists of a 

non-empty possibly infinite set of strategies and



a real valued payoff function giving the value of a joint strategy (combination of strategies)

for each agent. Agents choose their strategies, subsequently each agent receives a payoff resulting from the joint strategy. Each agent is assumed to act rational meaning that his sole objective is to maximize his value. Let for the moment assume that each player has perfect knowledge of the game and of each involved agent's rationality. 2.1.3.2.2 Best Response, Equilibrium and Dominance A strategy is a best response for an agent to a joint strategy of his opponents, if the agent cannot improve her payoff. A joint strategy is an equilibrium if each agent's strategy is a best response. In other words an equilibrium is a joint strategy, where no party can archive a higher payoff by unilaterally selecting another strategy. A strategy of an agent strictly dominates another strategy of this agent if its payoff is less for any joint strategy. A rational acting agent is assumed to never choose a dominated strategy. Hence when searching for a strategy that is optimal, one can safely remove all strictly dominated


25

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 strategies leading to the notion of a restricted game. The iterated deletion of dominated strategies in a finite game preserves equilibriums and is even order independent. A mixed strategy of an agent is a probability distribution of her strategy. Hence a mixed strategy is a weighted execution of pure strategies. The notion of dominance apply to mixed extensions of finite strategic games, as well. In this setting equilibriums can be characterized by Nash's theorem. Theorem (Nash). Every mixed extension of a finite strategic game has an equilibrium. Backward induction is the process of reasoning backwards in time, from the end of a problem or situation, to determine a sequence of optimal actions. It proceeds by first considering the last time a decision might be made and choosing what to do in any situation at that time. Using this information, one can then determine what to do at the second-to-last time of decision. This process continues backwards until one has determined the best action for every possible situation, i.e. for every possible information set at every point in time. 2.1.3.3 Mechanism Design Mechanism design concerns to arrange economic interactions in such a way that whenever each agent behaves selfish, i.e. in a self-interested manner, the result supports social welfare. The interactions are supposed to yield desired decisions when each agent is interested in maximizing his or her own utility. The challenge is to induce a behavior among the agents to submit genuine, true information. A mechanism assumes each agent 

a non-empty set of decisions,



a non-empty set of types, and



an (initial) real valued utility function from the decision and the type to a value.

A decision rule is a function from the combination of types to the combination of decisions. Decision problems are considered in the presence of a central authority taking the decisions on the basis of information provided by the agents. Given a decision problem the decision desired is obtained by the following procedure: 

Each agent receives or becomes aware of his or her type.



Each agent announces a type to the central authority, yielding a joint type.



The central authority takes the decision from the decision rule and communicates it to each agent.



The resulting utility is computed by the utility function.

The challenge in taking decisions through this procedure is to design a mechanism exploiting the intention of participating agents to maximize their utility under the assumption that they all act rational. Irrational behavior will be penalized with narrow utility. As a matter of fact agents may cheat submitting false information to manipulate the outcome. A decision rule is efficient if for all types the decision rule maximizes the sum of all utilities, i.e. the (initial) social welfare. To prevent manipulations we introduce transfer payments. A transfer payment, also called tax, alters a decision problem by the following extensions  26

the set of decisions is supplemented by a real valued tax vector Copyright © 2011 ASMONIA consortium. All rights reserved.


the decision rule is supplemented by a real valued tax function mapping types taxes and



the (final) utility for an agent is the (initial) utility plus the tax value.

A mechanism with a tax is incentive compatible, if the tax function will award agents announcing true types. Hence rational agents will announce their true type. A Groves mechanism has tax function for each agent composed of two functions g + h, where function g maps the types to the sum of all (initial) utilities of the other agents under the type constraint of the agent and function h maps the types of the other agents to a real value. A mechanism is called feasible, if the mechanism can be realized without external funding. Theorem (Groves). Groves mechanisms with efficient decision rules are incentive compatible. A pre-Bayesian game comprises agents where each agent has a non-empty set of interactions, 

a non-empty set of types, and



a real valued payoff

function mapping the joint interactions and the type of the agent onto the payoff. A pre-Bayesian game is a revelation, if for all agents the interactions are the types. In a revelation the strategies are functions on the types. A strategy is called genuine truth if it is the identity function. Theorem. A mechanism has a canonical revelation game, where the mechanism is incentive compatible, if and only if, in the associated revelation genuine truth is a dominant strategy for all agents. Game theory has major application in economics although recently there is a joining with algorithm design. Both disciplines contribute to security analysis and allow the definition of an integrated universal security approach. 2.1.4 Concept: Semantics Semantics is the rigorous mathematical formulation of the meaning of service formulation and service execution. The formal semantics provides a model of possible computations or executions when a service is invoked. 2.1.4.1 Behavior The behavior of the information system is defined by its observable operations.


27


Figure 8: Schematic visualization of the relationship between Description and Observation by means of behavior Deviation from specified or expected behavior is subject to security risk. Therefore it is necessary to define a coarse but structured operational semantics defining the expected behavior of the information system. The chosen operational semantic specifies the behavior in terms of transitions or events, where rules define the valid transitions. Such a definition allows formal analysis of the behavior. A state transition system comprises a set of states and a binary transition relation, that is a binary transition relation over the set of states. A transition system is labeled if it comprises additionally a set of labels and a ternary transition relation of labeled transitions.

Figure 9: Schematic visualization of a labeled transition system The transitions correspond to observable operations. Beside the defined and expected behavior there is an observable behavior. Observable behavior is a transition system that is constructed from observed events on the information system.

28


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Figure 10: Schematic visualization of the relationship between measurements and the transition system by means of observations 2.1.4.2 Simulation The most important relations between these two transition systems are simulation preorders. A simulation relation (pre-order) is a binary relation between transition systems. A transition system is simulated by another if there is a relation between the states of simulated and the simulating transition system each two states such that for every transition between two states of the simulated transition system there is a transition between the related states in the simulating transition system. Simulations allows to compare observable behavior with a behavior declaration by means of a reference. 2.1.4.3 Denotation A compact description for interaction inside the information system are sequence diagrams. A sequence diagram (interaction diagrams) shows how processes interact with one another and in what order. It comprises 

parallel vertical lines (lifelines) for different objects that live simultaneously, and



horizontal arrows (interaction) where the messages exchanged between objects, in the order in which they occur.

Objects could be decomposed recursively. A object is a decompose-able unit of the information system that provides an interface supporting interaction with other objects. An object type is a set of objects having comparable interactions


29


Figure 11: Schematic visualization of an interaction diagram 2.1.4.4 Decomposition Ensembles support a representation for decompositions. To define a model space and unify the possible objects ensembles are introduced. Ensembles are the unifying abstraction for object decomposition and composition. An ensemble represents a set of interactions among objects or object types that cooperate through interactions to provide some useful and predicted aggregate behavior. A blackboard is an instantiation of an ensemble for a subset of interactions within the scope of the ensemble.

30



Figure 12: Schematic visualization of blackboards Objects and events could have properties which are addressed in the next three definitions. A credential denotes a property of an object. It is a triple comprising 

a name of the object's property,



the value of this property, and



the description of the means to obtain this value.

Credentials allow to tag knowledge and to describe how this knowledge is obtained. Properties can range from version statements, which might be verified by comparing the component with an original or by verifying a certificate etc. Conjectures correspond to unknown proofs of properties. Conjectures are the means to identify incomplete knowledge. For an event or interaction a similar concept applies. A constraint denotes a property of an interaction. It is a triple comprising 

a name of the object's property,



the value of this property, and



the description of the means to obtain this value.

Credentials and constraints allow to tag knowledge and to describe how this knowledge is obtained. Whenever the property is not known but is relevant we introduce a third kind of tag. A conjecture denotes an assumption of an unknown property. It is a triple comprising 

property name,



value is a possibly undefined value of this property, and



the means that was used to obtain this value.


31

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Conjectures correspond to unknown proofs of properties. Origins might be experience or mining results. Conjectures are the means to identify incomplete knowledge and if becoming relevant form requirements for sensor services. For developing economics in the security domain for an evolving system it is a perquisite to develop a clear and concise description of security properties that are independent from the application or technical domain although applicative. This enables the formalization of behavior. 2.1.5 Methodology: Enterprise Architecture An enterprise architecture is a rigorous structural holistic description of an enterprise or society, which comprises enterprise elements (business entities, agents), the externally visible properties of those elements, and the relationships (e.g. the behavior) between them. Enterprise architecture describes the terminology, the composition of enterprise elements, and their relationships with the external environment, and the guiding principles for development and evolution of an enterprise. Architecture is seen as the process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle. Architecture (of a system) are the fundamental concepts or properties of a system in its environment embodied in elements, relationships, and principles of its design and evolution. Four architecture domains are commonly accepted 

The Business Architecture defines the business strategy, governance, organization, and key business processes.



The Data Architecture describes the structure of an organization's logical and physical data assets and data management resources.



The Application Architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.



The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middle-ware, networks, communications, processing, standards, etc.

Developing architecture content, transitioning, and governing the realization of architectures are carried out within an iterative cycle of continuous phases A Preliminary Phase comprises the preparation and initiation activities required to prepare to meet the business directive for a new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles. This is followed by

32



Phase A: Architecture Vision … the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Vision, and obtaining approvals.



Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.



Phase C: Information Systems Architectures … the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.



Phase D: Technology Architecture: the development of the Technology Architecture for an architecture project.



Phase E: Opportunities & Solutions: initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.



Phase F: Migration Planning: the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan.



Phase G: Implementation Governance: an oversight of the implementation.



Phase H: Architecture Change Management: procedures for managing change.

Requirements Management examines the process of managing architecture requirements throughout.

Figure 13 Enterprise Architecture Development according to TOGAF 2.1.5.1 Views Complex architecture practice embraces the concept of views. A view is a representation of a set of elements and the relations associated with them. Views are representations of the many structures present simultaneously. Mobile telecommunication networks are too complex to be grasped all at once. Instead, we restrict our attention at any one moment to a small number of the structures, which we represent as views. Views can be categorized according to the kind of information they convey: 

Module view describing the organization of the implementation units


33


Component-and-connector view describing how the communication system is to be structured as a set of interfacing and interacting structural elements.



Allocation view describing how the communication system relates to its environment.

A particular view of a system may fall into one of these categories or combine information from more than one category. 2.1.5.1.1 Module View This view describes the structural decomposition. Element is the implementation units, called modules that provide a coherent set of responsibilities. Relations are 

is-part-of defining the part whole relationship between modules



depends-on defining a dependency relationship between modules



is-a defines a generalization / specialization relationship between modules

Module views might impose topological constraints. This view facilitates impact analysis and supports traceability It explains the functionality and the structure of the system. It supports the definition of work assignments and shows the structure of the information to be persisted. 2.1.5.1.2 Component-and-Connector View This view describes how the system executes function. Elements are 

Components as the principal processing units and data stores. A component has a set of ports through which it interacts with other components.



Connectors are pathways of interaction between components. Connectors have a set of roles that indicate how a components will use connectors in interactions

Relation is 

attached-to, component's ports are associated with connector roles to yield a graph of component and connectors.

Components can be attached only to compatible connectors and connectors can only be attached to components. Attachment can only be made between compatible components and connectors This view shows how the system works and guides the development by specifying the structure and behavior. It assists in reasoning about the run-time system quality attributes.

34



2.1.5.1.3 Allocation views This view describes the deployment, i.e. the mapping of components and connectors to the computational platform Elements are 

Software Elements from a component-and-connector view



Environmental Elements such as computational resources or storage including relevant properties

Relations are 

allocated-to between units and software elements where the software elements reside



migrates-to if the allocation is dynamic

2.1.5.2 Service Orientation Service orientation or service oriented architecture (SOA) is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers standardization, platform independence, well-defined interfaces, and enables legacy system integration. From a quality attribute point of view, the primary drivers for service orientation adoption are interoperability and modifiability. A common misconception is that an architecture that uses a service-oriented approach can achieve these qualities by simply putting together a set of vendor products that provide an infrastructure and then using this infrastructure to expose a set of reusable services to build systems. Open, complex and distributed collaborative information systems with large number of providers and consumers are intended to interact collaboratively by means of services. The underlying enterprise architecture should therefore be prescriptive and not only descriptive. However, enforcing architecture requires architecture governance as a way to be prescriptive about architecture. There is a two-way relationship between architecture and governance that can be exploited for mutual benefit where service orientation payoff. In general, there are three types of governance: 

Design-time governance: Includes elements such as rules for strategic identification, reuse, development, and deployment of services, as well as policies to enforce consistency in aspects such as use of standards, reference architectures, and processes.



Runtime governance: Includes policies and enforcement rules to ensure that services are executed according to policy and that important runtime data is logged.



Change-time governance: Applies to maintenance and evolution of service-oriented systems and includes policies and enforcement rules for maintenance and evolution of all elements of service-oriented systems as well as communication of changes to stakeholders.

Architecture governance is defined by The Open Group as “[...] the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level [...]” and includes “[…] controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization.”


35

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 The loosely coupled nature of service-oriented systems enables system elements to evolve independently. Therefore, the type of control that is implied by the definition of architecture governance is key to following and preserving SOA architectural principles. Service-Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing systems, in which 

Services provide reusable business functionality via well-defined interfaces.



A clear separation between service interface and service implementation exists.



Service consumers are built using functionality from available services.



An infrastructure enables discovery, composition, and invocation of services.

From a technical point of view, SOA is an architectural style or design paradigm; it is neither a system architecture nor a complete system. Services are reusable components that represent business or operational tasks. Reusable is a key element because it enables the creation of new processes based on these services. Services expose their capabilities via well-defined interfaces. In a service-oriented environment, service interface definitions are available in some form of service registry. The service implementation corresponds to the actual system capabilities that implement the service interface. Service consumers access the services via standardized service interfaces that hide the complexity and diversity of service implementations from consumers. Service consumers are the clients for the functionality provided by the services. The organization that hosts a service implementation is referred to as the service provider. An SOA infrastructure is the set of technologies that bind service consumers to services through an agreed-upon communication model, such as one based on Web Services, message-oriented middleware, publish/subscribe, etc. In addition, SOA infrastructures typically host infrastructure services that can be used by service providers and service consumers to perform common tasks or satisfy quality attribute requirements of the environment. Typical infrastructure services include security, discovery, and data transformation. Service discovery is the mechanism by which service consumers become aware of available services and their capabilities. Service discovery starts with a one-time operation in which the service provider publishes its service in some form of service registry. The service registry is then queried by service consumers with desired capabilities. Service composition is the mechanism by which services are combined to fulfill a business or operational process. Service invocation is the mechanism by which services are invoked by service consumers at runtime. There are two basic invocation patterns: point-to-point and mediated. In the point-to-point invocation pattern, service consumers directly invoke services over a network. Point-to-point is most acceptable in environments that are small in number of services and consumers, homogenous in implementation technologies, and have low pace of change. In the mediated pattern, service consumers invoke services via a middleware component. The mediated pattern is most acceptable in environments that are large in number of services and consumers, technologically diverse and rapidly changing. SOA governance provides a set of policies, rules, and enforcement mechanisms for developing, using, and evolving SOA assets and for analysis of their business value. 36


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 2.1.6 Technology: Data Mining Data mining or knowledge discovery is an interdisciplinary field in computer science. It is the process of extracting patterns from large data sets by combining methods from statistics, artificial intelligence and database management. It supports the process of analyzing data from different perspectives and summarizing it into useful information. Recent technical advances in processing power, storage capacity, and inter-connectivity enable data mining as a method to transform unprecedented quantities of data into business intelligence giving an informational advantage. Within this project the method is used for the monitoring of the behavior and activities, or other changing information. Data are any facts or measurements that can be processed by a computer. This includes operational or transactional data, nonoperational data. The patterns, associations, or relationships among all this data can provide information. Information can be converted into knowledge about historical patterns and future trends. The CRoss Industry Standard Process for Data Mining (CRISP-DM) is a data mining process model that describes common approaches that data miners use to solve problems. It defines six phases where business understanding, data understanding, and data preparation are generically treated. Modeling, evaluation, and deployment and an instrumentation will be provided by a continuous process comprising the three phases: pre-processing, data mining, and results validation. While large-scale information technology has been evolving separate transaction and analytical systems, data mining provides the link. Data mining software analyzes relationships and patterns in stored transaction data based on open-ended queries. There are four types of relationships: 

Classes: Data is used to locate data in predetermined groups.



Clusters: Data are grouped according to logical relationships.



Associations: Data can be mined to identify associations.



Sequential patterns: Data is mined to anticipate behavior patterns and trends.

Among others the following types of analysis are available: 

Artificial neural networks / vector support machines: Non-linear predictive models that learn through training and resemble neural networks in structure.



Genetic algorithms: Optimization techniques that use processes such as genetic combination, mutation, and natural selection in a design based on the concepts of evolution.



Decision trees: Tree-shaped structures that represent sets of decisions. These decisions generate rules for the classification of a dataset.



Nearest neighbor method: A technique that classifies each record in a dataset based on a combination of the classes of the record(s) most similar to it in a historical dataset. Sometimes called the k nearest neighbor technique.



Rule induction: The extraction of useful rules from data based on statistical significance.



Data visualization: The multidimensional data.

visual

interpretation


of

complex

relationships

in

37

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Data mining applications are available on various sized systems. There are two critical parameters for computational complexity size of the database and query complexity. Relational database storage and management technology is adequate for many data mining applications less than 50 gigabytes. However, this infrastructure needs to be significantly enhanced to support larger applications. Some vendors have added extensive indexing capabilities to improve query performance. Others use hardware architectures supporting massively parallelism to achieve improvements in query time. 2.1.6.1 Mining Process Before data mining algorithms can be used, a target data set must be assembled. As data mining can only uncover patterns already present in the data, the target data set must be large enough to contain these patterns while remaining concise enough to be mined in an acceptable time frame. The target set is then cleaned. Cleaning removes the observations with noise and erroneous or missing data. Data mining commonly involves four classes of tasks 

Association learning, comprising the search for relationships between variables.



Clustering as the task of discovering groups and structures in the data that are in some way "similar".



Classification, i.e. the task of generalizing known structure to apply to new data. Common algorithms include decision tree learning, naive Bayesian classification, nearest neighbor, neuronal networks or vector support machines.



Regression attempts to find a function which models the data with the least error.

The final step of knowledge discovery from data is to verify the patterns produced by the data mining algorithms occur in the wider data set. Not all patterns found by the data mining algorithms are necessarily valid. It is common for the data mining algorithms to find patterns in the training set which are not present in the general data set. To overcome this, the evaluation uses a reference set of data on which the data mining algorithm was not trained. The learned patterns are applied to this test set and the resulting output is compared to the desired output. The accuracy of these patterns can then be measured from how many samples they correctly classify. A number of statistical methods may be used to evaluate the algorithm. If the learned patterns do not meet the desired standards, then it is necessary to re-evaluate and change the pre-processing and data mining. If the learned patterns do meet the desired standards then the final step is to interpret the learned patterns and turn them into knowledge. For analyzing behavior it is necessary to identify behavioral patterns which is subject to machine learning and treated by applying data mining approaches. 2.1.7 Technology: Human Computer Interaction Within the project an agent user will be confronted with a huge information overload, whether productive or receptive. It might be easy to obtain the information, but few methods are known being capable of processing it and assisting to understand it. On e of them used are semantic zoom-able presentations. A zooming user interface is a graphical environment where users are able to change the scale of a viewed area in order to explore more detail or less, and browse through different information presentations. Information elements appear directly on an infinite virtual pane

38


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 instead of in windows. Users can pan zoom into objects of interest.

across the virtual surface in two dimensions and

The pan and zooming is the main metaphor for information discovery through dependent or multivariate information (compassing simultaneous observation and analysis of more than one variable). Objects present inside a zoomed page can in turn be zoomed themselves to reveal further detail, allowing recursive nesting, adequate morphing and an arbitrary level of zoom. Semantic zooming is to adapt smoothly the level of detail present in the re-sized object is changed to fit the relevant information into the current size, instead of being a proportional view of the whole object. This metaphor allows to adapt information presentation on the relevance by focusing the pan and the object at the appropriate semantic level with appropriate presentation means. The use of this approach is to create ambient intelligence. The ambient intelligence paradigm builds upon ubiquitous computing, profiling, context awareness and human-centric / role computer interaction design having the following features 

embedded: many linked devices are integrated into one environment



context aware: these devices can recognize situational context



personalized: the environment is tailorable to user needs



adaptive: the environment can change in response to situation



anticipatory: the ability to anticipate desires without conscious mediation.

Ambient intelligence is closely related to the long-term vision of an intelligent systems in which technologies are able to automate a platform embedding the required devices for powering context aware, personalized, adaptive and anticipatory services.

2.2 Service Orientation, Monitoring and Tracing 2.2.1 Service Orientation Service orientation as conceptually outlined is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers standardization, platform independence, well-defined interfaces, and enables legacy system integration. From a quality attribute point of view, the primary drivers for service orientation adoption are interoperability and modifiability. Therefore open, complex and distributed collaborative information systems with large number of providers and consumers are intended to interact collaboratively by means of services. As a corollary the services the to be observed or supervised collaborative information systems and the to be developed observing or supervising system are made out of the same reusable elements: Services.


39


Figure 14: Service orientation within ASMONIA 2.2.2 Services These complex and distributed collaborative information systems are used for service provisioning and service consumption. The information system has a defined, even standardized operational semantics, and thus a defined expected behavior. The behavior of the information system results from service invocations. A service is a capability provided via an information system infrastructure in the context of an invocation.

Figure 15: Mobile Services Classification according to [SAFECOM] Services are considered as things of value. An asset is anything (tangible or intangible) of value. Information is knowledge enabling a capability that might be provided as a service. Information is another kind of asset. Information affects its context and information provisioning is considered as service.

40


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 2.2.2.1 Invocation Telecommunication services are usually categorized into top-level services, basic services and functional services, where functional services are considered as atomic and provided by one component. Other services are compositions. Invocation of a service is an observable action within the information system. A service invocation can be decomposed into further service invocations by means of the defined sequence diagrams. The characteristic for a sequence diagram describing a service is that the service invocation starts with a service request and ends with a corresponding service response completing the service fulfillment. The objects like components or subsystems provisioning the service are the objects in the sequence diagram. Usually interaction diagrams are used to specify interaction, i.e. to clarify the required service's semantic for development of a service implementation. This works also the other way around. By observing any interactions it is possible to reconstruct such diagrams from observing interactions. The results are not unique but the gathered objects together with constraints and credentials allow generically to observe service invocations and their security characteristics. The method is to trace a service invocation by observing related interactions and to glue the discovered graph of interactions by matching similar objects and messages. 2.2.2.2 Reconstruction Formally, a transition system can be constructed where the states are objects with a (local) time stamp and the transitions are the transitions are the messages that are sent at a first object and received at another at certain times. The algorithm is to use information messages to identify the sending object and the receiving object, ask the respective objects about their local time of sending and receiving and to complement the graph by transitions between states of the same object with consecutive time stamps.

Figure 16: Service decomposition


41

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Theorem. It is possible to conclude for a service invocation 

the timing of the events by chasing the related transition system



the invocation of any object

from the exchanged and observable message traces. Let a constellation of a service invocation be the related transition system. The constellation comprises the information about the set of invoked objects and the corresponding events with timing. Since it is formally possible to compare transition systems by simulation pre-order a constellation is suitable to expatiate operational behavior. Theorem. A constellation expatiate operational behavior. In addition it is possible to aggregate contextual measurements made at any involved object to a constellation because it declares time and identifies object. Theorem. A constellation can aggregate object measurements, , i.e. credentials. These measurements made at certain objects might evaluate properties of messages. Theorem. A constellation can aggregate message measurements, i.e. constraints. Let the canonical sequence chart of a constellation be the sequence chart comprising the objects with their timings form the lifelines and the transitions or messages correspond to interactions. The constellation is the aggregator of all monitoring results. It is an information collection that provides interaction tracing some service invocations down to invoked objects and events and involved components within the information system contributing to this service invocations. At the end it is the fundamental concept to compare and observe behavior. 2.2.2.3 Organization The information system is concreted by an infrastructure comprising components (objects or blackboards), which are finally able to provide functional services. A component is a unit implementation that 

is produced by a vendor who sells the component or licenses its use



is released by its vendor



provides an (service) interface for interaction with other components.

In the view of the heterogeneity imposed an additional classification scheme to partition the universal set of components into meaningful subsets are needed, where these subsets contain components that share properties. Such subsets can be arranged in an arbitrarily complex taxonomy although two classifiers seem to be useful because of the market driven component evolutions: technology and product - both forming blackboards of a suitable ensemble type. A technology contains the set of all components that have comparable functionality / interface for interaction. A product contains the set of all components provided by a particular vendor that satisfy the technology criteria.

42



Figure 17: Schematic visualization of ensembles Ensembles and blackboards support a representation for technical (observable) interaction. This is not too different from the UML definition of collaboration. In place of "society of roles and other elements" technologies, products, and components are used. UML collaboration is said to define an interaction, whereas an ensemble defines a set of interactions. This is a subtle but important distinction. An ensemble is a set of interactions among technologies, products, and components that cooperate through these interactions to provide some useful and predicted aggregate behavior. An ensemble as a composition of one or more interactions, where each interaction is an N-ary association between anything that can possess properties. A blackboard is an instantiation of an ensemble for a subset of interactions within the scope of an ensemble. Blackboards might refer a mix of credentials, conjectures and constraints. The more a system depends on disparate components, especially components in innovative technology areas, the more the analysis resembles a journey of exploration as lined out by the discovering algorithm yielding constellations. Specification or design time definition is error prone and cumbersome with regard to evolution because of the many dependencies that could be derived while service invocation. Hence the denotational objects of the operational semantic are structurally explored and reconstructed rather than assumed. The challenge is that the technology and the product have influences on properties. One might think that this exceeds the complexity because of the manifold of possible executions of any combination but there is a relatively simple approach to manage this complexity because every service specification can be translated into a canonical transition system which can also be supplemented with specified constraints and credentials. Theorem: For each combination of any objects, components, technologies or products within any possible blackboard of any ensemble type there is a canonical transition system. The admissible transition systems is the set of canonical transition systems derived from specified blackboards. Copyright © 2011 ASMONIA consortium. All rights reserved.

43


2.3 Behavioral Security 2.3.1 Collaboration and Security Open, complex and distributed collaborative information systems with large number of providers and consumers is threatened by (cyber) attacks from parties that have interest in misuse. These information systems consist of disparate domains belonging to parties with divergent interests. These parties are intended to interact collaboratively. This interaction of the involved parties determines the security of the information system. Security has conjectured a deep impact on the economic payoff. However the relation between security and payoff is rather opaque. Security can be considered as a strategic game where the parties can choose security means against unknown threats to protect their and others domains to maximize their payoff. Thus the economics of security has recently become a thriving and fast-moving discipline, identifying advantageous interactions in this collaborative scenario and enlighten the opaque relation between security and payoff. To provide valuable insights in this direction we develop a model unifying the concepts of economics, collaboration and security. The recurring concept collaboration describes how selfish parties, called agents, interact within the information system to reach their interests. Collaborative interaction can be found both inter- and intra-agent with respect to the aforementioned domains, and is also present within opposing interests. How a specific agent interacts collaboratively (or selfish) should be a rational decision maximizing the specific agents overall payoff. The agents will decide on their alternatives according to their divergent interests, their strategies, and the payoff, which will be determined by the agent's respective business models for each combination of strategies. The board of this game theoretic perspective is the collaborative information system. It allows agents consume or provide assets according to the real behavior of the information system. The information system has a defined operational semantics, and thus a well-defined expected behavior. But there are effects that cause behavior deviations. These behavior deviations imply security risk which is defined by the economical impact of the behavioral deviation. In consideration of security risk a social welfare value is incorporated in the payoff. The agents can implement countermeasures that ensure the convergence of real behavior and expected behavior. So they can influence the security risk thus the payoff. The concept security is seen as measurable characteristics within the information system classifying behavioral deviation. Presence of these characteristics makes the information system secure. 2.3.2 Security Characteristics and Measurements A Security Characteristic is a measurable property derived from detectors/sensors that allow identifying behavioral deviation. Security characteristics are categorized into:

44



Confidentiality: Ensuring that any services or information is protected against unauthorized agents.



Integrity: Ensuring that services and information are resistant and resilient against unauthorized modifications. o

Accountability: Ensuring that interactions are traceable with attribution of the responsible agents.

o

Authenticity: Ensuring that the interactions and the interacting agents are genuine.



Availability: Ensuring that any services or information is accessible when needed.

This characteristics has a leverage on the value mechanisms. Hence the occurrence or their establishment, security characteristics influence specific business decisions of the interacting parties according to their interests and influence collaborative security risk for an risk analysis and proactive intelligence gathering. A risk is understood as a measure of the extent to which an agent is threatened by a potential circumstance or event, and typically a function of the adverse impacts that would arise if the circumstance or event occurs. The security risk is the expectation value of a random variable for the damage caused by violating security characteristics. Hence security risks are those risks that arise from the absence of confidentiality, integrity, or availability of information, services or information systems and reflect the potential adverse impacts to agents' assets. In mathematical terms security risk is the expectation value of economic loss due to insecure operation which is approximated by summarizing realized and observed loss. The density or the probability function and even the random variable itself is unknown. measurement is a means to approximate the value of this random variable. Measurement is the process or the result of determining the magnitude of a quantity defined by a sensor relative to a unit of measurement. To effectively measure security characteristics and their impact it is necessary to define the properties by which these characteristics can be described. This set of properties whose presence or absence of the ground truth ensures security. Beside that there is a set of influential properties that do not directly ensure security but enable to characterization. There are many references for security characteristics but in literal terms security means 

The information system must ensure that any of its characteristics including its relationships with its execution environment and its users', it's managed assets, or its content are obscured or hidden from unauthorized entities.



The information system and its managed assets must be resistant and resilient to subversion. Subversion is achieved through unauthorized modifications to the implementation, managed assets, configuration, all behave year by authorized entities or any modifications by an authorized entities. Such modifications may include overwriting corruption tempering distraction insertion of unintended including malicious logic or deletion.



The information system must be in operation and accessible to its intended, authorized users when ever it is needed. At the same time, its functionality and privileges must be inaccessible to unauthorized users.



All security relevant actions off the information system must be recalled and tracked, with attribution of responsibility. This tracking must be possible while and after the recorded actions occur. The audit trail should indicate which actions are considered as security relevant.



The information system should prevent disproving or denying responsibility for actions it has performed.

Effects of a security breach are considered in terms of effects on these core properties by means of concrete observations in terms of measurements. Tracking measurements that witness about the presence or absence of these characteristics need to be identified. Monitoring these measurements has a side benefit because they could provide a true operational security view for exploration. If every security-relevant measurement reported to


45

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 a clearing house that there was an incident with its impact, it would represent a very accurate picture of the scope of any given threat. Unlike today when organizations are loathe to report incidents because of the risk of bad publicity. Data reported would not reveal any information beyond privacy concerns, leading to reports like "The attack failed or has been neutralized." This spans a market for independent institutions that deal with threat information secrets. Knowing the nationwide scope of attacks would yield to an invaluable information that is unavailable today. 2.3.3 Measuring Security Characteristics The security measurements are categorized by means of decomposition into sequence diagrams defining a service. 

Confidentiality Measurements are defined by constraints before and while a service invocation. This is usually the presence of a valid authentication and authorization sequence.



Integrity Measurements are defined by constraints and credentials ensuring that service invocations and information are resistant and resilient against unauthorized modifications. For service invocations this is done by ensuring the integrity asserting credentials of invoked objects and the integrity ensuring constraints (e.g. encryption) on interactions with proper instrumentation.



Availability Measurements are defined by credentials and constraints ensuring the timely availability of requested resources as objects or interactions with appropriate quality of service within a service invocation.

To create secure and reliable information systems it seems to be necessary continuously anticipating abnormal behavior. Unfortunately, security requirements are often simply linked with function those security features and mechanisms somewhere, is fuming that they doing so will address security needs throughout a system. Generally security isn't an emergent property of the system, not a feature. Because security is not a feature it cannot be voted on, knowledge can be patched in after attacks have occurred. One of the major security goals is to identify misuse and abuse cases which is done by the catalog of characterizing measurements. By reconstructing the admissible transition system comprising all applicable credentials and constraints there is a pool of potential secure behaviors. By reconstruction of a constellation it becomes possible to simulate and verify the constellation against the admissible systems. The set of admissible systems can be filtered by matching states and transition as well as by the decoration of measurements made. Theorem: A service invocation is secure (confidential, integer, available), if there is an admissible transition system simulating the constellation. Since service invocations are the sole economic interaction we are now in the position to exactly measure the loss due to security violations. 2.3.3.1 Detection and Recursion Consider for example the security characteristics integrity. Integrity is the characteristic ensuring that services and information are resistant and resilient against unauthorized modifications. This applies for data transport within a network as well as with executable software items on a network node. Integrity detection for a component is assumed to be provided by integrity sensors. These sensor support the underlying security mode. For instance a smartphone might run a malware scanner that validates applications by ensuring that there is no match to any known malicious fragments. The concept of an ensemble with 46


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 integrity predicates might also be applicable recursive. Concretely this might be realized by a monitor for this smartphone ensuring that there are only integer states, e.g. allowed threads of signed applications. In other words there are sensors measuring whether a constellation of components is considered as integer by evaluating the integrity predicates for any component and for the constellation. For instance a constellation could be considered as not-integer because there is a component detected that matches a malware pattern. Another example could be the default software constellation of a smartphone that is considered to be integer. Note that the smartphone is here considered as a service in order to enable formal service composition. Such information might be of relevance and will be attached to the corresponding component object as a evolution life cycle. From an evaluation point of view there are three answers for a constellation either it is integer or it is not integer or it is unknown. An economic (online) analysis could benefit of any security measurement and any information attached to any component or constellation because discriminating insecure set of constellations due to shared attached information indicates concrete properties of components which might be attacked or cause insecure behavior. The model space unifies all known approaches and can cope with the heterogeneity and evolution complexity of ensembles regardless for components or constellations. The intuition behind these concepts is simple. Since there are bound to be many unknowns, a denotation that exposes areas of uncertainty is needed. As a notion of catalog ensembles, blackboards, credentials and constraints are introduced. Blackboards are instrumental for security characteristics exploration. As a by-product, critical component properties and unexpected interactions might be discovered. This leads to an ultimately deeper understanding of what is needed to make ensembles secure and work properly. The evaluation is abstracted to a security guard. Security guards for services being evaluations of the truth of constraints and credentials that are invoked. 2.3.3.2 Integrity Detection Integrity is defined as being resistant and resilient against unauthorized modifications. Integrity is only assumed for constellations 

containing only integer objects and



simulated by an admissible transition systems.

That means there are security guard predicates telling whether a constellation is considered as integer. 2.3.3.3 Confidentiality Detection Confidentiality is defined as ensuring that any services and information are protected against unauthorized parties. Confidentiality is only assumed for constellations 

containing only confidential objects and



simulated by an admissible transition systems.

That means there are security guard predicate telling whether a constellation is considered as confidential.


47

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 2.3.3.4 Availability Detection Availability is defined as ensuring that any service or information is accessible when needed within specified quality of service. Availability is only assumed for constellations 

containing only available objects,



simulated by an admissible transition systems, and



the provisioning indicated by the constellation is within specified parameters.

Quality of service might be elapsed time or reaction time, i.e. the time between request and response

2.4 Security Economics 2.4.1 Quantifying the Economic Impact How should a data gathering and analysis system facilitate the collection of well-defined, consistent metrics to measure the financial impact of security incidents and investments in security protection? Even if security investments deemed appropriate for the investor owned utility they may be deferred or denied for unrelated or political reasons such as a perceived need to restrain consumer prices or simply political pressure to appear to be consumer friendly. Regardless of the possible larger picture wisdom of these decisions the fact is that the economics are convoluted and must be clearly understood. The economics of these portions of the critical infrastructure maybe substantially different from those that govern other aspects of the infrastructure which do not operate under social contracts. One of the most common wrong assumptions made is that if the impact of security incidents are sever, than it will naturally follow that adequate investments stop the attacks. A corollary to this belief is that bad behavior, including inadequate security investments will naturally be sanctioned economically and this economic penalty will provide a check on poor security practices. The assumption betrays a misunderstanding of the unique characteristics of security. One conclusion is simply something that legal theorists have long known before: Liability should be assigned to the part that can best manage the risk. Yet everywhere online risk seems to be allocated poorly: For instance people who connect insecure machines to the Internet do not bear the full consequences of their actions and developers are not compensated for costly efforts to strengthen their systems. Security engineering must shift from the technology-heavy, tactical operation to an intelligence-centric, risk analysis philosophy. It is not sufficient to understand the importance of security, one need to be able to make business and investment decisions based on knowledge of risks and potential impacts. If the risks and consequences can be assigned monetary value, organizations will have greater ability and incentive to address security. Often there is a lacking business case to justify the resource expenditures needed for integrating security and for engaging partnerships to collectively mitigate security risk. One side benefits of the approach is that it is the basis of a true common operational picture. If every security relevant measurement reported back to a clearing house that there was an incident, it would, given the potentially hundreds of thousands of devices reporting in, represent a very accurate picture of the scope of any given attack at any scale. While we believe this approach will be a game changer because the model envisions incentive compatible re-claiming and conflict resolving. The factual approach to increase security is expected to create the necessary trust relationships required to make this model work. Participating agents must be assured that there is no negative connotation to

48


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 submitting e.g. threat data. The simple imperative of getting security relevant information out to the broadest possible audience must take precedence. 2.4.2 Information Security The concept security is a set of characteristics of service invocations carried out by a collaborative information system. Hence the Security Characteristics 

Confidentiality: asset is protected against unauthorized agents.



Integrity: assets are resistant and resilient against unauthorized modifications



Availability: assets are responding within an adequate time frame and quality of service

classify insecure and secure service invocations, where insecure services will lead to a security risk. It can be assumed that directed inter-agent collaboration will improve detection of insecure behavior and increase information security as social welfare. For true and effective collaboration the agents need to be motivated by an incentive compatible mechanism. This concept, borrowed from economics science, enables analyzing provisioning and consumption of information and services deployed by the information system and is suited to motivate agents increasing social welfare. As described above information and services are the considered assets. Economics aims to explain how the information system works and how agents will interact, i.e. how parties consume or provide assets following a strategy, in order to maximize their payoff within a strategic game. Provisioning and consumption of assets, i.e. the possible interactions, is the degree of freedom for any party to decide. A party's business model declares how this party creates, delivers and captures value. The to-be-defined mechanism will especially suited to identify the economic impact of security and to recommend business decisions for interactions that maximizes payoff and increases social welfare. These decisions, explicit or implicit, depict a strategy in the to-be-discovered strategic game. 2.4.3 Interaction and Economy Security itself can be considered as an economic game, where the parties can choose security services or secure services to protect themselves and others to maximize their relative payoff. The economics of security has recently become a thriving and fast-moving discipline, identifying advantageous interactions in this collaborative scenario and enlighten the opaque relation between security and payoff. To provide valuable insights in this direction we develop a model unifying the concepts of economics, collaboration and security. Game theory enables analyzing provisioning and consumption of information and services deployed by the information system. Application of game theory aims to explain how the information system works and how the parties interact, i.e. how the parties consume or provide assets in order to maximize their payoff. Provisioning and consumption of assets is a type of interaction, i.e. the degree of freedom for any party to decide in terms of consuming or provisioning services or information within the collaborative information system. It is expected that the transparency about the distribution of security characteristics of a service will influence the market of service offering. A business model provides a rationale of how and by what service offer this party creates, delivers and captures value.


49

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 The term business model is used for a broad range of descriptions to represent core aspects of a business. Here it describes the design of value mechanisms, i.e. creating, delivering and capturing value by a specific party. These value mechanism is especially used to identify the economic impact of security and to recommend business decisions for interactions that maximizes payoff. These decisions, explicit or implicit, depict a strategy as a set of interactions by the participating parties based on assumptions of these parties behavior within the economics. The ever recurring concept is collaboration. Collaboration describes how the parties or agents interact within the information system to reach their interests. Agents are considered as autonomous selfish entities that intend to maximize their payoff. Collaborative interaction can be found both inter- and intra-agent with respect to the aforementioned domains, and is also present within opposing interests. How a specific agent interacts collaboratively (or selfish) should be a rational decision maximizing the specific agent's payoff, i.e. by selecting a best response in the underlying game. So there is a connection between business models and collaboration, too. The agents will decide on their alternatives according to their divergent interests, their strategies, and their payoff, which will be determined by the agents' respective strategies. The board of this game theoretic perspective is the collaborative information system. It allows agents to consume or provide assets according to the real behavior or intention of the information system. Although the information system usually follows an expected behavior according to a defined semantics, deviation occurs, i.e. an abnormal behavior. These behavior deviations imply security risk which is defined by the economic impact of this deviation. Reduction of security risk is considered as the social welfare. The agents can implement countermeasures and controls that ensure the convergence of expected and observed behavior. So they can influence the security risk thus their payoff and finally the social welfare. 2.4.4 Economy and Collaboration The concept of economics comprises the notions of agents, interaction, business model, payoff, value and assets. The challenge is to influence strategy of the agents with incomplete information about the economic game. In our setting an agent is assumed not to know the private information of the other players, and this information determines their preferred interaction. We adopt a model of games with independent private values and incomplete information. In this context independent private values means that the utility of an agent depends only on his private information and not on any private information of others as it is independent from his own information. It is noted that an agent might select an interaction to invoke a service providing some information, even security information. 2.4.4.1 Agent Agents represent involved parties within the collaborative information system. Agents have the capability of interacting independently and to making their own free (business) decisions based on all available knowledge. Each agent makes his own decisions influenced by his intentions and constraints with the target to maximize his payoff. An agent is able to interact. Each agent has a type. For each context, the game will have different types of agents. 2.4.4.2 Interaction Interactions are combinations of continuous feeds of decisions (choices of valid moves) of agents which concerns especially consumption and provisioning of assets and their security.

50


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 These interactions are the means driving the collaboration. Each agent's intentions yield to actions in a special context influencing the payoff. Each agent has a set of admissible (allowed) interactions. These actions constraint an agent e.g. by the business model or the agent's type. Recall: A joint interaction is the vector of all participating agent's interactions. This vector corresponds to a strategy profile in a continuously repeated game. An asset as described above is anything tangible or intangible of value. The notion of an asset is the capability of provisioning a service or information within the information system. The payoff function of the economic game determines the value of an asset. Recall that a service is a capability provided as a resource by an agent in the context of an interaction. Thus, services are the assets provisioned and consumed within the information system. Agents can act by consume or provide services. In other words, the information system allows trading of information and service assets. Invocation of a service is an action that defines a transfer of value. Information is knowledge enabling a capability provided by an agent in the context of an interaction. 2.4.4.3 Behavior and Security To gain insights of how behavior deviation of the collaborative information system impacts the economical result, the game is supplemented by behavior adding a further uncertainty about the economical payoff. i.e. the value. Since behavior of the information system has a deep and temporarily unbounded impact on the value transfer and thus the value mechanism, the value is raised to an independent entity. Behavior reflects the real trade of assets. The behavior of the information system is defined by its operational semantics. Deviation of expected behavior causes payoff deviation. This deviation is subject to security risk. Therefore it is necessary to define a coarse but structured operational semantics defining the expected behavior of the information system. The chosen operational semantic specifies the behavior in terms of transitions or events, where rules define the valid transitions, i.e. the admissible transition systems. Beside the defined and expected behavior there is an observable behavior, the constellation. That is a transition system that is constructed from observations on the information system. The most important relations between these two transition systems are simulation relation. As soon as the observed behavior deviates, it indicates security risk. Security measurements and discriminate constellations showing their security characteristics. What is needed to know is expressed in terms of attributes and their values within credentials and constraints. Patterns can be used as witnesses for insecure parts or constellations causing a loss of value. The security characteristics can be composed out of influential properties like dependability, correctness, predictability, reliability, complexity or traceability. The behavior is classified according applicable security guards.


51

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 This considerations lead to the following pictographically representation of a business collaboration model.

Figure 18: Schematic business collaboration model

2.5 Security Collaboration 2.5.1 Collaboration and Economy So far the concept of economics enables analyzing provisioning and consumption of information and services deployed by the information system. Economics aims to explain how the information system is used and how the parties interact, i.e. how the parties consume or provide assets in order to maximize their payoff. Provisioning and consumption is interaction, i.e. the degree of freedom for any party to decide to consume or provide services or information within the collaborative information system. These value mechanisms are especially applied to identify the economical impact of security and to recommend interactions that maximizes payoff. These decisions, explicit or implicit, depict a strategy as a set of interactions by the participating parties based on assumptions of these parties behavior within the economics. The ever recurring concept collaboration describes how the parties, from now on called agents, interact within the information system to reach their interests. Collaborative interaction can be found both inter- and intra-agent with respect to the aforementioned domains, and is also present within opposing interests. How a specific agent interacts collaboratively (or selfish) should be a rational decision maximizing the specific agents overall payoff. So there is an interference of business models and collaboration. The agents will decide on their alternatives according to their divergent interests. Hence collaboration need to be motivated by a payoff and security characteristics need to have a value impacting the payoff. 2.5.2 Incentive Compatible Economy To incorporate the economic impact of behavior deviation it is necessary identify the impact, i.e. the value of a security characteristic and the value of enforcing this characteristic. The economic impact is treated as a social welfare value in the economic game. The fundamental principle applies is that liability is assigned to the agent that can influence the security risk, i.e. to concentrate diffuse liability to the responsible agent. The economic game considers in this settings incentives of those responsible for the information system when these agents support social welfare. 52


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 This is reached by applying an economic mechanism, where each agent has in addition to his payoff function a payment function for each interaction that implements a Groves mechanism, i.e. there is a social choice function maximizes the social welfare defines an incentive compatible payment function. This incentive compatible transfer payment is allocated to these agents that are in the position to ensure the outcome according to the defined operational semantics which is guarded by the security characteristics. A claim and resolution procedure allocates loss for an insecure invocation to the agents that can or would have been able to influence the underlying security risk identified by defective security characteristics. The procedure might require a proof like a constellation as a witness for the claim or a mechanism ensuring genuine claims. To most simple resolution procedure is to tax the agent that was in the position to avoid the arrived loss such that information share between agents is encouraged. A claim and resolution procedure has a deep impact on rational decisions because if an information is offered to recognize a security characteristic to an agent he would have been able to influence the underlying security risk. The pricing of the service is crucial. It should motivate the agent to invoke it for increasing her payoff and it should enable the offering agents to provide the information. Since this is a highly dynamic effect it is approached experimental using a Vickery-Clark-Groves auction. For every insecure service invocation the claim procedure has to be invoked for 

creating the claim by impacted agents



allocate claim to impacting agents and capable agents



justify claim and allocation

This has to be ensured by an agreed authority or procedure initially provided. High claims will motivate the creation, share and application of security mean, i.e. 

create de-claim means



distribute the de-claim means



execute the de-claim means

This has to be ensured by an genuine auction.


53


3 Continuous Security Risk Reduction The ASMONIA projects targets on continuous improvement of the overall security status by means of a collaborative information exchange. Each participating party is assumed having interests in a continuous reduction of their security risk induced by the mobile telecommunication network. Therefore each ASMONIA party needs to have the capability to profit from and to contribute to a collaboration for increasing the overall security status. Although the capabilities are not yet developed they are described as intention and should be interpreted as outline, Continuous Security Risk Reduction decomposes a capability set by means of Continuous Security Monitoring, Continuous Security Model Adoption, Continuous Security Economics Analysis, Continuous Security Awareness and Continuous Security Collaboration. This capability set will improve the mobile telecommunication network surveillance, continuous reducing the security risk, and hence maximize social welfare. Each security risk reduction contributes to an increased social welfare as the aggregation of the overall value of the information security. The capability set of Continuous Security Risk Reduction requires the following functional capabilities, which might be realized differently even only partially but interoperable by the ASMONIA parties. Continuous Security Monitoring, defined as ongoing observance with intent to provide warnings in case of deviations from expected behavior of the mobile network. Continuous Security Model Adaptation, defined as the ongoing evaluation and adaptation of the underlying behavioral model of the mobile network. Continuous Security Economics Analysis, defined as the ongoing identification of the effective economical impacts associated with behavioral deviations. Continuous Security Awareness, defined as ongoing presentation of the current and past security status for decision support. Continuous Security Collaboration, defined as ongoing conflict resolution between parties having different security needs and divergent intentions.

3.1 Capabilities Traditionally, critical infrastructure elements have been lucrative targets for anyone wanting to attack. Now, because the infrastructure has become a life-line, attackers can achieve high economic value by attacking critical elements of it. Disrupting or even disabling the infrastructure may reduce the ability to defend, erode public confidence, and reduce economic strength. Although technical efforts under way, there is no unified foundational capability to protect the interrelated especially economical aspects. One reason for this is the lack of understanding the inter-relationships between economics and security. There is also no consensus about how and which the elements of the infrastructure mesh together, or how each element functions and affects the others. Critical infrastructure protection requires the development of a capability to identify and monitor the critical elements and to determine when and if the elements are under attack or are the victim of destructive forces. Critical infrastructure protection is the link between risk management and infrastructure assurance. Practitioners determine vulnerabilities and analyze alternatives based on incidents in order to prepare for incidents.

54


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Information systems can be approached and decomposed in several architectural views which is known from enterprise architecture. These views provide insights on several development phases of a system. The most relevant views concern business, information, application, and technology. Observing an information system and assessing the impact on the systems boundaries, i.e. real effects caused by the system, requires to observe these views and to extract corresponding technological interactions, application invocations, information transmissions, and value flows. Especially for complex information systems this approach seems to be promising in interlinking security incidents or risks with economical or social impact by reducing the complexity in manageable pieces with a recurrent method. Beyond that relations between these views can be observed which is expected being relevant for detecting behavioral deviations e.g. originated from attacks or incidents. The capability set Continuous Security Risk Reduction implements a risk management approach that maintains an accurate operational picture of security risk posture, provides visibility into assets, and leverages use of automated data feeds to quantify risk, ensures effectiveness of security controls and prioritization of remedies. Implementations via deployed detectors or sensors are expected to interface with existing management systems providing measurement data, comprising vulnerability management, patch management, event and incident management, malware detection, asset and configuration management, network management, license management, information management, software assurance, etc. The underlying use cases comprise as actors the parties, in the following called agents, consuming or providing services via the mobile network. The provisioning of the mobile network itself is also considered as service. The use cases show how agents are expected to interact within the social-economic aspect of an ASMONIA system. They illustrate how measurement data sources feed data collection activities, how this measurement data is stored, analyzed, and finally presented to any affected participating agents who make decisions based on a variety of influencing issues using the ASMONIA Collaboration Network. The capability set requires the following functional capabilities. Continuous Security Monitoring, defined as ongoing observance with intent to provide warnings in case of deviations from expected behavior of the mobile network. Continuous Security Model Adaptation, defined as the ongoing evaluation and adaptation of the underlying behavioral model of the mobile network. Continuous Security Economics Analysis, defined as the ongoing identification of the effective economical impacts associated with behavioral deviations. Continuous Security Awareness, defined as ongoing presentation of the current and past security status for decision support. Continuous Security Collaboration, defined as ongoing conflict resolution between parties having different security needs and divergent intentions.


55


Figure 19: Continuous Security Risk Reduction Capability Set An agent acting as mobile network operator establishes Continuous Security Monitoring (1) within his administrative domain by deploying and crawling data sources. The data sources include sources of participating agents, interactions (provisioning or consumption of services), infrastructure (mobile network), and environment (business- and legal compliance).

56



Figure 20: Provided ASMONIA services for Continuous Security Risk Reduction Focus for data collection is on utilizing standards-based methods and formats like the Intrusion Detection Message Exchange Format (IDMEF), the Incident Object Description Exchange Format (IDMEF) for detectors to reduce integration efforts, enable compatibility, and enable incorporating diverse security characteristics. However, not all data sources are currently standardized by vendor independent organizations like the Internet Engineering Task Force, e.g. the Common Event Format (CEF). Thus the technical architecture needs to cope with proprietary data payloads. Human generated data should be collected using mechanisms that harness automation and that leverage standardized methods. Also, the appropriate frequency for data collection needs to be determined for each data source. Some data collection will be truly continual (event triggered) whereas other will be continuous. The frequency interval will be usually time based, in some cases it may be more appropriate to be event driven. The collected data will initially reside at a storage co-located at detectors and then should be aggregated within an elastic scalable, preferably distributed repository or storage. Having measurement data available inside that repository acting as single point of information enables further analysis within the observed administrative domain. The Continuous Security Model Adaptation comprises (2) the extraction of expected, normal behavior out of measurement data reflecting the service invocations carried out. The behavior of the mobile network is defined by the extracted model, the operational semantics including explicit security characteristics. This operational semantic is not upfront rigorously specified but continuously enriched by evaluating measurements made and adapting the model in order to cover admissible behavior. This is not a mere re-calibration but a model enhancement. Continuous Security Economics Analysis (3) applies the current model for analysis of operational measurement data. Deviations indicating anomalies in behavior as defined by the model will be further classified with respect to their economic impact. Continuous Security Awareness (4) renders the analysis results for the affected agent(s) to enable exploration, root cause analysis and decision preparation. The presented situational picture indicates the mobile network security status and provides an operational, tactical and strategic overview. This contributes to the situational awareness through providing comparative information for a variety of viewpoints enabling efficient security risk reduction. Copyright © 2011 ASMONIA consortium. All rights reserved.

57


Figure 21: Mechanisms for an operational, tactical, and strategic overview of mobile network security status Continuous Security Collaboration (5) intends to increase the overall security status as social welfare of the whole mobile network as an (critical) infrastructure which is shared among all participating agents. Selfish acting agents need to have economic incentives to collaborate with each other. To ensure social welfare they need to be motivated and they need to be able to exchange security relevant measurement data, model enhancements, or even identified threat patterns (5). This implies that analyses carried out within domains need to be interoperable and results have to be exchangeable, hence relying on the Continuous Security Model Adaptation (2) and Continuous Security Economics Analysis (3). Within an operational scenario where multiple agents are involved, invocation of in-secure services might have commercial impact, i.e. realize a security risk. This commercial impact affects a first class of agents, called injured agents. A second class of agents, called aware agents, could have been capable of recognizing or even countering this security risk. A third class of agents, called the causing agents, is the set of originators of this security risk. These classes need neither to be disjoint nor need they contain an agent, i.e. they might be empty upfront. But the classes will evolve as soon as a commercial impact appears, i.e. a security risk was realized. To reach social welfare among the participating agents, it is necessary to provide incentives that resolve the potential conflicts in this setting. For instance an agent being in the position to become an aware agent should have appropriate incentives to do so. These incentives should compensate necessary efforts. This resolves the situation where this agent even might neither be a causing nor an injured agent but is able to contribute to anomaly detection or attack mitigation. The Continuous Security Collaboration (6) use case needs to be driven by a mechanism design ensuring strategy-proofness by incorporating the economic effects based on the identified security risks.

3.2 Requirements The approach targets the creation of a capability set which is here defined by using requirements for a system that can provide the services needed. It concerns stakeholders involved with the system throughout its life cycle, and their needs and demands. It analyzes and transforms these into a common set of requirements that express the intended interaction with the system in its operational environment and that are the reference against which each resulting operational service is validated in order to confirm that the system fulfills needs. According to ITU-T E.408 relevant Stakeholders classes are

58



Network operators (public or private)



Service providers (bearer service providers or value-added service providers)



Service subscribers/service customers



Service end users



Equipment/software vendors



Trusted third-party

All stakeholders are considered to be represented by agents in the social-economic ASMONIA system. Each agent is regarded having needs according to his intention depending on his applicable economic business model. In order to reach customer success and customer satisfaction all agents need transparent and competitive capabilities provided as services. Even governmental and regulatory institutions (treated as trusted third-party) are regarded to intend establishing social welfare by ensuring competitive capability of all agents. For maximization of payoff (value) by service invocations, including loss imposed by security risks, agents need to understand the relationship between value-adding services and (competitive) security characteristics. Security and especially security transparency is considered from an economical point of view. That means traceability from measurements/observations made proofing information security deficiencies to economic impact. The treated critical infrastructure (environment) is a 4G mobile network according to standardization by 3GPP. Legal compliance to German and European Law is considered, but not approached in order to enable reconsideration and stipulating legislation. Incorporation and reflection of existing business models is mandatory. This leads to the following top-level functional requirement on the system to be developed The economic payoff should be maximized for interactions carried out in 4G mobile networks, including transparent and traceable associated security risks for participating agents.


59


3.2.1 Functional Requirements In general, the functional architecture is developed from the problem domain. Stepwise economics, business and information architecture are investigated to identify requirements guiding the system's development. Table 1: Functional Requirements on Continuous Security Risk Reduction No.

Details

FReq. 1

The system should be capable of continuously monitoring a 4G mobile network by means of deployed sensors

FReq. 2

The system should be capable of making measurements available that allow concluding about the security characteristics (confidentiality, integrity, availability) and the imposed security risk for service invocations

FReq. 3

The system should be capable of inferring the security characteristics (confidentiality, integrity, availability) for service invocations, based on measurements made with respect to a security model that allows concluding about the security characteristics.

FReq. 4

The system should be capable of enhancing the security model (e.g. by supervised learning) to improve precision, recall and accuracy of inferring the security characteristics. In the context of behavioral classification with respect to security characteristics, the terms true positives, true negatives, false positives and false negatives are used to compare the given classification of a service invocation with the desired correct classification. 

Precision = tp/(tp+fp)



Recall = tp/(tp+fn)



Accuracy = (tp+tn)/(tp+tn+fp+fn)

FReq. 5

The system should be capable of identifying the economical impact of detected behavioral deviations in service invocations with respect to inferred security characteristics.

FReq. 6

The system should be capable of providing an interactive presentation of the current and past security status for decision support allowing exploring root causes and predictive analytics and on-line analytical processing. [On-line analytical processing is an approach to swiftly answer analytical queries.]

FReq. 7

The system should implement a mechanism design ensuring true collaboration for increasing social welfare in terms of ensured adequate security characteristics.

FReq. 8

60



The mechanism design should perform a true and incentive compatible security risk assignment.



The mechanism design should be capable to discover "conflicts resolution" between agents having different security needs or divergent intentions.

The system should be capable of enabling effective collaboration by exchanging models, measurements, inferences, and realized security risks.



3.2.2 Non-Functional Requirements In general, the architecture of the system to be developed is driven by the fundamental concepts or properties of a system in its environment embodied in elements, relationships, and principles of its design and evolution. The fundamental concepts are also governed by the non functional requirements. For pragmatic purposes the underlying architectural paradigm is to be assumed as service oriented following the main industry trend. Services implements discrete capabilities. This implies especially the following quality attributes. Table 2: Non-Functional Requirements on Continuous Security Risk Reduction No.

Details

NFReq. 1

Flexibility, as the ability to adapt quickly to new security challenges and the ability to invoke innovative and standardized methods, technologies and resources.

NFReq. 2

Security, as the ability to provide available, integer, and confidential services.

NFReq. 3

Extendibility, as the ability to flexible integrates with evolving mobile network infrastructures, and to integrate new measurements and analytical methods.

NFReq. 4

Maintainability, as the ability to easy and flexible change measurements and related components and the ability to integrate these measurements smoothly.

NFReq. 5

Interoperability, as the ability to analyze measurements, to operate according to an agreed operational semantics, and to share analysis results and information.

NFReq. 6

Scalability, (e.g., in the dimensions of service invocations, measurements and components) as the ability to store and process the emerging data volume.

NFReq. 7

Performance, as the ability to derive results timely.

NFReq. 8

Usability, as the quality of a user’s experience in interacting with information or services.


61


3.3 Constraints Although Continuous Security Risk Reduction is developed for the application within mobile telecommunication network, it should be also applicable to all kinds of collaborative information systems. The development von Continuous Security Risk Reduction is oriented at future mobile telecommunication networks as defined by the Third Generation Partnership Project (3GPP) and the underlying technical standardization of the mobile telecommunication infrastructure.

Figure 22: Next Generation Mobile Telecommunication Infrastructure as specified by 3GPP Additionally the capability set Continuous Security Risk Reduction is enclosed by regulatory requirements as defined by the European regulatory for electronic communications in the European Union and the realization in German laws, i.e. the German "Telekommunikationsgesetz (TKG)", the German "Telemediengesetz (TMG)" or the German (Bundesdatenschutzgesetz (BDSG)". A detailed investigation of regulatory and legal requirements is not considered within this document. Because Continuous Security Risk Reduction targets primarily on mobile telecommunication networks, this capability set needs to be interoperable with existing and evolving business models, business processes and frameworks for service delivery such as the enhanced Telecom Operations Map (eTOM) of Mobile Network Operators (MNOs) although also customers and third parties also treated uniformly as agents.

62



3.4 Enterprise Architecture Because the infrastructure has become a life-line, attackers can achieve high economic value by attacking critical elements of it. Disrupting or even disabling the infrastructure may reduce the ability to defend, erode public confidence, and reduce economic strength. Although technical efforts under way, there is no unified foundational capability to protect with regard to interrelated especially economical aspects. One reason for this is the lack of understanding the inter-relationships between economics and security. There is also no consensus about how and which the elements of the infrastructure mesh together, or how each element functions and affects the others. Critical infrastructure protection requires the development of a capability to identify and monitor the critical elements and to determine when and if the elements are under attack or are the victim of destructive forces. Critical infrastructure protection is the link between risk management and infrastructure assurance. Information systems can be approached and decomposed in several architectural views which is known from enterprise architecture. The most relevant views concern business, information, application, and technology. Observing an information system and assessing the impact on the systems boundaries, i.e. real effects caused by the system, requires to observe and interpret these views, i.e. to extract corresponding technological interactions, application invocations, information transmissions, and value flows. Especially for complex information systems this approach seems to be promising in interlinking security incidents or risks with economical or social impact by reducing the complexity in manageable pieces with a recurrent method. Beyond that relations between these views can be observed which is expected being relevant for detecting behavioral deviations e.g. originated from attacks or incidents. This current approach imposes the outlined deficits in identifying emergent patterns as well as in transporting knowledge about (economical) impacts. 3.4.1.1 Architecture Vision of ASMONIA Architecture Vision of ASMONIA is to establish collaborative security. To stipulate collaboration it is necessary to create a common understanding about security, i.e. a semantic, and motivating imperative to modulate security risk. If any collaborating agent will have a clear and concise picture of security impacts and their root causes, she will have a motivation to take countermeasures if her payoff is positively affected. Therefore the approach is to evaluate security deficits economically and to allocate or transfer impacts to agents that would have been in the position to manage the security deficit. This requires to close a gap between the current technical architecture of the mobile telecommunication network - comprising components as nodes and interfaces as edges - to the social network comprising agents as nodes and interactions or value transfers as edges. This requires to establish information exchange based on a shared semantic that allows to communicate risks or impacts based on observations over administrative boundaries.


63


3.4.1.2 Business Architecture of ASMONIA Business Architecture of ASMONIA incorporated the necessary economic resources into the identified economic value by approaching security as a strategy game between involved agents. This is reflected by considering necessary efforts in collaboration in the underlying payoff function as in place. Fix and variable costs are considered in the economic evaluation by design. Costs of ASMONIA are assumed to be effective cost of operations (fix and variable; global and local). The benefit is that the resulting transparency of security risk bears the opportunity to increase an agents payoff. Initially the ASMONIA system is assumed to be provided as a common good. The business architecture is treated as a payoff for each service invocation I for each of the participating agent A according to a simple linear-combination of imposed cost, value and risk, i.e. payoff(I,A) = a*value(I,A) - b*cost(I,A) - c*risk(I,A), where a,b,c are constants and 

cost(I,A) presents the costs for agent A for interaction I (variable and proportionally fixed)



value(I,A) presents the value of the service invocation for agent A for interaction I (revenue or other potentially higher value add)



risk(I,A) presents the damage for agent A due to a service invocation with a security deficit of I

To stipulate collaboration it is required to claim compensation for imposed risks due to a service invocation with a security deficit to the parties that were in the position to manage this risk with a rationale for the claim. This leads to value transfers from a security deficit provoking agent A to a claiming agent B having a rationale R. Denoted by claim(A,B) the risk assignment due to security deficits forming an adjacency matrix of claim flows. Each risk assignment has a rationale rationale(claim(A,B)). Similarly the cost transfers form a second network where the agents are the vertices, too. Here the value flows are based on trading, denoted by cost(A,B) of value transfers from agent A to agent B for service invocation. That means A is a consumer and B is a provider in the service invocation I. In this case the rationale is the business model underlying the agreement between the agents. These business models are based on service provisioning. Subjective theories hold that for a service to have economic value (a non-zero price), the service must be useful in satisfying human wants and it must be in limited supply. Value of information is assumed as the amount a decision maker would be willing to pay for information prior to making a decision, i.e. to invoke a service. Note that the life cycle of a service has another scale and influences the cost of a service invocation. Currently the transfer cost hide security risk because claims are implicit. Hence the integrated payoff for agent will be the sum of immediate payoffs, receivable claims and entitlements as a simple linear-combination. 3.4.1.3 Information Architecture of ASMONIA Information Architectures of ASMONIA needs to provide sufficient information to derive immediate payoffs, receivable claims and entitlements, i.e. claims caused by deficits having an agreed rationale for the outlined value flow networks. 

64

Cost forms a network comprising agents A, B as vertices and value flows originated by costs(A,B) (for a service invocation) as edges.



Claim forms a network comprising agents A, B as vertices and value flows originated by claims(A,B) (for a service invocation with security deficits) as edges.

Security deficit is due to observed behavioral deviation. Such deviation need to be observed by sensors providing sufficient information to conclude about a behavioral deviation. This implies sensors have to provide measurements with a well-defined semantics allowing to integrate observable events into a presentation for a service invocation allowing to classify the service invocation as secure or insecure. A claim will be based on the rationale for the value of the claim and the detected deviation in combination with the allocation to agents. The data providers needs to be encapsulated in a set of sensor services providing measurements that are embeddable in a structure out of existing measurement sources. The measurements are aggregated in a structure describing behavior of a service invocation that is comparable to reference behavior as well as classifiable with respect to its security characteristics. The classification mechanism as well as the sensor and the reference behavior needs to be adaptive to various contexts like upcoming threats and to the variety of available and future measurements. The claim is determined for behavioral deviation indicating the effective economic impact. The observed service invocation is an execution (sequence) of involved objects like network elements or software components. Hence the service invocation forms a network introduced as constellation representing the semantic of the service invocation. 

Service invocations form a network consisting of objects as vertices and observable events (contributing to the service invocation) as edges.



The network of objects with the interfaces allowing to exchange events is considered as the network.

This is the fundamental difference to current solutions because it allows not only to conclude about security deficits of technical means, i.e. the object based measurements but also the technical interactions (events) and the commercial impact. This is expected to be a game changer because it allows the community of impacted agents to organize their efforts efficiently and collaborative to maximize their payoffs. For the sake of inception it is intended to transfer the risks in an incentive compatible and transparent way. The approach is to embed available information in a uniform constellation of a service invocation with a defined semantic allowing to comparison with admissible transition systems. 

To identify behavioral deviation it is necessary to classify a constellation of a service invocations as secure or insecure.



To allocate claims it is necessary to identify agents being the service provider(s) and service consumer(s) of a service invocation.

Note that the service invocation network, the claim network and the cost network is volatile due to the transient service invocation. This is the rationale for the continuity approach. Anyhow, if certain information is not available, the information might be supplemented by randomizing e.g. via controlled sampling or distributions out of Markov processes / Markov fields or diffusion which is supported in this architecture. For presenting and exploring the model ambient intelligence in combination with advanced human computer interaction, e.g. semantic zooming will support understandably and learnability.


65

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 3.4.1.4 Procedural View The basic information items are measurements that need to be allocated to service invocations. The sensors are manifold and evolve independently yielding to a variety of formats, measurement concepts and standards that need to be organized in an coordinating ontology. Universally (in the sense of mathematics) is that a constellation of a service invocation serves as a unifying structure that embeds all measurements for evaluation of the security characteristics. The computation of a representation of information about a service invocation allows explicitly to classify security properties. If a service invocation is classified as secure the value of the underlying interaction between agents participating will be transferred according to a flexible specifically set of payoff functions. Otherwise the service invocation is subject to behavioral deviation. In this case the impact, i.e. the value of the realized security risk is allocated to impacted parties. In other words the risks are transferred in an incentive compatible and transparent way. This allows rendering a view of economic values for the identified entities, namely 

objects (network components)



assets (services)



behavior (service invocations)



agents (service provider entities, service consumer entities)



interactions (alternatives for service invocations that cause a value flow)

Depending on the granularity of service descriptions finally this enables to recommend interactions. The allocation of value to these entities allows to inspect for relevant causes, i.e. behavioral deviations with deep impact on the mobile telecommunication network identifies by high risks. This enables the explicit allocation of economic impact, e.g. assigning the impact proportionally to those agents that were in the position to manage the realized risk. It is expected that the instrumentation of countermeasures will be adapted to reduce the allocated risk if a rational acting agent could increase her payoff. It could furthermore motivate agents to increase the security means in domains that are not managed by themself. Currently every agent manages its own security within his domain. Transparent impacts and rules that explicitly allocate the damages have the opportunity to break the introvert pattern into a collaboration. The necessary exchange of information between two parties is limited to a validation of a claim. The information architecture is shared between all participating agents for the sake of interoperability. Hence the exchange of claims and values is candidate for standardization. 3.4.1.5 Technology Architecture of ASMONIA Technology Architecture of ASMONIA is dependent on the established infrastructure serving computational means, storage means, data transport means and existing sensors. For a prototype illustrating the system it is intended applying standard information technology comprising the existing sensors as measurement provider. Presentations of constellations will be created and stored using standard storage technology. Identification of behavioral deviation will be realized by applying data mining (machine learning) technology. A persistent store will serve as storage for the instances of the

66


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 economical model of an agent participating on the ASMONIA infrastructure, shaping the outlined networks.

Figure 23: Continuous Security Risk Reduction in mobile telecommunication networks

3.4.1.6 Rationale Continuous monitoring is addressed by invoking the analysis procedure for every (monitored) service invocation. (FReq.1) Making measurements available is addressed by incorporating available measurements within a generic data structure.(FReq.2) Inferring the security characteristics is addressed by applying standard data mining technology.(FReq.3) Enhancing the inference is addressed by applying standard data mining technology and by establishing incentives for collaboration and adoption.(FReq.4) Identifying the economic impact is addressed by ambient intelligence and a generic model respecting economic value.(FReq.5) Significant interactive presentation is addressed by ambient intelligence and a generic model respecting economic value.(FReq.6) Mechanism design ensuring true collaboration for increasing social welfare is addressed explicit.(FReq.7) Effective collaboration by exchanging models, measurements, inferences, claims are addressed explicit.(FReq.8) Flexibility, extendibility, scalability and performance are addressed by service orientation implementing the identified capabilities respecting economic value.(NFReq.1,3,6, 7) Usability is addressed by ambient intelligence and a generic model respecting economic value.(NFReq.8)


67


4 Continuous Security Monitoring The capability of Continuous Security Monitoring, defined as the ongoing observance of the mobile telecommunication network with the intent to detect and to provide information about deviations from expected behavior, is established to collect measurements from deployed sensors. These sensors provide measurements about the status of components within the network infrastructure, the behavior of service invocations in accordance with evolving metrics, leveraging existing information, and additional information for deriving and interpreting security characteristics out of measurement data. The goal is to provide access to measurements from sensors and sensor systems using a semantically aligned interpretation of the impact on the monitored mobile telecommunication system. This is a challenging task because concluding security characteristics out of measurements is usually not the primary goal for sensor deployment targeting on performance optimization. The challenge is to carefully model sensors, sensor systems, and measurements in an unifying model in such a way that the model covers all varieties of sensors and supports the requirements for deriving security characteristics. The unifying model must allow to interpret observations made as real risk in economic terms, i.e. risks realized and observed must be sound traceable to observations. Monitoring of the mobile telecommunication network cannot be efficiently achieved through manual processes. Automated processes and the use of automated support tools (e.g., vulnerability scanning tools, network scanning devices), can make the realization of the capability Continuous Security Monitoring more cost effective, consistent, and efficient. Deployed infrastructure components, e.g. Serving Gateways or Packet Data Network Gateways, and security controls, e.g. Security or Border Gateways, are candidates for monitoring using automated tools and techniques. Continuously monitoring implemented technical controls using automated tools can provide a much more dynamic view of the security state of the whole mobile telecommunication network. To supplement these technical security-related information with measurements made of service invocations, sensors deployed within the charging infrastructure need to be incorporated in the preparation of suitable representations of collected measurements. These representation provides visibility into interacting agents, used services, quality attributes of service invocations, underlying constellations and measurements of related components. The provisioning of suitable representations enables a realization of Continuous Security Economics Analysis and Continuous Security Model Adaptation.

4.1 Requirements This section map the identified and refined requirements to the sensor functionality. Sensors are data and information providers serving as monitors and sources for measurements. For developing the capability Continuous Security Monitoring it is necessary to interpret the measurements uniformly for recognizing behavioral deviations from expected behavior of the mobile telecommunication network. A sensor is considered as a component that provides atomic or complex observations of state changes (transitions) of the telecommunication network.

68


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Table 3: Requirements on Continuous Security Monitoring No.

Details

FReq.1

The system should be capable of continuously monitoring a 4G mobile network by means of deployed sensors

FReq. 2

The system should make measurements available that allow concluding about the security characteristics (confidentiality, integrity, availability) and the imposed security risk for service invocations. Minimal measurements comprise* cost(I,A); the costs for agent A for interaction I (variable and proportionally fixed) (and their propagation costs(A,B)) 

value(I,A); the value of the service invocation for agent A for interaction I (revenue or other potentially higher value add)



risk(I,A); the damage for agent A due to a service invocation with a security deficit of I (and their propagation claim(A,B))* Measurements of behavior necessary to classify a constellation of a service invocations I as secure or insecure.



Involved agents acting as the service provider(s) and service consumer(s) of a service invocation.


Addressed by 

Identifying of available sensors / measurements



Providing of behavior and context measurements by aggregating them in a constellation with a unifying semantic in a unified format for classifying security characteristics



Identifying oracles for calibration



Identifying candidate measurements for concluding on security characteristics



Identifying candidate measurements for security context



Identifying of existing data providers



Storing of measurements (history)



Aggregating measurements in constellations

69

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 No.

Details

FReq. 3

The system should be capable of inferring the security characteristics (confidentiality, integrity, availability) for service invocations, based on constellations with respect to a (evolving) security model that allows concluding about the security characteristics



Inference with respect to defined security semantics



Adaptive data mining for classification of constellations



Computing the classification of service invocations with respect to the security semantics

Flexibility, as the ability to adapt quickly to new security challenges, and to invoke innovative and standardized methods, technologies and resources.



Open architecture which allows to incorporate changes easy



Maximal use of sensors data and information



Standardized exchange format / methods



Generic semantics that allows to infer security properties



Security semantics



de-scoped



Ensuring an adaptive reaction on changing storage, communication and computational resource constraints by applying cloud computing / parallel computing methods, if applicable

NFReq.1, 3, 5

Addressed by

Extensibility, as the ability to flexible integrates with evolving mobile network infrastructures, and to integrate new measurements and analytical methods. Interoperability, as the ability to analyze measurements, to operate according to an agreed operational semantics, and to share analysis results and information. NFReq.2

NFReq.4

NFReq.6

70

Security, as the ability to provide confidential, integer, and available services. Maintainability, as the ability to easy and flexible change measurements and related components, and to integrate these measurements smoothly. Scalability, (e.g., in the dimensions of service invocations, measurements and equipment) as the ability; to store and process the emerging data volume.


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 No.

Details

Addressed by 

NFReq.7

Performance, as the ability to derive results timely.

Ensuring an adaptive reaction on changing resource requirements by applying cloud computing / parallel computing methods, or efficient algorithms, if applicable

4.1.1 Sensors A primary design goal for ASMONIA is to minimize the need for any specific implementation of sensors on existing components. The data to be gathered and provided for the capability Continuous Security Monitoring is collected by data and information feeds that are already deployed in a mobile telecommunication network or that are available. The data that they collect, however, must be transferred to a unified repository on an ongoing, periodic basis. The transfer can follow either a push or pull process, or both. 4.1.2 Measurements and Observations In the data push process, the scheduling and execution of the transfer is controlled by a local organization, possibly by the platform itself. This allows maximum flexibility at the local level and minimizes the possibility of interference with ongoing operations. But the push process is also more likely to require that specific functionalities be present on components. In the data pull process, the scheduling and execution of the data transfer is controlled by a Measurement Collector. This interrogate feeds on an ongoing, periodic basis, and stores the resulting data in the repository. The pull paradigm minimizes the need for any ASMONIA sensors on components of the mobile telecommunication network, but also provides less scheduling flexibility at the local level and may also interfere with existing operations. The pull paradigm may also involve directly integrating the repository with numerous and disparate individual sensors, negating the benefits of subsystem modularity and independence. 4.1.3 Semantics of Observations Describing the dynamic behavior of an information system, generically, such that the output of a large class of sensors can be embedded, is a non-trivial matter. However, formal descriptions are needed if we want to reason on behavior. Such reasoning is required for specifying, observing and comparing behavior. One of the great challenges is to develop techniques for effectively establishing properties of generated behavior. We need to develop a formalism to specify and observe security of a dynamic information system, where the state space is opaque. It is expected that the above described labeled transition system will serve this issue . Current security monitoring focus only on f infinite and finite lists of observations or measurements. 4.1.4 Constructive Semantics Initially constellations of service invocations, as described in section 2.2 Service Orientation, Monitoring and Tracing aggregate observations explicitly in one structure, together with contextual information like participating agents, time, location etc. can be compared with Copyright © 2011 ASMONIA consortium. All rights reserved.

71

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 other transition systems either explicitly by specified transition systems or by learned transition systems from service invocations that were classified (by an oracle) as secure. The subset of transition systems classified as insecure can be used for further investigation and procedures like the outlined claiming, in section 3.4 Enterprise Architecture. The presentation of an observed transition system for a service invocation is called analytical record in the data mining context.

4.2 Module View Sensors and sensor subsystem components assess and collect measurements of computing and networking assets. These are collected at a measurement collector, which is responsible for making measurements available at a repository, see section 4.3 Component-andConnector view. In general, there are many types of available sensors to assist in monitoring, measuring, and managing the security posture of computing and networking assets. The architecture is intended to leverage and support, as much as possible, the entire range of existing and deployed sensors within a mobile telecommunication network which is the rationale for a service oriented architecture encapsulating sensors as services. 4.2.1 Coordination of existing Modules According to [CAESARS] this set of available sensors can be subdivided into the following categories: 

Security configuration compliance sensors, which are designed to verify and validate the implemented security configuration settings in computing or networking assets and to measure the level of compliance to a defined security configuration baseline.



Patch-level compliance sensors, which are designed to measure the level of compliance to a defined set of patches and to identify and enumerate vulnerabilities associated with computing or networking assets.



Vulnerability assessment sensors, which are designed to identify and enumerate vulnerabilities associated with computing or networking assets.

The sensor subsystem contains a multiple vendor solutions (each may comprise multiple tools) that may map to one or more of the aforementioned sensor types. Although great parts of the subsystem are available within a mobile communication network, only modest instrumentation of existing tools will be required for the tools to participate. This instrumentation will primarily revolve around the ability to output particular standards-based data types (e.g., product names) and use ASMONIA defined interfaces. Thus, the tools can be viewed as external systems that are essential to, and interface with. ASMONIA does not replace the diverse security and management tools already provided by vendors and used by organizations (e.g., asset management, configuration management, and vulnerability management). Continuous Security Monitoring leverages those tools to feed essential data for further analysis within Continuous Security Economics Analysis based on security models derived from Continuous Security Model evaluation. The following processes are introduced by [SP800-37] as essential for enabling and ensuring an organization-wide Continuous Security Monitoring: 

72

Ongoing assessment of security controls (including system-specific, hybrid and common controls) with assessment frequencies based on an organization-wide Continuous Security Monitoring strategy;



Configuration management and change control processes for information systems, throughout their life cycle, and with consideration of their operating environments and their role(s) in supporting business processes;

The set of processes defined by NIST, comprises additionally the following processes which are addressed separately with their own capability within ASMONIA: 

Security impact analyses on changes to information systems and their environments of operation for any adverse security impact to systems and the according business. Considerations include the impact to the enterprise architecture due to the commissioning or decommissioning of systems. This will be addressed with the capability Continuous Security Economics Analysis.



Security status reporting to executives designed to enable risk based decisions with minimal response times. Considerations include organization relevant threat data where available. This implies active involvement of executives enabling ongoing management of information security-related risks. This will be addressed with the capabilities Continuous Security Awareness and Continuous Security Collaboration.

Ongoing control of information security risk requires security control assessment, security status monitoring, security status analysis, and security status reporting. The resulting information should be used in an organization-wide strategy, in order to maintain visibility into assets and awareness of vulnerabilities and threats and to ensure that implemented security controls continue to be effective. Security control assessments help ensure that security controls are implemented correctly, operating as intended, and meeting stated security objectives. Security status monitoring ensures that organizational officials have the metricsbased information necessary to make risk management decisions. Active involvement of management in reviewing and responding to security status reports helps ensure awareness of vulnerabilities throughout the organization, provides insight into the ability of implemented controls to mitigate those vulnerabilities, helps ensure availability of timely, actionable information, and promotes ongoing control of operations to within organizational risk tolerances. 4.2.1.1 Sensor Ontology There is a disparate, vast amount of existing sensors within a mobile telecommunication network, for different purposes requiring a classification of sensors and services. The figure below shows an ontology of abstract concepts, concepts having instances, and concrete elements being these instances for coordination.


73


Figure 24: Sensor Ontology The following abstract concepts were identified 

Sensor being a role of an abstract component provisioning a monitoring service.



Abstract component being an abstraction of elements of an existing mobile communication network.



Abstract service provided by an abstract component, having an (service) interface for interaction with other components.

The following relationships between these abstract concepts were identified 

role_of indicating that any specialization of an abstract component can comprise a sensor under the constraint that this specialization provides a monitoring service.



an abstract component provides abstract services



an abstract service has_an interface meaning that each specialization of the abstract service, a service, has its own specialization of interface.

As specialization of the abstract concepts the following concepts are identified by [D5.1] and can be clustered as follows 

Specializations of abstract component are, i.e. o

74

Home Subscriber Server (HSS), Equipment Identity Register (EIR), Authentication, Authorization, Accounting (AAA)-Server, Mobility Management Entity (MME), Operation, Administration, Maintenance (OAM) System, Offline Charging System (OFCS), Online Charging System (OCS), Serving GPRS Serving Node (SGSN), Serving Gateway (S-GW), Home evolved Node B (HeNB), Packet Data Network Gateway (PDN-GW), evolved Node B (eNB), evolved Packet Data Gateway (ePDG), Border Gateway (BG), Security Gateway (SeGW) are 3GPP specified components


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 o



Security Incident Event Management (SIEM) Systems, Billing System, Log Management System (LMS), ASMONIA System, Router, Firewalls (FW), Intrusion Detection Systems (IDS), Intrusion Preventions Systems (IPS), Malware Detection Systems are non-3GPP specified components

Specializations of abstract service are o

Control Plane Services

o

User Plane Services

o

OAM Services

o

Security Services

o

Monitoring Services

The following relationships between these concepts were identified 

a component provides defined services



the monitoring service observes components and other services

These concepts can be instantiated as concrete elements, i.e. an eNB as product of a vendor as describe in section 2.2 Service Orientation, Monitoring and Tracing.

4.2.1.2 Measurement Ontology Although sensors can be classified and clustered as shown above, measurements made and provided constitute an own ontology. Similarly to the vast amount of different sensors and sensor subsystem i accompanied by a vast amount of formats, intending to standardize formats for measurements. Up to now no consolidation has happened. Beside approaches made by standards development organizations like NIST, MITRE, FIRST, IETF and other there proprietary formats defined by specific vendors. The following table is an overview of available format definitions without claim of being complete. Table 4: Overview of available measurement collection formats Abbreviation Name

Organization

Source

AI ARF ASR

NIST MITRE MITRE

[AI] [ARF] [ASR]

RUS-CERT

[CAIF]

MITRE

[CAPEC]

MITRE

[CCE]

NIST

[CCSS]

3GPP MITRE HP ArcSight

[TS 32.298] [CEE] [CEF]

Cisco

[CIDEE]

CAIF CAPEC CCE CCSS CDR CEE CEF CIDEE

Asset Information Assessment Results Format Assessment Summary Results Common Announcement Interchange Format Common Attack Pattern Enumeration and Classification Common Configuration Enumeration Common Configuration Scoring System Charging Data Records Common Event Expression Common Event Format Cisco Intrusion Detection Event Exchange


75

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Abbreviation Name

Organization

Source

CPE

MITRE

[CPE]

MITRE

[CVE]

ICASI

[CVRF]

FIRST

[CVSS]

MITRE CERT-Verbund EISPP consortium

[CWE] [DAF]

IETF

[FINE]

IETF

[IDMEF]

IETF

[IODEF]

IETF

[RFC 3917]

MITRE

[MAEC]

Cisco DHS

[RFC 3954] [NVD]

NIST

[OCIL]

MITRE

[OVAL]

MITRE

[PLARR]

NIST

[SCAP]

ICSA sFlow.org consortium

[SDEE]

IETF

[RFC 3411]

IETF

[RFC 5424]

NSA

[XCCDF]

CWE DAF

Common Platform Enumeration Common Vulnerabilities and Exposures Common Frameworks for Vulnerability Disclosure and Response Common Vulnerability Scoring System Common Weakness Enumeration German Advisory Format

EISPP

EISPP Common Advisory Format

CVE CVRF CVSS

SDEE

Format for INcident information Exchange Intrusion Detection Message Exchange Format Incident Object Description Exchange Format IP Flow Information Export Malware Attribute Enumeration and Characterization NetFlow National Vulnerability Database Open Checklist Interactive Language Open Vulnerability and Assessment Language Policy Language for Assessment Results Reporting Security Content Automation Protocol Security Device Event Exchange

sFlow

sFlow

FINE IDMEF IODEF IPFix MAEC NetFlow NVD OCIL OVAL PLARR SCAP

SNMP Syslog XCCDF

Simple Network Management Protocol Syslog Extensible Configuration Checklist Description Format

[EISPP]

[RFC 3176]

This overview shows that there is a broad range of data formats as measurement representations available. All of them were developed to carry specialized information concerning different intents of use. Within this document, there will be no evaluation of suitable data formats for ASMONIA. As a consequence there is a need to define a unified semantics for interpreting measurements for enabling future capabilities, Continuous Model Adaptation and Continuous Security Economics Analysis. The figure below shows an ontology for measurements and observations.

76



Figure 25: Measurement and observation ontology The following abstract concepts were identified 

Sensor as defined above



Context is the observable state about the mobile telecommunication network i.e. its components, or any observable interaction or transition, i.e. service invocations o

Service Invocation

o

Components

o

Interpretation is the functional assignment of measurements to observations according to the context

The following concepts were identified 

Observation is a witness for a service invocation created out of measurement interpretations



Measurements are primitive observations without contextual interpretation provided by a sensor



Security characteristic are specified properties of a service invocation

The following concrete elements were identified, i.e. 

Confidentiality



Integrity



Availability


77


Log

The following relationships between these concepts were identified 

is_wittness



has_a



forms



provides



depends_on



instance_of

4.2.1.3 Measurements The recently released standard Directions in Security Metrics Research (REF) outlines relevant aspects of security measurements 

Correctness and Effectiveness: Correctness denotes assurance that the securityenforcing mechanisms have been rightly implemented. Effectiveness denotes assurance that the security-enforcing mechanisms of the system meet the stated security objectives.



Leading Versus Lagging Indicators: Security metrics may be potentially leading, coincident, or lagging indicators of the actual security state of the system.



Organizational Security Objectives: Security metrics are generally used to determine how well an organization is meeting its security objectives. These can vary widely, it is reasonable to expect that the metrics required to make such an assessment for one organization would also be very different from those used for another.



Qualitative and Quantitative Properties. Measurement of system properties in general has been difficult to accomplish. These tend to blur or being to be too specific and imply an in-transparent complex impact on the organizational security objectives.

These aspects of security measurement lead to potential research areas. The conclusion is that the present state of security metrics largely involves qualitative lagging indicators that require subjective evaluation and may not necessarily coincide with an organization’s security objectives. In order to improve the state of the art of security metrics, it is argued that research efforts need to be focused on areas that satisfy one or more of the following factors: 

Determine estimators of system security.



Reduce reliance on the human element in measurement and inherent subjectivity.



Offer a more systematic and fast method to obtain meaningful measurements.



Provide understanding and insight into the composition and effect of security mechanisms.

As useful future contributions are seen

78



Formal Models of Security Measurement and Metrics



Historical Data Collection and Analysis



Artificial Intelligence Assessment Techniques



Practicable Concrete Measurement Methods Copyright © 2011 ASMONIA consortium. All rights reserved.


Intrinsically Measurable Components

4.2.1.4 Sensor Candidates 4.2.1.4.1 Log Management Infrastructure The Guide to Computer Security Log Management (REF) provides recommendations of the National Institute of Standards and Technology for log management. A log is a record of the events occurring within systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred. Many logs within an organization contain records related to computer security. These computer security logs are generated by many sources, including security software, such as antivirus software, firewalls, and intrusion detection and prevention systems; operating systems on servers, workstations, and networking equipment; and applications. Number, volume, and variety of logs have increased greatly, which has created the need for computer security log management. This is the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. Log management is essential to ensuring that computer security records are stored in sufficient detail for an appropriate period of time. Routine log analysis is beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems. Logs are also useful when performing auditing and forensic analysis, supporting internal investigations, establishing baselines, and identifying operational trends and long-term problems. Organizations also may store and analyze certain logs to comply with legislation and regulations. A fundamental problem is effectively balancing a limited quantity of resources with a continuous supply of log data. Log generation and storage can be complicated by several factors, including a high number of log sources; inconsistent log content, formats, and timestamps among sources; and increasingly large volumes of log data. Log management also involves protecting the confidentiality, integrity, and availability of logs. Another problem with log management is ensuring that security, system, and network administrators regularly perform effective analysis of log data. This publication provides guidance for meeting these log management challenges. The following recommendations for efficient and effective log management are given: 

Organizations should establish policies and procedures for log management.



Organizations should prioritize log management appropriately throughout the organization.



Organizations should create and maintain a log management infrastructure.



Organizations should provide proper support for all staff with log management responsibilities.



Organizations should establish standard log management operational processes.

Logs can contain a wide variety of information on the events. Origins are separated into 

Security software logs primarily contain computer security-related (contextual) information. Security software includes Anti-malware Software. Intrusion Detection and Intrusion Prevention Systems. Remote Access Software, Vulnerability Management Software, Authentication Servers, Routers, Firewalls, Network Quarantine Servers.



Operating system logs and application / service logs typically contain a variety of information, including computer security-related data. Such logs include system


79

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 events, audit records, requests and server responses, account information, usage information, significant operational actions. Some logs are generally more likely than others to record information that would be helpful for different situations, such as detecting attacks, fraud, and inappropriate usage. The major problem is that this could not be decided upfront requiring flexible approaches on storage and analysis. By the standard this is approached by 

Prioritization log management appropriately



Established policies and procedures for log management



Created and maintained a secure log management infrastructure



Proper training

A log management infrastructure typically comprises the following tiers: 

Log Generation. The first tier contains the hosts that generate the log data.



Log Analysis and Storage. The second tier is composed of one or more log servers that receive log data or copies of log data from the hosts in the first tier. The data is transferred to the servers either in a real-time or near-real-time manner, or in occasional batches based on a schedule or the amount of log data waiting to be transferred. Servers that receive log data from multiple log generators are sometimes called collectors or aggregators. Log data may be stored on the log servers themselves or on separate database servers.



Log Monitoring. The third tier contains consoles that may be used to monitor and review log data and the results of automated analysis. Log monitoring consoles can also be used to generate reports. In some log management infrastructures, consoles can also be used to provide management for the log servers and clients.

The following items describe common log management infrastructure functions:

80



Log parsing is extracting data from a log so that the parsed values can be used as input for another logging process.



Event filtering is the suppression of log entries from analysis, reporting, or long-term storage because their characteristics indicate that they are unlikely to contain information of interest.



Event aggregation, similar entries are consolidated into a single entry containing a count of the number of occurrences of the event.



Log rotation is closing a log file and opening a new log file when the first file is considered to be complete.



Log archival is retaining logs for an extended period of time. There are two types of log archival: retention and preservation. Log retention is archiving logs on a regular basis. Log preservation is keeping logs that normally would be discarded, because they contain records of activity of particular interest.



Log compression is storing a log file in a way that reduces the amount of storage space needed for the file without altering the meaning of its contents.



Log reduction is removing unneeded entries from a log to create a new log that is smaller.



Log conversion is parsing a log in one format and storing its entries in a second format.



Log normalization, each log data field is converted to a particular data representation and categorized consistently. One of the most common uses of normalization is storing dates and times in a single format.



Log file integrity checking involves calculating a message digest for each file and storing the message digest securely to ensure that changes to archived logs are detected.



Event correlation is finding relationships between two or more log entries. The most common form of event correlation is rule-based correlation, which matches multiple log entries from a single source or multiple sources based on logged values, such as timestamps, IP addresses, and event types. Event correlation can also be performed in other ways, such as using statistical methods or visualization tools. If correlation is performed through automated methods, generally the result of successful correlation is a new log entry that brings together the pieces of information into a single place. Depending on the nature of that information, the infrastructure might also generate an alert to indicate that the identified event needs further investigation.



Log viewing is displaying log entries in a human-readable format.



Log reporting is displaying the results of log analysis. Log reporting is often performed to summarize significant activity over a particular period of time or to record detailed information related to a particular event or series of events.



Log clearing is removing all entries from a log that precede a certain date and time. Log clearing is often performed to remove old log data that is no longer needed on a system because it is not of importance or it has been archived.

4.2.1.4.2 Security Information and Event Management System Security information and event management (SIEM) software is a centralized logging software. SIEM products have one or more log servers that perform log analysis, and one or more database servers that store the logs. SIEM products support two ways of collecting logs from log generators: Agentless by receiving data from the individual log generating hosts either by push or pull. The SIEM then performs event filtering and aggregation and log normalization and analysis on the collected logs. Agent-Based, where an agent program is installed on the log generating host to perform event filtering and aggregation and log normalization for a particular type of log, then transmit the normalized log data to a SIEM server. SIEMs analyze the data from all the different log sources, correlates events among the log entries, identifies and prioritizes significant events, and initiates responses to events if desired. SIEM products usually include several features to help log monitoring staff, such as the following: 

Graphical user interfaces (GUI) that are specifically designed to assist analysts in identifying potential problems and reviewing all available data related to each problem



A security knowledge base, with information on known vulnerabilities, the likely meaning of certain log messages, and other technical data; log analysts can often customize the knowledge base as needed



Incident tracking and reporting capabilities



Asset information storage and correlation


81

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 There are no standards specific to SIEM, so each SIEM product stores and transmits data in any format it chooses. 4.2.1.4.3 Intrusion Detection System Intrusion Detection Systems (IDS) monitoring network and/or system characteristics and the events occurring within the host for suspicious activity. IDS are focused on identifying possible incidents, logging information about them, and reporting attempts. In addition, IDS are used for identifying problems with security policies, documenting existing threats, and deterring individuals from violating security policies. There are host-based and networkbased approaches. Network IDS tries to detect malicious activity (impacts) by network security monitoring of traffic. It reads all the incoming and tries to find suspicious patterns known as signatures or rules. Often valuable information about an ongoing intrusion is learned from traffic analysis inside and outside a domain. A host-based IDS monitors and analyzes the internals of a component as well as the network interfaces, i.e. the boundary of a node in the network. The principle operation depends on the fact that successful attacks will generally leave a trace. Visualization tools presenting security event data in a graphical format. For example, a tool could display data grouped or sorted by the values of different event characteristics, such as source address. An analyst can then look for patterns in the display and manipulate it, such as suppressing known benign activity so that only unknown events are shown. Visualization tools can be very effective for analyzing certain types of log data, such as showing the sequence of events that occurred in an attack involving several hosts. A log management infrastructure consists of the hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data. Log management infrastructures typically perform several functions that support the analysis of events, such as filtering, aggregation, normalization, and correlation. The infrastructures also provide assistance in making log data accessible and maintaining it through functions such as log parsing, viewing, analysis, rotation, and archival, as well as log file integrity checking. Log management infrastructures, which are typically based on either syslog-based centralized logging software or security information and event management software, usually use a three-tiered design. The first tier encompasses the hosts that generate the original log data. The second tier includes centralized log servers, which perform consolidation and data storage. The third tier contains consoles that are used to monitor and review log data, and optionally may also be used to manage the log servers and clients. Communications between the tiers usually occur over the organization’s regular networks, but may be routed over a separate logging network instead. The original syslog standard does not offer much granularity in handling different types of events. Also, because it has few data fields, it can be very difficult to extract the meaning of the data logged for each event when multiple log sources are generating events. Syslog was developed when log security was not a major concern. Unlike syslog-based infrastructures, which are based on a single standard, security information and event management (SIEM) software primarily uses proprietary data formats. SIEM products have centralized servers that perform log analysis and database servers for log storage. Because the SIEM products try to interpret the meaning of each logged field for specific log source formats, a SIEM-based log management infrastructure is usually superior to a syslog-based infrastructure in performing normalization, analysis, and correlation of log data from multiple log sources. SIEM products can analyze data from many sources, identify significant events, and initiate automated responses if desired. SIEM products may also

82


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 include analysis GUIs, security knowledge bases, incident tracking and reporting capabilities, and asset information storage and correlation capabilities. Although SIEM software typically offers more robust and broad log management capabilities than syslog, SIEM software is complex and resource-intensive. In general these systems use a database of objects it should monitor. Current Security Information and Event Management (SIEM) solutions are a combination security information management and security event management. SIEM technology provides real-time analysis of security alerts generated by network hardware and applications. SIEM solutions come as software, appliances or managed services, and are also used to log security data and generate reports for compliance purposes. The segment of security management deals with real-time monitoring, correlation of events, notifications and console views. Security Information Management provides long-term storage, analysis and reporting of log data. 4.2.1.4.4 Charging System Mobile telecommunication networks provide functions that implement offline and/or online charging mechanisms on the bearer, subsystem and service levels. In order to support these charging mechanisms, the network performs real-time monitoring of resource usage on the above three levels in order to detect the relevant chargeable events. These events service for the creation of observation of a service invocation, see Policy and Charging Architecture. In offline charging, the resource usage is reported from the network to the Billing Domain after the resource usage has occurred. In online charging, a subscriber account, located in an online charging system, is queried prior to granting permission to use the requested network resource(s). Typical examples of network resource usage are a voice call of certain duration, the transport of a certain volume of data, or the submission of a message of a certain size. The network resource usage requests may be initiated by a user equipment or by the network. For further information see Appendix A. The charging system serves a data structure that identifies invoked system elements for each service invocation. Hence it allows to join related measurements made to an arbitrary (charged) service invocation. It relates a service invocation with the invoked objects allowing to gather and join related measurements and observations to an analytical record of features for the service invocation. This implies a certain risk because charging was originally designed to support billing which might becomes obsolete because of increasing independence of service invocation and costs. Charging data might be incompletely provisioned. The trend is to apply not charging individual consumed resources e.g. by cross compensation. Furthermore usually not all system elements are itemized within a charging data record. 4.2.1.5 Modules Element is the implementation units, called modules that provide a coherent set of responsibilities. There are the following modules 

measurement collector: extracting context information for a service invocation



sensor: units gathering measurements from the environment



repository: units storing measurements and observations


83

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 A context collector is a component that gathers, filters and provides measurements relevant for one service invocation. At least this comprises the ensemble of involved components as well as time, location, operational and business context. The context collector might be an extended creator of CDR records. A sensor is a component that gathers and provides measurement of state changes of the telecommunication network in a defined format. The repository persists observations, compiled analytical records and related measurements. 4.2.1.6 Relations Relations are 

measurement collector depends-on sensors, measurements, interpretations, and contexts as indicated by the ontology above.

4.3 Component-and-Connector view While investigating measurement alternatives it became obvious that the rigorously approach evaluating measurements against specifications is too restrictive and inflexible for analyzing the highly complex relationships in the large data sets describing observations of the mobile network. The practical needs to extract knowledge from measurement data could be leveraged immediately but requires analytical techniques that enable analysis of highly nonlinear relationships in very large data sets with an unknown distribution. Developments of applicable techniques followed three paths: Fisherian or Bayesian Statistics, and Machine Learning. Data mining, the resulting method, is the non-trivial extraction of implicit, previously unknown, and potentially useful information. It comprises the following areas: 

Statistical modeling: The use of parametric statistical algorithms to group or predict an outcome or event, based on predictor variables.



Training and Evaluation: The use of machine learning algorithms to find patterns of relationship between data elements in large, noisy, and messy data sets, which can lead to actions to increase benefit in some form.



Knowledge discovery: The process of data access, data exploration, data preparation, modeling, model deployment, and model monitoring.

As the practice of data mining developed further, the focus shifted to knowledge discovery as the non-trivial process of identifying valid, novel, potential useful, and ultimately understandable patterns in data.

84



Figure 26: Component-and-Connector view of Continuous Security Monitoring The organization of data structures suitable for data mining requires a basic shift in thinking about data. Data should be organized to serve the analysis, i.e. relationship of data elements must be relevant to the analysis result and the data structures need to enable conversion into a form suitable for data mining, called Analytical Record. Set of measurements must be associated with the proper individuals (or households) i.e. service invocations, represented semantically well-founded as a constellation C(M1, ... Mn) derived from unified interpretable measurements M1, ..., Mn. The analytical record can be expressed as an equation Y = Classification(C(M1, ... Mn)) representing a computerized memory of the information. It is constructed by either statistical or machine learning algorithms, following specific methodological operations. The algorithms are mathematical expressions that describe relationships between the variable Y predicted and the predictor variables M1, …, Mn. The predictor variables are established inside a repository. Conceptually this procedure comprises measurement activity and an activity to interpret, aggregate and normalize the measurements to enable data mining. 4.3.1 Components There are the following kinds of processing units 

measurement collector: units gathering volatile context measurements from the environment (data and information feeds)



sensor: units gathering volatile security indicator measurements from the environment (data and information feeds)


85


repository: units storing measurements and observations (compiled constellations)

A context collector is a component that gathers, filters and provides measurements relevant for one service invocation. At least this comprises the ensemble of involved components as well as time, location, operational and business context. The context collector might be an extended creator of CDR records. A sensor is a component that gathers and provides measurement, i.e. atomic or complex observations of state changes of the telecommunication network in a defined format. The repository persists the typed data for further processing. The repository persists also compiled analytical records. 4.3.2 Connectors 

store and forwarder: units storing and forwarding measurements into a repository



reader: units compiling analytical records from measurements according to suitable contexts

A store and forwarder is a connector that packs a set of measurements and transfers it towards a repository. A reader compiles for each service invocation observed an analytical record comprising all measurements made that are relevant for this service invocation. All units need to be flexible, interchangeable and adaptive. That means for instance when a sensor provides a new measurement; the analytical record has to be extended by this measurement when it is relevant. All units should ensure confidentiality and integrity when processing measurements. Partial evaluation or a flow of measurements is a design option. 4.3.3 Relationships The outline leads to the following graph of component and connectors. 

sensor attached-to store and forwarder



store and forwarder attached-to context collector



reader attached-to context collector



reader attached-to store and forwarder



reader attached-to repository

Since there are many evolving sensors a sensor should be a service inside a service oriented architecture, declaring himself according to a the defined ontology. The measurements need to be composed into an analytical record gathering all available measurements relevant for a service invocation. This presentation applies to observed service invocations, context measurements and security indicator measurements. The measurement format need to be unified either by standardizing or transforming the raw measurement into a unified representation, in order to manage the various inputs. Service invocation allow to conclude its context and related service invocations. The context comprises especially the ensemble for the service invocation as the dynamic description of the involved components of the mobile network, the operational, and the business context. Out of the aforementioned primitives a service invocation can compile its analytical record by retrieving data stored in the repository. E.g. by retrieving a record of all measurements made within a service invocation by extracting the components where the measurements were 86


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 made and extracting the measurements made when the service invocation was performed using the ensemble in the context. For efficiency reasons sliding time window might be adequate. The repository stores all measurements for a defined time frame and the analytical records. The repository should be capable of handling 

volatile / transient (short time persistence; less than hours); estimation based on measurements per invoked device area



semi persistent (middle term persistence, less than weeks); estimation based on abnormalities; assumed to be volatile/100 (policies, evaluations, reactions)



persistent (long-term persistence, asset, years) assumed to be semi persistent/10 (recognized patterns, configurations, security (reference) models and analytical records)

as assumptions for an average mobile telecommunication network. The store and forwarder need to cache measurements inside a volatile storage in order to avoid loss of measurements at the sensors or contexts. Sensors and detectors need to operate within the time constraints imposed by the mobile network (components) such that missed measurements are seldom. In other words, the sensors and detectors need to be able to catch volatile events for measurements within the time constraints. Furthermore the store and forwards will smooth network resource consumption. Recent developments in the continuous monitoring reference model of the National Institute of Standardization identifies a collection system comprising similar elements as outlined above. A collection subsystem comprises Collection Controller, Data Aggregation, and Content requiring the following capabilities: 

Task Receipt: The Collection subsystem will receive incoming collection tasks for processing and produce responses. Note that both push and pull functionality is mandated in order to support operational needs that require both approaches.



Content Retrieval: The Collection subsystem will retrieve policy and supporting content needed to fulfill data collection tasks.



Data Retrieval: The Collection subsystem will retrieve data and collect new data as necessary to fulfill data collection tasks. The data retrieval collects and retrieve needed monitoring data in order to fulfill the data collection tasks. To support this objective, it should maintain a local repository of previously collected data that acts as a caching mechanism. If the requested data is not available in the local repository, the data is considered stale according to the specified data age parameter, then it attempt to collect the requested data from its sensors according to an applicable policy content.



Data Publication: The Collection subsystem will publish data gathered in support of a data collection tasks and stores the collected data to the appropriate repository.



Collection Console: The Collection subsystem can provide a console that enables direct creation of data collection tasks and general management of the subsystem configuration.

The standard introduces a presentation subsystem comprising a dashboard engine supporting a quarry result presentation analysis cycle, which is out of scope of this view.


87


4.4 Allocation view 4.4.1 Environment In order to fulfill the required quality attributes as identified (Flexibility, Security, Extensibility, Maintainability, Interoperability, Scalability, Performance, Reliability, Consistency) with a minimal total cost of ownership it is intended to evaluate the advantages to deploy the software elements in a cloud. Therefore the following guiding criteria were identified. 

Flexibility as cost (effort) of a to be expected configuration - mitigated by allowing variable analysis models / maximizing configurability



Security as cost (effort) of compliance - currently de-scoped



Extensibility as cost (effort) for changes in the architecture (minimize architecture constraints) - mitigated by considering generic evaluation / universality of semantics



Interoperability as the cost (effort) to minimize dependency and to maximize use of information - mitigated by introducing a unifying (scaling) semantic



Scalability cost (effort) to scale in time per evaluation, effort to scale in size of storage - mitigated by applying cloud technology



Performance as cost of processing delay



Consistency as cost of inconsistency (lazy) construction of constellations



Programmatic constraints cost of deployed product licenses



Risk of Compliance

For application of cloud technology reference, see [D3.1}]. The mobile telecommunication network itself forms a part of the environment where the sensors already site as data and/or information provider. Reference is made to the module view, see section 4.2 Module View. 4.4.2 Allocations and Dependencies allocated-to and migrates-to between units and software elements where the software elements reside is to be clarified.

88



sensor(s) (draft attached to mobile communication network)



context collector(s) (draft attached to sensor environment)



reader (draft attached to cloud)



repository (draft attached to cloud)



store and forwarder (draft attached to mobile communication network)



5 Discussion & Summary From the initially derived intent to maximize economic payoff for interactions carried out in mobile telecommunication networks it is necessary to develop associated security risk as a global perspective of the society transparent and traceable to security deficits. Current state of the art is focused on technical aspects of security failing to integrate social or business aspects. Technical means like redundancy lead to properties like robustness and reliability. As soon as these properties are affected or disappear, e.g. recognized by sensors or sensor subsystem components reactive incident response becomes necessary requiring efficient use of high qualified human resources. Because of the asynchrony and the asymmetry it is of high benefit that these specialists share current threat patterns and expertise in defending. This conclusion is in alignment with the many emerging exchange formats and the many CERTs, see e.g. CERTs in Europe map, http://www.enisa.europa.eu/act/cert/background/inv/files/certs-in-europe-map. To enable interoperation there are emerging standards for continuous monitoring although there is currently to the knowledge of the authors no standard under preparation for a unified interpretation as outlined in this document. The main challenge is to cope with black boxes within a system that do not declare security properties. Because of the inherent service interdependence and the associated value interdependencies an approach is outlined how to create a perspective on the telecommunication system that allows to conclude about current security risk. As outlined this requires to share a common semantics of agreed risk together with a rationale that is sufficiently flexible to interpret security for a evolving large scale telecommunication system. The same mechanism can then be used for incentives of sharing currently hidden knowledge on vulnerabilities or countermeasures leading finally to a higher security in terms of the supervised properties. To evaluate measurements as outlined computational effort will be high which lead to the application of sharing approaches and cloud computation. We see the open questions in making security risk transparent without disclosing disadvantageously, illegal or incompliance secrets. We seek for a well-founded semantics for interpreting the security properties of a service invocation where coalgebras will be a promisingly simple and formal approach that allow decoupling measurements from observations hence allowing to compare behavior and recognize behavioral deviation as an approximation for security classification. It will be also a challenge to provide human interaction that hides the complex evaluation but allows to explore root causes for a security deficit or interaction that allows to claim risk based on security deficit. Finally, the completeness question is open, i.e. if each relevant behavioral deviation is detectable remains upfront open but is approached by designing an evolving system. We observed a lack of formalism allowing to conclude sound on security characteristics which will be developed in future Way ahead will be the application and elaboration on the outlined concepts to concrete the enterprise architecture domains outlined so far. This comprises definitions of business, information, application and technology domain for a mobile telecommunication system in terms of the concepts as well as the supplementation by approaches especially the uniform interpretation of measurements as a central enabler for the outlined Continuous Security Monitoring capability. Similarly the other capabilities, namely Continuous Security Monitoring, Continuous Security Model Adaptation, Continuous Security Economics Analysis, Continuous Security Awareness, Continuous Security Collaboration will guide the development of the enterprise


89

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 architecture model. Finally this will lead to a technology selection supporting the outlined information flow and the intended collaboration to enable security risk reduction. For instance we will add malware detection mechanisms e.g. honeypots to improve the precision and reduction of the identified security risk. Identified technologies like machine learning or human interaction design will be validated on examples using either models or simulation. Finally the resulting enterprise architecture will be validated against the central requirement on security risk transparence meaning that behavioral (security) deficits or deviations will become observable on a network scale and impact on value flows will become transparent. The effort necessary to implement the capabilities needs to be opposed against the to be expected use or value to prepare a business case for migration.

90



References [AI] [ARF] [ASR] [Bas2003]

Asset Information (AI) Interagency Report 7693; National Institute of Standards and Technology; 2011 http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf Assessment Results Format (ARF); MITRE http://measurablesecurity.mitre.org/incubator/arf/ Assessment Summary Results (ASR); MITRE http://measurablesecurity.mitre.org/incubator/asr/ Software Architecture in Practice (SEI Series in Software Engineering); Len Bass, Paul Clements, Rick Kazman; AddisonWesley Longman, Amsterdam; 2003

[Ber2003]

Intelligent Data Analysis: An Introduction; Ed Berthold; Springer Berlin Heidelberg; 2003

[Ber2010]

Guide to Intelligent Data Analysis: How to Intelligently Make Sense of Real Data (Texts in Computer Science); Michael R. Berthold, Christian Borgelt, Frank Höppner, Frank Klawonn; Springer London; 2010

[BITKOM2005]

Ein nationales IT- Frühwarnsystem für Deutschland Positionspapier der ITK-Wirtschaft; Bundesverband Informationswirtschaft Telekommuniaktion und neue Medien e.V.; 2005 http://www.bitkom.org/files/documents/positionspapier_itfws_in_deutschland_v1.0f.pdf Formal Models of Communicating Systems: Languages, Automata, and Monadic Second-Order Logic; Benedikt Bollig; Springer Berlin Heidelberg; 2010

[Bol2010]

[Bra2004]

Knowledge Representation and Reasoning, Ronald J. Brachman, Hector J. Levesque; Morgan Kaufmann Series in Artificial Intelligence; Elsevier Science & Technology; 2004 PROLOG Programming for Artificial Intelligence; Ivan Bratko; International Computer Science Series; Addison-Wesley Educational Publishers Inc; 2011

[CAESARS]

[CAIF] [CAPEC] [CCE]

Continuous Asset Evaluation, Situational Awareness, and Risk Scoring Reference Architecture Report (CAESARS), Department oh Homeland Security, Federal Network Security Branch; Version 1.8; 2010 http://www.dhs.gov/xlibrary/assets/fns-caesars.pdf Common Announcement Interchange Format (CAIF); RUSCERT; 2005 http://www.caif.info/ Common Attack Pattern Enumeration and Classification (CAPEC); MITRE http://capec.mitre.org Common Configuration Enumeration and Exposures (CCE); MITRE http://cce.mitre.org


91


[CCSS]

[CEE] [CEE] [CEF] [CIDEE] [Cle2001]

Common Configuration Scoring System (CCSS); Interagency Report 7502; National Institute of Standards and Technology; 2010 http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf Common Event Expression (CEE); MITRE http://cee.mitre.org Common Event Expression (CEE); MITRE http://cee.mitre.org Common Event Format (CEF); ArcSight; 2006 http://www.arcsight.com/collateral/CEFstandards.pdf Cisco Intrusion Detection Event Exchange (CIDEE), CISCO http://www.cisco.com/en/US/docs/security/ips/specs/CIDEE_Spe cification.htm Evaluating Software Architectures: Methods and Case Studies (SEI Series in Software Engineering); Paul Clements, Rick Kazman, Mark Klein; Addison-Wesley Longman, Amsterdam; 2001

[Cle2010]

Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering); Paul Clements, Felix Bachmann, Len Bass, David Garlan; Addison Wesley; 2010

[Cor2009]

Introduction to Algorithms; Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein; MIT Press; 2009

[CPE]

Common Platform Enumeration and Classification (CPE); MITRE http://cpe.mitre.org Common Vulnerabilities and Exposures (CVE); MITRE http://cve.mitre.org Common Frameworks for Vulnerability Disclosure and Response (CVRF) Industry Consortium for Advancement of Security on the Internet http://www.icasi.org/cvrf Common Vulnerability Scoring System (CVSS); FIRST http://www.first.org/cvss/ Common Vulnerabilities and Exposures (CWE); MITRE http://cwe.mitre.org D1.1: Reference Architecture for Collaboration in Mobile Networks; ASMONIA Project; 2011 http://www.asmonia.de/deliverables/D1.1_ReferenceArchitecture ForCollaborationInMobileNetworks.pdf D2.1: Evaluating Methods to assure System Integrity and Requirements for Future Protection Concepts; ASMONIA Project; 2011 http://www.asmonia.de/deliverables/D2.1_EvaluatingMethodsToA ssureSystemIntegrityAndRequirementsForFutureProtectionConc epts.pdf D3.1: Analysis of Requirements for the Deployment of Cloud Systems; ASMONIA Project; 2011 http://www.asmonia.de/deliverables/D3.1_AnalysisOfRequiremen tsForTheDeploymentOfCloudSystems.pdf

[CVE] [CVRF]

[CVSS] [CWE] [D1.1]

[D2.1]

[D3.1]

92



[D5.1]

[DAF] [EISPP] [ENISA2009]

[ENISA2010]

[Erl2007]

[FINE] [For2010] [Fow2003]

D5.1(I): Threat and Risk Analysis for Mobile Communication Networks and Mobile Terminals; ASMONIA Project; 2011 http://www.asmonia.de/deliverables/D5.1_I_ThreatAndRiskAnaly sisMobileCommunicationNetworksAndTerminals.pdf Deutsches Advisory Format (DAF), CERT-Verbund; 2005 http://www.cert-verbund.de/daf/daf_description.html EISPP Common Advisory Format (EISPP), EISPP Consortium ; 2004 http://www.cert-verbund.de/daf/documentation/eispp_v20.pdf Baseline capabilities for national / governmental CERTs (Part 1 Operational Aspects); European Network and Information Security Agency; 2009 http://www.enisa.europa.eu/act/cert/support/files/baselinecapabilities-for-national-governmentalcerts/at_download/fullReport Baseline Capabilities of National/Governmental CERTs (Part 2 Policy Recommendations); European Network and Information Security Agency; 2010 http://www.enisa.europa.eu/act/cert/support/files/baselinecapabilities-of-national-governmental-certs-policyrecommendations/at_download/fullReport SOA Principles of Service Design; Thomas Erl; Prentice Hall Service-Oriented Computing Series; Prentice Hall International; 2007 Format for INcident information Exchange (FINE); Internet Engineering Task Force; 2006 http://tools.ietf.org/html/draft-ietf-inch-requirements-08 LTE Security; Günther Horn, Dan Forsberg, Wolf-Dietrich Moeller, Valtteri Niemi; John Wiley & Sons Ltd.; 2010 UML Distilled: A Brief Guide to the Standard Object Modeling Languange; Martin Fowler; Addison-Wesley Object Technology Series, Addison-Wesley Longman, Amsterdam; 2003

[Hop2007]

Introduction to Automata Theory, Languages and Computation; John E. Hopcroft, Rajeev Motwani, Jeffrey D. Ullman; AddisonWesley Longman, Amsterdam; 2007

[IDMEF]

The Intrusion Detection Message Exchange Format (IDMEF); Internet Engineering Task Force; 2007 http://www.ietf.org/rfc/rfc4765.txt The Incident Object Description Exchange Format (IODEF); Internet Engineering Task Force; 2007 http://tools.ietf.org/html/draft-ietf-inch-iodef-14 ISO/IEC 12207:2008 - Systems and software engineering Software life cycle processes; International Organization for Standardization; 2008 ISO/IEC JTC 1 SC 27 Standing Document 6 (SD 6) - Glossary of IT Security Terminology Terms and definitions; International Organization for Standardization; 2010

[IODEF] [ISO12207] [ISOJTC]


93


[Jos2007]

SOA in Practice: The Art of Distributed System Design; Nicolai M. Josuttis, Simon St.Laurent, Jessamyn Read; O'Reilly Media; 2007

[MAEC]

Malware Attribute Enumeration and Characterization (MAEC); MITRE http://maec.mitre.org Introduction to Information Visualization; Riccardo Mazza; Springer London; 2009

[Maz2009] [Nis2007]

Algorithmic Game Theory; Noam Nisan, Tim Roughgarden, Eva Tardos, Vijay V. Vazirani; Cambridge University Press; 2007

[Nis2009]

Handbook of Statistical Analysis and Data Mining Applications; Robert Nisbet, John Elder, Gary Miner; Academic Press; 2009

[NVD]

National Vulnerability Database (NVD) http://nvd.nist.gov/ Open Checklist Interactive Language (OCIL); National Institute of Standards and Technologiy http://scap.nist.gov/specifications/ocil/ An Introduction to Game Theory; Martin J. Osborne; Oxford University Press; 2009

[OCIL] [Osb2009] [OVAL] [PLARR] [Rac2009]

Open Vulnerability and Assessment Language (OVAL); MITRE http://oval.mitre.org/ Policy Language for Assessment Results Reporting (PLARR); MITRE http://measurablesecurity.mitre.org/incubator/plarr/ TOGAF Version 9: A Pocket Guide; Andrew Josey, Rachel Harrison, Paul Homan; Van Haren Pub; 2009

[Ras2000]

The Humane Interface. New Directions for Designing Interactive Systems; Jef Raskin; Addison-Wesley Longman; 2000

[RFC3179]

RFC 3176 - InMon Corporation's sFlow; Internet Engineering Task Force; 2001 http://tools.ietf.org/html/rfc3176 RFC 3410 - Introduction and Applicability Statements for InternetStandard Management Framework; Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3410 RFC 3411 - An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks; Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3411 RFC 3412 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP); Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3412 RFC 3413 - Simple Network Management Protocol (SNMP) Applications; Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3413

[RFC3410]

[RFC3411]

[RFC3412]

[RFC3413]

94



[RFC3414]

[RFC3415]

[RFC3416]

[RFC3417]

[RFC3418]

[RFC3917 [RFC3954] [RFC5424] [Rus2010]

[SCAP] [SDEE] [SEI2002]

[SEI2003a

[SEI2003b]

RFC 3414 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3); Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3414 RFC 3415 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP); Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3415 RFC 3416 - Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP); Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3416 RFC 3417 - Transport Mappings for the Simple Network Management Protocol (SNMP); Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3417 RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP); Internet Engineering Task Force; 2002 http://tools.ietf.org/html/rfc3418 RFC 3917 - IP Flow Information Export (IPFIX); Internet Engineering Task Force; 2004 http://tools.ietf.org/html/rfc3917 RFC 3954 - Cisco Systems NetFlow Services Export Version 9); Internet Engineering Task Force; 2004 http://tools.ietf.org/html/rfc3954 RFC 5424 - The Syslog Protocol; Internet Engineering Task Force; 2009 http://tools.ietf.org/html/rfc5424 Artificial Intelligence: A Modern Approach; Stuart J. Russell, Peter Norvig; Prentice Hall Series in Artificial Intelligence; Prentice Hall; 2010 Security Content Automation Protocol (SCAP), National Institute for Standard and Technology http://scap.nist.gov/index.html Security Device Event Exchange (SDEE), International Computer Security Association http://cpan.uwinnipeg.ca/htdocs/Net-SDEE/Net/SDEE.html CMU/SEI-2002-TR-009: Evolutionary Process for Integrating COTS-Based Systems (EPIC): An Overview; Software Engineering Institute, Carnegie Mellon University; 2002 CMU/SEI-2003-HB-001 - Organizational Models for Computer Security Incident Response Teams (CSIRTs); Software Engineering Institute, Carnegie Mellon University; 2003 http://www.cert.org/archive/pdf/csirt-handbook.pdf CMU/SEI-2003-HB-002 - Handbook for Computer Security Incident Response Teams (CSIRTs); Software Engineering Institute, Carnegie Mellon University; 2003 http://www.cert.org/archive/pdf/csirt-handbook.pdf


95


[SEI2003c]

[SEI2004a] [SEI2004b

[SEI2006]

[SEI2010]

[Sho2008]

[TS 21.905] [TS 22.115] [TS 22.228]

[TS 23.002] [TS 23.110]

[TS 23.203] [TS 32.240]

[TS 32.250]

96

CMU/SEI-2003-TR-001 - State of the Practice of Computer Security Incident Response Teams (CSIRTs); Software Engineering Institute, Carnegie Mellon University; 2003 http://www.cert.org/archive/pdf/03tr001.pdf Steps for Creating National CSIRTs; Software Engineering Institute, Carnegie Mellon University; 2004 http://www.cert.org/archive/pdf/NationalCSIRTs.pdf CMU/SEI-2004-TR-015 - Defining Incident Management Processes for CSIRTs: A Work in Progress; Software Engineering Institute, Carnegie Mellon University; 2004 http://www.cert.org/archive/pdf/04tr015.pdf Action List for Developing a Computer Security Incident Response Team (CSIRT); Software Engineering Institute, Carnegie Mellon University; 2006 http://www.cert.org/archive/pdf/csirts_action_list.pdf CMU/SEI-2010-SR-009 - Best Practices for National Cyber Security: Building a National Computer Security Incident Management Capability; Software Engineering Institute, Carnegie Mellon University; 2010 http://www.cert.org/archive/pdf/10sr009.pdf Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations; Yoav Shoham, Kevin Leyton-Brown; Cambridge University Press; 2008 TS 21.905 Vocabulary for 3GPP Specifications; V10.2.0; 3rd Generation Partnership Project; Sophia Antipolis; 2010 http://www.3gpp.org/ftp/Specs/html-info/21905.htm TS 22.115 Service aspects; Charging and billing; V11.1.1; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/22115.htm TS 22.228 Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); V11.2.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/specs/html-info/22228.htm TS 23.002 Network architecture; V10.2.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/23002.htm TS 23.110 Universal Mobile Telecommunications System (UMTS) access stratum; Services and functions; V10.0.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/23110.htm TS 23.203 Policy and charging control architecture; V11.1.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/23203.htm TS 32.240 Telecommunication management; Charging management; Charging architecture and principles; V11.0.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/32240.htm TS 32.250 Telecommunication management; Charging management; Circuit Switched (CS) domain charging; V10.0.1; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/32250.htm Copyright © 2011 ASMONIA consortium. All rights reserved.

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 [TS 32.251]

[TS 32.297]

[TS 32.298]

[Win1993]

TS 32.251 Telecommunication management; Charging management; Packet Switched (PS) domain charging; V10.4.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/specs/html-info/32251.htm TS 32.297 Telecommunication management; Charging management; Charging Data Record (CDR) file format and transfer; V10.0.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/Specs/html-info/32297.htm TS 32.298 Telecommunication management; Charging management; Charging Data Record (CDR) parameter description; V10.4.0; 3rd Generation Partnership Project; Sophia Antipolis; 2011 http://www.3gpp.org/ftp/specs/html-info/32298.htm The Formal Semantics of Programming Languages: An Introduction (Foundations of Computing); Glynn Winskel; MIT Press; 1993

[Woo2009]

An Introduction to MultiAgent Systems; Michael J. Wooldridge; Wiley & Sons; 2009

[XCCDF]

Extensible Configuration Checklist Description Format (XCCDF); National Institute of Standards and Technologiy http://scap.nist.gov/specifications/xccdf/


97


Glossary and Abbreviations Glossary Term

Explanation

Anomaly

In ASMONIA an anomaly denotes a measurable and detected deviation from an expected system behavior, value, or capability. In particular, this includes findings of malware detection tools, failure messages generated by methods applied for system and software integrity validation as well as conspicuousness found by any other system monitoring and the evaluation hereof.

Anonymity and Privacy Module (APM)

An element of the ASMONIA reference architecture in a participant's network for preprocessing of the participant's information that shall be shared with other ASMONIA participants. The preprocessing ensures the sanitization and/or conversion of the information to be exchanged to preserve the originator’s anonymity and privacy.

ASMONIA Collaboration Gateway (ACGW)

An element of the ASMONIA reference architecture in a participant's network that represents the physical border between the participant's network and the ASMONIA collaboration network and fulfils the tasks required for collaborative information exchange with other participants.

ASMONIA Collaboration Network (ACN)

An information sharing network constructed by two or more administrative domains with the goal to share incident related data between the ACN participants for attack mitigation and risk reduction.

ASMONIA Policy:

A set of rules the participants of an ACN agree on that defines the behavioral code, rights, and duties of the participants.

ASMONIA System An instantiation of the ASMONIA reference architecture, policy and security baseline based on the respective parameters defined by the system's participants. This is a technical term, which has been introduced by 3GPP, TS Autonomous 33.320 in the context of Home eNB security standardization. This term Validation is related to the mandatory integrity self-check of Home eNBs before connecting to the mobile network. Home eNBs, which do not successfully complete the self-checking process block the key required for device authentication. In case a Home eNB connects and successfully authenticates to the network it is implicitly validated (this is the core meaning of 'autonomous validation' from a network point of view). In ASMONIA this term may also be used in a wider context, e.g., as a synonym for a system's capability to take autonomous validation decisions and to enforce these without help of external entities (system point of view). A reliable piece of information indicating the presence or emergence of Early Warning a security relevant incident that allows reacting to a potential threat if necessary and mitigating its negative impact. A logical component that combines all functionalities required to fulfill a Functional specific task of an ASMONIA system. Currently three FCs exist: Cluster (FC) Integrity Protection (IP), Collaborative Cloud (CC), and Monitoring and Analysis (MA). In the Threat and Risk Analysis for mobile communication networks Impact (of a carried out in AP5, impact of a threat is the harm that can be caused by threat) attacks corresponding to the threat. 98


Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Term

Explanation

Integrity Violation This term describes detected deviations from an expected capability, behavior or value (e.g., a reported system state or cryptographic signature). In ASMONIA such deviation may stem from cryptographic integrity checks, as well as from malware analysis tools. In the Threat and Risk Analysis for mobile communication networks Likelihood (of a carried out in AP5, this is the likelihood for an attacker to launch a threat): corresponding attack, independent of the available security measures. The likelihood is classified according to how often is an attack expected to happen (like "less than once a year" or "less than once a week"). Normalization and An element of the ASMONIA reference architecture that facilitates operator-internal exchange of data between FCs by realizing the data Format Module conversion into one common format. (NFM) Reputation Monitoring Module (RMM)

An element of the ASMONA reference architecture that stores information about the reliability of warnings and their sources.

In the Threat and Risk Analysis for mobile communication networks carried out in AP5, where assets are terminals, network elements or groups of network elements, the risk captures, for a given asset and threat, the likelihood of an attack corresponding to the threat, the vulnerability of the asset against such attacks, and the possible impact of such attacks. Overall, the risk indicates, in a relative way, how relevant a threat is for an asset. Security Baseline A set of minimum requirements that have to be fulfilled by a participant to be allowed to join an ASMONIA system. Software Integrity Software Integrity denotes that a system's software is identical to a reference software, which stems from an authoritative source, e.g., an authorized software vendor. To verify software integrity a bundle of measures is required. Partly cryptographic mechanisms can be applied, but these only can compare software in a certain state (e.g., as it has been delivered or as has it been written into a system's ROM), but does not include deviations from an expected behavior, which can occur during the dynamic operation of a system. Such changes can be caused by real code modifications in memory, but also by maliciously injected or generated code (malware), which cannot be checked by cryptography, in particular if such code is executed in stack or heap areas. Thus, proof of integrity may also comprise analysis of malware, where known 'bad' patterns are detected (even within code that has been cryptographically protected). In addition attestation principles can be applied, where software integrity is evaluated by an external entity, which receives a system's state via a secured reporting mechanism. Similar to a system's software, here the integrity of an entire system System Integrity (compared to a reference system) is addressed. Even if in theory the proof of a system's integrity is imaginable, in practice it cannot be verified in an automated manner - in particular if a system in all its capabilities and aspects should be comprised. Thus, in many cases the system integrity is reduced to its Software Integrity and the proof of a burned-in HW identity, so that it can be detected, whether a system is unique (i.e., 'not cloned') and has been programmed and deployed by an authorized manufacturer. Technically, proof of hardware integrity in field is unfeasible as it involves very complex and cost intensive Risk


99

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Term

Threat

Translation Module (TM)

Vulnerability Vulnerability Factor

Explanation methods and processing steps, which require dedicated equipment and laboratories.. According to ISO13335-4, a threat is "a potential cause of an incident that may result in harm to a system or organization" (ISO13335-4). As an example, the Threat and Risk Analysis for mobile communication networks carried out in AP5 considers threats that correspond to attacks like "Flooding an interface", "Crashing a network element via a protocol or application implementation flaw" or "Compromise of a network element via a management interface". An element of the ASMONIA reference architecture that facilitates data exchange between heterogeneous types of sensors and their corresponding modules for analysis. The module furthermore converts different types of sensor data into a common format. According to ISO13335-4 a vulnerability is "a weakness of an asset or group of assets that can be exploited by one or more threats". The vulnerability factor describes an asset's overall state with regard to vulnerabilities related to a specific threat, i.e. it expresses how vulnerable the asset is against attacks corresponding to the specific threat.

Abbreviations

Abbreviation

Explanation

NIST

National Institute of Standards and Technology

100



Revision History Version 0.1 0.2 0.3 1.0

Date 2011-09-05 2011-10-12 2011-10-25 2011-10-27

Changes Initial version. Review Version for ASMONIA Consortium Incorporation of review comments Release


101


Annex A 3GPP Policy and Charging Architecture The following content is an excerpt of 3GPP Standardization [TS 23.203], [TS 22.115], [TS 32.240], [TS 32.251], [TS32.297] and [TS 32.298] focused on policy and charging (control).

A.1 General Requirements  

 

      

      

102

It shall be possible for the PCC architecture to base decisions upon subscription information. It shall be possible to apply policy and charging control to any kind of 3GPP IP CAN and any non-3GPP accesses connected via EPC complying with [TS 23.402]. Applicability of PCC to other IP CANs is not restricted. However, it shall be possible for the PCC architecture to base decisions upon the type of IP CAN used (e.g. GPRS, I-WLAN, etc.). The policy and charging control shall be possible in the roaming and local breakout scenarios defined in [TS 23.401] and [TS 23.402]. The PCC architecture shall discard packets that don't match any service data flow filter of the active PCC rules. It shall also be possible for the operator to define PCC rules, with wild-carded service data flow filters, to allow for the passage and charging for packets that do not match any service data flow filter of any other active PCC rules. The PCC architecture shall allow the charging control to be applied on a per service data flow basis, independent of the policy control. The PCC architecture shall have a binding method that allows the unique association between service data flows and their IP CAN bearer. A single service data flow template shall suffice, to detect a service data flow, for the purpose of both policy control and flow based charging. A PCC rule may be predefined or dynamically provisioned at establishment and during the lifetime of an IP CAN session. The latter is referred to as a dynamic PCC rule. The number of real-time PCC interactions shall be minimized although not significantly increasing the overall system reaction time. This requires optimized interfaces between the PCC nodes. It shall be possible to take a PCC rule into service, and out of service, at a specific time of day, without any PCC interaction at that point in time. PCC shall be enabled on a per PDN basis (represented by an access point and the configured range of IP addresses) at the PCEF. It shall be possible for the operator to configure the PCC architecture to perform charging control, policy control or both for a PDN access. PCC shall support roaming users. The PCC architecture shall allow the resolution of conflicts which would otherwise cause a subscriber’s Subscribed Guaranteed Bandwidth QoS to be exceeded. The PCC architecture shall support topology hiding. It should be possible to use PCC architecture for handling IMS-based emergency service. It shall be possible with the PCC architecture, in real-time, to monitor the overall amount of resources that are consumed by a user and to control usage independently from charging mechanisms, the so-called usage monitoring control. It shall be possible for the PCC architecture to provide application awareness even when there is no explicit service level signaling. The PCC architecture shall support making policy decisions based on subscriber spending limits. Copyright © 2011 ASMONIA consortium. All rights reserved.


A.2 Reference Architecture The PCC functionality is comprised by the functions of the Policy and Charging Enforcement Function (PCEF), the Bearer Binding and Event Reporting Function (BBERF), the Policy and Charging Rules Function (PCRF), the Application Function (AF), the Traffic Detection Function (TDF), the Online Charging System (OCS), the Offline Charging System (OFCS) and the Subscription Profile Repository (SPR) or the User Data Repository (UDR). UDR replaces SPR when the UDC architecture as defined in [TS 23.335] is applied to store PCC related subscription data. In this deployment scenario Ud interface between PCRF and UDR is used to access subscription data in the UDR. NOTE 1: When UDC architecture is used, SPR and Sp, whenever mentioned in this document, can be replaced by UDR and Ud. The PCC architecture extends the architecture of an IP CAN, where the Policy and Charging Enforcement Function is a functional entity in the Gateway node implementing the IP access to the PDN. The allocation of the Bearer Binding and Event Reporting Function is specific to each IP CAN type. The non-3GPP network relation to the PLMN is the same as defined in [TS 23.402].

Figure 27: 3GPP Policy and Charging Reference Architecture In order to allow for charging control, the information in the PCC rule identifies the service data flow and specifies the parameters for charging control. The PCC rule information may depend on subscription data. For the purpose of charging correlation between application level (e.g. IMS) and service data flow level, applicable charging identifiers shall be passed


103

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 along within the PCC architecture, if such identifiers are available. For the purpose of charging correlation between service data flow level and application level (e.g. IMS) as well as on-line charging support at the application level, applicable charging identifiers and IP CAN type identifiers shall be passed from the PCRF to the AF, if such identifiers are available.

A.3 Charging Models The PCC charging shall support the following charging models: 

Volume based charging;



Time based charging;



Volume and time based charging;



Event based charging;



No charging.

NOTE 1: The charging model - "No charging" implies that charging control is not applicable. Shared revenue services shall be supported. In this case settlement for all parties shall be supported, including the third parties that may have been involved providing the services. NOTE 2: When developing a charging solution, the PCC charging models may be combined to form the solution. How to achieve a specific solution is however not within the scope of this TS.

A.4 Charging Requirements 

It shall be possible to apply different rates and charging models when a user is identified to be roaming from when the user is in the home network. Furthermore, it shall be possible to apply different rates and charging models based on the location of a user, beyond the granularity of roaming.



It shall be possible to apply different rates and charging models when a user consuming network services via a CSG cell or a hybrid cell according to the user CSG information. User CSG information includes CSG ID, access mode and CSG membership indication.



It shall be possible to apply a separate rate to a specific service, e.g. allow the user to download a certain volume of data, reserved for the purpose of one service for free, and then continue with a rate causing a charge.



It shall be possible to change the rate based on the time of day.



It shall be possible to enforce per-service usage limits for a service data flow using online charging on a per user basis (may apply to prepaid and post-paid users).



It shall be possible for the online charging system to set and send the thresholds (time and/or volume based) for the amount of remaining credit to the PCEF for monitoring. In case the PCEF detects that any of the time based or volume based credit falls below the threshold, the PCEF shall send a request for credit reauthorization to the OCS with the remaining credit (time and/or volume based).



It shall be possible for the charging system to select the applicable rate based on:

104

o

home/visited IP CAN;

o

User CSG information; Copyright © 2011 ASMONIA consortium. All rights reserved.

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 o

IP CAN bearer characteristics (e.g. QoS);

o

QoS provided for the service;

o

time of day;

o

IP CAN specific parameters.



The charging system maintains the tariff information, determining the rate based on the above input. Thus the rate may change e.g. as a result of IP CAN session modification to change the bearer characteristics provided for a service data flow.



The charging rate or charging model applicable to a service data flow may change as a result of events in the service (e.g. insertion of a paid advertisement within a user requested media stream).



The charging model applicable to a service data flow may change as a result of events identified by the OCS (e.g. after having spent a certain amount of time and/or volume, the user gets to use some services for free).



The charging rate or charging model applicable to a service data flow may change as a result of having used the service data flow for a certain amount of time and/or volume.



In the case of online charging, it shall be possible to apply an online charging action upon PCEF events (e.g. re-authorization upon QoS change).



It shall be possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, i.e. to perform neither accounting nor credit control for this service data flow, and then no offline charging information is generated.

A.5 Charging Information Requirements Charging information shall be collected in the Serving Network to record chargeable User or Mobile Station activity and inter-carrier connections. Some of the information is provided by the user, other information is only available in the network element of the serving network. Depending on the type of charging information some of the data may not be available or might not be required. Information provided by the user 

The user’s user equipment that is incurring the charge shall provide the following information to the serving network:



User identity used for authentication;



Home environment identity;



Terminal Identity and Terminal Class;



Destination endpoint identifier for service requested (e.g. B number);



Resource requested (e.g. bandwidth, connectionless);



QoS parameters (e.g. maximum delay);



IP Multimedia capability requested (e.g. media components).


105

Development and redevelopment of sensors Data and Information Provider for ASMONIA D4.1(i) – 1.0 Information provided by the serving network 

The network serving the user shall provide the following information to the home environment:



All of the information listed in section above (Information provided by the user);



Serving network identity;



Recording network element identity;



Universal Time (UT) at which the service request was initiated;



Universal Time (UT) at which resources were provided for the service;



Universal Time (UT) at which the service execution was successfully completed;



Universal Time (UT) at which the service execution was unsuccessfully completed;



Local time of the serving cell when the service request was initiated for the originating or terminating UE. This could either be explicitly



reported, or implicitly reported by providing three pieces of information: the UTC, the time zone offset from UTC, and an indication of



daylight savings time;



Cause for unsuccessful completion of the service execution. At least the following causes shall be included:



the terminating party does not respond;



communication rejected by the terminating party;



network determined terminating party busy;



network congestion;



terminating party non reachable (out of coverage, switched-off);



destination non reachable (non active address, non-existing address).



Resource allocated to the user;



Quantity of data transferred both to and from the user;



QoS provided to the user;



Location of the user in the standard format used for 3GPP location based services (e.g. geographical



co-ordinates, Cell ID);



Network determined PLMN ID and Cell ID;



whether GSM Optimal Routing was applied;



If IMS, IN or CAMEL services were applied, the service parameters and the actually used destination number or identifier and calling



party identifier;



Time duration covered by this charging information to an accuracy of at least 1 second;

106



Unique identity of the chargeable event which allows the billing system to correlate all charging information belonging to the same



chargeable event;



Unique charging information identity (unique per network element in a period of about 100 days);



IP Multimedia capability provided to the user;



VAS information;



Identifier of third party accessed by the user;



Presence Information;



Service Identification (eg voice call, video call, data download etc);



Supplementary Services used;



Prepay account identifier and related information.

Information provided by the third party accessed by the user Supply of Value Added Services, especially in IP based environment, is often made with the aid of third parties typically represented by portals and content/application providers. To execute an effective charging of these services, the following charging information should be provided by the third party: 

Third party identity;



Type of service (information, entertainment, gaming, public utility);



Change in the type of service provided to the user;



Type of content (picture, videoclip, mp3 file, java file);



Universal Time (UT) at which the service request was initiated;



If a service change happens, Universal Time (UT) at which the service provision was initiated;



Universal Time (UT) at which the service execution was successfully completed;



Universal Time (UT) at which the service execution was unsuccessfully completed;



Cause for unsuccessful completion of the service execution. At least the following causes shall be included:



the terminating party does not respond;



communication rejected by the terminating party;



network determined terminating party busy;



-network congestion;



terminating party non reachable (out of coverage, switched-off);



destination non reachable (non active address, non-existing address).



Cause for Abnormal reject of the service;



Universal Time (UT) for abnormal reject of the service


107


A.6 Charging Architecture Offline Charging Functions

Figure 28: 3GPP Offline Charging Architecture Charging Trigger Function The Charging Trigger Function (CTF) generates charging events based on the observation of network resource usage as described in clause 4.1.1. In every network and service element that provides charging information, the CTF is the focal point for collecting the information pertaining to chargeable events within the network element, assembling this information into matching charging events, and sending these charging events towards the Charging Data Function. The CTF is therefore a mandatory, integrated component in all network elements that provide offline charging functionality, as depicted in figure 4.2. It is made up of two functional blocks, Accounting Metrics Collection and Accounting Data Forwarding. The behavior of the CTF with respect to the definition of the chargeable events, the matching charging events and the information elements to collect is specified per domain, subsystem and service in the respective middle tier charging. Charging Data Function The Charging Data Function (CDF) receives charging events from the Charging Trigger Function via the Rf reference point. It then uses the information contained in the charging events to construct CDRs. This procedure is characterized by the following conditions:

108



CDRs may be constructed from single charging events, i.e. a 1:1 relation between event and CDR



CDRs may be constructed from a set of several charging events, i.e. a n:1 relation between event and CDR.



Each charging event is used for exactly one CDR, i.e. a 1:n relation between event and CDR (with n>1) is not possible.



Multiple charging events that are used to create a single CDR may not necessarily be of the same type.



There is no requirement or assumption of any synchronization between the reception of the charging event(s) and the creation of the resulting CDR. However, the CDF shall be capable of receiving and processing charging events and generating the resulting CDR in near real-time.



The relationship between CDF and CTF may be 1:1 (integrated CDF) or 1:n (separated CDF). This includes the possibility of NEs of different types feeding charging events into the same CDF.



All charging events used to build a CDR must originate from the same NE, i.e. there is no cross-NE or cross-NE-type correlation of charging events in the CDF.

The results of the CDF tasks are charging data records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain / subsystem / service in the related middle tier charging specification. Charging Gateway Function The CDRs produced by the CDF are transferred immediately to the Charging Gateway Function (CGF) via the Ga reference point. The CGF acts as a gateway between the 3GPP network and the Billing Domain. It uses the Bx reference point for the transfer of CDR files to the BD. The entity relationship between the CDF and the CGF is m:1, i.e. one or more CDFs may feed CDRs into a single CGF. The CGF comprises the following main functions: 

CDR reception from the CDF via the Ga reference point in near real-time.



CDR pre-processing: o

Validation, Consolidation and (Re-) Formatting of CDRs.

o

CDR error handling.

o

Persistent CDR storage.



CDR routing and filtering, i.e. storing CDRs on separate files based on filtering criteria such as CDR type, CDR parameters, originating CDF, etc.



CDR File Management, e.g. file creation, file opening / closure triggers, file deletion.



CDR file transfer to the BD.


109


Online Charging Functions

Figure 29: 3GPP Online Charging Architecture The Online Charging System will not be considered in detail. Please see [TS 32.240] for further details.

110
