This is a two-part blog post that will talk about security and what we do at Guidewire to build trust with our customers. How do we approach security as a company? How do we approach security with our engineers, and then how do we demonstrate it?
Cybersecurity Stakes Continue to Increase Globally
If you’ve been paying attention to cybersecurity for any period of time, you’ve likely observed that the cybersecurity environment has been increasingly volatile over the past year. The global community has had ransomware running rampant all over the world. Critical infrastructure has been attacked by nation-state actors.
Along with these threats comes much more visibility from regulators, and a lot more visibility from your own companies. The recent discovery of the log4j vulnerability, and the management of it through the end of 2021 is a great example of this. The stakes continue to increase.
Trust Is a Driver of Guidewire Customer Success
When we think about security at Guidewire, we think about customer trust. Our customers trust us in order to run their business with some of the most critical technology they have. And with that trust, customers expect performance, security, and many other things.
As we enable you as our customer, we have to think about how to enable you to build and deliver securely on the platform, while also protecting Guidewire.
Part of the value of Guidewire Cloud is that you can take advantage of Guidewire’s ability to do many of the things that you were doing in-house, but at a much higher scale. For Guidewire, security at scale is an inherent value we’ve baked into the Cloud. It’s not on your invoice. It’s not one of the line items that you buy. It is part of the extended value we provide.
For many of you, security is also a board-level issue. At Guidewire, it’s certainly a board-level issue. In order for you to build trust with your board, we have to build trust with you.
How Do We Approach Security in the Guidewire Cloud?
Guidewire’s strategic approach to security can be simplified into three parts:
- Continuously strengthen the baseline
- Deliver value quickly and securely
- Govern strongly and verify compliance by third parties
1. Continuously Strengthen the Baseline
So, let’s start with continuously strengthening the baseline. A lot of things in security are table stakes: vulnerability management, incident response, and basic governance inside of our company, for example. They are expected, and they are not static. There really is no finish line for what we do in those areas. We need to repeatedly nail the basics, and do it exceptionally well so you can trust us.
While we continue to invest in the basics, we will also continuously improve capabilities for the future.
We use NIST CSF as a standard to drive our security roadmap. If you’ve not heard of that standard, several years ago the Obama administration observed that the federal government in the United States had an inconsistent cybersecurity posture. The administration went to NIST, the National Institute for Standards and Technology, and asked them to come up with a framework.
In 2014, the NIST released a framework that was applied to many government agencies and they started to see the value of security uplift in a very consistent manner across those agencies. So later in 2017, they released a follow-on to the framework, the NIST CSF, as a public version that many companies started adopting.
We’ve chosen the NIST CSF framework to give Guidewire a consistent way to grow, with a security roadmap that many of our customers can understand because they also use NIST CSF. So, we have this common vocabulary as to how we’re approaching security maturity.
We’ll continue to make incredible investments in our security program so that the level of security customers get now will only be increased in the future.
2. Deliver Value Securely and Quickly
We have to deliver value securely and quickly—both of these aspects are critical. Part of what we’re doing to accomplish secure and fast delivery is that we are continuously evolving our secure development lifecycle.
Our secure development lifecycle is the process that we apply to development across different grouping of products that we have at Guidewire. We’ve developed the following principles that will help guide us, in addition to the “nuts and bolts” aspects of creating secure software.
- Cloud, speed, and security: what we do has to be fast so that it doesn’t remove agility, and it doesn’t prevent you from getting new features.
- Defense in depth: multiple capabilities that can do the same thing and act as fail-safes.
- Secure by default: we design our products with security in mind, but we also think about the user experience of security.
As an example, when you look at Jutro, or other newer technologies that we release, we about how a customer will use it. How can we enable them to have an out-of-the-box experience that’s much more secure?
And how do we prevent people from making mistakes that could otherwise affect the deployments that all of us have? In another post, we’ll talk about “The Last Mile” of security, this shared responsibility with customers in the way that we deploy Guidewire software.
We also use standards like NIST SSDF, which is a lesser known framework, and is a cousin to the NIST CSF. It’s another way for us to mature our security, but in a very standardized manner. It’s a one-to-five scale, very similar to the NIST CSF, but it’s something that we can use as a roadmap that many of you could go and look and understand what direction we’ll take over time.
And then the last part is that we’ll continue to create guidance and resources to help our customers deploy securely.
Now, it’s one thing to talk about security in a way that everyone expects. But we also need to earn customer trust by demonstrating and proving our commitment to security. That’s why we think that security and compliance need to have checks and balances.
3. Compliance and Third Parties
There are a few ways that we do this. First, we rely on experienced third-party pen testers to check: are all the things that we’re doing — before the software gets released, before the services get deployed — are all of those things working? This gives us an objective third-party view. So it’s not just Guidewire saying, “Thumbs up. Everything’s great, everybody.”
These pen tests are also available to our customers. If you’re a customer of ours, you can reach out to your account manager and request the latest pen test. We do these on a recurring basis at least every six months for most products that release on that cadence.
In addition to pen testing, we also receive expert consultations. We recognize that we don’t have all the answers, so we also rely on outside experts. We rely on consultancies, and we coordinate with our friends and neighbors in different SaaS companies.
Finally, we have chosen industry-standard compliance certifications. Many of our customers have these certifications as well. We chose them because they are both rigorous and they are broad-based. Guidewire has certifications for ISO 27001, SOC 1 Type I, SOC 2 Type II and PCI.
More recently we’ve taken on a new privacy certification, ISO 27701. We chose this one because we have a global footprint. We didn’t want to choose anything US-specific. It’s a nice addition to ISO 27001, and it allows us to say “Not only do we run the company well in terms of security, but also we run the company well in terms of global privacy and provide those capabilities.”
We’ll also consider multiple new certifications. If there are certain certifications that would help our customers be more successful in their market or regulatory frameworks, we’d like to consider those and help support the security needs of our customers.
This concludes Part One. In Part Two, we’ll talk about “The Last Mile” of security: how we enable our customers to implement securely, and the shared responsibility model we have with our customers.
This post is a transcript of a session titled “Security in Guidewire Cloud,” which was presented by James Dolph and Mark Sayewich at Connections 2021. The transcript has been condensed and edited for easier reading.
About the Authors
Chief Information Security Officer
Director, Field Enablement, Technical & Security