Link to home
Start Free TrialLog in
Avatar of philodendrin
philodendrin

asked on

Server 2016 Essentials Causing PCI Compliance Scan to Fail

Working with a non-profit customer that has a Server 2016 Essentials server. Customer is utilizing almost all of the features in Essentials - workstations are running Essentials "connector" and backup nightly to the server, Anywhere Access is enabled and used, etc.

Problem is... they added a credit card processing terminal on the LAN and now they are failing PCI Compliance scans due to Server 2016 Essentials' use of TLS 1.0 protocol, as well as 64-bit block ciphers, RC4 Ciphers, and the use of "clickjacking" URLs (they cite https://public IP/connect as an example).

My typical go-to fix for this is to add a Public IP, segregate the credit card terminal on a VLAN, route the new public IP to the VLAN and call it good. PCI compliance scans no longer see the server and we don't need to break the server's features.

But, this customer has no funds to add an additional public IP, and my understanding is that if we use something like IIS Crypto to harden the server, it will break the Server 2016 Essentials connector and thus break workstation backups, the ability to join workstations to the domain with the connector tool, and pieces of "Anywhere Access."

Anyone have any other ideas for dealing with this? 
 
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

There is no way to be PCI compliant with essentials and a credit card terminal on the same broadcast domain.  Full stop.  It was never built for that particular use and cannot be made compliant without breaking the OS. It is a well documented and known limitation. If they aren't willing to give up money, they'll have to give up features. 
Avatar of philodendrin
philodendrin

ASKER

Agreed on that point, Cliff. We've tried before with Server 2012 Essentials and it wasn't pretty. I have not since attempted to harden Server 2016 Essentials, but assume the same features would break.

More or less, my question is out here to solicit creative networking replies that I may not have considered. Seems like if I can just put the CC terminal on a VLAN, I'm left with the Public IP address issue. If there was a way to mask the public IP or use a free VPN at the firewall level... maybe they could skirt around it that way?

Also considering having them use a cc terminal that uses a POTS line and then possibly use an ATA. I suspect that may skirt around the compliance issue as well. Would be slower than LAN...

Customer is "penny wise - pound foolish" ...but, I'm trying to be sensitive and reasonable given the economic climate we're in. 
ASKER CERTIFIED SOLUTION
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Cliff, I'm looking at this as more of an academic question rather than an ethical conundrum. But, I don't disagree with your points. I really just wanted to know if there were other networking options I hadn't thought of. But, from a business model perspective, what I've taken away from this is that we need to add this query to our customer onboarding process - "are you using or planning on using credit card terminals on-site," especially when an "Essentials" option is on the table.  

We wound up segregating their POS system onto its own VLAN and Public IP. The customer finally relented and that was what we originally suggested. Just goes to show how handy a decent firewall can be for situations like this. Their Zyxel USG40 handled the whole process easily, even with the customer kicking and screaming.

Now that Microsoft has crippled Essentials and made it into a farcical pile or excrement, it's almost a moot issue for new builds, but I'm sure we'll see this come up again with customers that add CC terminals on their existing Essentials managed LANs.   

I don't disagree with your assessment of the dismantling of SBS to Essentials then to what is "Essentials" now. However I'd have the same concerns with having credit card processing on the same network as the rest of the company even if essentials weren't in the mix.

It is increasingly common to see compliance audit companies drop-ship their own custom Kali Linux "appliance" and audit the internal network that a credit card system is on, and  most Corp desktops would cause an audit flag.  Getting in the habit of segregating networks is a good habit to form, even when essentials isn't in the mix.  Essentials just causes that external scan to highlight what is actually a bigger problem.

There have been enough breaches that have made (inter)national news that the industry is seeing a lot of rapid change.  Being ahead of the curve can be a lucrative opportunity. Worth planning for that now instead of later. 
Just out of curiosity and slightly off-topic, what has your go-to implementation been for customers that are 25 or less, now that Essentials is essentially dead? Are you just going Standard 2019 and manually implementing a Remote Desktop Gateway?
I moved away from anywhere access even when essentials was still a thing.  For businesses that still want or need access to network resources, a company issued laptop with a VPN that supports 2FA is our preferred choice.  There is a lower risk of credential disclosure and the laptop can be better hardened.

That handles any file/print needs and eve most LOB apps.  In the rare cases where LOB apps need high speed connectivity to their back-end, we've been putting that in Azure so the front end and back end are both on the same Azure vnet (high speed) and publishing as a remote-app.  Connecting to Azure is done via site to site VPN so, again, RDS is never exposed as a public IP.  I'm sure there are random one-offs where we did something unusual, but the above has covered 99% of the various use cases we've seen.  It's cost effective, flexible, and the wealth of knowledge that can be tapped into for the odd edge case support issues is pretty vast. Well worth the time to retool one's offerings to meet new demands..

While we chose Azure because WVD was on the horizon, I've seen similar done ib AWS, rackspace, etc.  You aren't locked to a particular vendor to roll out similar solutions.