Skip to main content
Version: 2.9.2

Security Guard for PowerScale OneFS

Introduction​

Security Guard is an automated validation tool that tests your Cluster's readiness against potential ransomware attacks. By simulating such a scenario, Security Guard verifies that your system's defenses are fully operational. Security Guard confirms that Ransomware Defender is correctly identifying threats, triggering alerts, and activating appropriate countermeasures like session lockouts.

This guide will take you through the prerequisites, and steps required to configure this tool.

Prerequisites​

It's necessary to verify each of the following factors in order to be prepared to follow the procedures explained in this guide.

Ransomware Defender License Key​

You will need a Ransomware Defender License Key, this License must be active and installed on the Powerscale or ECS Cluster you want to protect.

Dedicated Service Account​

A username and password must be created for use with Security Guard. The username created for this purpose:

  • Must validate on every network element (Cluster or node) where Security Guard is enabled.

  • Must not be shared with other services. (Especially not with the Robo Audit service account used in Easy Auditor.)

  • Must respect one of the following formats:

    • Local Account: (username)@(cluster name)
    • Domain Account: (username)@(domain)
note

If your PowerScale environment involves multiple Clusters, the best practice is to enable Security Guard on only one cluster using a local account.

info

If you're using a local service account for PowerScale, create it within the System Zone.

Dedicated Bucket Object Users on ECS​

Security Guard uses two dedicated Bucket Object users: one for simulating attacks, and the other for enabling bucket versioning as a protective measure.

When creating the Bucket Object Users, you will be able to generate access keys for them. Make sure to record the keys somewhere safe.

Lockout Behavior​

Basics of Lockout​

  • Validation of Lockout: Security Guard verifies that the lockout is effective by trying to write files to the honeypot share (PowerScale) or the test bucket (ECS) after the simulated attack. This is to verify that the lockout mechanism was effective.
  • Recovery Process: After the lockout, Security Guard starts a user recovery process to restore access to the affected share/bucket. Then, it tries to write files again to verify that the access was restored.

On PowerScale​

  • Dedicated Honeypot Share: Security Guard creates a dedicated share called "igls-securityguard" within the System Zone on the PowerScale Cluster where it's enabled. This share acts as a "honeypot", meaning that it attracts the simulated attack.
  • Service Account Lockout: The dedicated account for Security Guard is added to the "igls-securityguard" share permissions list. During a simulated attack, its access to the share is locked out to simulate the effects of a real ransomware event.
  • User Addition Not Required: Additional users don't need to be added manually to the "igls-securityguard" share. Security Guard uses its dedicated account for the simulated attack, which isolates the testing process from real user accounts.
info

If the dedicated Security Guard account is also added to other shares besides "igls-securityguard", its access to those shares will also be locked out during a simulated attack. Although files will only be written to the "igls-securityguard" share when a simulated attack occurs.

On ECS​

  • Security Guard automatically creates a dedicated bucket for testing on ECS.
  • The dedicated test user (bucket object user) is associated with the test bucket, which enables the simulation of ransomware activity.
warning

The Test Bucket User must not be used for any other purpose, nor should it be assigned to any buckets other than the designated test bucket.

Key Steps of a Simulated Attack​

  • Creating a share which is automatically secured to the service account.
  • Cleaning up old files from the last execution of a Simulated Attack.
  • Creating test files using a well-known extension to trigger a response from Ransomware Defender. (This is the "attack" itself.)
  • Verifying that the user lockout occurs.
  • Initiating recovery of the user and verifying access again.
  • Reporting success/failure per step.
  • Emailing results to an administrator.

Configuration Steps​

  1. Go to the Ransomware Defender icon on the desktop of the Eyeglass Web UI.
  2. Select the Security Guard tab.
  3. Under Job Settings, you may check the box or Enable Task to run Security Guard automatically every set interval. (You can then set the Interval Between Runs using the drop-down selector)
  4. Enter the Security Guard service account Username and Password. (Keeping the aforementioned prerequisites in mind)
  5. Click on Submit to save the settings.

How to Run Simulated Attacks On Demand​

  1. Open the Ransomware Defender Module, by clicking either the Desktop icon or the Main Menu item on the bottom left of the Eyeglass Web UI.
  2. Select the Security Guard tab.
  3. Select each licensed Cluster that you wish to test.
  4. Click on Run Now at the bottom right corner of the window.

To monitor progress of the test, go to the Jobs window (also found on the desktop of the Eyeglass Web UI) and select the Running Jobs tab. You may see each step of the job there, and you may also expand steps using the plus (+) button to see available sub-steps.

How to Review Test Logs​

  1. Navigate to the Security Guard tab of the Ransomware Defender Eyeglass Module (as shown in step 1 of the previous procedure)
  2. Go to the Security Guard Jobs History section to view the list of past Security Guard Jobs.
  3. To review the results of a specific job, click on Open.

Testing Ransomware Defender Using a Custom File Extension​

About​

Use this feature to test full user lockout and recovery using a file extension of your choice. This allows you to conduct manual testing similar to Security Guard, providing a deeper understanding of system behavior.

Requirements​

Eyeglass version 2.5.7 or later.

Configuration​

  1. Open the Ransomware Defender application.
  2. Navigate to the File Filters tab.
  3. Click on Add Filter.
  4. Enter a unique file extension for testing and make sure it is not used in your environment. Enable the option to add this extension.
  5. Review and note down your Critical Threshold values from the Thresholds tab.

How to Test​

  1. Mount a SmartConnect name and share it within an access zone that has auditing enabled. For example: \\fqdn\smb-share-name.
  2. Create files with your custom file extension, ensuring that you exceed the Critical Threshold value to trigger a lockout.
info

This setup allows you to test the lockout action and verify the restore process. Additionally, it can be used to generate alarms for SEIM tool integration

Advanced Configuration Options​

In some environments, audit events are delayed before they are sent to the ECA for processing. The security feature writes 100 files (one per second).

If an event isn't detected before these 100 seconds, the Security Guard will fail the test.

The second phase of the Security Guard will restore user permissions and test write access again to the share.

This process can also have a timer applied to extend the time between the lockout and restore steps, allowing authentication and sharing settings to replicate to the cluster.

info

If there are security guard events that are being raised within minutes after the previous event was archived, then extend the lockout time as per the CLI guide.

You may use commands to change the security timer. To consult the available commands. visit the Eyeglass CLI Commands guide.

There, you will be able to check these advanced settings and configure them to meet your needs.

You may also consult the Ransomware CLI Guide for more information.

Next Steps​

If you haven't already, consult the CLI Guides linked above. You may also want to run some on-demand tests to make sure everything is running smoothly.