1. Customer data
Do you store customer data from the customer Atlassian instance? If so, please outline any protection mechanisms you will have in place to protect this customer data.
Yes, we store customer data.
We store:
the unique ID of Atlassian Cloud products and the necessary secret keys to act behalf on the currently logged in user
SEN number
client's base URL
Worklog data
error logs data
The data is not encrypted and stored in the same form as we receive from Atlassian. All data except the atlassian_addon_client table is stored separately in a separate database for each Atlassian product instance.
Access to the hosts running the app is limited to the development and the infrastructure team. They can only SSH in from a specific IP address. Only the https port is open to the outside world.
What is the jurisdiction(s) of where this data is hosted?
Everit uses Amazon AWS for hosting Cloud apps to comply with all local laws. AWS has numerous security certifications and Everit implements many further security controls to safeguard data. AWS has all access/audit log devices that we monitor regularly. Our cloud solutions currently run out of AWS presences in the European Union with locations in Frankfurt. The Amazon Privacy Notices is here: https://aws.amazon.com/privacy/
2. Sensitive data
Is your application designed to store sensitive information?
For example Credit card data, Personally Identifiable Information, Financial data, Source code, Trading algorithms or proprietary models
No, we do not store any sensitive information. We only store work log information:
In order to be able to provide high performance and fast response times in the Timetracker Application, we synchronize the work logs from Jira Cloud Instance to our servers. We do a full synchronization of work logs when the application is installed and keep the two systems consistent afterwards with regular incremental synchronization tasks.
3. Security Policy
Do you have an Information Security Policy with supporting Standards and Procedures?
Please provide details or provide a copy of the policy.
Information Security Policy of EverIT can be found here: Information Security Policy
Details of the company security program:
Access to the hosts running the app is limited to the development and the infrastructure team using a PPK mechanism
There are contractual NDA's in place for all employees and contractors of Everit
Standard Linux audit logging is enabled (history) and reviewed on a regular basis
Everit uses Amazon AWS for hosting Cloud apps to comply with all local laws. AWS has numerous security certifications and Everit implements many further security controls to safeguard data. AWS has numerous monitoring and alert tools that we are using.
Other details are described in our Data security and Privacy policy
4. Release management
Do you have formal change control and release management processes to manage code changes?
Please provide details or provide a copy of the documented process.
Yes, we have a formal release management process.
We are working with fill CI/CD pipeline and with Kanban workflow adapted to it.
Development and release process:
Requirement analysis and backlog grooming
Specification of the task (reproduction, acceptance criteria)
Assigning the task, creating development branch and implement it
Code review and integration tests must run green before the change can be merged
The commit of the merge triggers the integration and functional tests
If the tests accepted, the development branch is merged and the new build is deployed to our development/test environment
On the test environment, we do the acceptance tests
If AC passed, merging to master and deploying to the production environment
Patches:
Patch branch for bug fixes then merges to the development and master branches
Hotfixes are merged on the master
Integration tests are run as a minimal acceptance gate.
Release is built either from the master or the release branch
Release is built always from the master branch then deployed on the production environment
We are using the SEMVER standard in our internal components and generated build numbers on our deployed cloud apps.
5. Audits
Do you undertake audits or other reviews to ensure that security controls are being implemented and operating effectively?
No, we only perform:
code reviews for code changes
regular review of our processes and systems
continuous monitoring
6. Accreditation
Are you accredited to any relevant security standards (e.g., SSAE16 SOC1/2/3, ISO27001, PCI DSS)?
No, ISO27001 accreditation is in the scope of 2020. We also operate an ISO 27001:2013 compliant information security management system (ISMS) which is audited regularly (but not certified at the moment).
7. Penetration testing
Do you undertake penetration testing or similar technical security testing, code review or vulnerability assessment?
Are you able to provide copies of results/findings?
Yes, we perform regularly:
code reviews for code changes
penetration tests for our cloud apps
We consequently follow secure coding practices. Secure coding is the practice of writing software that's protected from vulnerabilities, like buffer overflow or code injection flow, etc.
To identify the security vulnerability classes we use the OWASP recommendations and acknowledgements as it is described here: https://www.owasp.org/index.php/OWASP_API_Security_Project
Also, we ensure our testing covers the latest OWASP top 10 just as Atlassian recommends in the Vendor Security Guideline: https://developer.atlassian.com/platform/marketplace/vendor-security-guidelines/
We regularly examine our systems to discover and identify vulnerabilities. Our systems are tested by OSCP certified experts. The tests were performed by an external 3rd party testing lab called cclab.hu.
In the last penetration testing (before version:1.1.1-AC, build:1001001, release date:2019-10-09) we have found and resolved these problems:
lack of CSRF protection,
possible Denial-of-Service (DoS) vulnerability,
CSRF for JSON using Flash
According to the testing we build a penetration test report which includes the risk level, the short description or category, recommendations and reference to available public vulnerability description.
To solve these (or other found) problems we generally use the OWASP's cheat sheet series: https://cheatsheetseries.owasp.org/
8. Notifying Atlassian
Do you have mechanisms to notify Atlassian in case of a security breach?
Yes. we use a dedicated Slack Group in case of any incident e.g.:
Automatically detected by the monitoring system when it happened
In the case of operator detection
Based on customer notification (email/support portal)
If the detected incident/security breach concerns user information:
we contact the customer,
we contact Atlassian (if necessary)
We create an App Security Incident ticket upon the detection.
publish the security breaches or vulnerabilities with the proposed solution of the problem on our website,
ensure that customers can report security breaches or vulnerabilities to us on our support portal or on our email address
We raise a ticket in our Jira with the highest priority, notify our developers and administrators, and fix it as soon as possible.
In case if the breach concerns Atlassian infrastructure, we report an issue to the ecosystem service desk, notifying the Atlassian staff about the vulnerability, we link the issue to our customer service desk issue and ensure that all the customer support team members have access to the Atlassian support issue.
9. Employee access
Do your employees (e.g., developers or system administrators) have access to Atlassian customer data?
How is this access controlled and monitored?
Our support team has access to Cloud apps and may access customer data only for purposes of Cloud app health monitoring and performing system or Cloud app maintenance, and upon customer request via our support system. Only authorized Everit employees have access to Cloud app data.
10. Confidentiality
Are all personnel required to sign Non-Disclosure Agreement (NDA) or Confidentiality Agreements (CA) as a condition of employment to protect customer information?
Yes.
11. Managing security vulnerabilities
Do you have a publicly documented process for managing security vulnerabilities in your application(s)?
In case if the security breach concerns user information:
we contact the customer,
we contact Atlassian (if necessary)
publish the security breaches or vulnerabilities with the proposed solution of the problem on our website,
ensure that customers can report security breaches or vulnerabilities to us on our support portal or on our email address
We raise a ticket in our Jira with the highest priority, notify our developers and administrators, and fix it as soon as possible.
The process described above is an internal initiative and not published yet.
12. Disaster recovery
Do you have Business Continuity and/or Disaster Recovery Plans?
If Yes, please provide details including backup and redundancy mechanisms.
All systems are based on mirrored disk configurations
Daily backup our environment
Backup results are being monitored
We do not backup the customer data (worklog data) because the data is stored on Atlassian's Jira, we only sync it at intervals
In case of AWS problem:
We'll try to restore in another EU zone if something happened to the Frankfurt data center.
If no other EU zone is available, the service will be paused.
In case of an app problem, restoring from backup may be an alternative to restoring the service.
Informing registered customers since the last backup
Mailchimp list notification
Worklogs that have been added since the last save will be re-synchronized
13. Data recovery
Do you have capability to recover data for a specific customer in the case of a failure or data loss?
Please outline your processes and recovery capabilities for data loss including time frames.
What is the maximum data loss period a customer can expect?
Yes
Our backup data is securely stored, unauthorized access of backup data is not possible.
We backup customer information every 5 minutes.
We do not backup the customer data (worklog data) because the data is stored on Atlassian's Jira, we only sync it at intervals
We backup our latest deployed app and our environment at least once a day, and we keep the backups for a day