1. Incident response and intrusion detection
Eli mattrick and gus pessolano

2. Define incident
Incident: “a violation or threat of violation of computer security policies, acceptable use policies, or standard security practices” – NIST SP
Should not have an overly broad definition of incident, but it also should not be overly concise
The definition of an incident will vary from organization to organization

3. Define incident response
An organized approach to addressing and managing the aftermath of incidents.

4. Goals of IR Mitigate damage done
Reduce recovery time (business continuity)
Minimize financial loss
Verify incidents occurred
Determine how the incident happened
Prevent future attacks and improve security

5. IR Handling Phases Preparation Identification Containment Eradication
Recovery
Lessons learned

6. Preparation Readiness to handle an incident at a moments notice
Policies
Rules/guidelines
Must have clear policies
This will help define what is classified as an incident
Legal reinforcement
Response Strategy
Classify levels of severity
Communication
Documentation – Who? What? When? Where? Why? How?
Team, Tools, Training
Testing

7. Identification Incident is detected
What is the scope of the incident? Severity?
Communication is critical
Gather events/logs from systems (IDS, Firewalls, etc)
Start documentation

8. Containment Limit damage and prevent further damage
The faster the response, the more likely you can minimize damage done
Short-term
Isolate the infection – limit damage asap
Back-up
Take forensic images of affected systems (Preserve the evidence)
Long-term
Remove accounts/backdoors left by attackers.
Install security patches
Anything else to prevent escalation, as long as business operations continue

9. eradication Complete removal of malicious content
Usually done by reimaging affected systems
Harden systems (security patches, unused services)
Double-check everything

10. Recovery Putting the previously affected systems back into production
Test the system
Make sure everything is in working order
Monitor the system
Watch for any abnormal activity as the system is reinstated
Validate
Assure that the system isn’t being reinfected with malware, or compromised by other means
Purpose is to make sure the incident has been resolved, and there is no lingering threat waiting to reinfect the systems

11. Lessons Learned Review the incident step by step
What went well during the response? What didn’t?
Were there preexisting procedures in place for responding to this type of incident?
Scope of the incident?
This is the time for discussion on how to improve the IR process

12. Playbooks
Predefined policies and procedures on how to handle a certain type of incident (phishing, malware, etc)
Playbook Resource

13. Data collection – IR techniques
Professor Messer

14. Case Study #1 - Equifax How…Why? Poor security posture Timeline
‘admin’ – ‘admin’
Apache Struts vulnerability– ‘took efforts to identify and to patch any vulnerable systems in the company's IT infrastructure’
Timeline
July 29th – InfoSec team first notices suspicious traffic
August 1s & 2nd – Equifax execs sell $2 million in company stock, but apparently did not know anything about the breach (right…). At this point the breach was still not disclosed.
August 2nd -- Mandiant is hired. The investigation showed attackers had access to sensitive data starting on May 13th.
Mandiant indicated there was an additional breach in March, likely by the same attackers, but Equifax denied knowledge of this.

15. Equifax cont. Equifax’s IR / Intrusion Detected
No clear policies/procedures are apparent.
Why did the InfoSec team only notice the suspicious traffic, almost 7 weeks after it began? They also did not notice the breach in March?
Created a SEPARATE DOMAIN for customers to check whether they had been affected– . Why not just use the official domain?
Their social media account then proceeded to tweet out the WRONG website, at least THREE times.

16. Case Study #2 – Eli’s internship - Phishing
Preparation – Users know to send suspected phishing s to Abuse Mailbox. InfoSec team has a phishing playbook for investigation procedures.
Identification – User suspects an of being a phish, and sends it to the Abuse Mailbox. Analyst confirms or denies whether it is a phishing . Checks for attachments.
Containment – Block the sending address, or any links within the . Remove from affected person(s) mailbox. Transfers attachments to malware analysis lab.
Eradication – Malware analysis. Find Indicators of Compromise (IoC). Block any IoC found. users to make sure they did not open attachments/links.
Recovery – Monitor Abuse Mailbox for any similar reports.
Lessons Learned – Review documentation / write up

17. Case Study #2 Cont. An IoC from this case: 185.165.29.78
Petya/NotPetya ransomware

18. https://www.youtube.com/watch?v=GhuJFuzgj- k
Handling a breach k

19. Questions, comments, concerns?