copyright security-assessment.com 2005 incident handling considerations in approach presented by...

Copyright Security-Assessment.com 2005

Incident HandlingConsiderations in Approach

Presented by Chris Budge and Nick von Dadelszen


Introduction• Not legal advice• Not about computer forensic software

• Is about considerations when responding to an ‘incident’ that may involve staff inappropriate computer activity, and

• Is based on NZ experiences in both the Govt and private sector.


What We Have Seen• Staff ‘stealing’ IP (Client info etc)

• Ex-Staff able to remotely connect

• Overseas entry onto live systems

• Automated intrusions due to AV / Pop-Up activity

• Differences between desktop and laptop security (Static v Mobile)


What We Have Seen• IT Staff involved in incident as well as being

appointed to ‘investigate’

• Badly worded policies for employee release

• Incorrect terminology i.e. ‘objectionable’ (not in a legal sense)

• Errors in 3rd party monitoring software


What We Have Seen• Considerable inappropriate material:

– 25 to 38% of computers viewed held items of interest

– 0.5 to 2.5% suspected ‘objectionable’ pictures

– jpegs, gifs, HTML, mpg, avi etc

– Excessive use of the Internet


Excuses / Defense# 1 It wasn’t me, never seen that ‘picture’

# 2 It was a virus

# 3 It was a pop-up

# 4 I left my computer on when I went to the toilet / lunch, it must have been someone else

# 5 Someone else has my password


It Starts With Planning• Your preparedness:

– Realisation it could happen– The team– Independent v Internal– The equipment– The readiness state– The ‘resource’ bin– When to call for help


Evidential Considerations• Review logging / reporting set ups regularly• Do not ignore potential threats as isolated

incidents• Consider investigation early or at least securing of

potential evidence• Never assume ‘this is going nowhere’• Be prepared


Evidential Considerations• Identify and secure digital assets involved• If ‘live’ assets, secure on-line or secure off-line to

removable media• Secured logs etc, if so:

– Do before opening them– Make sure use original dates on CD/DVD burn– Original notes (even on a scrap of paper)


Digital Evidence• Is delicate. Is easily altered, damaged or

destroyed by improper handling.

• Any attempt to access data or run a computer program can jeopardise the integrity of the evidence.

• Digital evidence, like all other evidence, must be handled carefully and in a manner that protects its evidential integrity.


Locating the Evidence


Evidential Considerations• DO NOT WRITE TO THE HDD (Exhibit)

• Lots of notes

• Who has access/used the computers

• Confirm they (computers) are all there, if not, where are they ?

• Ask about passwords, consider encryption


The Challenges• Investigative environment is changing rapidly• Technology poses old and new threats• Demanding stakeholders• Financial pressures• Covert activities• Privilege claims• Standards (What is inappropriate)


Job Difficulties• Not being told the ‘whole’ story (Trust your investigation/audit team)

• Standard changes further ’up the chain’

• Disapproving Managers (After CEO direction)

• IT Know-it-all’s

• Financial – not all evidence reviewed


Forensic Case Study 1 of 4• Civil Matter (Government)• 4 cities, total 25 locations• % of total computers, total 580• 2 long weekends, 1 solid three week period• No offending at start, found as conducted• Media involvement-disgruntled employee


Forensic Case Study 2 of 4• Civil Matter (Private)• 15 cities• Unauthorised release of information• No compulsion by visited entities• Timeframe decided by complainant• Difficult to prepare• Once entered on-site until completed• Weather and commercial activities delay


Forensic Case Study 3 of 4• Civil Matters (Private/Government)• 2 entities, separate similar cases• Senior Management, Line Manager• Suspicious: activity, possible intrusion • Located by logs, not on computer• Dual logon capable, computer at home• Children (Teenagers) use• Security concerns


Case Study 4 of 4• Civil Matter (Government)• 1 location, 1 user• Secure locality• External reports ‘proved’ employee• Computer, logs reviewed• Error by external entity, logs mixed• Employee proven ‘innocent’


Lessons Learned• Need Secure on-site work areas• Do not ‘trust’ anyone outside your team• Do not ‘believe’ all reports received• Forensic copying is better than previewing

(Criminal/Employment proceedings)• Always have the ‘end state’ in mind


Locards Principle“For any two points of contact there

is always a cross-transference of material from one to the other.”

Edmond Locard 1877-1966

Every contact leaves a trace !


How To Survive an Incident(without losing the company or your mind)


Overview• What is an incident• Why it matters• The goals of incident management• The 6 steps

– Preparation– Identification– Containment– Eradication– Recovery– Lessons Learned

• What not to do• Conclusion


What is an Incident?• Computer Security Incident Response

• Denial of Service• Malicious Code• Unauthorised Access• Inappropriate Use

• How we get involved


Why You Should Care About Incidents• Because it is inevitable…

• Direct financial loss• Loss of trust• Legal implications of privacy leaks• Negligence

• The media cares about technology based crime• An incident is a PR nightmare


The Goals of Incident Management• Contain the issue • Find the extent of the issue• Find the source • Control publicity• Avoid legal implications• Prosecute • Avoid a repeat


Incident Response• 6 Steps

– Preparation– Identification– Containment– Eradication– Recovery– Lessons Learned


Preparation

Lets deal with that later….


Identification


Identification• How do I know I have an incident?

– As a general rule, you don’t but…

– Alerts from security systems– Your webpage has been redesigned by a 13 year old– “Funny” things happening on the network– Viruses from unknown sources– Strange network traffic– High volumes of network traffic– Complaints from other companies– Complaints from employees– The front page news


When An Incident Happens• Start logbook• Document all information to date on the event• Assign incident to a handler• Coordinate incident response team

• Determine next steps– Is the incident on-going?– What is the impact on business continuity?– Is full forensic investigation required?– Is external assistance required?– What do legal/HR recommend?


The First 12 Hours – What to Expect• 1400 Admin can’t reboot server, strange messages• 1500 Security department contacted• 1600 Initial investigation can’t explain it, but it is highly

suspicious• 1700 Security-Assessment gets a call• 1800 Arrive on site, create war room, gain

understanding of situation• 1900 Live analysis of server• 1930 Start forensic imaging• 2000 Inform CIO, call emergency incident meeting• 2100 Start gathering logs


The First 12 Hours – What to Expect• 2200 First forensic image completes, start

analysis• 2230 Initial analysis shows signs of an intruder

with considerable access• 2300 Meeting to decide on action plan for next 24

hours• 0000 Seal and lock away evidence • 0030 Get some sleep… it’s going to be a long

week


How to Handle Evidence• General Rule is

– If the machine is off, leave it off– If the machine is on, leave it on, don’t reboot– Unplug the network cable

• Make notes on who has accessed/used the computer

• Ensure that whoever collects the data is qualified

• If you want to prosecute your approach must very different.


Containment


Containment• What can be done to gain a quick understanding

of the extent of the problem?• How far does the compromise go?• What devices does the compromised machine

touch?

• Example 1: Firewall stopped firewalling• Example 2: Hopping through the network


What Can I Turn Off?• Where is the “critical” data stored? Can it be

secured?• Turn off the Internet• Disable services• Segregate the network• Send everyone home


Legal Implications• Could data concerning customers in California

have been leaked?• Could customer credit card data have been

involved?• Could financial records have been tampered with?


What is My Cover Story?• Don’t tell the world until you know what you’re

dealing with

• Incidents grow very fast, what seems small now could become massive.

• When you start looking you will find things you didn’t expect

• Example: Compromise on top of compromise


Eradication


Eradication• Perhaps the most difficult step…

• Determine the Cause• Perform Vulnerability Analysis• Improve Defences• Remove the Cause


Eradication• Kernel level rootkits• Hardware rookits

• Anti-virus is useless• You can’t ‘scan’ for an issue until you can reliably

detect it

• How many boxes do you rebuild from scratch?• When do you stop looking?


Recovery


Recovery

• Rebuilding systems securely

• Restore from backups

• Validate systems

• Monitoring


Preparation

Ostrich Risk Management


Preparation• Incident Response Policy• Incident Response Team• Logging• Monitoring• Training• Incident response tests


Preparation – Incident Response Policy• An incident response policy should contain:

– A list of threats the policy intends to cover– Who has authorisation for certain activities:

• Conduct interviews• Review sensitive data• Conducting communications

– What actions the responder is allowed to take• Taking a system offline• Denying access to intruder• Watch and monitor


Preparation – Incident Response Policy• An incident response policy should contain:

– Who will be on the Incident Response Team

– Who needs to be notified, in what manner and how often

– Which is more important to the business:• System availability• Legal prosecution• Incident recovery


Preparation – Incident Team• Parties who may be included in the incident team:

– Organisational security team– Executive management– Legal– Public relations– IS management– Human resources– CFO, financial auditor


Preparation – Logs• Logs are important

• Log relevant data– Successful logins– Failed login attempts– Use of privileges

• Make sure logs are archived to separate hosts


Preparation – Training• Your staff are the best detection mechanism

available

• Train your administrators – What to look for – How to respond

• Do trial runs

• Use small incidents as a safe training ground for the “big one”


Summary


The “what not to do” Slide• Don’t pretend it doesn’t exist

• Don’t stop investigating an incident because you’re bored of it

• Don’t let your IT “expert” loose

• Don’t hide information from your response team


The “what to do” Slide• Take a day to put together a basic incident

response plan

• Use small incidents as a safe training ground for the “big one”

• Stay calm

• Get help when appropriate


Questions???

[email protected]@security-assessment.com

copyright security-assessment.com 2005 incident handling considerations in approach presented by...

Documents

dadelszen slide

internet slide

encryption slide

prepared slide

password slide

scrap of paper slide

digital evidence

potential evidence