When PHP2Shell was made public in October, it was announced to the world through the media as one of the most serious and significant vulnerabilities of all time, and the expectation was that it would be exploited widely. In our experience, and in a view that’s been widely reported, the risk of exploitation was overstated. The exploits proved very difficult to execute, and our own monitoring systems didn’t detect a single attempt at exploitation against Kurtosys in the first week.
This was still a serious event, and we treated it as one. The over-reaction made it harder to manage, though, because the scaremongering added unnecessarily to the burden of the whole incident management process. What wins the day is a practical, well-planned and well-executed response, where proper analysis, communication and remediation are always the most important factors.
PHP2Shell is also the latest sign that the habitual rhythm of security patching is breaking down quickly. We’ve dealt with four serious zero-day incidents at Kurtosys this year, and we see no let-up on the horizon. We’ve learnt, and continue to learn, how to cope with this, combining AI to support our incident response plans with sound management processes that have been tried and tested over many years.
Why zero-day vulnerabilities are breaking the old patching routine
Once upon a time, vendors would review their bug lists and issue security releases on a regular schedule. The major players did this so consistently that we ended up with the concept of Patch Tuesday. As a consumer of that software, the discipline was keeping pace with the cadence, and if you fell behind, you built up compatibility issues and major-release dependencies that took real time and resource to catch up on.
A zero-day vulnerability is a flaw that attackers can exploit before the vendor has released a fix, which leaves no scheduled patch to wait for. That’s why acting on a zero-day carries far more urgency than applying a routine security release, and as they become more frequent, keeping pace with a release calendar isn’t enough on its own.
How we protect against what nobody knows about yet
We build our service with layers of protection, because layering gives a good level of mitigation against vulnerabilities that haven’t been discovered yet. For years we achieved this with firewalls, proxy access and VPNs, which isolate and obscure any unknown vulnerability sitting underneath. Today we make extensive use of zero trust network access, single sign-on, multi-factor authentication and other technical controls to manage those layers.
We verify every network, device and user, and we use device agents and mobile device management (MDM) policies to monitor and control how they’re used and how they behave.
AI is changing how vulnerabilities are found, exploited and managed
The cybercrime industry has trended away from simply attacking applications with known vulnerabilities. We got so good at securing the perimeter and building better software that attackers shifted their focus to human vulnerability, through phishing and account compromise. With AI, cybercrime is turning back to application weaknesses once again, because AI can uncover vulnerabilities much more quickly and turn its attention to exploiting them with the same speed and incisiveness.
AI is also our extra resource. We use it to analyse our code base and our datacentre deployments, so we can quickly and accurately determine our exposure to a new vulnerability. It checks and analyses our monitoring systems to establish which incidents need escalating, and in some cases we’re already using it to suggest and implement mitigations.
How media hype adds to the burden of incident response
We can’t ignore the hype and media attention that’s following the AI trend. Sometimes it’s most definitely overstated, and that isn’t healthy, as PHP2Shell showed. At other times, social media is providing early warnings we need to act on urgently. These discoveries have taken on a new public persona that will remain with us, so we need to learn how to deal with both.
Patching itself hasn’t fundamentally changed, and we still need the patches vendors produce. The way vulnerabilities are discovered and reported has moved on, though, so our response has to move with it. That means building the flexibility and speed of response to identify exposure quickly and find the lines of mitigation that protect us while the fix is on its way, because time used to be on our side, and it most definitely isn’t today.
If you’re reviewing how your technology partners manage security, a trust centre is a good way for a vendor to show its competence and transparency. What matters most is the substance, quality and relevance of the information inside it.
