Assessing the Security of Mobile Applications (Part 3) – The Test Methods and Outcomes

If you would like to be notified when Ricky & Monique Magalhaes release the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update.

If you would like to read the other parts in this article series please go to:

This is the third extract of this article series. In the previous articles we have moved through the assessing of mobile applications using a methodical approach. In article one of the series we looked at the early planning phase followed by the initial steps for the application testing process.

Moving forward we now deliberate a more in-depth look into the various mobile application test methods that could be utilised for app testing and finally consider the thought process behind choosing to approve or reject the application founded on the knowledge learned through the app vetting process.

Introduction

Mobile device and mobile app use within enterprise has clearly advanced production however the potential security risk presented through mobile applications within enterprise is also evident and should not be ignored, thus the need for a stringent app vetting framework.

The purpose of this article series is to assist organisations with the procedures involved with vetting of potential applications or those already running on mobile devices to ultimately improve security when mobile computing is utilised for corporate function, which is now commonplace within enterprises.

Test methods utilised for vetting of mobile applications should be used to effectively manipulate the application so that any potential vulnerability can be uncovered and informed decisions can be made by the organisation as to whether the risk level is acceptable or not and ultimately whether the app should be approved or rejected.

Test Methods

A varied set of test methods can be used for application vetting. Through this app testing/app manipulation process organisations will establish whether the application in question does or does not support the organisations security requirements (covered in part two).

Once tested auditors will assess the outcomes and decide, based on the organisations unique business function and security requirements and risk acceptance levels, whether the app should be approved or rejected.

All layers should be covered when testing is undertaken, from the client layer, code and user interface through to the server layer, as all areas could potentially harbour security vulnerabilities.

Testing methods are adapting to meet the testing of mobile applications. Methods used for some time, like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), have been adapted for mobile application testing purposes. Behavioural testing, analysis of a running application, for mobile applications is also now routinely used and can uncover valuable information.

A multiple set of test tools will be necessary for a more thorough and comprehensive testing process. One tool type may be superior at ascertaining a particular requirement but might be poor at another. Time and consideration should be given to the best tool set suited to your application testing in order to achieve the most successful level of testing possible.

Test methods could include:

  • Correctness testing
  • Source or binary code analysis
  • Static or dynamic analysis
  • Manual testing
  • Automated testing

Test Method

Functionality

When to choose this test method

Advantages/Disadvantages of method

Software correctness testing

Execute a program with intent to find errors

To approve the quality of the application

To evaluate the dependability of the   application

To confirm the applications depicted   functionality

To uncover security vulnerabilities (usually specific to the particular application)

This type of testing is usually constructed on the unique specifications of the application to be tested. Improving the testing for vulnerabilities that may be unique to a specific application, rather than a more general testing approach with more generalised results.

Source or binary code analysis

Analyse source code or binary code using various methods and tools.

Manual approach-physically reviewing the code files

Automated approach-using automated static analysis tools

Skills and knowledge of development and domains for application security is extremely important for this type of analysis to be undertaken accurately and successfully

Labour intensive

When the source code is available, to review the source code and find vulnerabilities in the source code.

When application is open source.

Also to confirm analyser results.

A variety of tools can be utilised (manual or automated approach)

Labour intensive

Static analysis

Examines code

Involves app behaviour analysis

Reverse engineering is often required if source code is not available

To contemplate all potential scenarios that may arise when application is running

To analyse behaviour of applications and   look for any exploitable weaknesses

Accurate Assurance is achievable for how the application will behave irrespective of application input or the environment in which it is run

Reverse engineering of code can be complex depending on the code type

Reverse engineering is useful to allow people to review the code

Dynamic analysis

Input analysis

Considers assorted use cases through varied input and analyses application conduct under the differing input scenarios

Use emulator or executing app or both

To see the working of the code as it is   executed

Time consuming due to numerous potential input scenarios

Accuracy is questionable as you can’t guarantee that every scenario has been covered and complete code analysis is unlikely

Utilising both emulators and physical devices reduces the number of false negatives

Manual testing

Test For applications vulnerabilities with human input and analysis

Test For applications vulnerabilities manually

Time consuming

Requires a good knowledge base and skill set and experience

Automated testing

Test for application vulnerabilities

Uses Simulator or remote device access

Tool Types include:

  • Data-driven testing tools
  • User interface-driven testing tools
  • Fuzzing tools
  • Fault injection tools
  • Network testing tools
  • Penetration testing tools

To test for vulnerabilities using a variety of automated tools

Receive a report and risk assessment

Mobile function is well suited to automated testing

Table 1

You’ve done your research, combined a great set of test tool types and undertaken your application testing. After gathering the numerous results, what should the next steps be?

After all the work you’ve undertaken to achieve your results you may feel obliged to keep those results for yourself. However it is highly recommended that sharing of results through a software assurance community database is greatly beneficial. Through doing this security professionals and organisations could benefit from the collective efforts, reducing costs and time. The data collected aids in managing security and vulnerabilities and helps with standardisation and compliance efforts. It can also be monitored regularly to keep on top of changes within app vulnerabilities and assist with prioritisation in the area.

Reporting of the results and risk assessments is a critical area. Results should be reported intuitively and in a way that is easy for the auditor to understand and interpret.

App Approval or Rejection

A procedure should be set up prior to app vetting for the handling of an approved or rejected application. This should form part of the organisations policy procedures for app security. This is necessary so that the steps for the implementation or removal of the app are clearly clarified and can be easily followed after a decision of approval or rejection is made.

An auditor/s (more than one auditor is recommended for a more conclusive result) should decisively consider the results obtained within the assessment report and the level of risk association with utilising the app, in respect to the enterprises function and initially stipulated security requirements to see if these requirements have been supported by the app and then make a recommendation for app approval or rejection. In order for the auditor to put forward a pertinent decision, the auditor must have in depth insight into the enterprise and its function.

The auditor will use and consider the following criteria to come to a decision:

  • Perceived level of risk if the app were to be approved and utilised
  • Consider the apps security posture
  • Consider the organisations risk threshold
  • Consider the organisations vetting requirements and whether they have been supported of not
  • Consider the reports and risk assessment app test outcomes
  • Consider data type that will be processed
  • Consider how critical the app is to the enterprise
  • Consider who will use the app
  • Consider the environment in which the app will be used or located and the type of hardware it will require
  • Consider application documentation and service level agreements

Ultimately it is the organisations decision to finally decide whether to approve or reject the application. The individual or team within the organisation responsible for the final approving or rejecting procedure should take this recommendation into consideration along with the other business criteria related to the potential utilisation of the app (not based on the security of the app).

The procedures for implementing or removing the app depending on if the app is approved or rejected must then be undertaken.

Conclusion

This third article in the series concludes the application testing process.

In-house produced apps or third party built apps developed with capabilities to specifically meet organisations unique requirements are likely to rise. Furthermore this will be fundamental in aiding organisations to realise the greatest productivity benefits from mobile technology use.

Many forms of vulnerabilities transpire in app design and coding. Identifying these weaknesses necessitates first defining the app requirements in the planning stages, so that any nonconformities from these requirements can be easily identified as weaknesses and not be allowed to lower the enterprise security posture through application use.

The benefits of mobile application use in business should not be achieved at the detriment of the enterprise security, therefore proper application vetting must be undertaken to ensure that the security standards within the organisation are sustained and held in high regard.

If you would like to be notified when Ricky & Monique Magalhaes release the next part in this article series please sign up to our WindowSecurity.com Real Time Article Update.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top