• Post Breach Lessons Learned

  • The post breach lessons learned is an important part of recovering from a breach. The lessons learned phase is actually part of the PICERL model for incident response. We have seen a trend over the year of breached organizations skipping this step entirely.

    The incident response process has traditionally been the PICERL model:

    • Prepare
    • Identify
    • Contain
    • Eradicate
    • Recovery
    • Lessons Learned

    In reality what we’ve found within breached originzations is actually this:

    • Identify
    • Contain
    • Recovery

    The Identify phase doesn’t count if you discovered an intruder on your network due to a ransomware notice. The intruder made their presence know in this case. Had they not displayed that banner demanding a ransom, you wouldn’t have known they were on your network.

    The Prepare phase was never implemented or matured in context with the threats the organization actually faces.

    When an incident took place organizations focused on the Contain phase for only on the affected systems and didn’t consider other areas the attacker still had access to. This resulted in the attackers maintaining persistence and access to the network.

    In the Recovery phase organizations returned the business critical systems back to operation, but did nothing to address the root cause of the incident.

    The phases of Prepare, Eradicate, and Lessons Learned were overlooked entirely. These are some of the contributing factors that create a post breach crisis.

    Post Breach Crisis

    The post breach crisis is that period when the organization perceives it has recovered from the incident and needs to make improvements to their security program. Without the appropriate strategy the knee-jerk actions to restore operations will slowly come unwound resulting in potentially a worse state of security than before the breach.

    Some of the main issues we see that contribute to this are:

    • Lack of a risk appetite statement. This is what drives how you secure your network, devices, and determines how you invest appropriately.
    • Relying on vendor to make recommendations for security without understanding the business objectives.
    • Not adding appropriate headcount. Simply adding more tools and technology without adding headcount results in your security team becoming burnt out and leaving the organization for better offers.
    • Not placing someone in charge of security. After a breach you should consider hiring a CISO to drive security for the organization.

    All these factors and more, contribute to the dysfunction of your security program after you think you are fully recovered from a breach.