SOAR Management Process
This document is a process guide and reference for KPMG GSOC management and tooling engineers for the process of managing the configuration of SECOPS and related GSOC processes. The RSA Archer SECOPS tool is a core component of the KPMG GSOC that is integrated tightly with both process and technology; it is the principal workflow engine for the GSOC. It has a highly flexible design, which can sometimes lead to unusual configurations. The purpose of this document is to provide a framework that simplifies the management of SECOPS configuration.
This process document does not go into elaborate detail, provide low-level technical procedures, or address all potential outcomes or failure cases. It provides the guide for identifying what needs to be considered and captured for SECOPS as it evolves. This is not intended to replace the change management process, but is considered an adjunct to the change management process to ensure that SECOPS and GSOC process change is appropriately managed.
This document is ultimately owned by the GSOC Director. He or she is responsible for ensuring that this is updated and maintained in response to feedback from GSOC Tooling Engineers.
This document is intended for the GSOC Tooling Engineer, the GSOC Director, the GSOC Assistant Manager, and the L3 Analyst.
This document should be reviewed on at least a 6 month basis, or at any time that the Constraints or Assumptions (Appendix 1) are believed to have changed. Data affected by this process (such as the updated SECOPS configuration made in accordance with this process) should be maintained continually
Exceptions to this process can be temporarily authorized by the GSOC Director or Assistant GSOC Director.
Failure to adhere to this process must be reported to the GSOC Director.
The following roles have overall responsibility for elements of this process. Please note that these are not comprehensive listing of responsibilities of each of the following roles, but represent these roles’ specific responsibilities to support the triage process.
The GSOC Director has overall responsibility for and authority over the process by which SECOPS is configured and customized, and for ensuring that SECOPS is optimized to meet the needs of the GSOC for security incident management and reporting.
The GSOC L3 Analyst has overall responsibility for ensuring issues with SECOPS are identified and resolved, and that change recommendations and requests are escalated and prioritized to the GSOC Tooling Engineer for action, and that Tooling Engineer recommendations/decisions on impact analysis are periodically reviewed.
The GSOC Tooling Engineer is responsible for maintaining SECOPS, consolidating change requests, tracking SECOPS configuration, and identifying probable impact and effort of proposed SECOPS changes.
All other GSOC Members are responsible for identifying issues or challenges with SECOPS workflows, content, and configuration to the GSOC Tooling Engineer.
- Intelligence Management Process
- Reporting Process
- Change Management Process
- Reporting Process
This process overview provides the key parts of the SECOPS Customization process. The process proceeds with the following workflow:
There is a potential for confusion between change management, and the requirement for managing change to SECOPS and GSOC processes in a discrete manner. The following table is provided to support better understanding of how each process is applied.
|Event/Change||SECOPS Customization Process||Change Management Process|
|New member firm added which will change process by which incidents are handled (due to unique requirement)||Will need to be executed||Only if change to SECOPS or other system is required.|
|GSOC Analysts recommend change to existing SECOPS field||Will need to be executed||Will need to be executed if net positive impact of change is confirmed.|
|SECOPS version will be upgraded||Will need to be executed||Will need to be executed if net positive impact of change is confirmed.|
|New content rules in SA require change to CRITS prioritization scheme||Will need to be executed||Will need to be executed if net positive impact of change is confirmed.|
The primary goals of this process are:
- To ensure that SECOPS configuration and functionality is managed in a way that maximizes its effectiveness to the GSOC.
- Ensure a straightforward, usable, and understandable GSOC analyst workflow.
- Ensure that change to SECOPS is managed in a fashion which incorporates analyst training needs and remains quick enough to respond to changing requirements.
The primary outputs of this process will be updates to SECOPS-related GSOC processes, training documents that describe the process changes to GSOC analysts, updates to artefacts that describe how SECOPS is configured, and input to the change management process.
Several GSOC processes are enforced or encouraged by SECOPS configuration decisions. If these processes are in specific process documents, these must be updated in response to SECOPS process changes.
Due to the arrangement of GSOC work schedules, it will be important to ensure that key changes to SECOPS GSOC processes are communicated in a way that can be handled on an individual or team basis to train on the changed process. The precise delivery mechanism or combination of delivery mechanisms for this training will depend on the complexity of the process change. Some potential mechanisms include:
- Hand-out/checklist that requires sign-off by all analysts to confirm understanding
- Recorded video presentation to describes new processes and requires sign-off by all analysts to confirm understanding
- Computer-based training to provide analysts walk-throughs of new/changes processes and test understanding.
- Access to the QA environment to provide analysts an ability to walk-through new/changed processes
Due to the complexity of SECOPS, detailed documentation of SECOPS configuration, interfaces, workflows, and other customizations must be maintained. At a minimum, there will be documentation of the following items supporting the new SECOPS configuration. Some of the documentation of these items will be included in other process documentation (e.g., reporting process).
- Mapping of all SECOPS related processes (e.g., triage, escalation, etc.,) to specific SECOPS named process phases.
- Identification of all normally used fields or applications within SECOPS that will be hidden from analysts, with a reason provided for their hidden status.
- Identification of all renamed or moved fields or applications with SECOPS, with a reason provided for their changed status.
- Identification of all additional (hidden or visible) variables, fields, and applications within SECOPS, with a reason provided for the additional requirement.
- A detailed application flow diagram for all SECOPS interfaces to external systems or devices.
- A detailed interface description for all SECOPS interfaces to external systems or devices. This will include network locations (ip addresses, logical location), connection information (i.e., protocol, port, file location), interface authentication credentials, and detailed interface format and content description.
- Mapping of Content Rules and/or categories to SECOPS response procedures.
- A listing of all supporting documentation that has content that places requirements of SECOPS configurations (e.g., reporting process, triage process).
- A detailed description of all custom SECOPS roles and/groups added to SECOPS, along with a reason for the addition.
- A detailed mapping of all SECOPS groups/roles to GSOC roles, external roles and external authentication/authorization stores (e.g., IDAM, AD).
The final output of the SECOPS Customization Process is specific configuration information (e.g., install packages, step-by-procedures, application code, etc.,) needed to conduct the update to SECOPS and associated systems, that will be used to support the Change Management Process.
There are multiple potential sources of data input, some direct and some indirect, that will drive potential SECOPS changes. Specific examples include:
- Modification or Additions to the data/logs provided by member firms.
- Modification to specific content rules that require changed in SECOP (e.g., response procedures)
Changes to GSOC process will occur due to changing stakeholder requirements, change to existing constraints and/or assumptions, and other changes to the operating environment.
There are numerous GSOC components which will integrate with SECOPS in different ways. Key drivers of change to SECOPS include changes to the following interfaces:
- Interfaces to Upstream data providers (Security Analytics)
- Interfaces to intelligence systems (CRITS)
- Interfaces to security portals
- Interfaces to external data sources (Active Directory)
Changes to any of the multiple systems and applications that make up or support SECOPS can potentially result in change to SECOPS. Key examples include:
- Archer Upgrades
- Operating System upgrades
- Database upgrades
- Web application server upgrades
The key consideration within the SECOPS Customization Process is identifying the level of impact from proposed changes to SECOPS. This is in an unstructured process that relies on a review of all potential impacts to the change. There are two types of impact assessments.
The purpose of this assessment is to identify the overall impact to GSOC capabilities based on a change to SECOPS. These specific impacts should be identified as part of the data provided to the L3 and/or the change management process. Key items to consider and document when weighing a potential change to SECOPS:
- Does this affect security incident detection rates or timelines?
- Does this affect security incident handling throughput or capacity?
- Does this add complexity which could have unexpected collateral impacts?
- Does this affect what Member Firms experience or receive from the GSOC (e.g., SLA’s)?
- Does this affect system stability, reliability, or capacity management?
- Does this require a significant change in GSOC member skill or training?
This is a more specific assessment, to determine if changes to external items potentially change GSOC process. Items to consider include:
- Does this significantly change the interface appearance or data content shown in security incidents for analysts?
- Are analysts expected to provide or create new information as part of the security incident handling process?
- Constraints and Assumptions
The purpose of this appendix is to describe significant constraints and assumptions that are the key drivers for the design and content of this process. The purpose of identifying these key constraints and assumptions is to ensure that when constraints change or assumptions are disproven, that the processes are examined to ensure that they still apply and are optimized for the goals of the GSOC.
Significant rates of change
Initially, there will be significant amount of changes to the GSOC (new countries, new logs, new capabilities, new members) that will potentially drive large amounts of and frequent changes to SECOPS and related systems.
Large dependencies between GSOC systems
Initial designs show a significant amount of interrelations between systems (SECOPS, CRITS, SA, Sharepoint) that potentially create strong and complex dependencies. These dependencies mean that almost all changes to other system potentially impact SECOPS.