[New Rules] Druva Data Security Cloud detection coverage

## Summary

Druva and Elastic are developing an Elastic Security integration for Druva Data Security Cloud telemetry.

The Druva integration provides the `logs-druva.event-*` data stream and normalizes relevant Druva security, administrative, backup, recovery, and unusual data activity telemetry into ECS and `druva.*` fields.

We would like to contribute an initial set of production-quality Elastic Security prebuilt detection rules for Druva.

## Why we are opening this issue first

We currently maintain a broader candidate library of 155 Druva detection rules.

We performed a static semantic review of those rules and classified them as:

- 120 likely aligned
- 7 partial / too broad
- 23 requiring redesign
- 5 post-ingest / integration-health checks

Rather than submitting all 155 rules, we propose starting with a focused Phase 1 set of 28 rules.

Each Phase 1 candidate will also be live-validated in Elastic before a pull request is submitted.

## Proposed Phase 1 coverage

### Cyber resilience and recoverability

- Druva - Recovery Started After Backup Protection Disabled
- Druva - Recovery Started Immediately After UDA Alert
- Druva - UDA Correlated With Backup Failure
- Druva - UDA Correlated With Backup Disablement
- Druva - Mass Backup Failures
- Druva - Abnormal Data Change or Deletion Spike
- Druva - Backup Data Deletion Attempt
- Druva - Backup Protection Disabled or Paused
- Druva - Backup Security Posture Degradation

### Administrator and privileged activity

- Druva - Administrator Created
- Druva - Privileged Role Assignment
- Druva - Repeated Failed Administrator Logins
- Druva - Privileged Action Immediately After Login
- Druva - Administrator Role Changed

### Recovery operations

- Druva - Recovery Cancelled
- Druva - Consecutive Recovery Failures
- Druva - Recovery Verification Failed
- Druva - Mass Recovery Across Multiple Resources
- Druva - Recovery Job Failed
- Druva - Recovery Target Changed

### Security and integration configuration

- Druva - Webhook Configuration Deleted
- Druva - Webhook Configuration Created
- Druva - Webhook Configuration Modified
- Druva - Security Setting Disabled
- Druva - API Token Created
- Druva - Backup Encryption Disabled

### Ransomware and unusual data activity

- Druva - Ransomware Alert Observed
- Druva - UDA Against Critical Resource

## Data source

The rules operate primarily on:

`logs-druva.event-*`

The integration normalizes telemetry into ECS fields where appropriate, including fields such as:

- `@timestamp`
- `event.id`
- `event.action`
- `event.outcome`
- `event.severity`
- `user.name`
- `user.email`
- `source.ip`
- `message`

Druva-specific fields are used where there is no suitable ECS equivalent, including:

- `druva.feature`
- `druva.event_type`
- `druva.customer.id`
- `druva.resource.name`
- `druva.resource.type`
- `druva.alert.name`
- `druva.uda.type`
- `druva.file.created_count`
- `druva.file.updated_count`
- `druva.file.deleted_count`
- `druva.file.encrypted_count`
- `druva.security.control`
- `druva.security.previous_state`
- `druva.security.current_state`
- `druva.backup.status`

## Related integration

The detection rules will declare the Druva Fleet integration using `related_integrations`.

We also plan to define the relevant `required_fields` for each rule.

## Detection approaches

The proposed rules include a mix of:

- ES|QL
- EQL sequence/correlation rules
- threshold rules
- query rules

The intent is to use behavioral and state-change detections rather than relying solely on static indicators.

## Validation plan

Before submitting the corresponding rules in a PR, we plan to:

1. Live-test the Phase 1 rules against Druva telemetry in Elastic Security.
2. Validate positive detection scenarios.
3. Validate expected negative scenarios and false-positive behavior.
4. Confirm required ECS and Druva-specific fields.
5. Add appropriate MITRE ATT&CK mappings where applicable.
6. Add investigation guidance and false-positive guidance.
7. Add `related_integrations` metadata referencing the Druva integration.
8. Validate all rules with the `elastic/detection-rules` tooling.

## Feedback requested

Before preparing the rule PRs, we would appreciate guidance from the Elastic detection-rules maintainers on:

1. Whether this is an appropriate scope for an initial Druva rule contribution.
2. Whether you would prefer the initial contribution to be smaller than 28 rules.
3. Preferred directory/category placement for Druva integration-specific detections.
4. Expectations for vendor-specific `druva.*` fields that do not have direct ECS equivalents.
5. Whether you recommend submitting the initial rules as one PR or several smaller PRs organized by detection category.

We are happy to adjust the scope and implementation based on feedback before preparing the rule contributions.

Start by reviewing the proposed detections against the logs-druva.event-* data stream and the listed ECS and druva.* fields. Maintainer guidance is needed on scope, directory placement, PR organization, and vendor-specific fields; done would include validated rules, required metadata, MITRE mappings, investigation and false-positive guidance, and detection-rules tooling validation.

Written by the indexing model from the issue text.