Data Security Document

The purpose of this document is to provide the reader with an understanding of how we at Atobi work with data privacy, our security policies, and incident management.

In this data security document, you will ﬁnd the main information of all the organizational and technical measures that Atobi has taken in connection to the security.

Application Security

Atobi ensures that users of the platform have access to exactly the data to which they are authorized. The security model of the application is based on:

Users: The members of your organization, managed by designated administrators within the organization. All members of the organization have a role that determines the users' rights to data access within the organization.
Chat: Shared privately in direct conversations, meaning only sender and recipient have access or shared with a group or with the organization.
Social feed: This information can be shared in the form of messages.
Groups: with memberships managed by designated administrators within the group or at the organization level. All members of a group have a role within that group, which determines their privileges. Groups have their own timelines, and content shared in the group (depending on the type of group) is only accessible to members of the group. Groups are flexible to reflect the hierarchy and access level of an organization.
Access permissions can be assigned on a module level per user or per group.

Web Security

All connections to and from the service use https with the TLS 1.2 protocol, using 2048 bit RSA keys and AES encryption, provided that clients support this as well (most modern clients do).
The older SSL protocol, which is weaker, is disabled.
Sensitive cookies are set with secure- and http-only ﬂags.
All user input is validated before processing. Special care is taken to prevent Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and SQL Injection.

Malware Protection

Malware deﬁnitions are updated regularly and automatically.

Authentication and Passwords

Atobi API Authentication is based on OAuth 2.0. Access tokens have a length of 100 bytes, are generated using OpenSSL's pseudo-random byte-string generator, and have a lifetime of 24 hours, after which they need to be refreshed.
All active access tokens are revoked when a user changes their password.
Passwords have a minimum length of 6 characters, must contain at least one lowercase character, one uppercase character, and one non-alphabetic character.
Passwords are stored as salted hashes using the BCrypt algorithm, so Atobi does not know the actual passwords.
To change a password, a user must always provide the old password.
When a password is forgotten, a user can request a password reset. A secret link to reset the password is sent to the user's primary email address.
Passwords are never stored on the user's device or in the browser. Instead, an OAuth token is stored securely.
The token is cleared when the user logs out or the token expires.
Authentication tokens expire automatically when not used for a longer amount of time.

Encryption

Data is encrypted in transit and at rest.
All communication over public networks uses HTTPS with TLS 1.2 (where supported by the client). RSA keys have a length of 2048 bits.
The older, weaker SSL protocol is disabled.
Passwords are stored as hashes, using the highly secure BCrypt algorithm.

System Architecture

The Atobi application consists of a few main components, all of which are hosted on the Amazon Web Services (AWS) cloud.
We can identify the following main components:
1. Mobile/Front-end application
2. API services and Administration module
3. Data persistence layer
4. Messenger service

Mobile/Front-end Application

The front-end application is created as a single-page application (SPA). As such, the relevant source files are downloaded to the browser only once, and all of the actions on the application are backed by API calls without reloading the page. To ensure that the application gets loaded as fast as possible to all clients, the application files are optimized to be as small as possible and distributed using a global content distribution network (CDN). As the application files are static, they are hosted from a CDN/object storage hosting solution which ensures no downtime and provides a fast response to user requests.

API Services and Administration Web Module

The API service and administration module are the components that the client front-end application talks to when the users interact with the website/application. The components are running on an auto-scaling server group that is accessed through a network load-balancer. This ensures that the API responds to user requests quickly, even on high load, and self-heals in case of infrastructure outages.

Data Persistence Layer

Data persistence is ensured by two technologies.

For user data, a database layer is used. It is set up to provide high availability and quick response. In addition to protecting the application from outages, it also allows changes to the database engine configuration with no downtime.
For user-uploaded data, an object storage solution is used. This allows simple yet resilient storage for uploaded content. The object storage solution exposes the uploaded user files directly through the CDN, ensuring fast response times to the user requests.

Messenger Service

Messenger service is designed in such a way that allows scaling it both vertically and horizontally.

This is implemented both in the application layer and in the data persistence layer of the messenger service. Due to this, it is possible to provide real-time messaging services to thousands of users. The messenger service is set up on a parallel infrastructure layer which allows us to host it independently of the main API\admin services. In addition, it is possible to spin up completely independent messenger service components for specific clients.

Protection of Servers and Infrastructure

Access to the production environment requires a VPN connection with mandatory 2- factor authentication.
On all servers, all ports and services are blocked by default and only opened when services are required.
Atobi servers are provisioned using a centralized conﬁguration management system which ensures uniﬁed secure conﬁguration across all servers. Version control is applied to all conﬁguration data.
A limited group of senior system engineers has access to the servers in the production environment.
All services are protected by ﬁrewalls.
The Least-privilege principle is applied.
Security-critical patches are installed within 24 hours of availability.
Atobi servers are automatically protected against DDoS attacks.

Logging And Monitoring

Operations performed by users in the application are logged to a centralized audit log.
24/7 monitoring and automated alerting ensure Atobi system engineers can act quickly in case of service disruptions.
Server logs relevant to security are stored in a centralized way and are subject to analysis and automated alerting.

Disaster Recovery, Backup, and Redundancy

Atobi guarantees 99.95% uptime, excluding scheduled maintenance windows.
All customer data is backed up once a day and kept for one month so that data can be restored in case of an emergency.
All critical services are set up redundantly to ensure high availability, in most cases with fully automatic failover.
Atobi's disaster recovery plan helps .to recover services in the event of a disaster quickly.

Data Center

Atobi's data center is operated by Amazon Web Services, Inc., which is ISO 27001:2013 certified.

Security During Development

Atobi development environments are separated from testing and production environments.
Production data is never used for testing purposes.
All changes to Atobi code are peer-reviewed by senior developers who have extensive knowledge of application security. The application is developed according to industry best practices, and measures are taken to prevent vulnerabilities listed in the OWASP Top 10.
Production data never transferred out of the production environment to test environments.

Security Audits, Automated Tests, and Penetration Tests

The access controls of the application are subject to automated tests, which are run on every change and every release.
All changes to the application are subject to an extensive suite of API and integration tests and unit tests, and static analysis.
Customers are permitted to conduct their own penetration tests on request.

Management and Organization

Risk assessment and business impact analysis are carried out regularly.
Information Security Awareness training ensures awareness of security risks and controls among all personnel.
Developers are required to demonstrate in-depth knowledge of security topics before employment.
To protect sensitive data, Atobi employees sign a non-disclosure agreement upon employment.
A clean desk and clear screen policies ensure conﬁdentiality at the Atobi oﬃces.
Employee workstations are required to have strong passwords, full-disk encryption, and automatic screen-lock.
Atobi's Password Policy requires that employees use strong, unique passwords for all systems used and that additional measures such as 2-factor authentication are applied when possible.
Information classiﬁcation policies, together with documented information and asset handling procedures, ensure conﬁdentiality, integrity, and availability of sensitive information.
All policies have identiﬁed owners and are reviewed regularly.
Access Management procedures ensure that employee access to systems is granted and revoked when changes occur, such as onboarding, termination of employment, or changes in roles within the organization.

Compliance

Atobi is GDPR compliant.

Atobi will direct law enforcement requests to the customer unless legally prohibited so that the customer can decide whether to produce the requested information or oppose the request.