All Articles

WHY APPSEC (APPLICATION SECURITY) WON’T ALWAYS BAIL YOU OUT OF APPLICATION BASED RISKS?

It is very typical of organizations to perform Web Application (WebApp) Security Assessments before the go-live of newer applications or periodic assessments of their existing applications. And these assessments are known by all sorts of aliases like Application Penetration Testing (App PenTest), Ethical Application Hacking etc. For those companies lacking the internal core competency of AppSec, often outsource this activity to competent 3rd party players in the market.

What does the CxO function expect post an AppSec assessment?

This (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’.

(Read more:  Action List Before Adopting a Cloud Technology)

So why are AppSec tested applications still not secure?

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 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.

(Read more: How To Write a great article in less than 30 minutes )

• 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.

• Password Management

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.

(Read more:  Can your SMART TV get hacked?)

• 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.

Watch more : Latest Attacks Vectors and Threats on Aircrafts and Unmanned Arial Vehicles

• 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.
4. Support for JavaScript & Flash based vulnerabilities.

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.

Read more:  Five Tips To Minimizing the security scourge of ‘Policy Accumulation’

Why a NetSec (Network Security) assessment if often better at annihilating WebApps?

This is purely based on my personal experience, after I saw some interesting results, post some internal NetSec assessments. The approach of NetSec professionals is very different from the AppSec folks. NetSec pros rather concentrate on the attack-surface (server infrastructure & communication equipment) than get 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.

Let me illustrate my point with a simple scenario that highly persuaded me to give equal importance to NetSec, while assessing WebApps – - – 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 I 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.

¬Dhananjay Rokde

Originally written for ITNext (Print) - http://www.itnext.in/content/playing-apps-safe.html

Also published @ CTOForum (Print) - http://issuu.com/ctof/docs/cto_forum-vol-7-issue-20-june-07-2012/52?e=0

The InfoSec Island - http://www.infosecisland.com/blogview/21415-Why-AppSec-Wont-Always-Bail-You-Out.html