Security self-assessment

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).

We have completed the "Cloud Security Alliance" STAR Level 1 self-report questionnaire, which can be found here: https://cloudsecurityalliance.org/star/registry/everit-kft/

We participated in Atlassian’s Marketplace Partner Security Self-Assessment program.

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.

We participated in the “Bug Bounty Blitz” program organized by the Atlassian. Since the end of September, we have been running a public “Bug bounty” program according to the Marketplace Security Bug Bounty Program.

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)

  • 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