Adversaries may utilize standard operating system APIs to collect data from permission-backed data stores on a device, such as the calendar or contact list. These permissions need to be declared ahead of time. On Android, they must be included in the application’s manifest. On iOS, they must be included in the application’s Info.plist file.
In almost all cases, the user is required to grant access to the data store that the application is trying to access. In recent OS versions, vendors have introduced additional privacy controls for users, such as the ability to grant permission to an application only while the application is being actively used by the user.
If the device has been jailbroken or rooted, an adversary may be able to access Protected User Data without the user’s knowledge or approval.
| ID | Mitigation | Description |
|---|---|---|
| M1006 | Use Recent OS Version |
OS feature updates often enhance security and privacy around permissions. |
| M1011 | User Guidance |
Users should be taught the danger behind granting unnecessary permissions to an application and should be advised to use extra scrutiny when an application requests them. |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0681 | Detection of Protected User Data | AN1786 |
For Android, detect Protected User Data by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate API Calls via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: ContentResolver.query() to sensitive provider URI (contacts, calendar, call_log, sms) with query_count > $ContentQueryThreshold$ by app NOT IN $ApprovedDataApps$]; Network Traffic Flow via Android Enterprise Network Logging / Enterprise VPN [DevicePolicyManager.retrieveNetworkLogs(): DnsEvent / ConnectEvent; VPN flow metadata]; Permissions Request via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |
| AN1787 |
For iOS, detect Protected User Data by correlating analyst-visible device/network evidence and management state; use streaming or batched telemetry only where the documented collector is deployed. Correlate API Calls via Application Vetting / Instrumented Dynamic Analysis [Dynamic API/runtime trace: CNContactStore.enumerateContacts or EKEventStore.fetchEvents or CLLocationManager.startUpdatingLocation called with broad scope by app NOT IN $ApprovedDataApps$]; Network Traffic Flow via Apple Network Extension / Enterprise VPN [NEFilterFlow / per-app VPN / secure-web-gateway flow metadata]; Permissions Request via Application Vetting [Code-signing entitlements and Info.plist privacy usage-description keys]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |