Merci à vous de suivre le flux Rss de www.sospc.name. ;o)<

Réjouissez-vous, Azamos et moi-même sommes de retour ! 😁 Oui, pour votre plus grand plaisir (enfin, on espère… 😁), nous vous avons proposé un live ce dimanche 5 Mars. Le live s'est déroulé ici : Lien direct : https://www.youtube.com/live/-nZxBrbpQFI?feature=share *** Pour voir ou revoir le live précédent de Décembre  : Lien direct pour voir le […]

Cet article Replay Live #28 on a répondu à vos questions en direct ! est apparu en premier sur votre site préféré www.sospc.name ;o)<

It has been a while since I took a question from a reader and turned it into a blog post. It is one of my favorite things to do here on ITProMentor, but the “busy-ness” of life has taken me away from the keyboard a lot in recent months. Now that I am (mostly) settled in a new home, I plan to rekindle some of these old joys.

This one came from Devin, who lives in the U.K.:

Hi Alex, I hope this message finds you well. I watched a recorded presentation of yours where you compared Conditional Access to a “Firewall for the Cloud,” but you mentioned that there are important differences. Specifically, you made the point that most firewalls have a “deny-all” rule by default, and it is up to the administrator to open the inbound ports that are necessary. In Conditional Access, you said it is almost the exact opposite, where everything is open by default, and you have to tell the system what you want closed.

This got me thinking, wouldn’t it be possible to start by creating a “deny-all” rule and then add other rules in front of that, to open the specific applications and access scenarios that you wanted, and no more? Wouldn’t this be more in line with the whole ‘Zero Trust’ concept?

Thanks for your insights!

–Devin, U.K.

Great question Devin, and I am glad that you asked it. No analogy is perfect, and it is actually because of these imperfections that the “firewall” comparison can be so illuminating. This will give us the chance to clarify a few things about Azure AD Conditional Access in general, and as well, offer some potential solutions to certain problems.

The first thing to remember is that Conditional Access differs from firewalls in another important way: there is no “ordering” to the rules. I cannot place one rule “in front of” another. All rules are evaluated simultaneously in Conditional Access. So, if I create a rule that says, “Block X,” it does not matter if that rule is located further up or down in my list. It will always be evaluated the same way. “X” will always be blocked.

This also implies that any “block” control always will always win over any “grant” control. Therefore, if I created one rule that said, “Block access to Email” (scoped to All users) and another one that said, “Grant access to email but require MFA” (either scoped to All users, or enabled for a specific security group), then guess what happens? Access is still blocked. In order to get the desired effect with these two policies, you would need to create a security group called something like “Email allowed users” and add that security group to the “Exclude” tab on the Block access… policy.

So, the answer to your question is both yes and no: it is possible to create “Deny-by-default” rules, but not exactly in the way you suggested. But in fact, this type of design (writing explicit block rules for everything then making many exclusions) would be unnecessary for most organizations. I will explain why shortly.

First, just notice that writing your “default deny” rule or rules quickly increases the complexity of your implementation. For example, you would need to manage double the policies and several security groups and exclusions for every access scenario you wanted to open/allow.

• Deny mobile access for all users / Allow mobile access for approved users
• Deny browser access from the desktop / Allow browser access from the desktop
• Deny client app access from the desktop / Allow client app access from the desktop
• Deny access to administrative services / Allow admin access
• Deny all guest access / Allow guest access to approved apps
• Etc.

I think these designs tend to get messy very quickly. You might say, so what? Why not do it this way?

Before we answer that question, let’s take a closer look at one of the other concepts I normally address during my talks on Conditional Access: the two so-called “Architecture types.”

Open (or targeted) architecture: This means targeting your policies to address specific access scenarios.  For example: “Require MFA for access to Office 365,” or “Require managed devices for access to Email.” In this architecture, you are putting specific requirements around certain applications or access scenarios, while leaving others “open” or unguarded (i.e.. you do not have policies covering “All cloud apps”).

Closed (or universal) architecture: This means targeting your policies as broadly as possible, for example All users / All cloud apps, e.g.: “Block legacy authentication globally,” or “Require MFA for all users.”

Closed architecture is better aligned to the concepts of Zero Trust since you are not leaving any “holes” or scenarios free of the constraints imposed by the policy. Note that it is also possible to combine these architecture types into a single policy set. For example, you may have a universal requirement for MFA across all cloud apps, but you only require managed devices for access to email, or certain other applications. That is completely fine and up to each individual organization.

Why Closed Architecture is more like Deny-By-Default

Now, let’s assume your goal is ultimate Zero Trust protection across all cloud apps, and that you want to impose both a multi-factor as well as a managed device requirement everywhere. In this case we require multiple policies for various reasons (e.g., easier troubleshooting, better for making more granular exclusions, and covering various access scenarios).

To begin, we need several policies enforcing the MFA requirement:

• Block all legacy authentication: legacy authentication is vulnerable to password spray and replay attacks, and it does not support MFA challenges, so we should eliminate it for all users and all cloud apps.
• MFA required for all admins: it is a best practice to have a policy covering this scenario even if you plan to place the same requirement against all users; that way, if the policy for standard users changes or needs to be temporarily disabled, admins are still protected.
• MFA required for all users: This is your universal MFA requirement for everyone
• MFA to register/join devices: We have a separate “User action” to control this behavior, as it is not covered by the “All cloud apps” selection above.
• Secure the security info registration page: We have a separate “User action” to control this behavior, as it is not covered by the “All cloud apps” selection above. Also, it is recommended to enable the Temporary Access Pass option so that users can still get in to edit authentication methods with help from an administrator, even in the absence of another factor such as a mobile app or hardware token.
• MFA for guests: Note that we can also trust MFA claims from other tenants, so that users are not double-prompted. If you have a policy for the guest access scenario, be sure to modify your default trust settings from Azure AD > External identities > Cross-tenant access settings.

And we need another policy set enforcing device-based requirements, for example:

• Grant mobile access with compliant device, or approved app, or app protection policy: for mobile devices like iOS and Android, you can choose whether to enforce MAM or MDM (or both).
• Grant desktop access with compliant device: we want desktop computers such as Windows and MacOS to be complaint with our policies and managed by the organization.

I suggest that this configuration achieves the “Deny-by-default” posture that we want, without needing to add another “Block” policy on top of it, with additional exceptions, etc. Let me explain why.

When you create a policy with access controls that say, “Grant access” and “Require X, Y or Z” then you could also read this policy as saying,  “Access is denied unless X, Y or Z can be met/satisfied.” Therefore, if you do not satisfy MFA, or do no have a managed device, and your policy explicitly says those things are required, then guess what? No access for you!* This is already “deny by default.”

(*By the way, if you target “All cloud apps” with a compliant device requirement, then you must also exclude the Intune enrollment app or else you will be unable to enroll new devices. It’s like a chicken-and-egg problem: you can’t get enrolled in the first place to become evaluated for compliance if there is a compliance requirement in order to get enrolled. Note there may be other impacts as well with other cloud apps when enabling closed policies.)

Additional Deny-by-default rules

Another popular policy set is to have broad “location-based” rules that “deny-by-default” except from approved countries or locations. Example:

• Block access from non-domestic countries: this policy is usually scoped to All cloud apps (closed), with a Block access control placed against All locations, excluding a named location containing the domestic country (e.g. USA, or wherever you live). Optionally, you can also use filters for devices to exclude managed devices (that way you can travel with devices that are already enrolled/managed)

And you can apply this concept to device platforms as well:

• Block device platforms that are not explicitly supported by the organization: in this policy, we block access for all cloud apps on all device platforms, excluding the platforms you intend to support. This has the effect of blocking platforms including ChromeOS, etc. as well.

Anecdotal story

Let me briefly relate another story that hopefully clarifies the point further. This one combines the concepts of Open architecture with a “Deny-by-Default” policy (for a specific application: email).

Recently a non-profit organization contacted me with a very particular request. They wanted to use Closed architecture for their core policies (i.e., block legacy auth & require MFA), and at the same time use Open architecture for their device-based policies, especially for personal (mobile) devices. The main concern was around corporate email on personal devices. Okay, that’s no problem, and in fact is very common. Here is the catch. They had a very specific on-boarding process whereby a user would not be allowed to gain access to their corporate email using a mobile app until they had completed an E-safety training module. HR would assign them to a security group shortly after passing the exam, and they would thereupon be granted access (but not before then). It was basically a carrot for completing the course material.

They did not want a closed architecture because the scope for this requirement was no wider than email (Exchange Online). However, they still needed a “fail closed” policy set for this application because they did not want a user to gain access on mobile devices before passing the exam. So here is what we did: We implemented the usual policy set for block legacy auth, MFA requirements, etc. Then for the device-based requirement, we only targeted Exchange Online, and used a security group called “Allowed to access email on mobile devices.” We then created two policies:

The first policy was called “Block access to email on mobile devices” and it was configured as follows:

• Users and groups:
  Include: All users
  Exclude: Allowed to access email + Emergency access accounts
• Cloud apps: Office 365 Exchange Online
• Conditions: Device platform > iOS & Android
• Access controls: Block access

Then the second policy was called “Allow access to email on mobile and desktop apps” and it was configured as follows:

• Users and groups:
  Include: All users
• Exclude: Emergency access accounts
• Cloud apps: Office 365 Exchange Online
• Conditions: Client apps > Mobile apps and desktop clients
• Access controls: Grant access w/ Compliant device or Approved App or App protection policy

Remember that all other access scenarios around this application are already covered by our “closed architecture” design for the MFA requirement, etc. This is an additional requirement that says access is granted only when the device is managed (MDM), or the app is protected (MAM), and when the user belongs to the proper security group (indicating they passed the E-safety course).

Now, in my opinion this configuration is not any “safer” or “more secure” than simply deploying the second policy and forgoing the first policy altogether. The reason we deployed both policies wasn’t “because security” or “because deny-by-default,” rather, we did this specifically to enable the custom workflow that they wanted to have, with the training pre-requisite. That’s it.

Conclusion

If your goal is to align your Conditional Access strategy as closely as possible with a ‘Zero Trust’ model, then you should probably be aiming for Closed architecture. However, a closed architecture approach may not be right for every organization and every application/access scenario. Whenever I implement Conditional Access, I always push closed policies for the basics: blocking legacy auth and enforcing MFA. After that, I think it is a good idea to begin evaluating device-based policies with regard to corporate email access specifically, and go further where it makes sense, even all the way to a closed policy set, especially in high-sensitivity or high-security environments. Just be aware there may be other impacts to certain applications (e.g. Intune enrollment, etc.).

Hopefully this cleared up the confusion for you, Devin. Thanks for writing in.

The post Reader Question: How can I set up a “Deny-by-Default” Conditional Access Policy? appeared first on ITProMentor.

Most of my readers will already be familiar with Microsoft Defender for Business (MDB), which is included with Microsoft 365 Business Premium. And a majority of those will be deploying MDB as one part of a broader security solution which includes other services within the Business Premium bundle. But a subset of folks have asked about the “Standalone” version of Microsoft Defender for Business.

Yes, it is true, there is indeed a standalone version (USD $3/user/month), which was announced last month. The use case? Consider a scenario where the customer is using a different productivity platform such as Google Workspace, or they haven’t yet made the transition to other Microsoft 365 services. Using the standalone SKU, you could theoretically onboard devices and start providing protection, ahead of deploying other services, and with far less upfront licensing commitment.

Some of the MDB-related services will function much in the same way as you are used to with the full product, however, you should be aware that certain services would only be available with an Intune license (Microsoft Endpoint Manager). For example, the “Automatic onboarding” option during the first-run wizard experience requires devices to be enrolled with Endpoint Manager already. As well, certain functionality in the Microsoft 365 Lighthouse product may rely on the presence of the Intune licenses in order to work. At the same time, some functionality within Endpoint Manager will still be available, even without the “complete” license set. In fact, just enough of the MEM product is activated to make basic policy deployment possible for the “standalone” scenario. Clear as mud, right?

Show me

Let’s take a look at an example where I have onboarded a new “standalone” device into a tenant where I also happen to have some “fully licensed” Microsoft 365 Business Premium users.

In the first place, I need to actually purchase and assign the standalone license product to the correct users. For this purpose, I created a new user named “Mark Twain” in my tenant, and assigned the MDB standalone product.

Next, we want to check on a couple of settings related to this scenario. Begin by navigating to Settings > Endpoints from the Microsoft 365 Defender Security Center, and click on Enforcement scope.

You will want to turn On the setting called Use MDE to enforce security configuration settings from MEM and select the OS choices below (and yes: Windows Server support is coming soon to the Business product).

Then, check Microsoft Endpoint Manager by navigating to Endpoint Security > Microsoft Defender for Endpoint.

Be sure that the option Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations is switched to On, and Save settings if necessary.

With those settings in place, let’s onboard a device named “Workstation10” using the local script method (you could also use GPO or other methods, but just note that you cannot use MEM to onboard the device in this scenario since the requisite license is not available and the device is not enrolled into the service).

Okay, now that the script has been run, we expect the device to show up in our inventory. Let’s take a look. We should be able to see it from the Defender Security Center:

Yep. And as well, from Endpoint Manager:

You will notice in both cases that there is a column called Managed by which will indicate whether the device is being managed by Intune or MDE (which is the Enterprise term for MDB). Those devices which are managed by MDE are the so-called “standalone” devices. You will also notice that not all the data are available for standalone devices, because they are not enrolled with Intune (therefore things like Compliance cannot be evaluated).

Finally, you will notice that we can still take all the same actions against standalone devices, such as Isolate device, Restrict app execution, Run antivirus scan, Collect investigation package, Initiate Live Response Session, etc.

I will also add that in addition to the device inventory and device actions, the Vulnerability management functionality that we have via the Microsoft 365 Defender Security Center is still available and visible for standalone devices.

Assigning policies

Let’s say you want to assign policies to your standalone devices. We can either use the Microsoft 365 Defender Security Center (you will find it under Configuration management > Device configuration), or we can use MEM. Since the purpose of this blog is to highlight the boundaries and limitations of MEM with regard to these standalone devices, let’s examine the option to assign policies from Endpoint Manager.

Start by creating a Dynamic device-based security group. Go to Groups, and create a new group. Name it something descriptive like “MDB Standalone Devices” or similar. Then, use the following expression to capture the devices managed by MDE:

• (device.systemLabels -contains “MDEJoined”) or (device.systemLabels -contains “MDEManaged”)

(Note: I have also observed that using the “All devices” option works as well when making assignments, but it can be useful to have a group that can identify for you which devices are managed by MDE/MDB, and not yet onboarded to MEM.)

Next we can create a policy and assign it to our new security group. The following policy types are supported currently:

• Antivirus
• Firewall
• Firewall rules
• Endpoint Detection & Response

I suspect we will see additional policy types supported in the future (e.g., Attack Surface Reduction), but at the time of this writing, the above is all that is included.

I created a simple Antivirus policy. Again this could also be achieved from the Microsoft 365 Defender Security Center, but I have elected to manage my policies in MEM instead for the purposes of demonstration.

Now, if I try to create and assign a policy that isn’t yet supported, such as Attack Surface Reduction rules, what happens?

As of now, we see that it just remains in a perpetual “Pending” state. I hope to see support for more policies soon, though. Fingers crossed.

Takeaways

So can the standalone product do everything that the MDB product can when bundled with a more complete subscription set such as Business Premium? No.

Certain policies and functionality would require the “full” license bundle including Azure AD Premium and Intune/MEM. For example, if you want to unlock features like the Conditional Access integration, and measure device Compliance, or if you want to view and managing additional device attributes. But it appears that Microsoft is attempting to open “just enough” functionality here to support a sort of “lite” management scenario of the MDE/MDB product via MEM, even if you don’t have an Intune license. (It is always best of course if you can move into the full experience with the complete license bundle).

In my opinion, we should at least get support for Attack Surface Reduction rules added both to the MEM for standalone scenario, as well as receive a new way to deploy these policies from the Defender portal (like we have with Antivirus and Firewall policies today). I do not know if/when this will happen, but my hope is that we will see it yet this year.

And that is basically the whole story in a nutshell, as of right now. Hopefully that cleared up some of the more confusing points. If we get additional functionality in the future, I will be sure to report back.

The post What are the limitations with Microsoft Defender for Business Standalone? appeared first on ITProMentor.

One of my readers wrote to me recently about an article that I penned a couple of years ago, on the topic of Data Loss Prevention in Microsoft 365. They pointed out that my breakdown was a bit dated now, and that the Microsoft universe seems to have become more complicated since then.

I suppose that’s true in some ways. I think some of this confusion was multiplied by the fact that many (if not all) of these products have new names now, such as the recent rebranding of the “compliance-related” features to Microsoft Purview. The other confusion points tend to revolve around licensing: “What is included in my subscription, and what requires an upgrade?”

I wonder if I can help those who are seeking clarity by taking another stab at this from a slightly different perspective.

There are many different risks associated with data leakage and/or loss of data. Each risk has a different set of possible mitigations, and most of the time we can find a solution within Microsoft 365. In fact, sometimes there is more than one technology solution in this suite of tools which could help us to address a particular area of concern. Let us examine a few common risk concerns that businesses may have, and apply the Microsoft 365 features that best help us to address these concerns. I will also highlight the features that require a full E5 subscription, versus the more common Business Premium or E3 that we tend to see in the SMB space.

Concern #1: Loss or theft of a device with access to corporate data

This is the first concern I normally ask small businesses to address. If a device were to fall into the wrong hands, wouldn’t you want to be able to wipe the corporate data from it? There are several solutions to this problem.

The first is App protection policies (a.k.a. MAM policies). This would be the minimum recommended mitigation for most small businesses, and more specifically with regard to personally owned iOS and Android devices. Although these policies are also available for Windows devices, it is more difficult for me to recommend this option (for Windows, this turns on a feature known as Windows Information Protection, which ends up being a difficult user experience for most people).

We will soon have a new App protection policy for the Edge browser on Windows; when combined with a Conditional Access policy, this would allow us to grant access on personal Windows devices via the Edge browser (using a corporate profile), while blocking access from client applications such as Outlook or the OneDrive sync client. Therefore, no company data would persist on the device itself. You can already accomplish a similar outcome using something called Conditional Access App Enforced Restrictions, which enforces ‘limited web access’ where downloads are prohibited on unmanaged devices, and this works on any device platform or browser.

Another option that I generally recommend is requiring devices to be enrolled and compliant with corporate policies in order to gain access to corporate data in the cloud. This is accomplished with a combination of Compliance policies, and Conditional Access policies. I always require this at least for Company-owned devices, but this can be made mandatory for personal devices as well if you prefer. This way, not only do you have remote wipe capability over the device, but you can enforce specific rules and settings as well, including  rules to reduce other risks such as malware, for example, by deploying Microsoft Defender policies like Antivirus, Attack Surface Reduction, and Endpoint Detection & Response (at which point you are addressing risks well beyond data loss).

Controlling access to corporate data on managed and unmanaged devices can be accomplished with Business Premium or E3 subscriptions, but if you happen to have E5, some additional scenarios open up. For example risk-based Conditional Access policies that apply certain restrictions only when risk is detected.

Concern #2: Oversharing of sensitive information stored in the Organization

Some types of information should not be shared externally, or at least not widely outside the walls of the Organization. For example Social Security Numbers, or other Personally Identifiable Information (PII) are often considered sensitive information which should be shared more carefully. The same can be said for financial information like credit cards, bank account numbers, and so on. Sometimes these information types are even regulated by certain laws whether local or state or federal/nation-wide.

To address concerns with handling sensitive information within the Microsoft 365 service, we can write rules using Microsoft Purview Data Loss Prevention that can help us monitor and govern how these data types are to be shared and sent outside the Organization. In most subscriptions (e.g. Business Premium, E3) this includes common services like email and file sharing, meaning we can have rules which are triggered when sending emails or links out of OneDrive or SharePoint. With an E5 subscription we gain rules for additional services such as Teams chat and channel messages, and even on-premises file severs.

Usually the rules we write include such common scenarios as notifying an administrator when something sensitive has been shared, or filing an incident report. As well, we can take actions to automatically encrypt emails containing sensitive info, or we can block certain types of data from being shared at all. Any of these rules can be accompanied by notifications or “policy tips” which display warnings to the end user when sensitive information is being shared in a way which triggers the rule.

Concern #3: Movement of sensitive data from a device to an unapproved app or location

This is sort of a sub-concern of #2 above. Sometimes organizations will want to prevent the movement of certain sensitive data types on an endpoint, for example, to prevent sensitive information from being copied off to a USB storage device, or printed to a network printer, or uploaded to an unapproved cloud service.

For these types of rules, App protection policies can once again come to the rescue. I normally turn these features on for iOS & Android devices, and, as I mentioned before, Windows Information Protection is available as an option too, but I generally shy away from implementation of WIP for various reasons. Within all of these policies, we have the ability to block copy/paste and save to unmanaged apps and storage locations. Sort of like an “Endpoint DLP Lite.”

And that brings us to the “Premium” E5 subscription: here Microsoft offers Endpoint DLP, which brings some more granular DLP controls down to Windows devices only, and these can even be extended to Google’s Chrome browser using the Microsoft Purview Extension (note: all of this is still included under the umbrella of Microsoft Purview DLP, but again you need an E5 subscription to unlock it).

Concern #4: Control of sensitive information once it leaves the Organization

There are cases when sensitive information needs to be sent or shared beyond the boundaries of the organization. And in these cases, we want to ensure the data can still enjoy some protection once it moves beyond our control, to an unmanaged device for example, or to an outside party.

The flagship solution in this space is Sensitivity Labels (part of Microsoft Purview Information Protection). Labels which define Sensitivity can have a lot of different powers attached to them. Sometimes they may do nothing more than mark a file visually with something like a header, footer, or watermark. In other cases, we may want to apply encryption, so that the recipient of the file or email message will need to sign-in before they can read or work with the information. Encryption can also be accompanied with permissions that restrict certain capabilities (for instance we can prevent exporting or printing the data).

Other powers include being able to restrict certain sites or groups (including Teams) with rules like, “Unmanaged devices cannot download, print or sync the contents of this site.” Further, Sensitivity labels can be used as a condition when writing our rules in Microsoft Purview DLP.

Finally, it is possible to automate the application of Sensitivity labels under various circumstances. For instance, we can scan for and label data at rest using auto-labeling policies. Otherwise, we may want to apply or even just “recommend” that a certain label be applied using the auto-labeling settings within the label itself. Or, only apply labels under specific conditions, such as when a file containing sensitive information is downloaded to an unmanaged device from a managed cloud application (including third-party apps like Box or Google); in this case we would need to layer on an additional solutions, for example Microsoft Defender for Cloud Apps.  Most of these auto-labeling capabilities will require the E5 subscription, of course, or another add-on which includes these features such as Microsoft 365 E5 Compliance.

Another “premium” auto-labeling feature (read: E5) includes the ability to use trainable classifiers to recognize information that you want labeled in a certain way. With this solution, you feed examples to Microsoft Purview so that it can “learn” what you consider sensitive data. This gives you some capability to move beyond the common preset information patterns like Passport Numbers, Social Security Numbers, Credit Card numbers, etc. that you get with the standard DLP features.

Concern #5: Insider Risks

Some businesses may have a higher level of concern around insider risks such as:

• Data theft by departing users
• Data leaks by disgruntled users
• Insider trading
• Intellectual property (IP) theft
• And more

Microsoft 365 E5 includes a Microsoft Purview solution called Insider Risk Management with several policy templates that can help you detect and take action on these types of events. This is an example of a more “advanced DLP” solution that also relies on additional components of E5 such as Microsoft Purview eDiscovery (Premium).

Since these are all dependent on more expensive subscriptions, most small businesses will choose to handle these risks in an alternative way. For example: by having a strict written policy, and leveraging the standard Microsoft Purview DLP rules to monitor or alert on the movement of sensitive data.

Conclusion

Here we presented a few examples of common risk concerns around data loss or leakage, and how each of these concerns can be addressed or mitigated using one or more possible technology solutions available within Microsoft 365. When you get into more advanced DLP scenarios, especially involving more automation, or control over third-party cloud apps, or insider risk management scenarios, etc., then we are talking about the more expensive Enterprise E5 subscription. The below table is an updated breakdown of the landscape today:

I think this is a simpler summary, which is perhaps even easier to understand than what I previously published. I can’t say it is completely exhaustive, but it’s a pretty good overview of the most common risk concerns and the associated solutions that we tend to  implement.

The post Making sense of the many DLP options for Microsoft 365 appeared first on ITProMentor.