Have you ever received a lot of email in your Exchange service that are tagged as “spoofed DMARC”, and is your SOC concern about the increase of spam and phishing attacks? Well, let me try to clarify by sharing some details on what how Microsoft 365 handles inbound email that fails DMARC. If the DMARC policy of the sending server is p=reject, Exchange Online Protection (EOP) marks the message as spoof instead of rejecting it. In other words, for inbound email, Microsoft 365 treats p=reject and p=quarantine the same way. Admins can define the action to take on messages classified as spoof within the anti-phishing policy.
Microsoft 365 is configured like this because some legitimate email may fail DMARC. For example, a message might fail DMARC if it’s sent to a mailing list that then relays the message to all list participants. If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they’ll be marked as spam and not rejected. If desired, users can still get these messages in their inbox through these methods:
Users add safe senders individually by using their email client.
Admins create an Exchange mail flow rule (also known as a transport rule) for all users that allows messages for those particular senders.
An allowed spoofed sender in the spoof intelligence insight or a blocked spoofed sender that you manually changed to Allow to spoof only allows messages from the combination of the spoofed domain and the sending infrastructure. It does not allow email from the spoofed domain from any source, nor does it allow email from the sending infrastructure for any domain. For example, the following spoofed sender is allowed to spoof: Domain: gmail.com and Infrastructure: tms.mx.com
Only email from that domain/sending infrastructure pair will be allowed to spoof. Other senders attempting to spoof gmail.com aren’t automatically allowed. Messages from senders in other domains that originate from tms.mx.com are still checked by spoof intelligence, and might be blocked.
When considering products or services for handling an agency’s information, it is common to see two variations of FIPS accreditation: FIPS validated and FIPS compliant. Although they seem similar, there are different implications with these two labels.
FIPS Validation means a product has undergone and passed detailed conformance testing at an accredited national laboratory.
FIPS Compliance means that different components of a product have received FIPS validation, but the product in its entirety has not passed testing or has not been tested at all.
Why is being FIPS 140-2 compliant important?
One of the many reasons to become FIPS compliant is due to the government’s requirement that any organization working with them must be FIPS 140-2 compliant. This requirement ensures government data handled by third-party organizations is stored and encrypted securely and with the proper levels of confidentiality, integrity, and authenticity.
Using services or software without these tested methods in place could lead to a massive breach in security, causing problems for every person in the nation.
Who needs to be FIPS compliant?
The main organizations that are required to be FIPS 140-2 compliant are federal government organizations that either collect, store, share, transfer, or disseminate sensitive data, such as Personally Identifiable Information. All federal agencies, their contractors, and service providers must all be compliant with FIPS as well. Additionally, any systems deployed in a federal environment must also be FIPS 140-2 compliant. Many organizations follow FIPS to ensure their own security is up to par with the government’s security. Many other organizations become FIPS 140-2 compliant to distribute their products and services in not only the United States, but also internationally. As FIPS is recognized around the world, any organization that possesses FIPS compliance will be seen as a trusted provider of services, products, and software. Some fields, such as manufacturing, healthcare, and financial sectors, along with local governments require FIPS 140-2 compliance as well.
Step 1: Ensure FIPS 140-2 validated cryptographic modules are installed
Step 2: Ensure all security policies for all cryptographic modules are followed
Step 3: Enable the FIPS security policy
Step 4: Ensure that only FIPS validated cryptographic algorithms are used
While you may be running the right algorithms, without the Microsoft Validated process in place, you will not be in a validated compliance mode, which could potentially affect your certification process.
Specially for Bitlocker, you can configure the Federal Information Processing Standard (FIPS) setting for FIPS-Mode. As an effect of FIPS compliance, users can’t create or save a BitLocker password for recovery or as a key protector. The use of a recovery key is permitted. However, the policy must be enabled before any encryption key is generated for BitLocker. When this policy is enabled, BitLocker prevents creating or using recovery passwords, so recovery keys should be used instead.
To enable FIPS-Mode, Windows provides the security policy setting, System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing. This setting is used by some Microsoft products to determine whether to run in FIPS mode. When this policy is turned on, the validated cryptographic modules in Windows will also operate in FIPS mode. This policy may be set using Local Security Policy, as part of Group Policy, or through a Modern Device Management (MDM) solution.
Intune: FIPS-Mode can also be enabled directly via Intune under the Configuration Profile (as shown in the image below)
As far as Microsoft validations processes for cryptographic algorithms, the cadence for starting module validation aligns with the feature updates of Windows 10 and Windows Server. As the software industry evolves, operating systems release more frequently. Microsoft completes validation work on major releases but, in between releases, seeks to minimize the changes to the cryptographic modules.
ON another note, FIPS 140-2 modules can remain active for five years after validation or until 21 September 2026, when the FIPS 140-2 validations will be moved to the historical list. I am not aware of that validation process for FIPS 140-3 has started or not. However, I don’t expect to see much information available publicly since the current validation process is still active until 2026
For more information about FIPS 140-3, visit the following information.
If you are deploying Microsoft Defender for Cloud (MDfC) on your servers (previously known as Microsoft Defender for Servers) you are probably using the built-in vulnerability assessment tool as described in the Integrated Qualys vulnerability scanner for virtual machines article. This Qualys tool is built-in into Defender for Cloud and doesn’t require any external licenses. However, if your company is already utilizing Qualys as your primary threat and vulnerability scanner, you should be able to leverage the BYOL solution, as this will provide Qualys Vulnerability Assessment in both your Qualys subscription and in the Azure Security Center. The Azure Security Center handles the deployment of Qualys Cloud Agent for this solution to work. Agents installed via other methods (extensions, baked into images, or deployed manually) will not report their findings into the associated ASC.
Some considerations to review before comparing the options.
Cost: The built-in scanner is included with MDfC has no added cost in Azure Defender for Cloud. BYOL option requires maintaining a Qualys license.
Coverage: The built-in scanner supports Azure ARC machines, while the Qualys BYOL option will not cover on-prem and multi cloud machines. The BYOL option only works with Azure Virtual Machines.
Deployment: The built-in scanner has more deployment options through API making it almost automatically deployment for Azure Virtual Machines (see official docs)
Vulnerability findings: The built-in scanner findings in Azure Security Center are richer with data, comparing to BYOL findings in ASC, whereas BYOL findings are also reflected in the Qualys platform. For instance, while you will find the same CVE and Security Recommendations, the metadata passed to ASC will not be as complete as using the build-in agent.