Applications are the lifeblood of our enterprises. Not many organizations can survive in a pencil and paper world. They are all dependent on IT with applications doing the heavy lifting of arranging, tracking, processing, communicating, and calculating daily business. But applications are no longer singular programs running on one computer, they are huge collections of interconnected services, processes, and data stores. Because applications are so complex and spread out, they can have many fissures and cracks that attackers can abuse. What is worrying is that sometimes our most critical applications are the most complex and consequently the most vulnerable.
Critical applications are often so baked into the day-to-day tempo of an organization that users often forget their importance—right up until the moment they go down. Indeed, the first key definition of a critical application is how much an enterprise is reliant on it. By their nature, critical apps have enormous data stores, multifaceted processing engines, and are deeply integrated into other dependent application services. Critical apps also tend to sprawl globally, touching all locations within an organization’s reach. Here are specific types of these critical applications:
Financial applications are the backbones of many organizations, yet they are often focused on the unique financial requirements of an organization. Consider the myriad of needs for banks that process loans. They need software that can deal with mortgage loans, car loans, revolving credit loans, small business loans, and leasing. These all follow different processes with different user bases at different cadences. It’s no wonder that banks have thousands of applications, all critical to revenue and business operations. Accounting applications are also often intricate and tailored to the particular industry of the organization.
Nearly all financial applications are subject to regulation, though their audits can be highly varied depending on their importance and sector of business. Most importantly, financial applications hold, process, and move critical financial data, which needs to remain confidential and unscathed from tampering. Because financial apps touch so many parts of a business, they often touch a wide range of locations, both internal and external. Often you will see Internet commerce systems with direct ties to financial systems to process and record customer payments. All of these are potential ingress points for attackers.
Despite their appearance, hospitals are rarely singular entitles. Most of the time they are assemblages of independent, smaller clinics, doctor’s offices, diagnostic facilities, and service organizations. Their applications exist in the same manner: deeply vertical and highly variable, yet all woven together into a common shared system. This means lots of applications with different levels of security and reliability all sitting side-by-side exchanging essential confidential medical data. Some of these systems are so old, that it’s not surprising for an old Windows XP box to be connected to a drug dispenser machine. Some systems are so specialized that you may have software developed by a singular researcher, who maintains the program as a side project (if ever)1. This is also an environment where patient safety trumps all other requirements, sometimes even security. So, you can see things like the network protocols that embed patient identification into the network packet itself to ensure medical information is never mixed up.2 This is great for reliability and patient care but not so great for maintaining confidentiality on a shared network.
Another overlooked but critical application is email and communication systems. By their very nature, messaging systems need to touch every single person within an organization as well as accept connections from the outside world. Mail systems are notorious dumping grounds for years and years of yet-to-be-classified-but-probably-should-be-secret documents and private conversation threads.
Email systems are also often the gateway to authentication with password resets landing in people inboxes. An analysis of the California Attorney General breach notifications for 2017 showed that 5% of reported significant data breaches were directly attributed to credential exposure via email compromise. Email messages often stand in as the primary identity on the Internet. When you send an email, people naturally assume it’s you that’s speaking. So a compromised email account can be leverage point for a variety of insidious scams, targeting both your customers and internal employees.3
Legacy systems are the most embedded yet the most difficult for IT to manage. Their function could fit into any of the previous categories, although a majority of them are specialized applications, often heavily customized by the organization. Think of airline reservation systems,4 customer management software,5 and one-off unique software.6 Legacy systems exact an excessive burden in their high operating cost and incompatibility with modern systems and security tools. The most difficult and insecure of these systems have existed in a long period of stasis, rarely updated due to their being written in archaic programming languages like COBOL.7 Legacy systems often have limited network facilities and when they do, they often run an excess of exploitable services like Telnet, FTP, Chargen, and Finger. Often these vulnerable services aren’t easily disabled and may even factor into dependent functions within the legacy application.
One of the first things that should be done to manage this risk is to become aware of what and where those critical apps live. As part of a forthcoming report on protecting applications, we commissioned a survey with Ponemon that found that thirty-eight percent of respondents had “no confidence” in knowing where all the applications were in their organization.
These large, sprawling, and critical systems do have some common vulnerabilities that can be exploited by attackers. Even though many critical systems are buried deep within an organization’s internal network, they’re often required to have open connectivity to the whole enterprise, so all employees can access them. These connections are potential avenues of attack.
Many older and specialized applications do not have sophisticated or robust authentication systems. This can lead to mismatches between these critical apps and your security requirements regarding password length, rotation, and complexity. This is even more true for legacy systems since some older systems have a maximum password length of 8 characters.8
If a critical app doesn’t support better authentication or can’t hand off authentication to an access directory server such as LDAP, then authentication gateway servers can be used. These are proxies that stand in front of the critical application and provide superior authentication schemes. All access to the critical app flows through the gateway, which in turn provides the legacy credentials to the critical app invisibly. Even weak passwords could be strengthened since authentication gateways provide seamless access to legacy applications with newer authentication technologies like federation, single sign-on, and multi-factor authentication. Of course, for this to be effective, you need network segregation to funnel all access through the authentication gateway.
Even if everyone in the enterprise and the Internet needs access to a critical app, you should apply some method of segregation. This can be done with firewalls and virtual LANs, which reduce inbound network traffic to the few limited protocols necessary for the application to function. Not only does this help with funneling authentication traffic through gateways, but it also can block other kinds of attacks. Considering that some legacy or specialized apps aren’t patchable and have limited hardening capability, a firewall can at least restrict connection attempts to those vulnerable services. Easily exploited services such as Telnet, FTP, Chargen, and Finger can all be blocked from external access. It’s not perfect because other traffic may still be required to traverse the firewall to the critical app, but at least you’ve reduced your attack surface from intruders moving laterally through your network. In some cases, smarter firewalls with intrusion prevention capability or virtual patching can also block attacks.
With all these network connections to critical apps running around your enterprise network, it’s a good idea to secure the transmission, as well. A malicious insider or an attacker that’s already breached your network is a viable potential threat, so any internal traffic carrying confidential information should be protected. If the critical app doesn’t support a secure transport protocol, then a TLS or VPN gateway can be used. Like the authentication gateway, these sit in front of the critical app and encapsulate all traffic passing through into an encrypted tunnel. These should also be used for all external links from the application, even to trusted third parties.
In time, the operational cost of managing and securing older but critical apps will probably mean they will be replaced, likely by software-as-a-service or cloud offerings. However, for a lot of organizations, these systems still exist as stark risks to operations and security requirements. Since these critical apps are well, critical, security teams should work to defend them against attacks that could cripple them, tamper with them, or take them down.
More to come in our Application Protection Report July 25th
As noted in the intro, the perspective to write this article was actually derived from a Ponemon survey as part of a forthcoming Protecting Applications Report. Since CISOs always want to know what other orgs are doing, we surveyed ’em. We saw the critical apps stat and decided to explore that here, but more in-depth analysis and findings to come in our Application Protection Report here on F5 Labs July 25, 2018!