Data Loss Detection

Data Loss Detection is a SIEM use case in Secure60. It monitors how data is accessed, moved and exposed across the systems connected to Secure60, and raises a threat when that behaviour indicates theft, leakage or destruction.

Detection works from log and audit streams, not file contents. It covers data stores that content inspection cannot read, such as encrypted backups in object storage, and runs alongside any content-inspection DLP tool already in place.

Typical questions it answers:

• Has an unusual volume of data been read from a bucket, share or database?
• Is an access key or account in use from a location or network it has not used before?
• Have the controls protecting a data store been weakened: a bucket made public, logging disabled, retention shortened?
• Are backups being deleted or overwritten?

How It Works

Data Loss Detection follows the same three stages as every Secure60 SIEM use case: collect, detect, respond.

1. Collect

Secure60 ingests the log and audit streams from the systems that hold or move data. Any source that records who accessed what, when, from where and how much is usable.

Source type	Examples
Object storage	S3 server access logs, AWS CloudTrail data events, S3-compatible storage access logs (Ceph RGW, MinIO, RackCorp S3). See Integrate S3.
Servers and file shares	Windows file access auditing, Linux auditd, SSH and SFTP logs, collected by the Secure60 Windows agent and Linux agent. See Linux auditd FIM and FIM audit configuration.
Databases	Database audit and query logs
Network	Firewall, proxy, DNS and NetFlow. See Firewall and network integration.
Identity	Active Directory, Entra ID, SSO and VPN logs
SaaS	Microsoft 365 and Google Workspace audit logs
Existing DLP tools	Alerts and events from content-inspection DLP products

Collect and Ingest lists connection guides for every source.

2. Detect

Secure60 analyses the incoming streams in three layers:

• Secure60 Rules match known risk events as they arrive, such as a bucket policy made public or audit logging disabled. See Rules & Responses.
• Secure60 ML builds a baseline of normal activity for each user, access key, host and data store, and flags activity outside it, such as a download volume ten times the usual level. See Entity Analytics.
• Secure60 agentic analysis investigates what the rules and ML raise. Digital Workers correlate activity across sources, determine whether it forms an incident, and record the evidence so an analyst can confirm it quickly.

3. Respond

When an incident is raised, Secure60:

• Creates a threat in the Threats Overview with the timeline and supporting events
• Sends a notification by email, or raises a ticket in the service desk or ITSM tool through a webhook response
• Retains the events and threat history as audit evidence

Containment, such as disabling an access key or blocking an account, remains with the customer’s team and existing change processes. Secure60 supplies the evidence needed to act quickly.

Detection Coverage

Category	Detections
Abnormal data volumes	Downloads well above the baseline for a user, key or data store; mass listing of buckets, shares or tables; large outbound transfers to new destinations; low-and-slow transfers spread over days
Anomalous user behaviour	Access at unusual times; new countries or networks; impossible travel; first-time access to a data store; dormant accounts becoming active; service accounts behaving like interactive users
Credential and key misuse	Access keys used from new IP addresses or networks; keys still in use after their owner has left; bursts of failed logins followed by success; the same credential active from two locations at once
Risky configuration change	Buckets or shares opened to the public; access policies broadened; encryption, versioning, object lock or logging disabled; new replication targets; firewall rules opening outbound paths
Destruction and ransomware activity	Mass deletes or overwrites; lifecycle rules changed to expire data early; old versions purged; retention shortened; backup jobs stopping or failing
Privileged activity	New admin grants and privilege escalation; changes outside approved change windows; the same administrator weakening controls and then accessing data
Exfiltration channels	Uploads to personal cloud storage and file-sharing sites; DNS tunnelling patterns; USB and removable media use; mailbox forwarding rules to external addresses
Correlated attack chains	Reconnaissance, privilege change, bulk access and a new outbound destination linked into a single prioritised incident across sources

Each deployment is tuned to the customer’s environment: the data stores that matter, the users and keys expected to access them, and the thresholds that define unusual activity.

Data leaving through copilots, chatbots and AI APIs is covered separately under LLM Data Exfiltration.

Complementing Content-Inspection DLP

Content-inspection DLP tools examine files and messages to classify whether sensitive data is leaving. Data Loss Detection evaluates who is accessing data, how much, from where, and whether the controls around it are being weakened.

The two complement each other:

• Content DLP identifies that a file contains sensitive data.
• Data Loss Detection identifies that the behaviour around that data is abnormal.

Alerts from an existing DLP product are ingested into Secure60 and correlated with access behaviour. A single DLP alert combined with an abnormal download volume and a new destination becomes a high-confidence incident rather than one more alert in a queue, which raises detection confidence and reduces alert volume.

Coverage Beyond Content Inspection

Many data stores cannot be inspected, or do not need to be:

• Encrypted backups. Backup products write encrypted, compressed data to object storage, which a content scanner cannot read. The risks are stolen access keys, bulk downloads and deliberate deletion, all of which appear in the storage access logs.
• Databases. Data theft appears as unusual queries and row volumes in audit logs.
• File servers and NAS. Access auditing records who opened what, and how much.
• Infrastructure and network devices. Configuration changes and outbound traffic patterns record the activity.
• Encrypted traffic. Where traffic cannot be decrypted, flow and volume data still shows where data is going.

Example: Protecting an Offsite Backup Repository

A customer stores encrypted backups in an S3 bucket. Secure60 ingests the bucket’s access logs and the storage platform’s audit events, and is configured to alert when:

• The backup access key is used from any IP address outside the customer’s backup servers
• More data is read from the bucket in a day than the restore baseline allows
• Objects are deleted or overwritten outside the backup software’s normal retention pattern
• Object lock, versioning or access logging is changed
• The bucket policy is changed to allow new principals or public access

Combined with encryption, object lock and least-privilege access on the bucket itself, this provides the prevent, detect and evidence controls the customer’s requirement calls for.

Compliance Mapping

Data Loss Detection provides evidence for:

Framework	Control
ISO/IEC 27001:2022	A.8.12 Data leakage prevention, A.8.15 Logging, A.8.16 Monitoring activities
CERT-In Directions (India)	Log retention and monitoring of ICT systems
APRA CPS 234 (Australia)	Detection of and response to information security incidents

Getting Started

1. Connect the log and audit sources for the data stores in scope. See Collect and Ingest.
2. Identify the data stores, users and access keys that matter most.
3. Secure60 configures the rules, baselines and analysis agent for the environment, and agrees where alerts are delivered.

Contact your Secure60 account manager, or support@secure60.io, to set up Data Loss Detection.