5 0 0:SEP Immutable Storage – SiS
Please note: SiS is an upcoming (planned for Jaglion V2 release) data protection feature. The release date and exact functionality may still change.
Immutable storage is a very effective defense against ransomware attacks. As ransomware continues to evolve, backups become one of the targets of ransomware attacks. They can be deleted, altered or encrypted. Data can be lost or your company can be exposed to the threat of selling or sharing important company data or authentication information if the ransom is not paid.
SiS - SEP Immutable Storage
SEP sesam introduces SEP Immutable Storage, also called Si-Storage or SiS, to prevent attacks on backups. The idea behind SEP sesam Immutable Storage is that stored data remains completely static in its original and unchanged form throughout its lifetime. This means that businesses can quickly recover from a ransomware attack, even if they have lost access to their data and servers, by using stored data copies that have remained unchanged and intact to restore the entire operating environment.
SiS: For scenarios where administrator access to backup servers is compromised
Attackers typically compromise multiple accounts when attempting to gain access to administrator accounts to launch the ransomware. Targeted administrator accounts include backup administrator credentials, which provide a backdoor to access relevant environment data stored in a single location. The backup environment is a good place to start because the backup server has access to critical systems such as the virtualization environment and storage locations.
|Therefore, SiS can play a critical role in a ransomware scenario. Even with full admin access to the SEP sesam backup server, the attackers cannot delete your backup data or modify or encrypt it in any way. So it does not matter if the attacker gained control over your backup servers, as you will always have the data that is not compromised and can be used to restore your entire environment.|
For more details, see Ransomware Protection Best Practices.
Key benefits of SiS
- Resistant to ransomware attacks
- Immutability ensures that data is static, unalterable, and undeletable. Attackers therefore cannot modify, encrypt or delete it, even if they have gained access to your backup environment.
- Resistant to human error and malicious insider threats
- No one from the inside, regardless of their role in the organization and user status, cannot intentionally or accidentally tamper with or delete the data.
- Meeting data security and compliance regulations
- SiS can ensure that data is kept in compliance with industry and regulatory requirements by ensuring data permanence and authenticity. Immutability guarantees the integrity of data and its deletion after a specified period of time.
- Legal hold
- Ensures data authenticity for litigation requirements and secure storage of sensitive information for a set period of time.
Ensuring data immutability
SiS is based on Si3 NG store, a special type of data store that is typically required for Si3 deduplication. Si3 NG is a new generation of Si3 data store that provides high performance for backup, restore and migration, as well as direct backup to S3. However, the new SiS functionality provides built-in security features to maintain data integrity, such as a WORM (Write-Once-Read-Many) function, definable immutability, audit logs, etc.
Based on the file protection service (FPS), which scans the file system and sets the "immutable" bit for all new objects, all data stored to SiS is marked immutable at the time of storage and can no longer be changed. No object stored on SiS can be modified in any way: It cannot be renamed or removed, no links can be created to these objects nor can its metadata be accessed or changed. The objects with immutable attributes can only be viewed in read-only mode.
SiS is a storage location that can be written to once and read as many times as needed. This applies to all media pools related to the SiS data store.
How it works
- Linux server with SEP sesam
- Si3 NG store must be set up on a dedicated Linux server with SEP sesam installed and directly connected to the SEP sesam Server via TCP network access to protect it from attacks via VM access. For all requirements for the Linux server, see Requirements below.
- Protected remote access
- If SSH access to the SiS server is enabled, completely different credentials than SEP sesam admin and server root must be used so that they cannot be compromised, and stored in a remote location that the SEP sesam Server cannot access. Robust authentication and authorization must be observed along with the principles of least privilege and separation of duties (SOD). It is recommended that SEP sesam components only communicate via a restricted TCP port using non-root credentials.
- Data cannot be touched
- Controlled access with flexibility of setting data retention time during which objects are WORM-protected and immutable, so access to the data is restricted – it cannot be modified, encrypted or deleted.
- No access allowed
- Once the immutability period is set, not even privileged accounts, such as an authorized backup administrator, can change, prematurely expire, or delete the retention.
- Ensured data integrity
- Each object stored on SiS has its own hash value based on its contents, ensuring its integrity. When updated data is stored in an immutable file system, it is stored in a new location in such a way that only the changed block is written and the file location metadata is updated. In this way, the data in an immutable file system remains the same while the metadata changes over time.
- Immutability guaranteed by SiS
- SiS immutability is based on the underlying filesystem. If old backup data is moved from SiS to another storage, e.g. to a cheaper archive storage in the cloud or to tape, SEP sesam no longer has ownership of the data, which is now in a domain of the chosen storage, and immutability is no longer guaranteed by SEP sesam.
|SiS can be configured to comply with regulations and demonstrate the confidentiality, integrity, and security of the data stored on it. However, the management and security of SiS storage is the responsibility of the customer, while SEP can guarantee the immutability of SiS and its uninterrupted operation only if the configuration of SiS storage has been carried out correctly and all conditions (as described below) for SiS operation are met.|
Supported task types
SiS supports all backup task types otherwise supported by SEP sesam:
- All Path (filesystem) backups
- All supported VM backup tasks: Citrix XEN Server/XCP-ng, Hyper-V,KVM QEMU, Nutanix AHV, OpenNebula, Oracle Linux Virtualization Manager (OLVM), Proxmox VE, Red Hat Virtualization (RHV), VMware vSphere
- All supported database backups: IBM DB2, Informix, MS SQL, MySQL/MariaDB, Oracle, PostgreSQL, SAP, SAP ERP with MaxDB
- All supported groupware backups: GroupWise, HCL (IBM) Domino, Kopano, MS Exchange, SharePoint
Configuring immutable storage
As Windows-based backup servers are more vulnerable to malicious attacks, SiS relies on a Linux system to store immutable copies of backup data. This requirement applies only to the SiS server, while the SEP sesam Server can be Windows or Linux, as described in the SEP sesam hardware requirements.
The following is a list of requirements for setting up the SiS Linux server and Si3 NG.
|SiS requires a dedicated Linux server running a 64-bit Linux distribution with the following characteristics:
The SiS server does not work on older Linux versions such as SLES12, RHEL 7, and Debian 10.
- Installed SEP sesam RDS package v. 5.0.0.x. For details, see SEP sesam Quick Install Guide.
- For the minimum Si3 hardware requirements that apply to SEP sesam Si3 deduplication server, see Hardware requirements.
- Additional amount of RAM is required for the Si3-NG data store. For details, see Configuring Si3 NG Deduplication Store: Required additional amount of RAM and CPU.
- When estimating the maximum size of a deduplication store, you have to ensure that there is enough space available for dedup trash, otherwise the deduplication store will run out of space. You should calculate the required disk space based on a representative sample of your full backup and add the additional storage space equal to approximately 50% of the representative full backup.
- Si3 NG runs on a Java platform and requires a Java Runtime Environment. The required Java version depends on the SEP sesam version.
- For details on installing Java, see Installing and Managing Java.
- For details on the required Java version, see Java Compatibility Matrix.
- Configuration of the SiS server must be done manually on the server itself, as explained in the following section.
|SEP ensures the security of SiS storage and protects your data from various attacks only if the following is true: If SSH is used to access the SiS server, you must use unique credentials with restricted access that are completely different from SEP sesam admin and server root. These credentials must be stored in a location that the SEP sesam server cannot access.|
Configuration: On dedicated SiS Linux server
- Download the SEP sesam RDS package v. 5.0.0.x from the SEP Download Center: Make sure you download the correct file for your processor type. Install the package on the Linux server as described in Linux Installation.
- To set up the storage path for the SiS data store you have to check the next free drive number on SEP sesam Server. Then open the shell on RDS and execute:
# sm_create_sds.sh -E <days> -d <drive number> <datastore name> <storage path> -E <immutable period in days> -d <drive number>
SiS immutability period
The immutability period means that all savesets on the SiS storage are immutable for the configured number of days. The immutability period specified in the SiS storage settings begins the moment a saveset is written to storage.
In the following example, the immutability period on a dedicated SiS Linux server is set to 30 days: -E 30. This should be enough to protect a typical backup chain, since ransomware may already be in your systems before it strikes.
#/opt/sesam/bin/sesam/sm_create_sds.sh -E 30 -d 20 si3 /data
In this case, SEP recommends the following retention for a backup chain: create a media pool MONTH with a retention time of 31 days (leave an extra day: SiS immutability period + 1 day, where SiS immutability period is the number of days that you specified on the SiS storage side) and create a seven-day policy for FULL INCR. Note that as backups to SiS are protected and are therefore impervious to any change, it is very important that your backup chain configuration is synchronized with the SiS immutability period setting so that your active backup chain protected. For more details, see the section Creating immutability and retention policies.
After the immutability period has expired, the backups are deleted from the SiS storage.
To accept a connection from the SEP sesam Server, the correct port must be open for the SiS service. The default port is 11701 + drive number (as configured above). Add (sum) the assigned drive number (from the first step) to the default port number.
Example for drive number 20:
11701 + 20 = 11721
This port must be open in the firewall.
Example for Debian Linux:
firewall-cmd --zone=public --add-port 11721/tcp -permanent firewall-cmd -reload firewall-cmd --list-ports (returns at least port 11721/tcp)
Configuration: On SEP sesam Server
|For security reasons, make sure you do not add the dedicated SiS Linux server as SEP sesam Client!|
First, add the following default value to SEP sesam DB to enable the SiS data store type in UI. You need to set the sesam profile to run the command from the command line. Then use the following command:
sm_db "INSERT INTO defaults (key,user_name,value) VALUES ('gui.enable.credentials.si3appliance','sesam','1');"
Once the above default value is added, open the GUI and create a new Si3 NG data store with the same name as used on RDS.
- In the Main selection -> Components, click Data Stores to display the data store content frame.
- From the Data Stores menu, select New Data Store. A New Data Store dialog appears.
- Under Data store properties, enter the name you previously used on RDS as the name for the Si3 NG deduplication store. Entering the name also creates the drive group name for your Si3 deduplication store in the Create new drive group field.
- From the Store type drop-down list, select SEP Si3 NG Deduplication Store.
- The Create drive and Create second drive options are enabled under the Drive parameter properties. The predefined value for the drive is automatically set in the Drive number field. Change the drive number and enter the drive number you selected in the SiS configuration.
- The name in the Create new drive group field is already created. You can change it by simply entering a new name.
- The predefined number of channels is already set in the Max. channels drop-down list. The number of available channels depends on your SEP sesam Server package. For details on licensing, see Licensing.
- From the Device server drop-down list, select the device server for your data store.
- Switch to the Storage Backend tab and and configure the credentials by selecting New. Name the new Credential set and set the SiS host to the hostname or IP number of RDS.
- Go back to Properties to configure the Path field. Use the large Browse button to locate the server and browse to the location of your data store that you set when configuring SiS. The New data store information window appears with predefined recommended values for your data store size. Click OK to confirm the selected location and recommended size values.
Note You cannot browse the location if you have not configured the credentials as described in the previous step.
You can modify your data store size later under the Size properties. You can also enter the following values manually, depending on the free disk space on SiS.
- Capacity: Set the size (in GB/GiB) of the storage for backups.
- High watermark: The HWM defines the upper value for the used storage space. When this value is reached, the status of a data store changes from OK to Warning, but backups are still performed. Make sure that you provide enough storage space for your backed up data.
Click OK to configure your data store. You will be prompted to immediately create a new media pool for it. Click Yes and follow the procedure described in the following section Creating immutability and retention policies.
Creating immutability and retention policies
By selecting the immutability period, you define how long objects are securely retained before they are deleted. The immutability of backed up data is achieved by completely restricting access to the data so that it cannot be modified. This means that the immutability policy that you create on SiS storage cannot be modified.
SiS immutability period and media pool retention time
When configuring SiS storage, the retention time is actually set twice:
- First on the SiS storage itself. The SiS immutability parameter is actually the immutability duration parameter and specifies how long the savesets stored on it are immutable and therefore cannot be deleted, moved, or modified in any way. See the example above.
Note The SiS immutability setting can only be configured on the SiS storage itself and cannot be modified via SEP sesam UI. The immutability period for data on SiS is applied in days since the policy was created. It is designed to enforce compliance with set rules and cannot be changed by anyone until the immutability period has expired.
- The second parameter is the media pool retention time. It defines the period of time for which all savesets in the respective media pool are available for reading, so that the savesets are preserved and available for restore, migration, or replication. This period should be longer than the SIS storage immutability period.
Note Once the immutability period for the SIS storage expires, the savesets are still available, but the additional protection against accidental deletion or modification of the savesets is no longer provided.
Creating a media pool and media pool retention policy
As SEP sesam data stores use media pools for backup to disks (in this case, a SiS storage), you must first configure a dedicated media pool for it and set a media pool retention policy. Note that you can create as many media pools for a data store as you need.
- In the New Media Pool window, enter a name for the media pool, select a drive group (which you created earlier in SiS data store configuration) and set the Retention time in days. This retention time specifies the number of days for which the data is protected from writing by SEP sesam, thus preserving the savesets and keeping them available for restore. The retention time period starts with the date a saveset is written to the media and defines the expiration date (EOL) after which the saveset may be deleted.
Note To protect at least the complete last backup chain, a minimum level of protection specified in the media pool retention policy should always be set in accordance with the SiS immutability period. Ensure that you set such retention settings that allow you to protect the whole backup chain on the SiS storage. Keep in mind the retention time specified at the media pool level should be higher than the SiS immutability retention. See the example above.
- Once you have set up your media pool, you have to create a backup task, create a schedule, and link a backup event with it. For details, see Standard Backup Procedure.
For more details on configuring a media pool, see Configuring media pools for data stores.
- Time settings
- The exact time is crucial for the immutability flag. This is checked on the SiS Linux server to prevent potential attackers from changing the time and bypassing the configured immutability time. So it is imperative to ensure that the time is correct. It is recommended to use a reliable NTP server for time synchronization of your dedicated SiS Linux server.
- Additional repositories on the dedicated Linux server
- Having immutable and non-immutable data stores or other data repositories on the same Linux server is not supported! Such a configuration poses additional security risks and is therefore not supported.
Audit Logging – Ransomware Protection Best Practices – About Authentication and Authorization – Backup Strategy Best Practices – Configuring RDS (Linux example)