Can Microsoft legally replace Baseline Policies with Security Defaults in Feb 2020?

[cjmod]

Earlier this week, we reviewed our company's Baseline Conditional Access Policies and were greeted with the following message (screenshot attached)

Baseline Protection policies are a legacy experience which is being deprecated. All Baseline Protection policies will be removed on February 29th, 2020. If you're looking to enable a security policy for your organization, we recommend enabling Security defaults or configuring Conditional Access policies.

We then reviewed the Program Guide linked on https://docs.microsoft.com/partner-center/csp-documents-and-learning-resources, & noticed that section 1.4 paragraph 2 and 3 state (screenshot attached):

effective as of August 1, 2019, Company must, and must require its Indirect Resellers, as applicable, to, enable a multifactor authentication service in accessing any Microsoft Commercial Cloud portal or any underlying service. Further, starting on this date any software application that is used to access the Partner Center API must adhere to the Secure Application Model, which is made available on Partner Center.

The requirement to enable a multifactor authentication service may be fulfilled by either (i) Company’s enablement of both the “Baseline policy: Require MFA for admins” and the “Baseline policy: End user protection” in the “Azure Portal” for all users; (ii) Company’s purchase of a Microsoft offer that includes a multi-factor authentication service (for example, “Azure Active Directory Premium”); or (iii) Company’s purchase of a third-party “on-premises” multi-factor authentication service that supports Azure Active Directory federated services.

Based on this, we're in full compliance with Microsoft's Partner Security Requirements.

However, with Security Defaults, the requirements have changed and now require us to block legacy authentication, which will prevent the use of App Passwords unless we purchase Azure AD Premium (as stated here in the Answer to Issue 5). In addition, any partner that enables Security Defaults will have all Baseline Policies immediately removed from their tenant, with no way (that we can see) to restore them without purchasing Azure AD Premium to create their own Conditional Access Policies.

We understand Microsoft can update these requirements at any time & are fine with that. The issue we have is that we're supposed to be given a 180 day notice, as stated here in Microsoft's Partner Agreement Legacy Comparision (screenshot attached).

So my questions are:

1. Can Microsoft legally replace Baseline Policies with Security Defaults in Feb 2020?
2. Why were we not given a 180 day notice of this change?

Baseline Conditional Access Policy NoticeProgram GuidePartner Agreement Comparison

[JanoschUlmer]

I would advise to discuss this with the account team or a legal advisor. I can not (not allowed to) give legal advice in this forum. 

My understanding is that security defaults are a technical successor to baseline policies, so an applicable replacement to baseline policies from technical perspective even though it works a bit different in some regards. But that is just the technical perspective.

[cjmod]

@JanoschUlmer: Can you help us understand why we were not given a 180 day notice of this change?

[JanoschUlmer · Accepted solution]

@cjmod : I can only guess, I'm not part of the CSP program team.

As far as I understand - The MPA agreement has not been changed (this is where a 180 advance notice would be required), and for preview services  (e.g. the baseline policies) there is no SLA or commitments how they are being available.  

[Jethro]

there is a major technical difference in the application of baseline (or customised) conditional access policies and the security defaults.

And that is breakglass admin accounts.

I have two breakglass global admin accounts including my onmicrosoft.com account that are not MFA enabled deliberately and are excluded specifically in my conditional access policy. I believe that meets the previous requirement (as advised by MSFT employees)

However if i turn on the security defaults i have to turn off the conditional access policy and i would have to enable MFA on these two accounts.

So i have not turned on security defaults.

This whole process seems rushed and not without due thought to how actual partner practices need to operate.

I would appreciate feedback. Currently we have 97% of user accounts complying ( these 2 accounts are the exceptions)

TIA

[JanoschUlmer]

@Jethro  This has been documented in the FAQ since summer 2019 - no exclusions for break glass admin accounts:

https://docs.microsoft.com/en-us/partner-center/partner-security-requirements-faq#how-do-i-configure-an-emergency-access-break-glass-account 

So an exclusion from MFA does not meet the requirements. And if your report shows 97% it means you are using the break-glass acount for daily business (Partner Center operations), which is imo also not exactly best practice for emergency accounts, they should only be used .. in emergency. 

The baseline policies also did not offer the ability to use exclusions (only if you used the preview and set exclusions before June 2019) - for any exclusions custom conditional access need to be used and sec. defaults should not be enabled then. With respect to best practices for emergency accounts - make sure this account has multiple methods for the 2nd factor (Phone + multiple apps, e.g. MS Authenticator + 3rd party token app), you can configure one admin with user-based MFA instead of conditional access, and you can consider using a 3rd party MFA service for some admin - so that a loss of device with the token app, a service problem with a certain notification method, an issue with the conditional access rules engine, an issue with Azure MFA service does not cause issues. But exclusing the users from MFA alltogether is not fulfilling the requirements documented in the Partner Agreement.

[Jethro]

thanks for the reply and link - which i had previously read back in 2019.

To be clear its the user accounts that are at 97% - admin usage is 100%. these accounts are not being used used.
The whole point of break glass accounts is they cant be MFA at all. What if I (primary admin) is tied to these accounts and MFA breaks or im not available. other users cant access them. I really dont get how a policy intended for large organisations with dedicated IT teams can be applied to a partner practice with one Global Admin and emergency access for the case of my non availability, death, incapicity etc.

I guess ill have to reluctantly enable MFA on them - and hope i never die.

[JanoschUlmer]

@Jethro : The whole point of a break glass admin is to make sure that you do not make you dependent on a single person or single login option as far as possible - and this always had and will ever have a very fundamental limitation - if the AzureAD service does not work, there will be no login possible. So it never was a 100% failsafe system for all scenarios where things can break, as always there where dependencies on services to work. The only thing that has changed is that there is one more dependency, by using a 3rd party MFA you can even still remove this dependency if you want.

Break glass admin is not to only have one global admin, and it does not say only a single person should have access to the 2nd factor. 

So make sure the global admins use different MFA services and/or  that at least they have multiple options to provide the 2nd factor not bound to the availability of a certain person or a certain device.

[Jethro]

i did not realise you can tie MFA to multiple devices - can the be on different mobile phone numbers? or through different app installs?

What happens if one person approves and someone else denies?

[KevinNSTA]

I know this is a late response, but in addition to the Multiple copies of the Microsoft Authenticator app or other TOTP Apps - you can also use Hardware Tokens for TOTP - I like Token2 - and that same process of "Hardware" tokens can work for you to set a specific account to use a specific Token from the Admin side (Instructions) 

We use this to keep MFA Keys for our Break-Glass admin accounts in our Password Manager as well - to have Auditing of anyone trying to access it. 

You can also use their Virtual Token to test it yourself or their hosted copy of it.

[JanoschUlmer]

@Jethro: You can enter a mobile phone number and a office phone number, and you can configure a different phone for text messages.

You can also add multiple apps, the issue might be that it is difficult to differentiate the apps you have registered.

If you e.g. registered MS Authenticator and Authy, you can easily differentiate this - one method will be label "Send notification", the other, Authy,  "enter code from an app". But if you registered multiple MS Authenticator apps, both will be labeled the same.

The notification will only go to a single device/phone number, not all apps will get a notification at the same time. When doing the login where you get prompted for using the default method or choosing another method for the 2nd factor - even when you accidentially use the wrong method, you can try again.

[Jethro]

While I understand the need for MFA and preach it to my clients, it often is unwieldy and annoying. when multiple people need access to an account (and shared mailboxes do not always cut it) MFA becomes very problematic.
Adding different methods but not having any way to change them without signing in and using the existing method is pretty much pointless.

haviong access on multiple devices would be awesome if you could actually have it go to multiple devices. eg if i am without my phone (which happens often) my ipad might be suitable.

my staff access and use my phone also and i also have many clients who have shared access to tablet devices.

the primary problem with MFA stems from an assumption that every user has their device on them at all times. this is simply just not the case and makes implementing MFA in these shared use scenarios complex and problematic.
Even more of a problem is that we custom setup machines for our clients remote access staff (not using autopilot) and we then have to coordinate MFA with them for an entire machine setup process. Its actually easier to turn it off and do it. We work in a country with lots of areas that do not have mobile service and so a customer might be underground in a mine or in a remote area with no service. If I am setting up their new PC I cannot get access to them for constant MFA approvals.
MFA in these scenarios (and there are many more) is just a pain in the backside.

[JanoschUlmer]

@Jethro :

haviong access on multiple devices would be awesome if you could actually have it go to multiple devices. eg if i am without my phone (which happens often) my ipad might be suitable.

And this is possible. You enter your password, you get asked to do MFA, you click on choose "Sign In another way" and you get the notification of choice. Attached screenshots on how it looks when both MS Authenticator and Authy are registered.

my staff access and use my phone also and i also have many clients who have shared access to tablet devices.

From compliance perspective I personally would consider this to be a problem alone (actually - using the same device is not a problem, using the same account would be). 

For the tablet devices, for the local logon - how is MFA involved? And if it is about using Office365 on those devices - if you are talking about a customer MFA is not mandatory for all and you could maybe work around using conditional access policies. Finally, you could even use apps like Authy in a browser, on the tablet.

the primary problem with MFA stems from an assumption that every user has their device on them at all times. this is simply just not the case and makes implementing MFA in these shared use scenarios complex and problematic.

The basic principle for security is that every user has their own account, so you can identify the specific user actions. When using delegated admin as CSP Partner you can easily have every employee use their own, distinct account for end customer managementfor daily work. 

You could also think about providing token hardware. 

To get security, the users need indeed to follow certain practices - my employeer rightfully assumes that at all times I wear my badge when in the office. The carmakers expect that drivers all times have a car key. So I don't think the ask to carry the security token solution with them is too problematic, but maybe this is just me 🙂

If you break this concept of each person having their own account, it will indeed become more complicated - but since you can easily add multiple methods you can also implement an additional method on a shared device (e.g. deploy a VM accessible for everyone, deploy Authy on it, let all users access it via RDP). Set up a phone number that rings in the office...  Of course this would be far from a best practice and I guess this way you would have issues getting compliant to secure operating principles like defined in ISO27001, but you can do this.

Even more of a problem is that we custom setup machines for our clients remote access staff (not using autopilot) and we then have to coordinate MFA with them for an entire machine setup process. Its actually easier to turn it off and do it. 

Not sure I understand the relation to MFA for partner - you refer to AzureAD join clients? The registration login would be done with a user account from the customer tenant (hopefully), and in the customer tenant MFA is not mandatory. Also you could use conditional access policies to make this easier if the user account is set up for MFA in normal cases. 

We work in a country with lots of areas that do not have mobile service and so a customer might be underground in a mine or in a remote area with no service. If I am setting up their new PC I cannot get access to them for constant MFA approvals.

If the device has no connectivity, and thus you are using local accounts - how is Azure MFA involved? Not saying that for every scenario there is a perfect answer - I would like to understand the problems with the PC setup better

[Jethro]

@JanoschUlmer some clarification

when i set up a client PC i use their credentials to set it up - as a company machine using the microsoft 365 account. I do it for them because getting them to do it is like giving the keys to your mercedes to a 16 year old who just got their licence. this way i know th emachine is setup correctly, office is installed correctly and configured for all their access. many people here hate computers, hate passwords, write them all down in notebooks and dont want to use their personal phones for work.
we have evolved ways of working with our micro business clients that get around these requirements and setting up their pcs for them is one way to do this. if they dont have access to mobile service while im doing this tying the MFA on their account to their device is pointless.
re multiple user access
many clients use . share the same device / account. EG. LOB apps that have a user account sign in for their app on a tablet. and all users can share that tablet. For example a real estate agencyu that has multiple staff who do property inspections using the same tablet and user accounts. they also all access the same generic email account. It is not practical or even possible to give them their own user accounts.
re delegated admin
we never use it. i always connect as the actual superadmin account.

[cjmod]

@Jethro: I would encourage you to read the thread linked below, as it specifically discusses your approach of using your customers' Global Admin account to access their tenant.

Link: https://www.microsoftpartnercommunity.com/t5/Control-Panel-Vendors-CPVs/Should-CPVs-allow-CSPs-to-access-customer-tenants-using-customer/m-p/11777#M34

[Jethro]

Thanks - lets hope they dont change this!

[JanoschUlmer]

I personally would do this differently in several aspects, but this is a different discussion. If you you use the customers account the mandatory MFA for you as Partner will luckily not interfere with your approach.

[AndyCooke]

I agree. The notion of 'just enable' security defaults is likely ill / incorrect advice.

I think what MS are really saying to partners, is that you musth ave xx% of using MFA. How you achive this, should be flexible.

Things like breakglass, 3rd party MFA, conditional access etc are not really discussed in the high level guidance.

[Jethro]

we never enabled the baseline security policies anyway but made conditional access ones that were specific and more flexible. now we are either unable to use those if we enable security defaults, or must not have excluded users. the whole point of emergency access accounts is for an emergency. having them tied to some users phone who might be overseas or uncontactable is pointless.

Partners are probably more security conscious anyway - its our job!

[JanoschUlmer]

@Jethro If you never enabled the baseline policies and already worked with CA, why do you now want to start enabling the Security defaults?

Again, you do not need to enable those if you already protect all user accounts with MFA by some other method.

And, as mentioned in my answer above, you don't need to tie it to only one device, you can have multiple devices as 2nd factor for a single account, you can for example also deploy TOTP apps like authy on a Virtual machine onpremises where the emergency admins have access, you can provide a phone number (office phone) as 2nd factor. There are so many options to overcome this "problem"...

[Jethro]

i didnt want to enable security defaults, but if i didnt i was going to be marked as non compliant.