Jul 28, 2023

Restorative Justice Framework: A New Way to Solve Conflict with Michele Chubirka

TLDR;

First Security hire for an organization should be a Generalist and has necessary soft skills to work with other teams to improve overall security. Soft Skills and Relationship building is key at the early stage of an organization.
Security Champions are important for a successful Security program implementation. Collaborate with Engineering and enable them to own the Security Roadmap.
When it comes to Kubernetes, Cloud providers abstract security for the managed pieces. Self hosting is another option but it brings many operational, security challenges with it. Unless absolutely necessary for business reasons, avoid self hosting and use a cloud managed k8s offering.
For Kubernetes security, use of Open Source tooling is a good start. On top of that, follow a threat modeling approach rather than just a checklist approach.

Transcript

Host: Hi, everyone. Thanks for tuning into another episode of Scale to Zero. I'm Purushottam, co-founder and CTO of Cloudanix. Today's topics include restorative framework, DevSecOps, Kubernetes. And to discuss on this topic, we have Michelle Schubarca, also known as Mrs. Y, with us. She's a recovering Unix and network engineer currently working as a cloud security advocate at Google.

Formerly the creator and official nerd stalker of the healthy Paranoia security podcast. She also has been a freelance writer for various B2B publications such as network computing, dark reading and tech target. She likes long walks in the websites. She travels to security conferences, spends time and she loves to spend time in bad game as well.

See, Sincerely believes that every problem can be solved with a follow. I'm interested to talk about this a little bit When when she's not blogging or podcasting she can be found using her 15 minutes in the Twitter sphere As Mrs. Y is Y. Michelle it's wonderful to have you in the show for our viewers who may not know you Do you want to briefly share about your journey?

Michele Chubirka: My journey, okay, I actually have a fine arts degree and I computerized a gallery, an art gallery that I had set up and it was infinitely more interesting than the work that I was doing. And this was, I'm not gonna date myself, but you can figure it out, I guess. But so I started working in academia, academic computing. I think that's where a lot of people started. And...I did everything. I did Unix engineering. I was an MCSC and NT4. I did network engineering. I ran services like SMTP servers and IMAP servers and DNS and all kinds of things. And then I think like a lot of people who started out back when, you know, in academic computing, I sort of fell into security because the network guys didn't want to do it.

In fact, there's a saying with networking guys that a firewall is a router that doesn't work. And that's how I got into security, and the rest is history.

Host: Okay. So like before we start, so we generally what we do is we ask all of our guests, how does, what does a day in their life look like? What does it look like for you?

Michele Chubirka: Okay. A day in my life. Well, now I'm a developer advocate and a lot of people in what is developer relations? Well, for the last part, I guess, 40% of my career, I've been an architect. And in a lot of ways, it's very similar to being an architect, except you're sort of an architect for the world now when you work for a cloud company. And what my typical day is trying to understand the friction that our customers, that Google Cloud's customers experience, and how we can, or I can, help advocate for customers for what they need.

So my work may include blogging or a friction log, or talking to a product team, or working with them on a feature to express to them how I think it should work, or you know, they ask me to look at it, they ask for my opinion. A lot of writing, researching, proof of concept work, testing features. It's, I'm making it sound like it's playtime. It's not all playtime, but it's very similar in that, you know, we advocate for... There was a woman who's written a book on developer relations who says that we're like an information funnel.

And we are that, we take information back and forth and we contextualize it with empathy so that people see each other's sides, so that they understand the priorities of a product team and that the product teams understand the priorities of enterprises and users. But we're also something called customer zero. Customer zero is the person that feels the pain so the customer doesn't have to. Hopefully that's what we try to do well.

And hopefully that makes our customer's journey a little easier.

Host: I like the analogy that you use, right? Information funnel. It sort of connects both the worlds. And it does the translation as needed, depending on who is the receiver. So yeah, it's absolutely on the spot. So I want to start with the questions. So first thing that I am curious about, and of course, this is a new area. I did not know that something like this exists.

You're working on something called a restorative justice framework, right? Applying that to information security programs. What is it? Like what is a restorative framework?

Michele Chubirka: Well, first of all, I don't know that anyone's doing it. I, this may be a first. I haven't, I've checked a little bit and I can't find that anybody's doing this. So restorative justice is a, and restorative practices by extension. Restorative practices is an emerging social science that focuses on building social capital amongst people.

Restorative justice is an approach to criminal, the criminal justice system that typically in criminal justice, you have the punitive permissive model. That's the pendulum that swings back and forth. Whereas restorative justice is a more responsive model that's trying to find a better way that isn't about punishment, that separates the deed from the doer or the person from the problem and is trying to find better ways than just simply sanctioning someone or putting them in jail, because that's not truly rehabilitative, right?

So there's an approach, typically it's based on reintegrative shaming, that brings perpetrator and victim and witnesses together, those stakeholders together in a room to address harm to find a way to repair the harm and then to restore community. That's typically what restorative justice is. Now, in information security, it's a little, it's a very different application because you have this, the perpetrator victim oscillates, right? You have an attacker who is a perpetrator, but sometimes you have your own user community who could be a perpetrator because...

They don't patch their systems or they don't test their, you know, use security testing on their applications and systems and things like that. And they don't follow good application security practices as another example, right? So in that example, you know, victim and perpetrator, they oscillate, it shifts. And so it's a much fuzzier area. But the point that I'm trying to make is our approach in the past, or typically with information security is we, you know, a professional goes into a room of people, either a virtual one or in person, you hand you pull up a report and you say, look at all the red. Yeah, you failed. Okay.

This is how you fell short. You were bad. Now fix that. And then I'm going to come back next month. And I'm going to show you how bad you were next month too.

Now, what you've just done is you've shamed someone, but you've stigmatized them. You haven't given them an out, right? You've stigmatized them, you've shamed them, you've made them feel bad about themselves, and you've probably humiliated them in front of their leadership. Are they likely to help you? Are they going to work with you? Probably not. You just killed the relationship. But if you...

If there are better ways to do that, more proactive ways, you are not gonna have a good conversation with someone unless you build a relationship with them first. Unless you understand you walked in their shoes, unless you build empathy, and yes, I'm gonna say the buzzword here, emotional intelligence, unless you use some emotional intelligence, and all that is, you know, everybody goes, ah, I don't know what that is. It's intrapersonal awareness regulation, you know, your self awareness and self regulation, inter personal. So how am I aware of what the other person is feeling? And then how am I going to manage the relationship between the two of us? That's the magic. That is the thing that is going to fix your security problems, not the latest technology for the most part.

Everybody has the technology they actually need, like probably 75%. Right. You know, for the most part. But they don't have is good relationships within their organizations and with other people. Like you'll see these massive breakdowns. Well, why aren't they doing the thing? Why aren't they just patching? Why aren't they patching the system or why aren't they patching the dependency? Guess what? Cause it's much more complicated. It's an adaptive problem, not a technical problem. They're moving parts. They're dependencies, there are reasons why they're probably not doing that, and you need to have that discussion. So is that helpful? Is that making sense? Okay.

Host: Yeah, so yeah, that is making sense. So a few episodes earlier, like we had a guest who was speaking about application security, DevSecOps and all of that. And he also brought up something very similar, that it's not about the tools, it's about the relationships. At the end of the day, as security team members, we can say that, hey, like as you highlighted, right, there are 20 things which are in red.

But unless you build that relationship, it will not get prioritized the way you want. Right. So that is where that relationship plays a role. So I have a follow up. Sorry, go ahead.

Michele Chubirka: Right! And restorative justice and restorative practices, it has as a framework because it's very, I understand and recognize that. And honestly, I've struggled with this just as much in the past. It's not simple enough to say, be empathetic, be build relationship. I mean, part...

You know, as adults, we don't get constant chances to professionally develop our emotional intelligence skills, to build our empathy skills. And the framework, having a framework of restorative practices that includes things like, you know, Katie Wine Garden's Common Shock, nonviolent communication from Marshall Rosenberg, the restorative continuum, and I could go on and on, but having like,

discrete practices that you can use and that you can learn to help build those skills. That's really the core that practice that I work on if that helps.

Host: Okay, so as you said, like not many people use it, right? So let's say in my organization, yeah. So I can see why not yet, right? So if I am running an organization and I want to implement this in my organization, what does the framework say? What do I need to do? Let's say top five things that I need to do.

Michele Chubirka: Not in information security. Yeah, not in information security. Well...

First of all, if you were going to implement restorative justice or restorative practices framework in an organization for information security, the continuum would say, first of all, you want to focus on proactive activities over responsive or reactive activities. It's less likely that you're going to be successful. And just like, or, you know.

We have that horrible expression shift left, right? I prefer moving upstream, right? Cause nobody knows what shift left always means, right? But let's say, but let's take that buzzword and use it in a different way. How can you shift left with your relationship practices to make them more proactive? How can you do that? How can you go out and build relationships? And that means that you show up not at the end that you should, and assuming, oh, I told them what to do. They have the tools. They'll just do it. No, you need to work with them. You need to understand, you know, similar to how a developer advocate works, you know, I'm customer zero, right? I go out and try to understand where the friction might be before they even get there.

So do the same thing in security. You should all be advocates in security. You should go out and go, um, like understand, oh, how do the developers work? How can I put myself in their shoes? What are their major priorities? What do our customers struggle with in our product? How can we treat security as a product feature and then address it in that way to understand what the qualities that our customers are seeking, how are the developers gonna get there? What do they need to know from me? Basically, it means showing up. It means showing up.

There are lots of things you can do. You can do circles, you can do effective statements and questions, you can do non- you can learn non-violent communication techniques from Marshall Rosenberg. I highly encourage that technique, it's very effective. You can do all those things. But at the end of the day, it's about showing up and hearing what the other person has to say and not being defensive about it, but actually putting yourself in their shoes and trying to understand and feel what they feel.

Host: Mm-hmm. Makes a lot of sense. One follow-up question to that is, like it all comes down to, at least from my understanding, is the culture that you have set in your organization, right? How your teams are empathetic to, let's say, your internal employees and also to the customers as well, right?

So what's your take on how can like cultivating that empathy within the organization or even to the outside world help address the security challenges in today's world.

Michele Chubirka: Well, I think, you know, I talk a lot about security people having empathy for developers, but it's also the other, it should go the other way too. I think right now a lot of security people are, I mean, you have something called compassion fatigue or empathy stress reactions in, you know, in helping professions like if you're a police officer or if you're...a nurse or a doctor. I mean, that's something that really happens, right? That you, it's, you start to not be able to process the trauma that you experience. And I'm using the, okay, it's a little T, not a big T, right, for trauma. I'm going to use that word because if you've ever mitigated a denial of service attack or, you know, a breach.

I mean, I've seen people, I've seen a CISO breakdown in tears. It's real, it's a real thing. It's a lot of stress. And so I think building those emotional intelligence skills by building relationships and organizations, by establishing a culture of, okay, we have something in Google called the, you know, this, you know, no,

God, I forget what they call it. I'm probably in trouble. But this no fault culture, yeah, that's it. A no fault culture. We have no fault postmortems, right? Where you separate the deed from the doer, right? You're not, the thing that happened is bad, but you're not bad. And I think that needs to happen. Understanding that, you know, instead of the shaming culture, which security really is just like law enforcement.

Like the criminal justice has become a very shaming process where people are going to feel shame during when a breach happens, when they get a vulnerability report, people will inevitably feel shame, but it's how you treat that shame. Okay, we know that's not you, right?

You're gonna find a way of separating that from the person and understanding that they are not bad something bad has happened, right? But they're not bad. Now we can move on. We can talk about how we feel about it. Okay, this is really hard. I understand that. I see that you're struggling. I understand that you have time constraints. I do too. You can talk about how you feel in a business environment. It's called professional intimacy. And you can then process it is called effective resonance where you work it out together and then everybody moves out of negative affect into a more positive affect. And then you get on with business. And because you've had that sort of contextual, emotional discussion and you've respected each other, right, you're not trying to shame somebody into doing something. Now you're on an even keel.

You're treating each other not as an object to be manipulated, not as a toy that you're going to use a permissive model on, but now you're treating somebody as an equal, as somebody you're going to work with. Right now, it's a respectful model.

Host: So, yeah, so like the word that you used repeatedly is the shaming, right? And one of the things that I have seen and I have also like read is like the moment you, let's say somebody feels ashamed, they sort of shut down for any feedback or they don't feel that comfortable anymore, right? So at that moment, it's a loss for the person and also for the process. If you're doing an incident reporting or if you're doing a retro, then it won't be that valuable anymore because you will not get the right set of data.

Michele Chubirka: I'm very impressed that you actually know that. Most people are not in this field, are not very aware of, they call it Tompkins and Nathanson who are affect, there's something called affect psychology and affect script psychology. And there's something called the compass of shame. And there are four basic reactions to shame where you withdraw, avoid, attack self or attack other. So

In information security discussions, you'll see every single one of those happen, right? Attacks, oh, I'm just bad, and the head down or whatever the cultural response is, or attack other. No, you don't know what you're talking about. There's nothing wrong with us. You don't understand how hard it is for us, right? Or withdraw, they stop responding to your emails, or avoid, they change the conversation to something else, right?

So those are typical reactions. It's observed. In fact, there's a strong shame anger correlation depending on if they've got other shame going on, you could actually make it that much worse and they could respond really with that shame, that rage anger axis, they could respond really strongly. And I have seen that, right? People screaming at you, right?

So yes, that is, you're absolutely right. And what you have to do is they will feel the shame, but it is the shame from a restorative justice perspective. Will it be a stigmatizing shame where you never get to have the conversation or is it reintegrative shame? Braithwaite came up with this concept of reintegrative shame, which means, okay, harm has been caused. Let's talk about how we fix it. How do we address it?

And then how do we restore the relationship between us? That's essentially restorative justice, right?

Host: Mm-hmm. Yeah, no, it makes sense. The moment like you started talking about, like separating the doer from the deed, I could think about that. So yeah, thank you for sharing that.

Michele Chubirka: it's hard. Don't get me wrong. It's when you know, and you see it, and you're like, it was so simple. Why? But, you know, there are lots of reasons. It's just not most companies aren't security companies. It's okay. That's not their main priority. They're trying to generate revenue for their organization. And in a lot of ways, I like I believe in this idea of security as a feature of don't buy a car without you don't have to justify you know when you when you make a car oh we've got to justify why we have to put in seat belts and airbags you don't have to justify that people want it they think right so you can you can there's a way to sell that but it's not let's face it the people buying the car still care more about the color if it's comfortable. how fast it goes, you know, 0 to 60 and how many seconds, right? So it is a harder sell and it's not, we have to appreciate that as professionals as well.

Host: Yeah and that's a great analogy of the cars right some of those things we already take for granted that there is seatbelt there are airbags all of those are in place right we never think about those when we are buying a car right so yeah that's spot on that that's a good segue to my next question as well which is around again relationships and all of that right security and others.

Often security teams are seen as roadblocks because of the obvious reasons, right? Because you are showing all reds.

How can security teams work with other teams so that perception changes?

And other teams, let's say I run an engineering team, you run a security team.

What can you do, let's say to, so that we have better relationship and we help each other.

Michele Chubirka: Mm-hmm. So I think it's about empowerment and about working with, right? There's this idea of the relationship window, you heard me talk about it, where the ideal is that you want to work with others, not do things to them or for them, right? The idea is that you're equals. And that means using techniques like fair process, the three E's of fair process, which expectation clarity, right? It's a Harvard Business Review classic concept. But understanding, I mean, people will, if you extend yourself, and that's an important aspect of the culture as well, you have to exist in an organization that has a sense that people want to work with each other, hopefully.

And you have to give people the opportunity, to see your perspective as well. So that means one of you has to reach out to the other. And typically, engineering teams, and software developers have been burned by misguided security people who don't understand their perspectives. So now you may go in having to do repair work. I feel like I have to do a lot of repair work. It's emotional labor, I admit it,

I think it's important labor for security people to do. Once you show up, once you hear them, hear their issues and what they hate about the way your program is working, then you have earned the right to get them to see your perspective. And it doesn't mean sending them to that horrible yearly security training. It doesn't mean setting up communities of practice where you just talk at people.

It means that you maybe use circles and you hear what their struggles are, maybe build a security champions program, which I feel really strongly about because the best security people, the best security, the ones who are gonna fix the problems, they're not gonna be on the security team. They're gonna be in, you wanna build those alliances, you wanna build ownership, you wanna build advocacy within a software development team or an engineering team. And that means getting somebody to accept responsibility and help you because you don't want, I mean, you can't afford to have a million security people, right?

So you just want to explain to them that, like you want them to own that, yes, this is part of my job. This is what I do. I mean, I don't think anybody thinks, oh, I don't have to worry about storage. I'm a, you know, you don't like, the software developer knows some of the basics of TCP IP, and networking, especially in the cloud. You have to. So they don't get to say, no, that's not my problem. I don't have to know that. So it's the same with security now. So that's how I think. Does that make sense?

Host: Yeah, no, that does. And so now the question is, let's say if I'm running a startup and I cannot hire a lot of security folks, as you said, right, I have a budget for maybe one or even maybe not even one. So in that case, I need to teach some of the security basics to my team. So what are?

What are some of the effective ways to bring that awareness of security? And also what should I teach them when they are starting?

Michele Chubirka: Okay. So a couple of things. First of all, be very careful when you hire that first or second security person in your startup. I would assert that you need a generalist and you need somebody who has what we call soft skills. I don't like that term, but that's how you probably have the conversation has to happen.

You want to be very careful that you don't get somebody who either wants to do everything themselves and put on the superhero cape, as I call it, so that they understand that in a startup, now you have people who are... Collaboration is much more critical, right, in a small organization. And so you need somebody who is going to understand that working with and collaboration. So what does that mean?

You're going to find jewels in a startup organization. Some of those developers actually will likely know more about secure coding than you do, if you're smart. If they've hired good software developers, experienced ones, then they are probably very good at secure coding. And if they're not, then the first thing that you want to do is you want to sort of not go in as some expert.

But go in as a collaborator and try to identify, hey, this is important. We need to have security as a feature. Have you heard of, are you familiar with the ASVS from OWASP, the Application Security Verification System? Like, do you understand the ASVS? Yes or no? Yes, I totally understand that. OK, let's look at that you know, those feet, because you really, what you want, even in a large organization is you want ownership. Like the worst thing I've ever seen is when you have a threat modeling program and a security person does a threat model, you already failed threat modeling 101. That's not how you do it.

The person doing the threat model should be the embedded team members, should be somebody from the team because they understand the application more than the security person. You're not going to learn that in like hours. So what you it's again it's about having conversations. What do you understand? Sort of creating a baseline for where they are and that means you know my favorite tools for that I love sure not everybody can afford the BSIM assessment. So use OpenSAM right from OWASP. There's there's OWASP OpenSAM.

That will give you an idea of your current maturity, what people know. It gives you a way of, okay, I'm gonna do this Open SAM assessment. I'm gonna figure out what your current maturity level is in terms of security. And you then go in not as an antagonist, but as a colleague and a collaborator. Am I answering your question?

Host: Uh-huh. Yeah. No, that makes a lot of sense. And one of the things that you highlighted is like the moment security team does threat modeling, you have lost the battle anyway, right? And that's spot on. And that's where you need a champion on the engineering side, right? Who is taking care, like who understands and also owns it. So.

We had Dustin Laird few episodes earlier and he loves the security championship programs. It talks a lot about it. And one of the things that he highlighted is that again goes back to what you answered to the first question, right? Building that relationship and having someone on the other side, not on the security side, other side, like engineering side, owning the security. That's what will make your security program successful versus somebody coming outside of engineering and enforcing that, hey, you have to do this or do this.

Michele Chubirka: Leaders always like, you'll get into it, you'll say, Oh, I want to have a security champions program. There's like, it's like a community prayer, you just want to waste our time and you want to make us sit in meetings and you know, and that's not what a security champions program should be. It's a way how can I empower a member of this team with information so they can make, I can delegate as many decisions to them as possible. I may not always agree. That's okay, we can talk about it.

But that's what a security champions program should really be, right? It's a tool to, it's a restorative tool, right? It's a way to find opportunities for collaboration and for sharing responsibility and ownership. And that's how you build the awareness, right? It's not through sending a bunch of people to training. They'll forget it in a week if they're not using it, or it just gets pushed to the side, or they're not really paying attention.

But if you're doing it right, if you're really understanding how security champions should work, it's a partnership.

Host: Yeah, yeah, it all goes back to the relationships that you build and then the partnership that you have with the security team. Makes sense. I want to change the topic a little bit to Kubernetes. Because you have expertise in that area, I want to learn something as part of this process. Everybody knows that Kubernetes is very complicated, right? It provides you a lot of capabilities. It can cover many use cases. So the question is, if I'm running a startup,

Is Kubernetes the right solution for me?

and I'll add one caveat to it. You cannot say it depends.

Michele Chubirka: Oh, no, that's not fair. That's not fair. That's the standard architectural response. That's a go-to. Every architect I know pulls out the It Depends card. We should just have a card. Because it really does. I mean, first of all, well, hopefully, if you're a startup, you don't have a lot of technical debt.

You're going to be. I mean, nothing's perfectly greenfield, right? We know this, right? Because you cut a lot of corners, you're trying to get, you're trying to monetize as quickly as possible. But so it's like greenish, green field, right? But the challenge with Kubernetes is, I don't think, when I started Unix and my first Unix was Solaris, which is a really hard Unix to learn back in the day.

And I remember the guy I learned it from used to have this saying, and I feel like it applies to Kubernetes. Sometimes Unix is a hill and sometimes Unix is a mountain, right? You, you start to feel a little cocky. You start using Unix and you think, Oh, I'm pretty good. I'm pretty smart. And then something happens. You're like, Oh no, that just happened. You know, um,

And that's sort of Kubernetes. You get in, and it seems really easy to adopt and use and play around with. And I think this is mostly when people just use straight Kubernetes, right? When you just use the open source. And then when you start to realize how much effort is involved in terms of development and how many resources are needed and how challenging it can be, especially to secure. And that's it.

I think then it's, you know, I sort of have a rule. If you're not focused, if your development time isn't mostly focused on your core competency, of say, let's say you make an HR application, right? If you're not focused mostly, if you're building developer platforms you know, having to do development in Kubernetes half the time and it's pulling away time from your core competency. I think that's a problem. And that's the beauty, by the way. And I mean, I'm saying this partly as a cloud person, but also even before I was a cloud person, I always say dance with the cloud that brought you. And what I mean by that is, if you're in any of the clouds, Google Cloud and respectfully our competitors, if you're in that cloud and they have a managed service, use the managed Kubernetes, it's gonna make your life a lot easier. So that's one way that you can deal with that, right? It's...

Host: Because the cloud provider abstracts some of those, right? You just focus on your workloads rather than understanding the foundation, like all the nitty-gritty details of Kubernetes. You are not worried about that. You are just focusing on deploying your workloads.

Michele Chubirka: And I have to tell you, I've worked at multiple places. They all start out the same way. No, we're going to self-manage because we want best in class. You don't need best in class. You need it to be good enough. As an architect, I can tell you, you just need good enough. You need it to be quick and get up to speed as quickly as possible. And what's the beauty of Kubernetes? It's about optimizing compute for homogeneous applications. Right?

That's what its real benefit is. It's that benefit of cloud, right? And so that's what you want to focus on, right? How do we get our applications up and running as quickly as possible? That's the whole selling point for Kubernetes. If you're spending all your time messing around and tweaking and playing with Kubernetes, you've kind of failed, right? So, and the harder, as hard as it is, to use raw Kubernetes in that way.

Unless there are certainly compelling cases. I'm not gonna, I don't want the CNC coming after me, right? There are certainly good cases. Say you're the cloud provider or say you have a hybrid environment, right? Or say you're multi-cloud. There are certainly valid use cases for this. Just know what you're getting into. Now, you're gonna have a lot more on your plate. You have to do the cost benefit analysis.

And as a startup, maybe that's not the first place you want to go. As a startup, maybe your goal, your long-term roadmap is to be multi-cloud and to really optimize your environment, to achieve best-in-class and you need full Kubernetes, but maybe you don't start that way. Because you want to be delivering product as quickly as possible. Is that helpful?

Host: Makes sense. Yeah, that is for sure helpful. Now, if I think about security in Kubernetes, let's say I use the GKE, like Google's managed Kubernetes, right?

When it comes to security, so if I'm starting implementing security around it, most companies start with, like startups start with, using some open source tools and doing some misconfiguration checks or one-time threat evaluation.

Is that enough, or do you think folks should pay more attention to security, or should invest more in security?

Michele Chubirka: Again, I want to say it depends so bad. I think there are considerable open source tools available. If you use, however, if you use a lot of these cloud providers, managed offering, they, by default, they will do certain things for you. They will offer you certain capabilities such as GKE has autopilot, which out of the box, it, pre-configure some of these options so that you don't make mistakes. Other cloud providers have the same type of offerings, very similar at least. And I think that's where you should start, unless there's some really compelling reason, there's some nuance that you need that you're not getting through, you know, there's Fargate, there's Autopilot.

Unless there's something, because it's too easy, especially when you're working lean, you're operating very lean in a startup, you want to be as judicious as possible and as you may not have the cycles to address the security of all those nuances. So that's why it may be more effective and efficient for you to do it that way. Is that, yeah?

Host: Yeah, makes a lot of sense, makes a lot of sense because at the end of the day, when you are at that phase, like when you are a startup, you have budgetary constraints, resource, like engineering constraints and all of that. So you try to use, like instead of hosting Kubernetes on your own, use the cloud providers and like use autopilot.

Michele Chubirka: Mm-hmm. Yeah. Here's a mistake I see. Yeah, here's a mistake I see all the time. They go, no, we're gonna roll our own Kubernetes or we're gonna use some of the, we'll use, we'll do Kubernetes ourself. We're gonna self-manage Kubernetes because we wanna be multi-cloud someday and we don't wanna get locked in now. And then they do something like, instead of doing routing in the cloud provider, which you can do, you have a choice. You can do overlay or routing.

And because it's easier, they choose overlay. But now you're doing overlay networking on top of a cloud's provider, which is overlay networking. So that's not gonna be very effective or efficient, right? You could have some latency, you could have some troubleshooting issues that just will, you know, blow your mind. So why not simplify it a little bit? If you don't need it, you know, I can see that you would go there, but you don't need it right then. Like you want to make good choices. It's the whole thing like, everybody's like, oh, we're moving to the cloud. We have to refactor everything. But do you, do you really, you know, do you need to put everything in microservices? There's nothing that inherently wrong with a monolith. I mean, there are perfectly good monoliths out there.

Banking has a lot of them, especially if you've got a mainframe, right? And mainframes are very fast. They're good at what they do. And you know, you're not going to rip out all your mainframes. And so you have to make intelligent choices about that. You have to sit down and go, what's, what's the cost benefit of analysis of me refactoring an entire app, right? Do I, is there.

Do I have to? Do I need to? So that's another thing. Because you're signing on, when you sign on for Kubernetes and microservices and containers, sure, go really fast. That's a benefit. You can break your teams up into very discrete units. But you are signing on for a level of complexity. And that means operational complexity in terms of SRE in terms of security that you may not be prepared for.

Host: Mm-hmm. Yeah, so like two things that I can take away from this, right? One is keep it simple. And if you break things into microservices or something like that, you're making life easy for, let's say, developers to move fast. But you are sort of adding complexity around operations and for others. So anyway, you need to find the right balance for your organization and use that.

Michele Chubirka: And to be frank, if you're refactoring, you're not always making life easy for developers with microservices. If they're used to that monolith, if that's what they've known for a long time, telling them, nah, we want microservices and containers and Kubernetes everywhere. I've been at places like that. And I actually built a maturity model, like a questionnaire to determine if you were Kubernetes ready.

Because it and I do things like that as an architect to make sure so that because questions don't simply access information, they create experience. So when you ask somebody in a questionnaire, it's another interpersonal kind of thing, where you say, now you're asking them to think about the answer to the question and they may they'll ask themselves, they may not have thought of that and they go, Oh, hmm. What? So

Host: Yeah, at least that initiates the conversation within the organization, right? So that helps them come to a decision. Yeah, makes a lot of sense. And that's a great way to end the security question section.

Let's go to the security practices rating.

Rating Security Practices

So the way it works is I'll share a security practice. And I'd like you to rate one to five.

And if you want to add context why you think it's a one or a five that will help. So the first practice is

Michele Chubirka: So as a typical practice, how well it's usually done in organizations, is that what you're saying? Okay.

Host: Okay. Yeah. So the first one is developing and regularly testing an incident response plan so that you can quickly detect, respond, and recover from security incidents.

Michele Chubirka: Most organizations do not do this. It's sort of like, I told somebody the other day, it's like nobody cares about their fire extinguisher until there's a fire. It's not, that's just how people are. You know, the brain is trying to conserve energy, right? We don't, to like waste a lot, I mean, I do because that's how risk averse I am. I will like, where are all the exits? How many fire extinguishers are there in this building?

I mean, I will do things like that, but most people do not. Okay? So.

Host: Most people even would not honestly know how to use the fire extinguisher. I mean, I know it sounds weird, but that is what it is, right?

Michele Chubirka: It's right there. Yeah. No? Right, yeah, you're looking at it. Oh my God, what are the instructions? Yeah, no, you're absolutely right. And so I don't ever see most, it's rare. I mean, you are required to do this in certain kinds of organizations, especially if you're a service provider, figure across most, and if you're in banking, financial organizations have regulators to answer to, so they have to.. They have to do a lot of this. But unfortunately, my experience is that a lot of organizations don't put as much attention as they should on that. So I'd rate it like a 2, 2 and 1 half maybe. Yeah.

Host: OK, makes sense. The next question is granting users unrestricted access to systems and applications, which can lead to unauthorized access and data breaches.

Michele Chubirka:

Yeah, I've seen that be the root of data breaches so many times, right? Authentication and authorization, least privilege, separation of duties. It's always a challenge. And I think it's always a challenge because IAM is usually not well cared for. I don't want to call it a train wreck. What I think is that IAM does not get the care and feeding that in most organizations that it deserves and needs.

I see this all the time and I always go back. There's an ITU document, it's 1257 maybe or 1258, and it talks about ontology and taxonomy. And already you probably just fell asleep, right? When I said the two words, ontology and taxonomy. And what that means is that in theory, what you should be doing is planning out your IAM architecture to align with your organizational structure and your organizational chart And most people just don't do this.

They don't have conversations. Well, what's your source of authority? What's your system of authority, your source of truth? How does that flow? What does that look like? What's the authoritative data source? Is it your HR application? Okay, everything should flow from there. And like nobody, it's because IAM for most organizations has grown sort of organically. And as a result, you get...

Yeah, in fact, I wrote a blog post on this. You can see it on the Google Cloud blog. It's called I Hate IAM because most people hate it. It's not very exciting. It's not very sexy. Leadership doesn't go, ooh, it catches APTs. No, they're going to go, hey, we have to fix IAM. And they're like, really? How am I going to sell that to the board? You know?

Host: Right, right. No, it makes sense. That makes a lot of sense because a lot of security issues all start from IAM because somebody has a lot of access and their account got hacked and now the attacker has access to all of those, right? So yeah, that makes a lot of sense. The third practice that I want to talk about is around DevOps. So DevOps practices are needed to move fast to deploy code to production. So you need to set up security tests and that slows down the DevOps practices. What's your take on that?

Michele Chubirka: Well, SRE slows things down too, right? Backup slow, slow development down. I think you want to find a sweet spot. And I think that means you have to understand what they're trying to do. What it means like, I learned DevOps, really, when I worked at this for this medium sized software company called Ellucian back in the day, and I made friends, I was smart, I made friends with the DevOps team, the DevOps maturity and the implementation team. Those were my best friends.

Why? I needed to understand what's the software development lifecycle like? How much is automated? What about test escapes? How much automated testing is there? What is our test coverage look like? Where does the testing look like? I need my testing to mirror the other testing. Okay.

They have unit tests. Well, that's where SAS goes. That's where static application security testing goes. That's where SCA goes. What works the best with their existing tools? I don't need to buy the best tools. I need to implement the ones that work with their process and fits with their tooling already. What about functional testing? That's where DAST would go. That's where IAST might go that you want to align as much as possible with existing processes and with you wanna understand the business rules because DevOps is just automating business rules for developing software, that's what it is. So I will typically go in and say things like, hey, where are your business rules for, what's your SDLC documentation? Well, how does that work? What are your, well, how do you do releases? How much do you push out every day?

You know, what are your runs like? How long is it? Like, I want to understand things like, what is the average time length for your pipeline? Is it five minutes? Is it 20 minutes? Is it 30 minutes? Is it a day? I mean, I've heard that. And so you don't want to go in. And I've worked at places where they have a really fast pipeline. And you add a tool in. And now their pipeline takes an hour and a half or three hours. You don't want to do that, right?

What can I do? What side channel testing can I do? Can I scan the code offline and then just look for a change? How much can I offload so that they're just checking? I call it in firewalls, you have a concept of fast path and slow path. When you establish a connection the first time, that's slow path. I inspect that initial connection, and I make sure then everything else, yes,

I've approved it, you're okay. Now the fast path is just gonna make sure nothing really is out of the ordinary or changed, right? And so let's think in terms of fast path, slow path. What can I do to, because I'm there to serve them, it's not the other way around, right?

Host: Right. Yeah. No, that's makes sense. And I love that firewall analogy again, like fast path or slow path is because you have the trust now, right? After the initial, let's say validation, there is a trust. So that sort of traffic is allowed through a fast path, something very similar, like once you build.

Michele Chubirka: Now that- Now that being said, sorry to interrupt, but now that being said, there are use cases, for example, in heavily regulated environments, or like you want to risk tier all your applications, right? And so your edge applications, maybe if it's a banking application, or it touches some kind of personal data, which most do these days, maybe your release criteria is different. That's the thing. You want to come up with release criteria um, business processes you want in your upfront, you want to have an agreement.

Okay. You want to understand this is my release criteria for something to go to production. It has to hit these things or doesn't get to go. And we all agree to it. That's fair process. We all agree to it. And then we go from there. Is that helpful? Yeah.

Host: Yeah, yeah, that is for sure helpful. And thank you for adding the context. That's a great way to end the episode. Michelle, I love the discussion. There were many things that I learned. And also, it was fun to sort of block you from using the word, it depends. So it was fun how you worked around it. So yeah, thank you so much for coming and sharing your knowledge and insights with us.

Michele Chubirka: Thank you for having me on the show. It's always fun. It's always enjoyable to have these discussions. So thanks.

Host: Absolutely, thank you. And to our audience, thank you so much for watching. Hope you have learned something new. If you have any questions around security, share those at scale20.com and we'll get those answered by an expert in the security space. Thank you so much and see you in the next episode.