For anyone unaware, a SOC3 is just a SOC2 with the audit details removed - it includes a high level statement from the company (Apple) and from the auditor (EY), that's it.
Also Apple certainly does invest heavily in security and privacy but SOC2's are so commoditized that it's like saying "look I can afford 50k", it's not particularly interesting
Importantly, anyone can get SOC2 (Type 1) by claiming some controls they figure they'll look at themselves.
SOC2 (Type 2) in theory requires an audit that you're actually doing what you said you'd do in (Type 1).
Both may also allow general lag time.
Note that firms decide on their own which controls to include, meaning, they get to decide to include or exclude various controls, the audit is on only the ones they picked. Pick basic controls, it's cheaper to pass easily, and now you have a logo.
This means SOC2s of either type cannot be compared to one another (and SOC2 Type 1 are roughly logo-ware).
SOC3 is, roughly, SOC2 redacted.
Recap:
SOC2 Type 1 is a firm picking some controls to say they'll do them, SOC2 Type 2 is roughly a firm having someone look at whether they're doing that (warning, screenshots might suffice, audit verification is probably not what you think), and SOC3 is public or non-confidential water down of that, typically without findings.
The only thing that matters is what controls, specifically, they're actually audited on. So ideally you want to know what the controls they picked are, and that a SOC2 Type 2 was audited on those.
Btw, keep in mind that "end to end encryption" means "https" and most controls have similarly basic ways of achieving them. It's difficult to fail SOC2 Type 2 core controls if you know "don't be useless" is how you pass them.
Also, it's not $50K even through the big five DIY SOC2 Type 2 shops. You can use the same ones trillion dollar firms use, by signing up online, and you'll be surprised how inexpensive relative to the cost of failing to let a business check that box in their procurement process.
I think both of you meant “Delve”, not “Deel”. Deel is a pretty successful HR startup that’s still growing at a good rate and AFAIK free of major scandals.
Again, Deel is HR, not SOC2. Delve was the SOC2 company described in the article linked above.
As a German I remember that they were banned from doing certain audits in Germany until earlier this year due to their involvement in the wirecard scandal. So at least my personal believe that their audits are done rigorously is nonexistent.
Not really. The more expensive the auditor, the more they'll work with you to craft something that will avoid exceptions. There's no real "rigor" involved in SOC2! The "audit" here is in audit in the accounting sense: "do your records square up?". SOC2 auditors are generally not technical people.
> SOC2 (Type 2) in theory requires an audit that you're actually doing what you said you'd do in (Type 1).
Even with an external audit - think of how many projects and repositories and servers and libraries and legacy systems Apple, a 50-year-old company with 166,000 employees, could have.
Then think about how much inspection is involved in a $50,000 audit. I doubt you get more than one inspector working full time for a year. In which case they've got 45 seconds of to audit each employee's entire work output. And places like EY will bill some people out at $700/hour, so it could be an order of magnitude less than that.
So this isn't some fine-toothed-comb forensic investigation or adversarial penetration test.
Literally any firm can get a SOC2 Type 1, because there's no lookback to it; the Type 1 is a pinky swear.
In practice, if you're careful about how you do your Type 1, the Type 2 is almost as trivial. Your HR/bizops practice is much more likely to screw up and cause exceptions than anything you do in IT or engineering.
From my 8 years of working SOC2 Type 2 audits done by PwC for a large PaaS Cloud with a worldwide presence (not the big 3) saying Type 2 is almost as trivial as type 1 is absolutely false. This might be true for someone running their own low volume SaaS in one region but for someone the size of Apple they are investing a lot of resource to stay on top of the controls, especially patching and permissions. If you've invested heavily in homogenization and automation your less likely to fail and the audits will be simpler. Even with significant investment I expect there are many aging corners in any "cloud" that make audits subject to failure and require a lot of work to avoid qualifying exceptions.
I'm not going to, like, whip out my resume here, but I am going to confidently assert that if you structure your Type 1 carefully, you can trivialize your Type 2, and as someone currently operating a globally deployed public cloud I can tell you right now that SOC2 doesn't really touch on anything interesting in our engineering.
I wrote an article about this, and I think it's the Correct advice for virtually every startup thinking about SOC2:
A few years before that, I wrote an article about what we learned from the consulting practice we ran building SOC2-supporting security programs for startups:
I've had the experience, many times, of offering this advice in some forum and having someone try to rebut it, claiming that SOC2 is difficult, or that real customers will pick a SOC2 attestation apart with a fine-toothed comb looking for shortcuts you took, or that they built their whole security practice around SOC2. I can go all 12 rounds with someone on any of those points, but I think you can get most of my take from those two posts.
It doesn't look like fly.io publicly disclose who there auditor is so it is hard to judge that specific part of your experience. I'm not disagreeing with your perspective on startups. I'm saying that type 2 gets much harder when you are large. non-homogenous and lack sufficient automation and monitoring.
Well you "claiming controls" to an independent CPA auditor. If a licensed CPA helps you lie -- they might lose their license (and can even get to prison), just like a tax preparer CPA can.
(Specifically: the SOC3 is a public report; the SOC2 report generally isn't supposed to be handed out except to named clients under contract. You pay extra to get the auditors to give you a report you can just stick on a website.)
The details people gloss over when throwing SOC 2 or whatever other audit costs around are the complexity of the system being audited, the chosen criteria to audit (AICPA defines 5 families of criteria... Security is one, but you can optionally add Processing Integrity, Confidentiality, etc etc) and the reputation of the auditor.
A security-only audit for a small company with a narrow product focus can indeed be very inexpensive. A full SOC 2 examination for a large organization with a mix of legacy and modern systems by a name-recognizable public accounting firm can be many hundreds of thousands of dollars, or more if you need a Big 4 firm.
In my opinion, there's not much value to the "cheap" audits... If you're doing enterprise sales to a certain kind of client, your partners who demand an audit are going to want a reputable auditor or they're just going to put you through their own in-depth procurement due diligence regardless. The segment of the industry where a SOC 2 attestation is mandatory to participate but where any random auditor will do feels pretty narrow.
Unless you have a very good reason (I compare notes with people at dozens of firms and have never heard one), the only criteria you ever want to get SOC2'd on is Security.
My experience is the opposite of yours: having a security SOC2 ends the vendorsec process it any enterprise buyer, and enterprise buyers virtually never read anything in the SOC2 other than a glance at the exceptions. A very large, very security-intensive vendor we have all heard of told me a story about a vendor they had that gave them several years of repeated Type 1 reports. Went fine.
I wouldn't put it the way they did but they're directionally sane about this. I would worry a lot more about someone repping their SOC2 as important or meaningful than I would worry about someone who was cynical about SOC2.
(I don't mean Apple; Apple spends more on security than almost any firm in the world.)
My experience with pen tests that you put above or on par with SOC2 Type 2 security mirrors the discussion here. It all comes down to the reputation of the firm doing the testing.
I'll just cite my 30 years in IT/InfoSec. Believe it or not, I really don't give a damn. It's common knowledge int he field regardless of what your experience is.
1. No, it does not require 50k, an auditor can cost way less (10k? maybe even less).
2. But the process of preparing for the audit will take a lot of work securing your systems (and increasing reliability and privacy as well), as long as you take it seriously. Of course you can lie to the auditor, but it's up on you. And auditor -- they might lose their CPA license and go to prison. Their job is to catch your lies.
Source -- went through it, and took it seriously. It really did increase our security stance, even though we thought we were good at it.
That auditors are responsible for catching the lies of an audited company on penalty of being suspended is a position that the big audit firms would not agree with. They might agree that they are responsible for ensuring the material accuracy of accounts if fraud occurs, but even here EY has disclaimed responsibility if the fraud were sufficiently complex [0]. Indeed auditors lobbied very hard against being mandated with a broader anti-fraud role [1].
Admittedly this is on the "real" audit side and not the advisory/consulting side, which would be the ones to handle SOC I imagine, but nonetheless a position I find a bit absurd.
> Admittedly this is on the "real" audit side and not the advisory/consulting side, which would be the ones to handle SOC I imagine, but nonetheless a position I find a bit absurd.
I mean, it's not like the supposed "Chinese wall" at the Big 4 has ever been accused of being "illusory" on multiple occasions.
I co-ran a business with a significant SOC2 practice (we ran security programs for startups), and then oversaw Fly.io's SOC2 Type 2. The person you're responding to is more right than you are, and I would push back in a variety of ways on your point (2).
I'm scared of companies where SOC2 auditors are driving their security improvements. It's a bit like letting my toddler drive how I stock my pantry: surely by the end the pantry will be more full, but not really in the way I want.
It's not auditors, it's the compliance requirements and controls. You should not even reach to an auditor before fixing the controls (most of them, the ones you lack auditor must flag, as sometimes it's not feasible to fix most of the controls). I'd say going through an audit is easy, but preparing for the audit is hard.
PS: regarding "most of them" -- if you're one-person shop, you'll likely fail a control that requires your board of directors to be independent of company management (i.e. having directors that do not work for the company). That's OK, but will be reported on your SOC2 report.
> One caveat, if you use bluetooth to connect your phone to the car DCM will use your phone to connect to the mother ship and presumably send your data. I only use my iPhone cable to connect to the car which does not have this effect.
A random post on a forum is not evidence that Toyota has found a magic way to exfiltrate data over a bluetooth connection without turning on hotspot/etc.
It's not evidence against it either. Presumably CarPlay and Android Auto could implement a network interface through the application layer, or even activate Bluetooth tethering at the system level as they are privileged apps.
But they could also do this over USB, so something doesn't add up.
RNDIS was a mechanism for tethering over USB, and you could certainly pair "Bluetooth Network Adapters" for years and there's a profile for it. So there's at least precedent for it. That makes it pretty plausible to me.
There's still a fuse for the DCM even in this car but:
- It has an internal battery and will keep running for quite a while after pulling the fuse. This is a safety feature in case you get in a crash that disconnects the 12V battery
- It will break your in-car microphone as discussed. Repairing that requires opening up the dash
- That won't do anything for disconnecting the GPS antenna
Storage space is limited. There's a black box for accidents that keeps a rolling window of data. That's not the dcm. Outside of that, how much telemetry can you store? What's the retention when there's no cellular connection? And importantly, where is it stored?
My guess is that the dcm, having a battery back up and a cellular connection, is also the telemetry store. No evidence other than it's the cheapest and most reliable way to do it.
At least for Subaru, the dcm also connects to all antenna so removing it disconnects gps antenna. For other cars, I'd still expect removing the dcm to be good enough for 95% of people given the current expectation from car companies that no one would want to remove the dcm.
That's an interesting point but consider that bandwidth is also limited when we're talking about an always on system that's in every vehicle sold. And until recently storage was remarkably cheap.
If you log 32 bytes once per second that's only 962 MiB per year uncompressed. But 32 bytes is a lot (or depending on what you're logging not very much), once per second is almost certainly more frequent than necessary, and almost all vehicles spend the vast majority of their time turned off.
For example logging RPM every 100 ms, 8 bits gets you reasonable but not perfect accuracy and you're looking at 300 MiB per year of continuous operation. It's just not much of a storage requirement for quite detailed telemetry.
Good point, but in practice I think the only way onboard data could be exfiltrated is by a dealer while the car is being serviced. If you DIY or hire an independent mechanic, this seems unlikely.
They don't. They have all internet traffic dragnetted and satellite imaging and radar far beyond what is publicly disclosed. They don't need to check in with some low res crap that insurance companies use to nickel and dime you. If you're trying to escape surveillance and control from TLAs then you better start your moon base plans soon.
The kind of organized crime that those people should be focused on are also resistant to this kind of tracking. The cartels and gangs just use burner cars that they dump, possibly with the keys and title still in it. Good luck doing much with the log but you've got the log and even the entire car to try and gather all the evidence you want. This tracking is mainly for hemming up small fry and productive citizens.
That also means it isn't passed to your phone via android auto / carplay. Phone GPS is much worse than car GPS for road navigation. It's basically unusable.
My Ford ~(2018 era SYNC system) has GPS and Bluetooth but no cellular modem.
It still technically is used for telemetry... but only when you get into a wreck. It'll ping the onboard GPS at that time for coordinates, then place a voice call over your paired cellphone to 911 with TTS coordinates and information about the wreck.
"Attention. A side crash with rollover has occured in a Ford vehicle. Multiple impacts detected. The maximum speed change was 38 miles per hour. Airbags deployed. Detected ONE seatbelt fastened. Press 1 at any time for location information, or press 0 at any time to speak with vehicle occupants."
In a perfect world they wouldn't collect it either, but I'd rather Apple have it than the car manufacturer (or rather, only Apple vs both Apple and the car manufacturer)
Also even with no modem, if you use CarPlay on your phone _via Bluetooth_ then the car will just use your phone's internet connection, so I only use CarPlay via a wired USB connection.
Aside from that the car works great, everything is 100% functional. I suppose I don't get OTA updates, which I'm fine with.
Wow, that is evil that they steal your data to send telemetry back via carplay. I always assumed that was possible so I have never actually hooked my phone up to a car but it really saddens me that it actually happens. There is 0 requirement for my phone to pass along raw internet access to the car in my opinion.
I have a Skoda and the GPS module was broken and that messed up a lot of the systems in the car, I couldn't use the adaptive cruise control, no traffic signs recognition and no SOS module. And apparently CarPlay sometimes uses the car's GPS module, so navigation was also a pain. I'd have to start the navigation from outside the car, otherwise it wouldn't use the phone's GPS.
I don't need something to protect the privacy of others from me, I need something to protect my privacy from others. The majority of people who use smart glasses are not going to be using this - where is the product that will protect me from them?
> Make an RSA key of 4096 bits. Call it your personal key.
This is bad advice - making a 4096 bit key slows down visitors of your website and only gives you 2048 bits of security (if someone can break a 2048 bit RSA key they'll break the LetsEncrypt intermediate cert and can MITM your site). You should use a 2048 bit leaf certificate here
Amateur question: does a 4096 not give you more security against passive capture and future decrypting? Or is the intermediate also a factor in such an async attack?
I thought FS only protected other sessions from leak of your current session key. How does it protect against passive recording of the session and later attacking of the recorded session in the future?
If using a non-FS key exchange (like RSA) then the value that the session key is derived from (the pre-master secret) is sent over the wire encrypted using the server's public key. If that session is recorded and in the future the server's private key is obtained, it can be used to decrypt the pre-master secret, derive the session key, and decrypt the entire session.
If on the other hand you use a FS key exchange (like ECDHE), and the session is recorded, and the server's private key is obtained, the session key cannot be recovered (that's a property of ECDHE or any forward-secure key exchange), and none of the traffic is decryptable.
The certificate is for authentication of the server. It has nothing to do with the encryption of the data.
Basically forward secrecy is where both the sender and receiver throw away the key after the data is decrypted. That way the key is not available for an attacker to get access to later. If the attacker can find some way other than access to the key to decrypt the data then forward secrecy has no benefit.
Unless details were intentionally changed that narrows it down to two companies that are not US based, despite being traded on Nasdaq. The other two are a ETF and SPAC
Worth noting, because many people seem to assume these folks are based in SV
Also Apple certainly does invest heavily in security and privacy but SOC2's are so commoditized that it's like saying "look I can afford 50k", it's not particularly interesting