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?
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
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.
I've had SOC2 auditors choose a random commit from our GitHub history, then ask to see the associated Jira ticket, logs from the build and deployment, etc. Hard to reliably pass an audit if you don't know which changes they'll drill down into.
They also asked for proof of system-enforced processes (e.g. GitHub branch protection rules and the setting for enforcing peer review for each change) which were basically proof of consistency.
They do that because in the DRL process you specified a change management process involving Github and Jira. If you specified a different process (for instance, Post-It notes applied to the bathroom wall), they would randomly ask for evidence about those Post-It notes.
That's what we're talking about when we say virtually any tool you can come up with will satisfy "vulnerability scans". For Cloudflare, it was nmap. I think they're right about this.
It absolutely doesn't rely on competent auditors. The AICPA that fabricated SOC2, is the same AICPA that gives licenses to the auditors. At some point, they opened it up to getting it over the internet.
Indian companies open up shell businesses in Wyoming and elsewhere, get "certified", and offer rubber stamp auditing services. Few ever check if you actually have SOC2, or what auditor you used (since, by definition, they need to be "legit").
By the way, the AICPA website was recently throwing https expired cert errors. Their solution after weeks of me pointing it out on twitter, was to take down the entire website.
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.
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.
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.
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.
I have direct experience telling a soc2 auditor that the approval control for installing applications on “endpoints” was a message to a slack channel that was assumed approved.
To satisfy the audit they looked at an app that was installed on a laptop that was not part of our base image from the previous 6 months and a screenshot of the message where the user “asked” to install it.
You can literally get a soc auditor to write up whatever you want as a control and if they don’t explain that and encourage it you should find a new auditor.
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.
Medical records are the most valuable records to steal. They contain financial info like SSN for card fraud, but also demographic info that makes it crazy valuable.
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.
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.
Your comment is essentially borderline conspiracy theory that HIPAA is somehow setting up a surveillance state.
> 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?
Sure, and I'm right there with you that people should protest frameworks for judicial rubber-stamping. But HIPAA is like the only privacy law in America, basically, and having it mandate that medical data is encrypted can be good on its own.
While there are standardized formats for medical data, many are so ill-adopted that building some sort of surveillance system would be a monumental task; the bulk of data I've worked with has been in poorly documented, non-standard formats.
> Both of these are easier when smaller vendors are forced out and larger vendors are the only ones left standing
Clearer regulations and standardized, interoperable data formats benefit smaller players.
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.
The whole VPN requirement sounds like bullshit to me. The terminal should use secure TLS connections to the servers it communicates with, without relying on the security of the (local) network at all.
Last I checked, a VPN isn’t required by PCI (or really any other compliance regime). The parent commenter’s infrastructure had a VPN. And once you have a VPN and you’re showing it to the auditors as part of your in-scope infra for PCI, asking you to remediate findings for insecure algorithms allowed in the server config is rational.
Eh, not really. The VPN was on the same router that gave the card scanner access to phone home to the credit card company. They weren’t related at all. You couldn’t connect to the scanner’s LAN through the VPN. But since they had the same public IP, the vuln scanner counted them as in scope.
But in reality, why’s that a problem? Is the credit card scanner so tacitly busted that it can’t coexist with other hosts? Does it not use TLS? Doesn’t it pin TLS certs so that it’s not subject to MITM? Is it listening on ports with vulnerable services? There’s no excuse for the scanner being that delicate. It should be able to service an office LAN. And yet, the PCI-DSS group managed to push the responsibility for their hardware onto the network owners rather than making their own hardware robust. That’s nuts.
> PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks.
My personally most hated compliance ruleset. I've been in Healthcare for over a decade, I'm a HIPAA/data security expert, and PCI compliance is genuinely harder and more nonsensical than HIPAA.
And to be honest, for every ONE healthcare place I've seen that would fail a HIPAA audit, I've seen 20 companies that would fail PCI compliance and by a wider margin. The number one PCI issue I've seen *literally* everywhere is recording/writing down card numbers with CVV. It's strictly forbidden by the rules, and every snall and medium business breaks that rule constantly.
What kind of business writes down credit card numbers (even without CVV)?
Online payments (e.g. e-commerce) usually send such data directly to the PSP, or encrypt it with a PSP controlled key.
And in person payments (e.g. stores and restaurants) use a payment terminal/device, which is presumably PCI DSS compliant and doesn't store such information.
I've implemented PCI-DSS and have 12 years of level 1 audits behind me. I actually find their rules to be sane, pretty good security practice. Internally, we made many of the controls standard across the board even for out-of-scope systems because they were sensible and we'd already built the tooling for it. If you implement it well, once you're compliant it is easy to stay compliant.
And yes, there is plenty of incentive to keep things out of PCI scope. I'd say that is PCI working as intended. Why would you want a larger attack surface that touches your credit card data?
We recently did PCI-DSS level2 and it was pain in the right place to complete the scans and gaps their scripts find. It took 6 months to complete the audit.
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).
I think the conduit exception still applies for analog faxes. Which makes no sense, since tapping a fax line is probably way easier than compromising a data center.
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.
Oh you meant like case law examples. It's a bit of reading but search for examples of case law where a person was convicted on technicalities but not violating the spirit of the law, sometimes later being over-turned. I don't have any examples and I hate to suggest this but maybe start with whatever LLM you use.
I avoid LLMs but wasn't concerned with case law as much as a specific law on the books, whether used or not. A peer comment offered mishandling of mail not addressed to you.
Discarding misdirected mail is a felony (18 U.S. Code § 1702). For example, you receive a flyer in the mail addressed to John Smith who previously lived at your address. If it doesn't say "John Smith OR current resident" then discarding that junk mail is a felony. You are supposed to write "Return to sender" on every piece of junk mail or correspondence not addressed to you and put it in the outgoing mail. People discard junk flyers every single day without looking at the address first. Simple things like that.
To tie back into the original discussion on HIPAA, I had a collection agency sending mail addressed to a previous resident to my address once. The return address was the clinic of the patient. I was dutifully writing RTS on every letter and putting it back in the mail, but they would not take me off their nastygram list. That was until I wrote "You know, it's a felony HIPAA violation to be leaking this patient's name and clinic to me after you've been notified of the incorrect address." The collection letters immediately stopped after I did 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.
I'll bite. Why is it the fault of the organization that gets broken into, rather than the fault of the attackers breaking into it? Even if the defender takes every reasonable defensive measure, they could still get pwned from some zero day that they had no defense against. Should they be fined into oblivion for something like that?
The question is whether the defender takes reasonable defensive measures or not.
The problem is that without having some kind of enforcement, businesses will decide that it is cheaper to not worry at all about security and thus their customers will have their data leaked/shared etc.
There's a world of difference between a company that puts effort into security and one that doesn't.
What is my incentive, as a shareholder in a medical company, to demand functional, bulletproof security, and to hold on to no more data than I need, and to encrypt everything? I'm never going to suffer as a result of breaches. Nor are any of my staff. so long as evidence doesn't show that they did it deliberately.
A cryptocurrency business or a diamond business, by contrast, has very strict security protocols, because if they don't, all the value gets wiped out very quickly. The rules basically absolve the healthcare company of fiscal responsibility.
This update OP is posting about may require jumping through certain hoops, but it does not require functionality of those measures.
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
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.
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.
Oh, I have typed that acronym thousands of times. Thousands. And I’d be surprised if I got it right 90% of the time. I have just enough dyslexia, I think, to make it very hard to be perfect. So perhaps OP is similar.
"As explained by" someone regurgitating the views of the "Citizens’ Council for Health Freedom", an anti-vax, right-wing organization that opposes HIPAA, Medicare, and government involvement in healthcare in general.
Universal encryption of PHI at rest is going to be INCREDIBLY painful. Hospitals mostly have onprem, locked down mainframe IRIS systems that host data. If the IRIS data is encrypted at rest then it can’t be compressed which means hospitals will have to buy a bunch more hardware which is super expensive, especially these days.
This doesn’t get you much in terms of security. The IRIS system itself is an OLTP so it’s going to need to constantly pass around the encryption key and use it constantly, and if an attacker gets disk access they also will have access to the keys.
So this is a big waste of everyone’s time and money.
I'm not sure why there's so much negativity in this thread. The listed requirements were already basic table-stakes security standards. IMO, anyone not encrypting all user data at rest, requiring MFA, etc. is bush league.
highly irritating. HIPAA was originally designed to be a "portability" standard (meaning easier to share). It has done the opposite. Health data is important to developing a cure, and privacy is unimportant to many people. The world would be better if there we were zero regulation here at all.
This was a pleasant surprise; I fully expected a gutting of the rules, based on what’s been on the front page these past few months. I’m glad to see that someone in the federal govt is paying attention to the risk landscape.
tptacek | a day ago
dgellow | a day ago
morpheuskafka | a day ago
dgellow | a day ago
tptacek | a day ago
dgellow | a day ago
tptacek | a day ago
dgellow | a day ago
akerl_ | a day ago
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 | a day ago
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
kevin_nisbet | a day ago
randerson | 22 hours ago
They also asked for proof of system-enforced processes (e.g. GitHub branch protection rules and the setting for enforcing peer review for each change) which were basically proof of consistency.
tptacek | 21 hours ago
That's what we're talking about when we say virtually any tool you can come up with will satisfy "vulnerability scans". For Cloudflare, it was nmap. I think they're right about this.
akerl_ | 19 hours ago
1. You write a DRL that says “we do a disaster recovery test annually to ensure that we can restore a production backup”.
2. It takes you 20 tries in 2026 to do a successful restore because your find out the first 19 times that your backup is broken and incomplete.
3. You never have to mention the first 19 tries to the auditors when you prove you did do a successful DR restore.
_hyn3 | 22 hours ago
latchkey | 14 hours ago
Indian companies open up shell businesses in Wyoming and elsewhere, get "certified", and offer rubber stamp auditing services. Few ever check if you actually have SOC2, or what auditor you used (since, by definition, they need to be "legit").
By the way, the AICPA website was recently throwing https expired cert errors. Their solution after weeks of me pointing it out on twitter, was to take down the entire website.
giaour | 23 hours ago
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 | a day ago
dgellow | a day ago
tptacek | a day ago
dgellow | a day ago
tptacek | a day ago
dgellow | a day ago
tptacek | a day ago
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 | a day ago
john_strinlai | a day ago
tptacek | a day ago
john_strinlai | a day ago
tptacek | a day ago
sonofhans | a day ago
akerl_ | 22 hours ago
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.
jasonlotito | a day ago
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.
john_strinlai | a day ago
while i find tptacek's opinions very strong on the subject, you would be extremely mistaken to think those opinions were formed without experience
tptacek | a day ago
kasey_junk | 19 hours ago
To satisfy the audit they looked at an app that was installed on a laptop that was not part of our base image from the previous 6 months and a screenshot of the message where the user “asked” to install it.
You can literally get a soc auditor to write up whatever you want as a control and if they don’t explain that and encourage it you should find a new auditor.
time0ut | a day ago
jpitz | a day ago
201984 | a day ago
burnte | a day ago
iloveoof | 23 hours ago
mjevans | a day ago
pphysch | a day ago
btown | a day ago
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)
deathanatos | 11 hours ago
> 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?
Sure, and I'm right there with you that people should protest frameworks for judicial rubber-stamping. But HIPAA is like the only privacy law in America, basically, and having it mandate that medical data is encrypted can be good on its own.
While there are standardized formats for medical data, many are so ill-adopted that building some sort of surveillance system would be a monumental task; the bulk of data I've worked with has been in poorly documented, non-standard formats.
> Both of these are easier when smaller vendors are forced out and larger vendors are the only ones left standing
Clearer regulations and standardized, interoperable data formats benefit smaller players.
bob1029 | a day ago
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.
kstrauser | a day ago
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.
akerl_ | a day ago
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.
kstrauser | a day ago
Context is everything. Here, the context is that within this scan environment, it was, in fact, a bullshit finding.
CodesInChaos | 21 hours ago
akerl_ | 21 hours ago
kstrauser | 20 hours ago
But in reality, why’s that a problem? Is the credit card scanner so tacitly busted that it can’t coexist with other hosts? Does it not use TLS? Doesn’t it pin TLS certs so that it’s not subject to MITM? Is it listening on ports with vulnerable services? There’s no excuse for the scanner being that delicate. It should be able to service an office LAN. And yet, the PCI-DSS group managed to push the responsibility for their hardware onto the network owners rather than making their own hardware robust. That’s nuts.
kstrauser | 20 hours ago
unethical_ban | 23 hours ago
bob1029 | 23 hours ago
burnte | a day ago
My personally most hated compliance ruleset. I've been in Healthcare for over a decade, I'm a HIPAA/data security expert, and PCI compliance is genuinely harder and more nonsensical than HIPAA.
And to be honest, for every ONE healthcare place I've seen that would fail a HIPAA audit, I've seen 20 companies that would fail PCI compliance and by a wider margin. The number one PCI issue I've seen *literally* everywhere is recording/writing down card numbers with CVV. It's strictly forbidden by the rules, and every snall and medium business breaks that rule constantly.
CodesInChaos | 21 hours ago
Online payments (e.g. e-commerce) usually send such data directly to the PSP, or encrypt it with a PSP controlled key.
And in person payments (e.g. stores and restaurants) use a payment terminal/device, which is presumably PCI DSS compliant and doesn't store such information.
randerson | 22 hours ago
And yes, there is plenty of incentive to keep things out of PCI scope. I'd say that is PCI working as intended. Why would you want a larger attack surface that touches your credit card data?
chopete3 | 22 hours ago
bonsai_spool | a day ago
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.
usernamed7 | a day ago
dwa3592 | a day ago
marsbars241 | a day ago
theptip | a day ago
saltcured | a day ago
supermdguy | a day ago
[OP] mooreds | a day ago
mapt | a day ago
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?
erikerikson | a day ago
[0] https://www.ama-assn.org/practice-management/hipaa/hipaa-vio...
panny | a day ago
erikerikson | a day ago
Bender | a day ago
[1] - https://www.amazon.com/Three-Felonies-Day-Target-Innocent/dp...
erikerikson | a day ago
Still, I was hoping for examples.
Bender | a day ago
erikerikson | 21 hours ago
panny | 23 hours ago
To tie back into the original discussion on HIPAA, I had a collection agency sending mail addressed to a previous resident to my address once. The return address was the clinic of the patient. I was dutifully writing RTS on every letter and putting it back in the mail, but they would not take me off their nastygram list. That was until I wrote "You know, it's a felony HIPAA violation to be leaking this patient's name and clinic to me after you've been notified of the incorrect address." The collection letters immediately stopped after I did that.
erikerikson | 21 hours ago
thewebguyd | a day ago
201984 | 23 hours ago
ndsipa_pomu | 9 hours ago
The problem is that without having some kind of enforcement, businesses will decide that it is cheaper to not worry at all about security and thus their customers will have their data leaked/shared etc.
There's a world of difference between a company that puts effort into security and one that doesn't.
mapt | 9 hours ago
A cryptocurrency business or a diamond business, by contrast, has very strict security protocols, because if they don't, all the value gets wiped out very quickly. The rules basically absolve the healthcare company of fiscal responsibility.
This update OP is posting about may require jumping through certain hoops, but it does not require functionality of those measures.
caycep | a day ago
ck2 | a day ago
rules for thee but not for me
saltcured | a day ago
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.
Cider9986 | a day ago
[1] https://www.youtube.com/watch?v=4sfIBRTcRpU
https://odysee.com/@NaomiBrockwell:4/HIPAA:7
burnte | a day ago
hoppyhoppy2 | a day ago
sonofhans | a day ago
adampunk | 22 hours ago
Cider9986 | 14 hours ago
MallocVoidstar | 23 hours ago
Jeremy1026 | a day ago
iloveoof | a day ago
This doesn’t get you much in terms of security. The IRIS system itself is an OLTP so it’s going to need to constantly pass around the encryption key and use it constantly, and if an attacker gets disk access they also will have access to the keys.
So this is a big waste of everyone’s time and money.
CodesInChaos | 21 hours ago
joncp | 22 hours ago
mchusma | 22 hours ago
threecheese | 22 hours ago
throw03172019 | 20 hours ago