This plus the latest State Dept. hack deserves pulling the CEO in front of Congress. It is known that there used to be a saying at Microsoft ~”Don’t get Bill pulled in front of Congress“ to avoid making bad decisions. That should be a thing again.
> He also faulted Microsoft for waiting five years to refresh the signing key abused in the attacks, saying best practices are to rotate keys more frequently. He also criticized the company for allowing authentication tokens signed by an expired key, as was the case in the attack.
https://arstechnica.com/security/2023/08/microsoft-cloud-sec...
For the latter issue you mentioned as well, it may be caused by fear of outages. The people implementing the design may have opted for a soft notification to the right people when the key expired but wasn't renewed instead of refusing to validate tokens and causing a global outage affecting every cloud service for every customer.
Hindsight is always 20/20, but why didn't any government, organization or institution require a 3rd party audit of MS prior to this? And how special is MS in it's design compared to gcp or aws? What is MS's response to the findings?
I have a pet-peeve for people that show up into an organization and find everything is done wrong without getting into the nuances and root causes so they can capitalize on the supposed failures for fame and glory. I don't know if that is the case here and certainly MS 's security track record and MSRC's response record is horrible but I am taking this report with a grain of salt.
The government does need to twist MS's arm a lot in my opinion. I've done an objective comparison of cloud provider security capabilities and Azure's is the worst by a large margin, too much nickle and diming to charge customers more for security.
I've done an objective comparison of cloud provider security capabilities and Azure's is the worst by a large margin [ . . . ]
My only experience with anything close to this is website SSL certs. Back in the day, we used to renew certs from once a year, to as long as once every five years. It was somewhat normal for certs to expire and things to go awry. Then Let's Encrypt came along with certs that expire in 90 days. I believe the thinking was that a shorter period would ensure that systems and org processes were always ready for certificate regeneration, to avoid outages.
My question is the case of Azure AD, is the design of a system where rotating a key would cause an outage, a bad design which is avoidable?
note: Please let me know if I am using any incorrect terminology, or not understanding a basic concept, in the interest of learning.
Bad example, since the krbtgt password needs to be rotated twice, since the old one is stored as well, precisely to avoid outages.
If only there were internal development resources that Microsoft could leverage to build a more robust system, maybe one that allows for phasing in of new keys, and not have to wait on external vendors to get around to improving security like the rest of us do.
This might be because it is almost impossible to tell where Microsoft starts and the government ends these days. Also remember that Microsoft was basically the pilot program for Prism.
Please don't self-peasantize or induce it in others.
For example, it notes that Microsoft do not know for certain how the attacker got in in the first place, but they and the government suspect (see 1.2.4 of the CISA report) it was a compromise of a laptop owned by an employee of Affirmed Networks, who Microsoft bought in 2021.
Are they saying, then, that the attacker was in their network for two years? Or that the attacker was someone able to leap from this laptop to Microsoft's identity systems (which would be very odd, since Affirmed were not in that business, so there would have been no reason for such a laptop to be anywhere close to Azure's insides).
One bright spot in the report, deserving of kudos, is that the folks at the State Department understood their monitoring tools and used them very well to uncover the anomaly that led to the discovery of this compromise.
I feel like this is a twist on the denial stage of grief. Sure, our house is on fire...but maybe it is because a asteroid just struck the earth.
The criticism here doesn't seem warranted. At an early stage of investigation, it seems prudent to iterate all possibilities, including grey swan events. This then allows to them to scale the investigation and delegate to various experts to address each hypothesis.
CISA Releases Report on Microsoft Online Exchange Incident from Summer 2023
The rotation isn't what stands out to me, it's the fact that the secret material wasn't on some HSM. Rotation can be tricky but why allow applications read access to the private key material at all.
Another fun problem is that their audit logs only log the identity of the person that triggered the event about 50% of the time. In many cases they mask or drop this field, which is the most important piece of data in such a log!
So for example a developer in our org pressed a button in an Application Insights troubleshooting wizard when his app ran out of memory. This “helpfully” doubled the size of an already huge server pool that had a reservation in it. We ended up paying $15K extra that month and never figured out who did it because the logged identity was some internal service account!