Loshan Wickramasekara

MSc in Information Security | BSc in IT

CPISI | CRISC | CISM | CISA
Manager - FINCSIRT
Event and Incident
• Events: An event is an observable occurrence in an information system that actually
happened at some point in time.
• For example:
• An email
• A phone call
• A system crash
• A request for virus scans to be performed on a file or attachment
• Incident is an adverse event in an information system – includes the significant threat of
an adverse event. In another word, it implies harm or the attempt to harm
• CERT guidelines indicates an incident can be:
• violation of an explicit or implied security policy
• the attempts to gain unauthorized access
• unwanted denial of resources
• unauthorized use
• changes without the owner’s knowledge, instruction, or consent
Event vs Incident
• Cyber Security Event: An identified occurrence of a system, service or
network state indicating a possible breach of information security
policy or failure of controls, or a previously unknown situation that
may be security relevant.

• Cyber Security Incident: A single or a series of unwanted or

unexpected Cyber Security Events that have a significant probability
of compromising business operations and threatening information
security
Examples
• Malicious code attacks
• Event – User reporting that they might have been hit with a particular virus.
• Potential incident – Their system exhibits behaviors typical for that particular virus.
• Denial of resources
• Event – User reporting that they can’t access a service.
• Potential incident – Many users reporting that they can’t access a service.
• Intrusions
• Event – A system admin think a system was broken into.
• Potential incident – A system admin provided the log indicating suspicious activities took place.
• Misuse
• Event – Web proxy log indicates an user has one hit to a Adult site and company policies dictate that such activities are
not allowed.
• Potential incident – Web proxy log indicates an user has multiple hits to Adult sites and company policies dictate that
such activities is not allowed.
• Unauthorized use
• Event – User tumbled onto an undocumented game within a commercial program by accident.
• Possible incident – User play the undocumented game within the commercial program and there exist a policy stating
that game playing is not allowed.
• Hoaxes
• Event – User send an email containing false information usually associated with chain emails to the masses.
• Possible incident – User send an email containing false information usually associated with chain emails to the masses
How to classify an EVENT as an INCIDENT
• Is there a risk to data integrity ?
• Is there a risk to the availability of the resource ?
• Is there a risk to the confidentiality of the data ?
• Is the activity abnormal ?
• Is it a violation against company security policies ?
What is Incident Management
“Capability to effectively manage unexpected
disruptive events with the objective of
minimizing impacts and maintaining or
restoring normal operations within defined
time limits.”
ISACA, Certified Information Security Manager® (CISM®) Review Manual

Incident management and response can be considered the

emergency operations part of risk management.
Goals of IM
• Detect incidents quickly
• Diagnose incidents accurately
• Manage incidents properly
• Contain and minimize damage
• Restore affected services
• Determine root causes
• Implement improvements to prevent recurrence
• Document and report
Incident Management :Benefits
• Reduced business impact of incidents by timely resolution
• Proactive identification of possible enhancements
• Management information related to business-focused SLA
• Improved monitoring
• Improved management information related to aspects of service
• Better staff utilization: no more interruption-based handling of
incidents
• Elimination of lost incidents and service requests
• Better user/customer satisfaction
Causes for poor incident management process
• Absence of visible management or staff commitment, resulting in non-availability of
resources for implementation

• Lack of clarity about the business/organisation’s needs

• Out of date working practices

• Poorly defined objectives, goals and responsibilities

• Absence of knowledge for resolving incidents

• Inadequate staff training

• Resistance to change
Standards and Guidelines
• The ISO/IEC 27001 Standard
• The ISO/IEC 27002 Standard
• ISO/IEC 27035 Standard
• The ITIL Framework
• NIST Special Publication (NIST SP 800-61)
• ENISA - Good Practice Guide for Incident
Management
• NorSIS - Guideline for Incident Management
• SANS: Incident Handler’s Handbook
Incident Management, Incident Handling and
Incident Response
Incident handling
• Detecting and reporting – the ability to receive and review event
information, incident reports, and alerts
• Triage – the actions taken to categorize, prioritize, and assign events and
incidents
• Analysis – the attempt to determine what has happened, what impact,
threat, or damage has resulted, and what recovery or mitigation steps
should be followed. This can include characterizing new threats that may
impact the infrastructure.
• Incident response – the actions taken to resolve or mitigate an incident,
coordinate and disseminate information, and implement follow-up
strategies to prevent the incident from happening again
Best Practices for Building an Incident
Response Plan
• Incident Response Plans are written and documented.

• Incident Response Plans are battled-tested.

• Incident Response Plans evolve over time.

• Incident Response Plans are implemented as a business practice.

• Incident Response Plans are actionable.

Plan Elements
• Mission
• Strategies and goals
• Senior management approval
• Organizational approach to incident response
• How the incident response team will communicate with the rest of the
organization and with other organizations
• Metrics for measuring the incident response capability and its effectiveness
• Roadmap for maturing the incident response capability
• How the program fits into the overall organization.
Policy Elements
• Policy governing incident response is highly individualized to the organization. However, most
policies include the same key elements:
• Statement of management commitment
• Purpose and objectives of the policy
• Scope of the policy (to whom and what it applies and under what circumstances)
• Definition of computer security incidents and related terms
• Organizational structure and definition of roles, responsibilities, and levels of authority; should
include the authority of the incident response team to confiscate or disconnect equipment
and to monitor suspicious activity, the requirements for reporting certain types of incidents,
the requirements and guidelines for external communications and information sharing (e.g.,
what can be shared with whom, when, and over what channels), and the handoff and
escalation points in the incident management process
• Prioritization or severity ratings of incidents
• Performance measures
• Reporting and contact forms.
Sharing Information With Outside Parties
Measure the effectiveness and efficiency of the
incident management function
• Total number of reported incidents
• Total number of detected incidents
• Average time to respond to an incident
• Average time to resolve an incident
• Total number of incidents successfully resolved
• Proactive and preventive measures taken
• Total number of employees receiving security awareness training
• Total damage from reported and detected incidents if incident response
was not performed
• Total savings from potential damages from incidents resolved
• Total labor responding to incidents
• Detection and notification times
CISM® Review Manual 2013
 Incident Management Roles
Computer Security Incident Response
• Team Lead/Chairman • Vulnerability Handlers • Trainers
• Group Leaders • Artifact Analysis Staff • Technology Watch
• Help Desk • Platform Specialists • Legal expert
• Incident Handlers • PR expert

Key Incident Management Personnel

• Incident response coordinator (IRC)
• Central point of contact for all incidents
• Verifies and logs the incident
• Designated incident handlers (DIHs)
• Senior-level personnel who have crisis management and communication skills, experience, and knowledge to handle an
incident
• Incident response team (IRT)
• Trained team of professionals that provide services through the incident lifecycle
Incident Response Life Cycle
NIST SP 800-61
Preparation
• Preparing to Handle Incidents
• Incident Handler Communications and Facilities
• Incident Analysis Hardware and Software
• Incident Analysis Resources
• Incident Mitigation Software
• Identifying the attack vectors – Removable media, web, email, impersonation, improper usage, loss or theft
• Preventing Incidents
• Conducting Risk Assessments in defined regular intervals
• All hosts should be hardened appropriately using standard configurations and patched.
• The network perimeter should be configured to deny all activity that is not expressly permitted.
• Malware Prevention Software to detect and stop malware should be deployed throughout the
organization.
• Users should be made aware of policies and procedures regarding appropriate use of networks, systems,
and applications. Applicable lessons learned from previous incidents should also be shared with users
Detection and Analysis
• Incident Detection
• Alerts
• Logs
• Publicly available information
• People
• Incident Analysis
• Incident Documentation
• Incident Prioritization
• Incident Notification
Containment, Eradication, and Recovery
• Choose a containment strategy
• Potential damage to and theft of resources
• Need for evidence preservation
• Service availability (e.g., network connectivity, services provided to external
parties)
• Time and resources needed to implement the strategy
• Effectiveness of the strategy (e.g., partial containment, full containment)
• Duration of the solution (e.g., emergency workaround to be removed in four
hours, temporary workaround to be removed in two weeks, permanent
solution).
Containment, Eradication, and Recovery
• Evidence Gathering and Handling
• Identifying the Attacking Hosts
• Validating the Attacking Host’s IP Address.
• Researching the Attacking Host through Search Engines
• Using Incident Databases
• Monitoring Possible Attacker Communication Channels
• Eradication and Recovery
Containment
• After an incident has been identified and confirmed, the IMT is activated and information
from the incident handler is shared.
• The team will conduct a detailed assessment and contact the system owner or business
manager of the affected information systems/assets to coordinate further action.
• The action taken in this phase is to limit the exposure.
• Activities in this phase include:
• Activating the incident management/response team to contain the incident
• Notifying appropriate stakeholders affected by the incident – Obtaining agreement on actions taken
that may affect availability of a service or risks of the containment process
• Getting the IT representative and relevant virtual team members involved to implement containment
procedures
• Obtaining and preserving evidence
• Documenting and taking backups of actions from this phase onward
• Controlling and managing communication to the public by the public relations team
Eradication
• When containment measures have been deployed, it is time to determine the root
cause of the incident and eradicate it.
• Eradication can be done in a number of ways: restoring backups to achieve a clean
state of the system, removing the root cause, improving defenses and performing
vulnerability analysis to find further potential damage from the same root cause.
• Activities in this phase include:
• 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
Recovery
• This phase ensures that affected systems or services are restored to a
condition specified in the RPO.
• The time constraint up to this phase is documented in the RTO.
• Activities in this phase include:
• 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
Post-Incident Activity - Lessons Learned
• Exactly what happened, and at what times?
• How well did staff and management perform in dealing with the incident?
• Were the documented procedures followed?
• Were they adequate?
• What information was needed sooner?
• Were any steps or actions taken that might have inhibited the recovery?
• What would the staff and management do differently the next time a similar incident occurs?
• How could information sharing with other organizations have been improved?
• What corrective actions can prevent similar incidents in the future?
• What precursors or indicators should be watched for in the future to detect similar incidents?
• What additional tools or resources are needed to detect, analyze, and mitigate future incidents?
Lessons Learned Benefits
• Learn from mistakes of the flow.

Facilitate the recurrence of positive

• Understand where problems occurred. outcomes (“let’s repeat what went well”)

• Recognize success. Prevent the recurrence of negative

outcomes (“let’s avoid making the same
mistakes”)
• Retain organizational knowledge.

• Reduce future risk.

• Improve future performance.

Security Operations Centers
(SOC)
• A Security Operations Center is a highly
skilled team following defined definitions
and processes to manage threats and reduce
security risk
• Responsible for monitoring and analyzing an
organization’s security posture on an
ongoing basis.
• Goal is to detect, analyze, and respond to
cybersecurity incidents using a combination
of technology solutions and a strong set of
processes.
What is a SOC?
Security Operations Centers (SOC) are designed to:
• protect mission-critical data and assets
• prepare for and respond to cyber emergencies
• help provide continuity and efficient recovery
• fortify the business infrastructure

The SOC’s major responsibilities are:

• Monitor, Analyze, Correlate & Escalate Intrusion Events
• Develop Appropriate Responses; Protect, Detect, Respond
• Conduct Incident Management and Forensic Investigation
• Maintain Security Community Relationships
• Assist in Crisis Operations
 Peop Proc
le ess
Tech
nolo
gy

Triad of Security Operations

People Process Technology

• Formal Training • Preparation • End-points
• On the job • • Net flow
Identification
• Network Monitoring
experience • Containment • Threat Intel
• Vendor specific • Eradication • Forensics
training • Recovery • Incident
• Internal Training • Lessons learnt detection/management
SOC Organization
Organization Of SOC
Tier 1 Tier 2 Tier 3 Tier 4

Analyst Incident Responder SME/Hunter SOC Manager

• Continuously monitors the • Performs deep-dive incident • In-depth knowledge • Manages resources to
alert queue analysis by correlating data network, endpoint, threat include personnel, budget,
from various sources intelligence, forensics & shift scheduling and
• Triages security alerts
malware reverse technology strategy to meet
monitors health of security • Determines if a critical
engineering, Specific SLAs
sensors and endpoints system or data set has been
applications or underlying IT
impact • Communicates with
• Collects data and context infrastructure
management
necessary to initiate Tier 2 • Advises on remediation • Acts as an incident “hunter,”
work provides support for new • Serves as organizational
not waiting for escalated
analytic methods for SPOC for business-critical
incidents
detecting threats incidents
• closely involved in
• Provides overall direction for
developing, tuning &
the SOC and input to the
implementing threat
overall security strategy
detection analytics.
KPIs for SOC

 Mean Time To Detect - MTTD

 Mean Time To Resolve - MTTR
 Number of False Positives
 Incidents Per Analyst
 Percentage of Recurring Incidents
 Number of SLA Breached Incidents
Systems available in SOCs
 SIEM: Security Information and Event Management (SIEM) software centrally collects, stores,
and analyzes logs from perimeter to end user. It monitors for security threats in real time for
quick attack detection, containment, and response with holistic security reporting and
compliance management
 EDR: Endpoint Detection and Response (EDR) is a cybersecurity technology that addresses the
need for continuous monitoring and response to advanced threats. Helps enterprises detect,
investigate and respond to IT security incidents by facilitating active threat hunting
 SOAR: Security Orchestration, Automation and Response is a solution stack of compatible
software programs that allow an organization to collect data about security threats from
multiple sources and respond to low-level security events without human assistance.
 Main functions of SOAR
 Threat & Vulnerability Management
 Security Incident Response
 Security Operations Automation