The Security Dilemma of Desktop Access to ERP Systems

Eric Smith is chief information security officer and Jason Snyder is librarian and manager of Communications and Outreach, Library and Information Technology, at Bucknell University.

Over the past decade, the information security's front lines have shifted from the data center to the desktop. Cybercrime targets end users and workstations, not servers, because workstations are softer targets, having multiple infection vectors and a reduced set of technological defenses. New desktop software flaws are constantly discovered and exploited, allowing hackers to infect systems with malware by exploiting Internet-connected applications and web browser plug-ins. The best defense against these types of attacks is an aggressive patch-management program. Many organizations, unfortunately, find that they are unable to keep key desktop components up-to-date due to compatibility and support issues with essential enterprise resource planning (ERP) systems.

Bucknell University faced this dilemma as an Ellucian Banner shop. Because users access Banner primarily through Java in their browsers, Ellucian must extensively test its product across numerous Java and browser environments to certify its compatibility with a particular version. The time needed for this testing creates a significant delay between the vendor-supported environment and a fully patched and secure one; by the time vendor-approved patches can be tested in-house and deployed, a new batch of vulnerabilities is inevitably announced, causing the process to begin anew. Each day that passes with insecure software on production workstations is another opportunity for hackers to imbed malware into the network.

In an ecosystem in which software security bugs are a weekly occurrence, our desktop support staff faced a terrible choice: either update the workstation software and risk breaking Banner, or don't update it and risk an information security incident. That the machines running Banner are, by definition, the same systems with access to confidential institutional data made this a particularly troublesome situation (see figure 1).

As if the security ramifications were not bad enough, running production software in an unpatched, vendor-supported environment introduced countless user and support headaches as well. In their default configuration, many components critical to the ERP client's operation attempted to automatically update, resulting in a constant barrage of pop-up notifications and warning messages (such as the one in figure 2). Finally, recent changes to popular browsers such as Chrome and Firefox made it abundantly clear to users that their systems were out-of-date and possibly vulnerable to security flaws. All of these aspects combined to create a hostile user experience and an elevated number of calls to our help desk.

Finding a Solution

The Bucknell team explored a number of solutions to this problem. We put significant effort into creating a VMWare Thin App solution that contained Ellucian-supported versions of Firefox and Java. We further configured the Firefox browser to route its Internet connections through a proxy server so that system administrators could present a user-friendly warning message if users tried to browse the web from the Thin App environment.

Although this worked reasonably well in our internal testing, our team encountered significant usability problems in early user trials. Not only was the concept confusing to our users, it was difficult to maintain; when conflicts with the native browser and Java runtimes persisted, our team reluctantly decided to abandon this approach.

We also investigated the use of Windows security zones to control which sites could launch Java applets from Internet Explorer (IE). This approach can minimize infection vectors that target vulnerable Java versions. However, it does not address problems that might arise in older, vendor-approved versions of IE, nor does it change the Java execution behavior in other browsers.

Our team ultimately decided to deploy Banner via Microsoft's RemoteApp service, which is a component of Windows Server 2008 R2. RemoteApp is an extension of Terminal Services, which lets end-user applications run on a data center cluster — and thereby pool and concentrate computing power for optimum performance. This approach allocates significantly more computing power per instance than a typical office PC could provide. In addition to the performance benefits, deploying Banner from this isolated data center environment insulates the desktop from security vulnerabilities inherent with older Java runtime versions.

Bucknell's RemoteApp design was based on our need to ensure peak performance for up to 100 concurrent clients through a design that easily scales and is highly fault-tolerant. Based on these needs, we deployed three Dell M620 blade servers — each with 12 processor cores and 128 gigabytes of RAM — to power the terminal services farm, incurring a capital cost of approximately $19,000. A virtualized server running the terminal services broker application maintains load balancing and state maintenance. To further secure the environment, we configured the network settings of these servers and the campus firewall to prohibit access to any Internet resources; Windows and other critical software updates are provided by the existing on-campus patch-management servers. As figure 3 shows, the overall configuration is straightforward, and our systems integrators were able to build our test and production systems relatively quickly.

To configure a vendor-supported client environment, we installed appropriate versions of Java, IE, and other utilities on the terminal server systems. Users access the environment through a virtualized IE window, which presents a common launch page to all clients (see figure 4). This launch page offers links to all available software, as well as information such as frequently asked questions, documentation, and instructions for contacting our technical support team.

Users connect to the environment using Microsoft's Remote Desktop Protocol (RDP) client, which lets the applications interact with a client's desktop as if they were running natively on the local system. Because Microsoft's own RDP client is available for various computing platforms, users can access the Banner environment from their choice of hardware, ranging from traditional Windows and Mac desktops to iPads and Android tablets.

Active Directory handles authentication into the terminal server in conjunction with access controls built into the terminal server environment. We added Banner users to a newly created Active Directory group; only users in this group can establish a connection into the environment. Once connected, applications prompt users to enter valid credentials before they can establish a session.

To simplify ongoing maintenance and administration, we configured the terminal server environment in much the same fashion as our computer labs. User profiles are created on-the-fly during login and do not persist across connections. We map the familiar "My Documents" and "Desktop" locations to users' personal network shares to preserve access to any files that they save locally during the virtual session.

Testing, Bugs, and Deployment

Following the system build and extensive testing by our project team, we pushed out icons for the Banner environment's new virtualized access to our users. We called the new system ASAP — for Administrative Systems Access Portal — and gave it a themed logo to clearly distinguish it from the myriad existing icons and bookmarks (see figure 5).

Because ASAP's user experience so closely mirrors the native experience that our users were already familiar with, minimal training was required. A few issues did surface during our initial testing. Printing through the remote desktop client generally worked well, but a few locally connected desktop printers had formatting and other compatibility issues. To address this, we provided native printing to networked laser printers around campus. We also installed a print-to-PDF package on the terminal server farm to encourage a paperless workflow.

A few users complained of poor performance when accessing the virtual environment from off-campus locations. We discovered that these users were connecting through low-speed, high-latency DSL connections. Adding the VPN connection's overhead resulted in poor performance, with graphics-intensive pages occasionally taking minutes to render. To provide a usable solution for these users, we created a "low speed" version of the terminal services icon. This icon launched a "no frills" session with reduced color depth and window resolution and thus provided an acceptable experience for clients saddled with low-performance broadband or cellular links.

Our project team quickly resolved these and other issues. Following successful user acceptance testing, the ASAP system was promoted to full production status, and we discontinued users' ability to connect through the traditional "fat" client. From start to finish, the team spent nine months designing, building, testing, and deploying this solution.

Community Reaction

Our users welcomed the change and the unified access approach. Pamela Noone, Bucknell's director of financial information systems, appreciated the new environment's simplicity and stability:

"It was a challenge to keep our browsers and Java settings on our laptops and desktops at a supported version for Banner and EPM11 [Enterprise Performance Management 11.0].We appreciate the one-stop-shop landing page, with easy access to all of our test and production environments."

The deployment's success has spawned increased interest — from both system administrators and end users alike — in our providing additional applications through the new ASAP interface. Jeremy Fertig, Bucknell's systems integrator, enjoys ASAP's key advantages:

"While there have been challenges to manage, centralizing the Banner client view has offered a number advantages to the campus. We can greatly increase the security of a large number of our client machines; the risks of running older versions of IE and Java have been substantially reduced. Our ability to deploy software to client machines with fewer dependencies will allow for faster updates in the future."

Conclusion

Bucknell's deployment is well into its fourth month and has been performing admirably. It has freed our desktop support team from the drudgery of maintaining out-of-date software across our fleet of desktop systems. We have removed the vulnerable instances of Java from our administrative workstations and no longer include the runtime in our imaging process. Older versions of the Firefox and IE browsers have also been upgraded to the newest, fully patched versions and are configured to apply security updates as soon as the vendors make them available. This not only gives us a more secure environment, it also significantly reduces time spent dealing with malware, spyware, rogue toolbars, and fake anti-virus messages. Given the essential role of patch management in any information security framework, eliminating the need to maintain insecure software represents a significant step toward securing our infrastructure.