Most of surveyed consumers (80%) stated that they would seize using a company’s services, if its mobile application would’ve gotten compromised in a data breach. The 2015 survey includes about 300 developers and 400 consumers as its participants.
The flaws that result in mobile app data breaches lie in the mobile OSs to some extent, same as in the applications. Over 1 bn. gadgets running vulnerable iOS and Android OS were subject to the past year’s Stagefright attack, as reported by Bluebox Security. This number comes from the install base of mobile gadgets with vulnerable operating systems. Thus, mobile can be considered one of the next big threat vectors in security.
Let’s take a look at how enterprises may abridge these breaches and keep their clients, instead of making them run to competitors.
Stagefright attacks targeted core mobile operating system flaws in the architecture of the Android media playback engine. As of XcodeGhost, a hacker was adding malware to a pirated Xcode copy used for iOS app building by developers. During the use of hacked Xcode copies for iOS application building by developers, malware was automatically injected into the application by the pirated version. Since developers were employing an Xcode version, although a hacked one, for building their applications simply meant that the App Store would eagerly clear it and list it as a clean application.
Since the release of iOS 9, Apple has patched well over 100 security vulnerabilities. But, how can mobile application developers assure their apps’ security, when the vulnerability is in the mobile operating system?
Users are responding to the unchallengeable evidence of seemingly insuperable insults to their mobile transactions and activities. It was found out that in the last 6-12 months Apple started receiving more requests from consumers concerning data privacy, security, and what happens to their data next. The thing is that two years ago barely anyone asked about something like this.
Reported unnecessary mobile application risks and advanced data breaches make users consider the seriousness of the threat to their personal data to the point of evolving their own action plans in case of future violations. In case a company isn’t able to guarantee mobile app security, clients will respond by referring to another service provider or vendor. One can get something at Wal-Mart, Jet, Amex, Target, or anywhere else they want, so there is a quite low switching cost, and users can actually take an issue into their own hands, if they want to.
Companies and their mobile application developers have to make inbuilt security from the head-on by building in encryption, implementing mind-confusing techniques in the app’s security framework, and conducting deep analysis to comprehend app integrity. It is necessary have understanding of app integrity and the stat of its libraries needed at runtime and those in memory. In order to create self-defendant applications, developers have to estimate a risk score and make a profile, and then use them for building in counter measures.
OWASP – Open Web Application Security Project – is one of the organizations working on making self-defending mobile apps. They have established the AppSensor project that, according to them, “defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications.” And thus, instead of being an add-on, mobile app security is becoming a native component, as developers are building intelligent IDS into applications, working at the app layer, and integrate automated responses to deal with each intrusion and malicious activity.
In their approach, the OWASP use identification points that include various exceptions and trends along with reputation and honey traps for internal attack detection. AppSensor is seeking to analyze app logs and the identification points inside the app, on the whole and independently, to define any malicious behavior, and then moving to blocking the malicious user.
As claimed by the OWASP, mobile apps may understand users and their actions, intended targets of the latter, and whether the application should permit those user-action combinations, but they need some help to do this. They want to make AppSensor able to determine advanced threats that have to do with evasive or exploitative behaviors. AppSensor makes the app able to permanently ban the user or to take other actions according to the company’s rules and policy. Banning restricts attackers to the app’s perimeter, as the OWASP states.
According to the OWASP, AppSensor allows companies to avoid blocking users automatically and get alerts about attacks via security monitoring and then look into the event prior to taking any actions in response to it. It all depends on each organization’s tolerance for particular needs and risks for a mobile app. As user tolerance and company tolerance for risk may drastically differ, it is reasonable to consider the benefits of instant and automatic banning, where it makes sense.
The OWASP also offer suggestions for identifying what app behaviors are malicious, response recommendations, advice in implementing an AppSensor-based system, and other things organizations can benefit from, when using the solution.
While AppSensor seems, like a valuable thing to consider, when dealing with security flaws in mobile apps, there are also other solutions available that can make it work since the very first digits of app development. One of the best examples is Onegini – a platform that provides all the necessary tools for mobile app development with maximum and most effective security up to date. There’s a free test version available on the company’s website that enterprises can run before deciding whether they do or do not want to use it for their business. However, it should be noted that Onegini is one of those few ways that can make clients stay with a company despite all the mobile security threats out there.