We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FI-WARE Security - FIWARE Forge Wiki

FI-WARE Security

From FIWARE Forge Wiki

(Redirected from Security)
Jump to: navigation, search

IMPORTANT NOTE: This page is deprecated. Please refer to the most updated description of the FI-WARE Security Architecture

Overview

Contents

Future Internet is expected to implement what is commonly called as a “Internet of Services”(IoS), a generalized service-oriented architecture where services and service providers will collaborate and compete.

In this IoS, the necessity of individualization will require the capacity to guarantee that the personal information provided by users will be processed in accordance with the user rights and requirements. As a common example, let’s say you want to create a Multimodal travel made easy, online services offer a traveler a wide range of travel and transport options, according to the user’s preferences, for all the stages of a trip that may use various modes including public transport, car, and non-motorized means. In that case new security and privacy functions are required to propagate geo-localization and geo-referencing data facilitating safe and easy rendez-vous between drivers and travelers, payment information allowing proportional automatic contribution to journey or specific security functions ensuring the safety of all participants through a careful set of preventive, en-route and forensics functions.

Future Internet services will always be exposed to different types of threats that can lead to severe misuse and damage. Creating secured and trusted services without sacrificing much of the desired functionality, usability, performance and cost efficiency is a great challenge, especially in a dynamic environment where new threats and attack methods emerge on a daily basis.

The Future Internet will provide an environment in which a diverse range of services are offered by a diverse range of suppliers, and users are likely to unknowingly invoke underlying services in a more dynamic and ad hoc manner. Moving from today’s static services, we will see service consumers that transparently mix and match service components depending on service availability, quality, price and security attributes. Consequently, the applications seen by the end-users may be composed of multiple services emanating from many different providers, and the end user can be bewildered in the way of guarantee that a particular service or service supplier will actually offer the security that they claim.

In this context it becomes essential to have means of security monitoring extremely efficient and respond quickly to attacks. Terrorist groups express their objective to unleash cyber attacks that are harder to detect and defend against them. Indeed, future acts of terror may come not only from suicide bombers wearing explosives belts but from a few keystrokes on the computer: a weapon of mass disruption. Of course, the Security monitoring covers more common threats, like toll-fraud, impersonation, service high jacking.. To defend ourselves, Future Internet services need more intelligent early attack detection and support for decision and rapid action making faced with constantly evolving threats. This is one of the challenges of FI-WARE.

The current landscapes of service delivery ecosystems do not fully address principals such as openness, usability and simplicity. FI-WARE aims to balance between simplified service usage and end user trust (including underlying security) in the service. FI-WARE will be designed in a flexible manner in order to reflect generic as well individual requirements. By that FI-WARE will be easily adaptable to upcoming needs. Furthermore this also is supported by including social interactions being part of the working community, e.g. by offering a “security market place” where anyone interested could contribute. A typical example of such a marketplace can be the sharing of vulnerable configuration descriptions within a community of users, allowing faster reactions and even prevention from potential attacks exploiting these vulnerabilities.

The overall ambition of the Security Architecture of FI-WARE is to demonstrate that the Vision of an Internet that is "secure by design" is becoming reality. Based on achievements to date and/or to come in the short-term (both from a technological but also a standardization perspective) we will show that "secure by design" is possible for the most important core (basic) and shared (generic) security functionalities as anticipated by the FI-WARE project and in accordance with the requirements of external stakeholders and users such as the FI PPP Use Case projects. The “secure by design” concept will, therefore, address both the security properties of the FI-WARE platform itself and the applications that will be built on top of it. As such, the Security Architecture will focus on key security functionalities such as identity management or security monitoring to be delivered as so-called generic security enablers that will be integrated with the design and implementation of the FI-WARE. The basic security architecture will be designed to be extensible to meet additional security requirements coming from both the FI-WARE project (development and research activities, market analysis and consortium-specific exploitation requirements) and the FI PPP Use Case (UC) projects and their trials.

Security, Privacy and Trust in FI-WARE will be mainly focusing on delivering tools and techniques to have the above-mentioned security needs properly met. This will be performed by design and some semi-automation and assistive technology to alleviate the workload of users and administrators while raising their security awareness to make informed decision.

In this section the foreseen high-level functional architecture is described, introducing the main modules and their expected relationships, then depicting the most important modules in detail along with their main functionalities.

The high level architecture is formed by four main modules: Security monitoring mechanisms (M1), a set of General Core Security Mechanisms (e.g. Identity Management and Privacy solutions) (M2), Context-Based Security and Compliance (M3) where an enhanced version of USDL for security will support the matching of security goals with available security services while addressing compliance management, and a set of universally discoverable Optional Generic Security Services (M4) that will be instantiated at runtime and can be dynamically reconfigured (triggered by M3) based on the needs of specific scenarios.

The overall security plane of the FI-WARE architecture will interlink with practically all its functional modules. In order to simplify the description of these links subsequently the main components as well as their technical relationships with only the Application and Service Ecosystem and Delivery Framework and FI PPP Use Case projects are depicted:

The core general security mechanisms for the FI-WARE project will be provided by M2, including support for Identity Management, Authentication Authorization and Access, and Privacy. M3 will provide the required language and tools for describing services in the FI and their security needs. Where specific scenarios will require optional generic security services these can be consumed on a basis of what is provided by M4. A key architectural assumption is that security services may fail. Security monitoring mechanisms as provided by M1 may detect deviations with respect to the expected behaviour and signal this to M3 to take action (e.g. invoke alternative security services or trigger countermeasures if under attack).

FI-WARE GEs to be developed and/or integrated as part of the Security chapter will materialize the (Security) Reference Architecture sketched in Figure below. This Reference Architecture comprises:

  • A component able to dynamically invoke and compose security services to answer related security needs while dealing with constraints which may apply (e.g. regulatory).
  • A set of GEs for a number of shared security concerns (i.e. identity and access management as well as privacy and auditing) that are considered core and therefore present in any FI-WARE Instance.
  • A set of optional Security GEs to address current and future requests from concrete Usage Areas.
  • An advanced security monitoring system that covers the whole spectrum from acquisition of events up to display, going through analysis but also going beyond thanks to a digital forensic tool and assisted decision support in case of cyber attacks.


Image:FIWARE_Sec_Arch_V.jpg
FI-WARE High Level Security Architecture

Security monitoring

Target usage

The Security Monitoring GE is part of the overall Security Management System in FI-WARE and as such is part of each and every FI-WARE instance. The target users are: FI-WARE Instance Providers and FI-WARE Application/Service Providers.

Security monitoring is the first step towards understanding the real security state of a future internet environment and, hence, towards realizing the execution of services with desired security behaviour and detection of potential attacks or non-authorized usage.

Security monitoring is focused essentially on monitoring alarms from network equipment, systems and security sensors. By the collection, filtering and correlation of data from large-scale heterogeneous environments, including sensitive data from security tools and devices, SCADA events, raw sensor data, suspicions behaviours, etc., coupled with a dynamic risk analysis engine, decision making support and role-oriented visualization engine, the security stakeholders can take appropriate actions to prevent and mitigate the impact of abnormal behaviour.

In addition, the availability of digital forensic evidence models and tools will provide a digital forensic for evidence solution to analyze abnormal behaviour, carry out a criminal investigation and provide evidence with legal value.

GE description

Overview

The GE as envisaged will address security monitoring and beyond, up to pro-active cyber-security i.e. protection of “assets” at large. The figure below provides a high-level initial architectural sketch of the Security Monitoring GE as envisaged in FI-WARE. It shows both how it is structured and how it is expected to work. The targeted functional components associated to this GE are described in the following subsections.


Image:Security_Monitoring_GE.jpg
Security Monitoring GE


Normalization of heterogeneous events and correlation

This component is shown as [1] in Figure above. It will cover the following functionalities:

  • Massive security events collection e.g.:
    • Firewalls, Intrusion Detection Systems, Security Information and Events Managers, (non-exhaustive list)
    • sensitive data events, Things events, FI-WARE service events,
    • raw sensor data & wireless event agents,
  • Normalization and correlation of security events
The Monitoring Security Enabler will exploit the security events logged by FI-WARE services and applications (i.e. non-Authorized access attempts, service disabling, denial of service attempt..). We will exploit them to detect an intrusion. Event correlation technology has been available in the monitoring field for years, but until now it has been based on static rules which are very hard to create (several sources of events), update (thousands and thousands of event identifiers) and understand (identifiers are just numbers).

Security Information and Event management

Security Information and Event Management is a technology that provides real-time analysis of security alerts generated by the component of the FI-WARE architecture. It aggregate data from many sources, providing the ability to consolidate monitored data to notify immediates issues and to help avoid missing crucial events.

Risk analysis

This component is shown as [2] in Figure above. It will cover the following functionalities:

  • Vulnerabilities collection and normalization
The Vulnerability OVAL scanner is designed to evaluate and manage the vulnerability level of Information Systems. Besides producing a list of discovered vulnerabilities, the OVAL scanner can also output a detailed machine configuration information
The Open Vulnerabilty and Assessment Language (OVAL) standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); reporting the results of this assessment.
  • Vulnerabilities impact
ICAT, a vulnerability database developed by the US National Institute of Standards and Technology, will provide the information about a vulnerability’s effect. The effect classification of a vulnerability indicates how it can be exploited and what is the consequence. The associate vulnerability enables a attacker to execute arbitrary code with all the program’s privileges. Fortunately, the ICAT database classifies the effect of a vulnerability in two dimensions: exploitable range (local, remote) and consequences (confidentiality loss, integrity). A local exploit requires that the attacker already have some local access on the host. A remote exploit does not have this requirement. Two most common exploit consequences are privilege escalation and denial of service.
  • Network configuration
The model of network is an abstract host access-control list provided by a network exploitation tool and also by entries from Cloud hosting configuration management data base.
  • Attack trace engine
A series of successfully exploits is a set of attack trace. The objective is to preemptively identify the attack trace and to avoid the access to the assets being the target of an attack. The discovery of these traces requires a reasoning engine analyzing the inputs from vulnerability Oval scanners, network configuration, vulnerabilities impact and Common Vulnerability Scoring System (CVSS-SIG).
  • Service risk level evaluation
    Of course, it’s not easy to evaluate the formal service risk level, but it is possible to identify critical services and sensitive data and to establish some priorities and adapted countermeasures.
The goal is:
- to detect risks affecting the realization of company objectives and non-compliance with regulatory requirements.
- to measure risks according to the probability of the event occurring and the impact of the event and taking into account the consequences of a loss of confidentiality, integrity and availability,
- to determine whether the level of risk is acceptable or requires mitigation,
- to adopt measures preventing situations that can compromise security and trust of services.

Decision making support and countermeasures

The Security Monitoring GE support manual or semi-automated selection of countermeasures (shown as [3] in Figure above) mitigating cyber-attacks and reduces the service risk level. This functionality is capable of proposing the most appropriate mitigation responses based on results of the risk analysis functionality.

Countermeasures can involve service experts, security and process managers, and watch keepers. It is therefore highly beneficial to accomplish a risk assessment, the goal of which is to weigh uncovered threats based on their probability (influenced for instance by the preparedness of a potential attacker), impact (e.g. by estimating the costs of a successful attack) and some additional factors (like the costs of the possible countermeasures). Such an assessment will help finding the most appropriate balance between security level and the associated costs.


Visualization and reporting

The Security Monitoring GE will provide a dynamic, intuitive and role-based User System Interface (shown as [4] in Figure above) for the various stakeholders to use in order to understand the current security situation, to make decisions, and to take appropriate actions. It will support the following features:

  • Multi-perspective user interface, able to present a high-level service view, illustrating the impact on the current service transaction, as well as lower level, more technical, views such as at the system or network level.
  • Rapidly customizable views to enable the user to select the data and information they need to see, along with the visualizations they find most effective. There are many potential visualizations, some of which are more suited for users in some roles than others, and indeed users will find some easier to work with for them personally compared to other users in the same role. The interface must enable the user to rapidly and easily select and arrange visualizations as they see fit.
  • Rapid addition of new data and information sources as well as visualizations. In order to assess the likely dynamic and complex security situations of the Future Internet, the ability to rapidly add and visualize new sources of data and information as they arise will enhance the user’s ability to make decisions.


Digital forensics for evidence

The high-level process of digital forensics (shown as [5] in Figure above) in the Security Monitoring GE deals with the acquisition of data from a source, the analysis of the data and extraction of evidence, and the preservation and presentation of the evidence. The digital evidence is intended to facilitate the reconstruction of events found to be malevolent or helping to anticipate unauthorized actions.

Digital evidence, by its very nature, is fragile and can be altered, damaged, or destroyed by improper handling or examination. For these reasons special precautions should be taken to preserve this type of evidence. Failure to do so may render it unusable. Original evidence will be acquired in a manner that protects and preserves the integrity of the evidence. A protection will be initiated to preserve and protect original evidence.

Correlating events provides the means to support the search for evidence process. Timeframe analysis can be useful in determining when events occurred. For this, we can review the time and data stamps contained in the file system metadata, linking error logs, connections logs, security events, alarms and files of interest to the timeframes relevant to the investigation.

Analyzing every bit of data is a daunting task when confronted with the increasing size of storage systems. A second problem is that acquired data are typically at the lowest and most raw format, which is often too difficult for humans to understand. The purpose of digital forensic analysis tools will be to accurately analyse data forensic collections at a layer of abstraction and format that can be effectively used by an investigator to identify evidence.

Critical product attributes

Compared to existing products and services, the security monitoring service as targeted in FI-WARE, offers a unique selling point. Today, no comprehensive security monitoring service ranging from network to the application exists for the Internet and applications running on top of it. Of course there may exist some products that could be used either in isolation or in conjunction but none of them has been integrated by design nor would offer the level of functionalities targeted here and described above.

Furthermore apart from satisfying the needs identified, the security monitoring service of FI-WARE will also be targeting some unique features not only demanded but also key to its success and wide adoption, including:

  • Integrity of the security monitoring service (applies to all security services)
  • Service usability and intelligibility,
  • Performance,
  • Cyber-security enablement
  • Assisted and informed decision making in case of alarms raised (e.g., events anticipating attacks, events reporting compliance violations)

In summary the Security Monitoring service of FI-WARE seen as GE according to the definition shared and agreed by project team offers several unique features:

  • A comprehensive and pro-active security monitoring system ranging from acquisition of events to role-oriented display, providing “intelligibility” of the visualization according to each of the stakeholders’ perspective)
  • Service-oriented decision making support (in case of cyber threats).
  • Digital forensics tool, also targeting at Services
  • Facilities to promote Collaborative Security (thanks to the openness of the GE able to serve other security-related purposes (e.g. normalized events could be shared with other EU Security Operational Centers to foster Collaborative Security at EU level)
  • Better Trust and Confidence in using Future Internet Services (main benefit for the EU Citizen)
  • Significant aid to fight cyber crime which today’s seriously impede the EU Economy.


Generic Enablers

Generic Security Enablers Architecture

The Generic Security Enablers consists of three primary sets of application level functionality based around the areas of identity management, privacy and data handling. Together they provide important elements of the trusted environment that is required for users, services and IoT to operate.

Image:Figure1.jpg
Figure 1: Generic Security Enablers – Overview

Component and Functionality Overview

The generic security enablers will provide a series of application level services to other components of the FI-PPP community. These external interfaces will be standardized and implemented using a set of security assets described later in this document. The use of standardized interfaces will allow the incorporation of multiple technologies in the security architecture. The following diagram shows a high level overview of the three generic enablers and the interfaces that they expose.

Image:Figure2.jpg
Figure 2: High Level Functionalities of the Generic Security Enabler


Image:Figure0a.jpg
Figure 0: Functional Architecture of the Generic Security Enabler

Identity Management Generic Enabler

Target usage

This enabler provides authentication/access control and identity/attribute assertions as a service to relying parties. The relying parties are typically service providers that provide easy and secure access to their services to users/IoT/other services for instance by means of SSO and that rely on (personal user) attributes (e.g. preferences, location, home address, etc). The users need easy access (SSO) to the growing number of services, and many of them also prefer their personal/identity attributes to be maintained by a trusted party which also protects the users’ privacy. The Identity Management core generic enabler can be used by such a trusted party which we also call an identity provider (for SSO) and attribute broker. The Identity Management GE is a core Security GE that provides services to its relying parties via open protocols such as OAuth [OAuth] and OASIS SAML v2.0 [Saml] (Security Assertion Markup Language). Motivated by the IoT, the enabler also covers new user attributes such as things, as well as it manages the identity of things themselves (attributes, current users, location, use history, etc). The large number of sensors and mobile devices poses new challenges; identity federation and single-sign-on support ease of use. Furthermore, the authentication feature of the enabler also covers the authentication of things for services, other objects or users as relying parties, and the authentication of users, services and other things for things as relying parties. It also supports user SSO across multiple things. Motivated by Cloud computing, the enabler can be run in the cloud as well; when doing so. Special care is taken so that the sensitive data is not exposed to the threats related to the nature of clouds (e.g. deployment in a public cloud).

Component Description

This component provides identity management functionality that can be used to manage the life cycle of Users and Roles. This includes functionality to register a user, update information associated with a user and eventually to delete a user. Further functionality includes the capability for a user to be set into a state where they are not deleted from the system but marked with a special status that indicates they have been disabled. The IDM solution consists of the IdM “front end” (IdMaaS) and the IdM “back end” (Authentication). The IdM solution communicates with the relying parties (services, things) as well as with the subjects of authentication and attributes assertions (users, things). Given the heterogeneity of the FI Core Platform, identities are usable across trust domains. Hence identity translation services (Secure Token Services) are expected to be a key component of the IdM solution. The Authentication Support connects the front end to the underlying authentication machinery where applicable; e.g. beyond the simplest password-based authentication of users, it can support the re-use of the network/telco-level authentication of users or things at communication services providers (telco operators) by means of GAA/GBA [GaaBook08] or by connecting to the Authentication-Authorization-Access function of the access network. The Policy Support consists of Policy Enforcement Points and the Policy Decision Point which control the access to attribute which are retrieved from the Policy Store. The Identity Store is a database of identities including identifiers and other attributes. It can be complemented with external stores as well.

Image:Figure3.jpg
Figure 3: Identity management - High Level Component Overview

Functional Description

This section describes the functionalities provided by the Identity Management generic enabler.

Image:Figure4.jpg
Figure 4: Identity management - Generic Enabler Functions

User Management This functionality is used to manage a user’s identity in the system. This is a pre-requisite for providing a trusted relationship between multiple parties. There are several features that are required in order for the life cycle of a user to be managed. These features include e.g.: • User Registration – where a new user is introduced into the system • User Information Update – where information about a user is updated • User Deletion – where a user is removed from the system • User Revocation – where a users rights are removed but they are left in the system

User Authentication Provides a set of functionalities that a service can use to authenticate a user. There are a number of open standards that will be supported which include in a first phase: • Open ID • OAuth • Oasis / SAML • user id and password

Adaptation to specific api’s or support of other standard interfaces might be considered on request.

Identity Federation This interface provides Identity federation functionality which allows a single sign on to be provided. There are a number of open standards that will be supported which include: • Liberty Alliance / Kantara

Credential Management Credentials or tokens are things used to convey a Users right to access a resource. This interface provides a series of functions to manage these credentials. Supported credentials include: • X509 certificate • RSA Tokens • HW Dongles • SAML tokens

These credentials need to be provided to a user in order that a service may be accessed. There are a set of features that allow a credential life cycle to be supported. These features include:

• Issue Credential • Renew Credential • Delete Credential • Revoke Credential

Access Policy Access Policies specify the conditions a user/service has to satisfy in order to obtain access to a resource. Such a policy can be expressed and interpreted by means of standard XACML [Xacml] machinery. The requests for PII (personally identifiable information) are intercepted and controlled by a Policy Enforcement Point (PEP). The PEP hands the request over to the Context Handler (CoH) in its native request format, optionally including attributes of the subjects, resource, action and environment. The CoH constructs an XACML request context and sends it to the Policy Decision Point (PDP). The PDP requests any additional subject, resource, action and environment attributes from the context handler. The PDP evaluates the applicable policies and returns the response (authorization decision) to the PEP. If access is permitted, then the PEP permits access to the resource; otherwise, it denies access. For a more detailed description, consult the XACML specification.

Administration This function enables an administrator to configure various aspects of the system and to provision and link user accounts.

External Directory Services An external directory service is an alternative for verifying user’s credentials (username and password) in case they are unknown to the IdM Generic Enabler System.

Critical product attributes

  • Authentication and attribute assertions about users and things as a service to relying parties via open protocols (OAuth, SAML).
  • Single sign-on (SSO) for end-users.
  • Enforcement of end-users’ privacy policies in attribute assertions.
  • Extensibility with external identity stores and authentication support functions.
  • A graphical user interface (GUI) for end-users to manage the rules to reveal their attributes via policies.A


Privacy Generic Enabler

Target usage

The privacy generic enabler provides a set of functionality similar in scope to the Identity management generic enabler described in the previous section but enhanced using special privacy enhancing technologies. These privacy-enhancing technologies are primarily centered on special credentials that contain attributes about the user which can be disclosed for authentication purposes selectively on a need-to-know basis.

Image:Figure5.jpg
Figure 5: Privacy - High Level Component Overview

Component Description

This component will utilize many of the basic functions provided by the Identity management generic enabler (see Generic Identity Enabler). The Privacy Generic Enabler includes the IDM solution (IdM “front end” (IdMaaS) and the IdM “back end” (Authentication)). It communicates with the relying parties (services, things) as well as with the subjects of authentication and attributes assertions (users, things).

Functional Description

From a functional point of view, the privacy generic enabler is almost identical to the identity management generic enabler. It differs mainly in the technologies that are used to instantiate the several components. In particular, those are the privacy-enhanced access policy and privacy-enhanced credentials that is reflected in the User Authentication and Credential Management.

Image:Figure6.jpg
Figure 6: Data Usage - High Level Function Overview

Privacy Enhanced User Management See Generic Enabler Identity Management for basic functionality. On top of that this functionality is enhanced by minimum disclosure technology.

Privacy Enhanced User Authentication See Generic Enabler Identity Management for basic functionality. On top of that this functionality is enhanced by minimum disclosure technology.

Privacy Enhanced Federation See Generic Enabler Identity Management.

Privacy Enhanced Credential Management This privacy credential sub element is based on IBM’s Idemix library and provides private credential systems and minimal disclosure tokens for enhanced privacy protection mechanisms. End-users are provided with the possibility of selectively disclosing their asserted private attributes or even just proving predicates over their attributes in an unlinkable manner. At the same time, the cryptographic technologies ensure strong and secure authentication to the service/resource providers In a private credential system, users can have different identities with different identity providers and identity consumers. In fact, an identity should be seen as the collection of attributes that are known to a party about the users. Furthermore, identity providers can issue a credential asserting attributes to a user. A user can then selectively reveal the attributes contained in a credential to an identity consumer. That is, the consumer will only learn that the identity provider asserted the revealed attribute but is not able to learn any other asserted attributes. The users can repeat this disclosure process as many times as she wishes without that these transactions can be linked to each (unless the disclosed attributes are unique). Thus, together with privacy-enhanced attribute-based access control, private credentials offer the best possible privacy protection. Finally, we note that the Identity Mixer private credential system also offers all the standard feature of a public key infrastructure such as revocation of credentials or hardware-binding.

Privacy Enhanced Access Control In order to support the full functionality of privacy-enhanced credentials an enriched policy language and token format is needed. The PrimeLife Privacy Policy already extends the standard XACML language to express for the important concept of predicates on attributes. That is, instead of revealing an attribute only the fact if some condition on the attribute is fulfilled will be revealed. Further extensions in the Privacy Enhanced Access Policy will cover the use of unlinkable pseudonyms instead of (identifying) public keys, or the optional lifting of the anonymity. Please refer also to “Data Handling Generic Enabler”.

External Directory Services See Generic Enabler Identity Management.

Critical product attributes

  • Unlinkability: Different tokens created by the same user cannot be linked -- unless the token was explicitly created in a linkable way.
  • Untraceability: The user who created a token cannot be identified -- unless the token was explicitly to be traceable by a trusted authority.

Data Handling Generic Enabler

Target usage

The component provides a mechanism for controlling the usage of attributes and data (=PII) based on the concept of ‘sticking’ a data usage policy to the data to which it applies. When the data is accessed by an application, an access control technology is then used to verify that the intended use of the data matches the scope defined in the usage policy.

Image:Figure7.jpg
Figure 7: Data Handling - High Level Component Overview

Component Description

Privacy Policy Engine

After the credentials of the user have been verified a check is made which policies apply to the user’s request. Policies are stored in the policy store and can be modified by both the users (own policies) and the administrators (all policies), depending on the scope of policy.

Credentials and Crypto

This component is responsible for enciphering the data stored by the user in the Data Store. Enciphering is being done by the public key of the users. In the case the users intend to retrieve the data their private key would be required. On top of that this component authenticates the users by checking the user’s credentials, prior to forwarding the requests to the Privacy Policy Engine.

Functional Description

This section describes the external function exposed by the Data Handling generic enabler.

Image:Figure8.jpg
Figure 8: Data Usage - High Level Function Overview

Privacy Enhanced Policy Editor

This function enables to control access to PII based on policies that have been attached to the data by a user. These data handling policies govern such aspects as to how long data should be retained, if the data may be handed on further to a third party, if it should be deleted after a certain time. If an Attribute Manager is available in the system identity storages can be provided with sticky policies.

End-users should be provided with strong control over the disclosure and use of their personal data by application/service providers and devices. The technical solution guarantees the correct enforcement of the privacy policies and regulations.

User Attribute Handling

Currently, websites and online applications acting as data controllers [EuPriv95] are obliged to publish a privacy policy stating how the data collected from users will be handled and treated. This privacy policy is a text is written by layers and most of the time not really easy to understand for the common users. Beside the lack of clarity of such privacy statements, their enforcement is not automated. That means that there is not technical mean to execute the actions and constraints described in such documents. Then it becomes very hard to check whether a data controller is compliant with his declared privacy policy. For instance a user will not be able to verify if the data controller shared his data with a third party. For this reason, we propose to provide a machine readable language called PPL [Ppl] that is able to express the rules contained in the standard privacy policies. This language is not only designed to express privacy policy but also privacy preferences expressed by the users. These preferences can then be compared or matched with the privacy policy of the data controller. The PPL language can express at the same time access control rules (how can access the data and under which condition), and usage control rules (how the data should/must be treated after being collected and for which purpose). Obligations can also been expressed in order to force a data controller to perform an obligation on the data after collecting it (ex. Deletion after a certain period, user notification when the data is used or shared, etc.). The language is symmetric and use similar syntax to express privacy preferences of the user, and the privacy policies of data controller. The agreement between these two parties is expressed into a sticky policy that will travel along with the data in order to keep trace of the applicable privacy rules. This concept is useful when the data is shared and forwarded through various data controllers. At any time the data controller can enforces the privacy rules related to the data.

Administration

This interface provides functionality for an administrator to configure various aspects of the data handling functionality.

External Directory Services

See Generic Enabler Identity Management.

Critical product attributes

  • Provide the users more control about his/her PII stored in the network/cloud.
  • Easy en-/decryption of the user’s PII even in unsecured areas provided by the Data Handling Generic Enabler.
  • Privacy respecting enforcement of PII with the help of a Privacy Policy Language PPL.

Context-based security and compliance

Target usage

The role of this Generic Enabler is to support additional security requirements requested by a specific subset of applications as a result of the application of very specific regulatory constraints.

The GE will accept security request from a client application and will select the best Optional Security Enabler to fulfil it.

The deployed security enabler will implement the compliance between the client security request and any applicable regulation from Private and or Public sources.

The framework has also monitoring capabilities to overseen the system performance.

As a result of this monitoring, if a non-conformance is detected, the framework is capable of performing run-time and context-based reconfiguration of deployed security enablers, such that the client application will be provided with a new configuration for the security enabler it is utilizing, or it can receive instructions to stop using that security enabler and use a newly provided one.

The figure below provides a high-level initial architectural sketch of the components of this Generic Enabler.


Context-based Security and Compliance Generic Enabler

GE description

Three main internal components are defined by this Generic Enabler

  • PRRS Framework: Provides run-time support to applications performing Dynamic selection & deployment of security enablers.
  • Context Monitor: It’s able to check the system compliance status and trigger PRRS Framework in case of noncompliance detected.
  • Security requirements repository: This component offers the possibility to manage (create, modify, storage & delete) compliance rules to be used.


PRRS Framework
The PRRS framework is the core of the Generic Enabler. It controls the rest of the components of the system; processing requests from end-user applications and orchestrating the instantiation of the Security Enabler selected.
PRRS is implemented as a service running in a device, on top of the operating system, and listening to end-user applications requests.
End-user applications send requests in order to fulfill their security requirements to it either as a specification of security requirements or as a reference to already existing rule.
Once receive a request PRRS will get the applicable rules of compliance from rules’ repository and will find the most suitable security enabler from enablers’ repository
Then PRRS will deploy the solution as executable components in the context of the end-user application is running
Finally PRRS will provide monitoring devices with the rules that end-user applications context must fulfill and will updated its internal data base
PRSS internal Data Base allows framework to link the deployed solution with the monitor that oversees the user context and the applicable rules the system must fulfill.
After security solution is running properly PRRS framework participation could be requested again either by monitoring system in case a noncompliance is detected or by rules’ repository in case of a rule modification is notified.
PRRS will take the necessary recovery actions by the reactivation, reconfiguration, deactivation and/or substitution the deployed enabler.
Anytime PRRS hasn’t been able to find a suitable security enabler it would notify the End-user application the situation.


Contex Monitor
Runtime context monitors are the components in charge of detect anomalous behavior or non-conformances in End-user context environments.
Each Monitor component will get context and status events from the end user and the security enablers it is overseeing.
Then it will compare the information obtained with the rules provided by PRRS Framework.
In case of non-compliance detection the assigned event will be send to PRRS framework by the appointed monitor so that the framework could take the necessary recovering actions
Additionally Context monitor will provide a Dashboard that gives the system reporting capabilities.
Reports of system performance will be generated once the information from data context has been compared with rules received from PRRS
These visual reports will provide useful information about the levels of compliance, performance of the solutions dynamically deployed by PRRS and make the task of identification of root-causes for non-compliant situations easy.


Security requirements repository
This component will allow the generic enabler to store and manage compliance requirements and relevant specifics at various abstractions levels and also check end-to-end business processes for compliance against the set of applicable constraints during design-time.
The rules to be stored could come from various sources, including laws and regulations, public and internal policies, standards, customer preferences, partner agreements and jurisdictional provisions.
In order to manage compliance throughout all phases of business process lifecycle, it must be possible to define and subsequently integrate compliance specifics into business processes and enterprise applications, and assure compliance starting from the process analysis and design phase.
Furthermore the component will be is able to reuse fragments of already stored formal rules specifications to built a new formal specification form a new law or rule to be stored
Reuse of rules specification fragments will make the task of compile new laws or rules into formal language easier
Each high-level rule or specification will be compiled into a formal pattern that can be applied and referenced in many scenarios either by end-user applications as a security requirement or any security enabler to describe its characteristics.
Finally Security requirements repository will be able to trigger PRRS framework when some rule will be modified so that the framework could take the necessary actions in case of the modification must be taken into account on compliance measurements


The generic enabler also will describe a new business service oriented language that will be able to describe & register security services, capabilities and compliance rules The communication between end-user applications, the deployed executable components and the framework will be is supported by this service oriented language. The USDL-SEC language will be defined as an extension of existing standard USDL 3.0 by implementing a new security oriented module. USDL-SEC language will support the following basic characteristics:

• Provide mechanisms to cover both high level description of the service and detail functionalities & implementations.

• Describe functional security services provided by the platform and needed by applications with functional and non-functional properties in single and complete description file.

• The Security model will be fully defined by its associated properties file; allowing consumers and providers to agree on a security protocol, through expressions of concrete mechanisms and links to existing standard such as WS-SecurityPolicy, XACML, P3P, etc...

• Provide means to compare and select services according to consumer needs. A service description is first made by a service provider, which then exposes it to a service broker. This will make the PRRS task of selecting a service following user requirements easy.

• Provide event management capabilities to allow monitors get the context event information from the security enablers they overseen.

• Describe requirements and compliance rules to be fulfilled in an specific end-user environment

Critical product attributes

  • Provide run-time security support for applications, by managing S&D Solutions and monitoring the systems’ context
  • Enhanced security and dependability by supporting automated integration, configuration, monitoring and adaptation
  • Dynamic compliance of software services to business regulations and user requirements
  • Tools for modeling business relations & agreements into an abstract set of rules
  • Compliance Repository not only to store, but also managing compliance requirements at these abstraction levels
  • A new business service oriented language to describe & register security services or capabilities.
  • This language will provide mechanism to cover from high level description of the service to detail functionalities & implementations.

Optional Security Service Enabler

Target usage

The Security Architecture has also been designed to support the optional generic security services that usage areas can potentially integrate as a generic enabler (so–called ―optional‖ as they are common across many usage areas, but not all). On the basis of a selected set of already available assets, this module will provide use case dependent security services. These optional security services will be described below in this section. Module 4 (in Figure 2) will equally provide the necessary technical means for integration of future security services. The requirements and security goals to be supported will stem from M3, which will enforce the compliant usage of the invoked optional generic security mechanisms and services.

One of the main goals for this asset should be the extension and the consolidation of the USDL-SEC service description language [IoS], in parallel with the work that will be done in M3. USDL-SEC should cover as much as possible the security properties defined in the different generic security enablers. For this task we require inputs from all the modules in the WP8 in order to capture the different security properties of the generic enablers. The optional security services are defined as a modular extension of the main USDL-SEC specification although if the security properties exposed there are domain specific. For this reason we have to define an optional element that can be used to extend the specifications with domain specific security properties such as security plug-ins that can be developed in addition to the basic security features. The second phase of this goal is to describe mechanisms, publish then invoke the optional services as an extension of the basic USDL-SEC framework.

The optional security services do not propose crucial and mandatory security functionalities as provided in M2 (Authentication, Access control, usage control, trust, etc.), but they offer some security capabilities that are applicable for specific cases and scenarios. These optional serves cannot be used by all the applications deployed in FI-Ware. Each optional security service is independent from any other generic security service and not restricted to a specific application domain. The usage of these services must be as easy as possible with no strong configuration requirement.


Image:Optional_Security_Service_Enabler.jpg
Optional Security Service Enabler


GE description

The optional security service enabler is used to customize the security service description within USDL-SEC when the security functionality is not covered by the specification. This asset targets directly the application domain usage. The goal is to make easily extendible the security service description for customized usage. This functionality will encourage all the developers to define and describe their own services through the USDL standard by adding new functionalities and new capabilities.

In Fi-Ware we want to overcome the limitations of the traditional service description languages that usually do not take into account the extensions wanted by the users. Most of the time the user has to add manually new elements and modify the delivery framework in order to take into account the new functionalities. Such approach is not feasible for any user. With this optional security services we will provide all the technical support to let users add and extend the USDL-SEC service description easily.

Some example of possible optional security services could be:

  • A database risk evaluation and anonymization service used to check a shared database is not vulnerable to the re-identification of the non shared part of the database. The service can be used to support these DB administrators to evaluate the disclosure risk for all their types of data; by recommending the safest configurations using a smart bootstrapping system. The service will provide the user with a feedback on the re-identification risk when disclosing certain information and proposing safe combinations in order to help him during the information disclosure. Albeit privacy risk estimators have already been developed in some specific contexts (statistical databases), they have had limited impact, since they are often too specific for a given context, and do not provide the user with the necessary feedback to mitigate the risk. In addition, they can be computationally expensive on large datasets.


Image:DB_Risk_Evaluation_and_Anonymization_Service.jpg
DB Risk Evaluation and Anonymization Service


  • Secure storage service that offers the possibility to safely backup his data and delegates the access to parts of data to third party. Data leaks are resulting from the lack of additional information on data: sensitivity, access rights, lifetime, etc… The existence and the availability of these kinds of attributes are necessary to master the storage and the exchange of sensitive data. The concept consists in providing an secure storage service, manipulating self protected metadata only. This (optional) service can be used or not by other services, depending on the privacy level of implied data. The main objective of SSS is to provide a secure storage to sensitive / private data, privacy-oriented capacities, according to legislation.


Image:Secure_Storage_Service.jpg
Secure Storage Service


  • Morphus: Malware detection service that explores a data structure in order to check whether this dataset contains malware applications. Morphus is a generic malware detector based on graph signatures. Unlike the traditional notion of detection based on string pattern matching, graphs allow a behavioral analysis of programs, thus providing a much finer description of malwares.


Image:Morphus.jpg
Morphus


Critical product attributes

  • Make USDL-SEC service description extensible and flexible so that it can be used by anyone interested in making using of it (i.e.company, organization, individuals, ...)
  • Provide a technical framework to deploy easily security services
  • Optional security services can be deployed as plug-in applications.
  • Break the description limits of the standard USDL specification


Question Marks

We list hereafter a number of questions that remain open. Further discussion on these questions will take place in the coming months.

Questions still under discussion

Forensics for evidence

The complexity problem in digital forensics is that acquired data are typically at the lowest and most raw format, which is often too difficult for humans to understand. It is not necessarily impossible, but often the skill required to do so is great, and it is not efficient to require every forensic analyst to be able to do so. To solve the complexity problem, tools are used to translate data through one or more layers of abstraction until it can be understood.

Similarly, the quantity problem in digital forensics is that the amount of data to analyze can be very large. It is inefficient to analyze every single piece of it. Data reduction techniques are used to solve this, by grouping data into one larger event or by removing known data. For example: identifying known network packets using Intrusion Detection System (IDS) signatures, unknown entries during log processing.

Proactive attack detection in a SOA context

It will very difficult to prevent attack in SOA context, if service providers are constantly changing.

Indeed, we must make, as a preliminary, a topological vulnerability analysis, using components and services stable enough to search their vulnerabilities and to identify the most likely traces of attack. The problem is that it is not possible, in this case, to identify such traces.

Service risk impact assessment

The difficulty to identify the attack trace in a volatile environment also can be applied to the service risk impact assessment. It is not possible to do it if the resources used by services are always indeterminate.

Identification of the Information System

Identification of the Information System assets impacts the efficiency of the security monitoring GE and more specifically the efficiency of the vulnerability assessment capacity. System discovery is not expected to be a good solution because of false positives but also isolation mechanisms put in place (NAT, firewalls ...) which often hide numbers of assets. Moreover, this type of identification doesn't meet real time requirements. As a consequence, the support of an efficient configuration manager included in FIWARE (WP?) feeding a global Configuration Management Database (CMDB) is needed to achieve effective & efficient security monitoring through precise and real-time knowledge of assets.

Identity, Trust & Privacy management

The identity, trust, and privacy management component is concerned with authorization and authentication. This includes a (credential requirements) policy language to define with attributes (roles, identity, etc) and credentials are requested to grant access to resources. It further include a (data handling) policy language that defines how the requested data (attributes, credentials...) is handled and to whom it is passed on. Finally, it includes the means to release and verify such attributes and credentials. That raises three issues:

  • The integration of the two policy languages into the access control system (e.g., XACML) of the FI-platform;
  • The definition of the interfaces of the Generic Security Enabler;
  • The integration of the different assets into components that realize the generic security enabler interfaces.

Accountability and Trust

The PPL privacy engine is designed to specify and enforce access and usage control rules on the collected data. But once the data collected and the privacy rules executed in theory how can we verify the accountability of the data controller? Accountability of the controller can be used to enhance the trust of the subjects that their data is not misused. One approach is to deploy an accountability mechanism for privacy policies which makes it possible to check a posteriori the logs of the system to check whether the actions performed over the data are compliant with the privacy regulation rules of the sticky policies. The fact that a controller agrees to implement a given compliance system can be a factor of trust for the subjects. Additionally, the level of compliance of each data controller could also be formalized as a trust metric used to describe the privacy reputation of a data controller.

Auditing

It must be possible to verify whether the system works as expected. (1) Logging of user activities in a standardized way is a key requirement. We should ensure that all the relevant data that is needed for a meaningful analysis is logged. (2) Logs may have to be exchanged across trust domains. We should provide mechanisms that support the analysis and correlation of logs that originated in different trust domains. Auditing also comprises the analysis of authorization and usage control policies based on meta-policies such as Separation of Duties (SoD) constraints.

New security/privacy threats related to Web2.0

How can we mitigate the threats that come from recent Web2.0 developments (e.g. “clickjacking”, “cookie jacking”, the threat that users of social networks such as Facebook trust their friends and hence easily accept malicious content from them, HTML5 geolocation API threat, etc).

Event interface definition

The event interface which will implement the communication between the Security enabler – User Application and Monitor systems would need to be defined asap.

Monitoring capabilities

Some of the monitor capabilities Context-based security and compliance will need to be developed, especially those referred to probe functionalities, may be fulfilled by Security monitoring enablers. Furthermore each of every monitoring capabilities addressed at WP8 level would have to be put back into perspective of overall monitoring capabilities offered by FI-WARE seen here as the FI PPP Core Platform.

Securing the deployment of new services

The definition and the deployment of the new optional security service require sometimes the composition with some generic security services (ex. Identity management, authentication, etc.). Then the service composition functionality should be supported by the FI-WARE service framework.

USDL-SEC specification

The current version of the USDL-SEC specification is a very early draft designed before the beginning of the Fi-Ware project. It does not reflect yet the security capabilities proposed in the generic security enablers exposed in WP8. The main task of the WP8 in the next months is to list these security capabilities and map them to a new version of the USDL-SEC specification in order to be able to publish correctly all the security services and make them available for any service deployed in the FI-WARE platform.


Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP)

  • Attack. Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself
  • Authentication protocol: "Over-the-wire authentication protocols are used to exchange authentication data between the client and server application. Each authentication protocol supports one or more authentication methods. The OATH reference architecture provides for the use of existing protocols, and envisions the use of extended protocols which support new authentication methods as they are defined." (OATH)
  • Access control: is the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. (ITU-T-X-800_Link). More precisely, access control is the protection of resources against unauthorized access; a process by which use of resources is regulated according to a security policy and is permitted by only authorized system entities according to that policy. RFC 2828
  • Account: A (user) account is “typically a formal business agreement for providing regular dealings and services between principal sand business service providers.” OASIS Security Assertion Markup Language (SAML)
  • Authentication (AuthN): We adopted the following definition of authentication from RFC 3588"Authentication is “the act of verifying the identity of an entity (subject)”
TrustInCyberspace adds the term “level of confidence” to this definition:
Authentication is the process of confirming a system entity’s asserted identity with a specified, or understood, level of confidence.” This definition holds all necessary parts to examine authentication in broad sense. First of all it does not narrow the authentication to human users, but refers to a generic “system entity”. See authentication reference architecture description for a closer look at different identities that could be authenticated.
Secondly it introduces the often neglected concept of “level of confidence” which applies to each authentication of an identity. No computer program or computer user can definitely prove the identity of another party. There is no authentication method that can be secured against any possible identity-theft attack, be it physical or non-physical. It is only possible to apply one or more tests, which, if passed, have been previously declared to be sufficient to go on further. The problem is to determine which tests are sufficient, and many such are inadequate.
The original Greek word originates from the word 'authentes'='author'. This leads to the general field of claims and trust management, because authentication could also mean to verify the “author” / issuer of any claim.
The confirmation or validation process of authentication is actually done by presenting some kind of proof. This proof is normally derived from some kind of secret hold by the principal. In its simplest form the participant and the authentication authority share the same secret. More advanced concepts rely on challenge/response mechanisms, preventing the secrets to be transmitted. Refer to Authentication Technologies for a detailed list of authentication methods used today.
As stated above, each authentication method assures only some level of trust in the claimed identity, but none could be definite. Therefore it makes sense to distinguish the different authentication methods by an associated assurance level, stating the level of trust in the authentication process.
As this assurance level depends not only on the technical authentication method, but also on the overall computer system and even on the business processes within the organization (provisioning of identities and credentials), there is no ranking of the authentication methods here.
  • Countermeasures. Action, device, procedure, technique or other measure that reduces the vulnerability of an information system.
  • Cyber attack. An attack, via cyberspace, targeting an entity (industrial, financial, public...) and using cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information
  • Exploit. A program or technique that takes advantage of vulnerability in software and that can be used for breaking security, or otherwise attacking a host over the network
  • Federation: The term federation “is used in two senses - "The act of establishing a relationship between two entities. An association comprising any number of service providers and identity providers.” OASIS Security Assertion Markup Language (SAML)
“A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on an identity, and possibly associated attributes, that are asserted in another realm.
Federation requires trust such that a relying party can make a well-informed access control decision based on the credibility of identity and attribute data that is vouched for by another realm.” WS-Federation @ IBM
Remark: Federation according to WS-Federation @ IBM is similar to the concept of a Circle of Trust.
  • FI. Future Internet.
  • Forensics for evidence. The use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation and presentation of digital evidence derived from digital sources for the purpose of facilitating or furthering the reconstruction of events found to be criminal, or helping to anticipate unauthorized actions shown to be disruptive to planned operations.
  • Identity. In the narrow sense, identity is the persistent identifier of users (user name), things or services by which other parties “remember” them and, hence, are able to store or retrieve specific information about them and are able to control their access to different resources. In the wider sense, identity also covers further attributes of users, things and services; e.g. for users, such information may include personal information such as context, group membership and profile.
  • Identity (Digital): The term identity and its meaning have been discussed controversially in the “identity community” for many years. Until now, there is no commonly agreed definition of that notion. : : The IdM && AAA reference architecture applies the following three definitions of identity.
The Identity Gang defines the term digital identity as follows:
A digital identity is “a digital representation of a set of Claims made by one party about itself or another digital subject.”
The following comments were added:
A digital identity is just one set of claims about a digital subject. For any given digital subject there will typically be many digital identities.
A digital identity can be created on the fly when a particular identity transaction is desired or persistent in a data store to provide a representation that can be referenced.
A digital identity may contain claims made by multiple claimants.
A digital identity may be signed by a digital identity provider to provide assurance to a relying party.
This definition emphasizes two facts:
Normally, a principal (subject) has multiple digital identities or personas.
Identities are made out of attributes (claims).
Therefore, the scope of identity management in the reference architecture has two viewpoints: For once it focuses on identities and personas itself, and on the other side, it deals with the attributes of these identities and personas.
The Liberty Alliance Project (LAP) defines digital identity as follows:
Digital identity is “the essence of an entity. One’s identity is often described by one’s characteristics, among which may be any number of identifiers. A Principal may wield one or more identities.”
RSA uses the following definition of digital identity:
“Digital identity consists of an identity assertion and the characteristics, sometimes called attributes that are collected or observed through our computerized relationships. It is often as simple as a user name and password.”
The definition of RSA adds one important aspect to the identity discussion: Even the simplest user name and password combinations without any additional attributes or claims constitute an identity.
  • Identifier: Identifiers can be understood as a dedicated, publicly known attribute of an identity that refers to that identity only. Typically, identifiers are valid within a specific domain. Special types of identifiers are valid globally, due to the use of popular domain naming and resolution protocols such as DNS, which implies addressing capabilities to the identity. OASIS Security Assertion Markup Language (SAML) defines identifier as follows:
An identifier is “a data object (for example, a string) mapped to a system entity that uniquely refers to the system entity. A system entity may have multiple distinct identifiers referring to it. An identifier is essentially a "distinguished attribute" of an entity.”
  • Identity context: is “the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions.” (Identity Gang)
  • Identity management (IdM): comprises “the management of identity information both internally and when it is passed from one entity to another.” Open Mobile Alliance (OMA)
  • Identity provider: The Open Mobile Alliance (OMA) defines the term identity provider (IdP) as follows - An identity provider is “a special type of service provider […] that creates, maintains, and manages identity information for principals, and can provide […] assertions to other service providers within an authentication domain (or even a circle of trust).”
Another notion defines identity provider as “an agent that issues a digital identity [that] is acting on behalf of an issuing Party.” (Identity Gang)
The following definition of identity provider descends from WS-Federation @ IBM: “An identity provider is an entity that acts as an authentication service to end requestors and as data origin authentication service to service providers […]. Identity providers are trusted (logical) 3rd parties which need to be trusted both by the requestor […] and the service provider which may grant access to valuable resources and information based upon the integrity of the identity information provided by the identity provider.”
The Identity Provider is part of the Identity Management infrastructure.
  • Impact. The adverse effect resulting from a successful threat exercise of vulnerability. Can be described in terms of loss or degradation of any, or a combination of any, of the following three security goals: integrity, availability, and confidentiality.
  • Partial identity: a partial identity is a set of attributes of a user. Thus, an identity is composed of all attributes of a user, a partial identity is a subset of a user's identity. Typically, a user is known to another party only as a partial identity. A partial identity can have a unique identifier. The latter is a strong identifier if it is allows for a strong authentication of the user (holder) of the partial identity, such a cryptographic "identification" protocol
  • Privacy: Dictionary definitions of privacy refer to "the quality or state of being apart from company or observation, seclusion [...] freedom from unauthorized intrusion" (Merriam-Webster online). In the online world, we rely on a pragmatic definition of privacy, saying that privacy is the state of being free from certain privacy threats.
  • Privacy threats. The fundamental privacy threats are: traceability (the digital traces left during transactions), linkability (profile accumulation based on the digital traces), loss of control (over personal data) and identity theft (impersonation).
  • Risk analysis. The process of identifying security risks, determining their magnitude, and identifying areas needing safeguards. An analysis of an organization's information resources, its existing controls, and its remaining organizational and MIS vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage
  • Security monitoring. Usage of tools to prevent and detect compliance defaults, security events and malicious actions taken by subjects suspected of misusing the information system.
  • Service impact analysis. An analysis of a service’s requirements, processes, and interdependencies used to characterize information system contingency requirements and priorities in the event of a significant disruption.
  • Single sign-on: is “From a Principal’s perspective, single sign-on encompasses the capability to authenticate with some system entity—[…] an Identity Provider - and have that authentication honored by other system entities, [termed] Service Providers […]. Note that upon authenticating with an Identity Provider, the Identity Provider typically establishes and maintains some notion of local session state between itself and the Principal’s user agent. Service Providers may also maintain their own distinct local session state with a Principal’s user agent.” Liberty Alliance Project (LAP)
  • S&D: Security and Dependability
  • Threat. An event, process, activity being perpetuated by one or more threat agents, which, when realized, has an adverse effect on organization assets, resulting in losses (service delays or denials, disclosure of sensitive information, undesired patch of programs or data, reputation...)
  • USDL and USDL-Sec: The Unified Service Description Language (USDL) is a platform-neutral language for describing services. The security extension of this language is going to be developed FI-WARE project.
  • Vulnerability. A weakness or finding that is non-compliant, non-adherence to a requirement, a specification or a standard, or unprotected area of an otherwise secure system, which leaves the system open to potential attack or other problem.
  • WADL. The Web Application Description Language is a machine-readable XML description of HTTP-based web applications used typically with REST web services.
  • WS-SecurityPolicy: It is an extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS.
  • The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.


References

[biccam]

P. Bichsel and J. Camenisch. Mixing Identities with Ease.

IFIP Working Conference on Policies & Research in Identity Management (IDMAN '10), Oslo, Norway, November 18-19, 2010. 

[EuPriv95]

EU Directive 95/46/EC - The Data Protection Directive

[GaaBook08]

Dr. Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg, Pekka Laitinen, Prof. N. Asokan. (2008) "Cellular Authentication for Mobile and Internet Services". Wiley, ISBN: 978-0-470-72317-3 October 2008.

[idemixspec] 

IBM Research – Zurich, Specification of the Identity Mixer Cryptographic Library, Version 2.3.3 

http://www.zurich.ibm.com/~pbi/identityMixer_gettingStarted/IdentityMixer_ProtocolSpecification_2-3-3.pdf

[idemixlib] 

http://www.zurich.ibm.com/~pbi/identityMixer_gettingStarted/index.html

[OpenId]

OpenID. http://openid.net/

[Ppl10]

Slim Trabelsi and Akram Njeh and Laurent Bussard and Gregory Neven,"The PPL Engine: A Symmetric Architecture for Privacy Policy Handling", W3C Workshop on Privacy and data usage control 04/05 October 2010, Cambridge (MA), USA.

[Saml]

Security Assertion Markup Language (SAML) v2.0. http://www.oasis-open.org/specs/index.php#samlv2.0

[Xacml]

OASIS eXtensible Access Control Markup Language (XACML). http://www.oasis-open.org/committees/xacml/

[IoS]

USDL - Internet of Services http://www.internet-of-services.com/

Personal tools
Create a book