11 ms·

Minimum Viable Secure Product

173 points by jot 3y ago

ChrisArchitect 3y ago
(2021)? Some previous discussion: https://news.ycombinator.com/item?id=29100400 https://news.ycombinator.com/item?id=29100400
ChrisMarshallNY 3y ago
I like the idea, but I'd be skeptical that it's practical for very small companies. That doesn't let them off the hook, but all that process overhead can be a killer. I worked for a company that was PCI DSS, and it often made it impossible to get any work done (to be fair, it had more to do with how they implemented it, than the standard, itself). But I agree that security needs to be Job One for everyone, regardless of size.
- janosd 3y ago
  A bunch of this stuff you have to do anyway if you want to be GDPR compliant. It's unfortunately not as easy to launch a new service these days as it used to be. But maybe that's not a bad thing given how much data we are being asked to share nowadays.
jawns 3y ago
While this may appear to be an altruistic consortium of security-minded companies trying to help startups do the right thing, my skeptical take is that it's primarily a way to drum up business, which explains why the contributors list largely consists of vendors that help you check these items off your list. Google (one of the main sponsors) and other cloud-hosting vendors can essentially say, "Sure, you can cobble all of this together yourself -- or you can buy our services with much of this already baked in."
- tptacek 3y ago
  I don't think Google covers a lot of this stuff.
- dadrian 3y ago
  If there's any vendor in the sponsor list with an ulterior motive, it's Vanta.
  - no_wizard 3y ago
    They all sell products (via cloud offerings etc) that pertain to this list, why call out Vanta in particular?
tptacek 3y ago
The name is too cute, and actively misleads. You can't call this a "minimum" anything; it's an opinionated list of controls that several of the most savvy security teams I know don't uniformly implement. Just off the top of my head, things that aren't even universally seen by practitioners as good things, let alone things everyone does as a "minimal" baseline: * On request, enable your customers or their delegates to test the security of your application * Implement role-specific security training for your personnel that is relevant to their business function * Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18 --- LOL to this whole line item. * Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored There is then a longer list of controls that I think most practitioners would say are good things, but that aren't always P1-prioritized (for good reason, to make way for more important things). CSP headers, SLSA level 1 builds, media sanitization policies; these things are situationally important. I think an opinionated checklist is a fine thing, but when you call something the "minimal viable" standard, you set yourself up to explain how lots of well-run companies are viable without these things.
- prepend 3y ago
  This is about as accurate in naming as a “minimal life list” that includes things like living debt free and having a $1M insurance policy. Or closer to recommended practices. As these are definitely not minimal since there are many products that won’t meet them yet are still viable. It’s also funny how cyber consultants seem more apt to add “required” thing that really tend to increase their bill hours. Like how accounting firms love Sarbanes Oxley and like to add in new rules that they claim are necessary.
  - reidjs 3y ago
    What is Sarbanes Oxley and what’s it got to do with accounting firms? Edit: court ruling (shortened SOX) has to do with security compliance for public companies. After Enron and other scams https://en.m.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act https://en.m.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act
- 3y ago
belval 3y ago
> Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18 > Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses > Ensure data localization requirements are implemented in line with local regulations and contractual obligations Whoever wrote this must be so irrationally out of touch with the startup space (or thinking of older billion dollar unicorn startup) to think that an MVP needs to do any of the above. I wouldn't care about GDPR until I have a somewhat strong EU userbase. Try to respect the spirit sure, but it's not like it will be enforced on a small business within it's first few years of existence. Localization for an MVP is even more out of touch. Make an English US-centric version first (I'm not even American) put it out there and work on localization once you've had some success.
- b112 3y ago
  Indeed, some of these things take months of work to complete, to expect a startup with a couple of people, working part time, to dedicate time to these is a startup death sentence. And really, most of them don't provide security, they're a checklist. Checklists don't provide security, they provide (sort of) accountability.
  - habinero 3y ago
    Frankly, security should not be the top priority of a small startup, unless you deal with extremely sensitive data. I'm not sure it should make the top five. Off the top of my head, survival, product dev, growth, hiring and infra are all more important if you're just starting out
    - b112 3y ago
      Sure, but what if you get hacked, or defaced, or your client info gets out? It could kill you too. It's a balance.
    - evantbyrne 3y ago
      There are certain things that are very difficult to implement if you skip them at launch. For example, encryption of 3rd-party secrets. CircleCI is a good example of a successful company burning themselves badly by treating encryption as an afterthought.
dogman144 3y ago
I’m a sec eng and worked at startups, I don’t love this list. Some of it is valid but generally it seems off target regarding how process-focused it is and ideas like startups doing data flows, vuln management and getting application-level logging done. You’ll get much more bang for buck for the product’s security by working on the enterprise and infra side - deploying EDRs (somehow not on this list?), tightening up Gsuite sharing and email settings, Okta (I see SSO on the list), anti-phishing capability, guardduty and sechub, a pw manager, getting on IaC early to support ops and sec goals, and a lightweight SlackOps infra for security alerts. Somehow mostly none of this is mentioned. The emphasis around the application seems misguided due to how (a) pragmatically it’s going to take much longer to get appsec controls and logs vs infra and enterprise controls/logs and (b) the vector in is usually Bob and Jodie in recruiting and HR getting phished, vs an appsec breach. Also, it seems to break the golden rule of security enabling revenue with acceptable risk trade-offs and pragmatic controls. All the process in here doesn’t seem pragmatic. The controls in here seem useful overall but not where I’d go at first to secure a fast startup.
- eganist 3y ago
  True as it is, not a thing you list here addresses the security of the product. Except for IaCs. And the site describes securing the product. Will edit with commentary in a moment. Edit: alright, fair criticism re business security controls given that the checklist's first section is specifically about business controls. And the rest should be focusing on automating those outcomes rather than just what the outcomes are. I agree that manually creating DFDs is just going to slow teams down, though it's definitely a capability that more security-mature or regulation-burdened organizations will need. When you're this early though, better to harden IaCs based on secure reference architectures up front and lint the heck out of code than to encumber all of ones processes with manual controls.
  - maratto 3y ago
    That's a valid point. We will address this in our upcoming work group meeting. If you're working for a startup, we would greatly appreciate it if you could try implementing MVSP in your organization and let us know which controls were difficult or problematic to implement. These controls can potentially be considered for removal.
thenerdhead 3y ago
Not sure I can get behind the idea. This is like an oxymoron. I get the heightened need for security, but this is not the way. Security is a journey, not a checklist.
andrewmcwatters 3y ago
Totally arbitrary. Some of the advice is actually bad. The only critically relevant pieces of information are the password guidelines and HTTPS-related bullet points, for which there are actual authorities to read, not this waste of time and effort.
glonq 3y ago
> A minimum security baseline for enterprise-ready products and services Sure, although minimum viable and enterprise-ready seems like an oxymoron to me. Step one: define MVP. Step two: add minimum enterprise security, minimum enterprise scalability, minimum enterprise legal compliance, minimum enterprise cost controls, minimum social responsibility ... Step three: why the hell is MVP 28 months late?
Conscat 3y ago
The checklist doesn't render correctly on mobile.
lexandstuff 3y ago
If this is the "minimum", I'd love to see what they left off the list. My minimum for a public-facing MVP: - All services use HTTPS to talk to users and each other. - High standard of password encryption (or prefer to use something like Cognito or Firebase). - Plan for GDPR compliance (not exactly security related, but in the wheelhouse. The GDPR grifters come out of the woodwork quickly, so you need all the popups and account deletion stuff from day 1 if you are releasing to the EU). - QA specifically for security: users can't access each other files, authentication controls work, etc. - Don't store or handle credit cards - use a vendor like Stripe. - Ensure all dev tools enforce 2FA where possible (GitHub, AWS, etc.). - A basic backup system. Then post-MVP, start working on the following: - centralised logging. - dependency patching plan. - etc
- seabass-labrax 3y ago
  > Don't store or handle credit cards - use a vendor like Stripe. Alternatively, if your customers will make one-off or infrequent payments, you might want to consider accepting cheques, which can be made electronically through a system like BACS (note that every country has different systems available). Cheques (checks) are a 'customer pushes' method as opposed to cards, which are a 'seller pulls' method. Accepting international payments makes transfers somewhat more difficult, and cheques always assume a higher level of competence on the part of the customer than cards do; however, neither are likely to be a problem for B2B products. > Ensure all dev tools enforce 2FA where possible (GitHub, AWS, etc.). Two things that are critical to remember are that 1: most forms of 2FA don't improve security and 2: many services will refuse to restore accounts based on trust or some other form of evidence if 2FA was enabled, where they would otherwise. Challenge-based forms of 2FA such as TOTP or FIDO are better than SMS, as latter can be intercepted in transit. Calculating the response to a challenge on a separate physical device to the one being authenticated is additional benefit that FIDO2 usually has. Side-note: if you need to authenticate customers, allow them to choose at least TOTP; try not to even provide SMS 2FA. As for the lack of account recovery, this can be a benefit, but only if you have robust procedures to make sure employees' credentials (like TOTP codes) are copied to sites accessible by other employees; this effectively means things like buying fireproof safes if you are doing it properly. Revocation of credentials by other employees is just as important as recovery. All this is to say that 2FA is not something that you can just toggle a switch for to make your company secure; it is worthy of a company-wide strategy.
mufti_menk 3y ago
Better to ask forgiveness than permission. Extra security not worth reduction to sprint velocity ime.
j45 3y ago
It was nice to see this kind of topic, reading the list felt a little higher level than I anticipated, even for a startup who is targeting enterprise sales. I would love to hear what others here consider important to make a minimally viable and secure product in a startup from the starting as a startup. How much of this list is hard needs, soft needs, beneficial, and nice to have preferences/interpretations? Many startups wouldn't make it to the start line fulfilling this list. If I could pick a solution architect's brain looking at this, I'd be curious to know what ways there are to satisfy these through architecture, design considerations, or using particular parts of particular platforms?
ed-209 3y ago
So Google wants it to be prohibitively costly to compete with Google. Got it lol
mrbungie 3y ago
A list of security recommendations about MV(S)Ps created by a consortium of pretty big non-startup companies. The joke tells itself. But seriously, I think the problem is in the name. This is not a set of best practices for any kind of startup but rather a public checklist that anyone looking forward to provide some kind of service or product to any of the contributors (i.e. Google, Salesforce, Okta, or even other companies subscribing to this extreme SecOps cargo cult) must comply.
motohagiography 3y ago
Interesting, but I'm having trouble thinking of a startup that was killed or even harmed by a security issue (outside cryptocurrency stuff). Anecdata-wise, startup graveyard stories don't seem to have being-hacked as one of their failure causes either, unless I'm missing some big ones. An old product attempt of mine was a threat model wizard that generated a simple deck with some very clear viz of the model and threat exposure addressed to all concerned parties - and then backlog issues and themes and epics for implementing or verifying the controls it implied. It reduced the checklist/risk assessment process to about an hour from the weeks of spreadsheet work that was a lot of peoples jobs, and it put security into the product/project dev process. Pretty much aha.io (the product management tool) but for security. What I learned from it is a) self-assessments weren't valuable to large org customers (who need to be able to say they were told by a 3rd party, so it's not like product management that way) b) the need of small orgs / startups was a standard compliance checklist to make standard assertions to potential customers as part of vendor onboarding, and a faster/better model didn't get them that standard. c) most security people trade on their insights, and codifying their ontology even just to speed it up undermined their leverage in their orgs. This checklist or something like it might actually meet the real needs of some startups who must make templated assertions to customers for vendor onboarding, but most startups would be lucky and probably pretty chuffed if they actually had something someone wanted to steal.
jwr 3y ago
Not a great list. Very opinionated, and much as I'm security-conscious, I disagree with a number of "minimum" recommendations there. This list looks like it was written by people who are not paying for anything, so they don't understand the tradeoffs, costs and compromises. I can assure you things look quite different when you are a solo founder running the business and you have to pay for everything. Technical stuff doesn't change, so recommendations like "Do not limit the permitted characters that can be used in passwords" still hold, but "Contract a security vendor to perform annual, comprehensive penetration tests on your systems"? Also, "Publish the point of contact for security reports on your website" and "Respond to security reports within a reasonable time frame" — I'm already spending too much time responding to "security researchers" trying to shake me by sending (rather silly and generic) "vulnerability reports". Some of them follow up by asking if they can "publish this on their social media channels" if I don't respond. I really don't need more "security reports" for my website.
- lelanthran 3y ago
  > This list looks like it was written by people who are not paying for anything, so they don't understand the TRADEOFFS, costs and compromises. That's the important word there (emphasis mine). I'm doing an MVP now for a client for a custom app (used internally by that client, i.e. only employers are users), and my recommendation for security is "I'll use a simple XOR symmetric stream cipher for now. We can switch to TLS[1] if the system turns out to be useful". Yeah, cut corners on other things as well - they just want to see how viable this thing is in practice. [1] While TLS is nice, certificate management becomes a pain in the rear for remote devices.
  - dgb23 3y ago
    So really it’s a prototype. Nothing wrong with that.
cglendenning 3y ago
The intent of a the "minimum" in MVP is to produce something quickly in order to learn what resonates with people who might actually pay you money for something. It would be useful to have a "detect my disasterous security vulnerabilities" scanner with various language plugins for go, dart, swift, whatevs that I can run on the source of my MVP so that I don't have to waste time reading a checklist. Does that exist? Dunno.
- dv35z 3y ago
  Are you familiar with https://snyk.io/ https://snyk.io/? Disclaimer: I used to work with the founder, he’s great.
andrewstuart 3y ago
Not really a fan of hijacking the MVP concept for something unrelated.
sergioisidoro 3y ago
I was hoping for something more like: * Check you're storing secrets safely and not in the code * Run a automated security scanner to check for the OWASP top 10 * Confirm your endpoints have correct auth/permission checks, and that all debug flags are off * Ensure databases are protected (eg. Not exposed to the internet or heavily restricted) * Enable 2FA for everyone in the company and use a password manager * Check what are the data protection laws and disclosure sla of your country
q-base 3y ago
Minimum Viable Secure Product, Minimum Viable Marketable Product, Minimum Viable Sellable Product. I don't get it. Why do we need all these additions? Perhaps it is me who does not understand the meaning of "Viable". MVP is not a restricted, well-defined end-goal. "Viable" means viable for your case. You can fill in whatever you want. It does not mean "Viable" without security or "Viable" without "Marketability".
- jjav 3y ago
  > It does not mean "Viable" without security But zero security is exactly what most startups see as viable. I remember one PM at a startup saying "Well hire a marketing firm to create flowery language for our website asserting how ultra military grade secure we are. And that's it. We're not going to spend a penny implementing any of that security geekery you people talk about."
benator 3y ago
I think a lot of comments here might be missing the point of this standard - it’s not specifically designed just for startups or to cover general organisation security (like EDR). It’s a product feature oriented checklist that should help short circuit some aspects of supplier security due diligence and establish a set of product security features that any B2B product with ambitions to sell to enterprise customers would benefit from aspiring to, and anyone buying can leverage. That means large multi-product businesses looking to ship an MVP for a new service as well startups with a bright idea but a possibly limited understanding of enterprise IT compliance needs. I’ve got some experience as Head of Cyber/InfoSec at a couple of startups/scaleups and I see this as potentially useful in a bunch of ways if broadly adopted. It establishes a baseline both for our own products and our suppliers, attests to stuff that actually affects how we integrate with and operate a third party product (ISO 27001 gives me no clue whether you support SSO, have viable logs that I can actually ship to the SIEM etc.) and hopefully simplifies both the due diligence we do on our suppliers as well as that done on us by our customers by allowing us to reduce a good chunk of the product feature questions to “does your product meet the MVSP standard”. There was a pretty useful discussion of it on the Google Cloud Security podcast a while ago: https://cloud.withgoogle.com/cloudsecurity/podcast/ep114-minimal-viable-secure-product-mvsp-is-that-a-thing/ https://cloud.withgoogle.com/cloudsecurity/podcast/ep114-min...
- Rapzid 3y ago
  I have been responsible for these controls in multiple startup and smaller businesses selling into Fortune 500, including setting up security "programs", and agree with everything you say. Ultimately it boils down to: > Convince whoever is asking you are following whatever process they are asking about so they can check a box. They call it security theatre for a reason. Of course if you don't want to be lying, well, you gotta implement a lot of this stuff as at least written policies. Also, auditors have a tendency to ask for evidence...
- dogman144 3y ago
  As head of security, did you ever try to get devs to remediate a ton of appsec vulns during early days, or ask them to build data flow diagrams? My criticism of this is that you can secure the product with solid defense in depth on the enterprise/infra side in a way that is: - minimally invasive to devs - aligns with what is likely there to slot into - what SAST tool can you pay for that early on at a startup, let alone slot into a non-existent DevOps pipeline. $1-200k SIEMs existing at a series A/B that prob has 1-2 sec engs? - get a WAF for a bandaid fix for the appsec problems initially until you can hire product security folks
camgunz 3y ago
Isn't this just a ploy to get decision makers to think they need to use these services/platforms to achieve MVSP (and to think MVSP is a thing)? Man the internet really gentrified in a gross, banal way.
dgb23 3y ago
> Cross-site request forgery. Example: Accepting requests with an Origin header from a different domain English is not my first language and I’m not a security expert, but this description seems a bit misleading. The “Origin header” part should be left out. You don’t check where it’s comming from (you can’t know). You either send a unique token back and forth, or you defer the issue to the browser (cookies with Same Site strict/lax). And it’s not “requests”, it’s “unsafe requests” AKA mutations (POST, PUT, PATCH, DELETE). It’s not just a nitpick. If your GETs are not safe, you might cause deeper issues.
Woodi 3y ago
What a brain deadness... "Maybe secure but must include HTTP.*"...
tguvot 3y ago
FedRAMP High is a good minimum viable security

173 points by jot 3y ago

(2021)? Some previous discussion: https://news.ycombinator.com/item?id=29100400 https://news.ycombinator.com/item?id=29100400

ChrisMarshallNY 3y ago

I like the idea, but I'd be skeptical that it's practical for very small companies. That doesn't let them off the hook, but all that process overhead can be a killer. I worked for a company that was PCI DSS, and it often made it impossible to get any work done (to be fair, it had more to do with how they implemented it, than the standard, itself). But I agree that security needs to be Job One for everyone, regardless of size.

janosd 3y ago
A bunch of this stuff you have to do anyway if you want to be GDPR compliant. It's unfortunately not as easy to launch a new service these days as it used to be. But maybe that's not a bad thing given how much data we are being asked to share nowadays.

jawns 3y ago

While this may appear to be an altruistic consortium of security-minded companies trying to help startups do the right thing, my skeptical take is that it's primarily a way to drum up business, which explains why the contributors list largely consists of vendors that help you check these items off your list. Google (one of the main sponsors) and other cloud-hosting vendors can essentially say, "Sure, you can cobble all of this together yourself -- or you can buy our services with much of this already baked in."

tptacek 3y ago
I don't think Google covers a lot of this stuff.
dadrian 3y ago
If there's any vendor in the sponsor list with an ulterior motive, it's Vanta.
- no_wizard 3y ago
  They all sell products (via cloud offerings etc) that pertain to this list, why call out Vanta in particular?

tptacek 3y ago

The name is too cute, and actively misleads. You can't call this a "minimum" anything; it's an opinionated list of controls that several of the most savvy security teams I know don't uniformly implement. Just off the top of my head, things that aren't even universally seen by practitioners as good things, let alone things everyone does as a "minimal" baseline: * On request, enable your customers or their delegates to test the security of your application * Implement role-specific security training for your personnel that is relevant to their business function * Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18 --- LOL to this whole line item. * Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored There is then a longer list of controls that I think most practitioners would say are good things, but that aren't always P1-prioritized (for good reason, to make way for more important things). CSP headers, SLSA level 1 builds, media sanitization policies; these things are situationally important. I think an opinionated checklist is a fine thing, but when you call something the "minimal viable" standard, you set yourself up to explain how lots of well-run companies are viable without these things.

prepend 3y ago
This is about as accurate in naming as a “minimal life list” that includes things like living debt free and having a $1M insurance policy. Or closer to recommended practices. As these are definitely not minimal since there are many products that won’t meet them yet are still viable. It’s also funny how cyber consultants seem more apt to add “required” thing that really tend to increase their bill hours. Like how accounting firms love Sarbanes Oxley and like to add in new rules that they claim are necessary.
- reidjs 3y ago
  What is Sarbanes Oxley and what’s it got to do with accounting firms? Edit: court ruling (shortened SOX) has to do with security compliance for public companies. After Enron and other scams https://en.m.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act https://en.m.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act
3y ago

belval 3y ago

> Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18 > Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses > Ensure data localization requirements are implemented in line with local regulations and contractual obligations Whoever wrote this must be so irrationally out of touch with the startup space (or thinking of older billion dollar unicorn startup) to think that an MVP needs to do any of the above. I wouldn't care about GDPR until I have a somewhat strong EU userbase. Try to respect the spirit sure, but it's not like it will be enforced on a small business within it's first few years of existence. Localization for an MVP is even more out of touch. Make an English US-centric version first (I'm not even American) put it out there and work on localization once you've had some success.

b112 3y ago
Indeed, some of these things take months of work to complete, to expect a startup with a couple of people, working part time, to dedicate time to these is a startup death sentence. And really, most of them don't provide security, they're a checklist. Checklists don't provide security, they provide (sort of) accountability.
- habinero 3y ago
  Frankly, security should not be the top priority of a small startup, unless you deal with extremely sensitive data. I'm not sure it should make the top five. Off the top of my head, survival, product dev, growth, hiring and infra are all more important if you're just starting out
  - b112 3y ago
    Sure, but what if you get hacked, or defaced, or your client info gets out? It could kill you too. It's a balance.
  - evantbyrne 3y ago
    There are certain things that are very difficult to implement if you skip them at launch. For example, encryption of 3rd-party secrets. CircleCI is a good example of a successful company burning themselves badly by treating encryption as an afterthought.

dogman144 3y ago

I’m a sec eng and worked at startups, I don’t love this list. Some of it is valid but generally it seems off target regarding how process-focused it is and ideas like startups doing data flows, vuln management and getting application-level logging done. You’ll get much more bang for buck for the product’s security by working on the enterprise and infra side - deploying EDRs (somehow not on this list?), tightening up Gsuite sharing and email settings, Okta (I see SSO on the list), anti-phishing capability, guardduty and sechub, a pw manager, getting on IaC early to support ops and sec goals, and a lightweight SlackOps infra for security alerts. Somehow mostly none of this is mentioned. The emphasis around the application seems misguided due to how (a) pragmatically it’s going to take much longer to get appsec controls and logs vs infra and enterprise controls/logs and (b) the vector in is usually Bob and Jodie in recruiting and HR getting phished, vs an appsec breach. Also, it seems to break the golden rule of security enabling revenue with acceptable risk trade-offs and pragmatic controls. All the process in here doesn’t seem pragmatic. The controls in here seem useful overall but not where I’d go at first to secure a fast startup.

eganist 3y ago
True as it is, not a thing you list here addresses the security of the product. Except for IaCs. And the site describes securing the product. Will edit with commentary in a moment. Edit: alright, fair criticism re business security controls given that the checklist's first section is specifically about business controls. And the rest should be focusing on automating those outcomes rather than just what the outcomes are. I agree that manually creating DFDs is just going to slow teams down, though it's definitely a capability that more security-mature or regulation-burdened organizations will need. When you're this early though, better to harden IaCs based on secure reference architectures up front and lint the heck out of code than to encumber all of ones processes with manual controls.
- maratto 3y ago
  That's a valid point. We will address this in our upcoming work group meeting. If you're working for a startup, we would greatly appreciate it if you could try implementing MVSP in your organization and let us know which controls were difficult or problematic to implement. These controls can potentially be considered for removal.

thenerdhead 3y ago

Not sure I can get behind the idea. This is like an oxymoron. I get the heightened need for security, but this is not the way. Security is a journey, not a checklist.

andrewmcwatters 3y ago

Totally arbitrary. Some of the advice is actually bad. The only critically relevant pieces of information are the password guidelines and HTTPS-related bullet points, for which there are actual authorities to read, not this waste of time and effort.

glonq 3y ago

> A minimum security baseline for enterprise-ready products and services Sure, although minimum viable and enterprise-ready seems like an oxymoron to me. Step one: define MVP. Step two: add minimum enterprise security, minimum enterprise scalability, minimum enterprise legal compliance, minimum enterprise cost controls, minimum social responsibility ... Step three: why the hell is MVP 28 months late?

Conscat 3y ago

The checklist doesn't render correctly on mobile.

lexandstuff 3y ago

If this is the "minimum", I'd love to see what they left off the list. My minimum for a public-facing MVP: - All services use HTTPS to talk to users and each other. - High standard of password encryption (or prefer to use something like Cognito or Firebase). - Plan for GDPR compliance (not exactly security related, but in the wheelhouse. The GDPR grifters come out of the woodwork quickly, so you need all the popups and account deletion stuff from day 1 if you are releasing to the EU). - QA specifically for security: users can't access each other files, authentication controls work, etc. - Don't store or handle credit cards - use a vendor like Stripe. - Ensure all dev tools enforce 2FA where possible (GitHub, AWS, etc.). - A basic backup system. Then post-MVP, start working on the following: - centralised logging. - dependency patching plan. - etc

seabass-labrax 3y ago
> Don't store or handle credit cards - use a vendor like Stripe. Alternatively, if your customers will make one-off or infrequent payments, you might want to consider accepting cheques, which can be made electronically through a system like BACS (note that every country has different systems available). Cheques (checks) are a 'customer pushes' method as opposed to cards, which are a 'seller pulls' method. Accepting international payments makes transfers somewhat more difficult, and cheques always assume a higher level of competence on the part of the customer than cards do; however, neither are likely to be a problem for B2B products. > Ensure all dev tools enforce 2FA where possible (GitHub, AWS, etc.). Two things that are critical to remember are that 1: most forms of 2FA don't improve security and 2: many services will refuse to restore accounts based on trust or some other form of evidence if 2FA was enabled, where they would otherwise. Challenge-based forms of 2FA such as TOTP or FIDO are better than SMS, as latter can be intercepted in transit. Calculating the response to a challenge on a separate physical device to the one being authenticated is additional benefit that FIDO2 usually has. Side-note: if you need to authenticate customers, allow them to choose at least TOTP; try not to even provide SMS 2FA. As for the lack of account recovery, this can be a benefit, but only if you have robust procedures to make sure employees' credentials (like TOTP codes) are copied to sites accessible by other employees; this effectively means things like buying fireproof safes if you are doing it properly. Revocation of credentials by other employees is just as important as recovery. All this is to say that 2FA is not something that you can just toggle a switch for to make your company secure; it is worthy of a company-wide strategy.

mufti_menk 3y ago

Better to ask forgiveness than permission. Extra security not worth reduction to sprint velocity ime.

j45 3y ago

It was nice to see this kind of topic, reading the list felt a little higher level than I anticipated, even for a startup who is targeting enterprise sales. I would love to hear what others here consider important to make a minimally viable and secure product in a startup from the starting as a startup. How much of this list is hard needs, soft needs, beneficial, and nice to have preferences/interpretations? Many startups wouldn't make it to the start line fulfilling this list. If I could pick a solution architect's brain looking at this, I'd be curious to know what ways there are to satisfy these through architecture, design considerations, or using particular parts of particular platforms?

ed-209 3y ago

So Google wants it to be prohibitively costly to compete with Google. Got it lol

mrbungie 3y ago

A list of security recommendations about MV(S)Ps created by a consortium of pretty big non-startup companies. The joke tells itself. But seriously, I think the problem is in the name. This is not a set of best practices for any kind of startup but rather a public checklist that anyone looking forward to provide some kind of service or product to any of the contributors (i.e. Google, Salesforce, Okta, or even other companies subscribing to this extreme SecOps cargo cult) must comply.

motohagiography 3y ago

Interesting, but I'm having trouble thinking of a startup that was killed or even harmed by a security issue (outside cryptocurrency stuff). Anecdata-wise, startup graveyard stories don't seem to have being-hacked as one of their failure causes either, unless I'm missing some big ones. An old product attempt of mine was a threat model wizard that generated a simple deck with some very clear viz of the model and threat exposure addressed to all concerned parties - and then backlog issues and themes and epics for implementing or verifying the controls it implied. It reduced the checklist/risk assessment process to about an hour from the weeks of spreadsheet work that was a lot of peoples jobs, and it put security into the product/project dev process. Pretty much aha.io (the product management tool) but for security. What I learned from it is a) self-assessments weren't valuable to large org customers (who need to be able to say they were told by a 3rd party, so it's not like product management that way) b) the need of small orgs / startups was a standard compliance checklist to make standard assertions to potential customers as part of vendor onboarding, and a faster/better model didn't get them that standard. c) most security people trade on their insights, and codifying their ontology even just to speed it up undermined their leverage in their orgs. This checklist or something like it might actually meet the real needs of some startups who must make templated assertions to customers for vendor onboarding, but most startups would be lucky and probably pretty chuffed if they actually had something someone wanted to steal.

jwr 3y ago

Not a great list. Very opinionated, and much as I'm security-conscious, I disagree with a number of "minimum" recommendations there. This list looks like it was written by people who are not paying for anything, so they don't understand the tradeoffs, costs and compromises. I can assure you things look quite different when you are a solo founder running the business and you have to pay for everything. Technical stuff doesn't change, so recommendations like "Do not limit the permitted characters that can be used in passwords" still hold, but "Contract a security vendor to perform annual, comprehensive penetration tests on your systems"? Also, "Publish the point of contact for security reports on your website" and "Respond to security reports within a reasonable time frame" — I'm already spending too much time responding to "security researchers" trying to shake me by sending (rather silly and generic) "vulnerability reports". Some of them follow up by asking if they can "publish this on their social media channels" if I don't respond. I really don't need more "security reports" for my website.

lelanthran 3y ago
> This list looks like it was written by people who are not paying for anything, so they don't understand the TRADEOFFS, costs and compromises. That's the important word there (emphasis mine). I'm doing an MVP now for a client for a custom app (used internally by that client, i.e. only employers are users), and my recommendation for security is "I'll use a simple XOR symmetric stream cipher for now. We can switch to TLS[1] if the system turns out to be useful". Yeah, cut corners on other things as well - they just want to see how viable this thing is in practice. [1] While TLS is nice, certificate management becomes a pain in the rear for remote devices.
- dgb23 3y ago
  So really it’s a prototype. Nothing wrong with that.

cglendenning 3y ago

The intent of a the "minimum" in MVP is to produce something quickly in order to learn what resonates with people who might actually pay you money for something. It would be useful to have a "detect my disasterous security vulnerabilities" scanner with various language plugins for go, dart, swift, whatevs that I can run on the source of my MVP so that I don't have to waste time reading a checklist. Does that exist? Dunno.

dv35z 3y ago
Are you familiar with https://snyk.io/ https://snyk.io/? Disclaimer: I used to work with the founder, he’s great.

andrewstuart 3y ago

Not really a fan of hijacking the MVP concept for something unrelated.

sergioisidoro 3y ago

I was hoping for something more like: * Check you're storing secrets safely and not in the code * Run a automated security scanner to check for the OWASP top 10 * Confirm your endpoints have correct auth/permission checks, and that all debug flags are off * Ensure databases are protected (eg. Not exposed to the internet or heavily restricted) * Enable 2FA for everyone in the company and use a password manager * Check what are the data protection laws and disclosure sla of your country

q-base 3y ago

Minimum Viable Secure Product, Minimum Viable Marketable Product, Minimum Viable Sellable Product. I don't get it. Why do we need all these additions? Perhaps it is me who does not understand the meaning of "Viable". MVP is not a restricted, well-defined end-goal. "Viable" means viable for your case. You can fill in whatever you want. It does not mean "Viable" without security or "Viable" without "Marketability".

jjav 3y ago
> It does not mean "Viable" without security But zero security is exactly what most startups see as viable. I remember one PM at a startup saying "Well hire a marketing firm to create flowery language for our website asserting how ultra military grade secure we are. And that's it. We're not going to spend a penny implementing any of that security geekery you people talk about."

benator 3y ago

I think a lot of comments here might be missing the point of this standard - it’s not specifically designed just for startups or to cover general organisation security (like EDR). It’s a product feature oriented checklist that should help short circuit some aspects of supplier security due diligence and establish a set of product security features that any B2B product with ambitions to sell to enterprise customers would benefit from aspiring to, and anyone buying can leverage. That means large multi-product businesses looking to ship an MVP for a new service as well startups with a bright idea but a possibly limited understanding of enterprise IT compliance needs. I’ve got some experience as Head of Cyber/InfoSec at a couple of startups/scaleups and I see this as potentially useful in a bunch of ways if broadly adopted. It establishes a baseline both for our own products and our suppliers, attests to stuff that actually affects how we integrate with and operate a third party product (ISO 27001 gives me no clue whether you support SSO, have viable logs that I can actually ship to the SIEM etc.) and hopefully simplifies both the due diligence we do on our suppliers as well as that done on us by our customers by allowing us to reduce a good chunk of the product feature questions to “does your product meet the MVSP standard”. There was a pretty useful discussion of it on the Google Cloud Security podcast a while ago: https://cloud.withgoogle.com/cloudsecurity/podcast/ep114-minimal-viable-secure-product-mvsp-is-that-a-thing/ https://cloud.withgoogle.com/cloudsecurity/podcast/ep114-min...

Rapzid 3y ago
I have been responsible for these controls in multiple startup and smaller businesses selling into Fortune 500, including setting up security "programs", and agree with everything you say. Ultimately it boils down to: > Convince whoever is asking you are following whatever process they are asking about so they can check a box. They call it security theatre for a reason. Of course if you don't want to be lying, well, you gotta implement a lot of this stuff as at least written policies. Also, auditors have a tendency to ask for evidence...
dogman144 3y ago
As head of security, did you ever try to get devs to remediate a ton of appsec vulns during early days, or ask them to build data flow diagrams? My criticism of this is that you can secure the product with solid defense in depth on the enterprise/infra side in a way that is: - minimally invasive to devs - aligns with what is likely there to slot into - what SAST tool can you pay for that early on at a startup, let alone slot into a non-existent DevOps pipeline. $1-200k SIEMs existing at a series A/B that prob has 1-2 sec engs? - get a WAF for a bandaid fix for the appsec problems initially until you can hire product security folks

camgunz 3y ago

Isn't this just a ploy to get decision makers to think they need to use these services/platforms to achieve MVSP (and to think MVSP is a thing)? Man the internet really gentrified in a gross, banal way.

dgb23 3y ago

> Cross-site request forgery. Example: Accepting requests with an Origin header from a different domain English is not my first language and I’m not a security expert, but this description seems a bit misleading. The “Origin header” part should be left out. You don’t check where it’s comming from (you can’t know). You either send a unique token back and forth, or you defer the issue to the browser (cookies with Same Site strict/lax). And it’s not “requests”, it’s “unsafe requests” AKA mutations (POST, PUT, PATCH, DELETE). It’s not just a nitpick. If your GETs are not safe, you might cause deeper issues.

Woodi 3y ago

What a brain deadness... "Maybe secure but must include HTTP.*"...

tguvot 3y ago

FedRAMP High is a good minimum viable security