What data do we store in our servers in Cloud?
What data do we have access to?
When you install a Jira Cloud add-on the add-on can request certain 'scopes' of access. In Automation for Jira's case, we require READ, WRITE and ADMIN scopes. This means the add-on is granted access to all Jira REST APIs marked with these permissions on this page: jira rest scopes.
We require this access to do things like adding comments to issues, edit issues etc.
When a cloud add-on is installed, we store a public and secret key in our database. We store this so that our add-on can make authenticated requests to your Jira instance as well as receive authenticated requests from your Jira instance. This is pretty standard for any Atlassian connect add-on for Jira Cloud.
Full disclosure here - we can use the public key and secret to make authenticated REST calls to any of the REST APIs mentioned on the page linked above manually. However we have only done this in rare circumstances when we need extra information to debug a tricky support problem. We will also ask for your permission first before performing these requests. You can revoke these rights at any time simply by disabling/uninstalling our add-on in your Jira instance.
What data do we store in our database?
We try to store as little identifying information about your data (issues, projects etc) as possible in our database. Things we do store:
- Rule config information:
- Rule name and description
- Rule component config information (e.g. JQL strings used in triggers could contain project keys etc)
- Audit log entries
- We store what you see in the audit log UI basically. Issue keys & ids as well as any changes made to the issue shown on the left hand side in the audit log
- Issue Details: We store full issue details for the lifetime of the rule execution. This enables us to make our rule execution queue more fault tolerant.
We also collect Google analytics to better help us understand how our users use the front-end, so that we can build better features. We do not include identifying information however in these analytics (such as issue data, config data etc).
Myself and my co-founder have both worked at Atlassian for 10 years previously and we treat customer privacy and security seriously. We believe in full transparency around these issues. As far as we are concerned, your data is yours and we do not share your data with any third parties (unless we are legally obligated to do so - however this case has not arisen yet).
Below is a copy of our cloud security self assessment for Atlassian created at 17/Oct/18.
1a. Customer Data
- Rule configurations
- Audit logs
- Tenant info (JWT secrets etc)
We try to avoid storing identifying data as much as possible. For example we don't store issue data or anything like it.
We take protection of this data seriously. Data is stored on a AWS RDS instance in a private subnet in a VPC. Access is only possible for application code running in the same private subnets, or via ssh jumpboxes in this VPC. Application database logins and logins used by Code Barrel staff are separate (using strong passwords stored in 1password). We never store usernames and/or passwords in application code. SSH keys for jumpboxes are also a heavily guarded secret and boxes are protected with fail2ban.
1b. Customer Data
Data is hosted in the us-east-1 AWS zone in the US.
2. Sensitive Data
We don't store much 'sensitive' data.
We only have one place (the aforementioned AWS RDS production database), where access is heavily guarded and only possible by application code or via ssh jumpboxes to which only select CodeBarrel staff have access.
3. Security Policy
Our EULA covers data security and privacy concerns. Please see section '3. Data': https://automationforjira.com/license-agreement
4. Release Management
We follow agile development processes:
- All bugs/stories/tasks are tracked in Jira
- We use a public issue tracker
- All code changes are made on branches in source control and can only be merged to master after detailed review in a pull request
- Automated tests are executed for code changes and deployments
- Further manual tests are carried out when releasing
- Releasing to Cloud is automated via secure CI server (SemaphoreCI)
Our main mechanism is pull request reviews. All code is reviewed by at least 3 other experienced developers on our team before merging.
Checking for security vulnerabilities such as the following is standard practice as part of these reviews:
- Other injection attacks
- Permission issues
- JWT token validation issues
We also often carry out manual exploratory testing of individual features for security vulnerabilities.
7. Penetration Testing
8. Notifying Atlassian
Yes. We have not encountered any security breaches yet, however would this happen we would:
- Treat this as highest priority
- Immediately notify Atlassian via Marketplace
- Provide open and frequent updates to Atlassian about progress with fixes.
We are all ex-Atlassians and follow the 'Open Company, No Bullshit' approach when it comes to security (and other incidents).
9. Employee Access
Yes. We are only small with 6 employees in total currently. All our employees are experienced developers with more than 10+ years experience developing Atlassian tools & apps on average and as a result we all take great care when accessing customer data.
We control access via 1password shared vaults. Access to this vault can be revoked on a per employee basis. We also have the ability to disable access to any production data completely by disabling our SSH jumpboxes in case of an emergency (or individual ssh keys).
Yes. Our employment contract signed by all employees includes strong clauses around confidentiality, including customer data and privacy.
11. Managing Security Vulnerabilities
No we do not publish anything publicly currently.
If we were to find a security vulnerability our process is as follows:
- Assess the impact and severity of the vulunerabilty
- We'd raise this vulnerability in a private Jira issue of the highest priority (may depend on impact and severity)
- We'd immediately schedule this issue for release. We release software very often (several times a day to cloud and every 1-2 days in server)
- Fixes would have to pass through pull request reviews as well as manual testing
- Once a fix has been released we'd
- Disclose the vulnerability publicly on our blog and prompt users to upgrade
- Make the original issue public
12. Disaster Recovery
Yes. Our main issue is loss of data in our AWS RDS instance.
To prevent this we have the following in place:
- Live read-replica database in a different availability zone in the same region
- Daily snapshots of the database stored in S3 (which has very high data redundancy)
The live read-replica fail over has been tested (and in fact already happened once in production when our main database failed - no data was lost).
13. Data Recovery
Yes. As mentioned, we have daily backups stored via AWS RDS snapshots. Recovering from one of these would only become necessary if both the primary and read-replica (in a separate AZ) RDS instances failed/were lost.
If this were to happen the maximum amount of data lost for a particular customer could be 24 hours. Even so, due to the nature of our app 'Automation for Jira', it would mostly consist of audit log data. Rule configuration data isn't edited that often, so losses would be fairly small.
Customers also have the option to export their configured rules to JSON and re-import them, given them an option to backup rule configuration data themselves as well.