Mobile Device Management (MDM/MAM)

Mobile Device Management (MDM) is a security solution that enables organizations to centrally manage, monitor, and secure mobile devices such as smartphones, tablets, and laptops. MDM is typically deployed in a corporate-owned, personally enabled (COPE) or company-owned (CO) model where the organization has full control over the device. The primary goal of MDM is to enforce security policies, manage device configurations, and protect corporate data.

MDM solutions work by installing a management profile or agent on the device. This agent communicates with an MDM server, typically via HTTPS (port 443) using RESTful APIs. The server pushes policies to the device, such as password complexity, encryption requirements, and application whitelists/blacklists. The device reports its compliance status back to the server. Common MDM platforms include Microsoft Intune, VMware Workspace ONE, and Jamf Pro.

4. Remote Actions: Administrators can perform remote actions like: - Remote Lock: Locks the device to prevent unauthorized access. - Remote Wipe: Erases all data on the device, restoring it to factory settings. This is typically used for lost or stolen devices. - Selective Wipe: Removes only corporate data and applications, leaving personal data intact. This is more common in BYOD scenarios with MAM.

Mobile Application Management (MAM) is a security approach that focuses on managing and securing individual applications on a mobile device, rather than the entire device. MAM is typically used in Bring Your Own Device (BYOD) environments where the organization does not have full control over the device but needs to protect corporate data within specific apps.

MAM works by creating a secure container or wrapping the application with security policies. This container isolates corporate apps and data from personal apps and data. The organization can enforce policies such as:

Microsoft Intune (MDM/MAM)

To create a device compliance policy in Intune, an administrator uses the Azure portal or PowerShell cmdlets. For example, the following PowerShell script creates a compliance policy for iOS requiring a passcode:

New-IntuneCompliancePolicy -Platform iOS -DisplayName "iOS Passcode Policy" -PasscodeRequired $true -PasscodeMinimumLength 6 -PasscodeMinutesOfInactivityBeforeLock 5

To create an MAM app protection policy for Android:

New-IntuneAppProtectionPolicy -Platform Android -DisplayName "Android App Protection" -AppSharingFromPolicy AllowNone -DataEncryption $true -PinRequired $true

Jamf Pro (MDM for Apple devices)

Jamf Pro uses configuration profiles. A typical iOS configuration profile for passcode policy is a .mobileconfig file like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>PayloadType</key>
            <string>com.apple.mobiledevice.passwordpolicy</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>PayloadIdentifier</key>
            <string>com.jamf.passcode.1</string>
            <key>PayloadUUID</key>
            <string>...</string>
            <key>PayloadDisplayName</key>
            <string>Passcode Policy</string>
            <key>allowSimple</key>
            <false/>
            <key>forcePIN</key>
            <true/>
            <key>maxFailedAttempts</key>
            <integer>10</integer>
            <key>minLength</key>
            <integer>6</integer>
        </dict>
    </array>
</dict>
</plist>

Android Enterprise

Android Enterprise uses a Device Policy Controller (DPC) app. Policies are set via the Google Admin console or MDM. For example, to enforce encryption, the admin sets a policy in the console, which is pushed to the DPC.

For SY0-701, know that:

An employee reports their company-issued laptop lost. The SOC analyst immediately checks the MDM console (e.g., Microsoft Intune). The device last checked in 30 minutes ago from a location near the employee's last known location. The analyst initiates a remote lock and then a remote wipe. The MDM sends the wipe command via push notification. The device acknowledges the wipe and erases all data, including BitLocker-encrypted drives. The analyst confirms the wipe in the logs. A common mistake is not having a remote wipe capability enabled for all devices, or failing to test the wipe process beforehand. The correct response is to first lock the device to prevent access, then wipe after confirming it cannot be recovered.

An employee uses their personal Android phone to access corporate email via Outlook. The MAM policy requires a PIN and detects that the device is rooted (via root detection). The MAM policy blocks access to corporate email and sends an alert to the SOC. The analyst reviews the alert and contacts the employee, instructing them to remove the root or use a compliant device. The analyst can also perform a selective wipe of corporate data from the Outlook app via the MAM console. A common mistake is wiping the entire device, which would delete personal data. The correct response is to use selective wipe to remove only corporate data.

An employee attempts to copy sensitive financial data from a corporate app (e.g., Salesforce) to a personal note-taking app on their BYOD iPhone. The MAM policy has a data transfer restriction that prevents copy/paste from managed to unmanaged apps. The employee is unable to complete the action. The MAM logs record the attempted violation. The SOC receives an alert about the blocked copy attempt. The analyst investigates and finds a pattern of similar attempts, escalating to HR for insider threat investigation. A common mistake is not enabling data loss prevention (DLP) policies in MAM, allowing data leakage to go undetected.