Technology advancements, including online access and services, along with the rise of e-commerce have elevated credit and debit cards to the default payment method for most goods and services. The ease and convenience they offer customers bring the obligations of the Payment Card Industry Data Security Standard (PCI DSS) for companies to secure and protect credit-card data and sensitive information when displayed, including in legacy host applications.
Although brand-new payment systems have been built for the digital economy, legacy host applications continue to play a large role. For example, travelers often provide their credit-card details over the phone when booking airline tickets. Should customers need to update their itinerary, they may call back and speak to an airline representative who will pull up a traveler’s file to make the change. This file often has the credit-card data saved; in many cases, the data is visible to any customer-service employee accessing the information.
According to the 2011 Cost of Data Breach Study by the Ponemon Institute, the average cost of an enterprise data breach was $5.5 million in 2011. This number doesn’t even take into account how decreased customer trust as a result of a breach can affect sales and the company’s reputation. And simple insider negligence, a factor under a company’s control, is the primary cause of most enterprise data breaches.
As a result, it’s important to be able to protect confidential data from malicious attackers who gain access to the system—whether the system is a modern or legacy one. But owing to internal-fraud concerns and data-breach risks, it’s just as helpful if an organization can hide that data to prevent it from ever being seen. Organizations need to apply modern security to legacy applications, but often they can’t afford to do so for every host application. There are, however, ways to modernize security surrounding your host applications without changing anything on the host side.
A Brief History
In the past, all data sent over a network was sent in plain text; there was no SSL/TLS or SSH encryption. This all changed with the public Internet, as the market began to process significant business online and Netscape created the SSL encryption standard to protect sensitive data in transit. With an estimated 70 percent of mission-critical data stored in enterprise systems like mainframes, it became imperative to protect network data on public—and private—networks. The lack of a security focus in the enterprise presented several security risks and challenges:
- No confidentiality of data or passwords. Without encryption, data and passwords are exposed.
- Weak authentication. Many hosts are limited to case-insensitive eight-character passwords.
- Decentralized authentication. Host applications are usually disconnected from the identity-management systems used in the rest of the enterprise, and host-based authentication is often difficult to tie into an enterprise directory service like those based on LDAP.
- Decentralized access control. Access control happens only at the host, so centralized control is limited to other enterprise resources, like printers and file shares.
- Decentralized auditing. Access to hosts is often monitored only by host admins themselves.
First-generation legacy host security architectures use SSL connections directly from the client to the host. This strategy provides one key advantage—data and passwords are encrypted. But the encrypted tunnel from the client to the host has the unfortunate side effect of defeating other security measures by making it difficult to monitor network traffic or apply any kind of access control in the DMZ. Limitations of the simple SSL direct-to-host architecture include the following:
- Weak, decentralized authentication. Authentication is still handled completely by the host in most SSL deployments, so many hosts are protected only by eight-character case-insensitive passwords. Host authentication is usually divorced from the identity-management systems used in the rest of the enterprise.
- Decentralized access control. Access control happens only at the host, so there is no centralized control over access to all enterprise network resources.
- Unauthenticated SSL traffic is passed straight to the host. The encrypted SSL tunnel makes it impossible to monitor the connection in the DMZ and provides intruders with safe passage all the way to the host-application logon screen. The central security team must let traffic through the DMZ without knowing who the client is, or what the traffic is, because the traffic is encrypted.
- Decentralized auditing. Access to hosts is monitored only by host admins themselves.
- No centralized threat monitoring at the perimeter. Incoming and outgoing traffic cannot be scanned with content inspection or other security devices because the content is encrypted.
- Decentralized control over security. Authentication, access control and auditing can be applied only at each individual host, making it difficult for a central security team to monitor and enforce the use of enterprise security policies.
SSL direct-to-host provides encryption but can make it difficult to have centralized enforcement of access control and other security policies.
Evolution of Technology and Requirements for Security
Enterprises face more threats to their network security than ever before—from both inside and outside the network. And with security breaches and insider fraud on the rise, many legacy host applications just can’t keep up with the new and emerging security requirements. A more cost-effective approach is to leverage a secure terminal-emulation solution to modernize the legacy host-application user experience and address evolving security requirements. Reasons to switch to a more secure terminal emulator include the following:
- Don’t have to touch the host. Updating host applications to meet new requirements is costly.
- Comply with PCI DSS. If your company processes credit-card transactions, you’re probably familiar with the requirements outlined in the PCI DSS standard, including masking displayed cardholder data and installing the latest vendor-supplied critical security patches. These days, it’s essential to fully protect customer data on host systems. After all, data breaches not only hurt your customers, but they can mean heavy—even catastrophic—fines for your business. Not all terminal emulators help you comply with the latest PCI DSS requirements, but some do.
- Protect data on host screens. Sensitive data—such as U.S. Social Security numbers, driver’s license numbers, and dates of birth—stored on IBM host screens can be protected with the right terminal emulator. You can even take security to the next level by preventing your users from copying data from a host screen to the Windows clipboard to be shared with other applications.
- Get the latest encryption. If your organization transfers sensitive data over public and private networks, it could be vulnerable to theft by hackers using network-sniffing tools. You can mitigate this risk with SSL/TLS and SSH technology that encrypts the data as it travels over the network.
- Tame macro sprawl. Do you know where your macros are in the enterprise and what they do? If you don’t know the answers to these questions, you’re exposed to a large, unknown risk. All terminal-emulation clients allow end users to record macros to automate their daily tasks. But macros can be subverted and therefore should not be automatically trusted—at least not anymore. And deployment practices from years ago allow users to easily share risky macros via email and sneaker-net. To effectively manage macros and other automated tasks, terminal-emulation solutions exist that allow granular control so that only trusted macros can be executed.
- Benefit from a secure development lifecycle. Security begins with intelligent software design and development processes. Are your software partners using a well-documented secure development lifecycle process to help protect you from security threats? Security features aren’t simple check-box items; make sure your vendor has a process for implementing secure code to maintain the integrity of your business applications.
A more secure operating environment for end users and the company—one with data encrypted and protected—results in fewer holes in the network to protect against data breaches and internal fraud incidents. One area where enterprises are particularly vulnerable is with legacy host applications that are expensive to update, which is why organizations are looking for a terminal-emulation solution that can ameliorate this pain. By selecting a modern, secure terminal emulator, companies don’t have to change the host system, saving money by not having to hire people with those skills. The company can redirect resources to focus on priorities, not training. With the right terminal emulator, organizations gain peace of mind.
Leading article image courtesy of jeff_golden
About the Author
Kris Lall is a product marketing manager for Attachmate Corporation. Kris has more than 20 years of experience in the host access and host connectivity industry, having served in roles that include technical support, systems engineering and product management. He started tinkering with computers when 16KB was the maximum addressable memory in a personal computer and software programs were loaded using a cassette drive. Kris uses this experience along with a math degree from the University of Washington and MBA in eBusiness to ensure Attachmate’s Reflection line of terminal-emulation products meet the demanding requirements of enterprise customers.