We use it for internal and external vulnerability scans.
We use it for internal and external vulnerability scans.
Instead of just looking at high, medium or low risk for vulnerabilities, and having to remediate all of them, we can remediate in a more effective manner. We have limited resources for remediation work and we want to spend our time on the most critical issues.
It helps us focus resources on the vulnerabilities that are most likely to be exploited. It gives a higher VPR number where the things are more likely to be exploited, instead of just using the pure severity rating as a way to prioritize and decide to remediate.
The most valuable feature is the breadth of vulnerabilities that it finds. It's able to find across a lot of different platforms and operating systems. It's also able to combine local testing with network-based testing.
When it comes to vulnerability prioritization, Tenable's predictive features are off to a great start. It's definitely giving us more data to help prioritize, instead of just relying on straight CVSS. The vulnerability priority rating has been accurate and is helping us prioritize effectively, based on risk or based on the likelihood of being exploited. Based on what they say, and comparing it to what we are seeing with malware exploits, their predictions are lining up with what we are seeing being exploited.
There is room for improvement in finishing the transition to the cloud. We'd like to see them keep on improving the Tenable.io product, so that we can migrate to it entirely, instead of having to keep the Tenable.sc on-prem product.
There is also room for improvement in some of the reporting and the role-based access. They have a pretty defined roadmap. They know where the gaps are, but it's a totally different product and so there's a lot of work that they have to do to get it to match.
I have been using Nessus for three years at my current company.
We monitor Windows, Linux, Mac, workstations, servers, and cloud resources.
It's very stable. We haven't had any issues. There has been no database corruption or anything like that. All we've had to do to the main Security Center is give it more disk space to save more data. That's it.
The scalability is okay. We would definitely run into issues if we wanted to save a longer history of the data. It would be terabytes and terabytes of data. But in terms of at least keeping all the data for all the assets that we have, it's good. We're good enough with the retention. It meets our requirements.
The issues would be storage and being able to search across it. If we needed to save five years of scan history, it would be operationally difficult to use all the data that would be saved. But it's not problematic to look at the current data or trends for the past six months. Stuff like that is fine.
We're at about 20,000 hosts and it's pretty stable. I don't think we're going to do a big increase.
Tenable's technical support is good, except for things that involve some of the custom development work that we've done using their API. Early on, that was problematic, but they've gotten better and released more API documentation and sample code, and that was fine.
It was nothing that was wrong with the product itself, but tech support is more designed for normal user interactions with the product, not doing development against the API. The problem with my code was because some documentation wasn't clear or there wasn't a sample for how to do this. That's where it was a little bit tougher. The normal, user function stuff was totally fine. It was really the developer-focused side.
We were on Rapid7. We switched because of scalability and performance.
We were looking for a solution that could handle and scan our volume of assets. It wasn't working with our previous solution. Nessus has scalability. Being able to scan in time and actually being able to report on that data were things we couldn't do with our old solution.
Also, the level of visibility that Tenable provides is much better than Rapid7 because we're able to actually see all of the data that was collected and we're able to scan for vulnerabilities and config issues and pull all the data together. We were having real trouble with that before.
The initial setup was straightforward. We were easily able to set up scan policies, asset groups, scan schedules, and start collecting data very quickly.
It wasn't complicated to define what we wanted to scan. It wasn't complicated to set up the credentialed scans, or to set up the different credentials for the different policies and different types of machines. Everything that that goes into building a scan policy was straightforward and we were able to get all of our assets scanned pretty quickly. Within 45 days of buying, we had good data and had done multiple scans already with all of our assets.
Our implementation strategy was that we wanted to set up credentialed scans for all of our machines as quickly as possible. We were working towards that and trying to get the coverage in Tenable as soon as possible.
We did it ourselves.
We are fulfilling our goals and able to deliver on the requirements that we have. It's hard for security to be a real ROI. We need to do vulnerability scanning, we need to know where the issues are and we need to be able to fix them. It is doing that.
Our licensing is on a yearly basis but we did a three-year deal. It is a fixed cost to cover a certain number of hosts or assets. There are no additional costs to the standard licensing fees.
Leverage authenticated scans if you can. That reduces the number of false positives compared to just network-based scanning. Leverage the Tenable Agents if you can, as well, because that will help reduce the scan time and make it easier to get data from machines that are all over your network.
The solution isn't really helping to reduce our exposure over time because there are always new vulnerabilities coming out. It's helping us keep track of what's out there better.
The next part is going to be convincing external auditors that VPR is a reasonable way to actually prioritize, in terms of whatever our policy statements say for what we fix and how quickly; to get that to line up. A lot of people are still in the, "You must patch criticals with this number of days, highs with this number of days." We want to be able to turn that into a more risk-based approach but haven't really been able to do that.
The users of the solution in our organization are really just the people on our security team, so the number is under ten people. They're really just using it to look at the vulnerabilities, analyze the vulnerabilities, and figure out where our risks are and what should get patched. For deployment and maintenance of the solution we have a quarter of an FTE.