Difference between revisions of "Native App Security"

From MgmtWiki
Jump to: navigation, search
(Created page with "==Full Name and Context== An application that is installed on a user's computing device with full power to act as the user. ==Context== * The day when a personal computer was...")
 
(→‎Other References)
 
(99 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
==Full Name and Context==
+
==Full Title and Meme==
−
An application that is installed on a user's computing device with full power to act as the user.
+
An app or application that is installed by the user to their device, as distinct from a [[Web App]] that runs in the browser  context only.  Apps implemented using web-based technology but distributed as a native app, so-called "hybrid apps", are  considered equivalent to native apps by RFC 8252.
  
 
==Context==
 
==Context==
−
* The day when a personal computer was for running application for the user is long gone, never to return.
+
 
 +
* This is a companion document to [[Native App Privacy]]
 +
* The day when a personal computer was for running applications for the user is long gone, never to return.
 
* Today a personal computer depends on cloud based service for nearly all of its functionality.
 
* Today a personal computer depends on cloud based service for nearly all of its functionality.
 
* Some of those sites are willing to use a trusted [[User Agent]], typically a web browser from a well-known and trusted vendor for rendering its content.
 
* Some of those sites are willing to use a trusted [[User Agent]], typically a web browser from a well-known and trusted vendor for rendering its content.
−
* The first of the [[Laws of Security]] tell us that when an attacker gets to run their code on your computer, it is not longer just your computer any longer.  
+
* The first of the [[Laws of Security]] tell us that when an attacker gets to run their code on your computer, it is no longer just your computer.
−
* For the case where the user is not forced to allow an application to run on their personal device, see the page [[Web App Security]].
+
* But now many [[Web Site]]s encourage to run their applications on the user device to improve their control of the [[User Experience]].
 +
* When these apps exchange user data with other locations, they are considered by [[OAuth 2.0]] to be operating a clients of the user.
 +
* But the security of these apps is questionable, a IETF standard [https://tools.ietf.org/html/bcp212 OAuth 2.0 for Native Apps] seeks to address some of the issues.
 +
* For the case where the user is not forced to allow an application to run on their personal device, see the page [[Web Site Security]].
 +
* NIST Special Publication (SP) 800-53 Rev. 5 defines a mobile device as <blockquote>A portable computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, non-removable data storage; and is powered on for extended periods of time with a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture (e.g., photograph, video, record, or determine location) information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, tablets, and e-readers.</blockquote>
 +
* [https://www.nccoe.nist.gov/sites/default/files/library/sp1800/mdse-nist-sp1800-22a-draft.pdf NIST SP 1800-22A] points out<blockquote>An ineffectively secured personal mobile devicebvcould expose an organization or employee to data loss or a privacy compromise</blockquote>
 +
===Taxonomy===
 +
NIST has publichlished [https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-1.pdf Recommended Criteria for Cybersecurity Labeling of Consumer Software] (2022-02-04)
 +
 
 +
This section takes a lot of terms from [https://doi.org/10.6028/NIST.SP.800-218 NIST Secure Software Development Framework(SSDF)]
 +
 
 +
The SSDF identifies common practices that are components to a secure software development process, and organizes them into four groups:
 +
* Prepare the Organization (PO)
 +
* Protect the Software (PS)
 +
* Produce Well-Secured Software (PW)
 +
*  Respond to Vulnerabilities (RV)
 +
 
 +
Note that the NIST specs address labels that can be understood by any user. This section expands that to the presentation made by the software to any [[Relying Party]]. Any [[Trust Registry]] should require a standardized binding mechanism to couple the claims in each label to specific software. They will need to tailor a [[User Experience]] to best match the needs of the users. Where appropriate, the labeling should leverage existing software identification standards including, but not limited to:
 +
# Software ID Tags [NISTIR 8060]
 +
# Concise Software Identification Tags [CoSWID]
 +
# Common Platform Enumeration [NISTIR 7695]
 +
#  Software Heritage persistent Identifiers [SWHIDS]
 +
# Package URL [PURL]
  
 
==Problems==
 
==Problems==
 +
*One of the worst case scenarios for [[Native App]] security is that of payments made directly from a user's bank account without the user selected user agent (browser) assuring that the user consents to the payment.
 +
*In [[Open Banking]] it is proposed that a payment initiator and a bank can both have [[Native App]]s running where the payment initiator app asks the banking app on the same device for permission to remove money from the user's account.
 +
* The article [https://www.wired.com/story/iphone-touch-id-scam-apps/ Watch Out for a Clever Touch ID Scam Hitting the App Store] shows how unscrupulous apps can fool the user in to granting access to their bank accounts.
 +
* A [[Web View]] is a display of information from a [[Web Site]]. There is no trustworthy indication that the [[Native App]] has correctly displayed the information that it obtained from the [[Web Site]].
  
 
==Solutions==
 
==Solutions==
 
* The [[Native App]] exposes its name and the web site that backs it in a manner that allows the user to make a meaningful trust decision.
 
* The [[Native App]] exposes its name and the web site that backs it in a manner that allows the user to make a meaningful trust decision.
 +
** Android play store requires<ref name='android'>''Handling Android App Links.'' https://developer.android.com/training/app-links/</ref> any app that uses a brand name service to be securely bound to a [[URL]] that properly exposes that brand.
 +
** Apple has not released any plans to improve app naming security as of 2018-09-21.
 
* Joint use [[Native App]]s are provide to some industries for all to use. It makes the trust decision by the user much more difficult.
 
* Joint use [[Native App]]s are provide to some industries for all to use. It makes the trust decision by the user much more difficult.
 +
* [https://www.owasp.org/index.php/SameSite Same Site] was designed to help, but [https://outlook.live.com/mail/inbox/id/AQQkADAwATExAGMzNy1iY2JmLWIwYmYtMDACLTAwCgAQAHD5YNrixl9FqyVrfekhw50%3D as of (2018-09-21) is not consistently applied]. In 2020 a process of tightening the same site requirements was under way at blink.
 +
* RFC 8258 ''OAuth 2.0 for Native Apps'' is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. It includes details for each of the major platforms, iOS, Android and Windows. In particular it mentions the app's security identifier for Windows, but all os's give the apps some sort of identifier that survives update and should be the primary source of app identity as the os app store will assure uniqueness.
 +
 +
===App Vetting Process===
 +
* Native Apps have been shown to be vulnerable by the public announcement of many breaches; see the discussion of [https://wiki.idesg.org/wiki/index.php/Patient_Choice Patient Choice].
 +
* The [https://www.firstnet.com/apps.html FirstNet process of app vetting] is already well tested for apps that are targeted to first responders. See their [https://developer.firstnet.com/firstnet Developer Portal],
 +
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-163r1.pdf NIST Special Publication 800-163 Revision 1 Vetting the Security of Mobile Applications] 2019-04 describes a process to ensure that mobile applications conform to an organizations's security requirements and are reasonably free from vulnerabilities. The following are extracted from that document.
 +
* [https://csrc.nist.gov/publications/detail/sp/800-218/draft NIST SP 800-218 draft ] (2021-09-30) Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
 +
 +
===NIST & NCCoE Support===
 +
* [https://mail.google.com/mail/u/0/#inbox/FMfcgzGsmDtjLdWlwcdhbJlLClZNstMQ NIST/NCCoE Mobile Device Security web page]
 +
* [https://www.nccoe.nist.gov/sites/default/files/MDS_COI_August_2019.pdf Mobile Device Security Community of Interest] from the National Cybersecurity Center of Excellence, author Gema Howell (2019-08)
 +
* Referenced NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments
 +
* Identified Threats Events (TE) using the NIST Mobile Threat Catalogue (MTC)
 +
* [https://www.nccoe.nist.gov/library/mobile-device-security-bring-your-own-device-nist-sp-1800-22-practice-guide Mobile Device Security--Bring Your Own Device (BYOD) SP 1800-22] 2021-various
 +
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-114r1.pdf User’s Guide to Telework and Bring Your Own Device (BYOD) Security] 2016-07
 +
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-46r2.pdf Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security] 2106-07
 +
 +
===NIST Threat Assessment===
 +
These treat events were taken from the [https://www.nccoe.nist.gov/sites/default/files/MDS_COI_August_2019.pdf Mobile Device Security Community of Interest] 2019-08
 +
* Their Mobile Threat Catalogue is based on [https://csrc.nist.gov/CSRC/media/Publications/nistir/8144/draft/documents/nistir8144_draft.pdf Draft NISTIR 8144: Assessing Threats to Mobile Devices & Infrastructure].
 +
* Additional reading material is at [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r2-draft.pdf Guidelines for Managing the Security of Mobile Devices in the Enterprise] which is focused on Corporate-owned devices.
 +
{| class="wikitable"
 +
|-
 +
! Threat Event || Closest STRIDE Threat !! Desired property
 +
|-
 +
| TE-1: Unauthorized access to sensitive information via a malicious or privacy-intrusive application || Information disclosure || Confidentiality
 +
|-
 +
| TE-2: Theft of credentials through an SMS or email phishing campaign || Elevation of Privilege || Authorization
 +
|-
 +
| TE-3: Malicious applications installed via URLs in SMS or email messages || Denial of Service || Availability.
 +
|-
 +
| TE-4: Confidentiality and integrity loss due to exploitation of known vulnerability in the OS or firmware  || Repudiation || Non-repudiability.
 +
|-
 +
| TE-5: Violation of privacy via misuse of device sensors  || [[Identity Spoofing|Spoofing]] || Authenticate
 +
|-
 +
| TE-6: Compromise of the integrity of the device or its network communications via installation of malicious EMM/MDM, network, VPN profiles, or certificates || Tampering || Integrit
 +
|}
 +
 +
* The STRIDE model is described in the wiki page [[Threat Model]]
 +
 +
===Android Support===
 +
* Rules for apps installed on Android devices <ref name='android'></ref>
 +
* [https://developer.android.com/google/play/licensing/server-side-verification Adding Server-Side License Verification to Your App]
 +
* [https://developer.android.com/google/play/licensing App Licensing]
 +
*[https://github.com/TransparentHealth/poet Pre Oauth Entity Trust] describes a means to represent third-party application endorsement for health care applications. POET’s goal is to help consumers distinguish between applications that have an endorsement versus applications that have no pedigree (i.e untrusted and could be malicious).
 +
* Android App list of [[Data Category|Data Categories]] that require [[User Consent]]. https://support.google.com/googleplay/answer/6270602?hl=en
 +
 +
===Apple iPhone Support===
 +
* Rules for apps installed on Apple devices are (not clear)
 +
* Apple iPhone App Requesting Permission: https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/requesting-permission/
 +
* Apple iPhone app Requesting Authorization to use System Features: https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy
 +
* Apple CKContainer manages all attempts to access user data on the device or in iCloud. https://developer.apple.com/documentation/cloudkit/ckcontainer
 +
===Windows Support===
 +
* Windows (UWP) settings are on all Windows 10 computer, but do not seem to be shown anywhere on the web.  Just navigate start -> settings -> privacy -> app settings.
 +
* Rules for apps installed on Windows devices are of two types (UWP and traditional), but it is not clear how the user could possibly distinguish, so the concept has not been helpful.
 +
 +
==User Experience==
 +
There has been a peristant view among developers and architects that user are not concrened enough about security to do anything about it.  This is simply not true. When the user has a meaningful choice, they will chose more secure options. If your are still in doubt about this read the antricle on [https://www.cpomagazine.com/cyber-security/debunking-and-addressing-myths-about-consumers-and-mobile-app-security/ Debunking and Addressing Myths About Consumers and Mobile App Security] from CPO Magazine on 2021-12-02.
 +
 +
Any [[Identity Management]], privacy or security feature added to a [[Native App]] will impact the [[User Experience]].<ref>Phil Vachon, ''The Identity in Everyone's Pocket'' '''CACM 64''' No. 1  (2021-01)</ref> Do not confuse Proof of Identity with a simple request for information from the user. When Proof of Identity is required, get the result and cache it for use until there is some reason to think that the user is not on the session any longer. This particularly applies to Proof of Presence which may require a face or finder scan.
 +
* Original creation of a relationship with the user will likely require proof of Identity, but after that simple [[Authentication]] may be sufficient.
 +
* In some cases the user will need to have or create credentials on the phone to complete the creation of the relationship. That my also require the user to navigate to one particular issuer to acquire those credentials.
 +
* The app needs to verify and report on the environment: whether the user has enabled a lock screen and if a biometric sensor is accessible to the app. Some user configuration of the phone o/s may be required before some security features can be used, or reported, by the app.
 +
* The app needs to determine if hardware protection of the signing key for storage, and possibly for use, is enabled. Then the user will likely be required to create a private key in secure store and know the impact of loss of the key or whether key back-up is enabled.
 +
* Similar impacts to the user will be required if a separate hardware key is required for a second authentication factor.
 +
* Do not try to scare the user.  Be helpful and supportive. Lead the user to making good decisions about security.
 +
 
==References==
 
==References==
−
===Organizational Support===
+
<references />
−
* Rules for apps installed on Apple devices
 
−
* Rules for apps installed on Android devices
 
−
* Rules for apps installed on Windows devices are of two types, but it is not clear how the user could possibly distinguish, so the concept has not been helpful.
 
  
 
===Other References===
 
===Other References===
−
# [https://www.owasp.org/index.php/Main_Page The Open Web Application Security Project (OWASP)] is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of web site software.
+
* [https://krebsonsecurity.com/2021/03/can-we-stop-pretending-sms-is-secure-now/ SMS is easy to hijack] and should not be used for security purposes.
−
# [https://www.nationalisacs.org/ ISAC]s are member-driven organizations, delivering all-hazards threat and mitigation information to asset owners and operators.
+
* [https://www.owasp.org/index.php/Main_Page The Open Web Application Security Project (OWASP)] is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of web site software.
 +
* [https://www.nationalisacs.org/ ISAC]s are member-driven organizations, delivering all-hazards threat and mitigation information to asset owners and operators.
 +
* [[Native App]] wiki page.
 +
* [[Native App Privacy]] wiki page.
 +
 
 +
[[Category:Security]]
 +
[[Category:Identifier]]
 +
[[Category: Attestation]]

Latest revision as of 11:23, 25 October 2023

Full Title and Meme

An app or application that is installed by the user to their device, as distinct from a Web App that runs in the browser context only. Apps implemented using web-based technology but distributed as a native app, so-called "hybrid apps", are considered equivalent to native apps by RFC 8252.

Context

  • This is a companion document to Native App Privacy
  • The day when a personal computer was for running applications for the user is long gone, never to return.
  • Today a personal computer depends on cloud based service for nearly all of its functionality.
  • Some of those sites are willing to use a trusted User Agent, typically a web browser from a well-known and trusted vendor for rendering its content.
  • The first of the Laws of Security tell us that when an attacker gets to run their code on your computer, it is no longer just your computer.
  • But now many Web Sites encourage to run their applications on the user device to improve their control of the User Experience.
  • When these apps exchange user data with other locations, they are considered by OAuth 2.0 to be operating a clients of the user.
  • But the security of these apps is questionable, a IETF standard OAuth 2.0 for Native Apps seeks to address some of the issues.
  • For the case where the user is not forced to allow an application to run on their personal device, see the page Web Site Security.
  • NIST Special Publication (SP) 800-53 Rev. 5 defines a mobile device as
    A portable computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection (e.g., wirelessly transmit or receive information); possesses local, non-removable data storage; and is powered on for extended periods of time with a self-contained power source. Mobile devices may also include voice communication capabilities, on-board sensors that allow the device to capture (e.g., photograph, video, record, or determine location) information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones, tablets, and e-readers.
  • NIST SP 1800-22A points out
    An ineffectively secured personal mobile devicebvcould expose an organization or employee to data loss or a privacy compromise

Taxonomy

NIST has publichlished Recommended Criteria for Cybersecurity Labeling of Consumer Software (2022-02-04)

This section takes a lot of terms from NIST Secure Software Development Framework(SSDF)

The SSDF identifies common practices that are components to a secure software development process, and organizes them into four groups:

  • Prepare the Organization (PO)
  • Protect the Software (PS)
  • Produce Well-Secured Software (PW)
  • Respond to Vulnerabilities (RV)

Note that the NIST specs address labels that can be understood by any user. This section expands that to the presentation made by the software to any Relying Party. Any Trust Registry should require a standardized binding mechanism to couple the claims in each label to specific software. They will need to tailor a User Experience to best match the needs of the users. Where appropriate, the labeling should leverage existing software identification standards including, but not limited to:

  1. Software ID Tags [NISTIR 8060]
  2. Concise Software Identification Tags [CoSWID]
  3. Common Platform Enumeration [NISTIR 7695]
  4. Software Heritage persistent Identifiers [SWHIDS]
  5. Package URL [PURL]

Problems

  • One of the worst case scenarios for Native App security is that of payments made directly from a user's bank account without the user selected user agent (browser) assuring that the user consents to the payment.
  • In Open Banking it is proposed that a payment initiator and a bank can both have Native Apps running where the payment initiator app asks the banking app on the same device for permission to remove money from the user's account.
  • The article Watch Out for a Clever Touch ID Scam Hitting the App Store shows how unscrupulous apps can fool the user in to granting access to their bank accounts.
  • A Web View is a display of information from a Web Site. There is no trustworthy indication that the Native App has correctly displayed the information that it obtained from the Web Site.

Solutions

  • The Native App exposes its name and the web site that backs it in a manner that allows the user to make a meaningful trust decision.
    • Android play store requires[1] any app that uses a brand name service to be securely bound to a URL that properly exposes that brand.
    • Apple has not released any plans to improve app naming security as of 2018-09-21.
  • Joint use Native Apps are provide to some industries for all to use. It makes the trust decision by the user much more difficult.
  • Same Site was designed to help, but as of (2018-09-21) is not consistently applied. In 2020 a process of tightening the same site requirements was under way at blink.
  • RFC 8258 OAuth 2.0 for Native Apps is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. It includes details for each of the major platforms, iOS, Android and Windows. In particular it mentions the app's security identifier for Windows, but all os's give the apps some sort of identifier that survives update and should be the primary source of app identity as the os app store will assure uniqueness.

App Vetting Process

NIST & NCCoE Support

NIST Threat Assessment

These treat events were taken from the Mobile Device Security Community of Interest 2019-08

Threat Event Closest STRIDE Threat Desired property
TE-1: Unauthorized access to sensitive information via a malicious or privacy-intrusive application Information disclosure Confidentiality
TE-2: Theft of credentials through an SMS or email phishing campaign Elevation of Privilege Authorization
TE-3: Malicious applications installed via URLs in SMS or email messages Denial of Service Availability.
TE-4: Confidentiality and integrity loss due to exploitation of known vulnerability in the OS or firmware Repudiation Non-repudiability.
TE-5: Violation of privacy via misuse of device sensors Spoofing Authenticate
TE-6: Compromise of the integrity of the device or its network communications via installation of malicious EMM/MDM, network, VPN profiles, or certificates Tampering Integrit
  • The STRIDE model is described in the wiki page Threat Model

Android Support

Apple iPhone Support

Windows Support

  • Windows (UWP) settings are on all Windows 10 computer, but do not seem to be shown anywhere on the web. Just navigate start -> settings -> privacy -> app settings.
  • Rules for apps installed on Windows devices are of two types (UWP and traditional), but it is not clear how the user could possibly distinguish, so the concept has not been helpful.

User Experience

There has been a peristant view among developers and architects that user are not concrened enough about security to do anything about it. This is simply not true. When the user has a meaningful choice, they will chose more secure options. If your are still in doubt about this read the antricle on Debunking and Addressing Myths About Consumers and Mobile App Security from CPO Magazine on 2021-12-02.

Any Identity Management, privacy or security feature added to a Native App will impact the User Experience.[2] Do not confuse Proof of Identity with a simple request for information from the user. When Proof of Identity is required, get the result and cache it for use until there is some reason to think that the user is not on the session any longer. This particularly applies to Proof of Presence which may require a face or finder scan.

  • Original creation of a relationship with the user will likely require proof of Identity, but after that simple Authentication may be sufficient.
  • In some cases the user will need to have or create credentials on the phone to complete the creation of the relationship. That my also require the user to navigate to one particular issuer to acquire those credentials.
  • The app needs to verify and report on the environment: whether the user has enabled a lock screen and if a biometric sensor is accessible to the app. Some user configuration of the phone o/s may be required before some security features can be used, or reported, by the app.
  • The app needs to determine if hardware protection of the signing key for storage, and possibly for use, is enabled. Then the user will likely be required to create a private key in secure store and know the impact of loss of the key or whether key back-up is enabled.
  • Similar impacts to the user will be required if a separate hardware key is required for a second authentication factor.
  • Do not try to scare the user. Be helpful and supportive. Lead the user to making good decisions about security.

References

  1. ↑ 1.0 1.1 Handling Android App Links. https://developer.android.com/training/app-links/
  2. ↑ Phil Vachon, The Identity in Everyone's Pocket CACM 64 No. 1 (2021-01)

Other References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Native_App_Security&oldid=18928"