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
FIWARE.OpenSpecification.Security.Context-based security and compliance - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.Context-based security and compliance

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.Context-based security & compliance
Chapter Security,
Catalogue-Link to Implementation [N/A ]
Owner ATOS, Antonio García-Vázquez


Contents


Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright

  • Copyright © 2013-2014 by ATOS

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

The goal of FI-WARE is to provide to use cases an environment in which a diverse range of services are offered by a diverse range of providers, and where users are likely to unknowingly invoke underlying services in a more dynamic and ad hoc manner. In that environment, the role of the Context-based Security & Compliance GE (CBS&C GE) is to provide the security layer of FI-WARE with context-aware capabilities to support additional security requirements through the optional security enablers developed in FI-WARE (DBAnonymizer, Secure Storage Service, Malware Detection Service, Android Flow Monitoring, Content-based Security, etc) not provided by the generic FI-WARE security services (Security Monitoring, Identity Management, Privacy, Data Handling), because Core GE's are the ones that by essence are also there by design since demanded by most application (As Security by design or Privacy by design). We could even think of making security by design have the capacity to be extended thanks to CBS&C offer that can add the additional optional services requested by the applications at hands.

CBS&C will also provide, together with optional security services search and deployment, run-time reconfiguration that will allow Use cases both deal with unpredictable context changes and ensure the compliance with the security requirements.

It is important to remark here that apart from the optional security services delivered through the approach promoted in FI-WARE (especially in Task 8.4 of the Security Chapter), it also offers the capacity to get some more coming from additional sources (either inside PPP, UC projects or partners, etc.) what would become especially significant for Phase III and overall sustainability of the work developed in the Future Internet Public-Private Partnership (FI-PPP) and the Security Chapter in particular.

It must also be remembered that in a real situation, there could be a lot of different FI-WARE compliant implementations of the same optional security enabler developed by different providers - not just the few implementations there are currently in FI-WARE. For example, there may be an implementation of the Malware Detection Service suitable for mobile devices (with low CPU consumption) and another more powerful one for laptops. Or, for example, an implementation of the Android Flow Monitoring enabler or an alternative may be selected to monitor network usage, depending on the client device. The end-user does not have to worry about the selection and deployment of optional security services to cover additional security requirements. It will be done by the CBS&C GE based on his specifications, context and preferences.

The architecture of the proposed Generic Enabler is detailed in the figure below. It shows the main components of the GE and the interfaces to be implemented between them and to be offered to external applications.

Context-based Security and Compliance Generic Enabler Architecture

Target usage

The Context-based Security & Compliance GE provides a help to end-users for automatic run-time selection and deployment of security services based on his security requirements and constraints to ensure the compliance with them in a changing environment. Therefore, the API provided by the Context-based Security & Compliance GE can be also used by any application or service to offer security by design searching, deploying and monitoring at run-time services to support additional security requirements not provided by the generic FI-WARE security services included in the FI-WARE Security Platform. Consequently, the use cases where the CBS&C GE can be used are the same as the different available FI-WARE optional security enablers. Later we describe one example scenario using one of these optional security enablers to shown the advantages to the end-user of using the CBS&C GE for their context-aware selection and deployment.

Basic Concepts

USDL-SEC

USDL-SEC language is being developed as a security extension to the latest version of the USDL language(Linked-USDL), currently maintained by the Applications/Services Ecosystem and Delivery Framework Work Package. More information on USDL can be found in its Open Specification page.

The available security service features as well as the rules to be fulfilled and the interfaces specification are described by using USDL-SEC language.

Furthermore the combination USDL/USDL-SEC describes a service along with functional and non-functional properties in a single and complete description file.

This language provides a means to compare and select services according to consumer needs.

The security extension allows:

  • Any application for expressing its security features in its associated properties file;
  • Consumers and providers to rely on a security protocol, through expressions of concrete mechanisms and links to existing standard such as WS-SecurityPolicy, XACML, P3P, etc.

Security Specifications & Rules

In the context of this Generic Enabler we define these two concepts as follow:

  • Security specification: Any single security requirement that can be supported by a security service. Some examples could be encryption, authentication, and accountability. They are expressed with USDL-SEC vocabulary. For example: usdl-sec:hasSecurityGoal=anonymity or usdl-sec:hasSecurityMeasure=cryptography.
  • Security Rule: A set or security specifications that describes a complex security agreement that must be fulfilled commonly by two (or more) entities. Some examples could be a Data Protection security rule to apply data protection laws from a country or FI Domain (such as Healthcare or Telecommunication) or a security service level agreement between two different companies, but most of the times they include the information provided by a SecurityProfile (in USDL-SEC language) as defined by the Service Providers in the description of a security service.

PRRS Framework

This component provides run-time support to end-users and client applications for performing dynamic selection & deployment of optional security enablers to support additional security requirements.

PRRS (Platform for Runtime Reconfiguration of Security) framework is the core of the Generic Enabler. It is in charge of controlling the rest of the components of the GE, processing requests from end-user applications and orchestrating the deployment of the optional security enablers selected.

End-user (through a Console) or client applications (through the API REST offered) send requests to the PRRS Framework in order to fulfill their additional security requirements not covered by the core Generic Security Enablers included by design in the FI-WARE Security Platform. These security requests, which include either security specifications (written in USDL-SEC vocabulary) or a reference to already predefined existing security rules, are managed by the PRRS Request Manager sub-module either as a specification of security requirements or as a reference to already existing rule.

The PRRS Request Manager module is also going to be in charge of responding to the Console or the client applications.

The PRRS Repository Manager module is going to deal with the communication between PRRS Framework component and the FI-WARE Marketplace to recover all the available FI-WARE optional security enablers that can be selected to satisfy the client requirements. An internal Security Repository will be used as a cache storing the security relevant information recovered from those services for a more efficient selection based on the USDL-SEC specifications included in the service descriptions.

From the Rule Repository, the PRRS Framework Manager retrieves the set of security rules or security specification to be applied on each security request received and will be triggered by the repository in case of a rule change situation.

ContextManager DB stores useful information related to the applications requests, monitoring systems that oversee them, the security rules that are being used and the registry of the optional security enablers deployed from the Framework Manager decision making support.

Finally PRRS Framework Manager is the decision making engine. It compares security specifications included in the security rules to be applied, user security requirements and context information, and USDL service description features to select the most suitable FI-WARE optional security enabler to be deployed to fulfil the received security requests.

The PRRS Framework Manager also provides external context monitoring services with the validation rules to be checked against the already deployed optional security enablers. Additionally, it takes the necessary recovery actions by the reactivation, reconfiguration, deactivation and/or substitution of the deployed enabler if is required when its reaction mechanism is triggered because an event is received from the context monitors.

Rules Repository

This component will allow storing and managing compliance requirements and relevant specifics at various abstraction levels to the GE and also checking 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 the 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 able to reuse fragments of previously stored formal rule specifications to build a new formal specification form a new law or rule to be stored

Reuse of rule specification fragments will make the task of compiling new laws or rules into formal language easier

Each high-level rule or specification will be compiled into a formal pattern following USDL-SEC specifications 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 the Rules Repository component will be able to trigger the PRRS framework when some rule is modified so that the framework can take the necessary actions in case the modification must be taken into account in compliance measurements

Context Monitor

The Context Monitor is the component in charge of detecting anomalous behavior or non-conformances in End-user context environments. Although in the architecture diagram it is shown only one, it would be possible to have more external context monitors. They must be predefined in the PRRS Framework Context Manager DB as well as the validation rules that the PRRS Framework must send to it when a new service is selected.

Each Context Monitor component gets context and status events from the end user and the security enablers it is overseeing.

Then it will compare the information obtained with the validation rules provided from the PRRS Framework (according to the rules preconfigured for that context monitoring service).

In case of non-compliance detection, the assigned event is sent to the PRRS framework by the appointed monitor so that the framework could take the necessary recovering actions

Additionally, the Context Monitor provides a Dashboard that gives the system reporting capabilities.

Reports of system performance are generated once the information from the data context has been compared with validation rules received from the PRRS.

These visual reports provide useful information about the levels of compliance, performance of the solutions dynamically deployed by the PRRS and simplify the task of identifying root-causes for non-compliant situations.

Example Scenario: Data Protection Schema

The use cases where the CBS&C GE can be used are the same as the different available FI-WARE optional security enablers. Below is described one example of a scenario using some of the available FI-WARE optional security enablers to shown the advantages to the end-user of using the CBS&C GE for their context-aware selection and deployment in the FI-WARE Security Platform:

A Supermarket Branch holds thousands of terabytes of datasets about their customers or their activities. They often have to release data files containing private information to third parties for data analysis, application testing or support. To preserve individuals’ privacy and comply with privacy regulations, part of released datasets have to be hidden or anonymized using various anonymization techniques, before data release.

To address that security requirement before releasing customers data to a new Consulting Company that works in the healthcare domain, Bob (the Local Data Manager) will use the CBS&C GE (included in the FI-WARE Security Platform installed in his company) for a context-aware search and deployment of the security services that best match to his environment and can help him to maintain the compliance with the data protection laws and regulations in the Healthcare domain.

This is the first time Bob uses the CBS&C GE so first, he must configure through the Console offered by the Generic Enabler his preference rules and configuration parameters. He establishes:

  • Service Provider = SAP (we are assuming they have internal agreements with SAP so they prefer to use their services)
  • Operating System = Windows (they are using a windows environment)

Through the same Console, Bob browses among the available predefined security schemas and finds one called DataProtection defined to ensure support for data protection. In particular, it provides support for the following property (the definition of the security requirements in the schemas is done using USDL-SEC vocabulary):

  • Anonymity (usdl-sec:hasSecurityGoal=anonymity)

Consequently, Bob selects this DataProtection security scheme in the Console and clicks the button to start its activation. That is all that Bob needs to do to deploy the optional security enablers that best match his preferences and environment!!

Once Bob has started the activation of the DataProtection security schema, the CBS&C GE will process it searching the services that includes the USDL-SEC requirements of anonymity and finally it will select the deployment of the SAP DBAnonymizer implementation (according end-user preferences about Service Providers).

NOTE: The CBS&C GE will access the FI-WARE Marketplace to search all optional security enabler implementations offered there and available to the user (according to his/her accreditations). In this simple scenario, it is assumed the following FI-WARE optional security enablers are available in the FI-WARE Marketplace:

  • SAP DBAnonymizer
  • Atos DBAnonymizer
  • Thales-UK CBS (Content-based Security)
  • Inria Morphus Antivirus

The CBS&C GE will manage the deployment and potential future reconfiguration of the security service associated to the required security rule. The selected implementation is downloaded and deployed in the end-user environment. The CBS&C will also be in charge of monitoring the availability of the deployed services and the compliance with the end-user context constraints. With that aim, it will have configured a list of active context-monitor services availables for the CBS&C and the validation rules predefined to monitor in them the compliance of the deployed services with the security requirements and end-user constraints. For our scenario, the following validation rules are monitored:

  • availability of the operations provided by the DBAnonymizer enabler (defined in its WADL description)
  • changes in the end-user constraints: service provider preference and operative system

Finally, Bob is informed through the Console that the DataProtection security scheme has been activated as well as the name of the service selected, the endpoint where it is available and how to access the USDL description where all the information about the service is provided so he can start to use it.

From that moment, Bob can use that additional security service deployed in his environment to evaluate his dbdump against his disclosure policy.

  • Context Change 1: What it happens if the SAP DBAnonymizer is down?

Periodically, the context-monitor sends a request to the deployed implementations of the optional security enablers. If after a timeout there is no answer or the answer is that the web service is not available, it generates a NonAvailability event. That event is sent to the PRRS Framework in the CBS&C. When the event is received, the PRRS Framework starts its reaction mechanism and first will try to redeploy that service in a transparent way for the client.

If the problem persists and the DBAnonymizer implementation cannot be deployed, it searchs an alternative service. In this case, Atos DBAnonymizer service is selected and deployed in a transparent way for the client. He will be notified but he can continue using the same interface he was using with the other implementation.

  • Context Change 2: What it happens if the client preferences change?

After a time, Supermarket Branch's internal agreements with SAP are finished and now it has new agreements for instance with Atos. In this new environment, Bob only will need to modify his preference rule about Service Providers in the Console. The context-monitor will detect automatically this change in the USDL preferences and start the verification of the deployed services. In this case, it detects the value of the attribute usdl-core:hasProvider for the deployed DBAnonymizer service deployed is “SAP”. The reconfiguration mechanism is triggered and it selects the Atos DBAnonymizer implementation (also offered in the FI-WARE Marketplace). The SAP DBAnonymizer is undeployed and the new Atos DBAnonymizer is deployed. This change is internal to the GE but transparent to the client application. Bob is notified through the Console but the interfaces are the same so Bob can continue using the endpoint he had to evaluate the policy with his dbdump datasets.

Main Interactions

Selection of user security requirements

Security requirements can be selected by the end-user through the Console offered by the PRRS Framework or sent to the REST API offered by the CBS&C GE from the client applications (or other FI-WARE generic enablers, such as the Security Monitoring GE).

It is possible to indicate/select security requirements with one of the following options:

a. ServiceName: The name of a specific implementation of an optional security enabler. The Console will show a list of all the FI-WARE security enablers offered in the FI-WARE Marketplace and available to the end-user (based on the credentials provided). Otherwise, it can be included in the security request sent to the API REST with:

          <serviceName>SAPDBAnonymizer</serviceName>

b. SecuritySpec: The name of the security specification to be supported. The Console will show a list of all the available security goals as they are defined in USDL-SEC:hasSecurityGoal. Otherwise, it can be included using the USDL-SEC vocabulary in the security request sent to the API REST with:

    <securitySpec>
           <param>usdl-sec:hasSecurityGoal</param>
           <value>antivirus</value>
     </securitySpec>

c. SecurityRule: The name of a security scheme that integrates a set of security specifications defined through a Security Rule. The Console will show a list of all the available Security Rules stored in the Rules Repository. Otherwise, it can be included in the security request sent to the API REST with:

    <securityRule>
        <name>DataProtection</name>
        <domain>Healthcare</domain>
    </securityRule>

Below, steps are described to be followed in a communication between an End-User application and the CBS&C Generic Enabler from the security request sent by an additional security application to its deployment by the GE.

User Request Sequence Diagram

1: An End-User application send a security request to the GE providing information about its security requirements and context. The GE stores the information into its internal data base and replies to the applicant with the assigned service-ID.

2:The GE gets from the Rules Repository either the list of security specifications associated with the Security Rule that the End-User application likes to fulfill or a set of Security Rules that could satisfy the security specifications detailed by the End-User Application.

3: The GE will select from FI-WARE Marketplace the security enabler that best fulfills the user requirements to be deployed into the End-user context.

The communication to be implemented with the Marketplace will be compliant with the API description provided by Application and Services Ecosystem and Delivery Framework Work Package (WP3).For additional details see the FI-WARE wiki.

NOTE: An internal Security Repository where the optional security enablers are already classified based on their security specifications (defined in the USDL-SEC section of the service descriptions) is used (like a cache) before searching in the FI-WARE Marketplace to improve the response time. This Security Repository included in the CBS&C GE is updated with the information stored in the FI-WARE Marketplace GE when the GE is started.

4: The validation rules are sent to the context monitors.

5: The selected FI-WARE optional security enabler is deployed and started. End-user applications get the details to interact with that deployed service.

Selection of optional security enablers to be deployed

The optional security enablers developed by the FI-WARE partners will be offered in the FI-WARE Marketplace GE. Consequently, the CBS&C GE will access the API provided by the FI-WARE Marketplace:

  • To get the list of available implementations of the optional security services offered in the FI-WARE Marketplace GE that can be selected for a client. The end-user must configure in the CBS&C GE his user and password. That user and password will be used to access the FI-WARE Marketplace so only the services included in the security stores where he has been registered can be accessed. The end-user must also configure the name of those security stores.
  • To get the USDL service description for each of those optional security enablers. With this information, the PRRS Framework will update its own Security Repository which works like cache and allows a faster selection based on USDL security specifications.
  • To get the file with selected optional security service or the url where the service can be downloaded (for instance in the FI-WARE Catalogue) in order to deploy it in the end-user environment.
PRRS Framework - Marketplace Sequence Diagram

Provision of Context Information

The PRRS Framework included in the CBS&C GE provides a Console interface to allow the end-users configure their preferences in the selection of optional security services. Only mandatory preferences will be monitored. For example, a company X could have agreements with another company Y and consequently, the end-user could configure the CBS&C GE to select implementations whose provider is company Y. All these preferences will be provided through USDL vocabulary (e.g: usdl-core:hasProvider=Atos)

On the other hand, end-users can configure through the same PRRS Framework Console parameters of their environment. For example, if the CBS&C GE is working on a Windows or Linux platform. These configurations will be also used in the context-aware selection and deployment of the optional security enablers. For example, if an implementation has the requirement of running on Windows, it cannot be selected to be deployed in a client with Linux. The parameters provided as configuration must also be included in the USDL service descriptions.

All the context information related to USDL attributes and provided by the end-user is stored in case of any change (for example if the end-user changes his priority about service providers in the Console), the CCBS&C GE will determine if the deployed service is still compliant with that new context or not (checking its stored USDL service description).

Finally, client applications could need to provide their own context information to be monitored by the CBS&C GE because a change in it could force a reconfiguration of a selected service (for example a disclosure policy to be applied in a company, a sensor data generated by a client application, the localization of a user in mobility, etc). This context information should be published in any FI-WARE Context Broker (Publish/Subscribe Broker) GE with capability to publish context information and to subscribe to changes in it. Then the end-user should provide the values to be monitored (entityId,entityType, and contextValue attributes). Finally the CBS&C GE can subscribe itself to changes in that information. In case of receiving a notification of change, the new contextValue received will be compared with the value preconfigured by the end-user. If they are different, a ContextChange event will be sent to the PRRS Framework module in the CBS&C GE to trigger the recomposition of the service with the new context value.

The end-user could include his context information through the PRRS Console or in the security requests sent to the REST API offered by the PRRS Framework. For example:

       <contextDesc>
             <name>disclosurePolicy</name>
             <entityType>CompanyData</entityType>      
             <entityId>profile</entityId>
             <attribute>disclosurePolicy</attribute>
             <contextValue>none</contextValue>
      </contextDesc>
End-user Context Monitoring Sequence Diagram

Non Compliance Detection

Context monitors are the components in charge of detecting anomalous behavior or non-conformances in end-user context environments. Each context 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 the PRRS Framework and in case of detecting a rule violation, an event will be sent to the RESTfull API offered by the PRRS Framework to trigger the reaction mechanism in the CBS&C GE.

Due to the fact that there is no partner in charge of the implementation of external context-monitors with all the features included in the Backlog Management (such as system performance and generation of reports), only the following context monitoring capabilities will be included in the CBS&C GE:

a. To monitor events generated by the deployed security services to detect anomalous behavior:

In this case it will be monitored, through events generated by the “security enablers handlers” (executable component instantiated by the PRRS Framework to manage each of the security requests), if the deployment of the optional security enabler is ok or not and periodically it will poll the enabler to detect if it is down. In that case, the context monitor will send a NonAvailability event to the PRRS Framework.

b. To monitor changes in the end-user context environment:

First, in case the end-user modifies the value of a mandatory USDL preference rule or a configuration parameter through the PRRS Console, that USDL attribute will be checked in the deployed services to detect if it is still compliant with it or not and in this case a NonCompliance event is sent to the PRRS Framework.

To detect changes in the context information provided by the end-user and published in the FI-WARE Context-Broker, the context monitor would subscribe the FI-WARE Context Broker to that entityId. In case of receiving a notification of a change with a new contextValue, it will be compared with the one predefined by the client. If they are different, a ContextChange event will be sent to the PRRS Framework.

c. To detect validation rule violations:

Rule violation events are sent by external Context Monitors to the PRRS Framework by provided by the RESTful API. Then the PRRS Framework will start the reaction mechanism defined in the End users security specifications.

This section briefly summarizes the steps to be followed in an internal communication between the external context monitors and the PRRS Framework component to notify a non-compliance situation.

Non Compliance Detection Sequence Diagram

1: A context monitor retrieves information from the End-User context both by receiving service even information and by accessing deployed security service logs.

2: The information retrieved on step one is compared with the validation rules and the PRRS Framework is triggered in case of a non-compliance situation.

3: PRRS framework manager takes the most suitable recovery action by the reactivation, reconfiguration, deactivation and/or substitution of the deployed enabler.

Deployment of the optional security enablers

Once the CBS&C GE has selected the optional security enabler that best matches the security requirements and context information provided by the client, it must deploy the optional security GE.

The PRRS Framework will instantiate a security enabler handler to manage the deployment/undeployment/reconfiguration of the selected optional security enabler. This handler will also generate events that will be sent to the context monitor component to detect anomalous behavior (for example, unavailability of the optional security service when the preconfigured timeout is reached without response).

To deploy the selected optional security enabler in the end-user environment, that security handler must:

  • Access the Marketplace GE to know where the selected optional security enabler can be downloaded.
  • Deploy the selected implementation of the optional security service. All optional security enablers must provide a common way of deployment.
  • Once an optional security enabler is deployed, it is added to the active security pattern and shown in the PRRS Console. That screen will also shown the endpoint where the optional security enabler has been deployed so the end-user can access it.
  • From that moment, the end-user can invoke the operations provided by the deployed optional security enablers.

Reaction mechanism

In case a context change is detected or an event with a rule violation is received, the end-user is notified through the PRRS Console and the PRRS Framework reaction mechanism is triggered. Several actions can be taken depending on the type of event received. For the Second FI-WARE Release the following ones will be considered:

  • If a NonAvailability event is received, the PRRS Framework will redeploy the same implementation of the optional security enabler.
  • If a NonCompliance event is received due to a rule violation detected by an external context-monitor or a NonDeployment event is received because the handler could not deploy the selected service, the PRRS Framework will search for a different implementation of the same optional security enabler. The old implementation is undeployed and the new one is deployed.
  • If a ContextChange event is received, the PRRS Framework will reconfigure the current implementation of the deployed optional security enabler with the new context value. With reconfiguration we mean that in case of detecting a context change in a predefined context element, an operation can be invoked in the optional security enabler with the new context value in order to adapt it to the new environment. All optional security enablers must provide a common way of reconfiguration.

Rule Change

This section briefly summarizes the steps to be followed in an internal communication between Rule repository & PRRS component to notify the PRRS of a rule change situation.

Rule Change Sequence Diagram

1: Rule Manager triggers the PRRS Framework every time a stored Security Rule is modified.

2: PRRS Framework Manager gets from its internal database the monitoring services that are overseeing the context where the Security Rule is applicable and updates them with the new validation rules.

Basic Design principles

Design Principles

  • Provide run-time security support for applications by dynamically deploying and monitoring the End-User applications environment
  • Enhance security and dependability by supporting automated integration, configuration, monitoring and adaptation
  • Dynamic compliance of software services to business regulations and user requirements than can be easily modeled trough the rule repository dashboard
  • As an extension (USDL-SEC) of the standard USDL language is going to be defined we share their main principles with it:
  • Uniform Service Descriptions
  • Modular Design
  • Extensibility Principle

Resolution of Technical Issues

When applied to Context-based Security&Compliance GE, the key design goals that can be obtaibed are mentioned in "Basic Design principles" part.

Detailed Specifications

Open API Specifications

Other Relevant Specifications

The data formats for the API rely on the Linked USDL specifications:

FI-WARE Generic Enablers used by the Context-based security & compliance GE are:

Optional Security Enablers developed in FI-WARE:


Re-utilised Technologies/Specifications

The PRRS Framework included in this Generic Enabler is based on the Platform for Runtime Reconfigurability of Security (PRRS) developed within the european Serenity Project (2008 - http://cordis.europa.eu/projects/rcn/78381_en.html).

This platform makes it possible that at design-time developers have the option not to include specific security solutions but rather specify simply the security requirements that the system will have to satisfy during runtime. Consequently, service developers need not to be concerned about the development of a security solution because the PRRS will supply them with the security solution that better fulfils the specifications. Moreover, the client application needs not to be bound to any one particular security solution. By using the PRRS, the system will benefit from a collection of security solutions (which has been developed by security experts and whose security has been previously verified) available during runtime that can be adapted to the context of the system.

The USDL-SEC language developed with this Generic Enabler to describe and register security services, capabilities and compliances rules, is defined as a security oriented module extension of the existing standard USDL 3.0 (http://www.linked-usdl.org).


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). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • 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.


Personal tools
Create a book