Ch4 cism 2014

27-Feb-14
2
Copyright@2014 Al-Taysir for Information Systems Security Consulting LLC
 Introduction
 Incident Management and Disaster Recovery Overview
 Roles and Responsibilities
 Incident Management Objectives
 Incident Management Metrics and Indicators
 Current State of Incident Response Capability
 Defining Incident Management Procedures
 Incident Management Resources
 Developing an Incident Management Plan
 Developing Response and Recovery Plans
 Testing Response and Recovery Plans
 Executing Response and Recovery Plans
 Documentation
 Summary

27-Feb-14
3
 Plan, establish and manage the capability to
detect, investigate, respond to and recover from
information security incidents to minimize
business impact.
 The content area in this chapter will represent
approximately 18% of the CISM examination.
 Establish and maintain an organizational definition of, and
severity hierarchy for, information security incidents to allow
accurate identification of and response to incidents.
 Establish and maintain an incident response plan to ensure an
effective and timely response to information security incidents.
 Develop and implement processes to ensure the timely
identification of information security incidents.
 Establish and maintain processes to investigate and document
information security incidents to be able to respond
appropriately and determine their causes while adhering to
legal, regulatory and organizational requirements.
 Establish and maintain incident escalation and notification
processes to ensure that the appropriate stakeholders are
involved in incident response management.

27-Feb-14
4
 Organize, train and equip teams to effectively respond to
information security incidents in a timely manner.
 Test and review the incident response plan periodically to
ensure an effective response to information security incidents
and to improve response capabilities.
 Establish and maintain communication plans and processes to
manage communication with internal and external entities.
 Conduct post-incident reviews to determine the root cause of
information security incidents, develop corrective actions,
reassess risk, evaluate response effectiveness and take
appropriate remedial actions.
 Establish and maintain integration among the incident
response plan, disaster recovery plan and business continuity
plan.
 The components of an incident response plan
 Incident management concepts and practices
 Business continuity planning (BCP) and disaster recovery planning (DRP) and their
Relationship to the incident response plan
 Incident classification methods
 Damage containment methods
 Notification and escalation processes
 The roles and responsibilities in identifying and managing information security incidents
 The types and sources of tools and equipment required to adequately equip incident
response teams
 Forensic requirements and capabilities for collecting, preserving and presenting
evidence (for example, admissibility, quality and completeness of evidence, chain of
custody)
 Internal and external incident reporting requirements and procedures
 Post-incident review practices and investigative methods to identify root causes and
determine corrective actions
 Techniques to quantify damages, costs and other business impacts arising from
information security incidents
 Technologies and processes that detect, log and analyze information security events
 Internal and external resources available to investigate information security incidents

27-Feb-14
5
 Incident
 Adverse event that has caused or has the potential to
cause damage to an organization’s assets, reputation
or personnel.
 Incident Management
 A process of developing and maintaining the capability
to manage incidents within an organization, so that
impacts can be continued and recovery is achieved
within the specified time objective

27-Feb-14
6
 Incident handling
 All processes or tasks associated with handling events and
incidents:
▪ Detection and reporting
▪ Triage
▪ Analysis
▪ Incident response
 Incident Response
 The capability to effectively prepare for and respond to
unanticipated events to control and limit damage, and maintain
or restore normal operations.
 Last step in an incident handling process that encompasses the
planning, coordination, and execution of any appropriate
mitigation, and recovery strategies and actions.
 Incident management systems automate many manual
processes
 Leaving only filtered information indicating an incident to be
processed by the Incident Management Team (IMT)
 Can be distributed or centralized
 An effective incident management system should:
 Consolidate inputs from multiple systems
 Identify incidents or potential incidents
 Prioritize incidents based on business impact
 Track incidents until they are closed
 Provide status tracking and notifications
 Integrate with major IT management systems
 Implement good practices guidelines

27-Feb-14
7
 To manage the impact of unexpected disruptive
events to acceptable levels
 Possible disruptions may be technical, physical and
environmental
 Any type of incident that can significantly affect the
organizations ability to operate or that may cause
damage must be considered by the ISM

27-Feb-14
8

27-Feb-14
9
 Incident Response Planning (IRP) is very similar
to BCP except that IRP focuses on security related
breaches that threaten the integrity of systems,
networks, applications and data as well as
confidentiality of critical information and non-
repudiability of electronic transactions.
 Planning considerations must include all business
functions that are critical, vital, sensitive as well
as non-sensitive and noncritical but necessary
support functions.
 Plans should be:
 Clearly documented
 Readily accessible
 Based on the long range IT plan
 Consistent with the overall business continuity and
security strategies

27-Feb-14
10
 Decisions to be made by the stakeholders and
ratified by senior management include:
 Incident detection capabilities
 Clearly defined severity criteria
 Assessment and triage capabilities
 Declaration criteria
 Prepare BIA
 Identify and prioritize systems and resources required to support critical
business processes
 Assess incident detection and monitoring capabilities
 Define and obtain agreement on severity criteria and declaration
criteria
 Choose appropriate strategies for recovering at least sufficient facilities
to support critical business processes
 Develop the disaster recovery plan
 Train staff on how to follow the plan
 Test the plans
 Maintain the plans as the business changes and systems develop
 Store the plans so they can be accessed despite computer and network
failures
 Audit the plans

27-Feb-14
11
 The following factors have contributed to the
criticality of incident management :
 The trend of both increased occurrences and escalating
losses resulting from security incidents
 The increase in vulnerabilities in software or systems can
affect an organizations infrastructure and impact
operations
 Failure of technical controls to prevent incidents
 Legal and regulatory requirements
 The growing sophistication and capabilities of profit
oriented attackers
 Can deal effectively with unanticipated events
 Has sufficient detection and monitoring capabilities
 Has well defined severity and declaration criteria as
well as defined escalation and notification processes
 Has response capabilities that demonstrably support
the business strategy
 Proactively manages risks of incidents appropriately
 Periodically tests its capabilities
 Provides monitoring and metrics to gauge
performance of incident management and response
capabilities.

27-Feb-14
12
 Document that formally establishes the IMT and
documents its responsibility to manage and
respond to security incidents.
 Sections of the charter should include:
 Mission
 Scope
 Organizational structure
 Information flow
 Services provided

27-Feb-14
13
 Containing the effects of the incident
 Notifying the appropriate people for the purpose of
recovery or to provide needed information
 Recovering quickly and efficiently from security
incidents
 Minimizing the impact of the security incident
 Responding systematically and decreasing the
likelihood of recurrence
 Balancing operational and security processes
 Dealing with legal and law enforcement-related
issues
 Define what constitutes a security-related incident:
 Malicious codes attacks
 Unauthorized access to IT/IS resources
 Unauthorized utilization of services
 Unauthorized changes to systems, network devices or
information
 Denial of service
 Misuse
 Surveillance and espionage
 Hoaxes /social engineers

27-Feb-14
14
 Developing the information security incident
management and response plans
 Handling and coordinating information security
incident response activities effectively and efficiently
 Validating, verifying and reporting of protective or
countermeasure solutions, both technical and
administrative
 Planning, budgeting and program development for
all matters related to information security incident
management and response
 Senior management is critical to the success of
incident management and response
 Incident management and response is a
component of risk management and needs the
same level of support from the top

27-Feb-14
15

27-Feb-14
16

27-Feb-14
17
 A documented set of incident response policies,
standards and procedures is important to:
 Ensure that incident management activities are
aligned to the IMT mission
 Set correct expectations
 Provide guidance for operational needs
 Maintain consistency and reliability of services
 The following security concepts and technologies
should be considered and known to IRTs:
 Security principles
 Security vulnerabilities/weaknesses
 The Internet
 Network protocols
 Network applications and services
 Network security issues
 Operating systems (how to)
 Malicious code
 Programming skills

27-Feb-14
18
 An IMT usually consists of:
 The ISM (who usually leads the team)
 Steering committee/advisory board
 Permanent/dedicated team members
 Virtual/temporary team members
 The composition of incident response staff will
vary from team-to-team and will depend on a
number of factors such as:
 Mission and goals of the incident response program
 Nature and range of services offered
 Available staff expertise
 Constituency size and technology base
 Anticipated incident load
 Severity or complexity of incident reports
 Funding

27-Feb-14
19
Personal
 Communication
 Presentation skills
 Ability to follow policies and
procedures
 Team skills
 Integrity
 Self understanding
 Coping with stress
 Problem solving
 Time management
Technical
 Technical foundation skills
 Incident handling skills
 If an organization is unable to find internal experts or
hire/train staff to provide the necessary specialist skills,
they may be able to develop relationships with experts in
the field to provide the necessary skills. When a situation
arises where in-house knowledge is not enough, these
technical specialists can be called upon to fill the gap in
expertise.
 When more complex incidents are reported, the
organization needs to supplement or expand the staff's
basic skills to include more in-depth knowledge so that
staff members can understand, analyze, and identify
effective responses to reported incidents.

27-Feb-14
20
 Audits (internal and external) must be performed
to verify the IMT’s conformance to policy,
standards, guidelines and procedures defined for
an organization
 Outsourcing incident management capability
sometimes is a logical choice.
 For example, organizations that have already
outsourced their information technology operations
may benefit from close integration if incident
management is to be outsourced to the same
vendor.
 Likewise, outsourcing incident management
capabilities when the information systems or assets
protected are still maintained in-house may not be
effective.

27-Feb-14
21
 Handle incidents when they occur so that the
exposure can be contained or eradicated to
enable recovery.
 Prevent previous incidents from recurring by
documenting and learning from past incidents
 Deploy proactive countermeasures to
prevent/minimize the probability of incidents
from taking place

27-Feb-14
22
 Well developed monitoring capabilities for key controls
 Personnel trained in assessing the situation, capable of
providing triage, and managing effective responses
 Managers that have made provisions to capture all
relevant information and apply previously learned lessons
 Managers that know when a disaster is imminent and have
well-defined criteria, the experience, knowledge, and the
authority to invoke the disaster recovery processes
necessary to maintain or recover operational status

27-Feb-14
23
 Constituency—To whom does the IMT provide services?
 Mission—It defines the purpose of the team and the
primary objectives and goals that are provided by IMT.
 Services—Services provided by IMT should be clearly
defined to manage stakeholder expectations.
 Organizational structure—The structure of the IMT should
effectively support the organization's structure.
 Resources—Sufficient staffing is needed to be effective.
 Funding—The IMT usually consists of highly specialized
members.
 Management buy-in—Senior management buy-in is
essential for establishing and supporting the incident
management function.
 Successful outcomes of risk management include
effective incident management and response
capabilities
 Any risk that materializes that is not prevented
by controls will constitute an incident that must
be managed and responded to with the intent
that it not escalate into a disaster

27-Feb-14
24
 The type and nature of incidents that the information
security manager may deal with will often require the
involvement of a number of other organizational
assurance functions.
 This may include physical security, legal, human resources
(HR) and perhaps, others. As a consequence, it is
important to ensure incident management and recovery
plans actively incorporate and integrate those functions
where required.
 An effective outcome is a set of plans that defines which
departments are involved in various incident management
and response activities, and that those linkages have been
tested under realistic conditions.
 Integrate with business processes and structures
as seamlessly as possible
 Improve the capability of businesses to manage
risk and provide assurance to stakeholders
 Integrate with BCP
 Become part of an organization’s overall strategy
and effort to protect and secure critical business
function and assets
 Provide the backstop and optimize risk
management efforts

27-Feb-14
25
 Resource management spans time, people,
budget and other factors to achieve objectives
efficiently under given resource constraints.
Incident management and response activities
consume resources that must be managed to
achieve optimal effectiveness. When it is not
possible to achieve all objectives, effective
resource management ensures that the most
important priorities are addressed first.
 Achieving the defined objectives and optimizing
effectiveness
 KPIs and KGIs should be defined and agreed upon
by stakeholders and ratified by senior
management

27-Feb-14
26
 The two most commonly adopted approaches
are from CMU/SEI and the SANS Institute.
 CMU/SEI technical report “Defining Incident
Management Processes”:
 Prepare/improve/sustain (prepare)
 Protect infrastructure (protect)
 Detect events (detect)
 Triage events (triage)
 Respond

27-Feb-14
27
 Coordinate planning and design
 Coordinate implementation
 Evaluate incident management capability
 Conduct postmortem review
 Determine incident management process
changes
 Implement incident management process
changes
 Implement changes to computing infrastructure
to mitigate ongoing or potential incident.
 Implement infrastructure protection
improvements from postmortem reviews or
other process improvement mechanisms.
 Evaluate computing infrastructure by performing
proactive security assessment and evaluation.
 Provide input to detect process on
incidents/potential incidents.

27-Feb-14
28
Proactive detection
 Processes that detect are
running before any incident
occurs
Reactive detection
 Anomalies are noticed,
triggering an investigation
 Two levels:
 Tactical - Based on a set of criteria
 Strategic - Based on the impact of business
 Subprocesses:
 Categorization
 Denial of service
 Malicious code
 Unauthorized access
 Inappropriate usage
 Multiple components

27-Feb-14
29
 Technical response
 Collecting data for further analysis
 Analyzing incident supporting information such as log files
 Technical mitigation strategies and recovery options
 Phone or e-mail technical assistance
 On-site assistance
 Analysis of logs
 Development and deployment of patches and
workarounds
 Management response
 Legal response

27-Feb-14
30
 Survey of senior management, business
managers and IT representatives
 Self-assessment
 External assessment or audit
 History of Incidents
 Input for assessment of the IMT’s performance
 Provides a descriptive picture for senior management
 Adverse events that may cause harm to an
organization’s assets, operations or personnel.
 Materialize when vulnerabilities are exploited.
 Include:
 Environmental
 Technical
 Man-made

27-Feb-14
31
 Vulnerability management is part of the incident
management capability; it is the proactive
identification, monitoring and fixing of any
weaknesses
 Risk is the probability that a threat will exploit a
vulnerability to cause an incident.
 A basic understanding of security risk analysis and the
effects on organizations of various types of risk are
important components of incident management.
 Risk Tolerance
 The ISM should be aware that incident management also
includes business continuity and DRP
 Overall response management is equal to the combination
of BCP, DRP and continuity of business operations and
incident response

27-Feb-14
32
 Oversee development of response and recovery
plans (based on BIA) to ensure they are properly
designed and implemented
 Ensure resources required to continue the
business are identified and recorded
 Identify and validate response and recovery
strategies
 Obtain senior management approval of strategies
 Oversee the development of comprehensive
response and recovery plans

27-Feb-14
33

27-Feb-14
34
 RTO
 The amount of time allowed for recovery of a business
function or resource after a disaster occurs
 Effective incident management includes resolving
incidents with the acceptable interruption window
 RPO
 A measurement of the point prior to an outage to
which data are to be restored
 Describes the state of recovery that should be
achieved to facilitate acceptable outcomes

27-Feb-14
35
 Incident response plan is the part of incident
management that is executed to adequately handle
incidents
 The SANS Institute proposes the following incident
response plan phases:
 Preparation
 Identification
 Containment
 Eradication
 Recovery
 Lessons learned
 Compares current incident response capabilities
with the desired level.
 Basis for an Incident Response Plan
 By comparing the two levels, the following may be
identified:
 Single point of failure
 Processes that need improved to be more efficient and
effective
 Lack of resources
 Lack of adequate handover between phases and persons

27-Feb-14
36
 Critical results of a BIA include
 Criticality prioritization
 Downtime estimation
 Resource requirements
 A vulnerability analysis is often part of the BIA
 A successful BIA requires participation from
 Senior management
 IT
 End-user personnel
 A BIA includes the following activities:
 Gathering assessment material
 Analyzing the information that is gathered
 Documenting the result and presenting
recommendations
 A BIA should:
 Establish the escalation of loss over time
 Identify the minimum resources needed for recovery
 Prioritize the recovery of processes and supporting
systems

27-Feb-14
37
 BIAs often have the following elements in common:
 Describing the business mission of each particular
business/cost center
 Identifying the functions that characterize each center
 Identifying critical processing cycles (in terms of time
intervals) for each such function
 Estimating the impact of each type of incident on business
operations
 Estimating the amount of time that recovering from each
type of incident is likely to take
 Conducting BIAs produces several important
major benefits, including:
 Increasing the understanding of the amount of
potential loss, and various other undesirable effects,
that could occur from certain types of incidents
 Facilitating all response management activities
 Raising the level of awareness for response
management within an organization/business

27-Feb-14
38
 Establishing an approach to handle incidents
 Establishing policy and warning banners in
information systems to deter intruder and allows
information collection
 Establishing communication plan to stakeholders
 Developing criteria on when to report incident to
authorities
 Developing a process to activate incident
management team
 Establishing a secure location to execute incident
response plan
 Ensuring equipment needed are available
 Assigning ownership of an incident or potential
incident to an incident handler
 Verifying that reports or events qualify as an
incident
 Establishing chain of custody during
identification when handling potential evidence
 Determining the severity of an incident and
escalating it as necessary

27-Feb-14
39
 Activating incident management/response team to contain
the incident
 Notifying appropriate stakeholders affected from the
incidents
 Obtaining agreement on actions taken that may affect
availability of a service or risks of the containment process
 Getting IT representative and relevant virtual team
members involved to implement containment procedures
 Obtaining and preserving evidence
 Documenting and taking backups of actions taken from
this phase onward
 Controlling and managing communication to public by
public relations team
 Determining the signs and cause of incidents
 Locating the most recent version of backups or
alternative solutions
 Removing the root cause—in the event of worm or
virus infection, it can be removed by deploying
appropriate patches and updated antivirus software
 Improving defenses by implementing protection
techniques
 Performing vulnerability analysis to find new
vulnerabilities introduced by the root cause

27-Feb-14
40
 Restoring operations to normal
 Validating that actions taken on restored systems
were successful
 Getting involvement of system owners to test the
system
 Facilitating system owners to declare normal
operation
 Writing incident report
 Analyzing issues encountered during incident
response efforts
 Proposing improvement based on issues
encountered
 Presenting report to relevant stakeholders

27-Feb-14
41
 Prioritizing event information
 Identify the decision process for determining
when to alert various groups
 Create a mechanism to communicate crisis and
other critical event information
 The ISM should understand and manage intrusion
detection policies and procedures including:
 Systems on which intrusion detection software runs are fault-
tolerant and are secure against attack
 Personnel who run and monitor intrusion detection systems
have adequate training
 Intrusion detection software and hardware runs continuously
 Intrusion detection software can be easily modified and can
adapt to changing environments
 Intrusion detection systems do not impose excessive overhead,
especially excessive network overhead
 Intrusion detection systems detect a high percentage of
anomalies

27-Feb-14
42
 An organization should ideally use two types of
intrusion detection systems (IDSs)
 Host-based
 Network-based
 Sensors should be suitably placed to provide
adequate coverage of the network typology
 Intrusion detection policies and procedures should
include:
 Identifying vulnerabilities exploited by the perpetrator
 Recording logs and making a full backup of systems
impacted
 Identifying any apparent motivation(s) for the attack(s)
 Determining how may systems were compromised
 Determining if any viruses, worms, Trojans or other
programs are still present in compromised systems
 Documenting steps taken to respond to incidents
 Assigning responsibilities for various aspects of the
intrusion detection process

27-Feb-14
43
 The ISM needs to:
 Define the goals, objectives and priorities for IDSs and
assess the alternative(s) that will best fulfill these
requirements
 Understand the complete costs of implementing
security controls
 Determine the appropriate mix between externally
managed security services providers to manage the
organization’s IDSs and internal staff to achieve timely
and knowledgeable reaction to malicious activity
 The information security manager should have processes defined for
help desk personnel to distinguish a typical help desk request from a
possible security incident.
 Prompt recognition of an incident in progress and quick referral to
appropriate parties is critical to minimizing the damage resulting from
such incidents.
 By defining appropriate criteria and by improving the awareness of help
desk personnel, the information security manager develops another
important method to detect a security incident.
 Proper training also helps to reduce the risk that the help desk could be
successfully targeted in a social-engineering attack designed to obtain
access to accounts, as when a perpetrator pretends to be a user who
has been locked out and requires immediate access to the system.
 In addition to identifying a possible security incident, help desk
personnel should be aware of the proper procedures to report and
escalate a potential issue.

27-Feb-14
44
 The emergency action team
 Damage assessment team
 Emergency management team (the team with
overall operational authority)
 Relocation team
 Security team

27-Feb-14
45
 Every IMT member should undergo the following
training program:
 Induction to IMT—basic information about the team
and its operations
 Mentoring re. team’s roles, responsibilities and
procedures
 On the job training
 Formal training
 Functions within organizations that are most
likely to need information concerning incidents
when they occur include:
 Risk management
 Human relations (whenever an attack appears to be
initiated by one or more insiders)
 Legal
 Public relations
 Network operations

27-Feb-14
46
 Lack of management buy-in and organizational
consensus
 Mismatch to organizational goals and structure
 IMT member turnover
 Lack of communication process
 Complex and wide plan

27-Feb-14
47
 Considerations:
 Available resources
 Expected services
 Types, kinds, and severity of threats faced by the
organization

27-Feb-14
48

27-Feb-14
49

27-Feb-14
50

27-Feb-14
51
Disaster Recovery
 Recovery of IT systems
when disastrous events
have severely disrupted
information processing
capabilities
Business recovery
 Recovery of the critical
business processes necessary
to achieve key business
processes
 Risk-based classification systems need to be in
place to help planning processes:
 Risk and business impact assessment
 Response and recovery strategy definition
 Documenting response and recovery plans
 Training covering response and recovery procedures
 Updating response and recovery plans
 Testing response and recovery plans
 Auditing response and recovery plans

27-Feb-14
52
 Criteria for selection of a recovery strategy include:
 Criticality of the business process and the applications that
support it
 Cost—the cost of preparation plus cost of handling incident
 Time required to recover
 Security-related considerations
 Reliability
 The appropriate strategy will result in
 A reasonable cost
 An acceptable recovery time
 Acceptable impact
 Lower likelihood of re-occurrence
 Once the organization is up and running in
recovery mode, which is usually from a disaster
recovery site in case of damage or inaccessibility
of the primary facility, the business continuity
teams should monitor the progress at the
primary site to assess when it is safe to return
and perform tests to evaluate whether the
primary data center and facilities are accessible,
operational and capable of functioning at normal
capacities and processing load.

27-Feb-14
53
 Recovery strategies must work for the entire
period of recovery until all facilities are restored
 Strategies may include:
 Doing nothing until recovery facilities are ready
 Using manual procedures
 Focusing on the most important customers, suppliers,
products, and systems with resources that are still
available
 Using PC-based systems to capture data for later
processing or performing simple local processing
 Eliminate or neutralize a threat
 Minimize the likelihood of a threat’s occurrence
 Minimize the effects of a threat if an incident
occurs

27-Feb-14
54
 The site should not be subject to the same
natural disaster(s) as the original (primary) site
 Ability to coordinate hardware/software
strategies
 Assurance of resource availability
 Ability to agree concerning the priority of adding
applications (workloads) until all the recovery
resources are fully utilized
 Ability to test regularly

27-Feb-14
55
 Pre-incident readiness
 Evacuation procedures
 Disaster declaration strategy
 Prioritized business processes and IT resources
 Identifying responsibilities in the plan
 Identifying persons responsible for each function in
the plan
 Updating contact information of teams and external
agencies
 The step-by-step explanation of the recovery options
 Identifying the various resources required for
recovery and continued operations
 Most business continuity plans are created as a set of
procedures that accommodate system, user and network
recovery strategies.
 Copies of the plan must be kept offsite to ensure that it is
 available when needed; this includes at the recovery
facility, at the media storage facility and at the homes of
key decision making personnel.
 Components of the plan must include key decision-making
personnel, a backup of required supplies, the organization,
and the assignment of responsibilities, telecommunication
networks and insurance provisions.

27-Feb-14
56
 Risk Acceptance and Tolerance
 Business Impact Analysis
 Interruption window
 RTOs
 RPOs (recovery point objectives—the age of data
to be restored)
 Services delivery objectives (SDOs)—minimum
services delivered
 Maximum tolerable outages (MTOs)
 Representatives of equipment and software vendors
 Supplies and equipment or services
 Recovery facilities, including hot-site representatives
or predefined network communications rerouting
services
 Offsite media storage facilities
 Recovery team
 Insurance company agents
 Human relations and/or contract personnel services
 Law enforcement contacts

27-Feb-14
57
 The plan must include provisions for all supplies necessary for
continuing normal business activities during the recovery
effort.
 This includes detailed, up-to-date hard-copy procedures that
can be followed easily by staff and contract personnel who are
unfamiliar with the standard and recovery operations. This is to
ensure that the plan can be implemented, even if members of
the regular staff are unavailable. Also, a supply of special
forms, such as check stock, invoice forms and order forms,
should be secured at an offsite location.
 If the data entry function is dependent on certain hardware
devices and/or software programs, these programs and
equipment, including specialized electronic data interchange
(EDI) equipment and programs, must also be provided at the
recovery site.
 Telecommunications capabilities to consider include:
 Telephone voice circuits
 wide area networks (WANs) (connections to distributed data centers)
 local area networks (LANs)
 third-party electronic data interchange providers.
 Options can include
 satellite and microwave links, and depending on criticality and
 location, wireless links or even single sideband radiotelephone
 communications.
 Critical capacity requirements should be identified for the
various thresholds of outage, such as two hours, eight hours or
24 hours, for each telecommunications capability.
 Uninterruptable power supplies (UPSs) should be sufficient to
provide backup for telecommunications equipment as well as
for computer equipment.

27-Feb-14
58
 Redundancy
 Alternative routing
 Diverse routing
 Long-haul network diversity
 Protection of local resources
 Voice recovery
 Last mile protection
 Availability appropriate circuits and adequate
bandwidth
 Availability of out-of-band communications in case
of failure of primary communications methods
 Fault Tolerant Systems
 Fail safe servers using clusters or load balancing
 RAID

27-Feb-14
59
 A vendor or third party
 Off-the-shelf—to make use of this approach,
several strategies must be employed
 Avoiding the use of unusual and hard-to-get
equipment
 Regularly updating equipment to keep current
 Maintaining software compatibility to permit the
operation of newer equipment
 Ensuring that the recovery plans include instructions
concerning how such equipment is to be paid for
 Types Of Insurance Coverage
 IT equipment and facilities
 Media (software) reconstruction
 Extra expense
 Business interruption
 Valuable papers and records
 Errors and omissions
 Fidelity coverage (in case of employee
fraud/malfeasance)
 Media transportation

27-Feb-14
60
 The ISM must understand:
 Activities involved in emergency management
 Risks pertaining to local area by meeting emergency
management officials (municipal, government)
 Focusing on activities during and after a disaster
that prompt recovery action is imperative:
 Restoring hardware, software and data
 Creating a command center
 Developing and using an evacuation plan

27-Feb-14
61
 Developing test objectives
 Evaluating the test
 Developing recommendations to improve the
response and recovery plans
 Implementing a follow-up process to ensure that
the recommendations are implemented
 After test objectives have been defined, the ISM
must:
 Ensure that an independent third party observer is
present to monitor and evaluate the test
 Implement a tracking process to ensure that any
recommendations resulting from testing are
implemented in a timely fashion
 Know about disaster recovery testing for
infrastructure and critical business applications

27-Feb-14
62
 The ISM performs tests that progressively
challenge the recovery plans, including:
 Table top walkthroughs of the plans
 Table top walkthroughs with mock disaster scenarios
 Testing the infrastructure and communication
components of the recovery plans
 Testing the infrastructure and recovery of the critical
applications
 Testing the infrastructure, critical applications and
involvement of the end-users
 Tests should:
 Be scheduled at a time that will minimize disruption to
normal operations.
 Verify the completeness and precision of the response
and recovery plan
 Evaluate the performance of the personnel involved in
the exercise
 Appraise the demonstrated level training and
awareness of individuals who are not part of the
recovery/response team

27-Feb-14
63
 Tests should:
 Evaluate the coordination among the team members
and external vendors and suppliers
 Measure the ability and capacity of the backup site to
perform prescribed processing
 Assess the vital records retrieval capability
 Evaluate the state and quantity of equipment and
supplies that have been relocated to the recovery site
 Measure the overall performance of operational and
information systems processing activities related to
maintaining the business entity

27-Feb-14
64
 A facilitator or director* (often ISM) is needed to
 Direct the tasks within the plans
 Oversee plan execution
 Liaise with senior management
 Make decisions as necessary
 Defining appropriate recovery strategies and
alternatives is important in the overall process
 Imperative plan maintenance activities:
 Develop a schedule for periodic reviews of infrastructure
changes
 Call for revisions out of schedule when significant changes
have occurred
 Review revision and comments and update the plan
 Arrange and coordinate scheduled and unscheduled tests
 Participate in scheduled plan tests, at least annually
 Develop a personnel training strategy
 Maintain records of plan testing, reviews, and training
 Update the plan (including the call tree within)

27-Feb-14
65
 The analysis should be done to determine
answers to questions such as:
 Who is involved?
 What has happened?
 Where did the attack originate from?
 When (what time frame)?
 Why did it happen?
 How was the system vulnerable or how did the attack
occur?
 What was the reason for the attack?

27-Feb-14
66
 It is essential for ISM to have processes in place to develop
a clear record of events.
 Preserving events can be investigated and provided to a
forensics team or authorities if necessary.
 There should be one or more individuals specifically
charged with incident documentation and the
preservation of evidence.
 Documentation of any event that has possible security
implications can provide clarity as to whether an incident
is merely an accident, mistake or a deliberate attack.
 Good documentation will prove invaluable in post-incident
investigation and forensics as well as possibly helpful in
incident resolution.
 Establishing procedures for documenting an event
 If an incident occurs:
 The information security staff needs documented
procedures so that information can be properly recorded
and preserved
 The ISM should develop data/evidence preservation
procedures
 The information systems staff must understand basic
procedures, including taking no action that could
change/modify/contaminate potential or actual evidence

27-Feb-14
67
 The initial response by the system administrator
should include:
 Retrieving information needed to confirm an incident
 Identifying the scope and size of the affected
environment (e.g., networks, systems, applications)
 Determining the degree of loss, modification or
damage (if any)
 Identifying the possible path or means of attack
 Backing up all possible sources of evidence or relevant
information when appropriate
 The ISM must know:
 Requirements for collecting and presenting evidence
 Rules for evidence, admissibility of evidence, and
quality and completeness of evidence
 The consequences of any contamination of evidence
following a security incident

27-Feb-14
68

27-Feb-14
69
 There are many different forms of evidence that can be used in a
computer crime trial:
 Direct: Oral testimony by witness
 Real: Tangible objects, physical evidence
 Documentary: Printed business records, manuals, printouts
 Demonstrative: Used to aid a jury (models, illustrations)
 Each type of evidence can have different forms. Some examples include:
 Best: Least susceptible to tampering or alteration
 Secondary: Less reliable in proving guilt or innocence
 Direct: Proves a fact without additional information
 Conclusive: Irrefutable and cannot be contradicted
 Circumstantial: Proves a fact that can be used to deduce another fact
 Corroborative: Used to help prove an idea or point
 Opinion: Can only be introduced by an expert witness

27-Feb-14
70
 Senior management should provide the incident response manager with the
goals for the investigation. There are several different investigative
requirements. The requirements would help define which course of action
should be taken. Here are some common goals and courses of action:
 Do nothing: This is the least expensive option and is often taken by
organizations without regulatory requirements to investigate incidents.
 Conduct surveillance: This is a more expensive option, but still a relatively
inexpensive option. In this course of action the investigation will focus on
interviewing people and monitoring for future incidents.
 Eliminate security holes: A quick and sometimes costly option is to plug the
hole that allowed the incident to occur. Once the hole is plugged the
investigation is over.
 Criminal investigation: This is the most expensive option. The goal of this
investigation is for the attacker to be prosecuted in a criminal court.
 Civil investigation: This is the second most expensive option. Evidence is
gathered using strict processes, but not as strict as if a criminal investigation
were the primary goal. The end goal of a civil investigation is to recover
monetary losses for the offending attacker in a civil court.

27-Feb-14
71
 The ISM should:
 Manage post-event reviews to learn from the
completed tasks and to use the information to
improve the IMT’s response procedures
 Consider enlisting the help of third-party specialists if
detailed forensic skills are needed
 Understanding the purpose and structure of post-incident
reviews and follow-up procedures enables the information
security manager to continuously improve the security
program.
 A consistent methodology should be adopted within the
information security organization so that, when a problem
is found an action plan is developed to reduce/mitigate it.
 Once the action plan is devised steps should then be taken
to implement the solution.
 By repeating these basic principles
 Information security program will adapt changes in the
organization and the threats it faces.
 Reduces the time personnel need to react to security incidents
so they are able to spend more time on proactive activities.

27-Feb-14
72
 The required documentation to maintain legally admissible
evidence must include:
 Chain of custody forms that include:
▪ Name and contact information of custodians
▪ When, why and by whom an evidence item was acquired or moved
▪ Detailed identification of the evidence (serial numbers, model
information, etc.)
▪ Where it is stored (physically or logically)
▪ When/if it was returned
 Checklists for acquiring technicians (including details of legally
acceptable forensic practices)
 Detailed activity log templates for acquiring technicians
 Signed nondisclosure/confidentiality forms for all technicians
involved in recovering evidence
 An up-to-date case log that outlines:
▪ Dates when requests were received
▪ Dates investigations were assigned to investigators
▪ Name and contact information investigator and requestor
▪ Identifying case number
▪ Basic notes about the case and its requirements and
completed procedures
▪ Date when completed

27-Feb-14
73
 Investigation report templates that include:
▪ Name and contact information of investigators
▪ Date of investigation and an identifying case number
▪ Details of any interviews or communications with
management or staff regarding the investigation
▪ Details of devices or data that was acquired (serial numbers,
models, physical or logical locations)
▪ Details of software or hardware tools used for acquisition or
analysis (these must be recognized forensically sound tools)
▪ Details of findings including samples or copies of relevant
data and/or references to their storage location
▪ Final signatures of investigator in charge
Q & A

Ch4 cism 2014

More Related Content

What's hot

Similar to Ch4 cism 2014

More from Aladdin Dandis

Recently uploaded

Ch4 cism 2014