Security Watch Monitor (secwatch) Guide

View the SQL injection secondary verdict results (alert/review/log) routed to your organization (csn) on screen, and query the same content through a read-only API read with your organization's SK so that an AI can regularly check for anomalies.

🛡️ Go to Security Watch Monitor →

📋 Overview

GIIP's secwatch (Jev-based SQL injection secondary verdict) takes the suspicious events sent by collectors (lssn), classifies them in the gateway using first-stage deterministic rules plus second-stage AI judgment, loads them into tKVSSecurityCheck, and splits each verdict by routing target.

Routing (kscRoutedTo)	On-screen label	Meaning
alert	Alert	Suspected exfiltration/write attempt or high-confidence attack — immediate alert target
review	Review	Possible attack but below the automatic-alert threshold — needs human review
log	Log	Judged normal/noise — not alerted, only counted

The screen (/en/admin/secwatch-monitor) shows these results filtered by time window (last 1 hour / 6 hours / 24 hours / 7 days) and routing target (all / alert / review / log). This screen is open to logged-in users and shows only the results routed to their own organization (csn) (enforced by the server SP).

🔎 How to read the screen

The screen has two areas.

1. Scan coverage panel — "what is being scanned, and where only did an anomaly occur." For each source it shows the number of scanned items, the number of flagged items, and the last scan time; if flagged is 0 it is 🟢 normal, and if it is 1 or more it is 🔴 anomaly. Even with no detections you can confirm that "scanning is running."
2. Verdict result cards — each verdict is one card. Displayed items:

On-screen item	Field	Meaning
Time	kscRegdt	Time the verdict was loaded
Routing badge	kscRoutedTo	alert / review / log
Event type	kscFactor	Kind of event (secevt_*)
Injection probability	kscIsInjection	Probability of SQL injection / attack preparation (0–1, shown as % on screen)
Severity	kscSeverity	0 noise · 1 reconnaissance · 2 enumeration/read · 3 credential/personal-data read · 4 write/privilege manipulation
Attack type	kscAttackType	Classified attack category
Pattern	kscPatternNo	Same method (pattern serial number within csn) — for tracking repeated attacks
Attacker IP	kscActorIp	Attack source IP (for tracking/blocking)
Flags	kscIsInjection/kscDataExtracted/kscWriteAttempt	When each probability is 0.7 or higher, an injection / data-exfiltration / write-attempt badge appears
Confidence	kscConfidence	Confidence of the classification/severity verdict (0–1)
Engine	kscEngine	Verdict engine
Collector	kscKey	The collector (lssn) that submitted the result
Routing reason	kscWhy	The routing rationale left by the gateway

Injection probability, data exfiltration, and write attempt are probability values from 0 to 1, and the screen treats 0.7 or higher as "established" and shows a badge.

🔌 API reference (read-only — for AI / external clients)

A read-only API that reads the same content as the screen using the organization identifier (csn) and that organization's secret key (SK). It calls two SPs through the general-purpose dispatcher giipApiSk4. It does not include any data-loading, verdict, or blocking functionality.

Common call convention

Item	Value
Method	POST (or GET)
URL	https://giipfaw.azurewebsites.net/api/giipApiSk4
Body (form-urlencoded) or query	text=<command>, token=<SK>, jsondata=<JSON>

• The first token of text is the command name, and the tokens after it are field names that match the keys of jsondata one to one. If you omit a token, that parameter uses the SP default (the examples below are the safest form).
• Put the organization's SK in token. An SK returns only the results of the organization (csn) that SK belongs to (it is automatically scoped to that organization even without passing csn separately).
• The response is always HTTP 200 and the body has the form { "data": [ ... ], "debug": { ... } }. Authentication/parameter errors also come back as HTTP 200, with { "RstVal": 401|403, "RstMsg": "..." } in data[0] — the AI must check data[0].RstVal first.

(1) Query verdict results — KVSSecurityCheckWindow

Field (jsondata)	Required	Meaning
minutes	Optional	Query time window (minutes). Default 60, max 10080 (7 days). 1 hour=60 / 6 hours=360 / 24 hours=1440 / 7 days=10080
routedTo	Optional	One of alert/review/log. Omit for all

Request example (last 24 hours, all — safest default form)

export GIIP_API_BASE_URL="https://giipfaw.azurewebsites.net"
export GIIP_SK="set_at_runtime_only"

curl --fail-with-body -X POST "${GIIP_API_BASE_URL}/api/giipApiSk4" \
  --data-urlencode "text=KVSSecurityCheckWindow minutes" \
  --data-urlencode "token=${GIIP_SK}" \
  --data-urlencode 'jsondata={"minutes":1440}'

Request example (last 24 hours, alert targets only)

curl --fail-with-body -X POST "${GIIP_API_BASE_URL}/api/giipApiSk4" \
  --data-urlencode "text=KVSSecurityCheckWindow minutes routedTo" \
  --data-urlencode "token=${GIIP_SK}" \
  --data-urlencode 'jsondata={"minutes":1440,"routedTo":"alert"}'

Success response (one data[] row per verdict)

{
  "data": [
    {
      "kscsn": 0, "kscKey": "12345", "kscFactor": "secevt_...",
      "kscIsInjection": 0.97, "kscAttackType": "...", "kscSeverity": 4,
      "kscDataExtracted": 0.10, "kscWriteAttempt": 0.95, "kscConfidence": 0.9,
      "kscEngine": "...", "kscRoutedTo": "alert", "kscActorIp": "...",
      "kscPatternNo": 1, "kscStatus": "...", "kscRegdt": "...", "kscWhy": "..."
    }
  ],
  "debug": { }
}

• Each row corresponds directly to the items on the screen card (see the "How to read the screen" table above).
• SK/AK/keys/DB connection details are never included in any response.

(2) Query scan coverage — KVSSecurityCoverageWindow

A per-source aggregate of "scanned but not sent (including normal)." Same content as the coverage panel at the top of the screen.

Field (jsondata)	Required	Meaning
minutes	Optional	Query time window (minutes). Default 1440, max 10080

Request example

curl --fail-with-body -X POST "${GIIP_API_BASE_URL}/api/giipApiSk4" \
  --data-urlencode "text=KVSSecurityCoverageWindow minutes" \
  --data-urlencode "token=${GIIP_SK}" \
  --data-urlencode 'jsondata={"minutes":1440}'

Success response

{
  "data": [
    { "ksvSource": "...", "ksvSystem": "...", "scanned": 1200, "flagged": 0, "lastTs": "...", "status": "normal" }
  ],
  "debug": { }
}

• status is normal when flagged is 0, and anomaly when it is 1 or more.

Error response (common to both APIs)

Returned in data[0] (the HTTP status code is always 200).

Condition	RstVal	RstMsg
SK missing or invalid	401	Invalid sk
Requested csn differs from the SK's csn (cross-csn blocked)	403	csn mismatch (sk 의 csn 과 다름)

⚠️ Security: Never put the SK in a URL, an issue, a repository, a prompt body, or logs. Pass it only from a runtime environment variable or a secret store.

🤖 Fixed AI call procedure (anomaly judgment)

1. Query per organization: call KVSSecurityCheckWindow with the SK of each organization you want to check. Set the time window to match the check cadence (e.g. minutes=60 for hourly checks, minutes=1440 for once a day).
2. Check authentication: if the response data[0].RstVal is 401/403, report that organization as having a wrong SK or being inaccessible, and move on to the next organization.
3. Judge anomaly: in data[], if there is even a single row whose kscRoutedTo is alert or review, report it as an anomaly. If there are only log rows, treat it as a normal record.
4. Prioritize: when reporting, sort in descending order of kscSeverity (severity 0–4) and kscIsInjection (injection probability), and note whether the same attacker / same method repeats using kscActorIp and kscPatternNo.
5. Cross-check coverage: use KVSSecurityCoverageWindow to confirm that each source is actually being scanned. If any source's status is anomaly, check that source first, and if an expected source is missing from coverage entirely, also report it as "possible collection gap."
6. Sweep all organizations: repeat steps 1–5 for each organization (csn) the account can access. Since an SK is per organization, to check multiple organizations call once with each organization's SK.

🛠 Troubleshooting

Symptom	Cause	Solution
"Access denied" on screen	Logged in but lacking that organization (csn) context/membership	Log in with an account that belongs to that organization. Via the API you can query without the screen by using that organization's SK
API data[0].RstVal=401	SK missing or invalid	Pass the correct organization SK in token (environment variable)
API data[0].RstVal=403	Requested csn differs from the SK's csn	Do not pass csn separately; use only that organization's SK (the SK determines the csn)
data is an empty array	No verdict results for that organization in that time window	Treat as normal (no anomaly). You can re-query with a larger minutes
Coverage is empty	No scan coverage aggregate in that time window	Check that the collector is running and re-query with a larger minutes

API reference

This guide includes the API details (endpoint, parameters, response, errors) self-contained in the "🔌 API reference" section above. There is no separate API guide.

---

Version: 1.0 Last Updated: 2026-10-30 Changelog: giip 4314 — newly authored the secwatch Security Watch Monitor user guide. Documented the verdict results (KVSSecurityCheckWindow) and scan coverage (KVSSecurityCoverageWindow) SK read-only APIs, and included the fixed AI procedure for anomaly judgment. Source File: giipv3/public/help/secwatch.en.md