Palo Alto Networks Certified Security Automation Engineer (PCSAE)Incident ManagementHard
A security analyst is reviewing an incident in Cortex XSOAR and notices a custom incident field named 'Attack Vector' that is crucial for their investigation. However, they are unable to edit its value, even though they have full 'Analyst' permissions. Other fields, like 'Incident Owner', are editable. What is the most probable reason for the 'Attack Vector' field being non-editable?
- AThe field's value was automatically populated by an integration and is locked from manual changes.
- BThe analyst's 'Analyst' role does not have field-level write permissions specifically for 'Attack Vector'.
- CThe incident is currently in a 'Closed' state, preventing further edits.
- DThe 'Attack Vector' field is configured as a 'Read-only' field globally or for that incident type.
Show answer & explanationAnswer & explanation
Correct answer: D. The 'Attack Vector' field is configured as a 'Read-only' field globally or for that incident type.
Custom fields can be configured as 'Read-only' either globally or specifically for certain incident types. This setting takes precedence over general role permissions for that particular field, preventing any manual edits regardless of the user's role.
Why the other options are wrong
- A. Fields populated by integrations can sometimes be locked, but the 'Read-only' configuration is a more direct and common way to enforce non-editability for a specific field, regardless of its population method.
- B. While field-level permissions exist, a 'Read-only' configuration at the field or incident type level is a more fundamental restriction that would apply even with write permissions.
- C. While a closed incident often restricts edits, the question implies other fields are editable, ruling out the incident state as a sole cause.
Cortex XSOAR Field Read-Only Configuration
Incident fields in Cortex XSOAR can be configured as 'Read-only' at either a global level or for specific incident types. This setting prevents manual modification of the field's value, ensuring data integrity or reflecting data that should only be controlled by automation.
- Overrules general user permissions for that field.
- Can be set during field creation or editing.
- Ensures data consistency and prevents accidental changes.
- Often used for fields populated by external systems or fixed data.
Memory trick: Read-Only Rules; Permissions are secondary tools.