The purpose of application security is to enable business operations to function and grow.
Businesses need satisfied users. These users want to make the most of the applications they’re offered. They also need to be confident that their sensitive data is protected in all other internal applications used to run the businesses that serve them.
Businesses need application security 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 down delivery of value. This could not be further from the truth.
It’s very much like the function of brakes in cars. Without the protection provided by brake systems, cars could not go fast (or far).
Most Users Are Good. Some Are Malicious.
Some users are not friendly. They impersonate others, and they look for security loopholes to access sensitive data. They try to install malware and gain control of servers that run applications on web templates, compromising the security of other users. They attempt to take over others’ accounts, and much more.
Protecting the great majority of well-behaved users from those that behave in a malicious way is a very challenging task. After all, to many fully functioning applications they look indistinguishable from other “users.”
The Challenge of Keeping Web Apps Secure
Today, every business is a software development business, whether in its explicit function, by responding to user demand, or both.
The challenge with application protection is that if one succeeds in building secure applications at the expense of user experience, well-intentioned users will do business elsewhere. In this case, even with seemingly-successful protections, the end result will be a failure. This is because the solution has defeated the purpose of protections — to allow the 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 will fail.
Lessons From the Past and Present: Traditional Methods Don’t Work
Web Application Firewalls (WAFs) offer application protection 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 traffic and by detecting malicious patterns of behavior by comparing input sent to the application with known signatures. In blocking mode, a WAF can block an individual user from accessing the service and thus protect the system and other users from its malicious intent.
This is a sound concept and in many cases must deliver, otherwise why would so many products exist in this space? But the recent SANS Institute 2016 State of Application Security survey paints a different picture.
The survey states: “Many web applications are directly exposed to external attacks and, while infrastructure systems such as web application firewalls exist, they are often considered inadequate for deterring a sophisticated attacker.”
The SANS survey goes on to assert that “Cloud-based web applications are often more exposed than web applications hosted in traditional enterprise networks. In cloud environments, implementing network controls such as firewalls, web application firewalls, intrusion detection systems and similar controls can be difficult.”
The survey does not go into great detail about the reasons WAF technology is inadequate. Research done by the analyst firm Securosis in 2012 provides some additional answers to this question. Securosis found that “compliance mandates have made WAF the path of least resistance for application security.”
In spite of this, Securosis found that “many WAFs are configured to neither block nor conceal the information pen testers look for and leverage for evasion. Information about the site, details about the application, configuration data, and even details on the WAF itself leak out, making the WAF nothing more than a speed bump for a good pen tester. Far too many WAF deployments are more about getting that compliance checkbox rather than stopping hackers or pen testers.”
Not only that, but WAF security policies often inadvertently block legitimate traffic. This issue, combined with poorly-designed user interfaces and the demanding skill set required in effective WAF administrators, mean WAFs are a heavy lift to operate successfully, the research firm found.
Once the very specific WAF rules are set, they are defined for very specific types of threats for very specific versions of the application. If the application changes, the signatures used by a WAF go out of sync. When signatures go out of sync they can confuse good users for malicious actors and prevent good users from accessing the service that they invested in.
Preventing advanced attacks should be job one for any organization concerned about web app security. Preventing well-intentioned users from accessing application functionality is what typically leads to prompt action — stop blocking “attacks” and just monitor traffic and users.
New Technologies for Application Protection
Getting web security right when you’re relying on WAFs requires a delicate dance between IT, development, and security. Whenever a change is made or a new feature is implemented, before or after the app is in production, the security team needs to know so the WAF is tuned to correctly recognize good traffic associated with the app and reject everything else. This takes time and resources that are typically not available.
To solve the human problem of wanting to securely deliver advanced services to delight users, it makes sense to look beyond WAFs to a way to build security into the application itself. This approach minimizes the human-driven security threats.
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 into what is happening inside the 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?