PCI Compliance and Open SQL ports
We have an ASP.NET site that we have written in house. It is basically a reporting suite that is hosted on a dedicated Windows server. When users use the site, requests are made to that client's SQL database, which is housed in their own shop. Their firewall has an open port to enable this to happen.
Obviously this is a security threat and is being picked up by the client's PCI scans as a fail.
The idea behind what we have done is so that we can change the report definitions in one place (i.e. on the Windows Server) and all our customers can benefit from that change instantly without having to wait for us to roll it out to them specifically.
With PCI compliance on the increase, we are just wondering what the 'better' way to achieve this sort of thing would be whilst still maintaining the flexibility we have currently. We have multiple customers all with different routers installed.
Obviously this is a security threat and is being picked up by the client's PCI scans as a fail.
The idea behind what we have done is so that we can change the report definitions in one place (i.e. on the Windows Server) and all our customers can benefit from that change instantly without having to wait for us to roll it out to them specifically.
With PCI compliance on the increase, we are just wondering what the 'better' way to achieve this sort of thing would be whilst still maintaining the flexibility we have currently. We have multiple customers all with different routers installed.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Besides the most obvious answer (put in a firewall that allows you to restrict access to ports based on ip), have you considered creating an administrative service (WCF or WebAPI) that you can connect to in order to push updates to the clients?
In this way, you wont have to have any ports open to the SQL database. You would want to use port 443 for SSL. You would want to configure it so that access would be restricted based on authentication. Bonus points given if your client implements a firewall to restrict access for whitlisted ip's.
Another possibility is to make your distributed ASP.NET site call home periodically and check for updates.
-saige-
In this way, you wont have to have any ports open to the SQL database. You would want to use port 443 for SSL. You would want to configure it so that access would be restricted based on authentication. Bonus points given if your client implements a firewall to restrict access for whitlisted ip's.
Another possibility is to make your distributed ASP.NET site call home periodically and check for updates.
-saige-
ASKER
Would the service need to be installed on each of the clients machines then? I presume it sits there waiting for requests from the Windows server? what is involved with getting that setup?
You wouldn't need to install anything (per se), consider it as an add-on to the current distributed ASP.NET site (you can almost think of it as a glorified web page).
As for what is involved in setting it up. A simple example is illustrated here: http:/Q_28701603.html
But there are many examples throughout the internet:
http://www.dotnetcurry.com/wcf/721/push-data-wcf-callback-service
http://adamprescott.net/2012/08/15/a-simple-wcf-service-callback-example/
http://www.codeproject.com/Articles/596287/Broadcasting-Events-with-a-Duplex-WCF-Service
And these are just WCF examples. There are also WebAPI examples.
-saige-
As for what is involved in setting it up. A simple example is illustrated here: http:/Q_28701603.html
But there are many examples throughout the internet:
http://www.dotnetcurry.com/wcf/721/push-data-wcf-callback-service
http://adamprescott.net/2012/08/15/a-simple-wcf-service-callback-example/
http://www.codeproject.com/Articles/596287/Broadcasting-Events-with-a-Duplex-WCF-Service
And these are just WCF examples. There are also WebAPI examples.
-saige-
ASKER
Thank you Saige. I understand about the service side - I have written a couple for other purposes. I'm just not sure I'm with you on it's implementation.
So client starts by browsing to the ASP site which is hosted on the Windows Server from their PC in the shop...* Then what, the ASP site, make a call to a service? where is that... on the Windows box also or on the shop PC?
Sorry - please excuse my ignorance.
* Ironically probably the same machine that the data is held on.
So client starts by browsing to the ASP site which is hosted on the Windows Server from their PC in the shop...* Then what, the ASP site, make a call to a service? where is that... on the Windows box also or on the shop PC?
Sorry - please excuse my ignorance.
* Ironically probably the same machine that the data is held on.
The client won't *have* to make the connection, unless you want them to do so. Instead your server would initiate the connection. The difference is that you would be using an HTTPs connection instead of an SQL connection.
-saige-
-saige-
ASKER
In the end, we tried using the Windows Firewall to block all traffic apart from certain IPs.
ASKER
We considered forcing them to buy a decent router, or perhaps to utilize the windows firewall if they were unwilling.
One of the parts of the PCI Compliance test (and I think this is more of question they want you to answer truthfully, as opposed to one of their penetration tests where they KNOW you are failing) is where they say that the data must be encrypted when leaving the building. Maybe we are getting worried over nothing and the Native Client provider does this anyway, but that was our additional concern.