Audit Logging

A subject may search for, or otherwise explore an IT Ticketing System to identify sensitive information or to identify credentials or other information which may assist in pivoting to other sources of sensitive information.

A subject has privileged access to devices, systems or services that hold sensitive information.

Data loss refers to the unauthorized, unintentional, or malicious disclosure, exposure, alteration, or destruction of sensitive organizational data caused by the actions of an insider. It encompasses incidents in which critical information—such as intellectual property, regulated personal data, or operationally sensitive content—is compromised due to insider behavior. This behavior may arise from deliberate exfiltration, negligent data handling, policy circumvention, or misuse of access privileges. Data loss can occur through manual actions (e.g., unauthorized file transfers or improper document handling) or through technical vectors (e.g., insecure APIs, misconfigured cloud services, or shadow IT systems).

Physical security credentials, such as an ID card or physical keys, that were available to the subject during employment are not revoked and can still be used.

API keys that were available to the subject during employment are not revoked and can still be used.

SSH keys that were available to the subject during employment are not revoked and can still be used.

The subject makes unauthorized changes to access controls resulting in harm. Examples include resetting/changing passwords, locking accounts, or deleting accounts.

The subject provides unauthorized party access to a collaboration platform, such as Slack, Teams, or Confluence that exposes them to information they are not permitted to access. This can be achieved by adding an existing organizational account, or a guest account.

The subject intentionally weakens or bypasses network security controls for a third party, such as providing credentials or disabling security controls.

The subject develops a custom API that monitors specific activities, network traffic, and system changes within the target environment. The API could monitor HTTP/HTTPS requests directed at sensitive endpoints, track modifications to security group settings (such as firewalls or access policies), and identify administrative actions like changes to user accounts, data access requests, or logging configurations.

This tripwire API is embedded within various parts of the environment:

• Cloud Services: It hooks into serverless functions, containers, or virtual machines to monitor access and activity.
• Applications: It integrates into custom-built web applications to observe access to certain URLs, paths, or endpoints.
• Infrastructure Services: It monitors cloud management APIs (e.g., AWS, Azure, Google Cloud) for unusual activities indicative of an investigation.

Once deployed, the tripwire API continuously monitors network traffic, API calls, and system changes for indicators of an investigation. It looks for:

• Known Security Tools: Scanning for network traffic signatures from common security tools (like Nessus or nmap) or patterns associated with incident response teams.
• Unusual Access: Detecting attempts from IP ranges linked to internal security teams or cloud provider security operations centers.
• System Changes: Watching for actions typical of an investigation, such as new logging mechanisms, alterations to IAM roles, or the activation of cloud monitoring services.

The API can use whitelists for expected IP addresses or user accounts, triggering alerts if unexpected access occurs.

Upon detecting activity, the API tripwire can take immediate evasive actions:

• Alert the Subject: It sends covert alerts to an external server controlled by the subject, through an HTTP request, encrypted email, or messaging platform.
• Suspend Malicious Activity: If integrated into a malicious workflow, the API can halt ongoing data exfiltration or malware processes.
• Clean Up Evidence: It triggers scripts to delete logs, clear files, or reset system configurations to hinder forensic analysis.
• Feign Normalcy: It restores access controls and system settings to their default state, masking any signs of unusual activity.

A subject deletes files or data that cause disruption of business operations.

Subjects who are issued Multi-Factor Authentication (MFA) tokens, whether software-based (such as Google Authenticator or Microsoft Authenticator) or hardware devices (like YubiKeys or FIDO2 devices), may retain access to systems if these tokens or devices are not deactivated upon their departure or role change.

When a subject leaves the organization or no longer needs access, failing to deactivate their MFA tokens allows them to continue authenticating to systems, potentially bypassing security controls. If a subject’s software-based MFA token remains active, they can still generate valid authentication codes unless the token is unlinked or deactivated. Similarly, if a subject retains a hardware security key, they can use it to authenticate to services as if they were still an active user.

In environments using federated authentication (e.g., SAML, OAuth), a subject’s MFA token can provide access to multiple interconnected services, allowing them to authenticate to systems they should no longer be able to access. This opens the possibility of unauthorized access even after the subject has left the organization.

To prevent this, organizations must promptly deactivate MFA tokens when subjects are removed from the network. Automating the deactivation process and regularly auditing active tokens will help close any gaps in access control. Additionally, securely managing backup MFA keys ensures that no unauthorized individual can reuse them.

A subject misappropriates, discloses, or exploits proprietary information, trade secrets, creative works, or internally developed knowledge obtained through their role within the organization. This form of data loss typically involves the unauthorized transfer or use of intellectual assets—such as source code, engineering designs, research data, algorithms, product roadmaps, marketing strategies, or proprietary business processes—without the organization's consent.

Intellectual property theft can occur during employment or around the time of offboarding, and may involve methods such as unauthorized file transfers, use of personal storage devices, cloud synchronization, or improper sharing with third parties. The consequences can include competitive disadvantage, breach of contractual obligations, and significant legal and reputational harm.

A subject with access to privileged groups (e.g., Domain Admins, Enterprise Admins, or Security Groups) or non-user accounts (such as service accounts, application identities, or shared mailboxes) gains elevated control over systems, applications, and sensitive organizational data. Access to these groups or accounts often provides the subject with knowledge of security configurations, user roles, and potentially unmonitored or sensitive activities that occur within the system.

Shared mailboxes, in particular, are valuable targets. These mailboxes are often used for group communication across departments or functions, containing sensitive or confidential information, such as internal discussions on financials, strategic plans, or employee data. A subject with access to shared mailboxes can gather intelligence from ongoing conversations, identify targets for further exploitation, or exfiltrate sensitive data without raising immediate suspicion. These mailboxes may also bypass some security filters, as their contents are typically considered routine and may not be closely monitored.

Access to privileged accounts and shared mailboxes also allows subjects to escalate privileges, alter system configurations, access secure data repositories, or manipulate security settings, making it easier to both conduct malicious activities and cover their tracks. Moreover, service and application accounts often have broader access rights across systems or environments than typical user accounts and are frequently excluded from standard monitoring protocols, offering potential pathways for undetected exfiltration or malicious action.

This elevated access gives subjects insight into critical system operations and internal communications, such as unencrypted data flows or internal vulnerabilities. This knowledge not only heightens their potential for malicious conduct but can also make them a target for external threat actors seeking to exploit this elevated access.

A subject with access to payment environments or transactional data may deliberately or inadvertently leak sensitive payment card information. Payment Card Data Leakage refers to the unauthorized exposure, transmission, or exfiltration of data governed by the Payment Card Industry Data Security Standard (PCI DSS). This includes both Cardholder Data (CHD)—such as the Primary Account Number (PAN), cardholder name, expiration date, and service code—and Sensitive Authentication Data (SAD), which encompasses full track data, card verification values (e.g., CVV2, CVC2, CID), and PIN-related information.

Subjects with privileged, technical, or unsupervised access to point-of-sale systems, payment gateways, backend databases, or log repositories may mishandle or deliberately exfiltrate CHD or SAD. In some scenarios, insiders may exploit access to system-level data stores, intercept transactional payloads, or scrape logs that improperly store SAD in violation of PCI DSS mandates. This may include exporting payment data in plaintext, capturing full card data from logs, or replicating data to unmonitored environments for later retrieval.

Weak controls, such as the absence of data encryption, improper tokenization of PANs, misconfigured retention policies, or lack of field-level access restrictions, can facilitate misuse by insiders. In some cases, access may be shared or escalated informally, bypassing formal entitlement reviews or just-in-time provisioning protocols. These gaps in security can be manipulated by a subject seeking to leak or profit from payment card data.

Insiders may also use legitimate business tools—such as reporting platforms or data exports—to intentionally bypass obfuscation mechanisms or deliver raw payment data to unauthorized recipients. Additionally, compromised service accounts or insider-created backdoors can provide long-term persistence for continued exfiltration of sensitive data.

Data loss involving CHD or SAD often trigger mandatory breach disclosures, regulatory scrutiny, and severe financial penalties. They also pose reputational risks, particularly when data loss undermines consumer trust or payment processing agreements. In high-volume environments, even small-scale leaks can result in widespread exposure of customer data and fraud.

A subject provisions cloud-based resources without prior authorization or a documented business justification. This unauthorized activity may circumvent established governance, security, or cost-management controls, potentially exposing the organization to operational, financial, or regulatory risk.