Why MSPs should care about vulnerability disclosure programs

What to look for in vulnerability disclosure programs

Sobel: Well, that's a key criterium. But what are you looking for when you analyze a vulnerability disclosure program? What are you looking for there to be to say, 'This is a good program'?

Slagle: I have selfish things that I'm looking for, that I think [are] better [for] the industry. For me, one of the bigger takeaways is I like to see bounties -- and we can talk about that because that's a part of it. That's a whole separate topic that I think we need to defer for the moment.

But I like to see that there isn't an NDA [nondisclosure agreement], because one of the things is that I want to be able to publish my research. Part of building that cred and that awareness of who I am, who the company is, and other things like that is being able to actually talk about the things that we found.

That being said, we want to talk about the things we find responsibly. So, I am not interested in releasing a zero day, basically, and getting everyone popped. But once a vulnerability is fixed and sufficient time has elapsed to allow the parties to patch or upgrade, I should be able to talk about that.

Other things that I'm looking for: I really would like [vendors] to define what's in and out of scope. Especially in the case of bounties, it doesn't do me a lot of good to spend a ton of hours basically developing a kill chain against something that you're just going to call out of scope. So, show me where the guidelines are of what you are considering part of your platform and that's testable and what's not.

Apple vs. Microsoft's vulnerability disclosure programs

Sobel: One of the reasons you and I started talking about this is there was a recent Washington Post article that covered Apple's vulnerability disclosure program. [The article said] Apple oftentimes accepts submissions, but then there's a perception that it doesn't do anything with them. What's your take, as an example of a big vendor, on Apple's vulnerability disclosure program and its engagement here?

Slagle: As somebody that does security research, I think Apple's program is great because Apple pays really well. I know a number of people that have made reasonably good money finding things like jailbreaks in Apple devices.

That said, you have to wonder what Apple's culpability is if it actually knows about a vulnerability, that vulnerability is not fixed, and then that vulnerability is later exploited. I realize Apple has like a 9,000-page terms of service, but at what point does Apple bear some responsibility for the outcome of that if it knows about and doesn't fix a bug?

Sobel: OK. So, let's contrast that with another large vendor to give people some thinking. How about Microsoft? What's their approach to this space?

Slagle: Microsoft pays very similarly to Apple. I think them and Facebook are probably the three highest paying ones out there. Microsoft is a lot more transparent. Microsoft allows its people to be more transparent and things tend to get fixed quickly because the company allows some of that transparency. If they don't get fixed, they tend to get published. So, Microsoft is not locking you behind, 'You can't disclose.' At some point or another, you're allowed to disclose.

Sobel: Gotcha. So, Microsoft favors transparency a little bit more. Apple, as is tradition for them, is a little bit more secretive. But both engage, pay, reward and have established programs.

How MSP software vendors' VDPs fare

Sobel: OK. Let's dive a little bit then into the IT services space, specifically as we think about the MSP players. How would you describe Datto's program?

Slagle: I think Ryan is doing an amazing job. Ryan Weeks is the CISO of Datto. I think he's doing a really good job of trying to define a good program. [Datto's vulnerability disclosure program] is solid. It's self-managed, so Datto has the chops to do it and is handling it internally. Datto has not yet published a bounty schedule. I've had some discussions with [Weeks] about that, and it all comes down to budget. When you're a big, publicly held company, they want to know how much money you're going to spend in this bucket. He has indeed informed me, though, that they actually are actively paying bounties. He just doesn't have permission yet to publish the amounts.

Sobel: OK, but [Datto has] obviously said that it will. How about ConnectWise?

Slagle: ConnectWise's bounty program -- and I've gotten permission from ConnectWise, because its bounty program is hidden behind an NDA. You have to be invited to it.

So, ConnectWise has two programs. ConnectWise has a VDP. The VDP is pretty basic. It just tells you how to engage, what's in scope and out of scope -- things I would expect. ConnectWise also has a bounty program. To be invited to the bounty program, you have to contact ConnectWise. I think at this point, ConnectWise will invite almost anyone if you ask -- but their bounty program contains an NDA. So, I'm actually not supposed to talk about the bounty program.

I've gotten permission from ConnectWise to talk about the bounty program in various places. ConnectWise pays, I think, from $100 on the low end to $2,000 on the high end, which is, I think a bit on the low side. But ConnectWise does pay something. The tradeoff is if ConnectWise pays you, you can't release. ConnectWise is holding those bugs. Without express written permission, you cannot release anything that you found about a bug you submit to ConnectWise's program. You just can't release information about it. And I'm going to go out on a limb and say you're not really going to get permission.

Sobel: OK. That sounds like that approach is unusual as a researcher.

Slagle: It's not super-unusual. There's actually a good number of companies that hide behind that NDA. I don't like it.

Recently, at my talk at GrrCon, I talked about this. I'm sitting in a room full of security researchers, some of which are new and trying to make a name for themselves. Forcing them to choose whether they want to publish and get the name or receive a small bounty in the end is a really tough position to put them in.

Additionally, to me, this is all about transparency. In the end, what I really care about with all these companies is, be transparent with us -- about what's going on, about the fact that I had a risk. It's like Schrödinger's bug: Was I vulnerable or not? And that NDA hides the transparency. So, I'm not a fan of it.

Sobel: OK. Fair enough. How about Kaseya?

Slagle: Kaseya's VDP is fairly standard. However, the language about bounties and what Kaseya is willing to do -- while Kaseya softened it a little bit, it was actually worse. I find it fairly hostile. It's like Kaseya is basically announcing loudly the fact that it's not going to pay you anything. And then, six lines above it, Kaseya says it's going to jump you through a bunch of hoops to accept a submission from you. So, it's like, 'You want me to do a bunch of work, but you're not willing to compensate me for any of that work.'

So, the end result is I think you're going to see two things. Either people, one, aren't going to security research Kaseya for vulnerabilities, which I think is what Kaseya hopes happens. Or, they're just going to release and they're not going to work with Kaseya. And I think that's kind of what we saw happen a little bit.

Sobel: OK. And how about N-able?

Slagle: I have found very little information online about N-able's program. Admittedly, I have not reached out to N-able, but the only [information] page is a security page that says you can email its PSIRT [product security incident response team]. And that's the only information I've ever been able to find about the program.

Getting information about VDPs

Sobel: I want to understand. Is it traditional that if you have a vulnerability disclosure program, you've published it and made that information easy to find?

Slagle: Not everyone does, but I think generally when you're the size of a company like N-able or Kaseya or ConnectWise or Datto, when you get to that size, it's very common for you to publish it. There's actually a defined standard for how to publish them. There should be like a security.txt, I think, at the root of your website and a couple other things that have become a standard for researchers to go to find, like how they can poke at a given website, specifically for cloud stuff.

Vendors should have VDPs

Sobel: OK. You said something there I want to go a little bit further into to help people understand. Where do you lump sizes of vendors and what the expectations should be? It was easy for me to pull Microsoft and Apple. They're really big. This cluster of four I just went into are kind of a midsize [category]. Where do you draw the lines on expectations of these programs?

Slagle: I don't know. That's a really good question. I've been poking some vendors, and there are several vendors in the channel that I think -- because of how loud I'm being, in particular -- are trying to build programs. And I think that's great. It's a couple hours of effort. There are good templates you can use to do it. So, in the end, it comes down to a couple hours' worth of effort; an email address, security@, which should always exist; and then somebody to monitor the reports that come in.

So, the bar to do it is pretty low, but I have a lot more sympathy for a small company that doesn't have anything than for a multimillion- or billion-dollar company.

Sobel: Sure. But it's definitely then tied to revenue. It would definitely be the way of looking at it. And a bit of maybe the duck test. You know it when you see it.

Slagle: Presumably, all four of those companies are big enough to have CISOs. And if you have a CISO, then there's really no reason they shouldn't exist.

Sobel: OK. If you've got somebody who is in that role, one of those outputs should be that program.

CISA's new guidance for MSP clients

So, as we think about this, one of the guidance that have come out recently, and I've been talking about it, is the new CISA guidance for MSPs' customers. It has lots of stuff around disclosures and bills of sale. What's your take on that particular set of guidance?

Slagle: From my standpoint, as somebody who's doing most of the things that CISA is asking us to do, it's a goldmine. I just literally told our sales and marketing people, 'You need to be asking customers to get this document. Send it to them and ask their current provider if they're doing these things, because we are.'

I think [the CISA guidance] is fine, if not a little bit misguided. I do believe that there is a co-ownership of the responsibility there and that the small and medium-sized businesses should care about what their MSPs are doing security-wise. Whether I think that particular thing, that particular document, will be effective, I don't think it will be. If you're clued in enough to actually be reading this document, you're probably already doing the right things anyway.

What vendors, MSPs need to do now

Sobel: Fair enough. All right. So, the last bit here is thinking about, again, MSPs, IT services companies. What's the thing you want them to do in regard to this? What's the action you think that they can take that will make a difference around bug disclosures, vulnerability programs? What do you want them doing?

Slagle: Be more transparent. One hundred percent, that has been my argument this whole time, is that what I need from an industry is I need transparency. I don't need these weird closed-door [discussions] that go on between Kaseya and ConnectWise because there's a vulnerability that happens somewhere. I don't need the release notes for your product to not call out the fact that the thing you just released [has] a security vulnerability and I have to go to this other site to find out that I really do need to apply this patch because it has security holes. It's that simple.

I mean, I would love to see bounties. I would love to see bounties at a reasonable level. And I would define 'reasonable' for a company the size of somebody like Datto or ConnectWise to be $10,000 on the high end -- $8,000 to 10,000. Based on research, I think that's pretty reasonable.

But more importantly, it's definitely the transparency. Just stop pretending you don't have bugs. Everybody has bugs. Stop pretending you don't have security issues. Everyone has security issues. Whether or not you tell us about them, they exist. So, be transparent. Tell us that you had a problem, tell us what our risk might have been, and tell us that you fixed it. And that's all I need to know, because that's how I assess third-party risk.

Sobel: It's interesting, because what you're saying parallels what's being called for by lawmakers. That's happening when I look at the federal level. That's exactly the echo. It's transparency. So, is this a criterium that an IT company, MSP, should be asking of any vendor that they work with, in your mind?

Slagle: Yeah. Actually, The ASCII Group spun up a security committee, and one of the first outputs from that committee was a document of questions that they feel MSPs should be asking their vendors. And there are a lot of questions around this and transparency.

Sobel: I covered it on the daily show, because it's exactly that. I said that was exactly the work product they were working on. Well, cool. I think you've given people a lot to think about here. If anybody wants to reach out to you, how do they get in touch?

Slagle: I'm on LinkedIn. You can also email me [email protected]. I tend to be pretty responsive in either of those places.

Sobel: Awesome. Thanks for coming on, Jason.

About the author

Dave Sobel is host of the podcast The Business of Tech, co-host of the podcast Killing IT and authored the book Virtualization: Defined. Sobel is regarded as a leading expert in the delivery of technology services, with broad experience in both technology and business. He owned and operated an IT solution provider and MSP for more than a decade, and has worked for vendors such as Level Platforms, GFI, LogicNow and SolarWinds, leading community, event, marketing and product strategies, as well as M&A activities. Sobel has received multiple industry recognitions, including CRN Channel Chief, CRN UK A-List, Channel Futures Circle of Excellence winner, Channel Pro's 20/20 Visionaries and MSPmentor 250.