Guest Post: Protecting SMBs – It’s a Big Job and You’ve Got to Do It
By Patrick Rougeau
CBCP, CISSP, CISA, ITIL
Patrick Rougeau is currently a student completing a M.S. in Cyber Security at Quinnipiac University located in Hamden, CT. Rougeau’s career spans over 16 years in disaster recovery, IT consulting/management, and cybersecurity consulting/ management.
In our acronym-laden profession, SMB is three little letters with two distinct meanings for a backup engineer – small and midsize business and server message blocks. As ransomware attacks using server message blocks, other storage protocols, and storage media types become more ubiquitous, methods are needed to protect against and detect them. These attacks attempt to delete or modify the backup files on the local network and cloud backup environment. And that’s a big problem especially for small and midsize size businesses (SMBs).
Managed detection and response (MDR) is a vital service for SMBs to leverage to ensure 24/7 monitoring and response capability. Many commercially-available backup systems generate activity and logs that can help determine response actions during a ransomware attack as well as add context to security operation center (SOC) investigations. The non-regulated SMB can learn how regulated counterparts store, protect, detect, log, and review the backup files.
The financial sector is among those industries that must keep data for years. If a financial institution with data retention requirements does not survive, the organization still must pay to store the regulated data for years to come. Historically, organizations adhering to long-term record keeping regulation used tapes or external hard drives that were physically picked up by a vendor and transported a secure offsite location.
Today, businesses are not likely to use tape or external backup drives if they have the choice. All storage media types can be lost in transit, experience bit rot, and take an extended amount of time to restore data. Human error can compromise backing up and storing critical data on tapes and external drives. Modern backup providers automate backup activity and transmit data over the internet to remote vaults. But just because the data is backed up doesn’t mean it’s safe from ransomware attack.
Enterprise Strategy Group (ESG) surveyed 303 IT professionals that were familiar with their organization’s data protection environment and discovered that “70% of respondents experienced at least one attempted ransomware attack within the last year.” The deletion of backup files in the attack method is confirmed by backup software leader Veeam’s polling of 500 IT leaders that suffered a ransomware attack “…95% of ransomware attacks also attempted to infect backup repositories.” For an SMB that is not prepared for the attack and relies on its data to do business, production files being encrypted, and backup files being deleted is detrimental.
Here is an overview of the methods used to create a write once read many (WORM) backup strategy:
Certain regulated data must be stored at a third-party where the organization does not have control of backup deletion functions or retention rules that could purge data in the offsite vaults. Once the customer data has been transmitted to the offsite vaults, the customer no longer has control over the deletion of data by any means within the local backup software’s capability. The deletion requests are denied even if the customer has administrator access to the backup application running in the environment. The delete function being disabled is enforced at the backup provider level, so it cannot be tampered with using the locally installed backup software. The customer shares or forwards the encryption keys used to encrypt and decrypt the backup data to the backup service provider. Forwarding encryption keys to a third-party is vital when the encryption key itself is lost or the ransomware encrypts the key or secrets manager, making decryption near impossible. The offsite vaults are not accessible through common protocols, so the only interaction with the client backup server is ingesting compressed and encrypted data from the production backup environment.
The backup 3-2-1 rule where there are two copies of the data onsite and one copy of the data offsite can be improved to prevent attacks that could delete all digital backup copies if not architected properly. One potential fix is to create a local copy of the data and then send the backup data to a primary offsite vault. The primary vault then transmits a copy of the backup data to the secondary vault. The secondary vault should be geographically diverse from the primary vault and has no communication with the customer environment or backup server. With the data air gapped, a hacker would have to compromise the victim’s environment and the backup provider’s environment, which is very expensive and complex for the hacker.
The cloud backup provider is essential when considering the ransomware threat described and the goal of building WORM storage. The backup software only correctly functions when the encryption key is available, the backup data is available, and the backup application database is functioning. The ransomware attacker could delete or encrypt the systems running the backup software in the customer’s environment; like corrupting the application files and backup program database. The backup software’s database usually stores the backup software configurations, and information about the data that has been backed up. A deeper look is necessary into why these databases are so essential and targeted by hackers. The backup software scans a production file and breaks the scan results of that file into blocks. A unique hash is created for that file, and the file is encrypted and backed up by the backup server. The backup application database stores the information about that file. When the customer performs a restore with the backup software, the database helps the software navigate to the suitable files for restore. Suppose the backup software database is encrypted by ransomware and not recoverable. In that case, the backup data cannot be browsed or used in restore activities by the backup software because there is no mapping to the files in the backup repositories. The service provider must also have a copy of the backup software’s database to reinstall the backup software in case of a system-wide attack.
An MDR provider is looking to analyze high-fidelity telemetry sources and not all alerts and logs like a Security information and event management (SIEM) strategy. MDR is focused on just a handful of telemetry source types requiring fewer events per day which can be better for a SMBs budget. When detecting and responding to threats, the MDR provider usually has a presence on the network and the endpoint. A physical or virtual log collection appliance is placed on the network if an API integration does not exist for the log source. The network traffic running in a “North-South” fashion is collected from the firewall and gateway intrusion detection system(s) (IDS). The traffic running inside the network in an “East-West” fashion is analyzed by IDS sensors strategically placed in various parts of the network along with endpoint detection and response (EDR) telemetry. EDR agents should be deployed to all the systems in the backup environment. The EDR software also monitors the activity on the endpoints and operating system logs. When this advanced ransomware attack occurs, it will create host level and network traffic patterns that are indicative of the discussed attack. SOC analysts can proactively thwart the emerging threat in the SMB environment. When an organization is scoping an MDR solution, the backup servers and local backup storage locations must be included in the MDR strategy. The backup application logs will be an additional source for the SOC analysts supporting the MDR service. The backup sets that are pointed at the critical data will generate logs of interest to help add context to an active ransomware investigation. Establishing baselines of the expected levels of activity in the backup environment can be compared to the anomalous activity. Information like large file count increases, large delta changes, deletion activity, user audit trails, can be paired with the typical MDR alerts to understand if the backup environment is being attacked.
This post was not meant to be an exhaustive list of backup and MDR features but can help SMBs evaluate their current configurations and security vendors. Backup systems being a “set it and forget it” type of solution, can be a high risk to any SMB. The days of getting a few emails confirming that the backups were successful and moving on with other system administrative activities are over. The ransomware attack examined will move quickly or systematically encrypt data over time, adversely affecting business operations if recovery points are not an option. The vigilant SMB will use the features and techniques described among others to achieve some level of assurance data will be available for years.
Disclaimer: Guest posts and comments represent the diversity of opinion within the resilience community. The views and opinions expressed in these posts are those of the author and do not necessarily reflect the official position of DRI International.