How To Demonstrate Backup Compliance. A Practical Guide

Compliance to industry standards and regulatory mandates can absorb a huge amount of time. Organizations need to verify they comply with the different requirements of security frameworks and regulations such as CIS, NIST, PCI DSS, ISO, and others.

In addition, many of these standards require organizations to verify that they are carrying out their fiduciary responsibilities concerning Common Vulnerabilities & Exposures (CVEs).

The big problem is time.

Backup Compliance is Time Consuming

Some organizations spend countless hours manually preparing for compliance-related activities such as a PCI audit. Once the preparations are complete, even more time is absorbed in writing reports that demonstrate compliance—and this is only the beginning of an ongoing process.

According to NIST document SP 800-209 Security Guidelines For Storage Infrastructure, organizations are required to: “periodically and proactively assess configuration compliance to storage security policy”. This includes the following 3 steps:

• Make sure that the actual configuration meets the storage & backup security baselines and identify gaps.
• Track the remediation of gaps in a timely manner.
• Consider developing KPIs to track the compliance to storage & backup security baselines based on types of data, their organization function, and their sensitivity.” 

Historically, these have been weak areas within organizations. The reasons are not difficult to comprehend—the scope of compliance for storage and backup systems is immense.

Many of the tools used to scan for vulnerabilities and security misconfigurations do a poor job in identifying storage and backup risks. In fact, they may cause the organization to falsely claim compliance when numerous security threats remain. The reason for this is that compliance often requires specific configuration checks for systems at all levels of your stack—not just the guest operating system that hosts your applications—working in concert to fulfill the policy’s objective. This includes your storage and backup systems.

Let’s dive a little deeper on this and take a look at 6 steps to verify backup compliance.

Demonstrating Backup Compliance – in 6 Steps

1. System software: Storage and backup systems suffer from CVEs like any other software, yet many organizations are either unaware that they exist, or have been lulled into a false sense of security that all critical CVEs have been addressed. The plain fact is that storage and backup operating systems are often riddled with vulnerabilities that can enable threat actors to gain unauthorized access, elevate permissions, and run arbitrary code.

As well as being present within storage and backup systems, vulnerabilities may also be found in underlying components and modules, including embedded switches, controllers, boards, drivers, firmware, and other components.

Unfortunately, most vulnerability scanners simply fail to run compliance checks for backup systems. They miss these critical CVEs and security misconfigurations.

2. SAN Zoning and Masking: A large portion of Enterprise Block Storage is implemented using dedicated, non-IP Storage Area Networking (SAN).  To allow hosts to access block storage devices (often referred to as “LUNs”), these networks need to be configured to support “Zones” (somewhat similar to Ethernet VLANs) that pool together hosts and storage devices that can communicate with each other, and “Masking” (somewhat similar to IP ACLs) that further control which block devices can effectively be accessed at various points along the network path.  Network Zoning and Masking mistakes are more common than many people realize. LUNs may have been left accessible to unintended hosts. Replicated copies and snapshots, too, may not have been properly secured. If that is the case, a hacker may be able to mount sensitive data to unauthorized clients.

3. Audit logging misconfigurations: Many backup systems are not configured sufficiently for audit logging. This manifests in ways such as missing audit log content, audit logs not relayed to central syslog servers, or logging settings that are tweakable by hackers to relay logs to unapproved hosts. These errors make it more difficult for the organization to detect brute force attacks and anomalous behavior patterns. They also impede forensic investigation and can curtail recovery efforts.

4. Default accounts and passwords: A surprising number of storage systems still include default administrative usernames and passwords. These factory settings can easily be exploited to cause serious damage. Compliance efforts must carefully look over the different storage subsystems and respective user accounts to ensure access security policies are properly enforced.

5. Control over administrative access: Configuration drift and oversights result in more user accounts with administrative access than required. An excessive number of administrator accounts increases the attack vectors that can be exploited by malicious actors. Furthermore, storage management components including Command Line and API interfaces often do not follow a least privilege design (aimed at making them accessible only by a minimal number of administrative accounts using an authentication system that complies with security and audit policies).  This leaves many storage and backup systems open for data manipulation, theft, and destruction.

6. Backup isolation and immutability: Various standards require that backup data shall be kept in an isolated, inaccessible environment that does not overlap with the production network.

These are just a few of the many security considerations and risks present in any backup system.

Fines and Penalties Galore

Organizations that fail in any of the activities required to demonstrate compliance are subject to heavy fines and penalties. These days, when it comes to regulatory compliance, there are more eyes on backups than ever:

• PII and PHI/HIPAA-HITECH, for example, are of interest to the SEC, PCI Council, and others
• SOX and PCI-DSS are very much under the microscope of regulators in financial services, retail, and public corporations
• Healthcare organizations must watch out for HIPAA compliance lawsuits in federal court
• Too-big-to-fail organizations follow NIST, FFIEC and more
• Federal organizations follow NIST
• Critical Infrastructure organizations must adhere to NERC CIP
• Retail, Financial and many others follow PCI

Since becoming law in 2016, almost 900 organizations have been fined more than 1.25 billion Euros due to violations of GDPR. Amazon Europe alone was fined three quarters of a billion Euros. Fines have been imposed on the likes of WhatsApp, Google, Target, Yahoo, Marriott, Equifax, and Facebook. All were doled out for various PII violations.

Simplifying Compliance – with Continuity & Veeam

On March 2^nd, join Continuity & Veeam in this webinar, to learn:

• How to establish a security baseline for your backups, and then validate configuration compliance through automated compliance checks
• Automate the detection and remediation of security misconfigurations, and prove adherence with security regulations and standards
• Apply stricter controls and more testing of backup security, and your ability to recover from a ransomware attack
• Develop KPIs to track the compliance to backup security baselines, based on types of data, their organization function, and their sensitivity.

Register today: