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
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:
- 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
- CSA/CCM report: https://aws.amazon.com/compliance/csa/
- TISAX report: https://aws.amazon.com/de/compliance/TISAX/
- GSHB report: https://aws.amazon.com/de/compliance/bsi-c5/
- PCI/DSS report: https://aws.amazon.com/de/compliance/pci-dss-level-1-faqs/
- SOC2/Type2 report: https://aws.amazon.com/de/compliance/soc-faqs/
- ISO 27017/18 report: https://aws.amazon.com/de/compliance/iso-27017-faqs/
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.
- SOC 2 Type II: https://auth0.com/blog/auth0-achieves-soc-2-certification/
- HIPAA BAA: https://auth0.com/learn/why-hipaa-compliance-is-vital-your-business
- Gold CSA STAR: https://cloudsecurityalliance.org/star/registry/auth0/
- PCI DSS Compliance
- GDPR: https://auth0.com/docs/secure/data-privacy-and-compliance/gdpr
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:
- Changes to operational and production systems are proposed by directors and employees of Anchorpoint Software GmbH.
- The executive board evaluates the proposed changes, assessing potential outcomes for the business and potential negative security impacts.
- 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.
- Anchorpoint’s development team implements the change.
- 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.
- 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
- Dennis Schlösser (CTO) | d.schloesser@anchorpoint.app | +49 1525 6159087
- Jochen Hunz (representation, Head of RnD) | j.hunz@anchorpoint.app | +49 178 7238643
- Matthäus Niedoba (representation, CEO) | m.niedoba@anchorpoint.app | +49 176 81678167
Critical services
- Anchorpoint backend server
- Kubernetes cluster with RabbitMQ message broker
- 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
- Notify the CTO and CEO
- Identify the cause responsible for the disaster. This is normally done by the CTO during the emergency meeting
- 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
- Prepare production system
- Turn off the Anchorpoint server. This will activate the offline mode in the Anchorpoint Desktop application
- Restore the database backup to a new AWS RDS Instance
- Test the backup on the staging system first
- Redirect the staging server to the new AWS RDS Instance
- Test the staging system using Postman to check that the data is valid
- Test the staging system using a Desktop application using the deployment test checklist
- If successful, move to the next step. If failed, redo the backup procedure
- Rollout the backup on the production system
- Redirect the production server to the new AWS RDS Instance
- Restore the S3 bucket backup
- Activate the Anchorpoint production server
- Test the production system using Postman to check that the data is valid
- Test the system using a Desktop application using the deployment test checklist
- Delete the old AWS RDS Instance
- Inform the CTO that the backup is complete
- 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).
- 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. - 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. - 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. - 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. - 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".
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.
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.
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.
