**Executive Summary**

This document presents the 1  st  version of the project’s Data Management
Plan (DMP). This regards, the definition of the DMP as of M6, while the final
version of it will be update during the project’s lifetime and submitted in
M36.

The DMP provides an analysis of the various datasets that will be produced by
the project and the main elements of the data management policy that will be
used by the beneficiaries, in respect with all these datasets that will be
generated by the project. This version of the document reflects the current
state of the datasets paving the way for further updates during the lifecycle
of the project.

In particular, within this document the methods & conventions, as well as the
recommendations for categorising about the use, manipulation and inclusion of
data sets in the FORTIKA project. Moreover, it refers to regulatory aspects
and operational information related to contact, personnel profiles details and
about the ownership of the data within the project. Finally, it serves as a
guide for the participants of the EU funded FORTIKA Project about the data
lifecycle with respect to the creation, identification, caption and
description, storage, preservation (including security and privacy),
accessibility, discovery and analysis, re-use and transformation of data in
the context of the different deployment sites.

Last but not least, the sections related to intellectual property rights (IPR)
are included with the objective to identify the significant aspects of the
project. Subsequently, the contents of the DMP are in fully accordance with
the signed Grant Agreement of the FORTIKA project with respect to EC Horizons
2020 recommendations, while the information provided will define common
grounds in relation to management of the data. In this respect, it is expected
to motivate the participation and the collaboration within the FORTIKA
consortium partners and amongst external partners or participants in the
project.

#  Introduction

##  Project overview

FORTIKA project aims to minimize the exposure of small and medium sized
enterprises (SMEs) to cyber security risks and threats and help them respond
to cyber security incidents. The project aims to relieve SMEs from unnecessary
and costly efforts of identifying, acquiring and using the appropriate cyber
security solutions. In order to achieve these goals, FORTIKA aims to provide
SMEs with a smart and robust hardware security layer (i.e. an FPGA accelerator
able to process data traffic) enhanced with an adaptive security service
management ecosystem (marketplace providing appropriate cyber security
solutions).

##  Data management plan purpose

A DMP describes the data management life cycle for the data to be collected,
processed and/or generated by the FORTIKA Horizon 2020 project. Data
Management Plans (DMPs) are a key element of good data manipulation and
exchange.

More specifically, the DMP shall be generated based on the EU Commission
guidelines regarding the management of data requirements coming from projects
funded by the H2020. According to these guidelines, the data that is going to
be shared for scientific, experimental and commercial purposes should be
easily discoverable, accessible, assessable and intelligible.

Thus, the purpose of this deliverable (D1.4 - Data Management Plan) is to
provide an analysis of the main elements of the data management policy that
will be used by the consortium with regard to all the datasets that will be
generated and/or collected by the project consortium.

##  EU Commission guidelines for data management

Basic guidelines  1  for data management plans are presented in Table 1. These
guidelines were published by the EU Commission for appropriate data management
plans in Horizon 2020 projects.  
  
<table>  
<tr>  
<th>

**DMP Component**

</th>  
<th>

**Issues to be addressed**

</th> </tr>  
<tr>  
<td>

Data Summary

</td>  
<td>

  * State the purpose of the data collection/generation 

  

  * Explain the relation to the objectives of the project 

  

  * Specify the types and formats of data generated/collected 

  

  * Specify if existing data is being re-used (if any) 

  

  * Specify the origin of the data 

  

  * State the expected size of the data (if known) 

  

  * Outline the data utility: to whom will it be useful 

  

</td> </tr>  
<tr>  
<td>

FAIR Data. Making data findable, including provisions for metadata.

</td>  
<td>

  * Outline the discoverability of data (metadata provision) 

  

  * Outline the identifiability of data and refer to standard identification mechanism. Do you make use of persistent and unique identifiers such as Digital Object Identifiers? 

  

  * Outline naming conventions used 

  

  * Outline the approach towards search keyword 

  

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th>  
<th>

  * Outline the approach for clear versioning 

  

  * Specify standards for metadata creation (if any). If there are no standards in your discipline describe what type of metadata will be created and how 

  

</th> </tr>  
<tr>  
<td>

Making data openly accessible

</td>  
<td>

  * Specify which data will be made openly available? If some data is kept closed provide rationale for doing so 

  

  * Specify how the data will be made available 

  

  * Specify what methods or software tools are needed to access the data? Is documentation about the software needed to access the data included? Is it possible to include the relevant software (e.g. in open source code)? 

  

  * Specify where the data and associated metadata, documentation and code are deposited – Specify how access will be provided in case there are any restrictions 

  

</td> </tr>  
<tr>  
<td>

Making data interoperable

</td>  
<td>

  * Assess the interoperability of your data. Specify what data and metadata vocabularies, standards or methodologies you will follow to facilitate interoperability. 

  

  * Specify whether you will be using standard vocabulary for all data types present in your data set, to allow inter-disciplinary interoperability? If not, will you provide mapping to more commonly used ontologies? 

  

</td> </tr>  
<tr>  
<td>

Increase data reuse (through clarifying licences)

</td>  
<td>

  * Specify how the data will be licenced to permit the widest reuse possible 

  

  * Specify when the data will be made available for reuse. If applicable, specify why and for what period a data embargo is needed 

  

  * Specify whether the data produced and/or used in the project is useable by third parties, in particular after the end of the project? If the re-use of some data is restricted, explain why 

  

  * Describe data quality assurance processes 

  

  * Specify the length of time for which the data will remain re-usable 

  

</td> </tr>  
<tr>  
<td>

Allocation of resources

</td>  
<td>

  * Estimate the costs for making your data FAIR. Describe how you intend to cover these costs 

  

  * Clearly identify responsibilities for data management in your project 

  

  * Describe costs and potential value of long term preservation 

  

</td> </tr>  
<tr>  
<td>

Data security

</td>  
<td>

\- Address data recovery as well as secure storage and transfer of sensitive
data

</td> </tr>  
<tr>  
<td>

Ethical aspects

</td>  
<td>

– To be covered in the context of the ethics review, ethics section of DoA and
ethics deliverables. Include references and related technical aspects if not
covered by the former

</td> </tr>  
<tr>  
<td>

Other

</td>  
<td>

– Refer to other national/funder/sectorial/departmental procedures for data
management that you are using (if any)

</td> </tr> </table>

##  Approaches for personal data management

The EU guidelines referenced above do stand that focus is not only given on
personal data but that privacy concerns are also taken into account. However,
the only mention about personal data is limited to a question from an ethical
perspective and as follows: “Is informed consent for data sharing and long-
term preservation included in questionnaires dealing with personal data?” In
addition, under the rubric “Data Security”, the above table requires that the
transfer of sensitive data shall be addressed in data management plans.

In FORTIKA it is mandatory to have a clear strategy with regard to the
personal data and privacy protection. Thus, the project has investigated and
studied the data regulatory aspects in current European frameworks and follows
closely the new European General Data Protection Regulation (GDPR) process and
its outcomes that will enter in force on the 25  th  of May 2018. The data
management plan of FORTIKA will be designed considering the coming
modification in the European GDPR.

##  Data management roadmap

The DMP is a living document that will be constantly evolving during the
lifecycle of the project. The overall timeline defining the oncoming updates
of the DMP are drawn in Figure

1\.

**Figure 1: Time plan of the DMP evolution throughout the project’s lifetime**

The current document forms only the 1  st  version of the DMP overviews the
current status of datasets and the specific conditions attached to them. An
updated version of the DMP will be defined by M18 and will be reported as an
extra section in D1.9 – Periodic Management Report. The final version of the
DMP will then be submitted in M36 as a stand-alone deliverable, i.e. D1.6 –
Data Management Plan (final version).

#  General Principles

This DMP consists of eight basic elements, namely, 1) _data
creation/collection/development methods_ , 2) _metadata and standards_ , 3)
_legal, rights and ethical issues_ , 4) _data storage, 5) data preservation,
6) data access, 7) data discovery and analysis, and 8) data re-use and
transformation_ . In the remainder of this section, the general properties of
these elements are discussed as applied to all members of project’s
consortium.

##  Data creation/collection/development methods

The project involves carrying out data collection (in the context of the
piloting and validation phase) and a set of large scale validation tests to
assess the technology and effectiveness of the proposed framework in real life
conditions. For this reason, human participants will be involved in certain
aspects of the project and data will be collected concerning their personal
info and the corresponding corporate intellectual property rights (IPR). Due
to the fact that the project will collect personal-related data, the
consortium will comply with any European and national legislation and
directives relevant to the country where the data collections are taking
place. To this end, personal -related data will be centrally stored. Also,
data will be scrambled where possible and abstracted in a way that will not
affect the final project outcome.

##  Metadata & standards

The standards used in the project are strongly related to the specific
dataset, so it will be described in more detail in Section 3\.

In general, all datasets are stored in well-known data formats, no new format
is used. Moreover, regarding metadata, references to adopted standards are
made. However, for a few of datasets, the definition of metadata is an ongoing
task, which will be finalised in the following months. Hence, in the next
version of the deliverable full reference to adopted standards will be made.

##  Legal, rights and ethical issues

Data management is necessarily connected to legal rights. A number of
perspectives may be applied in this regard. Data itself may be personal data
or other data. Personal data is further distinguished into sensitive data and
common data. All data may also have an economic value – notwithstanding
ownership of personal data theories and considerations.

Once the legal status of “data” under the FORTIKA project is established,
perspectives may again differ depending on the point of view. From the point
of view of rightsholders, “data management” means transfer of their rights, in
one way or another, to third parties in view of Project execution. From the
point of view of recipients of the data, “data management” means
implementation of an agreement (licensing or transfer) for the Project’s
purposes.

Even once data have been transmitted, again management issues arise, this time
of an internal nature within the organization of each Project partner.
Regardless of whether an agreement to this end has been entered within the
Consortium on a bilateral basis or not, Project partners need to apply certain
internal policies on the data they manage and process. The same is the case
even for data creators: although no bilateral agreement may yet be applicable
to them, Project requirements or general legal obligations may necessitate the
application of an internal data management policy.

Finally, the ethical perspective on data management ought not be overlooked.
Cases may arise when an otherwise lawful data management operation may not be
advisable to Project partners because of ethical reasons. Careful balancing
therefore needs to take place during the Project execution, so as for data
processing carried out during its term to comply both with applicable legal
and ethical standards.

In view of the above this analysis will highlight the many different
perspectives of data management under the FORTIKA project, in an attempt to
provide concrete guidance to Project partners.

###  The legal status of data

A Data Management Plan, at least from a legal point of view, first and
foremost needs to elaborate on the legal status of its basic component term,
data. Data under the FORTIKA project may be both personal data and other
(unqualifiable from a legal perspective) data.

With regard to personal data, EU data protection law applies. According to the
EU General Data Protection Regulation (Regulation (EU) 2016/679), “’personal
data’ means any information relating to an identified or identifiable natural
person (‘data subject’); an identifiable natural person is one who can be
identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an online
identifier or to one or more factors specific to the physical, physiological,
genetic, mental, economic, cultural or social identity of that natural
person;” (Article 4(1).

The FORTIKA project has well taken this matter into account, and has dedicated
a WP, WP2, to this end. It will be under this WP that the relevant, complex,
legal issues will be tackled. Here, for picture completeness purposes, it is
enough to be noted that the GDPR, that will become directly applicable in all
of the EU on May 2018, forms the legal basis for personal data processing
under the FORTIKA project. In the event of use cases carried out under the
Project, the applicable laws of the EU Member States concerned will equally be
taken into account. In this regard, all applicable laws and regulations with
regard to processing of personal data will be adhered to.

As far as other, unqualifiable, data processed under the Project are concerned
(for example, technical data) their legal status may vary considerably.
Technical data, for example, may not be protected per se, but if included in a
database they may acquire the special legal protection afforded to databases
within the EU (Database Directive, Directive 96/9/EC). As per its wording,
“’database’ shall mean a collection of independent works, data or other
materials arranged in a systematic or methodical way and individually
accessible by electronic or other means” (Article 2). While perhaps not being
able to profit from copyright protection, all data collected during Project
execution and placed within a database may make use of the above provisions.

On the other hand, if data under the Project pertain to a computer program,
these benefit from specialized protection under the EU law (Software
Directive, Directive 2009/24/EC), which is broadly placed under the
intellectual property law system. According to its wording, in Recital 7, “for
the purpose of this Directive, the term ‘computer program’ shall include
programs in any form, including those which are incorporated into hardware.
This term also includes preparatory design work leading to the development of
a computer program provided that the nature of the preparatory work is such
that a computer program can result from it at a later stage”.

Even for data processed under the Project that are apparently left outside the
scope of any of the above legal systems, competition law may be relevant, as
last resort. It is in this regard that, apart from work carried out under WP2,
Project partners are invited to communicate with the legal partner with regard
to the ad hoc legal status of their datasets, and the legal rights pertaining
thereto.

###  Data ownership

Notwithstanding the issue of whether ownership rights are applicable at all on
personal data, ownership of the data under the Project resides, under normal
circumstances, with their creator. This is, after all, confirmed, in Section 8
of the Consortium Agreement (on Results). The legal or natural person
generating the data is these data’s first rightsholder. Admittedly, this
statement makes the assumption that intellectual property rights apply on
these data (see, for example, Article 2 of the Computer Programs Directive).
The same is the case with the Database Directive: Data included in a database
bear property rights to the database’s creator. In all other cases,
competition law will most likely award property-like protection to the Project
partner generating the data.

In the event that the issue of data ownership is not addressed through the
applicable legal framework or contractual agreements already in place, Project
partners need to provide, within their respective organizations, accordingly.

Data transfers

Essentially being a collaboration project, FORTIKA involves a number of data
transfers among its project partners. These transfers ought to be examined
under the Data Management Plan as well, indeed from a legal perspective, in
view of their lawfulness and fairness, which will in turn contribute to
successful Project execution.

Data transfers under the FORTIKA Project need to be mapped and lawful. As far
as mapping is concerned, the relevant requirements are met within this
deliverable, in the sense that datasets are outlined herein and partners are
hereunder deciding, and agreeing, on current future data transfers among them.
It is however imperative that such transfers are well regulated as well.
Regulation may come in the form of either explicit mention in the Consortium
Agreement (for example, in Sections 8 and 9) or bilateral agreements between
the parties concerned. Access and use rights, as well as derivative products
or intellectual property exploitation (in the form, for example, of patents)
are all issues that need to be addressed in such agreements, if not addressed
already in the relevant Sections (8 and 9) of the Consortium Agreement.

Additional caution is advised in the event of transmissions of personal data.
In this case, apart from any contractual agreements, EU data protection law
applies (indeed, in the event of contradictions with contractual terms, it
supersedes them). The FORTIKA project has applied the necessary legal
procedures in view of lawful processing of data by data controllers (notably,
notification of competent DPAs). The details of these tasks will be described
under the Project’s D2.4 deliverable. In this case the principle of
accountability holds liable for any such personal data processing the
controller: as per Article 5.2 of the GDPR, “the controller shall be
responsible for, and be able to demonstrate compliance with, paragraph 1
(‘accountability’)”.

However, this addresses legal issues raised only within the same controller’s
organisation. If transmission of such data to other project partners is
required, this needs to take place under special contractual clauses and
arrangements. It is to this end that legal guidance will be provided to
Project partners during use cases execution, in order to resolve relevant
issues that may arise. At any event, the applicable legal framework, as well
as concrete, practical guidance in this regard, will be provided to all
project partners under WP2.

###  Internal data management policies

Regardless whether project partners are the rightsholders or the recipients of
data processed under the Project they are required to apply internal data
management policies. These are best elaborated under other subchapters of this
chapter, for example on data collection, data storage, data re-use etc. Here
is enough to be noted that these policies need to comply with applicable legal
standards, relevant to the legal status of the data concerned. Project
partners are advised to make use of relevant legal principles, for example the
principles of proportionality and reciprocity, while drafting and implementing
their internal data management policies.

In the event that a general data management policy is already in effect within
a Project partner’s organisation, then such partner is required to advise the
Project’s Security Advisory Board, as per Article 6.9 of the Consortium
Agreement, in order to warrant its approval. In the event of divergence with
applicable Project practices, an ad hoc solution will be required.

Apart from formal legal requirements and internal regulations already in
effect, Project partners are also advised to observe soft law requirements as
well, while drafting their data management policies. The latter is a
particularly critical point, in the sense that soft law, although not of a
binding nature, should be considered applicable for the Project’s purposes,
because it will enhance compliance and will constitute Project best practices.
In essence, guidance issued by EU agencies, such as ENISA, or industry bodies,
for example applicable technical standards, although not of a formal legal
status, needs to be taken into account by project partners. By doing so, they
will adhere to the highest possible regulatory standards, which will in turn
warrant successful Project execution.

###  Ethical standards on data management

Apart from legal requirements, ethical standards may too be applicable in data
management. The FORTIKA project has well acknowledged this fact, and will
issue a relevant guide, under WP2 (D2.4). In addition, it operates throughout
Project execution an Ethical Helpdesk, reporting regularly under the Project,
that is aimed at addressing relevant partners’ concerns. Issues such as
confidentiality, security and awareness are addressed under this thematic.
Here it is enough to be noted that partners are advised to apply the Ethics
Manual and Guidelines, and make use of the Ethical Helpdesk (section 1.3),
while drafting their data management policies.

In the event that ethical codes of practice or other relevant guidance is
already in place within organization, this fact needs to be announced to the
Project’s Security Advisory Board, in order for compatibility with the
project’s own guidelines to be confirmed. In the event of divergence, the
issue will need to be addressed on an ad hoc basis.

##  Data storage

Data is an asset that itself has a value; accordingly storing  2  the data
provides the capability to preserve value. When data needs to be stored there
may arise implications absent until this point in the data lifecycle (e.g. the
most relevant are the format and how the data will be stored). In this
context, we list some characteristics of this process that will be taken into
consideration during the project’s lifetime:

  * Format to be used for storing data 

  

  * Duration of the storage 

  

  * Plan for reusing the data 

  

  * Intended community that uses this data 

  

  * Data protection for security and privacy reasons 

  

##  Data preservation

Similarly, the preservation of the data is of equal importance as their
storage. As of this, a durable threat for the stored data is introduced, which
is no other than the secure and intact maintenance of both the content and the
format. In a wider definition preservation of data defines the process of
formulating and defining the ways to that guarantee the data will remain
during the time and that will be useful for the same purpose which it was
created and stored for. Some general characteristics about the data in this
process that will be taken into consideration during the project’s lifetime
include:

  * Migrate the data to best format 

  

  * Migrate the data to suitable medium 

  

  * Back-up stored data to preserve the information 

  

  * Create metadata and documentation for the stored data 

  

  * Archive data in a defined physical or virtual medium 

  

  * Secure mechanism against threats to delate, change, stole, etc. the data 

  

##  Data access

Providing access in adequate ways to the data lies within FORTIKA’s
conventional obligations. The accessibility of data is in general a complex
process since it has to be able to facilitate the data access for any demand.
For instance, whenever the demand comes from multiple parties the access
process is increasing. This is not only due to the specific activities
associated with every access request, but also because certain parts of the
lifecycle have to be repeated to generate new data. In this respect, data
access will also define ways to: – distribute Re-distribute the data

  * share and format of the data 

  

  * security and privacy mechanisms to control the accessibility 

  

  * establish copyright for the data 

  

  * promote data 

  

##  Data analysis

FORTIKA focuses on providing services for Data Analysis. Analysis of data has
in general several implications following the original data representation and
the basic information provided when the data was created. Data discovery and
data analysis reside together in the FORTIKA lifecycle simply because the
demands for the information is to generate a meaningful outcome that helps to
inform, observe, visualize features of the data, through the dedicated tools
(e.g. SIEM, visual analytics in the DSS, etc.).

Apart from the tools that will be developed within the project. Among others,
the idea behind this is to offer an enhanced version of the data discovery &
analysis system Snort  3  . Our aim is to provide powerful network traffic
analysis tool that can be used as an intrusion detection/prevention system
capable of performing real-time traffic analysis on IP networks that will
built upon technologies like:

  * Detection of buffer overflows, stealth port scans, CGI attacks, SMB bombs, OS fingerprinting attempt, etc. 

  

  * intrusion detection capabilities that can be defined by specifying the: 

    * protocol used for the network traffic 

  

    * IP address which has to be observed 

  

    * port number that gives access to a system 

  

    * browser which is installed 

  

    * application that can be a point of risk on a system 

  

  

##  Data re-use & transformation

The re-usability of the data and the ways to transform it into meaningful
results forms a significant process in the FORTIKA Data Management Lifecycle.
In this respect, the correct collection of data will be performed through an
appropriate transformation mechanism, able to facilitate data re-usability and
to allow for data repurposing. In this respect, FORTIKA aims to make best use
of this process by means of offering re-usability and transformation tools to
annotate, describe and share data as follow:

  * Follow-up data along other lifecycles 

  

  * New Data lifecycles – Undertake information about the produced data 

  

  * Find points for improving data 

  

  * Learn from the shared data 

  

  * Identify better mechanisms for sharing data 

  

  * Define post processing beyond re-using and transforming data 

  

#  FORTIKA data management plan

In this section the initial data to be provided and/or produced by the
project’s end-users and technical partners, respectively, have been identified
and presented. It should be noted that the idea behind this initial reporting
of the data that the project will deal with, analyse, produce and
built/validate its technologies upon is the following one: First the data
released by the end users (i.e. MOTIVIAN, ALKE, NEME, Obrela & WATT) have been
reported while then, the technical partners have studied how this data should
and will be processed, what kind of metadata can be extracted and/or generated
and most importantly what other network related data can be (seamlessly)
collected from different layers of an SME’s network infrastructure and how
this can be utilized in order to serve the cybersecurity scopes of the
project.

Last but not least, it should be noted that due to the current early phase of
the project, not all partners were able to identify the exact data with which
they will contribute to the project’s needs and the corresponding DMP, while
many of the reported data hereafter may change in the next few months. In any
case, a more complete version of the DMP will be delivered in M18 as described
in Section 1.5.

##  FORTIKA Datasets

The following subsections consist of the data management analysis for every
identified dataset.

###  Motivian dataset

**Table 1: Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

_**Motivian SMS Gateway** _

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

Name

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

Surname

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

Date of birth (not year)

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

Type of mobile device (Android/iPhone)

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

Mobile number

</td> </tr>  
<tr>  
<td>

**6**

</td>  
<td>

Number of SMSs sent per day

</td> </tr>  
<tr>  
<td>

**7**

</td>  
<td>

Time taken for whole transmission of SMSs.

</td> </tr>  
<tr>  
<td>

**8**

</td>  
<td>

Date and time of transmitted data

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. Motivian.SMS_Gateway> **

</th> </tr>  
<tr>  
<td>

**Metadata & standards **

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

</td>  
<td>

_The dataset is a string that comprises of the Name, Surname, date of birth
and type of mobile device for each user the campaign SMS gateway server sends
a message. The message varies per campaign and is not stored. We don’t foresee
any future sub-datasets._

_Data that can also be monitored is number of SMSs, transmission period, date
and time of transmission._

</td> </tr>  
<tr>  
<td>

**Data source (i.e.**

**device)**

</td>  
<td>

**which**

</td>  
<td>

_The dataset is collected online through Motivian’s SMS Gateway server and is
stored on a separate server hosting the database. The devices used are Linux
based servers in a 3-Tier architecture._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

</td>  
<td>

_Aggregated data concerning the frequency of sent messages or phone-calls will
be used for visualizing dependences between_

</td> </tr> </table>  
<table>  
<tr>  
<th>

**documentation**

</th>  
<th>

_mobile users. Information of interest would be:_

  * _How many messages are sent between people of_

  

_similar age (e.g. 30 to 40 years old),_

  * _How many messages are sent per hour (which hours of day have more traffic),_

  

  * _What type of device is used (e.g. android, iPhone) and with what frequency._

  

_By visualizing such information abnormalities in the frequency of sent
messages can be detected and investigated._

</th> </tr>  
<tr>  
<td>

**Standards, format,**

**estimated volume of data**

</td>  
<td>

_The data format is specific and is provided by the mobile operator. The
structure is as follows: - Name, alpha string 20 chars_

  * _Surname, alpha string 40 chars_

  

  * _Date, 4 digits (e.g. 30/11 for Nov,30)_

  

  * _Device Type, alphanumeric, 20 chars_

  

  * _Mobile number, numeric 20_

  

_The estimated volume can vary from 10.000 SMS per day to 1M SMS per day_

</td> </tr>  
<tr>  
<td>

**Partners’ activities & responsibilities **

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_Motivian_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_Motivian_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_Motivian_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data analysis**

</td>  
<td>

_Motivian_

</td> </tr>  
<tr>  
<td>

**Data storage & preservation **

</td> </tr>  
<tr>  
<td>

**Data storage, including** _The data is stored on Motivian servers (database
and storage)._

**backups** _The information is owned by Motivian’s clients with whom_

_Motivian has signed an agreement._

_Data is offloaded after approximately 1 month._

_There is no limitation in archiving._

_For the period of 1 month archived data can reach 100M SMSs._

</td> </tr>  
<tr>  
<td>

**Data access, sharing & reuse **

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_Data collected can be processed and run analytics on how many SMS have been
sent per day or per the whole campaign. This data is only for internal
consortium consumption or exploitation._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission**

</td>  
<td>

_The full dataset will be confidential and only the members participating in
the deployment will have access on it. Furthermore, if the dataset or specific
portions of it (e.g. metadata, statistics, etc.) are decided to become of
widely open access, it will be uploaded to the FORTIKA open data platform._

</td> </tr>  
<tr>  
<td>

**services, public)**

</td>  
<td>

_Of course, these data will be anonymized, in order to avoid any potential
ethical issues with their publication and dissemination. Care must be taken so
that the data is only seen by Motivian employees, who are accredited to see
the data._

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and distribution**

</td>  
<td>

_Data sharing policies have not been decided yet. Since the dataset in this
case contains personal information (name, surname) we envisage that no data
sharing will take place. The only data to be shared is number of SMSs,
transmission period, date and time of transmission._

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_No there Is no embargo period before data is shared. Embargo only applies to
Motivian to disclose any personal information and to the employees of
Motivian._

</td> </tr> </table>

###  ALKE datasets

**Table 2: Dataset List**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

_**ALKE dataset** _

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

Data exchange between the company intranet and the web.

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

Data exchange between the company and electric vehicles on the field.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. ** **ALKE.intranet > **

</th> </tr>  
<tr>  
<td>

**Metadata & standards **

</td> </tr>  
<tr>  
<td>

**Dataset**

</td>  
<td>

_Data exchange between the company intranet and the web._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which device)**

</td>  
<td>

_Company intranet._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and
documentation**

</td>  
<td>

_Aggregated data concerning the number of sent e-mails per hour, or the number
of transported ftp files per hour, and by which users, can be used in order to
produce visualized outputs and detect abnormalities in the behaviour of
users._

</td> </tr>  
<tr>  
<td>

**Standards, format,**

**estimated volume of data**

</td>  
<td>

_Any kind of data can be transmitted to the web from the company network
(emails, remote terminals, ftp files, etc). There is not a fixed dataset, it
is an amount of data going in and out._

</td> </tr>  
<tr>  
<td>

**Partners’ activities & responsibilities **

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_ALKE_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_ALKE_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_ALKE_

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Data access, sharing & reuse **

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_In order to deal with security problems such as security of incoming/outgoing
communications._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission services,**

**public)**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and distribution**

</td>  
<td>

_-_

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. ** **ALKE.Electric_vehicle > **

</th> </tr>  
<tr>  
<td>

**Metadata & standards **

</td> </tr>  
<tr>  
<td>

**Dataset**

</td>  
<td>

_Data exchange between the company and electric vehicles on the field_

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which device)**

</td>  
<td>

_Electric vehicles_

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and
documentation**

</td>  
<td>

_Aggregated data concerning the controller status, dashboard alerts, dashboard
light status, on board temperature, motor temperature, onboard devices status,
vehicle’s energy consumption, etc., can be used in order to detect
abnormalities in the behaviour of electric vehicles._

</td> </tr>  
<tr>  
<td>

**Standards, format,**

**estimated volume of data**

</td>  
<td>

_The data collected from the vehicle and shared in the cloud are the
following:_

  * _Vehicle ID,_

  

  * _total Km covered by the vehicle,_

  

  * _partial Km,_

  

  * _drive mode,_

  

  * _gearbox status (neutral, forward, backward),_

  

  * _driver presence,_

  

  * _battery cycles,_

  

  * _energy charged,_

  

  * _energy delivered,_

  

  * _regenerative energy produced,_

  

  * _total energy,_

  

  * _battery Voltage,_

  

  * _vehicle status,_

  

  * _controller status,_

  

  * _charger status,_

  

  * _battery data logger status,_

  

  * _GPS status,_

  

  * _GPS position,_

  

  * _date,_

  

  * _time,_

  

  * _dashboard alerts,_

  

</td> </tr>  
<tr>  
<td>

</td>  
<td>

  * _dashboard light status,_

  

  * _on board temperature,_

  

  * _motor temperature,_

  

  * _onboard devices status_

  

_(other functions are under development so not yet finalized, thus this list
may increase)._

</td> </tr>  
<tr>  
<td>

**Partners’ activities & responsibilities **

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_ALKE_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_ALKE_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_ALKE_

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_Stored in the cloud._

</td> </tr>  
<tr>  
<td>

**Data access, sharing & reuse **

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_In order to deal with security problems such as security issues that can
affect the system relates mainly to intrusion at level of vehicle body
computer or into the ALKE cloud platform with stolen data or in most negative
case with intrusion at level of control unit taking control of some activity
of the vehicle, not only getting data._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission services,**

**public)**

</td>  
<td>

_The only sensitive data that can link to personal data are in some very
specific circumstances the name of the driver in presence of specific request
for fleet management purposes._

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and distribution**

</td>  
<td>

_-_

</td> </tr> </table>

###  TEC datasets

**Table 3: Dataset List**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

_**TEC Dataset.** _

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_TIMIT data._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Twitter data._

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Switchboard LDC97S62 data._

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. TEC.TIMIT> **

</th> </tr>  
<tr>  
<td>

**Metadata & standards **

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_Access to TIMIT data corpus which was purchased as part of another EU
project._

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which device)**

</td>  
<td>

_TIMIT data corpus._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Standards, format,**

**estimated volume of data**

</td>  
<td>

_The size of the dataset we hold for research purposes is 19MB stored as plain
text file._

</td> </tr>  
<tr>  
<td>

**Partners’ activities & responsibilities **

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data analysis**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Data storage & preservation **

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_The size of the dataset we hold for research purposes is 19MB stored as plain
text file._

</td> </tr>  
<tr>  
<td>

**Data access, sharing & reuse **

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_Access to TIMIT data corpus which was purchased as part of another EU
project._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission**

**services, public)**

</td>  
<td>

_The data is open source and hence there are no confidentiality and privacy
issues._

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and distribution**

</td>  
<td>

\-

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. TEC.Twitter> **

</th> </tr>  
<tr>  
<td>

**Metadata & standards **

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_Data from Twitter users._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which device)**

</td>  
<td>

_Twitter._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and**

</td>  
<td>

_Aggregated information concerning the frequency of referenced words,
frequently referenced links (e.g. malicious_

</td> </tr>  
<tr>  
<td>

**storage dates, places) and documentation**

</td>  
<td>

_links sent by multiple users) and the location of such twits, can be used in
order to detect affected twitter accounts._

</td> </tr>  
<tr>  
<td>

**Standards, format,**

**estimated volume of data**

</td>  
<td>

_The size of the dataset we hold for research purposes is 10MB in XML format_

</td> </tr>  
<tr>  
<td>

**Partners’ activities & responsibilities **

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data analysis**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Data storage & preservation **

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_The size of the dataset we hold for research purposes are as follows is 10MB
in XML format_

</td> </tr>  
<tr>  
<td>

**Data access, sharing & reuse **

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_Data from Twitter users._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission**

**services, public)**

</td>  
<td>

_These data have sensitive attributes and hence we anonymize these data with
state of the art techniques. In addition, we apply the highly secure
homomorphic encryption to carry out any analysis on the encrypted domain._

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and distribution**

</td>  
<td>

\-

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. TEC. _Switchboard_LDC97S62_ > **

</th> </tr>  
<tr>  
<td>

**Metadata & standards **

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_Access to the switchboard LDC97S62 dataset that is publicly available for
research purposes._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which device)**

</td>  
<td>

-LDC97S62 dataset. 

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

\-

</td> </tr>  
<tr>  
<td>

**Standards, format,**

**estimated volume of data**

</td>  
<td>

_The size of the dataset we hold for research purposes is 20MB._

</td> </tr>  
<tr>  
<td>

**Partners’ activities & responsibilities **

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data analysis**

</td>  
<td>

_TEC_

</td> </tr>  
<tr>  
<td>

**Data storage & preservation **

</td> </tr>  
<tr>  
<td>

**Data storage, including** _The size of the dataset we hold for research
purposes is 20MB._

**backups**

</td> </tr>  
<tr>  
<td>

**Data access, sharing & reuse **

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_Access to the LDC97S62 dataset that is publicly available for research
purposes._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission**

**services, public)**

</td>  
<td>

The sensitive data we use for the evaluation of the security components are
all protected using the state of the art encryption tools.

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and distribution**

</td>  
<td>

\-

</td> </tr> </table>

###  Nemetschek dataset

**Table 4: Dataset List**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

_**Nemetschek dataset** _

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

Data exchange between the company intranet and the web.

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS. Nemetschek.intranet> **

</th> </tr>  
<tr>  
<td>

**Metadata and standards**

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_Data exchange between the company intranet and the web._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which**

**device)**

</td>  
<td>

  * _Nemetschek has certified ISO 27001 compliant ISMS and ISO 9001 QMS_

  

  * _Complex ITC infrastructure undergoing major restructuring._

  

◦ _More than 250 workstations (desktops, laptops) and numerous mobile/portable
devices,_

◦ _More than 15 servers (AD controllers, application and file servers)._

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th>  
<th>

</th>  
<th>

◦

</th>  
<th>

_Fail-_

▪

</th>  
<th>

_over internet connectivity_

_2 connections to 2 independent ISP providers (possibility of adding a third
one or replacing one of old providers is currently under investigation)_

</th> </tr>  
<tr>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

▪

</td>  
<td>

_2 enterprise Cisco routers (with BGP protocol)_

_2 enterprise Cisco ASA Firewalls (plus 1 legacy_

_CISCO ASA device with specific functions)_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

▪

</td>  
<td>

_2 Sophos UTM devices used as VPN tunnel termination points and mail-
relay/antivirus/anti-spam_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td>  
<td>

◦

</td>  
<td>

_New branch office to accommodate part of the Virtualization and Storage
infrastructure and is safely connected to the headquarters and to Internet_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_CISCO IDS modules on the ASA firewalls_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_Enterprise anti-malware protection system based on Sophos software_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_ITC monitoring infrastructure is based on Zabbix – with main focus on
availability of important of Nemetschek own or partner important systems and
resource availability of some particularly important servers_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_On-premise VOIP system (based on Asterisk)_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_LAN is Windows AD 2012 R2 based (future upgrade to 2016)_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_Trusted relationships between domains with 1 foreign partner_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_5 VPNs with foreign development partners (4 Point to point tunnels, 1 one
–to-many vpn)_

◦ _Employees of Nemetschek and partner representatives need to access systems
on the both sides of the VPNs_

◦ _Some of the partners have certified ISO 27001 ISMS and all of them - strict
Info Security Requirements_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_Office VPN is heavily used from employees at home office or on business
trips_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_2 Wi-Fi networks (Company network and Guest) with constantly increasing
workload_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_Complex e-mail infrastructure_

◦ _IBM Domino based 2 main servers (clustered), one server for WEB/mobile
access, 2 mail-relay/antispam/anti-malware Sophos UTM Devices_

◦ _Moving to MS Exchange (cloud based or on premise) is currently
investigated_

</td> </tr>  
<tr>  
<td>

</td>  
<td>



</td>  
<td>

_Certificate authority infrastructure is undergoing_

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th>  
<th>

_improvement and restructuring_

  * _Number of publicly accessible web sites hosted within company infrastructure is increasing steadily_

  

  * _Virtualization infrastructure based on VMWare and CITRIX hypervisors_

  

  * _Implementation of application and desktop virtualization (CITRIX)_

  

  * _Skype for Business infrastructure established (needed by one of the development teams) is under investigation_

  

  * _Video conference systems (Cisco Telepresence) are established at the headquarters and new branch office and need to be connected with similar systems at partner sites_

  

  * _Representatives of the support unit of the Sales Dept._

  

_have to visit customers or remotely access their IT infrastructure_

  * _Most of the Information systems are based on premise but future use of cloud based (IAAS, PAAS) or hybrid infrastructure is under investigation_

  

  * _Increasing number of security sensitive information systems which should be accessed only by authorized users (Payroll and Paid Leave systems for the whole company, systems in the Finance/HR Department)_

  

</th> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

_Aggregated data concerning the number of sent e-mails per hour, or the number
of transported ftp files per hour, and by which users, can be used in order to
produce visualized outputs and detect abnormalities in the behaviour of
users._

</td> </tr>  
<tr>  
<td>

**Standards, format, estimated volume of data**

</td>  
<td>

_Any kind of data can be transmitted to the web from the company network
(emails, remote terminals, ftp files, etc). There is not a fixed dataset, it
is an amount of data going in and out._

</td> </tr>  
<tr>  
<td>

**Partners’ activities and responsibilities**

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_Nemetschek_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_Nemetschek_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_Nemetschek_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Data access, sharing and reuse**

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_FORTIKA Systems/Technologies/elements could benefit from piloting_

  * _Hardware or/and virtual appliances_

  

  * _Intrusion prevention_

  

  * _Better analysis of traffic to security sensitive systems within our ICT_

  

  * _Better protection of publicly accessible systems and systems for internal use (including e-mail system) from cyber attacks from outside/inside Nemetschek ITC infrastructure_

  

  * _Monitoring traffic to/from Gest Wi-Fi network and detecting cyber attacks from users of that network_

  

</td> </tr>  
<tr>  
<td>

**Data access**

**dissemination**

**(confidential,**

**members of the consortium and the commission public)**

</td>  
<td>

**only services,**

</td>  
<td>

**policy/ level for**

</td>  
<td>

  * _Installation and configuration should not cause disruption of ICT infrastructure functioning, especially connections (VPNs, domain trusts) with partners, and publicly accessible web sites_

  

  * _Implementation and operation on FORTIKA solutions should not lead to significant changes in the configuration of Nemetschek ICT infrastructure (changes in the routing between networks, changes in IP address space, AS for external IP addresses, IP addresses for VPN tunnel terminations, changes in IP addresses of systems which are accessed by second and third parties (partners and customers)_

  

  * _All traffic between Nemetschek and its partners and customers should be protected from unauthorized access of organizations participating in FORTIKA project_

  

  * _Implementation (installation, configuration), and operation of FORTIKA systems/elements should not present significant increase the load on ITS personnel (system administrators) - steep learning curve, time for system monitoring_

  

</td> </tr>  
<tr>  
<td>

**Data sharing, distribution**

</td>  
<td>

**re-use**

</td>  
<td>

**and**

</td>  
<td>

\-

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_-_

</td> </tr> </table>

###  SEARS Dataset

In this subsection SEARS dataset containing information about users and their
chat activity is given.

Nowadays, SME employees are using cyber chat tools to better serve customers
or to meet other work needs. The characteristics of SEARS dataset for social
engineering recognition is given in the following matrix.

**Table 5: SEARS Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**SEARS features**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Username._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Dialogue._

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Timestamp._

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Exposure Time._

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_Interlocutors Common History._

</td> </tr> </table>

Information concerning SEARS dataset is given in the following matrix.  
  
<table>  
<tr>  
<th>

**Dataset name <DS. ** **UOM.SEARS > **

</th> </tr>  
<tr>  
<td>

**Metadata and standards**

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_The dataset is comprised of characterized chat text dialogues between
attacker – victims and usual chat dialogues. The dataset is accompanied with
UOM’s slang language dictionary._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which**

**device)**

</td>  
<td>

_Data will be collected during pilot use cases._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

_The content of metadata includes chat messages, timestamps and categorical
data. These data can be used in order to categorize a dialogue and infer about
social engineering attempts._

</td> </tr>  
<tr>  
<td>

**Standards, format, estimated volume of data**

</td>  
<td>

_The primary data formats of the final data set will CSV and JSON formats.
Moreover, special chat storage formats, like chat trees will be used in
combination with MongoDB._

</td> </tr>  
<tr>  
<td>

**Partners’ activities and responsibilities**

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_UOM_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_UOM_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Data access, sharing and reuse**

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_The dataset will be used in SEARS module to estimate social engineering
attack risk._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission services, public)**

</td>  
<td>

_The full dataset will be confidential during the FORTIKA project and it will
be available to FORTIKA . Furthermore, if the dataset or specific portions of
it (e.g. metadata, statistics, etc.) are decided to become of widely open
access, it will be uploaded to the FORTIKA open data platform. Of course, the
data will be anonymized, in order to avoid any potential_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

_ethical issues with their publication and dissemination._

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and**

**distribution**

</td>  
<td>

_The dataset will be available on FORTIKA members upon request to UoM
representative Prof. Ioannis MAVRIDIS, via email. The purpose of dataset
sharing request should be expressed clearly to UoM’s representative. After,
the approval of dataset sharing, access to dataset will be provided to the
requester via an email._

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_-_

</td> </tr> </table>

###  ABAC Dataset

Access request in an Attribute-Based access control system is consisted of
both subject (requestor) and object (resource) attributes, as well as a set of
attributes related to the context of the request, namely environmental
attributes. The aforementioned attribute sets vary between each individual
case and will be set during the implementation process, depending of each host
requirements.

**Table 6: Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**ABAC**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Subject Attributes._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Object attributes_

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Environmental Attributes._

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Access Decision_

</td> </tr> </table>

Information concerning the ABAC dataset is given in the following matrix.  
  
<table>  
<tr>  
<th>

**Dataset name <DS.UoM.ABAC> **

</th> </tr>  
<tr>  
<td>

**Metadata and standards**

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_ABAC Dataset_

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which**

**device)**

</td>  
<td>

_Data transmitted from requestor or sensed from the module itself._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

_Metadata information about an attribute in an ABAC implementation can be kept
allowing for a party to obtain greater understanding of how the attribute and
its value were obtained, determined, and vetted and provide more effective
policy creation and application. Metadata do not concern the individual or the
entity itself but the attribute only._

</td> </tr>  
<tr>  
<td>

**Standards, format, estimated volume of data**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Partners’ activities and responsibilities**

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_UoM_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data storage, backups**

</td>  
<td>

**including**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

**Data access, sharing and reuse**

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

</td>  
<td>

_The data will be used to evaluate decision access for a subject over a
resource in certain time. Record in terms of auditing might be kept._

</td> </tr>  
<tr>  
<td>

**Data access**

**dissemination**

**(confidential,**

**members of the consortium and the commission services, public)**

</td>  
<td>

**policy/ level only for**

</td>  
<td>

_The full dataset will be confidential and only the members participating in
the deployment will have access on it. There is no intention on publishing
these data._

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and**

**distribution**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_-_

</td> </tr> </table>

###  NEXTEL Dataset

This dataset will describe Risk Assessment data set. The following table
describe a set of files or metadata containing the following information.

**Table 7: Risk Assessment Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**Risk Assessment**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Assets inventory_

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Threats catalogue_

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Vulnerability reports_

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Security effectiveness for running security controls_

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_User directory_

</td> </tr>  
<tr>  
<td>

**6**

</td>  
<td>

_Security Policy_

</td> </tr> </table>

Detailed information for risk assessment dataset required  
  
<table>  
<tr>  
<th>

**Dataset name <DS.NEXTEL.RA> **

</th> </tr>  
<tr>  
<td>

**Metadata and standards**

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_The dataset will support and characterize a process for risk assessment._

</td> </tr> </table>  
<table>  
<tr>  
<th>

</th>  
<th>

</th> </tr>  
<tr>  
<td>

**Data source (i.e. which**

**device)**

</td>  
<td>

_Source of data will come from typical characterization for SMEs
environments._

_Concrete data source will be collected during pilot._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

_The content of metadata includes chat messages, timestamps and categorical
data. These data can be used in order to categorize a dialogue and infer about
social engineering attempts._

</td> </tr>  
<tr>  
<td>

**Standards, format, estimated volume of data**

</td>  
<td>

_Different formats for data. Standard storage on relational databases._

</td> </tr>  
<tr>  
<td>

**Partners’ activities and responsibilities**

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_SME or final use case partner. Finally, this point depends on FORTIKA license
typology. Device in FORTIKA context means FORTIKA accelerator or also named
FORTIKA gateway._

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_Data will be collected by SMEs or use cases, where assessment need to be
done._

_Nextel while implementing/developing the service in testing and development
phase need to be in charge of data collection using different components of
the FORTIKA solution._

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

</td>  
<td>

_Data storage responsibility will be in charge of the partner where risk
assessment will be conducted. Typically use cases partners. It is supposed
FORTIKA gateway could provide storage space._

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data storage, backups**

</td>  
<td>

**including**

</td>  
<td>

_This is also dependant on the exploitation. In a first approach data storage
will be responsible for use case partner or SME using FORTIKA gateway._

_In a second approach a maintenance service over this gateway could be
implemented._

</td> </tr>  
<tr>  
<td>

</td>  
<td>

**Data access, sharing and reuse**

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

</td>  
<td>

_Contribute to risk assessment service_

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission services, public)**

</td>  
<td>

_Confidential, only for members of the consortium_

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and**

**distribution**

</td>  
<td>

_Open to re-use and distribution inside the consortium_

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_-_

</td> </tr> </table>

###  FINT Dataset

This dataset will describe FORTIKA’s GW monitoring service data set. The
following table describe a set of files or metadata containing the following
information.

**Table 8: FORTIKA GW Monitoring Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**Monitoring**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_System monitor_

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Services status_

</td> </tr> </table>  
<table>  
<tr>  
<th>

**Dataset name <DS.FINT.MS> **

</th> </tr>  
<tr>  
<td>

**Metadata and standards**

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_The dataset will characterise the FORTIKA’s GW system and deployed services
statuses._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which**

**device)**

</td>  
<td>

_Source of data will come from the GW’s hardware and software components (OS
and applications)._

</td> </tr>  
<tr>  
<td>

**Information about metadata (Production and storage dates, places) and**

**documentation**

</td>  
<td>

_The content of metadata includes timestamps, numerical and categorical data.
These data can be used for assessing and reporting the performance and health
status of the FORTIKA GW._

</td> </tr>  
<tr>  
<td>

**Standards, format, estimated volume of data**

</td>  
<td>

_Different formats for data. Standard storage on a document database._

</td> </tr>  
<tr>  
<td>

**Partners’ activities and responsibilities**

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_SME or final use case partner. Finally, this point depends on FORTIKA license
typology. Device in FORTIKA context means FORTIKA accelerator or also named
FORTIKA gateway._

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_Data will be collected by SMEs or use cases, where assessment need to be
done._

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_Data storage responsibility will be of the GW owner (typically SME or use
case partners)_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_Data storage will be responsible for use case partner or SME using FORTIKA
gateway._

</td> </tr>  
<tr>  
<td>

**Data access, sharing and reuse**

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_Contribute to FORTIKA GW’s performance monitoring and assessment_

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission services, public)**

</td>  
<td>

_Confidential, only for members of the consortium_

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and**

**distribution**

</td>  
<td>

_Open to re-use and distribution inside the consortium_

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_-_

</td> </tr> </table>

###  CERTH Datasets

In this subsection datasets containing information of known threats are given.

Spam e-mails is a form of commercial advertising. Since this form of
advertising is not costly, spammers harvest recipient addresses from publicly
accessible sources, by using programs to collect addresses on the web, and
send massively advertisement e-mails. Spammers often hide the origin of their
messages in order to circumvent anti-spammer lists used by antispam software.
Nowadays more than 95% of e-mail messages sent worldwide is believed to be
spam. The characteristics of the FORTIKA dataset for spam e-mails are given in
the following matrix.

**Table 9: Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**Spam e-mails**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Country._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Autonomous system (AS)._

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Date of creation._

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Owner (sender)._

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_Recipient._

</td> </tr>  
<tr>  
<td>

**6**

</td>  
<td>

_Text._

</td> </tr> </table>

Phishing e-mails are designed to deceive users to install malicious software
on their computer or to hand over personal information under false pretences.
Cybercriminals usually send such e-mails pretending to be a professional
company or organization. Such emails may contain hyper-links which are linked
to malicious sites or to malicious .exe files. Also, such e-mails are very
common to ask for account passwords on the excuse of a security breach. The
characteristics of the FORTIKA dataset for phishing e-mails are given in the
following matrix.

**Table 10: Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**Phishing e-mails**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Country._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Autonomous system (AS)._

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Date of creation._

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Owner (sender)._

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_Recipient._

</td> </tr>  
<tr>  
<td>

**6**

</td>  
<td>

_Text._

</td> </tr> </table>

Malicious URLs may be sent through e-mails in order to install some malicious
software to users’ computers. The characteristics of the FORTIKA dataset for
malicious URLs are given in the following matrix.

**Table 11: Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**Malicious URLs**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Country._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Autonomous system (AS)._

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Date of creation._

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Owner (sender)._

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_HTML content._

</td> </tr>  
<tr>  
<td>

**6**

</td>  
<td>

_First level neighbours._

</td> </tr> </table>

Messages which may contain malicious links or software can not only be sent by
e-mails, but from various applications (e.g. facebook, twitter, viber, etc.).
The characteristics of the FORTIKA dataset for malicious messages are given in
the following matrix. **Table 12: Dataset Characteristics**  
  
<table>  
<tr>  
<th>

_**#** _

</th>  
<th>

**Messages**

</th> </tr>  
<tr>  
<td>

**1**

</td>  
<td>

_Application used._

</td> </tr>  
<tr>  
<td>

**2**

</td>  
<td>

_Time._

</td> </tr>  
<tr>  
<td>

**3**

</td>  
<td>

_Sender._

</td> </tr>  
<tr>  
<td>

**4**

</td>  
<td>

_Recipient._

</td> </tr>  
<tr>  
<td>

**5**

</td>  
<td>

_Text._

</td> </tr>  
<tr>  
<td>

**6**

</td>  
<td>

_Data type (e.g. media)._

</td> </tr> </table>

Information concerning the threat datasets is given in the following matrix.  
  
<table>  
<tr>  
<th>

**Dataset name <DS. ** **CERTH.Threats > **

</th> </tr>  
<tr>  
<td>

**Metadata and standards**

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

_Known Threats._

</td> </tr>  
<tr>  
<td>

**Data source (i.e. which**

**device)**

</td>  
<td>

_Data will be collected from available information of the web._

</td> </tr>  
<tr>  
<td>

**Information about metadata**

</td>  
<td>

_Information concerning identical e-mails that were sent to_

</td> </tr>  
<tr>  
<td>

**(Production and storage dates, places) and**

**documentation**

</td>  
<td>

_multiple users (e.g. spam/phishing e-mails) can be used in order to detect
such malicious mails. These data can be used in order to visualize such
abnormalities, while senders of such emails can be detected._

</td> </tr>  
<tr>  
<td>

**Standards, format, estimated volume of data**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Partners’ activities and responsibilities**

</td> </tr>  
<tr>  
<td>

**Device owner**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data collection**

</td>  
<td>

_CERTH_

</td> </tr>  
<tr>  
<td>

**Partner in charge of data storage**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

</td>  
<td>

</td> </tr>  
<tr>  
<td>

**Data storage, including backups**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Data access, sharing and reuse**

</td> </tr>  
<tr>  
<td>

**Data exploitation**

</td>  
<td>

_The data will be used to visualize abnormalities and detect cyber security
threats._

</td> </tr>  
<tr>  
<td>

**Data access policy/ dissemination level (confidential, only for members of
the consortium and the commission services, public)**

</td>  
<td>

_The full dataset will be confidential and only the members participating in
the deployment and/or the consortium will have access on it. Furthermore, if
the dataset or specific portions of it (e.g. metadata, statistics, etc.) are
decided to become of widely open access, it will be uploaded to the FORTIKA
open data platform. Of course, these data will be anonymized, in order to
avoid any potential ethical issues with their publication and dissemination_

</td> </tr>  
<tr>  
<td>

**Data sharing, re-use and**

**distribution**

</td>  
<td>

_-_

</td> </tr>  
<tr>  
<td>

**Embargo periods (if any)**

</td>  
<td>

_-_

</td> </tr> </table>

##  Data as used for evaluation in FORTIKA

The visualization of threats is expected to play a significant role in the
evaluation of FORTIKA. CERTH is contributing to the visualization of anomaly
detection and clustering of network entities. Visualization tools have been
developed for visual detection of anomalies regarding messages sent between
mobile phones, and for tracking frequently referenced key words on Twitter.

Visual clustering of mobile phones according to desired characteristics, such
as which mobile phones send messages in a similar way (similar frequency), is
achieved by using graph-based multimodal visualization methodologies, either
based on k-partite graphs or minimum spanning trees. The number of sent
messages through time can be also visualized, in order to track anomalies such
as increased number of sent messages during the night. The visualizations are
backed by outlier detection and clustering methods. This tool can contribute
significantly to the visualization of anomalies in various types of networks.

The above tool has also been adapted for the visualization of frequently
referenced words on Twitter. By tracking frequently referenced words, possible
threads can be detected, thus the adapted tool can be also used for the
visualization of anomaly detection of networks.

Adaptations of the aforementioned tools will be performed in order to
visualize other types of threats as well.

##  Self-audit process

Herein the self-audit process and the way it is expected to be implemented in
FORTIKA project are discussed. The process that every dataset in FORTIKA will
follow to assess the compliance of the DMP is shown in Figure 2. The initial
steps concern to the concepts around the data sets that will be generated,
registered and published in FORTIKA. In this self-audit process the definition
and any practical pre-validation, post validation, certification and selfaudit
will be defined as part of the Deployment Site Strategy but will be aligned
with the FORTIKA project overall strategy. Self-audit activities will be
described and the result of their implementation as part of Deployment site
quality control measurements. Figure 2 is used to represent and describe the
logic flow of the process for self-audits in FORTIKA.

**Figure 2: FORTIKA’s Self-Audit Flow Diagram.**

The FORTIKA project has a selected group of experts acting as steward of the
project, who will also support the activity and execution of self-audits to
the data that will be collected, managed and provided at the different
deployment sites. FORTIKA self-audit process will aim at effectively managing
data and identifying its potential, conditions and value of its data assets.
Conducting a data self-audit will provide valuable information, raising
awareness of collection strengths and data issues to improve overall strategy.
A data self-audit will highlight duplication of effort and areas that require
additional investment, allowing putting its resources to best use. It is most
importantly for highlighting inadequacies in data creation and curation
practices, suggesting policy change to lessen the risks. An organisation that
is knowledgeable about its data puts itself in a position to maximize the
value of its collections through continued use. The implementation of a self-
audit methodology envisages to bring benefits like the _prioritisation of
data_ _resources which leads to efficiency savings and the_ _ability to manage
risks associated with data loss and irretrievability_ _._

The self-audit process in FORTIKA follows an effective way to guarantee
consistency in the data, a controlled process and the best methodologies at
the different FORTIKA levels, i.e. Device, Platform and Application. The
following is the list of additional activities that are overseen in order to
execute the self-audit process:

  * Planning 

    * Plan and Set-up the Self-Audit 

  

    * Collect Relevant Documents 

  

  

  * Identification, Classification and Assessment of Datasets 

    * Analyse Documents 

  

    * Identify Data Sets 

  

    * Classify Data Sets 

  

    * Assess Data Sets 

  

  

  * Report of Results and Recommendations 

    * Collate and analyse information from the audit 

  

    * Report on the compliance with the Data Management Plan 

  

    * Identify weaknesses and decide on corrective actions 

  

  

**Figure 3: FORTIKA’s Self-Audit Process.**

##  Considerations for Linked data

The term Linked Data refers to a set of best practices for publishing and
interlinking structured data on the Web. These best practices were introduced
by Tim Berners-Lee in his Web architecture note Linked Data [1], and have
become known as the Linked Data principles. Such practices may be proved
useful during the development of FORTIKA.

Until recently the landscape of data on the Web was comprised of a plethora of
selfcontained data repositories. Basically, each Web application or platform
maintained its own repository, even if there was a significant overlap between
these datasets and data that was publicly accessible. From a knowledge and
information retrieval perspective, however, the integration of different kinds
of data sources yields significant added value. The use of different formats
and different technologies made such an integration challenging in the past.

These challenges spurred the development and success of the concept of Linked
Data. This concept describes a method of publishing not only documents but
also all kinds of structured data so that it can be interlinked and become
more useful. It builds upon standard Web technologies such as HTTP and URIs
(Uniform Resource Identifier), but rather than using them to serve web pages
for human readers, it extends them to share information in a way suitable for
reading them automatically by computers. This enables data from different
sources to be connected and queried. These principles listed below:  **URIs
and name identification**

This principle advocates using URI references to all things, i.e. extending
the scope of the Web from online resources to encompass any object or concept
in the world. Thus, things are not just Web documents and digital content, but
also real world objects and abstract concepts. These may include tangible
things such as people, places and cars, or those that are more abstract, such
as the relationship type of knowing somebody, the set of all green cars in the
world, or the colour green itself.

To publish data on the Web, the things need to be uniquely identified. As
Linked Data builds directly on the Web architecture, the Web architecture term
resource is used to refer to these things of interest, which are, in turn,
identified by HTTP URIs. Linked Data uses only

HTTP URIs, avoiding other URI schemes such as Uniform Resource Names (  URN)
and Digital Object Identifier (  DOI)  . The benefits of HTTP URIs are: (a)
they provide a simple way to create globally unique names in a decentralized
fashion, and (b) they serve not just as a name but also as a means of
accessing information describing the identified entity.  **HTTP and URIs**

The HTTP protocol is the Web’s universal access mechanism. In the classic Web,
HTTP URIs are used to combine globally unique identification with a simple,
well-understood retrieval mechanism. Thus, this Linked Data principle
advocates the use of HTTP URIs to identify objects and abstract concepts,
enabling these URIs to be dereferenced (i.e., looked up) over the HTTP
protocol to obtain a description of the identified object or concept. As a
result, any HTTP client can look up the URI using the HTTP protocol and
retrieve a description of the resource that is identified by the URI. This
applies to URIs that are used to identify classic HTML documents, as well as
URIs that are used in the Linked Data context to identify realworld objects
and abstract concepts.

  * **Including links to other URIs**

  

In order to enable a wide range of different applications to process Web
content, it is important to agree on standardised content formats. The
agreement on HTML as a dominant document format was an important factor that
made the Web scale. The third Linked Data principle therefore advocates use of
a single data model for publishing structured data on the Web – the Resource
Description Framework (RDF).

RDF provides a graph-based data model that is extremely simple on the one hand
but strictly tailored towards Web architecture on the other hand. RDF itself
is just describing the data model, it does not address the format in which the
data is eventually stored and transferred. To be published on the Web, RDF
data can be serialised in different formats. The two RDF serialisation formats
most commonly used to publish Linked Data on the Web are RDF/XML and RDFa.

  * **Querying linked data**

  

_SPARQL_ (SPARQL Protocol and RDF Query Language) is the most popular query
language to retrieve and manipulate data stored in RDF, and it became an
official W3C Recommendation in 2008. Depending on the purpose, SPARQL
distinguishes the following for query variations:

  * SELECT query: extraction of (raw) information from the data 

  

  * CONSTRUCT query: extraction of information and transformation into RDF 

  

  * ASK query: extraction of information resulting in a True/False answer 

  

  * DESCRIBE query: extraction of RDF graph that describes the resources found 

  

Given that RDF forms a directed, labelled graph for representing information,
the most basic construct of a SPARQL query is a so-called basic graph pattern.
Such a pattern is very similar to a RDF triple with the exception that the
subject, predicate or object may be a variable. A basic graph pattern matches
a sub graph of the RDF data when RDF terms from that sub graph may be
substituted for the variables and the result is RDF graph equivalent to the
sub graph. Using the same identifier for variables also allow combining
multiple graph patterns.

###  Storage, maintenance & Sharing of the data

Datasets will be released as agreed between partners, anonymised and in
accordance to GDPR, when available.

#  Conclusion

The Data Management Life Cycle (DMLC) of the FORTIKA project has been
designed, introduced and described within this document following a data
centric approach. It describes all the process for data creation, data
storage, data processing, data security, across the data value chain from
Deployment Sites operations to making data openly accessible.

The purpose of the FORTIKA DMP is to support the data management life cycle
for all data that will be generated, collected, and processed by the FORTIKA
project in the different deployment sites and in the FORTIKA system.

This deliverable renders the 1  st  version of the Data Management Plan and it
will remain a living document during the whole lifespan of the FORTIKA
project. This document is expected to further mature during the phase of
architecture/building FORTIKA and when the requirements collection phase will
be finalized. A 2  nd  version will be distributed was part of the 3  rd  PMR,
while the final version of the DMP in M36 shall include the update(s)
concerning the outcomes of above mentioned activities.