Other additional Security Incident Response setup tasks
If you are an administrator in the global domain, you configure how Security Incident Response handles day-to-day operations.
Before you begin
These options are standard to many service management applications, and as such, they use service management terminology. For example, Request is used for the main task (that is, the security incident) and Task is used for subtasks or Response Tasks.
If you are an administrator in a domain lower than the global domain, you can view the Configurations screen, but cannot modify the settings.
Procedure
Lock down security administration
To protect investigations and keep security incidents private, you can restrict Security Incident Response access to security-specific roles and ACLs. Non-security administrators can be restricted from access, unless you expressly allow them entry.
Before you begin
When the Security Incident Response application is activated, the System Administrator user is granted the sn_si.admin role by default. The System Administrator is the only administrator who can set up security groups and users.
A security role is required to have access to Security Incident Response features and records.
Role required: sn_si.adminProcedure
Manage Restricted Caller Access
The Restricted Caller Access (RCA) feature enables an administrator to define cross-scope access to an application or application resource and allow or deny access requests. This feature is enabled in Security Incident Response by default so security analysts can protect sensitive security-related information.
Run quick start tests for Security Incident Response
Validate that Security Incident Response still works after you make any configuration changes, such as applying an upgrade or developing an application. Copy and customize these quick start tests to pass when using your instance-specific data.
Security Incident Response quick start tests require activating Security Incident Response plugin (com.snc.security_incident) and loading the demo data.
| Test | Description | Release version |
|---|---|---|
| SIR: Create Security Incident | Determine whether a user can successfully create a security incident from the security incident form. | Madrid |
| SIR: Create Security Incident via Security Incident Catalog | Determine whether a user can successfully create a security incident from the catalog. | Madrid |
| SIR: Security Incident life cycle | Validate the response tasks of the Policy Violation workflow. | Madrid |
| SIR: PIR Assessments OOTB configuration test | Use this test to validate PIR assessments and base system configurations. | Tokyo |
| SIR: PIR Assessments conditional Configuration tests | Verify that security incidents matching the mandatory conditional rule are not closed without completing the post incident assessment. Verify that the security incidents matching the optional conditional rule can be closed without completing the post incident assessment. Verify that assessments are not generated for the security incidents that do not match any rule. |
Tokyo |
| SIR: PIR Run Time Experience | Verify that PIR reports are configured and attached to the security incidents as per the new design. | Tokyo |
| SIR: PIR Design Time Experience | Verify that the security incident is mapped with the report template based on the administrator configuration. | Tokyo |
| SIR: Link Security Incident to a existing Major Security Incident | Link a Security Incident to an existing Major Security Incident and validate data from Security Incident rolled up to Major Security Incident. | Tokyo |
| SIR: Promote Security Incident as Major Security Incident | Promote a Security Incident as Major Security Incident and validate data from Security Incident rolled up to Major Security Incident. | Tokyo |
| SIR: Propose Security Incident as Major Security Incident | Propose a Security Incident as Major Security Incident and validate data from Security Incident rolled up to Major Security Incident. | Tokyo |
| SIR: Security Incident life cycle | Validate a Security Incident life cycle with the policy violation response tasks workflow. | Yokohama |
| SIR: Create Security Case | Create a Security Case from the Security Incident form. | Yokohama |
| Verify that only Allowed Members can access the security incident once Enforce Restriction is ON | Verify that only the allowed members can access the security incident once the Enforce Restriction is enabled. | Yokohama |
| Verify that security incident enabled with "Enforce Restriction" is not visible for any user | Verify that security incident enabled with "Enforce Restriction" is not visible for any user. | Yokohama |
| Validate Read Access | Validate the view access. | Yokohama |
| Validate Write Access | Validate the edit access. | Yokohama |
| SIR Workspace: Read Access | Verify that Read Access user can view the security incident without having security roles even on workspace. | Yokohama |
| SIR Workspace: Write Access | Verify that Write Access user can update the security incident without having security roles. | Yokohama |
| SIR Workspace: Create new Security Incident | Create new security incident from workspace. | Yokohama |
| SIR Workspace: Create Response Task | Create new response task from an existing security incident. | Yokohama |
| Now Assist for Security: Active Security Incident Summarization | Summarize an active security incident and validate the displayed sections. | Zurich |
|
Now Assist for Security: Security Incident Summarization_Share to worknotes |
Share the generated summary to worknotes. | Zurich |
| Now Assist for Security: Closed Security Incident Summarization | Summarize a closed security incident and validate the displayed sections. | Zurich |