The problem with providing access to key resources through privileged accounts is that clients, consultants, and vendors are essentially handed the keys to the kingdom. A common security protocol is the principle of least privilege, which dictates that consultants, developers, and vendors should be given only sufficient access to get the job done. Providing limited, taskspecific access to these key resources, systems, and information is crucial to preserving the protected environment.
Areas most often supported by remote vendors include application management, desktop management, system management, platform development, and system security. Accordingly, privileged session control necessitates new and often entirely different requirements than traditionally exercised over internal employees. The enterprise landscape is comprised of multiple tiers of application and server platforms operating at various levels of infrastructure, each requiring individual security constraints and posing separate remote access challenges.
Additional laws and federal regulations impact organizations differently. In fact, even the implementation of overlapping compliance coverage differs greatly among similar organizations. This creates an entirely new set of challenges and compromises.
For an enterprise operating in compliance with the Gramm-Leach-Bliley Act (GLBA), there's no reliable means of ascertaining whether a vendor has taken full precautionary measures to avoid violating customer privacy while rendering contractual services. Likewise, a company complying with the Health Insurance Portability and Accountability Act (HIPAA) cannot ensure that consultants haven't compromised or exposed patient data—as has happened in the recent past with security contractors retaining patient records only to have them stolen offsite. Companies can only be assured of their own compliance or negligence under such conditions, while outside sources may not be held to the same standard or governed by the same processes.
An increasing interest in outsourcing gives rise to privileged session access, which only further complicates the privileged session scenario. In an ongoing effort to maximize uptime and reduce cost of ownership, more enterprises are permitting IT equipment vendors and service providers to access network and networked systems to diagnose and resolve issues remotely. Clients, consultants, and remote vendors are also becoming increasingly involved with company IT operations where cost-cutting efforts result in outsourcing responsibility for administrating, maintaining, and repairing on-site applications and equipment.
Granting, managing, and controlling access among these expanding external groups further challenges IT administrators within the company. Remote vendors staff personnel that are beyond the scope of review by company insiders, which creates difficult issues for maintaining accountability—particularly with any shift in the remote vendor's staff or user base. Administrator accounts are universally present, but network devices and security appliances often utilize a single administrator account without support for creation of sub-accounts. UNIX systems and Windows domain controllers are fully supportive of non-administrative account creation, though few restrictions apply to lower-priority administrative roles.
An enterprise cannot expect to dictate the rules of engagement for a remote vendor operating entirely out of their own interests in accordance with their own guidelines. This is problematic for the home team environment particularly where compliance requirements, product implementations, and security specifications clash. Furthermore, each vendor is likely governed by entirely separate site-specific security requirements and governmental regulations originating within an entirely different country.
Hiring consultants to perform on-site or remote services is equally challenging within a protected enterprise environment. Consultants aren't bound to the same regulatory and compliance practices as the enterprise environments they work within, even if there's a contractual obligation to retain privacy and maintain certain ethical standards. Companies and consultants are bound to entirely separate codes of conduct and modes of operation even where there is significant overlap in protocol or procedure.
Even when employees work remotely, especially those who must operate in privileged sessions or make use of privileged accounts, many of the same concerns that apply to outsiders also apply to them. Although employees can be held accountable to codes of conduct and expected to comply with security policy and best practices, their remote sessions need extra levels of protection, inspection, and control.
Current approaches to remote administration are incomprehensive and incomplete. In a "jump box" scenario, vendors have access to a few defined machines from which they launch their sessions. Although this scenario creates a defined point of entry capable of monitoring keystrokes and providing session replay, it works only in limited situations (such as commandline activities). VPNs enforced by access control lists (ACLs) also permit limited connectivity to select systems with defined access but provide no replay and still creates administrative burden.
Enterprises need granular authorization for administrative connections permitting strong authentication at every entry point into the protected environment. Remote administration should operate under a segmentation strategy with secure connections to ensure privacy. Proxy deployment interrupts direct system-level connections to prevent creating a bridge for remote vendor malware from creeping into the protected environment.
Application-to-application (A2A) or application-to-service (A2S) interactions often call upon elevated privileges to perform tasks involving sensitive data or processes. Without proper user account management, these interactions too often involve storage of credentials in configuration files or registry entries in plain text where anyone with elevated privileges can access such information. In particular, the following types of data demand more probative and careful treatment:
Managing privileged user accounts for remote vendor access involves entirely separate concerns and conditions than with typical remote employee access. Managing and monitoring access to sensitive systems must still be centralized, policy-driven, and automated, but the underlying characteristics and governing requirements are entirely different.
When it comes to dealing with remote sessions, privileged or otherwise, it's often difficult if not impossible to enforce security policy requirements for firewalling, antivirus, and other antimalware controls, platforms, applications, and so forth. Thus, when it comes to creating a cooperative environment among diverse and regionally dispersed systems and users, it's improbable to expect uniformity among operating protocols and platforms. Different organizations address system and network concerns differently, using dissimilar operating systems (OSs), network protocols, and security paradigms.
With this collaboration among consultants and vendors comes a distinct inability to enforce compatible and consistent firewall and antivirus applications. Unfortunately, this simple disparity can present a significant stepping stone for an attacker—whether automated or manual, man or man-made—to gain foothold into one or the other organizations. Where one company enforces timely updates for signature databases, firewall rules, and application updates, another may be lax or lenient; this can cause significant problems for a well-protected environment.
Also accompanying a difference in operating platforms, protocols, and procedures is a distinct inability to enforce compliance among VPN and remote access software. Clients, consultants, and vendors utilize individually or organizationally defined products to achieve remote access with partner companies, and this includes likely non-compliance with firewall policies as well. Furthermore, dial-up connections and VPNs introduce security vulnerability and inherently lack sufficient auditing capabilities, making it virtually impossible to track external access and maintain consistent data center security.
A likely scenario is that a participating partner uses different VPN software or an incompatible communications protocol. VPN connectivity is neither consistent nor universal, which poses real problems for ground-level IT workers whose job it is to make connectivity work. Many protected environments do away with modem connections entirely for improved security, but not all organizations are inclined to make such sacrifices and continue to utilize this most insecure communications medium.
The span of control issues scales in size with the remote vendor and whatever complexities it brings to the table. First and foremost, remote vendor staff operates well beyond company control. On-site staff often has no idea who they're working with remotely and even a simple change in remote vendor staff creates significant accountability issues. Trust within protected environments is a fragile thing.
As an organization expands in scale and scope, the number of administrators accessing sensitive data and systems grows as well. Organizations encounter growing pains with the realization that old standby methods of account management—sealed envelopes, sticky notes, spreadsheets, and so on—are insufficient and incompatible with modern auditing requirements. Yet the need to continue granting access to protected systems remains constant, with access now reaching an external scope of outside help. This calls for more highly granular access controls, along with comprehensive controls over remote access (who gets in) and privileged session activity (who may touch which resources, and what actions they may perform).
Numerous characteristics must be present for remote privileged sessions to be properly handled. We review the key characteristics in a workable solution for managing remote privileged sessions in the list items that follow:
Privileged sessions and the accounts they use continue to demand close scrutiny and tight control throughout the enterprise, primarily because they can bypass ordinary IT user access and management controls. Privileged sessions are only as strong as the weakest link in a long security chain. Privileged accounts should be handled with discretion, but even that is not enough to prevent authorized users from making unauthorized changes to system configurations or operational parameters. That's why account tracking, tight access controls, and activity logging are so important to delivering workable solutions that comply with security policy and regulatory requirements.