Grappling with web application security?

Grappling with web application security? Source: Shutterstock

The complete guide to understanding web applications security

MODERN businesses use web applications every day to do different things, from interacting and engaging with customers to supporting sales and operations.

As a result, web applications are rich with data and critical to the functioning of the company – which means, special precautions must be taken in order to protect them from hackers.

However, not all organizations or their applications are subject to the same level of threats and attacks. In an exclusive interview with Gartner’s Research Director Dale Gardner, Tech Wire Asia learns how businesses can best protect their web applications.

Gartner splits attacks on web and mobile applications and web APIs into four categories:

# 1 | Denial of service (DoS) 

DoS is a specific subtype of abuse where the attacker’s goal is to disrupt the availability of the web application or service.

In particular, this attack type covers volumetric attacks, which overwhelm network capabilities, and so-called “low and slow” attacks, which overwhelm application or service resources.

# 2 | Exploits 

Exploits take advantage of design, code or configuration issues that cause unintended behaviour of the application.

Some common examples include SQL Injection (SQLi), cross-site scripting (XSS), buffer overflows, and various Secure Sockets Layer (SSL) and Transport Layer Security (TLS) manipulation attacks.

# 3 | Abuse 

Abuse covers many non-exploit types of attack that primarily take advantage of business logic. This includes scraping, aggregating, account brute-forcing, scalping, spamming and other — often automated — scenarios.

# 4 | Access

Access violations occur when an attacker or legitimate user takes advantage of weaknesses in the authentication (AuthN) or authorization (AuthZ) policies of a web application or service.

Of the four categories, Gardner says only exploits can be potentially addressed with secure coding and configuration. The others require design-level considerations that cannot be reasonably compensated for in code.

For example, although it’s arguably possible to defend against account takeovers in individual application code, it is much more economical and error-proof to do so in the identity and access management (IAM) system or another external capability.

In an ideal world, the highest level of protection would be available at all times or as needed, but this isn’t feasible due to complexity and cost factors.

And continuously providing the highest level of protection to all web assets can be an expensive proposition, both from economic and operational perspectives.

Securing web applications and web APIs from attacks and abuse requires businesses to assess what level of protection is necessary.

“Security teams must first pick a protection baseline. Then they must decide what extra protections are necessary to apply to specific assets,” recommends Gardner.

When thinking of protecting web applications, security teams often first look to existing network technologies, such as next-generation firewall (NGFW) platforms and intrusion detection and prevention systems (IDPSs).

But these do not provide strong-enough capabilities in any of the protection areas, warns Gardner.

They are not easily integrated to intercept TLS and do not have the same signatures, rules, behavioral analysis and business logic insight as security solutions that focus on web applications and APIs.

Organizations often first look at a “completely automated public Turing test to tell computers and humans apart” (CAPTCHA) when they suffer from abuse of functionality.

But an always-on CAPTCHA creates user-experience hurdles for legitimate users, and it is also no guarantee to keep the abuser out (attackers keep finding ways to circumvent or solve many CAPTCHAs).

Multifactor authentication (MFA) and out of band (OOB) challenges are often used to enable strong access control, as well as to try to thwart abuse. Unfortunately, they suffer from similar issues as CAPTCHA, and in addition are often complex and expensive to implement.

Currently, no single security platform or solution implements the highest possible level of protection in each of the exploit, abuse of functionality, access violation and DoS mitigation categories.

Some organizations will still be able to start with a single solution to address the biggest potential risks. But they often find themselves needing greater security capabilities over time due to changes in threats and the application landscape.

Web application firewalls (WAFs) are broadly deployed, but buyers routinely express disappointment and frustration over factors such as accuracy, the ability to prevent attacks, the administrative overhead required to maintain attack detection profiles and price.

Incumbent vendors have begun addressing emerging requirements, but many products still lag.

The market for solutions to protect web applications will continue to grow, but given buyer dissatisfaction, vendors with innovative approaches and new product packaging will capture the bulk of new spending.

Buyers are shifting to service-based offerings, and demand for infrastructure as a service (IaaS) deployable products is growing. These shifts pose risks, especially to incumbents, but also present opportunities for new offerings and greater growth.

Gartner believes that by 2020, stand-alone WAF hardware appliances will represent less than 20 percent of new WAF deployments, down from 40 percent today.

By 2020, more than 50 percent of public-facing web applications will be protected by cloud-based WAAP services that combine content delivery networks, DDoS protection, bot mitigation and WAFs, which is an increase from fewer than 20 percent today.

Web applications, mobile applications, and web APIs are subject to increased numbers and complexity of attacks.

Gardner, who will be speaking at the Gartner Security & Risk Management Summit in Sydney later this month explains what organizations must keep in mind when planning and implementing solutions:

  • Public, limited-access external, and internal applications require different levels of security.
  • No one capability covers all types of attack.
  • No two capabilities have interchangeable protection efficacy.
  • Some of the capabilities have strong overlaps in addressing specific attack subcategories.
  • Enforcement of policy may be centralized or distributed (for example, use of micro-gateways).

“As a result, a mix of capabilities, though not necessarily separate products, have to be put in place as a layered approach,” concludes Gardener.

Considering the range of exploits and abuse that can occur with web and mobile applications and web APIs, technical professionals must leverage a mix of externalized security controls to deliver appropriate protection and alleviate burdens to development staff.






COMMENTS