Security - Incident Response

1. Outline for Incident Response - Introduction

First let me state the major themes. Each of these themes will appear as a regular cast of characters and help to orient our reader. The major themes are "before and after", "one size does not fit all", and "internal versus external threats". While many other topics may be touched upon, this talk will only deal with them in light of the major themes just announced.

2. A Security Policy

	
	2.1. 	Four types of industries
	
	2.1.1.  Financial, health, and banking
		These types of companies must deal with the public as a 
		source of revenue and therefore remain open and 
		accessible, albeit in limited ways.

	2.1.2. 	Internet Service Providers
		These companies must maintain broad connections to the 
		Internet.  Additionally, they must regard their client 
		base as hostile.

	2.1.3. 	Law and Architecture Firms 
		These types of companies maintain only limited and 
		mostly nonessential connections to the Internet.  
		Furthermore, their internal personnel are more 
		likely to be trusted.  

	2.1.4. 	Government and Military
		The government and military are only marginally 
		dependent on the Internet and withdraw into private 
		networks as needed.  Beyond this, they have their 
		own police forces and security measures.
	
	2.2. 	Analyze your security posture.
	
	2.3. 	What a security policy should do
		A security policy should help guide you to a sane 
		level of risk management.  
		o It should be sized to your organization and resources
		o It should help you budget resources
		o It might help you plan for the future
		o It should be made available

	2.4. 	What a security policy should not do
		o It should not be used to hang the CIO or systems 
		   administrator
		o It should not be a surprise attack
		o It should not be comprehensive
		o It should not swallow more resources than 
		    it is likely to protect
		o It should not be forced down people's throat 
		    in an endless series of meetings
	
	2.5. 	How to devise a security policy before an incident

	2.5.1. 	Simplify analysis to High Medium Low

	2.5.2. 	Use an impromptu grid

	2.5.3. 	Limit the time for policy development to a short period
	
	2.6. 	How to devise a security policy during and after 
	          an incident

	2.6.1. 	Keep calm - Set goals
		o Keep the business revenues flowing.
		o Regenerate key systems off-line
		o Monitoring
		o Don't get exhausted
		o Everything is not an attack

	2.6.2. 	Contacting an Incident Response Center

	2.6.3. 	Hiring a consultant

	2.6.4. 	Contacting Law Enforcement
	
	2.7. 	Example Security Policies

	2.7.1. 	Finance

	2.7.2. 	ISP
	
	2.7.3. 	Partnership

	2.7.4. 	Government and Military

3. Intrusion Detection

	3.1. 	Informants are the most reliable source of information on 
		   systems abuse

	3.1.1. 	Informers from within your organization

	3.1.2. 	Informers from outside your organization

	3.1.3. 	Working with law enforcement

	3.1.4. 	Privacy
	
	3.2. 	Automated systems can help find some things

	3.2.1. 	Data reduction a key element

	3.2.2. 	You can't ferret out all abuse, so select only
		  those things that are key

		o Automated security checkers
		o Internal to host checkers
		o Virus
		o Hacking
		o Information leaks
		o Fraud
		o External to host but Internal to network checkers
		o Hacking
		o Firewall logging
		o Sniffing
		o Backups
		o Internet checking
		o Commercial services e.g. SprintNet
		o CERT
		o CyberTrace
	

4. Recovery

	4.1. 	Getting healthy systems back on line

	4.1.1. 	How to generate clean systems from scratch on the cheap
		An expensive solution would be to maintain an entire 
		host computer identical in all respects to your on-
		line systems.  In an emergency, you could simply 
		switch to the backup system.  A cheaper alternative 
		is to maintain a model system and in an emergency, 
		simply clone its hard drive to replace the on-line 
		systems' hard drive.

	4.1.2.  The importance of separating system and company data
		 Only fix the part that's broken

	4.1.3. 	Disaster Recovery sites
		o Unless the IS department practices a regular 
		   switch-over, don't use it.
		o Shipping the latest data to the remote site
		o Keeping the remote site free from abuse
	
	4.2. 	Going Off the Air
		o Can you pull the plug on a particular user?
		o Can you disconnect entirely/partially?
		o Can you shutdown entirely/partially?
	
	4.2.1. 	Benefits
		o You don't have to worry about previous work 
		    becoming undone 
		o Abuser is kept in the dark as to your plans
		o Alert Status is lower since you no 
		   longer have to monitor the abuser's activities
	
	4.2.2. 	Penalties
		o You may not know who is the real abuser 
		o Abuser is alerted to your knowledge of his/her activities
		o Legitimate clients can be cut off
		o Revenue stream may be endangered
		o Bad publicity

5. Prosecution

	5.1. 	Retaining counsel
		o A good computer literate lawyer is hard to find
		o Hire a computer security consultant with prosecution 
		    experience to help guide your legal counsel
	
	5.2. 	Working with Law enforcement
		o Law enforcement has the same problem as the 
		     legal profession 
		o You have to do the Leg Work

	5.3. 	Chain of evidence
		o Keep a log
		o State your intentions along the way
		o Don't invade someone's privacy without cause
		o Obtain a warrant
		o Seizing evidence
		o Don't allow interested parties to be alone with the data
		o The problems with checksummed data
		o Analyzing evidence
		o Use bona fide experts
		o Use Commercial Off The Shelf (COTS) software
	
	5.4. 	Expert Testimony 
		o Unflappability is as important as expertise
		o Be prepared for the bill
		o Use this expert sparingly to review your 
		   procedures and to testify
	

6. Handling Publicity

		o Don't simply hold out a scape goat to be slaughtered
		o Take immediate responsibility at the highest level
		o Act in a responsible manner and clients will 
		    continue to trust you
		o Be open about the steps you are taking to rectify 
		    the situation
		o Don't hire the hacker or abuser to rectify the situation

Home