Security Console Best Practices
To help you be successful with the Security Console and its improvements and updates, we have provided the following recommendations.
System Requirements
When considering the system requirements for the Security Console, it is beneficial to plan for future growth instead of only the current environment. Configure the server resources for the Security Console at the higher end of system requirements whenever possible to ensure that your Security Console server is more resilient as your vulnerability program scales.
Differences in Hardware System Requirements
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.
If you intend to deploy to a virtual machine, ensure that you provision the virtual machine with sufficient reserved memory according to the system requirements. The reserved memory value must match the allocated memory. For example, if you've allocated 32GB, set the reserved memory to 32GB. Configuring a virtual machine with shared memory may cause negative performance impact including out of memory events.
Server Storage Options
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.
Network Communication
The Security Console requires communication with the Rapid7update server to receive product updates and vulnerability content:updates.rapid7.comover TCP port 443.
Additionally, you must configure communication with the Command Platform (Insight Platform) to send and receive vulnerability findings.
To ensure uninterrupted communication, read our documentation on allowlisting the Rapid7 Servers:
Add all required network addresses on firewalls and endpoint protection to the allowlist. Also, we recommend checking to confirm if there is any SSL/TLS packet inspection occurring as this can interfere with connectivity to the Platform and product updates if not appropriately allowlisted.
Communication with Target Assets
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.
Scan Engine Location
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.
Rapid7 Agent
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. Rapid7 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 Vulnerability Management (InsightVM) in order to authenticate to the target asset, which yields more comprehensive vulnerability results. Because Rapid7 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.
Adjust Administration Settings
There are several Vulnerability Management (InsightVM) settings that can be optimized out of the box for increased Security Console performance.
Adjust data retention
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.
| Data Type | Retention Period | Details |
|---|---|---|
| Scan data | 12 months | If you have any legal or audit requirements for keeping scan data, such as for PCI, scan data retention can be adjusted. If you have over 50,000 assets and you need to keep scan data longer, use the Vulnerability Management (InsightVM) Data Warehouse functionality to export the data to the warehouse database, and set the retention in the console to 3 months for better console efficiency. |
| Report data | 6 months | Some reports can get quite large, so periodically removing older historical reports can help clean up the console storage, especially if you email out the reports and store them off of the Security Console. |
| Asset data | 30 days | The asset data retention uses the last scan date of your devices to remove assets that have not been scanned in a while. We recommend running weekly network based scans against your network to help the Rapid7 Agent (Insight Agent) more efficiently determine which data should be retained. With weekly scans, if a device has missed 4 scan cycles, it very likely doesn't exist anymore. If the device has an Rapid7 Agent (Insight Agent) installed on it, the last scan date will be updated whenever the agent checks in as well. |
| Agent data | 30 days | The default data retention policy for agents on the Command Platform (Insight Platform) is 30 days, so we recommend you also set the agent retention policy to 30 days in the Vulnerability Management (InsightVM) console. You can lower Security Console data retention as needed, such as when needing to remove duplicate agent results from the Security Console. |
Adjust Data retention policies in Administration > Vulnerability Management > Backup and Retention.
Change Security Console Update Frequency
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 > Vulnerability Management > Console Administration > Updates.
Increase Session Timeout
The default session timeout in Vulnerability Management (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 Vulnerability Management (InsightVM) settings to match.
Update the Console HTTPS Certificate
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 > Vulnerability Management > Console Administration > Web Server. See managing the Security Console for additional guidance.
Utilize Platform Login
For Vulnerability Management (InsightVM) customers, after improving the connection with an internally signed HTTPS certificate, we recommend that you enable Platform Login to connect your on-premise Vulnerability Management (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 > Vulnerability Management > Console Administration > Web Server. See managing the Security Console for additional guidance.
Protect your private keys
By default, private keys are stored in a keystore file that is encrypted with a passphrase. Keystore files are stored on a file system that doesn't have any extra security protection unless you choose to implement it. Private keys are stored this way so that server applications can use them with minimal friction – in other words, they eliminate the need for a user to enter a password manually every time the Security Console restarts. This method of private key storage also simplifies monitoring, because the monitoring process targets only a small number of files.
Monitoring can be directed at individual keystore files, including nscweb.ks, which is created during the configuration of aCA-signed HTTPS certificate.
Thensc.ks keystore file is located by default in the keystores directory (for example, at /opt/rapid7/nexpose/nsc/keystores), and contains the private key that is used to decrypt scan credentials in the database and identify the Security Console with distributed or remote scan engines. The file also contains the private key used for the web interface, however this can be overwritten by creating a custom private key - to do so, follow the steps to use ause a CA-signed certificate.
The keystore file is encrypted and the encryption key is stored in the creds.kspw file in the /opt/rapid7/nexpose/shared/conf directory. To ensure these private keys are kept secure, you can optionally undertake these measures:
Some environments do not have any encrypted credentials in the database that a private key in the keystore is used to decrypt. For example, environments that:
- Only use the Rapid7 Agent
- Don't have authenticated scans configured
- Don't use Discovery connections
However, the keystore still contains the private key for the web interface (if you didn't create a custom private key to use a CA-signed certificate), so extra security measures are advised.
The keystore file is included in backups and could be used to decrypt credentials if:
The creds.kspw file is obtained by an attacker.
The attacker successfully figures out the password without access to the creds.kspw file, which can be mitigated by using a long password or passphrase.
Therefore, it is important that you treat backups as sensitive, since they not only contain the keystore file, but all of your environment data.
By contrast, the
creds.kspwfile is not stored in a backup and you must note the password to your private key, as advised in thePre-Backup and Restore Checklist.Reducing expensive calculations and administrative overhead
You can reduce expensive calculations and administrative overhead by organizing sites, ensuring you are efficiently running reports and pulling data, and asset tagging.
Asset Tagging
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.
Optimize scan templates
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.
Configuring Shared Credentials (Authentication)
For best results it is critical that credentials are granted with root/administrator level access to fully and properly assess assets.
There is a difference between credentials and permissions. Credentials are typically username/password login that allows us to authenticate to a server or workstation. Permissions or Elevated Permissions are what control what we can "access" on the server. In order to properly assess an asset we need root/administrator level permissions.
- Authentication best practices on Unix assets
- Elevating permissions
- Authentication best practices on Windows assets
Configuring a service account with the right level of permissions can be time consuming, Rapid7 offers multiple solutions for credential concerns:
- Rapid7Agents : Agents are installed on each endpoint and assessment occurs automatically every 6 hours, collected results are sent to the Vulnerability Management (InsightVM) platform, and then sent down to the Vulnerability Management(InsightVM) Security Console. Agents cannot perform unauthenticated (remote) vulnerability assessments. For the most accurate view of your environment, we recommend using Agent assessments for authenticated (local) assets and unauthenticated engine scans for unauthenticated (remote) assets. Seescan capability comparison for more information on the functionality provided by the Agent and Scan Engine.
- Scan Assistant: The Scan Assistant achieves the same results as a credential scan without the need for administrative credential management and provides accurate, granular vulnerability fingerprinting and assessment for assets. The Scan Assistant allows the Scan Engine to connect directly to an endpoint in order to collect data without the need for additional credentials. A secure connection is created between the Scan Engine and the Scan Assistant by using elliptic curve asymmetric encryption (ECDSA) and advanced encryption standard (AES).
Updating the Security Console
Vulnerability Management (InsightVM) product updates are usually weekly on Monday. To stay on the latest version, make sure the automatic updates are enabled, and follow the update frequency guidance mentioned above. If the Security Console does not update you may want to restart before contacting Rapid7 Support for assistance.
The Vulnerability Management (InsightVM) content updates include new or modified vulnerabilities. Content updates are checked every two hours and don't require a system reboot.
Make sure your Scan Engines are properly updated. As long as the Scan Engine has enough storage space and can reach the Vulnerability Management (InsightVM) Security Console, it should automatically update whenever it is not running a scan.
Unless you are on a Rapid7 hosted Security Console, you are also responsible for updating the underlying operating system, including applying the latest security patch and ensuring the OS version itself is still supported. This ensures you continue to receive the latest Vulnerability Management (InsightVM) versions.
Ensure you're running the latest version of the Vulnerability Management(InsightVM)PostgreSQL database. Running an older version can cause some potential issues with the database as well as general slowdown for the console and reports.
Vulnerability Management (InsightVM) Database Maintenance
Vulnerability Management (InsightVM) includes a PostgreSQL database, to ensure optimal performance it will automatically run Auto-Vacuum. You can learn more about Auto-Vacuum on the PostgreSQL page at https://www.postgresql.org/docs/15/routine-vacuuming.html .
If you have an environment with over 50,000 assets that also has a lot of frequent changes, such as adding or removing large numbers of assets, and are noticing slower console performance, you should consider running a manual database maintenance quarterly; frequency can be lowered as performance issues are resolved.
In Administration under the Database header, click Maintenance > Run Manual Maintenance. This executes a "Vacuum Full Analyze" on the PostgreSQL database.
Tune the PostgreSQL Database
Vulnerability Management (InsightVM) has a feature called Tune Assistant that performs database auto tuning such as automatically tuning based on the amount of RAM on the Security Console server. The database will be automatically tuned upon install, but if you increase the Security Console resources after install, you will want to manually run the auto tune.
To activate it, go to Administration > Vulnerability Management > Run and then run the command "tune assistant" to view how the database will be tuned, and then run "tune assistant apply". The tune will then be applied upon the next system reboot. This will have a greater impact if you have 64GB RAM or above.
You can also reviewthis additional guidance on tuning the PostgreSQL database for more details. We recommend contactingRapid7 Support for assistance with tuning PostgreSQL if you are utilizing memory based storage (SSD, NVMe) or if you are assessing over 75,000 assets in your environment.