The 18th practice described in the newly released edition of the Common Sense Guide to Mitigating Insider Threats is Practice 18: Implement secure backup and recovery processes. In this post, I discuss the importance of establishing a secure backup and recovery process in your organization.

The CERT Division announced the public release of the fifth edition of the Common Sense Guide to Mitigating Insider Threats in December 2016. The guide describes 20 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, and provides case studies of organizations that failed to do so. The 18th of the 20 best practices follows.

Practice 18: Implement secure backup and recovery processes.

Despite the best defensive efforts an organization uses, attackers can still get through that defense. Since a determined and trusted insider knows the protective measures implemented by the organization and has access to the facilities, their attacks can swiftly disrupt the organization and cause crippling loss of data, unavailability of data or systems, or fraudulent activity, potentially before the organization realizes it. Data loss can involve encrypting data to facilitate fraud or deleting data to sabotage the organization.

The CERT Insider Threat Incident Corpus describes some incidents where the results of attackers' actions could not be undone because of faulty backup systems. Attackers can even attack the backup system, to magnify the impact, by deleting backups or stealing backup media. Resilient organizations prepare for such possibilities by devising, implementing, and testing their backup and recovery process to ensure it is effective.

To guard against an insider attack, organizations should consider the following actions related to their backup and recovery processes:

Control access to physical media and backup storage facilities.

Perform backups and periodically test them.

Protect media and content from modification, theft, or destruction.

Apply separation of duties and configuration management procedures to backup and recovery systems.

Apply the two-person rule for protecting the backup process and physical media so that one person cannot take action without the knowledge and approval of another person.

When reviewing your backup and recovery process, make sure you can achieve the following:

Recover from a disruptive event to the level specified in your service level agreement.

Test the entire recovery process across the entire organization. To avoid potential malicious insiders tampering with the testing process, the test criteria should not be announced beforehand.

If part of the backup and recovery process is outsourced, account for the possibility that a malicious insider is employed by a trusted business partner.

SEI LIBRARY

LATEST POST

According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.