4 ms·

It's better to start early than anything, a lot of these certs are easier to get when you have nothing to audit. I've worked for 2 successful B2B fintechs, I wo

It's better to start early than anything, a lot of these certs are easier to get when you have nothing to audit. I've worked for 2 successful B2B fintechs, I wouldn't wait until a customer asks, I would be proactive if you have the time and money to go through it.

tptacek 5y ago
I think this is basically the opposite of the correct answer. If you do certification too early, you'll be pulled into pointless engineering projects that will likely have a TCO far larger than the certification itself. If you wait to do SOC2 until after you have a security team, you can avoid a lot of this work. It doesn't help that SOC2 auditors are basically wrong about a lot of stuff, so that if you're getting certified before you have a sane security practice in place, your security engineering will get dragged into weird, unproductive places.
- x0x0 5y ago
  I disagree. soc2 forced us to yubikeys everywhere; getting serious about knowing, auditing, and controlling access; etc. There def were useless bits (contingency plans? If an earthquake hits sfo bad we're screwed, you're screwed, etc)). But on the whole, I think it made us a more secure company. Lots of it is basically best practices. Have, test, and document db backups. Have, test, and document a network diagram. Audit employee offboarding. Don't let all employees trivially touch prod. Put admin tools behind a vpn. Automate approvals and deploys (we did it all with aws tooling) so that you can audit deploy -> git sha -> [PR approval in github, ticket in jira] Lots of this is probably dependent on your auditor though. Also, it's a slow lead time to get, and the upper midmarket / lower enterprise demand it. edit: bluntly, it also gave me some justification to slide things through when junior eng complained they couldn't touch the prod db.
  - tptacek 5y ago
    SOC2 did not force you to use Yubikeys everywhere. How I know that is: no mid-sized organization I've seen SOC2 has ever gotten everyone onto Yubikeys. The median SOC2 auditor hasn't the slightest clue what a Yubikey is (the median SOC2 auditor probably doesn't know the difference between a URL and a hostname). I understand what you're trying to say: the threat of a SOC2 information gathering process scared your engineering team into taking 2FA seriously. Your team was able to use it as a forcing function. Not to put too fine a point on it: your team is dysfunctional and has a poorly-communicating and unpersuasive security practice.† That's the problem you needed to fix. There will be things you very seriously need to get rolled out after Yubikeys, and you won't have another $70,000 Big5 audit to wave around to get it done. Meanwhile: people who don't want to endure that audit can get Yubikeys deployed without bothering with the SOC2 part. An important thing not enough people understand about SOC2 is that the profile of controls that you use (where controls are things like "logs we monitor" and "onboarding processes" and "2FA mechanisms") are self-determined. Auditors have a set of very high-level goals --- much higher level than "services need 2FA SSO --- and you get to pick what controls you map to them. You get to pick what SOC2 makes you deploy, and the auditors ostensibly just keep you honest. I would be surprised if anything close to 50% of reliably SOC2 -Type-2'd shops had any hardware 2FA at all. † Almost everyone does!
    - sk5t 5y ago
      Agreed, SOC2 says nothing about yubikey/u2f/etc. Almost any MFA will do unless one lets opinionated auditors head deep into the weeds. You can use spreadsheet-based recordkeeping to satisfy very much of SOC2 as long as the processes are followed consistently.
- makeitdouble 5y ago
  Starting too early might not be the best move (though parent has a point on better auditability), but doing it at the last minute or once the product is plenty mature also means a ton of needless changes that can be disrupting depending on how the product was built/managed. Perhaps it would make sense to at least know and understand the certifications as early as possible, and grow with it in mind. It makes it a lot easier to get certified when times come, or even to explain clients why it wouldn't be required in some cases ("we can already guarantee you this and that, if that's the part you're worrying about")

tptacek 5y ago

I think this is basically the opposite of the correct answer. If you do certification too early, you'll be pulled into pointless engineering projects that will likely have a TCO far larger than the certification itself. If you wait to do SOC2 until after you have a security team, you can avoid a lot of this work. It doesn't help that SOC2 auditors are basically wrong about a lot of stuff, so that if you're getting certified before you have a sane security practice in place, your security engineering will get dragged into weird, unproductive places.

x0x0 5y ago
I disagree. soc2 forced us to yubikeys everywhere; getting serious about knowing, auditing, and controlling access; etc. There def were useless bits (contingency plans? If an earthquake hits sfo bad we're screwed, you're screwed, etc)). But on the whole, I think it made us a more secure company. Lots of it is basically best practices. Have, test, and document db backups. Have, test, and document a network diagram. Audit employee offboarding. Don't let all employees trivially touch prod. Put admin tools behind a vpn. Automate approvals and deploys (we did it all with aws tooling) so that you can audit deploy -> git sha -> [PR approval in github, ticket in jira] Lots of this is probably dependent on your auditor though. Also, it's a slow lead time to get, and the upper midmarket / lower enterprise demand it. edit: bluntly, it also gave me some justification to slide things through when junior eng complained they couldn't touch the prod db.
- tptacek 5y ago
  SOC2 did not force you to use Yubikeys everywhere. How I know that is: no mid-sized organization I've seen SOC2 has ever gotten everyone onto Yubikeys. The median SOC2 auditor hasn't the slightest clue what a Yubikey is (the median SOC2 auditor probably doesn't know the difference between a URL and a hostname). I understand what you're trying to say: the threat of a SOC2 information gathering process scared your engineering team into taking 2FA seriously. Your team was able to use it as a forcing function. Not to put too fine a point on it: your team is dysfunctional and has a poorly-communicating and unpersuasive security practice.† That's the problem you needed to fix. There will be things you very seriously need to get rolled out after Yubikeys, and you won't have another $70,000 Big5 audit to wave around to get it done. Meanwhile: people who don't want to endure that audit can get Yubikeys deployed without bothering with the SOC2 part. An important thing not enough people understand about SOC2 is that the profile of controls that you use (where controls are things like "logs we monitor" and "onboarding processes" and "2FA mechanisms") are self-determined. Auditors have a set of very high-level goals --- much higher level than "services need 2FA SSO --- and you get to pick what controls you map to them. You get to pick what SOC2 makes you deploy, and the auditors ostensibly just keep you honest. I would be surprised if anything close to 50% of reliably SOC2 -Type-2'd shops had any hardware 2FA at all. † Almost everyone does!
  - sk5t 5y ago
    Agreed, SOC2 says nothing about yubikey/u2f/etc. Almost any MFA will do unless one lets opinionated auditors head deep into the weeds. You can use spreadsheet-based recordkeeping to satisfy very much of SOC2 as long as the processes are followed consistently.
makeitdouble 5y ago
Starting too early might not be the best move (though parent has a point on better auditability), but doing it at the last minute or once the product is plenty mature also means a ton of needless changes that can be disrupting depending on how the product was built/managed. Perhaps it would make sense to at least know and understand the certifications as early as possible, and grow with it in mind. It makes it a lot easier to get certified when times come, or even to explain clients why it wouldn't be required in some cases ("we can already guarantee you this and that, if that's the part you're worrying about")