RASP decisions: decide what runtime protection blocks
Runtime protection starts in monitor mode. It reports attacks and lets the calls through, so nothing breaks while you learn what your apps see. The decision queue is where a person makes the call to block.
Open Protect → WAF & RASP → RASP decisions.
An attack opened from Detections goes to what can act on it. A group reported by your app’s SDK opens alone in this queue. A group reported by Shield360 Edge opens Edge’s events for that app and path, where you can see the clients and block an address. Edge records only the first part of a path, so that view can include other paths under it.
What is in the queue
Section titled “What is in the queue”Monitored events are grouped by app, attack type, rule and route. Blocked events are already decided, so they never appear here. Each group shows:
- how many times it happened, and when it was first and last seen;
- the HTTP methods seen;
- an example from the latest event: the sink, where the input came from (such as
query.id), the source, the framework and any CVE.
Input values are never shown. A snippet appears only if your organization stores content and the snippet has not passed its own expiry. It is masked again before it is shown.
The Open view lists groups waiting for a decision. The Decided view lists past decisions, each with what it changed. Filter either view by app.
Decisions
Section titled “Decisions”| Decision | What it changes |
|---|---|
| Block | Sets the attack type to block for that app. Not offered for xss or the security baseline, which never block. |
| Patch route | Adds a virtual patch scoped to that route and its methods, so only that route is blocked. |
| False positive | Adds an allow entry where one exists: an allowed command for shell_spawn.shell, an outbound host for outbound.not_allowed, or a file root for path.outside_root. Events never carry the value, so you type it, and it is checked like any setting. For every other rule the group is recorded as dismissed. |
| Snooze | Hides the group for 1 to 90 days. |
A decision writes the app’s existing runtime protection settings, so the app picks it up the next time it fetches its signed config, usually within a minute.
Every decision can be undone from the Decided view. Undo puts back only what that decision set. If a later change edited the same value, undo is refused and says so. If another decision still relies on the value (for example, two decisions both blocked the same attack type), undo keeps it.
Learning mode
Section titled “Learning mode”Learning mode reads your apps’ normal behavior and suggests decisions in the Suggested tab. Nothing is applied automatically. Every suggestion waits for a person to accept or dismiss it.
It learns per app and route from data Shield360 already stores: runtime protection events, vulnerability findings, and the server and client spans of your own telemetry. It reads only rules, routes, methods, sinks, hosts and counts. It never reads a snippet, an input key or an input value.
| Suggestion | When it is made |
|---|---|
| Allow entry | A command, outbound host or file-root report keeps coming from one route, at least the minimum number of times on at least the minimum number of days, and no attack of the same kind was ever seen on that route. You always type the entry yourself: nothing is pre-filled, because the reports never carry the value and the app may have been made to call a host by an attacker. |
| Custom rule | Attacks on a route used an HTTP method normal traffic never uses. The suggestion is a custom rule that blocks other methods on that route. |
| Block mode | An attack type in monitor mode has been reported often (3× the minimum), on at least half the learning window’s days, recently, with no false-positive decisions for that app and attack type. The reasoning is shown on the card. |
If any of the data behind a suggestion can’t be read in full, Shield360 makes no suggestion of that kind in that run, rather than a suggestion built on partial data.
A dismissed suggestion comes back only when its evidence grows materially: at least twice the observations, or the minimum number of extra days.
Thresholds
Section titled “Thresholds”Set these for each environment under Learning thresholds in the Suggested tab:
| Setting | Default | Range |
|---|---|---|
| Learning | on | on or off |
| Learning window | 14 days | 1 to 30 days |
| Minimum observations | 20 | |
| Minimum distinct days | 5 | no more than the window |
Learning runs once a day. Run learning now runs it for the current environment.
Permissions and audit
Section titled “Permissions and audit”- Viewing the queue and suggestions needs View data protection events.
- Deciding, undoing, accepting, dismissing and changing thresholds need Manage agent policies. The server checks both.
- Everything works on the current project’s environment only.
- Every decision, undo, accept and dismiss is recorded in the audit log, with what it changed.