Strategy to Execution: How to Close the Identity Security Gaps in the Cloud

Dive deep into cloud security with Chris Kirschke, Head of Cloud Security at Albertsons, and Karen Levy, VP of Product Marketing at Sonrai. In their session, "Strategy to Execution: How to Close the Identity Security Gaps in the Cloud," Chris shares battle-tested wisdom on navigating the complexities of cloud identity and access. Unlocking Cloud Security Secrets: Chris advocates understanding existing issues, emphasizing active listening and strategic questioning to craft tailored solutions. Employing the jobs-to-be-done methodology, he crafts roadmaps that align detailed outcomes with business goals. Strategic Execution: Avoid overwhelming challenges with a systematic approach. Chris champions regular delivery of tangible business value and the power of automation. His philosophy? Embrace efficiency, steering clear of "shiny tools" temptations until current tools are maximized. Focus on APIs and long-term impacts, not just flashy interfaces. Key Takeaways for CISOs:

• Problem Solving Mastery: Ask, listen, and strategize using the jobs-to-be-done framework.
• Strategic Brilliance: Deliver quarterly business value, automate relentlessly, and avoid overwhelming initiatives.
• Smart Tool Selection: Balance build vs. buy, focusing on time-to-value and long-term capabilities.
• Stakeholder Synergy: Communicate openly, prepare stakeholders, and maintain alignment.

Chris' systematic approach emphasizes a strategic path that enforces clear communication, meticulous planning, and the fusion of business acumen with cutting-edge automation. Elevate your cloud security game with this transformative approach.

Jeff Moncrief (00:00): All right. Up next we have Chris, who's the head of cloud security with Albertsons, and Karen, who's the VP of product marketing here at Sonrai, and a very exciting session called Strategy to Execution, How to Close the Identity Security Gap in the Cloud. Karen Levy (00:16): Thank you, Jeff, for the introduction. I'm Karen. I'm going to be participating in this session with Chris from Albertsons. Chris, I'll have you introduce yourself to our audience today. Chris Kirschke (00:27): Sure. Chris Kirschke. I'm the head of cloud security and product owner for our cloud security here at Albertsons. Karen Levy (00:34): Great. Let's dive in. We're planning a great discussion on everything from strategy to execution and how you get something done at a relatively big company when you're trying to secure your cloud. And Chris, I know from talking with you a bit, you've got some great experience that has fed into how you're approaching this today. Can you just tell us a little bit about your background, and what you've learned along the way, and how it impacts what you're doing today? Chris Kirschke (00:59): Yes, absolutely. A little bit about my background. I come out of the cloud space having been at companies like Hulu, working with PayPal, working with LinkedIn. Before that, working in earlier cloud migration and adoption, looking to layer in the security components through those landing zones. But in general, I started in the data center like most of us in pre-cloud, and you kind of take that experience, and that layers a lot of... There's a very big difference between how we do cloud security versus infrastructure security in the data center. So, a lot of that experience has been very valuable in ensuring that we don't repeat the patterns from previous lives. Karen Levy (01:49): Great. It's interesting thinking about the on-prem world, and cloud, and similarities, and differences. Tell me now when you're in a new situation, maybe you've joined a new company, how do you start that first part of the process, which we think of as just identifying the problem? How do you get the lay of the land and figure out what problem you want to solve, what's the biggest one to focus on? Chris Kirschke (02:13): Ask a lot of questions and do a lot of listening. And I think taking that mentality in your first 90 days allows you to really... People are looking for that fresh face, that fresh set of the ears that isn't going to nod their head, agree to commiserate, et cetera. When you come in, you really have to understand what the problems are, what the impact of the problems are, and how long those problems have been prevalent. Then, I think my best practice is always to then take a look at... I use jobs-to-be-done methodology, so how do you do your job? What tools are you using, what processes are you leveraging? And then, tell me really where the pain points are. And when you do that, I think you start to get that holistic picture of each of your stakeholders, and again, how they do their job and where you can help them? You start to build that roadmap for them. Karen Levy (03:14): Great. And follow-up question to that, just as you're thinking about talking to different people, identifying stakeholders, what are the broad range of people? What different teams and functional areas are you talking to when you're in that discovery mode? Chris Kirschke (03:40): Sorry, a little noise in the background. I would say your infrastructure teams, the folks that are actually deploying it, the IAM team is probably the most critical. Cloud is all about IAM, and then, I think your DevOps teams. Those are the folks that are you going to work with to make sure that your guardrails are inserted correctly, but your coverage ratio is where you need it to be. And then, at the end of the day, you talk to your other business leaders. (04:13): How can I help you? That's always got to be a... It's hard to have that because a lot of them are busy. They're like, "Just keep doing what you do," and you're like, "I just got here. I haven't done anything yet, so I'm asking you how can I help you?" And it's driving that conversation that is probably the hardest, I think. Because you end up with either the laundry list of all stuff that's been nagging them or you get a, "Hey, we're good." You really have to start to dig in to ask harder questions and get them to answer those harder questions around, "Hey, if I could increase your remediation efficiency by 30%, what do you think that would do for your life?" "Free up a bunch of my resources. Let's go." You start to get buy-in by showing output. Karen Levy (05:09): I see that. So, you're digging for real measurable outcomes that matter to the people that you're speaking with. Chris Kirschke (05:17): Yeah. And I think you have to because as you build out your roadmap or your plans and your strategies, it has to be aligned to that. So, when you build a product roadmap, whether you're at a company or as a practitioner like myself, one of the first things you want to do is be able to explain what business value you're going to deliver and what timeframe. I think that those questions are critical. Karen Levy (05:51): Any other tips or thoughts or maybe a recent example of what you've done to convince others that this problem you've identified by talking to stakeholders is one that the company needs to address or invest in addressing in some way? Chris Kirschke (06:08): Yeah. I would say avoid the wall of shame. We always do that. You've got this many vulnerabilities, you've got this amount of time lapse between fixing. It doesn't work. It doesn't help. I would keep it as just an appendix slide or appendix metric where you can actually go back to say, "Hey, we've done excellent work over the last quarter in these areas. But again, here's where we still have some lagging effective metrics." So, I think you want to be careful there. I think the other thing that you want to really focus on is how do you tie it back to either reducing risk, number one. That's how we get all of our funding and all of our resources. I would say focus on tying it back to risk. Karen Levy (07:07): So, what I'm hearing is don't focus on what's not going well from a security operations or workload point of view, but try to tie it back to business outcomes and the positive side of what can happen with change. Chris Kirschke (07:20): Yeah. It can't be all hunky-dory, but focus on making the impact more positive. Karen Levy (07:28): So, you keep a balance. Yeah. We're talking about strategy to execution today. In your experience, what other things are hurdles in your way when you have identified a problem you know based on your experience, the strategic direction you need to move in, you've got a bunch of stakeholders. Can you talk about some other hurdles people may encounter when trying to get over from strategy to the execution side of security? Chris Kirschke (07:55): Absolutely. Probably the number one mistake I see is boiling the ocean. You end up with a huge waterfall project that does nothing but slip and tire people out. I've seen more success, again, in that product model, being very clear about what you're delivering to the business from the business value. Maintain that on a quarterly basis, be very, very diligent, and I would almost say militant on what you actually keep and commit to delivering. The second part of that is, again, that helps you avoid that mentality around building big spreadsheets and task forcing around remediation, focus more on making enterprise decisions around what can be automated as far as where the business has a comfort level of being okay with automation through that remediation. Now, everybody's afraid to break something, but if you show here's low-hanging fruit that has a low risk to the business, but is still continually generating churn or data, then let's start to build that framework and show that you can automate remediation. And you just keep driving that remediation, that criteria until you get to a metric that shows how much you're driving efficiency with that automation. Karen Levy (09:28): So, you mentioned trying not to boil the ocean. How do you balance painting the big picture of where you're going, and then, breaking it down maybe to more measurable things? I think you talked about doing something on a quarterly basis. Do you show the big picture, and then, break it down or not even get to the big picture ocean view of things? Chris Kirschke (09:53): I think you have to show the big picture. I think you have to show here's what our yearly roadmap is going to look like, our 18-month roadmap. I would never go farther than 18 months between M&A in our area, which we've seen with Cisco acquiring Splunk and other acquisitions as it goes. It's not worth the effort to plan out that far. Plus, my company's getting acquired. Things are going to change for me in that timeframe. So, you want to keep it into a tighter timeframe. But within there, one day, when people can see that linear, hey, we're going to be here in 18 months. That gives you six quarters to actually show we executed on Q1. We had a 95% completion rate for the work that we want to deliver. You do your demo days. You show people this is what we now actually can deliver to the business. (10:51): But then, after the second quarter, you're starting to show that movement towards the goal. And that's where I think there's a lot of strategic items that move with that as you start to execute, i.e. you're starting to generate metrics out of those programs and those efforts. So, you're actually starting to... Your dashboard should become a little bit more populated. They should have better data on them. And actually, in that process, you'll start to get a feedback loop through your leadership teams and your executive teams around, "Hey, you guys are actually doing what you said you would do. What do you think about doing this?" Or they'll start to come to you. Karen Levy (11:36): Yeah. The topic of our conference in this summit is around identity and access in the cloud. Could you tie some of what you're saying back to a project in that subject area just to make it more... Paint a picture for us of how what you're saying would apply to something like that, that type of project? Chris Kirschke (11:57): I can't talk specifically about what we're doing within Albertsons, but in previous lifes, I can talk about we were inspecting Terraform runs for compliance, being able to automate a lot of that, being able to build automation around closing permission gap, delivering revamped IAM policies as a GitHub pull request rather than three to five meetings and engineering effort. We were actually able to deliver new policies on a regular basis, and developers loved it. The developer experience was excellent. They had time. They could come to our office hours, ask the questions, negotiate most of the time. And then, we could actually see that we had a decent metric from the time we delivered the PR to the time that it actually was redeployed. Karen Levy (12:55): Yeah, it sounds like there's two key things here, keeping stakeholders' open lines of communication, keeping them engaged and happy, and then, being able to measure things so it's not just all conversation, but you've got clear numbers tied to it. One thing I know that our audience is thinking about and we run into all the time is you're solving a problem, you've got stakeholders involved, how do you start thinking about, do I have the people onboard who can fix this in a homegrown type solution or we're going to look at different technologies? How do you go about figuring out how you're going to solve the problem when you look at technology? Chris Kirschke (13:36): That's an interesting one, and it's actually a fun one because what it allows you to do, what the approach that I usually have taken has been to leverage the one-on-ones that I have with my team members, to ask them about their background, understand what the skill sets are, and I'll build out a capabilities map. And then, you actually can take that and lay that over your product roadmap. And we have actually now started to use Cyber Defense Matrix specifically to lay out and say, "Okay, are we skilled in these areas where we have deficiencies? Do we need to hire? Do we need to contract? How long is that effort going to be?" Which will determine FTE or interim resource. So, I think from the cyber skill, the skilling capabilities, I like doing it that way. (14:27): I would say the second part of your question, I think, is more around build versus buy. And that, to me, the time to value always drives that conversation. A lot of folks in the industry, they come out of places like Netflix where they built everything themselves. There was very little that they didn't build their own. There's something to be said for that. It drives one heck of an engineering culture, and you learn how your business operates, and you are actually able to engineer the way your developers interact with your cloud security or your IAM security. (15:11): But not everybody's Netflix. So, I think when you look at it, you have to look at it as if I'm going to my CISO or my board, whoever for funding, and I say, "Cool, I want X amount of dollars to go solve this CIEM problem that I propose the permission gap," I have to be able to say, "Is that a million dollars to get it up and running? Or is that a million dollars to be in a steady state operations with a tool?" And I think that's our clearest metric around whether or not we would build versus buy. Karen Levy (15:50): So, can you talk a little bit more about that process for calculating time to value or other people that you bring into that process and bring along with you to come up with build versus buy or time to value for solving the solution? Chris Kirschke (16:06): Yeah. We use, it's called the jobs-to-be-done methodology. Let's take IAM, since that's our focus here. I would go to my access services team or my identity team and say, "When we are evaluating permission sets for over permissiveness, what's the remediation process look like? Let's walk through that. Is it a Jira ticket? Is it a backlog? How much of it comes in shoulder taps through some IAM process?" So, it allows you to objectively start to identify a lot of the inefficient processes. It also allows you to point out your existing tooling where there's deficiencies, and then, automation and integration opportunities again, or are you just going to have to scale through staffing? Is this something that you look at putting junior roles into for specific tasks? But I think it allows you to truly understand and put data around the decision-making process. Karen Levy (17:16): Right. So, how are you doing it today? How much time? And then, how much time would it take us to fix it with humans versus maybe some technology? Chris Kirschke (17:26): There's a lot of places that like to do it themselves, and they don't mind manual processes. I'm not a big fan of them, but that's just me. But if I can sit there and say, "Hey, I've brought in Sonrai, and I've got my time to value is less than 90 days to operational," versus truly a data point that allows me to say, "It would take us nine to 12 months to build this capability ourselves." Or we would be able to reduce the amount of manual effort associated with this and redeploy some of those resources by buying the tool, then that opens up additional opportunities in the roadmap to be executed on. So, you always have to look at it as a juggling act. Karen Levy (18:14): Yeah. And I know a lot of times, there's value is added over time, so maybe it's a little while to get to full value, but what is the immediate value versus the end state value? Do you factor those types of things in as well? Chris Kirschke (18:29): Yep. Karen Levy (18:30): Yeah. You just mentioned that you're not a fan of the homegrown, build-it-yourself when you want to go look at technologies. Any tips for the audience in terms of how you discover technologies and tools that could help solve a problem? Do you go out and do your own research? How do you go about engaging with that? Chris Kirschke (18:51): So, it's always going to depend on the size of the organization. We're a fairly large company, so there's always somebody to pull the Gartner reports, the Forrester reports, whatever analyst firm you're signed up. That being said, also my style is more like, hey, we don't call them tools, we call them capabilities. That's critical, in my opinion. We principle of least privilege, capability to Albertsons in our infrastructure. But I also use it as a leadership function, whereas I work with a team to define the business requirements that I've gathered from my stakeholders. And then, they start to actually map the technical capabilities that they think they need. (19:42): And then, they will actually do the product evaluations, and they'll score the vendors, and then, we'll make a choice from that perspective. I think critically, a couple of things are really important to think about. One, don't get enamored with the UI. We try to maintain a rule where we run everything headless within 181 days. I don't want people logging into consoles for a living. I want those processes being automated. They should be working on maintaining that automation and those integrations rather than clicking around the console all day. You still have to do it occasionally, but you should get to that point within six months. The other piece there, it allows you to truly focus on the APIs that a lot of these modern products are built on top of. And once you've actually started to look at it from that perspective, it allows you to start to think about the art of the possible as when it comes to the tool or when it comes to inserting that capability into your business. Rather than, I got a new dashboard, cool. Can I automatically send that out on Fridays now? Karen Levy (20:55): I like that. I think it's interesting when you're looking at tools, obviously you see a UI, you're getting a demo. But you're thinking, yes, there's going to be immediate value. Maybe you start using the UI, it's up and running. But then, long-term, what's best for the company, and running headless, and moving off of that, and automating it even more. So, that ongoing increase in value is what I'm hearing. Chris Kirschke (21:17): Yes. Karen Levy (21:17): Speaking of that time to value, all these great things, and yet, we know that companies wind up with shelfware. So, how do you ensure that when you're buying and implementing, you don't get stuck in that middle ground of I saw the vision, I sold the company on time to value. How do you make sure it works out the way you want it? Chris Kirschke (21:39): So, there's two things there. There's, obviously, adopting the product model forces you to look at the whole set of capabilities that you want to implement over 18 months. And when you do that, you're looking at least 80% of the capability. There's going to be stuff you don't use some of out of each of the tool that you buy. But at least you want to use... We have an epic in all of our product roadmaps around road to 80%. So, you cannot ask me to replace a tool or to expand the tool unless you just have license capacity, period, and it's a risk. But don't come to me and say, "Hey, I want to get a shiny new toy," without telling you that you've got 80% of the existing toy in use, and it doesn't meet our requirements. When you run the product roadmaps, that's where you're like, "Okay, cool. In the best case scenario, I'll use 85% of the capabilities." 18 months from then, if I'm following my roadmap and executing correctly, and we're on track, then you should be able to achieve that. Karen Levy (22:51): That's great. I like that 80%. It's not 100%, it's not the magical everything perfection, but it's a good attainable goal. When you're working through that, getting time to value, when we started out the discussion talking about getting information from stakeholders and stakeholder buy-in, how do you keep them in the loop? How do you make sure that you're closing the conversation with them, delivering on what you sold them as you're getting this value out of the product? Chris Kirschke (23:19): This is something I was horrible at in the beginning. I like to hide in a corner and just do stuff. Karen Levy (23:26): What have you learned? Chris Kirschke (23:26): Communicate, communicate, communicate. When we started off in our journey around principle of least privilege, we wrote a North Star statement, kind of a interesting way to go about it. But we wrote it, and then, we ran it by all of our SLT. We wrote it by all of our stakeholders. And we took some of their inputs and we refined it. It took about three weeks to get that done. And then, I would say a lot of that was the initial metric. What is our North Star metric for principle of least privilege? Well, it's plus minus on the permission gap. That is really what we're going back to the business at an executive level saying, "We have one metric. We've closed the permission gap on this month by X." (24:18): Second part of that's focused on the remediation rates and that partnership with your stakeholders because you're going to be building a process. Once you've built a process that includes more than just yourself and your own team, you are now going to be reported on by other people. So, you want that partnership in place to be able to communicate accurately that you're actually effectively reducing that, you're doing it together within the business context and with your other stakeholders. And the last piece of that one is always prepare your stakeholders for your reports. No surprises is the golden rule. That'll kill your partnership in a heartbeat. Karen Levy (25:06): Nice. All right. A bunch of questions have come in. Before we jump to those, any final recommendations for folks in the audience? I think everyone either right now or in the near future, is going to be facing some of the challenges we've talked to in this session. You've learned a lot. You've shared a ton, so thank you for that. What is something someone can do next week when they're back at work, and what should they be thinking about? Chris Kirschke (25:30): Don't worry about the law of large numbers. We turn on a lot of our tools, whether it's VM, CSPM, CIEM, and it's a holy smokes moment, right? Just go figure out how to draw the line in the sand with your stakeholders to build those processes and say, "Okay, yes, we're going to remediate the really, really risky stuff. But let's," I hate saying this, "Shift left. But let's start to work on how we stop the problems from actually happening anymore." And I think they'll appreciate that because instead of, again, the wall of shame, you're asking them to help everybody walk into the hall of fame. Karen Levy (26:17): Oh, I like that. All right. Chris Kirschke (26:19): Yeah. Just [inaudible 00:26:20]. Karen Levy (26:21): Let's see if we can get to one question. Adrian asked about, you talked about knowing when you need tools, but do you have any questions that you always ask vendors? What are your tricks to really getting to the root of what a vendor can do to help you? Chris Kirschke (26:43): I would say how focused are they in that space? We have a lot of folks in the industry, a lot of vendors in the industry that now do everything. So, are you focused on the problem that I'm trying to solve or is this one part of your set of solutions? The other part of that is I really don't. I want to see how focused you are on my problem, but I'm really looking for how they answer. Are their answers clear, specific, factual, complete, respectful? I've seen a lot of interesting pitches over the last few years, and I really just look to see if this is a vendor that we can be a partner with because guys like me, we bring our vendors with us at our next bowl. I've known many of these folks for decades. You always want to know that you can trust them as a partner to make me and my program successful. Karen Levy (27:50): That's great. I think we're going to wrap it up there. I like that we talked a lot about identifying the problem at the beginning of the session, and then, we close it out with when you're talking to the vendor, make sure the vendor is focused on that problem you've identified. So, that was a great tip. And Chris is going to stick around in the chat. So, thank you for this great session, Chris. He's going to stick around in the chat to answer questions, so keep them coming in. And up next, we're going to hear from Accenture is going to talk to us about filling the security void left by PAM and IGA solutions in the cloud. So, stay with us. Thanks again, Chris. This was great. Chris Kirschke (28:22): Thanks.