We help IT Professionals succeed at work.

best location to connect Tenable vulnerability scanner & penetration scanner

sunhux
sunhux used Ask the Experts™
on
We're getting Nessus Tenable for vulnerability scans (likely with admin-credentialed scans)
& likely penetration tests.

Q1:
https://security.stackexchange.com/questions/71389/where-to-place-a-vulnerability-scanner-within-a-data-center
Above link has various views & I don't understand one of the line:
"If you're not granting the scanner admin level access to your assets and you're allowing an IPS to interfere then you're doing yourself a disservice."

Q2:
I intend to scan through the Network IPS because we may not be able to apply patches
in time (can't test out patches & obtain downtime in time), so most likely we'll deploy
NIPS virtual patches as interim remediation.  So do we still scan using 'admin credential'
scan in my scenario?

Q3:
Certainly dont plan to scan from public Internet but where is the best location within
our Prod network should we connect up this virtual (runs in VM) scanner?  Management
VLAN or in each Prod subnet, we place one scanner or run from laptop & connect to
a switch port which is assigned all the VLANs  or we just place in DMZ  or  internal
subnet & open up firewall rules?  Firewall may slow down the scans.

Q4:
From secure perspective, which is the most secure place to connect it as we may
use admin credentials (at this moment, no idea how to get it to integrate with
TPAM though we may move to CyberArk in 12-16 months' time as Nessus told
us it integrates with Cyberark, querying the password from Cyberark)
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2016

Commented:
between your firewall and your network is the best place.

Author

Commented:
Guess David suggest between external-facing firewall & our network IPS.

What are some of the firewall rules needed?  Thought of the following:
Tenable scanner/Console -> Fetch update from Tenable via Internet (ie patches)
Tenable scanner/Console -> Endpoint Agents (is there any updates to Tenable agents needed?)
Agent -> Scan servers, PCs, devices in the same subnet directly (by plugging in laptop running Tenable?)
Agent -> upload data  to console for reporting
Security Admins -> Access console
Distinguished Expert 2018

Commented:
Exactly which Tenable product are you getting? IO, or SC? I'm assuming SC, but you tell us.

I'd deploy inside the IPS to avoid causing an explosion in logs or the need to do a lot of exclusions. You'd probably also get a more complete picture.

Within the network itself, do you have firewalls? Or even restrictions between VLANs?

Author

Commented:
It's SC.

> Within the network itself, do you have firewalls?
We have 2-tier firewalls, one is external-facing & one is internal.
No further restrictions between VLANs
Exec Consultant
Distinguished Expert 2018
Commented:
1. How i read it is that scanner need to have a valid credential for authenticated scan and that account need to be of admin credentials or have the right to conduct such scan or equivalent. IPS and IDS is supposed to alert suspicious activity due to use of privileged account such as enumerating open network share services. Hence there can be lots of unnecessary noise which are all false positives. https://docs.tenable.com/nessus/Content/EnableWindowsLoginsForLocalAndRemoteAudits.htm
The most important aspect about Windows credentials is that the account used to perform the checks should have privileges to access all required files and registry entries, which in many cases means administrative privileges. If Nessus is not provided the credentials for an administrative account, at best it can be used to perform registry checks for the patches. While this is still a valid method to determine if a patch is installed, it is incompatible with some third party patch management tools that may neglect to set the key in the policy. If Nessus has administrative privileges, then it will actually check the version of the dynamic-link library (.dll) on the remote host, which is considerably more accurate.

 2. Ideal is on the need to basis and go by least privileged principal to allow authenticated scans. However, in Nessus term using Credentialed Checks, you need can still use a domain account, but that account must be a local administrator on the devices being scanned. Looks at the requirement for credential scans
https://community.tenable.com/s/article/Troubleshooting-Credential-scanning-on-Windows


3. Can take a look at the strategy below.  It is also important that you meet the recommenced Tenable.sc hardware requirements otherwise performance issues could result. https://docs.tenable.com/sccv/5_5/Content/Requirements.htm
Segmented Network
l If a network is behind a firewall or is VLAN separated, such as a DMZ, the Nessus Scanner may not be able to successfully scan its target.
l A Nessus Scanner should be placed in each network segment.
l Nessus requires port TCP/443 to communicate with Tenable.io and TCP/8834 for Tenable.sc.
l If a Nessus Scanner cannot be placed in the network segments, then firewall rules must be configured so the scanner can reach all intended target ports and protocols.
To reduce the scan duration of a large number of targets:
l Add additional scanners
l Pool scanners in a Scanner Group / Scan Zone
l Scan by network segment / VLAN
l Adjust scan policy performance settings
https://docs.tenable.com/other/nessus/Tenable_ProServ_Scan_Strategy_Guide.pdf

4. It should be on your trusted management LAN for each segment. For me there is a dedicated security segment which is monitored to make sure the security services does proper work and alert on deviated behavior detected. PSM can be within the mgmt segment and withe jumphost in the respective segment to the server so I would think we can leverage similarly on such for Nessus agent to the SC.

Overall, below are best practice
With traditional network scans, never scan through or try to bypass devices such as firewalls, switches, etc., that are designed to obfuscate or impede scans (for example, network address translation).

Either put Nessus scanners in every segment, closest to the host, or run agents locally on the system, which does not require explicitly making an overage of firewall rules. Both solutions require minimal firewall rules to provide connectivity when implemented correctly.

For full visibility into your network, it is recommended that you combine agent-based and traditional scanning to identify risk across your entire network. This approach is especially important if your organizations has specific policy that mandate you evaluate the entire spectrum of your risk.