Considering regular use cases of the solution, we wanted to cover two things, external vulnerabilities and the ability to identify misconfigurations on the perimeter, like, let's say, if someone is open, something vulnerable to outside, we monitor it. The use case was monitoring the external parameter addresses with Tenable.io and seeing changes there. If something changes or if something becomes vulnerable, as it's seen from the outside, without actual credentials to scan, you know, like, we can have several layers of scans. So, Tenable.io, we used as seen outside without providing any credentials, So it

gives you the true picture of how and what the attackers can use. It might be that if we use it with the credentials, we won't find additional vulnerabilities, but we don't cover that because it's not important because external attackers will not see it, actually. So, it's the first use case, and generally, Tenable.io is used for identifying vulnerabilities in the company infrastructure, servers, endpoints, and additional hardware and software, like routers, switches, and whatever has an IP address. Let's say, not for IoT, just for IT infrastructure and development infrastructure, and that was the use case of Tenable.io.

It improved basic things in resiliency, like cyber resiliency in the company, so as to not be attacked, not to be breached, or not be successfully attacked by hackers. So, it's basically a non-vulnerable state. This provided us with visibility of our actual status of where all the infrastructure is and helped to prioritize the vulnerability mitigation. It also indicates what to tackle first because you have a lot of stuff there, but you need to prioritize it. The main point here is to know how to prioritize since we never have enough time and resources to deal with fixing everything. You need to understand what to do first, and Tenable.io actually helps with that because they have additional intelligent sources to not just give you, like, CVSS because all the vulnerabilities have CVSS scores from zero to ten. So it gives you not just to always work by the score number because it just represents the vulnerability and how it can be hacked. But just take into account when you prioritize if it's a public-facing asset or computer or server or if not, or if this is now a trendy vulnerability to use and to exploit or not. Also, they have an additional score represented only in the system in addition to the CVSS score that helps you prioritize the mitigations.

The solution's most valuable feature is providing a single pane of visibility on all the infrastructure and its status. The aforementioned fact helps to prioritize things right and also to cover the mitigation process itself. However, what's bad about older systems, like, is when we do that, it just covers the identification. So, you have the problem and what you need to do, but it doesn't cover the whole cycle of dealing with it, and so you see the problem, you know what to do, maybe you know what to do first, But then the process needs to continue. I'm talking about a lot of negative things, but the fact remains that it doesn't cover, actually, the whole process of the identification and then the prioritization because we need to maybe open a ticket to deal with it by approaching the right people and to see that it's done, including the validation scans after it. The system gives you a way to do the scans somehow all around vulnerability and its status while not having to deal with the whole cycle. So you don't see, or you don't have this part when you mitigate the vulnerabilities themselves, and then you know what you did, what you didn't, and how you did, and which is status after it. So, it doesn't cover the whole vulnerability management process.

I would like the solution to cover the whole cycle of mitigation since it's an area where the solution currently lacks.

Nessus was created and, like, covered afterward. All the system is built around a basic unit that is mitigation, not the vulnerabilities. You don't have all the vulnerabilities where you build all the processes and all the reports that you have around it. Vulnerability is not like you have this problem. They say to you. Basically, you have a problem, but you don't have the patch. And the patch, inside of it, you have fifteen vulnerabilities, and it appears as a vulnerability. You are missing a patch, but it's not a vulnerability. All the system is built around missing mitigation. As a basic unit that everything is built around, and so this part is what you see when you do reports or when you build dashboards, and you have several databases inside that you can build reports around, but it's all beautiful, and you have a lot of reports, right, out of the box. But when you start creating something that you really need, like a new report, then you're, like, this data is in this database or downloaded database and this in another database of mitigations, and hence they cannot easily be connected, so each report can be all around this database because they have, like, two, three databases. I don't remember exactly, but they have separate databases inside, and you need to build the reports around one database, and it's not easy to connect two databases into one meaningful report. So, this is a hard part.

In short, I would like to see the databases seamlessly connected while doing a report.

The tool is okay, but, like I said, to cover the whole cycle and is like connecting the unconnectable things because they are built this way which I don't think they can change right now.

They can add things like brand reputation monitoring because it's the system that needs to identify all the vulnerabilities and infrastructure vulnerabilities. They can take it to add code vulnerabilities, like, if it's an R&D company that creates software, they have vulnerabilities of other types, like application-level vulnerabilities in the things that they are developing. And if it's a cloud, then it needs to be covered in a good way, considering the cloud infrastructure. Also, it works on the IP level. On the cloud, you can do it around EC2 instances. You can do the same in Tenable.io but then all the part of the cloud layer that is cloud-based but not on the EC2 level. Let's say it's CloudWatch logs and all the con configurations that are at a cloud provider level. So, there can be vulnerabilities there not at the EC2 level of the machine itself. So these are also vulnerabilities, and it can be good if they are shown and covered by the system.

In general, brand reputation and external CTI are needed in the solution.

Somewhere outside in the open world that it was bridged, and it's there, and then maybe we can show it to you also that it was bridged. So it's now in the open world, and they don't want to be, you know, to be the open world and also on the external attack surface, but I think we saw that some module that they are doing that is in just the right direction. So, it's a good direction.

I have been using Tenable.io Vulnerability Management for two years. I am just a customer of the solution. We used Tenable.io and then moved to Tenable.sc, which was on-premises.

Stability-wise, I rate the solution a four out of ten since there were problems with scans that were stuck and didn't work. Also, there was no nobody to talk to about the aforementioned issues. So, it was a problematic thing.

Scalability-wise, I rate the solution an eight out of ten.

We usually give it to maintain, run and configure everything we use to just two people to see the results. Each department has a user to see their problems by themselves. So it's like, apart from the two people, an additional ten or sixteen people use the solution, and these are people that are responsible for infrastructure management, like IT people at different places.

I rate the technical support around three to four out of ten. Sometimes, when we had problems, it was hard to get answers. The support was slow because it got to the wrong people at the start. So, the problems pass through tier one and then get escalated to the right people. So, it is very hard because some problems don't need just a tier one to solve the issue. So, tier three or four support may be needed at times.

Just installing it and keeping it running is pretty easy. However, support is very important. I think all the companies in the field lack some good support, specifically in my country.

I rate the initial setup a ten out of ten, but it's not important because afterward, when you have problems, and you want an additional initial setup, the integration needs to be done to just install it. It needs to integrate it with other systems and integrate it into processes. At this level, at least with Tenable.io, I didn't feel that they were doing that, and so I didn't just want to buy software and install it.

The solution is deployed on the cloud and on-prem. We chose some of the biggest three or four cloud providers, including Azure and Oracle.

It took two weeks to a month for the deployment process to be completed. It depends on where you want to deploy. To prepare the solution for work, you install it, then install the scanners, and later on configure the scanners. Also, you need to identify the ranges that you need to scan. If you have some problems with connections, etc., you solve them. Then, you need to do the actual work. Just actually use the system for mitigation, and you need to do the right reporting. Also, things like connecting to ticketing take more time just to install. We deployed the solution with around three to four people, including security engineers, the network team, and business owners of the places we wanted to scan.

The solution requires maintenance. We used two people for maintenance and for some stuff that didn't work or needed to be improved or to deal with scanners that had problems on this because of the configuration. For not-so-effective scans, we need to tune it because if you have a huge range and the scans are configured to scan everything, then it is stuck. So, you tune them to the right places and scan the right thing to take the right type of scan, and then tune this tool.

The system owner, the infrastructure that is responsible for it, was involved in the maintenance of the solution. So, it was from the same department.

With Tenable.sc, in comparison to Tenable.io, it was even easier to do the implementation because you don't need to do a lot of stuff.

I have experienced a return on investment using Tenable.io. It showed us what we did wrong in the process of building the vulnerability management program in our company. It also gave us an understanding, making it a good solution.

On a scale of one to ten, where one is no return on investment, and ten is a hundred percent return on investment, I rate the solution a seven.

On a scale of one to ten, where one is low, and ten is high price, I rate the pricing an eight. So, it is a pretty expensive solution.

After evaluation, we have switched from Tenable.io Vulnerability Management to Rapid7. We also looked at Tenable Attack Surface Management but didn't use its protection.

Before choosing Tenable.io, we evaluated Rapid7, Nexpose, and Qualys.

It is a viable solution, but we then preferred and switched to Rapid7 again since it was cheaper. Also, we like the one thing we like because we had, like, problems getting to all the user machines, and so Rapid7 gave us the agent that they have. So you don't need to get the scan to the machine. You just install these solutions. We install the agent that reports on vulnerabilities instead of getting credentials scanned. And today, it's more problematic because, like, it would take several years ago, like ten years ago, all the systems had the perimeter of the company, and all the users were in some understandable place, and we knew where to look for them. Today, as a company where people around the world are not always using VPNs to connect to the network, and if they connect, they connect for some time, and let's say you are scanning your user computers every night or every day at five o'clock. So when you do the scan, just ten percent of the people, you hit them because only ten percent of the people are connected to your VPN during the five o'clock window. So you don't see the other machines, and you don't get them. Hence, you don't know the vulnerability status because they are less scanned. The solution needs to be perimeter-less, let's say, or the scans we need to get to the machines to all the machines, and if you scan them somehow or even if they are on the open internet, it's hard. So here, the agent solution is very easy because they report to the management on the vulnerability status from the agent over the internet. It was a big plus.

In terms of pricing and capabilities and just of the capability, while also considering our use cases where it is most important for us to get to all the machines.

I rate the overall product a seven out of ten.