Applications are the lifeline of most organizations with more and more organizations having become dependent on some of these applications for their continuous growth. Due to growth in Technologies and with the increasing number of smart-phones and PDA users, many of these applications have been moved as an App on these devices. In recent times with the popularity of cloud-based deployments, Software as a Service (SaaS) has become the latest trend.

With the increasing number of businesses now having some amount of applications that are web based, application development and deployment using web technologies is popular. The Businesses need to ensure adequate protection of business critical information within the application from both internal and external users to provide trust and confidence to all its customers and stakeholders. Application Security is gaining the attention of senior executives in most organization. With the increasing popularity of mobile apps and cloud computing services, Application Security has gained even more importance as these same functionalities are now also replicated in these mobile apps that can be easily downloaded by the users including mal-intention users.

This article is specifically targeted for business applications and application security of these type of applications. Though there are many tools including freeware that can easily provide you the application vulnerabilities (especially for web applications), this article is focusing on manual (non-tool based) application security assessment for any kind of business applications and how to make the best out of your efforts.

Key challenges and scenarios where manual application security assessment is useful:

  • Organization prohibits tools in the production environment. The organization may have a policy prohibiting usage of hacking and penetration tools in the production environment or sometimes may not be comfortable with accidental changes that may be caused by the tools to their production environment.
  • Application is a legacy or non web-based application. Most of the automated application security scanning and assessment tools are specifically for web based applications. However, when you are faced with a legacy application or non-web based applications, manual security assessment techniques are the best.
  • You are tasked with finding business logic faults. Automated tools especially application security assessment tools will not help in locating errors in business logic. For example, PCI DSS mandates that your sensitive personal identifiable card data like credit card number, etc. should not be visible in plain text to certain application users. Now whether this information is encrypted or masked may not be easy to validate by automated tools. Similarly fault in applications due to logical errors that may lead to frauds is best located with manual approach.

.

What are the limitations of Manual Application Security Assessment?

  • Manual approach will be very tedious and a costly affair if the applications run into large numbers of pages, screens, forms and menu options.
  • Manual application security assessment approach is very much dependent on the skill of the person performing the assessment. Unlike tools where the attack patterns or signatures can be pre-configured and located automatically by the tools, manual techniques really involve understanding and locating the vulnerabilities in the application.
  • There can be a risk that some application security issues may not be detected due to human error or lack of time.

.

How to get the maximum out of manual application security assessment?

There is no limit on the number of tests that can be performed on the application; however, these are some of the most useful techniques:

  1. Spend quality time in understanding the business critical information processed by the application.

No matter how many technical vulnerabilities and issues you may observe and report in an application, these will not make much sense to business users if it is not demonstrated with what critical business information is really at risk. By our practical experience, spending quality time in this activity helps in a long way for better security assessment. Interviewing business users and using data flow diagrams, help in identifying the most likely scenarios where the confidentiality, integrity and availability of such information may be a major issue. Equally important is to understand weather the applications in question receive any information from other applications or as input from some flat file or other mechanisms.

  1. Look for user manuals and other documentation related to the application.

User manual would explain how the application can be used from an end user perspective. If it were a complex application, you might be lucky if you find a system administration manual. If the application has been developed in-house, you should request for various documents created during the complete software development life-cycle. The key thing to note is that when you are quickly reviewing these documents, you are looking for useful information that can help you to broadly understand the application security design or architectural components.

  1. Check if there is a test setup for the application under assessment

Though you are not going to actually assess the test setup, but I found this very useful in my manual security assessment where tools are not available for the application security assessment due to the legacy application or the application being non- web based application. By nature, since it is a test setup, you can risk to enter garbage and perform your negative tests to your heart content. Where you think, you still need to familiarize more with the application, you can always request help from business users for a quick walk-through of the application. In one of our assessment, we found an authentication bypass scenario where a normal user was provided with a screen option to upload a file available only to privileged user. The client development team was not convinced that it was possible to upload files for normal users as it is programmed only for privileged users. However, when we successfully demonstrated the same in test setup, the development team took it seriously.

  1. Integrate risk-based approach into your manual application security assessment.

We found risk based approach very useful and very rewarding in all our manual application security assessment projects. In a risk-based approach you identify the risks to the application in terms of threats, vulnerabilities and corresponding probability and impact and the resultant high risk areas are first evaluated with more focus. For example, if it is an application driven heavily with regulatory requirements, then violating any regulatory requirements is a high risk area. Similarly, if the application is processing any personally identifiable information or sensitive information, then all those modules within the application that manage the input, processing, storage and output pertaining to this information are areas of high risk and evaluated first.

In one of our security evaluation of an in-house application used for processing debit cards and ATM cards data, using the risk based approach, we were able to identify critical points within the application where the confidentiality of data was lost and we performed targeted tests on the application to demonstrated how the confidential information is available to other non-authorized users within a very short time.

  1. Have a basic application security assessment checklist and customize it to specific application.

It is good to have a basic checklist that you would like to test for each application and based on your study of the specific application, you can further customize it. If it is Web based application, then there are very excellent guides already available on the OWASP website that can be used for performing the tests and that can be integrated with the basic checklist. If it is something that is non-web based application, then you can start with something basic checklist as below and further customize it.

  Input and Output Validation
Num. Description Yes/ No/NA Observations
1 Is input validation done whenever data is received by a function through parameters?    
2 Does input validation accept the various input based on data type, format and maximum/minimum length?    
3 Does the application apply client side and server side input validation?    
4 Does the application validate for SQL injection and other input validation attacks?    
5 Are all output visible based on user role as defined in the application?    
  Authentication and Authorization
1 The user roles and the user accounts being used by the application has been configured for least-privileged access?    
2 Does the application restrict the number of failed logon attempts?    
3 Is there a strong password policy and/or authentication mechanism built-into the application?    
4 Are authentication related tokens such as cookies transmitted over secure connection?    
5 Is the authentication information encrypted?    
6 Is there hard-coded authentication information anywhere within the application?    
Secure Storage
1 What are the cryptographic algorithms used by the application for encryption and hashing requirements? Are these strong?    
2 Are sensitive data encrypted or masked for protection?    
3 Are temporary copies of sensitive data protected against unauthorized access and programmatically removed when it is no longer needed?    
Secure Communication
1 Does the application use cryptographic modules which enforce the use of secure algorithms?    
2 Does the application identify protection mechanisms for sensitive data that is sent over the network(internal and external)?    
3 Is SSLv3/TLSv1/SSHv2 (or similar) used to protect cookies and sensitive data such as usernames and passwords, credit card data etc. whilst it is in transit?    
Error Handling
1 Is there a proper standard approach to structured exception handling across the application?    
2 Does the application identify the level of auditing and logging necessary for the application and identify the key parameters to be logged and audited?    
3 Ensure resources are released if an error occurs.    
Session Management
1 Does the application issue a new session ID when a user is required to re-authenticate on screens involving sensitive actions?    
2 Do session values automatically expire after an agreed amount of idle time?    
3 Determine the actions the application takes if an invalid session ID occurs.    
4 Determine how the log-out functionality functions or how the user sessions are terminated.    
         

.

Organizations must factor the business critical applications and the threat landscape for adequate application security. Organizations performing the application security assessment internally, can integrate security practices very early on in the software development life cycle. Some of the applications are sometimes written in new technologies for which the automated tools may not be easily available. Using risk based approach and by following basic fundamental principles for manual application security assessment as outlined above, one can devise effective security assessment techniques for any applications. The results are always positive because a tool based approach alone, cannot report major application security risks as there are many scenarios where one has to count on the results of manual application security assessment.

.

[email protected]

.

References:

  1. https://www.owasp.org/index.php/Category:OWASP_Guide_Project
  2. Hacking Exposed: Web Applications 3, by Joel Scambray, Vinvent Liu, Caleb Sima, published by McGraw-Hill Osborne Media, ISBN
  3. http://www.isaca.org/Journal/archives/2004/Volume-4/Pages/Systems-Development-Advice-in-a-Web-enabled-World.aspx
  4. http://www.softwaretestingclass.com/what-is-risk-based-testing-in-software-testing/
  5. http://www.nist.gov/customcf/get_pdf.cfm?pub_id=890097