Download
1 / 52
520 likes | 671 Views
SEC 211. Incident Response ”Oh no, we’ve been hacked! Now what do we do?”. Why?. Typical incident response process. Oh no, we got hacked! Look for the easy solution Failing that, observe the damage for a time Update resume and await execution. There’s a better way.
E N D
SEC 211 Incident Response”Oh no, we’ve been hacked!Now what do we do?”
Typical incident response process • Oh no, we got hacked! • Look for the easy solution • Failing that, observe the damage for a time • Update resume and await execution
There’s a better way • Why wait until your first attack? • Affects decision-making • Costs more • Make it part of your security policy and risk mitigation strategy • Real benefits • No panic attacks—process guides response • Financial—discounts from insurance company • Service provider—help win business
Taxonomy of security work Prevention Detection Reaction IT budget
The process • Minimize the number and severity of incidents • Assemble the core computer security incident response team • Define an incident response plan
Know your stuff! • Where are your backups? • Are they good? • What assets are you trying to protect? • What are the threats against them? • What vulnerabilities might the assets have? • How likely are those threats to materialize? • What is “normal” traffic on your network? • How fast should the network typically respond? • Who sends us email? Who should be? • Are your computers protected from theft?
Where does this fit? Prevention Detection Reaction IT budget
Risk assessment High Yes!We worry! Risk Risk tolerance What?Me worry? High Low Asset Value
It’s got to cover all layers People, policies, and process Physical security Data Application Host Internal network Perimeter
Start with the “soft” stuff • Establish, enforce, and measure policies • If you can’t measure it, drop it • A lot of incidents happen “by accident” • Get management support • Begin regular security training • ILOVEYOU! • Most email worms target carbon, not silicon • Think about security banners • That they stop prosecution is an urban legend • But they remind people of their responsibilites
Don’t neglect periodic maintenance • Conduct regular vulnerability assessments • Do it yourself or hire a consultant, your choice • Run away from checklist slaves • Are they bondable? Do you trust them? (the “daughter test”) • Don’t forget to test social engineering • Get permission!
Don’t neglect periodic maintenance • Keep your systems patched and up-to-date • Clients: come on, start using a patch management tool • Servers: your choice, be mindful of reboots
Important technical controls • Strong password policies • Passphrases are better though • Monitor and analyze network traffic and system performance • Learn what “normal” means for you
Important technical controls • Routinely check all logs • But they’re useful only after you’ve already learned “normal” • Verify backups • Do restores actually work? • Is the media still functioning? • Who can perform?
The core CSIRT • These are the people who respond to all incidents • Require responsibility and authority • Clearly-defined duties: eliminates “not my job!” • Who pulls the LAN cable? Under what conditions? • Build this before you get attacked • Make it part of their regular job description • Include in job performance goals • Give them periodic drills for practice
Successful teams • Monitor for security breaches • Act as “communications central” • Receive reports of incidents • Disseminate information about incidents • Document incidents • Promote security awareness inside the company • Support system and network auditing • Vulnerability assessments, penetration testing • Remain abreast of new vulnerabilities and attacks • Research software patches • Analyze and implement new processes and technologies for reducing vulnerabilities and risk
Team preparation • Train to use good tools • Where are they? • How to use them? • Rapidly available—specialized laptops used only for this • Be sure to protect them when not in use!
Team preparation • Train to use good tools • Assemble all relevant communication info • Contact names and numbers • CSIRT team • Admins and owners • Legal • Public/media relations • ISP • Law enforcement • Involve legal in any dealings with law enforcement and when gathering evidence
Team preparation • Train to use good tools • Assemble all relevant communication info • Keep emergency info in central offline storage • Passwords • IP addresses • Router configurations • Firewall rulesets • Certification authority keys • Contact names and numbers • Escalation procedures • If electronic, encrypt it then lock it up!
In charge of the team’s activities Coordinates reviews of team’s actions Authorized to change policies and procedures Team roles TeamLead
Do the actual work Team roles TeamLead IncidentHandler IncidentHandler IncidentHandler IncidentHandler IncidentHandler
Owns a particular incident Coordinates all communication about the incident Represents entire CSIRT to those outside Might vary, depending on incident particulars Team roles TeamLead IncidentHandler IncidentHandler IncidentLead IncidentHandler IncidentHandler IncidentHandler
From various departments throughout your company Specialize in areas affected by security incidents Participate in incidents or delegate to another in their area Team roles TeamLead IncidentHandler IncidentHandler IncidentHandler IncidentHandler IncidentHandler AssociateMember AssociateMember AssociateMember AssociateMember
Where does this fit? Prevention Detection Reaction IT budget
Incident response is not… • Panic • Paranoia • Frustration • Giving up
Plan components • Make an initial assessment • Communicate the incident • Contain the damage and minimize the risk • Identify the type and severity of the compromise • Protect evidence • Notify external agencies (if appropriate) • Recover systems • Compile and organize incident documentation • Assess incident damage and cost • Review the response and update policies Test this process regularly!It’s the only way you can be sure that it will work when the time comes
Make an initial assessment • Is it really a bad guy? • An admin doing his/her job might appear malicious • Is it a configuration problem? • Causing the IDS to report too many false positives • Start trying to determine type and severity • Get enough info for further study and communication • How will you contain it? • Record everything you do • Not acting on a real incident is worse than acting on a false positive, but don’t take too much time to figure it out
Communicate the incident • If it’s real then communicate to entire CSIRT • Identify an incident lead and appoint handling team members • Determine who outside CSIRT to contact • Maintains coordination • Minimizes damage • Headline in newspaper could be more damaging… • Don’t want to tip off the attacker
Contain the damage • Acting quickly and decisively can make the difference between a minor attack and a major one • Helpful priorities— • Protect human life and peoples’ safety • Protect classified and sensitive data • Protect other data (proprietary, scientific, managerial) • Protect hardware and software • Minimize disruption of computing resources The goal: get back online as soon as possiblewhile protecting people and preservingthat which keeps us in business
Contain the damage • Don’t let the bad guy know you’re on to him • A wholesale password change, while necessary, will also be a give-away • Do you unplug or not? • Compare cost of yes or no • Will you violate an SLA? Which is more expensive? • Next time: incorporate such decision into the SLA itself • Disable bad guy’s ingress point • Modem…firewall rule…physical entry • Rebuild new system with new hard drives • Lock up existing ones to preserve forensic evidence • Change passwords, especially administrative
Determine nature of the attack • Might be different from initial assessment • What’s the origin? • What’s the intent— • Are we a specific target? • Just a random victim? • Why us? (information, bandwidth, …) • Which systems are compromised? • Which files have been accessed? How sensitive are they? • Helps direct how you will recover • Incident response plan should guide your responses as you learn more about the attack
Determine severity of the attack • Work with other CSIRT members • Do they agree with your assessment? • Any unauthorized physical access? • Any unauthorized hardware suddenly appearing? • Any new, unexpected members in admin groups? • Any new startup programs? • Any gaps in logs? Or completely missing? Anything else weird in them? • Unexpected or unusual access failures or successes • Strange times (nonworking hours) • Permissions changes or elevations • What’s different now compared to previous integrity check? • Any non-business data? (porn, music, warez) • Any employee data now in a bad place? • You might have to deal with privacy issues now • Any change in performance?
Comparing against a baseline • Best way to know what’s changed • Works only if you know your previously-recorded baseline hasn’t already been compromised • My favorite tool: TripWire • Others • EventCombMT • DumpEL • Microsoft Operations Manager
Collect and protect evidence • Prosecution should be the least of your worries… but make backups anyway • Make two bit-for-bit backups • First: on write-once media (DVD±R) • Use in case you decide to prosecute; keep physically secure • Second: on brand-new hard drive • Use for data recovery • Document everything you do with them • Physically secure original compromised disks • Will become evidence if you prosecute • Rebuild system with new drives
Collect and protect evidence • There’s always that trade-off • Does the cost of preserving data outweigh the cost of delaying response and recovery? • Is rapid recovery the most important thing for you? • Comprehensive backups might be impossible for very large systems • Limit to system state, logs, breached portions of systems • If you can figure it out!
Document document document! • If you do prosecute, questions about your evidence will arise • Every jurisdiction has its own requirements for acceptable evidence • Maintain detailed and complete documentation • Who…did what…when…and how • Sign and date every page
Notify external agencies • Potential agencies— • Local and national law enforcement (especially if loss is financial) • External security agencies (their experience is helpful) • Malware experts • Coordinate with your legal representative • What kind of public notification? • Depends on your industry • Depends on whether customers were affected
Media attention • If you’re a high-profile company, expect attention! • Rarely desirable, often unavoidable • Incident response plan describes— • Who’s allowed to interact • What they’re allowed to say • Whether you notify media or wait for their call • Speaking of notification… • Consider how to spin it to your advantage • Being honest, showing how you’re improving could actually win customers • Don’t lie about it, of course—reputation damage
Compile and organize documentation • What was the attack? • How did we respond? • Who • When • Why • Organize, sign, then review with management and legal representative • Consider dual sign-offs…increases likelihood of evidence acceptance • All this absolutely critical if you suspect an insider
Assess damage and cost • Direct and indirect costs • Loss of competitive edge (because of release of confidential information) • Legal costs • Labor costs—incident analysis and recovery • Downtime costs • Lost productivity • Lost sales • Replaced hardware, software, other property • Costs of updating physical security • Consequential damages—reputation, trust
Review and update • After you’ve cleaned it all up, review your response • What went well? • What needs improvement? • How will we get better next time? • Update policies • Can we make them better? • Opportunities to streamline? • Anything we need to strengthen? • Consider new technologies • Can we improve our prevention mechanisms?
