OWASP - User contributions [en]

Projects/OWASP IoTs Project

2013-12-07T15:37:59Z

Vinaykbansal:

{{Template:Project About
| project_name =OWASP IoTs Project
| project_description ="Advances in technology have led to the creation of intelligent and connected devices -- Internet of Things (IoTs) -- that can sense and act upon the environment. In not-so-distant future, IoTs will be pervasive in all aspects of human life such as: home, education, healthcare, and commerce. Since IoTs will access and act upon physical and digital reality surrounding humans, their security and privacy is of prime importance. A lack of appropriate security in IoTs can lead to grave outcomes including physical harm to humans. It is crucial that we study the IoT architectures and technologies to uncover the security flaws. And guide developers how to securely develop IoTs.

Goal of the project is to extensively research the various architectural models (peer-to-peer and client-server models) used by IoTs such as: Connected Home Devices (smart TVs, gaming consoles, toys) and Sensor devices (monitoring cameras, motion detectors). And identify the flaws in design, implementation and communication models.One of the goal for this project is to publish these security flaws and associated risks. Second goal for the project is to provide the secure security architectural patterns for IoTs to guide secure design and development. "
| project_license =Creative Commons Attribution ShareAlike 3.0 License
| leader_name1 =Vinay Bansal
| leader_email1 =Vinaykbansal@owasp.org
| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp_iots_project
| project_road_map = https://www.owasp.org/index.php/Projects/OWASP_IoTs_Project/Roadmap
}}

OWASP IoTs Project

2013-12-07T15:27:10Z

Vinaykbansal: /* = Contributors */

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP IoTs==

OWASP XXX is...

==Introduction==

Write a short introduction

==Description==

Write a description that is just a few paragraphs long

==Licensing==
OWASP XXX is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is XXX? ==

OWASP XXX provides:

* xxx
* xxx

== Presentation ==

Link to presentation

== Project Leader ==

==== Leaders ====
*Vinay Bansal
*Pankaj Telang
*Shankar Babu

=== Contributors ===

== Related Projects ==

* [[OWASP_CISO_Survey]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of XXX is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Example_Project_About_Page}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP IoTs Project

2013-12-07T15:26:58Z

Vinaykbansal: /* Leaders */

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP IoTs==

OWASP XXX is...

==Introduction==

Write a short introduction

==Description==

Write a description that is just a few paragraphs long

==Licensing==
OWASP XXX is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is XXX? ==

OWASP XXX provides:

* xxx
* xxx

== Presentation ==

Link to presentation

== Project Leader ==

==== Leaders ====
*Vinay Bansal
*Pankaj Telang
*Shankar Babu

==== Contributors ===

== Related Projects ==

* [[OWASP_CISO_Survey]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of XXX is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Example_Project_About_Page}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP IoTs Project

2013-12-07T15:26:33Z

Vinaykbansal:

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP IoTs==

OWASP XXX is...

==Introduction==

Write a short introduction

==Description==

Write a description that is just a few paragraphs long

==Licensing==
OWASP XXX is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is XXX? ==

OWASP XXX provides:

* xxx
* xxx

== Presentation ==

Link to presentation

== Project Leader ==

==== Leaders ====
*Vinay Bansal
*Pankaj Telang
*Shankar Babu

*ontributors

== Related Projects ==

* [[OWASP_CISO_Survey]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download

== News and Events ==
* [20 Nov 2013] News 2
* [30 Sep 2013] News 1

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of XXX, the priorities are:
* xxx
* xxx
* xxx

Involvement in the development and promotion of XXX is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Example_Project_About_Page}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

User:Vinaykbansal

2013-09-29T15:19:14Z

Vinaykbansal:

Vinay K. Bansal works as a Senior Information Security Architect in Cisco’s Corporate Security Programs Office (Infosec). He is the global architectural lead for Cisco's Cloud hosted offerings (such as WebEx, Social, Jabber,..). In his role Vinay focuses on doing architectural assessments and improving security of Cisco's hosted products, IT Web Applications, databases and mobile services. Vinay has 20+ years of IT industry experience in successfully leading; architecting and implementing IT based solutions with focus on security/Internet/e-commerce applications. Vinay worked at various Fortune 500 companies including Cisco (last 9 years), IBM, Nokia, Experian, and Plessey Telecom (UK). Vinay has presented in various conferences including CiscoLive, SANS, OWASP, iFront. Vinay holds a Master's Degree in Computer Science from Duke University.

Projects/OWASP Cloud ‐ 10 Project/Releases/Initial Pre-Alpha List of OWASP Cloud Top 10 Security Risks

2012-09-24T10:45:29Z

Vinaykbansal:

{{Template: <includeonly>{{{1}}}</includeonly><noinclude>Release About</noinclude>
| project_name = OWASP Cloud ‐ 10 Project
| project_home_page = Category:OWASP Cloud ‐ 10 Project

| release_name = Initial Pre-Alpha List of OWASP Cloud Top 10 Security Risks

| release_date = Still under work

| release_description = Aim of the "OWASP Cloud-10" list is to help balance security risks with the cost advantage that the Cloud and SaaS model provides. We expect the Cloud and SaaS providers to be indirect audience for "OWASP Cloud-10", when they try to showcase their security controls to potential customers against this list.

| release_license = [http://creativecommons.org/licenses/by-sa/3.0/ '''Creative Commons Attribution Share Alike 3.0''']

| release_download_link = https://www.owasp.org/index.php/OWASP_Cloud_%E2%80%90_10/Initial_Pre-Alpha_List_of_OWASP_Cloud_Top_10_Security_Risks

| leader_name1 = Vinay Bansal
| leader_email1 = vibansal@cisco.com
| leader_username1 = Vinaykbansal

| contributor_name1 = Shankar Babu Chebrolu
| contributor_email1 = shbabu@cisco.com
| contributor_username1 = Shankar_Babu_Chebrolu

| contributor_name4 = Ludovic Petit
| contributor_email4 = ludovic.petit@owasp.org
| contributor_username4 = Ludovic_Petit

| contributor_name[1-10] =
| contributor_email[1-10] =
| contributor_username[1-10] =

| release_notes = https://www.owasp.org/index.php/Projects/OWASP_Cloud_%E2%80%90_10_Project/Releases/Initial_Pre-Alpha_List_of_OWASP_Cloud_Top_10_Security_Risks/Notes

| links_url1 = http://www.owasp.org/images/4/47/Cloud-Top10-Security-Risks.pdf
| links_name1 = Cloud-Top10-Security-Risks' PDF

| links_url[2-10] =
| links_name[2-10] =

}}

Cloud-10 User Identity Federation

2012-09-24T10:39:40Z

Vinaykbansal:

==R2:User Identity Federation==

Identity

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Category:OWASP Cloud ‐ 10 Project

2012-09-24T09:37:22Z

Vinaykbansal:

Cloud-10 Guidelines

2011-12-07T17:00:54Z

Vinaykbansal: /* Guideline Document */

== Guideline Document ==

1. Development / Environment Setting

a) Developer Access
#Jump Server
##Multi factor Autch
##VPN/Cert based Authc

2. Architecture

#Tiering
#Communicaiton
##between zones
##within tiers
##ACLs
#AuthC/Identity
#Encryption
#Integration
## Web Services
##VPN based
#WAF

3. Deployment and Testing
#Hardening

4. Operations
#Patching

== Use Cases ==

#Deploying Third Party
#Building Your Own Application

== Target Providers ==
# Savvis - Shankar
# Amazon EC2 - Vinay
# Google Apps - Pankaj

== Timelines ==

1. Initial Draft from Shankar - Nov 29nd

2. Initial Draft from Vinay - Dec 9th

Cloud-10 Guidelines

2011-11-01T14:24:13Z

Vinaykbansal: /* Timelines */

== Guideline Document ==

1. Development / Environment Setting

a) Developer Access
#Jump Server
##Multi factor Autch
##VPN/Cert based Authc

2. Architecture

#Tiering
#Communicaiton
##between zones
##within tiers
##ACLs
#AuthC/Identity
#Encryption
#WAF

3. Deployment and Testing
#Hardening

4. Operations
#Patching

== Use Cases ==

#Deploying Third Party
#Building Your Own Application

== Target Providers ==
# Savvis - Shankar
# Amazon EC2 - Vinay
# Google Apps - Pankaj

== Timelines ==

1. Initial Draft from Shankar - Nov 29nd

2. Initial Draft from Vinay - Dec 9th

Cloud-10 Guidelines

2011-11-01T14:20:48Z

Vinaykbansal: /* Target Providers */

== Guideline Document ==

1. Development / Environment Setting

a) Developer Access
#Jump Server
##Multi factor Autch
##VPN/Cert based Authc

2. Architecture

#Tiering
#Communicaiton
##between zones
##within tiers
##ACLs
#AuthC/Identity
#Encryption
#WAF

3. Deployment and Testing
#Hardening

4. Operations
#Patching

== Use Cases ==

#Deploying Third Party
#Building Your Own Application

== Target Providers ==
# Savvis - Shankar
# Amazon EC2 - Vinay
# Google Apps - Pankaj

== Timelines ==

1. Initial Draft from Shankar - Nov 22nd

2. Initial Draft from Vinay - Nov 30th

Cloud-10 Guidelines

2011-11-01T14:10:29Z

Vinaykbansal: /* Target Providers */

== Guideline Document ==

1. Development / Environment Setting

a) Developer Access
#Jump Server
##Multi factor Autch
##VPN/Cert based Authc

2. Architecture

#Tiering
#Communicaiton
##between zones
##within tiers
##ACLs
#AuthC/Identity
#Encryption
#WAF

3. Deployment and Testing
#Hardening

4. Operations
#Patching

== Use Cases ==

#Deploying Third Party
#Building Your Own Application

== Target Providers ==
# Savvis - Shankar
# Amazon EC2 - Vinay
# Google Apps - Pankaj

Cloud-10 Guidelines

2011-11-01T14:08:36Z

Vinaykbansal:

== Guideline Document ==

1. Development / Environment Setting

a) Developer Access
#Jump Server
##Multi factor Autch
##VPN/Cert based Authc

2. Architecture

#Tiering
#Communicaiton
##between zones
##within tiers
##ACLs
#AuthC/Identity
#Encryption
#WAF

3. Deployment and Testing
#Hardening

4. Operations
#Patching

== Use Cases ==

#Deploying Third Party
#Building Your Own Application

== Target Providers ==
1. Savvis -
2. Amazon EC2
3. Google Apps

Cloud-10 Guidelines

2011-11-01T14:06:40Z

Vinaykbansal:

1. Development / Environment Setting

a) Developer Access
#Jump Server
##Multi factor Autch
##VPN/Cert based Authc

2. Architecture

#Tiering
#Communicaiton
##between zones
##within tiers
##ACLs
#AuthC/Identity
#Encryption
#WAF

3. Deployment and Testing
#Hardening

4. Operations
#Patching

== Use Cases ==

#Deploying Third Party
#Building Your Own Application

*Target Environment

Cloud-10 Guidelines

2011-11-01T14:02:35Z

Vinaykbansal:

Cloud-10 Guidelines

2011-11-01T14:00:36Z

Vinaykbansal: Created page with "1. Development / Environment Setting a) Developer Access 2. Architecture #Tiering #Communicaiton between zones 3. Deployment and Testing 4. Operations"

1. Development / Environment Setting

a) Developer Access

2. Architecture

#Tiering
#Communicaiton between zones

3. Deployment and Testing

4. Operations

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-07-23T13:26:58Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks:''' Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on device.

*1.1 In the design phase classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs etc.). Process, store and use data according to its classification. Validate the security of methods applied to sensitive data.
*1.2 Store sensitive data on the server instead of client-end device. This is based on the assumption that secure network connectivity is always available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment or OWASP Cloud top 10 for decision support).
*1.3 If possible, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption API’s which use a private key protected by the device unlock code and deleted on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden for the end-user. It also makes stored data safer in the case of loss or theft.
*1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see 2).
*1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet App not usable outside Europe, car key not usable unless within 100m of car etc...).
*1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see 1.8).
*1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:
**Be aware of caches and temporary storage as a possible leakage channel when shared with other apps.
**Be aware of public shared storage such as address book, media gallery, audio files, as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.
**Do not store temp/cached data in a world readable directory.
*1.8 Applications on managed devices should leverage remote wipe and kill switch APIs (OS-level or purpose-built) to remove sensitive information from the device in the event of theft or loss.
*1.9 Data deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).
*1.10 Bear in mind that there is no known secure deletion procedure for flash memory (unless wiping the entire media). Therefore data encryption is especially important.
*1.11 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
*1.12 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
*1.13 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (e.g. use a randomly generated number). Apply the same principles to app sessions as to http sessions/cookies etc....
*1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).

'''2. Handle password credentials securely on the device'''

'''Risks:''' Spyware, Surveillance, Financial malware, UI impersonation User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords.

*2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device. Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. The tokens could be time bounded to the specific service as well as revokable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire after an appropriate (not too long) delay.
*2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate encryption or hashing.
*2.3 Some devices allow developers to use a Secure Element (e.g. http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.html , http://code.google.com/p/seek-for-android/ //Check whether NFC only) - the number of devices offering this functionality is likely to increase. Developers should use such capability to store keys, credentials and other sensitive data.
*2.4 Provide the ability for the mobile user to change/remove passwords on the device.
*2.5 Password credentials should not be copied to backups.
*2.6 Consider using visual/pattern based passwords to aid usability.
*2.7 Check the entropy of all passwords.
*2.8 Ensure passwords and keys are not visible in cache or logs.
*2.9 SMS is not a secure channel and cannot be relied upon to send sensitive information.
*2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration to backend (like embedded password in code). Mobile application binaries can be easily downloaded and reverse engineered.

'''3. Ensure sensitive data is protected in transit'''

'''Risks:''' Network spoofing attacks, Surveillance. The majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network (3G, GSM, CDMA and others), bluetooth. Sensitive data passing through insecure channels could be intercepted.

*3.1 Assume that the network layer is not private. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the wifi network will be appropriately encrypted.
*3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. This includes passing user credentials, or other authentication equivalents. In some cases this may mean encrypting all communication.
*3.3 Enforce strong encryption algorithms and key lengths. Do not allow unsigned certificates and allow only reputable certificate authorities. Do not disable or ignore the SSL chain validation.
*3.4 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in the key chain.
*3.5 The user interface should make it as easy as possible for the user to find out if a certificate is valid.
*3.6 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end points.

'''Reference:''' Google vulnerability of Client Login account credentials on unprotected wifi - [http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''4. Implement user authentication/authorization and session management correctly'''

'''Risks:''' Unauthorized individuals may obtain access to sensitive data or systems. This can be done by circumventing authentication systems (logins) or by reusing valid tokens or cookies.

*4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the data being processed by the application and its access to valuable resources (e.g. costing money).
*4.2 It is important to ensure that the session management is done correctly after the initial authentication. Require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).
*4.3 Use unpredictable session identifiers with high entropy.
*4.4 Use context to add security to authentication - e.g. device ID, IP location, etc...
*4.5 Consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc...
*4.6 Use authentication that ties back to the end user identity (rather than the device identity).

'''Reference:''' Google's ClientLogin implementation
[http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''5. Keep the backend APIs (services) and the platform (server) secure'''

'''Risks:''' Attacks on backend systems, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

*5.1 Carry out a specific check of all data transferred betwen the mobile device and web-server backends and other external interfaces - (e.g. is location or other information transferred within file metadata)
*5.2 All back-end services (WebServices/REST) for mobile apps should be tested for vulnerabilities periodically e.g. using static code analyzer tools and fuzzing tools for testing and finding security flaws.
*5.3 Ensure that the back-end platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
*5.4 Ensure adequate logs are retained on the back-end in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
*5.6 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.
*5.7 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.
*5.8 Web Services, REST and APIs can have similar vulnerabilities to Web Applications. Perform testing of the backend Web Service, REST or API to determine vulnerabilities may exist. Perform abuse case testing, in addition to use case testing.

'''Reference:''' [https://www.owasp.org/index.php/Web_Services]
[http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Perform data integration with third party services/applications securely'''

'''Risks:''' Data Leakage

*6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (reliable source, supported, no backend Trojans, licensing)
*6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.
*6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing in the application.

'''7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data'''

'''Risks:''' Unintentional disclosure of personal or private information. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII).

*7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.
*7.2 Consent may be collected in 3 main ways:
**At install time
**At run-time when data is sent
**Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.
*7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent identifiers linked to central data stores containing personal information?
*7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).
*7.5 Keep a record of consent to the transfer of PII available to the user (consider also the value of keeping server-side records attached to any user data stored).
*7.6 Check whether your consent collection-mechanism overlaps or conflicts with any other consent-collection within the same stack (e.g. APP-native + webkit HTML)

'''Reference:''' EU Law [http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11_Spafford.pdf]

'''8. Implement controls to prevent unauthorised access to paid-for resources (wallet, SMS, phone calls etc...)'''
'''Risks:''' Smartphone apps give programmatic access to premium rate phone calls, SMS, roaming data, NFC payments etc. Apps with privileged access to such API’s should take particular care to prevent abuse given the financial impact of vulnerabilities giving attackers access to the user’s financial resources.

*8.1 Maintain logs of access to paid resources in a non-repudiable format and make them available to the end-user for monitoring (e.g. signed receipt sent to server back-end). Logs should be protected from unauthorised access.
*8.2 Check for anomalous usage patterns in paid resource usage and require reauthentication. E.g. when significant change in location occurs, user-language changes etc.
*8.3 Consider using a white-list model by default for paid resource addressing - e.g. address book only unless specifically authorised for phone calls.
*8.4 Authenticate all API calls to paid resources (e.g. using an app developer certificate).
*8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.
*8.6 Warn user and obtain consent for any cost implications for app behaviour.
*8.7 Implement best practices such as fast dormancy (3GPP), caching etc... to minimise signalling load on base stations.

'''Reference:''' Google Wallet Security [http://www.google.com/wallet/how-it-works-security.html]

'''9. Ensure Secure distribution/provisioning of mobile applications'''

'''Risks:'''
*9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
*9.2 Provide remote kill functionality
*9.3 Feedback channels
*9.4 Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.

'''10. Carefully check any runtime interpretation of code for errors '''

'''Risks:''' Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls. Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware

*10.1 Minimise runtime interpretation and capabilities offered to runtime interpreters.
*10.2 Run interpreters at minimal privilege levels.
*10.3 Fuzz test interpreters.
*10.4 Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data and use of third party API’s - e.g. javascript interpreters.
*10.5 Define a comprehensive escape syntax as appropriate.
//Giles look for an example.

=== Candidates (for consideration) ===

'''A: Some general coding best practices are particularly relevant to mobile coding too'''
*Input Validation and Output Encoding
*Minimise lines of code.
*Use safe languages (e.g. from buffer-overflow).
*Implement a security report handling point (address) security@example.com
*Use static and binary code analyzers to find security flaws.
*Use safe string functions, avoid buffer and Integer overflow.
*Run with the minimum privilege required for the application on the operating system. Be aware of privileges granted by default by API's and disable them.
*Don't authorize code/app to execute with root/sa privilege
*Always perform testing as a standard as well as a privileged user
*Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
*Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) -
*Remove all test code before releasing the application
*Ensure logging is done appropriately but do not record excessive logs, especially including sensitive user information.
*//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps)

'''B. Enforce higher security posture on the device for sensitive apps used in an enterprise context:''' // Vinay to check
*If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Vinay - Still needs to be clarified
*Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
*Banking Apps
*//(Remote Management, PIN enforcement, encryption, application monitoring)
**Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it.

'''C. Protect your application from other malicious applications on the device'''

Risk: User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

*(?? What guidelines could be provided to developers)
U*ser education on using due diligence while installing third party applications on mobile devices

'''D. Provide or use an existing reporting channel for phishing from apps '''

(e.g. if you are a browser plugin developer). //APWG? Can we recommend one?

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-07-23T13:26:03Z

Vinaykbansal: /* Candidates (for consideration) */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks:''' Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on device.

*1.1 In the design phase classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs etc.). Process, store and use data according to its classification. Validate the security of methods applied to sensitive data.
*1.2 Store sensitive data on the server instead of client-end device. This is based on the assumption that secure network connectivity is always available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment or OWASP Cloud top 10 for decision support).
*1.3 If possible, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption API’s which use a private key protected by the device unlock code and deleted on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden for the end-user. It also makes stored data safer in the case of loss or theft.
*1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see 2).
*1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet App not usable outside Europe, car key not usable unless within 100m of car etc...).
*1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see 1.8).
*1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:
**Be aware of caches and temporary storage as a possible leakage channel when shared with other apps.
**Be aware of public shared storage such as address book, media gallery, audio files, as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.
**Do not store temp/cached data in a world readable directory.
*1.8 Applications on managed devices should leverage remote wipe and kill switch APIs (OS-level or purpose-built) to remove sensitive information from the device in the event of theft or loss.
*1.9 Data deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).
*1.10 Bear in mind that there is no known secure deletion procedure for flash memory (unless wiping the entire media). Therefore data encryption is especially important.
*1.11 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
*1.12 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
*1.13 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (e.g. use a randomly generated number). Apply the same principles to app sessions as to http sessions/cookies etc....
*1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).

'''2. Handle password credentials securely on the device'''

'''Risks:''' Spyware, Surveillance, Financial malware, UI impersonation User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords.

*2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device. Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. The tokens could be time bounded to the specific service as well as revokable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire after an appropriate (not too long) delay.
*2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate encryption or hashing.
*2.3 Some devices allow developers to use a Secure Element (e.g. http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.html , http://code.google.com/p/seek-for-android/ //Check whether NFC only) - the number of devices offering this functionality is likely to increase. Developers should use such capability to store keys, credentials and other sensitive data.
*2.4 Provide the ability for the mobile user to change/remove passwords on the device.
*2.5 Password credentials should not be copied to backups.
*2.6 Consider using visual/pattern based passwords to aid usability.
*2.7 Check the entropy of all passwords.
*2.8 Ensure passwords and keys are not visible in cache or logs.
*2.9 SMS is not a secure channel and cannot be relied upon to send sensitive information.
*2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration to backend (like embedded password in code). Mobile application binaries can be easily downloaded and reverse engineered.

'''3. Ensure sensitive data is protected in transit'''

'''Risks:''' Network spoofing attacks, Surveillance. The majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network (3G, GSM, CDMA and others), bluetooth. Sensitive data passing through insecure channels could be intercepted.

*3.1 Assume that the network layer is not private. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the wifi network will be appropriately encrypted.
*3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. This includes passing user credentials, or other authentication equivalents. In some cases this may mean encrypting all communication.
*3.3 Enforce strong encryption algorithms and key lengths. Do not allow unsigned certificates and allow only reputable certificate authorities. Do not disable or ignore the SSL chain validation.
*3.4 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in the key chain.
*3.5 The user interface should make it as easy as possible for the user to find out if a certificate is valid.
*3.6 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end points.

'''Reference:''' Google vulnerability of Client Login account credentials on unprotected wifi - [http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''4. Implement user authentication/authorization and session management correctly'''

'''Risks:''' Unauthorized individuals may obtain access to sensitive data or systems. This can be done by circumventing authentication systems (logins) or by reusing valid tokens or cookies.

*4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the data being processed by the application and its access to valuable resources (e.g. costing money).
*4.2 It is important to ensure that the session management is done correctly after the initial authentication. Require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).
*4.3 Use unpredictable session identifiers with high entropy.
*4.4 Use context to add security to authentication - e.g. device ID, IP location, etc...
*4.5 Consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc...
*4.6 Use authentication that ties back to the end user identity (rather than the device identity).

'''Reference:''' Google's ClientLogin implementation
[http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''5. Keep the backend APIs (services) and the platform (server) secure'''

'''Risks:''' Attacks on backend systems, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

*5.1 Carry out a specific check of all data transferred betwen the mobile device and web-server backends and other external interfaces - (e.g. is location or other information transferred within file metadata)
*5.2 All back-end services (WebServices/REST) for mobile apps should be tested for vulnerabilities periodically e.g. using static code analyzer tools and fuzzing tools for testing and finding security flaws.
*5.3 Ensure that the back-end platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
*5.4 Ensure adequate logs are retained on the back-end in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
*5.6 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.
*5.7 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.
*5.8 Web Services, REST and APIs can have similar vulnerabilities to Web Applications. Perform testing of the backend Web Service, REST or API to determine vulnerabilities may exist. Perform abuse case testing, in addition to use case testing.

'''Reference:''' [https://www.owasp.org/index.php/Web_Services]
[http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Perform data integration with third party services/applications securely'''

'''Risks:''' Data Leakage

*6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (reliable source, supported, no backend Trojans, licensing)
*6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.
*6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing in the application. //Vinay: Give some specific examples (phishing, injection etc...)

'''7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data'''

'''Risks:''' Unintentional disclosure of personal or private information. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII).

*7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.
*7.2 Consent may be collected in 3 main ways:
**At install time
**At run-time when data is sent
**Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.
*7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent identifiers linked to central data stores containing personal information?
*7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).
*7.5 Keep a record of consent to the transfer of PII available to the user (consider also the value of keeping server-side records attached to any user data stored).
*7.6 Check whether your consent collection-mechanism overlaps or conflicts with any other consent-collection within the same stack (e.g. APP-native + webkit HTML)

'''Reference:''' EU Law [http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11_Spafford.pdf]

'''8. Implement controls to prevent unauthorised access to paid-for resources (wallet, SMS, phone calls etc...)'''
'''Risks:''' Smartphone apps give programmatic access to premium rate phone calls, SMS, roaming data, NFC payments etc. Apps with privileged access to such API’s should take particular care to prevent abuse given the financial impact of vulnerabilities giving attackers access to the user’s financial resources.

*8.1 Maintain logs of access to paid resources in a non-repudiable format and make them available to the end-user for monitoring (e.g. signed receipt sent to server back-end). Logs should be protected from unauthorised access.
*8.2 Check for anomalous usage patterns in paid resource usage and require reauthentication. E.g. when significant change in location occurs, user-language changes etc.
*8.3 Consider using a white-list model by default for paid resource addressing - e.g. address book only unless specifically authorised for phone calls.
*8.4 Authenticate all API calls to paid resources (e.g. using an app developer certificate).
*8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.
*8.6 Warn user and obtain consent for any cost implications for app behaviour.
*8.7 Implement best practices such as fast dormancy (3GPP), caching etc... to minimise signalling load on base stations.

'''Reference:''' Google Wallet Security [http://www.google.com/wallet/how-it-works-security.html]

'''9. Ensure Secure distribution/provisioning of mobile applications'''

'''Risks:'''
//Vinay - check and number. Interaction with the app-store.
*9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
*9.2 Provide remote kill functionality
*9.3 Feedback channels
*9.4 Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it).

'''10. Carefully check any runtime interpretation of code for errors '''

'''Risks:''' Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls. Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware

*10.1 Minimise runtime interpretation and capabilities offered to runtime interpreters.
*10.2 Run interpreters at minimal privilege levels.
*10.3 Fuzz test interpreters.
*10.4 Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data and use of third party API’s - e.g. javascript interpreters.
*10.5 Define a comprehensive escape syntax as appropriate.
//Giles look for an example.

=== Candidates (for consideration) ===

'''A: Some general coding best practices are particularly relevant to mobile coding too'''
*Input Validation and Output Encoding
*Minimise lines of code.
*Use safe languages (e.g. from buffer-overflow).
*Implement a security report handling point (address) security@example.com
*Use static and binary code analyzers to find security flaws.
*Use safe string functions, avoid buffer and Integer overflow.
*Run with the minimum privilege required for the application on the operating system. Be aware of privileges granted by default by API's and disable them.
*Don't authorize code/app to execute with root/sa privilege
*Always perform testing as a standard as well as a privileged user
*Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
*Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Vinay - Enterprise Apps (type of wifi, vpn, trusted)
*Remove all test code before releasing the application
*Ensure logging is done appropriately but do not record excessive logs, especially including sensitive user information.
*//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add

'''B. Enforce higher security posture on the device for sensitive apps used in an enterprise context:''' // Vinay to check
*If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Vinay - Still needs to be clarified
*Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
*Banking Apps
*//(Remote Management, PIN enforcement, encryption, application monitoring)
**Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it.

'''C. Protect your application from other malicious applications on the device'''

Risk: User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

*(?? What guidelines could be provided to developers)
U*ser education on using due diligence while installing third party applications on mobile devices

'''D. Provide or use an existing reporting channel for phishing from apps '''

(e.g. if you are a browser plugin developer). //APWG? Can we recommend one?

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-07-23T13:25:36Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks:''' Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on device.

*1.1 In the design phase classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs etc.). Process, store and use data according to its classification. Validate the security of methods applied to sensitive data.
*1.2 Store sensitive data on the server instead of client-end device. This is based on the assumption that secure network connectivity is always available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment or OWASP Cloud top 10 for decision support).
*1.3 If possible, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption API’s which use a private key protected by the device unlock code and deleted on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden for the end-user. It also makes stored data safer in the case of loss or theft.
*1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see 2).
*1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet App not usable outside Europe, car key not usable unless within 100m of car etc...).
*1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see 1.8).
*1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:
**Be aware of caches and temporary storage as a possible leakage channel when shared with other apps.
**Be aware of public shared storage such as address book, media gallery, audio files, as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.
**Do not store temp/cached data in a world readable directory.
*1.8 Applications on managed devices should leverage remote wipe and kill switch APIs (OS-level or purpose-built) to remove sensitive information from the device in the event of theft or loss.
*1.9 Data deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).
*1.10 Bear in mind that there is no known secure deletion procedure for flash memory (unless wiping the entire media). Therefore data encryption is especially important.
*1.11 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
*1.12 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
*1.13 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (e.g. use a randomly generated number). Apply the same principles to app sessions as to http sessions/cookies etc....
*1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).

'''2. Handle password credentials securely on the device'''

'''Risks:''' Spyware, Surveillance, Financial malware, UI impersonation User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords.

*2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device. Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. The tokens could be time bounded to the specific service as well as revokable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire after an appropriate (not too long) delay.
*2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate encryption or hashing.
*2.3 Some devices allow developers to use a Secure Element (e.g. http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.html , http://code.google.com/p/seek-for-android/ //Check whether NFC only) - the number of devices offering this functionality is likely to increase. Developers should use such capability to store keys, credentials and other sensitive data.
*2.4 Provide the ability for the mobile user to change/remove passwords on the device.
*2.5 Password credentials should not be copied to backups.
*2.6 Consider using visual/pattern based passwords to aid usability.
*2.7 Check the entropy of all passwords.
*2.8 Ensure passwords and keys are not visible in cache or logs.
*2.9 SMS is not a secure channel and cannot be relied upon to send sensitive information.
*2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration to backend (like embedded password in code). Mobile application binaries can be easily downloaded and reverse engineered.

'''3. Ensure sensitive data is protected in transit'''

'''Risks:''' Network spoofing attacks, Surveillance. The majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network (3G, GSM, CDMA and others), bluetooth. Sensitive data passing through insecure channels could be intercepted.

*3.1 Assume that the network layer is not private. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the wifi network will be appropriately encrypted.
*3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. This includes passing user credentials, or other authentication equivalents. In some cases this may mean encrypting all communication.
*3.3 Enforce strong encryption algorithms and key lengths. Do not allow unsigned certificates and allow only reputable certificate authorities. Do not disable or ignore the SSL chain validation.
*3.4 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in the key chain.
*3.5 The user interface should make it as easy as possible for the user to find out if a certificate is valid.
*3.6 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end points.

'''Reference:''' Google vulnerability of Client Login account credentials on unprotected wifi - [http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''4. Implement user authentication/authorization and session management correctly'''

'''Risks:''' Unauthorized individuals may obtain access to sensitive data or systems. This can be done by circumventing authentication systems (logins) or by reusing valid tokens or cookies.

*4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the data being processed by the application and its access to valuable resources (e.g. costing money).
*4.2 It is important to ensure that the session management is done correctly after the initial authentication. Require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).
*4.3 Use unpredictable session identifiers with high entropy.
*4.4 Use context to add security to authentication - e.g. device ID, IP location, etc...
*4.5 Consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc...
*4.6 Use authentication that ties back to the end user identity (rather than the device identity).

'''Reference:''' Google's ClientLogin implementation
[http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''5. Keep the backend APIs (services) and the platform (server) secure'''

'''Risks:''' Attacks on backend systems, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

*5.1 Carry out a specific check of all data transferred betwen the mobile device and web-server backends and other external interfaces - (e.g. is location or other information transferred within file metadata)
*5.2 All back-end services (WebServices/REST) for mobile apps should be tested for vulnerabilities periodically e.g. using static code analyzer tools and fuzzing tools for testing and finding security flaws.
*5.3 Ensure that the back-end platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
*5.4 Ensure adequate logs are retained on the back-end in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
*5.6 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.
*5.7 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.
*5.8 Web Services, REST and APIs can have similar vulnerabilities to Web Applications. Perform testing of the backend Web Service, REST or API to determine vulnerabilities may exist. Perform abuse case testing, in addition to use case testing.

'''Reference:''' [https://www.owasp.org/index.php/Web_Services]
[http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Perform data integration with third party services/applications securely'''

'''Risks:''' Data Leakage

*6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (reliable source, supported, no backend Trojans, licensing)
*6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.
*6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing in the application. //Vinay: Give some specific examples (phishing, injection etc...)

'''7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data'''

'''Risks:''' Unintentional disclosure of personal or private information. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII).

*7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.
*7.2 Consent may be collected in 3 main ways:
**At install time
**At run-time when data is sent
**Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.
*7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent identifiers linked to central data stores containing personal information?
*7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).
*7.5 Keep a record of consent to the transfer of PII available to the user (consider also the value of keeping server-side records attached to any user data stored).
*7.6 Check whether your consent collection-mechanism overlaps or conflicts with any other consent-collection within the same stack (e.g. APP-native + webkit HTML)

'''Reference:''' EU Law [http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11_Spafford.pdf]

'''8. Implement controls to prevent unauthorised access to paid-for resources (wallet, SMS, phone calls etc...)'''
'''Risks:''' Smartphone apps give programmatic access to premium rate phone calls, SMS, roaming data, NFC payments etc. Apps with privileged access to such API’s should take particular care to prevent abuse given the financial impact of vulnerabilities giving attackers access to the user’s financial resources.

*8.1 Maintain logs of access to paid resources in a non-repudiable format and make them available to the end-user for monitoring (e.g. signed receipt sent to server back-end). Logs should be protected from unauthorised access.
*8.2 Check for anomalous usage patterns in paid resource usage and require reauthentication. E.g. when significant change in location occurs, user-language changes etc.
*8.3 Consider using a white-list model by default for paid resource addressing - e.g. address book only unless specifically authorised for phone calls.
*8.4 Authenticate all API calls to paid resources (e.g. using an app developer certificate).
*8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.
*8.6 Warn user and obtain consent for any cost implications for app behaviour.
*8.7 Implement best practices such as fast dormancy (3GPP), caching etc... to minimise signalling load on base stations.

'''Reference:''' Google Wallet Security [http://www.google.com/wallet/how-it-works-security.html]

'''9. Ensure Secure distribution/provisioning of mobile applications'''

'''Risks:'''
//Vinay - check and number. Interaction with the app-store.
*9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
*9.2 Provide remote kill functionality
*9.3 Feedback channels
*9.4 Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it).

'''10. Carefully check any runtime interpretation of code for errors '''

'''Risks:''' Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls. Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware

*10.1 Minimise runtime interpretation and capabilities offered to runtime interpreters.
*10.2 Run interpreters at minimal privilege levels.
*10.3 Fuzz test interpreters.
*10.4 Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data and use of third party API’s - e.g. javascript interpreters.
*10.5 Define a comprehensive escape syntax as appropriate.
//Giles look for an example.

=== Candidates (for consideration) ===

'''A: Some general coding best practices are particularly relevant to mobile coding too'''
*Input Validation and Output Encoding
*Minimise lines of code.
*Use safe languages (e.g. from buffer-overflow).
*Implement a security report handling point (address) security@example.com
*Use static and binary code analyzers to find security flaws.
*Use safe string functions, avoid buffer and Integer overflow.
*Run with the minimum privilege required for the application on the operating system. Be aware of privileges granted by default by API's and disable them.
*Don't authorize code/app to execute with root/sa privilege
*Always perform testing as a standard as well as a privileged user
*Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
*Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Vinay - Enterprise Apps (type of wifi, vpn, trusted)
*Remove all test code before releasing the application
*Ensure logging is done appropriately but do not record excessive logs, especially including sensitive user information.
*//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add

'''B. Enforce higher security posture on the device for sensitive apps used in an enterprise context:''' // Vinay to check
*If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Vinay - Still needs to be clarified
*Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
*Banking Apps
*//(Remote Management, PIN enforcement, encryption, application monitoring)
**Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it.

'''C. Protect your application from other malicious applications on the device'''

Risk: User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

*(?? What guidelines could be provided to developers)
U*ser education on using due diligence while installing third party applications on mobile devices

'''D. Provide or use an existing reporting channel for phishing from apps '''

(e.g. if you are a browser plugin developer). //APWG? Can we recommend one?

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-07-23T13:22:01Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks:''' Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on device.

*1.1 In the design phase classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, personal data, location, error logs etc.). Process, store and use data according to its classification. Validate the security of methods applied to sensitive data.
*1.2 Store sensitive data on the server instead of client-end device. This is based on the assumption that secure network connectivity is always available and that protection mechanisms available to server side storage are superior. The relative security of client vs server-side security also needs to be assessed on a case-by-case basis (see ENISA cloud risk assessment or OWASP Cloud top 10 for decision support).
*1.3 If possible, use a file encryption API provided by the OS or other trusted source. Some platforms provide file encryption API’s which use a private key protected by the device unlock code and deleted on remote kill. If this is available, it should be used as it increases the security of the encryption without creating extra burden for the end-user. It also makes stored data safer in the case of loss or theft.
*1.4 Do not store/cache sensitive data (including keys) unless they are encrypted and if possible stored in a tamper-proof area (see 2).
*1.5 Consider restricting access to sensitive data based on contextual information such as location (e.g. wallet App not usable outside Europe, car key not usable unless within 100m of car etc...).
*1.6 Do not store historical GPS/tracking or other sensitive information on the device beyond the period required by the application (see 1.8).
*1.7 Assume that shared storage is untrusted - information may easily leak in unexpected ways through any shared storage. In particular:
**Be aware of caches and temporary storage as a possible leakage channel when shared with other apps.
**Be aware of public shared storage such as address book, media gallery, audio files, as a possible leakage channel. For example storing images with location metadata in the media-gallery allows that information to be shared in unintended ways.
**Do not store temp/cached data in a world readable directory.
*1.8 Applications on managed devices should leverage remote wipe and kill switch APIs (OS-level or purpose-built) to remove sensitive information from the device in the event of theft or loss.
*1.9 Data deletion should be scheduled according to a maximum retention period, (to prevent e.g. data remaining in caches indefinitely).
*1.10 Bear in mind that there is no known secure deletion procedure for flash memory (unless wiping the entire media). Therefore data encryption is especially important.
*1.11 Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
*1.12 Apply the principle of minimal disclosure - only collect and disclose data which is required for business use of the application. Identify in the design phase what data is needed, its sensitivity and whether it is appropriate to collect, store and use each data type.
*1.13 Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so (e.g. use a randomly generated number). Apply the same principles to app sessions as to http sessions/cookies etc....
*1.14 Application developers may want to incorporate an application-specific "data kill switch" into their products, to allow the per-app deletion of their application's sensitive data when needed (strong authentication is required to protect misuse of such a feature).

'''2. Handle password credentials securely on the device'''

'''Risks:''' Spyware, Surveillance, Financial malware, UI impersonation User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords.

*2.1 Instead of passwords consider using longer term authorization tokens that can be securely stored on the device. Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. The tokens could be time bounded to the specific service as well as revokable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire after an appropriate (not too long) delay.
*2.2 In case passwords need to be stored on the device, leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords, password equivalents and authorization tokens. Never store passwords in clear text. Do not store passwords or long term session IDs without appropriate encryption or hashing.
*2.3 Some devices allow developers to use a Secure Element (e.g. http://www.blackberry.com/developers/docs/7.0.0api/net/rim/device/api/io/nfc/se/SecureElement.html , http://code.google.com/p/seek-for-android/ //Check whether NFC only) - the number of devices offering this functionality is likely to increase. Developers should use such capability to store keys, credentials and other sensitive data.
*2.4 Provide the ability for the mobile user to change/remove passwords on the device.
*2.5 Password credentials should not be copied to backups.
*2.6 Consider using visual/pattern based passwords to aid usability.
*2.7 Check the entropy of all passwords.
*2.8 Ensure passwords and keys are not visible in cache or logs.
*2.9 SMS is not a secure channel and cannot be relied upon to send sensitive information.
*2.10 Do not store any passwords or secrets in the application binary. Do not use a generic shared secret for integration to backend (like embedded password in code). Mobile application binaries can be easily downloaded and reverse engineered.

'''3. Ensure sensitive data is protected in transit'''

'''Risks:''' Network spoofing attacks, Surveillance. The majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network (3G, GSM, CDMA and others), bluetooth. Sensitive data passing through insecure channels could be intercepted.

*3.1 Assume that the network layer is not private. Modern network layer attacks can decrypt provider network encryption, and there is no guarantee that the wifi network will be appropriately encrypted.
*3.2 Applications should enforce the use of an end-to-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. This includes passing user credentials, or other authentication equivalents. In some cases this may mean encrypting all communication.
*3.3 Enforce strong encryption algorithms and key lengths. Do not allow unsigned certificates and allow only reputable certificate authorities. Do not disable or ignore the SSL chain validation.
*3.4 For sensitive data, to reduce the risk of man-in-middle attacks (like SSL proxy, SSL strip), a secure connection should only be established after verifying the identity of the remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in the key chain.
*3.5 The user interface should make it as easy as possible for the user to find out if a certificate is valid.
*3.6 SMS, MMS or notifications should not be used to send sensitive data to or from mobile end points.

'''Reference:''' Google vulnerability of Client Login account credentials on unprotected wifi - [http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''4. Implement user authentication/authorization and session management correctly'''

'''Risks:''' Unauthorized individuals may obtain access to sensitive data or systems. This can be done by circumventing authentication systems (logins) or by reusing valid tokens or cookies.

*4.1 Require appropriate strength user authentication to the application. It may be useful to provide feedback on the strength of the password when it is being entered for the first time. The strength of the authentication mechanism used depends on the data being processed by the application and its access to valuable resources (e.g. costing money).
*4.2 It is important to ensure that the session management is done correctly after the initial authentication. Require authentication credentials or tokens to be passed with any subsequent request (especially those granting privileged access or modification).
*4.3 Use unpredictable session identifiers with high entropy.
*4.4 Use context to add security to authentication - e.g. device ID, IP location, etc...
*4.5 Consider using additional authentication factors for applications giving access to sensitive data or interfaces where possible - e.g. voice, fingerprint (if available), who-you-know, behavioural etc...
*4.6 Use authentication that ties back to the end user identity (rather than the device identity).

'''Reference:''' Google's ClientLogin implementation
[http://www.google.com/url?q=http%3A%2F%2Fwww.uni-ulm.de%2Fin%2Fmi%2Fmitarbeiter%2Fkoenings%2Fcatching-authtokens.html&sa=D&sntz=1&usg=AFQjCNGO-Yp1KHqO8USuL0zxL1Lpwq1Usw]

'''5. Keep the backend APIs (services) and the platform (server) secure'''

'''Risks:''' Attacks on backend systems, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

*5.1 Carry out a specific check of all data transferred betwen the mobile device and web-server backends and other external interfaces - (e.g. is location or other information transferred within file metadata)
*5.2 All back-end services (WebServices/REST) for mobile apps should be tested for vulnerabilities periodically e.g. using static code analyzer tools and fuzzing tools for testing and finding security flaws.
*5.3 Ensure that the back-end platform (server) is running with a hardened configuration with the latest security patches applied to the OS, Web Server and other application components.
*5.4 Ensure adequate logs are retained on the back-end in order to detect and respond to incidents and perform forensics (within the limits of data protection law).
*5.6 Employ rate limiting and throttling on a per-user/IP basis (if user identification is available) to reduce the risk from DDoS attack.
*5.7 Test for DoS vulnerabilities where the server may become overwhelmed by certain resource intensive application calls.
*5.8 Web Services, REST and APIs can have similar vulnerabilities to Web Applications. Perform testing of the backend Web Service, REST or API to determine vulnerabilities may exist. Perform abuse case testing, in addition to use case testing.

'''Reference:''' [https://www.owasp.org/index.php/Web_Services]
[http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Perform data integration with third party services/applications securely'''

'''Risks:''' Data Leakage

*6.1 Vet the security/authenticity of any third party code/libraries used in your mobile application (reliable source, supported, no backend Trojans, licensing)
*6.2 Track all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile applications using these third party APIs/frameworks.
*6.3 Pay particular attention to validating all data received from and sent to non-trusted third party apps (e.g. ad network software) before processing in the application. //Vinay: Give some specific examples (phishing, injection etc...)

'''7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data'''

'''Risks:''' Unintentional disclosure of personal or private information. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII).

*7.1 Create a privacy policy covering the usage of personal data and make it available to the user especially when making consent choices.
*7.2 Consent may be collected in 3 main ways:
**At install time
**At run-time when data is sent
**Via “opt-out” mechanisms where a default setting is implemented and the user has to turn it off.
*7.3 Check whether your application is collecting PII - it may not always be obvious - for example do you use persistent identifiers linked to central data stores containing personal information?
*7.4 Audit communication mechanisms to check for unintended leaks (e.g. image metadata).
*7.5 Keep a record of consent to the transfer of PII available to the user (consider also the value of keeping server-side records attached to any user data stored).
*7.6 Check whether your consent collection-mechanism overlaps or conflicts with any other consent-collection within the same stack (e.g. APP-native + webkit HTML)

'''Reference:''' EU Law [http://democrats.energycommerce.house.gov/sites/default/files/image_uploads/Testimony_05.04.11_Spafford.pdf]

'''8. Implement controls to prevent unauthorised access to paid-for resources (wallet, SMS, phone calls etc...)'''
'''Risks:''' Smartphone apps give programmatic access to premium rate phone calls, SMS, roaming data, NFC payments etc. Apps with privileged access to such API’s should take particular care to prevent abuse given the financial impact of vulnerabilities giving attackers access to the user’s financial resources.

*8.1 Maintain logs of access to paid resources in a non-repudiable format and make them available to the end-user for monitoring (e.g. signed receipt sent to server back-end). Logs should be protected from unauthorised access.
*8.2 Check for anomalous usage patterns in paid resource usage and require reauthentication. E.g. when significant change in location occurs, user-language changes etc.
*8.3 Consider using a white-list model by default for paid resource addressing - e.g. address book only unless specifically authorised for phone calls.
*8.4 Authenticate all API calls to paid resources (e.g. using an app developer certificate).
*8.5 Ensure that wallet API callbacks do not pass cleartext account/pricing/ billing/item information.
*8.6 Warn user and obtain consent for any cost implications for app behaviour.
*8.7 Implement best practices such as fast dormancy (3GPP), caching etc... to minimise signalling load on base stations.

'''Reference:''' Google Wallet Security [http://www.google.com/wallet/how-it-works-security.html]

'''9. Ensure Secure distribution/provisioning of mobile applications'''

'''Risks:'''
//Vinay - check and number. Interaction with the app-store.
*9.1 Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
*9.2 Provide remote kill functionality
*9.3 Feedback channels
*9.4 Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it).

'''10. Carefully check any runtime interpretation of code for errors '''

'''Risks:''' Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls. Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware

*10.1 Minimise runtime interpretation and capabilities offered to runtime interpreters.
*10.2 Run interpreters at minimal privilege levels.
*10.3 Fuzz test interpreters.
*10.4 Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data and use of third party API’s - e.g. javascript interpreters.
*10.5 Define a comprehensive escape syntax as appropriate.
//Giles look for an example.

=== Candidates (for consideration) ===

A: Some general coding best practices are particularly relevant to mobile coding too
Input Validation and Output Encoding
Minimise lines of code.
Use safe languages (e.g. from buffer-overflow).
Implement a security report handling point (address) security@example.com
Use static and binary code analyzers to find security flaws.
Use safe string functions, avoid buffer and Integer overflow.
Run with the minimum privilege required for the application on the operating system. Be aware of privileges granted by default by API's and disable them.
Don't authorize code/app to execute with root/sa privilege
Always perform testing as a standard as well as a privileged user
Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Vinay - Enterprise Apps (type of wifi, vpn, trusted)
Remove all test code before releasing the application
Ensure logging is done appropriately but do not record excessive logs, especially including sensitive user information.

//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add

B. Enforce higher security posture on the device for sensitive apps used in an enterprise context: // Vinay to check
If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Vinay - Still needs to be clarified
Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
Banking Apps
//(Remote Management, PIN enforcement, encryption, application monitoring)
Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it.

C. Protect your application from other malicious applications on the device

Risk: User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

(?? What guidelines could be provided to developers)
User education on using due diligence while installing third party applications on mobile devices

D. Provide or use an existing reporting channel for phishing from apps

(e.g. if you are a browser plugin developer). //APWG? Can we recommend one?

Projects/OWASP Mobile Security Project

2011-07-16T11:24:51Z

Vinaykbansal:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Project About</noinclude>
| project_name = OWASP Mobile Security Project
| project_home_page = OWASP_Mobile_Security_Project
| project_description =
The rapid growth of mobile computing has made the need for secure mobile development absolutely essential. The OWASP Mobile Security Project will help the community better understand the risks present in mobile applications, and learn to defend against them. This project will be forked into each of the following platforms:
* iOS Project
* Android Project
* webOS Project
* Windows Mobile Project
* Blackberry Project

| project_license =

| leader_name1 = Jack Mannino
| leader_email1 = Jack@nvisiumsecurity.com
| leader_username1 = Jack Mannino

| leader_name2 = Mike Zusman
| leader_email2 = mike.zusman@owasp.org
| leader_username2 = schmoilito

| leader_name3 = Zach Lanier
| leader_email3 = zach.lanier@n0where.org
| leader_username3 = Zach_Lanier

| leader_name4 = Giles Hogben
| leader_email4 = giles.hogben@enisa.europa.eu
| leader_username4 = Giles Hogben

| leader_name5 = Vinay Bansal
|leader_email5 = vinay.bansal@cisco.com
| leader_username5 = Vinaykbansal

| contributor_name2 = Jim Manico
| contributor_email2 = jim.manico@owasp.org
| contributor_username2= jmanico

| contributor_name1 = David Lindner
| contributor_email1 = david.lindner@aspectsecurity.com
| contributor_username1 = David Lindner

| contributor_name3 = Tom Neaves
| contributor_email3 = tom.neaves@verizonbusiness.com
| contributor_username3 = Tom Neaves

| contributor_name4 = Kuai Hinojosa
| contributor_email4 = Kuai.Hinojosa@owasp.org
| contributor_username4 = Webappsecguy

| contributor_name6 = Zach Lanier
| contributor_email6 = zach.lanier@intrepidusgroup.com
| contributor_username6 = Zach_Lanier

| contributor_name7 = Ludovic Petit
| contributor_email7 = ludovic.petit@owasp.org
| contributor_username7 = Ludovic Petit

| contributor_name8 = Zaki Akhmad
| contributor_email8 = za@owasp.org
| contributor_username8 = Zakiakhmad

| pamphlet_link =

| presentation_link =

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-mobile-security-project

| project_road_map = http://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project/Roadmap

| links_url[1-10] =

| links_name[1-10] =

| release_1 =
| release_2 =
| release_3 =
| release_4 =

| project_about_page = Projects/OWASP Mobile Security Project

}}

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-06-01T12:56:28Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware (e.g. SIM card) to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on removable media unless they are tamper-proof and password protected.
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory) //define protected
** Automatically delete data which is no longer required from device
** Be aware of caches and temporary storage as a possible leakage channel
** Be aware of shared data storage (e.g. address book, media gallery) as a possible leakage channel.
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis (to prevent e.g. data remaining in caches indefinitely)
** Use secure deletion procedures e.g. conforming to NIST 800-88 .
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Carry out a specific check of all communication with web-server backends and other interfaces with trust boundaries - (e.g. is location or other information transferred within file metadata)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //todo research mor and hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to be stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Access to highly sensitive data (e.g. access to wallet) should be protected by a PIN.
**Consider using visual/pattern based passwords to aid usability.
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes or any kind of password (OTP) should not be forwarded via SMS where (as on most smartphones) an alternative, more secure channel is available. Consider using HTTPS with client authentication (see 3.) to prevent Zeus-in-the-mobile style attacks.

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain.
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points.
** For one-time-password values, rather than SMS, consider using https with client authentication (i.e. OTP is sent to smartphone over https and smartphone is authenticated to prevent interception).
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''
//Downgrade this control
'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''
'''Risks''':
**Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.
**User authentication must be based on user's credentials. //??
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as a session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains). //This sentence not clear
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour. // and other consent best practices.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''
//Downgrade and mix with #4
**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
** Understand and test your patching process and its the interaction with the app-store - what is a typical time-frame are any updates possible (e.g. config files) without the approval of the app-store?
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. Link to 1. audit communication mechanisms to check for unintended leaks (e.g. image metadata). // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''8. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root/sa privilege
**Always perform testing as a standard user along with the privileged user
**Least privilege. Be aware of privileges granted by default by API's and disable them.
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.

'''9. Enforce higher security posture on the device for sensitive apps'''
//Reword May need to go in a separate enterprise security management point
**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Still needs to be clarified
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
** Banking Apps
//(Remote Management, PIN enforcement, encryption, application monitoring)
** Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it...

'''10. Carefully check any runtime interpretation of code for errors'''
Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls.
Risks: Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware
//Please check and add advice here.
** Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data.
** Run interpreters at minimal privilege levels
** Fuzz test interpreters
** Define comprehensive and complete escape syntax (not sure if this is theortically possible).
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook... (Angry bird attack)

'''11. Employ the secure coding/development practices'''
// Let's try to get rid of it and move the recommendation
//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)

**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it)
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific? (generic but important)
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Enterprise Apps (type of wifi, vpn, trused)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files -
//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-06-01T12:31:15Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware (e.g. SIM card) to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on removable media unless they are tamper-proof and password protected.
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory) //define protected
** Automatically delete data which is no longer required from device
** Be aware of caches and temporary storage as a possible leakage channel
** Be aware of shared data storage (e.g. address book, media gallery) as a possible leakage channel.
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis (to prevent e.g. data remaining in caches indefinitely)
** Use secure deletion procedures e.g. conforming to NIST 800-88 .
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Carry out a specific check of all communication with web-server backends and other interfaces with trust boundaries - (e.g. is location or other information transferred within file metadata)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //todo research mor and hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to be stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
** Access to highly sensitive data (e.g. access to wallet) should be protected by a PIN.
** Consider using visual/pattern based passwords to aid usability.
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes or any kind of password (OTP) should not be forwarded via SMS where (as on most smartphones) an alternative, more secure channel is available. Consider using HTTPS with client authentication (see 3.) to prevent Zeus-in-the-mobile style attacks.

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain.
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points.
** For one-time-password values, rather than SMS, consider using https with client authentication (i.e. OTP is sent to smartphone over https and smartphone is authenticated to prevent interception).
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''
//Downgrade this control
'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials. //??
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as a session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains). //This sentence not clear
** Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it...
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour. // and other consent best practices.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''
//Downgrade and mix with #4
**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
** Understand and test your patching process and its the interaction with the app-store - what is a typical time-frame are any updates possible (e.g. config files) without the approval of the app-store?
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. Link to 1. audit communication mechanisms to check for unintended leaks (e.g. image metadata). // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''8. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root/sa privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.

'''9. Enforce higher security posture on the device for sensitive apps'''
//Reword May need to go in a separate enterprise security management point
**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Still needs to be clarified
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive applications
** Banking Apps
//(Remote Management, PIN enforcement, encryption, application monitoring)

'''10. Carefully check any runtime interpretation of code for errors'''
Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls.
Risks: Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware
//Please check and add advice here.
** Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data.
** Run interpreters at minimal privilege levels
** Fuzz test interpreters
** Define comprehensive and complete escape syntax (not sure if this is theortically possible).
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook... (Angry bird attack)

'''11. Employ the secure coding/development practices'''
// Let's try to get rid of it and move the recommendation
//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)

**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it)
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific? (generic but important)
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Enterprise Apps (type of wifi, vpn, trused)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files -
//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-06-01T12:23:36Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware (e.g. SIM card) to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on removable media unless they are tamper-proof and password protected.
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory) //define protected
** Automatically delete data which is no longer required from device
** Be aware of caches and temporary storage as a possible leakage channel
** Be aware of shared data storage (e.g. address book, media gallery) as a possible leakage channel.
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis (to prevent e.g. data remaining in caches indefinitely)
** Use secure deletion procedures e.g. conforming to NIST 800-88 .
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Carry out a specific check of all communication with web-server backends and other interfaces with trust boundaries - (e.g. is location or other information transferred within file metadata)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //todo research mor and hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to be stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
** Access to highly sensitive data (e.g. access to wallet) should be protected by a PIN.
** Consider using visual/pattern based passwords to aid usability.
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes or any kind of password (OTP) should not be forwarded via SMS where (as on most smartphones) an alternative, more secure channel is available. Consider using HTTPS with client authentication (see 3.) to prevent Zeus-in-the-mobile style attacks.

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain.
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points.
** For one-time-password values, rather than SMS, consider using https with client authentication (i.e. OTP is sent to smartphone over https and smartphone is authenticated to prevent interception).
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''
//Downgrade this control
'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials. //??
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as a session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains). //This sentence not clear
** Device cert can be used for stronger device identity. // How to make sure that this does not provide linkability between transactions (i.e. using the same cert across different service providers leaks data). I guess zero-knowledge certificates are too far-out for this guidance? Is this a common feature - device-cert - I have not come across it...
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour. // and other consent best practices.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''
//Downgrade and mix with #4
**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores and the extra delay this may imply.
** Understand and test your patching process and its the interaction with the app-store - what is a typical time-frame are any updates possible (e.g. config files) without the approval of the app-store?
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. Link to 1. audit communication mechanisms to check for unintended leaks (e.g. image metadata). // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''8. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root/sa privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.

'''9. Enforce higher security posture on the device for sensitive apps'''
//Reword
**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // Still needs to be clarified
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

'''10. Carefully check any runtime interpretation of code for errors'''
Runtime interpretation of code covers any opportunity an app gives for untrusted parties to provide unverified text or binary which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls.
Risks: Injection attacks leading to Data leakage, Surveillance, Spyware, Diallerware
//Please check and add advice here.
** Note that it is not always obvious that your code is interpreting text. Look for any capabilities accessible via user-input data.
** Run interpreters at minimal privilege levels
** Fuzz test interpreters
** Define comprehensive and complete escape syntax (not sure if this is theortically possible).

'''11. Employ the secure coding/development practices'''
// Let's try to get rid of it and move the recommendation
//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)

**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration. (Vinay will expand it)
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific? (generic but important)
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network) - //Enterprise Apps (type of wifi, vpn, trused)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files -
//What sort of information should be recorded in the logs. (Keep audit data on the server, no user specific data - link to the Apple Issue - Signed Timestamps) //Vinay to add
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-25T13:06:07Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on the removable media
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis.
** Use secure deletion procedures.
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Consider using SIM card as default storage for small but sensitive data such as keys. //To be researched more
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes (OTP) should not be forwarded via SMS. Consider using HTTPS and protect it on the device (Zitmo)... //or can we make a better rec on this?

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''
//Downgrade this control
'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''
//Downgrade and mix with #4
**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''
// Let's try to get rid of it and move the recommendation
//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
//(Add least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

'''8. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''9. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''
//Reword
**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters - some guidelines on these?

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-25T12:56:57Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on the removable media
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis.
** Use secure deletion procedures.
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Consider using SIM card as default storage for small but sensitive data such as keys. //To be researched more
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes (OTP) should not be forwarded via SMS. Consider using HTTPS and protect it on the device (Zitmo)... //or can we make a better rec on this?

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''
//Downgrade this control
'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''
//Downgrade and mix with #4
**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''
// Let's try to get rid of it and move the recommendation
//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
//(Add least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

'''8. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''9. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters - some guidelines on these?

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-25T12:48:38Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on the removable media
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis.
** Use secure deletion procedures.
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Consider using SIM card as default storage for small but sensitive data such as keys. //To be researched more
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes (OTP) should not be forwarded via SMS. Consider using HTTPS and protect it on the device (Zitmo)... //or can we make a better rec on this?

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''
//Downgrade this control
'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''

**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''

//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
//(Add least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

'''8. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''9. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters - some guidelines on these?

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-25T12:45:12Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on the removable media
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis.
** Use secure deletion procedures.
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Consider using SIM card as default storage for small but sensitive data such as keys. //To be researched more
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes (OTP) should not be forwarded via SMS. Consider using HTTPS and protect it on the device (Zitmo)... //or can we make a better rec on this?

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should enforce the use of the end-end secure channel (such as SSL/TLS) when sending sensitive information on wire/air. (Do not assume transport encryption)
**For sensitive data, to reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''

'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''

**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''

//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
//(Add least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

'''8. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''9. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters - some guidelines on these?

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-25T12:35:33Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on the removable media
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis.
** Use secure deletion procedures.
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Consider using SIM card as default storage for small but sensitive data such as keys. //To be researched more
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes (OTP) should not be forwarded via SMS. Consider using HTTPS and protect it on the device (Zitmo)... //or can we make a better rec on this?

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should ensure that a secure channel (such as SSL/TLS) is established end-end when sending sensitive information on wire/air. (Do not assume transport encryption)
**To reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''

'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''

**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''

//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
//(Add least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

'''8. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''9. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters - some guidelines on these?

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-25T12:32:59Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risks''': Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure:
Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
** Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
** Do not store/cache sensitive data on the removable media
** Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
** Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
** Schedule deletion according to time, rather than on a push-pop basis.
** Use secure deletion procedures.
** Be careful when sharing cache data with other applications (check for covert channels leaking sensitive data)
** Consider the security of the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Where possible classify data storage according to sensitivity and apply controls accordingly (e.g. passwords, contact data, location vs error logs).
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers which are not shared with other apps wherever possible - e.g. do not use the device ID number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Consider using SIM card as default storage for small but sensitive data such as keys. //To be researched more
** For cryptographic keys, implement key management best practice including exploiting SIM card capabilities where possible //hook to best practice.

'''2. Handle password credentials securely on the device'''

'''Risks''': Spyware, Surveillance, Financial malware, UI impersonation
User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorization tokens that can be securely stored on the device . Encrypt the tokens while stored on the device and in transit. Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios. Consider using the latest versions of the authorization standards (such as OAuth 2.0).
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device (renew tokens)
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs
**We recommend that one-time codes (OTP) should not be forwarded via SMS (Zitmo)... //or can we make a better rec on this?

'''3. Ensure sensitive data is protected in transit'''

'''Risks''': Network spoofing attacks, Surveillance
Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should ensure that a secure channel (such as SSL/TLS) is established end-end when sending sensitive information on wire/air. (Do not assume transport encryption)
**To reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
** Do not disable or ignore the SSL chain validation.
** SMS, MMS or notifications should not be used to send sensitive data to mobile end points // What about banking OTP's?
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths (e.g. accept invalid certificates).
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''

'''Risks''': Attacks on back-ends through mobile device, loss of data via cloud storage. Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risks''':
Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof and potentially leaks private information when linked to other data. (Device Id could in some cases be used as an additional check that the request is originating from the known device) // Giles:I would NOT make the last recommendation because Device ID can be used for cross-site tracking since it is shared between apps.
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
** Implement best practices for dormancy (3GPP), caching etc... to minimise signalling load on base stations.
** Warn user and obtain consent for any cost implications for app behaviour.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''

**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''

//Risk? Isn't this circular? I don't understand the principle here.

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
//(Add least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code). //Hook...

'''8. Perform data integration with third party backend applications correctly'''
Risks: Unintended disclosure
** User informed if any personal data is collected or sent //This needs to be detailed - how to inform - one-time, on install, depending on the type of data etc...?
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user. // ditto
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?
** Do not send data which is not required for the functioning of the application unless you have obtained the explicit consent of the user.

'''9. Run the mobile client using minimal permission'''
Risks: Data leakage, Surveillance, Spyware, Diallerware

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

** Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters - some guidelines on these?

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-17T18:17:26Z

Vinaykbansal: /* Top 10 mobile controls and design principles */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risk''': Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
**Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
**Do not store/cache sensitive data on the removable media
**Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
**Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device
**Schedule deletion according to time, rather than on a push-pop basis.

'''2. Handle password credentials securely on the device'''

'''Risk''': User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term authorisation tokens that can be securely stored on the device (OAuth). Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios.
**In case passwords need to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanisms to the mobile user to change/remove passwords on the device
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords and keys are not visible in cache or logs

'''3. Ensure sensitive data is protected in transit'''

'''Risk''': Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should ensure that a secure channel (such as SSL/TLS) is established end-end when sending sensitive information on wire/air. (Do not assume transport encryption)
**To reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain. //This carries a high usability cost as advice...
**Do not disable or ignore the SSL chain validation.
**SMS, MMS or notifications should not be used to send sensitive data to mobile end points
** Consider use of GSM encryption-on flags to verify that GSM encryption is on.

'''Reference''': Google vulnerability of Client Login account credentials on unprotected wifi [http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html]

'''4. Keep the back-end API and mobile platform secure'''

'''Risk''': Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risk''': Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof. (Device Id could be used as an additional check or stronger validation that the request is originating from the known device)
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity
//Cover also excessive resource use.

'''Reference''': Google's ClientLogin implementation [http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html]

'''6. Ensure strong vulnerability and patch management in place'''

**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches, taking into account the requirements for approval by app-stores.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''

//Risk? Isn't this circular?

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS. //(least privilege)
**Code signing for some mobile platforms implies inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly. //Needs elaboration.
**Leverage static and binary code analyzers to find security flaws.
**Use safe string function, avoid buffer and Integer overflow //Is this mobile specific?
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files
//What sort of information should be recorded in the logs.

'''8. Perform data integration with third party backend applications correctly'''

** User informed if any personal data is collected or sent
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user.
**Validate all data received from the non-trusted third party before processing in the application. //What should be validated. Is this mobile-speciifc?

'''9. Run the mobile client using minimal permission'''

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe) // I don't follow this point.
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

**Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

//What about runtime interpreters

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Architecture and design principles

2011-05-17T09:54:44Z

Vinaykbansal: /* Mobile Security */

The following is a merge of ENISA, OWASP and Veracode top 10. Note that there is a mixture of threats and vulnerabilities here - we should decide whether to use risks (threats with impact on assets which occur with probability) and vulnerabilities (system flaws which increase the probability of a threat occurring). I have cut those risks/vulnerabilities which cannot be addressed in any way by developers. We should decide whether to include recommendations in the style of "code of practice"- e.g. activity monitoring should only be used in circumstances xyz... (feel free to restructure)

My recommendation would be to separate out the design principles from the Risks/Vulnerabilities.

=='''Mobile Security'''==
*1. Threats, Risks and Vulnerabilities (Risks)
*2. Design Principles (As part of the Controls) - Added here [https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Controls#Top_10_mobile_controls_and_design_principles]
*3. Architectural Patterns (New)
*4. Secure Mobile Development/Coding Guidelines

==1. Top Risks/Vulnerabilities==

* Unsafe sensitive data storage
** Consider the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Automatically delete data which is not required (how to know when it's not required?).
** Securely delete data using standard shredding techniques.
** Store a minimum of data on the client side device.
** Securely wipe removable media.
** Be aware of caches and temporary storage as a possible leakage channel.
** Implement key and password storage best practice.
** In the design phase analyse what data needs to be protected most and what doesn't and apply controls at appropriate places.

* Unintentional disclosure of data: The smartphone user unintentionally discloses data on the smartphone.
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers wherever possible - e.g. do not use the EMEI number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Obtain user explicit user consent according to best practice (see implementation guidelines) for collection of personal data.

* Attacks on decommissioned smartphones: The smartphone is decommissioned improperly allowing an attacker access to the data on the device.
** See first risk
** Provide a convenient way of resetting access credentials which does not require the device (consider an automated timeout on access credentials).
** Consider using SIM card as default storage for small but sensitive data such as keys.

* Phishing attacks: An attacker collects user credentials (such as passwords and credit card numbers) by means of fake apps or (SMS, email) messages that seem genuine.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths.
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

* Spyware: Spyware covers untargeted collection of personal information as opposed to targeted surveillance.

* Network Spoofing Attacks: An attacker deploys a rogue network access point (WiFi or GSM) and users connect to it. The attacker subsequently intercepts (or tampers with) the user communication to carry out further attacks such as phishing.
** Use the GSM encryption-on indicator to detect and signal downgrade attacks.

* Surveillance attacks: An attacker keeps a specific user under surveillance through the target user’s smartphone.
** Don't use 3rd party code without carefully verifying
* Diallerware attacks: An attacker steals money from the user by means of malware that makes hidden use of premium SMS services or numbers.
* Financial malware attacks The smartphone is infected with malware specifically designed for stealing credit card numbers, online banking credentials or subverting online banking or ecommerce transactions.
* Network congestion Network resource overload due to smartphone usage leading to network unavailability for the end-user.
** Note that this relies a lot on smart developers because a lot of the congestion is due to signalling overload. Could we make some recommendations on detecting idle/focus so that the app knows when it really needs to be connected to the network?
* Unauthorized network connectivity (exfiltration or command & control)
* UI Impersonation
* System modification (rootkit, APN proxy config)
** Validate updates and input data from untrusted sources.
* Logic or Time bomb (including runtime interpreter)
** Define clearly who should be responsible for updating the application Extensions or plugins e.g. Angry birds Add-ons and installations
* Unsafe sensitive data transmission
* Hardcoded password/keys
* Lack of data protection in transit
** Don't allow SSL downgrade.
** Don't trust network infrastructure
** See Network Spoofing.
* Client-side injection
* Client-side DOS
* Malicious third-party code
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code).
* Client-side buffer overflow
* Failure to properly handle inbound SMS messages
** Remove test code from software
* Failure to properly handle outbound SMS messages
* Failure to disable insecure platform features in application (caching of keystrokes, screen data)
** Least privilege. Be aware of privileges granted by default by API's and disable them.

OWASP Mobile Security Project

2011-05-17T09:49:41Z

Vinaykbansal:

==== Main ====
{{:Projects/OWASP Mobile Security Project | Project About}}

==== For Security Testers ====
{{:Projects/OWASP Mobile Security Project - Security Testers | Security Testers}}

==== Secure Development Guidelines ====
{{:Projects/OWASP Mobile Security Project - Secure Development Guidelines | Secure Development Guidelines}}

==== Top Ten Mobile Risks ====
{{:Projects/OWASP Mobile Security Project - Top Ten Mobile Risks | Top Ten Mobile Risks}}

==== Top Ten Mobile Controls ====
{{:Projects/OWASP Mobile Security Project - Top Ten Mobile Controls | Top Ten Mobile Controls And Design Principles}}

==== Mobile Platforms ====
{{:Projects/OWASP Mobile Security Project - Mobile Platforms | Mobile Platforms}}

==== Mobile Threat Model ====
{{:Projects/OWASP Mobile Security Project - Mobile Threat Model | Mobile Threat Model}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Mobile Security Project]] [[Category:OWASP_Document]] [[Category:OWASP_Alpha_Quality_Document|OWASP Alpha Quality Document]]

OWASP Mobile Security Project

2011-05-17T09:48:54Z

Vinaykbansal:

==== Main ====
{{:Projects/OWASP Mobile Security Project | Project About}}

==== For Security Testers ====
{{:Projects/OWASP Mobile Security Project - Security Testers | Security Testers}}

==== Secure Development Guidelines ====
{{:Projects/OWASP Mobile Security Project - Secure Development Guidelines | Secure Development Guidelines}}

==== Top Ten Mobile Risks ====
{{:Projects/OWASP Mobile Security Project - Top Ten Mobile Risks | Top Ten Mobile Risks}}

==== Top Ten Mobile Controls ====
{{:Projects/OWASP Mobile Security Project - Top Ten Mobile Controls And Design Principles| Top Ten Mobile Controls}}

==== Mobile Platforms ====
{{:Projects/OWASP Mobile Security Project - Mobile Platforms | Mobile Platforms}}

==== Mobile Threat Model ====
{{:Projects/OWASP Mobile Security Project - Mobile Threat Model | Mobile Threat Model}}

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Mobile Security Project]] [[Category:OWASP_Document]] [[Category:OWASP_Alpha_Quality_Document|OWASP Alpha Quality Document]]

Projects/OWASP Mobile Security Project - Top Ten Mobile Controls

2011-05-17T09:45:58Z

Vinaykbansal: /* Top 10 mobile controls */

== Top 10 mobile controls and design principles==

'''1. Identify and protect sensitive data on the mobile device'''

'''Risk''': Mobile devices (being mobile) have a higher risk of getting lost, stolen. And it is trivial to Jailbreak or root the device once someone has physical possession of the device. Adequate protection be built to minimize the loss of sensitive data on device.

** In the design phase analyze what data is sensitive and needs to be protected and apply appropriate controls (user personal/privacy data, password credentials etc.).
** Store sensitive data on the server instead of client-end device, if possible.
**Leverage the encryption and key-store mechanism provided by the mobile OS/hardware to secure sensitive data. In case no good key management is available on the client-end, storing keys on the server side could be considered.
**Do not store/cache sensitive data on the removable media
**Use only protected temp/cache directories (Do not store temp/cached data in a world readable directory)
** Automatically delete data from device which is no longer required
** Be aware of caches and temporary storage as a possible leakage channel
**Managed devices should leverage remote wipe and kill switch to remove sensitive information from the device

'''2. Handle password credentials securely on the device'''

'''Risk''': User's password credentials if stolen not only provides unauthorized access to the mobile backend service but potentially many other services/accounts used by the user. Since a majority of the users reuse their passwords (http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html )

**Instead of passwords consider using longer term tokens that can be securely stored on the device (OAuth). Tokens can be issued by the backend service after verifying the user credentials initially. And the tokens could be time bound to the specific service, minimizing the damage in loss scenarios.
**In case passwords needs to stored on the device leverage the encryption and key-store mechanism provided by the mobile OS/hardware to securely store password credentials
**Provide mechanism to the mobile user to change/remove passwords on the device
**Password credentials should be marked to avoid being copied to backups
**Ensure passwords are not visible in cache or logs

'''3. Ensure sensitive data is protected in transit'''

'''Risk''': Majority of the smartphones are capable of using multiple transport carriers including Wifi, provider network(3G, GSM,..), bluetooth. Sensitive data passing through insecure channels could be intercepted.

**Protecting Data in transit (assume the worst case, user sitting in a public unprotected wifi )
**Applications should ensure that a secure channel (such as SSL/TLS) is established end-end when sending sensitive information on wire/air. (Do not assume transport encryption)
**To reduce the risk of man-in-middle (like SSL proxy), secure connection should only be established after verifying the credentials of remote end-point (server). This can be achieved by ensuring that SSL is only established with the end points having the trusted certificates in key chain.
**Do not disable or ignore the SSL chain validation.
**SMS, MMS or notifications should not be used to send sensitive data to mobile end points

'''4. Keep the back-end API and mobile platform secure'''

'''Risk''': Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow bad guys to directly attack/compromise the back-ends.

**Web Services/ SOAP/ REST , security best practices (placeholder)
** Input validation
** Do not use a generic shared secret for integration to backend (like embedded password in code)
**Use authentication that ties back to the end user identity (rather than the device identity)
**Ensure authorization controls are done correctly in the backend APIs.
**Ensure that the backend platform is running on a hardened configuration with latest security patches
**Employ rate limiting and throttling, test for DDoS vulnerabilities

'''5. Implement user authentication/authorization and session management correctly'''

'''Risk''': Majority of the mobile applications interact with the backend APIs using REST/Web Services or other proprietary protocols. It is important to ensure that the session management is done correctly after the initial authentication.

**User authentication must be based on user's credentials.
**Use unpredictable session identifier with high entropy
**Do not use device id (UDID or IMEI) as the only session identifier. Device Id is easy to spoof. (Device Id could be used as an additional check or stronger validation that the request is originating from the known device)
**Session tokens can be cached using the operating system features to encrypt while in storage on device (e.g. Keychains).
** Device cert can be used for stronger device identity

'''6. Ensure strong vulnerability and patch management in place'''

**All the back-end APIs (WebServices/REST) for mobile apps must be tested for vulnerabilities periodically.
** Developers should use static code analyzer tools and fuzzing tools for testing and finding security flaws.
**Applications must be designed and provisioned to allow updates for security patches.
**Application team is responsible for tracking all third party frameworks/APIs used in the mobile application for security patches. A corresponding security update must be done for the mobile application using these third party APIs/frameworks.

'''7. Employ the secure coding/development practices'''

** Input Validation and Output Encoding
**Vet the security/authenticity of any third party code/libraries used in your mobile application ( reliable source, supported, no backend Trojans, licensing)
**Avoid opening application specific server sockets (listener ports) on the client device. Use the communication mechanisms provided by the OS.
**Code signing for some mobile platforms allows inherent trust between applications (with same code signatures), installed on the same mobile device. Plan code signing mechanisms properly.
**Leverage static and binary code analyzers to find security flaws.
** Use safe string function, avoid buffer and Integer overflow
**Context aware security: may be able to decrease/increase access based on the context (e.g. location, network)
**For applications using JNI (Android) using a third party validation to ensure no vulnerabilities.
**Remove all test code before releasing the application
**Ensure logging is done appropriately in the released application. No excessive logging, no sensitive user information in log files

'''8. Perform data integration with third party backend applications correctly'''

** User informed if any personal data is collected or sent
**No sensitive or user personal data is sent or shared with a third party/social site without prior approval and knowledge of the user.
**Validate all data received from the non-trusted third party before processing in the application.

'''9. Run the mobile client using minimal permission'''

**Run with the minimum privilege required for the application on the operating system.
**Don't authorize code/app to execute with root privilege
**Always perform testing as a standard user (rather than a privileged user)
**Least privilege. Be aware of privileges granted by default by API's and disable them.

'''10. Enforce higher security posture on the device for sensitive apps'''

**If a sensitive application needs to be provisioned on a device, application can employ enforcement of the certain security posture on the device (such as PIN, remote management/wipe)
** Enterprise applications can employ this principle of doing a security posture check before deployment of sensitive enterprise applications

=== Candidates (to be merged if needed) ===

'''11. No secrets in code/binary'''

'''Risk''': Mobile application binaries can be easily reverse engineered.

**Do not store any passwords or secrets in the application binary

'''12. Protect your application from other malicious applications on the device'''

'''Risk''': User's are prone to install applications that look cool (may be malicious) and can transmit data about user (or stored data) for malicious purpose.

**(?? What guidelines could be provided to developers)
**User education on using due diligence while installing third party applications on mobile devices

=== Original list (kept for review) ===
# Protect data at rest
# Protect data in transport
# Multi-factor authentication
# Session management
# Least privilege access control
# Untrusted data validation
# Output encoding
# Enterprise device management
# Keep business logic on the server
# Platform security

Architecture and design principles

2011-05-15T09:26:35Z

Vinaykbansal:

The following is a merge of ENISA, OWASP and Veracode top 10. Note that there is a mixture of threats and vulnerabilities here - we should decide whether to use risks (threats with impact on assets which occur with probability) and vulnerabilities (system flaws which increase the probability of a threat occurring). I have cut those risks/vulnerabilities which cannot be addressed in any way by developers. We should decide whether to include recommendations in the style of "code of practice"- e.g. activity monitoring should only be used in circumstances xyz... (feel free to restructure)

My recommendation would be to separate out the design principles from the Risks/Vulnerabilities.

=='''Mobile Security'''==
*1. Threats, Risks and Vulnerabilities (Risks)
*2. Design Principles (As part of the Controls)
*3. Architectural Patterns (New)
*4. Secure Mobile Development/Coding Guidelines

==1. Top Risks/Vulnerabilities==

* Unsafe sensitive data storage
** Consider the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Automatically delete data which is not required (how to know when it's not required?).
** Securely delete data using standard shredding techniques.
** Store a minimum of data on the client side device.
** Securely wipe removable media.
** Be aware of caches and temporary storage as a possible leakage channel.
** Implement key and password storage best practice.
** In the design phase analyse what data needs to be protected most and what doesn't and apply controls at appropriate places.

* Unintentional disclosure of data: The smartphone user unintentionally discloses data on the smartphone.
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers wherever possible - e.g. do not use the EMEI number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Obtain user explicit user consent according to best practice (see implementation guidelines) for collection of personal data.

* Attacks on decommissioned smartphones: The smartphone is decommissioned improperly allowing an attacker access to the data on the device.
** See first risk
** Provide a convenient way of resetting access credentials which does not require the device (consider an automated timeout on access credentials).
** Consider using SIM card as default storage for small but sensitive data such as keys.

* Phishing attacks: An attacker collects user credentials (such as passwords and credit card numbers) by means of fake apps or (SMS, email) messages that seem genuine.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths.
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

* Spyware: Spyware covers untargeted collection of personal information as opposed to targeted surveillance.

* Network Spoofing Attacks: An attacker deploys a rogue network access point (WiFi or GSM) and users connect to it. The attacker subsequently intercepts (or tampers with) the user communication to carry out further attacks such as phishing.
** Use the GSM encryption-on indicator to detect and signal downgrade attacks.

* Surveillance attacks: An attacker keeps a specific user under surveillance through the target user’s smartphone.
** Don't use 3rd party code without carefully verifying
* Diallerware attacks: An attacker steals money from the user by means of malware that makes hidden use of premium SMS services or numbers.
* Financial malware attacks The smartphone is infected with malware specifically designed for stealing credit card numbers, online banking credentials or subverting online banking or ecommerce transactions.
* Network congestion Network resource overload due to smartphone usage leading to network unavailability for the end-user.
** Note that this relies a lot on smart developers because a lot of the congestion is due to signalling overload. Could we make some recommendations on detecting idle/focus so that the app knows when it really needs to be connected to the network?
* Unauthorized network connectivity (exfiltration or command & control)
* UI Impersonation
* System modification (rootkit, APN proxy config)
** Validate updates and input data from untrusted sources.
* Logic or Time bomb (including runtime interpreter)
** Define clearly who should be responsible for updating the application Extensions or plugins e.g. Angry birds Add-ons and installations
* Unsafe sensitive data transmission
* Hardcoded password/keys
* Lack of data protection in transit
** Don't allow SSL downgrade.
** Don't trust network infrastructure
** See Network Spoofing.
* Client-side injection
* Client-side DOS
* Malicious third-party code
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code).
* Client-side buffer overflow
* Failure to properly handle inbound SMS messages
** Remove test code from software
* Failure to properly handle outbound SMS messages
* Failure to disable insecure platform features in application (caching of keystrokes, screen data)
** Least privilege. Be aware of privileges granted by default by API's and disable them.

Architecture and design principles

2011-05-14T15:48:15Z

Vinaykbansal:

The following is a merge of ENISA, OWASP and Veracode top 10. Note that there is a mixture of threats and vulnerabilities here - we should decide whether to use risks (threats with impact on assets which occur with probability) and vulnerabilities (system flaws which increase the probability of a threat occurring). I have cut those risks/vulnerabilities which cannot be addressed in any way by developers. We should decide whether to include recommendations in the style of "code of practice"- e.g. activity monitoring should only be used in circumstances xyz... (feel free to restructure)

My recommendation would be to separate out the design principles from the Risks/Vulnerabilities.

=='''Mobile Security'''==
*1. Threats, Risks and Vulnerabilities
*2. Design Principles
*3. Architectural Patterns
*4. Secure Mobile Development/Coding Guidelines

==1. Top Risks/Vulnerabilities==

* Unsafe sensitive data storage
** Consider the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Automatically delete data which is not required (how to know when it's not required?).
** Securely delete data using standard shredding techniques.
** Store a minimum of data on the client side device.
** Securely wipe removable media.
** Be aware of caches and temporary storage as a possible leakage channel.
** Implement key and password storage best practice.
** In the design phase analyse what data needs to be protected most and what doesn't and apply controls at appropriate places.

* Unintentional disclosure of data: The smartphone user unintentionally discloses data on the smartphone.
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers wherever possible - e.g. do not use the EMEI number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Obtain user explicit user consent according to best practice (see implementation guidelines) for collection of personal data.

* Attacks on decommissioned smartphones: The smartphone is decommissioned improperly allowing an attacker access to the data on the device.
** See first risk
** Provide a convenient way of resetting access credentials which does not require the device (consider an automated timeout on access credentials).
** Consider using SIM card as default storage for small but sensitive data such as keys.

* Phishing attacks: An attacker collects user credentials (such as passwords and credit card numbers) by means of fake apps or (SMS, email) messages that seem genuine.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths.
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

* Spyware: Spyware covers untargeted collection of personal information as opposed to targeted surveillance.

* Network Spoofing Attacks: An attacker deploys a rogue network access point (WiFi or GSM) and users connect to it. The attacker subsequently intercepts (or tampers with) the user communication to carry out further attacks such as phishing.
** Use the GSM encryption-on indicator to detect and signal downgrade attacks.

* Surveillance attacks: An attacker keeps a specific user under surveillance through the target user’s smartphone.
** Don't use 3rd party code without carefully verifying
* Diallerware attacks: An attacker steals money from the user by means of malware that makes hidden use of premium SMS services or numbers.
* Financial malware attacks The smartphone is infected with malware specifically designed for stealing credit card numbers, online banking credentials or subverting online banking or ecommerce transactions.
* Network congestion Network resource overload due to smartphone usage leading to network unavailability for the end-user.
** Note that this relies a lot on smart developers because a lot of the congestion is due to signalling overload. Could we make some recommendations on detecting idle/focus so that the app knows when it really needs to be connected to the network?
* Unauthorized network connectivity (exfiltration or command & control)
* UI Impersonation
* System modification (rootkit, APN proxy config)
** Validate updates and input data from untrusted sources.
* Logic or Time bomb (including runtime interpreter)
** Define clearly who should be responsible for updating the application Extensions or plugins e.g. Angry birds Add-ons and installations
* Unsafe sensitive data transmission
* Hardcoded password/keys
* Lack of data protection in transit
** Don't allow SSL downgrade.
** Don't trust network infrastructure
** See Network Spoofing.
* Client-side injection
* Client-side DOS
* Malicious third-party code
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code).
* Client-side buffer overflow
* Failure to properly handle inbound SMS messages
** Remove test code from software
* Failure to properly handle outbound SMS messages
* Failure to disable insecure platform features in application (caching of keystrokes, screen data)
** Least privilege. Be aware of privileges granted by default by API's and disable them.

Architecture and design principles

2011-05-14T15:46:51Z

Vinaykbansal:

The following is a merge of ENISA, OWASP and Veracode top 10. Note that there is a mixture of threats and vulnerabilities here - we should decide whether to use risks (threats with impact on assets which occur with probability) and vulnerabilities (system flaws which increase the probability of a threat occurring). I have cut those risks/vulnerabilities which cannot be addressed in any way by developers. We should decide whether to include recommendations in the style of "code of practice"- e.g. activity monitoring should only be used in circumstances xyz... (feel free to restructure)

My recommendation would be to separate out the design principles from the Risks/Vulnerabilities.

=='''Mobile Security'''==
*1. Threats, Risks and Vulnerabilities
*2. Design Principles
*3. Architectural Patterns
*4. Secure Mobile Development Guidelines

==1. Top Risks/Vulnerabilities==

* Unsafe sensitive data storage
** Consider the whole data lifecycle in writing your application (collection over the wire, temporary storage, caching, backup, deletion etc...)
** Automatically delete data which is not required (how to know when it's not required?).
** Securely delete data using standard shredding techniques.
** Store a minimum of data on the client side device.
** Securely wipe removable media.
** Be aware of caches and temporary storage as a possible leakage channel.
** Implement key and password storage best practice.
** In the design phase analyse what data needs to be protected most and what doesn't and apply controls at appropriate places.

* Unintentional disclosure of data: The smartphone user unintentionally discloses data on the smartphone.
** Apply the principle of minimal disclosure - only collect and disclose data which is required for the application (how to know what this is?)
** Use non-persistent identifiers wherever possible - e.g. do not use the EMEI number as an identifier unless there is a good reason to do so.
** Apply techniques for the detection of covert channels - e.g. covert flow trees to discover information which may flow through shared resources such as file systems, resource use etc...
** Carefully control what data which is stored in public stores such as address book, media gallery etc... including metadata.
** Obtain user explicit user consent according to best practice (see implementation guidelines) for collection of personal data.

* Attacks on decommissioned smartphones: The smartphone is decommissioned improperly allowing an attacker access to the data on the device.
** See first risk
** Provide a convenient way of resetting access credentials which does not require the device (consider an automated timeout on access credentials).
** Consider using SIM card as default storage for small but sensitive data such as keys.

* Phishing attacks: An attacker collects user credentials (such as passwords and credit card numbers) by means of fake apps or (SMS, email) messages that seem genuine.
** Provide appropriate trust cues for linking to unknown third party applications.
** Do not train users to follow untrusted paths.
** Provide a reporting channel for phishing from apps (e.g. if you are a browser plugin developer).

* Spyware: Spyware covers untargeted collection of personal information as opposed to targeted surveillance.

* Network Spoofing Attacks: An attacker deploys a rogue network access point (WiFi or GSM) and users connect to it. The attacker subsequently intercepts (or tampers with) the user communication to carry out further attacks such as phishing.
** Use the GSM encryption-on indicator to detect and signal downgrade attacks.

* Surveillance attacks: An attacker keeps a specific user under surveillance through the target user’s smartphone.
** Don't use 3rd party code without carefully verifying
* Diallerware attacks: An attacker steals money from the user by means of malware that makes hidden use of premium SMS services or numbers.
* Financial malware attacks The smartphone is infected with malware specifically designed for stealing credit card numbers, online banking credentials or subverting online banking or ecommerce transactions.
* Network congestion Network resource overload due to smartphone usage leading to network unavailability for the end-user.
** Note that this relies a lot on smart developers because a lot of the congestion is due to signalling overload. Could we make some recommendations on detecting idle/focus so that the app knows when it really needs to be connected to the network?
* Unauthorized network connectivity (exfiltration or command & control)
* UI Impersonation
* System modification (rootkit, APN proxy config)
** Validate updates and input data from untrusted sources.
* Logic or Time bomb (including runtime interpreter)
** Define clearly who should be responsible for updating the application Extensions or plugins e.g. Angry birds Add-ons and installations
* Unsafe sensitive data transmission
* Hardcoded password/keys
* Lack of data protection in transit
** Don't allow SSL downgrade.
** Don't trust network infrastructure
** See Network Spoofing.
* Client-side injection
* Client-side DOS
* Malicious third-party code
** Follow security best practice for implementation of runtime interpreters (be careful when implementing anything which turns user input into executable code).
* Client-side buffer overflow
* Failure to properly handle inbound SMS messages
** Remove test code from software
* Failure to properly handle outbound SMS messages
* Failure to disable insecure platform features in application (caching of keystrokes, screen data)
** Least privilege. Be aware of privileges granted by default by API's and disable them.

Projects/OWASP Mobile Security Project

2011-03-11T19:40:53Z

Vinaykbansal:

{{Template:Project About
| project_name = OWASP Mobile Security Project
| project_home_page = OWASP_Mobile_Security_Project
| project_description =
The rapid growth of mobile computing has made the need for secure mobile development absolutely essential. The OWASP Mobile Security Project will help the community better understand the risks present in mobile applications, and learn to defend against them. This project will be forked into each of the following platforms:
* iOS Project
* Android Project
* webOS Project
* Windows Mobile Project
* Blackberry Project

| project_license =

| leader_name1 = Jack Mannino
| leader_email1 = Jack@nvisiumsecurity.com
| leader_username1 = Jack Mannino

| leader_name2 = Mike Zusman
| leader_email2 = mike.zusman@intrepidusgroup.com
| leader_username2 = schmoilito

| contributor_name2 = Jim Manico
| contributor_email2 = jim.manico@owasp.org
| contributor_username2= jmanico

| contributor_name1 = David Lindner
| contributor_email1 = david.lindner@aspectsecurity.com
| contributor_username1 = David Lindner

| contributor_name3 = Tom Neaves
| contributor_email3 = tom.neaves@verizonbusiness.com
| contributor_username3 = Tom Neaves

| contributor_name4 = Kuai Hinojosa
| contributor_email4 = Kuai.Hinojosa@owasp.org
| contributor_username4 = Kuai Hinojosa

| contributor_name5 = Vinay Bansal
| contributor_email5 = vinay.bansal@cisco.com
| contributor_username5 = Vinay Bansal

| pamphlet_link =

| presentation_link =

| mailing_list_name = https://lists.owasp.org/mailman/listinfo/owasp-mobile-security-project

| project_road_map = http://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project/Roadmap

| links_url[1-10] =

| links_name[1-10] =

| release_1 =
| release_2 =
| release_3 =
| release_4 =
}}

Category:OWASP Cloud ‐ 10 Project

2010-10-26T16:56:02Z

Vinaykbansal: /* Audience */

==== Main ====

== Cloud Top 10 Security Risks ==

== Goal ==

According to Gartner, by 2012, 20% of businesses will adopt cloud services and own no IT assets. Goal of the project is to maintain a list of top 10 security risks faced with the Cloud* Computing and SaaS Models. List will be maintained by input from community, security experts and security incidences at cloud/SaaS providers.

* Most of the risks are based on the assumption that Cloud is a public or a hybrid cloud

== Audience ==

Audience for the project will be organizations planning on leveraging external cloud environment to host their applications or rent application in a SaaS model (Software as a Service). Aim of the "OWASP Cloud-10" list is to help balance security risks with the cost advantage that the Cloud and SaaS model provides. We expect the Cloud and SaaS providers to be indirect audience for "OWASP Cloud-10", when they try to showcase their security controls to potential customers against this list.

Also refer the recent presentation - http://www.owasp.org/images/4/47/Cloud-Top10-Security-Risks.pdf

== Initial pre-alpha list of OWASP Cloud Top 10 Security Risks ==

{| cellpadding="2" border="1"
|-
| [http://www.owasp.org/index.php/Cloud-10_Accountability_and_Data_Ownership R1 - Accountability and Data Ownership]
| A traditional data center of an organization is under complete control of that organization. The organization logically and physically protects the data it owns. An organization that chooses to use a public cloud for hosting its business service loses control of its data. This poses critical security risks that the organization needs to carefully consider and mitigate. (Pankaj, Vinay)
|-
| [http://www.owasp.org/index.php/Cloud-10_User_Identity_Federation R2 - User Identity Federation]
| It is very important for the enterprises to keep control over user identities as they move services and applications to the different cloud providers. Rather than letting cloud providers create multiple islands of identities that become too complex to manage down the line. Users should be uniquely identifiable with a federated authentication (e.g. SAML) that works across the cloud providers. User experience is enhanced when he/she does not manage multiple userids and credentials. This allows easier back-end data integrations between cloud provides. (Vinay, Pankaj)
|-
| [http://www.owasp.org/index.php/Cloud-10_Regulatory_Compliance R3 - Regulatory Compliance]
| - Complex to Demonstrate regulatory compliance. Data that is perceived to be secure in one country may not be perceived secure in another due to different regulatory laws across countries or regions. For eg., European Union has very strict privacy laws and hence data stored in US may not comply with those EU laws. (Shankar, Ove)
|-
| [http://www.owasp.org/index.php/Cloud-10_Business_Continuity_and_Resiliency R4 - Business Continuity and Resiliency]
| Business Continuity is an activity an IT organization performs to ensure that the business can be conducted in a disaster situation. In case of an organization that uses cloud, the responsibility of business continuity gets delegated to the cloud provider. This creates a risk to the organization of not having appropriate business continuity. (Pankaj, Shankar)
|-
| [http://www.owasp.org/index.php/Cloud-10_User_Privacy_and_Secondary_Usage_of_Data R5 - User Privacy and Secondary Usage of Data]
| User's personal data gets stored in the cloud as users start using social web sites. Most of the social sites are vague about how they will handle users personal data. Additionally most of the social sites go with the default share all (least restrictive) setup for the user. E.g. via LinkedIn, Twitter, Facebook it is very easy to deduct personal details of the users (Vinay) - Need to ensure with your cloud providers what data can or cannot be used by them for secondary purposes. It includes data that can be mined directly from user data by providers or indirectly based on user behavior (clicks, incoming outgoing URLs etc.). Many social application providers mine user data for secondary usage e.g. directed advertising. No wonder when many of us use their personal gmail/hotmail or yahoo account to tell a friend your vacation plans and immediately you start seeing advertisements on hotels/flights near your destination. (Vinay, Ove)

|-
| [http://www.owasp.org/index.php/Cloud-10_Service_and_Data_Integration R6 - Service and Data Integration]
| Organizations must be sure that their proprietary data is adequately protected as it is transferred between the end user and the cloud data center. While interception of data in transit should be of concern to every organization, the risk is much greater for organizations utilizing a cloud computing model, where data is transmitted over the Internet. Unsecured data is susceptible to interception and compromise during transmission. (Shankar, Ove)

|-
| [http://www.owasp.org/index.php/Cloud-10_Multi_Tenancy_and_Physical_Security R7 - Multi Tenancy and Physical Security]
| Multi-tenancy in cloud means sharing of resources and services among multiple clients(CPU, networking, storage/databases, application stack). It increases dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants. (Vinay, Pankaj)

|-
| [http://www.owasp.org/index.php/Cloud-10_Incidence_Analysis_and_Forensic_Support R8 - Incidence Analysis and Forensic Support]
|In the event of a security incident, applications and services hosted at a cloud provider are difficult to investigate as logging may be distributed across multiple hosts and data centers which could be located in various countries and hence governed by different laws. Also, along with log files, data belonging to multiple customers may be co-located on the same hardware and storage devices and hence a concern for law enforcing agencies for forensic recovery. (Shankar, Ove)

|-
| [http://www.owasp.org/index.php/Cloud-10_Infrastructure_Security R9 - Infrastructure Security]
| All infrastructure must be hardened and configured securely, and the hardening/configuration baselines should be based on Industry Best Practices. Applications, systems and networks must be architected and configured with tiering and security zones, and access must be configured to only allow required network and application protocols. Administrative access must be role-based, and granted on a need-to-know basis. Regular risk assessments must be done, preferably by an independent party. A policy and process must be in place for patching/security updates, and can based on risk/threat assessments of new security issues. (Ove, Shankar)

Although the fine details of the items above must be regarded as highly sensitive information, it is reasonable to expect a customer to want to see at least the high-level details. The Provider must be willing to provide this.
|-
| [http://www.owasp.org/index.php/Cloud-10_Nonproduction_Environment_Exposure R10 - Non Production Environment Exposure]
| An IT organization that develops software applications internally employs a set of non-production environments for design, development, and test activities. The non-production environments are generally not secured to the same extent as the production environment. If an organization uses a cloud provider for such non-production environment, then there is a high risk of unauthorized access, information modification, and information theft. (Pankaj, Ove)
|-
|}

'''<center>Table 1: Top 10 Cloud - Security Risks</center>'''

== Other OWASP Cloud-10 Candidates ==

* exposure to non-prod and internal environments
*Integration between cloud and internally hosted services
*Patching and Vulnerability Management
*Lack of Transparency in Internal Security Controls and difficulty/complexity of auditing
*Enterprise Intranets exposed directly on Internet (if they move on a Public Cloud)

<br> This needs to be debated and for each of these we may need to add a separate page-holder with the following details.

*Various Risk Scenarios
*Real World Examples
*Possible Mitigation and Security Controls
*Reference to any related Incident

<br>

==== Roadmap (Status) ====

== Managing OWASP Cloud-10 List (Pre-Alpha) ==

“OWASP Cloud-10” list will be maintained by input from, community, security experts and security incidences at cloud/SaaS providers.

Each of the identified risk in "OWASP Cloud-10" will provide details on:

*Various Risk Scenarios
*Real World Examples
*Possible Mitigations and Security Controls
*Reference to any related Incident

<br>
Risk Criteria:

#Easily Executable
#Most Damaging
#Incidence Frequency (Known)

== Alpha Release ==

#'''Identify and publish a first draft of potential "OWASP Cloud-10" candidates (Dec 2009)'''
#Ask contributors to collect more data and details on each of the risk item. (till Jan 2010)
#Get initial community feedback by discussing it in various blogs, discussion forums etc. (Jan-Feb 2010)

== Beta Release ==

# Writeup to be finished by April 5th (All)
# Provide feedback by April 19th
# Incorporate all the comments feedback by 26th April
# Publish the first (beta) list of "OWASP Cloud-10" (April 3rd 2010)
#Identify additional candidates
#……. (repeat steps as in Alpha)

<br>

==== Taxonomy ====

== Terms ==

== Diagrams ==

==== Reference ====

== Related Efforts ==

#Cloud Security Alliance - http://www.cloudsecurityalliance.org/
#IDC Aug 2008 Survey (Security #1) Challenge for Cloud/On-Demand Models - http://blogs.idc.com/ie/?p=210

== Related OWASP Projects ==

#OWASP Top Ten Project
#OWASP Legal Project

<br>

==== Contributors ====

== Project Leaders ==

[[:User:vinaykbansal|'''Vinay Bansal''']]
<br>[[User:Shankar Babu Chebrolu|Shankar Babu Chebrolu]]
<br>[[User:Pankaj Telang|Pankaj Telang]]
<br>[http://www.owasp.org/index.php/User:Ken_Huang Ken Huang]
<br>[[User:Ove Hansen|Ove Hansen]]

== Contributors ==

<br>

<br>

#[https://lists.owasp.org/mailman/listinfo/owasp-cloud-10 Subscribe or read the Cloud-10 mail archives]

==== Project Details ====

{{:GPC Project Details/OWASP Cloud ‐ 10 Project | OWASP Project Identification Tab}}

<br> __NOTOC__ <headertabs />

[[Category:Cloud_-_Top_5_Risks_with_PAAS|<br>]]

File:Cloud-Top10-Security-Risks.pdf

2010-10-26T16:48:07Z

Vinaykbansal: Presentation on OWASP Top Ten Cloud Security Risks

Presentation on OWASP Top Ten Cloud Security Risks

Cloud-10 Multi Tenancy and Physical Security

2010-08-30T11:41:00Z

Vinaykbansal: /* Countermeasures */

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services to run software instances serving multiple consumers and client organizations (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''Performance Risks''' :One tenant’s heavy use of the service may impact the quality of service provided to other tenants.
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# '''Architecting for Multi-Tenancy''' : Providers need to architect for multi-tenants, rather than making services that are not designed for multi-tenancy to work. Multi-tenancy architecture should take into account logical segregation, strengthen common services and single point of failures. Also provide more transparency to consumers/tenants [12].
# '''Data Encryption''': For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# '''Controlled Change Management''' : eployment of the changes (especially to common shared services) should be well planned . Usage of feathered release cycles to migrate tenants to new infrastructure. For SaaS providers tenants should be progressively migrated to newer underlying infrastructure. (Providers need to plan extra resources for these activities). Providers should have a dependency mapping of tenants to underlying resources and services. So that any change in the underlying resources can be well planned.
# '''Transparency/Audit-ability of Administrative Access''': Tenants should have knowledge on administrative access to all their resources/services. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.
# '''Virtual Private Cloud (VPC)''' : It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# '''Third Party Assessments''': Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].
# '''Tenant Isolation''' : Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.

==Related Incidence==

#'''Wordpress Outage June 2010'''
WordPress that houses high profile blogging sites (such as CNN, Techcrunch), 3 data centers (1300 servers , 10 million blogs) had an outage due to config changes done by programmer (to a database field). It impacted a large set of tenants on this multitenant blogging service [7,8,9].

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-30T11:23:18Z

Vinaykbansal: /* R7: Multi Tenancy and Physical Security */

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services to run software instances serving multiple consumers and client organizations (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''Performance Risks''' :One tenant’s heavy use of the service may impact the quality of service provided to other tenants.
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# '''Tenant Isolation''' : Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
# '''Data Encryption''': For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# '''Architecting for Multi-Tenancy''' : Providers need to architect for multi-tenants, rather than making services that are not designed for multi-tenancy to work. Multi-tenancy architecture should take into account logical segregation, strengthen common services and single point of failures. Also provide more transparency to consumers/tenants [12].
# '''Controlled Change Management''' : eployment of the changes (especially to common shared services) should be well planned . Usage of feathered release cycles to migrate tenants to new infrastructure. For SaaS providers tenants should be progressively migrated to newer underlying infrastructure. (Providers need to plan extra resources for these activities). Providers should have a dependency mapping of tenants to underlying resources and services. So that any change in the underlying resources can be well planned.
# '''Virtual Private Cloud (VPC)''' : It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# '''Third Party Assessments''': Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].
# '''Transparency/Audit-ability of Administrative Access''': Tenants should have knowledge on administrative access to all their resources/services. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.

==Related Incidence==

#'''Wordpress Outage June 2010'''
WordPress that houses high profile blogging sites (such as CNN, Techcrunch), 3 data centers (1300 servers , 10 million blogs) had an outage due to config changes done by programmer (to a database field). It impacted a large set of tenants on this multitenant blogging service [7,8,9].

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-30T11:00:59Z

Vinaykbansal:

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''Performance Risks''' :One tenant’s heavy use of the service may impact the quality of service provided to other tenants.
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# '''Tenant Isolation''' : Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
# '''Data Encryption''': For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# '''Architecting for Multi-Tenancy''' : Providers need to architect for multi-tenants, rather than making services that are not designed for multi-tenancy to work. Multi-tenancy architecture should take into account logical segregation, strengthen common services and single point of failures. Also provide more transparency to consumers/tenants [12].
# '''Controlled Change Management''' : eployment of the changes (especially to common shared services) should be well planned . Usage of feathered release cycles to migrate tenants to new infrastructure. For SaaS providers tenants should be progressively migrated to newer underlying infrastructure. (Providers need to plan extra resources for these activities). Providers should have a dependency mapping of tenants to underlying resources and services. So that any change in the underlying resources can be well planned.
# '''Virtual Private Cloud (VPC)''' : It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# '''Third Party Assessments''': Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].
# '''Transparency/Audit-ability of Administrative Access''': Tenants should have knowledge on administrative access to all their resources/services. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.

==Related Incidence==

#'''Wordpress Outage June 2010'''
WordPress that houses high profile blogging sites (such as CNN, Techcrunch), 3 data centers (1300 servers , 10 million blogs) had an outage due to config changes done by programmer (to a database field). It impacted a large set of tenants on this multitenant blogging service [7,8,9].

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-29T20:01:39Z

Vinaykbansal: /* Countermeasures */

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# '''Tenant Isolation''' : Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
# '''Data Encryption''': For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# '''Architecting for Multi-Tenancy''' : Providers need to architect for multi-tenants, rather than making services that are not designed for multi-tenancy to work. Multi-tenancy architecture should take into account logical segregation, strengthen common services and single point of failures. Also provide more transparency to consumers/tenants [12].
# '''Controlled Change Management''' : eployment of the changes (especially to common shared services) should be well planned . Usage of feathered release cycles to migrate tenants to new infrastructure. For SaaS providers tenants should be progressively migrated to newer underlying infrastructure. (Providers need to plan extra resources for these activities). Providers should have a dependency mapping of tenants to underlying resources and services. So that any change in the underlying resources can be well planned.
# '''Virtual Private Cloud (VPC)''' : It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# '''Third Party Assessments''': Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].
# '''Transparency/Audit-ability of Administrative Access''': Tenants should have knowledge on administrative access to all their resources/services. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.

==Related Incidence==

#'''Wordpress Outage June 2010'''
WordPress that houses high profile blogging sites (such as CNN, Techcrunch), 3 data centers (1300 servers , 10 million blogs) had an outage due to config changes done by programmer (to a database field). It impacted a large set of tenants on this multitenant blogging service [7,8,9].

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-29T19:51:15Z

Vinaykbansal: /* Related Incidence */

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
# For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# Tenants should have control on administrative access to all their resources running. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.
# Virtual Private Cloud (VPC): It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].

==Related Incidence==

#'''Wordpress Outage June 2010'''
WordPress that houses high profile blogging sites (such as CNN, Techcrunch), 3 data centers (1300 servers , 10 million blogs) had an outage due to config changes done by programmer (to a database field). It impacted a large set of tenants on this multitenant blogging service [7,8,9].

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-29T19:50:32Z

Vinaykbansal: /* Countermeasures */

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
# For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# Tenants should have control on administrative access to all their resources running. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.
# Virtual Private Cloud (VPC): It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].

==Related Incidence==

#'''Wordpress Outage June 2010'''
WordPress that houses high profile blogging sites (such as CNN, Techcrunch), 3 data centers (1300 servers , 10 million blogs) had an outage due to config changes done by programmer (to a database field). It impacted a large set of tenants on this multitenant blogging service.

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-29T19:48:11Z

Vinaykbansal: /* Reference: */

==R7: Multi Tenancy and Physical Security ==

Multi-tenancy in cloud means sharing of resources and services among multiple consumers and clients (tenants). It means physical resources (such as computing, networking, storage) and services are shared, also the administrative functionality and support may also be shared. One of the big driver for providers is to reduce cost by sharing and reusing resources among tenants.

In a multi-tenant environment a lot more security dependence on the logical segregation (at multiple layers) rather than the physical separation of resources. Some of the cloud providers due to mult-tenancy may not allow audit and assessment by a particular tenant within their shared infrastructure.

==Security Risks==

# '''Inadequate Logical Security Controls''': Physical resources (CPU, networking, storage/databases, application stack) are shared between multiple tenants. That means dependence on logical segregation and other controls to ensure that one tenant deliberately or inadvertently can not interfere with the security ( confidentiality, integrity, availability) of the other tenants.
# '''Malicious or Ignorant Tenants''': If the provider has weaker logical controls between tenants, a malicious or an ignorant tenant may reduce the security posture of other tenants.
# '''Shared Services can become single point of failure''': If the provider has not architected well the common services, they can easily become single point of failure due to misuse or abuse by a tenant.
# '''Uncoordinated Change Controls and Mis configurations''': When multiple tenants are sharing the underlying infrastructure all changes needs to be well coordinated and tested .
# '''Co-mingled Tenant Data''' : To reduce cost providers may be storing the data from multiple tenants in same database table-spaces and backup tapes. Data destruction can become a challenge in multi-tenancy especially if data is stored in the shared media (databases, backups, archives).
# '''XaaS Specific Risks'''
## '''SaaS''': Multiple clients (tenants) may be sharing the same application stack ( database, app/web servers, networking). That means the data from multiple tenants may get stored in the same database, may get backed up and archived together, may be moving on common networking devices (unencrypted), and managed by common application processes. This puts a heavy emphasis on logical security built within the application to separate one tenant's users from others.
## '''PaaS''': Platform stack is shared among the tenants. Vulnerability in the platform stack can allow bleeding between tenants. Shared data backups and archives.
## '''IaaS''': Cross Virtual machine attacks. Cross network traffic listening. Co-residents with lower security posture, where they are less concerned about keeping their hosts hardened and patched [5]. Especially when these hosts gets compromised and owned by the attackers.

==Countermeasures==

# Tenants can always negotiate or demand from the cloud provider to have their own separate physical infrastructure, databases, storage, networking gears,.. . Isolation does play a great role in the security field. However, it does increase the cost for tenants/clients.
# For encrypting the data and keeping it separate from other tenants , strong encryption complemented by tenant-owned key management is required. In a virtualized environment, this means that encryption can be done granularly on a per-VM basis, with key management owned by the tenant and not the service provider [1].
# Tenants should have control on administrative access to all their resources running. One of the way is to have audit-ability of admin access enabled at all the layers of stack (OS, networking, applications , databases) that can be auditable by the tenants. Provider may still be doing the administration but under strong auditable environment.
# Virtual Private Cloud (VPC): It is a private cloud existing within a shared or public cloud. A VPC is a way to partition a public cloud (multi-tenancy) into quarantined virtual infrastructure [3] and link it back to the tenants internal resources by encrypted network links.
# Alternate assessment options or contractual exceptions if the auditing is required as per the consumer's security posture but provider does not allow it [6].

==Reference:==

# http://chucksblog.emc.com/chucks_blog/2010/01/thoughts-on-secure-multitenancy.html
# http://aws.amazon.com/vpc/
# http://www.elasticvapor.com/2008/05/virtual-private-cloud-vpc.html
# http://blogs.gartner.com/thomas_bittman/2009/01/08/virtual-cloud-privacy-is-gray/
# http://people.csail.mit.edu/tromer/papers/cloudsec.pdf
# http://www.cloudsecurityalliance.org/csaguide.pdf
# http://smoothspan.wordpress.com/2010/06/11/wordpress-and-the-dark-side-of-multitenancy/
# http://techcrunch.com/2010/06/10/wordpress-gives-us-the-vip-treatment-goes-down-on-us-again/
# http://hakre.wordpress.com/2010/06/14/wordpress-outage-feedback/
# http://en.blog.wordpress.com/2010/06/14/downtime/
# http://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/
# http://salesforcechannel.com/video/Multitenant-Magic-Under-the-Cov
# http://natishalom.typepad.com/nati_shaloms_blog/2010/03/multitenancy-does-it-have-to-be-that-hard.html

[[Category:OWASP Cloud ‐ 10 Project]]

__NOTOC__
<headertabs/>

Cloud-10 Multi Tenancy and Physical Security

2010-08-29T19:47:09Z

Vinaykbansal: /* Security Risks */

Cloud-10 Multi Tenancy and Physical Security

2010-08-29T19:42:01Z

Vinaykbansal: /* Security Risks */