Process - Service Accounts Ownership

Service Accounts, the accounts that lack TLC since the day they are created rapidly to meet the requirements of a new implementation or for troubleshooting purpose.

The next in line are Service Prinicipals which are heavily used in Cloud Environments (Azure/AWS/GCP).

This is a manual task at the moment although there are several IAM Management Tools now to monitor them in an automated manner.

Not only that, almost every company is now working on automating this manual process of creating, maintaing, reviewing, deleting Service Acocunts into the IAM Management Tool.

To effectively automate this manual tedious task & process, I will provide my assistance to my level best to carry forward to the IAM Management Tool in a seamless smooth manner.

There are two ways to go about this:

1. Simple & Straightforard: You can simply and automatically get the IAM Tool to perform a full discovery & view them in a centeralized management console and begin the automated onboarding and management of new service accounts.

   However,

   1. This can lead to discovered service accounts missing information.

   2. Will need to set time & effort to update the necessary information which may be considered not important at the moment.

   3. Need to verify, if updating the details at the IAM tool will write to AD or will need to do at the AD level and re-discover the updated information.

   4. If need to re-discover, there might be a delay in monitoring of the service accounts as well as on-boarding new accounts, as a standardized approach needs to be defined.

   5. If were to proceed without re-discovery, this will lead to no uniform update of details of all Service Accounts found except for the new ones which are automated.

   6. If it's automatically reflected on the IAM Tool, upon updating at the AD level, than able to proceed ahead with the automated process.
      

      
      

2. Manual & Hardwork (Will Pay Off): You can follow the below steps to have a clean, clear, accurate information of Service Accounts at the source of truth, in the AD. It is indeed a manual task at first, but it will develop the right mindset and the standardized process on automated onboarding & managing new service accounts.

   
   

   1. Whenever there's a ticket rasied or a request for a new service account, the below steps can serve as a checklist.
      

   2. When the information is provided and reflected in the AD, it will turn into a standardized on-going process in the organization and can bring it forward to the IAM Tool for a smooth and seamless automated onboarding, managing, monitoring, reviewing & reporting of Service Accounts.
      

   3. With an IAM Tool or not, this is indeed the right way of creating new service accounts, managing them, reviewing them & reporting them with accurate & comprehensive details reflected at the AD itself, the source of truth.

Finally, you can create a Service Accounts Review through the IAM Tool and peform the review every 6 months.

Read Service Accounts Fundamentals: https://github.com/dcdiagfix/AD-ServiceAccounts-FUNdamentals/blob/main/AD-ServiceAccounts-FUNdamentals.md

---

The first step is to have an inventory of all the:

Service Accounts - On-Prem AD & GCP Service Principals - Azure

IAM Role (aka Service Principals) - AWS

Reach out to the AD Administrator to retrieve the full list of Service Accounts/Service Principals/IAM Roles.

When you receive the list, ensure you got the following details:

(This is a Starting Point to begin, add in columns when needed. Modify the columns accordingly for Azure/GCP/AWS)

Service Accounts Inventory.xlsx

Download XLSX • 8KB

---

Note: *** This particular task is excruciatingly manual, tiresome, in trying to find the rightful owner, the constant need to follow-up and obtaining accurate information. But this is a one-time effort, hence do not let it deter you from completing it. The effort, the hardwork & the time WILL pay off in the future. ***

The second step is to obtain thorough information about the Service Accounts from the Relevant Owners.

In this step, it's important that you assign Owner's Name, Designation, Email Contact to each service account for responsbility & accountability purpose.

Also, it's important to identify the current permissions that are being assigned.

Reason:

1. It will provide them the visibility and the awareness of how many Service Accounts are being created for their past, current & future needs.
   

2. These Service Accounts can be Local/Domain which will be considered as Privileged Service Accounts.
   

3. This will prevent the piling up of the Service Accounts as redundant, duplicate, dormant and orphaned & allows them to practice due-dilligence to clean up.

   
   

4. It also provides them with an accountability to review & maintain only the necessary service accounts on a regular basis as well as ensuring least of privilege permissions are assigned.

---

The third step is to further enquire about the permissions assigned to the Service Accounts.

1. There are Local Admin Service Accounts & Domain Admin Service Accounts
   

2. Will have to identify if they are considered Privileged Accounts? -

   1. Are they performing any highly sensitive tasks with privileged permissions?

   2. If they happen to be grouped in 'Admin Groups', are they considered Privileged?
      

3. Which Environment are they being used in & the relevance of the permissions assigned?
   

   1. In Production Environment - To be very careful of the permissions assigned and not assigning ALL for the sake of making things run/or for convenience purpose - This will lead to huge impact if breached/attacked.

      
      

   2. In UAT / Staging / Pre-Prod - Usually, this is where least of privilege permissons must be assigned to ensure it's working smooth and seamless prior to the migration to Production Environment.
      

   3. In Non-Production / Development Environment - Although it's understandable to have all permissions for testing purpose, justification or the timeline is required for monitoring purpose.

This is where the debate/unhappiness/minor arguments starts to take place.

However, from Security standpoint, they need to provide clear justification as to why those permissions are required upon validation.

They can reach out to Principal Vendor for assistance, or they can demonstrate the issues occured when certain permissions are not assigned and provide it as a documentation with screenshots.

Justifications must be reviewed, validated & approved by Security Team.

---

The fourth step is to validate the date created, the last login activity & the last password change.

• When you compare the date created & the last login activity, you will notice some discrepancies. In such situations, reach out to find:
  

  • Or is it a redundant/duplicate account that was created wrongly? - Sometimes, the account was NEVER logged in except for the date of creation.

    
    

  • If the account is a dormant/orphan account? - The last login could be 2-4 years ago and no longer actively used. In such situations, the recommended option is to disable for 30 days & delete them 30 days later.

Usually it's mentioned that Service Accounts Password have NO expiry date or change after 2 years.

However, it's now highly recommended to have a automated password rotation policy for Service Accounts. The password change duration is to be further discussed with Security Team to meet security compliance and standards.

---

The fifth step is to identify how & where the password is stored.

Usually if you were to notice the date of creation, anywhere from 2000s to 2021-2022, the password could be manually created and stored in an excel file, in a notepad or in a password manager.

It could be a simple password created by the user or a random generated password.

This will need to be identified and work on the process on how to migrate to the automated tool for authentication & authorization as well as password rotation.

---

The sixth step is to identify how are the Service Accounts Grouped or Standalone?

You willl definitely come across various ways on how the Service Accounts are created.

• Some will be in certain User/Application/Admin/Server/Database groups and NOT in the one dedicated specific group for Service Accounts.
  

• Sometimes, group naming convention will have a slight difference to differentiate different purpose for Service Accounts grouping. - This also serves a good opportunity to perform hygiene, clean-up.
  

• There are times where the Service Accounts are just by its own and no grouping.

  • In such instances, will need to refer to organization's security standards for a discussion with Security Team to determine if it's acceptable for Service Accounts to be standalone or needs to be grouped in a specific group.
    

• Need to ensure, they are not in nested groups - Likely not able to discover automatically by the IAM Tool and unable to perform a Service Accounts Review on them, will lead to missed out service accounts.

---

The seventh step is to obtain the purpose of the Service Account.

Below are the requirements for defining the purpose, if it's not clear:

1. Functionality of the Service Account:

2. Read Only / Read & Write / Modify / Delete Access:

3. For which application(s):

4. Which Environment:
   

Some examples:

• This Service Account has Read & Write access to establish connectivity from IAM Technology to On-Prem AD to retrieve User & Group details in Production Environment for provisioning, restoring & revoking User Access.
  

• This Service Account has Read Only access for Application A to read data from Database in Non-Production Environment.
  

• This Service Account has Delete Access to remove local users from application administration platform in the Pre-Prod Environment, hence it's considered Privileged Service Account. -- Deleting of Users should be performed by Administrator, not Service Account.

---

Once you have completed the above, your excel file is looking remarkably wonderful with ALL the details captured and ready to be updated with the latest details in the Active Directory first.

A Change Request is required to update the changes accordingly. This might take at least 1-2 months provided you have a great relationship with the AD team.

This particular task is crucially important to Business Owner, Application Owner & Team, Cloud Team, Server Team, Database Team, Security Team & AD Team, but without AD team's assistance, this will turn into a dormant document with words soon enough if not implemented timely.

Why? Because:

1. As the growing pace for new services & applications keep increasing, the quick need to create service accounts/service principals needs to be met.
   

2. If we do not implement the process for creating service accounts/service principals based on the detailed findings above, the AD team is likely not to follow a standardized approach.

Inevitably, you will have to repeat the above 7 steps for the new set of accounts. Tt will become a time-consuming task which will be neglected and postponed, creating gaps. When you return to do this task, the list will be much larger, and you must complete it and strongly emphasise for the changes to be updated and reflected in AD.

---

Onboarding of IAM Tool:

Prior to the oboarding of the IAM tool, the above mentioned discovery & changes are to be completed. After they are being verified, it's now ready to be retrieved by the IAM tool to auto-populate all the Service Account details.

Note: You will need to verify with the IAM vendor if there are any other information they require for an accurate and comprehensive retrieval of information for monitoring, reviewing & reporting on Service Accounts.

---

Some reads on Service Accounts:

Service Accounts Fundamentals: https://github.com/dcdiagfix/AD-ServiceAccounts-FUNdamentals/blob/main/AD-ServiceAccounts-FUNdamentals.md

What is Service Account Management?: https://www.securden.com/educational/service-account-management.html

Service Account Management 101: Back to Basics: https://delinea.com/blog/service-account-management-101

Service Account Best Practices: How to Manage and Secure Them: https://www.beyondtrust.com/blog/entry/how-to-manage-and-secure-service-accounts-best-practices