| We've begun producing the 2019 version of this Report, and are releasing portions of it as individual articles. To see the first Episode in the 2019 Application Protection Report (and continue through the rest of the series), click here. |
Protecting applications is a critical task for security professionals, yet many feel they’re fighting a losing battle. In F5 Labs’ first annual, comprehensive Application Protection Report, we provide a practical model for understanding the complexities of applications, explore specifically how and where apps are being attacked, and offer practical steps you can take now to start—and keep—winning the app protection battle. Read the Executive Summary below.
To download the full report, click here.
Executive Summary
Like coral reefs teeming with a variety of life, web applications are “colony creatures.” They consist of a multitude of independent components, running in separate environments with different operational requirements and supporting infrastructure (both in the cloud and on premises) glued together across networks. In this report, we examine that series of interacting tiers—application services, application access, transport layer services (TLS), domain name services (DNS), and the network—because each one is a potential target of attack.
To get an objective viewpoint on how applications are being attacked, F5 Labs looked at data from a variety of sources, including our own internal datasets, WhiteHat Security vulnerabilities, Loryka attack data, and a Ponemon security survey of IT professionals commissioned by F5.
In addition, we worked with faculty from the Whatcom Community College Cybersecurity Center to perform an extensive review of breach notification records in California, Washington, Idaho, and Oregon. (In each U.S. state, it is the state attorney general’s office that oversees and is responsible for enforcing state breach disclosure laws and notifications. Because of this role, some states publish data breach notification letters.)
In these four states, we analyzed 301 breaches in 2017 and Q1 2018 and found that web application attacks were the top cause of all reported breaches at 30%. Earlier research done by F5 Labs into 433 major breach cases spanning 12 years and 26 countries found that applications were the initial targets in 53% of breaches.
Protecting applications has always been a critical task and will continue to be in the future.
But, what do CISOs need to know now?
What Apps Do We Use and Where Are They?
Our F5 Ponemon survey, Web Application Security in the Changing Risk Landscape: Global Study, found that a majority of organizations have little confidence in their ability to keep track of all their applications. Thirty-eight percent of respondents said they had “no confidence” in knowing where all the applications were in their organization. Yet, at the same time, respondents reported that 34% of their web applications were mission critical. Among the most commonly used web apps were backup and storage (83%), communication applications like email (71%), document management and collaboration (66%), and apps in the Microsoft Office suite (65%).
How Could Application Attacks Affect My Organization?
When apps are attacked there are many different impacts. Denial of service was the most painful for many organizations, with 81% of respondents rating loss of availability at 7 out of 10 on a scale of 1 to 10 (10 being highest). Breach of confidential or sensitive information (such as intellectual property or trade secrets) placed second with 77% of survey respondents rating it 7 to 10. Similarly, 73% of respondents rated tampering with an application at 7 to 10. Finally, 64% of respondents rated the loss of personally identifiable information (PII) of their customers, consumers, and employees at 7 to 10.
What Are the Significant Risks?
Within the 2017 and Q1 2018 breach notification letters from the states’ attorneys general, we examined web attacks in detail. Specific application breaches included payment card theft via web injection (70%), website hacking (26%), and app database hacking (4%). We cross-referenced this with the relevant WhiteHat Security vulnerabilities, Loryka attack surveillance, and known exploits published by Exploit-DB, a CVE-compliant archive of public exploits1 and corresponding vulnerable software,2 to give us an idea of the most significant new risks.
Injection attacks against app services
The highest percentage (70%) of the breach reports for Q1 2018 were web injections that stole customer payment card information. Injection attacks allow an attacker to insert commands or new code directly into a running application (also known as tampering with an app) to pull off a malicious scheme. Over the past decade, 23% of breach records involved SQL injection attacks, the most infamous type of injection attack. Injection vulnerabilities (weaknesses that have not yet been exploited) are prevalent, as well. WhiteHat Security reported that 17% of all discovered vulnerabilities in 2017 were injection vulnerabilities. This problem is so significant that injection flaws are rated as the number one risk to applications on the OWASP Top 10 2017 list. For this reason, high priority should be given to finding, patching, and blocking injection vulnerabilities.
Account access hijacking
Breach records analysis shows that 13% of all web app breaches in 2017 and Q1 2018 were access-related. These broke down as follows: credentials stolen via compromised email (34.29%), access control misconfiguration (22.86%), brute force attacks to crack passwords (5.71%), credential stuffing from stolen passwords (8.57), and social engineering theft (2.76). Nearly 25% of the web app Exploit-DB scripts were also found to be access-related. The F5 Ponemon security survey showed that 75% of respondents were only using username and password for application authentication to critical web applications.
For any important application, stronger authentication solutions such as federated identity or multi-factor should be considered. For external applications over which you don’t have full control, a cloud access security broker (CASB) can consolidate and augment authentication.
Deserialization attacks against app services
In 2017, deserialization attacks were somewhat low in number but vast in impact. The Apache Struts deserialization injection vulnerability was the hole that attackers used to breach Equifax and steal the identities of 148 million Americans and 15.2 million UK citizens.3 Serialization occurs when an app converts its data into a format for transport; deserialization is the process of converting that data back again. These attacks are becoming more common because applications are now networked clusters of subsystems that require data-serialized communication streams. Attackers embed commands in the serialized data stream and pass them unfiltered directly into the heart of application engines. Thirty Exploit-DB scripts are related to deserialization.
To protect against this type of attack, applications should scan and filter all user inputs, including serialization data streams.
Attacks against transport layer protection
While 63% of survey respondents said they always use SSL/TLS for their web applications, only 46% of survey respondents said they use SSL/TLS encryption for the majority (76-100%) of their applications. With so many transport layer encryption standards (such as SSL and TLS 1.0) still in use, even though they’ve been retired as “broken,” there’s an ongoing risk of eavesdropping or man-in-the-middle hijacks from attackers. Furthermore, 47% of organizations said they use self-signed certificates, which reduces the trustworthiness of their applications.
DDoS attacks are pervasive across all levels of the application tier, so it’s critical that every organization have a DDoS response strategy.
Scripting attacks against clients to hijack access
Attacks against app clients are often underreported because they target individuals, who are unlikely to be mentioned in a publicized breach report, and there are no regulatory reporting mandates like those that exist for application breaches. A common way a client is hijacked is via cross-site scripting (XSS), which is one of the most prevalent vulnerabilities (30% of 2017 WhiteHat Security vulnerabilities, 9.24% of Exploit-DB scripts). XSS attacks can often lead to stolen user credentials or hijacked access. Cross-site request forgery (CSRF) is another way a client can be hijacked into unknowingly running unauthorized commands on a website. Both attacks involve a client app encountering malicious scripting code planted by an attacker somewhere on a website.
Sites can help reduce scripting attacks by using web server options such as session cookies set to HTTP-only and domain restricted, as well as setting the X-frame-options to DENY.
Malware attacks against app clients
Clients are also attacked directly with malware that hijacks the browser to sniff or intercept the application authentication credentials. Malware that targets financial logins is quite common for both browser and mobile clients. While protection of the client device is something that has largely been ignored to date since it is difficult to control, tighter data privacy laws, such as the EU’s General Data Protection Regulation (GDPR), are likely to come down on poorly written app clients.
Some web application firewall solutions can watch for suspicious connections by detecting compromised clients and filtering their access.
Am I Doing Enough to Protect My Apps? How Do I Compare with My Peers?
The F5 Ponemon security survey offers some insight into how other organizations are wrangling application security. The first question is one of ownership: 28% of respondents said the CIO or CTO owns responsibility for the application security risk management process. Only 10% of CISOs own it, yet they will be in the hot seat in the event of a breach.
The top three cited barriers to achieving a strong application security posture were “lack of visibility in the application layer,” “lack of skilled or expert personnel,” and “migration to the cloud environment.” The first and third response both speak to analysis and instrumentation of the application tiers, which are solvable problems with scanning, monitoring, and collaboration with the development team.
At 26%, web application firewalls were the top means for securing applications; others were application scanning (20%) and penetration testing (19%). Surprisingly, 26% of organizations do not deploy application hardening procedures, a useful way to bolster application security.
Four Steps to Take to Protect Applications
While all of these findings might seem to paint a bleak picture, taking these four steps will have a high impact on improving your application security and, for the most part, are not difficult to do.
1. Understand your environment.
Know what applications you have and what data repositories they access. Yes, determining this can be hard work, but it needs to be done. Focus on the apps your organization needs and the apps you build that your customers depend on. For the apps your organization needs, scan and inventory them regularly. For external applications your users depend on, a cloud access security broker (CASB) can be very helpful in counting and tracking app usage. For internal apps, it’s essential to have a good relationship with the developer team to track down applications, future app plans, and development environments.
2. Reduce your attack surface.
Any part of an application service that is visible on the Internet, either directly or indirectly, will be probed for possible exploitation by attackers. This surface is broad, given an app’s multiple tiers and the ever-increasing use of application programming interfaces (APIs) to share data with third parties. All exposed pieces should be access-controlled, patched, and hardened against attack. A good web application firewall (WAF)—our survey respondents’ #1 tool of choice—can buy you time to do this. Some WAFs can perform “virtual patching” by scanning application traffic and blocking known exploit attacks. They know what to block from automatic signature updates from threat intelligence feeds and vulnerability scans of your environment. This alleviates the time pressure to patch immediately when a new exploit is released, and it gives the operations team time to properly test and roll out fixes. Numerous preventable security incidents have occurred because security teams have not enabled the necessary security blocking features on their WAF. You should also segregate and partition your applications so that if a low-priority application gets breached, it can’t become a conduit to reach the higher priority systems. This can be done in code, with server isolation, sandboxes, lower privileged users, and even with firewalls.
3. Prioritize defenses based on risk.
Once you know which applications are important and have minimized your attack surface, identify applications that need additional resources. Your risk analysis doesn’t have to be perfect, just better than random guessing or biased decision making. So, use data to drive your risk strategy, figuring out what attackers would go after. Key data about your applications comes from security testing and scanning. Test internally developed code using internal scanners, code reviews, or a third party, which can give you an independent and knowledgeable perspective. With this information, you can properly assess the risk of any internally developed applications.
4. Select flexible and integrated defense tools.
You need a good but manageable selection of flexible, powerful solutions to cover controls for prevention, detection, and recovery from existing and emerging threats. Beyond the technical controls we’ve already mentioned—a web application firewall, a vulnerability scanning solution, and a CASB—protection needs to extend to all tiers that an application depends on. DNS servers should be well protected with DNS-savvy firewalls and be made highly available. Transport layer communications should be encrypted with a current acceptable standard of ciphers, and web servers should use HTTP Strict Transport Security (HSTS) to ensure encryption is fully covering all critical data flows. Security solutions should be consistent and well understood by security engineers. Many breaches occur despite these solutions simply because of a misunderstanding or misconfiguration of a product.
Based on the potential impacts of DDoS attacks, it's essential to protect your applications at the network, application, and infrastructure levels with on-premises scrubbing equipment or hosted solutions. The important thing is to size the solution based on the risk to your applications and the likely threats.
When it comes to protecting app clients, remember you have two classes of users: customers who access your apps and internal users who access apps on the Internet. To protect internal users, consider using federated identity or multi-factor authentication (MFA) for strong, reliable access control. For applications that only support username and password authentication (leaving your users open to access attacks like password guessing or stolen credentials), a CASB can help by consolidating and augmenting authentication for external apps. Protecting your customer’s app client sessions should also be done for any high-value applications. Some of the more powerful and flexible WAF systems can help you protect customers’ app client sessions by detecting bot attacks, brute-forcing, and logins from suspicious locations. This simple validation is great way to add another layer of protection for your customers as they access your apps.
What Does the Future of Application Protection Look Like?
Serverless applications
“Serverless” is a new way for developers to build web applications without having to worry about servers and the app’s supporting infrastructure. The code and scripts developers write connect to APIs that directly trigger functions and services, instead of the traditional approach where the code runs within a server to call other servers. Serverless computing enables developers to focus on faster, more streamlined app development, and in the long run, serverless apps provide more flexibility and scalability. Just be aware that they are still vulnerable to the same kinds of attacks as traditional apps at every tier, especially against the primary user login pages and the APIs.
Outsourcing of application security
The lack of skilled or expert personnel for security, cited as a main barrier in the F5 Ponemon security survey, will only continue to get worse for application defenders. Furthermore, with organization using an average of 765 different web applications, we can expect outsourcing of application security to grow, whether that means security functions such as anti-DDoS or web application security monitoring or moving to hosted platforms that provide security services as part of their offering. Outsourcing will require matching your specific security requirements to the outsourcer’s capabilities, focus, and experience in application security.
Transport Layer Security improvements
Because Transport Layer Security (TLS) 1.3 is a radical departure from previous iterations of the protocol, the security community will struggle with adoption. The specter of quantum computing is also hanging over TLS in the longer term. It is our opinion that TLS will suffer more severe shocks from an angle other than quantum computing, but those shocks are yet unknown. Organizations should keep an eye on browser support for TLS 1.3 and the major compliance standards regarding network encryption and updates in quantum computing.
Application protection that follows the tiers
Since modern applications are collections of scripts, libraries, services, and devices, we hope to see security tools catch up to this paradigm. In the future, developers will have a broader spectrum of secure components and frameworks to choose from in a way that is dramatically different and better than today’s fragile and overly dependent ecosystem. Developers should ask for application frameworks that are “secure by default” with the capability to report security status and events in a standardized format. Defenders should look for security scanners that can continuously test application components in production in a safe but useful manner.
Conclusions and More Questions
After reading all of this, you might get the impression that web application security is intimidating. Perhaps—but there are some easy ways to get started. If you’re in the minority and aren’t using a web application firewall (WAF) yet, that would be a good first solution to investigate. Be sure to get proper training and make use of all the WAF features to help protect your applications. To quote our own guide to WAF configuration: “Start small, but most of all, just start.”3
Our goal in this report is to give you the information you need to answer the question, “What is the most important thing we can do now to protect our applications?” We have tried to anticipate and answer the kinds of questions CISOs would have regarding their application security. We hope you can use this report to fill in the gaps in your application security strategy—and that it will fuel productive conversations about risk and defense.
What’s next? F5 Labs will continue to investigate threats and risks to applications and provide that information to you. Stay tuned.
To see the full version of this report, including recommendations, click “Download” below.
