Applications have become the heart of many businesses, with millions of dollars allocated to their development and millions of dollars in revenue associated with their success. And in the rush to release these applications as quickly as possible, many businesses are sacrificing on security. This is a dangerous misstep.
In an ideal world, applications would always be coded securely, pass all vulnerability scans and penetration tests, and never encounter zero-day attacks in production. However, vulnerabilities are often inevitable, and in a world of rapid software release cycles, remediation is often regarded as a burdensome task that slows down the pace of DevOps and business innovation.
The danger is real
We recently found that more than 70 percent of application developers admit that the pressure to release updates often overrides security concerns.
That is an alarming figure – especially when you think about how these enterprise applications interface and integrate with other applications, software platforms and databases. Many are customer-facing while others are deployed across a corporate network, internet or intranet. The impact is significant.
Development teams have adapted their security practices to try to keep up with emerging threats and attacks by employing routine application vulnerability scans, penetrations tests and dedicated in-house security resources. In fact, our research revealed that at least 82 percent of respondents said their companies perform some vulnerability scanning and/or penetration testing prior to application release.
Unfortunately, our research also revealed that applications are still being released before all known vulnerabilities are fixed. Specifically, nearly half (43 percent) admit to releasing applications with vulnerabilities at least 80 percent of the time. In other words, developers are fully aware that they are vulnerable to attack when they release or update an application in production. This approach is like asking for trouble.
To prove a point: SQL injections (SQLi), a potentially debilitating type of application attack, was the third most used attack vector, behind malware and distributed denial-of-service attacks in 2014. Standard application security practices are not sufficiently preventing this all-too-common attack vector.
According to a Security Intelligence article that discusses SQLi, attackers were able to manipulate application input and obtain confidential data without being detected by traditional network defense symptoms. Their process is simple: Hackers locate zero-day vulnerabilities in the proprietary code of web applications (which are unknown to common security defense systems because they are unique to each application and have never been introduced before) and exploit them undeterred.
Given the destructiveness of a major data breach, strong application security measures must be in place. And in this day and age, strong application security must include measures in both production and development.
Standard application security needs an overhaul
When it comes to safeguarding applications, the current thinking revolves around secure coding practices and network security products such as Web Application Firewalls (WAFs) and vulnerability management tools. We have also found that one of the top mistakes enterprises make when implementing an application security strategy is assuming that a one-size-fits-most perimeter approach can protect today’s distributed applications.
Enterprises are building applications that have numerous entry points, leverage web cloud services, use APIs and, integrate with third party applications, databases and feeds — making it virtually impossible to know where your application’s perimeter starts and ends. With sophisticated hackers using tools like fuzzers and launching never-before-seen dynamic injection attacks, they often go undetected by scanners or perimeter defenses.
Additionally, these practices are simply not accurate or relevant enough to provide true protection in production environments, and they don’t even cover those SQLi attacks I just mentioned. What’s more, this kind of limited thinking leaves enterprises with major challenges including visibility, remediation, scalability, and secure coding.
In order to improve security, companies need to look beyond securing the perimeter of an application, and embrace high-performance security technologies that enable applications to defend themselves at runtime.
Runtime security protects more than the perimeter
Application developers are in the business of building technology – not breaking it – so they may not always look at code the same way that a hacker would. Additionally, attack vectors are amorphous, constantly changing and evolving in subtle ways, developers may not be able to architect applications in ways that would prevent future, unknown attacks.
Fortunately, there is security technology available that can be built into an application, detect and then prevent real-time application attacks. Gartner labeled this category as runtime application self-protection (RASP). This approach allows an application to monitor itself and detect malicious input and behavior in a way that’s easy to implement and maintain – with only negligible impacts on performance.
Unlike perimeter-based security products, RASP uses the context of the application together with the content that the application is processing to accurately identify and, in protection mode, automatically neutralize the attack. Empowering enterprises to move security to the core of an application, this technology builds the security infrastructure into the application itself so applications are automatically protected in any and every environment. RASP improves security accuracy because of its detailed view into the actions of the application, including insight into application logic, configuration and data and event flows.
Preventing even the most sophisticated of household attack vectors like cross-site scripting (XSS), SQL injections (SQLi), and cross-site request forgery (CSRF), runtime solutions like RASP enable business to allow exceptions on vulnerabilities based on actual, real-time exploits (instead of potential vulnerabilities). What this ultimately means for the bottom line is that more applications can be safely pushed into production.
It is important to note that enterprises should continue to use the testing technologies available, such as Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST), and round out the software development lifecycle by protecting their applications with RASP technology while in production. RASP can serve as the last line of automated defense in a layered security model, working during runtime within the core of the application.
With the fast development cycles of today and the distributed nature of our critical applications, perimeter-based security is now no longer the final answer. Too many organizations let application vulnerabilities fall to the wayside. Explore layered security approaches that include WAFs and RASPs. Your data will love you for it.