7 ms·

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 ide

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.
- dogman144 3y ago
  Read my above replies. Product gets secured by defense in depth on the enterprise side edit - plus say a WAF and being disciplined about public endpoints and dialing into how users Authnz. Unless you have the unicorn dev who’s doing appsec also focusing largely on appsec early on is a losing battle politically, will get your 1x sec eng at the startup - who also has to do a ton of other stuff for the startup - to quit for a better job in 12 months, and so on. Defense in depth and threat modeling needs to rule a security program for a startup and doing MSVP as your guideline would miss that nuance.
_8j50 3y ago
EDRs and Phishing are largely for staff/enterprise side if things, not the product itself usually. Alhough people should put EDRs on product servers, for Linux at least (imho) auditd logs centrally logged, configures and monitored qualifies as minimally viable.
- dogman144 3y ago
  For a startup sec program, those delineations don’t exist which is my point.
victor106 3y ago
> Okta While I agree Okta is the most feature complete why only Okta? Are there any other products that can replace Okta?
- paulddraper 3y ago
  SAML IdP and password manager is basically equivalent (ideally add SCIM). Okta is definitely the most complete, but plenty of other options.
- evilduck 3y ago
  Azure Connect AD, JumpCloud, just to name a couple others. As an end user, I end up not caring, they're all about the same experience.
- dogman144 3y ago
  Azure AD can be a bit Microsoft-themed and startups and their SaaS providers who are startups half the time often are in the gsuite ecosystem. AAD probably works but okta is easy. Jumpcloud got breached badly recently. Okta has as well but their breach wasn’t the same. Generally with IDPs, worth going with a gold standard that works well. Okta is that
hamandcheese 3y ago
> You’ll get much more bang for buck for the product’s security by working on the enterprise and infra side I am not a security engineer. But as a generalist software engineer I do not believe this. Every time I go looking in app code with an eye on security, I immediately find all kinds of vulnerabilities. And yet, where I work, the security guys don't read or write a single line of app code. They do like you say, and focus almost entirely on the infra/business process side of things. I find it really hard to respect these people when they are more worried about locking down what jira tickets I can view than they are actually securing our product.
- tomnipotent 3y ago
  > entirely on the infra/business process side of things Considering most of the major incidents over the last few years fall into these categories, it makes sense.
  - dogman144 3y ago
    Exactly
- lelanthran 3y ago
  My experience of IT Security in enterprises is that it's simply a checkbox to check off so that someone, somewhere, can say "I followed best practices; this breach cannot be blamed on me!" Preventing breaches is an objective, but it's purely secondary to CYA. This is why the Security Strategy Policy exists and often looks so out of touch with reality: 1. An external consulting firm advised on that policy document. 2. Someone signed off on that policy document (CEO/CTO/COO/etc). 3. Everyone below that person ticked-off every single clause in that document. 4. Breach occurs. 5. Employees can't be blamed, they did everything that was asked of them 6. CEO/CTO/sign-off person cannot be blamed: they sought, paid-for, received and heeded professional advice. 7. The external firm cannot be blamed, as their advice is "in line with modern security guidelines." In this sense, no one should be shifting focus from whatever the policy document says because then they can be blamed.
  - 3y ago
bobek 3y ago
Absolutely agree. Even basics like password manager instead of one password everywhere. It is about the overall attitude. One cannot expect people to think about secure code, when they don't follow basic principles outside of the product itself.
Rapzid 3y ago
When I visit the link I see: > for enterprise-ready products and services Are we seeing something different?
littlestymaar 3y ago
> anti-phishing capability, Can you tell us more about that? What kind of capabilities can protect you against social engineering?
- dogman144 3y ago
  It’s a mix of training highest risk users and then layering a lot of defense in depth behind them from security tools offered by 0365 or (more commonly for a startup)GSuite, MFA everywhere early on (SMS would be fine very worst case for a lean/mean startup), EDR to catch DNS logging and if the phish got onto the endpoint successfully, and an idp like okta so you can quickly kill sessions for the breeches user. More advanced approaches are to sequester the most vulnerable users into something like Amazon workspace, where a successful phish goes nowhere. This can be harder to enforce though.
  - littlestymaar 3y ago
    > EDR to catch DNS logging What's an EDR? And what's the link between phishing and DNS? > like okta so you can quickly kill sessions for the breeches user I can the see the usefulness of the ability to kill compromises session, but if your user get his Okta account pwnd, then the attacker has access to the entirety of what the user had access to without needing to do any additional work, which is the worse possible scenario. And unless the user has the right reaction (seeking help ASAP), your kill switch isn't going to save you. Also, MFA isn't really helping against phishing: the user is going to give the MFA code to the attacker anyway…
maratto 3y ago
Hi there, I'm one of the authors of MVSP. Thank you for your feedback! I've carefully read all the comments in this thread, and it seems there's a misconception that MVSP replaces or substitutes enterprise or compliance controls. The goal of MVSP is to add the "S" in Minimum Viable Product (MVP). It establishes a minimum standard for a software artifact, like a SaaS app, to be considered for purchase by companies that use MVSP as an RFP baseline. MVSP originated from the security contracts' language used by big corporations like Salesforce, Google, Dropbox, and others in the FAANG MANGA group. If you believe that certain requirements could be removed, please feel free to join our mailing list and share your feedback for discussion: https://mvsp.groups.io/g/mvsp https://mvsp.groups.io/g/mvsp Our next working group meeting in the US timezone is scheduled for September.
- dogman144 3y ago
  Where I think we’re not aligned is you’d secure the product to secure revenue, right? Passing RFPs makes total sense but adding MSVP into an RFP check adds another layer of checklists to go through, and if it’s for RFPs that means the checklist likely gets done prior to much else, so these checklists anchor your security program ealry on. Anchoring a startup security to the MSVP would be misguided IMO, for my reasons below. It doesn’t mean it’s not useful, but it’s not where I’d burn my social capital and budget as a sec eng to meaningfully secure a firm. That’s the goal of running a security program for a startup, ultimately - get them to Series C without a serious breach, and then build out a security team to get them to IPO and through SOC2 etc. So my concern is that if you have just one shot to standup a security program, and the goal is the above, building out a appsec program with the MSVP (which also skews into a bunch of process, beyond appsec) seems to veer far into stuff that’d be unproductive for startup security team to do. Reason being is it hits what I said above in another thread - unless you have a dev knowledgeable and willing to do all the suggested appsec controls in the MSVP, that’s a sec eng asking for each of those controls. The odds of a clean devops pipeline even existing yet seems low, as to slot in SAST and some DAST approach to catch the vulns suggested by the MSVP. Or the budget for a pentest. That’s a sec eng annoying startup devs for constant code changes for code that works and is getting revenue (bc this is how the 101 startup dev usually sees these requests). That’s also a sec eng who is usually doing semi-GRC, supporting sales processes, doing all the above enterprise sec 101 stuff, and potentially ops/IT support, as there’s usually only 1 or 2 of these hires early on. So, makes me think that the MSVP as written misses the pragmatic reality of what works for startup sec programs, although I’d agree it’d work for a product. But to secure the product given realities for a startup dev, WAF for the product endpoints helps deal with the worst appsec problems and then use defense in depth on the enterprise side. Phishing the customer service rep, SaaS breach, or sketchy packages are very commonly what gets startups.
andromaton 3y ago
Could you please suggest a site or list that's more programmatic?

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.
dogman144 3y ago
Read my above replies. Product gets secured by defense in depth on the enterprise side edit - plus say a WAF and being disciplined about public endpoints and dialing into how users Authnz. Unless you have the unicorn dev who’s doing appsec also focusing largely on appsec early on is a losing battle politically, will get your 1x sec eng at the startup - who also has to do a ton of other stuff for the startup - to quit for a better job in 12 months, and so on. Defense in depth and threat modeling needs to rule a security program for a startup and doing MSVP as your guideline would miss that nuance.

_8j50 3y ago

EDRs and Phishing are largely for staff/enterprise side if things, not the product itself usually. Alhough people should put EDRs on product servers, for Linux at least (imho) auditd logs centrally logged, configures and monitored qualifies as minimally viable.

dogman144 3y ago
For a startup sec program, those delineations don’t exist which is my point.

victor106 3y ago

> Okta While I agree Okta is the most feature complete why only Okta? Are there any other products that can replace Okta?

paulddraper 3y ago
SAML IdP and password manager is basically equivalent (ideally add SCIM). Okta is definitely the most complete, but plenty of other options.
evilduck 3y ago
Azure Connect AD, JumpCloud, just to name a couple others. As an end user, I end up not caring, they're all about the same experience.
dogman144 3y ago
Azure AD can be a bit Microsoft-themed and startups and their SaaS providers who are startups half the time often are in the gsuite ecosystem. AAD probably works but okta is easy. Jumpcloud got breached badly recently. Okta has as well but their breach wasn’t the same. Generally with IDPs, worth going with a gold standard that works well. Okta is that

hamandcheese 3y ago

> You’ll get much more bang for buck for the product’s security by working on the enterprise and infra side I am not a security engineer. But as a generalist software engineer I do not believe this. Every time I go looking in app code with an eye on security, I immediately find all kinds of vulnerabilities. And yet, where I work, the security guys don't read or write a single line of app code. They do like you say, and focus almost entirely on the infra/business process side of things. I find it really hard to respect these people when they are more worried about locking down what jira tickets I can view than they are actually securing our product.

tomnipotent 3y ago
> entirely on the infra/business process side of things Considering most of the major incidents over the last few years fall into these categories, it makes sense.
- dogman144 3y ago
  Exactly
lelanthran 3y ago
My experience of IT Security in enterprises is that it's simply a checkbox to check off so that someone, somewhere, can say "I followed best practices; this breach cannot be blamed on me!" Preventing breaches is an objective, but it's purely secondary to CYA. This is why the Security Strategy Policy exists and often looks so out of touch with reality: 1. An external consulting firm advised on that policy document. 2. Someone signed off on that policy document (CEO/CTO/COO/etc). 3. Everyone below that person ticked-off every single clause in that document. 4. Breach occurs. 5. Employees can't be blamed, they did everything that was asked of them 6. CEO/CTO/sign-off person cannot be blamed: they sought, paid-for, received and heeded professional advice. 7. The external firm cannot be blamed, as their advice is "in line with modern security guidelines." In this sense, no one should be shifting focus from whatever the policy document says because then they can be blamed.
- 3y ago

bobek 3y ago

Absolutely agree. Even basics like password manager instead of one password everywhere. It is about the overall attitude. One cannot expect people to think about secure code, when they don't follow basic principles outside of the product itself.

Rapzid 3y ago

When I visit the link I see: > for enterprise-ready products and services Are we seeing something different?

littlestymaar 3y ago

> anti-phishing capability, Can you tell us more about that? What kind of capabilities can protect you against social engineering?

dogman144 3y ago
It’s a mix of training highest risk users and then layering a lot of defense in depth behind them from security tools offered by 0365 or (more commonly for a startup)GSuite, MFA everywhere early on (SMS would be fine very worst case for a lean/mean startup), EDR to catch DNS logging and if the phish got onto the endpoint successfully, and an idp like okta so you can quickly kill sessions for the breeches user. More advanced approaches are to sequester the most vulnerable users into something like Amazon workspace, where a successful phish goes nowhere. This can be harder to enforce though.
- littlestymaar 3y ago
  > EDR to catch DNS logging What's an EDR? And what's the link between phishing and DNS? > like okta so you can quickly kill sessions for the breeches user I can the see the usefulness of the ability to kill compromises session, but if your user get his Okta account pwnd, then the attacker has access to the entirety of what the user had access to without needing to do any additional work, which is the worse possible scenario. And unless the user has the right reaction (seeking help ASAP), your kill switch isn't going to save you. Also, MFA isn't really helping against phishing: the user is going to give the MFA code to the attacker anyway…

maratto 3y ago

Hi there, I'm one of the authors of MVSP. Thank you for your feedback! I've carefully read all the comments in this thread, and it seems there's a misconception that MVSP replaces or substitutes enterprise or compliance controls. The goal of MVSP is to add the "S" in Minimum Viable Product (MVP). It establishes a minimum standard for a software artifact, like a SaaS app, to be considered for purchase by companies that use MVSP as an RFP baseline. MVSP originated from the security contracts' language used by big corporations like Salesforce, Google, Dropbox, and others in the FAANG MANGA group. If you believe that certain requirements could be removed, please feel free to join our mailing list and share your feedback for discussion: https://mvsp.groups.io/g/mvsp https://mvsp.groups.io/g/mvsp Our next working group meeting in the US timezone is scheduled for September.

dogman144 3y ago
Where I think we’re not aligned is you’d secure the product to secure revenue, right? Passing RFPs makes total sense but adding MSVP into an RFP check adds another layer of checklists to go through, and if it’s for RFPs that means the checklist likely gets done prior to much else, so these checklists anchor your security program ealry on. Anchoring a startup security to the MSVP would be misguided IMO, for my reasons below. It doesn’t mean it’s not useful, but it’s not where I’d burn my social capital and budget as a sec eng to meaningfully secure a firm. That’s the goal of running a security program for a startup, ultimately - get them to Series C without a serious breach, and then build out a security team to get them to IPO and through SOC2 etc. So my concern is that if you have just one shot to standup a security program, and the goal is the above, building out a appsec program with the MSVP (which also skews into a bunch of process, beyond appsec) seems to veer far into stuff that’d be unproductive for startup security team to do. Reason being is it hits what I said above in another thread - unless you have a dev knowledgeable and willing to do all the suggested appsec controls in the MSVP, that’s a sec eng asking for each of those controls. The odds of a clean devops pipeline even existing yet seems low, as to slot in SAST and some DAST approach to catch the vulns suggested by the MSVP. Or the budget for a pentest. That’s a sec eng annoying startup devs for constant code changes for code that works and is getting revenue (bc this is how the 101 startup dev usually sees these requests). That’s also a sec eng who is usually doing semi-GRC, supporting sales processes, doing all the above enterprise sec 101 stuff, and potentially ops/IT support, as there’s usually only 1 or 2 of these hires early on. So, makes me think that the MSVP as written misses the pragmatic reality of what works for startup sec programs, although I’d agree it’d work for a product. But to secure the product given realities for a startup dev, WAF for the product endpoints helps deal with the worst appsec problems and then use defense in depth on the enterprise side. Phishing the customer service rep, SaaS breach, or sketchy packages are very commonly what gets startups.

andromaton 3y ago

Could you please suggest a site or list that's more programmatic?