This blog was written by an independent guest blogger.
Most cyberattacks originate outside the organization. Numerous articles, vulnerability reports, and analytical materials prove this fact. External attacks are usually carried out based on the following scenario:
- Overcoming the perimeter of the organization. This can be carried out directly or using a shadow payload or using a phishing attack aimed at compromising the user's system.
- Establishing a connection. At this stage, the attacker's task is to create a stable channel for delivering various hacking tools and auxiliary data onto the target system.
- Activity within the network perimeter. Next, the intruder examines the topology and resources of the network. He is also looking for opportunities to collect additional access parameters (usernames and passwords), elevate privileges, or use already existing compromised accounts for unauthorized access to systems, applications, and data.
- Reaching the goal of the attack. Ultimately, the attacker collects, packs, and sends data back to his servers. Cybercriminals may also perform some destructive actions aimed at data or systems.
Obviously, it is impossible to provide protection at all stages of an attack using only one type of protection. It is tough to do without a dedicated team and security solutions like firewalls, intrusion detection, antiviruses and more. But, in addition to these familiar security solutions, a set of measures related to the user management and audit of privileges is also required.
The use of a privileged account management infrastructure can be a very effective measure to counter cyberattacks at all stages of their implementation: from reducing the attack surface to detecting unauthorized activity, thus reducing negative consequences of unauthorized access.
Different types of privileges
To understand how privileges can be used to conduct attacks, it is necessary to define this concept first. In a somewhat simplified way, a privilege is a special right or permission inaccessible to the general mass of users. This includes the ability to install software, change its settings, manage backup operations, and more. The presence of such rights for a user does not mean that he becomes an administrator. It indicates that at a certain level of the detailed hierarchical structure, the user is endowed with appropriate powers that go beyond the basic set that the standard user has.
The basic approach assumes two levels: the regular user and the administrator. Some organizations add two more levels to this basic hierarchical structure: guest, no access.
It is essential to understand that the given basic concept of privileges is related to macro levels. However, providing the most reliable protection is possible only at the micro-levels of privileges. An example of this is access to specific files.
Regardless of the user authentication mechanism used, privileges must be built into the operating system, file system, applications, databases, hypervisors, cloud platforms, network infrastructure.
Privilege management problems
A regular user has basic privileges sufficient to carry out tasks in accordance with his job responsibilities. In a typical organization, there might be 10 – 100 -1,000 different roles for regular users. Each role is endowed with a particular type of access to systems, applications, and data, depending on the nature of the work performed by the user.
Obviously, in some cases, a user can have several roles at once. It is pretty common for many organizations to grant users more privileges than are required to fulfill their job responsibilities. Since malicious activity often does not require all admin rights, this situation significantly increases the risk of a successful insider attack.
On the other hand, there is a widespread set of problems arising with interactions with contractors and numerous service providers. Support provided by many vendors involves remote connections to the serviced components. These components are also connected to the corporate network. And this means that the security of the network environment of the target organization often depends on the protective measures used by third parties.
The implications are clear: the vendor's remote access parameters are not under the direct control of the customer. Obviously, when using an infrastructure that includes different networks with different user directories and different security policies, it is tough to comply with all information security requirements.
There are plenty of cases when external attackers obtain usernames and passwords to a system controlled by a vendor and then exploit vulnerabilities or poorly managed privileges to attack the target organization's network.
Issues with terms
Once an authenticated user session has been established, regardless of whether it is legitimate or became possible as a result of a successful attack on the user's password, the purpose of the intruder, as a rule, is to increase privileges and then obtain unauthorized access to other resources.
Attackers may use the following methods to obtain administrator privileges:
- Compromised passwords
- Security vulnerabilities
- Configuration flaws
- Malicious code
- Social engineering
Most methods of gaining unauthorized privileges are well known. The set of defense mechanisms to counter such attacks can generally be referred to as Privileged Access Management (PAM). Other naming conventions are also quite widespread: Privileged User Management (PUM), Privileged Identity Management (PIM).
Often, the given terms are interpreted as interchangeable. Sometimes, however, there appears confusion in terms of concepts when describing solutions existing on the market. A natural question may arise: “Is there a difference between the listed terms, and how significant is it?” Since the answer to this question will probably help understand the subject area more deeply, it is worth highlighting modern views in relation to these concepts.
Public vs. personal
The difference between Privileged User Management (PUM) and Privileged Identity Management (PIM) seems to lie in the personal perception plane. The fact is that a privileged user means a particular human, a separate personality. The term privileged user credentials is easier to relate to just a tool, an object, by which human users can perform particular tasks.
The use of a model within which control is carried out over the object (user identification info) and not over the subject (user) makes it possible to convey the essence of the corresponding processes more accurately:
- From the point of view of common sense, in practice, it is hardly justified to have a person who is privileged in all cases. You do not actually need an omnipotent administrator who needs to perform only operations that require special privileges. It is advised to have an individual employee who, from time to time, needs to obtain a special type of access to perform some tasks.
- The emphasis needs to be the user's privileged credentials rather than the user themselves. This allows the entity to be viewed more naturally as the target of an attack by both external and internal attackers.
- Identity information is an object, a tool that makes it easier for an organization to enforce management policies and implement the necessary security mechanisms. People should be less sensitive to the fact that restrictive measures are taken only in relation to this tool and not to the account holders directly.
Native vs. acquired
PAM is the process by which users can request elevated access rights to an application or system on behalf of their existing account to do the task that is not available to them under their current access level.
When a regular user needs administrative access, PAM provides them with the opportunity to make a request. Once approved, the user's request will be approved for their account. In addition, PAM can enforce this additional permission only for the duration of the time it takes to complete the task.
A characteristic feature of PAM is that it assumes that a regular user should never, under any circumstances, be granted elevated privileges once and for all times. By keeping access level to a minimum but providing a simple mechanism to increase it when the need arises, PAM helps reduce information security risks.
It is possible to manage many different elevated access levels: basic user, power user, user with basic admin rights, database administrator, system administrator, etc.
The concept of PIM, in contrast to PAM, is aimed at managing existing accounts: administrator, root, etc. These accounts, as a rule, are built into applications or systems and cannot be deleted. They are often limited in number and are therefore shared by different people in the organization. License restrictions also contribute to this separation, as organizations may prefer the cost-effective use of a single account instead of many. In turn, this factor serves as an obstacle to the use of multifactor authentication. In most cases, only passwords are used for authentication.
Some large companies use PIM (PUM) because they believe that a limited and strictly defined number of privileged accounts allows greater control over how users access information resources. The advantage of PAM here is an opportunity to look more deeply at the problem of determining who exactly received the privileged access, what kind of access he received, and over what time he used it.
It should be noted that organizations are not forced to make a mutually exclusive choice between PIM (PUM) and PAM. You can use a combination of these techniques, taking advantage of each of them.
Authentication without PAM
The lack of an effective PAM strategy in an organization leads to the following problems that are directly related to user authentication procedures:
- Sharing privileged accounts for the sake of convenience (a disadvantage inherent in the PUM concept). It is difficult to determine a specific person’s actions performed on behalf of the account.
- The factor of using the built-in access parameters, which is vulnerable to various attacks. Privileged access settings are used, among other things, for mutual authentication of applications, as well as for application access to databases. At the same time, systems, applications, devices are often supplied with built-in access parameters by default. They can be disclosed by an intruder since they may be stored in the form of plain text – in a file, script, or hardcoded into the program code. Unfortunately, there is no way to manually discover or centrally manage passwords stored inside applications or scripts. Protecting embedded passwords requires separating the password from the program code so that when the password is not in use, it is securely stored in a central repository.
- The use of SSH keys to automate secure access processes increases the risk. Organizations can operate a massive variety of SSH keys, many of which have long been forgotten and not used. These keys can be found by an intruder and used to overcome the perimeter of the organization.
- The practice of sharing privileged access policies and control of access parameters with third-party service providers. Interaction with third parties introduces a problem related to ensuring compliance of authentication procedures with established information security requirements, including secure storage of passwords, adherence to policies, etc.
Conclusion
The primary purpose of PAM is to protect against accidental or deliberate misuse of privileged access settings. This threat is especially relevant for fast-growing organizations entering new markets or implementing business expansion initiatives. Obviously, the larger and more complex the information system of an organization is, and the more users it has, the more acute the problem of distribution of privileges becomes.
The PAM strategy provides a secure and workflow-optimized method for authenticating and monitoring the activity of all privileged users by providing the following core capabilities:
- Granting privileges to users only in relation to those resources for which they are authorized.
- Granting access rights when necessary, and revoking access rights when the need for it disappears. This includes reacting automatically upon reaching certain conditions in terms of time, number of uses, approvals, tickets in the support system, etc.
- No need for privileged users to know system passwords.
- Association of privileged activities with a specific account and – further – with a person.
- Comprehensive auditing of privileged activity through session recording, logging of keystrokes, and monitoring application performance, etc.
PAM technology enables these procedures to be followed for local or domain administrator accounts, services, operating systems, network devices, databases, applications, as well as SSH keys, clouds, and social networks.
The post Privileged account management challenges: comparing PIM, PUM and PAM appeared first on Cybersecurity Insiders.
November 18, 2021 at 09:10PM
0 comments:
Post a Comment