How Google is fighting back against Android threats
Following on from my previous post on Android threats (this post is based upon research of Google’s Bouncer feature), Google’s strategy to combat Maldroids is four-fold:
Prevent security issues from occurring
Minimize the impact of any security issues
Detect vulnerabilities and security issues
Respond to vulnerabilities and security issues swiftly
The Android security team performs design reviews and code audits, device testing of the Android OS. They manage security processes and respond to incidents. They encourage security collaboration between Google, partner security teams, industry and academic partners. They also evangelize Android security by documenting security practices and development best practices. This all sounds a lot like what Microsoft does with its SDLC, and the Android Security Team’s function sounds a lot like Microsoft’s Trustworthy Computing group.
In terms of the OS itself, Android is a stripped down Linux kernel with minimal root processes, no listening ports with automated testing, code reviews and two acronyms called ASLR and NX whose expansion I don’t know. It uses full disk encryption, keychain management, an account manager, device management, and OTA updaters for the apps and the OS.
A user, partner or Google itself can flag an app’s content for review. When this occurs, a manual review process is initiated. If the content violates the market’s policies, it is removed. A team of analysts works on detection and is constantly improving and the process is transparent and free to end users with no cost or performance impact (this sounds a lot like the spam team’s role on a daily basis).
When takedowns occur, the application is suspended and the developer is banned. Google also works with law enforcement, contacts the ISP to take down any C&C’s, pushes an automated clean up tool, and reviews related applications and developers.
This entire process sounds almost exactly like Microsoft:
Windows is open, Android is open
Google has an Android Security Team, Microsoft has Trustworthy Computing
Google has a team of analysts reviewing apps manually, Microsoft has a team of spam analysts reviewing spam manually
Google has an automated Android clean up tool, Microsoft has the Malicious Software Removal Tool
Google’s Sec Team has security best practices, Microsoft does too.
For these reasons, I can’t criticize the Android platform for being so insecure because their response is a lot like Microsoft’s. I came away from these talks with the impression that the price to pay for openness is insecurity (the Internet is the same way).
However, there are some key differences in Android from Microsoft:
Apps permissions are granted at install time, not at runtime.
Permissions cannot be locked down later.
The user is presented with a long list of what permissions the app requires and the only options are grant all/do not install, there is no granularity.
The capabilities are often difficult to understand and/or evaluate why they might be needed.
I admit that I am not an expert on securities permissions and these types of models; the above part I include after discussing it internally here at Microsoft.
Google asserts that their process is getting better and people are downloading fewer rogue apps. I scoff at this because as Android becomes more popular, it will become a bigger target precisely because it is popular and open. That’s what happens.
It also means that if Windows Phone ever catches up, it will encounter the same problems.