Preventions
- ID: PV055
- Created: 25th April 2025
- Updated: 25th April 2025
- Platforms: Android, iOS, Windows, Linux, MacOS,
- Contributor: Patrick Mkhael
Enforce Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) is a critical component of a comprehensive security strategy, providing an additional layer of defense by requiring more than just a password for system access. This multi-layered approach significantly reduces the risk of unauthorized access, especially in cases where an attacker has obtained or guessed a user’s credentials. MFA is particularly valuable in environments where attackers may have gained access to user credentials via phishing, data breaches, or social engineering.
For organizations, enabling MFA across all critical systems is essential. This includes systems such as Active Directory, VPNs, cloud platforms (e.g., AWS, Azure, Google Cloud), internal applications, and any resources that store sensitive data. MFA ensures that access control is not solely dependent on passwords, which are vulnerable to compromise. Systems that are protected by MFA require users to authenticate via at least two separate factors: something they know (e.g., a password), and something they have (e.g., a hardware token or a mobile device running an authenticator app).
The strength of MFA depends heavily on the factors chosen. Hardware-based authentication devices, such as FIDO2 or U2F security keys (e.g., YubiKey), offer a higher level of security because they are immune to phishing attacks. These keys use public-key cryptography, meaning that authentication tokens are never transmitted over the network, reducing the risk of interception. In contrast, software-based MFA solutions, like Google Authenticator or Microsoft Authenticator, generate one-time passcodes (OTPs) that are time-based and typically expire after a short window (e.g., 30 seconds). While software-based tokens offer a strong level of security, they can be vulnerable to device theft or compromise if not properly secured.
To maximize the effectiveness of MFA, organizations should integrate it with their Identity and Access Management (IAM) system. This ensures that MFA is uniformly enforced across all access points, including local and remote access, as well as access for third-party vendors or contractors. Through integration, organizations can enforce policies such as requiring MFA for privileged accounts (e.g., administrators), as these accounts represent high-value targets for attackers seeking to escalate privileges within the network.
It is equally important to implement adaptive authentication or risk-based MFA, where the system dynamically adjusts its security requirements based on factors such as user behavior, device trustworthiness, or geographic location. For example, if a subject logs in from an unusual location or device, the system can automatically prompt for an additional factor, further reducing the likelihood of unauthorized access.
Regular monitoring and auditing of MFA usage are also critical. Organizations should actively monitor for suspicious activity, such as failed authentication attempts or anomalous login patterns. Logs generated by the Authentication Service Providers (ASPs), such as those from Azure AD or Active Directory, should be reviewed regularly to identify signs of attempted MFA bypass, such as frequent failures or the use of backup codes. In addition, setting up alerts for any irregular MFA activity can provide immediate visibility into potential incidents.
Finally, when a subject no longer requires access, it is critical that MFA access is promptly revoked. This includes deactivating hardware security keys, unlinking software tokens, and ensuring that any backup codes or recovery methods are invalidated. Integration with the organization’s Lifecycle Management system is essential to automate the deactivation of MFA credentials during role changes or when an employee departs.
Sections
| ID | Name | Description |
|---|---|---|
| ME007 | Privileged Access | A subject has privileged access to devices, systems or services that hold sensitive information. |
| PR027 | Impersonation | The subject deliberately adopts or fabricates an identity—visually, digitally, or procedurally—to gain access, mislead stakeholders, or enable a planned insider event. Impersonation may occur in physical environments (e.g., unauthorized use of uniforms or cloned ID cards), digital platforms (e.g., email aliases or collaboration tools), or human interactions (e.g., job interviews). These behaviors typically precede unauthorized access, credential misuse, sabotage, or data exfiltration, and may allow subjects to operate without attribution or delay detection.
Impersonation is a high-risk preparatory behavior that often precedes direct misuse of trust. By assuming a false identity or misrepresenting role, authority, or affiliation, the subject gains unauthorized access or influence—without triggering traditional insider threat controls. |
| ME024.003 | Access to Critical Environments (Production and Pre-Production) | Subjects with access to production and pre-production environments—whether as users, developers, or administrators—hold the potential to exploit or compromise highly sensitive organizational assets. Production environments, which host live applications and databases, are critical to business operations and often contain real-time data, including proprietary business information and personally identifiable information (PII). A subject with access to these systems can manipulate operational processes, exfiltrate sensitive data, introduce malicious code, or degrade system performance.
Pre-production environments, used for testing, staging, and development, often replicate production systems, though they may contain anonymized or less protected data. Despite this, pre-production environments can still house sensitive configurations, APIs, and testing data that can be exploited. A subject with access to these environments may uncover system vulnerabilities, access sensitive credentials, or introduce code that could be escalated into the production environment.
In both environments, privileged access provides a direct pathway to the underlying infrastructure, system configurations, logs, and application code. For example, administrative access allows manipulation of security policies, user permissions, and system-level access controls. Similarly, access to development environments can provide insights into source code, configuration management, and test data—all of which could be leveraged to further insider activity.
Subjects with privileged access to critical environments are positioned not only to exploit system vulnerabilities or bypass security controls but also to become targets for recruitment by external actors seeking unauthorized access to sensitive information. These individuals may be approached or coerced to intentionally compromise the environment, escalate privileges, or exfiltrate data on behalf of malicious third parties.
Given the sensitivity of these environments, subjects with privileged access represent a significant insider threat to the integrity of the organization's systems and data. Their position allows them to manipulate or exfiltrate sensitive information, either independently or in collaboration with external actors. The risk is further amplified as these individuals may be vulnerable to recruitment or coercion, making them potential participants in malicious activities that compromise organizational security. As insiders, their knowledge and access make them a critical point of concern for both data protection and operational security. |
| PR027.002 | Impersonation via Collaboration and Communication Tools | The subject creates, modifies, or misuses digital identities within internal communication or collaboration environments—such as email, chat platforms (e.g., Slack, Microsoft Teams), or shared document spaces—to impersonate trusted individuals or roles. This tactic is used to gain access, issue instructions, extract sensitive data, or manipulate workflows under the guise of legitimacy.
Impersonation in this context can be achieved through:
The impersonation may be part of early-stage insider coordination, privilege escalation attempts, or subtle reconnaissance designed to map workflows, bypass controls, or test detection thresholds.
Example Scenarios:
|