4

I am trying to design yearly program to scan for vulnerabilities on a very large network of payment terminals.

The company has thousands of retail points all around the world which need to be scanned for vulnerabilities. More specifically, we need to scan the credit card payment systems according to PCI DSS. While the terminals’ technology is somewhat standardized, there are firewalls in between, strong security policies and the systems might differ from country to country. The sites are connected to the servers mostly via ADSL, but some use phone and satellite.

The challenge is to identify cost-efficient alternatives for the scanning this massive network regularly. Any ideas? I would appreciate the input, specially out-of-the-box. Please keep it on the conceptual level.

Thanks!

Arthur
  • 41
  • 2
  • It's rather difficult to tell what you're looking for here. Questions about the logistics of communicating with all of those devices are off-topic here, since they're about networking rather than security. If you're asking for ways to actually test the security of the devices *once you've managed to talk to them*, I think we need a clearer scope - it's the kind of thing that one could write a book about. If you're looking at the managerial aspects of this, e.g. vulnerability management, you need to give us some more information about the scope and scenario you're looking at. – Polynomial Oct 30 '12 at 15:12
  • 1
    Since you're new around these parts, please familiarise yourself with the [FAQ](http://security.stackexchange.com/faq) - we have some requirements for question content on StackExchange. – Polynomial Oct 30 '12 at 15:14
  • A clarification: • The scanning concerns requirement 11.2.1 of PCI DSS regarding quarterly INTERNAL vulnerability scanning. – Arthur Nov 02 '12 at 17:34
  • Option 1. We are considering the option of setting up some sort of central workstation to make the vulnerability scanning remotely for all sites. Since this doesn’t seem to be a standard solution, we are hitting all sort of procedural complications. I am wondering if you guys have some idea on how to setup such scanning without compromising the network security (i.e. if we open the firewall, then we run the risk of someone else trying to get in). – Arthur Nov 02 '12 at 17:35
  • Option 2. On the other hand, we are now talking about on-site solutions which are easier to find on the market. Like Scott said, having dedicated hardware or installing the scanning tool in the information system of the retail site. Here we also have risks of machines stolen or that precious information of internal network being compromised. For this option we would need to find a very reliable provider of hardware and/or software and that can be easily scalable for global operations. Any suggestions? Besides Nessus, which other vulnerability scanners have the best reputation? – Arthur Nov 02 '12 at 17:36

1 Answers1

8

In the strictest sense the safest thing to do is to, of course, enter image description here

As you've no doubt found this can be difficult in a distributed environment. The specific vulnerability scanning tool you use can also add in some problems. Take Nessus for example. When building a scan profile there is an option called, "Check for PCI-DSS compliance." This makes a bunch of internal changes to the scan profile to meet the muster they've defined. However, this also requires there be no network protections between the scanner and the device. So no firewalls, no IDPs, hell they don't even want any routers involved.

Going back to the conceptual level, keep these kinds of problems in mind as you're building out your infrastructure. Here are the design features that I would start with, presented as a bulleted list in no particular order.

  • Remote scanner housed at each site
  • Centralized system to pull reports from all remote scanners for processing
  • Vulnerability management process to
    • Review reports
    • Analyze results for false/true positives
    • Define actionable items
    • Prioritize items
    • Determine remediation/mitigation paths for each items

So yes, this type of a program comprises both technical and procedural aspects that must work in tandem. Additionally, the process for reviewing and handling the reports must include representatives from all involved units. Primarily whomever is involved in managing the endpoints, the terminals, servers, etc. May also include the groups responsible for managing the networking, internal customers outside of IT who actually use the system, or others as fit within your environment.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
  • 1
    *"However, this also requires there be no network protections between the scanner and the device. So no firewalls, no IDPs, hell they don't even want any routers involved."* - It's mildly amusing that the conditions required for performing such a scan remotely automatically negate the possibility of being PCI compliant. – Polynomial Oct 30 '12 at 15:39
  • I'm not sure why routers in general would be a problem, except for NAT. But then, I'm not much familiar with Nessus. I can say, based on my experience, that full and effective vulnerability scans are much easier to do with less networking equipment between the scanner and its target. And, the scanners I've used do require certain firewall ports to be open in order to perform most checks - especially of the sort I'd expect in a PCI/DSS scan. – Iszi Oct 30 '12 at 15:54
  • @Polynomial: There may or may not have been a look passed between us after that question to support. – Scott Pack Oct 30 '12 at 16:23
  • 4
    And remember **Protect the Scanners** - they will have interesting information on them! – Rory Alsop Oct 30 '12 at 16:29
  • @Iszi Routers drop most malformed packets. A proper security scan involves a lot of those kinds of packets. The point is that your critical systems have to remain stable even if the attacker can send packets from within your network. – Polynomial Oct 30 '12 at 16:29
  • @RoryAlsop Not to mention that they'll be discoverable by an FOIA request during any civil suits. Do you _really_ want your old vulnerability scan logs becoming part of evidence if you get sued after a breach? Maintain evidence that a scan took place, and keep the reports, but ditch the detailed scan logs. – Polynomial Oct 30 '12 at 16:31
  • @Polynomial: Depending on your jurisdiction you may be able to make a compelling argument for redaction of those logs, or maybe even the results themselves. – Scott Pack Oct 30 '12 at 16:32
  • @RoryAlsop: This is definitely a true statement. That itself can be tricksome too. I've seen situations where host-firewalls blocked replies to scan probes. – Scott Pack Oct 30 '12 at 16:37
  • @RoryAlsop: +1 on protecting the scanners - not only against data theft but also against other kinds of compromise, including guessing date/time of the scan and installing rootkits on one of the remote scanners. – Deer Hunter Oct 30 '12 at 20:00
  • @DeerHunter: Truth. One sure way to guarantee a bad day is to have your vulnerability scanner, often with Domain Admin creds and blanket access to all computers on the network, compromised. – Scott Pack Oct 30 '12 at 20:07