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.USDL-SEC - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.USDL-SEC

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Copyright

  • Copyright © 2014 by SAP

Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. As all other FI-WARE members, SAP has chosen one of the two FI-WARE license schemes for open specifications.

To illustrate this open specification license from our SAP perspective:

  • SAP provides the specifications of this Generic Enabler available under IPR rules that allow for a exploitation and sustainable usage both in Open Source as well as proprietary, closed source products to maximize adoption.
  • This Open Specification is exploitable for proprietary 3rd party products and is exploitable for open source 3rd party products, including open source licenses that require patent pledges.
  • If the owner (SAP) of this GE spec holds a patent that is essential to create a conforming implementation of the GE spec (i.e. it is impossible to write a conforming implementation without violating the patent) then a license to that patent is deemed granted to the implementation.

Linked Open Data Vocabulary for Security Features

Introduction to the USDL Linked Data Vocabulary for Security (USDL-SEC)

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. As all other FI-WARE members, SAP has chosen one of the two FI-WARE license schemes for open specifications.

To illustrate this open specification license from our SAP perspective:

  • SAP provides the specifications of this Generic Enabler available under IPR rules that allow for a exploitation and sustainable usage both in Open Source as well as proprietary, closed source products to maximize adoption.
  • This Open Specification is exploitable for proprietary 3rd party products and is exploitable for open source 3rd party products, including open source licenses that require patent pledges.
  • If the owner (SAP) of this GE spec holds a patent that is essential to create a conforming implementation of the GE spec (i.e. it is impossible to write a conforming implementation without violating the patent) then a license to that patent is deemed granted to the implementation.


Introduction

USDL-SEC allows for an explicit representation of a service's security features requires to be easily usable as information source in different scenarios. USDL-SEC is a specification that uses Linked Data (LD) semantic web principles and technologies to interconnect security information with other descriptions and contents. USDL-SEC acts as trait d'union with business and functional information, thus contributing to the constitution of a comprehensive description of a service. It provides an overview of a service's security features, that can refer to a more exhaustive and fine-grained description.

In this way, processes like service discovery and provisioning based on LD can make use of service's multi-faceted descriptions (comprising functional,

business and security aspects), to better assist users in their decision making process.

Linked Data Principles in USDL-SEC

LD consists in a set of recommendations, maintained by the World Wide Web Consortium [1], for makingdata published on the Web "machine-readable, its meaning explicitly defined, linkable with other external data sets, and that can in turn be linked to from external data sets"[2]. LD enables the semantic interconnection among different data sources, so that pieces of information organized and presented on a web site, can be discovered and interpreted by another web site; the result is the integration of the two knowledge bases, and this process can be reiterated with other LD-enabled resources, to create new information exchanges and thus new knowledge.

Through its LD design, USDL-SEC enables an easy integration of its security descriptions with other LD-described data and in LD-enabled applications. USDL-SEC aims primarily at extending the more business oriented service description standard called USDL[3], although it is not limited to this extent, as it could support also other service description languages. USDL covers the main concepts and relationships characterising services, through a family of specifications: USDL-Core, USDL-SLA, USDL-Pricing. In particular, USDL-Core permits to indicate in the same structure a service's functional aspects (e.g. URL, WSDL and so on) as well as its business information (service provider, pricing policy, service-level agreements and so on).

USDL-SEC enters the picture by integrating a service's USDL description with a LD indication of its security features, that can be detailed by its digital security certificate information. LD applications can make use of this interconnected knowledge, as in the mentioned example of service discovery processes.

USDL-SEC Structure

The USDL-SEC model offers different abstraction layers to describe security features and functionalities: The higher abstraction layer offers a very high level description with no reference to any technical aspect, the lowest one enters into the configuration details of the security technologies. The following illustration depicts representation of USDL-SEC elements and relations.

The USDL-SEC elements that are part of the previous figure are:

  • Service: This element belongs to the USDL specification, and represents the USDL description of a standard service. It is the core element of a (business) service expressed with USDL. For this reason, it is the element to which to associate an USDL-SEC description. More information about USDL Service and its usage can be found on the USDL official page and the USDL specification page.
  • Security Profile: it is the root node of a USDL-SEC description of a service. This node does not contain yet any concrete information of the security feature, but just the given name of the security feature (in the following example about DB Anonymizer, the Security Profile is called "ReIdentificationRisk", for a USDL-SEC descrption of a Dropbox-like service, it could be something like "SecureStorage"). This name is not semantically related to any security vocabulary. A Security Profile can be used to represent an aggregation of information, when it is deemed necessary. For instance, for the Dropbox-like service example, the "SecureStorage" profile can contain elements to represent that service-stored data are served with confidentiality in transit and in rest, and their access is regulated by authentication measures.
  • Security Goal: it is the highest abstraction layer referring to a security topic. This element describes the basic security concepts like anonymity, confidentiality, privacy, etc. These concepts are not yet materialized into real solution at this level. A taxonomy for goals was defined for USDL-SEC, inspired from a previous work [4] and extended with new goals that were not defined. The Security Goals taxonomy is listed in Table 1; it is to be noticed, however, that it can be extended at will using LD semantic relations (e.g., inheritance, equivalence and so on).
  • Security Mechanism: is a set of security solutions that can achieve a security goal (a security goal can be achieved by more than one mechanism). These mechanisms are theoretical solutions that answer to specific security requirements like access control, cryptography, certification, etc. For example the confidentiality goal can be achieved by the encryption mechanism. An extensible taxonomy of Security Mechanisms is included in Table 2.
  • Security Technology: it is the lower abstraction layer of the model, it refers to the real implementation of the security mechanisms. Many implementations can refer to the same security mechanism like for example RSA, AES are solutions to implement encryption. For this element we do not propose an ontology due to the huge number of existing security implementations, it would be impossible to catalogue them and maintain the list. For this reason we kept this element open for self-edition. Beside the reference to the implementation trade name, this element contains additional parameters related to the configuration details of the technology, like for example the key length for RSA.
  • Security Measure: it is a means to represent a ternary relationship among a Security Goal, Mechanism and Technology. This method allows to express a direct relation among its participants, so to enable further reasoning on USDL-SEC descriptions. For instance, if a Security Mechanism is used to achieve multiple Security Goals, one can create multiple Security Measures to express the circumstance.
  • Security Realization Type: This element explains at which level a Security Measure operates. Referring to an ISO/OSI-like stack model a security measure solutions can be applied under three realization levels: in transit (e.g. at the network level), in usage (during service computation activities), and in storage. The Security Realization Types taxonomy is listed in table 3.

What is important to notice, is that thanks to the LD principles, everyone can make the structure of the language as just defined, defining its own contents for security goals, mechanisms and technologies. Then, at a later stage, using SKOS[5] and description versioning it will be possible to reconcile differences and/or to fix mistakes.

Namespace URI

http://www.linked-usdl.org/ns/usdl-sec#

USDL-SEC Taxonomies

Table 1: Security Goals Taxonomy
Accountability Anonymity Authentication
Authenticity Authorization Availability
Confidentiality Correctness Identification
Integrity Non-Repudiation Policy Compliance
Privacy Trust


Table 2: Security Mechanism Taxonomy
Access Control Auditing Biometric Data
Certificate Certificate Exchange Certification
Challenge-Response Checksum Control Code
Cryptography Delegation Digest
Digital Signature Filtering Key Management
Load Balancing Logging Monitoring
Obfuscation Obligation Password Exchange
Pseudonym Recommendation Replication
Reputation Shared Secret Steganography
Token Usage Control


Table 3: Security Realization Type Taxonomy
InStorage InTransit InUsage

A Security Feature Analysis for Writing USDL-SEC Descriptions

In order to explain how the USDL-SEC model can be used to real service, let's take the example of the secure storage functionality in the online file storage service DropBox. In its security overview page[6], the DropBox team claims to encrypt user information before storing them onto a third party infrastructure, Amazon S3. A simplified USDL-SEC description of this functionality can be described as follows:

  • Service: DropBox
  • Security Profile: Secure storage
  • Security Goal: Confidentiality
  • Security Mechanism: Encryption realized at the service level
  • Security Technology: 256-bit AES

This example provides a concise overview of the security functionality. However, it is worth noting that this is a single element in a USDL description; more security functionalities can be described with USDL-SEC at the same time, and they can reference to a more detailed security description .

In this way, service discovery operations can make use of USDL/USDL-SEC information, while in-depth security analysis would find their source of information in the referenced security description.

The USDL Editor

The FI-WARE Apps chapter released an USDL editor descibed and available at the following link: https://github.com/linked-usdl/usdl-editor (info at: http://www.linked-usdl.org/node/229 )

The main advantage of the editor, is that it simplifies, and a lot, the creation of USDL and USDL-SEC descriptions for services, especially for non-experts in Semantic Web standards and technologies.

Let us consider an example on how to use the UDSL editor in order to create a USDL and UDSL-SEC service description.

Suppose to have a service, whose Security Goal is Authorization. Let's suppose that it is achieved by a mechanism, Access Control, and by two technologies, SAML and OAuth2 for instance, and the OAuth technology has a parameter "grant_type". The security service is realized at application level.

Then, the UDSL editor compels you to write 2 Security Measures:

  • <Authorization, Access Control, In Usage, SAML> and
  • <Authorization, Access Control, In Usage, OAuth2> .

To write a description with the USDL Editor:

  1. Create a new generic description (the "About" menu entry) Image:usdlsec1.png
  2. Create a new service description (the "add service or model" link, and then select "service" and not "service model")
    • fill all relevant information for your service, they will be captured by USDL relations and types Image:usdlsec2.png
  3. To create a sercurity description, click on the "Security" menu entry, and then on the service name (on the left side of the page) Image:usdlsec3.png
    • Create a Security Profile ("Add security profile", and then "create")
    • Enter a title Image:usdlsec4.png
    • Add a so-called "Security Measure"
    • Insert a title and the select a goal, a mechanism, a technology and a realization type. Suggestion: also add a description, it might be useful for next steps. Image:usdlsec6.png
    • You can provide additional attributes related to the security technology by cliking the "Add variable" button below the technology field. At this level you specifiy the label and the value of the parameter, the unit field can be set according to the context. Image:usdlsec7.png
    • Repeat the previous step as much as needed
  4. When you are satisfied, export your work with the small arrow on the bottom left angle of the page ("Publish"), and select the output format as RDF, TURTLE or JSON. Image:usdlsec8.png

Note that the editor gives the possibility to create a fully customized USDL-SEC description as for the Goal and the Mechanism fields. One can choose a value from the existing dropdown entries or adding a new element by selecting the [NEW ELEMENT] option, Image:usdlsec9.png and then it will be possible to provide an URI element of another ontology or just enter a textual value. Image:usdlsec10.png

An Example: DB Anonymizer USDL-SEC Description

This example depicts the DB Anonymizer functionalities in a USDL-SEC description, and is written using the USDL Editor (see previous sections) and exported using the Turtle[7] syntax.

In order to understand the example, it is worth recalling the DB Anonymizer functionalities. DB Anonymizer performs a re-identification risk analysis (therefore, something with can be linked with the Anonymization Security Goal), it makes use of algorithms that are also used for data obfuscation (and so, we chose the Obfuscation Security Mechanism), and in particular the K-Anonymity and the Entropy-based algorithms.

We implemented the previous analysis defining 2 Security Measures, both Anonymization and Obfuscation, and then we defined a very simple Security Technology element.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix msm: <http://cms-wg.sti2.org/ns/minimal-service-model#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix usdl: <http://www.linked-usdl.org/ns/usdl-core#> .
@prefix legal: <http://www.linked-usdl.org/ns/usdl-legal#> .
@prefix price: <http://www.linked-usdl.org/ns/usdl-pricing#> .
@prefix sla: <http://www.linked-usdl.org/ns/usdl-sla#> .
@prefix sec: <http://www.linked-usdl.org/ns/usdl-sec#> .
@prefix sec-tax: <http://www.linked-usdl.org/ns/usdl-sec-taxonomy#> .
@prefix blueprint: <http://bizweb.sap.com/TR/blueprint#> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ctag: <http://commontag.org/ns#> .
@prefix org: <http://www.w3.org/ns/org#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix time: <http://www.w3.org/2006/time#> .
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix doap: <http://usefulinc.com/ns/doap#> .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html>
  a usdl:ServiceDescription ;
  dcterms:title ""@en ;
  dcterms:description ""@en ;
  dcterms:modified ""^^xsd:datetime ;
  dcterms:creator _:b127 ;
  dcterms:created "2013-05-27T02:00"^^xsd:datetime ,
    "2013-05-27T14:00"^^xsd:datetime .

_:b127
  a foaf:Person ;
  foaf:name "Marouene Boubakri" .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#roJEUOLULL6QJndqb>
  a usdl:Service ;
  dcterms:subject _:b128 ;
  dcterms:modified ""^^xsd:datetime ;
  dcterms:created ""^^xsd:datetime ;
  dcterms:title ""@en ;
  dcterms:abstract ""@en ;
  dcterms:description ""@en ;
  usdl:hasSecurityProfile <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#l8gBH0ncmgyff2zgr> .

_:b128
  a skos:Concept ;
  skos:inScheme blueprint:Industry ;
  rdfs:label "Other services" .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#l8gBH0ncmgyff2zgr>
  a sec:SecurityProfile ;
  sec:hasSecurityMeasure <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#E2SUyng2WEsvHcrXX> ,
    <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#NPiwTa8SlEYVAoC1s> ;
  dcterms:title "ReIdentificationRisk"@en .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#E2SUyng2WEsvHcrXX>
  a sec:SecurityMeasure ;
  dcterms:description ""@en ;
  sec:isRealisedByTechnology _:b129 ;
  dcterms:title "Measure1"@en ;
  sec:hasSecurityGoal sec-tax:Anonymity ;
  sec:isImplementedBy sec-tax:Obfuscation ;
  sec:hasSecurityRealizationType sec-tax:InUsage .

_:b129
  a sec:SecurityTechnology ;
  rdfs:label "K-Anonymization Algorithm Implementation" .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#NPiwTa8SlEYVAoC1s>
  a sec:SecurityMeasure ;
  dcterms:description ""@en ;
  sec:isRealisedByTechnology _:b12a ;
  dcterms:title "Measure2"@en ;
  sec:hasSecurityRealizationType sec-tax:InUsage ;
  sec:hasSecurityGoal sec-tax:Anonymity ;
  sec:isImplementedBy sec-tax:Obfuscation .

_:b12a
  a sec:SecurityTechnology ;
  rdfs:label "Entropy-based Anonymization Algorithm Implementation" .

An Example: Fully Customized USDL-SEC Description

The USDL-SEC part of the USDL Editor permits to indicate Security Goal and Security Mechanism elements in different ways:

  • By selecting them from the mentioned USDL-SEC taxonomies (Security Goals and Security Mechanisms).
  • By creating custom elements.

The former possibility gives to a designer a convenient way for specifying a concept that is already defined. The latter, instead, permits to create simple elements (by specifying their name), or to indicate URIs of existing concept.

Regarding Security Technology elements, there is no USDL-SEC taxonomy for them, for the motivations already expressed. Therefore, it is possible to create any concept, and to associate it to the Security Technology class in order to use it. The USDL-SEC part of the USDL Editor adopts an approach for the creation of simple Security Technology instances, that is described later on in the section #Analysis.

The following output is an example of a customized USDL-SEC description for a DropBox-like Secure Storage service :

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix msm: <http://cms-wg.sti2.org/ns/minimal-service-model#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix usdl: <http://www.linked-usdl.org/ns/usdl-core#> .
@prefix legal: <http://www.linked-usdl.org/ns/usdl-legal#> .
@prefix price: <http://www.linked-usdl.org/ns/usdl-pricing#> .
@prefix sla: <http://www.linked-usdl.org/ns/usdl-sla#> .
@prefix sec: <http://www.linked-usdl.org/ns/usdl-sec#> .
@prefix sec-tax: <http://www.linked-usdl.org/ns/usdl-sec-taxonomy#> .
@prefix blueprint: <http://bizweb.sap.com/TR/blueprint#> .
@prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ctag: <http://commontag.org/ns#> .
@prefix org: <http://www.w3.org/ns/org#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix time: <http://www.w3.org/2006/time#> .
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix doap: <http://usefulinc.com/ns/doap#> .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html>
  a usdl:ServiceDescription ;
  dcterms:description ""@en ;
  dcterms:modified ""^^xsd:datetime ;
  dcterms:creator _:b2f6 ;
  dcterms:title "DropBox"@en ;
  dcterms:created "2013-05-28T10:00"^^xsd:datetime .

_:b2f6
  a foaf:Person ;
  foaf:name "Marouene Boubakri" .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#G2OdAKozL1Gi8YOLM>
  a usdl:Service ;
  dcterms:subject _:b2f7 ;
  dcterms:modified ""^^xsd:datetime ;
  dcterms:created ""^^xsd:datetime ;
  dcterms:title ""@en ;
  dcterms:abstract ""@en ;
  dcterms:description ""@en ;
  usdl:hasSecurityProfile <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#7YGgjuifWYiZFN56B> .

_:b2f7
  a skos:Concept ;
  skos:inScheme blueprint:Industry ;
  rdfs:label "Other services" .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#7YGgjuifWYiZFN56B>
  a sec:SecurityProfile ;
  dcterms:title "Secure Storage"@en ;
  sec:hasSecurityMeasure <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#0y4bJ6yYbQFN3gXBB> .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#0y4bJ6yYbQFN3gXBB>
  a sec:SecurityMeasure ;
  dcterms:description ""@en ;
  sec:isRealisedByTechnology _:b2f8 ;
  dcterms:title "Measure1"@en ;
  sec:isImplementedBy _:b2f9 ;
  sec:hasSecurityGoal <https://example.com/cloud-storage-ontology#Confidentiality> ;
  sec:hasSecurityRealizationType sec-tax:InStorageType .

_:b2f8
  a sec:SecurityTechnology ;
  skos:exactMatch <https://example.com/cloud-storage-ontology#AES> ;
  gr:hasQuantitativeProperty <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#oQl1J3jBq9Fttrlts> ;  
  rdfs:label "AES" .

<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#oQl1J3jBq9Fttrlts>
  a gr:QuantitativeValue ;
  rdfs:label "Key" ;
  gr:hasValue "256" ;
  gr:hasUnitOfMeasurement "bit" .

_:b2f9
  a sec:SecurityMechanism ;
  skos:inScheme sec:securityMechanismsTaxonomy ;
  rdfs:label "Encryption" .

Analysis

USDL-SEC descriptions can be created manually; however, this requires an understanding of the internals of its specifications (besides a knowledge of LD standards). This section tries to help with this respect, by analysing the previous example.

The hasSecurityGoal relation connects the Security Measure with a Security Goal, which value can be an element of the Security Goals taxonomy, or a URI to another ontology, like in this case.

sec:hasSecurityGoal <https://example.com/cloud-storage-ontology#Confidentiality> ;

The isImplementedBy relation expresses how a certain Security Measure is implemented, by means of a Security Mechanism. Indeed, it also represents an indirect link with the Security Goal associated to the Security Measure. Similar to the Security Goals taxonomy, the Security Mechanisms taxonomy can be used as value for this relation. The USDL-SEC part of the USDL editor also allows the specification of textual values, and it would capture this information as the following example; it describes (using Turtle) a Security Mechanism for a user-inserted plain text that is "Encryption".

sec:isImplementedBy _:b2f9 ;
_:b2f9
  a sec:SecurityMechanism ;
  skos:inScheme sec:securityMechanismsTaxonomy ;
  rdfs:label "Encryption" .

A Security Technology is bound to a Security Measure using the isRealisedByTechnology relation. The editor allows to create a Security Technology element, by permitting the specification of a URI or a label, as in the previous case. Here, however, the element that is being generated supports the attachment of custom properties. They can be used to specify aspects and parameters of a technology, like for instance the key length for encryption algorithms.

sec:isRealisedByTechnology _:b2f8 ;
_:b2f8
  a sec:SecurityTechnology ;
  skos:exactMatch <https://example.com/cloud-storage-ontology#AES> ;
  gr:hasQuantitativeProperty <file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#oQl1J3jBq9Fttrlts> ;  
  rdfs:label "AES" .
<file:///C:/Users/I301505/git/fiware_wp8_usdlsec/index.html#oQl1J3jBq9Fttrlts>
  a gr:QuantitativeValue ;
  rdfs:label "Key" ;
  gr:hasValue "256" ;
  gr:hasUnitOfMeasurement "bit" .

In order to understand in which layer a certain Security Measure operates, a Security Realization Type element is bound to it using the hasSecurityRealizationType relation. Taxonomies listed in table 3 are valid values for such element.

 sec:hasSecurityRealizationType sec-tax:InStorageType .  

References

  1. http://w3.org
  2. Bizer, Christian, Tom Heath, and Tim Berners-Lee. "Linked data-the story so far." International Journal on Semantic Web and Information Systems (IJSWIS)5.3 (2009): 1-22.
  3. http://linked-usdl.org
  4. Herzog, A., Shahmehri, N., and Duma, C. (2007) An ontology of information security. International Journal of Information Security, 1, 1–23
  5. http://www.w3.org/TR/2008/WD-skos-reference-20080829/skos.html
  6. http://www.dropbox.com/dmca#security
  7. http://www.w3.org/TeamSubmission/turtle
Personal tools
Create a book