How Cloud-Native Journey is Changing the Role of CISO

Dave: Good morning, good afternoon, good evening, everybody. Welcome to our panel discussion on how cloud native is changing the role of the CISO. We're delighted today to have two senior security leaders in the industry with us to share their thoughts on several different topics around this concept of the cloud native journey, and really the broad interpretation of that is digital transformation and all of the aspects of migrating to the cloud from infrastructure all the way to modern application development. So, first at the top there you see Yaron Levi, CISO at Dolby Labs. Longtime CISO. Before Dolby, Blue Cross Blue Shield Kansas City. Oftentimes speaker on the circuit and is active in the Cloud Security Alliance and the like. So, we're delighted to have you on, Yaron. Welcome and thank you.

Yaron Levi: Thank you.

Dave: And we're also really fortunate to have Bill Shinn senior principal office and CISO at Amazon. Sp, senior leader at Amazon and in the community broadly and has a deep background in security stretching back into JP Morgan and US Bank as well as all of the things that he's done in his more than decade at Amazon. Bill, we're thrilled to have you. Thank you for joining us.

Bill Shinn: Thank you. Good to be here.

Dave: All right, let's jump right in. So, we'll start out just talking about digital transformation and cloud migration in app development broadly. I think this is a topic that most in the audience and the community hear about a lot, and they obviously get informed and stay current on many aspects of it, but I thought just given the breadth of experience that both of you bring to this, that you might be able to share some aspects of this topic that maybe are less well understood relative to what most people would identify with the topic. So, maybe Yaron, if I could just start with you. What strikes you about this journey as you've gone through it and seen others go through it that maybe is not as well understood in the community?

Yaron Levi: No, absolutely. I started to deal with the cloud probably back in, I don't know, 2009 time frame. I still remember the first time I went to AWS to do the initial cloud training and understanding what cloud is. Since then, probably for the last 10, 11, 12 years, what still strikes me is that how many people and how many organizations still don't understand the shared responsibility model of cloud, who is responsible for what. Many organizations, unfortunately, think that, " Okay, I'm moving to the cloud. I'm good. I don't have to worry about anything anymore. The cloud service provider will take care of that." Well, if you read the terms and conditions from the cloud service providers, you may not be covered as much as you think you are. Then there's the other aspect of if you think about the cloud model itself, infrastructure platform and software, what does that look like? Even if I have an infrastructure to service, I've seen people who are thinking about like, " Well, I don't have to worry about it. AWS or any of the other cloud providers, they will take care of it for me." No, they're not. They take care of the platform itself, but you have the responsibility from the infrastructure up and so on. This is something that is still largely, what I'm finding, largely misunderstood. There's another side to it when it comes to compliance. I'm still amazed to see how many third parties will actually send me the authentications of the cloud service provider as their own authentication that they are compliant. This is something that again, you kind of look at that like, " Do you really understand what you are asking or you're doing, what you are testing for?" It may sound funny. I've seen that so many times, and it's pretty common, especially in some industries. So, that's another aspect. The other aspect I want to mention that's also kind of related to that, but what does it mean when you're moving to the cloud. Yeah, we talk about cloud native and companies who were born in the cloud or developing on the cloud, but then there's also many others who think, again, I'm going to move to the cloud. I'm just going to lift and shift whatever I have, and then I'm done. I don't have to worry about it again anymore. Again, that's another misconception, because it doesn't change or it doesn't give you any protections from that perspective, but then also in some cases, you actually may be moving from what I call a quiet neighborhood to a more noisy one, because all of a sudden now that you have a lot of neighbors that you may not be a target, but they would be the target. Therefore, you may be impacted by a stray bullet or something like that. So, there are many aspects that people have to think about and be aware to because of this transition. But again, I think that still many, many organizations, many people still grossly misunderstand.

Dave: Yeah, those are great points, all three. The shared responsibility piece of it, and the compliance and what's required to be compliant. Then, don't think that you're good if you're just lifting and shifting. There's actually a whole host of problems there, too. All three of those are great points. Bill, how about from your perspective?

Bill Shinn: I think let's kind of pivot a little bit into a different aspect. When it comes to security and the security persona and practitioner, don't look away from the benefits of this digital transformation and cloud migration for security use cases. Most of the customers I talk to, they really struggle with the same scalability challenges and the security customers. The security teams are struggling with the same scalability challenges their business is struggling with. They're struggling to take advantage of new innovation more quickly, to be agile in their own development, to build internal microservices for security use cases. Things like authentication, authorization, logging, and monitoring. All the core controls, they want to automate as much as they can. Cloud in particular and API- driven architectures that are modern really can modernize the security use cases, too. I think that's something that's maybe a little less understood or people are looking at the risks of moving to a new deployment model and taking on a new set of technologies. But don't discount the upside benefits of elastic scale, infinite logging, analytic services, and there's tons of folks that are using cloud- based security services with a lot of success as opposed to running their own infrastructure on premises to perform those same functions. It's a different appreciation. Excuse me, acquisition cycle as well. So, the paying as you go model of cloud applies equally to security use cases as it does for digital transformation or business or other kinds of workloads. Versus buying fixed infrastructure that depreciates over time and you're kind of stuck with until you can operate it again. There's a lot of advantages to, I think, having that more dynamic environment that are applicable to the CISO.

Dave: That's a great transition, I think, into our next discussion point, which is thinking about how to take advantage of some of these transitions. At the technology layer, you start going down the path to recognize all the differences in the tech stack of a cloud- forward model and a digitally transformed business. If you abstract out of all the individual transitions, the one thing that strikes you is just a lot of complexity. There's just many transitions and individual systems and tools and platforms. There's transitions in technology that cut across the tech stack and the products. What advice would both of you have for CISOs trying to think about how do I get control and manage this rapid increase in complexity as we go through these transitions? Maybe Bill, I can just start with you on this one bridging off your last comment.

Bill Shinn: The cloud allows for more experimentation. You can change your architecture more quickly and make decisions more quickly. The upfront investment in selecting a technology is less risk. Typically, when you bought a capital investment of a technology, you had a long proof of concept period, because that investment was a longterm investment. If you got it wrong, you're kind of stuck with it. Well, the cost of failure is lower with experimenting with new technologies. While it may appear complex, it's much quicker to get to the technologies that you want to select with that faster reiteration and experimentation. But again, I think education is important. We talk a lot with customers about identity and access management, which is one example. We have nearly 200 services that require authorization, and we have one language to describe it, but it's a diverse set of IT services. So, it's a new language, and so just like any authorization framework, you have to invest in people and time to understand it. So, it's probably not groundbreaking innovationary insight there, but I think education is a huge part of it. You got to get people trained up on this stuff and make sure they're not taking on technologies they can't support.

Dave: It's great advice. Just, again, your point from the previous, just leveraging some of these transitions to think different. In this case, rapid experimentation to do proof of concepts more quickly and just a way to be more agile to manage some of the downside of a bad decision. That's a great point. Yaron, how about you?

Yaron Levi: Yeah, I think one of the things that we always have to think about is how do we adapt and how do we change even our approach. So traditionally, especially from a security perspective, we used to look at the perimeter, and we used to look at, " Okay, we have, for the most part, one perimeter that we are protecting and defending." I hear a lot of people saying, " Well, the perimeter is gone. There is no perimeter anymore," and so on. Well, the reality is that I would argue that the perimeter is actually multiplying. We have now a lot of perimeters, and Dave, you mentioned complexities. So, we have a lot of complex perimeters. In a way, the perimeter is shrinking, and it's actually moving very, very fast. So, I no longer have this one, big data center that I put my arms around it, my firewalls around it, and I call it good. I'm using tons of different services. In the cloud, infrastructure, platform service as a software, and so on. So, I have a lot of more perimeters to defend and protect. The question is how do you do that and scale? How do you handle all that complexity? If I go back to the same perimeter mindset or concept from earlier, for the most part, there was one team, small or large, that was tasked with defending the perimeter, defending the systems, keeping the systems up and running and so on. Now that model no longer scales now that I have a lot more complexity and I have many more perimeters. So, the question is how do we shift and how do we adjust from very centralized model to more decentralized model and actually start pushing a lot of these responsibilities closer to where the work is actually done? One monolithic one team that covers everything doesn't scale anymore. The flip side of that is decentralizing everything, and you may end up with a lot of chaos and inconsistencies and other problems and lot of cracks that people can slip through. So, really kind of finding that balance between centralized and some decentralized based on what you need to do. Lastly, when you think of and you look at it, Bill, you mentioned some of the core capabilities of the cloud. How do you leverage things like data that you get from your tools, from the cloud infrastructure itself, from the cloud platform themselves? And how do you use that to drive decisions and automate a lot of your operations and automations? That's pretty much the only way that you could scale and help support all that complexity.

Dave: You're starting to talk about decentralizing. That brings up the collaboration model, and so we pivot to the next discussion point on how that's changing as you decentralize security, but then as you have many more stakeholders. I wonder, Yaron, again maybe keeping the baton, if you could kick us off on this one and talk about how the CISO needs to adjust the model just given the changes in stakeholders.

Yaron Levi: We're looking at, for example, low code, no code solutions. The marketing department, HR department, finance department. Now you have people who are not necessarily engineers by definition, but they have the power and they have tools. They can create their own solutions. So, when we start thinking about all those aspects and we start thinking about aspects of security around risk management, threat modeling, defense, how do we deal with vulnerabilities, how they approach it more from the bad guys' perspectives so we can find all those holes and gaps. These skills now need to expand way beyond just security or just IT or engineering. It needs to expand now into other departments that traditionally we didn't classify as let's call it technical departments. I think a lot of what the CISO role is shifting towards is a lot of evangelism, a lot of education, a lot of getting buy- in from these different groups and making sure they understand why they should care, why it's important, how would they do, contribute to the overall risk of the organization, and what are the things that they need to do in order to contribute to the overall security. So, I like the line from Spider- Man that with great power comes great responsibility.

Dave: Turn it to Bill, and maybe as I do, you guys can think about the background. It occurred to me as you were talking, I wonder if CISOs are getting the right preparation and training for those aspects of their job, which are sort of recently emerged like evangelism, education, as they go through the career path and the preparation to be a CISO. Or do you sort of arrive at that, and then you discover that you're missing a number of skills? But before we get to that, Bill, what thoughts do you have to share on this stakeholder and collab question?

Bill Shinn: I think Yaron's points are strong. It does need to be important and taken seriously by bigger parts of an enterprise. The CISOs have always been saying security is important. I think I've seen successful CISOs partner with their business peers to make it a top priority of an organization. Not just for the security organization. It's one thing for the CISO to say it's important to follow the right processes and safeguard data, but to say this is the top priority for our entire organization is protecting and safeguarding the data that people trust us with or that we generate, whether that's healthcare data or intellectual property or pre- released video content. Whatever your content is, banking data. If that's the top priority in your organization, everyone understands that it's important. They may not have the skillsets to safeguard it properly, and that's where the CISO comes in to offer low friction, low bar of entry services, whether that's consulting services or technical services to make it simple and easy for the people that can now... Like to Yaron's point, with a credit card or with BI skills, move data around in new ways that if improperly, represent risk to an enterprise or organization. So, I think it has to be everyone's top priority. It has to come from the CEO and from the leaders in the organization, that is a core part of your values. If that's understood, then it becomes much easier for the CISO to say I'm here to help. Versus finding out about something later or someone not being aware that security was important at all. There is a point where people need to take deeper ownership, too, and that's more of a federated model, particularly in engineering- oriented companies. We have, like I said, 200 plus service teams. They own security for those services. Our security organization provides a bunch of shared services, we perform security operations, we have an oversight function, but our service teams own the security of their service. This is kind of the full stack engineering, end- to- end kind of engineering model that I think works. It works outside of just tech companies to see if you're a product owner, you own it. If you think security owns it, then that's a problem. You own it. We're going to help you fix it, and we're going to tell you when it needs to be fixed or if it's incorrect or whatever, but you own it. That business owner of that application has to own it, and eventually they start funding security resources. Otherwise, you keep telling crosstalk have issues. So, I think it's about ownership. Culture of ownership, culture of top priority, and I think that's a big part of it. Then the big collaboration I think I see changing is collaboration between security organizations and engineering organizations, and we'll talk more about that, too.

Dave: Yeah. No, that makes total sense. Just maybe real quick, because we'll probably pace through a little bit quicker that last three questions, but what advice would you have people in the audience who are trying to develop their own careers down the CISO path? They maybe don't have the experience of running these big cross- functional initiatives across all these different groups that are similar to the orchestration model that both of you are describing here. What advice would you have for people trying to develop their career to build those skills so that when they actually become a CISO, they're able to execute well here?

Bill Shinn: I'll say one thing and hand it over to someone who's in that world now who's worked their way up through that. I think getting out of a security organization temporarily. Not permanently, but having better visibility into the other parts of your enterprise. In banking, I was in a security organization, but I got to spend a lot of time with the business people in commercial banking or in card acquisition. I understood their business process, and the business information security officer role might fulfill that a little bit as kind of a career path to spend time in the business units so you see their perspective and what their P& L is, what their top line goals are, what their culture is, and then have that perspective when you go back to run a security organization. Because otherwise, I think you're operating in a vacuum.

Dave: That makes sense. Yaron, you've been a CISO for so long, it may be hard to remember back before you were, but what advice still would you have? Because I know you've grown leaders in your organizations into that CISO role. What advice would you have?

Yaron Levi: Yeah, I think traditionally when we look at a developer, development for a security practitioner, oftentimes we look at it predominantly from a technical lens, and you look at different certifications and different trainings. CISSP, et cetera. People build a lot of those skills and gain a lot of those skills and also kind of measure themselves based on, " Okay, I got this certification, that certification," and so on. I think one of the things that we need to pay more attention to, especially if you want to be on a track for more of a leadership position is what some call the soft skills. Excellent communication, know how to communicate, who to communicate, what do you say, who do you say it, when do you say it. Sounds easier than it actually is, but it's not. Also, kind of develop that skill for building relationship within the organization. That will help you tremendously when you need to first of all understand where they're coming from, what the business is trying to accomplish, how we at the end of the day are there to enable them to accomplish that. Not to stop them and tell them no, but how do we enable them to accomplish what they need to accomplish securely. In order to do that, you need to have a lot of empathy to where they're coming from. You also need to be able to communicate clearly, but also in order to do that, you need to build trust. To build that trust and have them trust in you and inviting you to the table and being with you or having you as part of the team, that's only done through relationship building.

Dave: Just with an eye on the clock, the next topic is a pretty broad one in terms of a technology transition that's associated with developing apps natively in the cloud with digital transformation is obviously the trend towards building security and upstream from the beginning as code is written. It's a broad topic, but just given the time, maybe if there's just one bigger picture observation that you can make about those broad topics.

Bill Shinn: Yeah, I think it's a really opportune time for security to understand how software is built and delivered. I think a lot of security professionals came up through risk management, compliance, network administration, systems administration, and they're not necessarily... There's a small percentage of the security industry that are professional software developers, and I think the speed at which software is being developed and the speed of data growth is why software is being developed at such a rapid growth to be able to consume and make meaning and benefit out of that data. That's driving a huge push in the rate of software development, and it's where all the action is security- wise. So, getting in... So, how code gets from a developer's head to production and how it processes data, understanding that process is the most important thing. The tool chains they use, the kind of check- in practices, the pull requests. All the new modern continuous integration, continuous deployment patterns that software engineers are using, huge opportunity for security to understand where to sit and where to inject themselves. I think the second piece is looking for commonalities in automation opportunities. So, developers can have a lot of autonomy. They can move really fast, and they can build and run in the small iterative teams, but there's certain things, crypto, identity, logging, network perimeters, different protocol implementation. Things that are kind of primitive, and then having good guardrails around that stuff. So, let's say you spit up a development environment, it's going to be reasonably secure, especially in the cloud. It's quite simple to do these days to build a developer environment all the way from dev to production that's got good, strong guardrails around it around kind of the primitives of what you can and can't do. Then lowering the friction from there. Automate things like static analysis and dynamic analysis. Automate linting for security. There's a whole bunch of things you can put in the dev pipelines that are real opportunities to partner and accelerate the rate of development.

Dave: I like that advice. If you're a security practitioner, understand dev ops before you wade in with dev sec ops. That's a great point. Just for time, I know there's a lot of great content we have here, but with a couple of minutes left, just touch if both of you could quickly on building and retaining teams in light of all these transitions. Just maybe quick couple of bullets from both of you so we can get to the final question here. But Bill, maybe you first, and then to Yaron.

Bill Shinn: Sure. The whole industry is stressed with this. Security practitioners are hard to recruit and maintain. So, I think you have to find talent in new places. Having a really diverse view of workforce and finding people that might be non- traditional security people and not necessarily looking for certifications or college degrees. There's people that look at veterans, look at diverse and underrepresented workforce folks, and I think there's a lot of opportunity to grow security talent there. The other thing is retention. You can't saddle security analysts with repetitive tasks. They're too high in demand. So, security people are curious. They want to automate things. So, finding ways to reduce the routine, mundane work and automate your way out of that stuff I think is what you need to do to encourage retention and find the curious high talent security practitioners.

Dave: Great points both. Yaron, quickly on your side.

Yaron Levi: Yeah, so couple of things there. You definitely want to enlist everybody into the neighborhood watch. As I said before, it's not just IT, it's not just security, it's not just engineering. We have a lot of other people, a lot of other constituents from the organization that are now developing and need to be involved or are involved in various aspects of cloud security and so on. So, building that into the culture, understanding the differences, where people are coming from. As security practitioners, we are usually wired to break stuff. Developers are wired to build stuff. That's a very big difference between the two. So, having that empathy for each side and understanding where they're coming from. I love, Dave, what you said about understand dev ops first before you can inject the sec into it. Yes, but it's ultimately everybody have to play within that.

Dave: You've both given great advice to the practitioners along the way. Just the last point. Advice for the partners in the audience. So, this would span everything from integrators to vendors to service providers and all across the spectrum, but for people who build and deploy technology and help clients, what advice would you give to them as they try to navigate these transitions just as customers with CISOs do?

Yaron Levi: I can start. I think one of the things is that it's a journey. It's not something that just switch and it happens. It's a journey, and I love the fact that you said partners, because we need these partners to partner with us on the journey as we kind of work through that. How do you find the right balance? How do you leverage the good things from all the partners and have the partners work together and play nicely with each other as opposed to just pointing fingers and just blaming each other for different things?

Dave: That's great. Bill, last word is yours.

Bill Shinn: Thanks. I appreciated Yaron's comments, and thanks for hosting us today. You got to be honest and upfront about the investment it's going to take. Just like any technology transition, it's not overnight. As partners, we try to do this. I think I go to other partners and practitioners just to be really honest and upfront that the technology alone is not going to solve a problem. It never really has. You have to have people in the culture to adopt that technology and to actually do something with it of value. So, as you're working with an enterprise as a partner or a systems integrator or something like that or an ISP, be upfront about whether this customer is going to have success with your service or your products given the constraints that they're under. I think just be honest about that. You know, " Your culture needs to change this way or you need to adopt these practices as people to be able to really leverage this technology," because some of these technologies are quite sophisticated. They take a transition and investment and training, and they take honesty about what it's really going to take to get it done. I think that's inaudible.

Dave: That's great crosstalk advice.

Yaron Levi: If I may, I'd just like one more thing. I think we talk a lot about building architectures and solutions and our journey and different things that we are doing. We also need to be careful not to fall too much in love in our architecture as it is and kind of hold to legacy things that we have, because it decays over time and things have to change and things are changing, even quickly now with cloud. So really, how do we more embrace that cloud mentality? Bill talked a lot about experimentation and more moving fast. We need to think about that as well as we kind of build our programs and how do we adjust to move even faster, even though it's difficult for us to do it in many cases.

Dave: That's a great point to close on. I just want to thank both of you for a rich and broad discussion. I think that covered a lot of ground and hopefully gave some great advice and insight to our audience both on the practitioner side and the partner side. Thank you both for being leaders in the community and for standing up and leaning in with Sue Mose as we try to chart the path towards modern security. So, we really appreciate it. This brings our panel to its conclusion. I want to thank our panelists again, and again, good morning, good afternoon, and good evening to everyone in our global audience. Thank you.

Bill Shinn: Thank you.

Yaron Levi: Thank you.