Two Houses, Both Alike In Dignity; AppSec and Cloud Security

00:00:05

Speaker 1: My name is Akira. This is Stephen. Thank you so much for coming to our webinar. Today we’re going to talk about AppSec versus Cloud Security and how in the past maybe they have not gotten along so well. And we’re here to convince you today that they can work together. Well, It’s very important for them to work together, and we might talk about some strategies that they can, they can actually work together and also talk about the top concerns of Cloud Security, top concerns of AppSec. And just give you a little background on both of those things as well. Feel free to ask a ton of questions. We’re also joined today by the Oracle, who is a mysterious figure that is definitely not Tanya Janca. It’s an AI powered blockchain Ethereum thing. So we’re not sure how it got here. It’s just here. So we’re going to ask questions of the Oracle from time to time as well. So feel free to put your questions in the chat, this will be more free flowing. It’s not super, super structured. It’s just a way to get to know about these two topics and hear about how they work together. So thank you everyone for coming. And Stephen, you want to go ahead and kick us off.

00:01:05

Speaker 2: So, should we do personal interests. Right, I’ll go so we’re alternating. That sounds good. My name is Stephen Giguere. Now you know where I’m from and where I live now. I did move to the United Kingdom in 1999, just in time to party. And I have been working in, I have crossed over actually, I was working in application security for several four or five years. And then I became this obsessed with Containerisation and Kubernetes and Cloud. So I’ve been kind of doing that for the latter four years. So that’s kind of where I am right now. I work at I worked at a small startup called BridgeCrew, which was acquired by Prisma Cloud slash Palo Alto Networks very hard. It’s a long, long title of a company to say I work for, but I work. I work primarily now as a contributor to the Open Source Tool Checkov, which does scanning of infrastructure as code and various other wonderful scanny things. I think I did a Bright webinar deep dive of Checkov just a few weeks ago, so I’m sure that’s somewhere you can go check that out. And otherwise I research and talk about security like I’m doing right now.

00:02:17

Speaker 1: Beautiful, ok. Hi everyone. My name is Akira. I work in developer relations at Bright Security. This is actually based out of California, not based out of Denver. We’re all remote workers. We actually all over the globe, which is super cool. I like that a lot. We get to meet all kinds of different people from different cultures. So I’m on the North America team. I work with Tanya Janca. Many of you know her as well from the We have Purple Community. She’s my boss, She’s great, and I’m more of a junior level person. I’ve been working in Devrel for about a year now, so starting to get my feet under me and understand a lot more about the kind of value I can provide. Before I worked in Devrel, I worked mainly as an educator for Tech, so I wrote EdTech Software and I also wrote courses and EdTech to help people learn how to become JavaScript developers. I’m an autodidact, I think is the word I’m self taught, although people like to say community taught, which I think is very true, I definitely did not just sit in a room alone and figure out stuff on my own 100% of the time. I asked a lot of questions and I’m very grateful to my community and I just I mainly got into Devrel so I can give back because so many people taught me and I want to teach all the things that I know to all the people. When I started at Bright, I truly did not know a lot about cyber outside of the authentication and authorization space because I had worked in an off shop before, right? A place called FusionAuth, really great, really great product for authorization and authentication. But now I’m learning a lot about AppSec, a lot about application security. I’d always been really interested in cyber, but I never really knew how to cross into this world. And then one thing led to another sort of I sort of stumbled into it and I’m really happy I’m here. I’m learning so much. We’re going to learn a lot from Stephen, and today I learn a lot from me today. But I think that one reason I like doing webinars like this is because it’s also an opportunity for me to learn. So what I’ll say is that if you have questions in the chat, please ask them because I will maybe not know the answer and then I’ll learn how to learn that particular thing. So I’m really excited for this. One last thing I’ll mention actually two last things. Just kind of my professional background. I’ve taught hundreds and hundreds of students all kinds of different things, not just tech. My first career was actually as a professional opera singer, and I still do that from time to time, as Stephen can attest. You know, sometimes I’ll just do it at karaoke and it’s pretty fun. But I do perform regularly still. But as part of my job there, I taught students from anywhere from age two, like really, really young kids, just basic music theory and how to play piano and all this stuff all the way up to people that were, gosh, probably in their late seventies. So I have a wide breadth of experience with teaching, and I’m really into education. I love to teach, I love to pass on my knowledge. And then the very last thing I’ll say, it’s kind of a matter of personal interest. I like to grow mushrooms. That’s like one of my big things. If you ever subscribe to my newsletter, you will learn a lot of random mushroom facts. So if you ever want to learn about CyberSecurity, music and mushrooms, find my newsletter because I will teach you all kinds of things that I’m learning from growing, which is a lot of fun. So we’re not going to devolve into a mushroom conversation because we will be here all day just talking about that. So maybe Stephen, we can our share our slides and talk about what we’re actually here to talk about.

00:05:49

Speaker 2: And at some point we’re going to break out into a band because I think the, The Oracle is also music oriented. If I move. You can see I have a bass guitar and a regular guitar sitting behind me. And off camera here there’s a drum kit. You can’t see that either. So myoffice doubles as a music studio.

00:06:13

Speaker 1: Are we going to sing this and perform this entire presentation in metal style?

00:06:20

Speaker 2: Oh, yeah. Yeah. We’ll do it in metal style. I’m glad you chose that. I figured that’s another. We’re talking about transitions. Opera to metal.

00:06:29

Speaker 1: Oh, yeah. Oh. Oh. Classical musicians love metal and vice versa. It’s like..

00:06:33

Speaker 2: That’s true. 

00:06:34

Speaker 1: You ask a metal guitarist what their favorite piece of music is probably going to say some kind of Paganini suite. So, yeah. 

00:06:41

Speaker 2: Yeah, that makes complete sense. Oh, we have an actual Q&A question from anonymous.. Are you putting the band back together? 

00:06:50

Speaker 1: yes.

00:06:52

Speaker 2: Let’s just say yes.

00:06:54

Speaker 1:  I’m going to type the answer, yes. Beautiful,  

00:07:01

Speaker 2: Rock on. All right. Let me introduce the slides, shall I? So before we got to this moment, Akira and I independently put together our top tips. Akira handling AppSec, I was doing CloudSec or Cloud security and thought this would be our talking points, and then we would allow to see how those overlap. But before we move into those tips and by the way, these houses, this slide came from me just Googling “weird house”. And then I just used my emotions to say, yes, that looks like AppSec and that looks like CloudSec. So I think both of them are ten out of ten on dignity for sure. So I’m not going to slide forward yet. But I think what we’re going to do is I’d like to throw it back to you, Akira, and say, like try and try to define application security in your own words or steal quotes from Tanya’s book as well.

00:07:59

Speaker 1: Yeah, for sure. Let me just read Tanya’s book really quick. Give me about three days and I’ll be back to. Yeah, so application security, Gosh, what a huge term. So application security is mainly like an umbrella term that is used to describe anything and everything that has to do with writing and shipping secure software. So that’s, that’s giant, right? So there’s activities inside of that, like secure code reviews. There’s things like using a DAST or a SAST tool. There’s things like getting an AppSec person into the design room when people are specing out and either a feature or a full application to make sure that when they are building, building these applications, that there’s not a bunch of security measures that are being either maybe ignored or maybe not followed correctly. And normally what I will say is that AppSec usually has been owned by an AppSec team or by someone like a pentester prior to now. However, with the sort of ratio of AppSec people to developers, the ratio is about 100 developers to one AppSec person, and that is actually from data from 2020. So I’m sure that it actually might be a little bit more, a little more crazy now like more developers to AppSec people. So there’s a big push in the industry now to try to give control over application security to developers. So a lot of that involves tooling, a lot of it involves education. That’s something I’m really passionate about, is teaching people like proper AppSec and just mindsets and how to maybe write your code in a way that is a lot more secure. So that’s kind of what AppSec is. It’s again, it’s just everything that you can do that helps you write and ship secure software. And I know I only mentioned a couple of activities today, but there’s quite a lot of ways that you can actually learn more about it. I’m a moderator in a community called We Hack Purple, probably a lot of you are here from that community. There are free courses that we have in that community that are all about AppSec, and you can learn all about the activities and all the things that kind of entail that even how to make your own like mini AppSec program at your job, or if you’re working maybe on an open source project, you can learn how to make an AppSec program for that as well. So definitely check that out. I’ll put that in the chat here in a minute. If you want to learn more about what AppSec is. How about you, Stephen? What is cloud security?

00:10:29

Speaker 2: What is cloud security? I’m going to get probably the sack if I get this wrong. So cloud security. I’m going to throw a little bit of history in here, too, because I had already mentioned how I moved from AppSec into the container space and Kubernetes and all of those wonderful buzzwords that populate search engine optimization. And I’ll give you the impetus to I was actually visiting with one of our let’s say, one of the, I guess, customers that was a solution architect at the time. And they decided to just put me in a corner and say, look, all that Java we were doing. Yeah, it’s gone. It’s all Node and it’s all Kubernetes. We’re doing core OS containers. So what are you gonna do about that? And I went. Leave. Put my tail between my legs and go. What are you talking about? What’s a Kuber…what? Moms Spaghetti? I don’t know what you’re saying. So I then had to put my tail between my legs, walk away, and figure out what on earth he was talking about. And two things happen. I was. This is probably 2017, maybe. And so my mind was kind of blown. And I realized, All right, does anything we’re doing here work in this environment or does this need to change? I think at the time AppSec needed to change. And that’s a question I’ll have for you later. But um..and it did. But then we had a lot of problems. And then I suddenly now apparently, I need to know Kubernetes containers. And what does this mean? Where is it going? It’s going all to the cloud. Okay. We’re dropping on prem. We’re not running it on servers. Everything is going to the cloud. But what does that mean? How much of a transformation is that? How hard is that, by the way, my hindsight? Who on earth is running Kubernetes in production in 2017? I wish I could go back in time and just say don’t. That was the most vulnerable. It had a zillion things wrong. But you know, they did. And then I just started doing the research and realized, okay, all right, so we’re building as we move from Monolith, and there’s still lots of monolith out there, right? There’s nothing wrong with Monolith. It’s just there’s a lot of people started moving into Kubernetes and Containers, which sort of encouraged microservice style architectures. And then if you’re doing tiny services and remote teams and no one’s really talking anymore and you have a team of five people, a team of ten people, and they’re all connecting the dots via APIs, how do I know the path through code? And that was where a lot of our things like SAST broke, and then we started moving towards 80% open source in some applications instead of writing their own. And I’m like, Ah, all right. So that was when I started realizing, All right, well. Most of the headlines I was seeing were like S3 bucket exposed. I’m thinking, All right, all right. That’s all I could do all my AppSec, right and still be completely exposed because I got my CloudSec wrong. Interesting. So that was when I kind of I switched companies a few times and then started studying. So Kubernetes, I have like the triple CKD, CK, CKS now to try and make sure that I never get caught up by these things again. But I still get caught all the time. And now I think of cloud security getting to the final answer. Is the webinar over, is there any time left? As securing where the application is going, and that is super complicated. It is the cloud. But it also can be how do you set up Kubernetes? Are you using it as a service? Have you deferred that risk? Good. Great idea. Vanilla Kubernetes is impossible. No one ever said Kubernetes the easy way. And are you making your containers secure? And this is where we cross over because the container ends up in the hands of the person who’s writing the app that might go in there, typically because their dependencies are going in there using a base image of some sort. And I think we really blur AppSec and CloudSec at this point. And so I’m coming from… if AppSec was on this side and I don’t mean left or right, let’s say top or bottom, if the AppSec is down here on the cloud is up here. I’m now starting up here and working back until I bump into AppSec and there’s a real Venn diagram now with this area in the center where these worlds need to talk more. And I think even security teams, InfoSec has taken on CloudSec. And InfoSec still doesn’t talk to AppSec or to the developers who are implementing it. And so this is why we’re doing this webinar so that we can be a living, breathing example of InfoSec CloudSec uniting with AppSec so we can see where we crossover and how we can collaborate more. And hopefully we can start by doing our top six and maybe that’ll be cool.

00:15:22

Speaker 1: I’m also curious, like in the chat, if at your company or in your experience ever, if you’ve ever experienced CloudSec and AppSec working together well? We’d love to hear about an example of that. Also, if you maybe have an example of it not working together well, we’d also want to hear that. So maybe we can kind of hear like talk about maybe why that didn’t work so well. Ozioma says I am AppSec and also CloudSec. Oh, interesting. So like, Ozioma do you do, like you do both jobs right now? Is that like something…or maybe you’re the entire team? I mean, who knows, right? Sometimes that can be… oh, you are doing both! Okay, good.

00:16:02

Speaker 2: Do you work for a one person company?

00:16:06

Speaker 1: The companies me, and I’m stressed out all the time. All right. Okay, let’s see here. Alex says identity and CloudSec needs to be solid foundation for the apps on top. Yeah. Would you agree with that, Stephen? Yeah, totally. I would agree with that too. Okay.

00:16:22

Speaker 2: Oh, well, I’m sorry. One more point. And I should say this because I don’t want it to be gray area. The supply chain itself, super hot right now. And I was, last night, I was at a meetup in London. I arranged a meet up in London. If you’re ever in London, come see me. And our speaker was John Hammond. He’s head of technology at Amazon and he was talking about securing Amazon. They do, I think he said 50,000 deployments a day. So that’s a lot, right? So he went through their AppSec and CloudSec profile and how it looked. But the first thing he started with was securing the supply chain. He goes, AppSec and CloudSec are pointless without a secure supply chain. So he’s like, So where does that fit? Is it AppSec or is it CloudSec or is it neither? Because both need it.

00:17:19

Speaker 1: Yeah.

00:17:20

Speaker 2: And I was like, Wow. Yeah. All right. Nice. It was a good talk. So I thought supply chain, I think is a great point of intersection between CloudSec and AppSec. But I have a feeling CloudSec will probably end up doing it.

00:17:32

Speaker 1: Was there like a specific industry he was talking about with that? Or just like in general.

00:17:38

Speaker 2: He was, well he was Amazon. So he he’s actually AWS so he is in charge of EC2, S3, machine learning, like all the good ones that you’ve heard of all those services. Yeah. Yeah, in Europe. So that’s all of his, his domain. So he was essentially starting there and he said like obviously going way back in time, AppSec had more of a high profile.

00:18:03

Speaker 1: Yeah.

00:18:04

Speaker 2: And then obviously they were designing the cloud and he was explaining the ramifications of failure within CloudSec. Being, CloudSec is ubiquitous to how we operate every single thing that we do daily, our phones, our Netflix, our everything. If something goes down, if US-West-2 goes down suddenly. Well, as he said, my wife’s calling me because the Netflix doesn’t work and she wants me to tell her why.

00:18:32

Speaker 1: That’s like the upgraded version of being the tech person in your grandma asks you to fix her printer.

00:18:39

Speaker 2: Yeah.

00:18:40

Speaker 1: Yeah. All right. Looks like we have a couple questions in the chat really quick. Maybe we can address those and then we’ll move on to, like, the top points. Sure. Okay. So let’s see here. Ozioma says I do AppSec and I can also work on CloudSec initiatives. We will be building out a ClouSec team too agreed on supply chain being a thing now. Awesome. Ozioma, good luck. I hope that you guys have a good time building out that CloudSec team. Good luck to you. The Oracle says thanks for the nightmares, John. Oh, you’re welcome anytime. Ok, Steven says CloudSec, AppSec, DevSecoOps, so many acronyms. Yes, so many. To me this just feels like it’s just different words for the same thing. Similar to the DevOps engineer versus platform engineer versus site reliability engineer debate. One company’s DevOps engineer is another’s SRE, isn’t it the same with AppSec and CloudSec? Oh.

00:19:45

Speaker 2: I’ll jump in on that.

00:19:47

Speaker 1: Yeah, go ahead.

00:19:51

Speaker 2: The idea of this is completely down to argument, not the same. We didn’t ask you, Oracle.

00:20:00

Speaker 1: Yeah Oracle, wait your turn.

00:20:02

Speaker 2: The. So the idea of a DevOps engineer, a lot of people would argue doesn’t exist. It’s not a real thing. It does exist. People are called DevOps engineer. It looks amazing on your LinkedIn, right? But the reality of DevOps is just a style of working that’s heavily collaborative. That’s all it really is meant to be. And it works very well, particularly in a containerized environment because you are building a bit of your ops in order for your application to be a build once run anywhere kind of scenario. So that’s what DevOps really is. Now the idea of understanding the operations with any level of intense detail is essentially what evolved, in my opinion, into the SRE. So the SRE is like your super DevOps person, but they have the knowledge. There’s a lot of argument these days about how recently written by the… Oracle might know this, DevOps for Dummies. Who wrote that she I want to say, Emily, I’m going to get it wrong. Put a controversial tweet out recently saying that devs don’t want to do ops. That’s just reality. So whether it’s not necessarily, DevOps is often mistaken as devs now do all the ops, I don’t think that’s what it’s meant to be. The idea is, you collaborate heavily and you’re not siloing those processes between dev and ops, which still applies to AppSec and CloudSec because if you’re if you’re creating infrastructure as code and it’s going to be going through a pipeline, it gets treated as a first class code citizen. So it’s going to go through all the same checks, all the same security. It’s going to be treated like AppSec. And I think that’s sometimes where CloudSec falls down, where it’s in its earlier stages. There’s a lot of maturity in AppSec that CloudSec can learn from. So I do think there’s too many terms and I do think people get confused. Um, did I answer the question? DevOps Engineer, platform Engineer. I don’t think platform engineer’s fake. This is somebody who’s implementing cloud and has to understand CloudSec, so that’s okay. I’m going to let that one go.

00:22:03

Speaker 1: Fair enough. Yeah. I would also say to kind of piggyback on your point, Stephen, like that sometimes like that controversial tweet that devs don’t want to do DevOps, is that what the tweet said?

00:22:15

Speaker 2: It said devs don’t do ops.

00:22:17

Speaker 1: Okay, cool. Yeah. So I. How do I say this? I think the devs are just really, really over…not overworked, but they’ve got a lot on their plate, right? So maybe they don’t want to do it because it’s just too much. Right. And so that  sort of, that actually also presents a problem in AppSec. And I’m just piggybacking on the Stephens point here, we’re kind of off of the main question at this point, but I talked to a lot of devs and that’s one thing that kind of comes up over and over again is like, I have so much work. I don’t want to have to be responsible for security right now. Like how can I make this fast? How can I make this quick? Like, I don’t want to take a ten hour course on secure code and just like, tell me what to do right now. And I’m like, okay, validate your inputs. Oh, you know, sneak preview, validate your input. Yeah. So I don’t know. It’s just something to think about. Like, yes, like all of these, how do I say it, kind of, like all of these names that cross over. Like, yes, it’s true. But at the same time,I feel like not a lot of people want to do other jobs than their own job. So that can be challenging for sure.

00:23:22

Speaker 2: It’s absolutely true. And I think DevOps for all of its glory has muddied that water. Unfortunately, we need to take it back. Sorry devs, it’s not about you doing ops. Yeah, there are going to still be ops people who are really good at ops that are and are better than you.

00:23:38

Speaker 1: Yeah, I know…go ahead.

00:23:43

Speaker 2: The oracle said you don’t get two paychecks.

00:23:45

Speaker 1: One job for one paycheck, two jobs, two paycheck. Yeah, right. I wish. Yeah, I have a couple of my developer friends who have had to be in that position actually, where maybe they’re working in a smaller company or something like that. And they’re… one of my friends was actually a junior Dev and they were like, okay, you’re a junior Dev, this is your first job ever. Like, now you’re going to do all our DevOps stuff too. And it just burnt her out, man. It was brutal. And I hear that happening a lot. Not, not as much as it used to be since DevOps has gotten a little more formalized. Right. But it was pretty tricky. And that’s what I want to avoid with AppSec is like, I don’t want to have to make Devs, I don’t want to have to educate Devs to like take on the job of the AppSec team, right? It’s just let’s talk about the one 1% or 2% of things that you can do that will help you not have to have the AppSec team dump a bunch of work on you later, but also can maybe foster that collaboration between the Dev and the AppSec team.

00:24:39

Speaker 2: So Absolutely. Yeah. I mean, it’s interesting, some of the people who implement DevOps engineers makes you wonder if they read any of the Gene Kim books because if you jump to skip to the end unicorn project, you know one of the main things is psychological safety. You should be able to make mistakes and learn from them and be open about that, certainly. And you’re going to make mistakes if they make devs do ops. Yeah, this is how containers end up running as route.

00:25:10

Speaker 1: Right? Yeah, okay. Maybe Steven, you want to go on to, like, maybe your first point. Looks like we’re out of questions right now.

00:25:21

Speaker 2: Fantastic. Time is flying. We could. We could sit and banter this forever. All right. 

00:25:27

Speaker 1: How long do we know we have today? Like 50 minutes or something?

00:25:31

Speaker 2: I think we have the hour.

00:25:33

Speaker 1: Okay, cool.

00:25:35

Speaker 2: Including questions. All right, my top six CloudSec tips. We were going to do five, but there’s no way man. Six, It’s got to be six. Can’t do anything in five. All right. I didn’t make this appear in order. I should have, you know, I should have faded them in. Oh, well, that’s too bad, but we’ll stop at number one, do not read ahead if you’re watching this. Okay? Don’t get excited. And my first biggest tip is just straight up. It’s not even a security tip. It doesn’t sound like it is, but it is. Not using infrastructure as code. So not using a terraform, a cloud formation, I don’t even care if you use in a script like Python, something that codifies the creation of your cloud or your Kubernetes, not using anything like going into Amazon console or Google Cloud Console and going okay EC2 and push this here and…. doing it that way. Absolutely terrible because you have no capability for KS engineering or pushbutton reproduction of an environment. If you’re like, I don’t know what’s going wrong, it’s not doing the thing, redeploy, get it back to a known state if you don’t have any of that. That’s really, really bad. Plus, codifying all of your infrastructure means, as we said earlier, it becomes code. It becomes a first class citizen and it can be scanned using security tools. It can, all those same checks and balances can be made on the destination for your application as is made for your application. So it’s, I still get a little bit amazed when I see people, Cloud engineers just kind of creating things through a strange, strange method of doing things. And it’s like, Hmm, really? That’s point one. Any comments? Anybody? Criticizing. We’re administrators, not developers. My outsourced ops refused to use anything that is not push-button click ups. Oh, my goodness. I’m so sorry, Alex.

00:27:38

Speaker 1: Brutal.

00:27:39

Speaker 2: You need to re-outsource to elsewhere. Well, if you outsource your ops, that could be a problem, actually, because if they codify it, they sort of automate themselves out of out of requirement a little bit. So, yeah. 

00:27:55

Speaker 1: I’m curious, Stephen, how do you convince people to not do this? Like again sometimes and be like, Don’t do it.

00:28:06

Speaker 2: I love it. What’s kind of funny in my current role, because I’m so heavily focused on securing both Cloud’s existence and tying it back to source changes. So my role is to detection of misconfigured cloud. But then rather than say, fix the cloud, I say fix the code. I don’t end up running into the people who aren’t using the code. I just know from previous jobs that they exist. But then it wasn’t my job to tell them not to do that. So it’s kind of funny. I don’t. It doesn’t. I stare at the camera and I say, Don’t. That’s what I do now. I hope they come to these webinars and they read these things. This is, this is how we scale ourselves to try and hope that the message lands.

00:28:54

Speaker 1: Yeah. Can you maybe tell us what happens when they do this? Like maybe go a little bit deeper into the consequences?

00:29:03

Speaker 2: Well, the consequences is non repeatability and that is, that is quite a big deal. And certainly it affects scalability because when you’re using infrastructure as code, certainly I’m going to use TerraForm because TerraForm is the open source version of infrastructure as code. Others are available and very valid, but you can start sharing modules. All the same benefits that you get with application security exist within infrastructure as code. You can commit them into a repo, you can share them out, you can say, I want to, I want my S3 bucket or I want my AC2 instance or I want my EKS. This is exactly how I want it set up. And I know it’s correct and it can be peer reviewed. It can go through pull requests. All of these advantages that we know work for application security that even as little as 5 to 10 years ago used to be a guy’s script in bash on his laptop. So making sure that it becomes part of the community is is really why we should start moving to these bespoke languages. If I were to skip to six, which maybe I should have made that 1.a, the other advantage of certain types of languages and I’m going to stress declarative and this is where I’m going to trash talk things like Ansible and Shell script and my Red Hat friends would be mad at me. But declarative infrastructure as code is declaring state versus declaring a recipe. Right. And oh, I should check out my infrastructure as code course on We Hack Purple and you can learn more about that. So and if you’ve got state, it means you don’t need a full blown SAST like a full blown SAST. And I’m sure the Oracle is well aware of this, requires the creation of an abstract. What’s it called? Oracle? Syntax table so you can parse all possible paths to find particular vulnerabilities. And because anything can happen in a term complete language, it means anything can happen to the deployment of your like an infinite loop can accidentally create infinite S3 buckets really, and it can get super expensive if you use a term complete language. If you use a declarative language, then you know what you get and this is what you get. If there’s two, you get two, that’s all. It’s not going to get out of control via traditional AppSec plus/minus one error, etc.. So that’s why I’m a big fan of declarative. And plus it also means that you can create graphs out of them. Graphing technology is very hot right now and you can use those graphs to create complex conditional misconfiguration checks like don’t have a container with a ten out of ten vulnerability in a manifest that is also privileged or doesn’t have a security context. So you can combine all of these things together. And Ozioma  made a very good point. Policy as code, OPA. Kyverno, I work on Checkov, so our policies are written in Python, so I’m going to big that up. But very similar doing policy is code allows you to create very simple rules. OPA and Kyverno are fantastic to use as declarative with declarative languages like ISE. So, so many security advantages come from not just using code but using a certain type of code. I’m going to stop talking, so I’m going on too long.

00:32:17

Speaker 1: Oh, no, it’s great. We actually just had another question for you. Come in in the chat, so maybe you can talk about this one and then we’ll switch over to the next one. So Ozioma said, I hope you get to talk a bit about policy as code. For example, OPA, Kyverno, etc. at Stephen.

00:32:34

Speaker 2: Yeah. So Kyverno, Kyverno is from, I can’t remember the company that makes it Jim BaGuardia. That’s the guy. Ketchumcoop con he always does a talk. He just released a really amazing Kyverno using cosine for attesting artifacts and checking containers. So check that out. Kyverno is awesome, but it’s YAML based and it’s specific to Kubernetes. Whereas OPA, open policy agent, from a perspective of policy as code is incredibly broad. It was created by a company called Styra and it can be used for authorization/authentication across huge VMs or it can be used, say via, I want to say gatekeeper. I think that’s their mission controller to block the deployment, to manifest using very similar graph based notations. It’s very, both are very simple for creating rules for security and are certainly massive in terms of cloud security. Both are great and I think if you can create your rules and you can also put your rules into git, so now you’ve got your security as code is being treated as a first class citizen as well and is going to be approved and go through pull requests and all that stuff happens. You’re kind of hitting cloud site nirvana if you’re doing that like nice work. Let’s send him a link, and you know, join us up here. Good advice. 

00:34:05

Speaker 1: Oh, this is good stuff. Maybe. Maybe he’ll have more good things to say, too, on the AppSec. So who knows? We’ll find out.

00:34:15

Speaker 2: Exactly.

00:34:16

Speaker 1: Yeah. Okay, cool. Let me see here. I know that I have my top six tips as well, so maybe we can go over to that really quick.

00:34:25

Speaker 2: Yeah, no problem. Boom.

00:34:26

Speaker 1: And I’m not going to do it in order because I feel like we’ve already talked about a few of them as well.

00:34:31

Speaker 2: And I’ve already broken my own order.

00:34:33

Speaker 1: So some of mine are kind of funny. Like number five. I think that’s neat. Let me see here. I kind of want to talk a little bit more deeply about the sort of point number three that some AppSec is better than none. And maybe, Stephen, you can talk about too, like how some Cloud Security is better than none. So like maybe like those bare bones things like you should absolutely do no matter what. And then there’s like the kind of nice to haves. I’m not sure. I don’t want to necessarily frame it as like, okay, well, if you do these three things, then you’re good, right? There’s sort of different layers that you can do inside of your application security endeavors. And I’m just talking about right now from a developer perspective. So I’m not actually talking about from an AppSec team or an AppSec person perspective, but because I mentioned earlier about how like developers, this is actually point number six. Developers need to own security a little bit more for their own code. There are things that Devs can do that they don’t necessarily need the AppSec team to be there for. They don’t need to have permission from the AppSec team. This can give them a little bit more agency in their own world. The first thing I’ll talk about would be, let me see here like a secure code review and using a SAST tool. So what does that mean? Essentially what you can do is the same way that you would do any kind of regular code review when you open a PR or you can actually have potentially a couple of people on the development team that know a little bit more about secure coding. So whether or not your company maybe offers something like a training course that people can take or maybe they give them a little more time to go and educate themselves about secure coding. Those people can potentially start doing code reviews in a secure manner for everyone on, not everyone on the team, but for people on the team that maybe will need it a little bit more. And then by doing so, they can also teach people what to look for, you know, things like, okay, like, you know, you do need to validate your inputs here. You need to do output coding here, You need to do maybe some other things that they would need to do, like a parameter statement or something along those lines. And then you can start educating your entire team. So that’s my thing that I like to emphasize the most is that education layer. So you can do things like that secure code review. If you don’t necessarily have anyone on your team that knows a lot about secure coding. First off, it’s a good idea to sort of lobby your company. Hey, this is actually really important because as you can see here on number four, upwards of 80% of breaches occur at the application layer, according to the Verizon data report, which we might talk about a little bit later, too, because sometimes, depending on how you read the report, the answer seem a little bit contradictory. However, it is, it is quite a lot of breaches. But if you don’t have time necessarily to do all these secure code reviews or you don’t have the necessary expertise, you can use something like a SAST tool. So SAST stands for Static Application Security testing tool. And what this does is it’s this tool like Snyk, and it is called a white box testing tool. So it looks at your code before it’s running and it just analyzes your static code and it will say, Hey, I think this is a problem. I think you might have some issues here. You should probably check this out here and it will actually look at the entirety of the code and give you a readout of vulnerabilities that you can then go remediate. Now, excuse me, there’s some downsides to that, which is that first off. You can’t necessarily rely entirely on tools to do all of your AppSec activities because again, like the best thing to do is to have security champions, to have more education so that you’re not writing bugs into the code in the first place. And then the second thing that is a little bit sketchy, not sketchy, but can be a challenge of SAST tools is that you can get what are called a lot of what are called false positives, which essentially is when a tool says, hey, this thing is a problem here, but it’s not actually a problem. So your developers can sometimes take a lot of time to look for, essentially go on witch hunts or go hunting for ghosts, things that are not there. And that’s sort of a downside, a way that you can configure this, though, and this kind of goes into sort of the ops way of doing things that maybe developers don’t want to do, is ask the AppSec team like, Hey, what are some things in this section of code that we’re seeing a repeated pattern on? Like what are the kind of vulnerabilities that we’re seeing a lot? And maybe they’ll say, Oh, you know what, SQL injection is happening a lot and we need to just focus on that. And then you can configure tools like SAST and DAST to just look for those types of vulnerabilities, which is a really good way to sort of minimize the work that needs to be done and minimize the overwhelm and the cognitive load. So that’s something I would like to kind of just say like again, there’s different layers, right? So I won’t go into all the layers because we’ll be here for 300 years and we’re already a little bit over half time. But essentially what I’ll say is that there’s sort of a 1 to 1 mapping at every single section of the software development lifecycle where the best thing to do is to have educated people looking at the code, making sure that it’s secure. And then there’s usually some kind of tool that can also supplement that. But I don’t think that people should just rely on the tool themselves. That’s what I’d say about that. Any questions on that or comments? Concerns, non sequiturs, More things for me, more things for Stephen. 

00:39:57

Speaker 2: I’m going to comment on that,  if you don’t mind. I think that was an official question. I’ll let you get to that in the actual Q&A section. Guess who it’s from. What a surprise. And the idea of education being incorporated into, well, SAST. But any tool that reaches developers, anything at all, the same kind of tools exist. When I mentioned if you’re running, say, in TerraForm, there are tools that can scan your TerraForm. The best ones are built into the IDE. And they are informing and potentially even suggesting there’s some fantastic maybe an old school term, but Linters or SAST tools that plugs straight into the IDE and I can be writing code and maybe, maybe when I save it, depending on how it triggers it can pop up and say, well, actually here’s I can’t see how you sanitized this input here. Or I can see that this is unencrypted from a more CloudSec perspective, and it can even, some of them even suggest fixes. And so I think some of the more modern, remember when I said AppSec needed to change and it has, there’s a lot of great things out there now that teach as they, constructive criticism, let’s call it that. They provide automated constructive criticism so that the developers do learn. I mean, outside of that, I think a great example of what you said is that if you see a repeating problem. Learn from it because you should have an education budget for your team so that you know how to target that. But even if you don’t, I’m sure the Oracle can direct you to some fantastic free training that can help you out in both our space, in both of our spaces.

00:41:38

Speaker 1: Yeah, absolutely. Yeah. I just, in every arena of my life, in my professional life, and sometimes in my personal life, to. The best way to remediate issues is just to avoid them in the first place. And the only way that that happens is via education. And like, it’s sort of like having almost like a healthy diet and then like taking a ton of supplements. The tools are important. You need to use these tools to help you. Sort of like taking a calcium supplement will help me when I get a little older because my bones are going to get all weird or whatever it is, right? But I can’t just eat Cheetos for every meal and then take a bunch of calcium supplements and assume I’m fine. Right? So it’s kind of similar. Like I think that the education component is like the fruits vegetables, it’s the eating healthy of the eating healthy of AppSec. Like I don’t think anyone’s ever said that phrase before in the world so there we go. Trademark Akira Brand. But it’s sort of like yeah, exactly. Sort of like eating healthy of AppSec. And then these tools can be sort of like a supplement to that. But they are very important. You still need to get those readouts, You’ll still need to understand things that these tools can catch that you necessarily may not be able to even as well educated as you are. Okay, we have…yeah.

00:42:56

Speaker 2: Oh, the oh, the toothbrush algorithm. That’s the one that I hear a lot in the AppSec world. You know, I pentest my teeth once a year. So do I need to brush?

00:43:07

Speaker 1: Exactly. Yes, that’s so true. We had a question in the chat about if you had to choose between one tool between SAST, DAST, SCA and IAST, which one would you choose? Oh.

00:43:20

Speaker 2: I know my answer to this. And it’s going to probably be different than yours.

00:43:26

Speaker 1: Really tough. Wow. If I had to choose one and then I have a really close runner up, I would choose a DAST tool. And that’s not because I work for a DAST company. And I’m not like, Yeah, I would choose Bright. I mean, I would, right? But that’s not that’s not why I say this. The reason I say DAST is because even if you have proprietary software, right, so it’s not open source, no one can see the source code. Someone on the internet can point a DAST tool at your software and find all the vulnerabilities that a DAST tooll can find. They don’t need to know your source code. They don’t need to know your dependencies. They don’t need to know who you are. They don’t need to have access to your GitHub. They literally just need a link to your website. They need the URL and then they can scan it with the DAST tool. Now that doesn’t make it legal, right? That’s not exactly like the most kosher thing to do, but they can do it. So I think that if someone, some rando on the internet can do it to your website, then you should definitely do it on your website as well and find all that low hanging fruit and remediate it as quickly as possible. Unless for some reason it’s a very non business critical vulnerability. But that’s a totally different conversation for another time. So that’s why I would say DAST is because anyone can do it. And it’s not that hard to use DAST, they are relatively simple to set up. If they can do it, so should you. The second one I would say would be the software composition analysis. And I say this because. If you have like let’s say you have a circle here, right? And it’s just like a little pie chart in any given application nowadays, especially with like so many dependencies on other pieces of software to write any application, your custom code might be like 5-15% of the actual code base. And then there’s all these dependencies, right? And I’m kind of just pulling these numbers out of the air. Don’t quote me on this, but there’s so many there’s so many dependencies and there’s so many vulnerabilities in those dependencies from time to time. And a software composition analysis tool will take care of analyzing those dependencies so that, you know, you’re not introducing vulnerabilities into your software via your dependencies. So I think that that’s really, really important. Now why do I not say SAST and why do I not say IAST? SAST I say wouldn’t necessarily put that at my number one priority because like I mentioned earlier, there’s oftentimes a lot of false positives. And unless you have a really close relationship with the AppSec team, it can be kind of, like I said, like just running around chasing ghosts. And if you don’t have guidance from the AppSec team on what to look for, that can be a really big waste of time. But they are good. If you have a good relationship with the AppSec team and you know what you’re looking for and you just are aware that there’s false positives and you know how to tell something is a false positive. Great. But for a beginner or someone that is a developer maybe doesn’t know a lot about secure coding and doesn’t have the time to learn it, that can be quite cumbersome. IAST, I’m not as familiar with IAST tools, but from what I understand they can take quite a long time to configure and they’re incredibly expensive. So if you need something that’s just quick and dirty, like just scan your website with an app. Excuse me, scan your website with a DAST or check it out with an SCA as opposed to having to buy a very expensive IAST that takes a ton of time to configure. So Stephen says, I agree, but my priority is the other way around. I’ll clarify why shortly.

00:46:52

Speaker 2: That’s me. My time is now! Hey, I’ll jump in on IAST. IAST for me is last place as well. IAST is super cool. It’s very clever. But most of the IAST tools that kind of came out of the woodwork, I mean, IAST started around 2009 and we’re like 13 years later and half of them don’t work or are really hard. They generally need to plug into the Java debug or the runtime of some sort in order to watch the events that are happening. And I think by the time IAST gets really good technologies like EBPF will be doing it better. My number one is SCA and I, it’s only like a little bit above DAST. I think DAST is just so easy. You can go on OWASP Zap and just turn it on and great. Some DAST is better than no DAST, that’s free. You can just go do it right. But SCA right now, having seen some of the insanity that happened when a certain bug from last December was released starts with L as with J and and seeing that was one of the first times I’ve seen a dependency that was so ubiquitous to Java applications that you could think you’d fixed your upgrade and not know that half of your other dependencies four, five, six levels deep were also using it as a separate entity potentially with a different version. So you see Java applications with five different versions of that vulnerable logging tool. And yet you think you’ve upgraded the one you see in your high level first level dependency tree and you’ve not. You’ve actually you’re still vulnerable because if I send the right message in, it gets logged. I can still exploit your application because the thing that depends on the thing that depends on the thing is using the logging version 2.13.1. and so it’s included separately in your in your palm XML or and it’s just there and it’s like, oh, whoops. So it was very easy to get caught out and because vulnerabilities are public to us for our positive security, white hat needs as much as they are annoying basement dwelling 14 year olds who want to write scripts that search showdown let look for vulnerable applications. It is one of the low hanging fruits in terms of and there’s tons of cheap tools for SCA or free. Like there’s so much free SCA out there, it’s bonkers. So I think it’s probably easier. And plus in a cloud native environment and this is super biased cloud native is mostly open source dependencies it’s like. We say on average 75% open source. But if you just went cloud native only, you’re talking like 85 to 90% open source. You know, we’re writing a lot of glu code here and so it’s just too easy to have transitive dependencies that are sneaking under the radar. So I’m a big SCA guy and I’m not saying that because seeing as you did this, we just launched an awesome SCA thing a week ago.

00:50:11

Speaker 1: Nice. Nice. Do you want to tell us about it a little bit?

00:50:15

Speaker 2: Oh, am I allowed to?

00:50:17

Speaker 1: I think so. I don’t see why not.

00:50:20

Speaker 2: All right, I’m doing it. The Oracle says yes, we released, so Prisma Cloud was always cloud security before, so it did live monitoring of running containers. And then it had a CSP tool which monitors cloud, and then BridgeCrew came in with the idea of looking for misconfigurations in cloud and shifting them left so that we were actually fixing the infrastructure as code, which is why I always go on about that. We had everything in place to do really amazing SCA, we just didn’t do it. We did Container scanning. But that was in isolation. Like, let me scan this container. Great. So now one of the first major integrations of what BridgeCrew does with what the former Twist Lock does, which is now Prisma Cloud compute, was to combine our powers and take the graph or the knowledge that we had of infrastructure as code. So taking everything from cloud all the way back to where the application lands goes into a container that we have this entire map because we’re looking at every piece of code and you integrate the repository is presenting that to the user via a visual supply chain graph that shows you these vulnerabilities are at this level and it goes as deep as it has to go. So if it’s if there’s a vulnerability and it’s in a ten level deep transitive dependency, but there’s a line to it. That will be shown to you. So I think we’re calling it Infrastructure Aware SCA. PaloAlto is big on coining phrases that don’t exist. So and that’s the idea and I’ve I, I came back from my holiday on Monday. I got my crash course on it and I did two webinars Tuesday. And I could legitimately be impressed with it because I’ve seen simple SCA, I’ve seen pretty complicated SCA, and I think they did a very good job at their first crack at it.

00:52:05

Speaker 1: Beautiful. Thanks for sharing with us. That’s cool. I’m glad. It’s always good to, like, have an experience where something your company releases is something you’re actually proud of and you’re pretty hyped about, which is always great.

00:52:17

Speaker 2: I think that’s really very cool. We only have 5 minutes left.

00:52:21

Speaker 1: Yeah, we have only 5 minutes. Good Lord. Um, all the hard questions, quick. Ozioma asked the question. Code quality tools versus SAST. What are your thoughts, Stephen? I feel like. Yeah, yeah, same. 

00:52:38

Speaker 2: You can’t have security without quality. You can’t.

00:52:41

Speaker 1: Right? Yeah.

00:52:44

Speaker 2: So that’s my immediate answer.

00:52:46

Speaker 1: Good answer. Yes. What other questions Do all y’all have? Anything else? But if you only got to pick one probably called quality tools.

00:52:57

Speaker 2: I go code quality because your security tools are going to go false positive, crazy if you’ve got bad quality code.

00:53:02

Speaker 1: Amen to that. Yeah, it’s like you just wrote a poem. Okay. Does anybody else have any questions? It’s probably a little bit too late to do any more of these top ten tips.

00:53:18

Speaker 2: Because I just slipped back to see if I didn’t casually mention any of these because I think I hit like we agree major breaches are a result of human human error. Basically, infrastructure defaults are insecure. I have to say that. Almost every default you download, off anywhere, be it code, be it Stack Overflow, be it Hashicorp examples, be it the instructions for deployments on Kubernetes, on the Kubernetes IO are giving you default manifests that you need to secure.

00:53:55

Speaker 1: Yeah. Yeah. That’s something that someone gave me a really good tip. I think it was the Oracle who gave me this really good tip a long time ago about how to find secure code. And, like, it’s like, if you’re looking on StackOverflow for something and, like, you see a piece of code that would fix your problems, Sometimes people copy, paste, whatever. But like Stephen just said, it’s not always secure. In fact, it’s usually not. A good way to do this though, is to ask your question about the code and then just type secure and you actually might get a secure answer, which is pretty cool. So yeah, that’s a good point. Defaults are not always necessarily the most secure options.

00:54:31

Speaker 2: Excellent. And I think if there’s no other question, is there another one? Info first, make sure it’s solid. So I’m…there is a lot of flurry in the chat. Oh, good advice from the Oracle. Yay! And make sure it’s just starting with securing your pipeline. Making sure that’s actually secure. First, whether you have one or two, that’s super critical. A good question about that is. So please read out the question. Building a separate CI/CD pipeline for app versus as code versus infra is code compared to building one pipeline. And the answer from the Oracle is to do two pipelines. But I think people do that because there’s usually a pipeline associated with a repo. So you end up having because your code destination and your implementation, you’re certainly CD part of that is completely different depending on whether you’ve got infrastructure versus app. So I totally agree with that. But I think get on board with making secure pipelines. And we have one minute left.

00:55:45

Speaker 1: Wow. Good for us. Let’s say. Any last thoughts?

00:55:50

Speaker 2: So I go, I was already talking. I’ll go. 

00:55:51

Speaker 1: Oh, yeah, go ahead.

00:55:53

Speaker 2: Almost everything I saw on Akira’s AppSec list, I think a lot of it applies in either a slight only with only maybe a slight abstraction. If you’re doing CloudSec, if you’re doing infrastructure as code. I think there’s a really heavy crossover is my big takeaway between the lessons I learned in AppSec and how we can apply them in CloudSec..

00:56:14

Speaker 1: Yeah, I think that for me as well, like, I think it comes down to understanding who does what and making sure that your tools are configured correctly. And again, just that education and collaboration component. I think they actually complement each other and it seems like at the end of the day. TLDR Like, do both. Don’t just do one and not the other. And it’s very it’s possible to secure an app if one is terrible and one is great or one is so-so and one doesn’t exist at all, so do both if you can. And if you can’t, then hire more people and throw money at it. It’s fine. All right, cool. Well, everyone, thank you so much for coming. We’re at time. We’re going to go ahead and close this webinar. Thank you again for your time. And we had a lot of fun. I think Stephen made great points. I think I made great points, of course. And thank you again to the Oracle for your hidden help in the chat. We really appreciate you and thanks again everyone for coming and we’ll say goodbye for now.