Mobile apps can present both common and unique security challenges, particularly for business-critical apps that must comply with Microsoft security and privacy policies. At Core Services Engineering (CSE, formerly Microsoft IT), we wanted earlier visibility into internal business app development to prevent security and privacy reviews from becoming blocking issues when an app team is ready to publish an internal mobile app. To help ensure that all internal mobile business apps published to our Intune Company Portal comply with security and privacy requirements, we integrated the Microsoft Security Development Lifecycle (SDL) into the publishing process for internally developed, mobile business apps.
Additionally, to help streamline our internal mobile app publishing process and better accommodate the agile app development methodologies used at Microsoft, we deployed Microsoft Enterprise Mobile Application Publishing (EMAP). We used EMAP to introduce automation and a workflow for addressing security and privacy throughout all phases of the app development process.
Integrating some of the key SDL requirement and validation processes with EMAP minimizes risk by helping ensure that we are building more secure mobile apps and are addressing our security compliance requirements before release. It has also helped improve the security and privacy review experience for app development teams by offering a better, more automated way to integrate security reviews and signoff into the application development life cycle.
EMAP helps automate SDL validation
We built EMAP, using Azure services, to help transform our application certification processes for internal business mobile apps that are published to our Company Portal. EMAP uses Azure Logic Apps for workflow automation and is tightly integrated with the tools that our app developers are using to build and test apps, including Visual Studio Team Services and HockeyApp.
- Visual Studio Team Services offers:
- Source code management
- Agile development planning
- Continuous integration
- Release management
- We use HockeyApp for:
- Beta app distribution
- Crash reporting
- User metrics
- Workflow integration
Note: HockeyApp is migrating (along with the cross-platform Xamarin test cloud) into Visual Studio App Center, offering improved integration with the Visual Studio Team Services platform.
EMAP provides malware scanning for all apps that are uploaded to the HockeyApp platform (not just our business mobile apps) and enforces security and privacy review and attestation for mobile internal business apps that are published to our Company Portal. As shown in Figure 1, we have made SDL validation part of the EMAP process.
We are continually updating both our processes and automation. Our goal is to help development teams understand what needs to be done to ensure that their apps meet security and privacy standards before they are published to the Company Portal. This is in line with our digital transformation and implementation of DevOps to push security issues upstream to the developers.
To read about our security best practices and what we have learned on our journey to support modern engineering, download the Security for Modern Engineering whitepaper. For more information about implementing Microsoft Secure Development Lifecycle in your organization, download Simplified Implementation of the Microsoft SDL.
Addressing mobile app security during development
Using EMAP to ensure that all apps published to the Company Portal have completed security and privacy reviews is just one part our application security strategy. We are addressing mobile app security during every stage of the development life cycle to help prevent security vulnerability gaps or vulnerabilities in security policies and configurations as apps are being designed, developed, and tested.
During the SDL, we engage app developers with the security review team, using a combination of physical reviews and tooling, threat modeling, and static code scanning, to help us begin addressing security at the software development level.
Some of the specific security risks and vulnerabilities we are seeking to mitigate in our internal mobile apps include:
- Authentication/authorization. Many mobile apps are designed to bypass additional authentication or only use single factor authentication by default. We require multi-factor authentication to protect both company data and personally identifiable information (PII).
- App permissions. We try to ensure that default app permissions that are not required for the app to work be locked down. For example, turning off the GPS permission in an application that doesn’t require location services can help avoid potential privacy issues.
- Injection. An injection attack consists of insertion or “injection” of a SQL query, input validation, SQL injection or cross-site scripting (XSS) via input data from the client to the application. This threat is still an issue with many mobile applications.
- Data at rest. Data at rest should be encrypted or stored in the cloud to help ensure that other apps on the mobile device cannot access company data.
- Cryptography/encryption. Mobile apps are less vulnerable to attack compared to non-mobile applications because of the limited data storage of mobile devices. The biggest risks related to cryptography stem more from SSL/TLS risks.
- SSL/TLS. Missing or poorly configured SSL/TLS configurations on a mobile device or server, apps that send sensitive data over HTTP, or configurations that downgrade from HTTPS to HTTP protocol can leave an app vulnerable to man-in-the-middle attacks or remote code execution.
- Open source (first-party, third-party, or malicious). Not keeping up with latest versions of critical libraries (client-side OpenSSL, AFNetworking) can pose direct risks to mobile apps. A continuing stream of patches, or hot fixes for SSL/TLS issues means that over time, the mobile app is increasingly vulnerable to man-in-the-middle attacks, information disclosure, and remote code execution. Third-party and open source code might include or download malicious code targeting identity theft—some of the most blatant examples include adware SDKs.
- Data-in-transit. Poorly implemented inter-process communication between apps can allow a process or application isolation.
- Vulnerable web content and services. Servers with stale critical-component patching (server-side OpenSSL, Java) can sabotage even the most secure mobile application. This also creates risks of man-in-the-middle attacks, information disclosure, and remote code execution.
Mobile app publishing and release
Mobile app development and publishing is not a one-size fits-all process. At Microsoft, the publishing and release distribution chain for internal mobile apps includes:
- Development and testing. Early builds of an app are made available to a small number of users, typically only the app development team.
- App validation. Pre-production versions of apps are released to a limited number of users, usually only within the development team’s organization, for platform and feature validation.
- Early adoption. Pre-production builds of an app are released to a larger number of internal user groups that are participating in pilots.
- Production release. Production release of internal mobile business apps are published to our Company Portal.
Internal app publishing at Microsoft follows a certification process that was designed to satisfy corporate policies for standardization, based on certification factors that include security, privacy, quality, and governance.
Mapping SDL validation requirements to deployment rings
To help our engineering teams address security throughout the development life cycle of internal mobile business apps, EMAP and our SDL security and privacy review and sign off requirements map to deployment ring “gates.” The gates define the various stages of sign-off that a mobile application must have to be released to each distribution ring during the different stages of its development. We based our ring classifications on the app’s intended reach and distribution, as we found it challenging to base our ring classifications solely on an actual number of users that an app is being deployed to. Some app development teams might only include a couple of members, while some can number in the hundreds. Typically, if an app’s distribution is more than a dozen users, it is classified as ring 1 and we start our SDL requirements process. Figure 2 offers an overview of each ring.
There are four rings we focus on for enterprise distribution of mobile internal business apps that are being published to the Company Portal:
- Ring 0: Me and my Team. Distribution through HockeyApp to a small number of users, typically only includes the immediate team. At this stage, we do not require the SDL process.
- Ring 1: Me and My Org. Distribution though HockeyApp to a larger number of users (usually within the app developer’s org) before pilot; is not a full enterprise-wide distribution. At this stage, we require that the SDL process has been started. The application developer registers their app, submits a questionnaire, and receives a unique security review ID number that will be used by EMAP to track progress of the security review and sign-off attestation.
- Ring 2: Enterprise Dogfood (MS Elite). At Ring 2, the app development team is ready to publish their application to formal pilot groups across Microsoft from HockeyApp. The Microsoft Elite program allows for testing of pre‑production mobile applications across the entire company. Before an app can be distributed, we require that the security review be complete and signed off.
Note. Some configurations within HockeyApp allow an application to be visible to the entire company. To help ensure that apps are compliant with our SDL requirements, we use the HockeyApp SDK to download a complete list of apps that are visible across the enterprise.
- Ring 3: Publish to Company Portal / Enterprise portal. Enterprise-wide distribution of a ready-for-production app through the Company Portal. We have configured HockeyApp to publish to our Intune Company Portal through the EMAP publication checklist. The checklist includes fields for the security review ID and for the privacy reviewer contact information. EMAP’s automated workflow then validates the information and certifies the app for publishing to the Company Portal.
Our experience integrating SDL validation into our mobile app publishing processes and tools surfaced some best practices that other organizations might find helpful. These strategies can be applied in organizations that develop either a large or small number of mobile applications. Regardless of the number of mobile applications being developed, any organization can benefit from supporting greater business agility by automating and streamlining security controls such as malware scanning, compliance, and privacy review attestation. Best practices include:
- Keeping an inventory and tracking progress. An effective SDL validation program should include a comprehensive inventory of apps that are in development, or have been published.
- Each app should have a distinct and unique identifier specific to a version. Assigning a new identifier to each agile development sprint can create overhead, so a balance must be met for agile projects.
- Support governance. Governance should include effective controls and offer the ability for enforcement through tooling. EMAP helps ensure both malware scanning and process compliance.
- Minimum required tooling for SDL compliance should include robust malware scanning. In addition to malware scans, periodic open source review and static code analysis, as well as static analysis of the compiled mobile application binary, should be performed. Tooling that examines the mobile app’s binary code will reveal flaws that are not otherwise visible with static code analysis. Binary analysis tooling should focus on actual security exploits over user behavior or the contents of the binary’s manifest.
Note. Malware scanning applies to scan of an app’s binary (code) itself, not malware scanning on a specific device. Although having anti-malware on your mobile device is always good idea.
- Track your progress. We enabled the right telemetry to track progress through the SDL review and validation process to manage app releases and publishing. Building tooling on top of the concept of deployment rings and requirement gates helps ensure that apps are not released internally or externally before they are ready.
- Pay attention to the mobile app threat landscape. The nature of mobile apps often introduces new challenges when dealing with existing risks and mitigation controls. Stale open source and poor SSL/TLS implementation are the two largest risks that we face.
- Use development platforms that support SDL. Effective implementation of an SDL also depends upon a development platform that includes centralized code repository, a process for code check-in, and a safe testing environment. Visual Studio Team Services, in conjunction with HockeyApp/Visual Studio Mobile Center can be the backbone of these requirements for your development environment.
- EMAP is used within Microsoft for SDL requirements enforcement via tooling such as malware scanning as well as compliance, using the app’s unique identifier.
- HockeyApp / Visual Studio Mobile Center is a developer-centric tool for managing pre-production builds.
Business continues to demand that process and security validation become increasingly automated. These business drivers will result in continued adoption of automated methods for both static and dynamic scanning of compiled mobile application code. As the Visual Studio Mobile Center platform matures, we also hope to pursue further integration of EMAP that will include external or consumer app publishing.
Some areas that we are focused on include:
- Migration away from security and privacy attestation in separate tools across Microsoft, to a single approach embedded within Visual Studio Team Services.
- A continued evolution and improvement of static and dynamic analysis of web sites and web services.
- Direct integration of static code analysis tools within the Visual Studio Team Services platform. Please see the Security for Modern Engineering whitepaper for more details about how this has been accomplished.
- Static and dynamic analysis of mobile application binaries performed during pre-production (integrated with HockeyApp) as well as continuous scanning of production releases.
- Continuous refinement and deployment of the methodologies that help to ensure consistent SDL compliance and privacy sign-off.
- As the Visual Studio Mobile Center platform matures, EMAP will be integrated further.
We introduced automation and integration with EMAP to implement a SDL requirement validation process for mobile apps that begins to address security and privacy early in the app development life cycle. Integrating the SDL with EMAP is enabling a digital transformation that has reduced the amount of time it takes to publish mobile apps to the Company Portal.
Security and privacy reviews are no longer a bottleneck that mark the end of the app development cycle and the start of the publishing process—the reviews are built into the process from the beginning. We are helping app teams and stakeholders focus on the business value of their apps rather than leaving them to navigate through a decentralized review and sign-off process that can block their app’s release. We can call early attention to compliance items, allowing developers to include those findings in their regular development sprints, while iterating through early app versions for testing.
For more information
Microsoft IT Showcase
© 2017 Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.