White Paper IT infrastructure layers requiring Privileged Identity Management Abstract Much of today s IT infrastructure is structured as different layers of devices (virtual and physical) and applications. Now each installation (device or application) on each of these layers comes with its own administrative account. These credentials, in turn, have to be managed themselves to prevent security breaches. To get a sense of the scale, just one large-scale IT deployment can potentially have privileged accounts to the tune of 6-digits (>100,000) if we count all installations on all the layers. Even if the number of vulnerable credentials is a small subset of this number, an automated tool can work through them in matters of minutes. Just the thought of manually managing all of them can be very intimidating. Fortunately, automated privileged identity management systems exist for this very purpose. And the best part is that you can integrate them at all layers of your infrastructure.
White Paper 01 Overview vulnerable privileged Identities are a clear and present danger The layered architecture of IT infrastructure exists for several reasons, like flexibility in switching vendors, having separate operational team manage each layer, no single points of failures and so on. But with all these advantages comes the cost of having a multitude of systems that need to be managed separately, i.e., the administrative logins don t get mis-configured, stale or shared; instances are not published with default logins that can be looked up in the device s user manual; and other general security practices that should be followed for credentials and access rights. If an attacker gets access to just a small subset of these vulnerable credentials, he can breach the system, working as a privileged user, with complete control over the installation in question, without leaving any trace, until it s too late. With the advent of the cloud, IT is expected to work at an absolute minimum cost to ensure high service availability and consistent data security. Until now, privileged access has been difficult to secure within a large-scale, dynamic IT setup using just manual intervention and outdated software tools. This, predictably, has led to inappropriately secured privileged accounts, which has been exploited byhackers and malicious insiders. As an example, compromised credentials were the reason for 84% of stolen data, as per a 2012 Verizon survey of larger organizations that suffered data breaches. This problem of fragile and unmanaged privileged credentials can be successfully addressed by automated Privileged Identity Management solutions across the disparate layers of the IT infrastructure, which are getting more complicated each passing day.
White Paper 02 Problems managing privileged identities IT infrastructure is mostly structured as layers of devices (virtual and physical), which are home to vast numbers of rapidly changing privileged accounts (Figure 1 below), including - Administrative logins at the Operating System layer - on physical and virtual computers (Windows, Linux, UNIX, and others), as well as the privileged logins present in VM hypervisors. - Administrator and Root accounts present in shared file system layer. - Highly privileged service and process accounts on the Application and Database layers - used for application-to-application and application-to-database authentication. - Root and Admin accounts on the Network layer - present on physical and virtual network security appliances and backup appliances. Securing these privileged identities is very crucial to the secure functioning any IT setup. According to the SANS Institute, a primary method for attackers to spread inside a target enterprise is the misuse of these administrative privileges. It is tempting to reason that these administrative credentials can be managed by conventional Identity and Access Management (IAM) systems. But privileged accounts aren t typically provisioned as user logins are. Privileged accounts are found on the network whenever physical and virtual IT assets are deployed (or changed).
White Paper 03 manufacturing Privileged Idenitities - Admin; Service Accounts Used to - Access data feeds; Enable/Disable monitoring shared file system Privileged Identities - Root Admin Used to - Add/Delete User, Change user privileges, Manage storage use. applications Privileged Identities - Service Accounts, ASP.Net, Run As Used to - Modify back-end applications, After published web-content, Access DB, Transact operating system Privileged Identities - Administrator; Root; Super User Used to - Read/Copy/Alter data; Manage security settings; Manage user accounts; Run daemons; Enable/Remove shared files. database Privileged Identities - SYS, SYSDBA, SA Used to - After schema/db configs; Modify schema objects; Manage Data network Privileged Identities - Admin; Root Enable Used to - After config settings; Manage security policies; Grant/Deny/Revoke network access; Access data feeds. backup Privileged Idenitities - Administrator; Root; Service Accounts Used to - Access transaction data; Manage archives; Purge saved files; Modify backup configs Figure 1: An inventory of privileged accounts across various layers Thus, automated software (not IAM) must discover and continuously track privileged credentials. And IT regulatory mandates including Critical National Infrastructure mandates, PCI DSS, SOX, HIPAA and others require that these credentials be frequently changed, as every shared, static, or cryptographically weak privileged identity represents a potential attack surface. These privileged passwords must also be cryptographically complex. Access to these passwords must be attributed to named individuals and audited. Because of the risks introduced by unmanaged privileged identities, industry groups cite the control and auditing of privileged access as an essential cornerstone of effective cloud security. a typical example Consider an IT setup for a bank s data center. Because of the sheer transaction volume that the system can experience at any time, there are several virtualized as well as physical servers distributing the load amongst them. Also, the regulatory mandates require each
White Paper 04 transaction to be atomic, and the system fault-tolerant. This requires the system to have multiple levels of redundancy with regular monitoring of nodes over a robust network, with regular backups. On breaking the setup into various layers, we can do a high level walkthrough. Keep in mind that each installation on each of the below layers have privileged identities that need to be managed: Network Devices layer Any networked system of this scale has a whole army of routers (wired and wireless), switches, load balancers and firewalls. The hardware surge on this layer is specifically to: a) handle the immense workload that transactional systems experience; b) and to act as the first line of defense for the entire setup by being impenetrable. Operating Systems layer As deployments of scale require multiple applications running on multiple servers, each with its own hardware and software requirements, the same environment can have Linux, Windows, Solaris or, custom OS s with multiple flavors (like CentOS, Ubuntu, Debian), and versions (like Windows Server 2003, 2008) Application layer The plethora of apps, custom-made and licensed, that run on these servers need to interact with each other, and other installations like network and OS, over the line. Credentials with access to more resources than necessary are usually configured for them. Any backdoors in these apps, in case of improperly managed privileged credentials, can compromise the whole system. Database layer Though the DB is a specialized application server, it s categorized as a separate layer due to the sizeable chunk of dedicated resources it needs. It is innermost, and the most important layer to protect, even from DBAs, as any unauthorized or mis-configured access can have disastrous consequences for the organization and its customers. Shared File System layer A fairly common need in such a setup is file sharing across applications. These can be reports, or data feeds, etc. This warrants a NAS (Network Attached Storage), or SAN (Storage Area Network) installation within the deployment. Backup layer Generally an automated task, backups themselves require privileged read-only access to data that needs to be backed-up. Sometimes, though, the back-up scripts are hard-coded with super-user credentials, which in itself is very unsafe as : a) bugs in the scripts can change the original data as it can write to it; b) and access to the script would be like handing someone the keys to the treasure vault.
White Paper 05 Monitoring layer Fault-tolerant systems need to be constantly monitored, and alerts need to be raised if something goes wrong. The automated systems that handle this requirement exist outside as well as inside the setup, and generally have deep access to all resources to properly accomplish these tasks. A breach at this layer can potentially lead to data leak about the internal configuration and will be disastrous. Large setups generally, but not always, go with a specific vendor for these devices/ applications because of economies of scale. Consider the following facts: the vendor s website a) has the bank listed as a satisfied customer; b) and has the downloadable user manuals with the default privilegedcredentials printed for all to see. This is generally enough for an attacker to get started on breaking in. Each layer above can act as a blockade(with properly managed privileged identities) or a gateway(with default, static, or weak privileged identities) for hackers. Compliance standards also require the bank to have on-site and off-site Disaster Recovery (DR) setups that can be switched over to in case of failures. Thus, the DR needs to be a reasonable reproduction of the main system, with close to 75% (if not 100%) of all nodes replicated. It is more often than not, that the DR setups once provisioned lay forgotten until the next system -wide failure. This means that not only are they not up-to-date with respect to the actual system they are supposed to fill in for, but also their privileged identities need to be excavated from long overdue reminders about updating the setup. Conclusion Now that solutions have evolved to service platforms that are designed to meet IT infrastructure requirements for managing privileged identities, certificates and other file-based secrets in large, ever-changing environments, a significant operational roadblock is removed that once prevented the largest service providers (in-house or vendor) from complying with industry and regulatory requirements.
White Paper 06 Organizations these days are aware of the potential risks of the unsecured privileged accounts in their IT environments and want to work to close these gaps. A PIM solution documents potential risks present in the infrastructure, enumerating privileged accounts by hardware platform, account and service type. It then continuously secures privileged accounts everywhere on a network and provides an audit trail of each access request. About ARCON ARCON is a leading Information Security solutions company specializing in Privileged Identity Management and Continuous Risk Assessment solutions. With its roots strongly entrenchaed in identifying business risks across industries, it is in a unique position to comprehend and identify inherent security gaps in an organizations infrastructure framework and build and deploy innovative solutions/products to significantly mitigate potential risks.