The Cybersecurity and Infrastructure Agency (CISA) in the United States of America is responsible for providing guidance to all United States government agencies and critical infrastructure.

On October 17th 2022 an initial draft (version 0.1) was released (here) for the minimum security configuration that “SHALL” or “SHOULD” be applied to Microsoft 365 Defender. 

The draft guideline states:

“Generally, use of Microsoft Defender is not required by the baselines of core Microsoft 365 products (Exchange Online, Teams, etc.); however, some of the controls in the core baselines require the use of a dedicated security tool, such as Defender. This baseline should not be considered a requirement to use Defender, but instead used as guidance for how these requirements could be met using Defender, should an agency elect to use Defender as their tool of choice. In addition to these controls, agencies should consider using a Cloud Access Security Broker to secure their environments as they adopt zero trust principles”

So in other words, if you are going to use Defender to secure Microsoft 365, then CISA has provided guidance on minimum security.

After reviewing the recommendations, my first suggestion to CISA is to update the title of this document to reference the specific product name that they are issuing guidance for. For example, the cover page states “Microsoft 365 Defender” which refers to a suite of many products, whereas the baseline recommendations included in the document seem to only reference one single Microsoft product: Microsoft Defender for Office.

In other words, if CISA intends to issue security baseline recommendations for the entire suite of M365 Defender, then this initial baseline is lacking recommendations for Defender for Endpoint, Defender for Identity, and Defender for Cloud Apps.

Let’s review each of their recommendations for a MDO security baseline.

Baseline 2.1 “Preset Security Profiles SHOULD NOT Be Used”

The very first recommendation is that you “SHOULD NOT” use the preset email security profiles in Microsoft Defender for Office (MDO) (Standard or Strict) which means you must instead customize each EOP + MDO setting.

CISA states “the preset security profiles are inflexible.“

Fortunately, they did not use the “SHALL” language because many organizations would benefit from the Standard and Strict preset profiles. These profiles will be adjusted over time by Microsoft to respond to threats on behalf of organizations.

For organizations that lack experience administering Office 365 then the preset policies will be less risky than untrained administrators attempting to customize each and every setting, because complexity is the enemy of security. The preset policies are very good in my opinion and they can greatly simplify the administration of email security policies if an organization decides to use Defender for Office.

So I recommend that CISA change this to the opposite, so that Preset Profiles SHOULD Be Used. Otherwise, CISA is going to have to come up with guidance on dozens of individual settings, and their guidance will quickly become obsolete as Microsoft continuously innovates and develops new features and old settings are deprecated.

Another reason that CISA should recommend to use the Preset Profiles is because the US Federal Government should have a clear standard that all email security settings are based on. If they are going to say “don’t use the preset configuration” then they need to exhaustively list a recommended configuration for each setting that has security implications. 

If CISA does not agree with the recommendations in the Strict or Standard policies, they should at least state which specific recommendations they disagree with.

Baseline 2.2 Data Loss Prevention

This recommendation is more strongly worded, that DLP “SHALL” be enabled. In other words, you don’t have a choice, get ‘er done!

However, it does not specify which confidence level should be used to block PII (Credit Card, TIN or SSN). For example, a high confidence block of SSN requires a strongly formatted SSN (xxx-xx-xxxx) and a keyword like “SSN” within 300 characters of proximity, whereas a low confidence block of SSN is an unformatted string of numbers like xxxxxxxxx (resulting in higher false positives, but provides a lower risk of data leakage). Presumably this nuance is left to the individual agency to decide but that should be made more clear in this document.

Two of the bulleted requirements require Endpoint DLP to be configured:

• “A list of apps that are not allowed to access files protected by DLP policy SHOULD be defined”
• “A list of browsers that are not allowed to access files protected by DLP policy SHOULD be defined.”

I recommend that the document call out that these two bulleted items require the Endpoint DLP product because it has the higher M365 E5 or G5 license. Endpoint DLP is considered a ‘Suite Feature’ included when the M365 E5 package is owned. As far as I know it is not possible to license Endpoint DLP separately.

The section 2.2.4 Implementation neglects a very important step of onboarding computers into Endpoint DLP. This should be added in order for the two bulleted items above to work properly.

Section 2.3 Common Attachment Filter Policy incorrectly states that a MDO Plan 1 or Plan 2 license is required. That is not correct, the common attachment filter is freely included in all EOP license plans (any license plan bundled with Exchange Online). Basically, just mirror the language used in section 2.6.3

Section 2.4 – the Zero Hour Auto Purge for malware should be changed so that it reflects the stronger “SHALL” language because when a file signature matches Malware, it is bad and in my experience Microsoft has a very low false positive rate for malware. Also later in section 2.6.1 the ZAP feature is listed as having the SHALL language, so section 2.4 should be updated to match the 2.6.1 policy recommendation for consistency.
Also, it incorrectly states that a MDO Plan 1 or Plan 2 license is required. That is not correct, the ZAP feature is freely included in all EOP license plans (any license plan bundled with Exchange Online). Basically, just mirror the language used in section 2.6.3

Section 2.7 – I recommend Safe Link policies use the stronger “SHALL” language rather than the current “SHOULD” language, effectively for the same reason why Safe Attachments in Section 2.8 have the “SHALL” language.