Log Management Strategy for Telecom Operators Under CTDISR-2025

Logs are the forensic record of your network's operation. They answer the questions that matter during an incident and the questions auditors ask during a CTDISR assessment: what happened, when did it happen, who did it, and was it detected. A log management strategy that collects the right sources, retains them for the required period, and makes them queryable during time pressure is one of the most operationally valuable security investments an ISP can make.

The common failure mode is not that logs do not exist, it is that they exist locally on individual devices, are overwritten after a short period, cannot be searched efficiently across multiple sources simultaneously, and are inaccessible during an incident because the device that generated them is the one that is down.

The Log Sources That Must Be Centralised

Not every log source has equal importance for CTDISR compliance and security operations. The priority tier is determined by two factors: whether an auditor will ask to see the logs, and whether the logs would be essential for investigating a security incident.

Tier 1, highest priority: authentication logs from FreeRADIUS (subscriber authentication and accounting records, essential for CGNAT correlation and lawful intercept), firewall filter logs from edge and aggregation MikroTik devices (particularly logs of management access attempts and anti-spoofing hits), BGP session event logs (session establishment, drops, prefix advertisements), system authentication logs from servers and critical network devices (SSH login success and failure), and CTDISR-relevant security tool outputs (any IDS/IPS, DDoS mitigation platform, endpoint protection alerts).

Tier 2, important: DHCP lease records (subscriber IP assignment history for CGNAT correlation), interface status change logs (link up/down events for incident timeline reconstruction), SNMP trap logs from network equipment, and application logs from billing systems and subscriber management platforms where they touch security-relevant actions.

Tier 3, operational value but lower compliance priority: performance metrics and bandwidth utilisation data (primarily NMS data, not security-critical), NOC ticketing platform activity logs, routine configuration change logs.

Centralisation Architecture

The centralised log infrastructure should receive logs from all Tier 1 and Tier 2 sources, store them in a queryable format, and retain them for the required period. The minimum viable architecture is a syslog receiver and storage server running Graylog, Wazuh, or Elasticsearch, configured as the syslog target for all MikroTik devices and Linux servers in the infrastructure.

For MikroTik devices, configure syslog remote logging in /system/logging: specify the IP of your centralised log server, UDP port 514, and the topics to forward. At minimum: firewall, system, critical, info. For FreeRADIUS, configure the sql accounting module to write to a database and either forward the database records to your SIEM directly or configure a log shipping agent.

The centralised log server must be on infrastructure that is not affected by the events it is logging. A log server that is also a subscriber-facing device fails precisely when the incident you need logs for is happening on that device. Separate the log aggregation function onto management network infrastructure.

Retention Periods

CTDISR-2025 does not specify a precise log retention period for every log category, but the practical requirement driven by audit cycles, incident investigation timescales, and lawful intercept obligations points toward a minimum of 12 months for authentication and security event logs. For subscriber session records (RADIUS accounting), Pakistani operator practice informed by lawful intercept obligations suggests 12 months as the working minimum.

Hot retention, meaning logs that are immediately queryable without restoration from archive, should cover at least 90 days. Logs beyond 90 days can be archived to cheaper storage (compressed, on local disk or object storage) as long as they can be retrieved and queried within a reasonable time if needed.

Query Capability for Incident Response

A log management system that cannot be queried quickly under incident conditions is not meeting its purpose. The key queries that must work efficiently: find all authentication events for a specific subscriber IP in a time range, find all firewall hits from a specific source IP, find all BGP events on a specific interface in the last 24 hours, find all SSH login attempts to a specific router in the last week.

Test these queries specifically before considering the log management infrastructure operational. A query that takes 10 minutes to return results against 30 days of logs is not usable during an active incident. Index your most commonly queried fields, IP addresses and timestamps at minimum, to keep query times under 10-30 seconds on typical queries.

For the SIEM component that sits above the log management infrastructure and provides correlation and alerting, the SIEM selection article on this site covers platform evaluation. For the full nTSOC integration that uses your centralised log infrastructure as the source for event forwarding, nTSOC Integration covers the integration design. For operators building centralised logging as part of a broader security programme, Cybersecurity for ISPs covers the full security architecture.