1

I have created a software solution for use by hospitals. It uses PHP / MySQL and cannot be compiled into binaries. A hospital that is interested in licensing this software is asking for the PHP code to be hosted on a server that they own, where several server administrators will effectively have access to this source code. This is obviously unacceptable to me. My counterproposal was that we host the source code on our own company server, but due to the risk of clinical data leaving the hospital, they do not want to go with this option either.

I am interested in your thoughts on the following options - and whether there is another way through this that would work:

Option 1: Colocate a server that my company owns and operates that only we have access to at the hospital behind a secure firewall. This protects the source code while mitigating risk for the hospital. They can basically firewall this server so that no data leaves the hospital. The network administrator I spoke to doesn't prefer this option since they have a unified network architecture they use and don't want to include another server. This response doesn't make a lot of sense to me.

Option 2: Contract with Amazon Web Services or another mutually acceptable cloud-based platform to host the PHP code. This does mean that the clinical data would leave the hospital for processing, and thus the risk of this may be less preferable than option 1.

Option 3: Am I missing any other options out there?

Thanks.

  • 1
    My $0.02 worth. Your companies lack or forethought about securing your own source code and IP is not really the clients fault. Being expected to implement servers, network security, infrastructure changes or to sign up for 3rd party services just to protect your IP would put me off dealing with a vendor. I expect vendors to meet my requirements not the other way around. So option 4. Rethink your approach/model. – Sir Swears-a-lot May 12 '18 at 09:32

3 Answers3

3

Option 3: use ioncube to encrypt the code. This prevents reverse engineering or tampering and allows you to visibly assign licenses (and print the licensee on-screen).

The client can then run the stuff wherever they need, but ioncube makes it immutable for the admins.

John Keates
  • 681
  • 4
  • 9
  • 1
    This is the option I'd recommend as well. There is no reason why this wouldn't work. Also, Ioncube loaders are free and can be installed on the host. – Ivan May 09 '18 at 06:43
  • Brilliant. I had looked at ZendGuard but that works only up to PHP 5.6. Ioncube goes up to current releases. Thank you! –  May 09 '18 at 20:57
0

Your option 1 seem the best to me, but it can cost you more than you think, some hospital need a special token to enter in VPN to access some ressources, thus they might sell you that part, as they surely have a proxy too, so your server will finish hard to connect too.

It could be a OVH or a VM to deploy too, if they prefer that way.

Dont forget your option 1 protect your code against new comer, but the fact the server is hosted on site does not protect it at all to have the server booted in recovery's mode to copy the files.

yagmoth555
  • 16,300
  • 4
  • 26
  • 48
0

Your options for hosting in AWS don't necessarily imply a lot more risk. For one thing, AWS protects its hardware and your information pretty darn well if you follow all the best practices. If you use a VPN gateway to link the VPC to the hospital network and remove all other Internet connections from the VPC, it can be just as isolated as the hospital network it is connected to.

You could also host at a non-hospital co-location facility, but to be frank, for one server that is way more work. It probably won't be a positive choice from a financial perspective either.

As far as the source code being accessible, you may consider a license agreement that forbids transfer / re-use of the software elsewhere. Not perfect security by any stretch, but many people making software make money from time limited license agreements that offer service and updates in addition.

Slartibartfast
  • 3,265
  • 17
  • 16