During a conversation with my colleague, Morey Haber, Senior Director of Product Management for Vulnerability at BeyondTrust, we got on the topic of privileged account audits. My specific area of focus is privileged account management, so audits of this type are a topic I frequently cover with customers and prospects.
Morey and I discussed how privileged accounts can be classified in a variety of ways, including built-in, user created, association with an employee/contractor, and anonymous. Passing an audit, in part, entails associating the activities of these accounts to users. It also requires proper management and control of those accounts.
Passing an audit on a new network, where the latest guidelines are adopted as the system is rolled out, is a fairly straightforward process. Most organizations, however, must secure environments with years of growth, acquisitions, divestitures, upgrades, redesign, application rollout, application shutdown, and, a host of other day-to-day activities. It could be said that passing a privileged account audit has a number complexities that must be overcome, including:
1. Delegation -- Delegation is critical as it requires you to permit a user or application to access the things needed to perform a task; this is also known as least privilege. The benefits of a restricted access model are many and when it comes to managing privileged accounts, risk is a key element we need to limit.
2. Inventory -- An ongoing inventory of privileged accounts is necessary as line of business applications and other corporate activities are a constant catalyst for the creating and abandonment of many of these accounts. The ongoing inventory helps to paint a clear picture of what you’re dealing with and any potential items that need to be addressed.
3. Password and Authentication Policy -- These policy requirements differ for privileged accounts. Some platforms support fine-grained policies for authentication and passwords. It is common to leverage and require soft certificates, high complexity password, OTP, and, a variety of other means to safeguard these accounts.
4. Password Reset Policy -- Rotate passwords as frequently as possible. Daily, weekly, or bi-weekly are acceptable frequencies for automating the rotation of passwords to maintain control and prevent passwords from leaking outside the organization.
5. Account Review Cessation -- Although account reviews should be done regularly, an audit is not the time to perform such an activity. Auditing helps detail what users are doing with the access they have been granted, however, it is the review or audit logs and recorded sessions that helps to ensure a trusted user or process is not abusing the privileges it was granted. These tasks should be separate.
6. (No) Hardcoded / Embedded Passwords -- Eliminate all embedded and hard coded passwords. This requires a change in mindset from making something work to making something secure. When developers design apps and temporarily hardcode a password to "make work," it is easy to forget to remove the password. A common breach for many organizations is due to poor practices around embedded passwords in scripts and applications.
7. Education -- Education should not be limited to traditional end users. Providing regular education for systems administrators, developers, application owners and others about the proper ways to manage credentials is important.
Organizations that take the approach of managing privileged accounts with goals of security, segmentation, and best practices find themselves more successful when audit day arrives.
Have questions about any of the steps shared above? Let me know in the comments and we can take a deeper dive into what you may be experiencing at your company.
