Episode 514: Vandana Verma on the Owasp Top 10 : Software Engineering Radio

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Priyanka Raghaven 00:00:16 Hello everyone. This is Priyanka Raghaven for Software Engineering Radio. Today we’ll be discussing the OWASP Top 10 with our guest Vandana Verma. Vandana is the Vice Chairperson, OWASP Global Board of Directors. And she also has experience ranging from Application Security to Infrastructure Security, Vulnerability Management, Cloud Security, and now dealing with Product Security. She currently works at Snyk. She has various initiatives that she contributes to, which includes diversity initiatives like InfoSecGirls and WarSec. She’s also been a key influencer in these peers, but apart from that, she’s a regular talk show host kind of a thing. In the OWASP spotlight she’s also been at various conferences, such as Black Hat and the OWASP meetups. It’s great to have a conversation with you Vandana. We’re really looking forward to this show. Welcome.

Vandana Verma 00:01:15 Thank you so much. And I’m really glad to be part of the show Priyanka.

Priyanka Raghaven 00:01:20 Vandana, we at Software Engineering Radio, we’ve done quite a lot of shows with respect to application security in terms of secure coding practices for software engineers. We’ve also done API security, network security. We’ve also done a show on Zero Trust Networks, but we’ve never really done a show on the OWASP Top 10, which is like the mantra for most software teams. So that’s why we decided to do this show. And of course, you’re the right guest for this. Before we start off, would you be able to give us a definition or a way to explain what is OWASP to our listeners?

Vandana Verma 00:01:57 Absolutely. So OWASP is O-W-A-S-P. It’s one of those communities which is spread across the world. And to precisely say, it’s more around application security. It’s a nonprofit organization trying to bring forward application security and work towards to improve the security of the softwares. Through community led Open-Source software projects, hundreds of local chapters worldwide, and many people getting involved in it. I personally get involved in a lot of things that are OWASP. So, it’s one of those places where you can learn a lot. If you don’t know anything about application security, this is the place to go. Just go to Project Section, you can check out many projects from OWASP or web testing guide to whatnot, and you find everything there. If you want to connect with like-minded people who are talking about application security or network security, or even Kubernetes containers, this is the community for you. You can look at the chapter near you. So probably it’s a place where you feel warm, connected. That’s in a nutshell OWASP.

Priyanka Raghaven 00:03:05 Great. I think I can personally vouch for that. I think that’s one of the places where I also met security enthusiast at the local Bangalore meetup. The other thing I wanted to ask you is OWASP Top 10. How did this idea come about to, you know, list the top 10 most common areas that one should focus on? How did that come up?

Vandana Verma 00:03:26 Right. So when we talk about application security, it was booming up at that time. We were getting a lot of bugs, even there was a cross-site scripting, which was reported in Microsoft as well. So that’s how excesses came into picture. It didn’t become CSS because style sheets were all already there. But then there were efforts which were needed by the people, for the people and for the community. And that’s how some people gathered together and came up with something called as OWASP top 10. Which is open web application security project, top 10. Which are top 10 risks in the web applications. And they keep changing every few years. And that’s how the idea came in where, wherein those people said, oh, we need something which industry can actually look forward to. If I understand something in certain way, you might understand in a certain other way as well, because we have different perception of things. That’s why people said, we need to have single perception of the top 10 risks. And those top 10 risks are not just top 10, but there are underlying vulnerabilities associated with them underlying risk associated with that. So that’s how it culminated.

Priyanka Raghaven 00:04:40 Okay, great. And also one of the things I noticed is that the OWASP top in seems to be getting updated like once in four years, I don’t know because there was 2021. And before that there was a 2017, I think, before that was 2013. So is the frequency once in four years, or do you aim for something quicker?

Vandana Verma 00:04:59 I feel that it was supposed to be three years and due to unforeseen circumstances, the frequency gets delayed sometimes. So the top 10 for 2020 was supposed to be released in 2020, but they mentioned in 2021 because of COVID because of people not getting the data. So this top 10 list is not just like you and I wrote it, or the leaders wrote it. No, there’s a data that’s get gathered from a lot of places, from companies, from the vendors, from everyone. And then that gets processed by machine learning. And that’s how the top 10 comes into picture. And even that’s even being shared with the community toward that process is a very exhaustive process. That’s why in 2020, we could not gather the data, and pull up data to come up with the right list. And that’s how it came in September, 2021 when OWASP celebrated its 20th anniversary.

Priyanka Raghaven 00:05:59 Oh, interesting. Very interesting. In fact, I was going to ask you, what are the sources of the data? And you just answered that. I’m also curious, like how does that, do you give a survey out to all the companies? And then they fill that up and say, what are they seeing? Or does it come from like their app test reports or any of the tools that they’re running with their source code analysis, things like that?

Vandana Verma 00:06:19 Actually, it’s a mix of it. It’s not just the pen test reports. I agree. It’s like a pen test report. It’s the survey, it’s the kind of bug organization see, the list of bugs that organizations see. So OWASP leaders have collaboration with many, many organizations and vendors. And then they pick up the list of most renowned bugs or most scene bugs that are impacting the organizations worldwide, not just in one place, not just in US, not just in UK, not just in India, but everywhere. And that’s how it comes up. And this data is a mix of a lot of things in checking, how much risk vulnerability is pausing and what sector it’s pausing, all of those things.

Priyanka Raghaven 00:07:05 That’s very interesting. I, in fact, wanted to ask you one thing in terms of the data, do you look at say how frequently a vulnerability comes up on the application or is it like the likelihood of that vulnerability occurring? And if it’s possible to get into some little detail before we jump into the OWASP top 10?

Vandana Verma 00:07:24 So frequency of occurring is actually, it’s subjected because this one I specifically saw in detail. There were many CWEs, which is common weakness enumeration that are part of each vulnerability. If you go and check out at OWASP top 10 page, with every vulnerability there are many CWEs associated with it. So, when the data is scrubbed, it’s checked that what is the frequency of it? How exactly differentiated from others. For example, I’ll give you an example and then it’ll be explained better. Like authentication controls, broken authentication control has gone to top one list. So in broken authentication control itself, there are 34 CWEs mapped. So each one has a different area, could be violation of privilege, escalation or violation of principles of least privilege, maybe when you are not supposed to edit something and you are having that access certain issues around APIs. So it underlie multiple aspects of each bug or different use cases.

Priyanka Raghaven 00:08:30 That’s very interesting. I didn’t know if there was that kind of detail, which goes in, maybe that’s further reading and I’ll add that in our show notes. So people can take a look at the OWASP page as well. I guess now we can move into the top 10 vulnerabilities for 2021. And so I’ll just maybe read out each element and we’ll go through that and sort of get your view on it. Maybe a definition or some example, whatever you think from your point of view makes sense for people to look out for. So, I think the first one on the 2021 list is the Broken Access Control. And if I look at the stats from OWASP, it says that 94% of the applications from the survey and the data had some form of Broken Access Control. So could you kind of explain the importance of this Broken Access Control and what exactly is it.

Vandana Verma 00:09:23 Absolutely. When we talk about this bug, it was move from fifth position to first position. The basic reason was that when the data was gathered, they realized that most of the issues that are arising, they are arising because we are exposing certain sensitive data, which should not be shared. And that happens because of access controls, that we don’t have the right set of access controls. For example, right now you are the podcast host, Priyanka. I am a podcast guest. And if I am getting access to the podcast, all the recordings of the past, that means the privileges are not properly set. So when that came into picture, we realized that every vulnerability that has some connection to broken access control, some are the other way. And on top of it, if you see this OWASP top 10, that goes in very much in Snyk, okay, this is not there.

Vandana Verma 00:10:20 Oh, this could be a problem. This is not there. This is the problem. So it goes very much in tandem. And this vulnerability specifically says that let’s take care of access. Let’s get the right access at the right time to the right person for the right role. Because if we don’t do that, we would see the problems coming on and it does not stop there. It also comes along with another aspect that metadata manipulation we’ve seen with SSR, which is the top 10 list and the 10th one. Now that also links again with a broken access control that you don’t have the right access. And that’s why somebody was able to manipulate it. So that’s why they have marked it as top one. And as you mentioned, rightly that 94% of the applications were tested for some of the other broken access controls.

Priyanka Raghaven 00:11:12 Wow. And interestingly, it all ties to the items in the list as well as you just brought out. Okay. I think that’s a pretty good overview of Broken Access Control. So let’s move on to the next one, which is the Cryptographic Failures. I think this was previously called Sensitive Data Exposure. It’s on the list. Do you think it’s because of all the hacks we’ve been reading online for the past couple of years, there’s been so much of leakage of sensitive data and cryptographic failures contribute to that?

Vandana Verma 00:11:44 Absolutely. They do contribute. And when we talk about sensitive data exposure, think of hardcoded passwords in your code, that has been like one turning and twisting point. On top of it, a lot of applications still have certain ports open where data can be fetched or think of you and I are using some channel of communication, which is on HDBP. And this does not stop there. You would see a lot of places wherein there are certain bank pages. Think of it as bank pages, which are only supposed to be accessed when you’re logged in. And now when you’re not logged in, I can open it in some other browser. How cool would that be for an attacker? Amazing. Now server-side certificates have become a trend, but if you start using self-signed certificates, will there be a problem? Absolutely. It’ll be a big problem.

Vandana Verma 00:12:38 If youíre using a depreciated or deprecated algorithm like MD5 hash or SHA-1 Hash, which are easy to break now for me, it’ll be amazing, but for you, it’ll be problematic. So it’s very, very important to understand like how much they contribute to these things and how much they can be helpful. And on top of it now we’ve started using keys a lot. If keys are not being stored properly, or if the keys are not managed properly, what will we do? There’s nothing that we can do and who to blame for it? Only ourselves. These things become so common.

Priyanka Raghaven 00:13:17 You know, you’re just speaking to someone who spent about a week now trying to find out about these issues. Like where do you store the keys properly finding that credentials have been there in, or maybe not in the right area with the right amount of privileges anybody could see. So, yeah. It’s been quite stressful at work because I think the original thing is trying to first take care of things and do it properly the first time then. So I think I should be sort of having this list printed onto my desktop as well. I think I’ll go to the next one now, which is the Injection Attacks. They are number three on the list from the survey. It says that again, this is something like 95% have said that they’ve had one form of injection or the other. And for me, when I think of injection, I only think of SQL injections. But you as an expert, can probably break it down for us a little bit on what are the different types of Injections?

Vandana Verma 00:14:13 I would say that this is one of my favorite and all-time favorite. I’ll tell you the reason for it. Because when you look at OWASP top 10, Injection has always been on the top. And when it’s on the top and it’s coming down to third level, it brings us to a point that it is going away. No. Why? Because XSS has also been clubbed with it now. And on top of it, if I say this, theyíre like when we were kids, this vulnerability was there, this vulnerability specifically was there. We’ve grown up, our kids are going to grow up and this is going to be there. Why as soon as the list came out, I saw log 4g? Then many, many remote core executions came into picture. So these vulnerabilities are not going to go away. You would keep seeing these Injections to whatnot. That’s funny, but that’s the truth.

Priyanka Raghaven 00:15:08 Yeah. I think that’s brilliantly brought out by the log 4g example that you gave. So it just brought us right back into thinking about how we do logging and thinking about who might use our logging frameworks. The next one on the list, the fourth item, which is Insecure Design actually caught me a bit by surprise. That’s great. Because I think one of the thing is everybody keeps talking about shifting left is this to encourage developers and teams to start doing more threat analysis or threat modeling?

Vandana Verma 00:15:41 You’re right. Some way, yes. But insecurity the design talks about even the more that let’s go ahead and understand security better from the start. There’s a principle called secure by design. So it talks about that. And it also impresses on moving just beyond shift left, understanding where it all starts when even the discussion starts. So this actually talks about that. This is one of the most interesting ones, because we have never seen it. Like OWASP can talk about Insecure Design, but if you don’t have the right design, you would always have these vulnerabilities. And vulnerabilities, we would never be able to fix it. If we are not able to architect our design, now we are moving to Cloud, right? We have so many instances or I think everything is moving to Cloud. When that’s happening, it is important to architect it securely from the design itself, from the very get go. So that when we host things, we are not doubtful. Oh, how the things were going to be? Where exactly is what? And we know it end to end. And that’s what makes it more helpful at the same time it emphasizes on the concept of let’s design it right. It also talks about culture, methodology and what not.

Priyanka Raghaven 00:17:01 And I think somewhere, I had heard that security vulnerabilities exist in application and software because of bad design. So because you’ve not really thought about how to build the system, which is why people are able to exploit it, right? Overflows to where, and that’s interesting, what’s your take on threat modeling? We had done separate episode on threat modeling, but for application teams, what do you think about in significance of, say getting developers into this exercise, can I get a take on that from you?

Vandana Verma 00:17:34 When we talk about threat modeling, it’s one of those things which should be done on our applications or even network. Why just applications? And even you can do the threat modeling in the code where, and you understand where exactly flaws can understand, and that’s why we all do it. So if you want to know more about it, instead of me saying, you should also look at threat modeling manifesto. So that’s by the leaders of OWASP, they’re created this manifesto and it’s a beautiful place to look at different aspects of threat modeling. They cover everything end to end. Why you should do, how it can be done, why is it important and what are the aspects to look at in a wider area?

Priyanka Raghaven 00:18:15 I’ll be sure to add that to the show notes, threat modeling manifesto. In fact, I’m not sure if this was quoted in the previous episode, but I’ll definitely add this to the reading list. The next set of items, which I want to look at is I think to do with security misconfigurations and outdated libraries, et cetera. So let me go to the, the next item, which is the fifth item in the list, which talks about Security Misconfiguration. I think just now you’d spoken about, you know, everything going on the Cloud. So maybe do you have some interesting examples from either what you’ve read or what you’ve researched on?

Vandana Verma 00:18:52 Yeah. I’ll tell you funny story. It’s actually not funny. For someone it can be scary as well. So this happened when I was working for a client and it’s not a recent incident. So what happened, we were testing the whole network and applications both, because we were supposed to scan. It was more of a pen testing activity. Now, when we were scanning the ecosystem, we saw certain accounts and the scan came up as default passwords, like who keep the default passwords. All right. It should not be, right? If it’s a server, it should not be. Then we started checking the IP and we started accessing those IPs via browser. It came up with a camera vendor and it was asking for a username and password. It took just few seconds for us to get to the password. Because as soon as you search internet, it’s easy to find the default passwords for any vendor.

Vandana Verma 00:19:45 We look through the fourth password. I remember fourth or fifth, if I’m not wrong. And we were able to access the camera, it was just right across the cafeteria. And there were many other IPs that were there as listed. So we tried checking each one of them. Now, the funny part is that if you, if you’re working on something critical or if you’re part of the legal team and I have access to the camera, what more I can do? Think of it. There’s an external purpose who has come inside the organization and that person has access to the, the whole network. And then they’re able to access the cameras. What more I can do if someone is a disgruntled employee, what will you do? They’ll have access to anything and everything that you are doing, all the paperwork. It looks nice for me to exploit that bug, but then it is not nice for an organization to have that bug. So that’s what this particular vulnerability talk about is security misconfiguration. Why do we keep passwords? And I have a simple analog. So Priyanka, do you use toothbrush every day?

Priyanka Raghaven 00:20:48 Yes. Yes.

Vandana Verma 00:20:49 Do you share with anyone?

Vandana Verma 00:20:52 Never. So passwords are like toothbrushes. They’re your personal hygiene? Why do you share it with your parents, with your partner, with your friends and friends, friends, and what not. Why do we have to do that? Let’s not do it. Let’s keep our password secure, like our toothbrushes. And on top of it, a lot of times what developers do it, they keep the stack traces open, which give us a lot of informations or they leave the banner disclosure open. Or there are certain features which are not supposed to be open and they’re still open. So they have to be very much secure.

Priyanka Raghaven 00:21:26 Right. Specifically, I think with application teams, what we see is that when you’re accessing resources on the Cloud and then the credentials to access those resources, you want to share it with your team member and you rather just do it by, you know, sharing it on a popular chat window or, you know, chat application. And then, so you just work gets done and they don’t want to take, nobody wants to take that extra step of going to a key vault and picking out those values. So, and that can lead to your disastrous consequences. But the one with the example that you gave with the cameras is, yeah, it’s quite scary. The other one I want to talk about, which is the next item in the list is the Vulnerable and Outdated Components. A lot of us in this show and also within many organizations, I think we spent the last few weeks of December working on the log4j vulnerability remediation. Generally. I think a lot of people couldn’t take the Christmas, New Year time off because they were fixing their apps. In this scenario, how important is this Vulnerable and Outdated Components? Is it, should it be sixth on the list or do you think it’s going to move up for the future?

Vandana Verma 00:22:37 It should be moved up. It has moved up from ninth to sixth. I’ll tell you, you just mentioned log4j. You remember Equifax breach which happened?

Priyanka Raghaven 00:22:47 Yes, yes.

Vandana Verma 00:22:48 Now when you remember that, that signifies that yes, these kind of bugs should be fixed or what will happen? We will keep remembering these breaches for ages or the years to come. We don’t want that. We want something which we can actually forget, or we don’t want the breaches at all. Breaches are inevitable. They will happen. But the one thing to remember is how we can fix it, how we can come back from it. So there are certain aspects to it. Is that, why do you want it to happen in the first place? Right? So it becomes even the more important let’s keep our things up to date, or you will see yourself getting breached. Nobody would be responsible for it. Everyone will blame you for it. Ideally, there’s no one to blame for, but then when a breach happens, organization is getting targeted, like anything. Think of SolarWinds attack, right? So what happened with that? The whole supply chain thing, when I have to give an example about supply chain issues or attacks, this particular case comes into my mind. Why? Because it becomes so important. So huge that everybody was like, oh, we need to do it. We need to do it. Even the local news channel started talking about it. That was that much insane. So it’s important that let’s work towards making sure that we keep our systems designed right, up to date.

Priyanka Raghaven 00:24:17 I think it’s pretty interesting because with these outdated components there, sometimes I do see even, you know, a repost or something that I work with, it’s always convenient to, you know, work on something that’s very popular, which might have vulnerabilities, but you just, you just want things to work. And so you just take it up and do it because that’s the way we work nowadays. I mean, development is a lot faster with third party of the shelf components, but then there is, you know, this balance that you, you really need to make sure that you keep updating because the more number of libraries you’re referring to, there’s also that much of upkeep that you need to do. So it’s a very delicate balance. You want to hit the road running, but maintenance and off your third parties is also important, which I think sometimes when we are writing software, we’re only thinking about the kind of code we are writing, but not about all of our third party libraries that come to this afterthought and from what you’re seeing and what we’re seeing in the news as well. I think that maybe has to change.

Vandana Verma 00:25:14 I totally agreeable because if your third party libraries, you don’t know your ecosystem, well, you would be in trouble. For example, you have four doors in your house and four windows. When you go out for a vacation or even to go to the market, you close all your doors, but then you forget to close your windows. And there’s a thief who comes in, takes out everything and goes away. How would you figure out who will you blame for when you don’t know your own house? How will you secure it? Correct? So that’s how the outdated libraries comes into picture or using components with known vulnerabilities. People emphasizing on the right kind of CMDB or software bill of materials, or even getting the right set of actions at the right time where you can track the things.

Priyanka Raghaven 00:26:04 Right. Yeah. Sometimes I also wonder, you know, because if you say like NPM libraries we just do this NPM install very, it’s easy. We just do that. And then I wonder if those kind of things are we thinking about it? When should we be thinking about what are the libraries that we are going to use at the design stage? So maybe we could, you know, try to reduce this kind of dependence on unnecessary libraries. But I don’t know if that’s an overkill, maybe this is only things which we’ll know when we actually start developing. And maybe that much is not known at design time, or like, I don’t know if, what do you think? I mean, do you think we should be doing design like more frequently and not just like as big bang exercise?

Vandana Verma 00:26:45 Actually, it’s very subjective because when you talk about libraries, it is important that you document it properly. And they’re not just from the getgo, because what happens is like a developer is working on some piece of code, the person installed something and then leaves the organization. How would the other person get to know that this is the version that it is installed? And I’ll go back again to the recent incident, which happened with SpringShell. The same thing happened. Now how would you handle that? How would you take care of all of these things? It is very, very subjective. And if a person leaves the organization, how would you figure out who did what? And that’s what documentation helps. And no doubt design is something which is needed at any given point of time. So let’s document everything right.

Priyanka Raghaven 00:27:37 Maybe that should also be in the OWASP doctrine, right? I think there was a show on the book on the missing ReadMe for repost things that’s super important. Of course, you have your library information and your packages list or whatever, but I think sort of having a good ReadMe with the document on why you did that as well as, you know, confluence pages are all very important. And also, I find that sometimes when I just take the effort to read the ReadMe or the confluence pages, I seem to know a lot more than just spending time asking people. So I think your documenting, like you say, is rightly important and reading that as well.

Vandana Verma 00:28:15 Right, I agree with you on that.

Priyanka Raghaven 00:28:17 Okay. Now, seventh on the list, we’ve gone through all of this and we are back now to Identity and Authentication Failures. Whyís this still on the list? I thought we have standardized frameworks now, and we have, all of us are, you know, using one or the other standardized frameworks to do identity, but it still seems to be on the list. Why do you think that’s the case?

Vandana Verma 00:28:41 Because when we are designing, we are not designing right. That’s one of the things for sure, because we keep deploying, like we are not deploying multifactor authentication. There was a research which was done in 2017. And if we do the same research, now this was done with no JS ecosystem. What happened is like they figured out that a huge set of people were still using insecure passwords. And if I speak to you, you would say that I’m using my husband’s name or some other close person password as my password. Or I use the same password, like everywhere, again quota breach, which is with a Colonial Pipeline attack. That was again a big one. What happened? Someone at the org, they had their password used somewhere, which was leaked. And then they interpreted this person might be somewhere. And then they picked up the VPNs credentials.

Vandana Verma 00:29:39 And that’s how the whole thing pivoted. Now, if we would’ve used a strong password and not the same password repeated a lot of places or multifactor authentication that would’ve been used, I think it, these things could have been avoided. Could have been avoided, or there are orgs, which are still using the same session identifiers. Why do we even do that? Let’s invalidate the session properly. Why do we have to play around with the session IDs? We’ve started using single sign-on, we’ve started using a lot more things, but again, we’re still living in the same era. And now we are not, we are trying to avoid route force, but then there are new ways which are coming up. It is not like that we are not doing it, we’re doing it, but then it needs more effort, more time and more energy synergy.

Priyanka Raghaven 00:30:29 And like you say, even though we have the frameworks, the weekly link could also be the social engineering.

Vandana Verma 00:30:35 Perfectly said, yes, absolutely. You know me, you’re a good friend of mine, but again, we are in Security. You might try and I’ll tell you funny thing, I shouldn’t be saying that, but a lot of people ping me on LinkedIn or connect with me and they say, we stalk you. And I’m like, you don’t stalk me. You just try and understand what I do. But they specifically say that word stalking and everyone does that. And everyone does social engineering or do the Open-Source intelligence, whatever, lying over there, trying to figure out that thing. And I think those things are very easily. You can detect like Priyanka, if I’m speaking with you, you know me for like few years now. I can say that now, you know about my son’s name, about my family, about the likes and dislikes. When you know that much, you can try and guess my password probably? I would say, that’s not good. Or you which company I work for. You try and get my username. And from the username you try and route force it. Is that good? No. So that’s how it leads to a total different position.

Priyanka Raghaven 00:31:43 I think it’s very interesting what you’re saying. I just, when you’re talking about this, I also remember that last week there was the Okta hack that happened, but of course, but I think here again, it was a mix of, I think not having the right privileges, which is like, yeah, of course your number one item on the OWASP list. But also I hear, and I’ve not done enough research on this one. Maybe, you know, I hear that the third party organization that was hacked, maybe somebody sold their credentials and that’s how they gotten these actors. Is that something you are aware of? I mean, I don’t know if you’ve read about,

Vandana Verma 00:32:18 I have read about the Okta breach, but I would refrain from commenting on that. I’ll be very honest.

Priyanka Raghaven 00:32:23 Okay. Makes sense. But I think one of the things is that I think two things that, which would come from any of these is that you can have any kind of V vector. So one could be just, even if the V vector is somebody, you know, getting your credentials. Then other thing that needs to be strong is that you have a second gate that kicks in, right? So at least your privileges are okay,

Vandana Verma 00:32:46 Right.

Priyanka Raghaven 00:32:48 Let’s move on to the number eight, which is Software and Data Integrity Failures, which actually focuses mainly on trusting software updates without checking for the integrity. How important is this? And do you have any takeaways for our listeners?

Vandana Verma 00:33:06 Absolutely. I’ll tell you something interesting around it, or maybe it’s very interesting for me. Again, it ties back to the vulnerable confluence and think of it as we trust certain things so much that we keep updating. For example, Open-Source, 80 to 90% of the code ask for one of the research by sneak itself that 80 to 90% of the code on the internet is all Open-Source. Now that’s a huge code and only 10% to 20% has been written by the organization, which means we are so much dependent that if something comes up, oh, let’s update it. Let’s do this. There’s a new update that has come in on the software, keep a time for it because we use it rigorously. And what happens is this year in January, what happened? There are two famous frameworks of no JS called color and faker. Now the both have the same person who’s contributing to it.

Vandana Verma 00:34:00 Who’s the leader. Who’s the person behind them. This person removed the content from the repository for faker and for color, this person added a loop condition. So anyone who runs this package like updates it and then runs the package. Their system would go in the loop condition or would have sort of a buffer overflow. Where your systems would stop working. So think of it as a very critical situation. And there are tons of downloads every week. How crazy that would be? That’s why people say that there has to be a review process before a change is committed. And it’s not just the only incident. There was an incident which happened a few years back with Events Stream, which is news for over 10 years, more than 10 years. And suddenly somebody comes and says that I want to help. The Project Leader start taking help. And this person adds a malicious dependency to it wherein any system who was using this particular project will have a crypto minor installed in their system. Now the crypto minor is mining and your system resources are being used. Isn’t that crazy? That’s why when we are setting up the CICD pipeline, when we are setting the whole ecosystem, let’s have these documentation, proper signatures, proper, and we need to have SBOM, which is Software Bill of Materials, where we are tracking all of these things.

Priyanka Raghaven 00:35:30 Any tips for like, how do you update a third-party competence? So should we be looking at say whether it’s properly peer reviewed, does it have like number of stars? Like if it’s got a five star and this version is good or something like reviews, what should we be looking at? Or do we wait a certain period of time in your experience?

Vandana Verma 00:35:49 I would say it is more important to test it in your lower environment first, and then move it. Because even if the peer review is done, sometimes we tend to miss it. It is very humanly, right? So, it’s best that we test it out in the local system or a dev environment or system, which is not connected to the production. And then go ahead and start playing around with it or post it to the production.

Priyanka Raghaven 00:36:14 That’s a very good point, I think. Yeah. So just don’t blindly trust, test it out. And then yeah. Start using the next company, which I think most of the times we don’t seem to be doing that because either we press for time or it’s easier just to update. Let’s move on to the last bit one, which is the ninth item, which is Insufficient Logging and Monitoring. It’s moved up from 10 to 9. And as per the industry survey, it was also actually ranked number three. So can you explain why logging and monitoring is important and maybe, I don’t know if you could share maybe examples without naming companies where insufficient monitoring actually failed to detect the breach.

Vandana Verma 00:36:54 Again, I’ll quote Equifax for it.

Priyanka Raghaven 00:36:56 Okay.

Vandana Verma 00:36:56 Okay. Because sometimes when you have everything right, but then the monitoring is not done properly, then there are issues. Because most of the companies are using security, right? It’s not new for organizations, but still the organizations are getting breached because we tend to miss out on certain aspects of logging and monitoring. So it is like tracking or backtracking something which has already been done. So if you don’t have the logs, how would you even do anything with that? How would you detect what has happened? It is not at all advisable to not retain the logs. You should retain the logs for a certain time or certain period. And that’s why these logs kicks in into picture or these compliances kicks in the picture.

Priyanka Raghaven 00:37:42 Super interesting what you’re saying. And yeah, actually, without, it’s difficult to do any sort of investigation without the logging. And I think that’s becoming increasingly difficult also in the microservices world, if you don’t do it right.

Vandana Verma 00:37:56 Right. Absolutely. We are living in the era where things are going super, super fast. So how would you even detect it? How would you even figure out that there are bugs?

Priyanka Raghaven 00:38:06 Yeah. Which component? Yeah.

Vandana Verma 00:38:09 Yeah. Like I can’t do with that. And even humanly, it’s not possible. And we want things to go live on the like lightning speed earlier. What used to happen when we were working with development teams, there is a release after three months, six months, nine months, or even one year now, when that happens, after the release, there’s a big party. Now think of, is it humanly possible now? Or is it practically not humanly, but practically possible now? You want everything tomorrow or today? How would you do that? It is not possible. Things will fall apart.

Priyanka Raghaven 00:38:43 Yeah. I will probably come back to that at the last part of the podcast on the culture aspect. But let’s move on to the last item, which is the Server Side Request Forgery, which you talked about also with the broken access control. Can you explain a server side request forgery to our listeners who are sort of not security experts? Because apparently even the survey, it seems to say that security professionals viewed this as more of a threat than say developers.

Vandana Verma 00:39:15 I would say Server Side Request Forgery is nothing, but when you are able to fetch data from the server and in a way that you can extract the information, you can instruct the organization or the URL. To be very precise, the URL to sense some data to somewhere. For example, if you have SQL injection and it’s a blind SQL injection, you wouldn’t get to know that yes, there is an injection or there’s some data. But if you say, send the data to this URL and then the data is being sent, that means there’s something which is happening in the background. Similarly, the Server Side Request Forgery, it happens out of band wherein you try and stretch the data, which you’re not supposed to have access to. So the access control again, plays a very big role. But I’m an external person and I’m able to scan all your ports, all the port, all the servers, which are there and as part of your organization.

Vandana Verma 00:40:08 And if I have to code a breach and I’ll tell you, it’s a big disclaimer, that all the breaches that I’m talking about, it’s there on the internet. You can read through it. And similarly, this happened with Capital One. It was a big credit card breach where a person tried to upload the credit card image. And then they figured out that the data is being hosted on a AWS S3 bucket. They started fetching metadata to IM credentials to getting the access and SSH keys to those accounts. And I wouldn’t blame anyone but not getting the access right. And that’s how they were able to perform Service Side Request Forgery. And when a breach happens or when there is a vulnerability, it does not happen when I would say that it’s just a breach or it’s just one vulnerability. It happens in tandem. It happens. It’s in chain. If I have to put it like one leads to other, other vulnerability leads to the other one.

Priyanka Raghaven 00:41:03 So you’re saying that like, it could just not be at that one vulnerability. It could lead to like many more things. If it’s not, you know, designed right. In terms of access control, there could be a lot of other things that you can pick up from there. That’s interesting and scary, but I think it’s great because we’ve sort of gone through the top 10 for our listeners. And I’ll definitely add the top 10 list again on the show notes. I’d like to use the last section of the podcast to ask you a few things. One, I think the first thing I wanted to ask you was also in terms of the culture, which we briefly touched upon in the ninth item, which is we want things faster. So I wanted to tie it in with the OWASP Top 10. Was this guidance to developers that the OWASP top 10 provides. Was it also to kind of influence the software community towards a better culture in terms of software development and life cycle and you know, going too fast or, you know, slow down a bit. What’s your take on that?

Vandana Verma 00:42:06 I would say when we talk about security, it’s everyone’s responsibility. Not mine, not yours, not developers, not security people, but everyone in the organization. So it is important to understand in aspect and educate the people. Developers are supposed to make the application look beautiful the way it should be developed, but what happens next? We start forcing security on them. It is not easy. I have a mindset. I have a way of working since inception. And now you say, oh, add security to it. And then we start beating them up for it. It’s not right. Being a security person I can say that. Now when that’s not right. Let’s work to go towards educating. And education is something which is must and let’s have it right, I would say. And that’s where it plays a big, big role

Priyanka Raghaven 00:42:54 Education right? That’s what it said.

Vandana Verma 00:42:55 Education and yeah. Peer education is very important.

Priyanka Raghaven 00:43:00 OK. And, you know, sort of building up on that. So does OWASP work with say tool vendors to help the community catch these flaws in terms of like, you know, educative tools that does it come from the tool vendors or the community that, because you have so many of these projects there, right?

Vandana Verma 00:43:17 Right.

Priyanka Raghaven 00:43:18 How does that work? Is it just the entire community that contributes that? Or do you have specific sponsors who you work with?

Vandana Verma 00:43:27 I would say that when we talk about OWASP, OWASP has so many projects in itself. So the projects, when you look at them, they themselves update or educate people. You can look at any project. And at the same time there are conferences which OWASP host, and also when OWASP post these conferences, they connect people. They have local chapters and these project leaders in turn educate each other.

Priyanka Raghaven 00:43:57 Okay. But do you also work with like tool vendors?

Vandana Verma 00:44:01 Tool vendors? Not particularly because OWASP vendor neutral community.

Priyanka Raghaven 00:44:06 Right. Sounds good. I was wondering if you could also tell us a little bit about some example Open-Source tools that you think that listeners should look at after the show from OWASP.

Vandana Verma 00:44:18 I love all of those projects, but I have to tell you OWASP web testing is the place to start off. If you want to make notes of the use cases, OWASPís Application Security Verification Standard, which is called ASVS, is the place to go. Another important aspect is that if you want to go more deep into it, then OWASP top 10. And then there are many projects for tools, for documentation. Everything is there, you could check it out. And if you want to know the highlights of it on my YouTube channel, just look for one, I’ve created a series just for the project, which is called OWASP Project Spotlight Series. I reached out to those leaders, the project leaders, and had a brief chat and the demo of how these tool works, how the documentation project works, if that might help.

Priyanka Raghaven 00:45:14 Yeah. I can definitely link to that because I think the OWASP Spotlight Series you rightly said, I remember catching the one on OWASP Zap that you’d done was great with Simon Bennett or that was very good. And I, I think also there’s, there’s something on the OWASP Juice Shop. I don’t know if it’s a part of this thing, but I remember seeing an introductory thing from that as well from you.

Vandana Verma 00:45:35 Right.

Priyanka Raghaven 00:45:35 I think I’m going to add all of that in the show notes.

Vandana Verma 00:45:38 Sure.

Priyanka Raghaven 00:45:39 And then how can we, as members of the Open-Source community contribute to OWASP? How does that work?

Vandana Verma 00:45:47 You can be a Project Leader. You can be a Chapter Leader, or if you really want to contribute to a project in detail, just go to that project. There’s a GitHub account. You can help in refining the language. You can help in adding some content to it. You can help in suggesting that this could also be there from your experience. So it really helps if you help that way, or there’s something that you want to create of your own. So you can be a Project Leader there. You can submit a project and can be a Project Leader. If you want to connect with the community, then please join a chapter. And if there is no chapter near you, please consider starting a new one.

Priyanka Raghaven 00:46:27 And I guess, get in touch with the OWASP Board?

Vandana Verma 00:46:31 Oh yes, I’m the current. So that’s funny. Yeah, absolutely.

Priyanka Raghaven 00:46:36 Okay. Vandana, also in terms of the OWASP top 10, right? The survey, is there a way that the open, I mean, how does one contribute to that survey? Do you get invited? Or is that again, is there an announcement that goes out and people can contribute data to that?

Vandana Verma 00:46:53 I would suggest reaching out to Andrew Wernerstock (?). We talk he’s one of the Chapter Leaders, or I would say Project Leaders for it, and it can be helpful.

Priyanka Raghaven 00:47:04 This has been great. And before I end the show, are there any other words of wisdom or advice that you’d give us software engineers on what we should be doing right apart from looking at the OWASP top 10 or any other nuggets that we should like look at?

Vandana Verma 00:47:23 I would say always keep exploring new things. Another important aspect is that there will be vulnerable reason. And what you can do is you can educate yourself. Nobody is going to be there for you when the things will start bursting. So let’s start educating ourself. There are so many wonderful re researchers which are out there, but we don’t look at them. We have so many wonderful content out there. Let’s take help from it.

Priyanka Raghaven 00:47:50 Brilliant. I think. Yeah. That’s great. So education is the key and thank you for coming on this show Vandana. And before I let you go, I just want to know where is the best place that people can reach you? Would it be on Twitter or LinkedIn?

Vandana Verma 00:48:04 Yeah. You can reach me out on LinkedIn and Twitter. Both of the places I’m super active.

Priyanka Raghaven 00:48:09 The handle is with InfoSecVandra(?), right?

Vandana Verma 00:48:12 Yes, absolutely. Even my website is InfoSecVandana.com. You can feel free to reach me there.

Priyanka Raghaven 00:48:18 I will definitely add that to the show notes. This is Priyanka for Software Engineering Radio. Thank you for listening.

Vandana Verma 00:48:26 Thank you.

[End of Audio]