Mobile devices have overtaken desktop devices as the leading means to access applications and the internet. The growing demand for mobile apps creates a need for developers to improve their processes and release new features at an unprecedented rate to stay ahead of the competition. Consequently, the development community embraces newer processes such as Agile and the culture of DevOps to produce their mobile applications much more quickly.
Modern software development cycles, which include a lot of automation and use of third-party code with backend API services, have broken the legacy security model for development, when there was plenty of time to look for and fix security issues manually before a product release. As a result, the risk of data security vulnerabilities in mobile apps and the potential for a breach of regulatory requirements are higher than ever. This is creating an imperative need to innovate the process for application security for mobile applications.
Top security questions for mobile app security
Steadfast mobile app security for business applications is especially critical in order to ensure customer trust and to maintain a good business reputation. To provide a well-rounded security evaluation of any mobile app, the security team must ask and answer a number of important questions:
- Does the app have any Priority 1 vulnerabilities? This is obviously a very serious concern. No application should ever be released to the public if it contains a known vulnerability that a remote attacker can exploit and use to extract data.
- Will the app get rejected by Google or Apple? An app that fails to adhere to appropriate guidelines for securing personal or sensitive information could be rejected by the top mobile app stores.
- Are third-party software development kits or open source software leaving security holes? Most mobile apps today invoke third-party tools or services to save time and money. SDKs and open source software are not immune from having their own security vulnerabilities, which affect any apps that use them.
- Does the app have an issue that is widely known? Some security flaws are so egregious that they gain widespread attention, such as when Forbes magazine wrote about the ZipperDown vulnerability affecting nearly 16,000 mobile apps. A Chinese research group exposed the applications that contained this flaw, essentially bringing unwelcome public shame to those app owners.
- Is the app in full compliance with the government and/or industry regulations we must adhere to? Most companies have an obligation to meet data security and privacy requirements outlined in one or more regulations such as HIPAA, PCI DSS, FERPA and GDPR. Security directors must work closely with their application development counterparts to ensure that all compliance requirements are met and maintained throughout an application’s life.
- Are there any data-in-transit exposures? An insufficient transport layer can allow a hacker to gain access to customer data and steal or modify it at will. Mobile apps have a distinct advantage over web-browser apps in their ability to protect data-in-transit, but it requires developers to add anti-eavesdropping protection with SSL/TLS certificate pinning.
- Is the app connecting to any malicious endpoints? Third-party code might prompt the application to reach out to malicious endpoints, such as a command-and-control server. This, of course, cannot be permitted in any mobile app.
- Does the app expose customer data to third-party applications? Some third-party apps might surreptitiously harvest data from an application and take it back for their own unauthorized use.
- Are there any data-at-rest exposures? Unintended data leakage can occur if critical app data is stored on an insecure location of the mobile device, making it accessible by other apps or even by the user.
Security experts might have additional questions, but the issues above are table stakes for assuring data security and privacy in any mobile app.
How mobile AppSec is verified today
The typical way that development teams validate their application’s security posture is through penetration testing, which can take weeks or longer. It’s a very labor-intensive, manual process that must be repeated for every new build of the application. One failed pen test can hold up the application release until a fix is made and a retest finds no additional vulnerabilities. This causes stress with the DevOps team that is anxious to meet the business objective of getting the release out the door.
There’s another obvious problem with relying on testing procedures performed by people: They don’t scale well.
Companies with a portfolio of applications soon discover they can never build a security team big enough – and with the quality of people they need – to move as fast as their software development team. Moreover, consistency can be an issue, as one person might overlook something important that another person would find. Security issues change quickly, and a person’s knowledge and expertise can easily fall behind the times.
Security teams often use static code analysis tools to evaluate their apps. However, many of the tools in this category are notorious for finding theoretical vulnerabilities that can never be exercised in runtime but instead are code hygiene concerns. What’s more, the effectiveness of the tools is frequently measured on the number of issues that are found, which creates a poor signal-to-noise ratio for both security and development. The true measure of effectiveness is the number of real-world issues that are found and fixed before the production release. The static and dynamic analysis tools need to focus on not just finding security issues, but also on a path to fixing the issues quickly. This latter approach provides a much higher value to the DevOps and Security teams.
Given that the manual penetration testing process requires a significant and costly security staff, resources and tools, it’s a very inefficient way to repeatedly validate security and compliance as part of the modern application continuous integration/continuous delivery (CI/CD) cycle. What’s more, manual pen testing is point-in-time and outside the software development life cycle (SDLC), so it tends to burden and slow the DevOps process.
A better approach is to automate the security and compliance validation checks continuously throughout the application development cycle, effectively automating what the penetration testers do manually and accelerate security within the entire DevOps stack.
Automate security for mobile app SDLC
Today, when software development is delivered by DevOps teams, developers publish their code into a continuous and rapidly available cycle. The developers review and test the code, put it through a build, and then compile the code. Lastly, it is published for general release. All of that can be done with automation in order to maintain Agile velocity and the speed synonymous with the DevOps world.
Now it’s time to add security early into that flow without needing any kind of manual intervention. Thus, when the software is being compiled and going through its normal testing, it's also going through an automated security test to make sure that it adheres to all the necessary security checks, as well as compliance requirements.
When the test results are fed back into the DevOps workflow, this prevents the development process from being held up because security is now an integral part of the normal DevOps CI/CD cycle. Security validation is done continuously and at the scale and speed needed to keep up with development today. This model follows the DevSecOps practice because development and security are all in one workflow.
Automate “the gauntlet” of security checks and processes
The goal is to have a truly comprehensive mobile app security program that is part of the development lifecycle. Whether the program is primarily manual or fully automated, the process must go through a gauntlet of measures, including the following:
- Conduct static and dynamic code analysis
- Discover dynamic runtime security flaws
- Alert on newly discovered Priority 1 issues and app store blockers
- Provide secure code samples and recommendations to fix the issues found
- Identify vulnerabilities in third-party SDKs
- Inspect open source libraries for insecure code
- Report on compliance for PCI, HIPAA, GDPR, FTC regulations, etc.
- Protect against SSL/TLS man-in-the-middle attacks
- Protect against third-party keystroke loggers
- Encrypt data storage for the app
- Help remove spyware and malware
Realistically, no human-focused security program can perform all those activities in a reasonable amount of time—let alone perform them continuously in a fast-paced SDLC framework. Automation is the only way to get to a true DevSecOps model. Many of the world’s largest and most innovative companies – Netflix, Facebook, Goldman Sachs, JPMorgan Chase, PayPal, Airbnb, Bank of America, and more – use security automation as an integral part of their mobile app development lifecycle.
For teams looking to follow this DevSecOps practice, innovative tools are available today that fully automate the measures above. Agile and DevOps development models are moving too quickly to still allow for manual security assurance and compliance validation.
By Himanshu Dwivedi, Founder and CEO, Data Theorem
