Security Console Best Practices

The Security Console and Scan Engine hardware requirements are different because the Security Console uses significantly more resources. See the hardware requirements page for further guidance.

We recommend higher performance drives, such as those that use solid state technology.

When opting for memory-based storage, the Rapid7 Support team can help review the Security Console tuning settings for your deployment.

Whenever possible, use a distributed Scan Engine. Rapid7 does not recommend relying on the local Scan Engine in most cases. If you intend to deploy a production scanning environment where the asset count is above 1,000 we highly recommend deploying distributed Scan Engines. The local Scan Engine included in the Security Console shares its resources with the application and the included PostgreSQL database. A distributed Scan Engine can reduce the chances of encountering resource contention with the Security Console.

Where Scan Engines are located has a different outcome depending on your goal.

• If you are trying to do a perimeter scan to see what is exposed to the internet, then a distributed Scan Engine outside of your network is recommended. It should be noted that it is not recommended to perform authenticated scans across the internet.
• If you want to remediate internal vulnerabilities, place the Scan Engine on the same side of the firewall, and ensure to allowlist communication from the Scan Engine to your target assets. This placement avoids having your Scan Engine network traffic navigate through perimeter firewalls, tar pits, and load balancers that may either significantly slow down your scans or block the scan entirely.

Network-based assessment becomes very challenging when the network is extended through technologies such as VPN. In addition to bandwidth constraints and users who may join and drop from the VPN throughout the day, each solution also has unique controls for network traffic that may need to be mitigated. Insight Agents are the most ideal solution for these environments, as they are not dependent on network connectivity via VPN to a Scan Engine.

One of the benefits of deploying Agents is that traditional scans rely on configured credentials in InsightVM in order to authenticate to the target asset, which yields more comprehensive vulnerability results. Because Insight Agents monitor the asset from within, their assessments are functionally authenticated already so that you do not have to configure credentials at all. Agent assets must have UDP port 31400 open so that the agent can respond to the Scan Engine during scanning. If this port is closed, the agent can not provide its UUID to the Scan Engine and the Security Console will not be able to use this information for correlation purposes.

By default, the Security Console retains all data in it forever, which can lead to decommissioned assets not being removed and too much disk space being used up. The following values are recommended as a starting point.

Adjust Data retention policies in Administration > Backup and Retention.

By default, the Security Console checks for product updates every 6 hours. This frequency means that the Security Console may reboot for an update in the middle of your work day. We recommend changing the product update frequency to 24 hours and the time to outside your work hours.

Adjust Security Console updates in Administration > Updates.

The default session timeout in InsightVM is 600 seconds (10 minutes). We recommend increasing the timeout to 1800 seconds (30 minutes) or 3600 seconds (1 hour), so that you don’t have to keep logging back in. If you have internal session timeout requirements, you can also adjust your InsightVM settings to match.

The Security Console comes with a default self-signed HTTPS certificate. Currently all administrative traffic to the Security Console is encrypted, but the traffic is not trusted by web browsers. We recommend generating a new certificate and having it signed by your internal Certificate Authority.

Adding a signed web server certificate can also help remove platform login errors between the cloud and Security Console. Ensure that the Subject Alternative Name (SAN) field is populated with the FQDN of your Security Console server.

The HTTPS certificate can be found under Administration > Web Server. See managing the Security Console for additional guidance.

For InsightVM customers, after improving the connection with an internally signed HTTPS certificate, we recommend that you enable Platform Login to connect your on-premise InsightVM account to your Insight Platform account. This ensures that you only need a single login to access all of your Rapid7 products. If you have an SSO provider, you can enable that on the Insight Platform for additional ease of user management.

Optionally, you can also change the default web server port from the default of 3780 to 443 if that is more convenient for your users.

The timeout settings can be found under Administration > Web Server. See managing the Security Console for additional guidance.

There are many ways to organize your sites. One method we recommend is to organize sites based on function or geographical region, for example, one site for “all stores” and one for “all corporate” ranges. Another example would be to break up the sites based on continents, or as large of a geographical region as possible such as “US-East”, “US-West”, and “EMEA”. Make sure that you have Scan Engines located as close to the devices you want to scan as possible for maximum visibility and reduced bandwidth concerns.

Having fewer sites with a larger scope will help reduce administrative overhead with scoping, scheduling, and allow for ease of scalability when scanning more devices. For granular reporting and access management, use asset groups, which are much more flexible than sites. You should have one Scan Engine per site so that your sites can be scanned at the same time without overloading a single Scan Engine. If you have some sites or locations that are much larger than others, you can deploy more engines to that location and pool them together for even greater scan efficiency.

While having fewer sites helps with having fewer scheduled scans, you should still be aware of which Scan Engine is being used for those sites. Running a scan uses up RAM on the Scan Engine, and having too many scans running at once can cause scan slowdowns or potentially Scan Engine crashes due to lack of memory.

Because running multiple reports and scans at once can also impact console server resources, you should stagger scans and reports whenever possible. This includes regularly reviewing scheduled jobs. Alternatively, usage of cloud reporting features can alleviate resource contention for the Security Console. These include Query Builder, Remediation Projects, and Dashboard Cards. If you have both InsightVM and InsightCloudSec, you can benefit from a shared view of risk across on-premises and cloud environments using the Executive Risk View and Remediation Hub.

You can also configure the Security Console to export data into an external Data Warehouse to obtain a richer data set for integration with your own internal reporting systems, such as Business Intelligence tools. The export performs an extract, transform, and load (ETL) process into the target warehouse using a dimensional model.

For higher efficiency, utilize Static Asset Groups and Tags instead of Dynamic Asset Groups (DAGs) or Dynamic Tags when possible. DAGs and Dynamic Tags are calculated after each and every scan or agent integration, which consumes resources. If you need to use Dynamic Asset Groups, use them strategically.

We recommend avoiding nested tags or circular references while using tags and Asset Groups, where several tags reference each other, leading to circular dependencies which can also cause database issues.

The more nested tags there are, the more operations the database needs to perform, leading to exponential performance hits and potentially causing Security Console slowdown or crashing. Tags could also be created with circular references. It is recommended to avoid any nested or circular tags to help reduce the database impact whenever any scans are performed or agents check in.

Scan templates configure parameters for scans. You can customize scan templates to fit your environmental needs. Please see our Scan Template best practices documentation for detailed recommendations.