EP114 Minimal Viable Secure Product (MVSP) - Is That a Thing?

Security. Hi there. Welcome to Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. You can also find us at cloud.google.com/podcasts. If you like plural podcasts, you should check out the other podcasts that we have available there as well. A lot of great content coming from the cloudcast world. If you like our content in particular and want it delivered to you piping hot every Monday, please do hit the subscribe button on your podcasting app of choice. You can follow the show and argue with your hosts on Twitter as well. twitter.com/cloudsecpodcast. Finally, I would be remiss not to mention we have an active presence on LinkedIn as well. Anton, we have something somewhat cryptic today. We have the mysteries of MVSP. Do you know what the V stands for? What does the M stand for? The P or the S? It's mysterious all around.

It is indeed. And it's also a concept that when I first learned about it, I realized that it should have existed. And it's something that I felt very natural kind of affinity to. Tim, on the other hand—

What did I feel? How would you describe my reaction?

You were mildly allergic to it. Don't think peanut allergies, think more of like maybe cat allergy.

You know, I am allergic to cats.

Yeah, me too. So I think it's the— it's— that's why I use the analogy. So it's not like anaphylactic shock, strong allergic, but more like sniffles, you know, like you're not happy to see a cat.

No. Well, I actually really like cats. I think cats are delightful, but I try not to spend too much time around them. And I think this concept is better than a cat. It's less likely to make me sneeze, but I definitely had some skepticism about why this particular letter was welcome amongst the others. And so I think our guest today actually did a really good job of standing up under fire and defending why this was a valuable effort. So perhaps without further ado, let's welcome to Today's guest. Today we are joined by Chris John-Riley, Senior Security Engineer here at Google, and kid you not, his title in our internal system, Technical Debt Corrector. Chris John-Riley, thank you for joining us. We're talking about MSVP today. I'm a PM, listeners, when I'm not recording the show, and I know what a minimum viable product is, an MVP. What's an MS— MVSP? I can't even say it. What is this?

It rolls off the tongue. It really does.

It does.

So let me interrupt very briefly.

No.

This is basically a fun intro for Chris specifically, because before this, I was excited about this. And I was like, what a cool concept. You really need it. MVSP is awesome. And Tim is like, what are you talking about? So, you kind of have like a— I mean, we don't have good cop, bad cop, or good Googler, bad Googler, because we're all good. But we have like a wild optimist, me, and somewhat of a skeptic, Tim. And a skeptic. And it's by chance.

So, what's this S doing in this PM phrase? What are you doing here?

We want skeptics, right? I mean, because that's who really starts the conversations and really drags out kind of the value of these things, right? If everyone's overly optimistic, it kind of gets boring after a while. So, MVSP is designed to be the security in your MVP, right? It's designed, it's tightly scoped to business-to-business enterprise products and services, but it's really designed to be that minimum baseline for your product, right? If you're developing a new product and you're going and coming out with your minimum viable product, your MVP, this is the security elements that you should expect to be in there, right? This is the minimum amount of security that you need to put in place for a business-to-business enterprise-grade service for someone to look at it and say, that reaches the minimum bar, I'll consider using this, right? Certainly, there's a whole lot more you can do beyond the minimums, but there has to be a lowest bar somewhere where you say, you must be this high to ride, right? Everything below this line, you know, we're not gonna class this as an even remotely secure product. And that's where MVSP comes in.

But so, wait, so this is like, if I'm shipping, I'm looking at some IoT devices, if I'm shipping a camera, and then the camera doesn't have login authentication, anybody can watch what's going on. Like, that's something that shouldn't pass the bar, right? Like, it's a— sorry, it's a consumer product example, but like, This would fail the MVSP bar because it doesn't have auth, for example. Yeah.

I mean, if you're shipping this as a system for enterprise and it's going to protect someone's data center, you'd expect it to have single sign-on authentication and all the relevant controls to be in place. You'd expect someone to have done a pen test of it. You'd expect there to be the ability to understand where that data flows within systems and things like that. And those are the kind of controls that we measure in MVSP.

Okay.

So one thing you said here, one thing you said here that stuck with me is you said this is for B2B enterprise stuff. And then Anton pops off with this example about video cameras. I think that illustrates exactly what I was going to say, which is, don't consumers deserve secure products too?

They do. And I think that's definitely an interesting space where MVSP and certain controls can work in the consumer space, right? We try and aim it towards business-to-business and enterprise because they're a different playground, right? Let's take a cloud example here. Google Workspace is an enterprise product. It needs to be secure. It needs to protect enterprise. As a result, you can put controls in place that protect enterprises beyond what you can do with something like Gmail, which is a much more consumer product that has to be open and available to everyone. How is someone in Sub-Saharan Africa with Android 2.4 on their phone going to use Gmail if you say you need TLS 1.3, right?

Sure.

There's differences in the control set. And as a result, we try and say MVSP is designed for enterprise. If you can use it for your consumer products, great, but it might not be the sweet spot, and you might not be able to get 100% coverage.

Well, I agree, that would be probably hard to ask my dad to set up, you know, mutual certificates to do Gmail. That's fair.

Okay, but so then there is another possible kind of like a, I guess, an attack or maybe criticism or question of this. Surely there are some kind of compliance standards for a bunch of business enterprise stuff. Even if you look at something as vanilla as PCI DSS, you would know that to build a web app, you have to have this thing and that thing. And there's also this whole ISO family, 27001 and others. So, isn't the job of setting a minimal bar in the hands of regulators and some kind of faceless bureaucrats in Europe? I don't know, no offense to people there. So, after my rambling, the point is, why do an MVSP if there are already compliance standards?

There's a couple of reasons. Things like ISO, SOC 2, they're great, right? ISO tells you how to do things but doesn't necessarily prescribe what you need to do. SOC 2 is 6 to 12 months, depending on what your timescales look like, which don't always meet with production timelines for new products. And the industry has a tendency to review security at the vendor level, right? At the enterprise level, right? You don't necessarily have a product that is SOC 2 compliant. You have SOC 2 compliance that covers your development infrastructure and things like that, but it doesn't measure the product. And this is where MVSP differs from a lot of those kinds of compliance regimes, where it's designed to measure the product.

Mm-hmm.

So, if you have 15 products, you have 15 different reviews for MVSP to say these products all meet MVSP, rather than something like SOC 2 that vaguely stamps and says, you're doing all your processes right. If you follow all your processes to the T, then you will meet all these requirements. But maybe 3 of these applications don't meet the requirements. That doesn't mean you fail SOC 2. It just means that you have some gaps in your product. So, it's kind of a sea change in that we should look, I thought we should look beyond just measuring a company as a whole and saying, you're secure. Large enterprises have multiple products across multiple different PAs with multiple different maturity models. And as a result, you're going to get different results if you look at different products within their ranges. So, MVSP kind of fits in that niche where it says, this is the minimum we would expect of each of your products to be considered as secure.

Let me ask a question that seems dumb, but is a very PM way of looking at things. Who's the list for? Who's meant to look at this list and say, ah, yes, I have met the SBAR?

Ah, let me do the podcast thing and say, thank you for asking that question. It's for, I mean, I'm going to say it's for everyone, right? But realistically, the way we designed it to be used, and by we, I mean the working group across Google, Salesforce, Okta, and 18 other companies who are in the working group right now, probably 22 by the time this podcast goes out. But the way it was designed was RFP processes, better quality vendors in results in lower overhead for due diligence processes. Also contractual languages, meaning that when you get to the end of that due diligence process and someone's signing a contract and the contract says, this vendor must keep logs for 60, 90, 120 days. They're not going to turn around and go, we don't keep logs. That's a control in NVSP. If you made it through RFP, then you should be able to agree to these controls at the end. So, it's designed to reduce that overhead, but also, it's designed to measure new products, measure acquisitions. Anywhere that you can put in 25 easy-to-answer controls for a product and say, good or bad, you can use this for acquisitions, you can use this for investments. Whatever you want to use it for, you can usually try and shoehorn MVSP into it. But certainly for us, better quality vendors in through RFP processes, and then build on those controls as the groundwork for more advanced controls.

So this makes sense. And I want to go back briefly to your compliance response, because wearing my PM hat, even though I'm not a PM, but maybe I have a PM hat somewhere, I sense the need for this, because in my PCI DSS days, I've seen a lot of people who try to attach a PCI label to a product or a platform. And people with PCI literati would say, wow, this is dumb. PCI is not about your stupid SaaS product. PCI is about an organization. So, you can't claim that your HR SaaS app is PCI compliant because there's no such thing. PCI doesn't do it. But the desire to do it was constant. And I've even seen SIEM vendors, actually, a good number of years ago, said, our SIEM is PCI compliant. And if you look at PCI compliance materials, there's no mention that anybody can certify a SIM. And of course, their SIM didn't accept credit cards because, like, it was too expensive for that. But the desire was constant, and going back maybe 5, 10 years, I recall people trying to certify products to PCI because there's no product-level cert like MVSP. So, I'm becoming even more of a fan. Sorry, Tim.

I mean, fans are great. I mean, we're trying to push the industry to embrace this new style of reviewing, right? We work a lot with third-party risk management platforms. platforms, a number of them are members of the working group, and their view is very much the historical view of, let's review the company as a whole and then give you a stamp of approval to say everything this company does is golden. And we all know that there's variety between products. Something you acquired 6 months ago is unlikely to be as mature as something that you developed from scratch within your system and have been working on for the last 15 years. Or the opposite is true, depending on which company. But effectively, measuring individual applications within a portfolio is gonna be a lot more effective than just giving a stamp the overall company.

So I think I understand where this is going. Could you talk about how we're using it here at Google/Alphabet today? Give us a story about what it's actually done for us, because I think I get it.

So personally at Google, I've been here just under 8 years, and I've been working on the vendor security program pretty much since day one when I joined. And part of that, there's a large dataset that we have over that period of time of good vendors, bad vendors. And we took a look at a large period of time, looked at the findings that we saw that were real blockers for vendors coming through our processes. And then we tried to distill that down to what's that minimum control that should be in place that would've caught this at the entry point, right? Because that's where you want to catch it, right? You don't want to ask someone to fill out 180 pages of questionnaire and then tell them no, right?

Right.

You don't want to say too many gaps here. You want, Quick, easy, let's get that answer, push left, let's move it to the RFP processes. And that's really one of those sweet spots that we're using it for, is pushing it towards the RFP processes and saying, if you're in this niche area of enterprise-to-enterprise services that we're looking at using, you need to pass this minimum set of controls. We can then make sure that before you get into the system, you're not going to trip over those easy-to-fix things that we sometimes find are real blockers. And then at the other end, we are using that in contractual language where we say, All of these controls that we have in our MVSP requirements at the beginning are also in the contractual requirements at the end, right? Do you do pen testing? Can you share the results? Those kind of things are all top and tail effectively at both ends of the process. And in the middle, the due diligence processes are very much, you know, MVSP is built on some of the data from our findings. So it helps us to say that you have the building blocks required when you're going through those due diligence processes, that even if there's something missing, right? Because Everyone's gonna expect more than the minimum. If you have something missing in those processes, you have the building block to fix that, instead of saying, well, we can't do this thing because we don't have any fundamental SSO support. So we can't solve this problem, or we're never gonna be able to, to try and avoid those blockers from appearing in the system. So that's how Google, Alphabet, and a number of different areas are looking at using that. And it's very similar across a number of members of the working group as well.

But so, wait, so then the problem that MVSP is trying to solve for the industry is kind of squeezing out woefully insecure products out of enterprise, right? Is that like— I'm kind of trying to— you never said this explicitly like that, but I'm kind of thinking of reverse engineering. The ultimate purpose of this is to make sure no business or enterprise buys utterly insecure crap, right, that misses a very low bar.

I mean, the flip side of that is We're helping vendors in that space understand where their key gaps are.

Absolutely.

So they can prioritize fixing those things because they are the highest priority things on your list. You know, if I was working for a SaaS provider now and I saw MVSP, even if I wasn't involved in third-party risk management and the viewing of other third-party vendors, I'd take a look at my products and say, wait a minute, we're missing 3 controls here. How can we prioritize addressing those so that we don't get ruled out in the RFPs in the future.

Okay. So, it's basically the batch that's like a top list, like P0s for a new product, for example. Like, I don't log—

Security P0s.

Yeah, but it's a secure— fair. Security P0 for a new product. So, for example, I don't log authentications. I authenticate, sure. I'm smart. I have authentication. I'm not like this camera example. So, I have auth, but I don't log any authentication decisions.

I mean, certainly, audit logging is one of the controls, and it's very important. I mean, MVSP has to be, I'm gonna use the word vague, but it's not, right? But it has to be broadly applicable to such a range of products that it's very hard to say, you know, your camera must log motion detections in an audit log, for example, right? There's gonna be certain sections of it where you have to say, you need audit logging relevant to your application. And there's always gonna be a level of, What does that mean for me? But starting that conversation, I think, is the important part because right now, people just look at their application and say, no one hacked us, we're secure, or no one hacked us, and we're used by the top 500 companies in the US, therefore, we must be perfect. And the answer is not always. You know, let's go back to the drawing board and make sure you have the building blocks for a successful product.

Okay. And so, is this list evolving? Is this like— so I've read the materials, and it looks like you've recently updated something, but this implies that it's not going to be shortlist that's true forever or for a good number of years. So, so what's there to evolve? It's the basics. No, no, no, it's— I think I can counter your argument about security being dynamic and fun by saying that, well, security basics really maybe aren't that dynamic. As a funny aside, yesterday we spent— well, yesterday compared to recording date, we spent some time asking a famous, you know, AI bot some security questions.

Mm-hmm.

And AI bot highlighted the critical need to have firewalls and antivirus. And I felt like, Tim, I'll show it to you later. But the point is that its thinking was mired in the past. But if you ask humans, a lot of security professionals about the basics, deep in my heart, a lot of them would bring up firewalls and AV.

So, you know, I'm looking at the list right now, and one of the ones that I love on here is do not limit the permitted characters that can be used for passwords. There's a whole password policy section here, but we all know that password policy is one of those things that has changed. And is likely to continue changing.

Yeah. I mean, perfect example is asking people to change their passwords every 30 days is something that was harped on for many, many years. But the modern take on that is, this is more likely to result in people changing it to something that is easily changeable, guessable. Between me and you, my girlfriend just puts the year at the end of it whenever they ask her to change it. People do, right? They change the number at the end of the password. This is not This is security theater, to use another acronym. It's not really pushing the industry forward.

Right. It's pushing it backwards because it kind of reduces security in subtle ways, but it doesn't improve it for sure. But so, how do you mix the dynamic versus God-given true things? Like, I'm genuinely curious.

And how do you get a group of 25 companies to agree on it?

Well, I mean, this was a 12-month project before release just to get people to agree to it. And there was a lot—

Only 12 months?

Well, there was a lot more companies involved in the discussions than actually backed final thing.

Ah.

Because, well, I mean, some people say, I really, I like this, I like the direction it's going, my legal team can't put a stamp on this because, you know, reasons. And that's something that more people have realized that this is something that's very, very important. But MVSP is gonna change. It's adaptable, we've designed it to be something that's reviewed on an annual basis so that we can take a look at the controls and say, is this really the minimum now? and take a look at the industry, talk to various different people and say, where does that minimum sit now, right? A perfect example is content security policy. If we'd have done MVSP 4 years ago, content security policy as an application protection would not have been on that list. It was not easy to deploy. 4 years ago, I don't even think it existed in a form that was usable or in a form—

Most people just deployed wildcard. It was bad.

Even if it existed, it was bad. Much respect to all the teams that spent years on this, on making it easy. Now, If it's not there, this is something you expect to be present in a reasonably mature and secure product, right? So, new things appear. I understand the idea of passwords are always gonna be something that people harp on, and, you know, you need all of these minimum stuff like audit logs and things like that are unlikely to change drastically over a period of time. But new technical controls are going to come and go depending on what we need to put in place. The flip side of something like CSP is controls that we needed to have in place, for example, to secure Internet Explorer, not to harp on Internet Explorer, there's a variety of browsers, but now those controls are not required because Internet Explorer is no longer a supported platform, and in the enterprise, you no longer need these headers to secure things, right? We've moved on, so things would drop off the list, new things would come on. And getting that set of minimums and agreeing that set, Not an easy task, right? Everyone says add a new one, but the answer is, is this really a minimum?

So that, I think, is really where the heart of my objection to this whole thing comes in. I'm a PM. I've been a PM for a long time now. MVP is not just about what's the smallest thing we can build. It's about how do we quickly get feedback from users and move in the right direction in an iterative fashion. It's kind of like Anton and Iman's ASO thing where you have an iterative SOC, MVP is about having an iteratively developed towards the right thing product, which of course you can make arguments about the problems there and hill climbing, whatever. What I want to pick at here is why did you choose S? Why is S the thing that's worthy to intrude on the hallowed halls of the PM's creed? And why is it not, for example, minimum viable resilient product? Minimum viable trustworthy product, minimum viable privacy-preserving product. Why S? Why does S get to join our party?

I mean, there's a couple of easy examples there, one of them being this was developed by security engineers and pushed out rather than privacy engineers or something like that. But also MVSP is, at least in the long term, likely to become something that's more of an umbrella topic of what's the minimum viable thing here, right? What's the minimum viable privacy, minimum viable trust, minimum viable measurement, right? And being able to morph the project into more of an umbrella project where you can say, this is things I'm interested in, in different areas. Security was where we start to see if this is workable, see if this is something that the industry can embrace and can use. And if it proves that it's usable, then in the future, there's opportunities for us to broaden that out and say, how else can we expand this, right? There's also opportunities for us to say, can we go beyond business-to-business enterprise products? SaaS products, for example. Can we cover specifically cameras? Probably not. But IoT devices, very possibly. What's the minimum viable secure or minimum viable resilience for IoT-style devices may also be something that's possible in the future.

So funny enough, I want to relate to the whole discussion before the start because it gives me a flashback to my Gartner days when we tried to write a paper that covers the mutually agreed or like a community definition of security basics, but for a company, not for a product. It was an agonizing effort. I'm looking at that old paper from 2015. Yeah, yeah. I mean, it was just agonizing. And then people showed up out of the woodwork with ideas like, no, no, no, no, IDS is a must. No, IDS is not a must. And, but so I'm almost like, I have a lot of compassion for the team building this, especially the consensus building part, because it's, um, it can be a real, uh, you know, cluster.

And I'm looking at the list of companies that on the contributors website, mvsp.dev. listeners, check it out. I love the .dev TLI. This is a good list of companies you got lined up behind this. This is like, I know I'm ragging on, but it's really impressive what you've achieved here.

Yeah. I mean, certainly, I'm not gonna say that coming up with a list of minimums is easy. It's not. And there's a lot of conversation on where those are. And yeah, we got it wrong in V1, right? I'll be the first to admit some of the stuff that we put in around passwords specifically was something that we felt the industry was ready for, and it was a minimum. But the feedback that came through to us in the latest revision was, this is unclear. No one knows how to do this. No one is doing this right now, at least not in a repeatable, measurable way. And it was specifically around regularly reviewing whether or not passwords in your system have been leaked through a breach. And the answer was, who do we pay to do this? You know, how can we get that list? What does that look like? We don't have a team for this. And as a result, even though we think it's a very important thing to do, do, it's not a minimum, right? Enough people came to us and said, we don't know how to do this. Where's the blog post? Where's the information that tells us how we can achieve this kind of thing? And it just wasn't quite there yet. So we ended up backing out some of those controls because it didn't make sense as a minimum.

That's really interesting. You would not believe the hours of my life I spent on trying to design a cryptographically secure mechanism for doing exactly that.

I can imagine. I could definitely imagine. Yeah. I mean, and there's ways of doing it without that kind of thing, right? Like app password use, right? App password wouldn't change. And there's ways of doing it, but the answer is, there's not enough ways of doing that that are just out-of-the-box, built-in, this is easy, you're done. It was hard enough that this was a problem. And it also gave us the opportunity, we brought in, for example, Salsa, slsa.dev, for people interested.

I saw that.

As a control in the recent refresh that we did October last year. And that's another Google initiative that is around build environments and talks a lot about trusted builds. And we put in level 1, which is the lowest SAWSA level.

That's like the mild, not the spicy.

No, it's, I think, the lemon chicken of spicy, right? But it's designed to be, where are we on this level of SAWSA? And the answer is, a lot of companies are just at the beginning of that ladder. A lot of companies are just at the beginning of understanding you know, I built this on a desktop rather than I built this on a reliable service. So, let's put that on the radar for people and say, level 1 is just understand what your build environment looks like. Once you understand, there's a whole maturity level on slsa.dev that you should really consider looking at. And as that becomes more common across the industry and something that we measure in more areas, you know, maybe we go to level 2 in a year or 2's time, right? And that idea of, A rising tide lifts all boats is one of the analogies we use, one of many, is that, you know, as we start to look at these controls and say, here's something new or here's a slightly more restricted version of this control, we should hopefully see the broader industry start to move upwards.

Well, with that, I'm afraid we are just about at time. So recommended reading and one tip for how to use MVSP. I'll allow the introduction of the S to boost product security.

Thank you. I appreciate it. Recommended reading. I'm sure Anton's got a book, right? You should definitely read Anton Chuvakin's book. If you don't, then you should write a book, and then everyone should read that.

Oh, don't give him ideas. I need him to stay focused on the podcast.

I would recommend Phantoms in the Brain. I'm blanking on the author. It is not technology-based in any way, shape, or form, but if you like how brains work and the weirdness in people's brain, that's definitely a great book to read. And I mean, a simple recommendation, have a read through the controls and just take an example product that you have looked at recently or your company does, and just go down that list and see where there's a gap, right? I think that you will truly, going through that list, you'll come up with something that's missing, and that's gonna give you a direction to head and a way to try to, you know, get on that first step of using MVSP in your organization.

I dare say that might give them a hint about where they could start collecting some technical debt. Chris John-Riley, thank you so much for joining us today. This has been truly a pleasure. And rarely, but I will say my mind has changed about the inclusion of the S. Thank you. Thanks very much.

Cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter @anton_chuvakin and @_timpeako. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security. Security.