Risk
11/4/2011
09:03 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Tech Insight: Managing Privileged Accounts

Strategies for identifying, managing, and auditing privileged accounts

Whether you're a company trying to comply with PCI requirements, an energy utility looking to get a handle on standards set forth by NERC, or the typical enterprise, separation of privileges and privileged account management can be a daunting task. The seemingly simple undertaking of inventorying privileged and shared accounts can be difficult in an environment with differing technologies. However, the need to identify those accounts and manage and audit them is a critical need for many companies -- though not one that can be done quickly and without proper planning.

Compliance requirements for privilege separation and monitoring of sensitive activities performed by privileged accounts give the phrase, "Who watches the watchers?" new meaning. And with the general consensus by users that IT administrators have too much control, it is important to have checks and balances in place to prevent abuse.

When dealing with the issues surrounding privileged accounts, enterprises have to approach it slowly and methodically to be sure business and security needs are met, as well as compliance. Jumping in too quickly just to check off a box for the auditor will cause numerous headaches. Problems can range from locked-out accounts and the failure of scripts that rely on embedded passwords, to business processes being delayed, causing loss of revenue.

The first step is to inventory privileged accounts, passwords, and how they are used. The last part is extremely important as shared passwords, service accounts, embedded devices, legacy systems, and automated scripts need to be considered. Email surveys and interviews with IT and users can be used to identify privileged and shared accounts. In an ideal world, the account provisioning process included a specific naming convention to identify these types of accounts, but even with those guidelines in place, things slip through the cracks.

Log monitoring and searching files (e.g., automated scripts) can help identify the accounts that humans aren't typically involved with using and have likely been forgotten about. The logs can be used to identify accounts that are used at regular intervals to indicate an automated process. Similarly, logins occurring late at night could be the results of automated backup processes.

Searching for passwords in scripts can be difficult because the creators could have named the variables holding the passwords anything such as PWD, password, PW, or scr_pwd. Finding them all could take several passes through the different systems; even then, some could go unnoticed until the passwords are changed later and some automated process suddenly stops working.

The inventory process can be time-consuming but well worth the effort because it helps security and IT get a handle on accounts and passwords that could have gone unmaintained for a long time. Skimping on this stage can lead to some of the issues mentioned above in which passwords are changed without realizing what systems and processes they will impact.

Once the passwords, shared accounts, and where they are used has been identified, the difficult decision of how to manage them must b made. Some organizations might be able to get by with developing their own in-house processes for managing a small number of privileged accounts and passwords. Midsize to large businesses, however, will likely need to invest in a privileged identity management solution.

There are quite a few PIM offerings to choose from, including Cyber-Ark, IBM, BeyondTrust, and Lieberman Software, but they all will typically have the same base features, starting with the ability to manage shared accounts and passwords for service accounts, scripts, and embedded devices. Management includes provisioning new passwords, changing passwords on a regular schedule or as the need arises (e.g., compromised account), and auditing to detect misuse. Authorization of privileged account usage can be performed based on roles or at the time of use, requiring the user to receive approval before the account can be used.

Beyond the base management and authorization features, PIM products also can provide granular access to systems and commands based on the user's group memberships, time of day, and security level or department of system being accessed. Multifactor authentication can be required depending on the policies of the organization and the sensitivity of the systems being accessed.

Organizations requiring extra auditing for extremely sensitive systems will like the ability to record the session during which the privileged account is used. For example, Cyber-Ark's Privileged Session Management Suite provides session recording capabilities for servers, databases, and virtual environments. By recording the session, auditors can review every action that takes place, and system administrators can review the recordings to identify the cause of a system outage that occurred as a result of the use of a privileged account.

With compliance requirements pushing for privileged account monitoring and management, enterprises have numerous PIM solutions to choose from that can meet those needs, no matter how large or small. The important thing to remember is not to rush the initial stages of account and password discovery to prevent accidental downtime and possible revenue loss.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web