Incident response and intrusion detection Eli mattrick and gus pessolano

Define incident Incident: “a violation or threat of violation of computer security policies, acceptable use policies, or standard security practices” – NIST SP 800-61 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

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

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

IR Handling Phases Preparation Identification Containment Eradication Recovery Lessons learned

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

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

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

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

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

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

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

Data collection – IR techniques Professor Messer

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.

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– www.equifaxsecurity2017.com . Why not just use the official domain? Their social media account then proceeded to tweet out the WRONG website, at least THREE times.

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

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

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

Questions, comments, concerns?