Vaikora-AzureSecurityCenter v3.0.1 — align playbook + analytic rules with Vaikora /actions API schema#14366
Open
mazamizo21 wants to merge 1 commit into
Open
Conversation
Closed
5 tasks
mazamizo21
force-pushed
the
feature/vaikora-asc-v3.0.1-agent-id-fix
branch
from
4b696c3 to
a1aec2f
Compare
mazamizo21
changed the title
mazamizo21
force-pushed
the
feature/vaikora-asc-v3.0.1-agent-id-fix
branch
from
a1aec2f to
5ae2531
Compare
…ith Vaikora /actions API schema The 3.0.0 release shipped against an assumed alert-shaped API response. End-to-end testing surfaced that the Vaikora /api/v1/actions endpoint returns action-shaped events. Concrete defects in 3.0.0: - Poll_Vaikora_Actions always sent agent_id=, even when VaikoraAgentId was blank. Vaikora API returns HTTP 422 because Pydantic cannot parse '' as a UUID. - Send_to_Log_Analytics crashed with InvalidTemplate because replace() ran against null title/description fields that do not exist on the response. - Filter_High_Risk_Actions referenced threat_detected, which is missing from the response. - The three analytic rules queried Vaikora_SecurityAlerts_CL with columns (AlertId_s, Title_s, Description_s, SourceIP_s, UserName_s, etc.) that the playbook never wrote. - The standalone playbook wrote to Vaikora_SecurityAlerts; the mainTemplate inner playbook wrote to Vaikora_AgentSignals. Same solution shipped two divergent target tables. This PR aligns everything on the action-field schema and the Vaikora_AgentSignals_CL table: - Poll_Vaikora_Actions URI now omits agent_id when VaikoraAgentId is empty. - Send_to_Log_Analytics body rewritten to action fields (action_id, agent_id, action_type, resource_type, resource_id, status, severity, policy_id, policy_decision, is_anomaly, anomaly_score, anomaly_reason, log_hash, timestamp) with coalesce guards on nullable values. Log-Type set to Vaikora_AgentSignals. - is_anomaly wrapped with toLower(string(coalesce(...))) so it serializes as JSON true/false instead of Logic Apps' default True/False, which json() refuses to parse. - Parse_Response schema accepts nullable fields so rows where anomaly_reason or other optional fields are null pass validation. - Filter_High_Risk_Actions drops the threat_detected check; mainTemplate inner playbook mirrors the fix. - All three analytic rules rewritten to query Vaikora_AgentSignals_CL with action-field columns. - entityMappings reduced to agent_id -> Account.Name. - alertDetailsOverride placeholders updated and kept at or below the 3-placeholder cap. - Solution description updated to reference Vaikora_AgentSignals_CL. Validated end-to-end against api.vaikora.com on a real Sentinel workspace: full chain (Poll_Vaikora_Actions -> Parse_Response -> Filter_High_Risk_Actions -> For_Each_Security_Alert -> Send_to_Log_Analytics) all succeed. LA Data Collector API returned HTTP 200 with the action JSON including populated anomaly_reason. arm-ttk local: 49/49 pass on Package/3.0.1.zip. 3.0.0.zip retained per repo policy.
mazamizo21
force-pushed
the
feature/vaikora-asc-v3.0.1-agent-id-fix
branch
from
5ae2531 to
ceaa077
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
End-to-end testing surfaced that the 3.0.0 solution was built against an assumed alert-shaped API response while the Vaikora `/api/v1/actions` endpoint actually returns action-shaped events. This caused failures across the playbook and all three analytic rules. This PR aligns the entire solution on the action-field schema and the `Vaikora_AgentSignals_CL` table.
Defects in 3.0.0
`Poll_Vaikora_Actions` always sent `agent_id=` even when `VaikoraAgentId` was blank. Vaikora API returned HTTP 422 because Pydantic cannot parse `""` as a UUID. Every downstream action skipped.
`Send_to_Log_Analytics` crashed with `InvalidTemplate` because `replace()` ran against null `title` / `description` fields that do not exist on the response.
`Filter_High_Risk_Actions` referenced `threat_detected`, which is missing from the response.
Three analytic rules queried `Vaikora_SecurityAlerts_CL` with columns (`AlertId_s`, `Title_s`, `Description_s`, `SourceIP_s`, `UserName_s`, etc.) that the playbook never wrote.
Same solution shipped two divergent target tables: standalone playbook wrote to `Vaikora_SecurityAlerts`; mainTemplate inner playbook wrote to `Vaikora_AgentSignals`. Rules failed to match in both install paths.
Fix
Align everything on the action-field schema and `Vaikora_AgentSignals_CL`:
Files changed
Test plan
cc @v-maheshbh @v-shukore