Applicable To: 

Duke Health

Duke University

Note: Developers may also want to view the Security Offices' position statement on Secure Native Application Authentication.

Duke Security Offices position statement on mobile application testing:

Introduction

Mobile applications play a big part of our everyday personal and professional lives. As Duke relies more on mobile applications, ensuring that they are adequately free from vulnerabilities and defects is critical. This document outlines and details some minimum mobile application vetting and testing standards. This process should be used to ensure that mobile applications conform to Duke’s security requirements and are analyzed for vulnerabilities.

Duke has a growing footprint of mobile applications to communicate, share or harvest information, provide health services, and transact business with internal and external constituents. Duke’s mobile application presence continues to grow, including (but not exclusively) the following examples:

  • Mobile applications involving Duke data, including sensitive data (e.g., PHI, PII, etc)
  • Institutional/Enterprise mobile applications, regardless of data classification
  • Mobile applications involved in specific research programs
  • School, center, and departmental mobile applications
  • Individual or project-oriented mobile applications
  • Applications that use the Duke brand or name

Mobile applications may be developed by Duke faculty, staff or students or by external development companies under contract with Duke. External development companies or partners should adhere to the same minimum standards required by Duke’s IT Security Office (ITSO) and/or the Duke Health Information Security Office (ISO) before use.

In an effort to improve the security of Duke’s mobile applications, the ITSO and ISO have developed joint guidance and options for vetting and testing mobile applications at Duke.

Scope

This guidance applies to Duke-developed and affiliated mobile applications and to third-party developers responsible for building or maintaining Duke mobile applications on behalf of Duke.  All apps that are Duke branded are in scope for testing.  All apps that are published through the official Duke app stores (Apple and/or Android) are in scope for testing.

The following scenarios are not included in scope for this guidance, but ITSO/ISO encourages a strong Software Development LifeCycle (SDLC) – including regular testing for security vulnerabilities – by the owners of these applications as well.

  • Commercially available mobile applications (e.g. FitBit, MyFitness Pal, etc) that were not developed by or under contract with Duke.
  • Duke Health research Sponsored provided or required mobile applications that were not developed by or under contract with Duke.
  • Duke University student developed mobile applications as long as they are not used 1) within the Duke Health environment (including Duke Health research) and/or 2) with sensitive data.
  • Web applications and mobile responsive web applications (see web application testing position instead).

Position

Mobile Application Security Requirements

Duke mobile applications should meet defined security requirements in order to be approved for use by Duke. Each in-scope application should have a documented SDLC plan.

General Mobile Security Requirements

General application security requirements define the software and behavioral characteristics of an application that should or should not be present to ensure the security of the application. These requirements apply to all in-scope mobile applications and are tailored to meet the security needs and risk tolerance of Duke. At minimum, Duke’s general application security requirements for all in-scope applications include those specified by the Open Web Application Security Project (OWASP) below:

https://owasp.org/www-project-mobile-security-testing-guide/

https://github.com/OWASP/owasp-mstg

https://mobile-security.gitbook.io/masvs/

OWASP Mobile Risks and Controls Guidance

OWASP maintains multiple useful resources for mobile application testing and security. The OWASP Mobile Application Security Verification Standard (MASVS) is a detailed model for mobile application security that is used to provide baseline security requirements for Duke. The MASVS defines a set of security declarations concerning the structure and behavior of an application. The MASVS defines each of the three verification levels.

  • Standard Security (Level 1)
  • Defense in Depth (Level 2)
  • Resilience against Reverse Engineering and Threats (Level 3)

Minimally, all in-scope mobile applications must meet Level 1 testing.  Duke Security teams reserve the right to require Level 2 and Level 3 testing based on data sensitivity, volume of use, or other relevant factors.

The MASVS is divided into the categories listed below and it may be used by mobile software architects and developers seeking to develop secure mobile applications, as well as security testers to ensure completeness and consistency of test results:

  • Architecture, Design, and Threat Modeling Requirements
  • Data Storage and Privacy Requirements
  • Cryptography Requirements
  • Authentication and Session Management Requirements
  • Network Communication Requirements
  • Platform Integration Requirements
  • Code Quality and Build-Setting Requirements
  • Resilience Requirements

Mobile Application Vulnerability Testing Requirements

An approved mobile application vulnerability assessment must be performed on every in-scope application. An approved application vulnerability testing process includes using security test tools and penetration testing to help identify vulnerabilities and weaknesses. Testing should be performed by experienced penetration testers, which may be an authorized 3rd party advisory group or approved internal testers who did not write code for the application. At minimum, testing must follow the OWASP Mobile Security Testing Guide (MSTG) and should be clearly documented. The MSTG is a manual for testing the security of mobile applications. It describes the technical processes for verifying the requirements listed in the MASVS.

Any and all identified vulnerabilities should include industry common classifiers and quantifiers in report descriptions. The following strategies and approaches are best practice when analyzing mobile apps for vulnerabilities:

  • use of static and dynamic analysis (e.g., Burp Suite, Drozer, objection, etc)
  • automated application security testing (e.g., MobSF, StaCoAn, Veracode, Codified, etc.)  
  • manual application security testing (e.g., fuzzing, file/storage analysis, APKtool, jadx, Wireshark, etc.)

Mobile App Testing Cadence

Due to the frequency of updates and evolving risks, mobile applications do not remain static. The documented SDLC plan should include planned cadence for testing after initial approval for use.  ITSO and ISO recommends that the documented plan include testing annually and during any major version release.

Any person at Duke who is responsible for an in-scope mobile application should ensure that the above guidance is adhered to.   ITSO and ISO staff are available for consultation if there are questions about adherence to this guidance and may request to review initial penetration test reports.

Security Offices position statements outline the ISO/ITSO's view on security-related topics and provide guidance concerning Duke standards.

Document Type: Other