Minimum Viable Secure Product
mvsp.dev
mvsp.dev
Thankfully, this checklist doesn't lead startups into a quagmire of stupid network security tools, scanners, and assessments. But it also leaves out corpsec almost completely ("single signon" is an application security control in the checklist, which wildly misses the point), so we'll call that a wash.
What I'll say is that if you're concerned about closing deals and filling out checklists, the appsec controls here aren't going to move the dials much for you, and the corpsec stuff that it's missing is going to trip you up. I'm not in love with it.
Also: for most companies, you're going to want to be well past product-market fit before you start engaging consultants to assess your code. Most startups are well past 30 engineers before they have their first serious assessment. Crappy assessments can hurt as much as they help, and they're the kind you get if you're shopping for $5k-10k pentests while delivering with 5 engineers.
I suppose it makes sense in a context where someone else is handling corpsec adequately, but if that's the idea then it's not very well explained.
Network/platform security is network access control rules, host configuration, to some extent cloud IAM†, and patching.
CorpSec is the stuff you do to address attacks targeted at your team and the computers and services you use to keep the company running --- laptop and endpoint security, Google Apps 2FA, single sign-on, onboarding/offboarding, and that kind of stuff.
† IAM and cloud access/monitoring can kind of bleed into both of the other buckets depending on the aspects you're thinking about, but like 80% of it belongs in the net/platform bucket for most companies.
SOC I vs SOC II helps get at these kinds of distinctions in practice. I've seen a lot of conversations enabled by that. "We did the SOC I software checklist. At some point, we'll pay vendors $50K-250K for SOC II, feel free to fast track that now as part of our contract."
I get why it's there, but this kind of thing is also why, despite being designed to address a real need, initiatives like FedRAMP have been slow & expensive disasters in practice. We should be pushing to self-serve & automated accreditation, and all the way to 1 person projects. Anything that puts third parties, people, and $$$ in the critical path needs to be split out.
Based on this list, how would you automatically validate that vulnerability reports are handled in a reasonable timeframe? How would you do self-serve validation for incident handling timelines? How do you quickly and easily automate assessments of subprocessor data handling?
Quick, easy, strong, self-service, automated accreditation is a wonderful goal! It's critically important to make this stuff as easy as possible because there are features to ship and customer needs to meet. Security must be a baseline for everyone, and achievable by everyone, or else it's just a way for big companies to squeeze out small ones It just might be worth considering carefully that there may be systems at hand that blend humans and computers. It may perhaps be possible that information security could be more than just an engineering problem.
If I may propose a different framing? Information security is primarily a human endeavor. It is mostly about how humans and systems made of humans behave. Information security is about process. Some parts of it can be partially handled by computers, but most of it is deeply not susceptible to automation.
It was a little like having a Physics teacher ask each student to write their own final exam... and then take it. The teacher opined on the number of questions being asked but that was about it. All they are doing is recording your questions and your answers and certifying that you were indeed the person that took that test.
That being said.. I do think you can learn a lot going through the experience of a SOC II. You force yourself to drown out the noisy world a bit and think really critically and thoroughly about security. You need to learn how to articulate security to the entire company, to clients, etc. And you need to back this up with data... not hand waves.
SOC II was a pain... but a good learning experience too.
However, it's not hard to imagine automated flows for verifying this. In this case, specifying endpoints and providing automation scripts for doing GPDR flows takes care of most of it.
A lot of these are converging on the same check boxes, so get rid of the people and $ aspect. A team should be able to put together COTS OSS, run on a cheapo cloud, and test as part of CI/CD . We need to reach the point properly configured RoR/Django on docker + some sidecars (ELK, autotls, ..) can do that.
Take a look at how AWS/Azure Marketplace programs and supporting vendors are using certified components and automation in multiple layers to get rid of most of the craft. It's possible.
People does make sense for parts, but we need to cut that part down by a ton I effort and $. I might feel better about the third party thing if the NSA started, as part of their cyber def responsibility, to provide free annual audits upon request (assuming heavy automation as per above) . We should be pushing to enable one-man shops to do this stuff, even if that makes tighter happy paths for how they build and run. Vendors can compete to make their stuff easy to add to that happy path and value add beyond the regulatory lockin.
SOC II Type 1/2 cover the "scopes" that more generally pertain to "secure" development.
A SOC II Type 1 is basically coming up with that checklist. The third-party auditor will then measure your performance against that checklist (you provide the evidence) for a single point in time. The Type 1 is considered the baby step into the Type 2.
A SOC II Type 2 is generally taking that checklist from the Type 1... but the auditor is randomly sampling for evidence over a time range (usually a year). Generally once you've done your first Type 2... you're doing it continually each and every year.
Yes I agree, although my my data might just be bad/skewed, my experience as a `freelance-security-auditor` (just a side hobby). Ever time I reported a serious website vulnerability to a company. Most of the time, their initial response was "But we paid for pen-testing/sec-audits !" or something to that regard.
Going through a grueling security compliance process at a previous job taught me that no single list of recommendations covers all the edge cases and complexity of modern software. At least with a "motivation" section, I was able to piece together what was actually expected of me. It also helps with prioritization if the "motivation" includes the consequences of non-compliance.
For example: the "data flow diagram" is probably meant to be part of threat modeling, where you're forced to think like an attacker. That may sound like a tedious paper-pusher task that could be put off, but actually IMO it's really nice to do early on since a threat model can help tell you where to focus your "minimal" security efforts: https://owasp.org/www-community/Threat_Modeling
Writing things like this, with clear requirements and no justifications, is what I do when I expect people will try and use explanations to weasel out of requirements.
Example: I once had a coworker try and justify sending full credit card data through Kafka as not really storing it if you set the retention time to under a second. So it was fine under PCI-DSS, right?
I also don't feel like all of the requirements should be the minimum. Good examples of minimum requirements are the redirect to TLS requirement. External pen testing is one of the requirements that feels like a nice to have rather than a minimum bar. Minimum standards should be stuff that if you don't do it, technically savvy people would be very concerned if someone uses your product. Stuff like lack of TLS, plain text passwords, lack of input sanitization, using an ancient web server, etc.
IP addresses aren't uniquely identifying. I think GDPR only considers them PII with additional information, no?
see https://gdpr.eu/eu-gdpr-personal-data/ section "Identifiable individuals and identifiers"
Yeah right, so how can you reproduce some bugs that only appear on production data, on other environment that is not production?
If you really need more context to reproduce a bug, you can always try to anonimize the data before moving it out of the production environment, and delete the anonimized data from the test environment once the investigation finishes just to be on the safe side.
Another list that I think is better for most startups: https://www.goldfiglabs.com/guide/saas-cto-security-checklis...
Currently still missing a lot of stuff I'd consider to be minimal on the corpsec side; the earlier it's implemented then the easier it is to keep in the company rather than trying to add it later after inertia sets in. Namely:
* Enforce security keys on the SSO side * Set up email security - SPF, DMARC, explicitly enumerating every source of email sent from your domain with full enforcement to catch new sources before they become critical and untracked
In other words this reads a bit like how you can protect your safe full of wads of cash when the real question should be whether you need to store that money in cash in the first place.
I have no doubt of the technical sophistication of Dream, but I do have some doubt that it provides a way to automatically assess the data handling of subprocessors for me (4.3).
It's been my experience that sooner or later, every app has a reason to deviate. Maybe you wind up constructing a large analytical query as a string because nobody loves joining a dozen tables in an ORM. Maybe you find yourself stuck at a vulnerable version of a package because that branch has been EoL'd and the patched versions require major logic reworking.
So I think you're right - you can get a lot of the tools to be compatible with many of these items from a framework. I'm just not so sure about how much of that is automatically inheritable by an actual working app.
If your product is solving a pain point things like SOC compliance will be granted exemptions or an attestation will be provided until an audit is completed, this allows the customer to reap the benefits of the product while the i's are dotted and t's crossed.
p =~ np, what can I say.
These efforts aren't meaningless, they are very important when you get into enterprise sales once your product has found market fit and is maturing.
I hope that the idea takes hold.
Edit: I have opened a quick PR.