A 2015 mobile app survey from Bluebox Security supports the notion that most consumers would turn away from vendors if their mobile app is compromised and take their business elsewhere.
The vast majority (80 percent) of consumers surveyed said that they would stop patronizing a company if its mobile app was compromised in a breach, say the Bluebox Mobile App Survey results. Participants in the 2015 survey include approximately 400 consumers and 300 developers.
The vulnerabilities that lead to mobile app breaches lie as much or more in the mobile OSs as in the apps. More than 1 billion devices running affected Android and iOS operating systems were vulnerable to the Stagefright attack this year, according to Adam Ely, CSO, Bluebox Security. That number is based on the install base of mobile devices with the vulnerable OSs. “That makes mobile the next big security threat vector,” says Ely.
CSO covers how to help enterprises curtail these breaches and keep consumers from running to competitors.
The source of mobile threats, consumer sentiment
The attacks on Stagefright targeted core mobile OS vulnerabilities in the Android media playback engine architecture. In the case of XcodeGhost, an attacker added malware to a pirated copy of Xcode, which developers use to build iOS applications. “When developers used this hacked version of Xcode to build their iOS apps, it automatically injected malware into the app,” says Ely. The fact that developers were using a version of Xcode, albeit a hacked version, to build their apps meant that The App Store would readily clear the app and host it as a clean app.
“Apple has patched more than 120 security flaws since it released iOS 9,” says Ely. When the vulnerability is in the mobile OS, how can mobile app developers ensure the security of their apps?
Consumers are responding to the unassailable evidence of seemingly unstoppable affronts to their mobile activities and transactions. “In our private conversations with our customers, we found that they were starting to get more inquiries from consumers in the last six to 12 months about security, data privacy, and what’s going to happen with their data. This was something that two years ago most consumers never asked about,” says Ely.
Adam Ely, CSO, Bluebox Security
High-profile data breaches and reported unnecessary mobile app risks are leading consumers to consider the gravity of the threat to their PII to the point of developing their own plans of action in the event of further breaches. If an enterprise can’t ensure mobile application security, customers will respond by clicking elsewhere. “I can buy something at Target, Wal-Mart, Amex, Jet, wherever I want, so there’s a very low switching cost, so consumers have the ability to take a matter into their own hands,” says Ely.
Instructing mobile apps in the art of self-defense
Enterprises and their mobile app developers should build security in from the start by building encryption in, implementing obfuscation techniques with a security framework, and performing deep analysis to understand application integrity, explains Ely. “You need to understand the integrity and state of the libraries the app requires at runtime and the libraries in memory. You need to build out a risk score and profile and then use that to build in counter measures to create self-defending apps,” says Ely.
Ely is not alone in disseminating self-defending app terminology. The OWASP is invested in self-defending apps. The OWASP has established the AppSensor project, which “defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications”, according to OWASP. By working at the application layer, building intelligent IDS into mobile apps together with automated responses to address each intrusion, mobile app security becomes native rather than an add-on.
The OWASP approach uses detection points including any of a variety of exceptions and trends as well as honey traps and reputation to identify attacks internally. AppSensor seeks to analyze application logs and the detection points within, independently and on the whole, to determine malicious user behavior, then moves to block the user, according to the OWASP.
According to the OWASP, with help, mobile applications can understand users, their actions, the intended targets of those actions, and whether the app should allow those combinations of users and actions. The OWASP intends AppSensor to identify advanced threats that are engaged in exploitative or evasive behaviors. AppSensor enables the app to block the user permanently or to take other action as the enterprise sees fit. Blocking limits attackers to the application’s perimeter, according to the OWASP.
The OWASP notes that AppSensor permits enterprises to opt out of blocking users automatically so they can receive attack alerts using security monitoring and investigate the event before making a response decision. “The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application,” the OWASP says. Since an organization’s tolerance for risk and the tolerance of their consumers or any other affected party can differ, it is worth considering the advantages of immediate and automatic blocking where it is reasonable.
Through the AppSensor project, the OWASP offers recommendations for determining what application behaviors are malicious, suggestions for responses, guidance in implementing a system based on AppSensor, and a Java reference implementation that the organization can integrate into its application(s), according to the OWASP.
Other entities claiming some form of self-defending app approach include Apperian, Mocana, and Metaforic.