Overseeing Compliance of Security Operations ◾ 209
© 2011 by Taylor & Francis Group, LLC
◾ Senior Management
◾ Security
◾ Legal
◾ Help Desk
◾ Corporate Communications
◾ Information Technology
◾ Business Unit/Operations
Senior Management representation leads the team and communicates with other
senior management and executives. Security representation addresses risk, mitiga-
tion, and general security issues with people, process, technology, and environment
as the situation requires. Legal representation may advise the team on legislative and
regulatory compliance. Help Desk may provide details on initial problem reporting
and details of the problem up until the formation of the CIRT for this particu-
lar incident. Corporate Communications deals with conveying details outside the
organization, including the media and local law ocials. Information Technology
representation brings deeper technical expertise regarding enterprise information
and information technology including network infrastructure, Internet connec-
tions, intra-enterprise networks, inter-enterprise networks, servers, data centers, etc.
Business Unit or Operations representation brings expertise on the aected business
operations. e CIRT team members will vary according to the aected area of
the enterprise.
e number one problem during an attack is eective communications. Having
the right CIRT team members and preparing each member with his or her respec-
tive accountability and responsibilities go a long way to alleviate this problem.
A similar construct to CIRT is the computer emergency response team (CERT).
Essentially, there is no dierence between CIRT and CERT other than in name,
e.g., tom-A-to versus tom-Ah-to … either one will get you a small edible red orb.
Another use of the CIRT acronym is critical incident response team. While all cyber
incidents may be critical, not all critical incidents are cyber, so name the team
according to their scope. Whatever your organization uses to denote this function,
socialize it among employees and use it consistently to avoid confusion.
e respond portion of incident management is the preparation for dening an
incident, determining an incident, dening and generally preparing for incident
response, incident reporting, incident analysis, business impact mitigation strat-
egies, and recovery options. Determine what characteristics dene an anomaly:
some threshold that says this particular activity is unusual. Such a determination
is likely to be more heuristically based than objectively based where the heuristic is
something just doesn’t look, sound, smell, or feel right. Further investigation may show
that this anomaly is a recurring activity of no consequence, or further investiga-
tion may show that indeed this anomaly is an unusual activity that warrants even
210 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
further investigation; now the anomaly is an event. If the unusual activity actually
poses some threat to the enterprise, then the event becomes an incident. An inci-
dent may be naturally occurring (e.g., recent rains are causing water tables to rise
to the point of ooding the basement that houses the voice communications equip-
ment), or the incident may be unnatural (e.g., malware has entered the network).
If the malware is determined to have entered the network by accident, the scenario
remains an incident. If the malware is determined to have entered the network by
contrivance and with specic intent, then the incident becomes an attack. Prepare
triage procedures and response plans to determine anomaly status as an event, inci-
dent, or attack. Establish priorities accordingly to allocate response resources.
Incident management also involves preparing for incident reporting. Prepare tem-
plates to ensure consistency, repeatability, and comprehensiveness. Prepare portions
of the reports for certain consuming audiences, meaning a concise summary of busi-
ness impact for executives versus more technical details for operations management.
Report Notifications
An important aspect of incident response is to keep all those informed who need
to be with the information they need to fulll their respective roles in handling
the incident. Management will deal with law enforcement, regulatory agencies, the
press, and the executive board. e security department provides timely and accu-
rate statuses of the incident details and incident response to management. Informing
local management is a key factor to managing the political situation between your
site and the main headquarters. Your local management will not like (and subse-
quently neither will you) learning about incident details from their superiors.
To ensure incidents receive the attention they deserve and that all lessons learned
from incident response inuence modications to policy, standards, procedures,
and practice, assign ownership to all incidents. e incident owner is accountable
for monitoring, tracking, and communicating the details of incident response and
the root cause analysis to appropriate parties within the enterprise. e incident
owner may create an incident record that includes all details of symptoms, root
cause analysis (RCA) ndings, subsequent modications to enterprise practices,
and how to resolve the incident. ese records then give the Help Desk sta the
ability to address the incident at Tier 1 without having to involve the more expen-
sive resources in Tier 2 and Tier 3.
Managing the news media is an art form, and any incident, however devas-
tating or benign, may result in good press or bad press. It is critical to manage
press communications via ocial enterprise channels to ensure that the right
message in the right format to the right people conveys the story the enterprise
desires to tell.
Overseeing Compliance of Security Operations ◾ 211
© 2011 by Taylor & Francis Group, LLC
Sustain
To sustain means to maintain an acceptable state or level of performance, i.e., sus-
tainment activities keep operations within acceptable operating parameters. Your
primary objective as a security professional is to optimize stakeholder interests; this
includes sustaining business functionality in the face of adversity. Given the loss of a
key technology and lack of a replacement technology, how will you sustain business
functionality? Sustaining technical performance is completely subordinate to sus-
taining business functionality. You must map technology to business functions, and
map business functions to mission operations and mission objectives. is will help
dierentiate a key technology that directly fullls a mission objective versus a support
technology that, while still important, is not as high a priority as a key technology.
Intelligent decisions to sustain operations require alignment of technology to
the business function it supports and understanding the business function in rela-
tion to the overall enterprise. is is a nontrivial endeavor, but it is very important
for you to make decisions and rationally justify those decisions. If you are going to
be wrong, be wrong for the right reasons and not lack of preparedness.
Enterprise statements of vision, mission, goals, objectives, policy, standards,
and procedure all contribute to dening an acceptable state or level of performance.
ese drive the decisions surrounding technical and security planning, implemen-
tation, enforcement, and maintenance that establish and operate technology and
security safeguards within acceptable operating parameters. Start with the high
level strategic documents for your organization and work your way down through
enterprise architecture (a formal alignment of business and technology), systems
engineering, security controls that comprise your ESS, and the technologies that
implement the controls.
Violations and Breaches
You have an incident, a violation, or breach of security! e rst thing to do is
remain calm and keep management calm; fear and panic interfere with rational
thought. e rst report is almost always wrong in some respect. Get the facts and
follow the response plan. Keep management engaged in the response process and
in the decision making, e.g., unplugging a critical business server may seem like the
right security decision, but is it the right business decision? A predesignated man-
ager may have to make this decision, and probably should make this decision, over
a systems administrator or Help Desk agent.
Executing the incident response plan will provide a good guide to focus eorts,
to engage the right people, and to follow the right procedures. At the point of initial
response, you don’t know if you are responding to a technical error, an attack, an
act of corporate espionage, or a disgruntled employee. Investigative procedures and
212 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
activities should follow evidentiary preservation procedures to be sure the path of
successful prosecution remains open.
Incident Response
e Respond phase within Incident Management alludes to the need for formal
incident response. Enterprise incident response details are best documented within
a formal incident response model. ere are many to choose from, and like the ESS
and ESF, the enterprise incident response model should reect the enterprise needs.
e following sections describe choices for incident response models and then pres-
ent incident response details in the context of one of those models.
Incident Response Models
e SysAdmin Audit Network Security (SANS) Institute and NIST SP 800-61
Computer Security Incident Handling Guide both oer incident response models.
e SANS model has six steps for incident response:
1. Preparation
2. Identication
3. Containment
4. Eradication
5. Recovery
6. Lessons Learned
e NIST model has four steps, and consolidates containment, eradication,
and recovery into a single step:
1. Preparation
2. Detection and Analysis
3. Containment, Eradication, and Recovery
4. Post-Incident Activity
Both models essentially cover the same material. An additional model that covers
essentially the same material, but may oer further insight into how to devise your
own incident response model, is the Organizational Models for Computer Security
Response Teams (CSIRTs) by Carnegie Mellon Software Engineering Institute.
*
Another incident response model includes the following phases:
*
http://www.sei.cmu.edu/publications/documents/03.reports/03hb001.html (accessed April
2009).
Overseeing Compliance of Security Operations ◾ 213
© 2011 by Taylor & Francis Group, LLC
◾ Monitor
◾ Detect
◾ Notify (recording of incident)
◾ Triage (classication)
◾ Escalate (investigate and diagnose; nd the symptom)
◾ Isolate/contain (stop the bleeding; treat the symptom)
◾ Restore business function
◾ Root cause analysis (RCA) (nd the problem, not just the symptom)
◾ Fix the problem (resolution and recovery; incident closure)
◾ Enterprise feedback (capture lessons learned and leverage throughout the enterprise)
is model is essentially the same as the other two, but with a greater number of
phases (i.e., more granular phases). e benet of this model is it has more granular
steps in which to dene incident response activities, dene metrics, and analyze the
metrics to gauge incident response eectiveness and eciency.
e occurrence of an event precedes the ability to detect. e dierence
between time of event occurrence (time
0
) and time of event detection (time
d
) pro-
vides insight into the eectiveness of the detection capability. ere are examples of
weeks, months, and even years between an event and detection.
e detection of an event is the detection of an anomaly, i.e., something doesn’t
look quite right. Upon detection, the detector noties the rst line of support for
handling anomalies within the enterprise; this is likely the Help Desk or the secu-
rity department, depending on the nature of the anomaly, e.g., calling an armed
security guard for an intruder in the data center and the Help Desk for malware
detection both make sense, but not vice versa.
e Help Desk will investigate the anomaly and classify it according to their
experience. At this point, an event may become a security incident depending on
what the anomaly is and the kind of threat it poses to enterprise operations. e
following are examples of incident categories:
◾ Applications
− Service not available
− Software bug
− Resource threshold exceeded (e.g., disk storage, bandwidth)
◾ Hardware
− System down; not available
− Automatic alert
• Intrusion detection system (IDS)
− Printer not printing
◾ Service Request
◾ Password reset
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.