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

Number: IRCAR201509275

Date: 2015-09-29

 

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).

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.

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 

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 generalized 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

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)

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

Table 1

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.

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.

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.

Resource:

http://www.windowsecurity.com/


نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 20 مهر 1394

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها:0