incident response oh no we ve been hacked now what do we do n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Incident Response ”Oh no, we’ve been hacked! Now what do we do?” PowerPoint Presentation
Download Presentation
Incident Response ”Oh no, we’ve been hacked! Now what do we do?”

Loading in 2 Seconds...

play fullscreen
1 / 52

Incident Response ”Oh no, we’ve been hacked! Now what do we do?” - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Incident Response ”Oh no, we’ve been hacked! Now what do we do?”' - dean


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
typical incident response process
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
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
Taxonomy of security work

Prevention

Detection

Reaction

IT budget

the process
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
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
Where does this fit?

Prevention

Detection

Reaction

IT budget

risk assessment
Risk assessment

High

Yes!We worry!

Risk

Risk tolerance

What?Me worry?

High

Low

Asset Value

it s got to cover all layers
It’s got to cover all layers

People, policies, and process

Physical security

Data

Application

Host

Internal network

Perimeter

start with the soft stuff
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
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 maintenance1
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
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 controls1
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
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
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
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 preparation1
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 preparation2
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!
team roles
In charge of the team’s activities

Coordinates reviews of team’s actions

Authorized to change policies and procedures

Team roles

TeamLead

team roles1
Do the actual workTeam roles

TeamLead

IncidentHandler

IncidentHandler

IncidentHandler

IncidentHandler

IncidentHandler

team roles2
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

team roles3
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 fit1
Where does this fit?

Prevention

Detection

Reaction

IT budget

incident response is not
Incident response is not…
  • Panic
  • Paranoia
  • Frustration
  • Giving up
plan components
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
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
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
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 damage1
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
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
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
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
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 evidence1
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
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
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
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
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
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
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?
slide52

Steve Riley

steve.riley@microsoft.comhttp://blogs.technet.com/steriley

© 2006 Microsoft Corporation. All rights reserved.

This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.