It is very typical of organizations to perform Web Application (WebApp) Security Assessments not only before their new applications go-livebut also to conduct periodic assessments of their existing applications. These assessments are known by all sorts of aliases like Application Penetration Testing (App PenTest), Ethical Application Hacking etc. For those companies that lack the internal core competency of AppSec, they often resort to outsourcing this activity to competent 3rd party players in the market.
The CXO function’s expectations post the AppSec assessment is often treated as an additional or ancillary investment to the core development expenditure. The CxO function expects air-tight security within the application after such an assessment. Once the development teams start mitigating actions; one can often hear statements filled with hyper-expectations like ‘the application should now become un-hackable’ or ‘no one break the application now & it can go public’.
Despite these assessments, AppSec tested applications are still not secure. This is due to the fact that in most of the 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 is a process that 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 the finalization of the design. And therefore the assessment that happens (post development) is more of a corrective activity rather than a proactive one. Flaws and vulnerabilities that could have been killed right at the beginning; are most often patched (with quick hacks & not actual AppSec best practices) after the application is already in production.
AppSec professionals are often expected to perform miracles & mitigate flaws that are often connected with the lifelines of the application. While business pressure will always compel the teams to have applications up & running; it is never an easy situation for any CISO to let such applications fly without the proper checks and balances. Here are a few crucial factors that every CISO needs to consider before signing-off applications & eliminating the blind reliance on AppSec assessments. Although AppSec assessments are vital they can never address the people, processes & technology completely.
Lack of STP (Straight-Through-Processing) & Manual Hand-offs
AppSec can never be held responsible processes that are offline or that are performed manually. While AppSec testers can test for data validation; they can never test for business rules. It is a common practice in several organizations, 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. This data can never be tested AppSec resources. This is simply because Applications only control the use of resources granted to them, and not which resources are granted to them.
Intentional disruption of maker-checker mechanism
One of the most observed practice with corporate is the dissolution of the maker-checker mechanism in the name of ease of use & time-saving. While such business rules may save some time; this is definitely the worst practice to adopt. A typical request-approval workflow works on the basis of the requestor (the maker) posting a request & 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’. In such a scenario no there is no validation or approval on the action taken by the checker & the very essence of the maker-checker mechanism is lost. AppSec can only detect flaws (if any) in the transfer of control from the maker to the checker; But it can never challenge the business rules or the excess privileges assigned to the checker.
Auditing for password management is always a tricky situation for AppSec professionals. While AppSec can always verify password strength, secure password storage & transmission. AppSec not dictate terms on the hard-coding of passwords into application frameworks. The most commonly found password management lacunae are Hard-coding passwords into macros and stored procedures & using a uniform password across the application framework. Because these passwords are hard-coded & difficult to change application development & infrastructure teams often seeks exceptions to ‘never change the passwords of the target systems or databases’.
Besides this; AppSec can also not address the problem of password sharing among the application development teams.
Excessive Super-User privilege abuse
Singular administrative user credentials being used by an entire team for local / remote administration like running backup scripts, routine batch jobs or updating and patching, is one the worst enemies of AppSec. 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.
Allowing too many user identities to directly access the application backend, makes access auditing very complicated & this also makes change and incident control very challenging. Questions like ‘who did what & when?’ become very difficult to answer. It is therefore extremely essential to audit & restrict unnecessary access on the infrastructure that hosts the application.
Unauthorized migration of environments
Developers often start development on a sandbox environment (colloquially known as the ‘Dev’ environment). As soon 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. This causes same build / release to mature on the ‘Dev’ environment itself & the same environment eventually lands up in ‘production mode’.
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.
Besides this, a clone QA or UAT environment helps to expedite the vulnerability mitigation process, without any negative business impact.
Excessive dependency of automated scanning tools & services
Most organizations 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 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:
1. Understand business rules & workflows.
2. Detect & Interpret ‘logical’ vulnerabilities.
3. Can perform ‘deep crawling’ in sophisticated applications that do not give all the links.
Most often several of the 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. Automated scanning can never replace human AppSec professionals; these tools only help to facilitate the assessment.
Based purely on my personal experience, after I saw some interesting results, post some internal NetSec assessments, I can confidently state that NetSec (Network Security) assessment if often better at annihilating WebApps.
The approach of NetSec professionals is very different from the AppSec folks. NetSec pros concentrate on the attack-surface (server infrastructure & communication equipment) rather than getting into the application itself. AppSec & NetSec, both are hot skills in the market and good resources are very hard to find. This is in no way comparison of intellect or level of difficulty of either of the disciplines.
This point can be illustrated with a scenario – – – When an AppSec tester is able to manually verify a privilege escalation, he/she would generally note down the affected module (piece of the application) & rank this risk based on the data that became visible, as a result of running the test. However; this escalation may not necessarily take him any further and could be dead-end. A flaw – nevertheless; but doesn’t result into someone taking over the complete application.
While the AppSec test will conclude in that manner; NetSec pros take this to the next level. They generally don’t rest until they have struck the application really hard. They will peruse this till they find some serious information leakage, an SQLi (SQL injection) that reveals some fascinating data, or any general platform flaw that lets them ‘own’ the entire system. The key difference that is observed here is that while AppSec folks will generally not venture beyond assessing and testing; NetSec pros take the application environment to its breaking-point. This clearly indicates the distinct ideology of the two skill sets.
The argument here is not that if an assessment is better than full-blown PenTest or not; but that sometimes AppSec professionals get mental blinders & that they should freely consult with their NetSec peers for helping them perform successful PenTests.