Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.

10.3. Implementing the Incident Response Plan

Once a plan of action is created, it must be agreed upon and actively implemented. Any aspect of the plan that is questioned during an active implementation can result in poor response time and downtime in the event of a breach. This is where practice exercises become invaluable. Unless something is brought to attention before the plan is actively set in production, the implementation should be agreed upon by all directly connected parties and executed with confidence.

If a breach is detected and the CERT team is present for quick reaction, potential responses can vary. The team can decide to disable the network connections, disconnect the affected systems, patch the exploit, and then reconnect quickly without further, potential complications. The team can also watch the perpetrators and track their actions. The team could even redirect the perpetrator to a honeypot — a system or segment of a network containing intentionally false data — used to track incursion safely and without disruption to production resources.

Responding to an incident should also be accompanied by information gathering whenever possible. Running processes, network connections, files, directories, and more should be actively audited in real-time. Having a snapshot of production resources for comparison can be helpful in tracking rogue services or processes. CERT members and in-house experts are great resources in tracking such anomalies in a system. System administrators know what processes should and should not appear when running top or ps. Network administrators are aware of what normal network traffic should look like when running snort or even tcpdump. These team members should know their systems and should be able to spot an anomaly more quickly than someone unfamiliar with the infrastructure.

 
 
  Published under the terms of the GNU General Public License Design by Interspire