This is not confidence inspiring. These fixes are only surface-level, rather than looking at the underlying systemic failures:
- Not storing key data in an HSM.
- Exporting crashdumps outside of the production account.
Redacting private keys and other sensitive data from these will always be failure-prone. Keys are also only just one problem, there will be personal data, passwords etc. in those dumps depending on what process it was.
- Corp environment infiltration not detected at the time (presumably, since this part is pure guesswork)
- Not enough log retention in the corp environment to track a 2 year old infiltration.
- Not assuring that key validation correctly denied requests with the wrong scope.
Fails-with-a-valid-key-with-wrong-(scope/date/subject etc.) are the kind of cases that always deserve test coverage, especially for a dedicated key-validation endpoint. Also concerning that this wasn't found by manual-testing/red-teaming/pen-testing in the time since it shipped.
- Slow detection, slow response, poor communication
The lack of scope checking seems especially egregious. It sounds like any number of keys would have been incorrectly trusted. If it was an RSA key that signed JWTs which it sounds like or similar, Microsoft has an issuer endpoint for all customers and it's critical to check the issuer/scope for those since any number of things can create a token with a valid signature.
> - Not enough log retention in the corp environment to track a 2 year old infiltration.
It didn't say that Microsoft couldn't identify that infiltration had occurred just that they didn't retain the logs to prove to exfiltration. That makes a lot of sense, maintaining access logs is one thing but to retain the detailed logging of every file action by every user on a 100k+ user corporate network long-term would be a massive amount of storage, of fairly limited value.
Even in this case, it might be nice to have but it wouldn't change any of the major findings you care about if you are Microsoft: that a bug allowed a key to be written to a dump file, that the scanning tools didn't detect the key in the dump file, and that the authentication process didn't properly check the keys.
I was more talking about the problems of moving data across trust zones rather than retaining it at all. Retaining logs and crashdumps for several years is good, but moving them from a locked-down production environment to a less secure corp account (where they were presumably easier to work with because of the lower security requirements) is why this leak happened.
Moving sensitive data to a less secure environment is of course a mistake, but leaks happen even with locked-down production environments.
It's very unlikely anyway a software company will fix an old crashdump - the software probably moved on a lot. So if there's no specific report/problem it's attached to and it's not a sensitive area, we're better off having it deleted. Same thing for old logs.
- Not storing key data in an HSM.
- Exporting crashdumps outside of the production account.
Redacting private keys and other sensitive data from these will always be failure-prone. Keys are also only just one problem, there will be personal data, passwords etc. in those dumps depending on what process it was.
- Corp environment infiltration not detected at the time (presumably, since this part is pure guesswork)
- Not enough log retention in the corp environment to track a 2 year old infiltration.
- Not assuring that key validation correctly denied requests with the wrong scope.
Fails-with-a-valid-key-with-wrong-(scope/date/subject etc.) are the kind of cases that always deserve test coverage, especially for a dedicated key-validation endpoint. Also concerning that this wasn't found by manual-testing/red-teaming/pen-testing in the time since it shipped.
- Slow detection, slow response, poor communication