Share
Privileged accounts represent one of the largest potential security vulnerability an organization faces today. In the hands of an external attacker or malicious trusted insider (such as IT administrators), privileged accounts allow attackers to take full control of an organization’s IT infrastructure, disable security controls, steal confidential information, commit financial fraud and disrupt operations.
The first step towards securing an organization network is to understand what vulnerabilities an attacker is likely to exploit. The primary task of an attacker who has infiltrated a network is to initiate escalation of privileges, which is how an attacker attempts to gain more access from the established foothold that they have created. After an escalation of privileges has occurred, there is little left to stop an intruder from whatever intent that attacker has. Attackers can use many different mechanisms to achieve an escalation of privileges, but primarily they involve compromising existing accounts, especially those with administrator equivalent privileges.
Organizations usually implement security control over standard user accounts, but often do not exert much control over service accounts, thereby making such accounts vulnerable and popular targets for attackers. After an attacker has compromised a network to the point where a critical account with high privileges is compromised, the entire network can never be considered as completely trustworthy again unless it is flattened and completely recreated. Therefore the level of security for all manner of high privilege accounts and service accounts is a very important aspect of any network security initiative.
These are often built-in accounts that services use to access resources they need to perform their activities. However, some services require actual user accounts to perform certain functions, and many businesses still employ the practice of using domain accounts to run services as well.
Service and high privilege accounts uses the term critical account to describe default accounts that are considered high risk because they have either high-level privileges or present elevated risks due to their ubiquitous use.
Security Challenges:
Unsecured administrator level accounts and service accounts present a significant risk to the organization. It is fairly common to find service account management that reveals vulnerabilities such as old passwords, default vendors password or service accounts that never change their password.
Common issues that organization should consider:
- How to protect against internal and external threats related to account management and employee work-around attempts.
- How to identify all service and application accounts in use on the network and local computers.
- How to change password to secure sensitive services, administrators and application-related accounts.
- How to determine what accounts are associated with services and applications.
- How to isolate service accounts from user account password policies.
Operational Challenges:
Services are executable that are often run without user interaction and launched automatically when an operating system starts up, which is why services and service accounts are often overlooked as a unique security risk in a business network. Even when the security risks are understood, service account management can be a rather complex ordeal, considering that a simple password change may require several other changes to prevent outages.
In addition, the use of domain accounts to run services is still a common practice because it has been easier to manage services across the domain instead of on local servers, despite the security risks associated with this practice.
Service account maybe in use not only by services but also by other objects such as: Schedule Tasks, Application pools, COM+/DCOM, configuration files and even hard coded in an executed code. Services store the information about the service account and password that they use in the registry, but other objects can store it in other places with no synchronization. Therefore, when a service account password change occurs in Active Directory, the account will lockout when Kerberos authentication will occur.
Solution:
Using CHS, system administrators can see all the information they need before changing high-privilege/service accounts passwords, know which application will be affected and be sure the password change process will not damage the operations.
The process will change and synchronize on demand or in schedule the high-privilege/service account password in all places it stored (Active Directory and all other objects).
As part of the CHS Learning Mode capabilities, it provides discovery mechanisms to detect and collect the high-privilege and service accounts information. After collecting the information to the CHS database, a process correlates the information with other information from all servers and creates profile to the high-privilege/service account user.
The profile includes all the information to identify the services account activity, which objects use the account, where the password stored and which application that user uses.
Using CHS, system administrators can see all the information they need before changing high-privilege/service accounts passwords, know which application will be affected and be sure the password change process will not damage the operations.
The process will change and synchronize on demand or in schedule the high-privilege/service account password in all places it stored (Active Directory and all other objects).
