Don’t underestimate the importance of an organization’s employees in helping identify security risks. While tools are important mechanisms in finding vulnerabilities, people can provide an inside-out approach since they’re the ones developing products and interacting with customers. That advice comes from Ryan Gurney, CSO of Looker, a software-as-a-service (SaaS) data analytics company that helps businesses make better decisions by giving everyone the organization access to data. Before joining Looker in May, Gurney was the vice president of security at Zendesk. He’s also held security leadership roles at Engine Yard and eBay.
Gurney talks about why getting to know co-workers leads to improved security and why the security team can’t work like it’s on an island. He also shares how information security teams should be seen as helping drive revenue, not just being a cost center.
Three come to top of mind. Certainly, the growth and the scale that we're experiencing, both for us and our customers can be a challenge. Also, because we're a SaaS company, there's a lot of motivation internally to use other young SaaS companies for services, and often these companies are still maturing their security story.
Then, we have a pretty broad spectrum of customers as a SaaS company. We’ve got the really small with one or two analysts to large, enterprise companies. Each of these organizations has differing levels of risk appetite and regulatory requirements. For us, when we're developing the product, we have to keep that in mind as we develop security features and capabilities within the product. They have to be able to stretch across differing needs.
From a security perspective, my product philosophy is that we don't want to make risk decisions on behalf of our customers; we want to establish safe defaults, but give them the toggles to dial things up or down depending on their specific needs.
First and foremost, you want to make security everybody's responsibility. You do that when you enter the door by building a lot of goodwill internally. Understanding people's needs, and aligning with sales on the various security questions they may get; facilitating conversations but not, frankly, owning all the controls; and making people understand that we're going to work with you. The security team is not on an island; we're going to work with you.
Help them align on what the risk is they might be trying to mitigate, or that security might be concerned about. Let them help design the controls with our participation but make them owners of those controls. Don't make it all the security's responsibility. That has proven effective in my career.
The other thing is changing the way people view audits and compliance. A lot of people look at those internally in various companies that I've been in as it's an event, it's this thing, it's an annoyance almost. You've got to try to change that conversation into “It’s risk mitigation.” If we're not developing controls that reduce risk and that you and the business unit leader agree reduce risk, then we're just wasting time. If we can get alignment on that, and we look at audit as not an event but something that could happen anytime and it's just a part of doing business, it's a little bit easier to get people on board.
The other side -- certainly we've seen this push lately -- it's technology companies, a concept of security -- sec dev ops is the nomenclature people use -- really using automation and orchestration, and in some cases, crowdsource security, just to speed things up and stay in front of things. Security should not be the person or the group blocking the train, but the tools and the automated tests should help show to everybody that this train shouldn't go out because of this flaw or this issue. There are a lot of innovative companies in this area that I've worked with in the past and will continue to work with here at Looker.
Also, make your security team ultra-responsive and ultra-available to everybody internally. You help them with training and security practices, and you'll be the consultative organization that they need, that they know they can go to security for advice. They can go to us when they see any kind of issues and we're going to work together to figure out the solution and solve it. Lately, you've seen, especially in a fast-paced environment where code is continuously deployed, thoughts around machine learning and artificial intelligence and all these things. The idea there is as you're doing things at scale, can you leverage those tools to say this is what a normal operating environment looks like. This is what a Looker instance should look like when it's operating from a secure fashion. If that changes, alert us, notify us, let us see what's going on. In some cases, make that configuration change for us, to revert it back. That's the future state and a lot of companies are working on processes to get there.
I can't speak to the history really since I've only been here since May. I will say I was pretty delighted when I first interviewed and then walked in the door, the architecture decisions that the company has made were aligned. One of those is we don't just take a copy of a customer's database and persist it indefinitely. The customer's data sits within their database behind their firewall or whatever public cloud architecture they may have. That's a huge difference because we're not keeping hold of that data.
We do persist a temporary cache, but we allow the customer to determine for how long we persist that cache. That cache is also encrypted. These decisions were made before I ever started and they were really wise. Also, the company culture is very transparent and open and friendly, and there was a need for, I think, some security leadership there. I’ve felt very much a welcome mat here from our different business units, so it's made my job a lot easier.
The key there is you try to embed yourself and be responsive. What we've done at Looker is a new process around getting deeper on security architecture reviews. I worked with product, and we identified -- before we started a large sprint -- all the projects we're going to be working on and the new features. Then let's look at what those features are and how they impact, potentially, our security model. From those, we, as a security team, will look at things that need a deeper security architecture review based on potential risk.
That's a collaborative effort where, for them, they get some peace of mind that they're not releasing a feature that didn't have visibility. We get the peace of mind that we're working together with them and that they will let us know about features they're developing, and we get that visibility to collaborate on controls. Just work together; put your desks beside product and engineering. Be available. Have a Slack channel specifically for security that folks can ask you questions and just be super responsive.
It also helps to talk through and have the experiences of some level of horror stories to share. We're going to do this specific thing around authentication, what are the risks? We tell them, “Well, we've seen this, and we've seen this, and we've seen this.” That resonates well with people and gives you a level of goodwill within the organization.
The first thing is getting to know people on a human level. Relationship building is really key and that's an area that I try to excel at in working with people. Then when you get to know them on that level, some of the harder questions or the harder decisions you have to deal with won't feel so difficult, especially if you have to say, “We shouldn't really go in that direction” and you have to take a stand in some cases.
The other thing that works is don't assume expertise on a topic that you're going to discuss. You may be working with the CFO or the CIO but you may have to level up that conversation and really talk about risk and risk to the business before any dive down into technical jargon. Respecting each other's time is really important. Being clear and concise and understanding that maybe this is the most top-of-mind thing that they're dealing with. After that conversation, hopefully, they see that risk is very important or the specific thing that you're talking about.
Finally, it's really important to be empathetic and transparent and understand their needs and ask, “How can I help you? I understand this is your business unit. What can I do to make your life easier?” That always allows the conversation to have a secondary conversation down the line, when they have something that they may need assistance with.
Understanding why you’re here. People need to know that you realize that you're responsible for the security in the company and the customers and the shareholders and that everybody knows that. It's very clear. Leadership ability is also important. You have to be able to bring different groups together. A lot of security risks need to be managed cross-functionally so you need to be seen as a leader who can facilitate that and willing to roll up your sleeves and do whatever it takes.
It’s important to be closely involved in responding to incidents so that people realize you've got this. There's a lot of confidence that people get when that person is in the room and they're involved in something that's huge. Finally, you must be super organized. Doing simple things like keeping your calendar up to date and responding to emails in a timely fashion. That all precipitates people's opinion of you. If you're that organized in how you do that, you're going to be very organized in a situation where there's a security event that needs investigating and responding to.
That is a business-by-business decision depending on the company and the people that are leading the company. At one company I reported to the CFO, and the security team reported to the CFO. I don't know if it's always about who has the biggest stake in the game, who is the most influential, who has the board's ear, who's not afraid of conflict, or who's best to understand the topic. Those are decisions that need to be made by the group.
Ultimately, security is more a business issue than a technical one. I consider my team -- although externally and internally people might look at them and call them security -- as more risk management and helping the business understand how to mitigate risk. We point out the issues of risk and then work with the stakeholders on how best to treat that risk.
It’s really who has the aptitude to understand the issue and then who has the ability to remove any blockers so that we can be successful. In previous companies, it's been all over the map. It's been a CIO. It's been the CFO. It's been the CSO. I think it's really who's in the seat and who has the influence.
In most companies, especially as they're growing, the security team is not going to be huge at first. You have to determine and understand the risks and the compliance landscape that you're going to be living in. Then build out the policies and the procedures around how security and risk is managed, and then identify who those owners are for those different technical things.
Now early on, for example, firewall management might be led by the operations team. That might continue to be the operations team, but they have to be clear on what their responsibilities are as far as security goes. The security team is really the group that's facilitating and developing the policies and where the information should be managed, if that makes sense.
Now as the company expands, it makes sense certainly to identify key players in the security team that have technical expertise. The way we're organized at Looker is that we have a product security group that reports to me, security operations that reports to me, and security compliance reports to me. Ultimately, we'll probably have a sales support team that reports to me. All of those are very specific niche things that are very technical in nature. At the end of the day, it is about risk management as far as how they do their job and how they prioritize the work that we do.
I wish they understood the space better. They're not always educated on the risk side and the security tools out there and the breach landscape, and in some cases the risk that companies might be running with when they're operating. Like I've said before, it's not just the technology problem, there a business decisions that need to be looked at through that lens. I've also been in some board situations where some of the board members might be motivated to push a certain vendor your way. There are possibilities there for pressure on security leaders; that they have to mitigate that by doing what's right for the business, based on what those needs are.
It’s also beneficial to have cybersecurity leaders on boards so that that balance is tilted a little bit more around risk, but with that said, I also think CISOs need to do a much better job educating boards on risk. The challenge some CISOs face is not getting down too much into the technical jargon and security jargon with the boards and ensuring that they are leveling that back up with why they should care.
Get one-on-one meetings with different board members to understand their perspective. Share your perspective so that it’s very clear that they understand what your mandate and your mission and your strategy is independent of that room. Sometimes some executive coaching for CISOs is helpful around how you present and how you talk to C-staff and board members. In the CISO world, there’s a pretty big supply and demand challenge. There’s way more jobs than there are qualified candidates. We’ve seen a lot of people accelerate their career quite quickly in security, but sometimes it’s not always the people that have that business risk sense or experience that gets promoted into the CISO role. Maybe they’re very good technically, and then that can be a situation where they’re just not prepared for what that is and how to ensure that the board is aware of the risks and that their presence and their leadership is shown to the board.
Absolutely. CISOs need to take more proactive measures with their own team. I like to tell anybody that I hire that, if I’m not preparing you to eventually take my job, I’m probably doing you a disservice. A lot of people come into it with a very specific skillset in one area of security. The challenge is that the domain itself, the security domain, is so broad. They need to be prepared, and they need to experience those other domains to some fashion, at least from, and I keep coming back to this, the standpoint of risk. Be able to understand risk and communicate risk so that they can go out and become CISOs of tomorrow, and that’s really critical for a company and for the industry as a whole.
No. There’s all these frameworks out there that you can use when doing risk assessment and threat modeling and all these things, and we certainly incorporate those. When you start at a company that’s fast moving and you’re new to that organization, just having conversations with people, setting up one-on-ones, and asking the simple question, “I’m trying to understand the risks that the company or that you feel, frankly, or that you see.” You give them some example of risks maybe from a past life that you had. Then you just get them talking, and you do a good job of listening.
Most security risks that I found in my career haven’t come through tools. That’s certainly an important piece of the program, but it comes from people reaching out, or you reaching out to them. Sometimes it’s, “I have this trust in you. There’s a thing I haven’t been comfortable with. I’m going to share it with you. Can you help me figure out how to mitigate that risk?” Maybe that person has been barked at by a manager or something. Maybe there’s been a real business reason to have this situation, but you can’t do anything about it unless you first hear about it and you understand it. That’s the way I approach it initially.
At the companies I’ve been at, we’ve maintained a very simple thing that we call risk register. I tell my team that if they hear anything that sounds weird, put it on the risk register and let’s evaluate it and dig into it. Maybe it will be a real risk, maybe it won’t be. It’s a great way to say, “We’re going to make sure that whatever people tell us, we’re going to take it seriously, and we’re going investigate it.”
The early stages are so critical because it’s much harder to move the needle on security controls and security awareness when a company is larger than it was when you started. It’s kind of a sprint, and it’s vital that you’re seen as thoughtful and considerate, professional, and just build that initial goodwill. The best way to know about the challenges in security is from the inside out by understanding from people in the company.
One approach that I’ve taken that allows me to build that goodwill and hear from people and stay in front of things is making strong commitments to business units. One strong commitment I made, for example, to sales when I started at Looker was to turn around sales security questionnaires that they got from customers within 24 hours. That shows how important the security side is. It takes care of one of their pain points, and you get some momentum across the whole organization and C-staff when they see that you deliver on that.
Then things start to happen, such as getting the budget and the resources you need because you built up trust. People say, “We want to work with that person because they care about our needs.” You also get to be a part of the return on investment of security, and that leads to things such as compliance initiatives like the SOC-2 and ISO. While you all have a reason to do that because it’s a framework that helps you secure the environment, it’s also something that sales and our customers want so that they can demonstrate to them that we’re taking security seriously. Once you spend the time and do those things, you get that runway of trust, which opens the door to more things and allows you to grow that organization.
It’s true. Finding the ROI around security from a revenue generating standpoint can be a little bit tricky. A simple one that CISOs can do is to stay on the commitment to turn your security questionnaires out really quickly, and that just gets a lot of momentum. My focus on the sales folks when I first arrived in companies has been rather well received.
Hire for values, especially integrity. Integrity is so critical in your employees, especially in the security team. Of all the people that have to show high integrity, it has to be your security team. Skills are very important, but integrity is so vital. Show to your team that there’s nothing below you. Take the opportunity to do work that no one on your team is excited to do to drive that point home.
You get to know your team on a human level, and you be a great listener, and share your failures and your successes as a leader. You’re going to have some. Take an active role in their career. You want to be a great mentor. Ensure that your employees understand that you’re a customer service organization. I worked at Zendesk where being customer service company was so critical. It bled through the whole company how important that is, and it’s great to see that in our security team. And finally, celebrate the wins.
It allows your team to see you as human, and that you learn from them. It endears your team members to you from a mentoring relationship. It’s tough to have a mentor who comes across like everything they’ve ever done has been perfect because that’s just not realistic. For your team members, it allows them to say, “Okay, I don’t have to be perfect to do this job. I just probably have to recognize when I fail and pivot quickly.”