Podstrony

• Index
• Gould Judith Piękne i bogate
• JACK L Chalker Charon
• Christian Jacq Prawo Pustyni
• Heyerdahl Thor Aku Aku
• NEJ 10 Denning Troy Gwiazda po gwiedzie
• Roman Warszewski Skrzydlaci ludzie z Naca
• Saylor Steven Roma sub rosa t Zagadka Katyliny
• Masterton Graham Manitou (2)
• Ostrzegam czytelnika Carter Dickson
• Peter Zarrow China in War
• zanotowane.pl
• doc.pisz.pl
• pdf.pisz.pl
• us5.pev.pl

[ Pobierz całość w formacie PDF ]
.The most straightforward way to maintain documentation is keeping a log book.This allowsyou to go to a centralized, chronological source of information when you need it, instead ofrequiring you to page through individual sheets of paper.Much of this information is potentialevidence in a court of law.Thus, when you initially suspect that an incident will result inprosecution or when an investigative agency becomes involved, you need to regularly (e.g.,every day) turn in photocopied, signed copies of your logbook (as well as media you use torecord system events) to a document custodian who can store these copied pages in a secureplace (e.g., a safe).When you submit information for storage, you should in return receive asigned, dated receipt from the document custodian.Failure to observe these procedures canresult in invalidation of any evidence you obtain in a court of law.6.Establishing Post-Incident Procedures6.1 OverviewIn the wake of an incident, several actions should take place.These actions can be summarizedas follows:1.An inventory should be taken of the systems assets, i.e., a careful examination shoulddetermine how the system was affected by the incident,RFC 1244 The Site Security Handbook 2332.The lessons learned as a result of the incident should be included in revised security planto prevent the incident from re-occurring,3.A new risk analysis should be developed in light of the incident,4.An investigation and prosecution of the individuals who caused the incident shouldcommence, if it is deemed desirable.All four steps should provide feedback to the site security policy committee, leading to promptre-evaluation and amendment of the current policy.6.2 Removing VulnerabilitiesRemoving all vulnerabilities once an incident has occurred is difficult.The key to removingvulnerabilities is knowledge and understanding of the breach.In some cases, it is prudent toremove all access or functionality as soon as possible, and then restore normal operation inlimited stages.Bear in mind that removing all access while an incident is in progress willobviously notify all users, including the alleged problem users, that the administrators areaware of a problem; this may have a deleterious effect on an investigation.However, allowingan incident to continue may also open the likelihood of greater damage, loss, aggravation, orliability (civil or criminal).If it is determined that the breach occurred due to a flaw in the systems hardware or software,the vendor (or supplier) and the CERT should be notified as soon as possible.Includingrelevant telephone numbers (also electronic mail addresses and fax numbers) in the site securitypolicy is strongly recommended.To aid prompt acknowledgment and understanding of theproblem, the flaw should be described in as much detail as possible, including details abouthow to exploit the flaw.As soon as the breach has occurred, the entire system and all its components should beconsidered suspect.System software is the most probable target.Preparation is key to recover-ing from a possibly tainted system.This includes checksumming all tapes from the vendorusing a checksum algorithm which (hopefully) is resistant to tampering [10].(See sections3.9.4.1, 3.9.4.2.) Assuming original vendor distribution tapes are available, an analysis of allsystem files should commence, and any irregularities should be noted and referred to all partiesinvolved in handling the incident.It can be very difficult, in some cases, to decide whichbackup tapes to recover from; consider that the incident may have continued for months oryears before discovery, and that the suspect may be an employee of the site, or otherwise haveintimate knowledge or access to the systems.In all cases, the pre-incident preparation willdetermine what recovery is possible.At worst-case, restoration from the original manufacturersmedia and a re-installation of the systems will be the most prudent solution.Review the lessons learned from the incident and always update the policy and procedures toreflect changes necessitated by the incident.234 Part I: Managing Internet Security6.2.1 Assessing DamageBefore cleanup can begin, the actual system damage must be discerned.This can be quite timeconsuming, but should lead into some of the insight as to the nature of the incident, and aidinvestigation and prosecution.It is best to compare previous backups or original tapes whenpossible; advance preparation is the key.If the system supports centralized logging (most do),go back over the logs and look for abnormalities.If process accounting and connect timeaccounting is enabled, look for patterns of system usage.To a lesser extent, disk usage mayshed light on the incident.Accounting can provide much helpful information in an analysis ofan incident and subsequent prosecution.6.2.2 CleanupOnce the damage has been assessed, it is necessary to develop a plan for system cleanup.Ingeneral, bringing up services in the order of demand to allow a minimum of user inconve-nience is the best practice.Understand that the proper recovery procedures for the system areextremely important and should be specific to the site.It may be necessary to go back to theoriginal distributed tapes and recustomize the system [ Pobierz całość w formacie PDF ]