RSA Archer Security

Operations Management 1
Practitioner Guide
Contact Information
Go to the RSA corporate web site for regional Customer Support telephone and fax numbers:
http://www.emc.com/support/rsa/index.htm.
Trademarks
RSA, the RSA Logo, RSA Archer, RSA Archer Logo, and EMC are either registered trademarks or trademarks of EMC
Corporation ("EMC") in the United States and/or other countries. All other trademarks used herein are the property of their
respective owners. For a list of RSA trademarks, go to www.rsa.com/legal/trademarks_list.pdf.
License agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and may
be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice below. This
software and the documentation, and any copies thereof, may not be provided or otherwise made available to any other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.
Third-party licenses
This product may include software developed by parties other than RSA.
Note on encryption technologies
This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption
technologies, and current use, import, and export regulations should be followed when using, importing or exporting this
product.
Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

Copyright © 2014 EMC Corporation. All Rights Reserved. Published in the USA.
January 2014
Practitioner Guide

Contents

Preface 6
About This Guide 6
RSA Archer Documentation 6
RSA Archer Security Operations Management Documentation Set 6
RSA Archer Security Operations Management Data Dictionary 7
Support and Service 7
Chapter 1: Security Operations Management 9
Security Operations Management 9
Challenges in Security Operations Management 10
RSA Archer Security Operations Management 10
Solution Sources, Standards, and Frameworks 12
Architecture Overview 13
RSA SOC Reference Architecture 13
RSA Archer Security Operation Management Architecture 14
Key Personas in Security Operations Management 15
SOC Manager 16
Incident Coordinator 17
L1 Incident Handler 18
L2 Incident Handler 19
CSO/CISO 20
IT Helpdesk Analyst 21
Cyber Threat Intel Analyst 21
Business Unit Manager 22
Corporate Compliance/Privacy Officer 23
RSA Archer Security Operations Management Workflow Overview 23
Solution Dashboards 25
L1/L2 Incident Handler Dashboards 26
Incident Coordinator Dashboard 27
SOC Manager Dashboard 28
Breach Response Dashboard 29
IT Helpdesk Dashboard 29
Solution Implementation 30
Managing SOC Readiness 30
Responding to Incidents 31
Responding to Data Breaches 32
Remediating Issues 32
Chapter 2: Managing SOC Readiness 34
Managing SOC Staff and Contacts 34
Document Solution Users 34
Document SOC Staff Skill Sets 35
Document SOC Teams and Team Members 35
Managing SOC Policies and Procedures 36
SOC Policies 36
SOC Policy Review Process 37
Document SOC Policies 37

3
Practitioner Guide

SOC Procedure Library 38

Document SOC Procedures 38
Call Trees 39
Set Up Call Trees 39
Security Controls 39
Document Security Controls 39
View Security Control Efficacy 40
Chapter 3: Responding to Incidents 42
Incident Response Workflow 42
Alerts vs Incidents 44
Aggregating Multiple Alerts into a Single Incident 44
Incident Status 45
Declared Incidents 46
Confidential Incidents 47
Creating an Incident 47
Create an Incident Manually in the Security Incidents Application 47
Create an Incident Manually from Security Analytics 47
Assigning Incidents 48
Assign Yourself an Incident from the Queue 48
Assign an Incident to a Handler 48
Review an Incident 49
Using Investigations 52
Create an Investigation 52
Close an Investigation 52
Complete Incident Response Tasks 53
Add Shift Notes to an Incident 53
Escalate an Incident 54
Review an Escalated Incident 54
Perform and Document Forensic Analysis 55
Document Impact Analysis 56
Log Issues for Remediation 57
Document Overall Incident Analysis Results 58
Close an Incident 58
Shift Handovers 59
Shift Handover Workflow 59
Create a Shift Handover Report 59
Review a Shift Handover Report 60
Chapter 4: Responding to Data Breaches 61
Data Breach Response Workflow Overview 61
Breach Response Lead 62
Breach Record Team 62
Create a Breach Record 62
Document Data Disclosed and Assign the Breach Response Team 63
Provide Breach Impact Analysis 63
Complete a Breach Risk Assessment 64
Decide Whether to Declare a Breach 65
Creating and Assigning Breach Tasks 65
Manually Create and Assign Breach Tasks 65
Complete Breach Tasks 66

4
Practitioner Guide

Executing a Call Tree 66

Execute a Call Tree 66
Log Issues for Remediation 66
Close a Breach Record 67
Chapter 5: Remediating Issues 68
Issue Remediation 68
Findings Process 68
Resolve a Finding 68
Review a Finding 69
Exception Request Process 70
Create a New Exception Request 70
Assign an Exception Request for Review 70
Review an Exception Request 71
Remediation Plans Process 71
Create a New Remediation Plan 72
Review a Remediation Plan 72
Appendix A: Configure the SecOps Theme 74

5
Practitioner Guide

Preface

About This Guide

This guide contains information that helps RSA® Archer™ GRC administrators and
users understand the business use of the RSA Archer Security
Operations Management™ solution.
This guide assumes the reader is knowledgeable about the GRC industry and
RSA Archer GRC.

RSA Archer Documentation

You can access the RSA Archer documentation from the RSA Archer Exchange
and RSA Archer Community.

Documentation Location

Platform On the RSA Archer Community at:

https://community.emc.com/community/connect/grc_
ecosystem/rsa_archer

Solutions, Applications, On Content tab on the RSA Archer Exchange at:

and Content https://community.emc.com/community/connect/grc_
ecosystem/rsa_archer_exchange

RSA continues to assess and improve the documentation. Check the RSA Archer
Community and RSA Archer Exchange for the latest documentation.

RSA Archer Security Operations Management Documentation Set

For information about the RSA Archer Security Operations Management solution,
see the following documentation:

Guide Description

Release Notes Introduces the RSA Archer Security Operations Management

solution, lists the documentation available, and provides
information for obtaining support and service.

Overview Guide Introduces the RSA Archer Security Operations Management

solution and provides information about the solution, any
subsolutions, and the applications.

Preface 6
Practitioner Guide

Guide Description

Installation Guide Provides administrators with instructions to install the

solution.

Practitioner Guide Provides usage scenarios highlighting how the solution

works.

You can access the RSA Archer Security Operations Management solution
documentation from the Documents page on the RSA Archer Exchange at
https://community.emc.com/community/connect/grc_ecosystem/rsa_archer_
exchange.

RSA Archer Security Operations Management Data Dictionary

The RSA Archer Security Operations Management Data Dictionary contains
configuration information for the solution, including the user groups and access
roles that must be created.
You can obtain the Data Dictionary for the solution by contacting your RSA Archer
Account Representative or calling 1-888-539-EGRC.

Support and Service

Customer Support www.emc.com/support/rsa/index.htm
Information

Customer Support [email protected]

E-mail

RSA Archer https://community.emc.com/community/connect/grc_

Community ecosystem/rsa_archer

RSA Archer https://community.emc.com/community/connect/grc_

Exchange ecosystem/rsa_archer_exchange

RSA Solution https://gallery.emc.com/community/marketplace/

Gallery

RSA SecurCare https://knowledge.rsasecurity.com/cleartrust/ct_

Online logon.asp?CTAuthMode=BASIC&language=en&amp
;CT_ORIG_
URL=https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fknowledge.rsasecurity.com%3
A443%2F&ct_orig_uri=%2F

7 Preface
Practitioner Guide

The Community enables collaboration among GRC clients, partners, and product
experts. Members actively share ideas, vote for product enhancements, and discuss
trends that help guide the RSA Archer product roadmap.
The Exchange is an online marketplace dedicated to supporting GRC initiatives.
The Exchange brings together on-demand applications along with service, content,
and integration providers to fuel the success of RSA Archer clients.

Preface 8
Practitioner Guide

Chapter 1: Security Operations Management

Security Operations Management

In the last few years, the information security industry has seen an upheaval in the
understanding and definition of security incident response. Highly visible, high
impact data breaches have clearly defined a turning point in the world of
information security. Multiple studies and reports have been issued on the changing
threat landscape. Hactivism, APTs, the digital underground, and many other trends
have stressed to companies that incident response—while always a core part of
information security for years—is not a stagnant science but a continually evolving
art. The ability of an organization to identify active attacks to their assets and to
respond quickly is essential to deal with the growing number, sophistication, and
tenacity of today’s security threats.
To protect a company against today’s threats, an IT security organization must
create a holistic strategy by implementing processes, tools, procedures, and
enablers. The program should have a continuous cycle that flows from prevention to
detection to response with a feedback loop to ensure that threats are proactively
managed as much as possible. No organization can prevent every attack. The
likelihood that a company will face a data breach has approached the absolute
inevitable. The goal should be to identify and prevent as much as possible,
effectively detect and respond to active threats, learn from events and incidents,
and improve going forward. A key part of this strategy is security operations
management.
The objectives of security operations management are to:
l Effectively and efficiently identify active attacks within an organization
l Escalate the attack to a team that has the skills and resources to analyze,
respond to, and contain the threat
l Remediate the issue as fast as possible
l Approach incident response in an operational way – not as a loose, ad-hoc
process

Note: Incident response centers are known by several names. The most common
ones are Security Operations Center (SOC), Critical Incident Response Center
(CIRC), Computer Security Incident Response Team (CSIRT), and Critical
Incident Response Team (CIRT). In this document, the term Security Operations
Center (SOC) team will refer to the overall team of individuals charged with
identifying and resolving security issues.

9 Chapter 1: Security Operations Management

Practitioner Guide

Challenges in Security Operations Management

Several key challenges make implementing a consolidated, organized security
operations management process difficult. The result of these challenges is that,
many times, a security attack can escalate into a major data breach before the
security team has a chance to contain the issue.
1. The SOC team needs a centralized incident management solution for managing
all alerts from security monitoring tools that require review and triage by SOC
analysts. A typical SOC has multiple security alerts sources and call centers
that enable employee crowdsourcing of security intelligence. Without a
centralized tool to aggregate and manage the security alerts and their review
process, SOCs cannot scale their incident response process.
2. Context (such as asset, data, identity, and business impact metrics) and cyber
threat intel (such as known attack vectors and C2 domains) are crucial for
efficient and effective incident triage. Current tools lack integrated context and
threat intel, requiring manual data collection for reviewing cases and inefficient
prioritization of incidents.
3. SOCs are struggling to gather, organize and share threat intelligence between
security teams. If the SOC is manned 24x7, or incident handling is outsourced at
times to a third party, the hand-off between shifts and resources is very manual
and things slip through the cracks.
4. SOC teams are struggling with disconnected processes and systems to manage
the end-to-end security incident lifecycle. Most incident reviews require cross-
functional engagement and business process workflows to enable collaboration.
5. Organizations lack a defined approach to develop incident response procedures
and industry best practices for incident and breach management. Incident
handlers may lack in-depth security incident analysis experience and need
incident response guidelines to help them quickly analyze the security incidents
and either classify them as false positives or escalate them to more experienced
analysts for further investigation. Team members also need to be aware of
organizational and regulatory policy requirements when handling a data breach.
6. SOC Managers need a tool to optimize SOC investments. SOC teams are
always under pressure to demonstrate return on investment and make the most
of the budget they are allocated. SOC Managers need a tool that helps perform
analytics on security alert and incident response data to identify SOC
performance metrics and control effectiveness.

RSA Archer Security Operations Management

The RSA Archer Security Operations Management solution provides four primary
capabilities:

Chapter 1: Security Operations Management 10

Practitioner Guide

l Incident Management. The RSA Archer Security Operations Management

solution integrates with systems that collect security alerts, such as RSA
Security Analytics. RSA Archer Security Operations Management then provides
a workflow-driven incident response process. Context and intelligence are
critical for effective security incident management process and RSA Archer
Security Operations Management makes the context (asset attributes and
business context from the Enterprise Management solution) available to an
analyst when reviewing/triaging an incident. Incidents can be then escalated to
the various analysts during the investigation and response process.
l Breach Management. Data breaches have dramatic impact on organizations:
they may result in large fines (regulatory, PCI), loss of competitive advantage,
business disruption, brand damage, lack of trust, and more. As a result,
organizations care about data breaches and need to quickly manage and
remediate a breach once identified. The RSA Archer Security Operations
Management solution helps organizations manage breach remediation tasks and
procedures by running a cross functional program that provides visibility to senior
executives.
l SOC Program Management. RSA Archer Security Operations Management
enables SOC Managers to effectively monitor SOC KPIs, measure control
efficacy, and manage SOC team personnel.

l IT Security Risk Management. RSA Archer Security Operations Management

integrates with other RSA Archer GRC solutions, such as Business Continuity
Management and Enterprise Risk Management, to maximize returns on RSA
Archer solutions and deliver quick time to value.

11 Chapter 1: Security Operations Management

Practitioner Guide

Solution Sources, Standards, and Frameworks

The RSA Archer Security Operations Management solution leverages several
different sources and frameworks for solution workflows and capabilities. Because
security operations management can be a complex discipline, you may want to refer
to these sources for further information about responding to and investigating
security incidents.

Standard Description

NIST This publication provides guidelines and best practices for incident
SP800-61 management. A key part of this document is the phases of incident
management, especially post-incident analysis. The RSA Archer Security
Operations Management solution uses several of these concepts within the
solution design.
http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-
61rev2.pdf

US-CERT In the RSA Archer Security Operations Management solution, you can
extend the Threat Category enumeration to include the seven incident
categories (CAT0 – CAT6) that US-CERT uses. You can also create
response procedures for each of these categories in the SOC Procedure
Library application, and then automatically generate incident response
tasks for incident handlers.
https://www.us-cert.gov/government-users/reporting-
requirements

SANS 20 The RSA Archer Security Operations Management solution provides the
Critical capability to track all of the security controls deployed in your
Security organization, such as the SANS top 20, and monitor their effectiveness at
Controls detecting, preventing, or investigating security incidents.
http://www.sans.org/critical-security-controls/

Verizon The RSA Archer Security Operations Management solution uses the VERIS
VERIS framework for taxonomy and enumerations, enabling standard incident
Framework reporting and consistent information sharing with others.
http://www.verizonenterprise.com/resources/whitepapers/wp_
verizon-incident-sharing-metrics-framework_en_xg.pdf

Chapter 1: Security Operations Management 12

Practitioner Guide

Architecture Overview
RSA SOC Reference Architecture
The RSA Archer Security Operations Management solution is part of a broader
architecture to respond to today's security attacks. A security operations
management program depends on multiple technologies to identify and respond to an
active attack. As shown in the following diagram, RSA Archer Security Operations
Management (denoted as RSA SecOps) provides the overlay of program
enablement to the incident response process.

Additional components of this broader architecture include the following:

l RSA Archer Enterprise Management is a required component of the overall
solution and provides the asset and business context information to support all
solution processes. The RSA Archer Enterprise Management solution gives you
an aggregate view of critical infrastructure technologies and their relationships to
your organizational hierarchy and business offerings and enables you to relate
assets to the business processes that they support. This information provides
immediate business context to incident handlers, giving them insight into the
possible business impact of a security event and allowing them to appropriately
prioritize incidents.
l RSA Security Analytics provides the deep network packet and event forensics
necessary to identify security attacks. For companies that do not utilize RSA
Security Analytics, this function may be performed by other technologies such as
SIEM and log management tools. Regardless of the technology, security
operations management requires insight into the actual system and security

13 Chapter 1: Security Operations Management

Practitioner Guide

events occurring on the network and hosts. The business criticality of a given
asset (as defined by RSA Archer Enterprise Management) should also drive
forensic and monitoring priorities in RSA Security Analytics. The integration
between RSA Archer and RSA Security Analytics streamlines this process.
l RSA ECAT represents the host level forensics capabilities to deal with today’s
malware attacks. Many security threats today utilize malware as launching
points to larger security breaches. Security operations need this type of capability
to analyze and identify malicious software at the host level.
l RSA Live Intelligence. With today’s constant change in security threats, security
operations need a constant flow of security intelligence to adapt and focus on
emerging threats. RSA Live represents the need for an up-to-date feed of
security information to adjust security operation priorities based on the latest
security intel such as indicators of compromise (IOCs), threat attach vectors,
known bad hosts, or malicious threat actors.

RSA Archer Security Operation Management Architecture

The RSA Archer Security Operations Management solution is architected to
streamline the escalation of security alerts from monitoring systems to an incident
response process, enabling security incidents to be analyzed, investigated and
resolved. The following diagram shows the high-level architecture of the RSA
Archer Security Operations Management solution.

The solution is comprised of three main elements:

l The RSA Archer Security Operations Management solution provides the process
workflow, reporting, and program management capabilities necessary to manage
a security operations center.
l RSA Security Analytics serves as the source of security alerts.

Chapter 1: Security Operations Management 14

Practitioner Guide

l RSA Archer Enterprise Management is a required component of the overall

solution and provides the asset and business context information to support the
entire process. This document does not go into detail of Enterprise Management,
however, the following are some key points to consider:
l For organizations that do not have a significant IT asset catalog or an existing
RSA Archer Enterprise Management implementation, a discussion of how this
catalog will be built should be part of the overall security operations strategy.
This may be as simple as starting with cataloging known business critical
devices such as key production, application, database and file servers or
networking devices and infrastructure. From this starting point, more assets
can be added. If the organization does have an IT asset catalog but limited
insight into the business context (such as usage, related business process, and
the business ownership/contact), the process may focus on building tactical
relationships between business processes, IT applications and devices and
executing business impact analysis. These functions are included in the RSA
Archer Enterprise Management solution.
l The more business context (through relationships to business assets) the
security operations team has on IT assets, the better the prioritization process
for security events will be. This will require an analysis of the existing and
planned attributes of IT assets within the RSA Archer Enterprise
Management solution to ensure a security operations has contextual
information for security response processes.
l Additional attributes on IT assets (such as compliance states, risk
assessments, vulnerability scan results or other information that gives the
security responders insight into the risk profile of an asset) can also play a big
role in proper containment of a security incident. Therefore, as part of the
overall implementation strategy, the continuous growth of the asset
understanding should be included.

Additional RSA Archer solutions (such as RSA Archer Business Continuity

Management) can also be integrated to extend the organization’s capabilities and
blend security operations management into the bigger IT and business risk
management program. This is also out of the scope of this document.

Key Personas in Security Operations Management

A SOC team, in most cases, has three to four sub-teams as summarized in the
following diagram. In a typical setup, over 50% of analysts are Level 1 (L1)
Incident Handlers, followed by Level 2 (L2) Incident Handlers and Cyber Threat
Intelligence Analysts.

15 Chapter 1: Security Operations Management

Practitioner Guide

The management of a SOC team is a complex process. These personas may be

shared between different individuals or multiple personas may be assigned to one
individual. These personas are reflected in various workflows and processes within
the RSA Archer Security Operations Management solution and the solution helps
each role with their key challenges.

SOC Manager

Job Description
The SOC Manager runs the SOC and owns the SOC budget which eventually rolls
up to CISO/CSO. The SOC Manager is responsible for the following (but not
limited to) tasks:
l Preventing successful cyber-attacks and leakage of sensitive information from
the organization as much as possible by deploying various types of security
controls.
l Effectively responding to security incidents to minimize impacts to the business.
l Providing visibility to CISO/CSO & Business Managers on ongoing incidents and
possible cyber threats that affect the organization through a combination of
periodic reports and real time dashboards.
l Tracking SOC KPI/KRIs and managing the SOC resources and budget in the
most effective way to meet objectives above.

Key Challenges
Most SOC teams rely on a collection of manual processes, home grown tools and
scripts and an IT Helpdesk system for managing security incidents and cyber threat
intelligence. The SOC Manager faces the following challenges:
l Needs business, asset, identity, and threat intelligence context for an effective
response to security incidents, but this information is difficult to organize.

Chapter 1: Security Operations Management 16

Practitioner Guide

l Incident management processes are too manual, which leads to a lot of

inefficiencies including the lack of centralized tool for incident collection and
aggregation, inconsistent priorities across alerts, manual response procedures,
and remediation tracking.
l Wants the team to stay ahead of the adversaries by collecting cyber threat
intelligence data from different sources, reviewing them and taking a proactive
remediation action based on its impact to the organization.
l Wants to monitor SOC KPIs and KRIs in a dashboard by summary metrics in a
score card. However, this is challenging because the current tools and processes
lack consistent attributes and enumerations.

Primary Tasks
l Managing SOC Readiness
l Responding to Incidents
l Responding to Data Breaches

Incident Coordinator

Job Description
The Incident Coordinator manages the Level 1 and Level 2 teams at an operational
site. In a large organization, there are typically one or more Incident Coordinators
(sometimes considered Shift Managers) to help drive 24x7 coverage for the SOC.
The Incident Coordinator is responsible for ensuring that incident response SLAs
(service-level agreements) are met and high priority incidents are contained and
remediated immediately. The Incident Coordinator achieves this by completing the
following tasks:
l Defining and managing the incident response process.
l Ensuring response procedures are in place.
l Monitoring incident queues to ensure the SOC meets its SLAs such as MTTR
(mean time to resolution) for security incidents.
l Coordinating shift hand-offs by creating a daily shift handover report which is
used by his counterparts running shifts at different sites.

Key Challenges
l The incident response process is many times managed manually through separate
documents or through some ticket system which is not security oriented.
l Required to manage and respond to security alerts from multiple tools:
o Collection of security alerts from these tools and aggregation (grouping) of
similar alerts into a single incident is not automated.
o Varying alert priorities from different sources are not normalized to incident

17 Chapter 1: Security Operations Management

Practitioner Guide

priorities based on business, asset, and identity context as well as cyber threat
intelligence data.
l While triaging security incidents, incident handlers may spend 40 to 60% of their
time gathering contextual and threat intelligence data for internal and external
systems and identities involved in the incident. This consumes a significant
amount of the handlers' time and needs to be minimized by connecting incident
management tools with enterprise asset and user repositories.
l Needs defined incident response procedures for various categories of security
incidents to enforce consistent triage and review processes for responding to
incidents.
l Spends a lot of time summarizing the work done on high priority incidents during
the shift so that the next incident coordinator can pick them up from where the
previous incident handlers leyft them.
l Needs a real-time dashboard to monitor incident metrics such as status and SLAs
that are currently in L1 and L2 incident queues as well as pending remediation
from IT Operations.

Primary Tasks
l Managing SOC Readiness
l Managing Shift Handovers
l Managing Incident Handler Workloads
l Ensuring Timely Response to Incidents
l Responding to Incidents

L1 Incident Handler

Job Description
The L1 Incident Handler is a member of the Level 1 Incident Handler team and
reports to the Incident Coordinator. The L1 Incident Handler is typically an
intermediate level security expert responsible for the following tasks:
l Reviewing incidents in their incident queue first thing in the morning and
working through them in the prioritized order.
l If done with current issues and the Incident Coordinator has not yet added
anything to their queue, checking on the overall L1 incident queue for the shift,
adding appropriate incidents to their queue and working through them.
l During an incident review and triage process, spending the majority of his or her
review time gathering context and intel.

Chapter 1: Security Operations Management 18

Practitioner Guide

l Performing quick analysis of incidents to decide one of the following actions:

o Is the incident a false positive? Remove noise and document why the incident
is a false positive.
o Is this something that requires further investigation by an L2 Incident
Handler? If so, escalate.
o Is this a standard security incident with well-defined incident response
procedures? If so, follow the steps in the response procedure and recommend
remediation to IT Operations by opening a ticket in an IT Helpdesk system.
l Tracking open IT Helpdesk tickets for remediation before closing the incident.

Key Challenges
l Could benefit from economy of scale by grouping multiple similar alerts together
into an incident, instead of working on an individual security alert as an incident.
l Spends 40 to 60% of his or her time gathering context and threat intelligence for
systems, applications, and users involved in an incident.
l Could significantly benefit from incident response checklists for each category of
incident, so that all required procedures are executed for a given incident before
escalating or closing them.
l It is time consuming to manually create IT Helpdesk tickets and track the status
for all open security incidents.
l During the incident review process, the L1 Handler needs to take notes on
actions performed during incident response for reporting and historical audit
reasons. However, it is tedious to take notes in a paper notebook and then type
them into the incident management tool.
l Needs an L1 Incident Handler dashboard to track assigned queue, status of all
the incidents and their SLAs, as well as any open tasks.

Primary Tasks
l Responding to Incidents
l Remediating Issues

L2 Incident Handler

Job Description
The L2 Incident Handler is a member of the Level 2 Incident Handler team, reports
to the Incident Coordinator, and is typically a more senior security expert with
advanced skills in network and host forensics and malware reverse engineering. A
typical day at work includes the following tasks:
l Reviewing incidents in their incident queue first thing in the morning and
working through them in the prioritized order.

19 Chapter 1: Security Operations Management

Practitioner Guide

l If done with current issues and the Incident Coordinator has not yet added
anything to the queue, checking on the overall L2 incident queue for the shift,
adding incidents appropriate incidents to the queue, and working through them.
l During an investigation, using multiple network forensic tools such as RSA
Security Analytics and host forensic tools such as RSA ECAT to perform in-
depth analysis. After completing the analysis, records the observations of the
forensic investigation into the incident management tool and justifies whether the
system is compromised or not. If needed, can take steps to contain the
intrusion/infection immediately to minimize the impact of the attack.
l Creating tickets in an IT Helpdesk system for remediating a given incident and
tracking their completion before closing the incident.

Key Challenges
Many of the L2 incident handler’s issues are similar to those of the L1, although the
following issues are more important:
l Collect and visualize context (asset, data, user and file) and cyber threat
intelligence within the incident review tool so that he can significantly enhance
his productivity.
l During forensic analysis, needs to work with one or more security tools and has
to log into those tools and manually create filters to locate the alerts under
investigation.
l While performing forensic analysis, needs to take multiple notes and screenshots
that must be captured and organized for documentation of the investigation.

Primary Tasks
l Responding to Incidents
l Performing Forensic Analysis
l Recommending Issues for Remediation
l Remediating Issues

CSO/CISO

Job Description
(For purposes of this document, only the responsibilities related to Security
Operations are included.) The CSO/CISO is accountable for providing effective IT
security to the enterprise and responsible for the security tools and staff. The
CSO/CISO needs to receive consistent security incident summaries but is also part
of the escalation of any high impact security incident. If an incident results in a data
breach or loss, the CSO/CISO may take the lead role for driving the breach
management program.

Chapter 1: Security Operations Management 20

Practitioner Guide

Key Challenges
l Needs a consistent, real-time summary of security incidents and cyber threats to
the organization. Would prefer to have a dashboard that summarizes the metrics
instead of a weekly report from the SOC Manager and regular meetings to
discuss the details.
l Wants to be able to track SOC investments in security tools closely and measure
the efficacy of these controls, instead of asking the board or CFO for more
money.

Primary Tasks
l Managing SOC Readiness
l Monitoring Incident Metrics and Status
l Responding to Data Breaches

IT Helpdesk Analyst

Job Description
The IT Helpdesk Analyst is responsible for working through the queue of tickets
created by L1/L2 Incident Handlers for remediating security incidents. The analyst
assigns remediation tasks to system administrators in IT Operations.

Primary Tasks
l Remediating Issues

Cyber Threat Intel Analyst

Job Description
The Cyber Threat Intel Analyst is the lead for the Cyber Threat Intelligence team.
Typically this role is a security expert with advanced skills in cyber threat
intelligence gathering and tracking new attack patterns from adversaries by using
feeds from partnering SOCs, industry (such as FS-ISAC, REN-ISAC, and ENISA)
and government (such as DOD DC3, DSIE, and DIB) government sources. A
typical day at work includes the following tasks:
l Reviewing unstructured and relevant cyber threat intelligence feeds from one or
more sources.
l Identifying feeds that are relevant to the organization, creating new IOCs
(indictors of compromise) and attack patterns and feeding them to SIEM/SEM
tools such as RSA Security Analytics (via Live) to:
o Check if a similar pattern has occurred within his organization, but went
unnoticed

21 Chapter 1: Security Operations Management

Practitioner Guide

o Automatically detect events that match the IOC going forward by updating the
correlation rules.
l Sharing new threat intel with the industry and partners, based on the
organization’s policies and NDAs.

Key Challenges
l Manually reviews the threat intelligence data from various portals (such as DoD
and DHS portals) blogs, emails, and information sharing groups. This is just too
much information to review in a timely fashion. There is concern that important
intelligence data is missing because there is time to review only 10-20% of the
data available via these sources.
l Knows that threat intelligence sharing is a two-way road to effectively combat
advanced threats. Sharing new threat intelligence data with internal and outside
parties is minimal and done manually via emails or over phone, which is very
time consuming.
l The current process for reviewing and managing threat intel data is ad hoc.

Primary Tasks
l Investigating New Threat Intel

Note: There is no out of the box access role built for the Cyber Threat Intel
Analyst, however it is a role that you should consider as you develop your full SOC
management process.

Business Unit Manager

Job Description
The Business Unit (BU) Manager persona is a generic term for the individuals
outside of IT that are responsible for a line of business or department and may be
involved in identifying the business impact (if any) from security incidents and
recovering from them. A BU Manager may be involved in assisting with issue
remediation, depending on the nature of the incident.

Primary Tasks
Monitoring and ensuring remediation of issues:
l Reviewing a Finding
l Reviewing an Exception Request
l Reviewing a Remediation Plan

Chapter 1: Security Operations Management 22

Practitioner Guide

Corporate Compliance/Privacy Officer

Job Description
Depending on the size or structure of an organization, the title of this persona may
differ, but the role is responsible for ensuring that the policies and control
procedures required to meet regulatory requirements and follow industry best
practices have been implemented in the organization. For RSA Archer Security
Operations Management, this role is mostly concerned with the root cause of
security incidents and how they map to control procedures and regulatory
frameworks. This persona will most likely be engaged if there is a security incident
that results in data compromise or disclosure of regulatory related or personal
information and may take the lead role for driving the breach management program.

Primary Tasks
l Responding to Data Breaches

RSA Archer Security Operations Management Workflow Overview

How a security team investigates and resolves possible security attacks depends
greatly on the nature of the attack, the data and systems involved, the skills and
resources of the organization, and many other factors. The following diagram shows
the high-level workflow included in the RSA Archer Security Operations
Management solution. The purpose of this diagram is to provide an overview of the
SOC Management processes, how the work flows from one role to another, and
how the program is managed. More information on the individual stages of an
incident can be found in the respective chapters of this document.

23 Chapter 1: Security Operations Management

Practitioner Guide

The major personas are included from the initial identification of a possible security
event through the various escalations until closure. This workflow highlights the
importance of defining the hand-offs and communication methods between
personas. The RSA Archer Security Operations Management solution provides the
mechanism to manage these various workflows while engaging the different
personas.
The following points about the high-level workflow are important to consider:
l The escalation of events and alerts from the security event infrastructure may be
automated or manual. This will depend on the nature of the infrastructure. The
critical point is to define how an event is identified and how the SOC team is
notified of a possible security incident. The quicker this process happens, the
more likely the organization will be able to respond and contain security
incidents and prevent serious data disclosures, disruptions or negative impacts.
l The Level 1 and Level 2 analyst roles acknowledge that most organizations have
a mix of security resources with differing skills and experiences. In companies
with limited security resources, these roles may actually be assigned to one
singular team or resource. However, as a SOC matures, there will be the need to
expand resources into varying levels – leveraging the skills of experienced
security practitioners as Level 2 analysts while building the experience of Level
1 analysts.

Chapter 1: Security Operations Management 24

Practitioner Guide

l The supporting functions of the SOC team are varied. Security, IT, and Business
resources outside the SOC play an important role in understanding and properly
remediating a security incident. This communication is important to build a
support function that can input into the process when needed.
l The CISO and SOC manager have multiple responsibilities, but the following are
the main responsibilities:
o The security response program management need is growing in importance for
organizations. Incident Response can no longer be an ad-hoc process and
leveraging the skills and resources of the SOC is extremely critical. The SOC
Manager provides the frontline management while the CISO provides the
executive oversight for the entire program.
o Control Efficacy is also a growing need. Security organizations must invest in
high impact technologies and processes, and the security incident process can
give strong visibility into how well the controls are operating. The SOC
Manager can provide the CISO with frontline information on which controls
are working and which technologies are providing the most impact. The CISO
can then leverage this insight to guide security investments.
o Operational Procedures within the SOC are necessary to streamline response
and triage of incidents and leverage experience and skills across the security
team. These procedures should also be connected to the overall security
policy to ensure proper practices are implemented.
o The SOC Manager must ensure the Escalation Readiness is in place to move
an incident “up the chain” when warranted, especially in terms of data
breaches and disclosures. The CISO must also ensure that organization is
properly prepared for a data disclosure event with the right connections to the
business and compliance teams. Compliance and reputational risks can be
substantial when related to a data breach and the organization needs to have
proper processes in place to be prepared for a data breach.
o Reporting upwards from the SOC to the CISO to the business and executive
management will be very important. The SOC Manager should provide the
right level of empirical data (metrics) and anecdotal information (such as
lessons learned and threat trends) so the CISO can put this information in the
context of the overall health of the security of the company.

Solution Dashboards
The RSA Archer Security Operations Management solution has six dashboards that
provide detailed summary information for each of the solution's primary users:
l SOC Manager
l Incident Coordinator
l L1 Incident Handler

25 Chapter 1: Security Operations Management

Practitioner Guide

l L2 Incident Handler
l Compliance/Privacy Officer (Breach Response Lead)
l IT Helpdesk Analyst

Each dashboard serves as the primary point of entry to the solution for that user, and
the majority of all tasks that each user needs to perform begin from their dashboard.
When each user logs on, they see their particular dashboard in the center of the
screen, the solution applications on the left, and the Security Operations
Management and Enterprise Management workspace tabs at the top.

Note: All of the screenshots in this guide show a UI configured with the SecOps
theme. For instructions on creating this theme and using it in your own environment,
see Appendix B: Configure the SecOps Theme.

L1/L2 Incident Handler Dashboards

The L1 Incident and L2 Incident Handler dashboards display information about
security incidents and (for L2 Handlers) incident investigations.The charts and
tables in each dashboard allow that user to see the items they are currently
assigned, items in the queue that they can begin working on, open tasks, and other
metrics.
Only users assigned to the L1 Incident Handler role can view the L1 Incident
Handler dashboard and only users assigned to the L2 Incident Handler role can
view the L2 Incident Handler dashboard.

Chapter 1: Security Operations Management 26

Practitioner Guide

Incident Coordinator Dashboard

The Incident Coordinator dashboard provides summary information about all open
incidents and investigations, shows the current workload for each Incident Handler,
shows all unassigned incidents that the Incident Coordinator needs to assign, and
displays recent shift handover reports for the incident coordinator to review at the
beginning of a shift.
Only users assigned to the Incident Coordinator role can view the Incident
Coordinator dashboard.

27 Chapter 1: Security Operations Management

Practitioner Guide

SOC Manager Dashboard

The SOC Manager dashboard provides summary information about all active
incidents and data breaches, displays maps of recent security alerts by external
destination and facility, shows metrics about the threat categories and business
impacts of incidents, and displays the most effective security controls in the SOC.
Only users assigned to the SOC Manager role can view the SOC Manager
dashboard.

Chapter 1: Security Operations Management 28

Practitioner Guide

Breach Response Dashboard

The Breach Response dashboard provides a high-level view of your entire breach
response program. You can view all active data breaches, any open tasks that need
to be completed as part of a breach response, which regulations have been most
impacted by data breaches, and what type of data has been disclosed.
Only users assigned to the Compliance/Privacy Officer, SOC Manager, or
CISO/CSO roles can view the Breach Response Dashboard.

IT Helpdesk Dashboard
The IT Helpdesk dashboard provides a summary view of all tickets (findings) that
need to be remediated for either an incident or a breach. You can view all open
tickets, all tickets that match a particular remediation type or action, and the most
critical open tickets.
Only users assigned to the IT Helpdesk role can view the IT Helpdesk dashboard.

29 Chapter 1: Security Operations Management

Practitioner Guide

Solution Implementation
There are many items to consider when implementing the RSA Archer Security
Operations Management solution. The chapters of this Practitioner Guide outline
the details of the different phases, but the following sections highlight some
important initial considerations.

Managing SOC Readiness

This phase is the responsibility of the SOC Manager, who outlines the different
steps necessary to lay out the approach for the overall SOC team. Most often,
existing SOC teams will have assigned roles that may or may not align with the
personas in the solution. When planning for the implementation, it is important to
map the roles/personas described in this document to your own team members. If
there are gaps, or roles that are not accounted for, then the team should determine
how current personnel are mapped to the roles in the solution. The solution also
includes the ability to catalog the skills of the team so the SOC Manager can
understand skill gaps and plan accordingly.

Chapter 1: Security Operations Management 30

Practitioner Guide

The SOC Manager should document the different security controls within the
infrastructure. Security controls could be both technology (such as tools, platforms,
and systems) as well as manual controls (such as a manual log review process).
The inventory of security controls enables the SOC manager to track the
effectiveness of the controls as they pertain to security incidents. The SOC
Manager should itemize security controls in the early phases – to set a baseline set
of controls – but also maintain this catalog over time as new technologies or
processes are implemented based on lessons learned from monitoring control
efficacy.
Policies and procedures for incident management will solidify the overall SOC team
strategy. Policies and procedures are important pieces of maintaining a methodical
approach to triaging and responding to security events. The solution allows the SOC
team to document specific procedures for different types of security incidents.
These procedures will enable the team to maintain a common set of steps based on
the profile of incidents and assist not only in the immediate response but also build a
common knowledgebase for information sharing between security team members.
This should be an active part of the overall SOC program management.
Call trees are necessary to itemize personnel relevant to different types of security
incidents. Building a call tree upfront (or as different types of incidents and events
are investigated and resolved) streamlines the communications necessary to handle
security events.

Responding to Incidents
The next phase of the implementation will focus on building the workflow and
mechanics of identifying a possible security event and escalating through the
different layers of the SOC team for investigation and resolution.
Some actions to consider for this phase:
l If the RSA Archer Security Operations Management solution is integrated with
RSA Security Analytics, this phase will include ensuring the integrations are
working properly. Planning should be instituted to run through various testing
cycles to ensure the data is properly flowing and the team understands how
security alerts are correlated into security incidents.
l The team should be trained extensively on the mechanics of the process
including how to create an incident, assign an incident and move an incident
through the workflow. This will require some training sessions that should be
part of the initial implementation. Ongoing training (for new team members)
should be considered as standard processes as the SOC team progresses.

31 Chapter 1: Security Operations Management

Practitioner Guide

Responding to Data Breaches

Data breaches are security incidents that result in some type of data disclosure or
compromise. Most data breaches will have some regulatory impact. For example, a
compromise of personally identifiable information (PII) such as credit card data
may require certain regulatory reporting processes to be initiated. Data breaches do
not have to be regulatory related. A data breach could be designated based on
internal types of information – for example, very sensitive intellectual property
being accessed by an unauthorized person.
Some actions to consider for this phase:
l The workflow for data breaches will engage other parts of the organization – for
example, designees from Public Relations, Compliance, Legal, or Privacy
functions. These individuals may not be daily users of RSA Archer and most
likely will not have deep security backgrounds. Therefore, the individuals that
are designated to be participants in this workflow should be briefed and a
periodic review of the process should be instituted.
l Since data breach response may require input and actions from parties outside
the SOC team, a periodic review of contact information and roles should be
instituted.
l Data breaches can happen very quickly and are usually unique to the
circumstances. Once the data breach extended team is designated and organized,
it is recommended to have periodic testing or reviews of the process. Table top
exercises such as what if scenarios are a good way to ensure the team
understands the process of managing a data breach, comprehends the different
roles, and the process is fine-tuned as much as possible. Many organizations
unfortunately learn about data breach management during a breach and are
unprepared for the different scenarios. This type of testing can also be
coordinated with other business continuity, disaster recovery, or crisis
management programs.

Remediating Issues
Many times a security event will require non-security team involvement. For
example, a virus infection on an end-user device could spawn a security alert. The
remediation of that alert could be the re-imaging of the infected device by the IT
desktop management function. Just like data breach management, these users may
not be daily RSA Archer users and may require special training.
Some actions to consider for this phase:
l Personnel that are designated or planned to be part of the remediation cycle
should be briefed and trained on the process. This will require both an initial
rollout training program and an ongoing periodic training offering to ensure new
resources are trained.

Chapter 1: Security Operations Management 32

Practitioner Guide

l The concept of “champions” or extended team members may be necessary to

help train and provide point-of-contact with the various remediation areas. For
example, a Point of Contact may be designated in the Server, Desktop,
Application and Network areas (or however the IT organization is structured) to
assist in these processes.
l Reporting to those Points of Contacts or the management level of the different
operational units on key metrics, such as time to close, time to respond, etc.
should be reviewed with the management team members to ensure proper
reporting is in place to the various operational teams.

33 Chapter 1: Security Operations Management

Practitioner Guide

Chapter 2: Managing SOC Readiness

Managing SOC Staff and Contacts

As the SOC Manager, you can use RSA Archer Security Operations Management
as a central repository for any information you require about SOC staff members
and cross-functional team members. You can document your teams of incident
handlers, capture each team member's education and training history in order to
help assign the right handlers to incidents, and store contact information for anyone
who needs to be notified about a breach.

Document Solution Users

User: SOC Manager, Incident Coordinator
For each user who needs to access the RSA Archer Security Operations
Management solution, you need to create both a record in the Contacts application,
(to capture basic contact info, job title, team membership, and educational
background) and an Archer user account (to use to log on and to assign access
rights and group membership).

Procedure
1. Create a contacts record for the user:
a. In the Security Operations Management solution, in the Navigation menu,
click Contacts > Add New.
b. Complete the required fields in the General Information section, and fill out
any other information as needed.

Note: If you are creating a Contacts record for someone other than yourself
and want that user to have the ability to edit or update the record, assign
them as a Record Owner.

c. Save the contacts record..

2. Create a user account for the user:

Note: You may require your Solution Admin to create the Archer user
accounts, depending on what administrative access you have been granted.

b. Click Administration > Access Control > Manage Users > Add New.
c. Fill out the General Information and Contact Information sections.
d. Click the Groups tab, and click Lookup.
e. Expand the Groups list, and select the group to which the user belongs.

Chapter 2: Managing SOC Readiness 34

Practitioner Guide

When you assign a user to a group, the user also inherits the access roles
associated with the group. Each SOC user group is associated with the
related SOC access role.
f. Save the user account.

Document SOC Staff Skill Sets

User: Any SOC Staff Member
Documenting the skills, education, and training history of each incident handler
allows the Incident Coordinator to assign security incidents to handlers with the
appropriate skills and background.

Procedure
1. In the Contacts application, open the user record.
2. Click the Education tab.
3. In the Skills and Capabilities field, select the user's skills.
4. In the Degrees and Certifications section, click Add New.
5. Fill out and save the record. If you also want to document training courses that
support the degree or certification, click Add New in the Training Courses
section, and fill out the record.
6. Repeat steps a-b for each degree or certification the team member holds.
7. (Optional) Document other training courses.
a. In the Training Courses section. click add Add New
b. Fill out and save the record.
c. Repeat steps a through b for all the user's training courses.

Document SOC Teams and Team Members

User: SOC Manager or Incident Coordinator

Procedure
1. Create a team record:
a. From the Navigation menu, click Teams > Add New.
b. Enter a team name and description, and select the team manager.
c. Click Apply to save the Teams record.
2. Add team members to the team:
a. In the Members section, click Add New.
b. Select the name of the team member and their role.

35 Chapter 2: Managing SOC Readiness

Practitioner Guide

Note: The Member Name field is a cross-reference to the Contacts

application. After you save the member record, the user's team membership
information is also displayed in their contact record.

c. Click Save.
d. Repeat steps a through c for each member of the team.
3. Save the team record.

Managing SOC Policies and Procedures

As the SOC Manager, you can use RSA Archer Security Operations Management
to track all the security policies you are required to follow, all the security controls
that you have invested money in, and how effective those controls are at detecting,
preventing, and investigating incidents. You can also use RSA Archer Security
Operations Management to document standard processes and procedures for team
members to follow when handling an incident or a breach.

SOC Policies
SOC policies define the processes, terms, and standards that your SOC team is
bound to follow. For example, your SOC might be required to respond to an incident
within a set amount of time depending on the incident's priority level. RSA Archer
Security Operations Management allows you to document all of your SOC policies
and to manage the process of reviewing and approving them with all required
stakeholders.
Establishing SOC policies around the following list of subjects up front will also
help you manage subsequent SOC processes for handling incidents and responding
to breaches in the RSA Archer Security Operations Management solution.

Policy What it should define

Incident Priority What does each priority level mean to your organization?
Classification How should they be assigned to incidents?

Incident Handling SLA How quickly must incidents be looked at, investigated,
Requirements resolved? How does this vary based on incident priority?

Declared Incidents What does a declared incident means to your organization?

When an incident should be declared?

Confidential Incidents What incidents should be marked confidential? Who should

have access to confidential incidents?

Chapter 2: Managing SOC Readiness 36

Practitioner Guide

Policy What it should define

IT Operations How quickly must a ticket be resolved? How does this vary
Remediation SLA based on criticality?
Requirements

Breach Handling Who should be responsible for managing the entire breach
response process?

SOC Policy Review Process

The following figure shows the process of creating and reviewing a SOC policy.

When you create and save a new SOC policy record, notifications are sent to each
assigned stakeholder to tell them that a new policy requires their review. Each
stakeholder must review the policy and either approve or reject the policy.
When all stakeholders have reviewed and approved the policy, the status becomes
Approved. If all stakeholders have not yet reviewed the policy or some have
rejected it, the status remains as Under Review.

Document SOC Policies

User: SOC Manager or Incident Coordinator

Procedure
1. In the Security Operations Management solution, in the Navigation menu, click
Security Policies > Add New.
2. Enter a policy name, description, owner, and stakeholders.

Note: The Stakeholder 1 role is automatically populated with the SOC

Manager.

37 Chapter 2: Managing SOC Readiness

Practitioner Guide

3. Click Save.
4. Repeat steps 1-3 for each security policy that you want to document in RSA
Archer Security Operations Management.

SOC Procedure Library

Response procedures define the tasks that incident handlers should complete or the
guidelines or checklists they should follow when responding to an incident or
breach. RSA Archer Security Operations Management allows you to maintain a
library of all of your standard response procedures.
By defining response procedures, you can provide incident handlers with guidance
and consistent processes for reviewing incidents and handling breaches. When an
incident handler categorizes an incident, any response procedures that match that
category are automatically copied into the Incident Response Tasks application and
linked to the incident record. When a breach response team member selects
impacted regulations, any response procedures that match those regulations are
automatically copied into the Breach Tasks application and linked to the breach
record.

Document SOC Procedures

User: SOC Manager, Incident Coordinator, or L2 Incident Handler

Procedure
1. In the Security Operations Management solution, in the Navigation menu, click
SOC Procedure Library > Add New.
2. Enter a name and description for the procedure.
3. Select the type of procedure: Incident or Breach.
4. Select the priority level of the incident or breach to which this response
procedure should apply.
5. Select whether the procedure is required or optional.
6. Assign a default user group who should implement the procedure.
7. For an incident procedure, select the category of incident to which this
procedure should apply.
8. For a breach procedure, select any applicable regulations to which this
procedure should apply.
9. Save the record.

Chapter 2: Managing SOC Readiness 38

Practitioner Guide

Call Trees
A call tree is a list of persons, roles, and/or organizations that you may need to
notify in a particular sequence in the event of a breach. You may have call trees for
internal contacts, such as a list of senior management who need to stay informed
about the response to a breach, or external contacts, such as a list of government
bodies that you are required to notify in the case of a breach.

Set Up Call Trees

User: SOC Manager, Incident Coordinator, L1 or L2 Incident Handler

Procedure
1. In the Security Operations Management solution, in the Navigation menu, click
Call Trees > Add New.
2. Complete the General Information Section.
3. In the Call Initiator section, select the user who is responsible for contacting
others in the event of a breach.
4. In the Call Recipients section, add or lookup the user or users who need to be
contacted.
5. In the Message section, enter the message that the Call Initator is required to
deliver.
6. Click Save.

Security Controls
Security controls are all of the tools or technologies that your SOC uses to detect,
prevent, and investigate security incidents. RSA Archer Security
Operations Management allows you to document all of your security controls,
including each control owner, deployment status, control category, and fixed and
annual operational costs.

Document Security Controls

User: SOC Manager or Incident Coordinator

Procedure
1. In the Security Operations Management solution, in the Navigation menu, click
Security Controls > Add New.

39 Chapter 2: Managing SOC Readiness

Practitioner Guide

2. Complete the General Information section.

3. In the Site Location section, add a cross-reference to the facility to which the
control applies.
4. Click Save.

View Security Control Efficacy

User: SOC Manager
As incident handlers resolve incidents and note which security controls they found
effective and ineffective, you can get a picture of your overall security control
efficacy.

Procedure
l To view your overall security controls efficacy:
o In the Security Operations Management workspace, select the SOC Manager
dashboard.
o In the Navigation menu, click Security Controls > Reports > Security Controls
Efficacy.
The Security Tools Efficacy report shows a summary of the top 10 most
effective security controls.

l To view the efficacy of a particular security control, open the security control
record.

Chapter 2: Managing SOC Readiness 40

Practitioner Guide

The Control Efficacy section shows the overall efficacy of the control and its
efficacy over the last 3 years. The Effective Controls section displays the
incidents that the control was effective in detecting, in preventing, or at
investigating an incident. The Ineffective Controls section displays the incidents
in which the control was not effective.
l To view the efficacy of security tools for a particular incident or investigation:
1. Open the incident or investigation record.
2. Click the Results tab.
3. In the Controls Efficacy section, view the detective, preventive, and
investigative controls that the incident handlers deemed effective and
ineffective.

41 Chapter 2: Managing SOC Readiness

Practitioner Guide

Chapter 3: Responding to Incidents

Incident Response Workflow

The RSA Archer Security Operations Management solution is built to enable the
following incident response workflows.

Chapter 3: Responding to Incidents 42

Practitioner Guide

Note: Only notifications that are a key part of the workflows are included in the
diagrams. For a complete list of notifications, see the Data Dictionary.

43 Chapter 3: Responding to Incidents

Practitioner Guide

Alerts vs Incidents
Security Alert Security Incident

A correlated event with a negative A distinct group of security alerts

consequence, such as system crashes, packet involving specific attackers, attacks,
floods, unauthorized use of system objectives, sites, and timing that results
privileges, unauthorized access to sensitive in a violation or imminent threat of
data, and execution of malware that destroys violation of computer security policies,
data, or a combination of one or more of acceptable use policies, or standard
these events. security practices.

RSA Archer Security Operations Management can collect alerts from RSA
Security Analytics and can aggregate alerts into incidents or allows you to create an
incident manually.
One security incident can be made up of multiple security alerts, however a
security alert can only be tied to one security incident. All alerts must be tied to an
incident.

Aggregating Multiple Alerts into a Single Incident

When you build a rule in RSA Security Analytics to define the meta data on which
you want to alert, an alert is triggered each time the conditions of the rule are met.
These messages could potentially flood your RSA Archer system with a series of
nearly identical incidents.
To avoid this situation, you can define the criteria to use to aggregate similar alerts
into a single RSA Archer incident. For example, you might create a rule in RSA
Security Analytics to identify any sessions between a critical asset and a
blacklisted IP address. RSA Archer Security Operations Management provides
templates for common aggregation criteria, but you can also configure aggregation
based on any meta data value available in RSA Security Analytics. For instructions,
see the RSA Archer Security Operations Management Installation & Configuration
Guide. The following examples demonstrate how the aggregation behavior works.
Aggregation Example 1
You configure the rule to aggregate based on Source IP and Destination IP.
On your RSA Security Analytics system, the alert is triggered multiple times:
l 10:45 – Criticality Alert fires for SRC=10.10.10.1, DST=10.10.10.2
l 10:48 – Criticality Alert fires for SRC=10.10.10.1, DST=10.10.10.2
l 10:50 – Criticality Alert fires for SRC=10.10.10.1, DST=10.10.10.2

The following happens in your RSA Archer system:

1. When the 10:45 alert is triggered, a single incident (Incident A) is created in the
RSA Archer Platform. The incident has a counter that indicates that the alert

Chapter 3: Responding to Incidents 44

Practitioner Guide

has occurred once. The incident also shows the time (10:45) that the incident
was first created.
2. After the 10:48 alert, Incident A increments its counter to say that the alert has
occurred two times and updates the time at which the incident was last updated.
A separate incident based upon the 10:48 alert is not created. The incident still
notes the time (10:45) at which the incident was first created.
3. After the 10:50 alert, Incident A again increments its counter to say that the
alert has occurred three times and updates the time at which the incident was
last updated. A separate incident based upon the 10:50 alert is not created. The
incident still notes the time (10:45) that the incident was first created.
For as long as Incident A remains in the New status, future alerts triggered based
upon the same rule, Source IP, and Destination IP continue to cause Incident A to
increment its counter. No new incidents are created. Once Incident A is assigned,
however, any future alerts triggered based on the same rule cause Incident B to be
created.
Aggregation Example 2
You configure the rule to aggregate based on Source IP only.
On your RSA Security Analytics system, the alert is triggered multiple times:
l 10:45 – Criticality Alert fires for SRC=10.10.10.1, DST=10.10.10.2
l 10:48 – Criticality Alert fires for SRC=10.10.10.1, DST=10.10.10.4
l 10:50 – Criticality Alert fires for SRC=10.10.10.3, DST=10.10.10.2

The following happens on your RSA Archer system:

1. When the 10:45 alert is triggered, a single Incident (Incident A) is created in
Archer. The incident has a counter that indicates that the alert has occurred
once. The incident also shows the time (10:45) that the incident was first
created.
2. After the 10:48 alert, Incident A increments its counter to say that the alert has
occurred two times and updates the time at which the incident was last updated.
A separate incident based upon the 10:48 alert is not created. The incident still
notes the time (10:45) that the incident was first created.
3. After the 10:50 alert, a new incident (Incident B) is created in Archer. Incident
B has a counter indicating that the alert has occurred once. The incident notes
the time (10:50) at which the incident was first created.

Incident Status
The status of the incident record reflects where in the overall workflow you
currently are.

45 Chapter 3: Responding to Incidents

Practitioner Guide

Incident
What it Means
Status

New Default status when a record is created.

Assigned Incident has been assigned to an L1 Incident Handler, but the Handler
has not yet started working on the incident.

In Progress The L1 Incident Handler has started working on the incident.

Escalated The L1 Incident Handler has escalated the incident to an L2 Incident

Handler.

Returned to The L2 Incident Handler has reviewed the incident found that the escal-
Level 1 ation is not valid. For example, the L1 Incident Handler may have
missed checks before they escalated the incident.

Remediation The L2 Incident Handler has completed their analysis and found items
Requested that require remediation.

Remediation The required remediation has been completed.

Completed

Resolved All tasks have been resolved and the incident is not tied to any open
investigations or breaches.

Invalid After review, the information in the incident does not reflect a security
compromise or malicious activity.

Declared Incidents
Your organization may have hundreds of incidents to investigate, but not every
incident necessarily reflects an attack or breach. For example, an incident handler
may investigate and discover than an incident was a false positive. RSA Archer
Security Operations Management allows you to flag an incident as a Declared
Incident for those incidents which you want to provide management visibility into or
those that are confirmed issues that require remediation.
When a handler flags an incident as Declared, the SOC Manager and Incident
Coordinator groups are notified and the incident appears in the Declared Incidents
report on the SOC Manager and Incident Coordinator dashboards.
RSA recommends that you establish a SOC policy about what a declared incident
means to your organization and which incidents should be declared.

Chapter 3: Responding to Incidents 46

Practitioner Guide

Confidential Incidents
Some incidents may be highly sensitive and require that you restrict who has access
to the record. For example, an investigation might be occurring about a SOC staff
member, in which case you do not want them to have access to the incident record.
When you flag an incident as Confidential, only members of the SOC Manager and
Incident Coordinators groups are granted access.
RSA recommends that you establish a SOC policy about what a confidential
incident means to your organization, which incidents should be marked confidential,
and who should maintain access to these records.

Creating an Incident
In RSA Archer Security Operations Management, there are three ways that
incidents can be created:
l Automatically, using the RCF to aggregate Security Analytics alerts into
incidents
l Manually, in the RSA Archer Security Incidents application.
l Manually, from Security Analytics (if your Solution Administrator configured the
custom context menu option).

Create an Incident Manually in the Security Incidents Application

User: SOC Manager, Incident Coordinator, L1/L2 Incident Handler

Procedure
1. In the Security Operation Management solution, in the Navigation menu, click
Security Incidents > Add New.
2. In the Overview tab, enter a title, summary, and any other initial information
that you have.
3. Save the record.
If you assign an incident owner, the incident will appear in that user's queue. If
you do not assign an owner, the incident will appear in the L1 Incident Handler
queue for any member of the team to begin work on the incident.

Create an Incident Manually from Security Analytics

Procedure
Right-click any meta data value and select External Lookup > Create Archer
Incident.

47 Chapter 3: Responding to Incidents

Practitioner Guide

If an Archer session is already open in your browser, a blank Add New Record
page opens in the Security Incidents application and you can fill out the details. If
an Archer session is not currently open in your browser, you must log on, and then
the blank Add New Record page opens. Only the Date/Time Reported, Status, and
Priority fields are populated by default; you must enter all other values as
necessary.

Assigning Incidents
Once an incident is assigned, no additional alerts can be tied to the incident by the
RSA Connector Framework. You can manually associate new alerts to an assigned
incident.

Assign Yourself an Incident from the Queue

User: L1 or L2 Incident Handler

Procedure
1. From the Security Operations Management workspace, and select the L1 or L2
Incident Handler dashboard.
2. From the L1 or L2 Incident Queue iView, click the ID of the incident that you
want to work on.

3. In the incident record, in the Incident Owner field, select yourself.

4. Save the incident record.

Assign an Incident to a Handler

User: Incident Coordinator

Chapter 3: Responding to Incidents 48

Practitioner Guide

Procedure
1. From the Security Operations Management workspace, and select the Incident
Coordinator dashboard.
2. (Optional) Review the Analyst Workload iView. These reports show you the
total number of incidents assigned to each L1 and L2 Incident Handler.

3. From the Unassigned Incidents Queue iView, click the ID of the incident that
you want to assign.

4. Review the incident record, then in the Incident Owner field, select the incident
handler who you want to assign to the incident.
5. Save the incident record.

Review an Incident
User: L1 Incident Handler

49 Chapter 3: Responding to Incidents

Practitioner Guide

Procedure
1. Review all the existing information:
l The Incident Summary section provides basic information, such as the title,
summary, basic details, and the source of the incident.

l The Incident Status section provides the current status, date created, incident
owner, and the priority of the incident.

The Priority field is initially populated with the highest priority level of all the
associated alerts, as follows:

Security Analytics severity level Security Alert priority

1-2 P3

3-5 P2

6-8 P1

9-10 P0

l The Alerts tab shows all of the individual alerts that comprise the incident.

You can click the Security Analytics Link to launch the Investigation UI in-
context of the given alert for additional investigation.

Chapter 3: Responding to Incidents 50

Practitioner Guide

Note: If your Solution Admin has configured the Enterprise Management

plug-in, the Security Analytics UI also displays criticality information and
other business context about your Archer assets.

You can drill down into each alert to view more details in the alert record.
l The Alert Summary tab displays alert metadata, such as the source of the
alert, its category and severity, as well as the raw alert message.
l The Alert Data tab display information parsed from the raw alert, such as
source and destination IP addresses, user data, and location information.

If a device is internal, business context from the Enterprise Management

solution is automatically displayed.

You can also use the pre-generated links to look up WHOIS and
Geolocation information.

2. Classify the incident. In the Initial Threat Classification section, do the

following:
l Select a threat category.
l Select whether the threat actor is internal or external.
l Select the threat vector

51 Chapter 3: Responding to Incidents

Practitioner Guide

l Select the asset type that was targeted

l Select whether the threat is valid.
3. In the Incident Reporting section, select whether the incident is confidential or
declared (if yet known; the L2 analyst may determine this during their analysis).
4. Save the incident record.

Using Investigations
An investigation record allows you to tie together multiple related incidents for
faster handing and resolution. You can also create an investigation in order to look
into suspicious activity, threat intelligence, or other information reported outside of
RSA Archer Security Operations Management. For example, a Cyber Threat Intel
Analyst might create an investigation and assign it to a L1 or L2 Incident Handler in
order to have the handler find and document any traffic associated with specific
new threat intelligence.

Create an Investigation
User: L1 or L2 Incident Handler, Cyber Threat Intel Analyst

Procedure
1. Do either of the following:
l In the Security Operation Management solution, in the Navigation menu,
click Incident Investigations > Add New.
l From an existing incident or investigation record, click the Overview tab, and
in the Related Mappings section, click Add New.
2. In the Overview tab, enter a title, summary, and any other initial information
that you have.
3. In the Related Mappings section, click Lookup, and add any related incidents or
investigations.
4. Save the record.

Close an Investigation
User: L1 or L2 Incident Handler

Procedure
1. Open the investigation record, and in the Related Mappings section, verify that
that all related security incidents have been closed.
2. Change the investigation status to Closed.
3. Save the investigation record.

Chapter 3: Responding to Incidents 52

Practitioner Guide

Complete Incident Response Tasks

User: Incident Owner (L1 or L2 Incident Handler)

Note: You can also complete response tasks for an Incident Investigation record.

Procedure
1. In the Security Incident record, click the Incident Response Tasks tab. You can
see which tasks are required and which are optional, and you can see which
tasks that have not been completed (status = Not Implemented).

2. Open the task you want to complete.

3. Complete the task, then in the Analyst Details section, select yourself as the
analyst, enter any notes about the task, and change the status to Implemented.

4. Save the record.

5. Repeat steps 2-4 for any other incident response tasks.
6. Save the record.

Add Shift Notes to an Incident

User: L1 or L2 Incident Handler
An incident may take more than your shift to resolve, in which case you should
leave shift notes to inform the next handler about the current status.

Note: You can also add shift notes to an Incident Investigation record.

Procedure
1. In the Security Incident record, click the Incident Journal tab.
2. Click Add New.
3. In the Journal Entry field, enter any information that you want to provide the
next incident handler.

53 Chapter 3: Responding to Incidents

Practitioner Guide

4. In the IR Milestone field, select either a stage in the attack process or a stage in
the incident response process, depending on what notes you are adding.

5. Save the Incident Journal record.

Escalate an Incident
User: L1 Incident Handler

Procedure
1. Open the incident record.
2. Change the Incident Status to Escalated.
3. Save the incident record.
The incident is automatically moved to the L2 Incident Handlers queue, so that
an L2 incident handler can begin work on it.

Review an Escalated Incident

User: L2 Incident Handler

Procedure
1. From the Security Operations Management workspace, and select the L2
Incident Handler dashboard.
2. From the Level 2 Incident Queue iView, open an incident to review.
3. Change the Escalation Status to Assigned, and select yourself as the Escalation
Owner.
4. Review the incident details and work done to date and determine whether the
escalation is valid.

Chapter 3: Responding to Incidents 54

Practitioner Guide

5. Do one of the following:

l If the escalation is not valid, change the Escalation Status to Returned. You
can also use the Incident Journal tab to note anything that the L1 Handler
missed. Save the record.
The incident status changes to Returned to Level 1 and the queue changes to
L1.
l If the escalation is valid, perform forensic analysis and document your
results.

Perform and Document Forensic Analysis

User: L2 Incident Handler

Procedure
1. In the Security Incident record, change the Escalation Status to Forensic
Analysis In Progress.
2. Click the Forensic Analysis tab.
3. Document host forensic analysis:
a. In the Host Forensic Analysis section, click Add New.
b. Document information about the host that was targeted. Save the Target
Host record.

55 Chapter 3: Responding to Incidents

Practitioner Guide

c. Import and attach any external forensic analysis reports.

d. Document any suspicious parameters. In the Forensic Analysis Artifacts

section, when you select each suspicious parameter that you want to
document, a corresponding tab appears below. From each tab you can add
and fill out a new sub-form to capture the details of the suspicious
parameter.
e. Save and close the forensic analysis record.
4. Document network forensic analysis:
a. In the Network Forensic Analysis section, click Add New.
b. Fill out the General Information section.
c. Click the Network Forensic Analysis tab.
d. Fill out the Summary section.
e. In the Suspicious Traffic section, add and fill out a new sub-form to capture
any details about suspicious network traffic.
f. Save and close the forensic analysis record.
5. Click the Overview tab, and change the escalation status to Forensic Analysis
Completed.
6. Save the incident record.
When you save the record, the overall Incident Status changes to Remediation
Requested.

Document Impact Analysis

User: Incident Owner (L1 or L2 Incident Handler)

Chapter 3: Responding to Incidents 56

Practitioner Guide

Once you have confirmed a security compromise, you must document the impact of
the incident. You can document the business, corporate policy, confidentiality,
integrity, and availability impact of the incident.

Note: You can also document impact analysis for an Incident Investigation record.

Procedure
1. In the Security Incident record, click the Impact Analysis tab.
2. Document the business impact of the incident. If you have licensed the RSA
Archer Risk Management solution, you can tie the incident to an existing risk
register record.
3. Document the confidentiality impact. If you find that data has been disclosed,
create a data breach record for the breach response team to track and resolve.
For more information, see Create a Breach Record.
4. Document the integrity impact.
5. Document the availability impact. If you have licensed the RSA Archer
Business Continuity Management solution, you can create a crisis event record
for your crisis event team to track and resolve.
6. Document the corporate policy impact.
7. Save the incident record.

Log Issues for Remediation

User: Incident Owner (L1 or L2 Incident Handler)

Note: You can also log issues for remediation from an Incident Investigation
record.

Procedure
1. In the Security Incident record, click the Remediation tab.
2. In the Remediation Required field, select Yes.
3. In the Specify Remediation Action field, select the types of remediation action
required.
For each action type you select, a new section appears in the Remediation tab.
4. In each section, click Add New.
5. In the Findings record, enter the following:
a. Enter a name and description of the action that needs to be completed.
b. Select a criticality for the finding.
c. In the Source Override field, select Security Operations.

57 Chapter 3: Responding to Incidents

Practitioner Guide

d. In the Security Operations Response section, select a remediation type,

requested action, an a target queue.
6. Save and close the Findings record.
7. Repeat steps 4-5 for each issue that needs remediation.
8. Save the incident record.

Document Overall Incident Analysis Results

User: Incident Owner (L1 or L2 Incident Handler)

Note: You can also document the overall results for an Incident Investigation
record.

Procedure
1. In the Security Incident record, click the Results tab.
2. Capture the results of the incident. Confirm the incident and your confidence
rating, and the attack category and method of discovery.
3. Capture the actors, tactics, and techniques that contributed to the incident.
4. Capture details about the target of the incident.
5. Look up and add the security controls that were effective in discovering the
incident and those that were not effective.
6. Save the incident record.

Close an Incident
User: Incident Owner (L1 or L2 Incident Handler)
An incident cannot be closed if it has:
l An open investigation or breach tied to it
l Open tasks that are marked as Required, if the incident has a priority of P0 or
P1. You can close P2 or P3 incidents even if they have required tasks that remain
open.
l Open findings

Procedure
1. Open the incident record.
2. Change the Incident Status to Resolved.
3. Save the incident record.

Chapter 3: Responding to Incidents 58

Practitioner Guide

Shift Handovers
If your SOC is manned 24x7 or has teams in multiple locations, the Incident
Coordinator of each shift should create a daily shift handover report for the Incident
Coordinator of the next shift. The shift handover report provides a summary of
incidents closed, incidents that still require follow-up, and any other information
that the next Incident Coordinator needs to take over incident handling coverage.

Shift Handover Workflow

The following diagram shows the process for creating and reviewing shift handover
reports.

Create a Shift Handover Report

User: Incident Coordinator

Procedure
1. In the Security Operation Management solution, in the Navigation menu, click
Shift Handover > Add New.
2. In the Shift Overview tab, fill out the shift location, coordinator, start and end
times, and a summary of the shift.
3. In the Items Closed tab, add cross-references to any incidents or investigations
that were closed during the shift.
4. In the Items for Follow Up tab, add cross-references to any incidents or
investigations that remain open and should be picked up by the next shift.
5. In the Analyst Blogs tab, add any summary information about the shift, such as

59 Chapter 3: Responding to Incidents

Practitioner Guide

overall trends or information not specific to a particular incident.

6. Save the record.

Review a Shift Handover Report

User: Incident Coordinator

Procedure
1. From the Security Operations Management workspace, and select the Incident
Coordinator dashboard.
2. In the Daily Shift Handover iView, open the shift handover report that you want
to review.

Chapter 3: Responding to Incidents 60

Practitioner Guide

Chapter 4: Responding to Data Breaches

Data Breach Response Workflow Overview

The RSA Archer Security Operations Management solution is built to enable the
following incident response workflow.

61 Chapter 4: Responding to Data Breaches

Practitioner Guide

Note: Only notifications that are a key part of the workflow are included in the
diagram. For a complete list of notifications, see the Data Dictionary.

Breach Response Lead

When an Incident Handler creates a breach record, they should assign a Breach
Response Lead. The Breach Response Lead is the person who will be responsible
for coordinating and managing the entire breach response process. Depending on
the organization, the Breach Response Lead may be a Privacy/Compliance Officer,
the CISO/CSO, a Legal Officer, or another user.
RSA recommends that you document your SOC policies about breach response, but
especially who should be designated as the Breach Response Lead, so that the
breach record creator knows who to assign in the event of a breach.

Breach Record Team

When a breach record is created. the Breach Response Lead should assign other
members to the Breach Response Team, the cross-functional group whose impact
analysis is required and who may help respond to the breach.
By default, only the SOC Manager, Incident Coordinator, CISO/CSO, the Incident
Handler who identified the breach, and the assigned Breach Response Lead have
access to the breach record. Any users who are assigned to the Breach Response
Team (the Business Manager, Legal Analyst, Customer Support, Public Relations,
Compliance/Privacy Officer, IT Manager, and Other Members fields) are also then
granted access to the record.

Create a Breach Record

User: L1 or L2 Incident Handler, Incident Coordinator, SOC Manager

Procedure
1. Create a new record from any of the following locations:
l In an incident or investigation record, click the Impact Analysis tab, and in
the Confidentiality Impact Assessment section, click Add New.
l In the Navigation Menu, click Data Breach Response > Data Breaches >
Add New.
2. In the breach record, document the following:
l In the Overview tab:
o A name and description of the breach
o The breach type

Chapter 4: Responding to Data Breaches 62

Practitioner Guide

o When the breach occurred

o How and when the breach was discovered
o Who reported the breach
o The members of the breach response team, including the breach response
lead
l In the Data Disclosure tab, the assets involved
3. Assign a Breach Response Lead.
4. Save the breach record.
When you save the record, notifications are sent to the SOC Manager, all
Incident Coordinators, and the Breach Response Lead to inform them that a new
breach record has been created.

Document Data Disclosed and Assign the Breach Response Team

When a breach record is created, the Breach Response Lead should first document
where the data was disclosed and assign members to the Breach Response Team.
User: Breach Response Lead

Procedure
1. In the data breach record, in the Data Disclosure tab, document the data
disclosed by region.
The location where the data was disclosed affects which regulations or privacy
laws may have been impacted and what response you will need to take to
remediate the breach.
2. In the Overview tab, assign users to the following roles:
l Business Manager
l Legal Analyst
l Customer Support
l Public Relations
l Compliance/Privacy Officer
l IT Manager
l Other Members
3. Save the record.

Provide Breach Impact Analysis

User: BU Manager, Compliance/Privacy Officer, Legal Counsel

63 Chapter 4: Responding to Data Breaches

Practitioner Guide

When a breach record is created and saved, notifications are automatically sent to
each member of the breach response team to inform them that they must review the
breach record and provide an impact assessment.

Procedure
1. Open the breach record, and click the Impact Analysis tab.
2. Depending on your role, enter your analysis about the impact rating, possible
fines, and your notes in the appropriate section.

3. Save the breach record.

When all the required breach impact analysis is completed, all members of the
breach response team are notified.

Complete a Breach Risk Assessment

Once all required reviewers have provided their impact assessments, you should
perform a breach risk assessment.
User: Breach Response Lead

Procedure
1. In the breach record, click the Breach Risk Assessment tab.
2. In the Breach Risk Assessment section, click Add New.
3. Complete and submit the assessment.
When you submit the completed assessment, the assigned Reviewer is notified
that the assessment is ready for review. You are then notified when the
Reviewer either approves or rejects the assessment.
Based on the assessment results, the values in the Assessment Results section
are then automatically populated.

Chapter 4: Responding to Data Breaches 64

Practitioner Guide

Decide Whether to Declare a Breach

User: Breach Response Lead
Once all the impact analysis has been gathered and the breach risk assessments
have been completed, you must decide whether to declare a breach.

Procedure
1. In the breach record, click the Breach Risk Assessment tab.
2. In the Assessment Results section, fill out the following:
l Impacted Regulations. Select any regulations that have been impacted by the
breach.
Based on the regulations you select, any response procedures in the
SOC Procedure Library that match that selected regulations will be copied
into the Breach Tasks application and will appear in the Breach Tasks tab in
the breach record.
l Declared Breach. Select Yes or No.
l Notification Decision. Select whether to send a notifications to affected
parties. If you decide to send notifications, you must execute and document
those notifications in the Notifications tab.

Creating and Assigning Breach Tasks

User: Any Breach Response Team member
Anyone who is assigned to work on a breach can create and assign tasks that must
be completed. Breach tasks can be created manually or they can be created
automatically using the Breach Tasks data feed. If your Solution Administrator set
up the data feed, when you select regulations impacted by the breach, any response
procedures in the SOC Procedure Library that match those regulations are copied
into the Breach Tasks application and are associated with the breach record.

Manually Create and Assign Breach Tasks

User: Any Breach Response Team member

Procedure
1. In the breach record, click the Breach Tasks tab.
2. In the Breach Tasks section, click Add New.
3. Assign an owner.
The Task Owner will be notified that they have a new task to complete.
4. Save the breach task record.
5. Repeat steps 2-4 for all the tasks that need to be completed to close the breach.

65 Chapter 4: Responding to Data Breaches

Practitioner Guide

Complete Breach Tasks

User: Any Breach Response Team member

Procedure
1. In the breach record, click the Breach Tasks tab.
2. Open any task that is assigned to you or which has your role assigned as the
Target Analyst.
3. Complete and save the task record.

Executing a Call Tree

A breach task may require that you notify specific individuals or groups through
email or phone. For example, if a breach needs to be made public, the Breach
Program Lead may create a task to notify key stakeholders.

Execute a Call Tree

User: Any Breach Response Team member

Procedure
1. Open the breach record, and click the Notifications tab.
2. In the Notification Details section, click Add New.
3. Fill out the Notification Record.
4. If the notification is part of a documented call tree, you can associate the call
tree record. In the Notification/Call Tree section, click Lookup and select the
call tree. You can associate the notification with more than one call tree.

Log Issues for Remediation

User: Breach Record Creator, SOC Manager, Incident Coordinator

Procedure
1. In the Data Breaches record, click the Remediation tab.
2. In the Remediation Required field, select Yes.
3. In the Findings section, click Add New.
4. In the Findings record, do the following:
a. Enter a name and description of the action that needs to be completed.
b. Select a criticality for the finding.
c. In the Source Override field, select Security Operations.

Chapter 4: Responding to Data Breaches 66

Practitioner Guide

d. In the Security Operations Response section, select a remediation type,

requested action, an a target queue.
e. Save and close the Findings record.
5. Repeat steps 4-5 for each issue that needs remediation.
6. Save the breach record.

Close a Breach Record

User: Breach Response Lead
Once all the tasks associated with a breach have been completed, you can close the
breach record.

Procedure
1. Open the data breach record, click the Breach Tasks tab, and verify that all
associated required tasks have been completed.
2. Click the Overview tab, and change the breach status to Closed.
3. Save the breach record.

67 Chapter 4: Responding to Data Breaches

Practitioner Guide

Chapter 5: Remediating Issues

Issue Remediation
The Issue Management subsolution allows the IT Helpdesk Analyst to manage the
remediation process for any tickets that are logged for remediation in the course of
investigating a security incident or responding to a data breach. Tickets are logged
as records in the Findings application, in which the analyst can document the
remediation performed and track the ticket to closure.
For tickets that require more extensive remediation, you can create a Remediation
Plan from the Finding. You can also tie multiple Findings to in a single Remediation
Plan in order to track the remediation in a single location.
For tickets that cannot be remediated, you can create an Exception Request from
the Finding to track and manage the risk of not performing the remediation.

Findings Process
The following figure shows the process of remediating a finding.

Resolve a Finding
User: IT Helpdesk Analyst

Chapter 5: Remediating Issues 68

Practitioner Guide

Procedure
1. In the IT Helpdesk dashboard, from the All Open Tickets iView, open a Finding
to begin work on.
2. In the Assigned to field, assign yourself to the Finding.
3. Complete the work required in the Finding.
4. Click the Response tab.
5. In the Response field, select either Accept Risk or Remediate Risk.
l If you select Accept Risk, create a new Exception Request.
l If you select Remediate Risk, complete the Remediation section. If the
necessary remediation is extensive, create a new Remediation Plan.
6. Once all associated Exception Requests and Remediation Plans are closed,
click the Workflow tab.
7. In the Reviewer field, assign a user to review the Finding.
You may want to assign the incident handler who created the ticket as the
reviewer, but this may depend on your organization's procedures and is not
required.
8. Change the Submission Status to Submitted.
The Review Status changes to Awaiting Review.
9. Save the record.
A notification is sent to the assigned Reviewer to inform them that the Finding
requires review.

Review a Finding
User: Finding Reviewer

Procedure
1. In the Finding record, review the work that was completed.
2. In the Review Status field, select either Rejected or Approved.
l If you select Rejected, a notification is sent to the Finding owner to continue
work on the Finding and resubmit it.
l If you select Approved, the Finding is automatically closed.
3. Save the record.

69 Chapter 5: Remediating Issues

Practitioner Guide

Exception Request Process

The following figure shows the process of creating and reviewing an Exception
Request.

Create a New Exception Request

User: Finding Owner

Procedure
1. In the Exception Request record, enter a description and business justification
for the exception.
2. Change the Submission Status to Submit for Review.
3. Save the record.
A notification sent to the Exceptions Review Group that there is a new
exception request to review.

Assign an Exception Request for Review

User: Exception Review Group

Chapter 5: Remediating Issues 70

Practitioner Guide

Procedure
1. In the Exception Request record, click the Review and Approvals tab.
2. In the Reviewer field, assign a user to review the exception request.
3. Save the record.

Review an Exception Request

User: Exception Request Reviewer

Procedure
1. In the Exception Request record, review the request and determine whether the
documentation is acceptable.
l If the documentation is not acceptable:
a. Assign a risk rating.
b. Change the Review Status to Denied.
l If the documentation is acceptable:
a. Perform risk analysis and document any risks the exception poses.
b. Change the Review Status to Approved.
c. Assign an initial expiration date.
d. Assign a risk rating.
2. Save the record.
If you assigned a risk rating of Low or Medium, the exception request is tracked
until the expiration date.
If you assigned a risk rating of High, a notification is sent to the management
reviewer to determine whether the documentation and exception risks are
acceptable.

Remediation Plans Process

The following figure shows the process of creating and reviewing a Remediation
Plan.

71 Chapter 5: Remediating Issues

Practitioner Guide

Create a New Remediation Plan

User: Finding Owner

Procedure
1. In the Remediation Plan record, enter a name and description, and select a
remediation type.
2. Assign either yourself or another user as the Remediation Plan Owner.
3. Assign a user as the Remediation Plan Manager.
4. Create and assign remediation tasks as necessary.
5. Enter an estimated cost, start date, and completion date for the remediation
work.
6. Change the Submission Status to Submitted.
7. Save the record.
A notification is sent to the Remediation Plan Manager to review the
remediation plan.

Important: Even though you have submitted the remediation plan, you must
still complete the remediation work and update the record when it is complete.

Review a Remediation Plan

User: Remediation Plan Manager

Chapter 5: Remediating Issues 72

Practitioner Guide

Procedure
1. In the Remediation Plan record, review the plan, and in the Review Status field,
select either Approved or Rejected.
2. Save the record.
If you selected Approved, the remediation plan is automatically closed. A
reminder notification is sent to the Remediation Plan Owner if the plan is not
closed within 30 days of the expected completion date.
If you selected Rejected, the Remediation Plan Owner is notified.

73 Chapter 5: Remediating Issues

Practitioner Guide

Appendix A: Configure the SecOps Theme

The screenshots in this guide show a UI configured with the SecOps theme. You
can configure this in your own environment, if desired.

Procedure
1. Click Administration > Appearance > Manage Themes.
2. Click Add New.
3. Ensure that Create a new theme from scratch is selected, and click OK.
4. On the Theme tab, select the following:

Appendix A: Configure the SecOps Theme 74

Practitioner Guide

5. On the Page Effects tab, select the following:

75 Appendix A: Configure the SecOps Theme

Practitioner Guide

6. On the Text Styles tab, select the following:

7. On the Hover Effects tab, select the following:

Appendix A: Configure the SecOps Theme 76

Practitioner Guide

8. On the Buttons tab, select the following:

9. On the Tabs tab, select the following:

10. Click Save.

11. To select the new theme in your system:
a. Click Administration > Appearance > Manage Appearance.

b. In the Theme field, click .

c. Scroll to the SecOps theme, and click OK.
d. Click Save.

77 Appendix A: Configure the SecOps Theme