Securing payments is much simpler than securing medical data in many ways because payment processors are centralized entities with established protocols for data transmission, where communication is largely many (vendors) to one or few (the processors), and where only one type of data is being moved. Health care organizations are HIGHLY decentralized entities where authentication is extremely difficult; where orgs employ many different protocols and software stacks; where many different types of data need to move freely between many orgs, with various levels of sophistication, in many different directions (patient to provider, provider to patient, provider to provider, provider to payer, payer to provider, patient to payer, payer to payer, provider to regulator, provider to researcher, provider to vendor, etc), with few established standards for how that is done (paper, phone, email, web application, fax, API, snail mail, CD, hard drive, USB, etc), with many people having access; and where organizations need to be porous, with high turnover by design. It should also be realized that a failure to access payment data or process a payment results in lost business and headaches. A failure to access medical data may kill someone, so tradeoffs between confidentiality and availability are much more nuanced.

In the medical world you have standards (HL7, DICOM, XDS) which are all about throwing large amounts of data around hospital networks (and in the case of XDS - outside). It's a castle with moat model of security - everything within the network is trusted and they focus on keeping the bad guys out.

Obviously that's a horrible strategy and it delivers the expected results..

Also your standards aren't entirely useful if you lack the inter-connectivity to employ them, the UIDs to be able to properly specify the data you are requesting, or restrictions on what data you are allowed to put within fields of the standardized data structures to make it easy to interpret by a program (believe it or not, with some standards this can also be a problem).

I prefer the term "candy shell security". Hard outer layer, warm gooey center.

This is an amazing summary of the problem and why it remains a problem.

Good comment, especially WRT trade off between confidentiality and availability. Nonetheless, I do feel that many of these items (few standards, little interchange, often old tech, data decentralization) are primarily problems because the vendors and hospitals don’t really have strong incentive to solve them. I do appreciate that the problem is non-trivial, but I don’t think that the problem would be unsolvable should the appropriate incentives be put into place.

I've worked as a security consultant for healthcare companies for years. The HIPAA Security Rule is a joke. The HIPAA Security Rule requirements are extremely basic things like "users must have their own login username rather than sharing an account" or "data should be encrypted where appropriate" (and it's left up to the company to decide where they think is "appropriate". There's also zero requirements around the type of encryption or implementation around it.. you could use a Caesar cipher and probably pass a HIPAA audit).

Yes, as the other commenter mentioned, hospitals do "take it seriously" in the sense that they put a lot of importance on passing HIPAA audits... but passing a HIPAA security audit is a checkbox exercise for security controls that are a decade+ outdated. It means absolutely nothing about an organization's actual security maturity.

Can confirm. Even the getting the ISO27001 certification is mostly about checking boxes. In many cases an ISO27001 item can be satisfied by picking one of several ways that standard gives to claim it's not relevant.

You don’t even have to check boxes for ISO 27001 these days. All you need to do is pay “consultants” in certain foreign countries about $5k and you magically receive your certification.

Can you elaborate? I’m not attempting to use them, it’s a useful tool when explaining 27001 doesn’t mean jack.

Can't speak directly to this, but just to add to the sentiment here - no breach was ever prevented through the application of pen to paper in the shape of a check mark.

If an organisation has the money to spend on doing ISO or something else, it should put the money towards someone who actually has some good skills and knowledge in security and can advise them.

An organisation that recognises the business value in being secure (less risk of fines, reputational damage, more ability to win work with lucrative large organizations) is already in a good place as they've crossed the first hurdle!

The issue with certificates like ISO (and indeed any other kind of kitemark for security) in my view is that it presents the opinion of one (probably inexperienced and cheap) junior person as to whether what you presented them with on the day sounded to comply with a rule. No focus on whether the mitigation is effective. No focus on whether it's relevant or appropriate. No focus on whether it's adequate, or how it sits in relation to the capabilities of a motivated adversary.

A decent understanding of your threat model, your exposure, and how you plan to invest to improve would be far more valuable. Second to this is to then avoid buying snake-oil vendor security products that aren't effective - many of the big organisations breached through solarwinds offer incredibly expensive "AI"-based cyber tools as those are in vogue. Yet all were compromised by a silly supply chain breach from some proprietary DLL a third party vendor was shipping into organisations, which was blindly trusted.

Getting a basic understanding of the old fashioned principles of security and having someone help you take technical measures will be a load more effective than producing paperwork to keep a junior auditor happy.

> If an organisation has the money to spend on doing ISO or something else, it should put the money towards someone who actually has some good skills and knowledge in security and can advise them.

These certifications are all about shifting blame and minimizing liability. They come up with these stupid standards that do nothing, certify their own compliance and then when they get owned they say "don't look at us we followed established best practice".

They don't actually care about actual security. To anyone who actually cares, the right way to do things will be painfully obvious. Instead we get people who scrutinize the standards in order to find the easiest, cheapest way to fulfill the requirements. Backup? Just copy the MySQL directory! Hashes? MD5 will do. Why encrypt data at all if it's only being transmitted on a local network? And so on...

There are legitimate concerns about the usability of secure medical software but I don't think that excuses some of the absurdities I've seen...

It’s even worse than that. Many of the compliance standards do require best practices, in most circumstances. For example, CSF, RMF, NIST 800-53 or 171 are all relatively sound from a technical perspective (e.g., data at rest must be encrypted, encryption must be FIPS-validated encryption, etc.).

Unfortunately with ISO 27001, NIST 800-171, etc., is that people see having written down policies as evidence of implementation of proper controls. If you have a policy that says you use role based access control, you have to actually do it. If you ha be a procedure that says you backup sensitive data to X alternate location and perform failover tests annually, you have to actually do it.

It’s sad, but 85% of compliance assessors I have worked with essentially look for “do you have a policy? Does that policy say the things the standard says it should? You’re compliant!”.

I blame the companies in part, but I also blame the people who are trusted to objectively and competently evaluate the system’s level of compliance. The standards and assessing compliance to them is great in theory, but in practice, people are...people.

The few areas I will say have succeeded are NIST 800-53/FISMA and FedRAMP. They are not perfect (see: SolarWinds), but the bar for obtaining an ATO and/or FedRAMP accreditation is relatively high.

I agree with largely everything which has been said, but have fallen back on ‘whelp, having even a shitty standard is better than nothing at all, because at least then people have anitivius’. I also would prefer to see an org with whitelisting and ASR enforced office over AV (if they had to be mutually exclusive), but alas we as an industry tell people to waste their time with things that don’t matter all to pass some checkbox security test to at least obtain some baseline. Some of this is probably greed/scams in the case of self-appointed standards (CREST for instance) where others legitimately are at least trying to solve the problems.

How do we solve these issues without upskilling a bunch of people who don’t know/care about security? Is there even a solution, or are we just bound to hit some mr robot-esk post apocalyptic scenario before people get their shit together?

Hard to say. In some industries I think it is unnecessary and if they face a breach, sucks to be them, but not a whole lot is likely to be lost/damaged.

In industries where it is a necessity (e.g., government, payment processors, healthcare organizations, etc.), I think there are several things that could encourage adoption.

However, fear of distant future possible outcomes is probably one of the weakest human motivators.

If I could advocate for an approach, it would be through tax incentives, government underwritten insurance that requires adherence and practice of security controls, etc.

My thought is, we can very likely encourage Cybersecurity practices using the same tools we use to say, stimulate the economy (e.g., providing liquidity to housing markets, tax rebates for first time homebuyers, etc.) or adoption of lower emission energy technologies (e.g., tax rebates on purchases of electric vehicles).

Unfortunately, people and government have not seemed to want to make the investment necessary to implement methods I’ve suggested above. Which is bizarre, because some of what we have lost and continue to lose is priceless (e.g., OPM government employee records, IP related to military technologies, etc.).

There are companies in certain developing countries who will skirt the rules on providing consulting and auditing/monitoring to the same company.

They do it for just about any ISO cert, not just ISO 27001.

It is a bit of a dirty secret with companies who work in heavily regulated industries. The companies in question will go through the motions, but make no mistake, you pay for the cert.

Sorry for being vague, just not looking to publicly out anyone. If you Google around, I’m sure you can find more about what I am talking about/much of the controversy around many of the ISO governing bodies.

> There are companies in certain developing countries who will skirt the rules on providing consulting and auditing/monitoring to the same company.

Welcome to my live :) We 'hired' these experts since they came up with the lowest price offer for our certification. I have been through many certifications in the past, this was one was the most... shameful.

Pathetic grasp of English, IT in general and security controls specifically. We passed that in absolutely zero time, if you exclude the time spend having lunch and 'discussions' about the interpretation of the requirements.

This was PCI BTW.

Next was the local healthcare certification, done by an international auditing firm. Possibly even worst. Total paper tiger exercise. Total lack of understanding of current security standards. Nice ties & suits though and even better lunches to discuss (you guessed it) the interpretation of the requirements.

I get why these guys get the jobs: they know the right people and look the part. But boy, would it not be nice if experts could do these jobs.

All a joke, we tell the auditors what they want to hear, we provide documents to prove the processses are implemented as they should but then in practice nothing if followed but they dont get to know that.

My favorite anecdote from working in health care was a VP asking if we could use—-trust OpenSSL, because it wasn’t version 1.0, and it was 0.9.8, and instead should we license an encryption product.

Was it a VP of a tech department? If not, it's a very valid question. Either way, it sounds like a good approach to ask the question to someone else who's closer to practical implementation.

He was our CIO. This was ~2011. Effectively, he was getting steak dinners from vendors, and using that to make decisions. These questions were either from ignorance or worse, malice, to force us to vendors.

This (public) medical company went out of business roughly a year after.

Especially considering some programs only get a minor version increment about once a year(FreeCad 0.18) while projects like Firefox or OpenSuse skipped tens of major version numbers within a short period.

I've done work in the medical industry, both for hospitals and private software companies developing medical software. In my experience; security, stability and compliance with HIPAA and other regulations are taken very seriously.

In my experience HIPAA is taken very seriously in the sense that people are willing to have meetings about HIPAA, with furrowed brows and serious expressions and a lot of signatures. Are the actual end-products more secure? No probably not. Of course this probably varies drastically from place to place.

Like you said, it may vary place to place, but you are definitely more secure when complying with HIPAA than without. The very act of discussing security within an organization in a structured way is a good start.

edit: missing word

There are plenty of reports of hospitals using out-of-support Windows versions (95-XP) with known vulnerabilities on _networked connected_ devices. ( https://nakedsecurity.sophos.com/2020/02/20/nearly-half-of-h... )

On the parent comment I am not saying that hospitals aren't HIPPA compliant but rather that the security expectations of credit card data are higher than medical data.

That's UK, no HIPPA per se. Funny enough, the infamous GDPR applies and data leaks are quite punishable.

The Hospital Group is in a quite bad position: 1) the blackmail, in no definition that's ransom. 2) The data leak has to be reported and potentially they will get fined by the state.

As for taking regulation seriously, I guess it does depend on the industry. Where I work GDPR and regulatory breaches are treated more seriously than downtime.

I assume UK business won’t have to worry about GDPR for clients in the UK going forward due to Brexit?

Not really. The UK has its own[0].

[0]: https://www.gov.uk/data-protection

Same. And we have external audits and experts checking what we do.

I dug out my login to comment on this:

>There are some regulations regarding medical data (Eg, HIPAA) but security seems like an afterthought in most hospitals at best.

I worked as a developer for healthcare/hospital websites and the company I worked for took it far more seriously than the hospitals did. We had to babysit them constantly on potential violations and actual violations. The average hospital has at least a dozen different HIPAA violations each and every day because in the end convenience almost always trumps security when a person is stressed and busy. And those were just the violations I was privy to as their web developer - undoubtingly there were even more that I couldn't have been aware of.

When we dropped support for IE8-10 it was a major issue at nearly every hospital we worked with and we couldn't convince them to finally upgrade until lawsuits started happening.

https://www.hipaajournal.com/upgrade-internet-explorer-to-re...

HIPAA compliance is a checkbox and actual security doesn't mean anything because actual security is too inconvenient.

Visa/MC have several advantages over a federal regulator:

- they have a more regular feedback mechanism (if someone's db gets leaked, they get more fraudulent charges from that company's customers, so they can figure out whose security was bad, and this happens often)

- they have a more credible enforcement mechanism: they can and will turn off your ability to process CC transactions, while a federal regulator in many cases faces a lot of political pushback if they try to actually shut down a medical facility

- the intended (and actual) purpose of PCI was to reduce the number of operators actually storing CC data; if a federal regulator tried to make things onerous enough to force most medical facilities to not store medical data, there would be enormous pushback and they would be forced by Congress to back down

Let's not go letting credit card processors off the hook, this was barely a month ago. Part of our security team is essentially full-time on dealing with the consequences of actors using stolen credit cards.

https://www.forbes.com/sites/billhardekopf/2020/11/13/this-w...

From that article:

> security researchers from Website Planet found that Cloud Hospitality stored information from more than 10 million travelers on an unsecured database with no password protection.

That will be taken by credit card companies as gross negligence and breach of contract (they include PCI DSS compliance on all contracts and a requirement that they do the same for anyone that processes credit card data for them) plus anyone going the legal route (and indeed there are reports of a class action that mention PCI DSS compliance explicitly)

My original comment was more in regards the care and security that is expected.

PCI is far from good requirements. Some of their controls make sense, some made sense for corps in the 90s and some are completely opposite to what you should do. It's good that they at least force the company to think of the requirements and dedicate some time to it. But I really wouldn't put PCI DSS as a good example, or an "almost always safe" example.

Not to disagree with you as I agree with the sentiment, but as a counter data point, I've seen a number of quite serious beaches in the past where PCI/DSS clearly wasn't being followed, as CVV2 was compromised along with payment details. Often the merchants were too naive to even understand what was going on.

Clearly having straightforward gateways to handle payments can help retailers and raise the bar, but I never cease to be amazed at how many sites run third party scripts on pages processing sensitive information! Bonus marks for using third parties that let other third parties place code on the page!

I think we have 2 orthogonal aspects here - the presence or absence of a straightforward commodity solution, versus the presence of clear security guidelines. The former seems to be what drives better practices, whereas the latter is more guidance people ignore, due to lack of personnel and skills.