RS Runtime Security Documentation
First-time onboarding

Follow this order: sign up, verify email, deploy sensor, then run event analysis.

Use this document as the implementation path for new users: complete sign-up form, activate account from email verification link, choose deployment method (standalone, Docker, K8s, EKS, ECS), then continue to findings, events, and policy control.

View 5-step onboarding Open Sign-up Form Log-in After Verify

How to start

First-time 5-step onboarding path

Complete these steps in order to go from account creation to runtime analysis and control.

Step 2

Activate account

Open your email and click the verify link before first login.

Step 3

Deploy sensor

Select one deployment method based on your environment.

Standalone Docker K8s EKS ECS
/docs.html#deployment-tracks
Step 4

Validate telemetry

Confirm inventory assets and event flow in Security Posture and Event Timeline.

Step 5

Analyze + control

Triage findings, analyze events, and tune file/process/network policies.

Production onboarding sequence

Sign-up and verification must happen first. Deployment comes next, then event analysis and policy hardening in the runtime console.

Start Sign-up Deployment Methods Open Console

Solution model

What Runtime Security includes

After onboarding is complete, use this as the operating model for daily runtime security work.

1) Runtime observability

Ingest runtime signals from Kubernetes-managed containers, standalone containers, and Linux hosts in one place.

  • Process, file, and network telemetry
  • Asset and workload context
  • Unified inventory across environments

2) Unified detection

Correlate threat, vulnerability, and behavioral findings to prioritize high-impact runtime issues.

  • MITRE and compliance signal mapping
  • Process alert correlation with findings
  • Drill-down path to event evidence

3) Runtime control

Apply policy controls to reduce alert noise and enforce monitoring coverage where risk is concentrated.

  • File monitoring control
  • Process monitoring control
  • Network monitoring control

Deployment tracks

Select deployment path by runtime environment

Choose one method first (standalone, Docker, Kubernetes, EKS, ECS), then verify event flow and control posture.

Kubernetes-managed containers

Enable namespace and pod context for runtime findings and policy actions.

  1. Onboard cluster sensors from deployment view.
  2. Confirm pod and namespace metadata in Runtime Overview.
  3. Open Findings view for combined threat and process triage.
/docs.html#deployment-tracks

Non-managed containers

Cover standalone container runtimes and host-level container workloads.

  1. Validate inventory rows for runtime and image context.
  2. Check open exposure and process behavior in findings.
  3. Tune file and process controls for high-risk images.
/overview.php?view=containers

Linux hosts

Track host process execution, file drift, and network runtime events.

  1. Confirm host telemetry in Runtime Overview.
  2. Triaging process alerts tied to host identity.
  3. Apply file/process/network policies based on findings.
/overview.php?view=inventory

Operational workflow

Map daily operations to console sections

Use this sequence to reduce context switching and improve runtime response quality.

1) Observe

Get coverage and telemetry health before deep investigation.

  • Runtime Overview
  • Container Runtime
  • Event Explorer

2) Triage

Use combined findings and process alerts to prioritize investigations.

  • Threat + vulnerability findings
  • Top process alerts
  • Drill-down to event explorer

3) Control

Apply monitoring controls where detections are noisy or high-risk.

  • File monitoring control
  • Process monitoring control
  • Network monitoring control

Detection domains

Runtime signal model reference

Use this table as the default mapping between detection signals and control actions.

Domain Primary signals Triage entry point Control action
Threat + Vulnerability MITRE tags, PCI tags, CVE-linked indicators, exploit behaviors /overview.php?view=findings Prioritize assets and map policy hardening
Process Unexpected execution chains, privilege escalation, noisy binaries /overview.php?view=top_alerts /overview.php?view=policies_process
File Sensitive path writes, config drift, binary tampering /overview.php?view=events&action=fim /overview.php?view=policies_file
Network IOC lookups, egress anomalies, unexpected destinations /overview.php?view=events /overview.php?view=policies_network

Troubleshooting

Common operator questions

Why does findings show low volume for one environment?

Validate that the environment has active sensors and current inventory events. Then verify date range and customer scope filters.

Where should I start when alerts are noisy?

Open combined findings first, identify top process alert sources, then tune process and file policies for those binaries and paths.

How do I confirm host visibility is healthy?

Review Runtime Overview asset matrix and ensure host rows include process and file signal counts in the current time window.

Can I use policies without Kubernetes?

Yes. Policy controls support host and non-managed container use cases in addition to Kubernetes-managed workloads.

Need implementation help?

Use this order: sign-up, verify email, deploy sensor, validate events, then tune controls in the console.

Sign Up Open Runtime Console