In 
Most IT heads and CISOs are challenged by the fact that application security (AppSec) assessment tools fail to bail out the application-based risks. The CXO and other groups in the organisation have set expectations regarding the performance of these tools; they are often considered the ultimate tools that offer respite from risks. However, there are certain inadequacies found in the App- Sec assessment process and formats within the organisation which cannot be ignored. It is not only the IT and information security teams that need to take cognisance of this short supply in the security process, but the business groups also need to take into account, the critical aspects of the process which result in risks.
Expectations around security
Typically, organisations perform web application (WebApp) security assessments of the newer applications before going live or conduct periodic assessments of their existing applications. These assessments are known by all sorts of aliases such as application penetration testing, ethical application hacking, etc. Companies that lack the internal core competency of AppSec often outsource this activity to competent third-party players in the market. However, from a business head or a CEO standpoint, AppSec is often treated as an additional or ancillary investment to the core development expenditure. Once the assessment is made, the CXOs expect air-tight security within the application thereafter. For instance, the development teams start expecting miracles to occur considering that the applications are completely safe, being incapable of being hacked, even if it goes on the public cloud.
Why the insecurity?
The obvious concern for all CISOs is why AppSec-tested applications are not secure. In most cases applications undergo assessments when they are either almost ready for production or already in production. This is against the spirit of AppSec to begin with, as AppSec as a process should ideally be invoked right at the inception of the applications SDLC (Software Development Life Cycle). Very rarely are AppSec resources involved during the requirement analysis or during the finalisation of the design. Flaws and vulnerabilities that could have been killed right at the beginning; are most often patched in (with quick hacks and not actual App- Sec best practices) after the application is already in production.
AppSec professionals are often expected to perform miracles and mitigate flaws that are connected with the lifelines of the application. While business pressure will always compel the teams to have applications up and running; it is never easy for any CISO to let such applications fly without the proper checks and balances.
Remedy to secure
Here are a few crucial factors that every CISO needs to consider before signing off applications and eliminating the blind reliance on AppSec assessments. Although AppSec assessments are vital, they can never address the people, processes and technology completely.
- Lack of STP (Straight-Through-Processing) and Manual Hand-offs: AppSec can never be held responsible for processes that are offline or that are performed manually. While AppSec testers can test for data validation; they can never do so for business rules. It is common practice in several organisations to have online workflows that detach themselves into (smaller or multiple) manual tasks. These could include physical verification / inspection, offline approvals or matching records with another system. Whenever there is manual hand-off; the application has to rely on the validation of the incoming data.
- Intentional disruption of maker-checker mechanism: One of the most observed corporate practices is the dissolution of the maker-checker mechanism in the name of ease of use and time-saving. While such business rules may save time, it is not an ideal practice to adopt. A typical request- approval workflow works on the basis of the requestor (the maker) posting a request and some approver (checker) taking a decision to approve, reject or hold the request. This workflow is generally disrupted by adding functionalities like the checker being able to modify the request or the checker being able to delete the request. AppSec can only detect flaws (if any) in the transfer of control from the maker to the checker.
- Password management: Auditing for password management is always a tricky situation for AppSec professionals. While AppSec can always verify password strength, secure password storage and transmission. AppSec cannot dictate terms on the hardcoding of passwords into application frameworks. The most commonly found password management lacunae are hard-coding passwords into macros and stored procedures and using a uniform password across the application framework.
- Excessive super-user privilege abuse: Singular administrative user credentials being used by an entire team for local and remote administration such as running backup scripts, routine batch jobs or updating and patching, is one of AppSecs worst enemies. While AppSec assessments revolve around the application components residing on the infrastructure; having multiple super-user identities or sharing credentials of administrative users completely defeats the purpose of implementing AppSec controls.
- Unauthorised migration of environments: Developers often start development on a sandbox environment (colloquially known as the Dev environment). As soon as they start progressing on their (software) builds / releases; they often do not port the changes into the UAT (User Acceptance Testing) or QA (Quality Assurance) environments. This is a very common blunder made by many development teams under the pretext of meeting stringent timelines and lack of migration strategy. Before actually starting the AppSec assessment; internal teams must ensure that a clone environment, along with the production, is ready at hand. This decreases the chances of the application becoming unavailable due to unforeseen effects of the assessment. Sometimes the AppSec testers run intrusive checks which have the potential to bring down essential services within the application.
- Excessive dependency of automated scanning tools and services: Most organisations looking to build-up their internal competency towards AppSec, often procure some sort of automated scanning tool or a service. These services are also offered as a pay-as- you-use, on-demand cloud service. One of the key aspects here is that these tools or services are completely black-box. These tools do not have the ability to understand business rules and workflows to detect and interpret logical vulnerabilities; they cannot perform deep crawling in sophisticated applications that do not give all the links. They do not support JavaScript nor detect Flash-based vulnerabilities. Most often, vulnerabilities reported by these tools are false-positives (and worse, sometimes false-negatives too). A great amount of human effort is required to fine-tune these scanners as automated scanning can never replace AppSec professionals.
Dhananjay C Rokde is Global Head of Information Security, Cox & Kings.
Add new comment