8 ms·

The SOC2 Starting Seven

109 points by lvh 7y ago

wglb 7y ago
>Any time anything security relevant incident happens, you could make a private Slack channel named for the incident. This might be a good start, but it makes me a little uncomfortable. In a true incident, there is a metric ton of stuff that I would not want to be discoverable. I like to set aside an area with locked-down access to keep the truly toxic material found during a serious incident. And for startups or other small companies reading this--the things mentioned here should not be a big deal or take enormous time to do. The earlier you do what is recommended in the post, the happier everyone will be. I'm reminded of my Dad's saying: Tires are like insurance: When you need it, it is too late. [edit typo]
- tptacek 7y ago
  A couple people told me the same thing, and I think it's a valid concern as security process. On the other hand: Slack-channel IR has worked well for clients of ours as a compliance step, and having Slack-channel IR is better than having no IR from a security posture perspective.
  - superq 7y ago
    That's a good point. Even just using Github or Gitlab issues to track incidents with approvals is better than nothing.
ejcx 7y ago
Very good post. This ticks all the boxes on the fundamentals when spinning up a security program. SOC2 Type2 is really where you want to be, but it takes time. Navigating compliance for startups is pretty challenging and I see so many not having a clue how to navigate sales without certs but it's super doable, and getting these things finished get you pretty far along towards Soc2 type1, and shows a lot of goodwill to share these practices even _before_ you have any certs
jesseendahl 7y ago
This is a fantastic article overall. As someone who has now gone through SOC 2 twice (first at Dropbox as an IC, now at Fleetsmith as cofounder/CSO, the only part I disagree with is the advice re: MDM. If you want to make SOC 2 easy, you should choose us (fleetsmith.com) over the competition. There are some specific things SOC 2 cares about with regard to laptops. The ones that can take effort are: - User to device inventory attribution ("give me a list of all your Macs and which employees they belong to") - FileVault enforcement, with automatic (and secure) escrow of the recovery keys - Enforcement of some kind of AntiVirus (either the native stuff built in to macOS, or deployment of a third party solution like MalwareBytes) Each of those 3 items are very time-intensive efforts with competing products. With Fleetsmith, each of them are quite literally (not marketing hype) a few clicks. We're also the leader in terms of security. If you're interested in the intersection of MDM and security research, check out the following: "Hacking a Brand New Mac Remotely, Right Out of the Box" — Article summarizing research presented at Black Hat 2018. https://www.wired.com/story/mac-remote-hack-wifi-enterprise/ https://www.wired.com/story/mac-remote-hack-wifi-enterprise/ -- A Deep Dive into macOS MDM (and how it can be compromised) — 61 page whitepaper related to Black Hat research. https://i.blackhat.com/us-18/Thu-August-9/us-18-Endahl-A-Deep-Dive-Into-macOS-MDM-And-How-It-Can-Be-Compromised-wp.pdf https://i.blackhat.com/us-18/Thu-August-9/us-18-Endahl-A-Dee... -- On DEP, MDM, device identity, and authentication — Blog post on the security of the device enrollment process. Includes Fleetsmith’s secure device enrollment implementation, in hopes that other vendors in the space will adopt it. https://medium.com/fleetsmith/on-dep-mdm-device-identity-and-authentication-82c9b78cb9c2 https://medium.com/fleetsmith/on-dep-mdm-device-identity-and... -- An Enterprise Security Roadmap for macOS — Detailed blog post on improvements that Apple should make to macOS and MDM, and why. Includes a detailed list of over 50+ bug reports/feature requests. https://blog.fleetsmith.com/macos-enterprise-security-roadmap/ https://blog.fleetsmith.com/macos-enterprise-security-roadma... If anyone is interested in chatting about any of this stuff (the product or the security side) I'm on Twitter at @jesseendahl and on the MacAdmins Slack (macadmins.org) at @jesse.
- tedivm 7y ago
  My issue with most of these solutions- including this one- is that I don't want separate MDM platforms for my Windows and OSX users.
tialaramex 7y ago
I guess this is appropriately sceptical about audit at least. I think people both over and under-estimate audit (in different ways), but certainly if I have to pick it's the over-estimation of the value of audit which hurts and so the scepticism in this piece is warranted.
- lvh 7y ago
  Maybe! I get the impression there are definitely plenty of people have bought SOC2s the way they also buy pentests: "I'm spending $X0,000 today so I can close $X00,000 in sales tomorrow". Which of course, we as security people would say is spending a lot of money and getting nothing, and the business person says is a necessary expense and something to keep in mind when re-evaluating margins :) (But yes lots of companies also mistake SOC2 for a security audit of course!)
tialaramex 7y ago
Typo: In the list of "things you don't do" it lists Web Application Firewalls and I thought there's an amusing asterisk for the claim that they "don't work at all"† But sadly there isn't - that asterisk is supposed to be the next bullet point for Endpoint Protection and AV. † So many missed opportunities. These things are so awful.
- lvh 7y ago
  Thanks! Just fixed that.
  - pvg 7y ago
    Also 'log munging' and scene from Love Actually instead of Say Anything
    - lvh 7y ago
      Wait, I can't find Love Actually and Say Anything in the post. Are you talking about a draft?
      - pvg 7y ago
        taped to the boom box playing Peter Gabriel you hold aloft outside their offices That's Say Anything. It's a movie from the previous century. The scene from Love Actually you can actually recognize from gifs and recent SNL parodies.
superq 7y ago
I've been through the process before and just went through it again, and the first thing listed (Single Sign-On) is not required at all. I'm not even sure it's mentioned directly in the AICPA criteria. I'm also not sure what SSO really buys you, except for just moving the criteria target to another SOC-2 report. ;) Also, MDM is not really critical at all, as long as you have a solid/documented way of managing accounts on web and mobile apps. I do like the rest of the article except for the list itself, however. SOC-2 is all about documentation and processes. Justifying your security choices is less important than carefully and fully documenting them, and the processes that you have in place.
- tptacek 7y ago
  SOC2 doesn't really "require" much of anything. The question we're answering is: "which security engineering projects can you undertake that will make a SOC2 audit go more smoothly". Because SSO directly addresses a lot of access control control points, and generates a lot of evidence for those control points, and because it's generally a very good practice to have anyways, it'd be the first bit of security engineering we'd recommend to ratchet up your maturity. What I can tell you is that the IRLs I've seen, both from big 4 auditors and from SOC2 boutiques, have dozens of questions that are directly answered by a sane SSO configuration. We've watched clients clear SOC2 audits without any coherent SSO. It's clearly doable. This is all made more tricky by the fact that different SOC2 auditors have different requirements. They're in one sense or another all negotiable, in that you can always switch auditors if they're unreasonable, and we've definitely collected several horror stories about aborted SOC2 processes that were resumed with a different vendor. And, to layer more complexity on that, different bigCo customers will have opinions about who did your SOC2. It's all a mess.
  - superq 7y ago
    Right, agreed 100%. In terms of security, the value of centralizing credentials is debatable.
    - tptacek 7y ago
      The other bit of subtext in this post is that you often have multiple ways of addressing control points auditors bring up, and we'd like to steer startups towards the good ways of doing that. So if an SSO keeps you from having an insane password rotation policy, or an MDM (also not "required") keeps you from installing Mac AV software, it's super worth it to us.
teilo 7y ago
Honestly, this misses a huge point and does more harm than good. Having some of these things in place is fine of course, but it don't really help you much, nor is most of it required. SOC2 does not require: SSO, MDM, or almost anything specifically (And what's with the JAMF pro recommendation? MDM is more than iPhones). What it does require are controls. It does not specify what those controls are. You need to create them yourself, and they need to be sufficient to meet the requirements of the Trust Services Criteria. And to have controls, you need to know what you are controlling and why. This brings me to my point: To succeed in SOC2 you actually have to have a plan. You have to have written, reviewed, implemented, and audited policies. THAT is the single biggest hurdle for most companies. You also need to know how to do a risk assessment on your organization. This is not terribly hard, but it is essential to SOC2. And finally, you need buy-in from the governing bodies of your organization. None of these things I mentioned are products. You can't buy them. They take work. A hell of a lot of work. I will guarantee that most companies doing this for the first time do not have half of the processes in place that SOC2 requires. I doubt that 20% have internal audit procedures, for example, or sufficient end-user training. And one more thing that will take nearly anyone who had done security by surprise if they don't know it's there. The COSO Principles. These were added to SOC2 in the wake of the Lehman Bros/Enron scandal. They extend SOC2 to the entire governance structure of your organization, and include controls on financial reporting, hiring practices, employee review processes, etc. This is a major PITA, because it lies far outside the bailiwick of most CISOs or equivalent, and, again, it requires extensive cooperation from the rest of senior management. As you can probably tell, I've done this before.
- tptacek 7y ago
  We've watched our clients get SOC2 certified and been directly involved in the IRL and audit interview processes, and circulated this among peers that have also been SOC2 certified, and we're pretty comfortable with the advice we're offering. So: As we've said repeatedly, SOC2 doesn't "require" much of anything. It certainly doesn't call SSO or MDM out by name. What it instead involves are abstract control points that are addressed with evidence. As the top of the post says, the point is to engage in security engineering practices that generate evidence useful in SOC2 engagements. So, you can certainly freestyle your application and infra access controls, and make up policy responses to the IRL questions on the fly. You can also sit around and worry about which of the "COSO Principles" you're covered on or not covered on. Or, you can do some basic sensible security engineering things that are almost certain to cover the majority of the evidence requests your auditors generate, in most cases without even needing to be aware of the AICPA guidance line items. You make your own process recommendation here: do a "hell of a lot of work" to have "written and audited policies" and a "risk assessment" and become aware of the "COSO Principles". I have no trouble believing that approach works, because after seeing and being involved in a bunch of SOC2 audits and talking to people who did SOC2 audits, I believe everything works. More importantly, we see startups led around by the nose by insane questionnaires (and a SOC2 IRL is certainly that). We've talked to firms that have been told by their SOC2 auditors to install IDS systems, WAFs, and Mac AV software. We are alarmed by the prospect of a startup without in-house security or compliance expertise reading what's out there about SOC2 --- especially the AICPA documentation, or example IRLs --- and then just going and doing that stuff. They'd be wasting a tremendous amount of time without realizing that smart startups skip a lot of that work and deploy none of the junk and get SOC2'd just fine. So, if you're going to do something, do something sensible. What I think people should be especially careful about is taking advice from people who have just done SOC2 at a single company or with a single auditor. They are all different. There are processes where you'll end up explaining what a URL is. There are processes where you'll end up explaining why you have VPC flow logs disabled. The value we're offering here is that we've seen it done repeatedly, with multiple auditors.
user5994461 7y ago
>>> Web Application Firewalls: Most SOC2’d firms don’t use them, and most WAFs don’t work at all. Most startups are on Cloudflare and Cloudflare does WAF out of the box.
tzs 7y ago
The article and the comments here contain a lot of TLAs and the like that many will not be familiar with. Anyone want to expand some of these to save people a bunch of Googling/DDGing/Binging? AD AES AICPA CISO COSO CSO DEP FDE FIM IDS IR JAMF LDAP MDM OIDC SOC2 SSO S/N WAF I don't recall ever seeing a comment thread with that many such things.
- deleted 7y ago
  [deleted]
- julianj 7y ago
  Sorry for any mistakes, mobile. AD active directory AES advanced encryption standard AICPA American Institute of Certified Public Accountants CISO chief information security officer COSO risk management framework CSO many things, probably chief security officer in this context DEP data execution prevention FDE full disk encryption FIM file integrity monitoring IDS intrusion detection system IR incident response JAMF apple device management LDAP lightweight directory access protocol MDM mobile device management OIDC open id connect SOC2 audit standard SSO single sign on S/N serial number WAF web application firewall
  - tptacek 7y ago
    Different DEP here. :) We're talking about the Apple Device Enrollment API.
    - julianj 7y ago
      Thanks, I hadn't yet made it through the full thread for context.
antoncohen 7y ago
I'd like more detail on the advantages of AWS AssumeRole, and what attacks it is designed to protect against. It must be more than CloudTrail logs, because normal API usage gets logged to CloudTrail. One thing I'd like to highlight is that SOC2 is about having controls (of your choosing), and documenting and proving you are following those controls. I think it is important to pick controls you actually want to follow, and that those controls aren't so specific that you get fenced in to a bad process. I've worked at a few companies that have gone through SOC2, one of them (Dropbox) did it very well. I think the average engineer didn't need to know about SOC2, or what all the controls were, because the controls were well thought out, and automation took care of the proof. At another company every engineer was constantly saying "you have to do that because of SOC2", because the controls intruded on the way engineers worked. "SOC2 requires that two people approve every PR". Hmm, no the accountants that created SOC2 don't know what PRs are. "Only members of the team called 'QA' are allowed to transition Jira tickets from state A to state B, SOC2 requires it". No, I'm pretty user SOC2 doesn't specify issue tracker workflows. "You need to name your git branched XYZ-abc-foo-bar, because of SOC2". You're telling me that accountants are specifying source control conventions?
- windowsworkstoo 7y ago
  The way it works best is when you have multiple accounts ,you have a single Identity account, which is where your user accounts live. This account basically allows sign in and assume role - oh and you can't assume unless you have authenticated with MFA. Then, all your other accounts - dev, prod, service, whatever - simply have roles and no user management overhead - i.e you aren't duplicating users in a bunch of accounts and having to deal with a bunch of different identities.
- time0ut 7y ago
  As mentioned, AssumeRole is a critical part of a multi-account strategy, which is considered an AWS best practice. In addition to that, it is an integral part of an SSO strategy. Ideally, instead of a pile of IAM users with separate credentials, user identities should be federated from your identity provider (like Auth0, Ping, AzureAD, whatever). There are a number of setups, but they all boil down to your users trading their corporate identity for temporary AWS credentials via something like an AssumeRoleWithSAML call. This is only slightly more complicated to set up than a good IAM user/group architecture, but has the benefit of not needing to deal with IAM users and multiple sets of identities for your users. You can also map particular roles back to something like AD groups to control who can assume what.
saagarjha 7y ago
> Another bonus point: standardize everyone on Chrome. :(
- Fnoord 7y ago
  The next sentence was worse: > We don’t have to grumble about why; we’ll just observe that this is what almost every security team does anyways.
mushufasa 7y ago
To be clear, when you talk about using SSO with all your applications, are you talking about A) all of the applications your team uses e.g. SaaS like GDocs or AirTable or whatever or B) the application you are creating? e.g. in lieu of your own database? Or maybe you mean for both?
- tptacek 7y ago
  Both. As much as possible. You'd like as many of the answers to questions about "how do you manage access to this application, know who has access to it, and ensure that people who shouldn't have access to it don't" be "screenshots and logs from your SSO system".
  - abraae 7y ago
    I'd be interested in any opinions as to whether keycloak is an acceptable solution for SSO wrt SOC2. (Hopefully so as we are well committed to it).
    - kasey_junk 7y ago
      SOC2 doesn’t judge which SSO you use (or even if you use SSO). If you write up your processes with your SSO provider and you follow your processes any SSO (or none!) works.
abeld 7y ago
Any suggestions for MDM for Linux laptops? Most device management solutions I have seen are for either Windows or Mac, but is there one that is accepted by auditors and is not utter garbage UX wise for the user on Linux, where the user is most likely going to want and have full admin access to their own laptop? (I.e. since the user in question is a developer, I feel a strong aversion to not trusting them to do system administration on their own laptop.)
- matharmin 7y ago
  We passed our SOC2 Type 2 audit without any MDM - we're just doing a manual quarterly audit on machines to check that they're update to date. MDM helps to detect issues earlier, and can remove the need for manual audits, but is not a hard requirement - same with most other things in SOC2.
- diafygi 7y ago
  We've been looking into Osquery. It's open source and appears to be very lightweight. Has anyone else used it? https://www.osquery.io/ https://www.osquery.io/
  - tptacek 7y ago
    osquery is great and, while it does not tick precisely the same checkboxes as Jamf or Fleetsmith, it'll almost certainly suffice for evidence generation for compliance (osquery is in fact much better at producing "evidence" than most MDM tools are).
    - zercurity 7y ago
      Just a shameless plug we've written thousands of queries to automate many compliance checks against major frameworks such as: NCSC-CE, CIS, SOC and ISO. https://www.zercurity.com/product/compliance/ https://www.zercurity.com/product/compliance/ It'll even collate all the evidence for you and help your employees improve their own cyber security posture based on your corporate policies.
statictype 7y ago
What VPN tools support SSO? What's a recommended soution?
deedubaya 7y ago
> SOC2 is about documentation, not reality Yup. If you’re a fixer, knowing this beforehand is going to save you a lot of pain.
csmattryder 7y ago
> Sign up for or set up a centralized logging service. It doesn’t matter which. Pipe all your logs to it. Is there one recommended by HN for multi-platform use? I'm in the process of preparing for ISO27001 certification and as the topic has arisen, I'd love to get a few opinions if possible.
- abarringer 7y ago
  There are a lot of amazing fancy services available... for a fee. We log billions of lines a year and use GrayLog because the other services are cost prohibitive.
  - tptacek 7y ago
    Which is totally fine. Auditors aren't going to care what your log service is. They might, on the other hand, ask you to show evidence of, like, a log line when someone accesses the admin console. You want that to be easy to generate and, just as importantly, you want the process of obtaining that log line to be easy to describe: "go to this one place, type in this one query, save the result". In a perfect world, you want the answers to lots of auditor questions to be the same, perhaps modulo the "one query" you type in to generate the result. This isn't because the auditor is going to care whether you have to log into 15 different hosts to grep for 20 different log lines; they have no idea what "grep" even is. It's because it's a lot of work to document 15 different processes coherently. This idea is the basic lens through which people should be reading our recommendations here.
zeveb 7y ago
A lot of really good stuff in here. I have a few questions & quibbles though. > You’re probably all Macbooks. What if we're not? Are there any good MDM solutions for Linux? I would prefer not to force macOS on folks who don't want it. > Another bonus point: standardize everyone on Chrome. Why not stick with Firefox? It has the advantage of at least trying to keep user information secure. There's a lot exciting in here, though. I would love to transition to SSH certificates issues by some fancy OAuth2 service. I imagine one could use a named pipe to request them on-demand, so one could just issue 'ssh foo' and everything would Just Work.
jgalt212 7y ago
It's amazing how many of these recommendations are cloud based. If you have a cloud based box with bad security, anyone can get to it. If you have a box you own on your own premises, you can have crummy security on that box and still be in good shape. I like belt and suspenders. 2FA and physical security.

109 points by lvh 7y ago

wglb 7y ago

>Any time anything security relevant incident happens, you could make a private Slack channel named for the incident. This might be a good start, but it makes me a little uncomfortable. In a true incident, there is a metric ton of stuff that I would not want to be discoverable. I like to set aside an area with locked-down access to keep the truly toxic material found during a serious incident. And for startups or other small companies reading this--the things mentioned here should not be a big deal or take enormous time to do. The earlier you do what is recommended in the post, the happier everyone will be. I'm reminded of my Dad's saying: Tires are like insurance: When you need it, it is too late. [edit typo]

tptacek 7y ago
A couple people told me the same thing, and I think it's a valid concern as security process. On the other hand: Slack-channel IR has worked well for clients of ours as a compliance step, and having Slack-channel IR is better than having no IR from a security posture perspective.
- superq 7y ago
  That's a good point. Even just using Github or Gitlab issues to track incidents with approvals is better than nothing.

ejcx 7y ago

Very good post. This ticks all the boxes on the fundamentals when spinning up a security program. SOC2 Type2 is really where you want to be, but it takes time. Navigating compliance for startups is pretty challenging and I see so many not having a clue how to navigate sales without certs but it's super doable, and getting these things finished get you pretty far along towards Soc2 type1, and shows a lot of goodwill to share these practices even _before_ you have any certs

jesseendahl 7y ago

This is a fantastic article overall. As someone who has now gone through SOC 2 twice (first at Dropbox as an IC, now at Fleetsmith as cofounder/CSO, the only part I disagree with is the advice re: MDM. If you want to make SOC 2 easy, you should choose us (fleetsmith.com) over the competition. There are some specific things SOC 2 cares about with regard to laptops. The ones that can take effort are: - User to device inventory attribution ("give me a list of all your Macs and which employees they belong to") - FileVault enforcement, with automatic (and secure) escrow of the recovery keys - Enforcement of some kind of AntiVirus (either the native stuff built in to macOS, or deployment of a third party solution like MalwareBytes) Each of those 3 items are very time-intensive efforts with competing products. With Fleetsmith, each of them are quite literally (not marketing hype) a few clicks. We're also the leader in terms of security. If you're interested in the intersection of MDM and security research, check out the following: "Hacking a Brand New Mac Remotely, Right Out of the Box" — Article summarizing research presented at Black Hat 2018. https://www.wired.com/story/mac-remote-hack-wifi-enterprise/ https://www.wired.com/story/mac-remote-hack-wifi-enterprise/ -- A Deep Dive into macOS MDM (and how it can be compromised) — 61 page whitepaper related to Black Hat research. https://i.blackhat.com/us-18/Thu-August-9/us-18-Endahl-A-Deep-Dive-Into-macOS-MDM-And-How-It-Can-Be-Compromised-wp.pdf https://i.blackhat.com/us-18/Thu-August-9/us-18-Endahl-A-Dee... -- On DEP, MDM, device identity, and authentication — Blog post on the security of the device enrollment process. Includes Fleetsmith’s secure device enrollment implementation, in hopes that other vendors in the space will adopt it. https://medium.com/fleetsmith/on-dep-mdm-device-identity-and-authentication-82c9b78cb9c2 https://medium.com/fleetsmith/on-dep-mdm-device-identity-and... -- An Enterprise Security Roadmap for macOS — Detailed blog post on improvements that Apple should make to macOS and MDM, and why. Includes a detailed list of over 50+ bug reports/feature requests. https://blog.fleetsmith.com/macos-enterprise-security-roadmap/ https://blog.fleetsmith.com/macos-enterprise-security-roadma... If anyone is interested in chatting about any of this stuff (the product or the security side) I'm on Twitter at @jesseendahl and on the MacAdmins Slack (macadmins.org) at @jesse.

tedivm 7y ago
My issue with most of these solutions- including this one- is that I don't want separate MDM platforms for my Windows and OSX users.

tialaramex 7y ago

I guess this is appropriately sceptical about audit at least. I think people both over and under-estimate audit (in different ways), but certainly if I have to pick it's the over-estimation of the value of audit which hurts and so the scepticism in this piece is warranted.

lvh 7y ago
Maybe! I get the impression there are definitely plenty of people have bought SOC2s the way they also buy pentests: "I'm spending $X0,000 today so I can close $X00,000 in sales tomorrow". Which of course, we as security people would say is spending a lot of money and getting nothing, and the business person says is a necessary expense and something to keep in mind when re-evaluating margins :) (But yes lots of companies also mistake SOC2 for a security audit of course!)

tialaramex 7y ago

Typo: In the list of "things you don't do" it lists Web Application Firewalls and I thought there's an amusing asterisk for the claim that they "don't work at all"† But sadly there isn't - that asterisk is supposed to be the next bullet point for Endpoint Protection and AV. † So many missed opportunities. These things are so awful.

lvh 7y ago
Thanks! Just fixed that.
- pvg 7y ago
  Also 'log munging' and scene from Love Actually instead of Say Anything
  - lvh 7y ago
    Wait, I can't find Love Actually and Say Anything in the post. Are you talking about a draft?
    - pvg 7y ago
      taped to the boom box playing Peter Gabriel you hold aloft outside their offices That's Say Anything. It's a movie from the previous century. The scene from Love Actually you can actually recognize from gifs and recent SNL parodies.

superq 7y ago

I've been through the process before and just went through it again, and the first thing listed (Single Sign-On) is not required at all. I'm not even sure it's mentioned directly in the AICPA criteria. I'm also not sure what SSO really buys you, except for just moving the criteria target to another SOC-2 report. ;) Also, MDM is not really critical at all, as long as you have a solid/documented way of managing accounts on web and mobile apps. I do like the rest of the article except for the list itself, however. SOC-2 is all about documentation and processes. Justifying your security choices is less important than carefully and fully documenting them, and the processes that you have in place.

tptacek 7y ago
SOC2 doesn't really "require" much of anything. The question we're answering is: "which security engineering projects can you undertake that will make a SOC2 audit go more smoothly". Because SSO directly addresses a lot of access control control points, and generates a lot of evidence for those control points, and because it's generally a very good practice to have anyways, it'd be the first bit of security engineering we'd recommend to ratchet up your maturity. What I can tell you is that the IRLs I've seen, both from big 4 auditors and from SOC2 boutiques, have dozens of questions that are directly answered by a sane SSO configuration. We've watched clients clear SOC2 audits without any coherent SSO. It's clearly doable. This is all made more tricky by the fact that different SOC2 auditors have different requirements. They're in one sense or another all negotiable, in that you can always switch auditors if they're unreasonable, and we've definitely collected several horror stories about aborted SOC2 processes that were resumed with a different vendor. And, to layer more complexity on that, different bigCo customers will have opinions about who did your SOC2. It's all a mess.
- superq 7y ago
  Right, agreed 100%. In terms of security, the value of centralizing credentials is debatable.
  - tptacek 7y ago
    The other bit of subtext in this post is that you often have multiple ways of addressing control points auditors bring up, and we'd like to steer startups towards the good ways of doing that. So if an SSO keeps you from having an insane password rotation policy, or an MDM (also not "required") keeps you from installing Mac AV software, it's super worth it to us.

teilo 7y ago

Honestly, this misses a huge point and does more harm than good. Having some of these things in place is fine of course, but it don't really help you much, nor is most of it required. SOC2 does not require: SSO, MDM, or almost anything specifically (And what's with the JAMF pro recommendation? MDM is more than iPhones). What it does require are controls. It does not specify what those controls are. You need to create them yourself, and they need to be sufficient to meet the requirements of the Trust Services Criteria. And to have controls, you need to know what you are controlling and why. This brings me to my point: To succeed in SOC2 you actually have to have a plan. You have to have written, reviewed, implemented, and audited policies. THAT is the single biggest hurdle for most companies. You also need to know how to do a risk assessment on your organization. This is not terribly hard, but it is essential to SOC2. And finally, you need buy-in from the governing bodies of your organization. None of these things I mentioned are products. You can't buy them. They take work. A hell of a lot of work. I will guarantee that most companies doing this for the first time do not have half of the processes in place that SOC2 requires. I doubt that 20% have internal audit procedures, for example, or sufficient end-user training. And one more thing that will take nearly anyone who had done security by surprise if they don't know it's there. The COSO Principles. These were added to SOC2 in the wake of the Lehman Bros/Enron scandal. They extend SOC2 to the entire governance structure of your organization, and include controls on financial reporting, hiring practices, employee review processes, etc. This is a major PITA, because it lies far outside the bailiwick of most CISOs or equivalent, and, again, it requires extensive cooperation from the rest of senior management. As you can probably tell, I've done this before.

tptacek 7y ago
We've watched our clients get SOC2 certified and been directly involved in the IRL and audit interview processes, and circulated this among peers that have also been SOC2 certified, and we're pretty comfortable with the advice we're offering. So: As we've said repeatedly, SOC2 doesn't "require" much of anything. It certainly doesn't call SSO or MDM out by name. What it instead involves are abstract control points that are addressed with evidence. As the top of the post says, the point is to engage in security engineering practices that generate evidence useful in SOC2 engagements. So, you can certainly freestyle your application and infra access controls, and make up policy responses to the IRL questions on the fly. You can also sit around and worry about which of the "COSO Principles" you're covered on or not covered on. Or, you can do some basic sensible security engineering things that are almost certain to cover the majority of the evidence requests your auditors generate, in most cases without even needing to be aware of the AICPA guidance line items. You make your own process recommendation here: do a "hell of a lot of work" to have "written and audited policies" and a "risk assessment" and become aware of the "COSO Principles". I have no trouble believing that approach works, because after seeing and being involved in a bunch of SOC2 audits and talking to people who did SOC2 audits, I believe everything works. More importantly, we see startups led around by the nose by insane questionnaires (and a SOC2 IRL is certainly that). We've talked to firms that have been told by their SOC2 auditors to install IDS systems, WAFs, and Mac AV software. We are alarmed by the prospect of a startup without in-house security or compliance expertise reading what's out there about SOC2 --- especially the AICPA documentation, or example IRLs --- and then just going and doing that stuff. They'd be wasting a tremendous amount of time without realizing that smart startups skip a lot of that work and deploy none of the junk and get SOC2'd just fine. So, if you're going to do something, do something sensible. What I think people should be especially careful about is taking advice from people who have just done SOC2 at a single company or with a single auditor. They are all different. There are processes where you'll end up explaining what a URL is. There are processes where you'll end up explaining why you have VPC flow logs disabled. The value we're offering here is that we've seen it done repeatedly, with multiple auditors.

user5994461 7y ago

>>> Web Application Firewalls: Most SOC2’d firms don’t use them, and most WAFs don’t work at all. Most startups are on Cloudflare and Cloudflare does WAF out of the box.

tzs 7y ago

The article and the comments here contain a lot of TLAs and the like that many will not be familiar with. Anyone want to expand some of these to save people a bunch of Googling/DDGing/Binging? AD AES AICPA CISO COSO CSO DEP FDE FIM IDS IR JAMF LDAP MDM OIDC SOC2 SSO S/N WAF I don't recall ever seeing a comment thread with that many such things.

deleted 7y ago
[deleted]
julianj 7y ago
Sorry for any mistakes, mobile. AD active directory AES advanced encryption standard AICPA American Institute of Certified Public Accountants CISO chief information security officer COSO risk management framework CSO many things, probably chief security officer in this context DEP data execution prevention FDE full disk encryption FIM file integrity monitoring IDS intrusion detection system IR incident response JAMF apple device management LDAP lightweight directory access protocol MDM mobile device management OIDC open id connect SOC2 audit standard SSO single sign on S/N serial number WAF web application firewall
- tptacek 7y ago
  Different DEP here. :) We're talking about the Apple Device Enrollment API.
  - julianj 7y ago
    Thanks, I hadn't yet made it through the full thread for context.

antoncohen 7y ago

I'd like more detail on the advantages of AWS AssumeRole, and what attacks it is designed to protect against. It must be more than CloudTrail logs, because normal API usage gets logged to CloudTrail. One thing I'd like to highlight is that SOC2 is about having controls (of your choosing), and documenting and proving you are following those controls. I think it is important to pick controls you actually want to follow, and that those controls aren't so specific that you get fenced in to a bad process. I've worked at a few companies that have gone through SOC2, one of them (Dropbox) did it very well. I think the average engineer didn't need to know about SOC2, or what all the controls were, because the controls were well thought out, and automation took care of the proof. At another company every engineer was constantly saying "you have to do that because of SOC2", because the controls intruded on the way engineers worked. "SOC2 requires that two people approve every PR". Hmm, no the accountants that created SOC2 don't know what PRs are. "Only members of the team called 'QA' are allowed to transition Jira tickets from state A to state B, SOC2 requires it". No, I'm pretty user SOC2 doesn't specify issue tracker workflows. "You need to name your git branched XYZ-abc-foo-bar, because of SOC2". You're telling me that accountants are specifying source control conventions?

windowsworkstoo 7y ago
The way it works best is when you have multiple accounts ,you have a single Identity account, which is where your user accounts live. This account basically allows sign in and assume role - oh and you can't assume unless you have authenticated with MFA. Then, all your other accounts - dev, prod, service, whatever - simply have roles and no user management overhead - i.e you aren't duplicating users in a bunch of accounts and having to deal with a bunch of different identities.
time0ut 7y ago
As mentioned, AssumeRole is a critical part of a multi-account strategy, which is considered an AWS best practice. In addition to that, it is an integral part of an SSO strategy. Ideally, instead of a pile of IAM users with separate credentials, user identities should be federated from your identity provider (like Auth0, Ping, AzureAD, whatever). There are a number of setups, but they all boil down to your users trading their corporate identity for temporary AWS credentials via something like an AssumeRoleWithSAML call. This is only slightly more complicated to set up than a good IAM user/group architecture, but has the benefit of not needing to deal with IAM users and multiple sets of identities for your users. You can also map particular roles back to something like AD groups to control who can assume what.

saagarjha 7y ago

> Another bonus point: standardize everyone on Chrome. :(

Fnoord 7y ago
The next sentence was worse: > We don’t have to grumble about why; we’ll just observe that this is what almost every security team does anyways.

mushufasa 7y ago

To be clear, when you talk about using SSO with all your applications, are you talking about A) all of the applications your team uses e.g. SaaS like GDocs or AirTable or whatever or B) the application you are creating? e.g. in lieu of your own database? Or maybe you mean for both?

tptacek 7y ago
Both. As much as possible. You'd like as many of the answers to questions about "how do you manage access to this application, know who has access to it, and ensure that people who shouldn't have access to it don't" be "screenshots and logs from your SSO system".
- abraae 7y ago
  I'd be interested in any opinions as to whether keycloak is an acceptable solution for SSO wrt SOC2. (Hopefully so as we are well committed to it).
  - kasey_junk 7y ago
    SOC2 doesn’t judge which SSO you use (or even if you use SSO). If you write up your processes with your SSO provider and you follow your processes any SSO (or none!) works.

abeld 7y ago

Any suggestions for MDM for Linux laptops? Most device management solutions I have seen are for either Windows or Mac, but is there one that is accepted by auditors and is not utter garbage UX wise for the user on Linux, where the user is most likely going to want and have full admin access to their own laptop? (I.e. since the user in question is a developer, I feel a strong aversion to not trusting them to do system administration on their own laptop.)

matharmin 7y ago
We passed our SOC2 Type 2 audit without any MDM - we're just doing a manual quarterly audit on machines to check that they're update to date. MDM helps to detect issues earlier, and can remove the need for manual audits, but is not a hard requirement - same with most other things in SOC2.
diafygi 7y ago
We've been looking into Osquery. It's open source and appears to be very lightweight. Has anyone else used it? https://www.osquery.io/ https://www.osquery.io/
- tptacek 7y ago
  osquery is great and, while it does not tick precisely the same checkboxes as Jamf or Fleetsmith, it'll almost certainly suffice for evidence generation for compliance (osquery is in fact much better at producing "evidence" than most MDM tools are).
  - zercurity 7y ago
    Just a shameless plug we've written thousands of queries to automate many compliance checks against major frameworks such as: NCSC-CE, CIS, SOC and ISO. https://www.zercurity.com/product/compliance/ https://www.zercurity.com/product/compliance/ It'll even collate all the evidence for you and help your employees improve their own cyber security posture based on your corporate policies.

statictype 7y ago

What VPN tools support SSO? What's a recommended soution?

deedubaya 7y ago

> SOC2 is about documentation, not reality Yup. If you’re a fixer, knowing this beforehand is going to save you a lot of pain.

csmattryder 7y ago

> Sign up for or set up a centralized logging service. It doesn’t matter which. Pipe all your logs to it. Is there one recommended by HN for multi-platform use? I'm in the process of preparing for ISO27001 certification and as the topic has arisen, I'd love to get a few opinions if possible.

abarringer 7y ago
There are a lot of amazing fancy services available... for a fee. We log billions of lines a year and use GrayLog because the other services are cost prohibitive.
- tptacek 7y ago
  Which is totally fine. Auditors aren't going to care what your log service is. They might, on the other hand, ask you to show evidence of, like, a log line when someone accesses the admin console. You want that to be easy to generate and, just as importantly, you want the process of obtaining that log line to be easy to describe: "go to this one place, type in this one query, save the result". In a perfect world, you want the answers to lots of auditor questions to be the same, perhaps modulo the "one query" you type in to generate the result. This isn't because the auditor is going to care whether you have to log into 15 different hosts to grep for 20 different log lines; they have no idea what "grep" even is. It's because it's a lot of work to document 15 different processes coherently. This idea is the basic lens through which people should be reading our recommendations here.

zeveb 7y ago

A lot of really good stuff in here. I have a few questions & quibbles though. > You’re probably all Macbooks. What if we're not? Are there any good MDM solutions for Linux? I would prefer not to force macOS on folks who don't want it. > Another bonus point: standardize everyone on Chrome. Why not stick with Firefox? It has the advantage of at least trying to keep user information secure. There's a lot exciting in here, though. I would love to transition to SSH certificates issues by some fancy OAuth2 service. I imagine one could use a named pipe to request them on-demand, so one could just issue 'ssh foo' and everything would Just Work.

jgalt212 7y ago

It's amazing how many of these recommendations are cloud based. If you have a cloud based box with bad security, anyone can get to it. If you have a box you own on your own premises, you can have crummy security on that box and still be in good shape. I like belt and suspenders. 2FA and physical security.