[HN Gopher] SOC2: The screenshots will continue until security i...
___________________________________________________________________
SOC2: The screenshots will continue until security improves
Author : todsacerdoti
Score : 256 points
Date : 2022-07-07 19:14 UTC (3 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| xpe wrote:
| I'm underselling SOC2. It assures some things pentests don't:
| * consistent policies for who in the company gets access to what
| ...
|
| That's a start. Of course, having policies raises a new question
| -- how well are they practiced? To what degree are they:
|
| a. discoverable via internal tools?
|
| b. descriptive and understandable (the policies use terminology
| that maps to the business processes clearly)?
|
| c. measured?
|
| d. internalized by employees as part of the culture?
|
| e. enforced (as desired)?
|
| f. externally reported (e.g. to downstream customers)?
|
| g. reviewed when appropriate?
|
| h. adjusted or removed as needed?
|
| There are some spectacular failure modes of policies in the real
| word. Here are five attributes that fit together nicely into a
| mosaic of dysfunction:
|
| * Everyone has to take a sleep-inducing thirty minute training.
|
| * Policy compliance is "tracked" with a spreadsheet on an ad-hoc
| basis.
|
| * Everyone in the organization has to "check off" that they
| comply, starting at the bottom and working up the chain to El
| Jefe.
|
| * If something hits the fan and you need someone to blame, follow
| the paper trail and blame the people who incorrectly attested to
| policy compliance.
|
| * Virtually anyone _could_ fail compliance if you haul out the
| microscope. This is a feature, not a bug. Now you have a
| convenient and official way to get rid of people you don 't like
| for arbitrary reasons.
|
| This is stylized, yes, but not too far off the mark at some
| places.
| AtNightWeCode wrote:
| SOC2 is a deal breaker. It is already a pain to work for large
| American companies. You are forced to not be honest in the
| audits. The audits are complete bs by the way. Some external off
| shored company that wants screenshots of some specifics that they
| somehow found important. It is more Kafka than actual value. Miss
| those days, not...
|
| It is better how it works in EU. Track money and stock activity +
| GDPR. SOC does not prevent Enrons. I mean, even if there was a
| complete ledger of everything ever done in a company you could
| still not prevent Enrons. The fraud part should have been
| detected anyway. And would have in EU, I would say.
|
| Edit: D'oh! I mixed it up with SOX that is mandatory.
| NovemberWhiskey wrote:
| > _SOC does not prevent Enrons._
|
| SOC does not prevent Enrons; SOX does ... that's a different
| audit, and a different process, though.
|
| > _The fraud part should have been detected anyway. And would
| have in EU, I would say._
|
| cough ... Wirecard ...
| AtNightWeCode wrote:
| D'oh! You are right of course. I mixed it up with SOX that is
| mandatory.
| CoastalCoder wrote:
| > You are forced to not be honest in the audits.
|
| Not sure I agree. The question is, what are you willing to
| sacrifice in order to be honest.
| michaelt wrote:
| When an audit imposes a dumb requirement that nobody will
| benefit from, and it's easier to change jobs than to do the
| dumb thing, you have the _theoretical_ option to be honest
| and do it.
|
| But if it's easier to change jobs than to be honest - is the
| option to be honest one that will be taken by any rational
| person?
| whatinthenote wrote:
| ceejayoz wrote:
| This matches our experience well. Surprisingly intensive in some
| unexpected ways, and surprisingly silly and incomplete in others.
| I get that the Fortune 500s want it, but having now done one I
| don't quite know why they value it beyond a checklist item in
| their own compliance.
| NovemberWhiskey wrote:
| You know how you get software engineering candidates that look
| awesome on paper, but can't code FizzBuzz?
|
| Same reason.
| mjr00 wrote:
| This is a great way to put it. People here are bashing SOC2
| because it doesn't go in-depth enough, it's just checking for
| the basics, it doesn't actually stop hackers from accessing
| insecure AWS buckets or ransomware attacks, etc etc, and
| they're absolutely right.
|
| But it's meant to be a _minimum_. It verifies that there isn
| 't one copy of the source code on a dev's laptop. It verifies
| that a dev who gets fired won't be able to log into the
| production server and delete all data in retaliation. It
| verifies that an intern isn't able to completely destroy the
| business by accidentally deleting the production database
| (because you have routinely tested backups and a documented
| RTO/RPO, of course). Being able to demonstrate this level of
| minimum competency is extremely valuable when you're in the
| B2B world and trying to sell your product to a larger client.
|
| The paperwork is a hassle, but if your company is following
| best practices for development and operations, there
| shouldn't be much of a step change in what you're actually
| doing on a day-to-day basis.
| JoshTriplett wrote:
| > This is the only issue we ended up having to seriously back-
| and-forth with our auditors about. We held the line on refusing
| to do background checks, and ultimately got out of it after
| tracking down another company our auditors had worked with,
| finding out what they did instead of background checks, stealing
| their process, and telling our auditors "do what you did for
| them". This worked fine.
|
| What process _did_ that company use instead of background checks,
| that you ended up doing as well?
| eoinboylan wrote:
| In Ireland there is no legal mechanism to do a background check
| unless you work with children or are in law enforcement. Even
| collecting and recording public information on individuals can
| be problematic with the data commission. Employee reference
| checks are acceptable for auditors in that case.
| hmahncke wrote:
| My company did adopt background checks, as part of our SOC-2
| requirements and because my company works with health insurers
| (which generally impose this requirement via contract,
| regardless of SOC-2).
|
| Like many people here, I didn't like the requirement. That
| being said
|
| 1) It's possible to configure background checks so you don't
| receive irrelevant information (e.g., if DUIs aren't relevant,
| then configure the check so you don't receive information about
| DUIs). In most cases, you'll just want to receive information
| about financial and privacy related offenses.
|
| 2) What you do with the information is up to you (unless your
| customers enforce certain actions). In general, the SOC-2
| auditors will want to see a plan by which you acknowledge and
| manage the risk, which doesn't necessarily mean you can't hire
| the person.
| tptacek wrote:
| The only reason I didn't write it out, besides it being boring,
| is we stole it from someone else who might rather share it
| themselves.
| InCityDreams wrote:
| So, two reasons?
| tptacek wrote:
| Oh HN I can't quit you.
| HorizonXP wrote:
| As pedantic as this comment thread was, I laughed.
| parkerhiggins wrote:
| Invite them to share?
| xorcist wrote:
| I have seen that SSO requirement creep into more and more audits.
| It reminds me of the requirement to change passwords every month,
| which was everywhere but now suddenly is nowhere to be found.
|
| It's weird. It's very convenient for the user, but it's on the
| opposite side of the convenience/security divide. Hijack one
| session and re-use it for other purposes. Of course it's
| preferable to not let systems access credentials but one would
| have thought that we had yubikeys or cards and whatnot now.
| rmaccloy wrote:
| FYI, the reason the pw change requirement went away is because
| NIST published an updated set of guidelines that explicitly
| disrecommend it: https://pages.nist.gov/800-63-FAQ/#q-b05
|
| On the vendor / policy side, many/most of these questions
| trickle down from NIST or similar institutional guidance. The
| auditors pick up on that and on practices from comparable
| companies they've audited, which can be helpful when your
| industry is moving towards sanity and painful when there's a
| meme that makes no sense in your context.
|
| (If you spend significant time dealing with customer compliance
| issues, I would definitely vote that it's worth being familiar
| with the relevant subset of NIST pubs.)
| NovemberWhiskey wrote:
| SSO is important because it's the best mechanism to show that
| employee lifecycle events are being appropriately mapped into
| access controls.
|
| You only activate the SSO account when the employee onboards.
| You deactivate the account when the employee off-boards. You
| can suspend the account if the employee is on an extended
| leave-of-absence.
|
| You can do this in one place, as single source of truth, rather
| than having to demonstrate that all the different identity
| systems in which Bob is represented have deactivated him when
| you have to let Bob go.
|
| Ideally this happens automatically due to an integration
| between your HR system and your identity platform.
|
| The alternative is that you have some kind of runbook that
| tells you exactly who to speak to about removing accounts from
| what systems (etc) which rapidly becomes unmanageable as scope
| of applications and number of employees increases.
|
| Even for small firms, you can run into problems when the person
| you need to let go is the person that knows how to run the
| process.
| michaelt wrote:
| Still - do you use SSO for your password manager?
|
| Edit: For your _work_ password manager.
| NovemberWhiskey wrote:
| I don't use a password manager at work.
|
| But for certain operations (e.g. privileged access stuff),
| we do have step-up to a second authentication factor in
| addition to SSO.
| eranation wrote:
| Going through SOC2 as well, I have a similar experience :)
|
| > I was surprised by how important this was to our auditors. If
| they had one clearly articulable concern about what might go
| wrong with our dev process, it was that some developer on our
| team might "go rogue" and install malware in our hypervisor
| build.
|
| > ... our auditors cared a lot about unsupervised PRs hitting
| production.
|
| It's indeed a growing concern, and (shameless plug) the main
| reason we founded arnica.io (help organizations automate that
| process without hurting development velocity)
| sergiotapia wrote:
| I will need something like this in 12 months. Can you add me to
| your CRM to reach out in a year please? Find me on linkedin,
| thank you!
| xtracto wrote:
| Have a look at https://www.vanta.com/ when you actually get
| involved in the SOC2 dance. A couple of years ago I took a
| startup through the SOC2 and PCI L1 compliance process
| "manually". At the same time Vanta was kind of starting.
|
| I decided not to use them because I (foolishly in
| retrospective) wanted to "learn" the SOC2 and PCI cert
| process by walking through it (kind of how you do
| derivatives, intergrals, numerical methods in school by hand
| so that you "grok" them).
|
| Since then, I've heard good things about Vanta from a couple
| of friend CTOs that adopted them. If I had to go through
| SOC2, PCI or ISO27001 (I did that in yet a previous startup)
| I would deffinitely go with them.
| ceejayoz wrote:
| We similarly had good results with Vanta (and their
| recommendation of a Vanta-friendly firm).
| yashap wrote:
| The blog post in general was good/informative, but I gotta say,
| this quote does reduce my confidence in Fly quite a lot:
|
| > To get the merit badge, we also had to document an approval
| process that ensured changes that hit production were reviewed
| by another developer.
|
| > This isn't something we were doing prior to SOC2. We have
| components that are effectively teams-of-one; getting reviews
| prior to merging changes for those components would be a drag.
| But our auditors cared a lot about unsupervised PRs hitting
| production.
|
| > We asked peers who had done their own SOC2 and stole their
| answer: post-facto reviews. We do regular reviews on large
| components, like the Rust fly-proxy that powers our Anycast
| network and the Go flyd that drives Fly machines. But smaller
| projects like our private DNS server, and out-of-process
| changes like urgent bug fixes, can get merged unreviewed (by a
| subset of authorized developers). We run a Github bot that
| flags these PRs automatically and hold a weekly meeting where
| we review the PRs.
|
| Letting code go straight to prod without a review is just IMO a
| really bad practice. It sounds like they've improved
| significantly here, but still have plenty of gaps where people
| can ship to prod with no code review until it's been running in
| prod for up to a week. This isn't just about stopping bad
| actors, it's 99% about preventing all sorts of
| bugs/mistakes/bad ideas from hitting prod. Obviously automated
| tests are the main line of defence there, but code reviews are
| very important too. I'm kind of shocked that they want to skip
| out on this. I personally wouldn't want to rely on a core piece
| of infrastructure from a team practicing this level of cowboy
| coding.
| d_watt wrote:
| Part of taking on SOC 2 is also choosing whether you want your
| attitude to be "Let's do the minimum to get past the audit" and
| "Let's take this framework, and figure out where we can learn
| from it."
|
| The post mentions background checks. On the one hand, I
| understand there's a real issue with these. On the other, if my
| PAAS isn't ensuring repeat offender fraudsters don't have access
| to sensitive data, that's possibly an area of concern. Hopefully
| the things they took from the other mentioned company do increase
| due diligence in vetting employees who have access to
| sensitive/regulated information.
|
| Use it as a framework to actually think about BCP, DRP, etc, etc,
| and it won't be a total waste of time.
|
| Edit: Also adding I bring up background checks as an example of
| learning from vetted practices, rather than trying to attack the
| decisions of fly. I respect this article, especially where it's
| easy for people on the internet to criticize decisions, when the
| reality is security is a series of tradeoffs, and to function as
| a business means having imperfect processes.
| ceejayoz wrote:
| > On the other, if my PAAS isn't ensuring repeat offender
| fraudsters don't have access to sensitive data, that's possibly
| an area of concern.
|
| I don't know that there's much evidence that background checks
| work for this, though.
| doubled112 wrote:
| I've always been mildly amused at the credit check.
|
| I'm sure bad credit is the indicator they're looking for, but
| what does it mean to them?
|
| A new hire makes bad decisions? A new hire could be easily
| bought or bribed? A new hire is broke and needs a job?
| Spooky23 wrote:
| It's a proxy for having your shit together.
|
| The bankrupt dude with a felony DWI is a liability for
| anything involving cash, driving or public contact.
| TylerE wrote:
| > A new hire could be easily bought or bribed?
|
| This one. Same reason it's looked at for a security
| clearance.
| TechBro8615 wrote:
| I would think it would be fairly obvious that a candidate
| could be "bought or bribed," simply from the fact they're
| asking for a job in the first place. They're willing to
| exchange their time for money, i.e. "be bought."
|
| So why do people _not_ commit corporate espionage? Well,
| it might have more to do with character traits than
| financial stability. In fact, most spies probably have
| their life fairly well together, and will have perfect
| credit. As for any asset they might compromise, what's
| the difference between someone with poor credit applying
| to a job because they need the money, vs. applying to a
| job because they need more money from your enemy bribing
| them? I'd argue the difference comes down to character.
|
| So for that reason, I'm skeptical of the effectiveness of
| a credit report as a proxy for likelihood to commit
| corporate espionage. A good credit report doesn't seem to
| offer meaningful signal in either case of a malicious
| attacker or a desperate contributor. A bad credit report
| produces as many false positives as a good one.
| TylerE wrote:
| You're not afraid of a spy.
|
| You're afraid of someone with 100k in gambling debts to
| the mob.
| ceejayoz wrote:
| Which isn't all that likely to show up on either a credit
| report or a background check.
| TylerE wrote:
| It will. You pay the guy who will break your legs first.
| Thus you will be delinquent on other stuff.
| NovemberWhiskey wrote:
| I mean, they're pretty effective for determining whether
| people have convictions (caveats apply, depending on your
| jurisdiction) for that kind of stuff, right?
|
| One of the problems with not doing background checks is _ex
| post facto_ if you do have problems with an employee, and it
| turns out that you _could_ have discovered them with a
| background check, then that can figure into your liability.
| d_watt wrote:
| Slightly different, but in a past life working in a field the
| company had extreme access to people's homes, we definitely
| weeded out some people who should not be given access to a
| strangers home using background checks.
|
| Again, they're not ideal, and there's a large social concern
| of a permanent record like that, but you have a duty of care
| if your customers are trusting you.
| [deleted]
| mrkurt wrote:
| We definitely don't do the minimum! Our goal was to keep the
| scope manageable so the Type 2 certification goes smoothly. The
| side effect of this is that the things we _did_ put into scope
| are things we expect to do really well.
|
| Preventing access to sensitive data is important. None of the
| top ten ways we try to solve that include "background checks",
| though.
| tptacek wrote:
| I will have more to yell about this in 3 hours because I have
| a thing I want to yell about this. Free stickers if someone
| yells it for me before I'm done with this appointment.
| rmaccloy wrote:
| Co-sign.
|
| You can run a SOC2 compliance program earnestly or as a
| check-the-box exercise.
|
| If you're running earnestly, I would argue that the hardest
| thing about a SOC2 is ensuring that you stick to your guns on
| approaches that work for you and not adding cruft that you
| don't care about. If you let the latter happen, you will
| invariably end up a box-checker, and being a box-checker
| eventually contaminates a robust engineering / security
| culture.
|
| And it's hard to walk back more restrictive / cumbersome
| policies; if you delegate your SOC2 to a person who doesn't
| deeply care, they'll eventually agree to put ClamAV on all
| the hosts or something (to make the auditors go away) and
| then you're going to be stuck with that for a while.
|
| (So you need to find someone who has enough business context
| and good judgement to run the process, which is super painful
| from an opportunity cost perspective at a startup, and hard
| to locate at all at a larger company.)
| chaps wrote:
| The ssh transaction/repl log thing is frightening to me. I get
| it, but when I've needed to get creds for a user to log into a
| service, one of my go-tos has been to pull shell history on all
| the hosts they log into since they've almost definitely typed
| their password prematurely at some point. So, logging all that
| sounds like a really fun way of making a password store!
| tptacek wrote:
| The trick here is not having any passwords that anyone ever
| types.
| NovemberWhiskey wrote:
| Right - for example: openssh supports GSSAPI, which you can
| make work (e.g.) with your Active Directory or other Kerberos
| implementation.
| iasay wrote:
| I worked for a SOC2 and ISO27001 cert outfit.
|
| Real security starts with a good security culture. Audit and
| compliance assures audit and compliance passes not a good
| security culture.
|
| While I respect that the two are independent, being audited
| doesn't mean your customers aren't at risk or you care about
| them.
| sergiotapia wrote:
| >Bottom-line: SOC2 is a weak positive indicator of security
| maturity, in the same ballpark of significance as a penetration
| test report (but less significant than multiple pentest reports).
|
| Having gone through SOC2 a few times, it's more about opening
| doors to enterprise customers. The audits are very "grey" and
| subjective to your compliance auditor. Also, you get the freedom
| to say we're working on this and it allows you pass certain
| controls.
|
| One final note: watching our CISO go through this I realize it's
| utterly the most boring, soul crushing job I have ever seen. It's
| non-stop clerical paperwork that nobody will ever read but
| everybody demands to cover their ass. Pay your CISO's.
| whatinthenote wrote:
| I think one thing that doesn't get covered enough is SOC 2's
| value in providing additional data for vendor security reviews.
| That poor CISO that have to work on SOC 2 is probably tasked
| with reviewing new vendors on a regular basis as well. Sure
| there are security white papers and pentests (which can come
| from dubious sources), a SOC 2 report at least serves as a
| fairly independent assessment of a company's security maturity.
| Most people don't fully understand the amount of vendors
| required for a company to operate (take every department you
| can think of and assume each will have at least 3-5 vendors per
| quarter).
| mixmastamyk wrote:
| > We moved everything we could to our Google SSO.
|
| I realize this is for employees and it is hard to escape their
| gravitational pull, but I hope no customer data is going to
| Google unless asked for.
| michaeldwan wrote:
| This is for employees only. We don't collect more than
| necessary for customers, and if we did we sure as hell wouldn't
| be sending it to Google.
| mixmastamyk wrote:
| Thanks, and right... I don't expect maliciousness on fly's
| part. But you'd be surprised (or not) how many goog products
| phone home with anything they can find. In fact it might be
| called a "business model" of some sort.
| ceejayoz wrote:
| Google's SSO can't really phone home. You're either using
| SAML or OAuth; in either scenario, the information flow is
| Google --> the app you're SSOing into; name, email, and
| user group information.
|
| If you're SSOing into, say, AWS, Google doesn't get any
| access or private info out of AWS in the flow.
| toomuchtodo wrote:
| This content marketing is so good I don't even know if I'd call
| it marketing: it is legit educational with a weak (in a good way)
| "throw some money at us" CTA. Bravo.
| tptacek wrote:
| The CTA is mostly a joke; the trick is just having fleshed out
| opinions and sharing them. It's easy to replicate!
| alooPotato wrote:
| Agree, this is so well written.
| PyWoody wrote:
| Which is my favorite kind of marketing. Others in this group
| for me are the Backblaze Drive Stats blogs and any guide that
| DigialOcean writes.
| mkl95 wrote:
| You can be SOC2 compliant and let your employees store passwords
| in plain text on Slack, Confluence, etc. and those passwords can
| be things like "password" and be shared with your partners. No
| 2FA / SSO by the way. And that's just the tip of the iceberg.
| givemeethekeys wrote:
| If I do SOC2, then I have to spend a lot of money.
|
| If I don't, then my customers will forgive me in a few weeks and
| life goes on.
| micromacrofoot wrote:
| A lot of enterprise-scale companies won't even consider your
| SAAS if you don't have SOC/ISO, but many can certainly make it
| without those companies as customers.
| karaterobot wrote:
| If you're trying to be a vendor for a medium or larger company,
| SOC2 is usually one of the bright-line requirements.
|
| ... Which is not a good thing, because (as noted already in
| this thread) SOC2 doesn't actually make you secure. Nor does
| not having certification make you insecure. But, when used as a
| shorthand, it leads companies to engaging in compliance theater
| to get certified, spending a bunch of money without actually
| making their data noticeably more secure.
| d_watt wrote:
| If you're in B2B, plenty of larger companies will disqualify
| for not having SOC2/ISO27001.
|
| Also, it can help get you out of repeat security assessment
| questionnaires, so it can actually give you time back,
| depending on how many of those you have to field.
| jacobsenscott wrote:
| This. You'll lose more money in lost clients than SOC2 will
| cost you. It is only really expensive the first time you do
| it - after that if you just follow your own procedures the
| annual audits are pretty easy. And yes, being able to just
| reply to those security questionnaires (do you have armed
| guards in your data center?) with "see SOC2 report" is gold.
|
| Of course if you are in an industry were clients don't ask
| for soc2, don't do soc2.
| tptacek wrote:
| For a lot of shops, yes. Don't SOC2 if that's you!
| yread wrote:
| Having policies, records, procedures and documents for
| everything might also make due diligence easier in case you
| want to sell the company at some point. Makes it look a bit
| less like a messy one man show too.
| mnd999 wrote:
| CoastalCoder wrote:
| > The whole industry is a fucking racket.
|
| That seems plausible, but can you flesh out the argument?
| vosper wrote:
| Not OP, but from my experience with SOC2 the auditing and
| compliance can be a complete joke. There are auditors who're
| entirely satisfied so long as an engineer dismisses all the
| dependabot alerts in Github (even if they're all dismissed
| with the "don't have bandwidth to fix this" option).
|
| > SOC2 is a weak positive indicator of security maturity
| [quoted from TFA]
|
| I'd argure it's no indicator at all.
| xtracto wrote:
| > SOC2 is the best-known infosec certification, and the only one
| routinely demanded by customers.
|
| In the US... and I think that SOC2 is not an "infosec"
| certification per se but more of a generic policies and
| procedures certification. When I sucessfully took a startup to
| SOC2 certification, we were doing PCI DSS Level 1 compliance at
| the same time. SOC2 was very light on InfoSec per se (it was more
| "bureaucracy"), whereas PCI leaned heavily into InfoSec itself.
|
| Of course that was for an American company, the rest of the world
| uses ISO 27001
| NovemberWhiskey wrote:
| SOC2 is absolutely an infosec certification; it's just one
| that's premised around the idea that that the service
| organization should have its own mechanisms for achieving
| security goals and then demonstrate compliance with them.
|
| This is different from PCI-DSS which is single-domain-specific
| and highly prescriptive at a technical level as a result.
| InfoSecErik wrote:
| A tqbf blog with a link to a blogger agreeing with a Matasano
| blog about not liking agents? I smell a reference loop!
| time0ut wrote:
| Congrats to the team at Fly.io. I can only imagine how lucky they
| felt to have Thomas. I'm sure having that level of expertise and
| experience in house made the process relatively smooth.
|
| > You're going to write a bunch of policies. It's up to you how
| seriously you're going to take this.
|
| I think this is one of the most important points in the article.
| SOC2 is going to hold you to these policies so they better make
| sense for your business, the nature of the product, and how your
| company works. Creating well written policies is an art though.
| AtlasBarfed wrote:
| Was ssh really broken that you need teleport? No.
|
| Things were once capable of being automated across fleets of
| cattle-vms with ssh + keys now are not since teleport was shoved
| into my face.
|
| Oh, you type teleport to get somewhere, and then your SSO appears
| in a web page/browser! Because what all IT at scale needs is a
| human constantly manually authenticating with a web browser every
| 2-4 hours.
|
| I will say that at least teleport is a "solution" rather than an
| imposition by some powerpoint security group run by people
| graduating from Florida Gulf Coast College running through
| checklists. Meanwhile the core change-my-company-password webpage
| won't run in chrome because the SSL algorithms are so out of
| date. But somewhere... the company is in compliance.
|
| I like that the article is self-aware how shitty the security
| industry is, mostly a bunch of bullshit they sell the execs so
| that the execs can say "we did what was best practice".
|
| Meanwhile, Okta SSO got breached by some teenagers bribing people
| with bitcoin, and everyone just ate their public "it wasn't that
| bad" and moved on with no real accountability to what was pushed
| out in the press release. I do appreciate those evil little shits
| pulling down the pants of Okta.
|
| China must laugh at the security employed by US companies. I
| guess the real challenge isn't getting in, it's just not getting
| caught.
|
| The problem with security audit log software is that it implies
| you have centralized systems with universal access. Uhoh, your
| security audit logs are now a ransomware vector, and as someone
| else pointed out, a place you mistakenly write your password or
| worse.
|
| The problem with organizational behavior audits is that there's
| no way your org can resist being bribed, because your org is
| cheap, mistreats its workers, and abuses them. Teenagers with
| bitcoin will lulz you, background checks or no.
|
| These auditors are consultant scum. The good news is that with
| all things like Rational Rose, Xtreme agile, etc, they too shall
| pass.
|
| Especially with teenagers with bitcoins embarrassing them on the
| regular.
|
| Sorry for the rambling. There are no easy answers, and fuck all
| the compliance and "enterprisey solutions" for saying there is.
| rsync wrote:
| "There are no easy answers, and fuck all the compliance and
| "enterprisey solutions" for saying there is."
|
| https://www.rsync.net/resources/regulatory/pci.html
| TameAntelope wrote:
| Okay cool; but where is the report?
|
| Surely you didn't write all of this just to make me sign an NDA
| to see your report...
| d_watt wrote:
| I've never met a company that gave SOC 2 out without an NDA. In
| fact, I'd consider it a negative indicator of maturity to not
| require it.
| asciimike wrote:
| I've met a few where it's not explicitly required on download
| (e.g. GitHub has their SOC2 available for download on the
| enterprise admin page, but by the time you're using GHEC
| you've signed a few pieces of paper), but agreed that most
| companies aren't giving them away for free.
| d_watt wrote:
| Those systems tend to stamp your account information into
| the PDF, as well.
| dave_universetf wrote:
| This is a restriction of SOC2 itself. SOC2 produces a
| "restricted use" report, meant for the client company who
| purchased it, and for limited access by third parties that do
| business with the client company.
|
| AIUI, the intent is to ensure that the people reading the SOC2
| report don't read into it more than what the auditor intended.
| This, according to the auditors, is fraught with difficulty,
| because you need a degree of familiarity with COSO principles
| and general SOC-ese to understand precisely what the auditor is
| making strong claims about, and what is _not_ being claimed.
|
| In practice, the way this is accomplished is that the SOC2
| report includes standard verbiage saying that the report is
| only for the client company, and for specific third-parties who
| must have "sufficient understanding" to parse the report
| correctly.
|
| The client company then implements some process, with the
| guideline of "do something that won't piss off your auditor".
| For small companies, by and large the implementation is "you
| have to be an existing or prospective customer, email to ask
| for the report, and sign an NDA." The very act of requesting a
| SOC2 report implies that you know how to read a SOC2 correctly.
|
| Some larger companies set up portals where you can help
| yourself to their various reports, sometimes without NDA - but
| in that case you have to click through a pinky-promise to not
| redistribute, and the report is watermarked with your identity
| to deter distribution. A very few publish the report at a
| hidden URL and hand out the URL to anyone who emails in to ask
| for it, though I personally think that's walking a bit too
| close to the edge of what they agreed to with auditors.
|
| Companies with deeper pockets end up paying an auditor extra
| for a SOC3 report, which is "SOC2, but abridged and with
| unrestricted distribution rights". I believe the theory
| (besides giving more money to the auditor) is that the SOC3
| removes all the information that might be misinterpreted,
| boiling it down to barely more than "I, a trustworthy auditor,
| confirm that the company is doing all the right things." You
| don't get much detail, but as long as you're willing to
| transitively trust the auditor (who are themselves scrutinized
| by their regulatory bodies), that gives you a "compliance is
| yes" document that you can publish far and wide.
|
| If you want an example of what a SOC3 says, Github has one:
| https://github.githubassets.com/images/modules/site/security...
| yread wrote:
| That's a neat document. Is there something like this also for
| ISO 27001?
| parkerhiggins wrote:
| Wonder how this will mesh with Vanta's new Trust Report
| feature.
|
| All it current requires is an agreement and your email
| address.
|
| The Trust Report doesn't show all the details unless you
| configure it to show those details.
| dave_universetf wrote:
| Trust Report seems to be irrelevant to this (from what I
| can tell from the brochure without being a vanta customer),
| because it's a way for a company to publish claims about
| itself. Crucially, nowhere does it say that an independent
| auditor verified those claims.
|
| SOC2 broadly contains: - A description of
| what the company claims to do - A statement that
| the description is complete and accurate -
| Auditor's testing procedure for verifying the company's
| claims - The results of the testing -
| The auditor's overall conclusion as to whether the company
| meets the bar for SOC2.
|
| Trust Report seems to only cover the first point.
| lavezzi wrote:
| > Companies with deeper pockets end up paying an auditor
| extra for a SOC3 report
|
| They usually don't. SOC3s are generally useless.
| tptacek wrote:
| You can't publish them; it's an auditor restriction. You do a
| separate, expensive report if you want it public. Trust me,
| you're not missing much.
| [deleted]
| [deleted]
| hobs wrote:
| SOC2 - the thing your CTO tells you important but does everything
| in their power to ignore.
| spidermanjones wrote:
| > but does everything in their power to ignore.
|
| aka "make the devops team deal with it even though we're paying
| double their salary to a 'Security & Compliance Director' who
| hasn't renewed any of the certs they used to get this job since
| 1997 and hasn't the foggiest clue how the SIEM works when the
| auditor shows up"
| xpe wrote:
| > Everybody would be better off if they stopped believing what
| they believe about SOC2, and started believing what I believe
| about SOC2.
|
| Since the author is a member of the set "everybody", we have a
| paradox. :)
|
| More seriously, it would not be hard to adjust the language just
| a little bit by saying, e.g. "Most people would be better
| off...". Alternatively, the author could adopt a common style
| used in business communication where the author creates a label
| for the group that would benefit from the SOC2 knowledge. Perhaps
| call the combination of "cynics", "customers", and "true
| believers" the "unwise trifecta" or something. (I admit don't
| have a catchy term in mind yet.)
| nonameiguess wrote:
| If we're being sufficiently pedantic about this, for any person
| A and belief B, it is perfectly non-paradoxical for A to stop
| believing B and then start believing B.
| PeterisP wrote:
| If we're being sufficiently pedantic, then after this process
| person A would be right where they started and would not be
| "better off", making the original statement false.
| mrkurt wrote:
| The best thing about written English is how malleable it is.
| Everybody doesn't have to mean everybody.
| xpe wrote:
| This is why we can't have nice things.
|
| e.g. remember when "synergy" actually meant something?
| rightbyte wrote:
| I literally remember that.
| CoastalCoder wrote:
| My current view is that ambiguous language only benefits
| poets and disingenuous scoundrels (politicians, sleazy
| marketers, etc.)
|
| That said, I'm open to being talked out of this viewpoint.
| Being cynical makes me unhappy.
| orliesaurus wrote:
| Wait, what screenshots?
| ceejayoz wrote:
| Yes. Screenshots of resolved security tickets, screenshots of
| 2FA being required in the Google Apps console, etc.
| NovemberWhiskey wrote:
| In my experience, massive reams of screenshots for evidence of
| process / tooling / etc. are the norm with auditors. I have in
| the past been asked to provide screenshots of _source code_
| even.
| jameshart wrote:
| Yes. Screenshots with the desktop clock included, because
| that way you can be sure of exactly when the screenshot was
| taken.
| deathanatos wrote:
| Like the sibling, I've been through a SOC2 process, and there
| were screenshots, lots of screenshots, to try to "prove" things
| to the auditor.
|
| (I say "prove", as sometimes the question is malformed, and so
| you're trying to make the best of it as you can.)
| sandGorgon wrote:
| thank you for writing this. this is one of the truest accounts of
| SOC2 ever!
| anewpersonality wrote:
| dvtrn wrote:
| _Careful, now. "Getting SOC2-certified" isn 't the same as "doing
| the engineering work to get SOC2-certified". *Do the engineering
| now. As early as you can. The work, and particularly its up-front
| costs, scale with the size of your team.*_
|
| Emphasis mine.
|
| I've uttered this phrase or something like it so many times that
| I want to get this line fire etched onto a large, thick and
| sturdy block of wood and go back in time to several jobs where I
| and my cohorts got stuck with shoring up SOC2 tasks and smack my
| former execs with it.
|
| Half joking but the pain and trauma from past SOC2 audits due to
| _exactly this_ is real.
| simplecto wrote:
| Great writeup. Dude is totally right about the importance of
| compliance and its implications.
|
| There are other ones as well. * ISO 13485 for
| medical software * ISO 2700x for process, security, and
| change management * ISO 55000 for asset management
|
| Your eyes might glaze over, but they can really help a startup
| graduate from "move fast and break things, cowboy shit" to a
| mature and respectable engineering organization.
|
| Congrats on the SOC2 and finding a good spin on the story. It is
| also an important number of checkboxes you might need to get
| those juicy Enterprise and Government deals.
| icegreentea2 wrote:
| Pedant mode on (this is standards after all) - ISO 13485 is
| medical devices in general. You'll end up tacking on something
| like IEC 62304 for medical software and software in medical
| devices.
| mopoke wrote:
| > SOC2 is the best-known infosec certification, and the only one
| routinely demanded by customers
|
| Maybe in the US. For the rest of the world, ISO27001 is arguably
| better known.
| bflesch wrote:
| SOC2 signals much higher maturity than ISO27001, also in
| Europe.
| OrvalWintermute wrote:
| SOC2 is also one of the weakest.
|
| >Developed by the American Institute of CPAs
|
| I don't know when CPAs became infosec experts.
|
| >Each company designs its own controls to comply with its Trust
| Services Criteria.
|
| Because it depends on self-assertion, SOC2 is generally a weak
| organizational certification.
___________________________________________________________________
(page generated 2022-07-07 23:00 UTC)