3 ms·

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, pick

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.

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.