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:
- Assessing the Security of Mobile Applications (Part 1) – Planning
- Assessing the Security of Mobile applications (Part 2) – Testing the application
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:
|
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: