Today’s Chief Trust Officers must expand beyond the position of security enforcer and into a more visionary and strategic role, balancing security risk with enterprise reward. Meet Adrian Ludwig, formerly of Nest and Android, and now Chief Trust Officer at Atlassian.
You joined Atlassian after working at Android and Nest. What did you learn there that you’re bringing to the Atlassian security team?
There are a few things that I have found to be true in my years of working in security:
The first is that the fundamentals have to be done right. There are always a lot of exciting projects in security, so it’s really tempting to focus on the shiny, new technology—currently we’re talking a lot about AI and machine learning—but until the fundamentals, like vulnerability management, efficient patching processes, effective code review processes, comprehensive 2FA, and solid endpoint protection are in place, adding new technology simply isn’t effective at reducing or managing risk.
The first is that the fundamentals have to be done right. There are always a lot of exciting projects in security, so it’s really tempting to focus on the shiny, new technology […]
The second is to assume that any technology or process we deploy is going to be fallible because humans are fallible. It’s just a fact. Once you assume that every process or technology will have a non-zero error rate it becomes critical that we first measure that error rate, and then actively work to improve the error rate over time, and finally, deploy redundant protections that provide backup protection for gaps.
You came up the ranks via product development, not infrastructure. How has this affected your approach to information security?
In my experience, some of the key differences between product and infrastructure are around mindset. I’ve often seen that folks who come up through an IT organization are somewhat risk-averse. And for good reason: The IT department is often measured by uptime and SLAs, and they have little incentive to take on projects that would put those metrics at risk.
Product leaders, on the other hand, are less often measured on how efficiently they use their resources and tend to be more focused on top-line growth. So making bigger bets is a normal approach for folks in a product role.
Along those lines, IT-centric leaders often work hard to temper expectations of their department’s results relative to its resources. Whereas product folks, myself included, tend to have a more growth-oriented mindset. I often emphasize to my team that if we work to exceed expectations then the business will ask us to do more and our share of the overall pie will increase, meaning we’ll be rewarded with more resources. And with that, the overall business will continue to grow.
I often say things like, “I don’t know how we’ll do this, but someone needs to do it. And if we don’t sign up for that, who will?”
That means I’m more comfortable setting goals that are difficult to achieve, and I’ve also found that those hard-to-achieve goals are a powerful motivation for my teams. I often say things like, “I don’t know how we’ll do this, but someone needs to do it. And if we don’t sign up for that, who will?” And the team will rise to the challenge, and they know that it’s okay if they only meet 70% or 80% of our overall goal. Traditional IT teams rarely take on something unless they’re confident they can succeed 100% of the time.
What changes should we expect to see in the security team in Atlassian?
We’re looking to increase our internal and our external transparency so that customers can better understand how we’ve built processes to manage the security of their data, and because we think some customers would be able to reuse these processes in their own environment.
For example, we have a really strong incident response process that is built on a combination of Jira, Confluence and several security-specific tools that were built by the security team. We’re hoping to provide more information about those tools in the future, and possibly open source them for others to use.
What are some of the cultural challenges that security teams face today?
There are two common traps that security teams can find themselves in:
The first is the security team that sees its primary function as an auditor. Likely due to some past mistakes, this type of team believes it is there to make sure that you never ship something that has any bugs in it.
They probably have some humility and recognize that they can’t stop everything, but if they find anything at all, they’re gonna say you can’t ship until you’ve fixed all those things.
If you lead with that style the consequence is that the product and engineering teams, the ones that you’re trying to help ship quality products, they just stop talking to you. They don’t tell you that there’s a new release; you find out after the fact. You lose control and then find yourself in constant conflict with other teams.
The second trap is even more insidious, because of the long-term consequences for the customer. In this situation, the security team tries so hard not to be in conflict with the product team that they end up abdicating their responsibility for safety.
They become so accommodating that eventually, they begin enabling bad behavior. They let something go to release on the condition that it will be fixed in the next release, which may or may not happen. You know that they shouldn’t ship it, the team knows that they shouldn’t ship it, but they still go through the motions of asking you if they can ship it anyway in order to not feel bad about doing the wrong thing.
We work closely with product teams to build security into every process and get ahead of security approvals so that both sides reach their goals.
Having seen these pitfalls in the past, we’ve worked very hard here at Atlassian to keep us from falling into either of these traps. We work closely with product teams to build security into every process and get ahead of security approvals so that both sides reach their goals.
When you talk to customers, what are their top security and privacy concerns when it comes to SaaS products? How can Atlassian help them with that?
Customers are still trying to figure out how the cloud fits into their risk management strategy. Many of them have very specific security requests—encryption at rest, enforcement of a 2FA policy, for example—but those feature requirements haven’t yet manifested into an actual strategy for managing risk.
While sometimes hosting applications on premise or on a private cloud server is required, I hope we can help customers realize that the economies of scale that cloud provides also improve security. We create highly-tuned monitoring for cloud instances, we can patch the cloud quickly (because we have direct access to them), and we implement tighter controls around direct access to data (e.g. insider threat).
In a recent Cloud Security Alliance survey, 34% of respondents said their hesitancy to jump to the cloud is rooted in a sense of loss of control over the management of data and IT services. What is your view on this?
Ultimately, I think we (Atlassian, and all of the cloud providers) need to demonstrate that we can actually provide better security (and uptime, and privacy, and reliability, etc.) than an internal IT team deploying a range of different tools and applications. Those that switch to cloud will have time and resources to look ahead and work on designing security, and not spend so much time managing and maintaining.
Those that switch to cloud will have time and resources to look ahead and work on designing security, and not spend so much time managing and maintaining.
But this is also a problem of perception. It turns out the vast majority of companies, even in highly-regulated industries, have already started to adopt some level of cloud services and we expect that trend will continue. For example, at a recent Chief Trust Officer summit I attended, one of the other Chief Trust Officers asked a few questions, specifically of other Chief Trust Officers who were saying, “We’ll never adopt cloud.”
He asked them how many run their own payroll infrastructure, for example, versus outsourcing that work function to ADT, or one of the other payroll companies.
And he asked how many of them run their own chat or collaboration servers, versus using Slack, or Hangouts, or Teams. And how many of them run their own email servers.
The reality is that many of these companies are already using mission-critical applications managed by cloud vendors.
What are the top benefits for security teams who use cloud services?
When a customer chooses to deploy on the Atlassian cloud rather than an on-prem server, we take care of server configuration, patching, logging infrastructure, incident detection, and response. That means we provide many of the security services that an internal security team would otherwise need to provide on their own. These are all huge benefits to the company that wants to focus its core business and efficiently use its limited resources. Many of the best Chief Trust Officers see this and consider it a “no-brainer” to adopt cloud.
On the other hand, some Chief Trust Officers—and IT teams—see these benefits and realize they are the exact same services their teams do. So, sometimes they worry that their jobs are going to be replaced. But we remind them that what we’re doing is taking care of the boring work for them, so they can devote time to the more forward-looking work. For example, by the time we publish the security bulletin for a new patch for the server version of a product, the cloud product is already updated.
Who’s your favorite spy or detective, real or fictional?
Early in my career, I had the honor of meeting a few people who spent most of their lives doing covert or undercover work. Since I was working with computers, I never did anything that interesting myself but I have an incredible amount of respect for those folks, the work that they do, and the risk they are exposed to throughout their entire lives. So I won’t name names.
And for fictional characters, my two sons are eight and five years old and, at the moment, we’re all pretty fond of Encyclopedia Brown and the Hardy Boys.