There’s no way to make a machine bullet proof. Hardened, yes, but this days even having it not connect to the net is no guarantee. Deep Freeze and its ilk is fine for individual public computers (say libraries), but would be impossible to use in a hospital setting. Ed: Also, Deep Freeze could probably be easily rendered useless with a root kit.
I disagree that the problem is the whole concept of EHR. Both the VA system and Kaiser Permanente have been using networked EHR for decades without problem. The execution (and as you point out, the Meaningful Use “guidelines” - hah!) has been craptastic. And in a distributed healthcare environment, where patients interact with at least half-a-dozen physical locations of a hospital system to receive even fairly basic care, running patient files around from place to place is just silly.
Just because EHR started poorly doesn’t mean it’s time to go back to clay tablets and chisels.
2 Likes
Depends how many medical errors are acceptable.
2 Likes
Linux malware isn’t a serious problem for users since there aren’t a lot of Linux workstations out there (comparatively), but Linux workstations are often not too hard to exploit if you’re looking to do so, thanks to a lot of design issues in X11, et al - security is a hard problem no matter what your OS. If IT locks down clients hard it helps secure things but users are bitter and try to work around it. Running Linux on servers is probably as high risk as Windows servers. There are is a lot of attack surface on a Linux box. It’s possible, but challenging to get all services properly hardened and keep them that way.
5 Likes
If all the crap I had to do to configure the RedHat boxes at my previous worksite is any indication my answer would be yes they are just as open to attack just not a big target like Microsoft. I kinda wish the linux side for install and patching was as well set up as the windows guys had it working. For windows install a base OS image from a network bootable CD that pulls from a depot your admin only account had access to and then you just submit a request to the patching tool that will automatically apply all the up to date patches and whatever specific configs for IIS/File/Print/Sharepoint/etc services you want applied to the box. RedHat I had to log in with root and manually run yum packages and then test them for all the monitoring/AV/LDAP etc. so much more of a PITA than microsoft to build the box.
And we locked down so many ports, well basically if you don’t specifically use it then it is blocked.
For desktops NOBODY GETS ADMIN not even server admins and the server admins get whitelisting for all apps on your work issued ‘personal’ machine even though you have a different account for server work vs. local email and such. You need to install something? It should be on the company software repository which will elevate privs just for the install and then take them right back. If you actually have an app that requires admin you get audited every 6 months and get recurring approval from your manager.
Also I used to get security bulletins when I was the local security focal and the linux/unix alerts for oops this allows root/remote execution were just as common as the windows ones.
Long story short no matter what freaking OS you use, keep it patched and up to date.
7 Likes
Hear hear!
5 Likes
For the day job I’m a dev. working on a Linux-based networking/security appliance, but we ship boxes with a (CentOS-based) distro on them so we have to keep up on secure defaults, patching, and hardening those things and have to keep tabs on various vulns. There’s a constant stream of sec. updates and a million ways to misconfigure to make pwnage possible, and a lot of security principles and practices you need to really understand if you want to be sure you’re properly hardened. Linux is a security nightmare on that front though it’s not Linux per-se, but the piles of services, each with their own caveats and quirky way of doing things, and the constant stream of patches that make it painful. It’s not surprising that there are Linux boxes getting pwned and added to botnets all over the place.
I think MS servers are probably simpler to admin in some ways (I don’t have too much experience), since there’s usually only one way to do things rather than a dozen, less complexity, and a more unified app/security model, though they seem to have their own challenges since everything’s rather opaque and dependent on one main vendor to ship fixes with fewer workarounds when there are issues.
4 Likes
well there are a lot of settings you can force with group policy that make things less of a pain. as long as the machine account is in the proper active directory container it is all automagic as any attempt to bypass this by changing the settings locally get undone next refresh.
2 Likes
not that I have any idea about the administration of Windows boxes but this does not sound like more automagic than a mature salt or puppet environment
3 Likes
Yeah I started looking into Chef/Puppet as I hadn’t heard of it till becoming unemployed… and well they have scaling issues which of course means not used where I worked. They look at lot like the HP System Automation that was used. Access to that was on not only a secondary account but a secondary whitelisted workstation and not handed out like candy because duh as the tool had admin access to EVERYTHING.
2 Likes
The last vendor I worked for shipped a security appliance where the OS was Linux based. When I first got there, they were “rolling their own” distro. Man, I was happy a couple years later when they decided to switch to CentOS. The overhead on trying to secure in house code, and keep up on the custom distro was a nightmare.
5 Likes
When I got here we were maintaining/patching an old vers. of Fedora and rebuilding core rpms/managing it all since there was no vendor support - nightmare. It was hard work to get off that and onto a modern CentOS based distro (and getting everything 64 bit clean, and other things), but life’s far better now.
3 Likes
GPO is a bit different since it’s a way to define a set of very fine-grained policies (security and otherwise) that all/some/select systems that join a domain automatically get enforced on them based on defined criteria. I don’t think there’s anything exactly like it in Linux-land - you can accomplish similar things with a good bit of work using Puppet/etc but that’s not what they’re for.
3 Likes
Stop. You’re giving me flashbacks. 
We went through similar gyrations, as well as getting the newer version DISA certified as software, instead of as an appliance. It was worth it though. Back during the “appliance days” there may have been an OS patch or two that rolled out with a rule update, instead of as an official patch… (That’s what I hear anyway.)
3 Likes
I don’t have any experience with UK healthcare IT. I have some passing experience with US healthcare IT. I just retired after spending 35+ years in IT. The last 15 were spent doing IT Security for a research university that had a wide variety of projects that were subject to the US HIPAA and other healthcare regulations.
The thing is, a lot of things that seem great in theory, are greatly changed after being ground down by years of reality. At the end of the day, everybody has to do the best with the tools available to them. I feel for the poor schmucks who were tasked with IT at those hospitals. There, but for the Grace of God, go any one of us.
In my experience, IT is ALWAYS a mixture of non-optimal parts, hastily assembled in ignorance, and managed according to deeply conflicting priorities. In theory, it is possible to manage any assortment of systems in a secure way. In practice, you never get meaningful agreement between the conflicting goals of efficiency, security, cost management, usability, and regulatory compliance. And, make no mistake, ALL of them conflict.
That is not to say that mistakes were not made in this case. I’m sure that after the analysis, they will decide that something should be changed. But, the usual core cause of broken IT is improper balancing of the conflicting priorities, not individual acts on the part of the low level admins. Nor, is broken IT usually caused by the unique permutation of components. Broken IT usually is planted as a seed of mis-managed priorities, then it is carefully watered with a mixture of insufficient resources and broken feedback. Finally, it comes to full flower in a gloom of tolerated mistakes.
In my experience, even with a high amount of available resources there are limits to how well any given mixture of IT components can be hardened to attack.
- If the admins are blocked by the vendors or management from hardening and protecting critical subsystems, then the environment can't resist some non-targeted, automated forms of attack.
- If the admins are allowed to harden and protect all the components, but they are limited from altering things in expensive, inconvenient ways, and the components are high target (IE Windows, Cisco, Oracle..) then the environment can resist all automated forms of attack, but it will fall to most targeted attack.
- If the admins are allowed to build from the bottom up for security, playing to their strengths, with no regard for expense or convenience, then the environment will resist all automated attack. It will also resist most targeted attack. Unfortunately, while this level of expense and commitment may sometime exist at the beginning of a project, it is never sustained.
5 Likes
And few of them sincerely believe that paper is the solution to their problems versus reforming the shoddy hack-systems in place.
2 Likes
I think what most doctors would like is a system that shows them what they need to see at a quick glance, but which lets them write or dictate:
BP not dropping as expected. Cardizem 60mg BID
instead of having to type and mouse for 2-3 minutes to get the same result, as they do with the EHR systems I am familiar with. Most of this time is overhead (logging in, getting to the right screen, logging out) rather than real clinical input.
If you’re really interested in seeing what some practicing MD’s have to say:
1 Like
Nah, I doubt the creators/controllers know nor care their ransomware is running on hospital machines. Why should they? They set the trap, it springs, the victims send them a bitcoins… and so it goes on. All it took is somebody in the hospital using a machine that had the vuln to take the sploit. Simple as that. Might have been a bank, might have been a car park, a greengrocer.
You wouldn’t be kicked all the way back to lamplight 'n laudanum; but I suspect that your friendly local radiologists might beg to differ on that. Even if they still have a stock of x-ray film somewhere, that’s not going to get you an MRI.
1 Like
About a decade ago, I was doing some autoradiography research (tracking inflammation markers and receptor densities in brain tissue).
We developed our own film, and used old developing gear that we’d bought second-hand from a hospital that no longer used such crude methods for X-rays (they’ve nearly all gone digital these days). It was already getting very difficult to find old-school film supplies appropriate for radiographic work.
