Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 58

Incident Response

and Risk
Management

CISC 6920

James Doyle

March 15, 2020


New Reality

• We will be meeting virtually


• Will everyone be able to do the Labs?
– If not, I will change the grading and eliminate
the Lab Practical. We will discuss tonight.
– Labs will be more demo, hopefully we will be
back in classes in April.
Remaining Schedule

Mar 15, 2020 Log Analysis, Timeline Analysis IRCF 8,9,10 Submit Gap Analysis on Apr
Incident Triage Scenario Distributed 4- Will Select some for
Lab- Tor/Grey & Dark Web Present
Student Presentations

Apr 5, 2020 Incident Response LM- Cyber Kill Chain Submit Scenario PPT-
Lab Axiom, Cloud FINAL NEXT CLASS
Student Presentations

Apr 26, 2020 Final Class- Conclude on materials and Submit Practical
labs.
FINAL IN CLASS
Student Presentations
Where are we?
• We have Finished Harkins, “MRIS”
• For IRCF, You should have finished up to Chapter 10.
We will not do further readings from this text.
• Should have read- All on Blackboard:
– NIST 800-61,r2. & 800-53 r4
– SANS Articles: “IR Team”
– SANS Article: IR Investigation
– SANS Article Creating & Managing IR team
– SANS Incident Handlers Handbook
– IBM 2019 Cost of Breach
– Deloitte Cost of Breach
– Verizon 2019 DBIR (2020 not released yet)
– For Next Class: LM Cyber Kill Chain
Today’s Agenda
• Scenario Distribution
• Lecture on Chapters from IRCF
• Tor Demo- Practice at home
• Discuss write blockers
https://www.bing.com/videos/search?q=tableau+writeblockers&&view=detail&mid=EE4963F2D7FE9CE2F577EE4963F2D7FE
9CE2F577&&FORM=VRDGAR&ru=%2Fvideos%2Fsearch%3Fq%3Dtableau%2Bwriteblockers%26qpvt%3Dtableau%2Bwrite
blockers%26FORM%3DVDRE

• Discuss Lab Practical


Scenario’s

• Review the scenario assigned (They are


on BB)- Individual Assignment
• Prepare a timeline of the incident in
PowerPoint-see following Slide
• Prepare a PowerPoint explaining steps
you would have taken to respond to the
incident, using the incident lifecycle as a
guide and conclude with the Lessons
Learned Phase
Scenario Assignments
Name Group Scenario
Ekpe-Antoniou, Danielli 1 1
Garrett, Daniel R. 1 2
Medina, Frandy 1 3
Rohr, Thomas J. 1 4
Badilla, Nicholas 2 5
Israels, Peter C. 2 4
Karimov, Ruslan 2 3
Macarayo, Rojie 2 2
Brewster, Noor A. 2 1
Marku, Angjelo 3 1
Mucerino, Meghan R. 3 2
Tsering, Tenzing 3 3
van der Linde, Ileana 3 4
Kaul, Kevin 3 5
Kotsis, Alexios I. 4 5
Lamb, Michelle 4 4
Neuman, Joshua 4 3
Schoenberg, Daniel F. 4 2
Baig, Adiyah 4 1
Furman, Michael 5 1
Khan, Zohaib 5 2
Miller, Dornell A. 5 3
Villacis, Dylan W. 5 5
Diallo, Alpha O. 6 1
Easy, Daneian 6 3
Spence, Sheldon A. 6 4
Williams, Sonya R. 6 5
Chapter 4
Incident Response Process

During the Incident Response handling, there are a consistent set of activities for gathering
information, coordinating activities, assessing results and communicating to involved or affected
parties. The following phases are utilized:
Alert & Eradicate &
Triage Contain Recover Report Closure
Scope Mitigate

Phase Description
Alert & Scope • Confirm receipt of a potential cyber incident, determine whether it is a cyber incident, determine its severity,
assign to a Primary Incident Responder and if needed, engage Subject Matter Experts (SMEs) or create a
Security Incident Response Team (SIRT)

Investigate • Determine extent of compromise; if the incident involves a data breach, then the Legal and/or the Chief
Privacy Officer will direct actions based on the privacy plan

Contain • Limit the spread of compromise

Eradicate/Mitigate • Remove artifacts of compromise and prevent future compromise

Recover • Return assets to operational-ready state

Report • Document the incident; make required notifications in the case of a data breach to relevant parties including
affected person(s), regulatory and governmental agencies, and law enforcement as needed

Lesson Learned • Improve future security posture by learning from previous experiences

Please note that the above 7 phases are based off the NIST SP800-61r2
publication
Incident Response Process
(Corporate Security Incident Response Team)

- Notify client
- Notify
regulators
- - Detect Incident
Remediate
- Analyze long Resolution & - Identify source of
Detection identified
term effects Reporting
- - Log incident
Analyze
- Reduce false
lessons
learned positive

- Determine scope
- Assemble Response

Digital
Cyber Incident Assessment -
Team
Collect & sort facts
Forensics Analysis Response Process (Initial response)

- Engage digital
forensics process -
- Determine
Collect evidence
- scope
Engage 3rd party Analysis -
Containment Assemble
(investigate incident) Response
- Team
Technology - Collect &
containment
- sort facts
Process
containment
- Procedure
containment
Collecting the facts
• The initial facts about an event are all an investigation has
to get started—so it’s a good idea to get them right.
• It’s also important to gather additional information about
those facts so you can establish context
• Also, a time that an event occurred is less useful if you
don’t know the corresponding time zone.
• Without that context, it’s easy to jump to the wrong
conclusions about what an event means.
• Investigation communication must be conducted out of
band
– Investigation integrity
– Privacy concerns
Time and Data Types

• Using UTC time when configuring or


displaying time in your forensics
environment
• Especially today- Nov 4 2018
• Type of data you are collecting and
looking at has to be organized in
– Transactional Data- Meta Data
– Referential Data- Circumstantial
– Enriching Data – Interview. rtc
Detection Summary Checklist
Triaging an Incident

• Incident Summary
– Date and time incident was reported
– Date and time incident was detected
– Reported severity based on certain variables
• Contact information of the person
documenting this information.
• Contact information of the person who
reported and who detected the incident
• Nature of the incident and its type (i.e.
malware, internal compromise etc..)
– Select a common taxonomy for incident
reporting
Detection Summary Checklist
Triaging an Incident

• Type of affected resources


• Summary of how the incident was detected
• Provide a unique identifier of the asset on
which the incident was detected
• Who accessed the system last
• Who has the logs
• Who are the parties aware of the incident
– Who else is still investigating
• What is the classification of the incident
What is the SEVERITY of the
incident
Detailed Detection Checklist
Triaging an Incident

• What are the sensors that discovered and


reported the incident
– Human: How reliable are human past detection
– Automated: Validate detection error rate
• Use Healthy skepticism
• Get your hands on raw data
• Validate source of data for accuracy and integrity
• Be very careful about the chain of custody of the
data
• Validate detection
• Store data in a safe location
– Network
– Local Storage
System Details
Triaging an Incident

• Physical location Include information so that


someone outside of your organization would
be able to clearly determine where a system
is physically located—for example, the full
address, building number, floor, room
number, or rack number.
• The asset tag number or serial number of the
system
• The operating system installed and its version
• Purpose of the system and its classification
• The system admin as well as the business
owner
System Details
Triaging an Incident

• The assigned IP addresses


• The system’s host name and domain
• The critical information stored on the system
• Whether backups exist for the system
• Whether the system is still connected to the
network
• A list of malware detected, from the time of your
investigation back to the beginning of log data
• A list of any remediation steps that have been
taken
• If any data is being preserved, what process is
being used and where it is being stored
Network Details
Triaging an Incident

• A list of all external malicious IP


addresses or domain names involved
• Whether network monitoring is being
conducted
• A list of any remediation steps that have
been taken
• If any data is being preserved, what
process is being used and where it is
being stored
• Updates to network diagrams and
configurations
Malware Details
Triaging an Incident

• The date and time of detection.


• How the malware was detected.
• The list of systems where the malware was found.
• The name of the malicious file, and what directory was it
present in.
• What the detection mechanism determined, such as the
name and family of the malicious file.
• If the malware is active during the IR and if active network
connections are present.
• Whether a copy of the malware is preserved, either manually
or through a quarantine process.
• The status of any analysis. Has the malware been analyzed
for network and host 120 indicators of compromise?
• Whether the malware was submitted to third parties, either
through automated processes or via direct action by an
employee.
Determining Severity

• Severity is the factor of Impact and


Likelihood of event
– Base it on the checklists
– Extract important variables
– A hybrid of art and science
(qualitative/quantitative)
Summary
• A major challenge at the start of every
investigation is separating fact from fiction and
setting the initial priorities.
• To ensure that information is flowing to and
among investigators good communication,
documentation, and reasoning skills are essential
• These will help ensure that information flowing to
and among investigators, management, legal
staff, and other decision-makers is as accurate as
possible.
• Using checklists, like the ones we’ve outlined in
this chapter, will help to ensure you don’t forget
something critical in the frantic early stages of a
possible incident.
Chap 5 IR&CF
Defining Leads of Value

• The lead must be relevant.


• The lead must be actionable.
• The lead must have sufficient detail
• For each lead
– Clarify the data.
– Verify the veracity of the lead.
– Determine the context of the lead.
Supporting Leads
Collect more data

• When a potential lead is validated


– gather additional data that will support the
lead.
– For example, if a network intrusion
detection device alert was generated that
stated a connection was made to a known
command-and-control server,
– identifying the internal origin of the
connection
– inspecting the raw logs
– and searching records of other
connections made by that host
Supporting Leads
Verification

• What is the false positive rate


• Is the lead complete
– To determine the veracity, you need to
understand the observables used to
generate the lead and understand the
process used by the generator
• Determine context of the lead
– Human factors
– Automated mis-configuration
Acting on Leads
Turning Leads into Indicators

• Most of the leads that IR teams generate


consist of detectable characteristics of
malicious actions
• Property based indicators
– Describes a set of known observable
characteristics of malicious software or actions
—a registry key, an MD5 hash for example.
• Methodology-based or anomaly based
indicators
– Are less specific, where a combination of
characteristics can define a malicious or
suspicious act—unexpected executable files in
the /Windows/Help directory, for example
Host Based Indicators of Compromise (IOC)

Building IOC that will give


a story of what happened

DNS calls
File size

Portable
Executable
(DLL)
Compilation
Check for time stamp
matching
MD5
Network IOC

• You are attempting to make a rapid


determination of whether a particular
session is relevant to your investigation.
• The properties and attributes you choose
are dependent on the capabilities of the
monitoring system you have in place
• Some indicators may have a limited
lifespan due to changes an attacker can
make in their tools or procedures
Human Based Leads

• There are no PERL scripts or automated


agents on the market that will help in
these situations.
• As an IR team, you may need to perform
interviews and gather witness accounts of
incidents
• Common sense techniques can be used
to interview people
Human Based Leads

• Thoroughly document any statement


• Allow the interviewee to tell a story
• Avoid leading questions and those that
lead to yes/no answers
• Collect the facts before allowing the
interviewee to give opinion
• Know when to get others involved
External Leads
• Private organizations cannot serve grand jury
subpoenas, or subpoenas, they must rely on
one of the following methods:
– File “John Doe” lawsuits and subpoena the
provider or organization that possesses the
records for the source address or e-mail.
– Rely on pre-litigation discovery mechanisms.
Depending on the state, these options may not be
available.
– If the issue involves copyright infringement, the
Digital Millennium Copyright Act provides for
pretrial identification subpoenas.
– Report the incident to law enforcement agents
and hope that they will investigate and prosecute
criminally.
Reporting an Incident to Law Enforcement

• you may want to report the incident to law


enforcement instead of taking action
through civil litigation
• Many organizations do not want to report
simply to avoid public leakage
• When leads point to foreign entities, such
as ISPs or hosting sites, the process to
obtain information can get quite
complicated.
• In most situations, foreign governments
require civil requests be filed through
official channels.
In Summary
• Indicators are only as strong as the tool you use to search
with.
– One tool may give great insight into user-land data, whereas
another may be better when you’re examining actions
performed by the kernel.
– Learn the constraints of every tool you use. Test your tools.
– We don’t rely on our own tools alone, and you should be
suspicious of anyone who does.
• Test and validate indicators before deployment.
– Validate and monitor the effectiveness of the indicators while
they are in production.
– Test against your baseline operating systems as well as known-
compromised systems.
• Work alongside legal counsel during investigations,
particularly when leads begin to resolve to external entities.
Additional Informational
Material

Several leading practices, standards and guidelines exist in the industry. Below are a number of additional
information sources for consideration:

• NIST: Computer Security Incident Handling Guide


• http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

NIST: Guide to Integrating Forensic Techniques into Incident Response


• http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

SANS: Incident Handler’s Handbook


• http://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901

Microsoft: Responding to IT Security Incidents


• http://technet.microsoft.com/en-us/library/cc700825.aspx#XSLTsection125121120120

ITC: Cyber Security Incident Response Plan


• https://www.efis.psc.mo.gov/mpsc/commoncomponents/viewdocument.asp?DocId=935724411

Carnegie Mellon University: Action List for Developing a CSIRT


• http://www.cert.org/incident-management/csirt-development/action-list.cfm?
• Chris to give ENISA
Incident Response
and Risk
Management

CISC 6920

James Doyle
Skill Sets Required for Incident Response

• Ability to utilize forensic software to


collect, preserve and analyze evidence
• Hard drives
• Network drives
• USB
• Cell Phone
• Cloud
• Logs
• Email stores
Evidence Integrity

• Be able to maintain and demonstrate


evidence inventory controls
• Chain of custody
• Evidence storage and range of access
• Physical security
To Respond you need to:

• Reconnaissance on own network


• Public information sources
– Linked in, Google
– Wayback machine
• Know your business, have contacts when
you need to determine importance of files
Detection

• Respond to alerts from devices to


commence an investigation-
– Access to alerts, contacts in DLP, SIEM
etc.
– Interview individuals forwarding alerts
– Take detailed notes moving forward
– NEOTWY:
• When
• Where
• Who
• What
• How
• Why
Communicate

• Establish your points of contact


– Have bridge numbers established
– Create call lists
Access to investigate

• Ability to remotely or physically connect to


any device
• Authority & Ability to take machines off the
network
• Authority & Ability to physically take
control of any device
• Authority & Ability to obtain credentials,
decryption tokens
• Authority & Ability to create, update delete
permissions or access
Access to workstation

• Ability to search, delete/kill files, processes


• Ability to implement and run scripts/agents
• Ability to target and search for IOC
• Ability to acquire, analyze, targeted collection of
files
• Ability to patch
Access to servers

• Access web-proxy cache


• Perform vulnerability scans
• Ability to remotely access and analyze
• Apply patches
Access to Network

• Access to netflows for analysis


• Ability to use tools to analyze (Wireshark)
• Ability to detect wireless abuse
• Ability to have baseline reports
• Network Diagram
• Ability to scan for vulnerabilities
• Rights to run certain internal commands
(ping, telnet)
• Ability to stop certain protocols(IMCP
during ping sweep)
Access to Logs

• Ability to analyze centrally collected logs


(Splunk)
• Ability to extract logs from Web, email,
system, endpoint protection logs (UNIX
scripting, Vi)
• Other logs: badge access, application
logs, guest wifi, phone, skype.
Access to Email

• Ability to access and export email stores


• Ability to analyze with forensic tools
• Ability to block/redirect emails
Backup

• Ability to retrieve
The LAW

• Know Global Data Protection Polices


Log Collection

• Identify Sources
• Identify parameters (volume, days kept,
time stamps)
• Consider integrity by hashing original
files. Acquire and preserve, work off a
copy.
• Normalize the logs- UTC to current
location, or location target was in.
• Filter and analyze- sometimes Excel is
your filtering tool.
Logs as Evidence

• Protect during collection to maintain


integrity
– repeatable, document scripts used
• When transporting, encrypt and verify
hashes
• Make sure you use an examiner
workstation that is safe, patched
• Logs are evidence and should be stored
with case
• Document any resultant reports from the
log data
Windows/Active Directory

• Information in Logs:
– System Events
– Audit records
– Application Events
– Command History
– User activity
• Possible correlations:
– Username
– IP address
– Port
– Hostname
Other Logs

• Unix/Linux
• Firewall
– Connection attempts
– Failed connections
– Audit events
– IP address
– Network
– Connection type (tcp, http, etc)
– Ports accessed or attempted
Router Logs

• Audit log
• Connection log
• Connection size
• NAT information
• IP
• Host
• Port
• Network
HTTP or Proxy Logs

• User Activity
• Websites visited
• User agent (browser)
• IP address
• Hostname
• IP address
VPN logs

• Username
• IP Address
DNS logs

• User activity
Investigating Logs Methods

• Splunk- automated or scripted


• Heuristic Detection
– Uses baselines to detect anomalies
– One of these things is not like the other
• User Behavior analytics
– Anomalies, but use initiated
• Attempting to access network location
• Trying to increase permissions
• USB copying
• Uploading to cloud
• Emails to personal emails
Other Investigative Areas

• Known malicious patterns


– DNS inquiries to known bad domains
– Antivirus alerts
– IDS alerts
• Malicious code patterns
– Malware activity
– Strange IP addresses and activity
– Unusual processes running
– Unknown application installed
– Unscheduled reboots
– New files installed

You might also like