Anyone Else using BI and get hit with a PCI compliance failure recently?
Been using BI for 2 years now, and PCI compliance network scans for 9 months.

Latest network scan came up with cross-site scripting and jQuery vulnerable

I don't think that BI advertised it is compliant.

Must every machine on your network meet those specs?

I suggest you secure the Blue Iris web server better. Perhaps put it behind an HTTPS reverse-proxy server that requires HTTP digest authentication. (I'm guessing that would be sufficient to pass the PCI compliance testing)

Even better, don't forward a port to Blue Iris at all, and run an OpenVPN server instead for your remote access.

I'm assuming the OP's org is running a scanner on then LAN and detecting all connected computers.

jonbellagio wrote: ↑Mon Sep 23, 2019 5:56 pm Anyone Else using BI and get hit with a PCI compliance failure recently?
Been using BI for 2 years now, and PCI compliance network scans for 9 months.

Latest network scan came up with cross-site scripting and jQuery vulnerable

For a BI system to come anywhere near Credit Card Payments you are seriously in the wrong game. PCI compliance goes well beyond a network scan.

I get you want to beef up security, here are the challenges, and way to resolve them;
- The BI web server does not support HTTPS
- You can bind BI WEB to listen on local loopback only. (Make sure it isn't listening on any active network interface)
- You can install a decent Reverse Proxy Server and restrict to TLS 1.2+ Only, re-directing traffic to BI port
For this task, STUNNEL can be used and performs quite well, but you have to modify the config to use TLS 1.2 only and configure to use strong ciphers. (Note: By default STUNNEL config uses weak ciphers and vulnerable TSL), so will fail an audit.
(Technically SSL offloading is not permitted in PCI, but in this setup the offloading won't be detected by the scan and you are not handling credit card payments.)
- You should also have a decent firewall
- Harden the OS
- Ideally you need a separate reverse proxy on different hardware performing authentication (but again to comply with PCI, it's not permitted to perform SSL offloading or inspection, so just provides another layer of abstraction). Your home router (port forwarding) can perform this (without authentication), as long as the IP is not in a DMZ you should pass a remote and local PCI scan,

From a technical perspective, PCI Compliance is about keeping things separate and providing the least amount of access to the fewest pieces of equipment as possible while still being able to function (least privilege security model) all while being able to track what's happening. That means that your Video Surveillance shouldn't be on the same network as your CDE. Even if you pass all scans, if you get audited or in the event of a breach you aren't actually in compliance. Try creating VLANs and segmenting that way. Normally for our clients that fall under PCI or HIPAA we create a minimum of 4 different VLANs:

One for General Business Use (Office use that doesn't handle sensitive data.)
One for PCI (or HIPPAA) use
One for Surveillance and Access Control
One for Public Use

This separates everything out. Each VLAN has its own subnet and then you route between the subnets for shared devices like printers.

That being said, it's still a good idea to run the scans on all of the subnets just to make sure everything is patched up and all known exploits and security holes are patched up.