Insider threats, whether malicious employees, negligent staff, or compromised accounts acting on behalf of an external attacker, represent a distinct risk category from external threats because they start from a position of legitimate access. An insider does not need to defeat the perimeter: they are already inside it. Detection depends on monitoring what legitimate users do rather than what is attempting to get in.
CTDISR-2025 Section 14 explicitly requires insider threat detection mechanisms. This is not a requirement for a dedicated insider threat programme in the enterprise sense, but it does require documented controls that would surface insider activity patterns that are anomalous or harmful.
What Insider Threat Looks Like in ISP Environments
The insider threat scenarios most relevant to Pakistani ISPs are shaped by the data and access that ISP employees hold. The categories worth designing detection around:
Subscriber data theft, where an employee extracts subscriber PII, CNIC data, or financial information for sale or personal use. For ISPs serving corporate clients, this extends to network configuration data and traffic monitoring capability that could be valuable to competitors.
Credential abuse, where an employee uses legitimate access to systems beyond what their role requires, or uses credentials of a colleague, or accesses systems at unusual times or from unusual locations in ways that suggest misuse rather than operational need.
Network manipulation, where an engineer makes unauthorised configuration changes: adding firewall bypass rules, modifying routing policy, or disabling logging. This category is particularly relevant for ISPs because network engineers have privileged access that can significantly affect service delivery and security posture.
Pre-departure data exfiltration, where a departing employee extracts data or credentials in the period before their departure. The weeks immediately before an announced resignation or termination are the highest-risk period for this category.
Detection Mechanisms
Access log monitoring is the primary technical control. For each critical system (NMS, billing platform, subscriber database, RADIUS administration), logs of access events should be reviewed for: access by users whose role does not justify it, access at unusual times (outside normal working hours without a documented operational reason), access to large volumes of records in a single session (a customer service agent querying 5,000 subscriber records in an hour is anomalous), and sequential access to records that suggests systematic data collection rather than responding to specific queries.
Privileged access monitoring extends this to the network equipment level: command logs from SSH sessions to routers and switches, reviewed for commands that are inconsistent with the stated purpose of the session (a scheduled maintenance visit that includes commands for disabling logging or creating new admin accounts warrants investigation).
Data transfer monitoring flags large file transfers or exports from systems that hold sensitive data. This requires either DLP (Data Loss Prevention) tooling or, at a simpler level, file transfer logs from servers that hold subscriber data. A 500MB export from the subscriber database at 2am by a user whose role is customer billing is a flag even if that user has technical access to perform the export.
Behavioural anomaly detection at its simplest is a human review process: a monthly review of access logs by the CISO or a designated security function looking for patterns that deviate from expected behaviour. At more mature stages, a SIEM configured with correlation rules that alert on specific patterns (the examples above) automates the first-pass detection.
Governance Requirements
Detection mechanisms need to be paired with a response process: when an anomalous pattern is identified, who is notified, how is it investigated, and what is the escalation path if investigation confirms a genuine insider threat event? This process should be documented and tested. An anomaly detection capability with no defined response process produces alerts that nobody acts on.
For CTDISR Section 14 evidence, the documentation needed is: what monitoring mechanisms are in place (specific systems and what they monitor), who reviews the output, what the review cadence is, and what the response process is when anomalies are identified. The existence of the monitoring and the documented governance around it are the evidence, not necessarily a history of specific findings.
For organisations where the CISO function owns insider threat detection as part of the governance programme, CISO-as-a-Service covers this as a core security governance deliverable. For the broader security programme that implements the technical detection mechanisms, Cybersecurity for ISPs covers the tooling and configuration.