We use it to scan both our workstations and servers for vulnerabilities. This includes vulnerabilities related to software, operating systems, and package vulnerabilities. It helps us gain an overview of our organization's security status, which in turn guides our patching strategies and decision-making.
We use agents for scanning and authenticated logins, but we do not utilize the scanner part that performs web scanning.
We've got better insights into our vulnerabilities and weaknesses. This has led us to a better situation where we have better control. Our ability to manage the situation has improved.
Previously, we lacked a good overview, but now we possess detailed reports. We generate these reports internally and disseminate them to other responsible teams. Now, we have made it a part of our daily workflow and it helps us monitor vulnerabilities and related matters. It aids us in pinpointing weaknesses and facilitates more effective updates. If something slips, it becomes visible.
However, this is a significant feature, although it could potentially offer even more assistance.
The scanning part, the agent part – that's the valuable aspect. The agent and plugin components function reasonably well. But setting up scans, those tasks are working decently.
There are some logical elements that require consideration to understand their functionality, but they perform their function.
Certain aspects require effort. The solution's built-in reporting components are somewhat clumsy. So, this is an area of improvement.
Therefore, we export data and integrate it with our other reporting tools - the Elastic Stack, also known as Elasticsearch. We find it more comfortable to generate reports from Elasticsearch because we're well-versed in creating those dashboards there. It's more convenient for us to extract and integrate information in the same manner.
We've been in discussions with Tenable regarding a specific enhancement. It is a concept known as VPR, which stands for Vulnerability Priority Rating. This is related to the CVSS (Common Vulnerability Scoring System) value, which rates vulnerabilities on a scale from one to ten. However, the CVSS alone doesn't accurately determine the severity of a vulnerability; it doesn't indicate how exploitable it is. The VPR takes into account additional factors, such as how widely the vulnerability is being exploited in the wild and the volume of reports from affected sites.
And if we want to have it on our dashboard, this is something that doesn't work well for us in that sense. We cannot extract it from the Tenable system; we're restricted to using Tenable's own dashboard and reports. However, there's certainly some logic or rationale behind it. It's not directly tied to the CVSS, but rather some other factors. So, it's not a one-to-one correlation with the CVSS, although CVSS is a metric commonly employed in various other systems for assessing vulnerabilities.
Aligning these metrics and incorporating an additional feature indicating the early harmfulness of a vulnerability is lacking. We're hopeful that the CVSS framework is undergoing changes. I've heard that version four, while not specifically linked to Tenable, is likely to introduce more meaningful values. These values won't be solely focused on severity but also on the level of exploitability. For instance, if exploiting a vulnerability requires local access and specific conditions, it might not merit a higher score like ten; it could be lower due to limited feasibility. Thus, certain developments could be anticipated in this regard. Tenable is also working on its own approach, known as CPR (Cyber Exposure Priority), but this feature is not exportable, unfortunately.
In future releases, I would like to see a feature that provides insight into the actual degree of harm associated with certain vulnerabilities. Ideally, I'd want this information to be exportable to align it with other vulnerabilities. It's possible that I might have the same CVSS value from another source, not necessarily Tenable. We're not using Tenable IO for container security, where we have a separate collection of CVs for containers. However, it's challenging to compare them directly due to the differing numbers and systems. If we could implement this VPR concept for other CVs as well, we could customize it to better suit our needs.
We've been using this solution for close to five years. We probably use the latest version.
I would rate the stability an eight out of ten. Occasionally, there are some maintenance tasks that might cause a slight uptick in activity, but we have monitoring mechanisms in place. Fortunately, it hasn't experienced any major breakdowns.
Sometimes we encounter issues with resources, like logs populating hard drives, which require manual or semi-manual cleanup. Overall, it maintains a relatively stable performance level. I would rate it at around an eight out of ten in terms of stability.
It is hard to tell because the size of our organization is not very big. Our license covers a range of assets, from 500 to 1000 assets, which we monitor. From their perspective, this falls within a very low scale.
So, we haven't encountered any scalability issues. Our scale is relatively small; we're not dealing with tens of thousands of assets.
The Security Center is actively scanning every day, targeting different resources with varying scanning frequencies. It operates on a daily basis, generating reports intermittently – some on a daily basis and others weekly. The usage is consistent and spans almost around the clock.
Certain tasks are scheduled during nighttime, while others are executed during the day. Essentially, there's a continuous level of activity distributed over time to avoid creating spikes in network usage.
We use it to its maximum potential but ensure it doesn't overly strain our network resources. There was a problem. When initially setting it up, we needed to be cautious. There's the potential to generate substantial network noise, especially if the agent and scanner tasks are simultaneously active. We had to significantly scale it down and task the settings from their defaults. Perhaps it's partly due to our network's capacity, but we encountered initial challenges in managing the traffic.
It is not super good and could do some improvements. I've had interactions with different parties, and while it's not exceptional, we were able to resolve issues with some effort.
We encountered certain challenges. Initially, the local distributor downplayed the situation, claiming that upgrading to a new version would instantly resolve the issue. However, it wasn't that simple. It took time to resolve the matter. I had expected better support, especially since we had informed them in advance about the downgrade we were planning. I had hoped for proactive support detailing what to expect and what actions to take. Instead, we received assurances that everything would work seamlessly after the version change, which didn't prove to be accurate.
There was a miscommunication or misunderstanding in that regard. It was quite frustrating at the time.
Neutral
The initial setup is somewhere in the middle. It's not very easy. Assistance is needed, especially when dealing with version changes. For instance, when we transitioned from Tenable Plus to the regular Tenable, there were complexities in changing the licensing. It was not so easy to change.
It might even lean a bit toward the difficult side, so I would rate my experience maybe a three out of ten, where ten is easy and one is difficult.
We had the support of a third party. We had to use the help of our reseller and also find an engineer from Tenable.
In certain cases, such as upgrades or downgrades, the documentation isn't always well-defined. You might encounter challenges that require external guidance. For instance, we faced a two-week period of difficulty this year due to a change we were making. It might not be an annual occurrence, but when significant changes are made, it can be far from a straightforward upgrade. Putting new versions in place doesn't guarantee seamless operation; there can be quite a bit of hassle around it.
This wasn't the initial deployment. This occurred when we were switching back from Tenable Plus to regular Tenable at the beginning of this year. It took us around two weeks to ensure that everything was properly transitioned. It's important to note that this was not a continuous two weeks; it involved time periods over the span of around two weeks. This change involved a transition to a simplified licensing structure. We opted to revert to Tenable without the Plus version, as it fulfilled our requirements and was also more cost-effective, approximately a quarter less. This process took place during that time, and it was a hassle.
Only one person was involved in the deployment. We don't have a big team. We have a dedicated engineer who oversees this service. He took the lead in managing the deployment. He also engaged with relevant contacts internally and externally, including the local distributor and partners, but overall, it was primarily handled by this one engineer.
For maintenance, the same engineer who handled the deployment also manages the ongoing maintenance.
We purchase the solution through a local distributor, but we also directly communicate with representatives at Tenable. So, we acquire the license from their distributor, but we are direct users as well.
I would rate the pricing a nine out of ten, where ten is expensive.
The pricing might deter some companies from adopting this solution, especially in our region, which includes countries like Estonia and neighboring Eastern European nations. For us, the cost is a significant consideration, and we often face challenges when budgeting for it each year.
There's on-premise hosting, which incurs some costs, but it's not a major factor. Additionally, we have an engineer providing support, but that's a shared responsibility across multiple tasks. So, licensing is the primary cost driver, and there aren't any other major expenses.
There are positives and negatives, but despite looking at other options, we haven't found anything better suited for us. So, we continue to use it and have plans to keep using it in the near future.
I would suggest running a proof of concept to evaluate the product's suitability. Test it on a smaller scale over a period of one to two months to see how it works.
It's essential to assess whether the solution aligns with the organization's specific needs. Our approach involves using agent-based scanning, but this varies based on individual requirements.
Be aware of the network "noise" it might produce. Default scanning intensity might be too much and you might need to alter it in order to prevent network problems (DoS yourself).
My advice would be to give it a trial run before committing. It's hard to tell if it fits without firsthand experience. Additionally, the fact that Nessus, the scanning component of the security center, has been around for decades and even had open-source iterations in the early 2000s provides some confidence in its longevity and reliability. However, for newcomers, I would recommend testing it out on a smaller scale before making a decision.
Overall, I would rate the solution a seven out of ten.
