Last updated at Thu, 16 May 2024 14:35:46 GMT
Over the years, our recommendations and best practices for the InsightVM console have changed with the improvements and updates we’ve made to the system. Here are some of the most common improvements to get the most out of your InsightVM console.
Adjust Administration Settings
There are a few InsightVM settings that can be optimized out of the box for a better experience.
Adjust Data retention
By default, the InsightVM console keeps all data in it forever. This 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.
Scan data retained for 12 months:
If you have any legal or audit requirements for keeping scan data, such as for PCI, this can be adjusted. If you have >50,000 IPs and you need to keep scan data longer, it is recommended you use the 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 retained for 6 months:
Some reports can get quite large, so periodically removing older historical reports can help clean up the console storage, especially if you’re emailing out the reports and storing them off of the console.
Asset data retained for 30 days:
The asset data retention uses the last scan date of your devices to remove devices that have not been scanned in a while. It is recommended that you run weekly network based scans against your network. With weekly scans, if a device has missed 4 scan cycles, it very likely doesn’t exist anymore. If the device has an Insight Agent installed on it, the last scan date will be updated whenever the agent checks in as well.
Agent data retained for 30 days:
The default data retention policy for agents on the Insight Platform is 30 days, so it is recommended you match that in the InsightVM console.
Data retention can be adjusted in Administration -> Maintenance, Backup and Retention
Change Console Update Frequency
By default, the InsightVM console is checking for updates every 6 hours. This could mean that the console reboots for an update in the middle of your work day. It is recommended to change the update frequency to 24 hours and the time to outside your work hours.
The Console updates can be adjusted in Administration -> Updates
Session Timeout and Console HTTPS Certificate
The default session timeout in InsightVM is 600 seconds, or 10 minutes. It is recommended to increase this to 1800 for 30 minutes or 3600 for 1 hour so you don’t have to keep logging back in to the console. If you have some internal session timeout requirements, you can also adjust it to match those.
The console comes with a default self signed HTTPS certificate. Currently all administrative traffic to the InsightVM console is encrypted, but the traffic is not trusted by web browsers. It is recommended to generate a new certificate and have it signed by your internal Certificate Authority. Adding a signed web server certificate can also help remove platform login errors between the cloud and the on-premise console. Be sure that the Subject Alternative Name (SAN) field is populated with the FQDN of your security console server.
After improving the console connection with an internally signed HTTPS certificate, it is recommended that you enable platform login to link your on-premise InsightVM account with your Insight Platform account. This will make it so 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 will be more convenient for your users.
The timeout and HTTPS certificate can be found under Administration -> Web Server
https://docs.rapid7.com/insightvm/managing-the-security-console
https://docs.rapid7.com/insightvm/enable-insightvm-platform-login https://docs.rapid7.com/insight/single-sign-on
Optimize scan templates
The default Full Audit Without Web Spider scan template is good for some initial scanning, but it can be adjusted to speed up your scans and improve overall scan accuracy. If all of your scan engines have the same resources, you can get away with only one optimized scan template, reducing potential confusion and further simplifying your scan configurations. My colleague Landon Dalke wrote a great blog post documenting the best practices for your scan templates. Here are a few highlights from his post:
Assets scanned simultaneously per scan engine
Please use the following table for reference depending on how much CPU and RAM your scan engines have. Make sure your engines have a 1:4 ratio of CPU to memory for the best performance. Also, if your scan engines are virtual, make sure to reserve the allocated memory to avoid insufficient memory issues.
Send UDP packets to ports
We recommend disabling it. It’s unlikely a device will be reachable that doesn’t respond to ICMP, ARP, or TCP but is somehow found only using UDP.
Do not treat TCP reset responses as live assets
We recommend enabling it. This will help prevent “ghost assets” with no hostname or operating system from appearing, as some routers or IDS/IPS send TCP reset responses.
Nmap Services Detection
We recommend disabling this, as it can cause scans to take 5-10 times longer to run. Having a credential or agent on a device gives the same information.
Timeout Interval
The Timeout Interval can be adjusted depending on the bandwidth in your environment to speed up asset discovery and port scanning. If you are scanning low bandwidth environments or offices across the world from one scan engine, it is recommended you leave these settings alone. If you have fast networks and engines placed close to the devices being scanned, the following values can be used:
Initial Timeout interval: 200ms
Minimum Timeout interval: 200ms
Maximum Timeout interval: 500ms
Skip checks performed by the Insight Agent
We recommend enabling it. If the agent is detected on a device, it will skip the vulnerability checks the agent is already performing, reducing scan time.
Store invulnerable results
We recommend disabling it. In the scan logs, when this setting is enabled, it will tell you if a vulnerability is not vulnerable on a target host. PCI has an audit requirement where you need the explicit negative for the vulnerability on a target host. If you do not need to be PCI compliant, or have not had a PCI auditor ask for this level of detail, internal testing revealed disabling this setting caused scans to run ~50% faster with ~70% less disk space used.
Update the Console
For InsightVM product updates, the typical release schedule is weekly on Wednesday, with the occasional out-of-band update. To stay on the latest version, make sure the automatic updates are enabled, and follow the update frequency guidance mentioned above.
The InsightVM content updates include new or modified vulnerabilities. This is checked every two hours and doesn't require a system reboot.
Make sure your scan engines are properly updated as well. As long as the scan engine has enough storage space and can reach the InsightVM console, it should automatically update whenever it is not running a scan.
Unless you are on a Rapid7 hosted console, you are also in charge of updating the underlying operating system. Not just applying the latest security patch, but making sure the OS version itself is not end of life. This will ensure continued support of the latest InsightVM versions.
Lastly, you want to make sure you’re running the latest version of the InsightVM PostgreSQL database. If you are still running an older version, this can cause some potential issues with the database as well as general slowdown for the console and reports.
https://docs.rapid7.com/insightvm/postgresql-database-migration-guide/
Tune the PostgreSQL Database
InsightVM has a database auto tune feature which automatically tunes based on the amount of RAM on the console server. The database will be automatically tuned upon install, but if you increase the console resources after install, you will want to manually run the auto tune. To activate it, go to Administration -> 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.
Check out this doc on tuning the PostgreSQL database for more detail. If you don’t feel comfortable tuning your own database, you can always contact Rapid7 support for assistance.
Scan and Site Cleanup
Before October 2020, the discovery portion of the scan would only hit 1024 assets simultaneously. Now, we are running discovery against 65,535 IPs at once. This leads to much faster discovery of larger IP ranges. Because of this, we recommended having fewer sites and using larger IP scopes, such as /16, /12, or /8 CIDR ranges.
The best way to organize these new, larger sites is based around function or geographical region. For example, having a separate 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. Make sure that you have engines placed 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 micromanagement 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.
Besides having too many sites, the next largest problem most consoles face is when scans overlap on the same scan engine. Having fewer sites helps with having fewer scheduled scans, but you should still be aware what 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 slowdown or potentially engine crashes due to lack of memory.
Aim to have one scan engine per site. That way, your sites can be scanned at the same time without them overloading a single 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.
If you’re scanning more than 2,000 devices or have a segmented network, you should not be using the local scan engine as that is running on the console server, taking away resources from the web server and PostgreSQL database.
https://www.rapid7.com/blog/post/2023/12/04/method-to-an-old-consultants-madness-with-site-design
After following these steps, your console should be in a much better place to reduce micromanagement and improve overall efficiency. If you need continued assistance, don’t hesitate to reach out to Rapid7 Support or your Customer Success Manager.
