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.

BlackJack11
BlackJack11 used Ask the Experts™
on
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
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Scott SilvaNetwork Administrator

Commented:
How about the Xp machines being on a separate switch and separate subnet with a basic switch.with a san or nas device.
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...
J SpoorTME / Network Security Evangelist

Commented:
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
J SpoorTME / Network Security Evangelist

Commented:
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
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Dr. KlahnPrincipal Software Engineer

Commented:
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.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
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.
J SpoorTME / Network Security Evangelist

Commented:

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.
Senior Information Technology Consultant
Commented:
Something to consider.

As a former HIPAA officer, I would state that it will be more expensive not to upgrade.  I would speak with the HIPAA Officer for that organization   and at least let them know.  A single fine can be $200,000 and per incident.  That is "many thousands".

And you are not going to prevent XP from going away.  Change is imminent.

Now if the intent is to sunset the entire solution then temporary segmentation might suffice.  However, I doubt it will survive a real audit.
J SpoorTME / Network Security Evangelist

Commented:
@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...
nociSoftware Engineer
Distinguished Expert 2018

Commented:
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.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
@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.

Author

Commented:
Thank you all for your input

I think I am not going to risk a audit and recommend a upgrade of the XP devices

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial