| ▲ | tptacek 5 hours ago |
| As is the case with SOC2, the "vulnerability scan" requirement here is likely to be meaningless; any automated process that can plausibly be described as instrumental in finding some kind of vulnerability is a "vulnerability scan", so all you have to do is run nmap. |
|
| ▲ | john_strinlai 5 hours ago | parent | next [-] |
| they have comment/request for information sessions for HIPAA rule proposals, which your input would be valued. |
| |
| ▲ | tptacek 3 hours ago | parent [-] | | I don't think the rule would be better with more detailed vulnerability scanning requirements! All these things inexorably become races to the bottom. | | |
| ▲ | sonofhans 2 hours ago | parent [-] | | Yes, exactly, the rules are intentionally broad and vague. You can wave paper at most of them and technically succeed. And then when you release accidentally PHI for the first time and your bullshit comes to light, your chickens will come home to roost. Doing a good job on compliance is less about security and more about staying out of jail. | | |
| ▲ | akerl_ 11 minutes ago | parent [-] | | The ideal flow here is: 1. Do good security and operations. 2. Overlap the minimum subset of your existing good security and operations as evidence for whatever compliance regimes help you get paid. 3. Get paid. Nobody is suggesting that you bullshit the auditors. They’re suggesting not letting the auditors accidentally trick you into letting step 2 get in front of step 1. |
|
|
|
|
| ▲ | dgellow 5 hours ago | parent | prev | next [-] |
| If it is like SOC2 I would expect respected auditors to reject that |
| |
| ▲ | morpheuskafka 5 hours ago | parent | next [-] | | But there are no auditors required for HIPAA. Only the government (HHS OCR) itself can enforce the standards. | | |
| ▲ | dgellow 5 hours ago | parent [-] | | Thanks for the clarification, in that case the text is indeed really weak. Does that system work in practice, or are companies just claiming they are HIPAA compliant with close to no actual auditing mechanism? | | |
| ▲ | giaour 17 minutes ago | parent | next [-] | | It's been a few years since I worked in this space, but HIPAA doesn't really work under the same kind of legal framework. Oversimplifying here, but basically HIPAA defines what constitutes personal health information, how such information may be used, and establishes monetary penalties for improper use and unauthorized disclosure. The law doesn't have any certification standard, no more than the prohibition on stealing cars does. Maybe there's some kind of third party certification system to support signing information sharing agreements ("BAAs") with other health information systems. I worked at CMS on first-party stuff so I'm not really familiar with how it works in the private sector. | |
| ▲ | tptacek 5 hours ago | parent | prev [-] | | You get that the technical controls in SOC2 are also extremely weak, right? | | |
| ▲ | dgellow 4 hours ago | parent [-] | | Sure, yes. The way I understand SOC2 relies on the auditors to set the effective standard. So it really depends who audited you | | |
| ▲ | tptacek 4 hours ago | parent [-] | | SOC2 auditors are accountants. A SOC2 auditor verifies only that you're doing what you say what you're doing. | | |
| ▲ | kevin_nisbet 3 hours ago | parent | next [-] | | And the way they verify you are doing what you say you are doing is by asking you to provide evidence, which is usually pretty easy to demonstrate that a policy was followed once or twice, a lot harder for them to pick up consistency issues or exceptions. | |
| ▲ | dgellow 4 hours ago | parent | prev [-] | | Obviously, yes | | |
| ▲ | akerl_ 4 hours ago | parent [-] | | A SOC auditor who tells you that you can’t use an nmap scan to meet SOC2 obligations is a bad SOC auditor, because they’re attempting to enforce a constraint on you that SOC2 does not. But the far more likely thing is that a medium SOC auditor, upon being told “we do our vulnerability scanning with nmap”, would say “I haven’t heard of nmap. You should use Tenable,” and if you’re letting SOC auditor drive your engineering you’d make a mistake and accidentally think that meant you needed to change your answer for SOC2 and go buy Tenable licenses. | | |
| ▲ | dgellow 4 hours ago | parent [-] | | The whole thread drifted way too far from a very mild push back I had regarding the claim « any automated process that can plausibly be described as instrumental in finding some kind of vulnerability is a "vulnerability scan" ». My experience is that no, SOC2 auditors won’t consider literally any automated process of that sort as compliant. Which in no way implies the auditors are forcing you to use a licensed tool or driving your engineering. I will stop that thread here, I don’t think that exchange is productive |
|
|
|
|
|
|
| |
| ▲ | tptacek 5 hours ago | parent | prev [-] | | No? Like, wildly no? This is a big part of why you pay for the most respected auditors. | | |
| ▲ | dgellow 5 hours ago | parent [-] | | I guess we had different experiences. The ones I interacted with were ok and wouldn’t have accepted a simple nmap here | | |
| ▲ | tptacek 5 hours ago | parent [-] | | I'm not being snarky when I say that not getting your automated vulnerability scan, whatever it might have been, past your SOC2 auditors is a skills issue. SOC2 audits are not technical and the vulnerability scan control in SOC2 is categorically not meaningful. Cloudflare wrote a whole post about this. | | |
| ▲ | dgellow 4 hours ago | parent [-] | | FWIW I agree that SOC2 for automated vulnerability scans has a really low bar and isn’t too meaningful. At no point did I defend SOC2 here. The bar I’ve seen is above “just an nmap”, which is pretty bad standard IMHO. You seem to be reading way too much in my comments | | |
| ▲ | 4 hours ago | parent | next [-] | | [deleted] | |
| ▲ | tptacek 4 hours ago | parent | prev [-] | | I brought up nmap. You said you'd expect respected SOC2 auditors to reject it. I don't just think that's not true, I know it not to be true. | | |
| ▲ | dgellow 4 hours ago | parent [-] | | I know, that’s already established. I already acknowledged we had different experiences. I have no idea what you’re pushing for at that point | | |
| ▲ | tptacek 3 hours ago | parent | next [-] | | Just to clarify, this is a bugbear of mine. It's nothing personal with you, but I've spent the last 6 years or so evangelizing the idea that people should minimize their SOC2s and not get pushed around by auditors or evidence collection platforms like Vanta, because that drives a lot of terrible security engineering, and the hypercompetent best-staffed security orgs in the industry all push their SOC2 auditors around. Compliance and security are entirely different practices in a well-run firm. Security can inform compliance. Compliance should not inform security engineering. If you search my name and "SOC2" in the search bar below, I've expanded on this quite a bit. | | |
| ▲ | rmccue 2 hours ago | parent [-] | | As just one data point here, let me say thank you for all your writing on it; it was super useful to have things to point at to say “we don’t have to just blindly do a thing the auditor suggested!” for our SOC2. |
| |
| ▲ | john_strinlai 3 hours ago | parent | prev [-] | | tptacek just hates soc. its probably not personal. | | |
| ▲ | tptacek 3 hours ago | parent [-] | | We got some value from it! I just think it's important to remember what it actually is, rather than axiomatically deriving what you think it should be. |
|
|
|
|
|
|
|
|
|
| ▲ | jasonlotito 3 hours ago | parent | prev [-] |
| > so all you have to do is run nmap. This is ignorance at best. No one who has ever actually had to do SOC2 compliance legitimately has just run nmap and been done with that. |
| |
