The Security Table
The Security Table is four cybersecurity industry veterans from diverse backgrounds discussing how to build secure software and all the issues that arise!
The Security Table
Security Guardrails and Paved Roads
Guard rails and paved roads -- how do they fit together in application security? Guardrails are security tools in the pipeline that help ensure the software doesn't drift too far from established standards. These guardrails allow developers to maintain their creativity and flexibility while building features that ultimately go to the customer.
Paved roads are platforms that developers can build on top of without having to worry about aspects like identity and access management. Paved roads and guardrails funnel developer activity without breaking their freedom to do what they need to do
Automation is critical in maintaining guardrails and paved roads. Automation allows for the creation of new structures and ensures that existing structures function as expected.
The episode concludes with the hosts expressing their commitment to driving down the paved roads, building more security guardrails, and making everything secure by default.
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Hey folks. Welcome to another episode of the Security Table. This is Chris Romeo. I'm joined by Izar Tarandach and Matt Coles. And in this episode we're going to dissect a bit this paper that we saw that Atlassians put out to the world, the paved. Path to balancing security and innovation. So first a plug for the paper. I thought it was, it was a, uh, well worth your time type of thing is four pages. So it's, you don't have to go take a whole night to read it. Um, it's very succinct, but has a lot of valuable things that they share in it. And there's one section in this paper. Uh, manage control with a three lever approach and securing your internal environment while still providing teams with the flexibility to innovate. Bala recommends three main levers of control. And so Baa was the, the, the, uh, this is the CISO from Atlassian, uh, who was interviewed and, and was the main subject matter expert for this, this paper. And so we really wanna just discuss the three levers that, uh, were shared here in the document as, as a way to get started. And so I'll throw the first one out cause I feel like we've, we've spent some time talking about this one. We can rehash it a tiny bit. But the first one was really, Have a secure by default approach. And so first of all, what's the difference between secure by design and secure by default? Somebody gimme that context.
Matthew Coles:Well, I guess. You could refer to our earlier podcast, uh, episode about, uh, the csa secured by design, secured by this default document. But, you know, in a nutshell, secured by design is you build in controls so that your, uh, your security po your posture is secure and Will will want, probably wanna probably wanna dive into that a bit more. Uh, So you design in design into your system so you're not tweaking it at runtime. And then secure by default is when you deploy, you deploy into a secure state. So your configuration is pre secured, pre hardened lockdown, you know, no default passwords, uh, no insecure protocols enabled. Uh, and, and you've, you know, turned all the knobs and dials and things to 11.
Izar Tarandach:In other words, Cuba design is, you shouldn't be able to screw this thing up and secure by default is you have the option of screwing this thing up. But from the start, we are putting it in a mode that shouldn't be screwed up.
Matthew Coles:And, and by the way, we know that it will run and operate correctly in that, in that lockdown configuration state. We've designed it to
Chris Romeo:that was always the challenge with hardening, right? Hardening guidance is you'd get the, I mean, cuz you know, as I've said before on this podcast, I'm extremely old and I've been in our industry for a long time and so I remember ha taking Windows servers, grabbing a, a document of hardening guidance and going. Line by line to the document, go change a setting. But the fun part was you'd always get to the end and you'd restart and it would lock up and it wouldn't It wouldn't boot anymore. And like something in the guidance would've caused it to no longer work. And so that was the, it was secure by default, of course, cuz there was no one was getting into it. Now we weren't able to use it either, but the attackers couldn't. So it was in, in fact, secure by default. But that just makes me think about the olden days of hardening
Matthew Coles:all crypto, and crypto and permissions were the two things that broke everything. You know, you suddenly couldn't get a, you suddenly couldn't get a console because nothing trusted each other. And, uh, or you're using a crypto algorithm that nothing recognized.
Chris Romeo:yep. Windows would always get you to the blue screen of death as a way to re, to to know what, that you were basically screwed
Matthew Coles:And then you'd have to put
Chris Romeo:on you needed to
Matthew Coles:into mode safe mode, right? Put into safe mode, and go driver by driver,
Chris Romeo:I remember Windows mo Windows versions that didn't have safe mode So you were, you were just, basically, you like got to restart the install of the We didn't ever put anything onto these servers before we applied the hardening guidance cuz we, we got smart along the way. Like, don't go install something else cuz you're just gonna have to redo it when the thing doesn't start after. Um, But we're talking, I mean, I'm talking about ancient history here. So when we think about secure by default, um, cloud, you know, the, you know, this, this paper's talking about cloud infrastructure, um, trying to provide security controls as a foundation so the teams have the flexibility to get started with their work in line with security policies. Um, You know, at Atlassian, they have a very clear set of patterns on the types of hosted images that they allow default configurations when you're spinning up and secure by default. They gave an example their S3 buckets, when they're created, they're only accessible within Atlassian's network by default. And these are built into a service that they have. So, so they're, they're referring to this as like a paved path in this context. Um, what, what do you, what do you think about that analogy of this being a paved path?
Izar Tarandach:I think at the end of the day, if put in context, when we get to the third bullet, when we get to the security guard rails, the, uh, the analogy here is there is one way to go. There are bumpers on the side to keep you on that path, right? And this is paved because somebody already took this road before, somebody already walked in here and, and worked the road for you. It's a, it's a, it's a soft landing thing to, to mix analogies. So the, the one thing that that's interesting to me here is that, and something that I heard you Chris, uh, talk about in a different podcast is that this secure by default is, is focusing heavily on the spinning up of resources and cloud infrastructure. And, uh, nothing is being said of the, uh, of the application itself. And so just, just to call out here, for example, they use the DS three buckets as the. Perennial example of, uh, of resources in the cloud, right? I use that all the time myself. So when they're, they are created, they're only accessible within the, their network by default. But why not take the, the step towards application? Say, we are going to give you libraries that doesn't matter which language you're working on whenever you need crypto. You just put the thing that you want to encrypt and it's going to take care of all the good stuff in the back with the keys and, and, and the correct algorithm, the, the cipher, the size. Why is it that the secure by default goes to infrastructure and stops there?
Chris Romeo:Hmm.
Matthew Coles:Well, so we probably should keep in mind what Lae is using these, this infrastructure for. Right? We're talking about a build pipeline to build software and to host services, right? At Lae obviously has products that get sold, right? That, that get delivered to people and they deploy it as well as, uh, a hosting environment, right? They, they host, uh, uh, a cloud ver a SaaS version of their, of their, many other tools. Uh, So first off, just in terms of the paved part, I think it's paved because the powers that be within their organization have created this, this development environment. Right? That's the paved part, right? The, a, it sounds like there's an organization, a sub-organization within Atlassian that, um, Has created an environment that can be used by their developers to create the software, to create the, to create the, the, the hosting hosted components. Uh, and those things are managed for them as part of their platform. As a service. Service, right? So they're, so they have a team that's building a platform as a service that then is provided to developers who then utilize that to then host. Software as a service offerings or, and or build product. So I think in that regard, uh, is our, you know, why stop at infrastructure? Well, that's what this team is building is, uh, our infrastructure components that are used by developers to build software components.
Chris Romeo:Let's think bigger though, right? Let's think. We don't have to stay within the constraints of what this paper was just a jumping off point
Izar Tarandach:But, uh, wait, Chris, just because just before we go there, uh, Matt, I just run a very quick search here on the CV details. 404 cvs by Atlassian.
Matthew Coles:Okay, and that's important in this conversation. For what reason?
Izar Tarandach:because.,we are talking about their cloud environment and how protected it is and secured by default and all that. And meanwhile, there's been a number of recent failures in the application that they, they host, that they create, that they deploy the day, everything. And Gunnar completely agrees with me, as you can hear.
Matthew Coles:That was skier actually, but that's okay.
Izar Tarandach:so, I lost the accent. So it.
Matthew Coles:versus Shepherd Mix. Come on.
Izar Tarandach:so it, it, it's, it's great. It's great that the, the environment gets secure and that, uh, forward development is secured by default, but it's missing. It's missing the rest. The data is still being touched by people who shouldn't be touching it, so,
Matthew Coles:Well, yeah, so I guess. Without knowing, uh, those details of, of the CBEs about when they came out versus when this infrastructure was put in place. Right. This is a recent report, so it could have just been deployed maybe to, to address those vulnerabilities that were identified, but also those vulnerabilities presumably were in the software packages or in the cloud services, the SaaS components that were delivered. Whereas I, I'm reading as we read this paper, it's really. It seems like it's about the platform that's provided to the developers is secure, not necessarily making the thing that gets delivered on top of it, automatically
Chris Romeo:So there's more, there's more to the story right than, than what this paper is exposing. But I wanna come back around cuz Izar, I wanna get your take and, and Matt's as well on if we, if we take this paved path analogy further beyond just secure infrastructure. These are, you mentioned libraries, like is a li should a library, a set of libraries be on our paved path for developers that say, Hey, if you're gonna use crypto and you know, we're using Node, here's the specific library that we're vetting and we are approving for use, which, or, or, you know, what other, what other pieces would exist in the paved path as well outside of just software
Izar Tarandach:Look, if if I could dream, I wouldn't even say, here's the, the library that we as security have vetted and how we want you to use it. I think that, uh, in, in my perfect scenario, security would have the resources to step forward and say, here's a layer that we are putting between you and any library that we want you to have access to where you get the security services. and we control the security services. We know what happens behind them, so that we'll never get into a a point where, hey, there's a vulnerability. You have to update this, this library. Yes, I know we've veted it, but hey, there's a problem. So now go and update. And they'll say, oh, we can't update because backwards compatibility or anything else. in my rosy view of that paved, paved road, rather than giving a how to, security will be able to give. Function. Call and say, this is how we use crypto here in our place. No.
Matthew Coles:aren't they doing that? I mean, a again, this is where I think the timing question comes in of when this was introduced. If their, if the, if their security team is providing a platform as a service, presumably that platform is providing a set of services, which could include a secure, uh, a secure value store, right? As opposed to having to write a, or, or implement a secure value store on top of the platform. Right. So I That's where you're, I think you're, what you're trying to focus
Chris Romeo:I mean, that gets you, that gets you secret protection. That doesn't get you, if you're doing something from a crypto perspective outside of tls, from browser to application, then. I there, there could be value in having this, this kind of standardized approach to crypto that's enforced at the platform level. Because, you know, I mean, I think with secrets management like that, that's a problem that's solved if you just tap into what the cloud provider does. You know, I'm thinking of Amazon, k m s for example, like Secrets Management used to be. It used to be the thing where we said, oh, that's a super hard problem. I don't feel like I need to answer that any anymore. Like secrets of Management is not a hard problem. It's a. It may be an arduous, time consuming problem to implement and go through and clean up all your secrets that exist in your application, but the services are there in every cloud provider to do key management for me, so that, I think that's a paved road as well. Key
Matthew Coles:well. and actually I think, I think you've touched upon something else. Just as I reread that, that section, you know, the very first statement that B, the co very first comment that they, or, or quote, that they have from B in this do in this section is we have a very clear set pattern on the type of hosted images that are allowed and their default configurations are secure. So first off, they've chosen this platform as a service based on aws. So already developers are in that mindset. You're not, when you're deploying services, you're on aws. We're providing that middle tier, that platform as a service layer, define interfaces, whatever the case may be. You know, may, maybe there's a crypto services and secret stores and all this other stuff supplied by the platform, but it's on aws. And so they've already set, made a technology decision. and set the, set the boundaries. We'll get into boundaries, I guess, in a, in a little bit. Uh, and, you know, providing certain resources and. Knowledge of, of default, secure by default. Um, and so that's actually really important I think, because, uh, developers don't have to make the choice, or rather, developers are restricted from making the choice, right? They're not being asked, okay, how do you wanna deploy this? Oh, we're gonna choose GCP, or we're gonna use Azure, or whatever. Well, you're gonna use this platform. This platform is built on aws and now you have. I don't wanna say it. We'll but, but we'll get there. Guardrails, uh, you'll have guardrails on what you do and we can, as a security team, we can know that what you're doing is secure. Um, yeah, go
Chris Romeo:we've mentioned guardrails enough, we just
Izar Tarandach:No. Before we go there, before we go there. Matt, that's just you to take a lift on, on what you just said. This whole thing of secure. Secure by default and, and secure by design, actually just a secure by default, it makes our lives as threat modelers much easier because now we are telling people, Hey, this is how we deploy things in here. This is how we build things in here. And rather than threat modeling everything all the time, I just want you to tell me where you are trying to go out of what we're putting down here. and then let's focus on that and try model that.
Matthew Coles:day she died.
Izar Tarandach:And then I'm going to
Matthew Coles:I'm gonna disagree with you a little. I'm gonna disagree with you just a little bit. Uh, I, I, I think you're, I think you're almost there. If you simply look at where you go outside of those boundaries, then you have the potential of missing, uh, I think you have a potential potential of, of missing where, where gaps can occur even without intent. right? So we are making an assumption that the platform is secure, right? Somebody must have threat model of
Izar Tarandach:Mm-hmm. Yep.
Matthew Coles:right? So to say that we can avoid that. We, we can avoid that as developers, but not necessarily as the organization. So maybe that, maybe that's what I, I want to just highlight is I don't think we can completely ignore it if we're looking at it, the organizational level, but at a development level, we need to, you may be able to shortcut that effort.
Izar Tarandach:if again, in a perfect word, the organization decided these are the configurations that we consider secure. How did, how, how did they get to that? Hopefully by building a threat model that cover all those configurations and saying, Hey, we mitigated everything that we needed to mitigate, right? So they created this thing and called, if you do this, you are secured by default because you are falling inside. Our threat model now comes T A B C and says, Hey guys, listen, we, we can't have the, what, what was the example they used? We can't have the S3 bucket, uh, that we are creating only assessment within Atlas. We have to corporate with somebody. They. So now you have the, that delta, that specific delta, that story to go and look at. So you are reducing the scope of the nutrient model by factors of magnet, by orders of magnitude. And now we go back to what you said, which is, I, I agree completely. You, you caught that. But what I say is by reducing that scope, The amount of second and third order implications that that change could have in the overall ready threat modeled figure is much smaller.
Matthew Coles:Right?
Izar Tarandach:yes, we go back to the, to the big threat model in the sky, but the changes that could happen are different.
Matthew Coles:A Absolutely. And I think that's really the key part there also is that Delta,
Izar Tarandach:Yes,
Matthew Coles:whoever does that analysis originally needs to share
Izar Tarandach:yes,
Matthew Coles:because that's where you start from, right? And you can look for, you can look for new openings, you can look for gaps, you can list, look for. attempts to modify the known configuration or the the understood configuration.
Izar Tarandach:It's the butterfly effect of threat modeling, right? You could make a very small change in here, and that's going to reverberate across the, the structure, and it's going to cause a much, much bigger gap somewhere else.
Matthew Coles:Well, and we, and we see it all the, we see that all the time, right? Code changes, right? Uh, you're looking at source code and you're doing code review, and you go, oh, yeah, we assume that it works. Oh, yeah. Document that assumption, because guess what? A year from now, somebody's gonna make a modification that's gonna completely violate that assumption. Now you're all, you're all hosted, right?
Izar Tarandach:Butterflies everywhere.
Chris Romeo:effect, the butterfly effect of threat modeling. Like, that's trademark, patent pending Izar Tarandach. Like that's a, that's a, that's a, it's a, it's a good way to think about drift in, in a technology product. And it's the reason we want to revisit threat models at some increment of time because drift does occur. Butterfly wings flap off to the side and all of a sudden somebody's using a bad library or
Matthew Coles:chaos engineering at a design level.
Chris Romeo:Yeah, that's another trademark patent pending. Just a, right, so let's talk about guardrails.
Matthew Coles:Alright, we'll we'll skip the second we'll skip the second one. The
Chris Romeo:We'll come, we'll come back if we have time, cuz I think guardrails go along with the paved path, like the secure by default approach and the guardrails are, are two things that are supporting constructs here. And so I've heard guardrails, security guardrails thrown around as a term for the last number of years. But let's, let's stop and think about like, what are we, what, what is a security guardrail? And I feel like Matt needs a moment to draw a picture. So Izar, what's a security
Izar Tarandach:So a guardrail, the, the analogy when, when it comes up to me, The feeling is that, where do you put guard rails? You put guard rails in places in the road where if you go beyond the thing, turbo things happen, right? So you put it in like steep, uh, core curves and things like that. So it's not like you're putting it everywhere. You're not closing people in the, on that road and saying you cannot get out of the road. You are saying, we have identified places in this road where horrible things could happen if you drive out of it. So we're going to put this piece of meadow in here. to a show you that you shouldn't go past it, and B, if you happen to really, really go fast and go against it, it's going to sort of try and stop you. Now the analogy is imperfect because we know that guardrails don't really stop horrible accidents from happening. Or perhaps the analogy is perfect because guard REOs don't stop horrible accidents from happening. But, uh, the fact that you have that one more bump in the road between driving and disaster. I think it's, it's worthy enough to justify the efforts.
Matthew Coles:Yeah,
Chris Romeo:it's a stop from chaos. It's a step away from chaos. Chaos being the developer can do whatever they want with anything that they want. The guardrails, hold them into the road. But don't, don't force them to stay in one particular lane induced and have a, a kind of fixed way. Like, oh, you have to do it
Izar Tarandach:Yes.
Chris Romeo:It gives them
Izar Tarandach:but I'm going to take a bit of the responsibility of the developer here. It's not that it's stopping them from doing what they want, it's also stopping them from unintended consequences to things that they didn't know might happen. And it goes back to our, to developers have to know everything about security. No, they need to know not to break the guardrails.
Matthew Coles:So interesting. That's an interesting way of describing it. Um, uh, uh, it's comes down to, I, I think that, I think that it's an interesting thing to, to, to, uh, concept to think about here about how much. How much developers be aware of the changes of the things that they're making, what they do? Like how much conscious thought, uh, should they have, or how much liability should they? And, and I wanna use liability in not the legal way of, not the legal terms side of things, but. Should they ever, if they can do whatever they want within that paved road and they hit the guardrails, as long as they don't break the guardrails, you know, it protects them from danger, it protects them from themselves to some extent. Is that okay? that developers can, are free to operate in that environment. Uh, maybe a another analogy here might be, have you ever gone bowling and you've got gutters, right? And you have those bumpers that can come out, you know, that you can put up, it prevents people from going in the gutter until they learn how to shoot down the lane. But then you take it away and now you have the gutters as your protection, right? From jumping lanes and, and everything. I guess how much should developers be oblivious to what's going on? Versus being prevented
Izar Tarandach:So I, I think that before people started talking about guardrails, we were talking a lot about handholding. right? And handholding always brings the idea of the parental guidance. Hey, I know better than you. Here's my advice. Here's what you should do. That one, I think, is a offensive to, to developers, very smart people who can most of the time learn better than others and can teach us. And, and, and b, it's extremely, um, limiting because it says there is this one way of doing things and this is how I want you to do from now on. Right. or at least until you are experienced enough to figure out by yourself, what's the, the other right ways of doing it. Guidewires on the other hand, they try to limit the scope of, uh, where they might even go from the beginning. So you're not saying there's only one way of doing the right thing. You are saying there's a limited amount of things that you can do before you hit the boundary of the right thing. So I, I, I, I feel that guardrail is a bit more trusting of the developer, and it's not trying to tell them you can't do what you want to do, but it's saying there is a, a, a, a limit. So the latitude that you have to do the things that you want to do.
Chris Romeo:Yeah.
Matthew Coles:I, can I actually, I, I wanna, I'm having a hard time with this and maybe you guys can correct me here. If somebody builds a platform as a service and provides a bunch of services and then automates the and, and. Puts up guardrails. Ignore for the moment. The automation part. The automation part I think is actually really important. We should touch upon that, but, but the putting guardrails in the first place, aren't you limiting choice In doing so, somebody has, or somebody else at the development organization has decided on AWS and all the services. Somebody else at the development organization has said, these are the interfaces you should be using. Somebody outside the development organization said This is how you're going to do privilege access. how much is actually under control of developers?
Chris Romeo:Well, they still get to build the feature. right? Like you're, you're still like, we're not even talk. We haven't even, we're not talking about the thing that we're delivering to the customer. By way of the feature, the guardrails are the things that are helping us to keep that feature so that it's as secure as we possibly can get it when it does roll into production. Cuz when I think about other guardrails, I mean, I would say that security tools in the pipeline, those are guardrails as well. They, they, um, are helping us to ensure we're not drifting too far away or we're not having, you know, um, software composition analysis is helping us to not have super old dependencies that are riddled with vulnerabilities if we configure it properly, that is a guardrail. Um, it's not as, it's, it's kind of a, I don't have a way to get around it. Like there's, there's, that's an example of one where there's only really one way to, like, I don't have a lot of creativity in fixing a, a dependency vulnerability. I guess I do, I guess I could go get the library, I could customize my own fix for it, or I could up upload or upgrade my, um, pack my library. Now I'm gonna take the easy, whatever the quickest way is, I'm not gonna go fix it myself. But like I think about the developers still have the creativity. The flexibility, the ingenuity to build the feature that ultimately goes to the customer. And what we're doing with guardrails and paved roads is we're keeping, we're giving them a platform to build on top of where they don't have to worry about, uh, identity and access management. Like there, there's a series of services that are available. They don't have to worry about secrets management. They just have to, to, to follow the rules that have been established there.
Izar Tarandach:You know what, now what you, what motive you just said got, got me thinking in a different way. It's not really that, that it's that, that it's new guard rails or, or hand holding. We we're talking about the funnel here. Okay? think, think think about this. you are developing close to the iron. Now you, you're working on the, the processor. You have Ring Zero, you have ring Cs, you have all that good stuff. Then you put an operating system on top of that and you just funnel the bit. All of a sudden you don't have ring zero all the time. And then on top of that, you put another layer that now describes the, the authorization that you need for APIs and stuff like that. So you just go funneling and funneling and funneling and funneling up. until you get to this stop layer where you say, okay, developer, now you can go and do whatever you want in, in double quotes. And now we, we are just funneling a bit more by saying, you can do whatever you want inside this, this next limit that we just gave you. And it could be that with security by default, security by design and the guardrails, we are finally reaching. a point where we have funneled as much as we could without breaking the freedom of the developer to actually do what they need to do as opposed to what they want to do.
Matthew Coles:Yep.
Izar Tarandach:that make sense
Matthew Coles:And, and, um, it does actually, uh, it, it, it does, it wasn't where I was going. I did actually have an ulterior motive in, in the questioning here. Um, but I'm gonna just say it, you know what goes around comes around. It's a, it's, sorry, that's the wrong phrase. Sorry. What's old is new again. Uh, right.
Izar Tarandach:all that has happened will happen again. Yeah.
Matthew Coles:So right. So. Remember when we used to have tool development teams and configuration management teams that res were responsible for setting up environments and creating APIs and creating SDKs and, and, creating those funnels. and setting those guardrails, right? So you had a tools team that managed your, your ClearCase or whatever, and your, and your, um, your config specs hit well. Yeah. So very, I'm gonna go back like I'm old too, right? Uh, so
Izar Tarandach:Sorry,
Matthew Coles:so uh, you know, so you're gonna have somebody managing your source control and somebody managing your, your, your development environment and your. Production, non-production environments and those funnels that this was just talking about, right? All of that is, is starting to come back now in this, in this way, in a new environment, right? So that was physical hosts being managed and physical assets being managed and you know, developers had network access and, and route access, you know, ring zero access to some extent. And now we're in the cloud and so now it's different, but. we're putting those same processes back in place so that developers no longer, this is, I guess the whole concept of DevOps, right? Developer DevOps was developers had to take care of all of that themselves now, and that means that we're doing a lot of extra work. Oh, what tools do we have to deploy to make data code, you know, static code analysis or software composition analysis work, and have to manage all of that in addition to being the creative, doing the creative stuff. So now we can create these filters. A team, a tools team, whatever, can create the fill, create these funnels, and create these guardrails and create these services that developers then can do creative stuff on top of that sound. That's what it sounds like. This is leading to, leading to, and, and or implementing. Maybe it's not intentionally that way, but that's what it sounds like
Chris Romeo:No. And I love the fact that like, I hadn't thought of this, like this is, you're really stretching my mind here. because DevOps was almost an opposite reaction to having tools teams and having people that ran stuff in production. But now it's almost like, see, I think we gotta break DevOps into different. I think DevOps has much more than, than than developers making things, developers just basically building on top of a framework that represents production. So there is no longer a disconnect. I feel like DevOps has gone so much further
Izar Tarandach:Hmm.
Chris Romeo:When you think about C I C D and when I think DevOps, I think speed. I think being able to, to push 50 or 5,000 times a day, That's the benefit. It's pipelines. It's it's automation. It's so much more than what the original reason DevOps was created. But to your point, Matt, like we're almost coming back, we're going back around the circle again to say, well, guardrails are gonna constrain what people can do. Just like tools. Teams used to constraint, used to provide the environments that then, now, I would argue in those earlier days, the tools teams, a lot of us didn't follow. what the tools team said we were supposed to do. And so, I mean, wait, no. I mean a lot of other people didn't follow what the tools, teams, I didn't mean us, uh, what the tools team said we had to
Matthew Coles:The guardrails were sort of like, uh, suggestions. Not really
Chris Romeo:they were made of cheese, Swiss cheese or whatever, like you could easily bump up and just go
Matthew Coles:But that's actually the interesting, right? So c, c, D as a good example, right? The tools team used to manage the C I C D pipeline, let developers do their, their creative work. Then DevOps happened and the developers took over responsibility and were doing the creative work, and now we're coming back to a tools team is develop, is deploying C I C D, and developers can do creative work.
Izar Tarandach:But you know, it's, it's a strange thing, Chris, you, when we talk to the ICDs, you go back to the speed and I don't know you guys, but recently I have had the experience of trying to write something. and I have this very clear idea of what I wanted to write, and I sit down to write and then it begins, okay, I need this library, but that library needs that version of the interpreter. Okay? So I need a virtual environment, okay? So I need to download something that creates the virtual environment, but then I have to write test file that describes the environment. And then I have to post this somewhere and I have, and it's basically six hours of work. Becau, before I can write one line of the thing that I actually sat down to write. So, CICD doesn't really bring me speed to to mind.
Matthew Coles:It doesn't bring you as an individual if you're doing all the work, but imagine if there's somebody already providing that service to you that you can then sit down and write, start coding in.
Izar Tarandach:right. So that was my next step, which is where, when I hear C I C D, the big advantage that jumps to my mind and as a security professional, I think is the repeatability. The trust that I have, that the processes are going to happen the same way, in the same order every single time that I fired that thing. Right?
Chris Romeo:I mean, it's small batch size too, right? That was the whole beauty of C I C D is we can make a batch size of a couple of lines of code changed and we get a lot better fidelity as to who broke the build and who screwed up versus the waterfall method where we would wait till the end and we deal with this, this hell on earth called integration where we try to make all of our code work together and it would take an additional. As much time as it took us separately to build it, it would take at least twice as much time to get it all to work together. And by the time we released it, nobody even
Izar Tarandach:right. So the guard rails to me go, go much, much more towards maintaining it with trust on the reliability of the C I C D than going for the speed. Because even places that you know, deploy 500 times a day, It's not like you have the same developer 20 times during a day adding new libraries and adding new packages and adding whatnot. It's a very, it takes longer to add a package to something that's running than in between prs, right? So I think that the guard rails, again, they come both as a mechanism to a, reduce the cognitive workload on the developer. The things that I have to learn. to keep inside that those boundaries and the other side of the guard rail, looking from the outside in, they are not going to do anything. That's going to break, break the repeat repeatability and the trust that I have on the other processes that I have around the thing that's being produced. So the guard
Matthew Coles:And on top. Yeah, go
Izar Tarandach:the guard rails keep people from going out of the paved road, but they keep the, the paved road from collapsing on them.
Matthew Coles:And with the automation part, so the, the as other aspect here is the automation. If, if there is a break in the pavement, right? So if you're, if it's a heavily traveled road and you got a, you know, monster truck driving over it, that breaks the pavement, you can, you can repave it or patch it, you know, in, in, you know, without having to send a whole work crew or the guardrail, somebody bumps the guns to guardrail and bends it. You know, you have automation in place, or when you're building new road paving, new, new territory or putting up new guardrails, it's automated. I mean, this is a, this is a. A wonderful thing, right? The ability to not only create new structure, but also look at what you did put in place and make sure it's still functioning the way you expect it to. Right? And that, that was the, that's the very last line in that section there. Right? The automation can enable auditing, which allows you to meet compliance. Well, yes, that's true. Yes. Uh, you can do that for, you can audit for compliance purposes, but you can also audit for extending that trust. To your developers, the system is working the way you expect it to. You can rely on it.
Chris Romeo:Yeah. And look at the example that baa put in here, in that first paragraph. I think that's, that's a, it's, it's just good to, to revisit that in regards of the security guardrail. So, you know, baa often hears from engineers that they need admin rights. I mean, who doesn't? We all need admin rights for their day-to-day, such as provisioning certain services in aws. For those in similar situations, he advises, teams ask themselves, there's a way for me to do this with code, push it, have it run on its own. So he's defining a service that will provide the service provisioning so that I don't have to go into a I am and a w s and say, everyone's admin and everyone has full privileges to everything here, which is a great security principle that we would all, none of us are gonna argue that you should give people admin rights. Everybody should have admin rights in a cloud deployment. And so, This is the case where a security guardrail insulates the entire infrastructure, the entire cloud world for this particular company, from having o, from having too many people with admin
Izar Tarandach:So one thing that I, that I hear a lot from developers about, uh, the principle of list privilege is, why should I constrain myself? I don't know if tomorrow I'm going to need something that needs more than the rights that I'm giving it right now. Right? So they, they're forward looking. I may not need it now, but I may need tomorrow. Why should I remember that I have this mechanism thing in place. Let me just be admin and, and do whatever I want. But I think that when you put that together with the and and he Bala calls out defined infrastructure as code. we, we know that code is something that today we know how to automatically interpret and check and link and figure out things like we have the tools. They may be, that's a whole completely d different discussion. But we have the tools, so
Matthew Coles:have some tools. We
Izar Tarandach:have the power, We have the technology. So by, by forcing developers to. to. explicitly declare themselves what level, to, to go back to the, to the example here, what level of rights they need. We, as security people get the enforcement of lists, uh, uh, list privilege. They get to ignore it because we are telling them these are the, the, the Lego pieces that you have to build. And then what gets solved is one of the bigger problems I think of this privilege that always. Counted as security professionals, which is okay, we went into the track model, we defined that these would be the least privileges, but now how do we check that this actually got done? So by being in the, in the boundaries of infrastructure as code, as part of the guardrails, we as professionals have the, the assurance that we have a place to go and look and automatically parse and, and, and check that these are indeed, The, the rights that are there. And then we have the whole mechanism at the end of the pipeline when the things are already deployed to go and query the structures of the cloud system. Are these actually the, the rights that are in place? So now we have multiple checkpoints to figure out the same powerful thing that before we didn't have as much visibility on top of. And we can go and say, I will do these things because wait for it. they are reasonable. It's reasonable to ask developers, Hey, define your infrastructure as code and take this privilege into account. It's reasonable to ask, uh, DevOps people to say, use infrastructure as code, and it's reasonable to ask our security tools to check that code for what we are expecting to see.
Chris Romeo:Yeah.
Matthew Coles:You know, it's interesting in all of what you just described, you could take out the cloud aspect and that would still
Izar Tarandach:Yes, exactly.
Matthew Coles:and that's really important, right? Cloud is not, the cloud is not the drive was maybe the driver for this, but cloud is not necessarily the sole beneficiary of this.
Chris Romeo:Hmm. Yeah, this is, uh, it's been a good spirited debate as always, so we didn't really have time to talk about split cloud environments and have different levels of control. Um, I think we're all likely gonna be in agreement that that's a good practice. I don't think any of us are gonna be like, well, I really think we should put everything in one VPC and just let everything talk to everything. Give everyone
Izar Tarandach:Wait, not
Chris Romeo:and just, yeah. Yeah. Izar. Let the record show Izar just fixed all of his infrastructures code and he deployed and he is good. Oh, we went green. Everything's
Izar Tarandach:I wish I had more guardrails, huh?
Chris Romeo:And more paved roads and guardrails and, and more illustrations for how we can call this. So, uh, yeah, this has been, it's been a fun conversation here on the security table. And, uh, we will continue to drive down the paved roads and building more of the security guardrails. And I forgot the other
Izar Tarandach:And making everything secure by default.
Chris Romeo:secure by default. There you go. So, once again, thanks for listening to this episode of the Security Table.
