Reduce Risk with Synack's Managed VDP Offering

00:05 Welcome to cut to the chase. I'm here with Jordi Tello, senior security analyst at Synak to talk with you about Synak's VDP offering. Jordy, can you provide a little background on your role here at SYNNAC and its relevancy to vulnerability disclosure programs? Thanks, Luke. So I've been at SYNNAC now for four years. I'm a senior security analyst and I work in the vulnerability operations department. So what that consists of is taking reports submitted by our researchers, verifying their accuracy, impactfulness, and other criteria before sending them off to our clients.

00:37 And I also have the opportunity to work with our responsible disclosure programs here at SYNNAC as well. Awesome. Well, I think this, brings me to a natural question, which can you just tell us what a VDP is? Yes. So a vulnerability disclosure program, also known as a responsible disclosure program, like those terms are interchangeable, is basically a program set up so that companies can receive reports from researchers and members of the

01:07 public in an organized fashion and then process those reports to fix any potential vulnerabilities on digital assets that the client owns. A VDP allows organizations to receive information about accessible vulnerabilities on their assets, which they then triage and validate to reduce overall cyber risk. Awesome. Well, it seems really easy, so why don't most organizations already have one set up? So it's actually a really great tool,

01:37 but it can be really hard to get going. You have issues such as your team's already being overstretched and now having to deal with reports submitted by members of the public who might not always submit stuff that signal you might get a lot of noise, a lot of non issues submitted to your programs. You also have to deal with communicating with researchers, keeping up with their timelines for disclosure and whatnot, and also we have to deal with tracking the status of vulnerabilities and seeing where they are along in the patch process.

02:12 Okay. That's that sounds like a lot. So tell me, how does a managed VDP with SYNNAC help address those concerns? A VDP managed by SYNNAC helps you not have to deal with the overhead of having such a program. When you work with SYNNAC, you're helping to reduce the cost of an incident, and this is true if you're setting up your own VDP. You might have a situation where a researcher on social media is trying to get ahold of anyone who can fix the vulnerability.

02:42 So they might report it to your customer service agents who might not be trained to deal with vulnerabilities. So then it's just trying to make its way up the chain, and you involve so many different people, and that kind of grinds operations to a halt, and then you spend money on people who are kind of not relevant to the solution itself. It's about being efficient, about having less people involved in these issues. It's also about

03:13 us at SYNNAC, for instance, taking on all communications with the researchers so that the client doesn't have to deal with that aspect. It's also about, you know, tracking the patch status of a vulnerability on our platform, so you don't have to worry about that. And when you have a VDP, you're also basically meeting a best practice, and in some cases, a requirement for certain entities. We have things like binding operational directive twenty o one,

03:43 which was basically like a piece of regulation put out by the White House that requires federal agencies to set up a VDP within a certain amount of time. We also know that frameworks like ISO twenty seven thousand and one, recommend the implementation of a VDP as well as the NIST Cybersecurity Framework, which is also recommending it. It's basically becoming a best practice. Awesome. Awesome. Well, it sounds like there's quite a need for VDPs. Now it's time to cut to the chase.

04:15 Can you get let's jump into the platform, and can you show us what one looks like? Yes. So I'm gonna take you through the process from beginning to end, like, all the way from someone a member of the public submitting a report all the way to it being patched and then verified by SYNNAC and the initial reporter. If we assume that we have a responsible disclosure program set up such as this one, what you're seeing here is our very own SYNNAC responsible

04:45 disclosure program. You will see our policy, a summarization of the typical vulnerabilities we accept, as well as what we consider to be typically out of scope and other guidelines. So a member of the public would start here, and then they would submit a report to us providing us a form of contact, and then describing the vulnerability in detail, locations, steps to reproduce the finding, as well as a recommended fix, among other information.

05:17 Afterwards, they would submit this finding to us, where it would then make its way here on the, Sync client platform. So now at this point, we can go to our assessment section, and we can find our demo vulnerability disclosure program here, our Sync demo VDP. So I'm gonna click here, and then we're gonna see details here such as the rules of engagement for this listing, any updates,

05:47 and then the scope for this listing. And then finally, we have other information like source IP addresses, firewall, a timeline for testing, as well as helpful information here, such as the assessment type, exploitable vulnerabilities found, and, and other information. So Let's assume that this was a finding submitted onto the responsible disclosure program.

06:17 This is an example of a report you might see, for instance. We have the description of the report, the impact for the report, the vulnerable location, an HTTP request if that's necessary or relevant to the vulnerability, steps to reproduce, and then a fix followed by some other information such as the CVSS for the finding, the severity of the finding, and then the patch verification history for the finding, the vulnerability history.

06:47 At this point, your team would evaluate this report, and if they've fixed it, they could then change the status of the report from pending review to closed fixed. Then they would give us details about how they fixed the finding here before submitting the verification request. At that point, we then on the back end see this verification request and

07:17 we usually give the initial reporter a chance to verify that the patch was completed before also verifying ourselves. Assuming that the report is correctly patched, the initial reporter would confirm with us providing a screenshot showing what kind of testing they did. We would then look at that, evaluate it, make sure it's sufficient before sending that back to the client and then confirming that the issue is patched. On our responsible disclosure programs, the types of issues we see on a day to day basis includes

07:48 stuff you would normally expect from the OAuth top ten, so cross site scripting, SSRF, remote code execution. We also have interesting findings. I think, in the last month or two, we've been hearing a lot about matrix bleed being exploited publicly. We've had researchers reporting stuff like that as well more recently. So yeah, I've basically taken you through the process from beginning to end of what a initial reporter would do and

08:19 then, like, what we would do on our side and then, like, the actions that the client would take on theirs. Jordy, that was an awesome overview of the Synact Managed VDP. Thank you so much for taking us through it, and I wish you an awesome day.