The Human Factor and Cardinal Sin of Web Application Protection
With users wanting both high security and enjoyable performance, developers these days need to look to new technology to keep the balance.
Join the DZone community and get the full member experience.Join For Free
The purpose of web application security software is to enable business operations to function and grow.
Businesses need satisfied users. These users want to enjoy and experience the value provided through applications offered to them. They also need to be confident that their sensitive data is protected in all other internal applications that are used to run businesses that serve them.
Businesses need web application security encryption to allow them to function and go fast.
This statement may sound contradictory—application security is often seen as an expense, a necessary evil, something that slows delivery of value down. This could not be farther from the truth.
Web application security is an essential. A baseline.
It is very much like the function of car brakes. Without the features and fundamental protection provided by brake systems, cars could not go fast (or far). However, speed is not the first association that comes to mind when we think about brakes.
Most Users are Good. Some Are Malicious.
Some users are not friendly. They are malicious. They impersonate others, they look for web application security loopholes and firewall flaws to get to sensitive data, they try to install malware and gain control over servers that run applications, or web templates that can compromise the security of other users. They attempt to take over other users' accounts and much more.
Protecting the great majority of well-behaving users from the bad ones is a challenging task. After all, to many fully functioning web application methods and metrics, they look indistinguishable from others. Furthermore, there is no perimeter between good users and bad users, no giant medieval gates to shut down in the presence of an imminent web application security risk, or worse—attack.
Today, every business is a software development business, whether by following a vision or by responding to user demand—or both. Business-critical operations are executed with the help of web applications.
The challenge of application protection is that if one succeeds in building secure applications at the expense of user experience, well-behaving users will do their business elsewhere. In this case, even with seemingly successful protection, the end result will be a failure because it won’t deliver on the major purpose of the very existence of web protections—to allow business to move fast.
In the opposite case, if one builds a fantastic user experience in an insecure way, the users and, ultimately, the business will suffer and application security fails in accomplishing its objective.
Lessons From Past and Present
Web application firewalls offer application protection solutions "after the fact"—once the application is already developed and deployed. The idea is that one can distinguish between good users and malicious users by looking at the traffic and detecting malicious patterns of behavior by comparing input being sent to the application with known signatures. In blocking mode, a WAF can decide to block an individual user from accessing the service and thus "protect" the system and other users from its malicious intent.
In the world of global business, which is in the process of massive migration to the cloud, building (fire)walls around the perceived perimeter is insufficient when it comes to web application protection and web application security validation.
A recent SANS Institute survey concludes:
“While infrastructure systems such as web application firewalls exist, they are often considered inadequate for deterring a sophisticated attacker.”
The survey does not go into great detail about the reasons for the technology's inadequacy, but research done by the analyst firm Securosis provides additional answers as described in their blog post Trouble with WAF, which is a part of a larger research study about WAF management:
"WAFs Break Apps: The security policies—essentially the rules that tell what a WAF should either block or allow to pass through to the application—can (and do) block legitimate traffic at times."
As described earlier in the article, blocking valid users, who are often paying customers, is the cardinal sin of web application protection technologies. It goes against the very reason for their existence.
New Technologies for Application Protection
Getting web application security vulnerability right when you’re relying on WAFs requires a delicate balance between IT, development, and security training. Whenever a change is made or a new feature is implemented, before or after the application is in production, the web application security team needs to know so the WAF is tuned to correctly recognize good traffic associated with the web application and reject everything else. This takes time and resources that are typically not available.
To solve the human problem of wanting to provide great service, delight users, all while maintaining a high level of security, it only makes sense to look beyond WAFs and find a way of building security into the application itself, so that the human-driven security implications are minimized. After all, we (normally) do not stop cars by dropping safety barriers in front of them, or by bolting breaks onto the outside of the vehicle. The technology that’s most recently come to the fore in this arena is Runtime Application Self-Protection (RASP), the technology around which IMMUNIO is built. RASP is changing the way security is done—it’s based on insights on what is happening inside the web application when suspicious traffic is sent in.
Does the new payload change the behavior of the application? Is it going to execute? Does a suspicious user respond to the challenges that the application is sending in response to the increased threat? Is the user human, or is it a bot?
IMMUNIO is offering demos to see their product in action.
Published at DZone with permission of Goran Begic, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.