The world has changed.

Cloud and DevOps have shifted how applications and software are built. 

Open-source and no-code have changed the speed and time it takes to create software.

In the same way, the Cloud and Containers have changed how software is run. 

In all this landscape change, we are still trying to address vulnerabilities in the same old-fashioned ten-year-old method, with manual triage and manual assessment calls. What’s the result? Security teams are drowning in a sea of red/critical alerts that are un-contextualised and spending time arguing with businesses on all the problems that need to be solved. The business leaders don’t speak the vulnerability language and only understand risk and the money spent to reduce risk. 

Now is the time for a paradigm shift and to tear down the language barriers. 

Security Teams are drowning in alerts, and developers-security interaction is at the highest friction point.

Every time a major vulnerability hits, there is a panic drill as everyone scrambles to find where the vulnerability is and which asset is at risk. 

In the meantime, highly exploitable vulnerabilities in business-critical applications get missed. It is a matter of priorities, and the security/development team doesn’t currently have the contextual view required to fight back against attackers. 

Hoping to find critical vulnerabilities in this chaotic scenario is very hard and leads to more pain and mistakes than anything else. 

Triaging vulnerabilities manually doesn’t work either, as it leads quickly to alert fatigue and security teams burning out. 

Enter Phoenix Security with the Phoenix Security Platform

Removing noise, contextualizing vulnerabilities, translating vulnerabilities into risk, and bringing the whole organization on the security journey towards a path to resolution.

Shifting the paradigm from security begging for fixes to be implemented into risk-based targets owned by the business and accelerated by security, building with confidence, and securing what matters most. 

Launching V3 Phoenix Security Platform

Originally we were focused on application security, in itself, it was enough as it didn’t add a risk-based view on WHERE the organization run the applications.

We added cloud and container security, and now we knew what was running but not which application was running.

We innovate again and added dynamic asset traceability based on tag-based association.

Now we know which application is running on which assets

We started working on owner assignment, traceability and correlation between who owns what and where is this information is. Phoenix now has several data sources to fetch and correlate user information from. 

With those three concepts created, we have a platform that can :

• Track dynamic applications as they are being built, 
• Trace vulnerability for those applications dynamically
• Link cloud security and other workloads dynamically to apps and where they run
• With the correlation feature, we can now transfer information from one domain to another. 

We can transfer the ownership of who runs a set of workloads from the applications running on it.

We can understand how exposed a particular instance of an application is based on where it runs and how many endpoints are exposed. 

Many of the features mentioned have been tested and released to selected teams in the platform over the past 12 months. We are announcing the General Availability of the full platform in January 2023. Some of the most important features will be released and available in the GA. 

Guiding Principles

With the new platform, we wanted to unify the three fields that form what Gartner defines as exposure and the life cycle of management. 

• Mapping attack surface and context
• Mapping Vulnerabilities into business applications
• Creating a Roadmap to validate the vulnerability and auto remediate 

The main drivers of our platform evolution are centred around key points.

• Provide complete visibility of assets and vulnerabilities across AppSec, CloudSec and InfraSec.
• Minimise the time required for our users to have a full view of their security landscape.
• Provide a risk-focused view of the organisation’s position at any time.
• Strong vulnerability management, including vulnerability prioritisation, and improved actionability through exception management workflows and integration with ticketing systems.
• Leveraging and augmenting the Security team by providing vulnerability insights, trends and “hot spots”.

Guided by those main drivers, we’ve embarked on expanding and improving the Phoenix Security Cloud Platform. This journey has involved changes in a broad range of functional areas, but the key advancements could be summarised as follows:

From vulnerability-focused to asset-centric. We have placed assets (Software, Cloud and Infra) at the centre of our platform while focusing on the vulnerabilities affecting those assets as a measure of risk. This makes sense since vulnerabilities always affect some assets, and most of the context for those vulnerabilities is provided by or related to the affected asset.

From a vulnerability driven to asset and vulnerability lifecycle, to a flexible composition and modelling of the organisation’s state. At the start of our journey, it seemed quite adequate to model the organisation’s state (into Applications and Environments) by leveraging the “grouping” provided by the scanners. Depending on the scanner, these groups can be called projects, applications or targets, but they always reflect how those scanners relate to the scanning targets. For us here at Phoenix it became clear that the way scanners see their targets (very technical) is not necessarily aligned with the way the business organises its teams and management around functional areas, applications and environments. We have worked hard to provide unparalleled flexibility when it comes to modelling an organisation’s sea of assets and vulnerabilities into a landscape of Applications and Environments. In doing this, automation and flexibility are the key ingredients.

Evolution of our risk calculation to the current ACT-ON risk formula – Actionable Contextualized Threat. We have already talked about the former ARCTIQ (now ACT-ON Risk) in previous posts. Still, it’s important to highlight here how we’ve evolved our risk calculation to make it a better reflection of the vulnerabilities and assets’ context and to provide real-time actionable and quantifiable information that leverages threat intelligence sources. For example, exploitability information like EPSS plays an important role in determining the effective risk score of a vulnerability and hence the assets and components that contain it.

A constant stream of new integrations. If there is something that hasn’t changed over the last year is our continuous push to integrate with more scanners, ticketing platforms and, more recently, asset information sources. This drive for increased connectivity provides our clients with a broad range of out-of-the-box integrations to their scanners, project management and ticketing systems, and additional sources of asset details (beyond the actual vulnerability scanners).

Key Additions and Enhancements

It would be difficult to list every single addition and improvement made over the last year, but a list of key changes would help highlight the previously mentioned points.

• Deployed Applications: The year started with one of the key ingredients for our “contextualised risk” – the ability to deploy applications onto selected environments to provide the context of “what is running where”.
• 0-Day Alerts: Sometimes vulnerability management involves a quick reaction to the latest attack activity. Our platform can detect and alert the presence of 0-day vulnerabilities within our client’s state – for this, we use early warning signs (products, versions) and confirmed detections (CVEs), with varying degrees of certainty.
• Selection Engine: One of the critical components of Cloud Security Phoenix, the selection engine is responsible for identifying the vulnerabilities the organisation should tackle first. We are constantly working to ensure that the selection is based on effective risk and contextualised within the organisation’s applications and environments. Our smart selection process considers factors like fixability and CTI information, together with the prioritisation of vuln types depending on the component’s locality (internal vs external).
• Security Dashboard: Where security specialists can get insights about common vulnerabilities, particularly weaker assets or commonly used vulnerable software and libraries.
• Asset Screens: In our shift to a more asset-centric view of the organisation’s state, we have been creating comprehensive ways to navigate and find specific assets across all the different sources: Software, Web/API, Cloud, Infra and Container.
• SBOM: With the exponential increase in the use of third-party, mostly open-source, libraries, it has become paramount to be able to explore the “bill of materials” for each of your applications. Furthermore, our users can turn the focus around and see which applications use a particular library and version.

The Paradigm Shift

Suppose the above items are key additions to the Cloud Security Phoenix platform. In that case, others create a paradigm shift of how we fetch, process and present assets and vulnerability information.

We strive to provide value to our users as soon as they use the platform. To do this, we have changed how we interact with their scanners. We start pre-fetching asset and vulnerability information as soon as the scanner credentials are configured on the platform. This allows us to start modelling the organization’s state within minutes of sign-up, presenting an initial overview of assets and vulnerabilities and the organization’s risks as soon as they are fetched from the scanners.

As mentioned above, one of the key evolutions of the platform has been breaking the scanner’s target boundaries. The organization’s business applications and teams are not aligned with the scanner’s view of the world, and neither should their representation in the platform. Using flexible matching (or filtering) rules, users can define exactly what set of assets form part of a component or service – allowing them to model their state in whichever way best fits their organization.

Leveraging the above two points is one of the latest additions to the platform: the automatic creation of Default Applications and Environments to capture any assets that are not included in user-defined components. This provides several benefits:

• As soon as users connect to their scanners, the platform captures those assets into the Default components, providing a complete – if still not fully modelled – view of the organization’s risk posture and security landscape.
• As users start carving out parts of the assets into their Apps and Envs, the default components still ensure that non-assigned assets’ impact is still considered when calculating the organization’s risk posture.
• Furthermore, since Default components are just like normal ones (almost) they can be navigated and configured in the same way.

We place a big emphasis on automatic asset and vulnerability retrieval through native API integrations with scanners. However, weaknesses will always be discovered through a manual process, whether regular pentests or ad-hoc security reviews. And we want to ensure that those vulnerabilities can seamlessly be integrated with those provided by scanners. This is why asset and vulnerability import is a key feature in Cloud Security Phoenix, with dedicated screens to define “assessments” (or engagements) and to keep track of previous imports. All this ensures that imported information is fully integrated into the platform’s features and flows.

One of the cornerstones of our platform has always been the correlation of AppSec with Cloud and Infra, helping organisations get the proper context for their product vulnerabilities by ensuring that application vulnerabilities are evaluated within the context of where they run. This is why our risk calculation logic considers where applications are deployed and “transfers” the locality factor of the environment (how internal or external it is) to the deployed application.

With locality being such an important factor, we want to ensure that our users can easily define the value of the factor for every asset in the state. This provides a flexible and powerful way to set the locality value of an asset using rules based on its tags, IP address or any other attribute it might have. And, since there is always a common case, users can define the default value for all assets that are not matched by any explicit rule. All assets are always accounted for.