Let’s say an IT server is built on an Operating System that is managed and maintained by administrators with varying degrees of access, whether the root for UNIX, local administrator for Windows or other sub-systems that have their own privileged service accounts. The same server may require middleware and other installed applications that in turn require a database and web server with service accounts that may be managed by other IT teams with different roles and responsibilities.
With three operational groups leveraging different service accounts, there will be overlap with the web and database teams leveraging root/administrator accounts from time to time. Add in the applications, developers and teams that manage them, and there are now upwards of five teams with four groups of service accounts. When overlaying various internal compliance processes, understanding permissions and access can get even more complicated.
We’ve already highlighted the who of your organizational accounts — but where do we go from there?
Documenting the Core Elements of Your Unique Organizational Structure
For the program to be effective, there must be a complete understanding of the relationship between the various IT assets impacted by the change. Think systems, accounts, applications and processes that span the entire enterprise.
If you have a global Windows admin team, for instance, then a regional scope will be harder to control than one that focuses just on Windows servers and excludes other platforms. Similarly, be careful that you understand everything in your scope and don’t exclude anything which can’t reasonably be separated out.
If, for instance, you have very heavy systems account usage by applications, then excluding application use of privilege may make it impossible to deliver truly effective PAM. Even before you have started to build out your PAM control infrastructure, you should document the core elements within your unique scope.
Understanding Use Case
The information required to do this analysis comes from a variety of disparate data sources – and based on the use case, the methodology can be vastly different. Understanding use case can also help drive the ownership analysis configurations. For example, when accounts contain “username_adm”, one could ascertain that the account is an alternate administrative account owned by username. Or, perhaps an account called “App_X4T5” can reference an entry in your CMDB showcasing the owner of a certain application identified by code X4T5.
There may be a single account called “SVCbackup” that is a member of the local administrators group. This account may be sprawled across nearly every server across the organization and impacts nearly every application hosted on those servers. In your CMDB, you may have documented server owners, so do you simply choose one since the account has local admin access on the chosen server? No. Instead, this account should be owned by the Infrastructure team that owns the backup functions.
Reporting on Security Issues
Once you’ve compiled the discovery of all privileged access, catalogued ownership and understood the use case, IT can begin to measure the degree of risk and discover where the true security issues lie.
Once the source systems have been scanned and there is an inventory of privileged accounts, IT should focus initially on the accounts that have the highest reach. These are ideal places to start remediating risk that put organizations on the path to better privileged account management. Armed with the broad analysis of account type, use case, ownership and business area provides the actionable intelligence for management to effect change across the enterprise.
Knowing What to Certify
As only asset owners (account/server/application) know which accounts should be onboarded into a password vaulting solution, as well as who requires access and what they need access to, certifying accounts is equally as important as identifying ownership.
To start validating ownership, simply ask the question, “Are you the owner?” as it is a critical first step before moving onto more detailed questions. If the individual is not the owner, it is inherent that the solution provides a mechanism to propose a new owner or supply additional information of value to the project team. Again, some accounts may no longer be needed.
Pruning Access
With the visibility and ability to report on access and ownership, remediating unnecessary accounts is the next step. Remediating stale and unused accounts from the systems creates an immediate reduction in risk with little or no impact to the end-users.
This will require identifying each account’s most recent log-on date per endpoint (its stale date) while removing the accounts on each endpoint that are defined as stale.
For a workflow application to be effective it should integrate with a change management solution. In three basic steps, this requires identifying any accounts that are unnecessary, submitting a change request to remove access, then removing the privileges and access from the endpoint.
A successful and compliant end state should pull together the required reporting, analysis and certification on an ongoing basis, ensuring unmanaged accounts are identified, access is pruned regularly and an ongoing measure of key risk indicators is available to IT management for review. And that’s just the start.
Download our whitepaper, Privileged Access Management Filling The Gaps to learn more.
