This article includes details about the annual security self-assessment approved by Atlassian.
The security self-assessment contains 13 security questions. Check the self-assessment program details for more information.
Below you can find the answers for these questions.
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.
For "Exalate Jira Issue Sync & more": Every customer has their own web application connected to their own database residing within own linux network.
Access to the hosts running the app is limited to the development and the infrastructure team using a ppk mechanism.
- What is the jurisdiction(s) of where this data is hosted?
Roubaix, France OVH infrastructure, as well as Canada, OVH infrastructure
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
- There is no specific structure to store sensitive data
- It might be that the data which is synchronized is containing this type of information
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.
- 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 iDalko
- Standard linux audit logging is enabled (history) and reviewed on a regular basis
- Access to the tracker application is only permitted in case this is required to resolve critical incidents, and only during a screen share session with the appropriate representative of the customer.
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.
iDalko has a documented development process based on an agreed definition of readiness and definition of done
- The development workflow for features has following steps:
- Feature/bug development is prioritized in a product backlog
- Feature is represented by an Epic, which gets broken down into individual stories during the preparation phase of the epic
- At sprint planning time top-level stories (belonging to the to-be-released epics) are selected into the sprint backlog
- Development is done on a feature branch and depending on the scope, either branch on epic, or branch on issue is selected
- Product code and unit test code is developed in parallel
- Integration test are run at every commit and problems resolved
- Whenever ready, a pull request is triggered in bitbucket. All team members are included as reviewers
- Code review tasks needs to be resolved and integration tests must run green before the change can be merged.
- The commit of the merge is being integration tested and regressions addressed
- Whenever an epic is RESOLVED, quality control runs agreed test cases
- Whenever a code freeze milestone is attained, a release branch is created (branch on release)
- Regression tests are being run on release candidates built from the release branch
- At the release readiness meeting we decide for a go/no-go based on the definition of done.
- The release branch is merged into master (and develop) and the GA artifact is built from the master
- The development of patches is much shorter:
- Depending on the target release we either create a patch branch on release/x.y or on master
- The integration tests are run as a minimal acceptance gate.
- A release is built either from the master or the release branch
- iDalko is following the SEMVER standard major.minor.patch-tag, where a tag is dependent on the purpose of the build: release candidate, milestone, etc...
Do you undertake audits or other reviews to ensure that security controls are being implemented and operating effectively?
- code reviews for code changes
- All access is ssh based on a PPK scheme
- All access is monitored through slack
All bash history is collected regularly to look for suspicious activities
Are you accredited to any relevant security standards (e.g., SSAE16 SOC1/2/3, ISO27001, PCI DSS)?
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?
Penetration tests are being run on a monthly basis using penttest-tools service 2 hosts to be guarded (for the Atlassian cloud integration)
8. Notifying Atlassian
Do you have mechanisms to notify Atlassian in case of a security breach?
Yes. In case if the security breach concerns user information, we contact the customer, ensure that there is an idalko support portal issue for the incident (with the customer involved there).
Report the issue to our dev.
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?
Yes, they must receive written consent from the customer before accessing the customers environment.
Are all personnel required to sign Non-Disclosure Agreement (NDA) or Confidentiality Agreements (CA) as a condition of employment to protect customer information?
11. Managing security vulnerabilities
Do you have a publicly documented process for managing security vulnerabilities in your application(s)?
No, as described earlier.
In case if the security breach concerns user information, we contact the customer, ensure that there is an idalko support portal issue for the incident (with the customer involved there).
Describe the vulnerability in the Product Release Notes.
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 of all data + configuration
- Backup results are being monitored
- Restore methodology is fully documented tested once every quarter
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, with backup every 24 hour.