This article shows how to leverage the Lumu Defender API and Unisys Stealth Configuration API to mitigate security risks.
OR
Using the Unisys Stealth console, you need to create and set up an Isolation role. Further instructions on how to run this configuration can be found in the Unisys Stealth Information Center Configuration Guidelines.
Ask for the hostname or IP address, username, and password of your Stealth server to work via API. Remember that you need connectivity end to end between your Stealth server and the Integration host.
There are 2 environment options to deploy the script, select the one that fits better in your current infrastructure. Whatever alternative you select, you need to unpack first the integration package shared by our Support team. Unpack the deployment package provided by Lumu in your preferred path/folder. Keep in mind this location, as it will be required for further configurations. From now on, we will refer to this folder as <stealth_lumu_root>.
In the package, you will find the script required to run the integration. To use the script, you must locate yourself on the path selected for deployment (<stealth_lumu_root>). Specific directions are included in the next sections.
If you are running different Python scripts in the selected host, it’s recommended to create a virtual environment to preserve the integrity of other tools. To do so, follow these steps:
1. Using a command line tool, locate yourself in the <stealth_lumu_root> folder
2. Run the following command to create the virtual environment
python3 -m venv <venv_folder>3. Activate the virtual environment running the following
source <venv_folder>/bin/activate
The file requirements.txt contains the list of requirements for this integration. After deploying the package locally, run the following command from the deployment folder:
To use the script, you must locate yourself on the path selected for deployment (<stealth_lumu_root>). Use the following command to show all options available for the package:
usage: main.py [options]
Options | Description |
---|---|
-h, --help | show this help message and exit |
--stealth_host STEALTH_HOST | Unisys Stealth Host [domain name or IP] |
-u STEALTH_USERNAME--stealth_username STEALTH_USERNAME | Unisys Stealth user access |
-p STEALTH_PASSWORD--stealth_password STEALTH_PASSWORD | Unisys Stealth password access |
--stealth_role STEALTH_ROLE | Unisys Stealth isolation role |
--show_exclusions | show Stealth Machines exclusions |
--add_exclusions ADD_EXCLUSIONS | Case Sensitive hostname, separated by "," host1,host2 |
--del_exclusions DEL_EXCLUSIONS | Case Sensitive hostname, separated by ",", e.g. host1,host2 |
--hours HOURS | Lumu hours backwards |
-key COMPANY_KEY--company_key COMPANY_KEY | Lumu Company Key (Defender API). |
--logging {screen,file} | Logging option (default screen). |
--verbose, -v | Verbosity level. |
--clean-all | wipe out all the endpoints in a role |
--clean | wipe out the endpoints in a role which once were isolated |
Machines which are in exclusion list will no take any effect in case machine is triggered to isolation
To query all the IoCs related to Lumu incidents triggered in the last 30 days, run the following command.
By default, the integration script will query incidents for the last 30 days(720 hours). If you need to change this value, you can use the --hours flag as follows.
In this example, the integration will query and push to Stealth Role list lists, Affected machines related to incidents in the last 5 days
You can run the integration using a configuration file where you can save the required arguments in the form of <argument_name>=<value>, one argument per line. In the <stealth_lumu_root> path, save a file named .config with your configuration. Following, you have a sample of the format of the file.
- ## Configuration file # Lumu company_key=<LUMU_COMPANY_KEY> # App stealth_host=<STEALTH_HOST_SERVER> stealth_username=<STEALTH_USERNAME> stealth_password=<STEALTH_USER_SECRET> stealth_role=<ROLE_NAME> hours_past=720
When the script is run with the –clean or –clean-all flag, it will return isolated devices by the integration to their original state:
If you want to revert the isolation state from all isolated machines, regardless they are Lumu machines or client machines, use the following syntax.
According to your needs, you can combine the examples shown.
To run the script on a timely basis, consider implementing a Scheduled task in Windows or a Cron task in Unix-based systems. If you are pushing hashes, the integration could take longer to run. We recommend that the scheduled job runs every 30 minutes.
Following, you have an example of how this Cron job should look using the recommended time.
It’s recommended to add the --logging file argument to any scheduled task. It will record all the output in the log file for further reference. If you have created a configuration file, your crontab entry doesn’t need arguments. It should look as follows:
If you need to work with another scheduling time, you can use the crontab guru service.
To avoid race conditions, you can run only one instance. If you have one running, the second one will be canceled immediately.
If you have a Docker environment, you can select this option to run the integration as a Docker process. To deploy and run your integration as a docker container, locate yourself at the <stealth_lumu_root> folder, and follow these instructions:
1. To build the container, run the following command. Change all the flags based on the reference given in the script section above.
docker build --tag python-lumu-unisys-stealth .Do not forget the dot "." at the end of the line2. To run the container, run the following command:
docker run -d --restart unless-stopped --name lumu-unisys-stealth python-lumu-unisys-stealth
With this mode, your integration will run every 30 minutes.
For troubleshooting purposes, you can run the following commands:
To log in to your container using an interactive shell:
To collect integration logs:
After running the integration, check the machines attached to the role via Stealth API or Stealth manager, then check if the isolated machines have regular network permissions according to the role permissions, also check the integration logs.
Before:
Logs
05-07-2023 14:41:01 - lumu-unisys - [140615468185408]:[INFO] - ----------------- Lumu Unisys Stealth Custom Response -----------------
05-07-2023 14:41:02 - lumu-unisys - [140615468185408]:[INFO] - affected_machines=['cdeiro', 'cd-ho', 'dvalero', 'sebastián’s macbook air', 'lumustealth2', 'lumustealth', 'lumu-stealth']
05-07-2023 14:41:02 - lumu-unisys - [140615468185408]:[INFO] - newest_machines=['LumuStealth', 'LumuStealth2']
05-07-2023 14:41:02 - lumu-unisys - [140615468185408]:[INFO] - still_machines=[]
05-07-2023 14:41:02 - lumu-unisys - [140615468185408]:[INFO] - no_longer_machines=[]
05-07-2023 14:41:05 - lumu-unisys - [140615468185408]:[INFO] - Isolated: LumuStealth
05-07-2023 14:41:07 - lumu-unisys - [140615468185408]:[INFO] - Isolated: LumuStealth2
05-07-2023 14:41:07 - lumu-unisys - [140615468185408]:[INFO] - current endpoint de-attached to the role: []
05-07-2023 14:41:08 - lumu-unisys - [140615468185408]:[INFO] - current endpoint list attached to the role: ['LumuStealth', 'LumuStealth2']
05-07-2023 14:41:08 - lumu-unisys - [140615468185408]:[INFO] - active sessions: ['LumuStealth2', 'vm-sth-dash', 'VM-STH-EM', 'LumuStealth', 'STH-SAAS-CLI1', 'STH-DEMO-FS']
To identify failures in the script execution, use the -v flag. The script execution log will show more detailed information.
If you receive the following error.
There could be another instance running. To check this, open the pid.pid file in the integration folder. This file stores the process id if it’s running. Search for this process in your system. The following pictures show the process in Windows and Linux.
If the previous validation indicates that another instance is running, please, check its progress using the integration’s log lumu.log.