Security Posture and Threat Detection

Security posture management continuously inspects your environment for configurations that are dangerous — a publicly readable bucket, an overly permissive firewall rule, a service account with excessive rights, an unencrypted disk — and reports them as findings.

Threat detection is a different activity. It analyses activity rather than configuration, looking for behaviour that suggests something is actively wrong: credentials used from an unexpected location, unusual data access, or a workload behaving like it has been compromised.

Cloud environments drift. Someone opens a firewall rule to debug a problem at midnight and never closes it. A bucket is made public for a demonstration. A broad role is granted temporarily and never revoked. None of these are attacks, and all of them create the conditions for one.

Detection matters because prevention is never complete. Every organisation eventually has an incident; the difference between organisations is how quickly they notice and how well they can reconstruct what happened.

• Admin activity logs — record every change to configuration or metadata. Always on, cannot be disabled, and free of charge. This is your record of who changed what.
• Data access logs — record reads and writes of data itself. Mostly disabled by default because the volume is enormous and it costs money to retain. Must be explicitly enabled for the services where you need it.
• System event logs — record actions the platform takes automatically, such as a live migration.
• Policy denied logs — record when a request was blocked by a security policy, which is often the first signal of a misconfiguration or an attempt.

A very common exam scenario: an investigation needs to know who read a particular file, and the answer is that data access logs must be enabled in advance. Admin activity logs will show who changed the bucket's permissions but not who read its contents.

Most detection failures trace back to the first two steps rather than the rules. If a log source was never onboarded, or is parsed incorrectly, detections that depend on it silently never fire — and nothing alerts you to the absence.

• Continuously scanning for publicly exposed storage, permissive firewall rules and over-privileged accounts.
• Alerting when an unusual identity accesses sensitive data or a credential is used from a new country.
• Exporting audit logs to long-term storage for compliance retention.
• Building an asset inventory to answer what exists across every project.
• Automating remediation for well-understood findings, such as removing public access from a bucket.
• Reconstructing an incident timeline across identity, network and application logs.