Keeping Pace with Cloud Security: A Guide to Maturity Models with Rich Mogull

TLDR;

• When it comes to Cloud Security, it needs a mindset shift vs on-prem security. And Cloud Security Maturity Model helps with that.
• Biggest challenge with Adoption of Cloud Security Maturity Model is expectation setting. Work with Leadership to set the right expectations.
• Before acting on Maturity Model, evaluate the current Level, set a Goal and work towards it. This helps teams to monitor, measure, communicate about and achieve the goal.

Transcript

Host: Hi, everyone. This is Pursottam, and thanks for tuning into ScaletoZero podcast. Today's episode is with Rich Mogul. Rich is the SVP of Cloud Security at Firemon and founder of Securosis Research. He's been working hands-on in cloud security for over a decade and has made, funnily, quite a few mistakes and learned a lot of lessons from that as well.

And that's what we want to tap into today so that we can learn some of it from him.

So for our audience, Rich, do you want to briefly share about your journey?

Rich: So yeah, I got involved in cloud security. I mean, I've been in security for about 25 years now and got involved in cloud security about 13-ish years ago, right around the time the Cloud Security Alliance was created. I started looking at the technology and realizing, hey, this is really interesting. I think this is going to be something someday. And that wasn't a popular opinion at the time.

There was, I was talking a lot with like large enterprises saying, we're never gonna go to the cloud. We're not gonna trust that thing. We're not gonna let that book company have any of our data. Sure enough, I was right. But it's also evolved tremendously. I mean, in those days it was, you could do ephemeral virtual machines. There was no persistent storage yet. That was just release with the elastic box storage on Amazon. Azure didn't really exist yet. There was no IAM when I first started on Amazon. Everything was, you know, root account all day, every day. That's all you had. I think they were doing early preview of it around the time I set up for my first account. No VPCs. That also launched quickly after I first started. So it was a whole different world and learned a lot along the way.

And I, you know, the advantages is I describe it as I got to learn, I got to start with a Commodore 64 and made it a lot easier. Like I could just learn as the cloud kept improving where people who get started today, you know, are starting with a crazy supercomputer and having to jump right in and figure it all out.

Host: So I feel like we can record an episode only on AWS evolution with you. Like how has it started, how it has matured and how is it doing today? So yeah, yeah. And one of the things that we do with all of our guests is we ask them this question and we get interesting answers.

What does a day in your life look like today?

Rich: I have such a weird life. So I don't have anything like normal days. So typically I'll, depending on whose turn it is to wake my daughter up at 6.30, because she has school pretty early, I'll wake up, usually I just grab coffee, catch up on news, and then my day kind of breaks out depending on what the focus of the day is. So.

My main job is on the SVP of Cloud Security at Firemon. And my role there is primarily to basically run our cloud defense product. So myself and our cloud CTO, we work together. Some days I'm going to be recording videos that are going to go up on a marketing website. Other days, I'm going to be working on product strategy and defining new features for the product, doing research on some new thing that needs to be like some new Amazon or Azure issue that maybe we can build something into the product to address.

And then I hand that off to the development team. Usually a couple of meetings, not too many a day. So there's that block, which is a mix of research for what we should be doing, product strategy, go to market, and sometimes technical. Today I'm writing AI prompts to extract data from a compliance thing and map it to some of our internal stuff. So I have some database scripts Python code and everything I'm using for that.

So that's great. 80 to 90% of my time is that piece. Then for Securitasys, the new thing is, because I still do some of that. And it's interesting because that work feeds into my role in product strategy because I still actually advise organizations. So I'll do some strategy, or basically we call ask an expert calls through this organization called IANS, the Institute for Applied Network Security.

So I'm one of their faculty members. I'll do one to five calls a week with a company who's an INS client about, hey, we've got this issue. We spend an hour kind of focusing in on what, how do I do cloud forensics? Or how do we redo our governance? I'll also be writing stuff for the cloud security alliance. We're working on the new version of the CCSK training and the cloud security alliance guidance. So there's usually some time spent every day and working hours on that.

And then Cloud Security Lab a week, which is I'm trying to keep it mostly the evenings and weekends, it takes me about four to six hours to make a 15 minute lab on average. And so it's working on that piece of stuff as well. So any given day, I don't know what it's going to be like, but those are the activities that occur and then I'll pick up a kid from school and I'll go work out. And recently I just got my pilot's license. So I've been getting flying papers in.

I have to do my paramedic refresher next week, so I'm going to miss all of work. It's just, it's a very weird, unstructured lifestyle.

Host: Sounds like you have a lot going on in a normal day, like starting from like at Firemon, your research, working with other teams, sales marketing, and then the securities where you do advisory as well. And also you have cloud security lab every week. And we'll be talking about cloud security maturity model and Lab a week as part of the podcast.

So let's dive in. But before we dig deeper into Cloud Security maturity model and its significance, for our audience, can you briefly share what Cloud Security maturity model is?

Rich: Yeah, this was something that myself and Mike Rothman made a few years ago, three or four years ago, I think at this point. And we were approached by IANs, Institute for Cloud Network Security, to see if we could, because they have a lot of like these very large enterprises that are their customers. And a lot of them were asking questions about what they should be doing for cloud security and where they should go. And not the detailed technical questions, but the, how do we build a cloud security program?

I mean, We've been in business for 50, 70 years or a hundred years in some cases. Now we're moving to cloud. Like how do we do this in an organized way? And so our first batch of research we came up with was the, the maturity model. And it was really interesting. So the idea behind it was to tell a story. And that story is we don't like the maturity models that are, if you do these five exact things, then, you know, that wasn't what we were meant.

We meant it to be used. It was meant to show you what maturity would look like. And then we divided it up into domains and categories. So we can talk about those pieces later, but the areas of security. What we did not anticipate is that organizations started finding it useful to use as a cloud security framework. Not the maturity levels themselves, that's helpful.

It turns out we came up with a really good way of describing the major areas of cloud security that was didn't make everything look like it overlapped with on premise security. And so that kind of the origins of it. And then, you know, we'll talk about version two and how we took those lessons and try to make them better.

Host: Also, a follow-up question to that is, like,

What were the cloud practitioners doing before the maturity model was introduced? And another question is, why do you think it's valuable for organizations to navigate the complexities of cloud security?

Rich: Yeah, that's a good question. I mean, they're doing what many organizations do today, because as much as I would love if everybody used my maturity model, they don't. And so it's learning lessons from peers, and they go to events. A lot of it is cloud provider driven. So the providers have well-architected framework. Both the Amazon, Azure, Microsoft, and Google, they all have their versions of that. And following their different pillars, or whatever their terminology is, I tend to be more familiar with that.

Amazon, but Microsoft's actually done a pretty good job with theirs as well. That guides a lot of these efforts, and at least in the organizations that I've worked with, it's a lot of talking to peers and maybe getting some people some training and following the cloud provider frameworks has been what's driven.

Where we saw a problem though, and I still see a problem, is a lot of places will take… the something like the NIST 853 standard and just try to apply that to cloud. Now the cloud security alliances has done a great job with some of their tools with the cloud controls matrix, the security guidance, which we wrote most of the guidance document, although we have to redo it. It's out of date now, but that kind of helps focus.

But even those have kind of tried to be a bridge from what you've done before to what you need to do now. The… with what we do with the maturity model is, is we said, hey, if you're just looking at cloud security, what would this look like? And so that's the extra guidance you get. So instead of having to take NIST 853 and try to convert it and use that for cloud, tell you this is what you should focus on for cloud.

And then you map that back to NIST 853. It's fully compatible with that or NIST CSF or whatever other frameworks and standards you want to use.

So that was kind of the main, I know it's not like a huge difference. It's a little policy wonky, but it does help. It just is like, these are where I should get started in cloud and how to structure it. And then I can just go do my control mappings later.

Host: Yeah, I think one of the things that I'm getting from your responses, from your answer is it's the mindset, right? When you are in on-prem, it requires a different mindset. When you are in the cloud, it requires a slightly different mindset. I mean, doing the NIST thing and then doing a conversion from NIST rules to the cloud rules might work, but the maturity model directly sort of addresses the cloud.

And then you can go back if you want to do the on-prem as well. But it's the mindset shift with which it helps, like the maturity model helps with that. And that is often a challenge with organizations, because if an organization had an on-prem and they're moving to cloud, they're still thinking the cloud in an on-prem way sometimes. And that creates internal challenges with alignments and with setting the right priorities even.

Rich: Yeah, you have it exactly right. Yeah, I mean, you know, that's exactly what I think the, what we try to do with the maturity model is to, to give you a way of getting that, that shift. And, and again, version one was not meant to be like a framework version two is meant to be a framework. That's one of the big differences and that kind of guide along that a little bit better.

Host: Mm-hmm. Yeah, I mean, we'll talk about version two as well. But before we go to the version two, I have one last question. Like, maturity model should align with organization broader security strategy, right? Cloud security strategy.

So let's say I already am following NIST or something like that. How does cloud security maturity model align with the overall strategy? And how does it complement with existing frameworks. Any thoughts on that?

Rich: Yeah, the first version, we didn't build it to be thinking that it had to be complimentary at all, but some of the actual changes in version two were to better align. And let's put specifics in place.

So there's 12 categories that we focus on in three domains. And the domains are our own construct, and I'll talk about the domains separately. But the categories are very well aligned with things like NIST, CSF, and the clock controls matrix, for example, it's governance, identity and access management, organization management, network security, data security, workload security, incident response, risk management, compliance, like those categories are very commonly seen in other frameworks. So the categories can sort of map across.

Where we added a little more for the mindset shift is those categories are organized in domains. And so there's a foundational domain, which we describe as these are the core shared services things you should do first that are gonna be consistent.

So governance, IAM, security monitoring, and organization management, which is like your account hierarchy or your management group hierarchy, whatever project hierarchy. So getting them thinking of Let me start there and focus my efforts there.

The next we call structural and that's, you could probably guess network application data workload, that's really the same stuff we've always done. But the reason we broke out separately is that's going to change from project to project or deployment to. So like, yeah, one app sack is going to, your network security is going to be different than another one. You'll have some shared services and standards and stuff, but our mindset this is thinking of, hey, technically each of those is in its own data center, so it should have its own security customized. So that's the organization of those parts of it. And then the last are procedural, which is like these are the things to help you be better over time, risk in provider selection, compliance, resiliency, and incident response. And then we have an overlay for DevSecOps and an overlay for.

So that's the thought is like just shifting the thinking, but everything I just said is in every one of those other frameworks. But we do skip certain pieces. We don't have, you know, BYOD and mobile policies. You know, we don't, we keep human resources, like all of these things that should be done at the organization are not cloud specific. We leave all of them.

Host: Mm-hmm. I really like how you have structured, right? There is a core set of components that everyone must do. And then as you mature, you focus on other services and other sort of categories as well. That's at least as a person who is thinking about adopting it gives me a framework, right? Like, how should I plan it out as part of my cloud security strategy? So yeah, sounds very helpful.

Rich: And that ties to the idea that we wanted it to tell a story. It said, yeah, it's a maturity model, it's a spreadsheet, but can it tell the story of what it looks like as you progress? And so part of it is, how do I go down vertically, across these domains and categories and kind of, how do I figure out how to prioritize those pieces? And then horizontally, which is what's the maturity kind of look like at each of those phases? So that was the goal is just to… describe a journey, it's not the same as a model. Like DOD has their maturity model and it is, if you meet these XYZ requirements, you're there. Now we have added all that, but the focus is on the story first and the measurement set.

Host: Mm-hmm. Oh. Now, let's say I'm convinced that I should adopt a maturity model.

What challenges have you seen other leaders, security leaders face when they implement the maturity model? And how have they worked around it?

Rich: Yeah, we've done that. Like I've done some projects, actually, to some organizations where we use the model as, as a framework for like helping them build their security program. And that's actually, again, what led to a lot of the changes in version two is to help with those issues. So I say a couple of them are a few things. One is you're not going to be level five on maybe anything like, you know, I don't know about you, I'm kind of a completionist.

Like if I have a problem or something, like I have to like get all the way to the end. And people look at the model, oh, I have to be level five. I'm like, but you don't like level five is the cloud unicorns, member practices, but they also have the budgets and they have a reason to be a level five, like most organizations I talk with, I'm like, you know, your goal in the next two years might be to be level three at your baseline with like a couple of pockets of level four.

But you don't need to be level five and you shouldn't plan on that because especially for a legacy org, getting a level five is really expensive because you need to do a lot. You have to hire your own security development teams to get to a level five. That's not achievable for everybody. It's also a moving target. Level five is what's mature today, which is different than it was three, four years ago when we first wrote it and it'll be different in five years.

So that's the first one is expectation setting. And the challenge for leaders who understand that is if they go to use the model to communicate up to their management, their leadership, if they don't communicate that well, their leadership is gonna go, why are we only a level three? And because that's what's appropriate for us. So I think that's one of the big challenges.

The other is that they're It's great to have this concept, but you know, day to day, there's still like operational stuff that needs to be dealt with. You still do need your control requirements. You're going to be dealing with the politics of other organizations. If you have already been using 853 or some other benchmark internally standards, you still have to, you do have to do all of that. And so the challenge is, is we translate that out in a structured way to not overwhelm us.

Host: Make sense. So yeah, what I'm hearing from you is, of course, it's amazing if you can get to the level five, but you should also make progress towards that and show that progress to the leadership so that you get buy in from them. Like, let's say you need budget for hiring. If you show that progress, leadership might see value and then help you with the budget as well. Right. So that you can do the hiring and you can move up the ladder even the maturity model.

Rich: Well, it's also, but it's about goal setting and expectation setting. And you shouldn't just assume level five is your goal. Your level should be what's, you have to have an honest discussion of what is appropriate for us. So, if I go out running, I'd love to run a four minute mile. It's never going to happen.

I'm in my fifties. I will never run as fast as I did, you know, run a single mile, you know, in five minutes, like I did when I was 18, like, let's have some expectations, but I can have goals and improvement. And so just really important to set that up. And this is any model or framework. Everyone's like, bam, I got to be at that. You don't.

Host: Yeah. Yeah, no, that's a good correction that you made of my statement that, yeah, it's often that expectation setting, like setting it as a goal and you get there. And another key thing that you mentioned is the goal. The goalpost is also moving, right? It's not a fixed set that you reach there and you are done. It constantly changing as well. Makes sense. So let's talk about version two.

Rich: Yeah.

Host: So there is this recent update to it. What are the major drivers for this change?

Rich: Yeah, so like I said, we never planned on it being used as a framework. And it turned out it was useful for that, for helping people figure out how to, again, the mindset, you said it better than I did to get that mindset shift. So we added more things to support that. So one is we did adjust some of the categories because we realized having the model for a few years in actual consulting engagements, that there were stuff we missed, for example, governance. was not originally in there.

So we added governance because we realized that's the root of all evil in cloud is governance. It's not technology. The other was we had a category like we called it account security and structure. Well, it was just organization management, which is what NIST uses. And the class here clients. So let's just switch our language to be the same. We had defined our maturity levels in a weird way where we called it no automation, full automation.

Because automation was kind of the story, more mature you are, more automated you are. We're like, no, let's just use the standard capability maturity model definitions. Automation is still part of that, but let's use the standard definition. So there was that standardization, and then just updating the boxes that, you know, we had DevSec, like stuff like that, DevSecOps and AppSecurity, it turns out, well, it made more sense to consolidate those.

The big… Big change though is that we decided to make it more of a usable as a tool. And instead of going through and us describing what maturity level of whatever would be, and some of this was because of a big project we did over with the European Government Agency, they had asked us to actually write out control objectives for every maturity of all. So we took that work and made a more our version of it. So the new version, we have the front page looks kind of the same. It's a graphic with boxes and spreadsheet.

Behind that now, for every maturity level and every category, we have between one and three cloud security control objectives that are key indicators of security at that level.

And yeah, and so we're trying to be very clear that these are our take on those key indicators, and you should optimize them. Like some of these are not gonna work for you. But we added those key indicators, which is an example would be, use MFA on all console login access. Then we started to build out the spreadsheet for a single control specification for each one of those control objectives that you can automatically assess.

Now there's a lot I think like 30% can't be automatically assessed. It's got to be manual. Also, we work it out for AWS, but we haven't filled it in for Azure or Google yet, which is, I kind of hope that the vendors will like, get excited about that part of how to meet those control objectives. So now you can actually load that up into your automation tools. Now it's all going to be released publicly.

At FireMond, we actually built it into the tool, so you can plug in an account that will automatically assess to all of the, for Amazon at least, for all those control specifications and give you a maturity rating. I do want to emphasize though, that this was, it's version one of version two. These are the control objectives that we thought were the best key indicators and the ones that we thought could be automated to the best degree possible. But, you know, when organizations are actually using this, they should...

Now we've got some full-stop security lines that's going to be down the road. Because one thing is to go through the entire cloud controls matrix, CCM, and actually put maturity rates on all of those. And then that's really going to blow this up in terms of our ability to get a better, much more combined the qualitative and the quantitative.

Host: Yeah, yeah. And one thing I really liked is that 70% of it can be automated. I mean, no matter which framework you look at, you cannot do 100% automation. There are manual aspects, but 70% is really high. And that should give confidence to cloud practitioners that if we follow some of these controls and the automation parts, it will help us get the best results to a much better state like maturity state. So a follow up question to this is with the version change, how do you see existing like organizations who have followed the first version?

How do you see it impacted?

Rich: Yeah, like we've been working with one that they've been pushing us actually for version two. What they're going to do is they're going to take that and they'll just put a plan in place in terms of making the shift. I don't think because we didn't have the control objectives in the first version, it wasn't really being used in automation. It was being used more as a discussion tool. So for those organizations that now move to version two and start adopting some of those control objectives as measurements. So evaluate them, pick the ones that work, and then measure it out. And we've got a couple of tools that will do this.

One from IANS is, IANS has a diagnostic, which is a qualitative survey tool. And you can go in, you know, and it can take anywhere from 15 minutes to an hour, depending on how much time you want to spend with it. You fill out survey questions, it'll actually generate a PDF of maturity.

We've had a couple hundred organizations use the version one. So I think we had over 200 organizations use that. And we produced a report with anonymized, you know, generalized metrics. For those organizations, they would want to go through and use the diagnostic again to give them their baseline. Because that's going to tell you kind of generally where you are. And that's the tool to help you figure out what, give me a sense of where I am and where should I be going? Like what areas? or my strengths and my weaknesses.

So that would be kind of the first step for them. Now, then you can either use the survey, use the spreadsheet that's just about to be released. I have to double check. It might not go out until next week for my ends, where you can actually do the control of JXIS and the controls to start measuring them. So again, come check out Cloud Defense. We've got that built in. You can use it for free in the product and connect to your Amazon accounts.

It'll automatically assess the quantitative stuff. And then you can also answer the control objective questions more specifically. So it's like the Ion Survey diagnostic is the top level to get you started and figure out, that's what I use to have that initial discussion of, where are we? Where do we want to go? Then you plug in a tech tool. You can do it yourself. You can map your own existing CSPM results or whatever you're using or come to us and get all the nice pretty charts already.

But then you actually map out exactly where you are on each of your individual deployments, your Amazon accounts at this stage. And, and then that's, then you can build your roadmap for, you know, where do you want to improve? Cause you can, you can find cool stuff. Like you might have one team that's, you know, level three and level four and everything, maybe the rest of the org is level two, level three. So you can go to that team, like take their practices and start moving those into the other parts of the organization.

Those are some of the kind of the ways that you can actually use this from a practical standpoint to improve.

Host: So it helps you understand the current state and also compare it with other accounts, let's say AWS accounts, and start setting a plan how you can improve collectively and also from an individual account perspective as well. So now, like last question on this topic is, how can organizations use this new version to improve their cloud security processes?

Rich: Yeah, I mean, I think the, you know, again, when I go in, I always like to start with either discussion or have them use the diagnostic and that's the like, where do you feel that you are right now? And especially, I found most people answered those questions pretty honestly, I did work with one company, guys like I were level four and everything.

Like, okay, but because, again, the very first thing you want to do is figure out, you know, from our program, like how do we feel about it and where do we want to go? And then the next part is this discussion of where should your priorities be? Like if everything is a level two or a level three, maybe for your organization it makes sense to focus more on governance. Like you don't have a cloud security center of excellence or a central cloud team or you don't have the right policies in place.

So with the… At a high level, what the maturity model is meant to do is to show you the areas you can focus on and help you figure out which ones you want to prioritize. As much as it's great, we have all the more individual control objectives that work. Those are just key indicators. That's one thing of a hundred things in that at a given maturity level, we could potentially look at. Just to let you know, if you're doing this, you're probably around here. But again, it's just meant to kind of help you prioritize and have a sense of what it can look like. Like, all right, well, what does it look like to be a level four? Which of those things do we think?

Host: So sort of understanding your current state is the first important step and then sort of figuring out what's the goal that we want to achieve and then plan out how you want to achieve that. Not end state, but a particular milestone rather. That makes absolutely a lot of sense. And it also helps security leaders show progress as well. Right. Like since you have a milestone, you can show progress at a defined intervals to your leadership as well. So yeah, makes a lot of sense.

Rich: And this is why it's really important not to just hone in. Yes, we have control objectives and controls listed. Your goal shouldn't be to achieve all of those controls because I'll tell you what, in some cases you can achieve a large percentage of the level four controls, but you're still a level two organization because all you did was target those specific things on the list, which is a very small, very small sample of all the stuff you should be doing. Now we tried to pick ones that you can't.

Generally, you won't be doing that unless most of the other stuff is there, but you can game it for sure. And so I don't want people to look at this as something to game and to target and to show off because like you're, yeah, you're, you'll just go down a really bad path.

Host: Yeah, yeah, absolutely. Now let's go to the next topic, which is around learning cloud security. So I have recently started an initiative called Cloud Security Lab a Week. At least to me, correct me if I'm wrong, it sounded to me very similar to Exorcism, but for cloud security, very focused on cloud security.

So what made you decide to start a lab for Cloud Security?

Rich: Yeah, so I've been teaching cloud security for a very long time. And 12, 13 years now is when we did the first class for the Cloud Security Alliance. I teach at Black Hat. I've run a bunch of private trainings. And I was kind of coming up with an idea of, like I see a lot of posts in some of the communities you're in. Where can I get started? How can I learn this?

And there's pros, plural site courses and I, you know, all these various sites and everything else. And at the same time, I had a bunch of friends who were doing newsletters. I just thought, why don't I have a newsletter where it's 15 to 30 minutes a week. And I start from the beginning and it's all hands on. That's, you know, very, I mean, of course I do have lecture parts of it, but it's focused on the hands on and just, if I were to have an infinite amount of time instead of a three day class, what could I make that look like? And then could I give it away for free and just kind of, I kind of just want to change, I want to be disruptive with it, to be totally honest.

Host: Yeah, so I like the format because you have a lab, right? You are not just reading text or you are not just watching a YouTube video, but you are actually doing hands-on lab, which helps you learn the concepts much faster compared to like traditional learning, like learning through text or videos. How did you start this journey?

Rich: I was just, I don't, it was kind of weird. I was like kind of coming up with an idea around this. I wanted to do something, you know, around getting more of the, because I have just so much of this educational content I've built over the years. But it's frustrating. Like, you know, when I write the CCSK, like we're doing the new version of that now for the Cloud Security Alliance. It has to be structured fit within a timeframe and it's driven towards a certification standard. And so what if I just...

I did my own thing and then I was also looking at some of the newsletters I read every week and found those were interesting. And then it kind of all came together when I came up with the stupid name of Cloud Slaw. I'm like, oh!

Host: No, it's very catchy. Honestly, you I don't know why you're saying stupid, but yeah, it's very catchy like Coleslaw with sometimes the so CloudSLAW.

Rich: Yeah, and I came up with the name and then it all started falling into place. And I'm like, well, what should it look like? I want it as a newsletter that people like you sign up and then you get all of it in order from the beginning. Uh, you know, I'll have a hundred labs someday. You'll get every lab in order from the beginning. Okay. But then I also wanted people who just want to jump in and see all the content. Maybe just go onto a topic, have that.

So I'll do it also as a blog post. And I found a platform that did that. And then the YouTube videos is I've taught so much, I know people really need the walkthroughs. So then I started doing the YouTube videos, which is, you know, why we get to do this, I'm staring at a teleprompter and I've got lights in my office and microphones everywhere, but I had a lot of the equipment to do that already. So that's kind of where it came together. And then it was the content. Can I break these down into an average of 15 minutes and maybe a few that go to 30 minutes, still cover the concepts and still have a complete lab. And so there's a lot of behind the scenes stuff I've been working on for that.

Like and have it be very cost effective. So writing cloud formation templates so that, hey, if you didn't do these other five labs, click this, the template will deploy what you need and now you can do this lab. Concepts like that to come into play. And then what order do I teach in? And it's a very different order than I have ever taught these topics.

Host: Make sense. Now, last question on this is any pearls of wisdom that you have for anyone who wants to start something similar, maybe for other areas of security?

Rich: Yeah, so I mean, interestingly enough, I've already had two friends who want to add their own content to CloudSlaw. So we actually might have different learning paths starting up soon. But I use the Behive platform. It's a newsletter platform. And then it has an automation capability so you can actually do sequence automations of posts. And then it also supports the blog post. So that was a big piece of it.

I would also recommend if anybody… wants to get into doing this from an educational standpoint, really put time in and learning how to make good labs and step-by-steps. I have learned the hard way over the years, things like I have to show the screenshot of the button that says next. I have to, I can't skip steps. I have to make sure the flows are, because everybody learns in different ways. So that's really important.

And then the other piece would be make sure you're not just showing somebody how to do a technical thing, but give them the background about why it matters. So for every one of my labs, I have the lecture section and I call it lecture, right in the email template. And then I have the lab itself. And it's not long. I try, I record one on IAM roles. My first take of it was 15 minutes of lecture and that was too long. So I just, I sliced that in half and I re-recorded it in seven minutes.

And then five is, you know, seven minutes or something along those. So like that, those are some tips on like how to build this out.

Host: Okay, makes sense. I liked the part where you said that even you should not skip that you have to click a next button because sometimes you as a listener or as a consumer, you feel like, hey, how did this switch happen? Like what exactly was done in between? So having that detail oriented content would help the readers or like the audience better. Yeah, that's a very good, very good suggestion.

So, and that's a great way to end the questions section, security question section as well.

The next section is focused around rating security practices.

Rating Security Practices

In this, I'll share one security practice and you should rate them between one to five, one being the worst and five being the best.

So let's start with the first one. So huge strong passwords that contain a mix of uppercase, lowercase characters, lowercase letters, numbers and symbols and change them frequently and avoid using the same passwords for multiple accounts. I know it's a pretty long one. This is more around password policies, right? What's your take on that?

Rich: Yeah, I'm gonna give that a two out of five. And so here's what I like about it. Long complex passwords, absolutely. And different passwords for everything, absolutely. That, use a password manager. I mean that, changing your passwords, nope. And in fact, I have some of my, even some of my sensitive accounts that are short passwords that I haven't changed in 10 years.

Why? Because I have MFA turned on. So I think that the changing passwords every 30, 60, 90 days is, I'm sorry, can I use bad words on this show?

Host: Right. No, please go ahead. That's okay.

Rich: I'll just say BS. It's just BS. It's like, it's not a modern practice. A modern practice is strong passwords, password manager, MFA. And then you should never have to change your passwords after that. Now look, if you have service accounts and things that are stored like in files on servers and stuff, static credentials, it's a whole different ballgame. But for users and my friends and family, I write your passwords down. Yeah.

Host: Mm-hmm. Yeah, I agree with the MFA part and rotation. The more complex it is, sometimes we tend to write it somewhere. And these all come from the security framework sometimes, right? That these recommend that you rotate your password. And it has become a practice everywhere that you should rotate your passwords now.

Rich: Because we didn't have MFA. So before MFA, you had to rotate your passwords. Or MFA was really expensive. RSA used to charge a ton for that stuff. Now MFA can't be free, basically. So yeah, MFA changes the game. Or better yet, for the more advanced stuff, go get some YubiKey's for I don't know if there's this showing, but I've got YubiKey's. Yep.

Host:  Yeah, yeah, like something like this. Yeah, absolutely. Yeah, the next question is, develop and regularly test an incident response plan to help quickly detect, respond to, and recover from security incidents.

Rich: Absolutely. So the most fun I've been having is I paired up with Will Bengtson over at what's his title, Director of Security Engineering at HashiCorp. And Will and I have been teaching Cloud Incident Response at Black Hat for three years now. And we put a class together. We built a whole training platform. And that's been a lot of fun running around doing teaching Cloud IR. But I'll tell you this. So today, the iPad sitting next to me American Heart Association, Advanced Cardiac Life Support, protocols on there, because I have to go recertify my paramedic on Monday and spend all of next week in getting my 60 hours of paramedic recertification training done.

When I do my disaster response and my emergency response work, it's all practice, drilling incidents, everything from when I was younger and doing firefighting to my current disaster response scenarios and incidents of all different sizes and testing the frameworks and making sure what we do works and making sure the equipment works and that's essential for incident response. So yeah, I mean training, testing, running exercises and drills it really is important even if you have a busy team. You know, very busy fire department, every busy ambulance service, police department, they still pull their people out for training.

They still pull them out and run scenarios because you have to train for the ones also you don't run every day or the training allows you to be evaluated as you go. I think it's absolutely critical.

Host: OK, makes sense. The last one is continuous integration is must for DevOps practices. Security architecture review should be conducted as part of the integration itself.

Rich: Yeah, I mean, huge proponents. So this is all the DevSecOps stuff and integrating security into the DevOps process and CI CD pipelines, really incredibly valuable. So I like that you called out in that question doing the architectural reviews early because especially in cloud, there's a lot of security problems we can make go away with good architectural decisions, such as proper network design and isolation and segregation of networks using multiple VPCs and stuff instead of one big flat one, which a lot of works actually do.

I don't like that practice. I know why they do it. Sometimes it's a cost reason, but, uh, or, uh, designing like, Hey, well, why aren't you, this is long running. It should be auto-scaled. And then we can go to immutable and ephemeral, making sure the pipelines are secure, like all of that stuff is just, there's so much you can do with architecture and cloud that can improve your security that, and I've done this myself.

Give you an example. So the platform at work, so a Cloud, FireMod, CloudDepense, it's all serverless for the most part. Now, we're lucky. We didn't have to build a legacy thing. We got to build this from scratch. But when I come up to have to scope out for someone to come in and do a penetration test, they ask for a list of our internet-facing IP addresses, and we don't have any.

They are, what's your network IPs? I'm like, well, we have one private VPC, but it's a private subnet just for containers to talk to a database. Like there's no network, it doesn't talk to the internet. So it's almost isolated out. Like those things make a real difference. Doesn't mean we don't have a great, yeah.

Host: Yeah, architecture does make a huge difference. So yeah, you're spot on that.

So yeah, that's a great way to end the podcast. But before I leave you, there is one last question that we ask every guest, which is any reading recommendation that you have. It can be either a blog or a book or a podcast or anything.

Rich: Oh geez, um… You know, I was asked to do a reading list for a friend of mine who was doing an interviewer book thing, and I didn't have a good answer at the time. And a friend's like, oh, you should read this book, which I read. So it was Hale Mary by Andy Weir, which was the sequel to the, not the sequel, but the same author as The Martian.

So I think it was one of my coworkers, Lisa Wallace, I think recommended that. And I had read that book a while ago and it was great personally read mostly fiction. It just, it's how I think in my head at night. I don't read a lot of business or workbooks. And if I read those, I read them during the day. And, you know, probably the most recent nonfiction I wrote was the killing zone or something like that. It was how pilots die.

And it was for an aviation statistical analysis of the different ways, different kinds of general aviation accidents with to try and learn how I can not die in an airplane. Nothing I'm doing.

Host: No, but I'm glad that your friend asked you for recommendation earlier. So you have a recommendation ready for us.

Rich: But I didn't, I didn't have the recommendation. I'm stealing somebody's recommendation to me that I just don't want to read. And when you asked me, I'm like, that was one of the more interesting books that I had read in terms of problem solving. And it's just also just a good emotional story is great. I love that, a little good sci-fi.

Host: Hahaha! Mm-hmm. OK, love that. And yeah, with that, we end the episode. Thank you so much, Rich, for joining and sharing your learnings of the maturity model, the new lab that you are running. We'll make sure to share that when we release this podcast. But yeah, thank you so much for joining with us.

Rich: Yeah, thanks a lot for having me. It was great.

Host: And to our audience, thank you for watching. See you in the next episode. Thank you!