Home > All, Security Issues > Appstore security: a new report from ENISA

Appstore security: a new report from ENISA

September 13, 2011 Leave a comment Go to comments

ENISA, the European Network and Information Security Agency, has produced a new report: Appstore security – 5 lines of defence against malware. Its purpose is to help the burgeoning app store market protect against infiltration from malapps (not a widely used word yet, but watch it grow); smartphone apps pretending to be apps but really just plain malware.

Appstore security

Appstore security: a report from ENISA

The five lines of defence range from the bleeding-obvious through good-idea-but-don’t-hold-your-breath to illustrations of the-conflict-between-security-and-liberty. They are

  • App review – bleeding obvious but not foolproof
  • Reputation – not foolproof
  • Kill switch – hang on a bit
  • Sandboxed apps – bleeding obvious
  • jailing – hang on a bit more

App reviews should obviously be done. But they’re not foolproof and are time-consuming and costly. New app stores will minimise them in order to reduce their own costs and speed the population of the store. Even where they are performed, with or without the help of automated testing, there is no guarantee against false negatives.

Reputations can be manipulated. Cyber criminals have shown that they are willing to play the long game. With enough time and resources it would be easy enough to release a few genuine and good apps before slipping in, backed by a good reputation, the bad one.

Kill switch. I don’t want one. And they don’t necessarily work. If I buy something, it is mine (I’m sick of the industry selling me something and then revealing later or in the small print that I only rented it). If I buy it, it’s mine. Therefore only I should be able to remove it. Not the software developer, not the app store, not the device manufacturer, not law enforcement and not the government. And anyway, they don’t work. DroidDream foiled the Android kill switch by simply operating outside of the sandbox. Here’s a good security principle: if something can be set up by software, it can be taken down by software. And another thing:

in a military setting, apps may be mission-critical and the app revocation mechanism may need to be turned off.

I’m not sure that I like being told that only the military has mission critical apps. My apps are critical to me.

Sandboxing. Now that is a good idea. It probably has more to do with the OS developer than the app store provider, but it’s still a good idea. It may not work nor be possible in all cases; but it’s still a good idea.

Jailing. Again, this has more to do with the OS developer and the hardware manufacturer than the app store itself. And again, if something is mine, I don’t want a third party telling me what I can do with it. It may be good security but it infringes my rights as a human being.

You may think I’m being overly critical and a bit frivolous, but I’m not. This report will make not one iota of difference to the app market. I wish ENISA and all the myriad other European agencies would spend the time and money we spend on them on something more worthwhile. Especially when the solution to malapps is easy: make the app stores liable. Make them liable for any losses incurred through malapps bought or downloaded from them. And where there is no measurable loss, simply fine the pants off them. That will stop malapps from app stores in their tracks.

ENISA

Categories: All, Security Issues
  1. September 15, 2011 at 3:38 pm

    As one of the authors, allow me to briefly reply to your comments.

    First of all thank you for reviewing the paper, I appreciate the feedback. Rants can be very refreshing.

    It is true that the lines of defense are not in anyway controversial and may seem obvious. We felt that there was the need to outline the different defenses that can be used, as most of the app stores and platforms are not very explicit about these defenses. This is confusing for consumers.

    Allow me to comment on your criticism of the killswitch. I would like to note that we do not exclude that there are other (than military) settings where a killswitch is unwanted. Bare in mind that most of the users do not want to keep malware on their device. We even mention that an optout where appropriate should be offered.

    About jails: We are not saying that jailbreaking should be illegal, or that consumers should have no means of using alternative appstores… only that this should not be made so easy as to allow drive-by download attacks (email+link, genuine looking appstore, install approval, click, infected).

    Your alternative proposal, to hold appstores liable for software vulnerabilities, is really a legal solution. I think it is a very interesting subject, but (big disclaimer) I am not a legal expert:

    Some issues with this:

    – It would be easy to set up a rogue appstore, run it from some obscure country, fill it with some infected apps. It would also be relatively easy to trick users into installing from there. Your solution, to simply find a suspect, and a court to fine, sounds to me a bit complicated. Just think of all the extradition procedures, harmonisation of laws, etc. that would be needed. Let’s ignore rogue appstores in the sequel.

    – If I look at other platforms/software I do not see many consumers being granted compensation by courts, nor do I see many software vendors being fined for selling/distributing flawed software. Now this could change in the future, but I think we should address security in the meantime as well.

    – Secondly, judges usually start fining people when it is clear they have been negligent or had malicious intent. That requires some kind of definition/agreement of what are best practices and sufficient measures/defences.

    – Another issue with liability is – I think – the following: Imagine the opensourcing of software to continue. Android, Linux, Openoffice, etc, are example of this trend: A couple of volunteers decide to solve a problem (text editing say) by writing some software routines (say openmoko)… they publish them free of charge and they disclaim that you should only use this software at your own risk. Would you think it is fair to still fine them for flaws? What I am trying to say is that there are numerous examples of free opensource software/apps/platforms, and that we still need to address security there as well. Do you agree that the liability solution would only work for commercial software/platforms? In that case, what do we do about the rest?

    Looking forward to discuss with you – software liability is a fascination topic🙂

    Best, Marnix

    Like

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s