Red Hat OpenShift DevSecOps is the Way | Red Hat Livestreaming, 16 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DevSecOps is the Way (S1E7): Bringing SecOps to DevSecOps with Runtime Analysis

Description

In this monthly series, learn how Red Hat weaves together DevOps and Security to master the force called DevSecOps. This show brings you Red Hat products and our security ecosystem partners to aid in your journey. September is Runtime Analysis month! In this episode, we’ll take DevSecOps beyond the CI/CD pipelines that are such a popular topic and focus on the SecOps side of delivery and design principles. We’ll discuss SecOps practices and how they can be used as part of the operational monitoring of establishing a DevSecOps program. Bring your lightsaber and be prepared to train hard... may the DevSecOps be with you!

A

A

B

Good morning, good afternoon, good evening and welcome to another edition of devsecops is the way I am chris short hosts, the most of red hat live streaming and I'm joined by the one and only dave muir and the about to break some stuff. Jamie scott dave how's it going today, buddy.

C

It's going awesome another great day down here, you know in tampa bay and that's right. We, I think we have a really good show uh this month and um yeah jamie's, not only gonna break stuff, he's going to hack some stuff we're going to we're going to actually hack some kubernetes today, which will be very cool yes um before I do that. I just want to let the audience know. Some of you already know. This is part of the monthly security series called devsec. Ops is the way we've broken each month into different security categories.

C

This is actually, according to a framework. Red hat has developed around devops and security and what how to make sense of all the different security categories and methods out there, we've actually got 34 different, distinct functions, underneath some of these categories that we detail, but this all consists of a lot of publications during each month. So this is one of two red hat live streaming shows we publish at most three podcasts per month.

C

There's always a blog on that topic. Talk about! You know the definition of what this category is and how it integrates within devops life cycle and then any other sort of publications, webinars and things that we do with red hat and with our partner ecosystem.

C

So um stay tuned for a lot of that stuff or look at the old months. um If you're interested in any one of those categories find more information, you can go to red.ht forward, slash, devsecops or just contact us at that email.

C

You see there so without further ado, I want to bring jamie in jamie, um as we've said, is gonna start breaking some stuff, which is great, but before we do that jamie, why don't you tell everybody who you are where you're from what you're doing at red hat.

D

Awesome so my name is jamie scott. I live in santa clara, california.

D

I think it's one of the most beautiful places in the world because it is either scorching hot or 60 and there's not really anything in the middle. I haven't seen snow in about three years, so I envy you dave occasionally, um but I haven't cleaned my car off in 10, so it's a nice trade-off.

C

Oh, I I I think chris is the one who sees snow, there's no snow down here in florida I mean.

B

I get more snow than I know what to do with most of the most of the winter, so you.

C

B

Mean that's it's just life in detroit. um We're used to it up here right, like it's cold, it snows. That's the nice part right like if it's gonna be cold. At least it's snowing.

B

That's awesome.

D

So um at red hat we came over with the acquisition of stackrocks and we were a bunch of developers and security professionals who really wanted to take on the world and transform how security is done with the focus on kubernetes.

D

So one of the things we saw really early on was that kubernetes very holistically allowed you to have the context in order to make more informed risk management decisions, and we've tried over the last few years to put that context together in order to enable security teams. So our team came over with the acquisition and I'm product manager for that team.

C

Very cool, yeah stackrocks was actually one of the partners that I dealt with before the acquisition. So it was interesting to see guys all come over as a great acquisition really helps to. uh You know add that what we call red hat, the layered approach to container security or defense and depth, um of course, acs as it's now called advanced cluster security. There's a lot of things this month, we're going to talk specifically about runtime security and in the show, we'll we'll look at actually how to hack a running kubernetes cluster.

C

But in terms of runtime analysis, how would you? How would you define that um you know or what would you say about that? I guess.

D

Sure so runtime analysis is the ability to look inside of a container and understand what processes are running. So I know that's a self-explanatory thing, but there's really two methods of doing that in the market. Today. One is the identification of what is known bad activity.

D

So, for instance, you don't want someone to be running a crypto miner in your side, uh one of your production applications so looking for crypto mining processes is a potential way of runtime analysis and the only alternative way to do it from known bad is to look at known good activity and differentiate between what is known good and what is anomalous from known good.

D

So, typically, that's in the form of process baselining or establishing a list of what the container should run at any given time.

C

Gotcha yeah, because, typically, if you first think about it, the the opposite might seem optimal. Try to understand what's bad activity, but that's that doesn't necessarily lead into the right answer. Correct.

D

Yeah so there's two ways to look at it in terms of known good activity. There is a higher likelihood of a false positive anomaly, so, for instance, you could have an application running.

D

um Someone could be trying to troubleshoot that and executing into the pod to troubleshoot it, and maybe they forgot to detach the container before they did that, so the commands they run would immediately be identified as anomalous from what is known to be good, so known, good, has a higher risk of a false, positive and known bad has a higher risk of a false negative, because an attacker could either leverage something that you have, that is known good in the environment and try and use that as the basis for an attack, or you could have just missed a process or they could have renamed a process which is a reasonably standard way of getting around these things.

C

Yeah, it's almost like you, don't know what you don't know right, so uh attackers can exploit all sorts of ways that you don't account for um which is pretty interesting um so before we get to before we get to the demo. um What were we we were talking earlier about the mitre attack framework? Can you um can you comment on that like? What is that? Are there different revisions? Is that helpful for understanding attack factors.

D

Yeah, so there's actually a few industry standard ways of monitoring for attacks and mapping out a defensive strategy for and doing gap analysis, so miter attack specifically, is one of the solutions in the market that defines ways that an attacker, the techniques and tactics that an attacker is going to use in order to get into your environment, and these range from the tactics which are what you see at the top from initial access execution, which is, I want to run malicious code in your environment, persistence, which is I'm trying to be able to establish a foothold into your environment, privilege escalation, which is I'm trying to get additional privileges to do more um defensive evasion, meaning I want to delete all the logs and ensure that you can't find that I did it credential access, which is, I am trying to get access to credentials.

D

Discovery is a basic understanding of your environment and impact, which is really your action or an objective which can be anything from hijacking your resources, such as the example of crypto mining, to a denial of service attack. If say, I'm a competitor trying to shut you down.

D

So, ultimately, we see these tactics and techniques be used in order to map defensive strategies and prioritize where people are trying to target their instant response procedures. So, for instance, something that is initial access might be a lower priority than something that is an indicator of privilege escalation.

D

um So this is an industry framework which we see people using in order to map defensive strategies, um but there's also ones that, in my opinion, are a little bit more mature. So, for instance, the microsoft threat matrix for kubernetes also has a very similar mapping. That's more kubernetes specific! So really there are many industry standards and they help users to understand and prioritize where their gap analysis is and their instant response procedures.

C

Yeah, it looks like this one has a bit more on on cloud things like using cloud credentials and cloud resources so really interesting from a multi-hybrid cloud perspective, yeah cool and um what you know in your experience, stack, rocks and other places. Where do you see?

C

Where do you see most of the attacks in terms of mapping it to the you know these matrix, like? Do you see mostly execution attacks, privilege escalation? What what do you see most.

D

Yeah, so in terms of so we don't actually get that information from our customers, because we do sell this commercial, the commercial off-the-shelf software. So I'm going to speak to what I've seen in things like hacker news, for instance, and usually what we see in hacker news and the attacks that are reportedly wild are mostly financially incentive, so crypto mining, for instance.

D

We all know that bitcoin and ethereum have gone exponentially into a curve at this point, and we also know that most attacks are from not from complicated things, they're actually from gross misconfigurations right so, for instance, an unauthenticated kubernetes api endpoint. Well by default, most cloud providers- um openshift they're gonna, have an authentication mechanism that prevents that. But if you're rolling your own kubernetes, then it's really low-hanging route to just start scanning the internet reports and trying to authenticate and then stealing all of those resources and doing what you want with them.

D

So I mean I'm gonna, I'm gonna do this a bit ad hoc, but I can even show you that, like showdown.io is where a lot of these porch scans are.

D

um So if I wanted to just search for six four four three cube- I don't know if I'll actually find anything, but here I can start uh to look to under oh perfect container. One is this image, so I found a kubernetes api server here and I don't let's stop showing this one.

B

D

So so it is reasonably easy to do it's public information and there are tools like shodan who ultimately are publicly accessible, that are very easy to use and scrape the internet to understand that both defenders can use to understand if their network is vulnerable, but attackers can also use to target things um and ultimately, people test with these yeah.

C

Yeah, it was interesting you mentioned configurations because my my mind might pass it's all been about applications and vulnerabilities in those applications as well as maybe credentials, but even I we did a show yesterday with a partner where we talked about the reports that red hat has put out, and it was aqua and awkwardness that they put out and the reports on the red hat side listed that 60 percent of issues security incidents were because of bad configurations.

C

So it's really sort of been now the primary issue um for attack or for getting hacked for security events. Is these. You know bad configs that are and there's so many different configs right in kubernetes that it's, it's obviously tough, to to keep track of.

D

Yeah I mean ultimately, we do see that the the basics of hardening and using compliance benchmarks, like the cis benchmarks, are really effective methods to compete with attackers trying to exploit basic misconfigurations. So like. Ultimately, I think you'll realize that a lot of attacks are script. Kitties, um an advanced nation-state attacker is going to have a lot more of a budget in order to run a dedicated attack on you.

D

So one of the largest exploitation methods that you hear about is someone launching a scan of a generic exploit and just seeing what they hit um without any real intent of targeting any specific individual.

C

Yeah interesting cool. um Well, I think we we should probably get to the demo now I guess in order to introduce it, you mentioned what it what it uh did before the show. What can you just tell everybody in a couple sentences? What what you're planning to do.

D

Sure so, first, I want to show you some examples of known, good and known bad activity by going through a reasonably realistic attack scenario that to preface this is definitely set up in a way that will help me. But I want to show you places and the steps that an attacker would go through in order to identify bad known bad attack vectors so that you can get a better idea to understand how to approach runtime analysis.

D

um So I want to show you known good and how that works. I'm going to do that through acs and its baseline technologies, and then we're going to try to pone some kubernetes and running application in a more realistic scenario to see if we can get to the host and ultimately destroy the host.

B

Nice wait: let's do it.

C

Yeah, so the goal would be to have a to have the demo break at the end. We can't use it anymore. The cool thing, though, about this demo, is, I believe it shows most of these miter attack columns right so we're doing privilege escalation, execution, credential access.

D

Yep so we'll start with initial access. um We will then move on to some forms of execution and privilege escalation. I'm not going to show you persistence, but show you representative examples that could be used for persistence and we're going to take care of impact and credential access as well.

C

A

D

Cool, if you want, I can get started. Let's do it have at it yeah. So this is red hat advanced cluster security and the view that you're seeing here is a prioritized risk view. This is used to identify what is known to be the potentially most risky deployments in your environment.

D

So up here we see visa processor, backend atlas and mastercard, processor, mastercard, processor and visa processor and both in the payment name space. So it's reasonable to assume hey. Maybe they potentially contain credit card information, so I'm going to click on master card processor and get some identification of what the risk indicators are and why people are saying this is the riskiest in my environment.

D

So I see I have several policy violations. I have suspicious processes running images with the vulnerabilities and some potential misconfigurations.

D

So if I look at process discovery here, what I can see is that cat is being run and ls is being run in a way that is anomalous to what is the standard activity for mastercard processor.

D

So I want to look at this a little bit more because cad and ls don't really tell me much. It really just tells me, maybe someone's troubleshooting something so I click on cat and I can see they're counting the file, var lib processor card data, and now this is beginning to concern me so rather than unders and it looks like the ls was really just to understand what was in a processor.

D

So let's look a bit more about what's happening. I can see you name is a standard they're, not running arguments. um There's a java process running looks like this is tomcat, so maybe they're exploiting a tomcat vulnerability. I'm not sure how someone could have gotten in this or if someone just looked at that, then I look at carl, and what I see here is that someone is posting the card data that was just catted to innocent.site.web.

D

So obviously, that's an innocent site and I'm going to completely overlook that for now, because it says it's innocent right, I'm I'm going to go to a visa processor now and basically do the same thing, and this is a lot more representative of an attack that you would see because you can see. People are accessing the entry point. Rm is standard, sh and sleep are standard.

D

But if I look at what's actually happening in this environment, I can see a package manager was run. The package manager was used to install netcat, then netcat was run and it looks like it's being used to initiate a reverse shell over port 9001 to shell.attacker.com.

D

So, ultimately, these are the types of things that we can start to look for in terms of deviations from known good activity. While these are more drastic examples, you can get the value proposition of I understand what my container should be running. Containers are ephemeral and if my container does not standardly run this process- and I have not pardoned it in order to remove processes that are not standardly run, then this is my best option, and this is some of the value.

D

Add that you can see with I trying to identify the differences between known good and what could be anomalous.

D

So that's just an example, but now I want to talk about known bad because that's way more interesting, so I'm going to move this and move over to our our shell shock site. So, if you're not familiar with shell shock, shell shock was a remote code, execution vulnerability, I believe back in 2014 and it allowed users to effectively input trailing commands to as part of environment variables, so um it impacted a large portion of the internet, ranging from ssh to apache for instance.

D

So what we're going to do is we're going to put exploit apache, so I want to show you just how to do that here. So what I'm doing here is um apache, so this exploit is about running trailing commands when you use environment variables, so apache is using the user agent header here that I'm defining and it's inputting that as an environment variable.

D

So now I'm escaping that running echo really just for legibility, and I want to test to see if this works, I'm port forwarding to this instance, because I don't want to run random vulnerable things on the internet.

D

So I can see here. I've got the command that I've tried to do, I'm just running pwnage as a test, and I can I know what I can do now. So I want to see now that I know I can exploit this. I want to see what permissions I have so I want to see who I am so. This is disappointing to me because I'm running as www data, which ultimately means there's a default configuration within apache.

D

So what saddens me is. I now know that I won't be able to get root and it'll be incredibly more difficult for me to exploit this container, which is why users always say um don't run your containers as root and they also say to harden it, because I've just run two commands that are likely anomalous activity and ultimately this was not caught. So if you're, looking at known good behavior and looking for deviations, I should now have linda lit up the sock to help people.

D

I look and say who's who's. Checking. Who am I so now because I'm not root. I want to see what I can get so I'm going to check my environment variables and I can see here that we have a host we've identified. I can see my present working directory, but there's nothing good here so now I want to see what commands I can actually run in my environment, so I'm really just going to run an ls to bin to understand what I have access to so now.

D

I have a list of the processes within the container that I can run and this list is going to form the foundation for how I approach it, because I have a few methods of approaching this at this point. I can either try to download tools, so I can use a package manager. I can use wget, for instance, um but I need to put in the tools if I do not have the tools here, that I need in order to continue this hack, I'm screwed.

D

But if I do, then I need to download them. So ultimately, what I'll end up doing is I don't have wget. I have access to a package manager. So, let's see if we can do that a bit later, but ultimately I've already tested this. This is a pre-setup environment.

D

So I want to see how I can begin to escalate. Privileges. Kubernetes itself has a standard place that puts service accounts in your environment and, if you don't explicitly say I do not want to mount a service account, then it will just add the default service account.

D

So that's why guidance, like the nsa guidance for instance, says to turn the auto mounting and your deployments for service accounts to false, so this container specifically has not turned that off, so I am going to cat a token that can then be used to authenticate to the kubernetes api server with whatever permissions the service account has, and at this point I don't really know what service account it is.

D

uh I can reasonably assume that, given I can access this in the first place that it's going to be the default, so I now have used a remote code, execution, vulnerability in a website. Initial access run and executed multiple commands and used those commands to get an authentication credential to the api server.

D

So I know that as the wwe data user, if I explore this more, I'm really not going to be able to do anything effectively. So I need to begin to access the actual api server itself in order to launch as a mount point.

D

So what I'm going to do is I'm going to exit this. I know that we do not have the actual information in the environment variable, because this was not a root user to link to the kubernetes api server. So let's assume for a second that I have managed to get that api server endpoint in a different way and that I would have access to it. So I'm going to export this token.

D

Let me just copy paste that.

D

Okay, I've exported that as environment variable, I'm just going to oc log out to make sure I am not.

A

D

There we go perfect so now I've used this token to authenticate to the kubernetes api server, so I've now begun to take initial access and I've begun a privilege escalade.

D

So let's check oc project oc projects and I can see okay now I can begin to understand more about this environment that I'm trying to hack now that I have access to the api server.

D

So ultimately, I don't want to set off a bunch of alarms. So I want to check very slowly what level of access that I'm given with this account. So, ultimately I would go through. I would do cube cuddle. Can I and I would check hey- can I exacting the pods, because if I can exec into pods, then I can begin to run commands within them to try and see if I can, access data or get other credentials or even run a crypto miner.

D

So let's try cube cuddle. Can I and yes I can exact into pods perfect and let's see if I can create pods, because this is going to allow me to create a back door? Yes, okay, perfect! So I now own this.

D

So, first off I want to go back to that shell shock deployment that we had so I'm going to exec into that to really show you how I would have done this if we were running as rich, so oc, exec chuck it's in the default namespace, so I'm not going to put in a namespace okay. So now I've exec into this shell shock deployment, I'm going to run. Who am I okay? Now I am roo and here's an important thing to say um now that I am root.

D

I have the information directly here in order to have authenticated to the api server in the first place, so I know the service host. I know exactly where it's hosted and I know it's poor, so this has given me sufficient information in order to authenticate to the kubernetes api server. If I was not running as the www data user.

D

So what do I want to do here? I want to install crypto miner on this service because I just really want to see how insecure this is so, first off I try and install w get, because I want to download a crypto miner. It looks like I can't do that, so the reasonable next step is to get update.

D

Okay, it looks like I'm failing. I am failing, because I am unable to reach out to places where packages are. I see that this is based on a really old container image, which is also an alarming sign, and no doubt the reason why it this is vulnerable, so I am going to remove its sources and update them so that I can actually download packages um because I do not have the ability to do a vi.

D

I'm gonna have to print this and type it in to the sources list itself and now, if I do apt-get update.

D

I can see that I've now successfully updated. There are a few things I couldn't download, but I think that'll be fine. So now I want to begin to do an ingress tool transfer.

D

So what an ingress tool transfer is, is it's the ability to download tools that can then be useful to me to continue the attack. So there are two types of tool transfers. um I can either do one from a place within the network or I can do it from a place external to the network. This is an ingress tool transfer because it is getting tools from an external network, so I am going to download w getting curl.

D

D

And this is taking away slower than it should perfect. Now, I'm going to cd to temp.

D

I am going to go to I'm going to w get ethminer, which is a a standard tool for mining ethereum.

D

I've now downloaded ethminer as a tarball file. So now I have to unzip it.

D

And I'm not actually going to run this full command, because someone told me that I shouldn't put my own crypto mining wallet in this. um But ultimately, at this point I can now I now have ethminer in bin. So I can. I can see data bin.

D

And ls now I have ethminer, so I am going to just run this. um Ultimately, what I'm doing here is I'm using the tool to connect to uh in ethereum mining pool. I am checking the farm and rechecking it I'm using the stratum protocol over and over and encrypted transport.

D

um If I wanted to actually use my own crypto mining wallet, I would insert it here and then I would put in the worker name, which is really just the the identity of the mining pool and go to ethereum.org.

D

So I'm going to run that this won't actually work in real time, because I don't have my worker name or ethereum all in here, but it'll be used as a representative example.

D

Or maybe not, that's, probably a good thing yeah, but you will see at the end of the day that I have attempted to run heath miner in solutions that monitor this and that this is a known, bad process.

D

So, ultimately I wanna I wanna, go through and see what I would do next. So this is my impact. Assuming that I could run ethminer, I could have gone through and really taken some of these resources, but I'm still logged into the kubernetes api server.

D

So I can do a bunch of things, but first before I do those, because my now next goal is to destroy this entire cluster is I want to show you what the identification of known bad activity looks like.

D

So, if I look at the shell shack deployment here, you can see. We've run a crypto mining process now sure that crypto mining process did not actually function. But you can see here that process did not work because it doesn't have the worker name or the eth wallet, and you can also see that someone's running a crypto miner in my environment, with the shell shock deployment, which really is alarming.

B

D

C

D

You can identify that the package manager is executed, so this is an indicator of that ingress tool. Transfer, I'm port forwarding, because I don't want to expose any of this to the public internet, so ignore that for now- and you can see even that- I've exec into this backdoor container so exec is that means of execution and monitoring for known bad activity like ingress tool, transfers and crypto mining services is what's really important in this context.

D

So I I want to move on a bit to how would I begin to finally escalate my privileges and show more about this environment.

D

So I have a few things I can do, but first I have a privileged container here. So I'm going to use this privileged container and schedule it because I have access to create containers and because I have access to create the containers and create pods, I can schedule a pod that is purposefully designed to give me access to the host, so this is designed insecurely by me and by the attacker in order to facilitate a container escape.

D

So the reason I can container escape here is because I am a privileged container and I have a host mount. So what I'm going to do is I'm going to schedule this container that has privileges and I'm going to route to the host in order to get in so first, I'm going to oc, apply f to privileged.

D

Perfect now I've now created my backdoor, so I also have access to exec in so this is all the access I need to get onto the host.

D

So now I'm going to oc exec it um my container is called the back. My pod is called the back door. Pod um looking for names like this is obviously alarming, but the one thing I do want to call out is that attackers aren't just going to schedule. Things called backdoor pod.

B

Right they're going to pick a random uid or something right like.

D

Exactly actually, what I'm going to do is I'm going to look for the names within the the actual name space, I'm scheduling in and I'm going to try to name it as similarly as possible. So we showed the visa processor and the master card processor deployments in the payments name space, I'm going to schedule this backdoor pod, I'm going to call it the amex processor and and see if anyone notices that they don't take. Mx wow.

B

So for to your security team, they might not know that.

D

B

D

So that's crazy but yeah, it's all about business context! So now I'm on this pod. I know that this pod is privileged and has a host amount of pwned. So I'm going to ls check that that host mode is there and then I'm in the right container. I see pwned I'm going to troop deponed.

D

And I can now see that I'm on the host, so I'm going to check. Who am I I'm root on the host ils and I can see okay. This is different from the file system that I was on previously and, if I want to say cat etsy.

D

Cat etsy- let's see, what's here, oh wow, what a terrible command right! Yeah um you said you enjoyed watching people, make blatant mistakes when they're, not following scripts um cool. So now I can see the configuration or, if I'm really just bored, I can rmrf slash right. So, oh.

B

D

There are real fill saves here, that is, that is wonderful, perfect new preserve.

A

B

And it's gone bye.

B

You can't touch anything in prak anyway, so but yeah it's ninja vanish.

D

And now I go to this uh back to the service and I wait slowly for everything to be deleted and nothing to function.

B

That's not going to take too long. I don't think.

D

Exactly so, ultimately, that's the way we tend to look at things. There are known good vat. There are known bad. There are known good. We can monitor for those things and if you look at it from a security perspective, you want your sim to be notified near instantly.

D

You want to initiate incident response activities, as you start to see these things and you need the business context in order to make more informed risk management decisions because, like I said, if you see amex processor, you don't know, if you see amex processor and that's privileged, then that is terrifying.

D

So that's why a lot of a lot of guidance that people give are minimized privileged containers, because, yes, they're absolutely going to be needed for something like a monitoring program or for a security solution within kubernetes.

D

But the reason why that we say minimize is because we want to prevent backdoors so that ultimately, is an example of a real world attack and that's how we want to go through and monitor and initiate runtime analysis and why runtime analysis as a security program and opposite devsecops program is important.

D

So there's a few things I could have done if I wanted to, I could have initiated those policies that were catching and alerting on the things I was doing and I could have killed that pod right. So that's why, as a devops program, it's really important that you have liveliness and readiness probes so that you can kill that pod effectively without business impact.

D

So devops does need to care about security and security does need to care about availability, and that is how ultimately you as a devops team, can help identify what is known good with your security program for the most important things in your environment and that's why those security controls are set up in devsecops.

D

So that is the value proposition for why devsecops is the way.

B

That is awesome well done. Thanks.

C

Very cool and that that whole thing, though, interestingly right it all started with a vulnerable um pod right. So one thing right that you probably know hopefully before you even push that into prod is hey. You've got some vulnerabilities in here that that you should resolve, um and so you talk about devops devsecops.

C

That stuff should all always be caught. You know, early on in life cycle during builds. Now, of course, vulnerabilities happen all the time. You know your your image is clean today it won't be tomorrow. So that's why it's good to have what jamie was talking about some sort of um well, the liveliness probes and everything. So you can kill a pod or you have some sort of remediation in place, so you can take care of that, because devops ultimately also speeds up, helps you to fix production issues quicker right.

C

um You don't want to be sitting there with one. You know legacy app, it gets hacked. You got to shut down your your payment processing application for any amount of time.

D

C

D

That's why ultimately, a security program and a development and application delivery program really have to care about informed risk management, because monitoring and just securing all the things like that's an anti-pattern security is about risk management, and there is literally no point in trying to ensure that your rules apply to the least critical application in your environment. That's locally, hosted not even externally exposed in any way versus your visa processor, like you want to monitor that, you want to make sure that you have your program, treats visa processor very differently than cron job.

D

That really just sends a report to single developer.

B

That I mean, and in a way like, I noticed acs, pointed out how old the container was right like to an extent like uptime, is a bad metric nowadays right, it's kind of flipped on its head. um Those containers should kind of be cycled out more. You know often I feel like right. So there's patches, you can apply constantly. You should be swapping those containers out and updating them as you go yeah.

D

And that's why I always say security is interests have shifted right, so you'll you'll hear a lot of people say like security is viewed broadly as a blocker and security has stopped my application from being deployed now. Why did they stop that? Okay, there's a critical vulnerability in it that they blocked you on. um They want you to go fix it, okay, that critical vulnerability is already there.

D

So what is your next step you need to? You do need to escalate that you need to identify if you are actually vulnerable to that, but ultimately fixing it is going to need to occur quickly. So devops is in the best interest of the security program because being able to deploy and remediate things quickly and having a mature testing program is going to be the ultimate indicator of success, and that's why I say: there's no such thing as devsecops before devlops.

C

Absolutely true: yeah security was always part of devops from the beginning, we're just trying to put the focus more on security so that it doesn't. It isn't a blocker. You.

A

Know like it was, I always say I always remember.

C

When I deployed my apps as a developer, I'd get a spreadsheet from a security team saying your app is vulnerable, but they wouldn't tell me any details like right.

B

C

B

Ugly, sorry yeah.

C

So um yeah, so that's you know, devsecops you're, totally right. Jamie has always been a part of devops. We just want to make sure to focus on that give security a seat at the table. You know uh let them be part of the group. You know the lunch team whatever and uh so that uh you're all working together. Obviously devops devsecops is more of a culture shift, initially at least than anything but uh yeah and getting security right and integrating it at the right time will definitely allow you to to not make it a roadblock.

C

B

C

Well, cool that.

B

Was very sweet.

C

Any any other things you want to chat about jamie, or is that wrap it.

D

Up wrapped, that might be the first time of rmrf to node, but.

A

B

I have to admit right, like I've, never done that.

C

I don't even want to type those words.

C

On a terminal, well cool, I I want to thank you jamie for coming on to uh devsecops is the way um it's a really neat topic and uh loved, how you hack some stuff, and so that probably is a wrap for, for today's show stay tuned for a blog which will be coming out, hopefully in the next week or so around the the category, and then next month october, we're going to have another exciting category and then all the way up until december december, we're going to start talking about platform security.

C

That's going to be a lot of red hat, ish type stuff, like se, linux and um those type of good stuff, we'll see if we can get some good guests on for those shows. But with that I want to thank you thank everybody and chris I'll. Let you wrap things up.

B

Yeah awesome. Thank you very much. Jamie awesome demo as always um coming up next on the channel here in an hour. So, uh oh, I don't have my utc clock up. Sorry, uh we're gonna have the stack racks office hours with we're gonna be talking about kubernetes network policies with, uh if I can say the name right, oh, I lost it, never mind it's not on the screen anymore.

B

So one of the stack rocks team members coming on gonna kick tires on some network policies and show us the why and the how behind it all so yeah, please stay tuned for that and uh when in doubt, subscribe to our calendar or look at our calendar and you can see what's coming up next on the channel and uh thank you dave for coming on again. Thank you. Jamie.

A

B

Stay safe out there folks.

A