Microsoft - MS-102: Microsoft 365 Administrator

Sample Questions

Explanation:

As a security admin concerned with device security, use Intune endpoint security policies to manage security settings on devices. These profiles are similar in concept to a device configuration policy template or security baseline, which are logical groups of related settings. However where device configuration profiles and security baselines include a large body of diverse settings outside the scope of securing endpoints, each endpoint security profile focuses on a specific subset of device security.

The Windows Security Experience policy template includes the required settings.

Reference: Manage device security with endpoint security policies in Microsoft Intune

Explanation:

To simplify network configuration and management, you now have the option of onboarding new devices to Defender for Endpoint using a reduced URL set or static IP ranges. This new connectivitiy method is known as streamlined device connectivity method.

The Defender for Endpoint-recognized simplified domain *.endpoint.security.microsoft.com consolidates connectivity to the following core Defender for Endpoint services:

• Cloud-delivered protection
• Malware sample submission storage
• Auto-IR sample storage
• Defender for Endpoint command & control
• Defender for Endpoint cyber and diagnostic data

To support network devices without hostname resolution or wildcard support, you can alternatively configure connectivity using dedicated Defender for Endpoint static IP ranges.

Note

• The streamlined connectivity method will not change how Microsoft Defender for Endpoint functions on a device nor will it change the end-user experience. Only the URLs or IPs that a device uses to connect to the service will change.
• There currently is no plan to deprecate the old, consolidated service URLs. Devices onboarded with "standard" connectivity will continue to function. It is important to ensure connectivity to *.endpoint.security.microsoft.com is and remains possible, as future services will require it. This new URL is included in all required URL lists.
• Connections to the service leverage certificate pinning and TLS. It is not supported to "break and inspect" traffic. In addition, connections are initiated from a device context, not a user context. Enforcing proxy (user) authentication will disallow (break) connectivity in most cases.

Reference: Onboarding devices using streamlined connectivity for Microsoft Defender for Endpoint

Explanation:

In organizations with Microsoft Defender for Office 365 Plan 2 (add-on licenses or included in subscriptions like Microsoft 365 E5), you can use Attack simulation training in the Microsoft Defender portal to run realistic attack scenarios in your organization. These simulated attacks can help you identify and find vulnerable users before a real attack impacts your bottom line.

Simulations

A simulation in Attack simulation training is the overall campaign that delivers realistic but harmless phishing messages to users. The basic elements of a simulation are:

• Who gets the simulated phishing message and on what schedule.
• Training that users get based on their action or lack of action (for both correct and incorrect actions) on the simulated phishing message.
• The payload that's used in the simulated phishing message (a link or an attachment), and the composition of the phishing message (for example, package delivered, problem with your account, or you won a prize).
• The social engineering technique that's used. The payload and social engineering technique are closely related.

In Attack simulation training, multiple types of social engineering techniques are available.

The following social engineering techniques are available:

• Credential Harvest: An attacker sends the recipient a message that contains a link*. When the recipient clicks on the link, they're taken to a website that typically shows a dialog box that asks the user for their username and password. Typically, the destination page is themed to represent a well-known website in order to build trust in the user.

• Malware Attachment: An attacker sends the recipient a message that contains an attachment. When the recipient opens the attachment, arbitrary code (for example, a macro) runs on the user's device to help the attacker install additional code or further entrench themselves.

• Link in Attachment: This technique is a hybrid of a credential harvest. An attacker sends the recipient a message that contains a link inside of an attachment. When the recipient opens the attachment and clicks on the link, they're taken to a website that typically shows a dialog box that asks the user for their username and password. Typically, the destination page is themed to represent a well-known website in order to build trust in the user.

• Link to Malware: An attacker sends the recipient a message that contains a link to an attachment on a well-known file sharing site (for example, SharePoint Online or Dropbox). When the recipient clicks on the link, the attachment opens, and arbitrary code (for example, a macro) runs on the user's device to help the attacker install additional code or further entrench themselves.

• Drive-by-url: An attacker sends the recipient a message that contains a link. When the recipient clicks on the link, they're taken to a website that tries to run background code. This background code attempts to gather information about the recipient or deploy arbitrary code on their device. Typically, the destination website is a well-known website that has been compromised or a clone of a well-known website. Familiarity with the website helps convince the user that the link is safe to click. This technique is also known as a watering hole attack.

• OAuth Consent Grant: An attacker creates a malicious Azure Application that seeks to gain access to data. The application sends an email request that contains a link. When the recipient clicks on the link, the consent grant mechanism of the application asks for access to the data (for example, the user's Inbox).

• How-to Guide: A teaching guide that contains instructions for users (for example, how to report phishing messages).

Explanation:

Anti-malware policies contain a common attachments filter. Messages that contain the specified file types are automatically identified as malware. 

Common attachments filter in anti-malware policies

There are certain types of files that you really shouldn't send via email (for example, executable files). Why bother scanning these types of files for malware when you should block them all, anyway? That's where the common attachments filter comes in. The file types that you specify are automatically identified as malware.

A list of default file types is used in the default anti-malware policy, in custom anti-malware policies that you create, and in the anti-malware policies in the Standard and Strict preset security policies.

In the Microsoft Defender portal, you can select from a list of additional file types or add your own values when you create or modify anti-malware policies in the Microsoft Defender portal.

• Default file types: ace, ani, apk, app, appx, arj, bat, cab, cmd, com, deb, dex, dll, docm, elf, exe, hta, img, iso, jar, jnlp, kext, lha, lib, library, lnk, lzh, macho, msc, msi, msix, msp, mst, pif, ppa, ppam, reg, rev, scf, scr, sct, sys, uif, vb, vbe, vbs, vxd, wsc, wsf, wsh, xll, xz, z.

• Additional file types to select in the Defender portal: 7z, 7zip, a, accdb, accde, action, ade, adp, appxbundle, asf, asp, aspx, avi, bas, bin, bundle, bz, bz2, bzip2, caction, cer, chm, command, cpl, crt, csh, css, der, dgz, dmg, doc, docx, dos, dot, dotm, dtox [sic], dylib, font, fxp, gadget, gz, gzip, hlp, Hta, htm, html, imp, inf, ins, ipa, isp, its, js, jse, ksh, Lnk, lqy, mad, maf, mag, mam, maq, mar, mas, mat, mau, mav, maw, mda, mdb, mde, mdt, mdw, mdz, mht, mhtml, mscompress, msh, msh1, msh1xml, msh2, msh2xml, mshxml, msixbundle, o, obj, odp, ods, odt, one, onenote, ops, os2, package, pages, pbix, pcd, pdb, pdf, php, pkg, plg, plugin, pps, ppsm, ppsx, ppt, pptm, pptx, prf, prg, ps1, ps1xml, ps2, ps2xml, psc1, psc2, pst, pub, py, rar, rpm, rtf, scpt, service, sh, shb, shs, shtm, shx, so, tar, tarz, terminal, tgz, tmp, tool, url, vhd, vsd, vsdm, vsdx, vsmacros, vss, vssx, vst, vstm, vstx, vsw, w16, workflow, ws, xhtml, xla, xlam, xls, xlsb, xlsm, xlsx, xlt, xltm, xltx, xnk, zi, zip, zipx.

When files are detected by the common attachments filter, you can choose to Reject the message with a non-delivery report (NDR) or Quarantine the message.

References:

Anti-malware protection in EOP

Configure anti-malware policies in EOP

• Tag Server1 as a high-value device.
• Ensure that an alert is triggered when App1 is accessed.

Explanation:

We should create a critical asset classification that tags Server1 as High - tier 1 asset.

Critical assets protection enables security administrators to automatically tag the "crown jewel" resources that are most critical to their organizations, allowing Defender for Cloud to provide them with the highest level of protection and prioritize security issues on these assets above anything else.

Defender for Cloud suggests pre-defined classification rules that were developed by our research team to discover critical assets automatically, and allows you to create custom classification rules based on your business and organizational conventions.

Critical asset rules are bi-directionally synced with Microsoft Security Exposure Management - rules that were created in Microsoft Security Exposure Management are synced to Defender for Cloud, and vice versa.

To ensure that an alert is triggered when App1 is accessed, we should add an indicator of compromise for the IP address of App1.

An Indicator of compromise (IoC) is a forensic artifact, observed on the network or host. An IoC indicates - with high confidence - a computer or network intrusion has occurred. IoCs are observable, which links them directly to measurable events. Some IoC examples include:

• hashes of known malware
• signatures of malicious network traffic
• URLs or domains that are known malware distributors

To halt other compromise or prevent breaches of known IoCs, successful IoC tools should be able to detect all malicious data that is enumerated by the tool's rule set. IoC matching is an essential feature in every endpoint protection solution. This capability gives SecOps the ability to set a list of indicators for detection and for blocking (prevention and response).

References:

Critical assets protection in Microsoft Defender for Cloud

Overview of indicators in Microsoft Defender for Endpoint