On 21 October, PHP released emergency updates for two critical vulnerabilities, collectively referred to as PHP2Shell. These vulnerabilities allow an attacker to execute code on a server without logging in. According to researchers, the flaws have been present in PHP versions dating back to 5.4. The impact is far-reaching, extending even to products from security vendors themselves. In the Netherlands, websites including MijnOverheid, DigiD and the Dutch House of Representatives were taken offline as a precaution (source: NOS). And organisations still running PHP 8.1 or earlier no longer receive standard security updates from the PHP project itself.
The recent coverage of PHP2Shell raises an interesting question: what if vulnerable code has been present for years in software that organisations use every day? With PHP2Shell, organisations chose to take websites temporarily offline until an update was available. But what do you do when that isn’t an option? This risk is not limited to websites or programming languages. Organisations also rely on legacy systems, older applications and industrial systems that have sometimes been running reliably for years. A production line, a building management system or an old connection to your ERP system cannot simply be switched off for a few days. Replacing them is not always straightforward. Systems may depend on other applications, or be so critical to business operations that updates cannot simply be applied without careful consideration. And these are precisely the systems where accounts and access rights are often no longer fully understood or properly monitored.
What if you cannot fix a vulnerability immediately?
That was precisely the situation with PHP2Shell. The NCSC urged organisations to update as soon as possible, but at that point, no update was yet available. According to Amazon, an exploitation attempt had even been detected four days before the patch was released. (Source: BleepingComputer)
Imagine that such a system contains a vulnerability that has not previously been identified. Or that an account has had access rights for years that are no longer needed. Of course, it remains important to keep software up to date, assess vulnerabilities and address them wherever possible. In practice, however, it can take time to do this safely. That is precisely why it is important to maintain visibility of what is happening across your network in the meantime.
It is not just about knowing what is happening, but understanding what it means
Which accounts are active? Which access rights are actually being used? And are there changes in behaviour that warrant further investigation? A system may continue to function normally from a technical perspective, while the way it is used changes. An account may have legitimate access rights but use them in an unexpected way. An individual event may appear harmless, yet become significant when considered alongside other activities. By correlating information about accounts, access rights and activities, organisations gain more context to assess such situations.
What role can Fryqua play in this?
Fryqua brings together identities, access rights and user activities in a single investigative view. This helps organisations better assess whether actual access usage still aligns with what is reasonable, necessary and secure. Fryqua does not replace existing security measures, but complements them with context that helps organisations investigate anomalies, assess risks more effectively and make informed decisions.
You do not always need to replace an older system immediately to manage its risks more consciously. However, it is important to understand what is happening within your environment and to be able to assess whether activities and the use of access rights still align with your expectations.
How do you maintain visibility of the use of older systems and existing access rights within your organisation?