Skip to main content

Part 3 – Secure data sharing step by step

4 Secure data sharing

This section discusses how to achieve data security in the context of data sharing. Here, the two dimensions of data sharing building blocks and data security aspects are combined. For each data sharing building block, we show which security aspects are applicable and we present a list of security recommendations based on these aspects.

To further elaborate on how each recommendation should be implemented, this section contains a matrix with the mapping between the previously presented recommendations and security controls specified by ISO, ENISA, BSIGSK, and OWASP. The controls specify the practical measures that should be considered for implementing the stated recommendations. Therefore, they give specific guidance on what needs to be done, and/or considered, during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

Finally, each data sharing building block sub-section contains a checklist that provides a series of questions that should be considered in order to ensure security in the context of each respective building block.

 

4.1 Data storage

The first building block in a data-sharing scenario is the storing of the actual data. Quite a few considerations need to be made regarding the storage of data that need to be shared. The first consideration is that data has different types of value for the organization that owns it and, given that storage solutions come at a cost, a cost-benefit analysis needs to be conducted. Apart from the business value of the data, sensitivity is an aspect that needs to be addressed. Financial records and trade secrets are inherently more sensitive than e.g. promotional material – and, therefore, need to be stored with the according access and use permissions.

In addition to the value of data, compliance with data retention regulations is often a requirement. In such cases, the data storage solution needs to be adequate in terms of long-term storage capability and redundancy.

Many organizations opt into procuring a cloud service for their main data storage instead of their local infrastructure. While this is a viable approach, given that the cloud service provider offers adequate redundancy, it comes with the risk of losing the full control of the data and, in cases where the data is neither encrypted in transit nor at rest, unauthorized access to the data by the provider is likely. There are also scenarios where regulations do not allow the data to be stored off-premises or even in different regions, although in EU the regulation of free flow for non-personal data establishes that there are no data localization restrictions with a few exceptions.

Regardless of the chosen storage solution, and depending on the type of data, an access control mechanism needs to be deployed either on the sharing platform or on the storage solution itself and, preferably, the data needs to be stored in an encrypted form.

Security recommendations on data storage
 

To ensure proper data storage security, the responsible practitioners should make certain that the following measures are taken:

  • R-101 – When designing the architecture of the data storage subsystems, the required security mechanisms should be taken into account from the start of the design process. The “security by design” approach should be part of this process.
  • R-102 – Since the security mechanisms that should be built in and around the storage subsystems come at a cost, there should be alternative solutions that can fulfil the security requirements at lower costs. The trade-off will usually come as lack of usability, difficulty in maintenance, or smaller long-term integrity guaranties. It should be noted that for long term storage systems, integrity is a high priority requirement.
  • R-105 – Apart from the security design, the operational and maintenance procedures of the storage subsystems and the stored data should be clearly defined as part of the full security management plan.
  • R-106 – The security mechanisms to be deployed with the storage subsystem should be selected according to the security requirements of the system and not follow a one-size-fits-all approach. Depending on the sensitivity of the data in terms of secrecy, value, and availability, the security mechanisms should be chosen accordingly. For example, for high availability of non-confidential data, a cloud storage solution behind a CDN is sufficient. For scenarios which involve processing of medical data, the solution should be housed on-premise and all processing should be done within the organization itself.
  • R-201 – There are a multitude of local or cloud storage solutions, most of which come with their own standard security mechanisms. Those mechanisms should, after careful evaluation, be prioritised. Introducing custom-made mechanisms which have not been subjected to rigorous integration tests should be avoided. In general, the offered security mechanisms of a storage solution should play a prominent part in the evaluation of the solution itself and, given the adoption of the solution, should be used as directed.
  • R-203 – Almost all storage solutions offer some form of access control. The default configuration of the access control at the storage level should follow the deny-by-default and least privilege approach. In the case where user access control is performed at application level, the data storage services should only be accessible by explicitly configured applications.
  • R-204 – Every user account in the database should be assigned roles that allow the minimum required access to the data. Generally, users should not have direct database accounts. The applications that have access to the database should not use administrator accounts.
  • R-207 – Database and storage solutions are shipped with a minimum default configuration that includes default administrator accounts and default network configuration. The default configuration needs to be changed before the system goes into production.
  • R-209 – Configuration of the storage subsystem as well as deployment of databases and their schemas should be documented on both operation and application levels. This ensures that there are no forgotten or misconfigured databases and/or API endpoints that could be used as a vector for a data breach.
  • R-401 – Access to the stored data is governed by the deployed access control mechanism and the security policy in effect. This policy should be communicated clearly to anyone that has any kind of access to data and should be followed accordingly.
  • R-403 – One probable breach vector for data centres and/or subsystems are maintenance windows. In terms of availability, maintenance should not result in complete loss of data access, especially without prior configuration of application servers (i.e. the usual systems that have direct access to the data subsystem) to use redundant databases. In terms of confidentiality, old and broken hard disks could be used by malicious entities to access insecurely deleted data. The maintenance personnel - especially if they belong to external vendors - should not perform any kind of datacentre work unsupervised.
  • R-603 – Apart from data centres, personal or confidential data can also exist in individual employee workstations. Even if there is no provision for long term storage of data in a workstation, caching could create temporary copies. Therefore, the workstation should be password-protected and unattended workstations should be locked automatically.
  • R-604 – The strictness of the security mechanisms and policies for the stored data should be equivalent to their value and sensitivity.
Applicable Controls
 

The controls specify the practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. The controls are on the horizontal axis (blue shade) and the requirements on the vertical axis (yellow shade).

Table 1: Data Storage: Relationship between the identified IT-security recommendations and the available controls

As shown in Table 1, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Operational planning and control - [ISO27001] chapter 8.1
  • Information access restriction - [ISO27002] control 9.4.1
  • Classification of information - [ISO27002] control 8.2.1
  • Policy on the use of cryptographic controls - [ISO27002] control 10.1.1
  • Information backup - [ISO27002] control 12.3.1
  • Event logging - [ISO27002] control 12.4.1
  • Development of a cryptographic concept - [BSIGSK] M 2.161
  • Selection of a suitable cryptographic procedure - [BSIGSK] M 2.162
  • Files and records encryption - [ENISA1] chapter 7.2.3
  • Storage encryption - [ENISA1] chapter 7.2.4
  • Access control policy - [ENISA2] – chapter 4.1.1.3
  • Security of data at rest - [ENISA2] chapter 4.2.3
  • Back-ups - [ENISA2] chapter 4.2.5
  • Data deletion/disposal - [ENISA2] chapter 4.2.8
  • Disaster recovery capabilities - [ENISA3] SO18
  • Monitoring and logging - [ENISA3] SO19
  • Security of data at rest - [ENISA3] SO23
  • Privacy in databases - [ENISA4] chapter 4.5
  • Local encrypted storage - [ENISA4] chapter 4.9.2
  • Secure remote storage - [ENISA4] chapter 4.9.4
  • Stored cryptography verification requirements – [OWASP_ASVS] V6
  • File and resources verification requirements - [OWASP_ASVS] V12
  • Principle of Least privilege - [OWASP_SDP]chapter 5.3
Practical checklist
 

The following checklist provides a series of questions and considerations that should be taken into account to ensure secure data storage in data sharing scenarios. These are based on the previously cited requirements as well as the respective recommendations and controls.

Does the storage subsystem provide redundancy against data loss?

 

Does the storage subsystem provide redundancy for data availability?

 

Is the confidential data encrypted at rest?

 

Is all communication with databases and storage subsystem encrypted?

 

Is network access of the storage subsystem protected by firewall?

 

Is there a defined back-up procedure and solution as part of the security management plan?

 

Is authenticated access to the storage subsystem allowed to the smallest number of users?

 

Do all storage endpoints and database access endpoints require authenticated access?

 

Are vendor-specific storage security mechanisms configured properly?

 

Are all default passwords, accounts and configurations removed or updated?

 

Is workstation access authenticated?

 

Are workstations full-disk encrypted?

 

Are all user accounts in the databases accounted for and documented?

 

Are maintenance procedures documented as part of the security management plan?

 

Do storage maintenance procedures mandate supervised-only access to maintenance personnel?

 

Does the storage subsystem provide sufficient security mechanisms?

 

Is physical security of the storage subsystem ensured?

 

Is access to the storage subsystem monitored?

 

Does the storage subsystem allow traceability of changes?

 

 

4.2 Ownership or control over data

It is often desirable or mandatory to be able to verify the integrity of the shared datasets. When there is a reasonable concern that the shared data can be tampered with, the recipient needs to be able to verify that the datasets are the ones that the owner or the holder of the data intended to share.

Electronic signatures and seals are the most common security solutions for this problem. The eIDAS [eIDAS] regulation defines the framework and the requirements for electronic transactions which include the notion of data sharing. There are also initiatives like MyData[1] that act complementary to electronic IDs by allowing individuals to control the usage and sharing restrictions of their personal data.

Another concern is the intellectual property rights of the shared data, especially in cases where the sharing organisation does not own the entire dataset. Similar to the distribution of software source code, any dataset could contain information defining what is allowed to be used but what is not allowed to be shared or distributed. Therefore, each dataset needs to be checked for third-party material. Additionally, it must be clarified whether the licence for this material allows further distribution.

One last consideration, which is particularly relevant to the environments of the data markets, is the data provenance capabilities of the employed sharing environments or platforms. It is often desirable to have the ability to trace-back the origin and all the predecessors of a dataset and track changes to datasets and documents. Electronic signatures offer a partial solution. However, when dealing with intermediate analysis results as part of the original dataset, more strict data-sharing platforms, that are able to regulate the flow of information between entities, are required.

Security recommendations on ownership or control over data
 

To ensure a proper data storage security, the responsible practitioners should make certain that the following measures are taken:

  • R-105– A full security management plan should include procedures for the proper digital signing of outgoing data, either via the organization’s sharing services and portal or via direct exchange of data between individuals. Apart from the signatures, IPR information and any applicable licences should accompany the data whenever necessary. This should be explicitly specified in the security management plan.
  • R-303– The data that is made accessible to external entities should contain proper identifiers denoting the ownership, intellectual property rights, and applicable licence. Its authenticity should also be verifiable. This additional information should be added as accompanying metadata and its authenticity and ownership should be attested via digital signatures.
  • R-401– Since the exchange of data often takes place directly between individuals (for example via email), the mandatory signing of data should be an explicit part of the organization’s security policy and should be followed by the individuals.
  • R-601 & R-605– The security policy regarding signing outgoing data and adding applicable licences should be properly documented. The policy should describe the signing procedure and contain an explicit enumeration on the types of data that can be excluded from the procedure. It should also contain the contact details of the responsible individual for licence information and intellectual property rights.
  • R-604– There are always categories of data that do not have to follow the security policy. Those exceptions are documented in the policy, and for those exceptions the security mechanisms and procedures are much more relaxed. In general, the level of protection depends on the sensitivity and value of the data.
Applicable Controls
 

The controls specify the practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. Controls are in the horizontal axis (blue shade) and requirements in the vertical axis (yellow shade).

Table 2: Ownership: Relationship between the identified IT-security recommendations and the available controls

As shown in Table 2, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Operational planning and control - [ISO27001] chapter 8.1
  • Documented information - [ISO27001] chapter 7.5
  • Information security in project management - [ISO27002] control 6.1.5
  • Classification of information - [ISO27002] control 8.2.1
  • Identification of applicable legislation and contractual requirements – [ISO27002] control 18.1.1
  • Intellectual property rights - [ISO27002] control 18.1.2
  • Personal data breach notification - [ENISA1] chapter 5.2.2
  • Security obligations in GDPR - [ENISA2] chapter 2.3.1
  • Interoperability and portability - [ENISA3] SO26
  • Attribute based credentials - [ENISA4] chapter 4.2
  • Intervenability-enhancing techniques - [ENISA4] chapter 4.12
Practical checklist
 

The following checklist provides a series of questions and considerations that should be taken into account to ensure proper ownership in data sharing scenarios. These are based on the previously cited requirements as well as the respective recommendations and controls.

Do all organization individuals have a digital signature?

 

Are all available datasets signed by the owning organization?

 

Do all available datasets contain accompanying owner information as well as licence and IPR information?

 

Is mandatory data and email signing part of the security policy?

 

Are the types of data that are excluded from the mandatory signing explicitly enumerated?

 

Are provisions of transferring control over data documented in the licence or accompanying ownership information?

 

Is there a defined incident response/data breach procedure?

 

Is there an impact assessment for the loss/publication of confidential data?

 

 

4.3 Anonymization

Sometimes the data to be shared contains personal or confidential information. In these cases, it needs to be checked whether the owner of the data has the right to share those parts of the data or whether those parts need to be removed or masked in some way. This is called data anonymization.

Personal or confidential information in this context usually refers to the following types

  • Personal data such as names, addresses, id numbers
  • Financial or other sensitive data on natural persons or legal entities
  • Identifiers and data that can lead back, by aggregation, to the true identity of an individual such as an IP address in combination with a timestamp
  • Special categories of personal data such as “personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, ... genetic data, biometric data ...[that] uniquely identify... a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation” as per Article 9[2] of the GDPR.

The simplest course of action is to remove these fields from the data before publication. There are cases though where the simple removal results in the loss of utility and value of the data up to a point where sharing is no longer desirable. Therefore, various approaches to anonymize data exist, depending on the intended usage scenario. The most common approaches are:

  • Redaction: This is the simplest of all the approaches. In redaction, the relevant fields are simply deleted from the data. This approach is valid for scenarios where the rest of the data hold the actual value for the external entity and the personal or confidential data are just unneeded parts of the initial dataset.
  • Pseudonymization: In this approach, the relevant data are being converted to random strings but there is still a correlation between the initial and resulting values. This can be achieved, for example, via hash functions without salting. This approach is useful to scenarios where the shared data needs to be analysed against the relevant fields without having access to the real values of those fields. One common example is network traffic analysis.
  • Generalization (k-anonymity): Generalization is a similar approach to pseudonymization. In generalization, a portion of the relevant fields is removed and replaced by common values. For example, replacing all the phone numbers by the same sequence of numbers while keeping the area codes intact. This approach is most often implemented by using the method of k-anonymity, a technique for hiding the identity of individuals in equally sized groups of similar people or data points[3].
  • Differential privacy: For differential privacy, noise is added in response to specific queries on the respective data. Noise can be added by altering the values of the personal or confidential data and by adding random values to them (e.g. rounding). So, different from k-anonymity (and the other methods described before), differential privacy does not create one single, “static” view on the anonymised data set, but the anonymisation is effectively adapted in response to every query on the data. This makes it difficult to assert whether an individual or entity is part of the dataset while keeping the utility and value of the dataset relatively high.

It is important to stress that the appropriateness of each approach is dictated by the type of data and the regulations that are applicable to these types. There are scenarios where a heavy redaction of the relevant fields is the only alternative regardless of the resulting loss of value to the dataset.

Security recommendations on anonymization
 

To ensure proper anonymization responsible practitioners should make certain that the following measures are taken:

  • R-102 & R-106 & R-604– Depending on the type of data that needs to be anonymized and the usage scenario of this data, there are many anonymization approaches to be considered. An overview of the different approaches, such as tabular data protection, query perturbation, and k-Anonymity, can be found in [ENISA4] chapter 4.6.
  • R-203 & R-303– Regardless of the anonymization approach the amount of information an external entity is allowed to access should be kept to the minimum. This applies not only to the access allowed to the datasets but also to the level of aggregation of the data available for processing.
  • R-204– There should be preconfigured anonymization rules for each available user role; especially for roles assigned to external individuals. This allows for fine-grained control on the field and property level for each dataset. The rules should be designed following the approach of providing the highest usable level of aggregation by default. Only when explicitly needed, should a user or group have more detailed access to data.
  • R-209– The anonymization rules, as well as any dataset specific configuration, should be documented and kept together with the rest of the system documentation for easy reference and audit. The documentation should be kept up to date.
  • R-406– Anonymization is one of the important security objectives of an organization intending to share personal or confidential data. Therefore, security audits should include checks on the state of outgoing data by monitoring either the logs (automatic anonymization) or the data itself (manual anonymization).
Applicable Controls
 

The controls specify practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. The controls are in the horizontal axis (blue shade) and the requirements in the vertical axis (yellow shade).

Table 4: Anonymization: Relationship between the identified IT security recommendations and controls

As shown in Table 4, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Identification of applicable legislation and contractual requirements - [ISO27002] chapter 18.1.1
  • Privacy and protection of personally identifiable information - [ISO27002] chapter 18.1.4
  • Security risk management for the processing of personal data - [ENISA2] chapter 2.3.2
  • Eight privacy design strategies - [ENISA4] chapter 3.2
  • Technologies for respondent privacy: statistical disclosure control - [ENISA4] chapter 4.6
  • Privacy-preserving data mining for data-hiding - [ENISA4] chapter 4.7.1
  • Limits of privacy by design - [ENISA4] chapter 5.1
  • Data classification - [OWASP_ASVS] V6.1
Practical checklist
 

The following checklist provides a series of questions and considerations that should be taken into account to ensure proper anonymization in data sharing scenarios. These are based on the previously cited requirements as well as on the respective recommendations and controls.

Have datasets that contain personal or confidential data and require anonymization been identified?

 

Is there a defined anonymization procedure for each type of data?

 

Are there pre-configured anonymization rules for each type of data?

 

Are there pre-configured anonymization rules for each user role? (for data requestors)

 

Are anonymization rules documented as part of the full security management plan?

 

Are checks on the state of outgoing data (in terms of anonymization) part of regular audit plans?

 

Do both manual and automatic anonymization procedures follow GDPR regulations?

 

Are all publicly available datasets anonymized accordingly?

 

 

4.4 Ethics checks

In some cases, shared datasets contain personal information. For example, if research requires obtaining data from people, the organizations involved are expected to maintain high ethical standards such as those recommended by professional bodies, institutions and funding organisations, both during processing and sharing. Datasets, even when they contain personal or confidential data, can be shared ethically and legally as long as the organization pays enough attention to the following important aspects:

  • The persons’ identity must be protected (this is required almost in every case).
  • The provision for data sharing must be included while gaining informed consent.
  • The controlled access to the shared data should be taken into consideration.

These measures should be considered even when data sharing is not planned.

Data collected from and about people could contain personal or confidential information. However, this does not mean that all the data collected this way is personal or confidential.

The particular strategy for handling the confidentiality strongly depends on the nature of the corresponding processing of the data. In any case, the strategy must reflect the organization’s ethical and legal obligations, for which the fundamental framework is the [GDPR]. Depending on where the organization that plans to collect, process and store the data is located, some national regulations may have to be considered in addition to the GDPR. In Germany, for instance, the national regulation to be obeyed is [BDSG].

In order to be compliant to the above regulation framework, the organizations are expected to have sought and received the informed consent from the individuals whose data was collected. The consent should also, as much as possible, take into account the future uses of data. This could be for instance:

  • Sharing the collected data.
  • Sharing of analytical results based on this data.
  • Preservation of the data and their usage for a long term.

The consent should at least permit data sharing as well as deletion of the data which is no longer required. The organisations are obliged to at least:

  • Keep the participants whose data is/has been collected informed on the modalities used to maintain the confidentiality,
  • inform the participants how the collected data will be stored, processed and used in the long term, and
  • gain written informed consent for the sharing of data (in some cases a verbal consent could also be sufficient, see below).

The most important aspect of the consent is its existence. For this purpose, there has to be an active communication between the parties. The consent has to be given freely and contain sufficient information on all aspects of the intended collection and planned data usage.

In case of detailed interviews or research, where personal data are collected, the following aspects should be taken into consideration:

  • Written consent is recommended (compliance with [GDPR]).
  • Consent should be clearly stated in the form of an information sheet signed by the participants.
  • Alternatively, a verbal consent agreement could be audio or video recorded.

If the information to be collected does not relate to personal data, or personal identifiers are removed from the data, written consent may not be required. Nevertheless, research participants have to be informed on the detailed nature and scope of the research, the identity of the researcher and on the potential handling of the collected data (including any intended action on data sharing).

Other aspects of the consent are the one-off and process consent approaches:

  • One-off: Simple and practical approach that avoids multiple requests to participants and assures the compliance with the GDPR [GDPR],
  • Ongoing process: informed consent from participants is ensured repeatedly throughout the research project. Different parts of the consent, e.g. participation in research for primary data use and for data sharing can be handled at particular stages of the research project. This gives participants a clearer view on the details of their participation, i.e. which data is collected and how this data is handled in the project.

In most cases, collected data (containing personal information) has to be detached from personal references (e.g. individuals, organisations, businesses, etc.) before it can be published or shared with other entities. One way to achieve this is to anonymize data. Based on the underlying informed consent the reasons for applying the anonymization could be:

  • Ethical reasons – protecting people’s identities.
  • Legal reasons – not disclosing personal data.
  • Commercial reasons.

It can be time consuming and expensive to anonymise some types of data, e.g. textual data, or audio-visual data. Therefore, it is strongly recommended to have anonymization already planned in the very early phase of the process and to consider its influence on the design of the surveys and format of research data to be collected as well as the particular content of the informed consent such as the intended use and scope of the collected data.

Security recommendations on ethics checks
 

To ensure proper ethics checks responsible practitioners should make certain that the following measures are taken:

  • R-103 – The identified requirements on ethics need to be clearly specified and documented. Those can be derived from business strategy, regulations, legislations, given contracts, and the current and estimated information security threat environment.
  • R-104 – The necessary controls to fulfil the specified ethics requirements need to be implemented. An ongoing control and improvement process must to be put in place.
  • R-105Ethics checks should be implemented as part of a holistic approach towards IT security (security management plan). IT-security aspects bound to the ethics can only be successfully solved if they are handled as a part of a general IT security approach.
  • R-303 & R-304 – Access to provided data and services, especially from outside the system, has to be limited to minimum and be compliant with contracts and rules. Corresponding technical mechanisms (e.g. role-based access control systems etc.) should be implemented and used. In order to minimize the attack surface only relevant sets of features and access rights to necessary information should be given to the users (see also recommendations below).
  • R-401 – Underlying regulations (contracts, rules, policies) should be available to and followed by the users. Especially when data is propagated to other countries, general compliance as well as possible export restrictions should be considered.
  • R-601 - IT security (including ethical aspects) should be documented and certified (e.g. ISO 27001 or similar). All relevant aspects relating to ethics must be documented and published internally.
  • R-604 – Confidential data has to be adequately protected. This means that classification of information has to be carried out and documented. Access to confidential information must be done according to the agreed terms. The implementation of an adequate access control system can be significantly simplified by documented classification of information.
  • R-605 – The list of people responsible for the aspects of ethics should be documented and published. In order to clearly define the point of contact for ethics affairs, responsible persons must be designated. Their duties include the support of the conception, the implementation, and the continuous improvement of the aspects of ethics within the IT security, according to the strategic objectives of the security policy.
Applicable Controls
 

The controls specify practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. The controls are given on the horizontal axis (blue shade) and the requirements on the vertical axis (yellow shade).

Table 5: Ethics Checks: Relationship between the identified IT-security recommendations and controls

As shown in Table 5, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Information security management system - [ISO27001] chapter 4.4
  • Operational planning and control - [ISO27001] chapter 8.1
  • Documented information - [ISO27001] chapter 7.5
  • Policies for information security - [ISO27002] control 5.1.1
  • Review of the policies for information security - [ISO27002] control 5.1.2
  • Information security roles and responsibilities - [ISO27002] control 6.1.1
  • Classification of information - [ISO27002] control 8.2.1
  • Access control policy - [ISO27002] control 9.1.1
  • Documented operating procedures - [ISO27002] control 12.1.1
  • Identification of applicable legislation and contractual requirements - [ISO27002] control 18.1.1
  • Intellectual property rights - [ISO27002] control 18.1.2
  • Independent review of information security - [ISO27002] control 18.2.1
  • Compliance with security policies and standards - [ISO27002] control 18.2.2
  • Aspects of data protection concept - [BSIGSK] M 2.503
  • Data protection and privacy architectural requirements -  [OWASP_ASVS] chapter V1.8
  • Security policy and procedures for the protection of personal data, [ENISA2] chapter 4.1.1.1
  • Roles and responsibilities - [ENISA2] chapter 4.1.1.2
  • Confidentiality of personnel - [ENISA2] chapter 4.1.3.1
  • Training - [ENISA2] chapter 4.1.3.2
Practical checklist
 

The following checklist provides a series of questions and considerations that should be taken into account to ensure proper ethics checks in data sharing scenarios. These are based on the previously cited requirements as well as the respective recommendations and controls.

Are current ethic requirements documented as part of the security management plan?

 

Have people for ethics checks been appointed and are they known to the entire organization?

 

Have ethic requirements undergone an independent review since their last update?

 

Is there an “ethics issues” table in place for each project?

 

Is there an “ethics review procedure” in place for each type of project?

 

Is there an ethics committee or a responsible individual appointed to each project?

 

Is there a regular ethics audit for each project?

 

 

4.5 Licensing

In terms of licensing, two topics need to be addressed:

  • Copyright – Who owns the right to make copies of a creative work?
  • Licensing – How can copyright owners licence others to use their intellectual property?

Discussing copyright implies the assumption that the work the copyright should apply to is original and fixed in a material form (e.g. written, recorded, etc.). The originators of the data in digital form (e.g. publications, spreadsheets, computer programs or different types of reports etc.) are usually the copyright holders. Their contribution falls under literary work and is thus protected by copyright. The author of the work is automatically the first holder of the copyright, unless there is some other legal construct in place that transfers the copyright to a third party (e.g. an employer). In case of derived data or results of collaborative work, various authors or institutions could hold a copyright cooperatively. In these cases, it is important to correctly apply the copyright to the particular parts of the entire dataset.

Any secondary users have to obtain clearance from the copyright holder before using the data. Various ways exist to license the reuse of copyrighted data:

  • Open data: Secondary users are allowed to access the data fully and free-of-charge. In many cases of free access, the owner of the data wants to be acknowledged.
  • Non-open data: Access to data is subject to certain conditions such as:
    • A fee is required to access the data.
    • A licence that forbids the re-use of the data including the use of “no derivatives” requirements.
    • There is a time-limit on the access to the datasets or resources,
    • Prior registration or explicit request is required to access the data.

Especially when dealing with open data, the European Data Portal offers a comprehensive licensing assistant[4] that helps with choosing the correct open data licence among the multitude of options such as:

  • Creative Commons (CC)
  • European Union Public Licence (EUPL)
  • GNU Free Documentation License (GFDL)
  • Open Data Commons License (ODC)
  • Open Government Licence (OGL)
Security recommendations on licensing
 

To ensure proper licensing, responsible practitioners should make certain that the following measures are taken:

  • R-103 – Terms and conditions of a licence have to be clearly defined. In some cases it is necessary to write a custom licence text, but the recommendation is to use an existing licence text and adapt it accordingly.
  • R-104 – Correctness and consistency of the defined licence terms have to be continuously verified and, if needed, adjusted. The suitability of the licence can change, e.g. if some additional third-party data has been acquired and integrated. There could be discrepancies or even contradictions between the previous and the new licences which prohibit the use of the new data without the necessary adjustments to the previous licence.
  • R-105 – Handling licensing should be part of the security management plan. As with almost all IT security aspects, handling of licenses must be part of the overall concept of IT security.
  • R-208 – Both license terms and security provisions of shared data must be clearly presented to the requestor in an easily accessible manner (e.g. presented on the website and using easy-to-read formats and layout).
  • R-401 – Users are required to know and follow the mandated security policies and licence of the processed data.
Applicable Controls
 

The controls specify practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. The controls are shown on the horizontal axis (blue shade) and the requirements on the vertical axis (yellow shade).

Table 6: Licensing: Relationship between the identified IT-security recommendations and controls

As shown in Table 6, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Policies for information security - [ISO27002] control 5.1.1
  • Review of the policies for information security - [ISO27002] control 5.1.2
  • Identification of applicable legislation and contractual requirements - [ISO27002] control 18.1.1
  • Intellectual property rights - [ISO27002] control 18.1.2
  • Privacy and protection of personally identifiable information - [ISO27002] control 18.1.4
  • Independent review of information security - [ISO27002] control 18.2.1
  • Compliance with security policies and standards - [ISO27002] control 18.2.2
  • Compliance with relevant standards and regulations - [BSIGSK] M 1.1
  • Transmission and retrieval of personal data - [BSIGSK] M 2.205
  • Design and organisation of compliance management – [BSIGSK] M 2.439
  • Consideration of legal framework conditions – [BSIGSK] M 2.340
  • Roles and responsibilities - [ENISA2] chapter 4.1.1.2
  • Information security policy - [ENISA3] chapter 2.3
Practical checklist
 

The following checklist provides a series of questions and considerations that should be taken into account to ensure proper licensing in data sharing scenarios. These are based on the previously cited requirements as well as on the respective recommendations and controls.

Is every dataset accompanied by a licence?

 

Does the structure of the dataset licence follow existing established licences?

 

Has the correctness of the licences been checked after the last modification of the datasets?

 

Have the licences been checked by an independent expert?

 

Is handling of the licensing process defined as part of the full security management plan?

 

Are licences of combined datasets compatible?

 

Do you have permission to share or own all the licenced datasets?

 

 

4.6 Data security

The appropriate handling of data security is a key aspect in data sharing. The delivery of authentic data that only contains the appropriate personal or confidential information and applies fully to the underlying licence is one of the most common requirements when data is shared. The receiver of the shared data needs to be sure that the received information comes from a particular source and has not been manipulated on the way.

Data security can be divided into three main topics: physical, network, and systems security.

Physical security deals with the physical access to, and protection of, the relevant buildings and rooms in which data is stored, the secure handling of hardware (e.g. access, maintenance), and the secure hardware and software administrative processes. The main goal is to provide a secure foundation for setting up the environment of the sharing platform (i.e. hardware, software, processes).

Network security deals with the protection of the underlying systems, especially ringfencing them against the risks related to the communication between systems over the internet (e.g. the implementation of network firewalls and DMZs).

Systems security ensures the adequate handling of the security requirements implemented on the computer systems especially at the user level. Among others, it includes:

  • Password handling (e.g. how long they should be, how often they should be changed);
  • Implementing suitable access control mechanisms (e.g. RBAC);
  • Implementing appropriate encryption;
  • Monitoring and filtering transmitted data (e.g. filtering of personal data, only allowing encrypted transfer of data);
  • Destruction of the data in a secure manner (the destroyed data cannot be recovered);
  • Secure processing of the shared data including traceability of changes.

The current state of the implementation of relevant IT-security measures should be confirmed by the corresponding certifications and audits, e.g. in accordance with [ISO27001].

Security recommendations on data security
 

To ensure data security, responsible practitioners should ensure that the following measures are taken:

  • R-101 – Policies ruling the security mechanisms have to be defined at an early stage in the project, i.e. significant IT-security-aspects should already be considered in the design phase.
  • R-102 – The security implementation costs can be controlled by a wise choice of mechanisms and tools. It is recommended to get an overview of the market when planning the implementation of measures. The most advertised solution may not always the best.
  • R-103 – The security architecture must be clearly defined. Only a sufficient list of IT security requirements can lead to a successful implementation. A clear IT security policy and security architecture based on these requirements are important milestones along the way.
  • R-104 – The implementation of security mechanisms should be exhaustive, controlled permanently, and routinely improved. The successful implementation of the security strategy implies full compliance with the requirements. Sufficient measures must be implemented for each requirement. Only a holistic approach will lead to success. Furthermore, the status of the implementation must be constantly checked, revised and adjusted if necessary. Information can be secured cryptographically on databases or servers, but it is also important to secure the access to the premises.
  • R-105 – A holistic approach according to IT security should be the long-term target. The tasks of IT security should not be seen as a one-off hurdle, but represent a continuous process that must be seen as part of a long-term strategy of the project.
  • R-106 – A set of necessary security requirements should be defined and used as a base for the security mechanisms to be chosen. It is extremely important that not only all defined requirements of IT security are implemented, but also that no further unnecessary mechanisms are introduced. Each new mechanism increases the complexity of the system and expands the potential attack surface.
  • R-201 – Already existing protection mechanisms should be reused. Many of the applications used already have some security features. It is recommended to check these functions and if necessary to use them as part of your own security measures. This approach saves money and very often leads to better results because application manufacturers know their own products better and, thus, can often implement security measures more appropriately.
  • R-202 – Protection against malware has to be implemented. One of the biggest threats to IT continue to be different types of malware. Use of appropriate anti-virus applications is essential. In order to increase the effectiveness of such tools, it is also recommended to use multiple programs that come from different manufacturers (multi-tool and multi-vendor strategy).
  • R-209 – As an important aspect of IT security, the complete documentation of the system must be available. An undocumented system cannot be used. All functions and processing information in the system must be sufficiently documented. The documentation must be made available to the all authorized users. Furthermore, documentation provides the basis for developing, maintaining, and improving an organisation’s own IT security.
  • R-301 & R-302– An adequate protection of own networks is crucial. Access to own networks must be secured by the use of an appropriate firewall. It is important to change the default settings of the chosen product and to reconfigure them according to the requirements of your own IT security.
  • R-306 – The e-mail communication channel has to be monitored, because of the potential to transfer the information as attachment outside of the organisation. E-mail is a channel with a substantial threat potential. It is quite possible that on the one hand through this channel various malware find their way into the system or on the other hand confidential information is transmitted unnoticed from the system to externals. This aspect must be payed adequate attention.
  • R-401 – Security policies must be known and followed by everyone. The best IT security will not help if the underlying security policies are not known to everyone and not applied by everyone. Note that this is a continuous process. The knowledge must be continually refreshed, the application of which should be controlled.
  • R-402 – Staff should be informed on the handling policy for the personal data. The handling of personal data is an important aspect of IT security. Failure to comply with relevant regulations can result in considerable damage. For this reason, it is important that staff is adequately trained on this issue.
  • R-403 – The handling of third-party actors should be clearly defined. The conditions and procedures for dealing with outsiders within your own organization must be defined precisely. In particular, access to certain premises may result in unnoticed access to confidential data stored there.
  • R-405 – Emergency contact data for external experts for particular IT security aspect should be defined and communicated. In case of an incident, it is important that the responsible persons can quickly contact the relevant experts and call them for help. In order to make this possible, the experts must be known in advance and their contact details and the associated application procedures must be communicated to staff.
  • R-406 – Audits of the implemented IT security (preferably with a certification) should take place regularly. Even the best functioning system has to be constantly checked. In addition to the internal audits, audits by the external experts (auditors) must be carried out in regular intervals. Preferably, external audits should be completed with a corresponding certification, according to a recognised IT security standard (e.g. [ISO27001]).
  • R-407 & R-408 – The handling of detected security breaches has to be specified. In order to be able to respond appropriately to potential incidents and to maintain the defined security objectives in relation to the kept information, the procedures for dealing with the incidents must be defined and communicated to responsible persons.
  • R-503 – A strategy for the application of security updates and a corresponding update plan have to be created. In some cases, non-upgraded applications become sources for successful IT infrastructure attacks. Such applications provide attackers with access to active vulnerabilities and allow the use of known exploits. A clear update / upgrade strategy and its consistent application reduce this threat to the necessary minimum.
  • R-601 – IT security provisions should be documented and certified (e.g. ISO 27001 or similar). A security certificate according to an established international standard generally increases the maturity of the implemented IT security and is therefore strongly recommended.
  • R-604 – Personal or confidential data has to be sufficiently protected. Violations of these rules will usually cause damage, both in monetary terms and in reputation.
  • R-605 – Responsibilities for particular tasks have to be defined and assigned. The core of the security policy is a clear allocation of responsibilities. The security team must react quickly and actively to occurred incidents and initiate effective countermeasures. In such cases, it must be clear who is responsible for which part of the measures to be implemented.
  • R-606 – IT security has to be controlled and improved (ISMS[5]) on an ongoing basis. Only a steadily maintained approach can permanently improve IT security. In this sense, it is necessary to continuously review and improve the implemented IT security system. In particular, regular audits by external auditors contribute to such improvement through their impartiality.
Applicable Controls
 

Controls specify the practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. Controls are in the horizontal (blue shade) and requirements in the vertical (yellow shade).

 

Table 7: Data security: Relationship between the identified IT-security recommendations and controls

 

As shown in Table 7, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Information security management system - [ISO27001] chapter 4.4
  • Operational planning and control - [ISO27001] chapter 8.1
  • Documented information - [ISO27001] chapter 7.5
  • Policies for information security - [ISO27002] control 5.1.1
  • Review of the policies for information security - [ISO27002] control 5.1.2
  • Information security roles and responsibilities - [ISO27002] control 6.1.1
  • Information security in project management - [ISO27002] control 6.1.5
  • Information security awareness, education and training - [ISO27002] control 7.2.2
  • Disciplinary process - [ISO27002] control 7.2.3
  • Classification of information - [ISO27002] control 8.2.1
  • Policy on the use of cryptographic controls - [ISO27002] control 10.1.1
  • Physical security perimeter - [ISO27002] control 11.1.1
  • Working in secure areas - [ISO27002] control 11.1.5
  • Documented operating procedures - [ISO27002] control 12.1.1
  • Controls against malware - [ISO27002] control 12.2.1
  • Information backup - [ISO27002] control 12.3.1
  • Event logging - [ISO27002] control 12.4.1
  • Installation of software on operational systems - [ISO27002] control 12.5.1
  • Information systems audit controls - [ISO27002] control 12.7.1
  • Security of network services – [ISO27002] control 13.1.2
  • Information transfer policies and procedures - [ISO27002] control 13.2.1
  • Responsibilities and procedures (with regard to information security incident management) - [ISO27002] control 16.1.1
  • Planning information security continuity - [ISO27002] control 17.1.1
  • Identification of applicable legislation and contractual requirements – [ISO27002] control 18.1.1
  • Intellectual property rights - [ISO27002] control 18.1.2
  • Compliance with security policies and standards - [ISO27002] control 18.2.2
  • Aspects of a data protection concept - [BSIGSK] M 2.503
  • Development of a cryptographic concept - [BSIGSK] M 2.161
  • Selection of a suitable cryptographic procedure - [BSIGSK] M 2.162
  • Data protection and privacy architectural requirements - [OWASP_ASVS] chapter V1.8
  • Communications architectural requirements - [OWASP_ASVS] chapter V1.9
  • Malicious software architectural requirements -  [OWASP_ASVS] chapter V1.10
  • Minimize attack surface area - [OWASP_SDP] chapter 5.1
  • Principle of Least privilege - [OWASP_SDP] chapter 5.3
  • Security policy and procedures for the protection of personal data, [ENISA2] chapter 4.1.1.1
  • Roles and responsibilities - [ENISA2] chapter 4.1.1.2
  • Access control policy - [ENISA2] – chapter 4.1.1.3
  • Confidentiality of personnel - [ENISA2] chapter 4.1.3.1
  • Training - [ENISA2] chapter 4.1.3.2
  • Access control and authentication - [ENISA2] chapter 4.2.1
  • Information security policy - [ENISA3] SO 01
  • Third party management - [ENISA3] SO 04
  • Access control to network and information systems - [ENISA3] SO 10
  • Asset management - [ENISA3] SO 14
  • Monitoring and logging - [ENISA3] SO 19
  • Compliance - [ENISA3] SO 22
Practical checklist
 

The following checklist provides a series of questions and considerations that should be considered to ensure data security in data sharing scenarios. These are based on the previously cited requirements as well as respective recommendations and controls.

Is someone assigned the responsibility for data security?

 

Have employees received training on basic information security?

 

Is there an established IT security policy?

 

Do assigned department technical administrators with clear roles and responsibilities exist?

 

Do established reporting protocols for indications of security breaches exist?

 

Do established email handling protocols and guidelines exist?

 

Does the organization provide digital IDs for email encryption and signing?

 

Has the organization established back-up protocols?

 

Is physical access to computer hosts protected?

 

Is vision to computer hosts screens restricted from people passing by?

 

Are computer hosts password protected?

 

Are there established procedures for wiping data from computer hosts prior to disposal?

 

Is there an established password policy?

 

Are there automatic security updates on computer hosts and servers?

 

Is there a regular auditing procedure of logs and indicators of compromise (IOC)?

 

Are there physical access restrictions on the servers?

 

Is remote access to internal services secured via VPN?

 

 

​​​​​​4.7 Discoverability

In order to enable the shared data to be broadly discovered and reused the data has to be prepared. It would not be sufficient to collect and provide data to potential users. Instead, it is crucial to describe (document) the data to be shared in a discoverable and understandable way, which is accessible by external users. Data documentation covers technical and business aspects; such as how data was created, what it means, its structure and content (e.g. origin, purpose, time reference, geographic location, creator, access conditions and terms of use of the data collection). Documentation of data is done via the use of metadata.

Providing structured and well-defined searchable information helps the users find and classify the data underneath. Therefore, metadata for online data catalogues or discovery portals is often structured according to international standards or schemes (e.g. the Dublin Core (cf. [ISO15836-1]) or the Metadata Encoding and Transmission Standards (METS)[6] etc.).

Documenting data is vital when creating, organising, and managing data due to its importance not only for data discovery but also for (long-term) data preservation.

Security recommendations on discoverability
 

To ensure that data is both discoverable and secure, responsible practitioners should ensure that the following measures are taken:

  • R-104 – Appropriate metadata and data format standards have to be used. The information can only be used if it has been adequately described and if it can be readily represented. In both cases, the successful fulfilment of the requirements addressed above is related to the formats used. The used formats of the so-called metadata (description) as well as the visualization must correspond to the accepted international standards as accurately as possible.
  • R-106 – Security mechanisms that ensure authenticity and integrity of data should be implemented. Mechanisms must be implemented that reliably assure integrity and authenticity of the electronic information available. The use of electronic signatures and seals is one option to achieve such assurance.
  • R-303 – Only data released for the search (especially without privacy violations) should be accessible. Requirements of data protection must be respected. In particular for research purposes, data must be prepared accordingly, e.g. personal data must be removed or rendered illegible.
  • R-304 – Only search function should provide less restricted (even perhaps unrestricted) access. The search function as the first step in finding the appropriate information must be provided to the user on a (more or less) free basis. The next step (information access) should be realized according to the conditions of use for the wanted information. Free access should be kept to a minimum and applied only to absolutely necessary functions.
  • R-401 – Policies for the preparation of searchable subsets of data have to be followed. The pursued strategy of how to prepare the database must be filed as part of the security policy. The approach followed must be documented in detail and this documentation must always be available to staff. The correct application of the approach must be monitored and regularly reviewed.
Applicable Controls
 

Controls specify the practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. Controls are in the horizontal (blue shade) and requirements in the vertical (yellow shade).

 

Table 8: Discoverability: Relationship between the identified IT-security recommendations and controls

 

As detailed in table 4, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

  • Classification of information - [ISO27002] control 8.2.1
  • Labelling of information - [ISO27002] control 8.2.2
  • User access provisioning - [ISO27002] control 9.2.3
  • Information access restriction - [ISO27002] control 9.4.1
  • Secure log-on procedures - [ISO27002] control 9.4.2
  • Policy on the use of cryptographic controls - [ISO27002] control 10.1.1
  • Security of network services - [ISO27002] control 13.1.2
  • Information transfer policies and procedures - [ISO27002] control 13.2.1
  • Agreements on information transfer - [ISO27002] control 13.2.2
  • Confidentiality or non-disclosure agreements - [ISO27002] control 13.2.4
  • Intellectual property rights - [ISO27002] control 18.1.2
  • Compliance with security policies and standards - [ISO27002] control 18.2.2
  • Regulations concerning information exchange - [BSIGSK] M 2.393
  • Checking the legal framework and prior checking before processing personal data - [BSIGSK] M 2.504
  • Definition of technical/organisational safeguards according to the state-of-the-art for processing of personal data - [BSIGSK] M 2.505
  • Obligation/briefing of staff members for the processing of personal data – [BSIGSK] M 2.506
  • Selection of a suitable cryptographic procedure - [BSIGSK] M 2.162
  • Input and output architectural requirements - [OWASP_ASVS] chapter V1.5
  • Compliance - [ENISA3] SO 22
Practical checklist
 

The following checklist provides a series of questions and considerations that should be taken into account to ensure data discoverability and security in data sharing scenarios. These are based on the previously cited requirements as well as respective recommendations and controls.

Do all published data include relevant metadata?

 

Are metadata following an established format (like DCAT)?

 

Is access to datasets granted via an authentication/authorization mechanism?

 

Are all relevant data searchable via queries?

 

Are search endpoints protected against abuse? (e.g. denial of service attacks)

 

Are all databases protected against direct access?

 

Is publicly accessible data indexed by established search engines? (e.g. Google)

 

Are all API endpoints, including search functions, encrypted?

 

  1.  

4.8 Data access

The applicable ethical standards also affect the level of access control to data. Under certain conditions, personal or confidential data can be protected by restricting access and/or granting regulated access to such data. Usually, data collected is not in the public domain, e.g. during research projects and kept in data centres and/or archives. Usage is restricted by both user registration and the informed consent signed by the research participants. Re-users of data have to accept and obey the conditions imposed by the applicable licence in order to gain access to the shared data.

However, access to confidential data can be further regulated by:

  • Requirements for usage of specific authentication/authorisation procedures.
  • Limiting access to approved users.
  • Limiting access by only enabling remote analysis, but not the download and local processing of data.
  • Removal of confidential data at least for the given period.

Which access type and corresponding regulations should apply in general depends on the mutual agreement between the user and the data owner, which should be documented in a particular licence format. Access regulations should always be proportionate to the kind of data involved and the required confidentiality.

Security recommendations on data access
 

To ensure that data is both accessible and secure, responsible practitioners should ensure that the following measures are taken:

  • R-101 – The data access policy should be defined in the early phases of the project (in particular while developing the rules for the sharing of collected data). Similarly, the aspect of regulated data access must already be documented at an early stage in the security policy. According to the classification of the offered data, corresponding access protection mechanisms must also be anticipated.
  • R-104 – Relevant controls must be implemented (either by the owner of the shareable data or by the service provider, e.g. the sharing portal). All controls addressed in the context of the IT security concept must also be implemented. Only a full implementation of measures guarantees adequate achievement of postulated security goals and ensures a sufficiently operational access protection of information.
  • R-105 – A holistic approach for security management should be designed and implemented. Even in the context of data access, its successful deployment is strongly dependent on the holistic approach to IT security. Implementation of only parts of the underlying security concept may result in one-off improvements, but will not be effective as they are likely to ignore the weak points in other areas of the overall system. The best implementation of login and access control will be useless if, for example, no firewalls are used and access controls can be bypassed.
  • R-201 – Synergy effects should be considered. The access control mechanisms that are already offered by the products used can very often be retained. Reimplementing existing technology is rarely desirable. Especially complex access control mechanisms can be effectively designed and implemented by the manufacturers of such systems / products due to their extensive knowledge of the products and their underlying logics.
  • R-203 – Appropriate concepts for access control have to be in place. Regardless of the implementation, the design of access control mechanisms must be completed and documented. The requirement to use such a system must be included in the security policy.
  • R-204 – Especially the treatment of privileged users should be controlled and managed. Dealing with privileged users poses a particular challenge in any system. Especially with the use of personal information, this aspect is of increased importance. This needs to be included in the security policy and a corresponding plan must be drawn up.
  • R-205 – Access rights of privileged users should be limited to the required minimum. Due to the fact that damages done by privileged users will generally be greater, this aspect deserves increased attention. In general, it is important to ensure that no accumulation of access rights in the case of such users can occur. The fine-grained design of appropriate roles and implementation of additional mechanisms (for example, following the four eyes principle) can help.
  • R-207 – Default accounts and users should be reconfigured. There have been successful cyberattacks based on the use of default user accounts or configuration by the manufacturers. These settings must be changed before the system is taken into operation. In particular, standard administrator accounts represent a considerable threat.
  • R-303 – Only necessary data should be provided for access from outside of the system. According to the minimum principle, only data necessary for the fulfilment of the preliminary task should be made available. Providing additional data doesn’t help accomplishing the task but instead increases the risk that may result in breach of relevant security objectives and, thus, cause damage. Only necessary applications/services should be provided for access from outside of the system
  • R-401 – The security policy, especially data access policy, should be well-known to all relevant users. The need for an implementation of adequate access control mechanism must be included in the security policy.
  • R-403- Access of third-party staff to systems holding confidential data has to be regulated and limited to a minimum. Dealing with outsiders who have access to the protected premises must be clearly regulated. Measures must be developed and implemented which do not result in compromised protected information resulting from such access.
  • R-404 – Regular training on security aspects of the staff has to be implemented. Staff must be continuously trained in the relevant aspects of IT security in general and access control in particular. Changes to the concepts and mechanisms must be communicated immediately. Confirmation of the knowledge transfer is recommended.
  • R-501 – Necessary updates, especially security updates, should be installed immediately. As in the case of any technical system, access control systems must be continuously maintained. All necessary updates / upgrades (especially security-related) must be installed promptly. To control the correct execution of related activities, a responsible person must be named. The designation must be announced.
  • R-602 – An appropriate password policy has to be established. Suitability of the passwords used determines the suitability of the underlying sign-on mechanism and, in part, the access control system. For this reason, it is important that correct handling of passwords is defined in the corresponding policy and that this policy is made available to both personnel and users. Measures should be implemented which automatically monitor compliance with the policy and, thus, rule out their violation as much as possible.
  • R-606 –Implemented security mechanisms have to be audited and improved on a regular basis. Mechanisms for access control (like the other security aspects) should be checked by external experts through regular audits. This is necessary to fully meet the requirement for continuous maintenance of the specified mechanisms. The objectivity of the external auditors can help enormously in finding the uncovered security risks.
Applicable Controls
 

Controls specify the practical measures that should be considered to implement the stated recommendations. Therefore, the controls give specific guidance on what needs to be done and/or considered during the implementation of a recommendation. The appropriate measures can be technical, physical, procedural, or policy-specific.

The following matrix gives an overview of how security controls specified by ISO, ENISA, BSIGSK, OWASP and other external resources apply to the previously mentioned requirements and recommendations. Controls are in the horizontal (blue shade) and requirements in the vertical (yellow shade).

 

Table 9: Data access: Relationship between the identified IT-security recommendations and controls

As shown in table 5, the most important controls that should be applied for the managing, controlling, and implementation of the above-mentioned security aspects are:

Policies for information security - [ISO27002] control 5.1.1 Review of the policies for information security - [ISO27002] control 5.1.2 Access control policy - [ISO27002] control 9.1.1 User registration and de-registration - [ISO27002] control 9.2.1 User access provisioning - [ISO27002] control 9.2.2 Management of privileged access rights - [ISO27002] control 9.2.3 Management of secret authentication information of users - [ISO27002] control 9.2.4 Use of secret authentication information - [ISO27002] control 9.3.1 Information access restriction - [ISO27002] control 9.4.1 Secure log-on procedures - [ISO27002] control 9.4.2 Password management system - [ISO27002] control 9.4.3 Aspects of a data protection concept- [BSIGSK] M 2.503 Definition of technical/organisational safeguards according to the state-of-the-art for processing of personal data - [BSIGSK] M 2.505 Provisions governing the use of passwords - [BSIGSK] M 2.11 Guidelines for access control - [BSIGSK] M 2.220 Appropriate choice of authentication mechanisms - [BSIGSK] M 4.133 Secure use of single sign-on - [BSIGSK] M4.498 Compliance with relevant standards and regulations - [BSIGSK] M 1.1 Password protection for IT systems - [BSIGSK] M 4.1 Change of pre-set passwords - [BSIGSK] M 4.7 Utilisation of the security functions offered in application programs - [BSIGSK] M 4.30 Documentation of authorised users and rights profiles - [BSIGSK] M 2.31 Development of a cryptographic concept - [BSIGSK] M 2.161 Access control architectural requirements - [OWASP_ASVS] chapter V1.4

Practical checklist
 

The following checklist provides a series of questions and considerations that should be considered to ensure access control in data sharing scenarios. These are based on the previously cited requirements as well as respective recommendations and controls.

Has an access control policy been established as part of the IT security policy of the organization?

 

Is every user account tied positively to an authorized individual?

 

Is every user authorized to only access information that is required for their work duties?

 

Are all non-public files only accessible via authentication/authorization mechanism?

 

Is there an established audit log mechanism?

 

Have employees been trained on secure handling of personal or confidential data?

 

Are all databases protected by a firewall and not directly accessible from the internet?

 

Do all API endpoints require authentication?

 

Is the authentication/authorization mechanism up to date and secured?

 

Have regular external audits and penetration tests been established?

 

Are all vendor remote maintenance connections documented and secured?

 

Is remote file sharing and printing disabled?

 

 

 

 

Bibliography

 

 

 

[BDSG]

 

German Bundesdatenschutzgesetz (BDSG) is a federal data protection act, 30.07.2017,
https://www.gesetze-im-internet.de/englisch_bdsg/index.html

[ENISA1]

 

Reinforcing trust and security in the area of electronic communications and online services: Sketching the notion of “state-of-the-art” for SMEs in security of personal data processing, ENISA, 2018, https://www.enisa.europa.eu/publications/reinforcing-trust-and-security-in-the-area-of-electronic-communications-and-online-services

[ENISA2]

 

Guidelines for SMEs on the security of personal data processing, ENISA, 2017, https://www.enisa.europa.eu/publications/guidelines-for-smes-on-the-security-of-personal-data-processing

[ENISA3]

 

Technical Guidelines for the implementation of minimum security measures for Digital Service Providers, ENISA, 2017, https://www.enisa.europa.eu/publications/minimum-security-measures-for-digital-service-providers

[ENISA4]

 

Privacy and Data Protection by Design, ENISA, 2015, https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design

[GDPR]

 

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), 4.5.2016,
http://data.europa.eu/eli/reg/2016/679/oj

[ISO15836-1]

 

ISO 15836-1:2017. Information and documentation — The Dublin Core metadata element set — Part 1: Core elements, ISO, 2017

[ISO27001]

 

ISO/IEC 21001:2013 Information technology - Security Techniques - Information security management systems — Requirements, ISO, 2013

[ISO27002]

 

ISO/IEC 27002:2013 Code of practice for information security controls, ISO, 2013

[OWASP_ASVS]

 

OWASP: Application Security Verification Standard 4.0, March 2019, https://github.com/OWASP/ASVS/raw/master/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-en.pdf

[OWASP_SDP]

 

OWASP: Security by Design Principles
https://www.owasp.org/index.php/Security_by_Design_Principles

[HIC2016]

 

Password Guidance
https://www.microsoft.com/en-us/research/publication/password-guidance/

[NIST800-35]

 

NIST Special Publication 800-35, “Guide to Information Technology Security Services”
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-35.pdf

[BSIGSK]

 

IT-Grundschutz-Catalogues, BSI, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/International/GSK_15_EL_EN_Draft.pdf?__blob=publicationFile&v=2

[eIDAS]

 

The Regulation (EU) N°910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation)

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG

[DCAT-AP]

 

The DCAT Application Profile for data portals in Europe (DCAT-AP)

https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe

 

 

secure-data-scds
Image credit:
Support Centre for Data Sharing