Resource Center  >  Webinars

The Quest for the Perfect AppSec Program


Speaker 1: Welcome, everybody, to the webinar about the quest to find or to create or to build, depending on the question. We’re on the perfect asset program. I think this is a topic that we hear every day from our customers, from our partners and from the industry overall. And people are trying to figure out in this modern DevOps world how to build the right programs, how to make sure that Appsync and development partner together. And we have assembled, assembled a great panel today. We will let everybody on the panel introduce themselves in a second. My name is Gadi Bar. I’m the CEO of Bright. I’ll introduce myself in more detail in a second as well. But with that, let’s dive into the agenda. So we’ll start with those introductions, as we mentioned, and we thought quite a bit about what is the correct format for this session. And we’re going to create slides and have something very structured. But then we said, no, if we bring such a a cadre of very, very experienced people, let’s just have a free flowing discussion. And in order to help that discussion, we decided to raise a few questions that we put together. You can see those questions here and my esteemed colleague Ken will actually lead that discussion. Yes, it’s an option for those who are interested, but he will lead that discussion and we’ll have an open discussion between the panelists around those. Feel free to post questions in the chat and the Q&A. We will monitor them and we didn’t plan on the full hour with the five questions that we have here. We were certainly expecting questions from all the participants so we can address those throughout. And then obviously at the end we can have some Q&A. So joining me today in this great panel are Gary, who’s the chief architect and co-founder of and the security veteran, have practiced your last name. So hopefully I get it right before camera Vic? Yes, Excellent. Good. She’s the director of cyber security at Job and Talent and Tanya, which I’m sure does not need any introduction. She is the CEO and founder of Hack Purple. I will start by letting each of the panelists introduce themselves and then we will go from there. So get us started.

Speaker 2: Thank you very much. So I’m Hannam and like I said, I’m a chief architect and co-founder here at Tensor Security. We build an application security posture management solution. And I came I’m coming to this end, to this discussion and to my role at Enzo from Guess the same place of starting as a hands on penetration test. I spent many years doing that. I got perspective of the challenge from from the way that the large organizations see it, but also innovative small companies also spent a few years in building applications myself. So kind of got the perspective of R&D. What does it mean to build something that is a business ready but also try and make it secure? How does that hit your priorities? And if ask different questions in from bottom up and top down in this realm of application security, I’m very excited to have this discussion with this with the rest of the panel.

Speaker 1: Perfect. Welcome.

Speaker 2: Thank you.

Speaker 1: Petra.

Speaker 3: Hi. So in my previous life, I used to be a medical doctor, and then I did like a full 360 shift and went into cybersecurity, went back to university, studied it, returned. Came into cybersecurity as a security engineer. And there I found my passion for OpSec, for cloud security, a lot of automation and all things tech, actually. So I progressed my career later on into going for a director of cybersecurity and job and talent, where I’m facing different challenges, which is, you know, creating a team, creating processes and figuring out how to scale in a large enterprise. So also I have a little hobby which is machine learning. So I do look at a lot of things from a data analysis and analytical point of view as well. So that’s me.

Speaker 1: Well, I think I just added a few questions to the Q&A based on your presentation. So welcome. Thank you, Tanya. You’re muted.

Speaker 4: Thank you. Hi, I’m Tanya Jenkin. I’m the head nerd. At we had purple. I wrote a book about OpSec. I’ve been coding since the mid 90s and was a software developer a long time. And I sort of. It became a pen tester, but figured out OpSec was where I actually belonged. It’s hard to be a social butterfly, but also be a pen tester. And so, yeah, I’m pretty excited to be here and talk about essentially the world’s best OpSec program. I think this topic is going to be amazing.

Speaker 1: But thanks for joining us. Briefly about me, your your entertainer for today. I started my way in cyber about 25 years ago. Actually. It’s a bit more than that now in the 8200 unit in in the Israeli military, grew up in a bunch of different countries around the world, but have been doing a lot of different roles, starting with the developer role through product roles, dealing with all sorts of fun encryptions and fun things like that. And then ultimately four years ago ended up in the OpSec world leading right security. Our focus is on developer centric tasks, so very applicable to how you get organizations and developers collaborating and working together. So seeing that from many different eyes of customers and partners and excited to join the the esteemed panel today for that discussion. Again. Before I turn it over to everybody, please feel free to post questions in the Q&A. I will be monitoring them. I’ll be adding those questions to and peppering them throughout the discussion. So let’s let’s make this interactive. You can see Tanya has got her humongous coffee ready. So everybody else, I hope you’re doing this. I don’t think we have that size in the US. Tanya, That’s just a unique.

Speaker 4: It’s just a venti. Theoretically. Yeah.

Speaker 1: Excellent. Perfect. So with that, let’s let’s turn it over to Ken and Ken. Let’s take, let’s take the discussion points.

Speaker 2: Yeah. So, um, as we were thinking of a good framing for, for the discussion that we’re going to have now, and we looked into our past activity. So by the end of 2022, we completed the survey and with about 50 CISOs globally and to ask questions to frame some of the questions that related to to abstract. We did it as part of our market fit analysis, but also as a general, um, getting prepared to understanding what is the market is going to be like and what are people actually looking for and what problems we have when we think about it from top down. And and then we’re going to touch on some of the the things that came up with this research. It’s available online. You can you can also look for it afterwards. And and the first thing that, um, that I want to bring up is, is that because this domain is so wild on one hand and, and we still have we still have a lot of approaches, a lot of things that we can start with. We have often that people don’t really know how to start. One of the things that we did at Enzo is to map it with the asset map. You can go look for it at asset It’s just a website that maps different solutions and, and and services that exist in this realm. It’s I know on personal account that people have used it to onboard but um, but when we think about it and with this experience of so many years delivering different different components, different blocks in the huge thing that is classic, I think that a good place to start is to ask, and I’m going to start with Petra to ask how to start. Like what would be the first thing you do?

Speaker 1: It’s a really good question.

Speaker 3: I think a lot of people who find themselves in this position where, you know, this question is, is like suddenly I’m wearing the upset hat is a lot of people start with just gut instinct, right? They do like a gap analysis based on their previous experience. And then they just figure out what would be the best solution to integrate. I would say the main starting point would be actually to get the buy in is like, you really need to get the buy in from the developers, from the engineering. You need to get the buy in from the whole company. On the corporate level, you need a risk framework because what’s the point of finding all of these OpSec.

Speaker 1: Risks.

Speaker 3: Doing so many scanners and then you have no one fixing it. It’s just sitting there. So I would say the first thing would be to get the buy in and then think about the tools to integrate. Now, tools wise also depends on the size of the company. If it’s a small company that’s just starting a startup or a small company that’s below 500 employees, I would say you can start with open source tools. If you got the right team to implement them, you can go with or zap for dust. You can if you’re on GitHub, you can get dependable, you can do container scanning with trivia. You can use a SEM grip as a tool. So a lot of things can be done in open source to begin with. But if you’re a large company that’s scaling, you might want to think about some commercial tools to integrate into your pipelines, to do reporting for you, to make it easier for the devs to remediate. But as I said, the main starting point is actually to get the buy in.

Speaker 4: Right. May I add on to that? So of course, I totally I love Pedro’s answer. I would add on to that inventory because sometimes when I go to start talking to companies, I realize their list is only about half of their apps. And all the lists are all the apps that are not on that list are particularly insecure, usually because no one has been taking care of them. And so, yeah, and just like she said, if you don’t have a budget like getting a bunch of open source tools is way better than nothing and just taking their temperature, if that makes sense. So find all your apps, including your APIs, and then trying to just figure out sort of where they’re at. Like these ones are bright red and need lots of love. These ones look okay, and so we can do those ones later. So yeah, I really liked your answer.

Speaker 1: Petra Thank you.

Speaker 2: Think that? Yeah. So. So do you see this as, um. So now I’ll take Petra’s answer and say we need to get the buy in. And the buy in is key because otherwise the rest of the activities would not be so, um, so impactful. And then you also add this, that a first step that you probably get, you want to people buy in on would be to prepare this inventory or maybe the inventory is how you get this buying. I’m not sure what you what you meant.

Speaker 4: Oh yeah. So if you do an inventory exercise that’s a value not just to the security team, but all of the software developers or whoever’s managing that group, they definitely would like to have that list of inventory, especially the APIs, because you’ll probably find, first of all, some old APIs that are still on that you didn’t think about. There’ll be a bunch of apps that you know, Oh, that guy that wrote that left three years ago, but it’s still just been running on its own. Yeah. So I find the inventory can help you build up that buy in. I also find that like when you call it like taking their temperature, but you run a whole bunch of scans and sometimes I’ll call it lighting up like a Christmas tree, like where the whole report is like red and orange and yellow and there’s not very much green. I’m also noticing a whole bunch of really good questions in the chat. So for when you’re ready.

Speaker 1: Yeah, I’m monitoring those. It’s mainly people chiming in with their own ideas, so feel free to talk about it. I’ll mention some of those, but I think maybe to to to add on to, to the framework because people did talk about frameworks in the chat, etcetera. Now there’s the age old and we’re seeing this work very well with our our partners. It’s people process technology, right? If you’re going to start a new program, first of all, understand I actually think the process is the most important thing in in understanding how does your organization work? Because you want to make sure that whatever framework you create for the apps program fits well into the rest of the organization. If it doesn’t fit well into the rest of the organization and make it seamless for everybody, then you’re not going to get the adoption that Petra is talking about. You’re not going to figure out the technology that Tonya’s talking about and the mapping that Tonya is talking about, etcetera. So first of all, understand what the organization is doing now. Then look at the technology and what are the assets that we have, What do we know about what don’t we know about? And then based on knowing those two, make sure that you get the buy in and work with the people on getting the correct process. So it’s three different steps that I think are very helpful.

Speaker 2: Yeah, I think I think that, um. You can also you can also look at these as three different components of building a good program. And in that and so everyone ever try to build a to plan for an engineering project knows that one of the first things that they will hit would be the Jira, the building up, the the columns of activities or Kanban or whatever, whatever you choose, you use technology, the right technology to, to, um, to help you set up the process. The combination between technology and process is very tight in, in the world that we are living in because we use technology also to build up our processes. And in this we’ve experienced that the, that inventory is, is a technology that fits into these people, process technology and combination. And if it’s invested and you have the proper technology, it can help you set up this start the journey for the buying because it will let you create those measurements that can be useful to talk to the top of the the decision makers, but also to the organization and showcasing the right things to do. And this could be a step that is almost that is very useful on the way to get through buying and starting establishing the right process to secure your technology. I think with this, we can we can move on to the next question and I send it back to you also talking about and we can skip to the next slide.

Speaker 1: Yeah, I’ll move in a section. Just a couple of questions that came in that are really relevant to this. Maybe we’ll discuss those and then move on. Sure. 11. that Steve brought up is where does threat modeling fall into everything that we discussed? So if anybody wants to address the notion of threat modeling, and then we have one other question.

Speaker 3: If I can I want to mention. So I completely agree with the threat modeling and risk assessment, because as I said initially, even like you need to have a risk framework, how to escalate whatever you find. And I think. Having an inventory, like Tanya said, also goes into it because once you have your inventory, you will be able to actually understand the owners of all your assets and then, you know, actually what to threat model, you know what to scan, you know what to threat model. And yes, if you are, you know, just starting a good idea could be to first do a threat model, understand what would be the most critical applications or services and then focus your energy on those.

Speaker 2: You’re talking about like meta top, top level threat model.

Speaker 3: Oh, yeah, exactly. So you start with a big threat model of your like depending like if you have an application that is hosted in microservices, you start with a threat model that will kind of give you an understanding of your whole attack surface and then you understand what the criticality of all your assets and incorporate that into your inventory, assign the owners, and then you understand where you can put more energy in in terms of your team and asset program.

Speaker 4: I agree completely. And that’s actually I was going to word it a different way, but say the same thing. Like every organization has a mission. And so, for example, I worked at Elections Canada, and guess what their mission is? Is democracy, right? Their mission is to ensure every Canadian that has the right to vote is able to vote in the easiest possible way. Right. And they want to encourage as many Canadians as possible to vote. And so whenever we look at our apps, it’s like, oh, there’s one that registers people to vote. And it’s like, that’s pretty important to our mission. And so just like Petro said, you start with the super important parts of whatever your organization’s mission is.

Speaker 1: Yeah, totally agree.

Speaker 2: Good. The other the other question that came up was more around discovery. Both Petra and Tanya touched on the fact that, first of all, you need to know what you have out there. And people asked whether there are great discovery tools that we can recommend. I know there’s a lot of companies that have come out in the last few years like Salt Security and others around Discovery, which is probably the place that most people don’t really have any good visibility into. But with the esteemed panel, I’d like to talk a bit about discovery of how you find stuff out there.

Speaker 4: So I’m kind of obsessed with this topic, which is probably why Gary’s smiling. So there’s ways that you could manually try to discover all your APIs. So for instance, if you’re in the cloud, you you have a cloud dashboard. You can look at all your platform as a service. You can scan all your containers and your virtual machines in the cloud or on prem and look for is Port 80 open. And also if it is bad, is port. So port 80 Http and then port 443 is Https. So encrypted traffic. So I hope that that’s the one you’re doing. But scan all of those and see if any of those are open and then go check them out so you can automate some of that. If you use was that product called. Um, it’s something I open AI or something. Anyway, it’s an awesome tool and you can just send it and say just load the index page and just take a snapshot. So like any sort of traffic over those things is Webby, whether it be API or it be a web app, you can use something like Nmap to scan a whole bunch of these things, but there’s a lot of products on the market right now to do API inventory, but also there’s a bunch that do web app inventory as well. Like oh my gosh, cloud defense. I know that um, Wiz Wiz doesn’t really do web apps. It’s more like APIs. You sort of ill find all your middleware like your SaaS products, which you still have to secure. If you do apps, you still have to test them sometimes, but basically you end up using usually a combination of a bunch of products or you buy one where that’s all it does and it’s amazing, but it’s usually expensive.

Speaker 2: You also have tools.

Speaker 3: Like Orca and Lightspeed. They will also show you your external.

Speaker 2: Assets.

Speaker 3: And has a community version as well where you can just do a discovery of all your domains and show you your attack surface.

Speaker 4: Oh yeah. Okay. So there’s also bit discovery asset note and then also came up with something called a mass. So am a SS, so that’s free. And yeah, that’ll do like a public footprint based on your domain as well. Sometimes. Petra I have seen things where it’s like, why is my domain name switching when I click this page? Why? Why? So you want to find all the things? All the things.

Speaker 1: So think one of the things we’ll do as a follow up as well is there’s there’s a lot of good comments and good links in the in the Q&A. We are recording this, so we’ll summarize everything and send out a summary to to everybody.

Speaker 2: So think that Am also approaches like external attack surface mapping that combines those tools that you’ve mentioned, Tanya to one offering that also build an external inventory and external map. Here at Enzo, what we do is that we tap into engineering data sources, so we tap into GitLab, GitHub, these kind of sources. So we read the same APIs. We also follow up on the content inside the SIM to follow them up like to a next level. And this is what we do on the left side and we also on the right side we have we can feed on, on logs and on cloud configuration similar to what products are reading and build the a map of the dynamic assets. And then we also have correlation engines inside that brings the two images together to show you a full connected inventory. And then we move on to controls to instrumenting controls on top of this. But our approach to this is just to bite in the data and correlate it and build the inventory for you. So this fundamental basis for inventory will be an unquestioned say.

Speaker 3: Perfect.

Speaker 1: Good. So I think we can jump to the next question.

Speaker 2: Yeah, so.

Speaker 1: Let you take that from there.

Speaker 3: Yeah.

Speaker 2: So, um, unfortunately what we see that, that the activities that are that were mentioned here, for example threat model is, is not gaining enough, enough, enough attention. And it’s not because people don’t recognize it as very, very important. It’s just because it is harder to approach and something that is much easier to approach is less automation. Like we had a couple of options mentioned here with open source or with commercial. And I think that because because we have we have a CEO of a dust solution here in the panel, I think it’s a very important we ask we ask you how how do you see the question of value add in this very, very challenging playground of application security? Yeah.

Speaker 1: So obviously I’m a bit biased, but there’s a reason we chose to do what we’re doing because we think it has real, real value. And I think it actually goes back to the the previous question around people process technology. You need to make sure that whatever tools you’re choosing, whatever solutions you’re choosing, are actually a fit for your organization and are going to drive value. Now, we understood that there is a segment in the market of companies that are utilizing DevOps and have modern development technologies and some of the tools and solutions that are out there are just less of a fit for them. So if you look at legacy solutions or if you look at some static analysis tools, etcetera, they provide less value to those organizations because of the speed and the velocity in which their development organization operates. And if you try to deploy the wrong tools, that creates antagonism between apps and development. And we all know that we don’t want that. We want full alignment between apps that can development and we want the two to work and collaborate at the correct speed and the correct way. So think the the most important question you need to ask is how does my organization work today and how can I make sure that the tools that I select are the correct tools for how that organization works so we can get the most value? If you are, again, a modern development organization, I believe that will serve you very well as long as it’s developer centric best. If not, then there are other tools that will serve you better and you need to get that understanding.

Speaker 2: Yeah, well, we also experienced that, um, that this buy-in that we mentioned previously is not something that you, you know, you just get and then it’s yours. It’s something that you have to maintain and it’s something that you can also very easily lose. And if you and if you put, if you put the rest of the equation. So if we think about maybe the engineers themselves as sort of the bottom of the equation and the decision makers that they would budget on the top of the equation and is somewhere in the middle trying to trying to bridge the gap and maybe govern somehow and make help to help both sides take the right decisions. And this buy in, if you if you aggravate the any side of this equation, you will lose the buy in and you will use the ability to to impact. And this is why we see that um that any tool that that that gives the option for controls to to the developers and let developers tap in in a natural way has less um less risk of damaging this and more chance of getting better adoption and incremental adoption into development. And it’s also easier to inventory if you have evidence in, in code that this tool has been onboarded to, to a static. So to a task that is instructed in the code you have, in the code, you have the instruction for the desktop to perform the scan, you can tell that there is a coverage by this control. This control cover. That is it.

Speaker 4: I would also add it depends on what talent you already have. So let’s say you’re an OpSec manager and you come from vulnerability management and before that you did audit and before that you did governance. And you don’t really have a ton of technical skills if you don’t have any technical people on your team. And I’ve seen I’ve seen this and they’re just like, I don’t know what to do. You you would pick a different like a more point and click simplified tool that handles a lot of this for you rather than if it’s like, Oh, we have three people that used to be pen testers. They love destroying stuff, then maybe you would get a more manual tool that requires a lot more technical knowledge and they’ll go slower. So depending upon who you have on your team, like let’s say you’re the asset manager and you already have a three year deal with a company or even I’ve heard of five year deals and you’re just stuck with this toolset. You have to work with what you have and then try to figure out how to roll it out in a nice way. And so that’s a challenge I’ve seen companies do to or they’re like, Yeah, our tool is this We know it’s old, we have to deal with it.

Speaker 1: Yeah, maybe just a pointer. From what we’ve seen from a lot of our partners, Tanya, to that challenge that you bring up. Yeah. If you find the correct solution, even though you have another solution in place, talk to the vendor. They’ll be able to help you. We’ve definitely had cases where somebody was stuck with an old solution that they didn’t want. They didn’t have budget, and we figured it out together in a partnership to make sure that they actually get the tools that they need. I’m sure Colin has done the same in the past.

Speaker 2: Yeah, believe it or not, vendors are here to help in many ways.

Speaker 3: Shocking.

Speaker 4: No, but I had no idea that that might be an option. So that’s. That’s very, very good to know. I also think it depends on the technologies that you’re building to like if you have one great big, huge monolithic app, you might take a different approach to We’re a startup that’s nine months old and we have like 4000 microservices and we don’t even have a gooey. Do you know what I mean? I think that that also matters too. And the way that you would set up your your scanners and stuff. Yeah.

Speaker 2: Um. Maybe. Maybe you can move to the. Yeah. So. So I think we’ve touched this subject. Um, but the real question here is. How. How do you. Operate in a scenario where you don’t necessarily know what you are protecting. What what would how would you recommend to approach this? Um, I’m, I’m trying to build trust with developers. So let’s dig in a little bit more into this question and maybe try to talk about how what things we can avoid in breaking the trust and what things we can do to make sure that there will be more pool left, that people will pull more tasks to their direction, actually doesn’t matter for us if it’s left or right or up or down. It just we are often in a position that we can’t really perform the fix. We’re only there to raise the flag and hopefully to set up the rule, to set up the the playground and and to maybe help in in setting priorities. But we are not those will go in and change the code or make a new deployment. So we have to play in this way. So what are your tips? We start with you better.

Speaker 3: It’s a really good question and it’s something that I’m sure that most OpSec engineers and program managers encounter. And there’s two things to it. One thing is whenever you pick a tool, make sure the developers are included in the POC, get their feedback on it. You want them to be happy with the tool. If the tool floods them with false positives and they weren’t even included in the POC, then they’re not going to trust you. The other thing is trust goes both ways, right? So if you maybe don’t have the skills that you could do a proper assessment to tell them how accurate this tool is, then maybe you can put that back to them and ask them to do the assessment. You know, tell them, Hey guys, this is the tool tells us this is critical. Can you look in your code? Can you let us know what you guys think? And I think if you showed them that you trust them to assess all the findings, then also they will trust you when you start trying to do that, too. And maybe once you have a more developed program and, you know, senior security engineers who can win that trust more easily.

Speaker 2: But but don’t you think that it might you know, no one really have enough time to assess all of this, so maybe maybe in a controlled way, I’m not sure how to because then say say that you have included them in the PLC and then decided to switch on the automation around reports from dependable and then all of a sudden so many reports. So what do you do then?

Speaker 3: I think I think this is where you need to be careful, right? You don’t switch on automation straight away. You drip feed it. So depending on how mature you are with your OpSec program, you start with, okay, maybe we can just see what we got right now. See, ask people to try remediate what’s out there. Okay, maybe now we can turn on some PR checks. Maybe only for critical and then. Okay, now that we’re more mature, now that we’re not getting any vulnerabilities and maybe we can be more stricter now, we can put something in the pipelines and potentially start blocking pipelines. So you start gradually and you go via maturity level. You don’t just throw everything at them at the same time. Yeah.

Speaker 1: I think maybe to add a few basic things, having worked with Ben and worked with many developers and I’m sure Tanya will echo this, is there are a few key no no’s for developers. One, if you give them false positives, they will never talk to you again. So make sure that whatever tool you’re giving them is precise and is finding the stuff that they can actually trust to give them proof. They are not absolute experts. So if you’re going to show them a vulnerability, if you’re going to show them a problem with what they wrote, then you need to make sure that it’s spelled out in dev speak and not in apps speak. They don’t know what CV’s are, they don’t care. They understand bugs and they understand how to fix a bug. So whatever you report to them, you need to make sure that it’s communicated to them in a way that they can work with. And the third one is make sure that you’re helping them resolve the issue. So don’t just tell them here’s a bug, go fix it. Make sure that you actually giving them remediation guidelines that is meaningful to them. If like SCA tools, you can actually fix the problem for them even better. But for most vulnerabilities, you can’t fix it for them. You can just guide them and show them how to actually fix the issue and then they will appreciate it. The other point I’ll add is, sorry, I’ll pause here and I have one more point, but I’ll let others chime in on this.

Speaker 2: I think you should go ahead. I want to hear it.

Speaker 1: Okay. So the other point was make sure that you’re showing them value, right. One of the great research points by Nest shows that if you’re able to identify and remediate a vulnerability very early, as early as the unit testing or a step like that, it will take 60 x time less to resolve it than if it’s in production. Imagine you’re a developer and you have two scenarios to deal with. Scenario number one is I’m writing the code right now. I did a submit or a pull request. Vulnerability is found and X is found and remediated right there on the spot. It took me an hour to fix it. Scenario two is I wrote this code six months ago. It’s in production. A vulnerability was found and now I need to work for two weeks. Or even worse. I didn’t even write this code. A guy that’s no longer with the company wrote this code and now I need to spend two weeks to get into that code and try to fix it. Which would you prefer as a developer? Of course you’d prefer the one hour fix right now on the spot and get it done with, but people don’t perceive it that way. So if you’re able to have the right solutions and the right processes in place to show them the value immediately, they would accept it much more.

Speaker 4: I like all of that. I would add on to that. We don’t have to put every single tool in the pipeline to do a great job like I’ve seen it where, you know, they have an agreement for however many years where they have to keep using XYZ tool and they take it outside the pipeline and they run it overnight every night or they run it once a week on things that are already out in production. I there’s this project called Defect Dojo where it sucks up the results of basically all the popular scanners, which is exciting. And so I’ve seen people just plug that into the CI CD pipeline and basically there’s a policy for each different app and it’s like if you have this many things wrong, you can or cannot go to prod. And so it would just pull Defect Dojo. And so every time they check in their code, there’s some scans Every time they push to their dev server, there’s some scans. And so you can automate a lot of things to make the pipeline go faster. If that’s really, really important to your developers or you can practice in a copy of their pipeline so you don’t actually deploy anywhere or you don’t deploy anywhere that matters. So you have your own little security server and you can just like pew pew until you’re blue in the face, right? But I think the key, like Gadi was saying in Petra, we’re saying is you kind of need to check in with what the devs want and how they’re working. I remember a few questions ago Gadi was talking about this and like build what we’re doing into their processes. If we, you know, when you pet a cat backwards, it really doesn’t like it. We don’t want to do that to them. And so, yeah, just to add on to that, thank you.

Speaker 1: Maybe. Sorry. Go ahead.

Speaker 3: Yeah, I just wanted to add to this how important it is to give them when you were saying like not to give them false positives, it’s also important to give them vulnerabilities that they can actually fix. There’s no point showing them things that don’t have a fix, you know, because a lot of scanners just show you things that, you know, oh, here there’s a vulnerability, but what can I do to fix it?

Speaker 4: So information.

Speaker 1: Informational.

Speaker 4: Yeah.

Speaker 3: Exactly.

Speaker 2: So before before before any of my co-founders and I, we were practicing the As apps team at Wix and very large company and hundreds of developers and, and one of the things that we did to that is part of this was to have always a challenger and the role of the challenger and this would be a selective task force running on specific mission to bypass a security mechanism, always this challenger, but it has to be deep in the technology stack of the application layer and they have to find interesting things. It’s the only the only the bottom line was it will be interesting. It will get developers excited from from a techie point of view. So they will be tapped into the to this also from from understanding try to a little bit get to the understanding of is it dangerous. So if you show a developer and ask it is dangerous on one hand but it was also cool on the other hand and they get excited and this pulls them in a little bit to the process. But like we said before, it’s something that you have to keep maintaining. It’s not, it’s not magic and it wears off after a while.

Speaker 1: Perfect. Maybe to address a couple of the questions that came up. So three questions quickly. One, there was a question regarding Security Champions program, and Tanya already posted a response to that. So please look in the Q&A again, we will send a summary and we will add links to all the references and the points that were discussed here, but definitely an important program for many organizations. A question tied to that came in the Q&A, and that is how large does your organization or your development or company overall need to be in order to have an abstract program? How do you define a budget for it, etcetera? I know my approach to that, but I’ll let other answers before then. And then there’s a third question that we’ll touch on in a sec.

Speaker 2: I think you’ve already answered this by saying that if you start early, I mean to hope to catch this bug in unit testing is is awesome when you can. But the greater scheme of that is that if you start early with building the right building blocks for OpSec and making sure that it’s part of the culture, you should start from the first line of code with those easy to onboard solutions that are free. Sometimes that are included in you just have. At least even the tiniest bit of upset maybe have by your by your GitHub. So have dependable running on and have and have a little bit in your process to take care of some of this feedback. So the organization will be used to doing this from day one and then the rest will will be to accelerate and improve on that.

Speaker 1: I think for anybody who’s read Tanya’s book and if you haven’t, you should write apps as part of development. If you’re doing development, you have to be doing OpSec, right? There’s no you can’t separate the two. Otherwise it’s like saying to to me, it is actually mind boggling that somehow there’s this perception that security vulnerabilities are not bugs. No, they’re bugs. If you’re fixing bugs in your code, you should be fixing security vulnerabilities. So you should be starting very early on. As Len said, you need to understand what budget you have, etcetera, and do this correctly, but you have to start very, very early.

Speaker 3: The same way security tests are actually QA.

Speaker 4: Yeah. So if you’re doing.

Speaker 3: QA, you should be doing security testing.

Speaker 2: A little less prestigious sounds maybe, but it’s not. It’s not the point. The point is to build the right process for every part of engineering. Security is part of engineering and, and it’s just to, to build it correctly. Even those bugs have the same kind of problems sometimes when they hit the priority and buying problems and when the bug is not prioritized by the feature owner because it’s not exactly it’s about maybe, say, product principles that are coming from another angle that is not under their feature owner. We already start discussing priorities of bugs, not even security bugs. So this this issue of of having to invest a lot of attention in in software development is all over the place and it also touches us. But here we have a special element of risk that you are exposing to some risk when you don’t take care of this.

Speaker 4: I would say to that when you’re doing your SDLC, so your system development life cycle, you don’t have to like so let’s say you don’t have a budget, which is what my first abstract program had. Our budget was zero. And so I did use some open source tools, but I also just started at the kickoff meeting. I’m like, Hi, I’m Tonya, I’m your OpSec nerd. I’m hoping that we can do these two things during our project. Know I want to run some of these scans. I’m hoping you will run some of those scans. I’m also going to give you like 2 or 3 security requirements of things that I want to see. And back then, you know, I was asking for every single public facing app to be Https only. And I remember they’re like, Oh, Tanya, that’s not important. But I made it a project requirement and then I got it right. And so we can support them not only by sending them 400 bugs that we found with our amazing tool set, but we can teach them how to not make those bugs in the first place. We can help them design a more secure app. Oh, and I didn’t write a book about security champions. I just have a talk about it in a long blog series, but I am considering that. But my publisher says I better get back on the secure coding book or else. Just kidding. They’re very nice to me. I have to write that book first.

Speaker 1: I think one other question before we move on to the next one. I don’t think we’ll address it here, but there was a question in the Q&A regarding how you actually get started in application security. I know Tanya has talked about that excessively in the past. So we will we will make sure that we respond when we do the follow up with more resources on that. All right.

Speaker 2: All right. So. So a large part of the theme of this discussion is prioritization, because it is, I think, one of the core problems and then even even how to how to come up with this list of of the things that you would be doing and and how to prioritize it. How do you how do you prioritize today? How do you approach the problem when you meet the when you advise or when you when you practice? What what is your approach to to choosing the right activities and to prioritizing between from that moment on?

Speaker 3: So I think that’s a also a very common question. You know, like how do you understand what you need to prioritize of so many findings, especially if you have a lot of microservices, a lot of repos out there, where do you even begin? Right. So. Again, it depends on the size of your organization. If you have someone who’s very technical, your team and a small organization, you can try creating some scripts maybe that communicate with the GitHub API, something in Python. You can try and create some, you know, dashboards using elastic and things like that. But I think if you’re in a large organization and you want to really answer this question appropriately, you want to probably look into some tools as well, maybe even like Enzo, you know, like that will give you the visibility over all your repos or your services, what is in production, what is not in production, and that will help you prioritize because then you will understand which asset is critical and then and which asset is external. And that way you will know what you give to the devs to fix first.

Speaker 2: Yeah.

Speaker 4: Yeah. Sometimes I’m like, if I just go right in after her, am I, like, cutting someone else off? I’m Canadian, so we’re very concerned about appearing rude. Yeah, I agree. I try usually to talk to them about again, like I focus on our mission. And so sometimes the mission of the organization, their app is not part of that. And so I try to go with how important that app is to the mission and then how important those vulnerabilities are to that app. Like sometimes this might sound odd, but something that’s a low in the scanner based on your specific business model, it might be a medium or even a high or if you have two things separately. So for instance, cross-site scripting plus missing security headers or plus your serve token is not so secure or plus your cookie settings are bad so they can steal your session ID, right? So it’s like, you know, this one on its own is not bad, but because you have this like you’re now in the trifecta of awful. And so if you can explain it to them like like that does that make sense? Like you can string two together and then that’s the two of them become critical at that point?

Speaker 1: Yeah.

Speaker 2: We’re definitely seeing more to that point, more and more requirements. And this is something we started years ago and constantly focused on the notion of business logic, vulnerabilities and how do you understand the logic of the application to be able to represent the actual threat to your application or API, which makes it even more exciting, um, based on the actual context. So definitely something we’re focused on in our solution. Yeah.

Speaker 3: So to, um, think it’s Steve’s question, um, how can you approach this complicated scoring? And our approach is, is to break down the question in and add a little bit to it. We add first of all, so we ask more about the program, the program itself, and we try to measure it more than the actual defects. And then the score is basically aligned to the gap of the abstract process. The gap of the abstract process can be that you don’t have enough controls. We don’t have a control for this asset, or you don’t have enough controls. Maybe you have some controls, but not enough. And a gap can be that you have controls. But these controls suggest that you should take a follow up action and then you take those those measurements and you multiply them by the importance. If you have an easy list of assets, the inventory that that shows you the assets and their priority score, you multiply the gap with the priority of the asset. And these are the places where you should address first when you are approaching from, um, from risk scoring. If you want to know what is the riskiest place is the place where it’s most important for me. I don’t have enough controls or I have a lot of alerts coming out for the controls that I’ve chosen to apply to that asset. Then it becomes kind of a very simple prioritization matrix. And in this we take into account the criticality of issues as as the scanner choose to report it. But because it is being it is being considered inside the framework of asset first prioritization, it is becoming something that is much more simpler to accomplish, simple to accomplish and and to improve on, on finding those right fixes that we can actually deliver to to the end users, to the developers.

Speaker 4: In it.

Speaker 1: Sorry. In a couple of different places that I’ve worked, we’ve had like many scores, like many risk scores. And it would just be is it public facing or private? Like only behind the firewall? Is it one of our mission critical apps? Does it have sensitive data in it? And then is there any sort of legislation or audit or compliance that apply to it and you get 0 or 1 for each one and then you get a mark out of four? And if you’re a four, you better fix everything if you’re a three. And so then we just made this little matrix and it was like, if this scanner finds these things and you are a four. So we would go like from four and then three, you have to fix everything from four and down and or actually, no, we would start at one and we would add on to it. And it sounds so simple and I know it’s not perfect by any means, but if you’re just starting with scoring, starting simple will be a lot easier. You can score an app in like five minutes if you have the right people to talk to and then you know, Oh, this is super important. Or you know what? Actually, maybe we could chill out. It just plans, you know, it just tells people what the cool lunch and learn is next month. And maybe that’s not something we need to freak out over. Yeah.

Speaker 3: Yeah, I just wanted to.

Speaker 1: Pitch in on that.

Speaker 2: So. I know. Oh, good pitcher. Sorry.

Speaker 3: Wanted to pitch.

Speaker 4: In on that. I completely agree with what Tanya said at the beginning when we were setting up our OpSec program. We’ve done exactly that. We categorized our most our assets based on, you know, is it external, does it have PII, you know, what is the business criticality of a service? And I think also it’s important to think about the impact, like if this vulnerability was to be exploited and we had an incident because of it, what would be the impact? Because if the impact is actually not that large, it wouldn’t affect that many users. It wouldn’t cost us a lot of money, even though if it’s easily exploitable, we’re not going to consider it. So as long as we can link any vulnerabilities to a certain risk for the enterprise, I think we should take it into consideration.

Speaker 1: Yes. So much. Yes, Petra. I remember once, they’re like, Oh, there’s a SQL injection in this app. And it was like 10 p.m. and I was like, okay, so the servers totally locked down and was recently hardened and super patched. It’s, you know, the, the actual user within the database is select only all the data in the database is actually public. And we’ve actually been trying desperately to promote it to the public. And so I like looked and I’m like, there’s actually very little business risk so we can just sleep on it and fix it tomorrow. And I remember one of the greybeards just losing his self with anger of just being like, but it’s as fuel injection and that’s number one on the top ten. And I was like, Well, let’s argue about this tomorrow. Go get some sleep and calm down. Um, but yeah, exactly what you said. Sorry, Just all of you have such great things to say.

Speaker 2: All right, So keeping us on track. We have three minutes, and I know other people have other stuff to do after this, So let’s do a lightning round. Last question and then sum up and provide provide more resources to everybody. And you want to take the last one. When you’re muted.

Speaker 3: Think we’re kind of we kind of discuss this point over the panel, so maybe we can we can already what the top was actually planning to ask you. How do you prioritize generally? Because it is just part of general prioritization. I think I think it came up in here that it’s part of your business, it’s part of your engineering. It’s just part of part of making software how to make good decisions. What will be like a key, key tips.

Speaker 1: Yeah. I think a couple points want to to address both this and the question here. Right. It all has to flow together. The team is no different than the development team. The development team is no different than the risk team or the considerations of the business. Right. It all has to flow together and everybody has to operate on the same time frames in the same time loops. If you’re not working on the same time frames and that means developers is running really quickly in DevOps mode and Appsync is not in that mode. You’ve got a time zone gap or a time lapse gap, and that’s a problem. You need to make sure that you’re leveraging the larger teams in your organization, like a large developer team, and you’re empowering people to do the work so you’re not trying to do everything yourself. We all know that the ratios of developers to abstract people now can be 1 to 200, 1 to 300. You’re never going to be able to keep up with the development process, So make sure that you’re part of that process in that cycle, right? Yes, correct me, 500 to 1 now. So make sure you’re part of that process and that the cycles are aligned and you’re empowering people instead of trying to take over the project. Yeah.

Speaker 4: I like that. I also like the idea of trying to select activities that scale. So for instance, I remember someone saying, Oh, like go to this threat modeling session. And I did. And they were going to use serverless for the first time. And the plan was to just start doing tons of serverless at that organization. So I was like, Yes, we’ll do this threat model, but I’m going to take the time to write like a one pager. And from now on, every project that has serverless has to do these four or 5 or 6 things. I can’t remember how many it was. And then from now on, APIs we’re going to have these project requirements. So they had all of the information ahead of time. And then we had like a little lunch and learned thing on each one of them. And doing that then prepared the developers like, Oh, we’re going to do an API. That means we have to go behind the API gateway or we have to do this or that. So they set expectations in advance and like I did that work for the one team when I did the threat model, but then I scaled it by sharing it with every single developer that worked there.

Speaker 3: Awesome.

Speaker 4: I agree as well. Also, let’s not forget the security champions again, because like, if you want to scale, that’s the only way. And get them to do the threat models and get them to, you know, to propagate the requirements that you set out after the threat. Threat modeling. I’m really happy that you’re saying that, Tania, about getting the requirements off of the threat models, because that’s what happened to us as well. We realized, okay, every service actually we have the same control, so let’s just make some requirements that we can generalize for all the teams. But you still need threat modeling, though, to kind of think about sometimes outside of the box.

Speaker 2: And also to challenge what you’ve already concluded about a good process because you always learn about new things. You always have to have a challenge in your processes, but there are always surprises.

Speaker 3: Spot on. Yeah.

Speaker 1: Perfect. So I know we’re right at time. Thank you, everybody, very much. Appreciate all the insights from from the panel and really appreciate all the questions and the discussion. It makes it much more fun for us and much more informative for everybody. I’m showing some resources here on how to get in touch with with all of us. I would also encourage everybody who participated. We are all going to be at RSA, we will be at OSC Global in October. So please make sure that you reach out to us. We’re hosting multiple parties, which I just heard when we were in the panel talking when this was starting. So ping us and come to our parties, reach out. As I said, our team will consolidate all the information that was brought up in the discussion and share all the resources that Petra and Tanya all brought up in the discussion. So you all have visibility to it. So thank you very much, everybody. If you have additional questions, feel free to follow up. You have our contact information here. You’ll also hear from us. Thank you to all the panelists. It’s a pleasure. And hopefully we can do it again very soon.

Speaker 4: All right.

Speaker 1: Having us.

Speaker 2: Thanks for having. Great discussion. Thank you. Bye bye. Bye.

Get Started
Read Bright Security reviews on G2