SEC 211

Incident
Response
”Oh no, we’ve been hacked!
Now what do we do?”
Why?
Typical incident response
process
1. Oh no, we got hacked!
2. Look for the easy solution
3. Failing that, observe the damage for a time
4. 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
Minimize
Incidents
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
Detection Reaction

IT budget
Risk assessment
High

Yes!
We worry!

Ri
Risk

sk
to
le
ra
nc
What? e
Me worry?

Low High
Asset Value
It’s got to cover all layers

Data
Application
Host
Internal network
Perimeter
Physical security
People, policies, and
process
Sample classification
schemes
Physica Where is the How is access obtained?
l asset?
Public area Available during business hours
Employee-only Card-key readers
Controlled Card-key, PIN, and palm print
Networ Access from How to authenticate?
k where?
Wired corpnet Domain logon (human and PC)
Wireless Domain logon plus certificates
corpnet (human and computer)
Domain logon, smartcard,
VPN quarantine
Kiosks Disallowed
Internet Disallowed except from corp PC
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?
Assemble 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
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
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!
Team roles
Team
Lead

In charge of the team’s activities

Coordinates reviews of team’s actions
Authorized to change policies and procedures
Team roles
Team
Lead

Incident Incident Incident Incident Incident

Handler Handler Handler Handler Handler

Do the actual work

Team roles
Team
Lead

Incident Incident Incident Incident Incident

Handler Handler
Lead Handler Handler Handler

Owns a particular incident

Coordinates all communication about the incident
Represents entire CSIRT to those outside
Might vary, depending on incident particulars
Team roles
Team
Lead

Incident Incident Incident Incident Incident

Handler Handler Handler Handler Handler

Associate Associate Associate Associate

Member Member Member Member

From various departments throughout your company

Specialize in areas affected by security incidents
Participate in incidents or delegate to another in
Associate members
IT contact Coordinates communications between incident
lead and rest of IT department
Legal Lawyer familiar with incident response policies;
representati determines how to proceed. Involved before
ve incidents, evaluates response policies to ensure
you aren’t at legal risk during containment
If we shut down, do we violate service agreements?
If we don’t shut down, are we liable if someone else
gets attacked from the compromised system?
PR officer Crafts message for the public and handles all
media inquiries
Managemen Either departmental or company-wide; determines
t total impact (financial and otherwise) to the
company; directs communications officer and
interaction with law enforcement agencies
Response roles
Legal
Inc. lead IT contact repr. PR officer Mgmt.
Initial assessment Owns Advises
Initial response Owns Implemen Updates Updates Update
ts s
Collects forensic Implemen Advises Owns
evidence ts
Implements Owns Implemen Updates Updates Advise
temporary fix ts s
Sends Advises Advises Advises Implemen Owns
communication ts
Checks with law Updates Updates Implemen Updates Owns
enforcement ts
Implements Owns Implemen Updates Updates Update
permanent fix ts s
Determines Updates Updates Advises Updates Owns
business impact
Define an Incident
Response Plan
Where does this fit?

Prevention Detection
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
Test this process regularly!
Review
It’s the only the response
way you and
can be sure thatupdate policies
it will work when the time
Not purely sequential
Throughout Documentation
incident Communication
In conjunction Initial assessment + damage
containment
Some 1.Identify type and severity
sequence 2.Contain damage and minimize risk
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—
1.Protect human life and peoples’ safety
2.Protect classified and sensitive data
3.Protect other data (proprietary, scientific,
managerial)
4.Protect hardware and software
5.Minimize disruption of computing resources
The goal: get back online as soon as
possible
while protecting people and preserving
that 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
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?
More Information
Learn more
Handbook for Computer Security
Incident Response Teams
by Moira J. West Brown, et al
http://www.sei.cmu.edu/publications/
documents/03.reports/03hb002.html
Forum of Incident Response and
Security Teams
http://www.first.org/
 Steve Riley
steve.riley@microsoft.com
http://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.