[HN Gopher] Minimum Viable Secure Product
___________________________________________________________________
Minimum Viable Secure Product
Author : jot
Score : 42 points
Date : 2023-08-16 19:30 UTC (3 hours ago)
(HTM) web link (mvsp.dev)
(TXT) w3m dump (mvsp.dev)
| thenerdhead wrote:
| 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 wrote:
| 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 wrote:
| > 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?
| tptacek wrote:
| 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.
| ChrisArchitect wrote:
| (2021)?
|
| Some previous discussion:
| https://news.ycombinator.com/item?id=29100400
| jawns wrote:
| 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."
| dadrian wrote:
| If there's any vendor in the sponsor list with an ulterior
| motive, it's Vanta.
| tptacek wrote:
| I don't think Google covers a lot of this stuff.
| belval wrote:
| > 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.
| bbarnett wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| janosdebugs wrote:
| 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.
| dogman144 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-16 23:00 UTC)