Update: That's a wrap! Thanks so much for your questions. If you didn't make it for the live AMA, not to worry. Add your questions below and I will get to them ASAP.
Hello Atlassian Community,
My name is Adrian Ludwig and I’m Atlassian’s CISO (Chief Information Security Officer). I look after the teams that work to prevent security threats and keep your data secure every day.
On Tuesday, May 7th at 12 pm Pacific, I'll be hosting real-time AMA to answer your questions about Atlassian’s security program and cloud security more broadly, including product security, platform, and network security, and trends in cloud security.
Here's how it works:
Add your questions below any time before or during the AMA. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.
At 12 pm PST on Tuesday you can expect to see answers from me and my team rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event at 1 pm PST, but will be sure to answer any questions we didn't get to.
Certifications is one of the most frequent questions that we get, so we have already invested in many certifications and controls to ensure that we are keeping keeping sensitive data private and secure in our cloud products. We’ve achieved SOC2 and SOC3 compliance as well as ISO27001 and ISO2701. You can see more information and download our certificates on our compliance page.
We don’t currently have HIPAA, but it’s definitely something that we are investigating building into our roadmaps for Jira Align and Jira Cloud. You can see see our Platform roadmap here with more details.
You asked about employee training. We have developed a security training and awareness program on the premise that security is everyone’s responsibility. These responsibilities are extracted from our internal Security Policy Program, and the training and awareness program is used for communicating these responsibilities to our staff.
Candidates and contractors are required to sign a confidentiality agreement prior to starting with us, and subsequently, during the onboarding process, security awareness courses are delivered to these new hires.
Keeping in line with the theme of ‘continuous improvement’, we disseminate security messages through company-wide email messages and blog posts. These messages generally carry a message that is relevant at that time, e.g. a newly discovered and publicized threat, and reinforces the importance of following security good practices.
https://www.atlassian.com/trust/roadmap?tab=compliance references Jira Agile HIPAA compatibility. As far as I know, Jira Agile is a product that is no longer supported by Atlassian. I assume it's a typo and should say Jira Software? If so, does this mean you're targeting HIPAA compliance out of the box for the Server / Data Center deployment as a first step before Cloud?
Hi @Jon Doyscher,
That’s a short questions – and it deserves a much longer answer than I’ll have a chance to provide here. But I'll give it my best shot.
For me, the two most important things have been to always be working on something that I find challenging and that forces me to learn something new every day. Ideally, I’ll do that while working with people that are challenging (in a good way!) and that encourage me to learn.
It so happens that for most of my career, security has been that field – but it’s not hard for me to imagine having a similar experience working in other engineering roles, product management roles, or even sales. In fact, there was a brief period of time where security wasn’t that much fun for me. So I took a risk and tried something different for a while: I spent several years working in product marketing – which isn’t something that you’ll find in to many CISOs but it really opened up my eyes to the range of challenges that senior executives in a business face every day. And it reinforced my belief that what is most important is not the specific field that I’m in, but that I’m working on a challenging problem and learning.
I’ll try to give a brief overview, but you can find more information on our Security Practices page on the Atlassian Trust Center.
Our threat model, at it’s highest level, considers every party that has access to our environment to be a potential threat. This includes all parties on the internet, all of our customers, and even Atlassians that have access to our infrastructure as as part of their job. We use that threat model to guide our product development (e.g. defining our security model and determining where we need to build in security features to mitigate risk), our security development lifecycle (e.g. to reduce potential vulnerabilities in our security model), and also our operating model for security. (e.g. how do we securely deploy, manage, and monitor our cloud offering).
Specific to monitoring, we have designed our cloud offering with a centralized logging service that allows a team of Atlassian security analysts to monitor for potential security events anywhere in our infrastructure. We use a combination of off-the-shelf monitoring technologies (mostly open source, but some that are provided by vendors) and custom technologies to detect and respond to potential security incidents. The head of our Security Intelligence team recently wrote blog post that provided a bit more detail about the incident management process: https://www.atlassian.com/blog/inside-atlassian/our-security-incident-management-process
I hope that helps,
What is your response/message about the news of the ransomeware attack that appears to be via Sourcetree and Bitbucket (although it also affects Github and Gitlab)?
There is more about it here:
I was going to recommend adopting Bitbucket across our organisation but it looks like a potential security risk so we will stay with what we have for now.
Still no reply from Adrian or anyone else in Atlassian to my question about this potential security threat.
Am surprised that my question was not even acknowledged. Not even a "Thanks for your question. We are looking in to this and will get back to you".
Does anyone else think this is a bit unprofessional?
Adam, you may find the response from Atlassian in the link you've posted useful.
For me the important part is: In addition, we recommend enabling 2FA on your Bitbucket account.
If someone steals your credentials, it's not much that a service provider can do. There are ways to restrict access, but I guess not many people would like, for example, to have access to their cloud instances only through a single IP address.
You're right, I missed a question. I apologize for the oversight.
We believe that this attempt at ransomware is a case of credential stuffing. Basically, that means these accounts were compromised when the account credentials were published or leaked in another location, and then an unathorized person used those credentials gain access to Bitbucket (Gitlab, Gitlab, etc.) We don't believe that Sourcetree was involved in the compromise of credentials or accounts -- Sourcetree was mentioned in some news reports because some legitimate users first noticed they had a problem when they used Sourcetree to connect to Bitbucket (or whichever service they are using to manage source code).
As @Andrei pointed out in that article -- we do strongly recommend that users enable 2FA on BitBucket (and all of your Atlassian services) to help improve protection against Cred Stuffin attacks and phishing. We do also provide automated risk analysis on login attempts to Atlassian's product , but those defenses aren't perfect, so enabling 2FA is an important additional protection.
BTW -- I used the word attempt because all affected Bitbucket accounts have been notified that they have a problem, their passwords have been reset, and their data has now been restored. Source code repositories are designed to be robust against accidental commits so they are kind of a strange target for ransomware like this.
What can you tell Atlassian customers about the new Australian encryption law, that will re-assure our risk teams we can keep data in your products?
This is an area that we have received a number of questions about, being a prominent Australian tech company.
That said, there is a lot of confusion about this law and the impact that it could have with respect to customer data. The law was written in such a broad fashion that it effects all of the major cloud service providers – it’s not specific to Australian companies, nor companies that have employees that work in Australia.
Our policy (both prior to and after the law passed) is very similar to that of all of the other major cloud service providers. We cooperate with law enforcement where we believe requests are lawful, and we will challenge the scope of the request where we believe it is overly broad. That policy is publicly available here.
We will continue to work with the Australian Government towards a solution that strikes a better balance between the interests of law enforcement and our responsibility to protect our customers and their data. We’ve published a short document urging Australia to update the law https://www.atlassian.com/blog/announcements/atlassian-urges-changes-to-australian-assistance-and-access-act
Hi @Barb O-Connell,
I can give you a quick overview and update.
All data sent between our customers and our applications is encrypted-in-transit using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.
We also recently announced that we now offer encryption-at-rest for our Cloud Services, primarily Jira and Confluence. Keep in mind, this is currently available for any new sites created after April 10, 2019. Encryption at rest for all existing sites created before April 10, 2019 is in process and will be coming soon. (This is also on our Platform roadmap. )
We will share an update in our Trust and Security group once encryption at rest for all existing sites is complete, so keep an eye out for an update there!
I hope that helps give some clarity.
We have an active bug bounty which provides continuous third party testing of Atlassian products. You can read more about the details about our approach to security testing of our products and our environments at : https://www.atlassian.com/trust/security/security-testing
At the bottom of that page, you can download roll-up reports for our Jira and Confluence cloud, Statuspage, Trello and Opsgenie. You can also sign up to be a part of our Bug Bounty at : https://bugcrowd.com/atlassian
We actively triage and fix any issues that come through either our Bug Bounty, our internal vulnerability scanning or notifications we get from customers according to our Security Bug Fix SLA : https://www.atlassian.com/trust/security/bug-fix-policy
You can also find information on our security in our Cloud Security Alliance (CSA) Consensus Assessment Initiative Questionnaire (CAIQ) and Google Vendor Security Assessment Questionnaire (VSAQ).
Basically, we’ve proactively filled out a few of the industry’s most common security questionnaires and posted that information to our website, with the goal of being as transparent as possible about our security practices and operations.
Check out those security questionnaires here - https://www.atlassian.com/trust/security/vendor-security-risk-response
We also regularly conduct security reviews with third-party consultants, as well as with our internal security team. We’re considering providing more information about those reviews in our Trust and Security group. Keep an eye out for updates there!
Hi @Michael March ,
We are constantly looking to improve how well app vendors are prepared to manage customer data. In December, we published a page for Security Guidelines for App Vendors. The main emphasis were proactive recommendations that each of the App Vendors can take to improve security practices, including endpoint, infrastructure and development practices. Read more at : https://developer.atlassian.com/platform/marketplace/vendor-security-guidelines/
We also published guidelines to help our App Vendors prepare for a security incident before they experience one. We included example incident management guidelines as well as comms templates for both a security incident as well as vulnerability reports. Read more at : https://developer.atlassian.com/platform/marketplace/app-security-incident-management-guidelines/
Longer term, we think that Atlassian has a great opportunity to encourage security best practices across the Connect app vendors. We’re working to build out a set of security services that are similar to the ones that we’ve built for our own software development teams – including analysis of source code, a bug bounty, and third-party security reviews.
Generally speaking as the CISO how do you manage security across such a large number of locations and development teams?
What things do you centralize and which things are the independent teams or products responsible for? Are there criteria you use to decide?
Hi @Shane Phelan ,
Great question, and one that I think a lot about!
At Atlassian we have a central security team that builds our security processes and infrastructure that is shared broadly across the company. And we also have an expectation that everyone at Atlassian has a shared responsibility to make sure that we build and deliver secure products. Because many of our teams (including our security team) are spread across multiple locations, we rely on Jira, Confluence, and our other tools to provide good communication and track our work.
Some examples of things that we have centralized:
The creation and management of tools that scan our software and services for potential vulnerabilities, as well as the infrastructure that we use to monitor whether security issues are being resolved in a timely fashion (e.g. within our SLAs) are centralized – but the actual fixing of issues is the responsibility of individual product teams.
Similarly, our security intelligence function, which write alerts for potential security issues and leads security investigations, is centralized, but we work closely with the teams across Atlassian to make sure that we have logging integrated throughout our infrastructure and to assist in resolving incidents as quickly as possible.
If I had to try to boil it down to a single criteria for when to centralize or when to decentralize work, I’d say we tend to centralize when we think the same approach can be used across multiple products – and we ask the product teams to take the lead where they have special skills or access that we can’t provide on the central team. But even for the decentralized efforts we provide centralized monitoring and consulting services to make sure that we have a consistent security quality across the company.
Hi @Barb O-Connell - the AMA will be on a Community thread, text only. Here's an example of one we hosted before! https://community.atlassian.com/t5/Atlassian-Cloud-Migration/CLOSED-AMA-with-Chris-Clarke-Migration-Platform-Product-Lead-on/qaq-p/1048942
Hello Atlassian Community! We're pleased to announce the availability of a new Jira Server to Cloud migration planning guide for customers and partners who are interested in moving to our Jir...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events