It's worth noting that cybersecurity requirements can be a mechanism of control.
As a government regime, do you want to build an effective surveillance system where health data on large numbers of suspects can be pulled into a data fusion system at the push of a button, once a judicial framework for rubber-stamping is in place? And do you want to be able to pressure vendors into not supporting certain types of research/analysis and even direct patient care that could be construed/presented as counter to the regime's goals?
Both of these are easier when smaller vendors are forced out and larger vendors are the only ones left standing. As such, regulatory capture becomes a mutually beneficial tool to dominant vendors and regulators alike.
There are few coincidences when lobbying is involved. Which is not to say that cybersecurity improvements aren't a good thing! But speed and mechanisms of required rollout need to be balanced. And with the numerous signatories of [0] opposing the rule and describing "unreasonable implementation timelines," it's hard to say that this is entirely done in the interest of patients.
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.
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?
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.
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.
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
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.
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
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.
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.
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.
I've got this saved and I'll watch it and reply soon, but my kneejerk reaction is "this is someone who probably doesn't actually understand what they're talking about" simply because as someone who is in healthcare IT, I can assure you privacy is taken extremely seriously and I can guarantee medical privacy today is far better than it ever was before.
I don't understand why there shouldn't be a strict-liability play here on top of penalties for knowing violations.
You lose all your customer's data to a darknet leak? We should be taking a huge chunk out of your balance sheet.
My insurer has disclosed names, social security numbers, and ENTIRE MEDICAL CASEFILES for their entire client base more than once at this point in overlapping data breaches. Why exactly don't they owe me $10k for my trouble, or N% shares of the company? If that's too much, why do these penalties exist for knowing disclosure, if incompetence is so tolerated that knowing disclosure does no damage?
Penalties are $100-$50,000 per violation (i.e. per leak for each person), up to $1.5 million per year[0]. If in the US (I'm assuming given you mention your health insurance) you can report it to your state insurance commissioner which may have already occurred for your incidents.
There's also possible prison sentences. I just love it when someone wants to "get tough on X" when all the laws are already tough on X and just unenforced. That's how you end up with every American committing three felonies a day without knowing it.
It's from a topic in a book [1] that is sometimes also discussed on forums. The gist of it is something to the effect of, there are so many laws and so much wiggle room in most of the laws that each person is committing multiple felonies per day without knowing it thus empowering agencies to arrest just about anyone at any given time. The United States of America has the highest incarceration rate of the world is just one small example of that.
At some point we really should consider a similar system to points on a drivers license for repeat offenders like that. Once, maybe twice come with some serious fines and compensation to victims. 3 times or more? Why are they allowed to continue to be in that business? We can't let repeat offenders be allowed to continue to handle sensitive data.
PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks. The notion that your system might become "in-scope" is one of the scariest things you have to deal with. Avoiding this designation is almost always easier than satisfying all the controls they prescribe. Stripe & friends have it really good. I don't know who their equivalents are in the health care industry but I am certain they exist.
I despise PCI-DSS. A friend owns a small business and has a credit card reader. Due to that, we had to build out a separate LAN so that the reader is on its own precious network, and have to pay an external auditor for a quarterly scan of our external IP. Bullshit past findings were things like âyour VPN server supports old encryption algorithmsâ. âBut our clients donât support them. They select the newer algorithms!â âBut they could!â âWhat do you care? Those clients arenât even on the same LAN as the scanner.â âPCI-DSS lol!â I have no way of knowing, but I bet the firewall mightâve accidentally blocked the scanning IP from reaching the VPN server port on the retest and called it a day, but surely not.
Basically, Visa and friends externalized their own shitty security and made every other company in the land responsible for wrapping their janky hardware in electronic bubble wrap. A real security framework wouldâve said âdonât make a credit card scanner so weak that it canât survive being on the same LAN as a printerâ. Instead, the whole country has to waste billions of dollars mitigating that risk for them.
> Bullshit past findings were things like âyour VPN server supports old encryption algorithmsâ. âBut our clients donât support them. They select the newer algorithms!â
Given that downgrade attacks are a massive category of attacks for network protocols, and in fact modern protocols go to great lengths to make them impossible, that doesnât sound very bullshit at all.
If a client doesnât support an algorithm, you canât force a downgrade to it. A compensating control is that the clients are managed and only support the newest algorithms, and arenât vulnerable to a downgrade attack.
Context is everything. Here, the context is that within this scan environment, it was, in fact, a bullshit finding.
Of course they have to double down on yet another compliance regime. Why not converge on an existng NIST 800-53 baseline, or some HHS "tailored" variant? Or CMMC, if they want to push for more strict certification processes instead?
It's getting absurd with how many different compliance regimes a modern research university will have to follow simultaneously, if they do a broad set of defense, energy, basic sciences, and health research as well as having an attached medical school and teaching hospital.
It's so grating to read obviously LLM-generated text, even more so from a company that is asking us to hire them for a security audit.
AI writing makes somewhat more sense on tech blogs. Where a business' value proposition is "We are knowledgeable and reliable about computer security", it seems unwise.
I was thinking the same - makes the article feel very amateur and unprofessional. And I know for a fact that AI can do a better job at writing than this, I doubt they read it and had any sense of how poor the writing actually is.
It really depends on who is testing and enforcing these standards. I have worked in this area, built scalable systems for medicare. The annual pen testing used to be a joke. Any consultant who would come had no clue what was being built, how the process worked - and they wouldn't even care to understand. After a meeting, we'd get the notification that the pen testing was successful. So, on paper you can change any rule - if the consultants you are hiring don't give a shit (which they usually don't)- nothing gets enforced. We would go out of our 'job responsibilities' to do internal testing of all sorts (the external agency would not even do 2% of that).
How kind of them to require 2FA without requiring the governments to issue real 2FA tokens for use in signing / interacting. No doubt this will require some rootkit 'authenticator' app on the consumer's purchased mobile device that they are then not allowed to truly own.
Interesting. I havenât fully read through the rule change, but seems like HHS is directly adopting the controls required by HITRUST? I have been out of the industry for a while. Always interesting how the industry shapes regulation and vice versa.
you can be certain the DOGE kids downloaded as much as they could grab from federal systems about everyone's medical history including the federal e-prescription system
It's worth noting that cybersecurity requirements can be a mechanism of control.
As a government regime, do you want to build an effective surveillance system where health data on large numbers of suspects can be pulled into a data fusion system at the push of a button, once a judicial framework for rubber-stamping is in place? And do you want to be able to pressure vendors into not supporting certain types of research/analysis and even direct patient care that could be construed/presented as counter to the regime's goals?
Both of these are easier when smaller vendors are forced out and larger vendors are the only ones left standing. As such, regulatory capture becomes a mutually beneficial tool to dominant vendors and regulators alike.
There are few coincidences when lobbying is involved. Which is not to say that cybersecurity improvements aren't a good thing! But speed and mechanisms of required rollout need to be balanced. And with the numerous signatories of [0] opposing the rule and describing "unreasonable implementation timelines," it's hard to say that this is entirely done in the interest of patients.
[0] https://assets.ctfassets.net/opszt4tga0mx/4QrJlGP2EkCiZjgvGx... (2025)
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.
they have comment/request for information sessions for HIPAA rule proposals, which your input would be valued.
I don't think the rule would be better with more detailed vulnerability scanning requirements! All these things inexorably become races to the bottom.
If it is like SOC2 I would expect respected auditors to reject that
But there are no auditors required for HIPAA. Only the government (HHS OCR) itself can enforce the standards.
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?
You get that the technical controls in SOC2 are also extremely weak, right?
Sure, yes. The way I understand SOC2 relies on the auditors to set the effective standard. So it really depends who audited you
SOC2 auditors are accountants. A SOC2 auditor verifies only that you're doing what you say what you're doing.
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.
Obviously, yes
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.
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
No? Like, wildly no? This is a big part of why you pay for the most respected auditors.
I guess we had different experiences. The ones I interacted with were ok and wouldnât have accepted a simple nmap here
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.
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
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.
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
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.
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.
tptacek just hates soc. its probably not personal.
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.
> 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.
https://blog.cloudflare.com/introducing-flan-scan/
>No one who has ever actually had to do SOC2 compliance
while i find tptacek's opinions very strong on the subject, you would be extremely mistaken to think those opinions were formed without experience
As explained here[1], HIPPA makes our medical privacy worse, not better.
[1] https://www.youtube.com/watch?v=4sfIBRTcRpU
https://odysee.com/@NaomiBrockwell:4/HIPAA:7
I've got this saved and I'll watch it and reply soon, but my kneejerk reaction is "this is someone who probably doesn't actually understand what they're talking about" simply because as someone who is in healthcare IT, I can assure you privacy is taken extremely seriously and I can guarantee medical privacy today is far better than it ever was before.
Here's the full proposed rule: https://www.federalregister.gov/documents/2025/01/06/2024-30...
I don't understand why there shouldn't be a strict-liability play here on top of penalties for knowing violations.
You lose all your customer's data to a darknet leak? We should be taking a huge chunk out of your balance sheet.
My insurer has disclosed names, social security numbers, and ENTIRE MEDICAL CASEFILES for their entire client base more than once at this point in overlapping data breaches. Why exactly don't they owe me $10k for my trouble, or N% shares of the company? If that's too much, why do these penalties exist for knowing disclosure, if incompetence is so tolerated that knowing disclosure does no damage?
Penalties are $100-$50,000 per violation (i.e. per leak for each person), up to $1.5 million per year[0]. If in the US (I'm assuming given you mention your health insurance) you can report it to your state insurance commissioner which may have already occurred for your incidents.
[0] https://www.ama-assn.org/practice-management/hipaa/hipaa-vio...
There's also possible prison sentences. I just love it when someone wants to "get tough on X" when all the laws are already tough on X and just unenforced. That's how you end up with every American committing three felonies a day without knowing it.
I'll bite: examples?
It's from a topic in a book [1] that is sometimes also discussed on forums. The gist of it is something to the effect of, there are so many laws and so much wiggle room in most of the laws that each person is committing multiple felonies per day without knowing it thus empowering agencies to arrest just about anyone at any given time. The United States of America has the highest incarceration rate of the world is just one small example of that.
[1] - https://www.amazon.com/Three-Felonies-Day-Target-Innocent/dp...
I was aware of the de facto state but not the book, thank you for sharing that.
Still, I was hoping for examples.
At some point we really should consider a similar system to points on a drivers license for repeat offenders like that. Once, maybe twice come with some serious fines and compensation to victims. 3 times or more? Why are they allowed to continue to be in that business? We can't let repeat offenders be allowed to continue to handle sensitive data.
The institutional moats grow ever wider.
PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks. The notion that your system might become "in-scope" is one of the scariest things you have to deal with. Avoiding this designation is almost always easier than satisfying all the controls they prescribe. Stripe & friends have it really good. I don't know who their equivalents are in the health care industry but I am certain they exist.
I despise PCI-DSS. A friend owns a small business and has a credit card reader. Due to that, we had to build out a separate LAN so that the reader is on its own precious network, and have to pay an external auditor for a quarterly scan of our external IP. Bullshit past findings were things like âyour VPN server supports old encryption algorithmsâ. âBut our clients donât support them. They select the newer algorithms!â âBut they could!â âWhat do you care? Those clients arenât even on the same LAN as the scanner.â âPCI-DSS lol!â I have no way of knowing, but I bet the firewall mightâve accidentally blocked the scanning IP from reaching the VPN server port on the retest and called it a day, but surely not.
Basically, Visa and friends externalized their own shitty security and made every other company in the land responsible for wrapping their janky hardware in electronic bubble wrap. A real security framework wouldâve said âdonât make a credit card scanner so weak that it canât survive being on the same LAN as a printerâ. Instead, the whole country has to waste billions of dollars mitigating that risk for them.
> Bullshit past findings were things like âyour VPN server supports old encryption algorithmsâ. âBut our clients donât support them. They select the newer algorithms!â
Given that downgrade attacks are a massive category of attacks for network protocols, and in fact modern protocols go to great lengths to make them impossible, that doesnât sound very bullshit at all.
If a client doesnât support an algorithm, you canât force a downgrade to it. A compensating control is that the clients are managed and only support the newest algorithms, and arenât vulnerable to a downgrade attack.
Context is everything. Here, the context is that within this scan environment, it was, in fact, a bullshit finding.
Of course they have to double down on yet another compliance regime. Why not converge on an existng NIST 800-53 baseline, or some HHS "tailored" variant? Or CMMC, if they want to push for more strict certification processes instead?
It's getting absurd with how many different compliance regimes a modern research university will have to follow simultaneously, if they do a broad set of defense, energy, basic sciences, and health research as well as having an attached medical school and teaching hospital.
It's so grating to read obviously LLM-generated text, even more so from a company that is asking us to hire them for a security audit.
AI writing makes somewhat more sense on tech blogs. Where a business' value proposition is "We are knowledgeable and reliable about computer security", it seems unwise.
I was thinking the same - makes the article feel very amateur and unprofessional. And I know for a fact that AI can do a better job at writing than this, I doubt they read it and had any sense of how poor the writing actually is.
It really depends on who is testing and enforcing these standards. I have worked in this area, built scalable systems for medicare. The annual pen testing used to be a joke. Any consultant who would come had no clue what was being built, how the process worked - and they wouldn't even care to understand. After a meeting, we'd get the notification that the pen testing was successful. So, on paper you can change any rule - if the consultants you are hiring don't give a shit (which they usually don't)- nothing gets enforced. We would go out of our 'job responsibilities' to do internal testing of all sorts (the external agency would not even do 2% of that).
Wait a second. If encryption is required for all ephi, that means faxes will finally die, right? Right??? Please!
Nah, in legal compliance minds, faxes are magical, remote, wet ink.
My thought too. This would be huge if true.
Mandatory annual security assessments are going to be brutal for small businesses.
How kind of them to require 2FA without requiring the governments to issue real 2FA tokens for use in signing / interacting. No doubt this will require some rootkit 'authenticator' app on the consumer's purchased mobile device that they are then not allowed to truly own.
TOTP should be totally fine and can be used with very dumb hardware/software.
Interesting. I havenât fully read through the rule change, but seems like HHS is directly adopting the controls required by HITRUST? I have been out of the industry for a while. Always interesting how the industry shapes regulation and vice versa.
I'm not sure how meaningful it is to adopt some of the controls from HITRUST without any of the consequences.
Is this why every healthcare website has 2FA now? It's so annoying.
you can be certain the DOGE kids downloaded as much as they could grab from federal systems about everyone's medical history including the federal e-prescription system
rules for thee but not for me
eh how are they going to make the usual small practice do "penetration testing"?