The Cloud Security and AppSec teams at Phoenix Security are pleased to bring you another set of new Phoenix Security features and improvements for vulnerability management across application and cloud security engines. This release builds on top of previous releases with key additions and progress across multiple areas of the platform.

We are sure that you’ll find these quite interesting!

• Improved Management your Vulnerabilities and Assets
  • Display “Closed” vulnerabilities list page
  • Display vulnerability stats in Asset screens
  • Override asset exposure for whole Apps/Envs
• Risk-based Posture Management
  • Update risk formula structure
• Integrations
  • Configure “vulnerability types” fetched from SonarCloud/SonarQube
  • Users can manually trigger a “scanner refresh”
  • Update Jira tickets when the associated vulnerability is closed
• Other Improvements
  • Handle large number of items in Treemap chart
  • Improved scanner flow: don’t fetch targets until needed
  • Improved performance of MTTR queries

Please note: The features discussed in this article will be released on Monday August 21th.

There will be a small but noticeable variation fo the risk score as there are new parameters like fixability, exploitability and adjusted likelihood of exploitation introduced in this release. The more noticeable change would be at Asset level.

Users would notice a change in the vulnerability risks and those aggregated up to the Organisational risk.

---

Manage your Vulnerabilities and Assets across application security and cloud security.

Display “Closed” vulnerabilities list page

Phoenix Security’s primary focus is on the management of active Infra, Cloud and AppSec vulnerabilities and the assets affected by them. Nonetheless, during their day-to-day activities, security experts and engineers might need to look back at the vulnerabilities already closed.

This information has always been available in Phoenix amongst the statistical data present by the platform. However, users can now display closed vulnerabilities with the active ones in the Vulnerabilities screen.

This screen now features new controls to select which type of vulnerability should be displayed: Open, Closed or both.

Display vulnerability stats in Asset screens

At Phoenix Security, we are always looking to make our user’s life easier. Providing relevant information about assets and vulnerabilities in the right context is one of the ways we do this.

With this release, users can now see a summary of vulnerability information at the top of any Assets pages. These stats are calculated for the set of assets selected by the current filters, if any, which provides a powerful tool to dynamically analyse vulnerability and risk profiles across different sets of assets.

In a follow-up release we will include additional information (e.g. asset stats) and extend this feature to the Vulnerabilities screen.

Override asset exposure for whole Apps/Envs

Phoenix Security features a powerful and flexible way to define asset exposure (internal/external/DMZ) by using filtering rules that identify each type of asset. This allows our users to create precise rules to define each asset’s exposure.

However, sometimes an organisation needs to define the exposure of the assets of an entire Application or Environment. This is now easier than ever with the new App/Env filter option within Policy > Context Rules.

Risk-based Posture Management

Update risk formula structure

Over the past year, we have been working with our clients and advisors to ensure that the Phoenix platform’s risk calculation correlates with the expectations of security specialists and supports our clients’ workflows.

As a result of this analysis, we are making several improvements to the way vulnerability risk is calculated and how it gets aggregated at the Asset, Component and Application level. All these changes will be shortly reflected in our Risk Calculation article, but the key highlights are:

• We have increased the number of parameters that feed into the vulnerability risk calculation and adjusted their ranges and weights. These changes ensure that our contextualised vulnerability risk better reflects the factors that influence it.
• Most of the contextual factors are now applied at the vulnerability and asset level, even when the context is defined by the components and applications that those assets belong to. This removes any potential double correction and makes the logic of the risk aggregation more straightforward.
• Now both Applications and Environments get their risk directly from the assets they contain, not from any intermediate asset grouping (e.g. Components). This eliminates the “averaging” effect that intermediate groups can have, and ensures that assets assigned to multiple Components (coming soon) do not “double count” when aggregated at the Application/Environment level.

Integrations

Configure “vulnerability types” fetched from SonarCloud/SonarQube

Some scanners, like SonarCloud and SonarQube, provide access to different types of “findings” through their APIs – e.g. Vuln, Bug, Code Smell. However, in many cases, some of these types of findings are not really relevant for vulnerability management activities since they are more about best practices and lints than actual vulnerabilities.

Our users can now choose which type of finding is retrieved through our integrations with ConarCloud and SonarQube by selecting the desired types in the scanner integration configuration.

Users can manually trigger a “scanner refresh”

One of the key advantages of the Phoenix platform is its configure-and-forget approach to scanner data retrieval. Once the integration with a scanner has been configured, the platform periodically fetches updated findings.

Some times, however, users want to trigger a scanner data refresh at a particular point in time, without waiting for the platform to get to the next interaction with the scanner. This is now possible by using the refresh button at the top of the scanner configuration screen (see screenshot above).

Update Jira tickets when the associated vulnerability is closed

One of the key strengths of the Phoenix Security platform is its “actionability”. It allows users not only to gather, contextualise and track assets and vulnerabilities but to trigger actions across the wider team by creating issue tickets in their platform of choice.

With this release we are taking our Jira integration one step further, by ensuring that tickets created for vulnerabilities get closed in Jira when those vulnerabilities are closed in Phoenix. At this point the platform will update the ticket with a comment indicating that the vulnerability has been closed and will change the ticket status to Done.

Other Improvements

Handle large number of items in Treemap chart

Sometimes, when navigating the Impact Explorer chart (treemap), we can loose clarity of details if there are many items in the current level. This tend to happen more easily while navigating populous Components or Services.

In this iteration we have improved this situation by only displaying the top 50 items of any level, and showing an extra block that represents the rest of the items, not displayed.

Improved scanner flow: don’t fetch targets until needed

Phoenix Security’s scanner configuration functionality provides great control over what is fetched from the scanner. In order to do this, the platform needs to interact with the scanner to obtain up-to-date information about the structure of what’s being scanned (targets).

In our continuos effort to improve usability and user experience we have reviewed the configuration flow to minimise interactions with the scanner, hence improving responsiveness.

Improved performance of MTTR queries

Mean Time To Resolution (MTTR) is a key metric that can take some time to gather in certain scenarios. This can cause the chart to remain empty for some seconds, even after the rest of the page has been rendered. We have now reviewed the associated queries and calculation to minimise the more extreme cases’ impact and provide a smoother user experience.