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.
Dealing with Privileged accounts outline both security and 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.
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.
CalCom CHS can dramatically simplify the process of changing service accounts passwords. The CHS learning mode indicates where the passwords are stored. After mapping the locations and objects were passwords are stored all needed is a simple, regular password change.
CalCom CHS for MSFT SCOM/OMS is a server-hardening solution that addresses the needs of IT operations and security teams. The CHS software-based solution implements a proactive, automated hardening approach that ensures that servers are constantly hardened, secured and compliant. The CHS three-step process automates security baseline policies deployment procedures in a cost effective fashion, eliminating server down time and configuration drifts.