Hello,
Seems, that he problem you encountered was related to prerequisite, you miss the "requests" package on your remote Linux Machine
As said on the link : https://community.ibm.com/community/user/security/blogs/pascal-weber/2023/10/10/managing-network-hierarchy-the-art-the-legend-and
Working directly on QRadar
Qradar > 7.5.0Python 3.6 (Use of f-strings))
The script has been designed with flexibility in mind. For those who have direct access and the required privileges, the script can operate directly on a QRadar system. We have verified its compatibility with QRadar versions 7.5.x. This direct method allows for streamlined integration and quick access to QRadar's features without the need for additional configurations.
However, there are some considerations when working directly on QRadar.
Working on a Remote Linux Machine (Preferred Method)
For a more isolated and controlled environment, we recommend executing the script on a remote 🐧 Linux machine. Our tests have particularly been positive on Debian-based systems.
This method has several advantages:
- 🏝️ Isolation: Running the script remotely ensures that QRadar's primary functions remain undisturbed. There's no risk of unintentionally consuming excessive resources on the QRadar system.
- 🤸 Flexibility: A separate Linux machine provides more freedom for customization, debugging, and script optimization. This can be especially beneficial when integrating the script with other tools or systems.
- 🛡️ Security: Operating the script remotely can add a layer of security. By limiting direct access to the QRadar system, you can further safeguard against potential threats or mishaps.
📋 Requirements for the Remote Linux Machine:
- Python Version: Ensure that Python is installed, preferably a version that supports f-strings (Python 3.6 and above).
- Network Access: The remote machine should have network access to QRadar for API calls. Ensure that any firewalls or security groups allow for the necessary communication between the two systems.
- Required Libraries: The script might rely on specific Python libraries. These should be installed and kept updated on the remote machine
- Authentication: API authentication details, like tokens or credentials, should be securely managed. Consider using environment variables or secure configuration files.
🧪 Tested on my side on :
- debian Bullseye (11.7)
- Python 3.9.2
Requests==2.31.0urllib3==1.26.5
In conclusion, while both methods have their merits, using a remote Linux machine offers a balance of security, flexibility, and efficiency.
Depending on your organization's infrastructure, security guidelines, and resource availability, you can choose the method that fits best.
Regards,
Pascal
------------------------------
zoldax
https://www.credly.com/users/pascal-weber.029e134d/badges------------------------------
Original Message:
Sent: Wed January 17, 2024 04:12 AM
From: Cyber Post
Subject: Managing the Network Hierarchy with API
Tried and ended up with this error.
Any idea how to fix this
@Pascal Weber
Original Message:
Sent: Thu October 26, 2023 05:47 AM
From: Michael Namet
Subject: Managing the Network Hierarchy with API
Hello Carlos,
I'm not sure if you've had the chance to see it, but there was an interesting blog post published a few weeks ago regarding Network Hierarchy in the QRadar blog section of the IBM Community:
https://community.ibm.com/community/user/security/blogs/pascal-weber/2023/10/10/managing-network-hierarchy-the-art-the-legend-and
It might be worth checking out!
Additionally, there is a link to the open-source utility named NHSuite, which can manage the Network Hierarchy from CLI(export, import, check).
It includes a lot of features like safety, controls, and error logging, and is available on GitHub : https://github.com/zoldax/NHSuite
Regards,
Michael
------------------------------
Michael Namet