 Thanks, hello everyone. I think Shubham Stocks sets a good pre-context for my talk on how to go about doing things. So today the aim of the stock is to guys give you an idea how to have a successful bug bounty platform. And if you want to set up a bug bounty program for your organization, how do you go about it? What's the, what all it takes to run a successful bounty program, right? So let's get kick started. So first thing about me, I'm currently head of security privacy interest at a hot star. Before this, I was with Ola, before that Flipkart Adobe. What I love to do is solve security at scale. That's one of the first fun thing that I love to do, right? Why am I talking about bug bounties? Is because long time ago I was, I wouldn't say a bug bounty hunter. I would say security researchers who used to do sort of bug hunting when there wasn't a bug bounty programs such and I've done quite a few then. From then onwards, I moved from that side of the table to this side of the table where four years back, sorry, I launched a successful bug bounty platform for an organization that I used to work with, right? And I'll take you through the journey of how things happen and what all it took to do that. So before starting, let's have a quick glimpse of what's a bug bounty program, right? I think this picture depicts it clearly, what's a bug bounty program, right? Like it's shake up a tree to get some money out of it. And harder you shake, the more money you get, right? To summarize in points, it's like, it's a platform where you receive recognition, reward bounties for submitting vulnerabilities, right? Why it is such a thing now? Because bug bounty hunters or white hat hunters get paid around roughly two and a half times, two point seven times more than an average software engineer. And in India, it's very different. It's like it can go up to 16 times, right? That's why it's a big thing now, right? Why do we need a bug bounty program, right? Well, according to a recent research, probably it's IBM or so forth, I'm not too sure, where they said cyber criminals have said for them to breach any network, it takes 10 hours, right? If we have to make sure our organizations, our infrastructure is secured, we have to work the way they do, like something the previous talker explained a lot, right? Now that's why we need the support for the whole bug bounty or white hat community together to make it work. But this is important. Bug bounty is towards the last thing I wanna do. It's not the first thing, it's not the fundamental thing. It's the process to identify bugs that have slipped through the cracks, okay? And that's why you deploy a bug bounty program, not a replacement for your security team. That's really important. History of slightly, some issue about bug bounty. What I recently got to know, the first bug bounty came in 1983 with Hunters and Wedding Corporation. Then Netscape, Navigator 2 launched one in 95, Tomozila, Pontoone, Google, Facebook, to now all the telecom operators have it, payment companies have it, all the governments have it, hotels have it, adult website have it, right? And it goes from, it has gone from this to finding bugs here and getting this as a gift as well, right? And that's how it transitioned in the last probably two and a half decades. Today's agenda is gonna be understanding what are the use case for you to consider to launch or not to launch or to have or not to have a bug bounty program for your organization. What's the parameter you should think on? What are fears, concerns, having a bug bounty program? What things that you run into you haven't thought through while having a bug bounty program? Understanding who does it apply to, right? Here we have organization from 10 people startup to a big like 1000, 10,000 people corporations. Does it applies to all? What's the thumb rule to understand who does it applies to? Dark side of having, not having one, right? If I don't have one, what are the bad or the worst thing that can happen to me? How to launch your own bug bounty program where things, essentials before setting up, launching one, what are the logistics you have to take care? How do you make sure you run a successful one, right? Couple of pitfalls while you're running and how to avoid them? And some yarn from my side, right? Okay, now before I give you all that theory of what's needed, what's not needed, I wanna give you a quick walkthrough of how I did it for years back at Ola, right? Now, when I launched at Ola, it was just two of us, me including in a security team and we're doing so many things and we thought of launching a program. We had our own things done, which I'll walk you through. And when we decided we wanted, like ideally, probably some of you have interactive bug bounty platform or commercial one. So you know it's like you submit something by a form, someone sends you an email, then there's interaction happening over email, all of it, right? My aim was, it's two people team. If I get 10 bugs in a week, I cannot manage that because I have to do a lot more work. How do I go about automating all of that stuff? The aim was like, can I have click buttons where I just click and everything happens? Like it sounds a bit fancy, but we did achieve to a good level in terms of how do we go about doing it? So that was my aim. Now, doing that, so that's the way I wanted to. And post that, what I wanted to have is all the things that would be coming in how I would be counteracting with them, right? So this was aim of how should a bug bounty platform I should build, right? And I'll also talk about why not use a commercial one in slightly couple of slides later, right? So ideally, as I said, there's a communication channel and everything follows. For me, if it's an email, then it becomes a hard thing. Hey, have I replied to those researchers? Have I fixed those bugs? It's hard to follow up all of those things, right? So what we did is I have video and I have images of these, videos to explain to you how I did it. So just to kill you, again, the vision was, can I have things at the click of a button and how do I explore with minimum hard work put in place with maximum automation to do all of it, right? So it works something like this, like you go ahead, fill a form on a page and you submit, right? Okay? You submit the bug. It's all received. Now, ideally it goes to an email account that we had. Okay? Now, the point was, I cannot monitor email accounts so we need some kind of automation. We, at that point in time, using a ticketing system called JIRA. And we went ahead exploring how we could abuse and exploit JIRA in a good way to automate all of it, right? Probably workflows and things that I'll show you here, you haven't seen, you would have thought JIRA exists that way, but it does. And probably after 20 days of exploration, we did a lot of stuff. I'll first show you what it works. Let me pause it here. So what happens is the moment you submit a bug, it goes in email and we wrote a JIRA handler to monitor that email and then it comes to JIRA. The moment it comes to JIRA, it keeps moving, okay? We had, let's say, some artificial intelligence to understand the criticality of the bug so we can monitor on how, which are critical bugs that needs to be looked at because if I'm getting 100 bugs, I need to first focus on the critical P0 bugs, right? Then it gets a lot of details. It has a security where we created this to understand each bug and how do we measure, or monitor each bug and that we're talking to the same person who has submitted X bug, but for that particular bug, right? All of those things comes in an email, right? Now, if few of you have interacted with JIRA, you know there are workflows that are refined where you have buttons to do things, right? So now, when this happens, we wrote a JIRA post trigger which sends an automatic email the moment it receives a JIRA ticket to the customer, to the third party researcher saying that, hey, we have received your bug, this is your identifier to use further and give us some time to validate this bug. This is all automatic, no one's doing. The moment, I'll show you how it's done. And okay, now, as I said, right? We had few things done. A bug could be valid, invalid, I'm not able to reproduce, duplicate, won't fix out of scope. Email is an option that we had, how we can interact with the third party researcher or the bug bounty hunter in terms of over the communication. So, and the whole security team needs to just work on this JIRA, where everything they say goes as a comment. Every reply that customer says comes as a comment. So everything is tracked here and we just click buttons, hey, it's valid, it's not. Right? So, I'll show an example of send email where if I have to talk with a customer saying that, my bad, talking with the researcher saying, hey, can you help us with some more details or hold on for some long? So, you understand, we just, the security team just says thanks for submitting, nothing else, right? What happens at the back end, it's all post things and triggers that we wrote. Let it refresh. The JIRA adds couple of headers, footers, signatures, the key, all of it, right? We could write anything that we want to. So, if you have seen commercial platform, that's like timeline that goes through where you interact with the researcher, we do it via JIRA because we can do it, the whole organization is used to use JIRA, right? Now, let's mark a bug valid. The moment you mark it valid, the flow changes to, okay, fix in progress. Researcher gets, again, an automated email that, hey, you know what, you have spotted a valid bug while you evaluate here things that you need to look for while we are working on it, right? Now, then it goes to a fix in progress where engineering team fixes it, they mark it fix, then it goes to QA team, they mark it QA done, no regressions, then it goes to security team, they say, hey, you know what, there is no security bypass, then they mark, hey, verify from the security researcher itself and it issues an email to the security researchers that we have deployed a fix, how about you go and see if they are bypassers or the fix is good enough, right? We have fixed it, how about you just verify it's good enough or not, right? So, security team is just clicking buttons ideally, doing nothing, right? This is another awesome thing, right? So, the moment we want to close a bug, obviously it's a valid bug, we have to figure out how much do we have to pay out to the researcher. So, we created another Jira project, pay out which only security team and the finance team had access to, what we said it's an all automated way, the moment I click on, sorry, click on close, it creates a new ticket where we can just enter the amount, I'll just show you. And another email will go to researchers saying, hey, we are awarding you this much amount, how about it? And then the finance team can close the loop. So, we enter the amount, it's a test, and we close, okay? Now, what do you see here? It's a new, it's not coming in, okay? For some reason, the bloating is getting disconnected, okay? So, as a pay out ticket was getting created, which is not visible here, and if I refresh my Gmail account, the researcher refreshes his Gmail account, a new email gets triggered to him, asking him about, again, tons of things in terms of, hey, here is something that we are paying you out, here are the details and everything, right? So, this was the front end of how security team has automated everything and they, so at Jira, you could just create dashboards so I know how many bugs are open and which state, how many critical bugs are there, how long, are we taking to fix critical bugs, all of it together, right? Okay, here is something that I'll show you how we abuse Jira in a good way is, this would be probably the most mess up the workflow of Jira that you have seen, would be something like this. So, right? I cannot tell you, like, after I was done with this, I started even, when we wanted to hire a Jira admin, I started interviewing Jira admins because I knew so much about Jira, think that it had, was really, I didn't knew that Jira could do so much, right? How we created bug mandlers, post triggers, pre-triggers, triggers to itself, right? So, yeah, so now let's see the workflow that I was talking about. So, what happens is if anyone of you have used Jira or any ticketing system, you know from, you have like four or five state on how things flow, right? Here what we had is, here what we had is something really hard, like just opening an issue, sends an email, it can go to x states, I'll just, like, I have images on this which I'll walk you through, but just a quick find through of how things could be done. How much effort went in just designing this because it becomes, it becomes like, hey, if this effort we haven't put in, we wouldn't be able to automate the thing that you saw on the front end of the Jira. This is all that went in doing all of it, right? Reopening, I'll talk about reopening and how after closing, it creates a new ticket for payout, right? That's how it does, and it's a bit messy up, right? So, if I have to go just, so, so as I was showing you, right? Something happened. So we had post function, we wrote all of that, right? So it's as simple as we went ahead, created a post function, posted a groovy script of whatever we wanted to do, whether fetching an email from account handler, how to push it, and all of that was done at Jira. This was a one-time activity that we did. This was a one-time activity that we did which gave us enough bandwidth to manage things. So now, as a security or the triage team, we just had to click buttons, and it goes to the right people, whether finance team, engineering team, QA team, or security team, or the researcher for that matter. So this is something which we did, okay? What happens, I'll just walk you through, is, as I said, right? Whether the priority comes in by default, we wrote a post function for that. We, so Jira, this key that you see here is created by Jira itself, nothing else, because email comes, form submission comes to an email then to Jira, right? Everything is done at Jira and itself, right? Now, after this researcher receives that email from an open state, it can go to either of those five states that you see, out of scope, won't fix, invalid, duplicate, valid, right? Now, the moment we mark anything, it sends an email as I showed you. Now, just telling you, right? All the arrows that you see, these are triggers in itself, like close has three, four triggers. This is something while designing, probably I took around just one week to 10 days to design this workflow, because if I launch bug-bound T without having this workflow, it's gonna be manually managing all, because I have to figure out what state it goes to and what all it can happen, right? So, from fix, from fix and progress to fix, there was so many things that needs to be happening at the same time that we have to design and prepare for. So, the point is how much effort went in at the one time to automate all of it, right? The moment we have fix and progress, again, it goes to QA state where a QA can mark it, so everyone was involved, the whole organization knew about this, that you were launching this. We had things, like, I'll walk you through the theory of how did we prepare for all of it, is everyone was aware we had proper SLA in place and completely automated. So, this is where an email goes to third party researcher to validate that we have identified, verify the fix that we have deployed to the bug, right? That's where he replies, yes, no, and see, the close itself can happen from so many places and so many things that needs to happen at the closed state, it has to create a payout ticket, all of that, right? Told you, you could have a payout, for sometimes you want to just pay out goodies, we need to have an option for that. Amount that we have to pay out, it comes in and the payout email that goes, so we need to have a bunch of these information, right? Whether we have to send goodies to you, you want Hall of Fame or not, this is a different identifier from the bug you have submitted because this goes at the payout ticket and this is something that finance team keeps a track of things, right? That's it. Now, this was how we automated all of it, right? But before even we went to the stage, there was a lot of backend things that went in where we had to prepare everyone for the bug bounty itself, right? Where should we have it, should we not have it, all of the agendas that I talked about would be here, right? Cool. Consideration for the bug bounty program. So here the problem is few companies launch a bug bounty program for the right reason, few do it for not so the right reason, right? Some examples or some reasons where if we're launching bug bounty for this purpose, wouldn't be a good idea, right? You think crowd sourcing security is a good alternative to have a replacement for our security team, bad idea. You'll only pay out for the bugs people find. Now you don't have to pay a full-time researcher, you just pay out for the bugs anyone find. So if you think having a team to exploit your system before you have enough security in place, think about it, right, because bug bounty hunters are people who want to exploit system, like the last talk, you saw how we can go about exploiting, where people pay enough money just for something that was committed to GitHub, right? You think, hey, you know what, this is a nice way of getting assessment of an application done. To avoid bad VR situations because there has been a case probably a year to year back where a food tech startup was forced to have a bug bounty program because of the way they didn't have it and some researcher went ahead or publicly and they were in a situation. Now we need to have one, right? You don't want to be in a situation that and you start having bug bounty program, bad idea. You think, hey, you know, like instead of having two people doing all of it, let's have like 100 people, 1000 people doing it? No, the reason you should be thinking of plus the season is a good idea, right? The first thing is to understand attackers approach, like when a bug bounty hunters or white attackers test your system, you understand from what all things people are looking at your apps, from what all different perspective they are looking at your apps, right? You want to have an open connect with the security community. The point of security community is not, hey, I'll pay you, just do it. It's all about how you build a repo with them to make sure they help you and how would you help them? Apart from bug bounty itself. You should understand if you have baked in security and a security team, you want to understand the resilience and the robustness of those baked in security mechanisms that you have. You could get a variety of outputs over a longer period of time because as people at the security team tends to have a bias because they know this application or services are good enough always. So they tend to have biases and that's where a bug bounty hunter can help you if things have slipped through the cracks. How to go about building a detection preventer system? So this again is a very good point where you don't understand what kind of people will attack you so you can build a robust detection and monitoring system, right? Eliminating bias, understanding your attack surface area. But again, bug bounty is not a replacement for your penetration testing team. It's just an additional step to understand the things that have fallen through the cracks, right? Now, what's the fear of a bug bounty program, right? This image depicts clearly what's the problem with a bug bounty program whether it's a real bug or it's a fake bug, right? For me to identify it and I'm scared of it, it's gonna be a problem, right? So the biggest problem organization have having a thinking of a bug bounty program is can I trust these people? I don't know them. I don't have an NDA with them. I don't know how would they go about. So can I trust them, right? It becomes too risky because I get a nub for an organization point of view because if I say I have a bug bounty program, it puts too much attention to me. Now, people who probably listen and care about me want to get easy money out and I become the center of attention. Do I want to be? It becomes a bit risky, a great area, right? Will I get bombarded with vulnerabilities? Like how would I handle the scale of issues that would come in, right? I have a quick stats to answer you this. Does it gives license to people to exploit our apps, right? I don't want people to exploit our apps. As a CEO of a company, I wouldn't want that ever, right? Having a bug bounty program doesn't define anything where it's wrong, it's right, right? Can I have a PR incident? Like the example I can talk about here is I have an image later where someone submitted a bug to Facebook. The team said it's not a valid bug. As a proof of concept, he went ahead, posted. The vulnerability was he can post on anyone's wall and the guy went ahead and posted on Mark Zuckerberg's wall. Now, if that happens, do you think whoever is responsible for security and Marks calls him? How would he respond, right? It's hard to manage, right? The last example that I gave to you. Some may have opinion, it gives a, it's a rewarding behavior for having, sorry, rewarding a bad behavior itself. Yes and no, right? Like you're saying, I'm gonna give you money if you find a bug to my app. It helps you, but it does reward you a bad, rewarding a bad behavior, right? So, okay, I'll just move around. So, this is a stats from Hackers Trophy where they talk about valid issues. So, what they say on Hackers Trophy, you get out of 100, 23.3% are valid bugs out of 100 submitted bugs. Two at Facebook, out of 100 submitted bugs, only four bugs are valid, the rest are invalid. Now, all of them, so three are commercial platform to manage bug bounties to have the own bug bounty programs, right? Now, think for those two companies where it's 5% and 4%, the best bugs are invalid. Like, if they have automation, someone is clicking invalid for like 96, 97 bugs, correct? So, how should I have it or not, right? So, pointers of now, we talked about what are the actual use cases to have a bug bounty program, what are fears and concerns of having one, right? Now, let's talk about how do I identify should I have a bug bounty program as an organization or not? Because I could be a payment company, I'm already compliance with RBI, PCRDSS, XYZ, right? I'm all good, why do I need to have one, right? I'm a CRM or ticket management startup, right? I know the person who's submitting via an email ticket and I have a team inside who manages all those tickets. I know those two people, do I need one, right? E-commerce cab aggregation, right? It's like, if I have to ship a product to an e-commerce, I know his email phone address. What bad could, like, what's the export that could happen? The same goes with cab aggregation, right? The customer's gonna onboard my cab. I know his pickup address, drop address. Why do I need a bug bounty program? Non-ID companies, HR, finance, supply chain, do they need one? Content website where there's future generated contents, it's like, hey, I don't care about anything. People can post anything and that's it, right? Communication platform like Slack or anything where two people talking to each other, they know each other, right? I'm talking to, let's say, Kiran here. I know I'm talking to Kiran and Kiran knows he's talking to Shut Up. How can a bug bounty program add the value for those organizations, right? Online registry, like NPM talkers, like DevOps conference, you think like it's all trusted, signed, everything is there. We know what happened with Docker a few months back. We know what happened with NPM a year or so back, right? Now, how do I define there's a thumb rule to understand is my organization eligible to have a bug bounty program or what's the timeline for an organization to have a one, right? The point is bug bounty program, as I said, is a good to have feature provided you have a security team, right? Whether you have 20 people startup, whether you are a startup which has just interacted or has API integration with all the other apps. The point is if you have enough decent security in place, you can live without bug bounty program. It's always a good to have thing, but a security is a must have thing, right? Security evangelization. So understand, security is all about exploiting and exploring the nuances. In an, as a logical statement, payment companies is all good. Docker registries are all good, right? A security guy goes ahead and exploits the nuances, which becomes a problem. As a company, payments are all set up sorted, right? Dark side of not having one, right? Let's say, here, now I think probably whatever category I fall into, I don't think I need a security bug bounty program, right? Well, if you don't have one, so I have presented here two points of view from the searcher's point of view and from organization point of view. From the searcher's point of views, see whether you have, whether you don't have, researchers won't stop poking holes around in your website or app, right? You can't stop that. You cannot say, hey, I don't run, why are you wasting your time and asking me to pay you for the bug that you have found? That's a valid statement, but they are there, it's internet, everyone can do what they want, right? From a researcher point of view, it comes to like, hey, they found something, they're not able to contact the right person in the company and it's a critical bug, it's getting ignored, it's not getting fixed, so they think because it's a critical bug, the right way to go about it is writing publicly about it, right? Versus for an organization, it's like, hey, writing a full disclosure becomes a problem, right? I don't want people to write about what kind of bugs people found on my application, right? Bombarded with simple issues, people threatening and bug bounty hunters, your logs got lit up, believe me, like people's gonna run all kind of scanners to do all of that, okay? You can't close high critical bugs in a timeline, right? In a few days, you cannot do. How would outside world react to that? Hackers discuss vulnerability or they sell on the dark web, so you think, hey, not having one is better because I don't know if they sell it outside, right? How to go about launching one? So we have talked about consideration, we have talked about fear and concerns, who does it applies to, and the dark side of not having one. To launch one, I'll just quickly rush through because I have just 10 minutes left. So you have seen a demo of how it looks like the automated way, but a lot more goes in without that as well, right? The first thing is the ingredient itself, like you need to have a platform, you have to engage researchers, to set up the workflows, how would you try it, all of that, and how would you pay, right? So that's a 50,000-feet view of what needs to be there in a bug bounty program. If I funnel it down for you, a 30,000-feet view is where you want everything operated. Who doesn't want to be a rich rich where everything happens all by itself? To do that, to build that kind of an automation, what you need is a communication channel, a ticketing system, well-communicated SLA because engineering team do not have understanding of how critical the bug is, and you have to get, depending on the RC, or the remote code, or the command execution, you want to get it in a few hours' fix. So this has to be set up with your engineering team as well. No one should have access to your bug bounty tickets as well apart from the security team. What's the workflow? The thing that I showed you, I know I'm a bit rushing through, you can catch me offline, but I just want to give you an idea and cover the whole set of slides. So workflow, what you need to have. So what I showed you is one way to have it, not the best way or not the right way. That works for me, may not work for you, right? How would you set up things with payments team, logistics for bug bounty, buy-ins from legal PR team, measurement of KPIs, how successful is your program, right? Evangelization. So the biggest thing is, before launching one, you want to go, if you're responsible for security in your team, you want to go to leadership, hey, we want to launch a bug bounty program. Now, these are things they are concerned about. You should have answered to these things before reaching out to them, okay? So this image depicts what their concern is. How would we handle all the attention? What if people, instead of reporting exploit vulnerabilities, is it good to ask people to exploit a system? Like, think of this, instead of your DevOps shoes, think from a CEO perspective, would you want that? That's the leadership problem they have, and you have to make them comfortable before launching one, right? The precautions, if you can't patch things within a defined SLA, do we need a formal one or if someone submits, we'll pay them out? This becomes a problem because if you have bug bounty program, you have defined out-of-scope, in-scope vulnerabilities. If you don't have one, they can do whatever you want and you're gonna be in a bad shape, right? Why can't we do with third-party security testing companies? Does it put a target on my back, right? If you could give your leadership team confidence on these things, they can help you to understand how does they value infrastructure importance in the organization, and with the budget, obviously, right? Finance team, India specific, okay. Finance teams work in a very standard way. It's been there for last, I don't know, a couple of decades. They work for everything. They have to give money out. They need a PO invoice or anything. Now you're saying, hey, you have to give a guy who we don't know. We cannot identify his validity. Couple of thousands of rupees, right? Good luck setting up with that, right? How would you validate to searchers? If I have given him money, how do we get a receiving thing from a researcher that they have received and they are the right person to receive? Like, this is a typical finance mindset. You have to convince them to have bug bounty program too, right? How do you verify the person who submitted the bug and who's sent his account details are the same person? Do you pay in dollar or INR depending how many countries do you work in, right? You need Pankard details. Where will you store the Pankard details? Tax deduction, budget utilization. So it's like, for finance team, these two images depicts what they worry about, what their concern is, and how do you help them to fix these things that, hey, you know what I've taken care, I can catch hold of this rat and that dog, right? Security team, preparation is really important, right? I'll quickly rush through. The point here I'm trying to say, before launching one, you should have fixed all the known bugs. If you haven't, you should have planned on how to handle the PR incident that can happen for a non-fixed bug, right? You need to have an awesome monitoring in place. That image depicts clearly. You don't know what can go wrong. The point is how you can plan things, not prevent. Detect things and plan things that if they go wrong, you'll get to know, okay? Automate things as much as possible. Legal PR team. So again, the image that I talked about, someone wrote on Zuckerberg's wall saying, hey, your team is not able to understand the security issue and here's a proof. This is important because this protects your company in a really good manner. Whether you need to have a cybersecurity insurance. Yes, that's a thing now. And how would you handle PR incidents, right? Logistic issues. Now, we launch bug bounty program, but your Consurgers Service or your admin team cannot be sending 20 goodies every week. You need to have planned that, set up that process completely, right? Just rewind. You've got a leadership bind. You've got budget approvals. You've got financing to fund your things. You have sign off from legal PR team. If things go south, how would you handle? You have taken care of logistics, rules, scope. The security team has taken care of. You have an automated platform to take care of things. Now the question is like, fine, the demo was good, but after this whole theory, it becomes too much. Like, why do I need to manage? Like, I can go with all those commercial platforms, right? My answer to that is why not, right? It's a one-time thing where you do invest as a one-time activity, okay? Now, after, I tell you, it's gonna be a weak effort if you want to do it, right? I took around 20 days to, because I was exploring G-right cell, versus a commercial platform where it's a turnkey solution. You get out-of-the-box reporting, but you've got to pay a platform fee. For every bounty that you pay, you have to give a cut of 20, 25% to the fee, to the platform, all of that, right? So if I have to summarize, I'll say, it's like, do I want that? Damn yes, okay? But having that, can I maintain it? Question for you to ask, if you could maintain it, go ahead, non-shopping. Versus, should I buy a Model Tesla 3 for $50,000? Versus that. A bit of exaggeration, but I hope you're trying to get the point, right? I'll skip through this. I have do's and do nots where you, I'll just say two things. You need to have your scoping done properly. What's in a scope, what's not in a scope? Else you're gonna have an awesome time, and in a bad way, okay? You need to have awesome monitoring in place for everything, right? Do not have your WAF enabled on bug bounty pages because people will be submitting payloads which are attack vectors and WAF gonna block all of it. So plan around that, right? Don't expect people to read your policies, understand how should they go about it. They're gonna go all berserk. You have to figure out on how you're gonna handle all of that, right? To summarize, if you have a security team like this, or you don't have one, because it's as good as not having one, you're gonna end up doing that in a bug bounty platform. It's just gonna be burning your company's money, right? Notes, I'll just say, prepare well. Bug bounty, understand the importance of bug bounty. It's not cost-effective for penetration testing. If you think of hiring a bug bounty program, understand properly what your hiring strategy is. Like at first it looks good, but it's a gray area. I won't say yes to hire or no, not to hire. You have to plan. I can give you inputs on what to do, what not to do, later, and it does require effort technically, financially, human resources, whether you have commercial or this, because if you have a platform, you're gonna say valid bug, not valid bug, respond to him. That's what you're gonna do, regardless. You build or you buy, right? So it takes investment, and are you ready for that investment? Not financially, right? That's all I had. I'm up for question, I hope I'm in time. Thank you. Any questions? So say for like a regular-sized startup in any sector, would you recommend that they go with a third-party bug bounty platform, or in which place would you recommend that they make? So as I said, this slides the peg. So if you could afford that, yes. If you think as a one-time investment, you need to figure out on how to automate. Let's say if you're an organization, you don't have JIRA, you need to find a way of how to do what I've done, right? If that's too much, yes, you can go ahead. So I'm not saying the needle moves, this is better, that's better. That depends, your size, the time you have, how fast you want to go to the market, what's your budget? So, yeah, sure. Hi, at the start you mentioned that you received a lot of issues, and somehow you managed to categorize those issues. Yes. How did you manage to do it at the start of it? Sure, so just to give you guys an idea, the start of the program, when you say, hey, you know what, I'm launching a bug-oriented program, I'm gonna pay you out this much, there's gonna be a flood of bugs that are gonna coming in, valid, invalid, all of it, right? The point was, if someone is submitting, hey, you have trace option enabled, or option enabled, or your Apache version, this is visible, you don't care about that. Versus someone is saying, have on an XSS, SQLI, remote code execution, all of that, right? Now, so that's what we did an automation in JIRA, hey, if these lies in these kind of categories, let's put them as P4. I may look at them because I've defined an SLA, P4 I look in, let's say in a week's time. P0 I look in few hours, few minutes, P1 I look in couple of hours or a day's time, okay? So how do I handle is we did categorize in terms of how do we filter out those bugs and put them as a priority as P4, so not a problem to look at right now. So that was our logic of saying, hey, these bugs I don't look at, and JIRA puts them as P4, so we don't look at them. So the way it used to work with us is when we open a JIRA dashboard, we have P1, P2, P3, P4 with aging, when it came in, all of that, right? What our focus was P1, P2, and P3, right? This is something I can look. That's how I did, right? I'm not saying that's the only way you could go about doing all the way you want to. Yes, so all this automation that we did because we had JIRA, so either I had to build something or I explore JIRA, right? So I said let me explore how can I explore JIRA in a good way. I found all the things that I could do in the tool that I build, or anything that any commercial platform has where you have a timeline, comment section, sending response, assigning it to people, all of that existed with JIRA, but for a general person, JIRA is just a ticketing system. We thought let me explore how can we do it? So all automation that we saw, we did it in JIRA itself. Yep, you had questions, right? So for example, if there is a red team. Okay. So the responsibilities which they will have, so is there any difference between the responsibilities between the red team as well as in the bug bounder? Yes, there is. See, as a point, red team does act as like a bug bounty hunters, but they know they don't want to flood your system, they want to go ahead and see how far they can go to exploit system, being undetected, but they just don't want to say then, are connected with tons of scanners and flood you to see what works, what doesn't work. They have an understanding of what methodology to follow to go about exploiting system. Bug bounty hunters, because it's a thing now, people run scanners, people run so many things, they see, okay, in one platform someone got rewarded. So like last talk showed you, a key put up in GitHub, one of the companies paid $7,000, the other company paid $15,000. Now, would a red team do it? Probably, probably not, but it's something you should have monitoring in place regardless, right? Bug bounty hunters is like, okay, you know what, I found something, pay me. So the idea of what red team does versus what the mindset of a bug bounty hunter is different, they just want money. The easy, simple bug which can make them earn money is something they look for. While red team is like, how can I sophisticate my attack? Go ahead and exploit system. In your experience, has an employee or ex-employee ever abused the system? Sorry, come again? In your experience, has an employee or an ex-employee ever abused the system? Like they know the vulnerabilities, and then? People do it all the time. You've been able to catch just kind of issues? Yeah. So that's what I'm saying, the point of while you do it for this, or you do it for something else, right? How do you build an awesome detection system? Okay, because what you don't know, you don't know. The point is, hey, I'll just give you an example. You say one of the talks that was today, right? Talking about login OTP, right? Now the point is, ideally, no one can exploit my OTP, right, or no one can log in via my OTP, bypassing an OTP flow, logically, right? That's why I say that security is all about exploiting the nuances. Now, if someone has a valid OTP in your DB and is still logged in, has a session, that's a problem, right, but you'll say, logically, that's not possible. I agree, but security is all about exploiting that. Now, can you put an alert around that? Ideally, you shouldn't get those alerts. You're putting alerts like, hey, this won't go wrong, definitely. But put up an alert, if it ever goes wrong, how do I detect it? Can someone sign up with the invalid phone numbers? No, because they have to fill an OTP, but if you find someone signing up with less than 10 digits in India, let's say, send it up an alert. You should, the point is, how awesome detection system can you build to catch all of this? If you don't, you're like, hey, my security team would do it, my bug-bound hunters would do it, that's a wrong mindset itself. Any other question? Cool, thanks.