Turning Attention to Mobile Applications

caspar-rubin-669071-unsplashNIST 800-163, Vetting the Security of Mobile Applications, was recently revised from its 2015 version to address the evolving landscape of mobile application security. NIST provides details and clarity on how exactly organizations can minimize their mobile app risks.

The Approach

NIST provides a way to evaluate mobile applications by offering specific, security-focused guidance.

  1. Planning and implementing a process to “vet” the application
  2. Developing security requirements for mobile applications
  3. Identifying appropriate tools for testing mobile apps
  4. Determining if a mobile app is acceptable for deployment on the company’s mobile devices

Interested Parties

The new recommendations might affect you if you are:

  • Responsible for establishing your company’s mobile device security posture
  • Responsible for the management and security of mobile devices (think Mobile Device Management)
  • Responsible for determining which apps your company will use
  • Interested in understanding what types of assurances the app vetting process provides

Security Requirements

General Application Security

NIST SP 800-163 outlines both general and organization-specific app security requirements. General app security requirements define the software and behavioral characteristics that should (or should not) be in place in order to ensure that app’s security. The following frameworks are referenced:

Organization-specific Security

Organization-specific security requirements define the policies, regulations and guidance that a company must follow to ensure the security position of the organization. NIST outlines the following “non-vulnerability” factors that could still impact the security of a mobile application:

  • Policies: The security, privacy and acceptable use policies; social media guidelines; and regulations applicable to the organization.
  • Provenance: Identity of the developer, developer’s organization, developer’s reputation, consumer reviews, etc.
  • Data Sensitivity: The sensitivity of data collected, stored, or transmitted by the app.
  • Criticality: The level of importance the app is to the organization’s business.
  • Target Users: The app’s intended set of users from the organization.
  • Target Hardware: The intended hardware platform, operating system, and configuration on which the app will be deployed.
  • Target Environment: The intended operational environment of the app (e.g., general public use vs. sensitive military environment).
  • Digital Signatures to be applied to the app binaries, libraries, or packages.
  • App Documentation, including a User Guide, Test Plan, Test Results, and Service Level Agreements (SLAs) (if the app was developed by a third-party).

Introducing the above criteria in a questionnaire form may help identify potential security flaws or weaknesses related to the application. Known vulnerabilities are typically published in the Common Vulnerabilities and Exposures database.

Risk Tolerance

Companies must define the amount of acceptable risk related to the mobile application, including:

  • Compliance with security regulations, recommendations and best practices
  • Privacy risks
  • Security threats
  • Data and asset value
  • Industry and competitive pressure
  • Management preferences

Risks should be rated and ranked by management by order of criticality (e.g. High, Medium, Low). Companies may choose to have these risks evaluated either by compliance (internal or external evaluation) or by certification (third-party evaluation that may involve labs).

Application Vetting

The vetting process involves testing an application to ensure conformance with the company’s application security requirements. This process is presented in a straightforward manner: any application should be vetted before deployment, and if this vetting process is performed outside the company (e.g. contract work), it is the company’s responsibility to ensure that security was appropriately considered.

The process helps identify vulnerabilities that may be common across many applications. A security analyst should then make the determination that security requirements are met (or not met) before proceeding. Results should be formally documented and approved by the appropriate levels of management.

Mobile Application Management (‘MAM’) should be considered during integration to allow enterprise control over applications that access or store services or data related to the company.

NIST has built AppVet to assist organizations with automating the application vetting process.

Room for Improvement

As with any guideline, there is some room for improvement.

The first noticeable issue with the new guidance is that your company may have a tough time adopting this framework to scale as it is so exhaustive. One potential solution is to consider outsourcing the adoption of the framework to a third-party that could work alongside you to scale in an effective way for your company.

Secondly, policies and procedures must be added alongside this guidance to properly secure devices. One major gap appears to be the lack of BYOD (“Bring Your Own Device”) support. With so many employees managing company and client data via their mobile devices, this seems to be a needful addition. Consider partnering with a security or audit firm to construct policies and procedures for your company. Having outside expertise and collaboration is crucial to success.

Finally, the guidelines do not address the “security-by-design” principles that should be present in a company’s culture as part of the application vetting and testing process. Security awareness training for employees should be conducted at least annually, and considerations made for advanced penetration testing and social engineering testing.

Closing Remarks

NIST has made a needful step towards the addressing of mobile application security, but a challenge will be the constant movement of threat by design in the industry. Companies involved in the application design industry must remain aware of constant threats (e.g. ransomware, spyware, adware, etc.) that affect mobile design, and approach the vetting process accordingly.

The draft revision is open for public comment until September 6, 2018.

COMMENTS

THIS POST WAS WRITTEN BY Ryan Wallace

Ryan Wallace is a Cyber Risk Supervisor at HORNE Cyber where he works to provide IT-focused assurance to clients both public and private.