Questions for IT and cyber leaders from the CSRB Microsoft report

The CRSB report – key highlights

The report is relatively compact at 34 pages and whilst it does refer to other reported Microsoft hacks, including the January 2024 Midnight Blizzard attack, it otherwise keeps tightly to its brief of the Storm-0558 May/June hacking event.

The report forensically unpicks the failures leading to the attack and makes 25 recommendations:

• Four of these focus directly on critical corporate failures identified with Microsoft practices and security culture;
• Five recommend uplifts to Microsoft Identity and Access Control models to align with identified strong practices in Google, AWS and Oracle;
• One lays down minimum logging and audit standards the CSRB believe should apply to all CSP’s;
• Three recommend use of open identity standards, tied to CSRB’s identification that proprietary Microsoft Identity technologies contributed to the attack;
• Seven introduce an obligation of transparency for CSP’s to the US government and for improved victim notifications – which may need to be carefully implemented if they are not to fall foul of other global legislatures existing concerns over the US government’s ability to see into US cloud provider services; and
• Five suggest possible changes to NIST standards for Cloud Identity, and a revamp of the US FedRAMP model – the latter of which would principally improve the security position for US government cloud users rather than provide a general worldwide benefit.

In my last ‘five questions’ article I opened with a question about Microsoft’s security posture:

Microsoft presents itself as being an intrinsically secure platform – is that still the case?

The CSRB has given its answer to this question, identifying that Microsoft’s security posture and culture fall well below the norm for cloud service providers; to the extent that the CSRB has urged it to suspend the creation of increasingly complex new features until it has confirmed they can be introduced securely.

In addition, the CSRB confirmed that the means by which the Storm-0558 attack was completed still remain unknown, but have identified Microsoft’s reliance on 20 year-old legacy identity products, poor manual key management processes, and poor logging and audit as key weaknesses exploited by these and other attackers.

I previously postulated that Microsoft might never be able to prove its platform is 100% secure after the Midnight Blizzard hack, and the CSRB has laid that challenge on the Microsoft Executive Board’s desk – to prove it is both serious about security and that it can once again be considered a trustworthy platform.

Five questions to ask

For organisations consuming Microsoft, the updated five questions we now might ask are:

Have the new products introduced by Microsoft improved or weakened your security?

Microsoft has commenced global rollout/general availability of the Copilot LLM/AI-based tooling to all customers – either on additional payment or bundled with enterprise licences.

The uptake of Copilot has not, however, been universally welcomed, with the US Congress barring Copilot from its devices citing concerns over control of the data it ingests and reports upon.

Given the CSRB report and recommendations that Microsoft should revert to Bill Gates’ 2002 paradigm of “security and privacy over new functionality”, how do we know these services do provide the benefits Microsoft have suggested?

Microsoft confirmed that the Midnight Blizzard hackers were inside its systems for up to 42 days before they were found – despite AI enabled Security Copilot technologies monitoring the environments.

Next-gen AI security tools have been pushed out aggressively, and adopted at pace by most Microsoft customers over the past six months, but is the CSRB correct to suggest that its underlying security, and security value might not be worth the risk of their adoption?

Do we actually improve our security through their use, or just get a false sense of comfort, and could the information in them be weaponised by attackers to identify vulnerabilities or craft new attacks?

Are we likely to be a target for future attacks through Microsoft services?

Microsoft has previously claimed that hacks on its infrastructure have had strictly limited effects on customers, whilst concurrently in January advising “governments, diplomatic entities, non-governmental organisations (NGOs) and IT service providers, primarily in the US and Europe” to be aware of attacks on Microsoft services and advising them on how to identify if they had been compromised (security threat intelligence blog).

The CSRB report has gone further and identifies that government bodies and critical national infrastructure (CNI) operators running services on Microsoft cloud platforms are indeed a key target for Chinese and other state sponsored hackers.

In this respect it’s important that we understand the UK is probably at a much greater risk here than its allies, having limited domestic cloud services, and relying almost exclusively on Microsoft and AWS cloud platforms for the key functions of state. The US government uses Microsoft cloud extensively, but mainly in its FedRAMP US-domiciled and federally-assured flavour – and not the public cloud platform the UK uses.

It’s unlikely that the UK government properly understands its risk exposure on the Microsoft cloud platform today (and this might hold just as true for non-government organisations too).

Over the past decade adoption of Microsoft public cloud services by the UK public sector has been relatively unconstrained, whilst records of public spend on Microsoft are often contained in contracts awarded to partners and service integrators, or listed as ‘licences’ and thus may be inaccurate.

Understanding exactly what Microsoft services you rely upon – such as cloud-based identity – is more important now than ever (as are fall-back mechanisms in the event of failure or loss of services).

It’s also vital to ensure you know what applications and services you have on Microsoft cloud infrastructure, and exactly what data is contained in each.

At a governmental level the UK needs to conduct a proper audit of cloud use by each public body and create a national information asset register.

Only once we have both can we hope to understand our national risk posture.

If we had to disconnect from Microsoft what would it mean for our business operations?

This question is as valid now as when I first tabled it – with the additional consideration that whereas there might previously have been some indications of compromise and security weaknesses in Microsoft; the CSRB report has now confirmed both of these possibilities to be evidenced fact.

In addition, organisations who have begun to adopt (or rely upon) newly rolled out Azure or 365 services might want to prepare for the eventuality that Microsoft could withdraw or suspend them – which it might be obliged to do if the recommendations to the US president made by the CSRB are followed through.

Investments in the latest tech might therefore now carry some additional risk, or project plans might need review.

This isn’t an urgent “act now” risk – I doubt we’ll see service reductions on a large scale, but it merits careful watching. It’s perhaps more likely that upcoming features might stay in beta or limited preview for a longer period of time.

Are the decisions we previously made based on risk acceptance still valid?

All organisations today operate on some degree of risk acceptance, and doing so requires us to regularly review our risk position as circumstances change.

The CSRB report identifies a number of concerning behaviours and low prioritisation of security in Microsoft, and if your risk acceptance was based in part on  intrinsic good security practice by Microsoft then it might be prudent to read the CSRB report and decide if you should re-examine them.

Recently Google has announced an alternative to the ‘shared responsibility model’ for cloud, and given that in Microsoft’s case its responsibility to maintain the security of the cloud appears to have been poorly fulfilled, the Google Shared Fate’ model is perhaps worth considering, and might be more equitably balanced.

Should we be looking at a different cloud platform – or even self-hosting?

Whilst the CSRB has been highly critical of Microsoft, it has still been broadly positive about cloud services in general, and have called out specific good practices in Google, AWS and Oracle which suggest that their underlying confidence in cloud as a delivery model remains strong.

Ultimately deciding to move from your current cloud provider is a hard choice – not to be taken without careful thought, unless you believe it’s an intrinsically unsafe platform for your particular use.

For some government services it would not be unreasonable to reach that conclusion on the basis of the CSRB report – but even so, no government migration from Microsoft is likely to be easy or palatable in the current climate.

There is however now a sound basis to consider either a pause on further adoption of the Microsoft platform, and perhaps to even apply a moratorium on its use for some types of data until the CSRB report has been actioned, and the exact means by which Microsoft was compromised is determined.

Even now – nine months after the attack – the CSRB has identified that Microsoft still has no clear understanding of how Storm-0558 was able to so deeply invade Microsoft’s identify services, and that should worry us all.

It would be unwise for the UK government not to act on this report in some meaningful way given the detailed findings of the American analysis and the regular citation of NCSC investigations within the report.

Although HMG’s Cloud First policy is often cited as justification to push services into the public cloud, that needs to be balanced against the evidence-based decisions expected of public bodies choosing to do so.

The NCSC Cloud Security Principles identify several use cases and caveats where public cloud use may not be the right choice, but few organisations use the principles as they were intended – to assess and help select a suitable cloud platform, rather than as a tick box compliance exercise.

In conclusion

Using public cloud services has always been an exercise in balance of risk versus reward, and for the moment the CSRB report suggests that the rewards to be gained from use of Microsoft might for many organisations, and for the first time, be somewhat outweighed by the risks posed by their corporate culture and poor security practices.

That’s the decision now faced by Microsoft’s customers – both commercial and in the public sector: in the light of the CSRB report, is trust in Microsoft now trust misplaced?

Do we need to moderate or start to reduce our reliance on Microsoft cloud, or should we press on regardless and hope we don’t fall foul of the next state-sponsored attack?