Trust in draw.io for Confluence - Security, Privacy, Compliance

Do you have any certifications for your apps on the Atlassian Marketplace?

The apps draw.io Diagrams for Confluence and draw.io Diagrams for Jira are offered by Seibert Media GmbH in Wiesbaden, Germany and produced by JGraph in Northhampton, England. JGraph also runs the servers for special features of the Cloud offering. Those two companies are working on company certifications. Seibert Media will obtain an ISO/IEC 27001 certification. JGraph is working on a SOC 2 certification. Contact us to get an update about our current status in this process.

What rights are granted to me when I confirm the End User License Agreement (EULA) for draw.io Diagrams for Confluence Cloud?

By confirming the draw.io EULA, the user can see which rights are granted to him. Furthermore we inform our customers about the service, the support channels and the warranty by us.

The draw.io Diagrams for Confluence Cloud EULA can be viewed in detail here: draw.io Cloud EULA – End-User Licence Agreement for Atlassian Cloud.

Do you have a user access approval process in place? If so, how is user access governed and granted for users who have access to the OS, DB, or whatever constitutes a service that the application runs on or integrates with? (i.e., is access based on job description and/or responsibility?) We are asking if you have an access approval process in place at your organization (Seibert Media GmbH)? Is access to Seibert Media’s OS, DB, Servers based on job description?

This answer describes the policies at Seibert Media. We highly encourage our partners and subcontractors to apply the same or higher standards in their organizations.

Yes, we have a strict and coherent access approval process in place. Our central IT department manages it and decides who is granted access to which assets. And our information security management system (ISMS) is governing it. We have a dedicated team of three people working on the ISMS. OS, DB and other server based accesses for our hosting clients are dependent on job descriptions and roles. All passwords for web applications will be granted individually and have to be applied for by each employee individually. 

Please also note that no one at Seibert Media or our sub-processors has access to your servers or diagram content. Ever. (Unless you explicitly and manually share it.)

Do you have a process in place that ensures user login IDs, that have OS, database, application access, are disabled in a timely manner (e.g., within 1 hr, 12hrs, or 24 hrs, etc.)? And if so, when is access removed subsequent to employee termination? We are asking if you have a process in place to remove user access to systems after employee termination at your organization (Seibert Media GmbH)? When is access removed to Seibert Media’s systems?

This answer describes the policies at Seibert Media. We highly encourage our partners and subcontractors to apply the same or higher standards in their organizations.

Yes, we’re using a central and web based password manager called TeamVault. Each access to passwords has to be approved by our IT. Each individual access is put in our audit log. Passwords are rotated automatically if the service offers that. Otherwise we’ll rotate passwords manually. If user’s leave the company they automatically lose access to all passwords and access credentials and third party services are marked for password rotation.

Our partners use industry-standard password management software as well and protect user credentials from leaking outside the organization.

Do you have a process in place that ensures segregation of duties (e.g., the requester is not the approver, etc.)? How is privileged access approved? (i.e., Is access approved by authorized personnel?) We are asking if you have a process in place at your organization (Seibert Media GmbH) that ensures segregation of duties with your employees?

It is impossible in TeamVault to approve your own request for a password. Access is only approved by authorized personnel through TeamVault. All access is logged in an audit log. We have a process that ensures that duties are segregated and everything is logged and transparent for review.

Do you have a process in place that logically partitions our data from other customer data? Does each customer have their own database and/or subnet (only applies to Confluence Cloud, as draw.io for Confluence Data Center and Server are running behind your firewall)?

The editor of draw.io runs in your browser and loaded with the diagram from your Confluence Cloud instance. The final diagram is saved to your Confluence Cloud instance. So there is no need to logically partition your data from any other customer data, as all of our customers save their diagrams to their Confluence environment at any time. Atlassian Cloud handles the saving and storing of diagrams.

Do you have a change management process in place? If so, what are the process control requirements?

We aren't running a defined change management process. Instead, we are a customer demand-driven company, enabling our users to suggest new features and changes to our tool (see our public Github repository). If requests get enough votes from the community, are relevant, and fit our strategic goals, we will check if the feature can be implemented and eventually start building it.

Do you have access to our instance of the application and/or data? If so: Is your vendor access removed upon application go-live? What is the timeline when your access is removed? Is there an elevated support period or ongoing support access that is governed by us?

We don't have access to your data, as all of your diagrams are stored in Confluence (see answers above). A few services can't run in your browser (such as PDF creation and a few import functionalities, this only applies to draw.io for Confluence Cloud) that require a separate server. Please have a look at https://drawio.link/datagovernance for details. You can enable our data governance feature to match Atlassian’s data data residency location in all our cloud products. We also locate all of our endpoints in the EU, in Germany, specifically. This means that if you are located in the EU, processing of data sent externally only occurs within the EU. Furthermore, you can even disable the features to limit the endpoints to your browser and Confluence Cloud. When using our external server for rendering, e. g. a PDF file, your data is (of course) always encrypted, securely transmitted, and deleted from the server, once it has been provided to you.

Do you perform static and dynamic scans on updated code? If vulnerabilities are identified, how are they remediated in a timely manner?

Detectify is used for automated web app scanning. Vulnerabilities go into Jira with a specific security tag that starts an SLA process for that ticket and escalates automatically.

What do you use for system hardening across your various assets (i.e., servers, workstations, mobile devices)? What benchmarks, if any, are being used?

For dev machines, we use jamf. For AWS servers we use Trend Micro.

Do you have an established process in place for security patch management for their application? If so, what is the established frequency of the security patch deployment (i.e. Quarterly, Annual, etc.)?

We are running a continuous process when it comes to security patches. Once the need for a patch is discovered, we are working on a fix and automatically roll it out to your draw.io for Confluence Cloud subscription (no need to install a patch). For draw.io for Confluence Data Center and Server, you need to update draw.io to install the patch. There is no established frequency, as we roll out patches once there is a need for it. But we usually update draw.io every two weeks.

Do you have a process in place for vulnerability management? If so, have you defined a vulnerability remediation methodology based on severity (i.e., time frame of remediation per severity ranking, etc.)?

Our team that is working on Seibert Media’s ISO certification is also working on our vulnerability management. With a common vulnerability scoring system (CVSS) we are ranking the risk potential of vulnerabilities of our software products and plan timely actions based on this assessment. We’re using privacy, integrity and availability as core dimensions for the definition of vulnerability issues. For vulnerabilities in software products from other vendors (e.g. Atlassian Software, OS packages), we use the vendor’s scoring. If there is disagreement regarding the classification in the specialist departments (development or IT), the ISO team is consulted. For vulnerabilities with a very high risk, we develop quick workarounds, e.g. in the form of blocking unsafe functions in the web application in the reverse http proxy. In the meantime, a sustainable software patch is being worked on and deployed.

Do you have a process in place for encrypting sensitive data that is at rest and in-transit (i.e., disk, database, URL parameters, only applies to draw.io for Confluence Cloud)? 

Data is encrypted during all network transmission to and from the endpoint. Storage is handled by Atlassian Cloud, which also offers encryption at rest and in transit. All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Data drives on servers holding customer data and attachments in Jira Cloud, and Confluence Cloud use full disk, industry-standard AES-256 encryption at rest.

To learn more, please see Atlassian’s Security Practices page.

How do you ensure that draw.io is continuously working on the security of their Atlassian apps and closing security gaps?

We are part of Atlassian's official Bug Bounty Program, which supports app vendors in detecting vulnerabilities in applications and services. Atlassian partners with Bugcrowd, one of the leading crowdsourced security platforms. Bugcrowd uses the collective creativity of a global hacker community to discover and fix software vulnerabilities. In addition to the official Atlassian program, we naturally always take care to prevent bugs from occurring in the first place. Furthermore, we are in a continuous exchange with our users and offer the possibility to report bugs quickly and easily via our Github repository. 

Where is my diagram data stored in Atlassian Confluence and Jira? How about third party servers or usage tracking?

draw.io for Confluence and Jira (Server/Data Center)

Your draw.io data is exclusively stored on the server that you are using to run your Confluence or Jira deployment. No diagram data ever gets tracked or saved to a source outside your deployment or used by one of our servers or third party services. In the default setup, no diagram data is ever sent externally under any conditions. There is an option to connect to an external image generation server to improve font support the draw.io PDF export. Note that this is disabled by default and PDF export is still available by default, just with limited font support.

draw.io for Confluence and Jira (Cloud)

Your user authentication is only stored in your browser. Saving/loading your diagrams is directly between your browser and Atlassian's servers, these operations do not transit through third-party servers. All of the primary data stored in your Confluence and/or Jira instance will reside on servers in your chosen region due to Atlassian's data residency policy.

A few extended features (export to pdf, import of .vsd, .vss and .vsx files, Gliffy import and generating diagrams from PlantUML) can't be performed within your browser. When using these features, the data is sent securely to the draw.io server endpoints. Data is encrypted during all network transmission to and from the endpoint. Once it has been successfully returned, all data is deleted from our servers, nothing is persisted. In the draw.io standard plans for Confluence Cloud and Jira Cloud, we’ve implemented the data governance option, which lets you specify the draw.io server endpoints region. → How to define endpoints

Using the draw.io lockdown option, you can additionally restrict data transmission to only between your browser and your Confluence Cloud instance (and effectively disable the features described above).

We don't track who uses draw.io and how it is used. Be sure to not find any third-party code embedded in our software. 

Linking to diagram data outside of Atlassian deployments

draw.io offers to embed existing diagrams from the web service/desktop solution diagrams.net. These diagrams will only be linked to the Confluence page if you manually choose so. There is no possibility to edit the diagram with the Atlassian deployment. It's a view only mode for cloud-based diagrams from Google Drive or other cloud hosting services. If you like to embed these diagrams into Confluence, drag and drop the XML files on a blank drawing canvas.

Does Seibert Media GmbH have a SDLC process?

Seibert Media is using agile methodologies like Scrum and Kanban for software development. We do have communities of practice for ideation, planning, and analysis of business challenges, design and user experience, implementation and software development, maintenance, and operations.

Does draw.io meet ISO/IEC standards?

Because your diagram data is not shared or stored outside of your device and the platform where you save your diagram, draw.io can help you achieve certification under the ISO 27000, 27001 and 27002 standards, the three worldwide standards that cover data protection.

Along with the comprehensive and integrated Confluence revision history, your draw.io diagrams will help you get certified under ISO 19011 (auditing and quality management systems).

More information about data privacy and security

Please also refer to our Data privacy section and our //SEIBERT/MEDIA - End User License Agreement to learn more on how we protect your data and make it secure. There is also a blog post on data security from 2018 that you may be interested in.