FAQ

This page will be dedicated to answering many of the common security and privacy related questions. These questions focus mostly on our cloud based applications for the Atlassian and monday.com ecosystems.

Architecture

What does the architecture of your applications look like?

All our cloud applications are cloud-hosted multi-tenant SaaS applications that utilize cloud computing service offerings from Google Cloud Platform (GCP) and Firebase as the core building blocks.

While there can be distinctions between our apps regarding architecture and data flow, the most common approach to delivering the web application is through a single cloud function, which in turn reaches out to Firestore and other cloud functions

Tenants are segregated by the installation and authentication methods provided by the ecosystem's host product.

Do you maintain separate environments for testing and development?

We maintain three separate environments for production, testing and development. These environments are all logically segregated to protect and isolate the data.

What technologies do you use?

Our applications are programmed in the Clojure(script) programming language. Besides the dependencies from Google Cloud Platform and Firebase we use awesome tools like: Fulcro, Reitit and Pathom.

Do I need any software to use your application?

Our applications are closely integrated with the Atlassian and monday.com ecosystem. This means that on any device you can access those ecosystems, you'll likely be able to access our applications. Though we recommend a desktop web browser for most of our applications.

Do you provide SAML and SSO capabilities?

No, not directly. As will be explained in the following section, we rely on the capabilities of the host ecosystem.

Authentication

Are there authentication mechanisms in place before users can access the applications?

Yes

How are users authenticated to the applications?

Our apps integrate with Atlassian's and monday.com's third-party authentication mechanisms. Customers are authenticated to our applications using a JSON Web Token (JWT) provided by the host ecosystem product.

How does an Atlassian JWT token authenticate the user?

The high-level steps in creating a JWT token are:

  1. Create a header JSON object.

  2. Convert the header JSON object to a UTF-8 encoded string and base64url encode it. That gives you encodedHeader.

  3. Create a claims JSON object, including a query string hash.

  4. Convert the claims JSON object to a UTF-8 encoded string and base64url encode it. That gives you encodedClaims.

  5. Concatenate the encoded header, a period character (.) and the encoded claims set. That gives you: signingInput = encodedHeader+ "." + encodedClaims.

  6. Compute the signature of signingInput using the JWT or cryptographic library of your choice. Then base64url encode it. That gives you encodedSignature.

  7. Concatenate the signing input, another period character and the signature, which gives you the JWT token: jwtToken = signingInput + "." + encodedSignature

The high-level steps of decoding and verifying a JWT token are:

  1. Extract the JWT token from the request's authorization header (using a jwt query parameter is deprecated)

  2. Decode the JWT token without verification. This gives you a header JSON object, a claims JSON object, and a signature.

  3. Extract the issuer (iss) claim from the decoded, unverified claims object. This is the clientKey for the tenant - an identifier for the Atlassian product making the call, which should have been stored by the app as part of the installation handshake.

  4. Look up the sharedSecret for the clientKey, as stored by the app during the installation handshake

  5. Verify the signature with the algorithm specified in the header's alg field. sharedSecret is used to verify HS256 algorithm, and for signed lifecycle callback events with RS256 algorithm verify using a public key.

  6. For JWTs with a computed qsh value, verify the query has not been tampered by Creating a query hash and comparing it against the qsh claim on the verified token.

  7. For context JWTs and session tokens, the qsh claim will be present but will be a fixed value 'context-qsh'. Standard qsh validation will fail on such values. You must make a deliberate decision to accept such context JWTs and session tokens on a given endpoint. Do not accept context JWTs in module or lifecycle endpoints. You should only accept one type of JWT per endpoint.

  8. Verify standard claims

How does a monday.com JWT token authenticate the user?

A successful OAuth authorization between your app, the user, and the monday OAuth server occurs in the following order:

  1. Make an authorization request and redirect the user to the monday OAuth URL with the client ID: https://auth.monday.com/oauth2/authorize

  2. The user sees the permission scopes your app is requesting and approves the request.

  3. The user is redirected to a defined URL (redirect URL) with a temporary authorization code in the query params after approval.

  4. Your app's backend sends a POST to the token request endpoint with this code. The token endpoint will respond with an access token. The access token gives your app access to the monday API on behalf of the user and will be valid until the user uninstalls your app.

The high-level steps of decoding and verifying a session token are:

  1. Extract the token from the request object

  2. Decode the token using apps client secret

Do the applications store passwords?

No

What is the password policy used by employees?

For the software and hardware we use, the following password policy applies:

  • A randomly generated password consisting of at least 20 characters

  • A minimum of four words that are completely incoherent is also allowed if it is not a network password

  • Do not reuse passwords (including a password that you use for private purposes)

  • The use of capitals, numbers and special characters are optional (unless an application requires this)

  • It is encouraged to change your personal passwords periodically

Session Management

Are users automatically signed out after inactivity?

Yes

How are users signed out?

As described in How are users authenticated to the applications? users are authenticated by a token received from the host ecosystem product. These token have an expiration time indicating when the user session ends. Users must re-authenticate after this time.

If the user terminates their session, will cached data remain on their device?

We might store some preferences on the clients device between user sessions. No sensitive data is stored on the users device.

Access Control

Do the applications offer Role Based Access Control (RBAC)?

Our apps leverage Atlassian and monday.com products' role-based access control, allowing administrators to provision and manage different levels of access.

Some apps provide more detailed role options, allowing administrators to precisely define and manage user access. For more details, refer to the apps' documentation pages.

Does the RBAC ensure that cannot view or modify another user's data?

Where applicable RBAC ensures logical access to data based on assigned roles and permissions.

Can access be disabled and/or removed then no longer required?

Our apps utilize the ecosystem's role-based access control, ensuring that access management is handled directly within the ecosystem.

Our apps that have more detailed role options provide the possibility to remove access from roles.

Are employees restricted from accessing sensitive data?

Avisi Apps treats all customer data as confidential, regardless of classification. Access to confidential information is restricted to employees who are required to access such information as part of their job and only in those circumstances where access to such information is required to provide a specific service to the customer or to support the delivery of the services.

Event Logging

Do the applications maintain audit logging?

Our apps log system failures and user activity to find deviations and enable auditing of usage patterns. We also keep audit logs on the access of data within our system by employees.

Are these audit logging accessible to the user?

No, but some of our apps retain additional event logging accessible through the application's user interface.

Can employees see the audit logging?

Avisi Apps employees can access these logs using Google Cloud's Logs Explorer. More information on Logs Explorer can be found here: Google Cloud Logs Explorer.

What information is included in the audit logging?

Audit logs typically include the following information:

  • Timestamp: The date and time when the event occurred.

  • Tenant: Information about the tenant who performed the action.

  • Message: Description of what happened

Monitoring

What monitoring is in place for the applications?

Our applications are monitored on their uptime. The status of the applications can be found on their respective status pages like: https://status.atlascrm.avisi-apps.com/.

Is suspicious activity being monitored?

Currently not. We are actively working on improving our monitoring based on our audit logging.

Operations

Are there any third parties involved in the operation of the applications?

Yes. For both the Atlassian and monday.com ecosystems several third parties are involved in the processing of data. More information on these third parties can be found in our Data Processing Addendum.

How will we get notified on security incidents?

We have a detailed plan in place for handling security incidents, which includes contacting the affected customers by there technical contact information.

Do you have an Service Level Agreement (SLA)?

Yes, this is accessible in our legal documentation.

Can I request to delete my data?

We are required by the GDPR to handle any request to delete personal data.

Will my data be deleted when I stop using the application?

Personal data will be deleted in accordance with our DPA.

What backup process is in place?

Our applications are backed up daily to storage location within the same data-center, and to a storage location outside the same data-center. Once a month the backups process is verified. Twice a year a backup restore test is performed to validate the backup process.

These backups make sure we can recover data in the event of a storage malfunction.

Encryption

Do you encrypt data transit?

Yes, we enforce HTTPS on all our applications ensuring data is encrypted while in transit.

Do you encrypt data at rest?

Yes, Firestore (read Google) will automatically encrypt all data at rest.

All data that is stored by Google is encrypted at the storage layer using the Advanced Encryption Standard (AES) algorithm, AES-256. Google own and manage the keys used in default encryption at rest.

Security

Are there any security measures in place to mitigate Denial of Service (DoS) attacks?

We rely on the Google Cloud Platform to handle any DoS attempts. We have no security measures of our own in place to handle this potential thread.

What scans and tests are done to ensure security of the applications?

For our Atlassian apps we have an active bug bounty program. This program allows security researchers to test our apps for security vulnerabilities and earn money doing so.

For our Monday.com apps we in the process of arranging a penetration test.

We run regular scans on the dependencies of our dependencies for known vulnerabilities using tools like Dependabot.

Compliance

Do employees receive security training?

Yes. Every new employee receives a security and privacy awareness security training. This training will cover the importance of security and privacy within Avisi.

What certifications do you have?

We are proud to let you know that we have both ISO 27001:2022 and ISO 27701:2019 certificates, and are fully SOC-2 Type 2 certified.

If you would like to receive any of these certifications, feel free to reach out to our support portal.

Last updated