Grab the Secure Mobile Application Development Reference here - http://www.denimgroup.com/know_artic_secure_mobile_application_development_reference.html Are you looking to build a program to ensure maximum mobile security coverage? If you are tasked with putting together a security testing program to address risk with internally developed mobile applications, there is no shortage of technical and process factors to consider. It is also critical to balance the security with a positive end-user experience, helping propel the overall brand forward - safely. Without proper mobile security, one significant loss can quickly destroy the trust foundation your company has worked years to craft. This webinar will provide the security leader an overview of the challenges associated with mobile testing, certain technologies that one can use to identify mobile application vulnerabilities, and repeatable process strategies that will help build the foundation for a recurring testing program. The session will provide attendees a broad understanding of mobile technologies, as well as a mobile testing launch checklist that will help your organization go from ground floor to a fully-functioning testing program in 30 days. The session will also include: An overview of the major mobile technologies and their defining attributes An overview of how iOS and Android handle certain security issues differently via the Denim Group Mobile Development Reference Guide An overview of a typical mobile application architecture and how it differs from a web application environment How important web services are to a typical mobile architecture The limitations of automated testing and how to augment security reviews to overcome testing gaps How to make a program repeatable and economically feasible without disrupting the software development process

1. Building a Mobile Security Program
John B. Dickson, CISSP
@johnbdickson

2. John’s Background
• Application Security Enthusiast
• Helps CSO’s and CISO’s with
Application Security Programs
• ISSA Distinguished Fellow
• Security Author and Speaker

3. Denim Group | Company Background
• Professional services firm that builds & secures
enterprise applications
• External application & network assessments
• Web, mobile, and cloud
• Software development lifecycle development (SDLC) consulting
• Secure development services:
• Secure .NET and Java application development & remediation
• Classroom secure developer training for PCI compliance
• Developed ThreadFix

4. Overview
• Overview of the major mobile technologies
• Overview of a typical mobile application architecture
• How iOS and Android handle certain security issues
• Web services and mobile architectures
• Automated testing and coverage gaps
• A repeatable and economical mobile testing program
• Questions and Answers

5. True Software Attack Surface is Often Unknown
Why do these usually merit consideration?
• Substantial monetary or brand value flows
through them
• Compliance requirements
(e.g., PCI, HIPAA, FFIEC, etc.)
• Formal SLAs with customers
• You’ve had one or more previous security
incidents (or near misses)
What’s normally in this category?
• Critical legacy systems
• Notable web applications
Don’t forget mobile and cloud
To assess application security, many organizations focus on obvious
software resources, but overlook their overall inventory of applications
and code from less obvious sources when they analyze their assets.

6. OVERVIEW OF MAJOR MOBILE
TECHNOLOGIES
Building a Mobile Security Program

7. The Distinguishing Features of Mobile
• Smartphone applications are essentially thick-client applications
• That people carry in their pockets
• And drop in toilets
• And put on eBay when the new iPhone comes out
• And leave on airplanes
• And so on…
• What else should you assume they know or will find out?
• Attackers will be able to access:
• Target user (victim) devices
• Your application binaries

8. Specific Platforms
• iOS (iPhone, iPad)
• Tightly controlled ecosystem
• Android
• Different platform implementations
• Blackberry
• Windows Mobile
• Others (?)
• HTML 5
8

9. How are iOS & Android Different
• iOS
• Objective-C and compiled to ARM machine code.
• All developers can run applications in a local emulator
• For actual production application installation the applications must be
downloaded from Apple's iTunes Store.
• Android
• Android applications are written in Java and the Java source code is
compiled to Dalvik Executable (DEX) binaries
• DEX binaries that are run on the Dalvik virtual machine.
• Developers can run applications in a local emulator and install applications
on the device and debug them via a USB connection
• Production applications can either be loaded onto Android phones via a
USB connection or device SD card and can be downloaded from Google's
Application Store

10. What Does this Mean for Security?
• IMPORTANT: It is really the system as a whole you care
about
• Application plus…
• 3rd party web services
• Enterprise services
• How can attackers gain unauthorized access?
• Attacker steals or accesses a lost device
• Malicious application
• Attacker reverse engineers an application to access corporate
resources
• The most “interesting” weaknesses and vulnerabilities we find
are in mobile applications’ interactions with supporting services

11. OWASP Mobile Security Project Top 10 Mobile Risks
1. Insecure or unnecessary client-side data storage
2. Lack of data protection in transit
3. Personal data leakage
4. Failure to protect resources with strong authentication
5. Failure to implement least privilege authorization policy
6. Client-side injection
7. Client-side DoS
8. Malicious third-party code
9. Client-side buffer overflow
10. Failure to apply server-side controls
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks

12. HOW IOS AND ANDROID HANDLE
CERTAIN SECURITY ISSUES
Building a Mobile Security Program

13. How Does iOS and Android Handle Security?
• Denim Group Secure Mobile Application Development Reference
• Overview of Application Development
• Overview of Secure Development
• Defeating Platform Environment Restrictions
• Installing Applications
• Application Permissions Model
• Local Storage
• Encryption APIs
• Network Communications
• Protecting Network Communications
• Application Licensing and Payments
• Mobile Browser
• Native Code Execution
• Browser URL Handling
• Mobile Application SMS/Push Update Handling

14. Local Storage
iOS
• Applications are given access to their
own portion of the iOS file system that
is within the application sandbox and
inaccessible to other applications
• Files can be designated for Sharing
and such files are accessible in the
Documents/ directory in iTunes
• Files can also be marked as Protected
so that they can only be accessed
when the device is unlocked
• Property List (plist) files can be used to
store user preferences and other
configuration information in a way that
can be moved between OS X and iOS
applications.
Android
• Android applications have a variety of
local storage options
• Can hold files in internal storage protected by
the default Android/Linux permissions model
that segregates access to application files via
Linux file/group permissions
• Files may also be stored externally on an SD
card that will not be covered by those
protections.
• Unless there are special circumstances,
files should be created with
Context.MODE_PRIVATE or
Context.MODE_APPEND
• Files that are created using the
Context.MODE_WORLD_READABLE can
be read by other applications and should
not be used to store data that a malicious
application could access.

15. Encryption APIs
iOS
• iOS provides access to a variety of
certificate and key management
functions so that applications can
access various encryption capabilities.
• iOS provides applications access to
the Keychain service that allows the
application to securely store local data
such as passwords and encryption
keys
• Applications can access their Keychain
items but other applications are not
allowed access
Android
Android provides access to industry-standard
encryption APIs via the javax.crypto libraries.
Also, some organizations have chosen to use
the Bouncy Castle Java libraries with
success.
• Android javax.crypto Javadocs
• Main Bouncy Castle site

16. OVERVIEW OF A TYPICAL MOBILE
ARCHITECTURE
Building a Mobile Security Program

17. Generic Mobile Application Threat Model
17

18. Typical Mobile Threats
• Spoofing: Users to the Mobile Application
• Spoofing: Web Services to Mobile Application
• Tampering: Mobile Application
• Tampering: Device Data Stores
• Disclosure: Device Data Stores or Residual Data
• Disclosure: Mobile Application to Web Service
• Denial of Service: Mobile Application
• Elevation of Privilege: Mobile Application or Web Services
User
Local App
Storage
Mobile
Application
Mobile Web
Services
Device
Keychain
Main Site Pages

19. WEB SERVICES AND MOBILE
ARCHITECTURES
Building a Mobile Security Program

20. Web Services and Mobile Security
• 3rd Party Web Services
• Is data being treated as untrusted?
• Google promised to “not be evil”
• For everyone else…
• Enterprise Web Services
• Did you know these were deployed?
• Have these been tested for possible security flaws?
• Stealing records en-masse is preferable to stealing them one-
at-a-time
20

21. A REPEATABLE AND ECONOMICAL
MOBILE TESTING PROGRAM
Building a Mobile Security Program

22. Mobile Attack Scenarios
• Borrowed Device
• Stolen Device
• Malicious Application Functionality
• Other Malicious Application
• Attacks from Mobile Web Services
• Attacks against Mobile Web Services
• Attacks from Local Network
• Abuse of Device Feature

23. Approaches for Identifying Threats
• Use Cases for Business
• Useful for identifying flaws with specific application features
• Data Flow for Architecture
• What threats can we identify looking at the application’s data flow?
• The whole system’s data stores, services, processes, etc.
• The interaction among those components
• Functional Security
• Here are the security features. How could an attacker defeat them?
• Attacker’s Goals for Threat Trees
• If you are an attacker, what would you want to accomplish?
• How would you go about achieving the malicious goal?
• Useful for identifying any erroneous security assumptions
• No one approach is perfect – these are essentially brain storming
techniques

24. Assessment Activities
Type of Analysis Activities
Static Analysis
Source Code Source code scanning
Manual source code review
Binary Reverse engineering
Dynamic Analysis Debugger execution
Traffic capture via proxy
Analyze remote services
Forensic Analysis File permission analysis
File content analysis

25. The General Assessment Approach
• Identification
• Help identify what applications have highest priority to assess
• Preparation
• Obtain requisite code and/or access
• Baseline Review and Testing
• Account for risks inherent to the technology and common features
• Commercial scanning tools with manual auditing
• Targeted Testing
• Account for identified threats, data flow, abuse cases
• Follow up with suspect behavior in the baseline review and testing
• Reporting
• Rate vulnerabilities
• Provide remediation recommendations

26. Static Analysis
• Source Code Scanning
• Manual Code Reviews
• Advantages
• Identifies flaws during integration, when it is easier to address issues
• Developers can identify flaws in their own code before checking it in
• Many projects already have a code review process in-place
• Disadvantages
• Freeware tools do not address security well
• Licensed tools are a significant investment
• Manual review can be unstructured and time-consuming without
licensed tools
• Not ideal for discovering logical vulnerabilities

27. Dynamic Analysis
• Integrate abuse cases into unit and automated testing
• Use application scanning tools
• Perform a dedicated penetration test by security staff or a
3rd party
• Advantages
• Generally more time-efficient than manual code review
• Good for discovering logical vulnerabilities
• Disadvantages
• Requires fully functional features to test
• Security staff may not have application security training or
experience
• Scanning tools may have difficulty with unusual applications

28. Dynamic Analysis Tools
• Automated Tools
• IBM Rational AppScan
• SPI WebInspect
• Acunetix Vulnerability Scanner
• Netsparker
• Manual Testing
• Zed Attack Proxy
• Burp
• Google RatProxy
• Browser plugins
• Testing Scripts – Qasl, Watir
• Load and Performance testing tools – Jmeter, Grinder

29. Key Thoughts
• Automated Testing Alone Does Not Solve the Problem
• Know where to Augment Automated Testing
• Assume Binaries can be Reverse Engineered/Rooted
• Context-driven Testing is Imperative!
• Don’t Reinvent the Testing Wheel
• Leverage source by looking at “diffs”
• Minimize Testing Overhead
• Optimize your Testing Tempo

30. AUTOMATED TESTING AND COVERAGE
GAPS
Building a Mobile Security Program

31. Tools vs. Manual Review
• As we have discussed, some tests are better done
manually
• Automated tools are well suited to discover
implementation flaws
• Cross-site scripting
• Injection
• Information leakage or improper error handling
• Transport layer security
• Manual testing is a better approach to discover design
flaws
• Direct object references
• Malicious file execution
• Cross-site request forgery
• Authentication/Authorization

32. The Scope of Mobile Security Review

33. So Where Do You Go From Here?

34. So What Should Security People Do?
• Find out about smartphone projects
• Not always done by your usual development teams
• R&D, “Office of the CTO,” Marketing
• Assess the security implications of smartphone
applications
• What data is stored on the device?
• What services are you consuming?
• Are new enterprise services being deployed to support the
application?
• Gauge organization appetite for mobile risk
• Tailor testing program to address perceived risk
• Continually optimize
34

35. Questions and Answers
John B. Dickson, CISSP
@johnbdickson