Biting Off More Than You Can Chew; Scaling a Small AppSec Team

00:00:00

Speaker 1: So I’m Tonya Janka. I’m your host. We’re going to talk about biting off more than you can chew. And if you work in apps, I have a feeling you really feel this. And basically throughout this presentation and basic giant discussion, we’re going to talk about how to scale a small app team. And this event is sponsored by Brite Pletka and a hero together. Okay, So next slide. So this is our agenda. So we’re going to go through a bit at of time. So you might be thinking, Oh, is this a presentation that’s just a ton of slides? No, it’s going to be a lot of open discussion. And so each one of the I’m the moderator, each one of the panelists are going to answer a whole bunch of different things and they’re not always going to agree. So it’s going to be pretty fun. So we’re going to talk about big challenges of small teams and then most of it will be proven practices for getting over these hurdles and Q&A. So if you have a question, you can put it in the chat now or as we’re doing the thing. So if the question has to do with the topic of whatever we’re talking about, we’ll answer it right then. But if not, we might save it until people take a breath and we move on to the next topic. But we really want to hear your questions. And so with that, who are we? So you already know me. I’m Tonya and I am a developer relations nerd at Brite. Then we do. Each one of you want to just maybe say a little bit about yourself and introduce yourselves because.

00:01:28

Speaker 2: We’re not going.

00:01:29

Speaker 1: To go.

00:01:31

Speaker 2: Cool. So I’m with them. I’m a product security team leader at Politica. I’ve been working at Politica for the last three and a half years and I will be talking about political debate as well.

00:01:44

Speaker 1: X developer.

00:01:45

Speaker 2: X, developer X, DevOps, x, Devsecops or whatever I need to.

00:01:53

Speaker 1: Scotty.

00:01:56

Speaker 2: Sure. Hello, everyone. Great to be here. Thanks to our partners, SHAPIRO and Politica for for the webinar. My name is Gadi. I’m the CEO at Brite have been playing around with all sorts of cybersecurity things for about 30 years. Scary to think about that at this point, but have yeah, have been running bright for the last four years and very excited to be here.

00:02:24

Speaker 1: Hi, everyone. Thanks for joining. Thanks for listening to our stories. I’m Dan Plotnick, co founder and CEO with SHAPIRO. 20 plus years in the cybersecurity industry. Also started as an engineer and that’s it.

00:02:44

Speaker 2: As I’d like to note, I feel all of them were extremely modest with their because I’ve seen what they do and they do a lot more than they said, but modesty is good. OC So next, if my slides are willing to. There we go. So Gary, is there a chance that you would be willing to speak to this slide?

00:03:07

Speaker 1: Yeah. Thank you. And I’ll try to keep it brief. Just tell you a bit about Bright. We are focused on developer centric enterprise test. That means that we are trying to help development organizations and apps organizations better collaborate to shift deployment of dust left, find vulnerabilities very early in the development lifecycle, as early as the unit testing something that did not exist before. We we invented it and created it. We are a growing company backed by Evolution Equity Partners, DNA and quite a few other investors. There are 85 of us around the world right now and really the focus of our solution is to enable organizations to find vulnerabilities in APIs and applications very early and remediate them throughout the development lifecycle. The way we see it and very tied to the topic of of this webinar and we’ll talk about it a bit later, is the app team is significantly understaffed and needs to collaborate much better with the engineering organization and the DevOps organization to be able to deliver on the promise of securing applications and APIs. And that means that you need to have the right tools to deploy scans at speed, automate them, have no false positives, and make sure that the app team is providing the governance while the developers are doing most of the work. That’s what we do. We have a bunch of very high profile customers that we work with and would love to collaborate with you as well.

00:04:55

Speaker 2: US oc. Up next we have politica.

00:05:01

Speaker 1: Yeah. So a bit about plastic. Athletica is a gaming and entertainment company. The company traded on Nasdaq for over a year now and play the guys around 15 game titles for both casual games like Solitaire and Elvis. Bingo players like that and also social games like Total Mania and WSOP and things like that. And Politica is kind of a unique company because the company acquires multiple companies, both acquirers, a lot of companies over the years. And since we acquire a lot of companies, we also acquire the technologies that they are using. So in Pratica, you can use a huge variety of technologies, almost every language and technology that you will mention. We have it in a Politica, also have around 4000 employees around the globe and and almost half of those are R&D related, so development, DevOps and etc.. So we are going to talk about how being outnumbered is not that good. So we will talk about it and you will see that we are way out on board.

00:06:12

Speaker 2: So basically, Playtech is is a software company. That’s it. It’s a software company.

00:06:18

Speaker 1: Yes. With a lot of products. Yeah.

00:06:21

Speaker 2: Yep. Well, nice.

00:06:24

Speaker 1: Now we have a pro.

00:06:27

Speaker 2: So we yes, we empower security and development teams with complete visibility into everything that they have across the development lifecycle and with actionable context to help them proactively fix critical risks. We won the RSA Innovation Sandbox in 2021. We got the cool vendor from Gartner on Devsecops and we just raised last week we announced $100 million backed by top tier VCs like Greylock, Kleiner, General Catalyst, and we have four main areas we discover. We provide you a very comprehensive software bit of materials across all the application components. We help you remediate with context by tying every risk to the code owner and trigger a remediation workflow. And we measure the mean time for remediation and the coverage of all the OPSEC tools and your DEVSECOPS maturity. That’s a pure.

00:07:33

Speaker 1: No, it’s cool. I like I like how they have the cool vendor like award. It’s like you guys are cool.

00:07:41

Speaker 2: I’m wondering, Don, when you say $100 million, do you have to say like Dr. Evil 100 million?

00:07:48

Speaker 1: It’s it’s 135 million total. So it’s more than. Yeah.

00:07:56

Speaker 2: Oh, my gosh. That’s incredible. So I’m really glad all of you are here. This is a topic that I get asked about constantly, like the big challenges of apps, like teams, especially small apps, like teams working out big companies. And so all of you have faced that, and I’m pretty excited to hear what all of your thoughts are. And so. We all know that this is an issue which one of us wants to talk to the about how there’s disproportionate resources. Who of us wants to cover this?

00:08:29

Speaker 1: So I’ll take that. So I can also mention another thing that I didn’t mention earlier is that I was the first member of the security team, so I was kind of alone for a while. And being alone versus a huge number of developers and an R&D group is very challenging. And I think that the challenge is to find how to even start by doing something. And I think that the best way for me to start a challenge like that is, first of all, to start with the numbers, to understand what I’m facing against. And numbers could be various things. It could be things like understanding the organizational structure and maybe I can use another group or subgroup of people as my multipliers. And what we did at POLITICA is to use architects, the regular software architects that are responsible for all the architecture of the software, including all the functionalities and the non functional aspects to also cover the security aspects. And what that means is that we are using them, for example, for triaging new security vulnerabilities, that we are getting to train the developers on some areas. And although we are going to.

00:09:47

Speaker 2: Talk about that.

00:09:51

Speaker 1: Sounds like the champions. Yeah, so that’s the difference because we are looking at the architect as security champions by default, so they don’t have the option to choose whether they want to be security champions or not. And to be honest, it worked pretty well. I think that they are also leveling up and getting some value from being security champions out of the box. And also we are getting the multipliers that we wanted across all the business units. So that’s a nice thing.

00:10:21

Speaker 2: Yes.

00:10:23

Speaker 1: One quick question for you that I know you and I talked about in the past. Was it hard to get the architects involved and excited to be part of this or did they volunteer? How did you convince them?

00:10:38

Speaker 2: Okay, So actually we started by thinking how we can start and overcome the challenge. And then we had like kind of a offsite meeting with all the architects across the globe. And I was there and decided to take a few hours to present what we are doing, what our roadmap is, and to just discuss the plans and to see how we can engage them to do that as well. And I was amazed to see that they all wanted to be part of that. So they didn’t. No one said that they don’t want to participate in such a thing. And it was like a grid that out of the box. Software architect is also responsible on the security of the software is saying that they’re responsible for the scalability, maintainability and all the other duties that we have on software development.

00:11:26

Speaker 1: But this is not common. Like you have your I know you for many years and I know that you have a magic stick. And when you are doing that, then then you’re I don’t know what happened, but but they’re actually listening to you. I’m trying. If you can help the people here on the call to if you can share this magic, because it’s not common when when I’m formerly I was a GM at Microsoft for engineering and it was hard for me to get these the the the request from security because I had to deliver features. So now I need to decide why should I prioritize a task from Rotem versus delivering features to the business which actually brings more money to the company? Yeah.

00:12:24

Speaker 2: So I think that first of all, as an XT developer, as we said, I kind of know what they’re doing on the day to day job, so I’m not requesting them. And this is something that is very important for me and we’re going to talk about it maybe a lot today, especially with Gadi and about how not to overwhelm developers and architects with false positives and noisy alerts. And I think this is one of the bad things that security people sometimes do. They are like going to the software engineers and telling them, okay, you have a vulnerability and you have to fix it by tomorrow. And then they are getting asked, why do I need to fix it by tomorrow? And the answer is because and I think that I’m explaining to them the rationality behind that. And I’m also not giving them things that I don’t believe that we need to fix. So, for example, we are working with context and you and I will talk about it today.

00:13:20

Speaker 1: Yeah, no, no, but but I think what you just said, this is the magic. Don’t give me as an engineering manager, I don’t want to get the list of 100 alerts or whatever, and then I need to do the hard work to go and triage and make and suddenly understand that 90% of it is false. But let’s let’s move on and talk about this this later in more detail.

00:13:46

Speaker 2: One final sentence, because what you said so. That’s right. I’m I’m doing it. Triage for them and with them, I’m not giving them to do the triage. And this is maybe something important because a lot of organizations that I saw over the years are giving the R&D departments to do that research to understand whether this vulnerability affects them or not. And we are not doing it. We are doing it by ourselves and not giving them all the spam. We’re giving them all the things that matters. So that’s an important thing to say. Yeah.

00:14:17

Speaker 1: Awesome. I’m going to speak to this side. I think everyone knows this, but talent is scarce. Basically, it’s really, really hard to hire qualified security professionals. It’s difficult to tell who is and is not qualified because just because someone has a certification doesn’t mean they necessarily know what they’re doing and vice versa. Lots of people without certifications can be extremely qualified. I don’t have any certifications, but I wrote the book about OPSEC, so it’s really hard for employers to find and retain talent. Does anyone else want to comment on this? I feel like we all agree a lot.

00:15:00

Speaker 2: We are all in agreement here. Like.

00:15:05

Speaker 1: Okay, let’s move on.

00:15:06

Speaker 2: Like literally on on a daily basis, our customers are asking me, Hey, we need your help to hire a product security engineer, OPSEC. Engineer, Just help me what I can find. It’s been months. So, yes, I feel that.

00:15:26

Speaker 1: We’re even seeing the other side of it of can we use your resources as embedded people on our team? And like, we’re a software company, we have partners that can help you, but that’s definitely a big challenge.

00:15:41

Speaker 2: Well, next week, Braid is doing a webinar with Trace three, and Trace three does that. So maybe we could do some connecting of people and everyone watching. If you want to hear about that Trace series next Thursday. So next we have well, did you want to talk a little bit about how risks are increasing?

00:16:01

Speaker 1: Yeah, I think there are multiple parts to to risks are increasing. Right on on one hand, there are a lot of bad actors out there that understand that the the easiest way for them or conceptually the easiest way for them to actually make money is by going after larger organizations that have vulnerabilities. That’s one side of it. The other side of it, though, is and all of them touched on this is most organizations are developing and deploying faster and faster and faster. And if you’re developing and deploying faster and faster and faster and you used to release once every three months and now some of our customers are doing 100 releases a day. So if you’re doing 100 releases a day, but your application security test cycles are once every couple of weeks, that means that you’ve done a few thousand releases between two security cycles and you’ve got a big gap. And that’s another key reason for the very significant increase in vulnerabilities because OPSEC teams that are small, as we said, just can’t keep up and we’ll talk about what to do about that here. I’ll give you one second. Just to add one last point. The other thing that we’re seeing and that’s highlighted here on the right hand side is the huge increase in use of APIs. And the huge increase of use of APIs means that there is a lot more attack surface out there that in many cases people don’t even know about.

00:17:38

Speaker 2: If I may ask. I for me adds to two more things. One, from my experience, customers don’t even understand their attack surface. This is one, they don’t know what they have in their code base. And second, and going back to what Dropcam said earlier, if you have 2000, 3000 developers plus acquisition plus like so many technologies, different programming languages, the velocity increased. I think this is the problem that you have so many different technologies that you cannot keep up with. And what attackers are looking for is complexity. Where you have complexity, you have breaches. This is very, very simple. So we will talk about the visibility and the attack surface. But I think this is one of the reasons why we see an exponential growth in the risks. And application security is growing very, very fast.

00:18:51

Speaker 1: Yeah, I think there’s one other stat, which surprisingly enough is 86%, but as well. But I find it fascinating where 86% this is from IDC from last year, 86% of organizations are knowingly releasing vulnerable applications and APIs because by the time they find these vulnerabilities, it’s too late to remediate them. To me, all that says is that if it’s 86% that are knowingly releasing it for 14% are unknowingly releasing it because everybody’s releasing vulnerable applications. And that’s that just highlights the enormity of this problem.

00:19:31

Speaker 2: I also maybe add something, if I may, on this side to what it does it because some companies are rushing to adopt some tools, for example, static analysis tools before they even know what they’re facing, what is their attack surface? And I think that this is one of the downsides of those companies, because as an application security engineer and usually, as we said, we don’t have a lot of those, you are one versus, I don’t know, under it. So you must do the prioritization in a good way. And I think that starting from static analysis, for example, because it’s easy to implement, isn’t a good thing. Maybe you need to start from the most right side of the SDLC and then to understand what is your attack surface, because this is what attackers will look for. They won’t look at your code, they will look at your external attack surface. So start with that. Start with the same tools they are using the same, I don’t know, open source or not open source tools that they’re using and cover yourself from the most right side before you even considering to add another internal tools.

00:20:32

Speaker 1: I, I have so many things to say, but I’m preaching this message for years. Why? Why? Starting with a tool that will generate a lot of noise and before you do, you even know what you have. And but let’s wait a few slides and dive into it later.

00:20:59

Speaker 2: I am nodding my head a lot, agreeing with all of you. This is good. So now we’re going to talk about solutions. So if you’re at this webinar, you know there’s problems. That’s why you’re here. If everything was awesome, you wouldn’t need to learn how to scale your team better. Your team would be huge and awesome and everything would be totally in hand. All your apps perfectly secure, but most of us are not in that state. So we’re going to talk about people, processes and technology that help basically scale your team so you can do better, like have a higher security posture, more reliable, make sure every single release is secure, etc.. So let’s so I’m I’m going to start with this slide. So I work at Right Security who acquired my company. We hack Purple earlier this year and what we had Purple did was tons of training about secure coding apps at Cloud Security Infrastructure Code, ET cetera. That is our jam. And so I want to talk briefly about if we could scale our training and scale our knowledge. And so you probably know all these reasons why you want to train your people, but I just have a few tips, like if you can do on demand training or different types of training that can work for your employees. Like if you have hundreds of employees, not all of them necessarily want to take an entire week off work to learn stuff. So you might want to try different types of training like on demand or like a little bit each day or some of them go offsite. Sometimes you bring a trainer on site, but also job shadowing and mentoring, like hire that junior OPSEC person and put them with someone like Rotem. They’re going to be an intermediate person in like six months. Consider recruiting a full time security coach to help the whole team go to the next level. There’s also subscription services and just basically the training is exploding everywhere. But one thing I really want to get across is thanks to right security acquiring. We had Purple earlier this year, all of our trainings free. Now we’ve even added more courses. So if you want to go check out the absolutely free community and absolutely all free courses and events go to community dot. We have purple dot com and join the other six and one half thousand of us that are hanging out and being nerds together. I feel like that’s enough because I’ll just go on and on and on. And scaling your team with knowledge is just one of the solutions. There’s a whole bunch more and so. Who wants to talk about developing a Champions program? Because I have a feeling, yeah.

00:23:31

Speaker 1: I will say a few words, but again, Rotem actually implemented it. So. So I think it would be great to hear his thoughts. I’m just saying that you cannot be successful in application security without the security Champion program. And there are different variations for different cultures, for different companies. But the essence is that you cannot scale without a security champion program to make. Just five things that we learned from our experience is that it’s so obvious you need to define success, what success means, What are the KPIs who say, Hey, we train the people we gave them, provided them tools, but it’s good, it’s working. Did we reduce the risk? Did we increase the velocity? I don’t know. It’s even possible or not. But but these are questions that you need to ask yourself and define based on your culture, based on your company. We can help, of course, but you need to define success. Second, you need to identify 3010.

00:24:51

Speaker 2: Could you tell them what security champions are? Because we’re just assuming everyone knows and some of them might not really fully understand.

00:24:57

Speaker 1: So it’s not the Bible, but but it means that you have people as part of the development teams that are responsible for security. You can say they are 70% app engineers inside the development team and 30% developers. And you can play with with with the percentages based on what you think is best for your company. But they are actually responsible for identifying, fixing, prioritizing the vulnerabilities, running threat models, training the developers, talking about security as part of the day by day job. This makes sense, Tanya.

00:25:56

Speaker 2: Absolutely. Absolutely. I also want to add, sometimes it’s just the person that’s the absolute most excited about security. Like if I can have a junior person who’s really, really, really excited versus a senior, extremely knowledgeable, knowledgeable developer who is like, I work late every day, I don’t have time for this crap. Please go away. I’m going to take the junior person who’s really excited over the senior person who doesn’t have any time for me.

00:26:24

Speaker 1: I have a lot of things to say. I think it in passion is a must and passion is a must, regardless to security champion. If you want to be successful in life, you need to to have passion to what you are doing. But if you are bringing a junior person with a passion and he or she cannot actually embed the process into the development process or cannot take a task and add it to the next sprint, then it’s like it’s meaningless. Like like you are wasting your time. And because eventually you need to make sure these tasks will be part of the day by day sprints, whatever methodology that you are using so you can see results. So if this person can actually got the mandate or someone empower them, which is point number five, then the answer is yes. I don’t care if you are a senior or a junior or whatever, you need to make sure that you are doing your job and and you can influence the the the planning of the releases, the features and the vulnerabilities. I have a question as well.

00:27:52

Speaker 2: Can you maybe elaborate on how you can help to identify the security champions? Or what is your approach to identifying the security champions in the first place?

00:28:02

Speaker 1: Sure, sure. So again, in apparel, what we are doing is as part of the platform, we are assessing the knowledge and the activity of developers. So you can go and filter and say you want to get visibility and say, I am a 90% Java shop or I am whatever, go shop or other. And then you can filter and say, Show me all the active developers that are dealing with authentication or dealing with authorization or removing secrets from the code or other things. And then you can identify them in an automatic manner. Because if I am one person against 200 developers and I cannot track all these 200 developers and understand what their knowledge. Now we help you identify them. Now you need to reach out, but you need to build a plan and incentives like give them incentives. Why they should do that. As I said, you have the magic and I think everyone needs to learn from from what.

00:29:25

Speaker 2: You said, the magic stick before. And I just imagine I’m running around with this ticket.

00:29:31

Speaker 1: With the stick, and he’s doing the magic. But but I think he told us what he’s actually doing and he’s not throwing risks on the development team. This is the first thing if you’re doing it like, Hey, this is what I got from the tool and this is what you need to do, you are doomed. You will never be successful in your company and you you will have clashes or between the security, the product security and the development team. So I think this is how we help our customers identify the security champions. But they need to take it one step further. You need to build a relationship. You need to bring someone like Tom, like Rotem, that actually understand the language of developers, what they are doing, how they are thinking. And then you need to continuously provide them training and guidance. It’s not one time, Hey, I trained you. You can fix a SQL injection or open source dependency or secret. Great. Go bring results. No, this is not the case. It needs to be a culture that you are building inside the company. Provide them visibility to how you prioritize their tasks and help them or empower them to prioritize the next ones so they don’t rely on. They will not rely on you as a single point of failure. And and and this is again, goes back to the success criteria because you want to see that even without you, they can actually do the work and fix thing and reduce the risk without slowing down the process. So this is my $0.02 on on the security champion program.

00:31:23

Speaker 2: I also have some.

00:31:25

Speaker 1: One.

00:31:25

Speaker 2: Of those questions in the chat. So after you wrote them, I’m going to go with the questions in the chat for all of you.

00:31:31

Speaker 1: Okay. So I just want to give also the small letters. So people need to know that running a Security Champions program is not plug and play. And if you are planning to have like a plug and play solution, this is not the case. This is a community that will need maintenance and support and a lot of love. So if you can give that, don’t start with that. That’s it.

00:31:52

Speaker 2: Yes, I love that. Rotem So in the chat someone says, I love it. At my last company we passed on an experienced guy in favor for an excited new guy, and it was definitely the right choice. And then Sarah adds, I feel like security champions are sort of like Scrum Masters are for Scrum and Agile. They coach their team to become autonomous on holding security and handling security within the secure system development lifecycle. And then.

00:32:23

Speaker 1: I totally.

00:32:24

Speaker 2: Agree with someone was asking if there’s a framework for security champions and we published some blogs on the blog. So if you go to bright slash blogs, we have a series of security champions with a six part recipe how to recruit them, engage them and train them all up and get them going. If if Amanda could put that in the chat that’s on the we have. Purple blog and on the Bright Security blog.

00:32:51

Speaker 1: But we have it.

00:32:53

Speaker 2: We have it in the last slide as well. Tanya. We have links to all the content.

00:32:59

Speaker 1: Perfect. Awesome. I feel like Gaddy reads my mind sometimes. So we have one more. Oh, my gosh. There’s just so many questions about champions. Someone was saying they got good results based off of the champion’s framework from Sands Security Awareness Maturity Model, in case anyone wants to see that. Are there any last comments on security champions? Like there’s so many things in the chat about how people basically just think that they’re awesome and this is great and people really liked all of your points. I’m going to I’m going to try to just push us on to the next slide because I don’t want us to lose time because we have so many comments. I feel like people really like this. So increasing ownership across the organization. I was supposed to speak on this slide, but I’m also happy to open it up to the whole floor. I think we all know that we need developers, we need operations, we need the entire I.T department to take ownership and doing their job securely. And it’s our jobs to support them for sure. Does anyone want to add any pieces to this slide?

00:34:10

Speaker 2: Nick, we.

00:34:11

Speaker 1: We talked to this. There’s a lot more to get to.

00:34:14

Speaker 2: Yeah. I also feel like we all already said it.

00:34:18

Speaker 1: Yeah, but just one one word, few words. But I think that it’s it’s a process where CIOs and CTOs needs to understand that they also have the ownership for security, as Rotem said. I’m just repeating what he said. But it needs to be at the higher level, not only at the team level. Rotten without an executive backing him up. He cannot be successful in his job. And that’s I think this is the key.

00:35:00

Speaker 2: Yes, I agree. And we should add to this slide engineering, just all of it. I completely agree. Done. So up next, focus on software building materials. And I believe that if Dan wanted to talk on this one.

00:35:16

Speaker 1: Sure. Sure. There is tons of buzz around software supply chain. From the moment the government published this doc, whatever they call it. But. But I’m saying, to make a long story short, we need an accurate inventory of everything we have across the software supply chain. We need to understand, for example, how many APIs we have in the source code, how many open source dependencies, how many containers, where do we have sensitive data? Which languages do we have? How many external third party SDK we’re using? How many cloud resources, everything from the code, How many source control managers, how many repositories, what’s the permissions, how many deployment pipelines we have? And I can go on and on and on and on. What I’m trying to say is and do not start with scanning tools before you know what you have. What you have will help you understand what you need to protect. First, I can share and I’m working with hundreds of customers. They are going spending tons of money on, I don’t know, a SAS or an SIA, and then they get 15,000 alerts and then they are overwhelmed. The security champions are overwhelmed and they don’t know what to do. Just filter and say, Show me all the active repositories that holds sensitive data that are high business impact, that are exposed to the Internet, that has APIs, then and then buy a tool and enable these tools on these specific repositories. And I think that software bill of material will be a standard in the next five years for procurement to if you want to sell me a software, you need to show me what are the ingredients. That assembled your product. If I can’t see the ingredients, I’m not going to buy. It’s the same as I don’t know what I’m drinking today and I’m buying from the grocery. I want to understand what our if you have sugar, I don’t want you to eat sugar. So it’s the same concept and you will need to embrace it more and more and more.

00:37:54

Speaker 2: I feel like if you don’t know that you have it, you can’t be certain that you are protecting it and having a complete application portfolio, having a complete inventory and knowing every single thing that you must protect is the first step. I totally agree. We already knew we would agree on this one. Everyone was like, Yeah, inventory’s pretty darn important.

00:38:15

Speaker 1: You see, we all in agreement. But eventually in, in, in reality, no one is doing it. I think it.

00:38:26

Speaker 2: Done. You’re touching on a really important point. I don’t think there’s anything that we are saying in this webinar that that somebody disagrees on. The problem is having the right people process technology, which is what Tonya touched on earlier, to actually enable that. Because if you don’t have the right people process technology, then then you’ve got a problem. And that’s why it’s important to have all three in place and that’s why we’re talking. Otherwise all of us would be out of a job.

00:38:56

Speaker 1: I agree. I am not concerned about there not being security jobs soon. Okay. So did you want to touch a little bit more on spam or do I feel like.

00:39:07

Speaker 2: We we can move on. We have more interesting things to talk about.

00:39:14

Speaker 1: So let’s talk about choosing the right tool for the right job. I was kind of hoping that maybe Gandhi would speak to Dast and maybe do the right side, and then.

00:39:25

Speaker 2: Perhaps it’s going to be an interesting discussion.

00:39:29

Speaker 1: Well, I think we have to slide. We have two slides that are tied to this, right? We have this one, and then the next one goes into more detail. This one is more of a of an overview that that we all we all agree on, that you have to deploy the right solutions in or throughout the entire life cycle. And whether you’re looking at the code side of things and you’re looking at software composition analysis or static analysis, whether you’re looking more on the discovery side of things or whether you’re looking at the compiled application. And the compiled application can be in various stages. It can, as I mentioned earlier, it can start as early as unit testing and it can go through the production. You have to make sure that the solutions you have and are deploying actually support the strategy that you have of leveraging a very small app stack team and a much larger development organization. So I think that you have to take that into consideration and everything that you do. And in the next slide we’ll get into, well, what do you need to look for in each of these tools to make that happen? I’m sure that automated done have more to say about this brought them.

00:40:43

Speaker 2: Go ahead.

00:40:46

Speaker 1: So I think that looking at the full SDLC is a very wide thing and eventually you need to be creative. And some of the things that I did here, Athletica, is to engage with the department, for example, because working with QA makes sense, like we are doing the same thing, that they are doing exactly the same things, but we’re doing it like two different departments in two different methods. And sometimes we’re even using two different tools for the same purpose. For example, they could use some kind of static analysis tool already for doing code smells or finding unused code block and things like that. So if you will talk with the other departments in your company, you will understand that you can work together in cooperation and do some things that won’t even require you to pay even one extra buck on on another tool. So use the things that you already have inside. This is one thing. The second thing is that you can also use the resources that you have in another creative way. For example, running an internal bug bounty program. And this is also something that we did in ATHLETICA since we have a huge R&D group, we created an internal bug bounty program that every employee in the company can report on a security vulnerability and get rewarded for that. And we were amazed to see how many critical vulnerabilities we got through the internal bug bounty program. At first we were like kind of spectacle on. We will probably get a few loads or won’t get anything, but eventually we got crazy bugs out of it. So if you have a big R&D group, you can do something with them internal bug bounty or even some kind of contests or other things like that. And on the most right side. And then I will maybe let someone else talk a bit is that again, you need to think as an attacker. In my opinion, you need to think what will attacker try to do when they will approach your organization, what they will look for and how they will look, how they will do that. For example, if you have a lot of open source tools or you have a huge attack surface on GitHub. So maybe you need to protect your public repositories first of all. Or maybe you need to protect your web application. If you have a lot of microservices, maybe you need to focus on the API gateway or other things like that. So first of all, start by mapping again, all your technology. Yeah, the inventory. And if you are already using the static analysis tools from the QA guys, why don’t you mix that with another tool that will give you the context right then and will give you the ability to know, okay, this specific API with a critical vulnerability is also exposed outside, so you should start with that.

00:43:45

Speaker 2: Yeah. So Rotem is actually referring to a hero, but so, so. So what I want to say that this this was the problem that I was facing as a practitioner. And what you can see here, a SOC or a SPM, all these buzzwords, application security, orchestration and correlation or application security posture management, basically analyze the code, understand the application architecture much better not to find vulnerabilities, but to understand the relationships between all the connections between the components like API is connected to a data model that exposes sensitive data that uses open source dependency in a high business impact application. Now, on top of that, you can augment the alerts from SCA, SAS, Das and others and you can prioritize it better with all the context in an automatic manner. So I think this is where or how we see the the tools that you need to do, like the tools, the right tools to the right job. But I’m saying it that before knowing what you have. Again, it’s it’s I’m repeating myself. But for example, I can give a concrete example if you are 90% Java shop, so you have SAS tools that will not be suitable for the job. You need a specific SAS tools that is better in Java or other tools based on the technologies, based on the architecture. Most of these tools are on the left side, are not suitable or was not designed for a microservice architecture. So you need to make sure they are providing you the value based on your architecture, based on your assets.

00:45:52

Speaker 1: I think, Tonya, we can move to the next slide because it is already jumped into making sure that you choose the right tool. And what does that right tool?

00:46:01

Speaker 2: Sorry.

00:46:02

Speaker 1: All good.

00:46:03

Speaker 2: Everywhere. Awesome. Awesome. Gary, do you want to kick us off on this slide and then we’ll go to Idan or Eden and also Rotem or how do we want to do it?

00:46:16

Speaker 1: Yeah, I think he done already kicked us off on this slide. Right? The goal is you have to make sure that you are choosing the tools that are appropriate and can do what you need to do, and you need to make sure that whatever solution you are going to deploy, it fits into your strategy so it aligns with your people and your process. If you try to choose a tool and then fit it in and it’s a it’s a square and you’re trying to fit it into a round hole, it just won’t work. And there are some basic things that with every solution that you look for, you need to make sure that it has, and that aligns with the top down strategy. Then it’s making sure that you can actually shift it left. And there are many solutions that have been out there for for many years in the apps world, but they were never built for a shift left strategy. They are much more monolithic. They don’t have the ability to deal with microservices. They don’t have the ability to break down the targets that you’re going to scan into many different parts. They can’t deal with APIs as well as they should. They have a lot of false positives and they don’t add the validation. They are all good for a world that is not looking to leverage the entire organization and rely on the engineering. So you have to make sure that when you are evaluating the solutions, you put together the requirements around making sure that they can actually be deployed effectively. Scans can be run early to both identify what your attack surface is. As my esteemed colleagues mentioned, and then when you know what that attack surface is, be able to find vulnerabilities and guide effectively the development organization on how to remediate those vulnerabilities because just finding them is not enough.

00:48:11

Speaker 2: I agree completely. And for anyone who’s really beginner, who’s in the audience, when we say shift left, what we mean is start security earlier in the system development lifecycle. So when you’re making software, you know you have a kickoff meeting. A security person should be there when you’re gathering your requirements, there should be some security requirements. And when you’re coding, basically you can start using security tools right then. And so we’re not saying only do one step at the beginning or the end, we want to be there the whole way through. I think as the shift everywhere, like start at the beginning. Be there all the way to the end. Even when you’re maintaining your security, when you’re maintaining your software. Again, security continues. Does anyone else want to add to this slide? Och.

00:49:00

Speaker 1: No, I think we can go. Yeah.

00:49:03

Speaker 2: So I think that this slide was basically made for Gatti.

00:49:09

Speaker 1: Yeah, I think I think it ties into the the the last point. Right. People are wasting time on false positives. They are focused in the wrong places. You’re trying to give developers solutions that are not fit for developers. They were created for the app team and if they were created for the app stack team, they are translating the information incorrectly. For developers. Solutions that were created specifically for developers are looking at things differently. One, they have a built in ability to eliminate false positives. Two, they provide proof of vulnerability. If a developer we all know likes to look at stuff and see, Oh, here’s a screenshot, or here’s the information that proves to me that this is a vulnerability and they give remediation guidelines. We talked about SCA and say usually it’s relatively easy. You can just say, Hey, upgrade to this version, which solves this issue in static analysis and dynamic analysis and others. You have to give them guidance on how they can resolve the issue. If you don’t do that, you fall short.

00:50:18

Speaker 2: I agree. I think I suspect that most of the people in the audience also have suffered from fatigue, alert and have suffered from finding false positives with certain types of tools and then having their software developers lose faith. I think that we all know that this is a big problem. And if the panelists don’t mind, can we go to the next slide? Because I know we have a lot more to say.

00:50:41

Speaker 1: Yeah, and we have only 6 minutes.

00:50:44

Speaker 2: Yep, I.

00:50:44

Speaker 1: Know.

00:50:46

Speaker 2: So if we want to get contacts to identify material changes, either it then or Rotem, did you want to chime in on this one?

00:50:55

Speaker 1: Rock n go at me.

00:50:57

Speaker 2: Okay. So I think that we already covered like, pieces of that. So you need to work more with the context to understand if something is really vulnerable and if it even matters. And I think that one of the things that we did ill around the penetration testing activities is to work in a more agile way. So moving from traditional penetration tests and doing a penetration test per application or product once a year is not that good. You’re not covering a lot, you’re paying a lot for the penetration test, but eventually you’ll you might be missing the same vulnerability that got released a day after. And as a software company, you were releasing like a few times a day, if not more than that. So what we did is to be led by risks and not by vulnerabilities. So, for example, if I’m detecting a material change that someone puts pushed something to production and this is publicly exposed and it has some missing input validation, then I want to give it as a challenge to my penetration tester to make sure that we are covered and that there are no issues there. We could even determine on some cases to stop it in a more left in the SDLC and in the pull request and say, okay, I want the software architect to take a look on that and decide whether we can move on or not. So moving from looking at only vulnerabilities to some kind of leads and looking at the risks is also something that you can do and you can move faster.

00:52:34

Speaker 1: And this is why I have not zero words. We can like I, I think this is an innovative approach. Rotem is a real pioneer in this approach, and I’m trying to convince others to go and follow him. And and I think this proves based on KPIs, this proves the value. And and it’s just it’s hard to change the entire industry. That was said, Hey, we have SAS, let’s deploy SAS and we solved all of our problems. And then they got the alert fatigue and now there is a new approach. Yeah. Yeah.

00:53:23

Speaker 2: We have so many questions in the chat. I’m going to go to the next slide specifically so we could try to get all the way through the content because I know a lot of people are really excited. And so if we can stay on top of apps like Trends and News, we’re more likely to do a better job. And also, like Rotem and Dan were just saying, knowing what the bigger risks are to our specific organizations and prioritizing the work that we do based on that. So for instance, if you’re a company that sells online widgets and you have like 400 customers, you don’t have the same risk as McDonald’s or Disney or Walmart or Amazon. And so. Keeping on track of trends via podcasts, reading tons of blogs, or also like online media will help you stay on track. There’s also a lot of newsletters that you could join as well. But I actually want to hear a little bit more on the next slide because we have so many questions in the chat, like really, really, really good questions. So one from Sarah was which security tool do you recommend using in a CIC pipeline for efficient shift left vulnerability detection? I’m assuming with this audience that Sast is a no go or with this panel. This last is a no go.

00:54:47

Speaker 1: So that’s maybe that’s fine because.

00:54:52

Speaker 2: So much.

00:54:53

Speaker 1: So I.

00:54:54

Speaker 2: Think where is the point where where is the fight? Where is the adrenaline? I.

00:55:02

Speaker 1: I think that the answer is not that we are saying and by the way, also, Randi, that I don’t think that we are saying no to sassed. We are saying that you need to customize the tools or select the tools that you are using according to your organization, to the amount of people that you have in your team, to their capabilities. There are a lot of factors when considering to add a new tool, and if you are using static analysis tool or dynamic analysis or whatsoever, do it in a wise way. Know what you are getting into and know that you have also the context to handle that and the people to triage it and not throw it on the R&D side. So this is my answer to that.

00:55:41

Speaker 2: Because we only have one minute left. I was wondering if each one of you could give a key takeaway from this presentation. And one of my key takeaways from after listening to all of you that I’d want the audience to remember is there are a lot of ways that you can scale your security team. If I were you, I would make a list from all the things in this presentation and try each one and see which one works the absolute best for your organization, because it doesn’t matter if it works best in mine. It only matters if it works best in yours. And I feel like these three panelists, basically they gave at least ten different ways that you could try to do it, and so could we go down the line. So I see Gabby next in line. GATI Is there a key takeaway that you wish the audience would think about?

00:56:28

Speaker 1: I think it’s really about aligning your your people process and technology. And if you’re trying to leverage additional people in the organization, you have to make sure that you deploy the correct tools and ask the tough questions. Don’t just go with the legacy tools that have been around for 20 years because many of them are just not a fit anymore.

00:56:51

Speaker 2: I agree. Iddon would you like to add?

00:56:56

Speaker 1: Same mantra. Mantra like, I think you need to know what you have to be able to be successful. And this is the fundamental phase of building an accurate inventory that will constantly updated for every change. So you will know your attack surface. So you will be able to think like an attacker and trigger the right processes. To the right people based on these material changes and based on these risks and not vulnerabilities. With all the context, this is my thing.

00:57:39

Speaker 2: Awesome. Tim, would you like to give the last key takeaway we hope the audience remembers?

00:57:45

Speaker 1: Sure. So one, be creative. Look what resources you have in your organization and the processes and try to see how you can engage with those that are already existing or that you can create without affecting the organization in a drastic way and try and fail, but have the safety net behind you. And I believe that crying and failing is good and this is the Agile approach that we are all believing in in software development. So let’s do the same in application security.

00:58:13

Speaker 2: I love it. I absolutely agree with all three of you. I think that was I wish I could keep you for two more hours. Apparently, that’s not appropriate if I just, like, have the the webinar never end. But I am hoping that the two of you come back and are on another bright webinar at some point, because I feel like there’s a lot more to say on this topic. Thank you to everyone in the chat. Thank you for your zillions of questions. They’re really great. We’re going to save them and potentially write some blog posts out of that content. Thank you so much to all three of you for being on this webinar with me. It would be really dull if it was just me.

00:58:51

Speaker 1: Bye, everyone. Thank you very much.

00:58:54

Speaker 2: Thanks, Tanya. Thanks. Thanks all the time. Thanks, everybody.

00:58:57

Speaker 1: Bye bye, everyone. Thank you very much for joining.