# job 03 · logging and watching
Logging and watching a VPS you run
On a server you run, the event logs are yours to set up, keep and read. Where the server is supplied as Infrastructure-as-a-Service, ASD’s logging guidance says that model “would include a significant amount of logging responsibility on the tenant”. Its small business handbook turns the job into six habits, starting with a simple logging policy, and asks that logs be “monitored regularly or supported by automated alerts.”
General information, not technical advice for your server. This guide rests on ASD’s Best practices for event logging and threat detection, with the event logging chapter of its small business handbook; the official place to check is cyber.gov.au.
habits: 6Six habits, in ASD’s order
The handbook’s advice is to aim for the important security events rather than gathering everything, and to keep logs accurate, secure and regularly reviewed. Then it lists what to do.
- “create a simple logging policy covering systems, events, retention and responsibilities”
- “focus on high-value events such as logins, administrator changes, remote access and security alerts”
- “ensure logs include useful details (time, user, system, action, outcome)”
- “retain logs for several months or longer where possible”
- “centralise logs to improve visibility and prevent data loss”
- “restrict access to logs and protect them from modification or deletion.”
Where cloud services are used, it adds, logging should also be switched on for user activity and administrative changes.
watch listWhat to watch for
The handbook pairs keeping logs with watching them. It says to focus on unusual activity, and that knowing what normal activity looks like makes threats easier to spot.
ASD’s small business handbook: “Watch out for:”
> “multiple failed login attempts or unusual login behaviour”
> “access from unexpected locations or outside normal hours”
> “creation or modification of administrator accounts”
> “large or unusual data transfers”
> “unexpected system or configuration changes.”
practitionerWhat the fuller guidance adds for a server
ASD’s best practices publication is written for people in medium to large organisations, but several of its points land squarely on a single server.
Log the tools already on the system
ASD points to attackers using “living off the land” techniques, which turn a system’s own tools against it and are hard to detect. Among its logging considerations for spotting them is this one: “On Linux-based systems, logs capturing the use of curl, systemctl, systemd, python and other common LOLBins leveraged by malicious actors.”
Give every log the same clock
ASD suggests one accurate, trustworthy time source used across all systems, so events from different logs can be connected. It calls Coordinated Universal Time (UTC) “the preferred time standard”, written in ISO 8601 format with the year first, down to milliseconds, as in its own example:
2024-07-25T20:54:59.649Z
Know which sources come first
- “critical systems and data holdings likely to be targeted”
- “internet-facing services (including remote access) and, where applicable, their underlying server operating systems”
- “use of the tenant’s user accounts that access and administer cloud services”
- “logs for administrative configuration changes”
- “logs for the creation, deletion and modification of all security principals, including setting and changing permissions”
- “authentication success and/or failures to third party services (e.g. SAML/OAuth)”
- “logs generated by the cloud services, including logs for cloud APIs, all network-related events, compliance events and billing events.”
retentionKeep them long enough, and out of reach
“Default log retention periods are often insufficient.” ASD asks for retention set by an assessment of the risks to the system, and gives a reason to err long: “in some cases, it can take up to 18 months to discover a cyber security incident and some malware can dwell on the network from 70 to 200 days before causing overt harm”.
ASD names insufficient storage as “a common obstacle to log retention”, since “many systems will overwrite old logs when their storage allocation is exhausted”, and says forwarding logs to central, secure storage prevents that loss. To reduce the risk of logs being tampered with if a network or system is compromised, ASD recommends storing them in a separate or segmented network with extra security controls, and backing them up.
afterwardsThe day the logs are needed
Logs are the first item on the list of data ASD says it may ask for after an incident is reported; the list also names memory dumps and disk images. ASD’s logging guidance says the longer logs are kept, the better the chance of working out how far an incident reached.