4 ms·

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 s

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
- benator 3y ago
  I think these are broadly reasonable points and when there is no existing security team (I’m joining to set one up) I usually start with going after infra, picking the low hanging fruit and carefully planning out any points of friction with a user base that isn’t used to having a security team. That’s often a journey that involves basic cloud controls, restructuring IAM, bringing in MDM, pushing for license upgrades for key SaaS apps that force you to pay the SSO tax, making sure the WAF and DoS protections are actually doing something useful, documenting the security signals we have and those we need, rolling out and drilling an actionable incident response plan etc. I came from software engineering into appsec, prodsec and then into security management and possibly as a result of that I don’t push for plugging a dependency/static analysis tool into a work item tracking system and fire hosing engineers with CVEs in code paths they never hit. I do want to see that they can keep up with general patching though - can they, on a regular (think weekly/monthly) cadence upgrade their libraries and frameworks to the latest patch version and still ship with quality that week? But when you look at some key aspects of that infra/biz app security journey at a largely cloud based young business - like taking more control of IAM across SaaS, bringing together activity from those multiple cloud systems and creating alerts that actually matter - that all involves knowing your vendor supports SSO, possibly also SCIM, has logs that contain relevant data that can be exported/streamed into a SIEM. Some of the stuff this standard demands is going to be fairly core to securing business infra. I just get bored talking to vendors that want to wave an ISO cert at me as if that somehow makes it ok they don’t give me access to audit logs.
  - dogman144 3y ago
    I’m broadly aligned with what your focus is on what to do first. Your approach seems to self-evidently present the issue with this proposed framework. If: - the goal of a startup security program is to meaningfully protect revenue (two parts to this IMO: prevent catastrophic breach, and have a sec program that can pass RFPs and SOC2 eventually) - RFPs can start early and often and: - for a small sec program, ideally you shoot for a very tight overlap of the above (tangible risk controls that helps sales) - the goal of the MSVP is to slot into the RFP process to provide meaningful controls Then: - we’ve both independently laid out that a bulk of the work for early wins is on enterprise and infra, and it’s not worth hammering devs beyond the obvious (patches acceptably safe package management, no horrible API or authn/z risks) - majority of what you’ve covered and I’ve covered aren’t on the proposed MSVP So putting that together, it makes me feel that MSVP misses the mark vs its goals. The authors claim that it’s supposed to be more product related, but much of it is not product-related. These parts also largely don’t at all cover the obvious things you’ve laid out. And, the product-related parts get right into the dev’s space, such that you’d need a very security-committed dev or a very over-tasked sec eng to do it all. It seems to be a bad blend of not pragmatic for the realities of startup sec via not understanding how one can get defense in depth product wins without doing strictly “prodsec” and why that’s a solid approach.

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

benator 3y ago
I think these are broadly reasonable points and when there is no existing security team (I’m joining to set one up) I usually start with going after infra, picking the low hanging fruit and carefully planning out any points of friction with a user base that isn’t used to having a security team. That’s often a journey that involves basic cloud controls, restructuring IAM, bringing in MDM, pushing for license upgrades for key SaaS apps that force you to pay the SSO tax, making sure the WAF and DoS protections are actually doing something useful, documenting the security signals we have and those we need, rolling out and drilling an actionable incident response plan etc. I came from software engineering into appsec, prodsec and then into security management and possibly as a result of that I don’t push for plugging a dependency/static analysis tool into a work item tracking system and fire hosing engineers with CVEs in code paths they never hit. I do want to see that they can keep up with general patching though - can they, on a regular (think weekly/monthly) cadence upgrade their libraries and frameworks to the latest patch version and still ship with quality that week? But when you look at some key aspects of that infra/biz app security journey at a largely cloud based young business - like taking more control of IAM across SaaS, bringing together activity from those multiple cloud systems and creating alerts that actually matter - that all involves knowing your vendor supports SSO, possibly also SCIM, has logs that contain relevant data that can be exported/streamed into a SIEM. Some of the stuff this standard demands is going to be fairly core to securing business infra. I just get bored talking to vendors that want to wave an ISO cert at me as if that somehow makes it ok they don’t give me access to audit logs.
- dogman144 3y ago
  I’m broadly aligned with what your focus is on what to do first. Your approach seems to self-evidently present the issue with this proposed framework. If: - the goal of a startup security program is to meaningfully protect revenue (two parts to this IMO: prevent catastrophic breach, and have a sec program that can pass RFPs and SOC2 eventually) - RFPs can start early and often and: - for a small sec program, ideally you shoot for a very tight overlap of the above (tangible risk controls that helps sales) - the goal of the MSVP is to slot into the RFP process to provide meaningful controls Then: - we’ve both independently laid out that a bulk of the work for early wins is on enterprise and infra, and it’s not worth hammering devs beyond the obvious (patches acceptably safe package management, no horrible API or authn/z risks) - majority of what you’ve covered and I’ve covered aren’t on the proposed MSVP So putting that together, it makes me feel that MSVP misses the mark vs its goals. The authors claim that it’s supposed to be more product related, but much of it is not product-related. These parts also largely don’t at all cover the obvious things you’ve laid out. And, the product-related parts get right into the dev’s space, such that you’d need a very security-committed dev or a very over-tasked sec eng to do it all. It seems to be a bad blend of not pragmatic for the realities of startup sec via not understanding how one can get defense in depth product wins without doing strictly “prodsec” and why that’s a solid approach.