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 active implementation will most likely 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 while the CERT is present for quick reaction, potential responses can vary. The team can decide to pull the network connections, disconnect the affected systems, patch the exploit, and then reconnect quickly without further potential complication. 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 — in order 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 will be 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 quicker than someone unfamiliar with the infrastructure.