back to article Under CISA pressure collab, Microsoft makes cloud security logs available for free

Microsoft announced on Wednesday it would provide all customers free access to cloud security logs – a service usually reserved for premium clients – within weeks of a reveal that government officials' cloud-based emails were targets of an alleged China-based hack. Microsoft wrote on its blog it was expanding the service's …

  1. Pascal Monett Silver badge

    "a step in the right direction"

    A small step for Borkzilla, a giant leap for cloud network administrators.

    And it took a breach to make that available. The fact that retaining cloud log ability had been considered acceptable by a provider is not really surprising. The fact that potential customers found that acceptable is just the demonstration that it is not technical people that wanted The CloudTM to happen, it was the CEO's nephews and the bragging rights that it erroneously conferred.

    Any admin worth the name would have seen the paltry amount of tools at his disposition, compared to what he had available with his on-prem servers, and scoffed at the idea that he should hand over his data to a server he barely had any control over.

    Except nobody asked the admin's opinion in the mad dash to be the coolest cloud kid on the block.

    Well, at least now some semblance of sanity is emerging from the morass.

    1. Danny 14

      Re: "a step in the right direction"

      dont get me started on how shitbag azure logging is. even a lowly 2 node on prem cluster is a cost burden if you go with the default recommended windows admin center azure logging. The only other free option I knew of was WUFB logging (but not email alert).

      id rather powershell the shit out it to a syalog server just to spite them.

  2. John H Woods

    "forging tokens"

    Not really forging is it? It's signing them with a stolen key whose theft had gone undetected and which should never have been valid for signing them. I think it makes it slightly worse that the key was inactive and should have been revoked, or at least deleted, long ago.

    1. diodesign (Written by Reg staff) Silver badge

      Re: "forging tokens"

      That's how Microsoft described, but yeah, if you're interested in the specifics, they're in the linked-blog.

      C.

    2. Michael Wojcik Silver badge

      Re: "forging tokens"

      Depends on your definition of "forging", I suppose. In some contexts, it's used to mean something along the lines of producing a document that falsely attests to provenance and authenticity, regardless of the document's accuracy in other respects. Under that sort of definition, using a key that's shouldn't be authorized for this purpose would be a sort of "forging".

      In the forensics and cryptoanalysis of PKI-based attacks, "forging" seems to be used in a number of ways, so I can't really fault Microsoft for their use of the term here.

      But your point is good, in that it helps to provide technical accuracy.

  3. Ken Moorhouse Silver badge

    I've seen mainframe core dumps...

    ...that are more intelligible than Microsoft logs.

  4. Concrete Gannet

    These two paras in https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

    are very scary. (MSA is a Microsoft account, so the self-service identity you can create whenever you want, for example by creating a new mailbox on outlook.com) .

    "Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident – including the actor-acquired MSA signing key – have been invalidated. Azure AD keys were not impacted. The method by which the actor acquired the key is a matter of ongoing investigation. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. This issue has been corrected."

    "As part of defense in depth, we continuously update our systems. We have substantially hardened key issuance systems since the acquired MSA key was initially issued. This includes increased isolation of the systems, refined monitoring of system activity, and moving to the hardened key store used for our enterprise systems. We have revoked all previously active keys and issued new keys using these updated systems."

    They're not owning up to how the key was obtained. Either a Microsoft employee stuffed up, or a vital key management system was compromised. Either one is bad news.

    By "inactive", do they mean they were leaving older keys lying around when they weren't actively using them, so they would be less likely to notice if an attacker had obtained that key?

    It seems up until now they thought it was OK to manage their signing key for personal accounts in a sloppier way compared to the accounts within an organisation's Azure AD (Azure AD is currently being renamed to Entra). And yet that key was able to be used for signing Azure AD tokens!

    I think this is a big deal and Microsoft are lucky - there could easily have been a larger and more vehement response and criticism. They really need to do better.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like