GDPR implementation part 7: Information and Tools for Implementation of Users’ Rights

GDPR

One of the main objectives for the European Union (EU) when they developed the replacement for the Data Protection Directive 95/46 (from 1995), was to expand individual control over the use of personal data.

This can be seen in a broader view as an implementation of the right to one’s private life, as laid down in the European Convention on Human Rights (Article 8). The right to respect for one’s private and family life is also stated in the EU Treaty on Fundamental Rights (Article 7).

Norway has signed both of these agreements, and the Constitution of Norway implements these rights in Article 100 and 102 of the Constitution and in the Norwegian Human Rights Act.

Already in GDPR1 Article 1 we see the connection between the GDPR and especially the Treaty on Fundamental Rights:

This Regulation protects fundamental rights and freedoms of natural persons and in particular their right to the protection of personal data

Article 1-2 of the GDPR

Observe the expression “rights and freedoms of natural persons“, which is very important throughout the Regulation and is used 31 times in all.

Before we go further into the subject of this post, it is important to state that Norway’s legislation on the processing of personal data was already compliant with the GDPR before the latter was declared as the new framework for the legislation in Norway. The Norwegian Personal Data Act (PDA2), as compliant with the GDPR, tok effect 20 July 2018.

First and foremost, the GDPR states that no processing of personal data shall be done unless the data subject has given consent (Article 6-1, a). Runbox obtains consent to registration of our users’ personal data when they sign up for an account and accept our Terms of Service.

The GDPR (Article 6-1, ff.) allows a controller – that is Runbox in our context – to process personal data when there is a legitimate reason for doing so, i.e. something that is necessary to use our services.

It is an important objective for the GDPR to secure one’s control of one’s own personal data. In this respect, the GDPR has given the data subjects eight fundamental rights (Article 15—17).

When implementing these rights in Runbox, we found that most of those were already there. However, the introduction of the GDPR provided us with a checklist and the opportunity to analyze our status, and to improve our services in this respect.

Our Privacy Policy provides exhaustive information about how we process personal data, but here is an overview of the data subject’s rights, and our implementation of them:

  • The right to access (Article 15): Since Runbox does not collect other types of information than what the users register by themselves, they can easily check which personal data is processed. The data processing is only done in order to process your emails, and optionally your web site and domain name.
  • The right to rectification (Article 16): You may at any time log in to your email account and change your personal information.
  • The right to erasure (‘right to be forgotten’) (Article 17): You may terminate your subscription any time, and your account contents will subsequently be deleted after 6 months. Your personal details data will be deleted after 5 years in accordance with Norwegian accounting regulations. However, you may send a request to dataprotectionofficer@nullrunbox.com for immediate erasure of your account contents.
  • The right to restriction of processing (Article 18): Runbox will never use your personal information for purposes other than providing our services to you, so restrictions are not necessary in our context.
  • The right to be informed (Article 19): Runbox uses your personal information only in order to provide our services to you..
  • The right to data portability (Article 20): In case that you wish to move to another email service provider and export your data, you will find information on how to do this through our services and documentation.
  • The right to object (Article 21): Since we never will use your personal data for other purposes than to deliver the services you have agreed to, this right is implicitly fulfilled.
  • The right to individual decision-making (Article 22): This article is intended to protect data subjects against automated data-processing that might involve profiling them based on personally identifiable information, which is something Runbox doesn’t do.

Regarding questions or concerns about our implementation of the GDPR, customers may use the email address dataprotectionofficer@nullrunbox.com as a direct channel to our appointed Data Protection Officer.

Some final remarks about consent: Runbox uses cookies in order to provide our services, and new users must give express consent to this on our signup page. On this page, and on the Account page once logged in, you may also give/revoke consent to future news and offers from Runbox.

In our next post in this series, we will consider our contractual situation regarding GDPR requirements. Stay tuned.

Footnotes

1. The GDPR means Regulation EU 2016/679 of 27 April 2016 on the protection of individuals 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, General Data Processing Regulation. Article refers to Article in the GDPR, unless stated otherwise.

2. The Personal Data Act (the PDA) means the regulations that are currently in force in Norway for the protection of individuals in connection with the processing of personal data, which includes the implementation of GDPR in Norway (2018-07-20).

Continue Reading →

Security improvements to our services

At Runbox we are continuously working to improve the security of our services. We are now strengthening the security of your web browser’s connection to our servers to ensure that it utilizes modern web security standards.

If you are using an updated version of one of the major web browsers such as Firefox, Chrome, Safari, Opera, and Edge you will probably not notice any effects. You can then continue using our services just like before, while knowing that the strongest encryption protocols are being utilized.

If you’re using a non-standard or not updated web browser, then please read the information below for more details about these changes and how they may affect you.

Those who are interested in the technical details of these changes may also find this information useful.

What we are doing

When you visit our website the connection between your web browser and our web servers is encrypted. This means that no one can intercept your username, password or any other transmitted data including the content of your email messages.

It’s important to use a modern browser that supports modern encryption methods to prevent that encryption from being broken and compromised. This is essential to web security because hackers increasingly use more powerful computers and techniques in their attempts to decrypt data and eavesdrop on unsuspecting users.

In order to ensure that Runbox is providing the latest and most secure encryption between your browser and our service we will therefore end support for outdated encryption methods.

This entails that we will only support the strongest encryption cipher suites that are compatible with most major web browsers.

It also helps us prevent unauthorized access to our servers and helps keep the Runbox services safe for all of our customers.

On December 1, 2019 we will retire some outdated encryption methods and this might affect some older web browsers.

Once these changes are made the TLS protocol version and cipher suites will be the same for all access methods to our email services, including web, POP, IMAP, and SMTP.

The technical details

You don’t need to delve into all the technical details, but we know many customers are interested in this and it is useful for everyone to stay educated about web security.

The changes involve retiring support for TLS (Transport Layer Security) version 1.0 and 1.1, and only provide support TLS 1.2 or later. We will also only support a small suite of strong encryption cipher suites that are recommended by the reputable organizations Mozilla and OWASP.

TLS 1.2 has been around for 10 years so there has been a long time for browsers to adopt the use of this type of encryption. However, you don’t need to understand anything about this to make any necessary changes.

All the cipher suites we will be utilizing are of the type Diffie-Hellman Ephemeral (DHE), which means that a unique cryptographic key is generated each time a new connection is made.

This in turn means that even in the unlikely event that one set of keys is compromised it cannot be used for another connection made from another client (“forward secrecy”).

An updated list of cipher suites that are supported currently include the following:

  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-SHA256
  • ECDHE-RSA-AES256-SHA384
  • DHE-RSA-AES128-SHA256
  • DHE-RSA-AES256-SHA256

More information about these cipher suites can be found on Wikipedia: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

How this may affect you

The vast majority of web browsers already support TLS 1.2 and you are only likely to have a problem if you are using an outdated browser and/or an outdated operating system.

We have tested the following browsers and they all work with the modern encryption that we will use:

  • Firefox
  • Chrome
  • Safari
  • Opera
  • Edge

Many other modern browsers are also likely to work with TLS 1.2 and those listed above are just commonly used ones that we have tested.

What you can do

If you are not using an upgraded version of one of the major web browsers listed above, please upgrade your web browser and/or operating system now. This is the most important action you can take to ensure that your data and communications are secure.

If you’re using a web browser not listed above and are unsure whether it will continue to work with the specifications we have provided, we recommend that you keep one of the major web browsers available as an alternative.

We generally recommend Firefox as it is free, standards compliant, and open source, and therefore reviewed by the security community.

Further help

If you need any further information or help on this issue please contact Runbox Support with details of how we can help you.

Continue Reading →

GDPR implementation part 6: Access Control and Permissions

In part 3 of this blog series we described how we mapped the “world” of our operations, including the following components:

  • Server infrastructure, including all servers and other hardware as well as the links between these.
  • Software components that comprise our application stack from the operating system level to the front-end application level.
  • Data networks, including how and where our serves are connected to the Internet, but also the Local Area Network at our premises.
  • Data inventory, i.e. all personal data including customer and employee data, financial records, information about partners/associates, etc.
  • Applications necessary to run the company itself, meaning software that is managerial in nature.

Access control concerns permissions attached to system-related objects. Within each of the components listed above, there may be several sub-objects — servers, software modules, data files, catalogues etc., to which restricted access should be implemented.

Creating an Access Control Table

These objects then form one axis of an Access Control matrix or table (ACT). The other axis of the table include organizational units, broken down into person-related objects, for instance segments or groups, but also individuals, for each unit.

After breaking these objects down to an appropriate level, we attached roles to each of these components. In terms of the GDPR, data processor and data controller are examples of roles to use in this context.

To each of the defined roles, we attached categories of tasks, for instance sysadmin, developer, and support staff tasks.

For our email service systems we found it convenient to structure the system-related objects in 3 main categories:

  • General software.
  • Application software.
  • Personal data.

Within each of these categories there are various numbers of objects, to which access permissions are attached, comprising the Access Control Table for the realm in question. For other realms of our “world” we used a similar approach, resulting in a number of ACTs that implement a principle of least privilege.

With this the groundwork was laid for establishing various mechanisms for implementing the access control regime, in order to secure our most precious pieces of hardware, software, and data.

In our next blog post in this series we will look at Information and Tools for Implementation of Users’ Rights.

Continue Reading →

GDPR implementation part 5: Risk Assessment and Gap Analysis

In previous posts in this blog series we have referred to our main planning document, Rules and Regulations for Information Security Management, or RRISM for short, where our road to GDPR compliance started out. In that document we worked out the structure of the project, based on descriptions and definitions of the various components.

Obviously, risk management has to be taken very seriously, and the RRISM lays the groundwork for how we should handle this aspect of information security. The baseline is that risk management is an essential part of the company’s life, and one that comprises all its assets.

Defining and assessing risks

As usual, we first had to agree upon some definitions, and we found the following to be adequate for our purpose — directly from NIST (National Institute of Standards and Technology):

Risk is the net negative impact of the exercise of a vulnerability, considering both the probability and the impact of occurrence. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.

Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.

In order to assess risks, we first have to identify possible threats that may exploit vulnerabilities in our systems or our organization.

In short: Risk management shall first and foremost have as objective to protect assets that are at potential risk.

Analyzing assets

Then we outlined the methodology we adopted:

  1. Identify the assets that could be at risk.
  2. Identify possible threats and vulnerabilities.
  3. Identify the possible consequences of each potential vulnerability.

Each threat was characterized by probability and criticality which together gives one of four risk levels: Very High (red), High (orange), Medium (yellow), and Low (green). This helped us decide what we should prioritize regarding improvements, measures, and other actions.

Analyzing our assets we actually found more of these than anticipated, grouped in 21 different asset types, ranging from our customer base, general software in use and our own key business systems, through hardware and communication lines, and employees and partners – and more.

Threat, vulnerability, and gap analysis

Then we reviewed the vulnerability potentials (what could go wrong) for each asset and created scenarios for possible consequences if something happened that exploited a vulnerability.

The question raised thereafter was: Do we have the necessary measures and remedies in place to eliminate the potential vulnerabilities, or mitigate the consequences if things went wrong — or is there a gap?

The next step was to find out what actions should be taken in order to close the gaps in cases where we were not satisfied with the situation, and this will be the topic of future blog posts in this series.

Conclusion

Our mantra through this process has been: Threats we can imagine will sooner or later be reality, but never as we expect them to happen, and never where we expect them.

We live in an ever-changing environment, which means that risks have to be monitored continuously, and so our risk assessment and gap analysis is continually evolving as well.

Continue Reading →

GDPR implementation part 3: Mapping our “world”

This is the third post in our series on Runbox’ GDPR implementation.

After having structured our GDPR project, the next piece of necessary groundwork was to map out status on relevant facts about important areas of our business. The reason is that it’s impossible to establish and maintain good security and privacy – and to determine GDPR compliancy — if the “territory” is not clearly described.

The “territory”

The “territory” in question was foremost and first of all,

  • The email service delivery system, that is the Webmail and backend systems and files – the development platform that is used, the components of which the system is built, the dependencies between the components, description of access points etc. – while being well aware of that the GDPR compliancy also includes Privacy of Design requirements.

Other realms that are necessary to describe were for example:

  • The economic system in which the company operates; i.e. mapping out the network of organizations with which our company is involved – including partners, associates, suppliers, financial institutions, government agencies, and so on – in order to serve our customers.
  • Server infrastructure with all physical links and channels, and not the least: All software components.
  • Data networks, including how and where our serves are connected to the Internet, but also the Local Area Network at our premises.
  • Data catalogue, including of course all personal data, that is, what kind of data are registered on customers and also employees and partners/associates as well.
  • Applications of all sorts necessary to run the company – applications that are managerial of nature.

Level of description

One problem encountered is how detailed the descriptions should be. Too many details will make the job unnecessarily big in the first place, followed by a lot of maintenance to keep the documentation current.

We chose to start with a “helicopter view”, to obtain an overview of the different realms with the intention to fine-grain the documentation depending on the requirements of the ultimate goal: To identify areas where privacy and security is of concern, ticking off issues that are well taken care of in light of the GDPR, or followed up with measures to improve the situation to achieve GDPR compliancy.

Of course, the GDPR Implementation Project is not a sequential one, as development projects seldom are. Therefore, from time to time we had to go back and adjust our planning tools when needs arose.

The next blog post in this series will concern our Information Security Policy.

Continue Reading →

Runbox Two-Factor Authentication

Runbox recently launched Two-Factor Authentication (2FA). 2FA is a log in procedure where an additional piece of information is required in addition to your username and account password.

This additional factor is a code that can only be used once, or for a limited period of time.

Two-Factor Authentication
Runbox Two-Factor Authentication

Runbox 2FA currently supports Timed One-Time Passwords (TOTP) and One-Time Passwords (OTP) as additional factors. We are planning to expand this with Yubikey or U2F support.
 

Runbox is the only 2FA-enabled email provider in Norway

NorwayRunbox is located in Norway, which has some of the strongest privacy regulations in the world.

By choosing Runbox as your email provider, your data will be protected by these regulations while ensuring your email is secure from unauthorized access.

Read on to find out how Runbox 2FA works and which options are available.

 

Timed One-Time Passwords (TOTP)

2FA Timed One-Time Passwords
2FA Timed One-Time Passwords

To use this option you will need a smartphone and some free software.

Timed one-time passwords works by giving you a login code which changes over time, in addition to your password.

To get started, download a TOTP app such as Authy, FreeOTP or Google Authenticator onto your mobile phone and follow their instructions.

Note: It is essential that your smartphone has the correct date/time set as this is used by the TOTP app to generate the correct codes that allow you to log in.

 

One-Time Passwords (OTP)

2FA One-Time Passwords
2FA One-Time Passwords

When you enable this option, the system will generate random passwords that you can use only once. Used passwords are discarded automatically and cannot be used again.

You can download the the list of passwords to a computer or mobile device, or you can print them out if necessary. However, you must keep the list secure as these passwords can be used to access your account along with your usual username and account password.

 

 

Trusted browsers

2FA Trusted Browsers
2FA Trusted Browsers

This option allows the server to trust your current web browser so that you don’t have to use a 2FA code. The option places a small piece of code in your browser (a cookie) that tells the server not to require the 2FA details and you can just log in with username and password.

You should only use this method of bypassing 2FA on a computer or device that you are confident nobody else can log in to. You can temporarily turn on/off individual browsers from the trusted list, or you can delete the browser entry entirely which will force that browser to require the 2FA details.

 

Unlock code

2FA Unlock Code
2FA Unlock Code

If for some reason you are unable to log in with 2FA after it has been enabled, this code can be used to disable 2FA.

The code can be used in conjunction with a secure question/answer for additional security.

 

 

Continue Reading →

New Account Security features launched

We are excited to announce the launch of a new Account Security interface with Two-Factor Authentication (2FA) for Runbox.

This completes more than a year of development, and we are quite proud of the result. The new features will significantly improve the security of your Runbox account when you activate them.

Account Security features

The new Account Security interface includes 4 main features: Two-Factor Authentication, Manage Services, App Passwords, and Last Logins.

Used separately or in combination, these features add extra layers of security to your Runbox account.

Two-Factor Authentication

Two-Factor Authentication (2FA) is a log in procedure where an additional piece of information is required in addition to your username and account password.

This additional factor is a code that can only be used once, or for a limited period of time.

Two-Factor Authentication
Runbox Two-Factor Authentication

Runbox 2FA currently supports Timed One-Time Passwords (TOTP) and One-Time Passwords (OTP) as additional factors. We are planning to expand this with Yubikey or U2F support.

Manage Services

The new Account Security interface lets you disable various services such as IMAP, POP, and SMTP. These are the services you use when using an email app/program to access your mail.

By disabling services you are not using, you prevent attempts at unauthorized access to your account via those services.

App Passwords

You can also set up unique passwords for each of your apps or devices, giving you complete control over the access to your account.

If you then happen to lose a device you can simply delete the corresponding app password, effectively disabling access from that device.

Last Logins

This section shows a list of the most recent login attempts to your account from each service such as web, IMAP, POP, and SMTP.

If you suspect that there have been unauthorized login attempts to your account, you can review this list and take appropriate action.

How to set up Account Security features

To get started, just go to the Account Security screen to set up 2FA and the other security features.

We encourage you to review our Account Security help page for details about the new functionality first. This will ensure that you understand how 2FA works and prevent you from getting locked out of your account.

We welcome any questions or feedback you might have, either as comments to this blog post or via our contact form or support system.

Continue Reading →

How To Use Email Securely

Much has been said and written in the media recently regarding email, and here at Runbox we’d like to take the opportunity to help make it all a bit more understandable.

What is email, anyway?

Email, or electronic mail, is the most common method of exchanging digital messages.

It is easily the most flexible online messaging service available, because it lets users send and receive unlimited text, multimedia, and other files to anyone with an email address anywhere in the world.

Email was invented in the 1960s and is still one of the most popular services currently available via the Internet, with over 90% of US Internet users actively using email.

How does email work?

Email systems consist of computers and devices that are connected via the Internet. These computers and devices can be servers that process and store electronic mail, or clients such as laptops and smartphones that are used to send and receive email.

Email clients and server Email clients connected to a server

When someone sends an email, the message is transferred from his or her device to a server that processes the message.

Based on the recipient email address, the server finds out where to send the message next.

This is usually to another server associated with the recipient’s address, and often via a number of other servers that act as dispatchers.

There are many different types of email software that can send, receive, and store email. If you use a computer or a smartphone, you might be familiar with software such as Outlook, Apple Mail, or Thunderbird.

Where is my email actually stored?

Because the volume of email is so large, email clients typically let servers store all the email that is received and sent and only download messages when they are opened.

This is very convenient because the server can then do resource intensive things like filtering out spam and viruses, and other kinds of sorting and processing.

Another important reason for keeping emails stored on a server is that it lets more than one client access the same messages.

For instance, you can set up your laptop, your tablet, and your smartphone to access all the email that is stored in your account on the server. You can also use a webmail in your web browser, which essentially works as an email client.

This means that your email will be synchronized across all your devices, without you having to do anything manually.

You can read more about how this works in our Help article Using an Email Client with IMAP.

How can I be sure that no one else can access my email?

When you sign up for an email account, you select a username and a password that only you know. This ensures that only you can access the email that is stored in your account on the server.

As you can imagine, it is important that you choose a strong password to make sure that no one else can guess it. It’s also important to be aware of scams that may try to trick you into revealing information that could let someone gain access to your account.

End-To-End Encryption
End-To-End Encryption

However, to be certain no one can read your email even if they were to gain access to it, you can use encryption.

Email encryption can protect your messages all the way from your device to the recipient’s, by encoding them in such a way that it’s virtually impossible for someone unauthorized to unscramble them.

You can read more about this in our Blog post Email Encryption with Runbox and our Help article Encrypting Your Runbox Email.

We hope this article helped clarify what email is, how it works, and how to use it securely. For a more in-depth article, please see How Email Works.

Continue Reading →

Hardened web server security

We have recently hardened our web server security, giving Runbox an A+ rating on securityheaders.io — in addition to our existing A+ rating on ssllabs.com.

The policies we have implemented are the following:

X-Frame-Options: Tells the browser that we don’t allow the Runbox web site to be framed (included) by other web sites, which defends against attacks like click-jacking.

HTTP Strict Transport Security: Strengthens our implementation of Transport Layer Security (TLS) by making the browser enforce the use of encrypted communication (HTTPS).

Content Security Policy: Protects our web site from Cross-Site Scripting (XSS) attacks.

HTTP Public Key Pinning: Protects us from from Man-in-the-Middle attacks by making sure the TLS certificates used by the browsers are the ones implemented on our servers.

X-XSS-Protection: Sets the configuration for the cross-site scripting filters built into most browsers.

X-Content-Type-Options: Forces browsers to use the declared file content type instead of trying to be too clever, which helps to reduce the danger of drive-by downloads.

These changes will help ensure that your use of Runbox is as safe and secure as possible, and we will continue making security-related improvements in the future.

Continue Reading →

TLS Upgraded for Incoming Email

Today we have upgraded the TLS (Transport Layer Security) of our incoming email servers to support version 1.2, which is the most recent. This means that when email is sent to Runbox from other services, the highest level of encryption will be used if the other service supports it.

This also means that all communication between your email program and Runbox now uses TLS 1.2 (if supported by your email program).

 

Continue Reading →