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 some customer data. 
We store:

• Tenant details like SEN number, Client's base URL etc

• Issue type and issue status ID (number)

• Worklog data

• Error logs data

The data is stored in the same form as we receive from Atlassian. All data is stored separately in a database for each Atlassian product instance.

Access to the hosts running the app is limited to the development and the infrastructure team and they can only SSH in from a specific IP address. Only the https (secured) port is open to the access the app. 

What is the jurisdiction(s) of where this data is hosted?

Trundl uses Amazon AWS for hosting Cloud apps to comply with all local laws. AWS has numerous security certifications and Trundl implements many further security controls to safeguard data. AWS has all access/audit log devices that we monitor regularly. The area of jurisdiction will depend on the client location and their governing policies.
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.

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.

Details of the company security program:

• Trundl uses Amazon AWS for hosting Cloud apps to comply with all local laws. AWS has numerous security certifications and Trundl implements many further security controls to safeguard data. AWS has numerous monitoring and alert tools that we are using.

• Access to the hosts running the app is limited to the development and the infrastructure team using a PPK mechanism

• There are NDAs in place for all employees of Trundl

• Standard Linux audit logging is enabled (history) and reviewed on a regular basis

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.

• Development and release process:

  • 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

  • During sprint planning stage, the 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

  • Integration tests 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 need to be resolved and integration tests must run green before the change can be merged.

  • The commit of the merge is integration tested and regressions addressed.

  • Whenever an epic is RESOLVED, the 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 the GA artifact is built from the master.

• Patches:

  • Patch branch for bug fixes then merges into the development and master branches.

    • Hotfixes are merged into the master

    • Integration tests are run as a minimal acceptance gate.

    • Release is built either from the master or the release branch 

• Releases are always built from the master branch then deployed on the production environment

• We use 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?

We perform the following internal reviews:

• code reviews for code changes

• continuous monitoring of our processes and systems

• review of system access logs, system audit logs, VPC flow logs and security groups

6. Accreditation

Are you accredited to any relevant security standards (e.g., SSAE16 SOC1/2/3, ISO27001, PCI DSS)?

No. Not exclusively but Trundl uses AWS for all hosting requirements.

• AWS has certification for compliance with ISO/IEC 27001:2013, 27017:2015, 27018:2019, 27701:2019, 22301:2019, 9001:2015, and CSA STAR CCM v3.0.1. Please refer ISO Certified - Amazon Web Services for details.

• AWS is also PCI DSS complaint and certified. Please refer PCI Compliance - Amazon Web Services for details.

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

• secure coding education and review, once in six months

We 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 described here: https://www.owasp.org/index.php/OWASP_API_Security_Project

Also, we ensure that our testing covers the latest OWASP top 10 guidelines as recommended by Atlassian: https://developer.atlassian.com/platform/marketplace/vendor-security-guidelines/

We regularly examine our systems to discover and identify vulnerabilities.

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

• Automatic detection system in a real time

• 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,

We ensure that customers can report security breaches or vulnerabilities to us on our support portal or on our email address. Once an issue is raised, we create 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 the 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?

For ease of resolving customer issues, our support team needs to have access to some cloud apps and may access customer data only for purposes of health monitoring and performing system or app maintenance. We exclusively do this upon customer request via our support portal.
Only authorized Trundl employees from the product team have access to this 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)?

We have necessary processes and security measures in place to mitigate security vulnerabilities.

As mentioned before, 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,

The process described above is an internal initiative and not yet published.

12. Disaster recovery

Do you have Business Continuity and/or Disaster Recovery Plans?
If yes, please provide details including backup and redundancy mechanisms.

Our disaster recovery plan covers the following:

Computer Emergency Response Plan: Who is to be contacted, when, and how? What immediate actions must be taken in the event of certain occurrences?

Succession Plan: Describes the flow of responsibility when normal staff is unavailable to perform their duties.

Data Study: Details the data stored on the systems, its criticality, and its confidentiality.

Criticality of Service List: Lists all the services provided and their order of importance.

Data Backup and Restoration Plan: Details which data is backed up, the media to which it is saved, where that media is stored, and how often the backup is done. It also describes how that data could be recovered.

Equipment Replacement Plan: Describes what equipment is required to begin to provide services, lists the order in which it is necessary, and notes where to purchase the equipment.

General approach: We backup our environment based on the client requirements and monitor the results. 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 any problem related to AWS:

• We can configure multizone deployment to set up a DR

• Backups can be configured on schedule based on our requirement (EFS backup, EBS backup and Instance backup)

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?

• We backup our latest deployed app and our environment at least once a day, and we keep the backups for a day

• Our backup data is securely stored. Unauthorized access of backup data is not possible

• We backup non sensitive client information required for functioning of the app

• We do not backup the customer worklog data as the data is stored on Atlassian's Jira instance

We can recover data from the three types of backups available.

• Instance recovery from AMI backup

• Snapshots which can be restored for EBS volume recovery

• EFS backups can be restored for shared directory and files