A hospital in WV got hacked, which included taking security equipment down.
How do you give users access to things like VMS systems in an environment like a hospital and prevent things like this from happening? Is there a best-practice approach?
A hospital in WV got hacked, which included taking security equipment down.
How do you give users access to things like VMS systems in an environment like a hospital and prevent things like this from happening? Is there a best-practice approach?
In my experience completely separated networks are required.
...got hacked...
Who says it got hacked?
I'm obviously using the term loosely here since we don't know the exact attack vector and my question is more about how do you isolate a centralized component like a VMS server and still provider efficient user access?
I have a few ideas/answers myself but wanted to see what others came up with. I wasn't interested in starting a debate on vocabulary.
I wasn't interested in starting a debate on vocabulary.
Me neither, I saw the "this was not an attack or attempt to hack" statement, but I missed the malware connection. My bad.
So that we don't get offtopic on this, other reports I was reading (eg: ransomware) were initially equating this to a ransomware style attack, though it may have been some other form of malware.
The hospital hasn't disclosed details from what I've been able to find to describe the exact attack or what they did to restore things. One very possible approach could have simply been a good backup strategy where they could restore systems to a prior working state and then attempt to locate the infiltration source if it was a network attack vs. something like a USB/sneakernet attack from someone's infected thumbdrive.
From my own experience, I've seen deployments like these where multiple users outside of the security team want access to video streams, which makes it very hard to adequately lock down and isolate things.
One thought I had is that HTML/WEB gateways may make it easier to protect against these kinds of problems. You can limit open ports and in many cases the web gateway can be run on a separate machine which helps eliminate direct data transfer between a client machine and the server holding the actual video.
In some cases you might lose functionality by restricting some users to an HTML interface, but many times you have users that only need basic live viewing or occasional recorded video review.
It's not the first time....
Hollywood hospital pays $17,000 in bitcoin to hackers
....They paid the money!
One thought I had is that HTML/WEB gateways may make it easier to protect against these kinds of problems. You can limit open ports and in many cases the web gateway can be run on a separate machine which helps eliminate direct data transfer between a client machine and the server holding the actual video.
I think that would definitely help protect what lie behind the gateway.
My only though about these particular ransom type attacks is they seem more targeted at disrupting desktops and departmental datastores residing on the edge, than the enterprise.
It's worthwhile of course if the video and VMS install is safe behind a firewall, but when the client machines are inoperable it may initially have they same net effect, denial of feeds to those who need it.
Also, the hospital might not be willing to pay much for the keys to unencrypt their video data, assuming there was no known unexported incident. Compared to employee records or billing info say.
Also, the hospital might not be willing to pay much for the keys to unencrypt their video data, assuming there was no known unexported incident. Compared to employee records or billing info say.
Other than regulatory reasons...
"Oh, we will still keep it for 1 year, because that's the law. We just can't actually do anything with it." :)
While isolated or dedicated networks is one approach to a Healthcare environment, with the emergence of the IoT (Internet of Things), it is getting to the point where it simply is not feasible to do. SDN (Software Defined Networking) is driving simplicity and dynamic capabilities into today's networks as opposed to rigid complexity. Networks are now becoming subservient to the very applications that run on them. In other words, an application, device, or IP camera will be capable defining its requirements, and the network will dynamically deliver the requirements in a zero-touch capacity. While this will simplify installations of Video Surveillance, it will also raise security risk. Components that belong to the Video Surveillance solution will be placed in their own VRF (Virtual Routing and Forwarding) Container automatically.
VRFs have been around for quite some time, and commonly used in integrated networks to create secure containers for applications like surveillance. Deploying a surveillance solution within a VRF keeps security data confined within the VRF without requiring a dedicated network. Throughout the years, I have deployed many successful airports, hospitals, and critical infrastructure using this approach.
Simple, always create an isolated (no outside access) physically separate network for IP CCTV (all security). There are a lot of reasons this is smart, but security of the network and its assets is the best. If you need the admin and security network to talk to each other (say, for remote access - or to reach an access control database) handle these transactions via a firewall.
Use a VPN with authentication for remote access, password protect everything and if possible a separate network.
Ben, in such a scenario when connected from home thru a VPN, let's say remoting into a VMS server, if I were to use a web browser and downloaded malware, would the network be at risk?
UND 1, would depend on the sophistication of the VPN and how well it was configured to firewall off unneeded connections and restrict software acces.
My point was that if the VMS Server has access to download potential malware (as is arguably the case here), the addition of the VPN does not mitigate this risk.
That would be true. It would then depend on what restrictions are enabled for the VMS server. It most often is the one piece of the system that connects to the customer LAN to accommodate viewing clients, so therefore a threat vector. Limiting risk and damage would be the usual procedures.
1. Password protect operating system and VMS software on the server.
2. Ensure VMS software has some form of encryption for authentication. (Surprisingly as little as three years ago I knew of some systems that did not.)
3. Turn off all listening services unneeded.
4. Firewall/port block unneeded connections.
5. Anti-Malware software on server.
6. Restrict or deny Internet or general web browsing activity on the VMS server.
7. VLAN client connections to the VMS server, such as making access to the VMS server only from the same VLAN the server is on, separate from the business LAN.
Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.