Security Infosheet

This document was last updated on January 11, 2023

Intro

The purpose of this document is to summarise the technical architecture of Anchorpoint, including the security and privacy measures implemented by Anchorpoint to protect customer data.

About Anchorpoint

Anchorpoint is a Version Control and Digital Asset Management (DAM) solution. Its purpose is to facilitate the organization of files and tasks within projects that involve the creation of digital content such as video, real-time 3D graphics, animation, or still images.

Creating this type of content requires complex file exchanges and file structures, which Anchorpoint helps to organize. It provides a set of tools that includes version control, tagging, search, and comments & annotations directly on a file, without uploading it to a cloud server.

Anchorpoint is a desktop application, designed to work like a file browser that manages metadata (tags, annotations, comments, and so on). Users provide their own (mostly existing) solution for file storage, and Anchorpoint reads the files on that storage and adds the metadata.

Why do companies work with Anchorpoint?

Content production facilities use Anchorpoint to ensure smooth collaboration between members of a content production team and to organize assets and tasks.

Reducing costs

Due to having a single source of truth for assets and tasks, companies save time and money on searching for information. Data does not need to be duplicated, which is the case when using multiple tools. With Anchorpoint's flexible integration and extension capabilities, there is no need to develop an own asset pipeline solution, as Anchorpoint can be adapted to any pipeline.

Reducing risk

Anchorpoint ensures that everyone is kept up to date with the latest project development state. Issues such as working on the wrong file version or missing an approval are minimized.

Increasing productivity

Mundane, repetitive tasks can be automated and reduced to a minimum with the help of Anchorpoint's shortcuts and utilities.

How does Anchorpoint deal with files?

Anchorpoint does not modify any of the project data, such as videos, images, 3D models, Blender, Nuke files, etc. This data is typically stored in Dropbox, Google Drive, on a hard drive, in a Git repository, or on a network drive, and Anchorpoint simply observes the data. Anchorpoint can add metadata, such as a different thumbnail to a Blender file or comment on it.

Where does Anchorpoint store metadata?

Metadata (comments, tags, thumbnails) is processed by Anchorpoint on the Anchorpoint Server. This facilitates team collaboration and synchronization across multiple computers, enabling users to send comments with @mentions, push notifications, and easily send files via link to their colleagues. Anchorpoint stores a .approj file in the project so that it knows where project files are located.

Application architecture

General application architecture
Architecture of the Git integration

Account Information

Account information helps Anchorpoint to connect data to an existing account, and provides the necessary information for granting permission to data and features. It does not include payment information. Account information consists of:

  • Email / Social login information (e.g. Name or Profile Image)
  • Subscription tier
  • Number of purchased seats

Website

The Anchorpoint.app website allows access to the user login and is required within the login flow of the desktop application. It redirects to the user authentication (Auth0 with OAuth2) and receives a token that indicates the login status on the website. In case of payment, it redirects to Stripe payment processing.

Metadata

This is the data required to perform fundamental tasks in Anchorpoint. Metadata can be represented as projects, tags, annotations, comments, versions, or reviews; all of which are string-based data stored in a relational database.

Anchorpoint also stores binary data in the form of PNG image files, such as user-replaced file thumbnails, project icons, and customized user icons. This binary data is stored in an AWS S3 bucket.

Anchorpoint Server

The Anchorpoint server is operated by the Infrastructure as a Service (IaaS) provider Amazon Web Services (AWS). The corresponding datacenters are located in Frankfurt, Germany, with instances running on eu-central-1a, eu-central-1b, and eu-central-1c.

This entity stores the metadata using an Amazon Aurora PostgreSQL database. This data is then sent to the entitled Anchorpoint desktop application. It does not store critical user data, such as passwords and credit card information.

Desktop Application

This is the main interface that represents the metadata to the end user. It also provides the tools to create, edit, and remove metadata. The data is also stored in an offline cache to improve performance and is synced with the Anchorpoint Server. Therefore, only user-accessible metadata is synced to the offline cache. To be able to access or modify data on the Anchorpoint server, OAuth2 authorization code flow is used. An obtained refresh token is stored AES 256-bit encrypted in a local cache and has a maximum lifetime of 30 days. Refresh Token Rotation is enabled, which prevents the reuse of an already used refresh token. The according AES encryption key is saved in the platform-specific credential manager (macOS Keychain and Windows Credential Manager). Obtained access tokens are only held in memory and have a maximum lifetime of 1 day.

The Desktop Application does not have access to the user login credentials (OAuth2 flow via Auth0) or read or process any kind of payment information (only accessible in Stripe).

User Authentication (Auth0)

For managing user accounts, Anchorpoint uses the Auth0 platform by Okta Inc. Auth0 is an external provider for user authentication solutions which is certified by ISO27001, ISO27018 norms and is also SOC 2 Type II and GDPR compliant.

The user can create an account via Auth0 and can log in via authorization code flow on Auth0 and get redirected to the desktop application. The desktop application resolves tokens via the resulting code and saves them as described in the previous section.

Payment Processing (Stripe)

Payment and payment information is stored and processed via Stripe Inc. It complies to the PCI DSS norm and is certified as a PCI Level 1 service provider. No payment information is stored or transferred out of Stripe to the Anchorpoint Server. Stripe provides the following account information to the Anchorpoint server:

  • Email
  • Number of seats
  • Tier Plan Information

Further cornerstones of Anchorpoint's architecture

External Network Traffic

External network perimeters are hardened and configured to prevent unauthorized traffic. Ports and protocols are limited to those with a specific business purpose. Traffic from the public internet is only allowed to a highly available load balancer that only allows TCP traffic on ports 80 and 443. Port 80 is only allowed to forward traffic to port 443. All networks only allow the traffic that is required by our applications.

DMZ

External connections are terminated in a DMZ and the connections are recorded in event logs. The external connections are terminated at the load balancer, which is located in a DMZ-like network segment. Most traffic is immediately dropped, except for traffic on ports 9090, 80, and 443.

Inbound and Outbound Protection

Inbound and outbound points are protected by firewalls and Intrusion Detection Systems (IDS). Communications are limited to systems strictly allowed and Intrusion Prevention Systems (IPS) are used. Inbound and outbound traffic runs through the DMZ-like network segment of AWS.

DNS and IP Addresses

Ionos.com is used as a DNS provider which holds CNAME records to DNS names managed by AWS.

Data Segregation

Unless mandated otherwise, all client data within scope should be logically segregated on the service environment. If physical segregation is necessary, please contact your Anchorpoint representative.

Backups

Backups are performed daily and stored on physically separated servers (AWS S3). The backups are managed using the AWS Backup Service. Logs of the backup process are automatically created. The backup window is between 02:00-06:00 UTC.

Technology Providers

AWS

Anchorpoint's server runs on AWS (Amazon Web Services). AWS is the market leader for Infrastructure as a Service (IaaS) and provides all the necessary security and compliance requirements for our products.

Anchorpoint uses EU data center regions. Data is hosted in Frankfurt am Main, Germany, with instances running on eu-central-1a, eu-central-1b and eu-central-1c.

AWS is fully ISO 27001 certified. Further information and the certificate can be found here: https://aws.amazon.com/de/compliance/iso-27001-faqs/.

Additional certifications

Auth0

Auth0 is the authentication system that manages user accounts and generates tokens, allowing a secure connection between the desktop application and the server. This procedure follows the OAuth 2.0 protocol.

Auth0 is also fully ISO 27001 and ISO 27018 certified and complies with the following policies and certifications.

Stripe

Stripe is used to process payments and store payment information. It has been audited by a PCI-certified auditor and is certified as a PCI Service Provider Level 1, the highest level of certification possible in online payments. For more information about security at Stripe, please visit this link.

Connections between Services

Backend Hosted on AWS

Database

Runs on a private subnet of a VPC (only internal communication possible).

Application

Runs on a private subnet of a VPC (only internal communication possible). Communication to other backend components like database, message broker, or load balancer happens over non-TLS connections. No external outbound connections to external services (like Stripe or Auth0) are used.

Load Balancer

Performs TLS termination of external requests on outbound-facing port 443 mapped to internal port 80

Message Broker

Runs on a private subnet of a VPC (only internal communication possible).

External Services

Stripe

Uses a webhook over TLS connection terminated by AWS load balancer and passed to the application.

Auth0

Uses an API request for user upsert TLS terminated by AWS load balancer and passed to the application.

Client on End User Desktop Device (Mac or Windows)

Client Application

Runs on the end user device.

Daemon Service

Runs on the end user device and connected with the client application over a gRPC connection on localhost, therefore no TLS connection.

Change Management

Each change to operational and production systems is made in the following way:

  1. Changes to operational and production systems are proposed by directors and employees of Anchorpoint Software GmbH.
  2. The executive board evaluates the proposed changes, assessing potential outcomes for the business and potential negative security impacts.
  3. Major changes that affect stakeholders and customers must be communicated in an appropriate time prior to implementation. The Chief Technology Officer is responsible for obtaining approvals from affected stakeholders and clients.
  4. Anchorpoint’s development team implements the change.
  5. After implementation, the change is tested in a proper staging environment. The Chief Technology Officer is responsible for ensuring that the change has been implemented according to its requirements and has not caused any negative side effects.
  6. The Chief Executive Officer is informed of the implementation of changes.

Incident Management

Every employee, customer, and stakeholder can report an incident. Unless mandated differently, the following terms apply:

Contact in Case of an Incident or Malfunction

  • Email: support@anchorpoint.app
  • Phone: +49 176 8167 8167
  • Microsoft Teams (for internal use): using the “General” channel

Low and Medium Severity

Issues of this severity are only suspicions or strange behaviors. They haven't been proven and need more looking into. There is no sign that systems are in danger and don't require immediate action. This also includes occasional crash reports by our crash reporting system.

High Severity

High severity issues mean problems where somebody might take advantage or cause harm, even though it hasn't happened yet. Examples of high severity issues are vulnerabilities with a chance of being exploited, malicious programs on our systems, people accessing business information (like passwords, vulnerability data, and payment info), or any threats that might cause physical harm.

When high severity issues are being dealt with, the subject line of the email to support@anchorpoint.app has to be marked as "Urgent" and that @general has to be mentioned in Microsoft Teams.

Critical Severity

Critical issues relate to actively exploited risks and involve a malicious actor. Identification of active exploitation is critical to this severity category.

High severity issues should include a “Critical” in the subject line of the email to support@anchorpoint.app and an @general mention in Microsoft Teams. Furthermore, the CEO and CTO need to be contacted via direct message or phone.

Response Times

  • Low and Medium Severity: 5 hours
  • High Severity: 2 hours
  • Critical Severity: 1 hour

Recovery Times

  • Low and Medium Severity: The next scheduled software update
  • High Severity: 8 hours
  • Critical Severity: 4 hours

Response Step

The CTO is responsible for setting up an emergency meeting with the required participants to fix technical issues, as well as informing the CEO for communicating with affected stakeholders and customers. The purpose of this meeting is to define an action plan in written form that will be executed immediately. This action plan will be stored in the company wiki and will serve for communication and retrospective purposes. Stakeholders and customers will be informed immediately via email after the incident has been properly identified and after a fix has been rolled out.

Disaster Recovery

The purpose of this policy is to define the procedures for recovering Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a recovery time, as described in Chapter Incident Management, based on the severity.

Incident Response Team

  1. Dennis Schlösser (CTO) | d.schloesser@anchorpoint.app
  2. Jochen Hunz (representation, Head of RnD) | j.hunz@anchorpoint.app
  3. Matthäus Niedoba (representation, CEO) | m.niedoba@anchorpoint.app

Critical services

  1. Anchorpoint backend server
  2. Kubernetes cluster with RabbitMQ message broker
  3. AWS RDS Instance (Relational Database Service)

Backups

Restoration of a database means that a second database (which includes the snapshot) is instantiated. A redirection will point to the new instantiated database, while the existing one is still running. More information about backups can be found in the chapter on Application Architecture.

Disaster Recovery Procedure

  1. Notify the CTO and CEO
  2. Identify the cause responsible for the disaster. This is normally done by the CTO during the emergency meeting
  3. Make sure that the cause is eliminated so that the recovery next steps can take place. If that is not the case, inform the CTO
  4. Prepare production system
  5. Turn off the Anchorpoint server. This will activate the offline mode in the Anchorpoint Desktop application
  6. Restore the database backup to a new AWS RDS Instance
  7. Test the backup on the staging system first
  8. Redirect the staging server to the new AWS RDS Instance
  9. Test the staging system using Postman to check that the data is valid
  10. Test the staging system using a Desktop application using the deployment test checklist
  11. If successful, move to the next step. If failed, redo the backup procedure
  12. Rollout the backup on the production system
  13. Redirect the production server to the new AWS RDS Instance
  14. Restore the S3 bucket backup
  15. Activate the Anchorpoint production server
  16. Test the production system using Postman to check that the data is valid
  17. Test the system using a Desktop application using the deployment test checklist
  18. Delete the old AWS RDS Instance
  19. Inform the CTO that the backup is complete
  20. Prepare a report based on the template

Vendor Breach Notification

The following steps apply to all employees, contractors, and third-party service providers with access to our systems and data. This is the standard procedure when a breach is detected in one of our third party services (AWS, Auth0 or Stripe).

  1. Detection and Assessment
    Any suspected or confirmed data breach must be immediately reported to our Incident Response Team (IRT). The IRT is responsible for assessing the breach's impact, including which vendors are affected and the sensitivity of the compromised data.
  2. Notification Procedure
    Timing:     Vendors will be notified of any breach affecting their data no later than 24 hours after the breach has been confirmed and assessed.
    Method of Notification: Notifications will be sent via email from the IRT. If necessary, follow-up communications may be made via phone or encrypted messaging services.
    Content: The notification will include:
    - A description of what happened.
    - The type of data that was affected.
    - Steps we are taking to secure our systems and prevent future breaches.
    - Actions the vendor should take to protect their data and systems.
    - Contact information for further inquiries.
  3. Support for Affected Vendors
    We will provide support to help vendors assess the impact on their systems and mitigate potential risks. This may include offering security audits, sharing best practices for data protection, and providing timely updates as more information becomes available.
  4. Regulatory Compliance
    We will comply with all applicable laws and regulations regarding breach notification and data protection. This includes cooperating with vendors to meet their regulatory reporting obligations.
  5. Review and Update
    ‍    This policy will be reviewed annually and updated as necessary to reflect changes in legal requirements, industry standards, and our business practices.

Rules and Permissions

An Anchorpoint workspace is the place where members can be added and projects can be created. A workspace is connected to the subscription and the number of members that a customer is paying for. Members in a workspace can edit metadata and have the following roles and permissions:

Member

Members can collaborate in a workspace by editing metadata in projects to which they are assigned. They can also create new projects and invite members from the workspace to a project by knowing their name or email address. They cannot see or edit all the members of a workspace. They cannot access projects to which they are not assigned. Members can only add other members to projects when they have an explicit permission to edit the project settings.

Members can only be assigned to projects by:

  • Assigning them in the project settings by admins or members who have explicit permission to change project settings
  • Accessing the .approj file on the file system. Opening that file will automatically add them to the corresponding project.

Admin

Admins can do everything that members can do, but they have all the rights to modify project settings without explicit permission. They can also view all workspace members, as well as add and remove members from the workspace. Admins can also change workspace settings.

Owner

Each workspace has only one owner. An owner can do the same as an admin and change the subscription settings. An owner can purchase or remove additional seats, or cancel the subscription.

Login and Authentication Flow

The login flow assumes that the Anchorpoint desktop application has already been downloaded and installed correctly.

1. Initial State

The application has been opened and no user is logged in. To create an account, the user has to click on "Sign Up".

Anchorpoint login screen on desktop application

2. Account Creation

When the user clicks on "Sign up", a website window opens. The sign-up form from Auth0 is opened. The user can sign up via email or use a social login via Google.

Auth0 login screen in the web browser

3. Opening the Desktop Application

After creating an account, the user is landed on a confirmation website and the desktop application is started. It receives a token from Auth0, which was created during the login process before and is able to connect to the Anchorpoint server.

Confirmation that the login was successful
The application opens up with a welcome popup, where the user can edit the name, profile picture and set the name of the workspace

Data at Rest

All databases use a so-called "at rest" encryption. This means that data can only be read if proper authentication takes place on the respective database system. The files in which the data is stored are stored in encrypted form so that they can only be read by database systems that have the appropriate decryption key.

Data in Transit

Anchorpoint applies transport encryption whenever data has to be transmitted over an insecure or public network. The type of transport encryption depends on the encryption requested by the client system. Anchorpoint uses HTTPS connections with 256-bit SSL certificates for all communications with clients.

Monitoring

Monitoring is executed using a tool called Grafana to ensure maximum availability, performance, and security of the application. The monitoring includes, but is not limited to, the following parameters:

Availability

  • Availability of the application
  • Accessibility of backend systems and services

Resources

  • CPU utilization
  • Utilization of network interfaces
  • Utilization of persistent and volatile storage

Performance

  • Response times of the application
  • Response times of backend systems
  • Query times for database contents

Security

  • Update status of systems
  • Error logs
  • Access logs

Documentation

The Anchorpoint documentation can be accessed online via docs.anchorpoint.app. It describes features of the application and is updated with each new release.

Versions and Updates

Software updates are distributed approx. every 14 days via an update system that runs in the background in the desktop application.

Critical fixes are applied based on the incident management procedure in the respective recovery time.

Major versions: x.0.0

Contain significant new features that affect the entire application.

Minor versions 0.x.0

Contain improvements of existing functions, as well as bugfixes, which affect only a certain part of the application and are not classified as critical.

Hotfixes 0.0.x

Contain bugfixes (non-critical as well as critical) but no major product features.

A changelog of features and bugfix releases can be accessed via https://www.anchorpoint.app/releases. New entries are marked with the appropriate version number.

Further policies

Security
Refund policy
Eula
Terms and conditions
Privacy policy
Imprint