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 3) – The Test Methods and Outcomes
Introduction
To support BYOD and to take advantage of the multiple applications available to organisations it’s essential that the applications be properly vetted before installation and use so that any vulnerability can be uncovered and organisations can improve business function with minimal risk. It’s very important that applications are secure and function as intended.
To recap we concluded that the app assessing process should include:
- Planning (covered in article one)
- Testing of applications (covered in this article and the third article of this series)
- Application approval or rejection (to be covered in the third article of this series)
In the first article of this series we looked at planning, the initial steps in the application vetting process.
In this article we will cover testing of applications. As part of the planning process, responsibilities would have been assigned and a team positioned to facilitate the application testing process (this covered in part 1).
The application is then submitted to the responsible individual/team and put through a set of analysis procedures either undertaken manually, by tools and services (automated) or a combination of all three.
Processes for testing should be consistent and easily repeatable as well as efficient so that room for error and false negatives and positives are minimised.
Analysis will involve first establishing whether the application will be suited to the testing procedures to be undertaken (pre-processing), followed by testing the app for vulnerabilities using various methods.
All discovered issues and recommendations should be reported and a risk assessment initiated to validate the next steps in the vetting procedure.
The intricacies of application testing
A few things to take into consideration:
- Provision a procedure whereby the security of the app can be assessed
- Be sure the analysis undertaken complies with what is agreed or allowed and stated in the EULA for the application as to avoid violation of the EULA and legal ramifications later on
- Testing should be undertaken after app development but before the app is deployed on the mobile device
- Don’t forget to test the application updates- this is very important
- Use a secure approach when testing (utilise encryption where possible for transfer and storage)
- The strategy should be aligned with your organisations unique security requirements, this should be carefully considered as it is necessary to specify the organisations security requirements to use as a baseline for the vetting process
- Ensure that any previous testing is not taken as final, as one organisation’s security requirement or risk acceptance level may be very different from that of another
- The app testing can be done internally or externally by service, tool or hands-on manual testing or a combination of various techniques
Testing the application
Pre-processing
The delegated team or individual will arrange that the application be forwarded for testing. The application will be sent to the analyser/s, which may be in-house or external to the organisation for analysis.
The initial steps in the testing of the app are for pre-processing whereby the app will be analysed to confirm its suitability to the testing methods, this often involves de-compilation of the app and storage of the app file. This may be cause for concern with regards to the security of the app/files/code, especially if the analyser is not part of the organisation but rather a third party.
Precautionary measures need to be taken to ensure that the apps security and integrity is not compromised during the pre-processing stage. Organisations must ensure that the app compliance with license agreements remains intact during processing and intellectual property protected. Transferring the app via an encrypted channel and ensuring it is stored securely and that appropriate measures are taken to prevent unauthorised access will help safeguard that the security of the app is upheld at all times and throughout the testing procedures.
Testing the app for software weaknesses
Before vulnerabilities can be uncovered a set of security requirements need to be be stipulated for the app. These requirements laid out are used as a baseline to ascertain whether the vulnerability found will violate the requirements or not by testing appropriately with that particular requirement in mind. The requirement signifies a feature or conduct that the app should display to ensure that it’s secure. The requirements are also valuable for when security audits are undertaken.
The recommended security requirements should look as follows:
- Enabling authorised functionality (the app must function as intended)
- Preventing unauthorised functionality (the app should function in a modus that prevents unauthorised functionality)
- Limiting permissions (apps should function with the least required permissions and allow the same (least) to other apps)
- Protecting sensitive data (where applicable, if an app processes data, the privacy, integrity and confidentiality of that data needs to be upheld at all times)
- Securing app code dependencies (ensure code dependencies are used sensibly and not for malicious activity)
- Testing app updates (updates for apps must always be tested as if it were a new app, prior to installation on the mobile device.)
Testing per requirement
The requirements should be tested to achieve an outcome of either violation of the requirement, or the requirement has been met and is satisfactory.
These results will assist in concluding whether the app should be approved or rejected at a later stage depending on the organisations specific requirements and the organisations risk acceptance levels.
|
Requirement being tested |
What to consider with regards to the app |
|
Enabling authorised functionality |
Test the user interface (displays, virtual keyboards, buttons) Test all physical attributes used by the app (cameras, GPS, microphones, communication between devices) Make sure calls and messages are not being utilised for purposes of the app functionality Ensure all these attributes are functioning as intended |
|
Preventing unauthorised functionality |
Look out for intentional malicious functioning violating security (functions that assist fraudulent activity, stealing of information, opening doors for attack) Banner ads are sometimes utilised to deceive users and provision phishing attacks Malware detection is important but not 100% guaranteed effective Ensure that the app doesn’t converse with untrustworthy sites, domains or servers |
|
Limiting permissions |
Ensure that the app does not have excessive permissions but the least permissions required for its intended functioning The more permissions it has the less secure it is and the higher the potential security risk Look out for the following permissions and consider carefully whether any are necessary:
|
|
Protecting sensitive data |
Apps most likely process sensitive data in one form or another, this should only be allowed if the appropriate cryptographic procedures are used to ensure the data remains secure and private Validated cryptography must be used and implemented correctly as well as suitable key management utilised Digital certificates need to always be properly validated Data leakage via various unauthorised network routes needs to be considered (cellular, Wi-Fi, Bluetooth, shared system logs) It’s recommended to study the app logs to distinguish the type of data that is leaked |
|
Securing app code dependencies |
Make sure the app does not use unsafe code. Care should be taken to only depend on code from an external source when really necessary (Consider: external libraries and classes, dynamic behaviour, native calls and apps that communicate with each other) Although these behaviours can prove beneficial they can also pose a great security risk so their functioning should be carefully considered and only allowed if undertaken securely. |
|
Testing app updates |
Updates should always be tested to avoid new vulnerabilities or the introduction of new weaknesses. This should be done before the update is downloaded to the mobile device. Mobile device management within the organisation plays an important part with regards to test updates. Some polices will allow for unprompted updates, when made available, this approach should be avoided whenever possible. Updates should always require pre-authorisation and should not be allowed to be automatic so that vetting of the update can be undertaken prior to installation. |
Table 1
Test Methods
A varied set of test methods can be used for application vetting. Below are a few that we will cover in more detail in the article to follow (Part three)
Test methods could include:
- Correctness testing
- Source or binary code analysis
- Static or dynamic analysis
- Manual testing
- Automated testing
Conclusion
It is critical to test an applications security features and stability to ensure secure mobile computing for both your user base and the organisations. At the high speed that apps are released some security gaps are missed and thus the exposure factor and risk is higher.
A key strategy is to build security into the development lifecycle with rigorous and methodical testing to ensure that the application is properly built. Independent vulnerability assessments and application penetration testing is highly recommended before releasing both internal and external applications.
If you would like to read the other parts in this article series please go to:
