Data Security Compliance

Information processed by MobileTrack through MobileTrack Nexus and Azure is marked by the GDPR law^[1] ('AVG'^[2] in Dutch) as 'highly sensitive information'; this is because if the data leaks, it will have considerable consequences for individuals. This document outlines where focus on compliance is needed.

1. Leaked data can put lives at risk (e.g. from customers using panic buttons and GPS trackers because their lives are being threatened by malicious actors)

2. Leaked data can be about very vulnerable people (e.g. elderly care homes for dementia patients)

3. Leaked data can be harmful for national security and the judicial state apparatus (e.g. the courthouses that use our devices)

To summarize, this means that all of our customer data is highly sensitive, and that some of our customers have enemies that wish them harm.

With that being said, MobileTrack does not process special categories of personal data (See GDPR Article 9).

This is because MobileTrack only keeps track of GPS Objects and other devices that are used to monitor sensitive individuals or places; it doesn't know which individual is being tracked and whose actions are being processed; it doesn't need to know that.

If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation.

- Article 11.1 of the GDPR

However, we're still dealing with very sensitive data; if a malicious actor gets hold of the data, they might know whom it concerns.

Personal data which are, by their nature, particularly sensitive in relation to fundamental rights and freedoms merit specific protection as the context of their processing could create significant risks to the fundamental rights and freedoms.

- Paragraph 51 of the introduction of the GDPR

The law gives us the obligation of handling this data seriously:

1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

- Article 32.1 of the GDPR

Following the needs from Article 32 of the GDPR, we must have a number of controls within the organization and the codebase to prevent data leaks, unauthorized access, unauthorized modification, prevent transfer of data to foreign entities, handle encryption properly and prevent outage incidents.

We must also be able to withstand hacking attempts from (foreign) agents.

On this page, we will go into detail about how MobileTrack strives to uphold these laws.

The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.

-Article 25.2 of the GDPR

The implementation of this control regarding the division of responsibility between Azure, MobileTrack and the customer companies is outlined in this page:

Shared Responsibility

In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.

- Article 32.4 of the GDPR

To prevent unauthorized access or modification of data, all users (AccountDto) have been assigned a Role through Role-Based Access Control (Roles). This role - whether a default one or created by the customer company itself - comprises Permissions (PermissionValueMap)

To prevent accidental/unlawful destruction, customer companies are given two options they can decide for themselves: one is to make objects soft-deletable. (see ItemsCanBeImmediatelyDeleted) This means that if an item is deleted, it will be moved to a trash bin rather than immediately and permanently removed. If the customer company so wishes, the item will be deleted in a number of days. (see SoftDeletedItemsHasCountDown) It will then expire in a number of days as set by the customer, with the default being 28 days. (see SoftDeletedItemsDaysUntilPermanent) It will then be permanently removed, unless someone with the correct permissions returns the object before that time. The second option is that the company can enact a four-eye policy, (see RequireFourEyes) meaning that such drastic actions created by one person with the correct permissions must be affirmed by another person with the correct permissions.

To prevent accidental or unauthorised alteration, the customer company must set the appropriate permissions for the appropriate users, and can use the four-eye policy to prevent unintentional alterations of data.

To prevent unauthorised disclosure, the customer company must set the appropriate permissions for the appropriate users to prevent users from gaining access to the wrong objects. This is why, by default, users can only view (and modify, if given the permission) the contents of the environment (EnvironmentDto) they're a part of, or of its underlying environments.

In this example, user User is part of the environment Location B. This means the user knows about the existence of the GPS Object, of Location B1 and whatever items there are in Location B1, and so forth. However, the user doesn't need to know about the existence or the contents of environments the user is not a part of. This is why Location A and its properties are hidden for this user. The customer company can decide for themselves what to do in these situations; either allow the user to know about the existence of the object but to deny access, or withhold this knowledge altogether. (see HideForbiddenElements) Depending on the customer, there are different needs at play.

To prevent what the GDPR refers to as access to personal data transmitted, stored or otherwise processed. is handled through Cosmos. The database containers, like AccountRepository or DeviceRepository, are segmented into different partitions based on who owns said Accounts or GPS Objects. This means that, if we're processing data for Company A and we need to retrieve their GPS Objects, then by default we cannot retrieve GPS Objects that belong to Company B.

To prevent malicious actors from using the accounts of users, the following safeguards are being implemented:

1. A password must contain a lowercase and uppercase character, a digit and a special character, and be at least 7 characters long.
2. A password is using both a hash and a salt to prevent reverse-engineering passwords upon data breach
3. Portal uses a white- and blacklist for IP addresses. Customer companies can have their own individual white/blacklists. If a user tries to sign in from an unfriendly nation, their IP Address will be automatically added to the blacklist.
4. A user can enable Multi-factor authentication using the Microsoft Authenticator App, Google Authenticator, Twilio Authenticator, email addresses and/or SMS/WhatsApp. This can be made obligatory by their company. If a user signs in on an IP-Address they didn't sign in on before, they must first enact MFA for that location before moving on.

The list of unfriendly nations includes:

The nations of the former Soviet Union (excluding the Baltic States and Ukraine), North Korea, the People's Republic of China, Mongolia, Afghanistan, Pakistan, India, Bangladesh, Cambodia, Vietnam, Iran, Iraq, Syria, Libanon, Egypt, Libya, Tunisia, Nigeria, Sudan, South Sudan, Zimbabwe, Democratic Republic of the Congo, Colombia, Venezuela and Nicaragua

To ensure Azure remains safe, the controls for it are listed in this document:

Azure Services Zero Trust Implementation

1. Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility. [..] 5. The obligations referred to in paragraphs 1 and 2 shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects.

- Parts of Article sections 30.1 and 30.5 of the GDPR

As per law, the following actions will be logged:

1. A user modifies data
2. A user (soft-)deletes data
3. An automated process invoked a data change
4. A user logged in or out.
5. A user lets us know he is aware of a notification, like a SOS button being pressed by a client.

Logging can be extended to the following actions if need be, or be done if the customer company wishes this to happen:

1. A user views a specific dataset, e.g. somebody's account

A log contains the following contents:

1. The user performing the action. (Except for automatic events)
2. The type of action being performed
3. Where in the code base the action was being performed.
4. The customer company (or MobileTrack Support) the user belonged to
5. When the action was performed
6. The IP-Address of the user (except for automated tasks or device receivers)

Logs are segmented based on the company they belong to, and then on the impacted resource; those with the required Permissions (see ReviewLogs) can review the logs.