I need to allow 2 medical devices that run Win XP embedded on my network to send PDF files to a share. And have the solution satisfy HIPPA rules.
I need to keep networked 2 medical devices (Zeiss eye scanners) that run Win XP embedded. However HIPPA does not like XP. To upgrade to the latest would cost many thousands MANY.
The devices just need to send a PDF to a network share.
I am looking for the best way to segment out the XP machines and still satisfy HIPPA requirements.
One thing I cant do is just unplug the network and use a usb drive because the devices are used many times a day and would hamper workflow.
I have considered removing the gateway on the XP pcs and also adding strict firewall rules (sonicwall)
Also thought of using a win 10 pc with 2 nics for 2 different subnets to act as a go between
Any thoughts?
Thanks
The devices just need to send a PDF to a network share.
I am looking for the best way to segment out the XP machines and still satisfy HIPPA requirements.
One thing I cant do is just unplug the network and use a usb drive because the devices are used many times a day and would hamper workflow.
I have considered removing the gateway on the XP pcs and also adding strict firewall rules (sonicwall)
Also thought of using a win 10 pc with 2 nics for 2 different subnets to act as a go between
Any thoughts?
Thanks
I understand your challenges,
these medical devices can be considered IoT devices, they offer the same challenges
-Older / Unpatched operating systems that pose security risks, e.g. getting breached to 1) be included in DDoS attacks, 2) being used to spread malware
Luckily you do have a SonicWall, I hope you have it fully licensed?
SonicWall can help you here with the following
1) Segment IoT devices away from the corporate LAN
2) Protect / Virtually patch IoT devices with Intrusion Prevention Service (IPS), if it runs a web server that needs to be publically available also suggest adding a WAF in front of it. If it runs a web server and it's HTTPS use SSL Decryption
3) Protect your LAN from the IoT device incase of infection, make sure that traffic to and from these devises are scanned by IPS and Gateway Anti-Malware (Gateway AV and Gateway AntiSpyware), SonicWall is one of the few vendors that can do GAV on SMB/CIFS (aka filesharing)
4) SonicWall has some HIPAA guidelines for you, also SonicWall has some pre-sales folks specialized on HIPAA certification
Addendum, dual homing (2 nics) will only trigger you to still have a port in your LAN, bad idea... The only valid reason for dual NICs is if you want to create an External DMZ: allow HTTP traffic from WAN to device and an Internal DMZ: allow device to contact LAN. Both DMZ should be fully scanned by your SonicWall device.
What SonicWall do you have? The Gen 6.5 series: NSa x650 has more memory and is better aimed to do DPI-SSL (SSL Decryption)
What firmware are you running?
Do you have the full licenses? Suggest you include Capture ATP
these medical devices can be considered IoT devices, they offer the same challenges
-Older / Unpatched operating systems that pose security risks, e.g. getting breached to 1) be included in DDoS attacks, 2) being used to spread malware
Luckily you do have a SonicWall, I hope you have it fully licensed?
SonicWall can help you here with the following
1) Segment IoT devices away from the corporate LAN
2) Protect / Virtually patch IoT devices with Intrusion Prevention Service (IPS), if it runs a web server that needs to be publically available also suggest adding a WAF in front of it. If it runs a web server and it's HTTPS use SSL Decryption
3) Protect your LAN from the IoT device incase of infection, make sure that traffic to and from these devises are scanned by IPS and Gateway Anti-Malware (Gateway AV and Gateway AntiSpyware), SonicWall is one of the few vendors that can do GAV on SMB/CIFS (aka filesharing)
4) SonicWall has some HIPAA guidelines for you, also SonicWall has some pre-sales folks specialized on HIPAA certification
Addendum, dual homing (2 nics) will only trigger you to still have a port in your LAN, bad idea... The only valid reason for dual NICs is if you want to create an External DMZ: allow HTTP traffic from WAN to device and an Internal DMZ: allow device to contact LAN. Both DMZ should be fully scanned by your SonicWall device.
What SonicWall do you have? The Gen 6.5 series: NSa x650 has more memory and is better aimed to do DPI-SSL (SSL Decryption)
What firmware are you running?
Do you have the full licenses? Suggest you include Capture ATP
I know the above is a lot of work, but I truly highly recommend segmentation!!!
And if you can't patch the Embedded XP, use virtual patching (IPS and WAF) instead
And if you can't patch the Embedded XP, use virtual patching (IPS and WAF) instead
This is a problem because you are trying to convert something insecure into something else secure and that's always a difficult issue to do with provable safety.
You could try this. It is not 100% provably safe but it is "reasonable" safety. You would absolutely need a HIPPI expert review it to see if it is acceptable.
Block off the XP machines on their own physical subnet with one other system and a firewall to the rest of the network. I'd use linux on a thin client for the "other system" as (1) this is not a heavy load to lift and (b) Windows is then out of the picture. Set the firewall up so that it will only pass outgoing Secure FTP (SFTP) traffic from the "other system" and no other traffic at all.
Let the XP systems send their PDF files to the "other system" on a network share using Samba. This gets XP reliance on SMBv1, and indeed XP itself, completely out of the picture.
Now get Microsoft Networking out of the picture. Have the "other system" check the share once a minute and if anything is in it, SFTP the file out through the firewall to a cooperating system on the primary network. The XP system can not get to the main network at all as the firewall is only permitting traffic from the "other system", everything but SFTP is blocked, and SFTP did not come with XP and should not be present.
Have another "other system" on the primary network look run an SFTP receiver, look at its SFTP folder once a minute and if anything is in it, send it to the destination.
You could try this. It is not 100% provably safe but it is "reasonable" safety. You would absolutely need a HIPPI expert review it to see if it is acceptable.
Block off the XP machines on their own physical subnet with one other system and a firewall to the rest of the network. I'd use linux on a thin client for the "other system" as (1) this is not a heavy load to lift and (b) Windows is then out of the picture. Set the firewall up so that it will only pass outgoing Secure FTP (SFTP) traffic from the "other system" and no other traffic at all.
Let the XP systems send their PDF files to the "other system" on a network share using Samba. This gets XP reliance on SMBv1, and indeed XP itself, completely out of the picture.
Now get Microsoft Networking out of the picture. Have the "other system" check the share once a minute and if anything is in it, SFTP the file out through the firewall to a cooperating system on the primary network. The XP system can not get to the main network at all as the firewall is only permitting traffic from the "other system", everything but SFTP is blocked, and SFTP did not come with XP and should not be present.
Have another "other system" on the primary network look run an SFTP receiver, look at its SFTP folder once a minute and if anything is in it, send it to the destination.
The least you can do is run them on their private LAN behind a firewall that filters all traffic except the stuf that is allowed.
and allow access only to a device outside that net that isn;t used for anything else (NAS like).
Or put the NAS on the SAME LAN and allow only outside access to that NAS.
and allow access only to a device outside that net that isn;t used for anything else (NAS like).
Or put the NAS on the SAME LAN and allow only outside access to that NAS.
Let the XP systems send their PDF files to the "other system" on a network share using Samba. This gets XP reliance on SMBv1, and indeed XP itself, completely out of the picture
This requires SMB/CIFS traffic to be allowed from the IoT Segment to the LAN segment. Please make sure this traffic is scanned by an Intrustion Prevnetion Service, and a Gateway Anti Virus.
CIFS/SMB/File Sharing is one of the main mechanisms/protocols used by
a) viruses to spread
b) hackers to acquire access to more systems
FYI, also suggest you disable SMB v1 in the LAN on any systems that does not need to be accesses by these ancient XP devices...
SMB v1 was a target for epxloits like Spectre and Metldown, also see Eternal Blue regarding this :)
Not wanting to praise SonicWall too much, but their IPS and GAV can block these.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@DrCline, SFTP is just hiding the transfers behind SSL/TLS encryption.... as he has a SonicWall that can do Gateway AV and IPS, encrypting traffic to LAN hides possible attacks and malware... and just complicates things...
SMBv1 was a target long before that because passwords can be guessed/calculated from traffic. (MSCHAP attacks, 1998-2008 era, it is/was also part of the core issue with PPTP).
Spectre & Meltdown are quite different methods to get any value from memory cells anywhere in memory even when non-accessible (other process, kernel space) or in a different VM on the same hardware (same memory set effectively) using a timing attack where the cause is a Hardware failure (speculative execution).
It would be better to restrict transfers to tools that require less infra structure and services, like SCP, SCP uses the same underlying protocol as SSH (SFTP uses the same, but is interactive). SCP it is just easier to manage as it is completely setup from the commandline therefore it also is easier to audit.
SMB Should be encrypted as well so that firewall AV won't help at all. Getting the attack surface down to a single port is helpfull. (only port 22 open).
Also SSL is not about "Hiding" data, if setup correctly it will also ensure the source & destination are the intended ones, without someone snooping or changing data in the middle.
Spectre & Meltdown are quite different methods to get any value from memory cells anywhere in memory even when non-accessible (other process, kernel space) or in a different VM on the same hardware (same memory set effectively) using a timing attack where the cause is a Hardware failure (speculative execution).
It would be better to restrict transfers to tools that require less infra structure and services, like SCP, SCP uses the same underlying protocol as SSH (SFTP uses the same, but is interactive). SCP it is just easier to manage as it is completely setup from the commandline therefore it also is easier to audit.
SMB Should be encrypted as well so that firewall AV won't help at all. Getting the attack surface down to a single port is helpfull. (only port 22 open).
Also SSL is not about "Hiding" data, if setup correctly it will also ensure the source & destination are the intended ones, without someone snooping or changing data in the middle.
@J Spoor, there should be NO traffic TO the LAN , only traffic LEAVING the LAN.
So no access from the outside and only port 22 (SCP) access FROM the LAN to one device outside.
So no access from the outside and only port 22 (SCP) access FROM the LAN to one device outside.
ASKER
Thank you all for your input
I think I am not going to risk a audit and recommend a upgrade of the XP devices
I think I am not going to risk a audit and recommend a upgrade of the XP devices
You can have a newer machine with 2 nics scan that san every say 1 to 5 minutes and move any files found off and onto their new destination...
A cheap firewall can even do better isolation.
or even easier, find a nas device that is capable of having 2 separate subnets on 2 interfaces.
We basically use something similar to move hourly data off of our SCADA systems and into our GIS system with no possibility of cross communication...