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:
|
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:
مشخصات خبر
 |
|
| تاریخ ایجاد: | 20 مهر 1394 |
نظرات