Developing Securely for SmartPhones - A few Key Principles

At AppSecEU last week, I attended Dan Cornell's (Denim Group)  presentation  on Security Testing Mobile Applications. You can view the slide deck on the Denim Group blog.

Basically, Dan demonstrated how you can "root" the smartphone and then reverse engineer the application to do whatever you want. Slide 6 shows a "Generic Mobile Application Threat Model" for a SmartPhone app connecting to an enterprise application.  It shows the following threats:

1. Malicious User
2. Malicious User (bypassing Mobile Client)
3. Malicious Mobile Application
4. 3rd Party Services (Possibly Malicious)

Nr. 2 is where a malicious user bypasses the smartphone completely and attacks the enterprise web services which the smartphone uses.

Nr. 3 is a malicious application which is installed on the smartphone and can interfere with other installed applications.

Nr. 4 is where the smartphone connects to 3rd party services which have been compromised.

Key Principles

So what  are the lessons when developing enterprise type apps for smart phones? Here are a few thoughts. These are based in part on a short conversation I had with Dan after his talk*.

1. Treat the smartphone as an "untrusted device".
2. If possible, don't store confidential information on the phone. 
3. Develop your web services securely, as an attacker may discover the web services and attack them directly - bypassing the smartphone completely.
4. Your web services should validate any input data and perform the necessary authorisation, access control, business logic checks etc.. Any validation performed on the phone should be repeated by the web service
5. Use SSL to prevent man-in-the-middle type attacks.

* These may not be an accurate reflection of Dan's views!

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

My OWASP AppSec Europe 2011 Presentation

I gave my presentation today at OWASP App Sec Europe 2011 today.

Here is a link to the slide deck. 

Note! It's in PDF format.

The talk is aimed at the developerment team. At the start of a development project you should think a bit about security. In the presentation I go down through a simple structured list of security  tasks that you should address in order to gather the security requirements that the project should implement.

                   
                                          

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot

My OWASP AppSec Europe 2011 talk

I'm giving a talk at the OWASP AppSec Europe talk in Trinity College, Dublin, Ireland on Friday June 10th at 11:10. It's part of the Prevent track.

The talk is aimed at developers (or builders as OWASP calls them). At the start of a development project you should think a bit about security. In the presentation I will go down through a simple structured list of security  tasks that you should do in order to gather the security requirements that the project should implement.


If you spend a few hours thinking about security early on, you could save yourself a whole lot of problems later on. A workshop with the relevant people is a suitable format for this. The list of tasks which the presentation outlines can form the basis for this security workshop.  

In fact, you can use the list of tasks as the agenda for the workshop.

A fictitious website which processes personal information (as defined by EU Data Protection Legislation) will be used as an example.

Even QEII likes the list

The list will include the following:

• Data Classification
• Simple Threat Analysis
• Data Flow Diagram
• User LifeCycle/Authentication etc.
• Authorisation
• Segregation of Duties
• Audit Trail
• Data Retention
• Availability/Resilience
• Other Compliance Issues

If you spend a few hours at the start of a project going through this list, you will have a good idea of your security requirements and what you need to do. It is much better than trying to do this at the end.

This is what I will try to get across in this talk. So if you are on the development side of the house and you are interested in a simple approach to specifying your security requirements then do come along to the talk.  It will be an XSS-free zone!


The security list is based on Section 2 of  the SDLC Quick Reference

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot