World-leading heart hospital 'very, very lucky' to dodge ransomware hit World-leading Papworth Hospital has escaped a full-on zero-day crypto ransomware attack thanks to the "very, very lucky" timing of its daily backup. It's believed that an on-duty nurse at the heart and lung hospital in Cambridgeshire, UK, unwittingly clicked on something in an infected email, activating the attack at about …
I'll get downvoted for this but the simple answer is that clinicians wouldn't stand for it. Easy access to everything allows them to get on with treating patients and every clinician loves their e-mail.
Apart from anything else network controls should limit damage malware can do, that's assuming it can run in the first place which is something many NHS trusts/boards/CCGs are managing to block using application whitelisting, sandboxing etc.
"As for ransomware, how do you stop it when you have a shoestring budget preventing a proper prevention strategy and the most likely zero point is over your head?"
I'm on a shoestring budget. Here's how I stop them.
1) Write a list of what programs your users use that are not installed in the /program files directory. These are typically programs that "run" from the network. Create a list of network paths that need to be executable.
1A) Check the security permissions of the executables on network shares. Do the users *need* to be able to overwrite your executables, potentially with a Trojan that everybody then accesses via a shortcut when they try to login to $program in the morning? This is allowed by default, but the default is stupid. Consider changing it if you don't require users to do this.
2) Create a new Group Policy Object. Goto the Security Restriction Policy options. Change the default level from "unrestricted" to "disallowed". Whereas before any program would run anywhere with no questions asked, now programs by default will pop up a message saying essentially "Sorry Dave, I can't let you do that" unless the program is on the exceptions list. Your list already includes %program files% by default, so you only need to add network paths where people need to be able to execute .exe files. Add the paths that you gathered at step one.
3) You need to download some additional extra GPO bits. There are GPO addons for Office, and Adobe. You want the Office ones to prevent Macro's from running, and the Adobe one to disable scripting. Have a look at EMET5.5 while your thinking about security. Nice freebie, but probably too much effort for most people to install since it needs doing on each computer.
4) Assign the new policy object to your desktop, and check you haven't prevented things from running. When your sure that you haven't, roll this out to a handful of users, then to wider groups, and then to everybody, having added the programs that you forgot about that only two users used.
Money required from management, £0.00. All that is required is your time. It's now impossible to:-
1) Run any file that is vaguely executable (.exe, .pif, .bat, .scr, .etc) which is not in program files or in an authorised directory.
2) Have macro's in MS office ruin your day. (or if Macros are in use, digitally sign them and run only macros signed by you)
3) Have PDF documents running scripting on your computer as well as just displaying a document.
With a spend of zero, your network is now hardened to the point of being impervious against your users running trojans. Your users are unaffected by the security precautions that you have just taken, since they only become apparent when they try and do something like running a program attached to an email or on external media.
The only real downside is that executable autoruns on CD's will now fail, you could enable these through putting in path exceptions for your CD drives if your organisation security policy allows running random potential zero day viruses from external media sent from outside the company. Given the option, our top management went for complete paranoia and disabling any potential threat.
Ultimately though, if your being given solutions (even good ones) to implement then your doing it wrong. What you should do is what I did to get to where I am, which is sit down with a pen and paper and consider what threats you face, and how you can mitigate against each of those entry vectors/threats.
"your network is now hardened to the point of being impervious against your users running trojans. Your users are unaffected by the security precautions that you have just taken, since they only become apparent when they try and do something like running a program attached to an email or on external media."
OK so far. Now what about the rest?
How, exactly, does your suggestion help protect against the apparently never ending stream of exploits that use authorised (non-blacklisted) executables and just require the user to access a specially crafted JPG, PDF, web page, or whatever. In the case of a web page, it might even be served up by a whitelisted website, especially if the whitelisted website serves 3rd party adverts and isn't accessed with the aid of an ad-blocker or script blocker. Then how does your strategy help?
""consider what threats you face, and how you can mitigate against each of those entry vectors/threats.""
Exactly. Consider what you do about approved applications with as-yet unknown vulnerabilities which can be exploited by permissible (and often necessary) data formats. What's your mitigation there?
Start again, please.
It's not rocket science, but apparently to some people it might as well be.
"I'm on a shoestring budget. Here's how I stop them."
How on earth does that stop them?
You haven't even identified different groups of users with different sets of access rights to different sets of data. Y'know, a scheme where people's access (a user's access) to data depends on their role within the organisation, and where their activities can be authenticated, authorised, and logged accordingly.
You definitely haven't deployed an OS with a securely implemented scheme for rights management and object access control and trustworthy audit logging facilities.
Is that too much to ask for?
All you've done is provide a false sense of security, which sadly seems to work well for lots of IT people.
"Easy access to everything allows them to get on with treating patients and every clinician loves their e-mail."
Yes, but seriously it's not a conflict between "easy access" and security. It's a conflict between stupidity and security. If you can just stop people from being stupid you'll have solved most of the problem.
Just like there are basic safety standards for things like light fixtures, the NHS could enforce those for the software they use. Since software security doesn't really cost money (only features) that should be easy to do.
If you can just stop people from being stupid you'll have solved most of the problem.
OK, I'm getting really, really tired of this meme, so let me give you the benefit of close to 3 decades of experience in dealing with security, people and protecting organisations including military and governments (hence anon).
Stop treating people as a variable you can just tweak to your satisfaction. You should accept they are your reality, so stop blaming them and start working on ways to incorporate that established reality into your work, otherwise you are quite frankly busy finding excuses for not doing your job.
Working on any model of protection starts with accepting current realities. Yes, there are things you can change but, trust me on this, people are not part of that helpful set. You can tweak them a bit, but you will find that over time they will meander back to that mean value - in short, seeking to change them is wasting time and resources for frankly appallingly little benefit.
Now, ransomware. Assume that your users WILL open these emails, irrespective of how much advertising, training and awareness campaigns you throw at them. Start with wondering how it is possible that they can run unauthorised executables and work from there.
Just stop the excuses already.
You can't work that way because Murphy means you MUST assume EVERYONE is a Darwin Award candidate with Domino Effect potential. The one you ignore or are forced to overlook WILL be the one that destroys you.
As for ransomware, how do you stop it when you have a shoestring budget preventing a proper prevention strategy and the most likely zero point is over your head?
Put it this way. Try stopping the Black Death with nothing but a net.
"Start with wondering how it is possible that they can run unauthorised executables "
Actually in quite a few places I'm familiar with, it might also be interesting to wonder *why* people think they *need* to run "unauthorised" code to do their jobs (non-work-related stuff is a different matter). The answers might be interesting inside and outside the IT department.
But eliminating unauthorised executables still leaves a zillion vulnerabilities (known and unknown) in the authorised executable list. You want to blacklist Outlook or Word or even Acrobat, good luck with that. But if that's not done, the vulnerabilities still exist, whether the IT Department like it or not.
Well even if you cannot change people themselves, you can easily influence their behaviour. How many people do you know that got electrocuted by their household appliances? With all those appliances around, that must be a high number, doesn't it? The fact that this number is rather low is that household appliances are designed to prevent you from doing stupid things. You cannot simply touch any conductors inside, because they are encased in plastic.
However in computing there is no sense for security. Yes we tell people not to execute code from the Internet, yet when you click on a link to download an executable in your browser, it'll actually offer you to execute it right away. That's a stupid thing that should never have been offered. Same goes for all kinds of app containers like apk or flatpack. If you click on a link, and your system will install software that's a _really_ bad thing.
Instead you can make stupid things hard and provide safer alternatives. This then will influence people into not doing stupid things. Also make sure that the things they actually need to do (e.g. opening PDF files) is as safe as possible (e.g. not using a feature complete PDF reader).
BTW the stupidity doesn't always just lie on the end user side, often it's also in the IT departments. Just think of the many computers that have office software installed without needing it, or Acrobat Reader when a more secure PDF reader would be good enough.
"household appliances are designed to prevent you from doing stupid things."
That's a very 20th century remark, which seems increasingly inapplicable to various modern pieces of consumer electronics and even white goods (and other stuff).
Expect increasing accident rates as the years go by and appliances are designed more by the "industrial design" people and less by actual clued up engineers.
This applies particularly to software-based systems in recent decades; far too much software is not fit for purpose, defective by design, and yet it's extremely rare for anyone to be held accountable for providng or procuring stuff that isn't fit for purpose.
"Expect increasing accident rates as the years go by and appliances are designed more by the "industrial design" people and less by actual clued up engineers.
This applies particularly to software-based systems in recent decades; far too much software is not fit for purpose, defective by design, and yet it's extremely rare for anyone to be held accountable for providng or procuring stuff that isn't fit for purpose."
Yes a lot of poor software is and will continue to be created but not very little of it has any safety impact.
I would be surprised if the SW in a home appliance was required to operate correctly to ensure safety. It is still engineers who are responsible for making things work and pass the appropriate regulatory requirements. Demonstrating that the requirmenst for functional safety for SW are met is rightly very demanding which is why designers avoid it unless absolutely necessary. I do not know what you have against industrial designers but in the real world they work in a team with the engineers. My prediction is that despite an every increasing number of devices overall accident rates decline due to the slow accumulation of knowledge and experience and improvement of regulations and design.
Much as I hate the "why have a dog and bark yourself" attitude, this is very true.
<massgenerlisation>
It's our job to design, build and secure IT environments
It's their job to help people with very serious heart conditions
Trying to either side to do the others job isn't going to end well
</massgenerlisation>
Start with wondering how it is possible that they can run unauthorised executables and work from there.
They probably aren't "running executables" at all. It's far more likely that they are opening an EMail attachment that contains an image or other binary file that has been specially crafted to take advantage of a bug in the software on the PC that displays that kind of file, and by exploiting the bug the attachment gains execution access, possibly with elevated privileges.
Short of blocking all attachments, the only defence against this sort of attack is to run only bug-free software, and we all know how hard that is to come by!
I've found it relatively easy to set up secure systems as demanded by management - the same management that demands it taken down because they are too bloody stupid and lazy to follow their own rules. However I'd still imagine that 80% or more of the files could easily be un-encryptable as there is no reason to modify most data.
As someone working within the NHS I can honestly say it varies massively. My own NHS don't, it's highly restricted but still reliant on the NHS Mail system which itself was letting through a ton of ransomware e-mails at the tail end of last year, thankfully better now.
The bigger problem tends to be access to personal e-mail, required by students and typically it's attachments from those which cause the problem. However with proper network controls the damage ransomware can do should be extremely limited and quickly rectified - that's assuming it doesn't just start uploading that information - which is the nightmare scenario for many of us.
Maybe they shouldn't be using the same email system for both communication between fellow clinicians and the general public. There should be an internal and an external one.
The internal one requires that secure messaging standards (S/MIME or OpenPGP; the former might be somewhat easier for the NHS) be used: on sensitive machines, they only have access to the internal system.
Then they can email their colleagues internally just as they ordinarily could… digitally signed so they know the email hasn't been spoofed, and possibly encrypted to for patient privacy.
The external one talks to the outside world, and is only accessed from suitably protected endpoints. Those same systems could have access to the internal one so you can forward information to people on the internal network after manual checking.
Least then, the malware has limited reach.
Then again, paper does not have these problems… the other solution would be that they walk around with pencil and paper and record things the old way. Sure, use the computer system to transfer the data from place to place, but hold onto some paper records for as long as it takes to ensure the digital copy is safely backed up.
Our local NHS Trust uses Cisco Ironport's for everything outbound, not sure about the rest.
ANY email that's sent out is encrypted by default. If you want to send non-sensitive e-mails you have to placed [DONOTENCRYPT] anywhere in the subject. They also had DLP keyword triggers which placed the email in a queue if it contained any number of patterns (e.g NHS Patient numbers, and so on).
Nor does a properly designed and run computer system, especially one with fewer privilege escalation vulnerabilities than the legacy OS (and applications) in widespread use in the NHS.
As noted elsewhere, why does Joe/Joanna Random User have any access rights to change other people's data? Maybe they didn't, if an unauthorised privilege escalation is in the picture.
This stuff shouldn't be rocket science. What happened here shouldn't be acceptable either, and any costs should be charged back to the people who provided the system (and to those who signed it off as acceptable). That might start to change behaviours a bit.
The bigger problem tends to be access to personal e-mail, required by students and typically it's attachments from those which cause the problem.
Would blocking gmail, hotmail etc. whilst whitelisting *.ac.uk, *.edu and other universities'* email servers work in this scenario?
* I know this gets a bit complicated in places like France or Switzerland, but should be doable.
"Just how did a nurse's account have permission to cause any significant damage?"
Depends who they are. A senior nurse with many years of training and experience can easily outrank some doctors. And don't forget, the article described it as a "zero day" so maybe it was a privilege escalation attack.
A friends daughter is a nurse. She has two degrees. She's a senior Sister and orders doctors around every day. That's part of her job.
I just read your comment, saw the highlighted letter, and thought (in order)
But that IS how you spell it.
Has El Reg made a typo ?
OMG, perhaps the g wasn't there in the first place.
That would make, erm, Goole. That's a place!
I'll go back and check the article!
Have an upvote
Indeed there is such a place - I used to travel through it a lot on the train in the 1980s on my way to university in Hull, and always had a titter at the brick water tower. All it needs is a couple of goolies at the bottom.
http://www.goole.com/wp-content/uploads/2015/01/water-towers.jpg
Lots of wards are running XP. Even if the accounts are setup correctly, when you're running something that old there are going to be cracks criminals can creep through.
BTW those systems have email because it's how the different departments sent each other results e.g. get an x-ray and the image is emailed to the consultant before you can walk back to their office.
I will take a small wager that whatever hit them wasn't able to do privilege escalation on a patched remote server just because it happened to be running on XP. Even if it managed to do local privilege escalation.
...and if the servers were running XP then there are even more questions to be asked.
We have 8 XP machines, all on a separate LAN with no connection to anything else. The rest of the desktops/laptops are Windows 7 or 10.
Ward PCs are all Windows 7. We demanded clinical system suppliers ensured compatibility before the deadline for support on XP. The remaining 8 XP machines are there due to specific lab equipment not being compatible with Windows 7.
Hey Terry, I know what you mean (every tech here does). Finance people do not walk through reality, they live in alternate reality.
I've been trying to push in a system for disaster -prevention- into our setups, but how do you prove to them how much you -will- save? They don't care. It won't be them up all night fixing broken stuff. And broken stuff will be replaced out of a different budget. Sigh.
I've been trying to push in a system for disaster -prevention- into our setups, but how do you prove to them how much you -will- save? They don't care. It won't be them up all night fixing broken stuff. And broken stuff will be replaced out of a different budget. Sigh.
That's why we use BCM (Business Continuity Management) scenarios. BCM planning is based on estimating the cost of certain scenarios, which then drives decisions about business risk mitigation. In other words, you calculate the cost of things going AWOL and then decide if you engineer a solution, insure it or mark a budget for taking a hit. The fun part is that especially in a business with shareholders there is a duty to protect a business, so once you have a doomsday scenario where security fails you have a financial basis on which to base decisions - and board members who are responsible for making it happen. It moves the pain of failure to where the money decisions are taken which rather helps.
BTW, if someone talks about BCM being an IT activity, send him or her back to school. This plays at board level. IT is an important part, but it's BUSINESS continuity, not IT continuity :).
"finance people only like to plan for what's actually going to happen,"
Finance people should never, ever be allowed to run a business; advise those who do - fine, but beyond that... no.
Quite apart from that an attack on a corporate IT system is going to happen; the only unknown is when. A hospital IT system is simply too tempting a target for a hacker to ignore.
"We've got some fairly ancient application architecture so we've got some file-shares, and actually that's what happened to us – a crypto attack went through our file-shares and encrypted the data."
"Thank God for that full backup, then," she added.
Correction: Thank our IT staff for that full backup.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
