SO SAG 4.2.3 en

F I R E E Y E T E C H N I C A L D O C U M E N T A T I O N
SECURITY ORCHESTRATOR
SYSTEM ADMINISTRATION GUIDE
RELEASE 4.2
SECURITY ORCHESTRATOR / 2019

FireEye and the FireEye logo are registered trademarks of FireEye, Inc. in the United
States and other countries. All other trademarks are the property of their respective
owners.
FireEye assumes no responsibility for any inaccuracies in this document. FireEye
reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.
Copyright © 2019 FireEye, Inc. All rights reserved.

Security Orchestrator System Administration Guide
Software Release 4.2.3
Revision 1
FireEye Contact Information:

Website: www.fireeye.com/company/contact-us.html
Technical Support: www.fireeye.com/support/contacts.html
Contents
Contents
PART I: Getting Started 7
CHAPTER 1: About Security Orchestrator 9

SO Virtual Appliance 10
SO Architecture 10
SO Command-Line Interface (CLI) 11
Using GNU Screen 11
SO Web UI 12
Web Browser Support 12
CHAPTER 2: System Requirements 13

Virtual Appliance Requirements 13
Network Requirements 13
PART II: Deployment 15
CHAPTER 3: Deployment Checklist 17
CHAPTER 4: Virtual Appliance Installation 19

Obtaining the SO Deployment Files 19
Installing the SO Virtual Appliance 20
Configuring the SO Virtual Appliance at Initial Startup 21
Setting the Date and Time on the SO Virtual Appliance 26
Accessing the Web UI 27
Troubleshooting Web UI Access Issues 28
© 2019 FireEye 3
Contents
CHAPTER 5: Plug-In Installation 31

Plug-In Installation Checklist 31
Content Installer Arguments 33
Obtaining Plug-In Installation Packages 34
Listing Plug-Ins Available for Installation 34
Installing Plug-Ins by Name 35
Installing Plug-Ins by Vendor 35
Installing Plug-Ins by Category 35
Installing All Plug-Ins 36
Verifying Installed Plug-Ins 37
Loading Content Management Tools 38
Uninstalling Plug-Ins 38
Installing Plug-Ins and Dependencies Independently 39
CHAPTER 6: Configuration 43
Manual Configuration 43
Networking Configuration 43
Hostname Configuration 44
Web Configuration 46
Firewall Configuration 47
SSL Configuration 49
Remote Access with Secure Shell (SSH) 50
Configuring Remote Access Authentication 50
Generating RSA Keys for SSH Authentication 51
Connecting with PuTTy and Authorized Keys 52
SNMP 55
SNMP Installation 55
SNMP Configuration and Monitoring 56
4 © 2019 FireEye
Contents
PART III: User Management 67
CHAPTER 7: About User Management 69
CHAPTER 8: Managing Groups 71

Access Permissions by Component 71
Courses of Action 72
Cases from COAs 72
Plug-Ins 73
Devices 73
Adapters 74
Users 74
Current User 74
User Groups 75
Scripts 75
Tables 75
Forms 75
Viewing Groups 76
Creating a Group 77
Modifying a Group 78
Deleting a Group 79
CHAPTER 9: Managing Users 81

Viewing Users 81
Creating a User 82
Changing User Details 83
Changing User Passwords 83
Resetting Passwords for Locked-Out Users 84
Resetting Passwords Using the CLI 84
Changing User Group Assignments 84
Enabling or Disabling a User 85
Deleting a User 85
© 2019 FireEye 5
Contents
PART IV: Administration 87
CHAPTER 10: Managing Services 89

Status of SO and Dependent Services 89
Stop SO and Dependent Services 89
Start SO and Dependent Services 90
CHAPTER 11: Managing Logs 91

Configuring Logging Levels 91
RabbitMQ Service Logs 92
CHAPTER 12: Generating Log Bundles for Customer Support 93
CHAPTER 13: Managing Snapshots 95

Creating a Snapshot 96
Restoring a Snapshot Without Encrypted Data 96
Restoring a Snapshot with Encrypted Data 96
CHAPTER 14: Viewing Content 99
CHAPTER 15: Upgrading Software 101

Obtaining the SO Upgrade Files 101
Upgrading the SO Software 102
Technical Support 103

Documentation 103
6 © 2019 FireEye
SO System Administration Guide
PART I: Getting Started
l About Security Orchestrator on page 9

l System Requirements on page 13
© 2019 FireEye 7
SO System Administration Guide PART I: Getting Started
8 © 2019 FireEye
CHAPTER 1: About Security

Orchestrator
Security Orchestrator (SO) is an open workflow automation platform that integrates FireEye
and third-party products and services to provide effective threat detection and incident
response. Security Orchestrator provides a workflow builder that allows you to model your
security procedures, and a plug-in API architecture to integrate external systems into your
workflows.
Security Orchestrator can initiate workflows, called playbooks, that complete automated
tasks and request human intervention to complete manual tasks. Playbooks can
automatically create cases and escalate important alerts or events. You can create your
own playbooks and customize FireEye's pre-configured playbooks to meet the needs of
your organization.
With the variety of Security Orchestrator plug-ins provided by FireEye, you can perform a
diverse set of tasks in playbooks. In addition, you can develop your own plug-ins to extend
Security Orchestrator's capabilities. The existing library of plug-ins can integrate your
playbooks with various products and services, including:
l FireEye appliances and tools

l Threat intelligence services
l Malware analysis tools
l Security information and event management (SIEM) tools
l Cloud-based storage
l Ticketing and issue tracking systems
l Endpoints
l Firewalls
l Switches
l Sandbox tools
l Email servers
© 2019 FireEye 9
SO System Administration Guide CHAPTER 1: About Security Orchestrator
l Chat tools
l Mobile devices
This guide contains information on installing, configuring, and maintaining the Security
Orchestrator virtual appliance. To get started, see the following sections:
l SO Virtual Appliance below

l SO Architecture below
l SO Command-Line Interface (CLI) on the facing page
l SO Web UI on page 12
For information on creating, customizing, and managing playbooks, see the Security
Orchestrator Playbook Management Guide.
SO Virtual Appliance
Security Orchestrator (SO) is a virtual appliance distributed in the Open Virtualization
Format (OVF), which is an open standard for sharing virtual appliances. The
SO 4.2 virtual appliance is a CentOS 6 virtual machine with core SO components already
installed.
SO Architecture
The following services, systems, and components are installed on the Security Orchestrator
virtual appliance:
Name Description
Security Orchestrator The main Security Orchestrator service (fso) that manages all
service Web and engine services
Apache HTTP Server Web server that provides access to the Security Orchestrator Web
2.4 UI
Python Virtual SO uses a Python virtual environment for running plug-in

Environment commands. This environment is different from the Python
environment included in the CentOS operating system.
Python Interpreter Used by the SO engine. One process runs for each worker thread
(up to 10 processes total), as well as one process per running
adapter.
10 © 2019 FireEye
Release 4.2 SO Command-Line Interface (CLI)
Name Description
Cassandra database The database that stores most SO data, including application
configurations, playbooks, cases, and events
Elasticsearch Used for storing data for dashboard data and custom tables.
database Some plug-ins also use Elasticsearch to persist data from
execution to execution.
RabbitMQ server Message queuing framework used to store events that need to be
processed by SO, such as results received by adapters and
playbook tasks.
Mnesia database The RabbitMQ server uses the Mnesia database to store data that
SO needs to access quickly, such as in-progress executions and
their status.
Erlang Redirects Erlang input and output streams on Unix systems.

Erlang runs the SO Web application.
Erlang Runtime Used by RabbitMQ and SO Web servers
Java Runtime Used by Cassandra and Elasticsearch databases
Node.js Used to run Javascript code and custom scripts entered in the
SO Web UI. One process is used for each script task worker (5
script task workers available), one for each mustache worker (5
mustache workers available), and one more for playbook
validation, for a total of 11.
Cron Scheduler Daemon to execute scheduled commands, such as logrotate
SO Command-Line Interface (CLI)

The Security Orchestrator (SO) virtual appliance has a command-line interface (CLI) that
can be used to configure the system, monitor and manage system services and logs, install
and upgrade software, and create and restore snapshots.
Using GNU Screen

If you use GNU Screen to run Security Orchestrator commands, some commands that use
Python might fail to execute and report errors when loading libraries. This occurs because
GNU Screen runs with setuid and resets LD_LIBRARY_PATH for security reasons.
© 2019 FireEye 11
SO System Administration Guide CHAPTER 1: About Security Orchestrator
The error reported by Python is:

python: error while loading shared libraries: libpython2.7.so.1.0:
cannot open shared object file: No such file or directory
The workaround is to add the following line to ~ixoperator/.screenrc:

shell -$SHELL
Then restart any existing GNU Screen sessions.
SO Web UI
The Security Orchestrator (SO) virtual appliance has a Web UI that can be used to build
courses of action (COAs), manage cases generated by COAs, view metrics, manage users,
and monitor system status.
For information on managing user access from the Web UI, see About User Management
on page 69. For more information about the Web UI, see the Security Orchestrator Playbook
Management Guide.
Web Browser Support

Follow these guidelines when choosing a Web browser to access the Security Orchestrator
Web UI.
Supported
The following browsers have been tested and approved for use with Security Orchestrator:
l Google Chrome versions 55 through 60

l Mozilla Firefox versions 54 through 55
Later versions of Chrome and Firefox should function properly but have not been tested.
Not Supported
The following browsers are not supported because of known issues with Security
Orchestrator:
l Microsoft Internet Explorer

l Microsoft Edge
12 © 2019 FireEye
SO System Administration Guide Virtual Appliance Requirements
CHAPTER 2: System
Requirements
Before you deploy a Security Orchestrator virtual appliance, make sure the following
requirements are met.
Virtual Appliance Requirements

Verify that the following resource requirements for the virtual appliance are met:
Resource Minimum Requirement
Processor 64-bit quad-core processor
Memory (RAM) 32 GB
Disk space 220 GB
Network Requirements
The following communications will be required to allow the virtual machine to
communicate.
Description Source Destination Protocol Port
DNS resolution SO virtual appliance Internal DNS servers TCP/UDP 53

(eth0)
NTP SO virtual appliance Trusted NTP servers UDP 123

(eth0)
CLI using SSH Admin workstation SO virtual appliance TCP 22

(eth0)
© 2019 FireEye 13
SO System Administration Guide CHAPTER 2: System Requirements
Access to the SO Admin and analyst SO virtual appliance TCP 443

Web UI workstation (eth0)
The following communications are optional. You can install and configure SNMP as part
of your Security Orchestrator deployment; it is not installed by default. For more
information, see SNMP on page 55.
SNMP polling for SO SNMP Manager SO virtual appliance UDP 161

Web UI (eth0)
SNMP traps for SO SO virtual appliance SNMP Manager UDP 162

Web UI (eth0)
14 © 2019 FireEye
PART II: Deployment
l Deployment Checklist on page 17

l Virtual Appliance Installation on page 19
l Plug-In Installation on page 31
l Configuration on page 43
© 2019 FireEye 15
SO System Administration Guide PART II: Deployment
16 © 2019 FireEye
CHAPTER 3: Deployment
Checklist
Follow these steps to install and configure Security Orchestrator.
Task Details
Step 1: See System Requirements on page 13.

Verify that your environment
meets the necessary
requirements.
Step 2: 1. Download the deployment files. See Obtaining

Set up your SO virtual appliance. the SO Deployment Files on page 19.
2. Install the virtual appliance. See Installing the
SO Virtual Appliance on page 20.
3. Perform the initial configuration. See
Configuring the SO Virtual Appliance at
Initial Startup on page 21.
4. Configure date and time settings. See Setting
the Date and Time on the SO Virtual
Appliance on page 26.
Step 3: See Accessing the Web UI on page 27.

Access the SO Web UI.
Step 4: See About User Management on page 69.

Configure user access to the SO
Web UI.
Step 5: See the following sections:

Install SO plug-ins. l Plug-In Installation on page 31
l Plug-In Installation Checklist on page 31
© 2019 FireEye 17
SO System Administration Guide CHAPTER 3: Deployment Checklist
Task Details
Optional Configuration Steps:
Configure secure shell See Remote Access with Secure Shell (SSH) on
(SSH) authentication. page 50.
Configure firewall settings for the See Firewall Configuration on page 47.

SO virtual appliance, as needed.
Configure a custom SSL See SSL Configuration on page 49.

certificate.
Install and configure SNMP. See SNMP on page 55.
18 © 2019 FireEye
SO System Administration Guide Obtaining the SO Deployment Files
CHAPTER 4: Virtual Appliance

Installation
This section describes how to initially install and configure your Security Orchestrator
virtual appliance.
This section includes the following topics:
l Obtaining the SO Deployment Files below

l Installing the SO Virtual Appliance on the next page
l Configuring the SO Virtual Appliance at Initial Startup on page 21
l Setting the Date and Time on the SO Virtual Appliance on page 26
l Accessing the Web UI on page 27
l Troubleshooting Web UI Access Issues on page 28
For information on upgrading the virtual appliance, see Upgrading Software on page 101.
Obtaining the SO Deployment Files

To obtain the SO deployment files:
1. Download the following files from the FireEye Customer Service Portal:
l SO Release Readme file, which contains the SHA-256 checksums for the SO
deployment files
l SO virtual appliance, fso-system-4.2.x-<rev>.el6.ova
l SO login credentials for the virtual appliance,
fso-system-4.2.x-ova-credentials.zip, which contains the FSO_Access_
Credentials_Readme file
2. Verify SHA-256 checksums for the SO virtual appliance and login credentials files.
© 2019 FireEye 19
SO System Administration Guide CHAPTER 4: Virtual Appliance Installation
Installing the SO Virtual Appliance

A Security Orchestrator (SO) virtual appliance is a virtual instance of the SO system image.
You deploy the SO virtual appliance using a hypervisor product. The following
instructions use the VMware ESXi hypervisor as an example.
This document assumes familiarity with deploying virtual machines and

administering ESXi hosts. This document provides the basic steps for creating
and deploying a Security Orchestrator virtual appliance. For comprehensive
information about deploying virtual machines, see the documentation provided
by VMware, Inc.
Prerequisites
l Root user account on an ESXi server
l Familiarity with deploying virtual machines and administering ESXi hosts
l Virtual Appliance Requirements on page 13
l Virtual appliance deployment files. See Obtaining the SO Deployment Files on the
previous page.
This section describes how to install a virtual appliance.
This procedure uses VMware ESXi version 6.0.0 (build 3568940) and vSphere
Client version 6.0.0 (build 3562874) on VMware vCenter Server version 6.0.0
(build 3018524). The navigation instructions and user interface may vary based
on your version of these products.
This procedure covers the required settings for a FireEye virtual appliance. You
can accept the default values for the other settings, or specify values that are
appropriate for your setup.
To install a virtual appliance:
1. Log in to vSphere Client.

2. From the File menu, select Deploy OVF Template to start the wizard.
3. On the Source screen, click Browse and navigate to the OVA file containing the
Security Orchestrator system image. Then click Next.
4. On the OVF Template Details screen, review the information. If the information is
correct, click Next. Otherwise, click Back and enter the correct URL or path.
5. On the Name and Location screen, enter a unique name that describes the virtual
appliance.
6. On the Disk Format screen, click Next.
20 © 2019 FireEye
Release 4.2 Configuring the SO Virtual Appliance at Initial Startup
7. On the Network Mapping screen, click Next to accept the default settings.
8. On the Ready to Complete screen:
a. Verify the information.
b. (Optional) Select the Power on after deployment check box.
c. Click Finish.
Configuring the SO Virtual Appliance at

Initial Startup
Follow these steps when you boot the Security Orchestrator (SO) virtual appliance for the
first time.
Before You Begin

Collect the following information:
l Hostname for the SO virtual appliance

l Static IP address (IPv4) for the SO virtual appliance, if not using DHCP
l Netmask (subnet mask), if not using DHCP
l Default gateway IP address, if not using DHCP
l IP addresses for primary, secondary, and tertiary DNS servers
l IP address and fully qualified domain name (FQDN) that will be used to access the
SO Web UI
To initially configure the SO virtual appliance:
1. Power on the SO virtual appliance, if it is not already on.

2. Log in as the ixoperator user with the default password provided in the FSO_
Access_Credentials_Readme file (in fso-system-4.2.x-ova-credentials.zip).
The system immediately prompts you to change the ixoperator's password.
3. Change the password for the ixoperator user.
4. Run the following command to configure the appliance's network interface, DNS
servers, and hostname:
$ sudo fso-host-config
The system prompts you for the ixoperator password. Enter the password to
continue.
© 2019 FireEye 21
The Select Action screen appears:
5. Select Device configuration in the list, and then press Enter.

The Select a Device screen appears:
22 © 2019 FireEye
6. Select the eth0 device in the list, and then press Enter.
The Network Configuration screen appears:
© 2019 FireEye 23
7. Configure the following network settings:

Setting Description
Name Default: eth0. Default value is recommended.
Device Default: eth0. Default value is recommended.
Use DHCP DHCP is on by default. However, the use of DHCP is

generally not recommended. If DHCP is selected, you
will not enter the Static IP, Netmask, or Default gateway
IP values.
Static IP This is the IP version 4 address that will be used. If

there is already an IP configured, or if one was received
via DHCP, then it will show as the default value.
Netmask This is the dotted quad notation for the subnet mask.
The default value is what was detected via DHCP or
255.255.255.0, if nothing was detected.
Default gateway IP This is the default gateway to use for IP communication.
Primary DNS Server Leave empty. You will enter this value on the

DNS Configuration screen.
Secondary DNS Server Leave empty. You will enter this value on the

DNS Configuration screen.
Peer DNS If Yes, the system automatically adds nameserver

entries to the resolv.conf file.
On boot Yes is recommended. If Yes, this device will be

activated at boot time.
Controlled by This setting has no effect. Network Manager is not

NetworkManager installed on the SO virtual appliance.
8. Select OK to continue.
9. On the Select a Device screen, select Save.
24 © 2019 FireEye
10. On the Select Action screen, select DNS configuration in the list, and then press
Enter.
The DNS Configuration screen appears:
11. Configure the following DNS settings:

Setting Description
Hostname Enter the host portion of the domain name to set the system
name. Do not enter periods or dots. Default: fso
For example, if the full domain name is
myfsoserver.mydomain.com, enter myfsoserver as the
hostname.
Primary DNS This is the IP address of the primary DNS server. This will be
saved as a nameserver entry in /etc/resolv.conf.
Secondary DNS This is the IP address of the secondary DNS server. This will
be saved as a nameserver entry in /etc/resolv.conf.
Tertiary DNS This is the IP address of the tertiary DNS server. This will be
saved as a nameserver entry in /etc/resolv.conf.
DNS search path List of domains to try when the appliance tries to translate a

machine name into an IP address. This will be saved as a
nameserver entry in /etc/resolv.conf.
12. Select OK to continue.
© 2019 FireEye 25
13. On the Select Action screen, select Save & Quit.

If you changed the hostname on the DNS Configuration screen, the system
automatically restarts.
14. If the system restarts, log in as the ixoperator user and then run the following
command to continue configuration:
$ sudo fso-host-config
The installer begins configuring system components.

15. When prompted for Hostname for the node, enter the fully qualified domain name
or the IP address for the SO virtual appliance. This value must match the Hostname
for the Web UI (entered in the next step) exactly.
The Hostname for the node and the Hostname for the Web UI must be
the same for the Web UI to run.
16. When prompted for Hostname for the Web UI, enter the same value used for the
Hostname for the node.
The initial configuration completes and then starts all system services.
17. Change the password for the root user:
a. Log out of the system with the following command:
$ exit
b. Log in as the root user with the default password provided in the FSO_
Access_Credentials_Readme file.
The system immediately prompts you to change the root password.
c. To change the root password, re-enter the current password and then enter
the new password.
All Security Orchestrator services and components should now be running and accessible.
Next, verify that the SO Web UI can be accessed. See Accessing the Web UI on the facing
page.
If any of the initial configuration information changes, such as the IP address, domain
name, hostname, or DNS information, see Manual Configuration on page 43 for
instructions on how to change these configuration settings manually.
Setting the Date and Time on the SO

Virtual Appliance
Ensure that the date and time setting on the SO virtual appliance is accurate. By default,
SO uses the NTP protocol to synchronize time with trusted time servers available online.
This may need to be adjusted to point to internal time servers. The configuration is in the
26 © 2019 FireEye
Release 4.2 Accessing the Web UI
/etc/ntp.conf file. By default, the following NTP servers are specified in the
/etc/ntp.conf file:
l server 0.fireeye.pool.ntp.org iburst
To check and correct date and time settings:
1. Log in to the SO virtual appliance as root.

2. To display the date and time, run the following command:
# date
3. If the date and time are not accurate, update the NTP servers in the /etc/ntp.conf
file. To open the file for editing, run the following command:
# vi /etc/ntp.conf
4. After making changes to the /etc/ntp.conf file, restart the NTP service by running
the following command:
# service ntpd restart
You can also force an immediate time synchronization at any time by restarting the
ntpd service with the command above.
Accessing the Web UI

The Security Orchestrator (SO) Web UI uses HTTPS to provide a secure connection with the
SO virtual appliance. You access the Web UI by directing a browser to the SO Web UI IP
address or hostname using HTTPS. The IP address and hostname are set during the initial
configuration of the SO virtual appliance. The hostname must be resolved by a DNS server
if you use it to access the Web UI.
Prerequisites
l The IP address or hostname for the SO Web UI
l A supported Web browser. See Web Browser Support on page 12.
To access the SO Web UI for the first time:
1. Open a Web browser and enter https://<virtualappliance> in the address line,

where <virtualappliance> is the IP address or hostname configured during initial
setup of the SO virtual appliance.
© 2019 FireEye 27
If you cannot access the SO login page or receive an error message, see
Troubleshooting Web UI Access Issues below.
2. Enter the following user name and password the first time you log in to the Web UI:
l User name: admin
l Password: changeme
After you log in to the Web UI the first time, change the password.
To change the password:
1. In the upper right corner, point to ISO Admin (or the user's name) and then select
Change Password.
2. In the Previous Password box, enter the current password.
3. In the New Password and Confirm Password boxes, enter a new password.
4. Click Apply.
Troubleshooting Web UI Access Issues

If users encounter issues when trying to access or use the SO Web UI, review the following
sections that describe common problems and solutions.
28 © 2019 FireEye
Release 4.2 Troubleshooting Web UI Access Issues
Red Hat Enterprise Linux Test Page

If you see the following Red Hat Enterprise Linux Test Page, it means that the Apache Web
server is running but cannot reach the specified application host:
The most common reason for this problem is that a hostname was used for the AppHost
in the /opt/rh/httpd24/root/etc/httpd/conf.d/zzz-fso-system.conf file and the
server is unable to resolve that hostname to an IP address. The solution is to add the
appropriate entry in the /etc/hosts file to ensure that SO can resolve the IP address of
that hostname without relying on external DNS. See the steps for updating the /etc/hosts
file in Hostname Configuration on page 44.
Unresponsive Web UI
If the Web UI is unresponsive, first try reloading the browser page by clicking the browser's
Reload button (or pressing F5). This may resolve issues such as difficulty logging in or
changes not being saved. For further troubleshooting, you can open the browser’s
developer console (F12 in Chrome, Ctrl-Shift-K or Cmd-Opt-K for Firefox). This console
displays any HTTP or HTML errors encountered while loading the current page, which
may help you identify the underlying issue.
© 2019 FireEye 29
Service Unavailable Message

The following error indicates that the Apache Web server is reachable but the SO Web
application is not running or not responding:
This typically means the SO service is not started. The solution is to restart the services as
described in Managing Services on page 89.
Site Can’t Be Reached Error

The following error often indicates that the Apache Web server could be reached and the
browser was redirected to an unreachable host:
Common causes of this include:
l Firewall blocking the connection

l DNS is not resolving the hostname
l Subnet mask or routing issue
If the hostname in the address bar appears to be incorrect, then this error is likely caused
by a misconfigured setting in the /etc/fireeye/fso/web.conf file. See the steps for
updating the /etc/fireeye/fso/web.conf file in Hostname Configuration on page 44.
30 © 2019 FireEye
SO System Administration Guide Plug-In Installation Checklist
CHAPTER 5: Plug-In Installation

This section describes how to install plug-ins needed for your Security Orchestrator
deployment. You can also upgrade plug-ins by following the instructions provided in this
section.
FireEye distributes plug-ins and supporting software in monthly Security Orchestrator
Content releases. Content releases include the following:
l General availability (GA) plug-ins

l Early access (EA) plug-ins
l A Content installer that installs plug-ins and their dependencies
l Content management tools for uninstalling plug-ins and viewing configured content
For instructions on installing plug-ins with the Content installer, see the Plug-In
Installation Checklist below.
For instructions on installing plug-ins not distributed as part of a Content release, see
Installing Plug-Ins and Dependencies Independently on page 39.
For instructions on uninstalling plug-ins, see Uninstalling Plug-Ins on page 38.
Changing a device's plug-in version in the SO Web UI may invalidate playbooks

and adapters. For more information, see the Security Orchestrator Playbook
Management Guide and Content Release Notes.
Plug-In Installation Checklist

Follow these steps to install plug-ins, and review Content Installer Arguments on page 33
for descriptions of required and optional installer arguments.
© 2019 FireEye 31
SO System Administration Guide CHAPTER 5: Plug-In Installation
Task Details
Step 1: See Obtaining Plug-In Installation Packages on

page 34.
Get and extract the plug-in
installation package.
Step 2: See Listing Plug-Ins Available for Installation on

page 34.
List the plug-ins available in
the installation package.
Step 3: Before installing plug-ins:

Prepare to install plug-ins by 1. Disable all devices used in active adapters or
disabling devices and closing playbooks. For instructions, see the Security
all SO Web UI sessions. Orchestrator Playbook Management Guide.
2. Close all Web browsers running the SO Web UI.
Step 4: See the following sections:

Install plug-ins by name, l Installing Plug-Ins by Name on page 35
vendor, or category.
l Installing Plug-Ins by Vendor on page 35
l Installing Plug-Ins by Category on page 35
Step 5: (Optional) See Installing All Plug-Ins on page 36.

Install all plug-ins distributed
in a Content release.
Step 6: After installing plug-ins:

After installing plug-ins, restart 1. Restart the Security Orchestrator service with
Security Orchestrator and re- the service fso restart command. For more
enable devices. information, see Managing Services on page 89.
2. Wait for all command and script workers to
load before re-enabling devices. For worker
statuses, see the System Status page in the SO
Web UI.
3. Re-enable disabled devices.
For more information about devices and the Web UI,

see the Security Orchestrator Playbook Management Guide.
Step 7: See Verifying Installed Plug-Ins on page 37.

Verify installed plug-ins.
32 © 2019 FireEye
Release 4.2 Content Installer Arguments
Content Installer Arguments

You must specify either the online or offline argument when running the Content
installer. Offline installation should be used in environments without full Internet
connectivity. For online installation, Internet connectivity is required.
./fso_content_install [-l|--online] [-o|--offline] [-f|--force-reinstall]

[-g|--general-availability] [-e|--early-access] [-d|--only-dependencies]
[-i|--plugins-info] [-n|--name] [-m|--vendor] [-c|--category]
[-v|--verbose] [-V|--version] [-h|--help]
Argument Description
Required
-l, --online Online installation of general availability (GA) and
early access (EA) plug-ins and dependencies. Internet
connectivity is required for online installations.
-o, --offline Offline installation of general availability (GA) and
early access (EA) plug-ins and dependencies. The
offline installation package is required for offline
installations.
Optional
-f, --force-reinstall Force the reinstallation of plug-ins and dependencies.
-g, --general-availability Install only general availability (GA) plug-ins and
dependencies.
-e, --early-access Install only early access (EA) plug-ins and
dependencies.
-d, --only-dependencies Install plug-in dependencies only.
-i, --plugins-info List plug-ins included in the content installation
package.
-n, --name Install plug-in based on name with dependencies.
-m, --vendor Install plug-ins based on vendor with dependencies.
-c, --category Install plug-ins based on category with dependencies.
-v, --verbose Enable verbose mode.
-V, --version Print installer version information.
© 2019 FireEye 33
-h, --help Print installer help.
Obtaining Plug-In Installation Packages

To obtain an SO plug-in installation package:
1. Download the following files from the FireEye Customer Service Portal:
l SO Content Release Readme file, FSO_Plugins_Content_Bundle_Release_
Readme_<yyyy>_<mm>, which contains the SHA-256 checksums for the plug-in
installation files.
l SO Content online installation package, fso-plugins-<version>.tar.gz.
Internet connectivity is required during installation when you use the online
installation package.
l SO Content offline installation package,
fso-plugins-<version>-offline.tar.gz. The offline installation package
contains all plug-in dependency installation files, so Internet connectivity is
not required during installation.
2. Verify SHA-256 checksums for the SO plug-in installation files.
4. Copy the online or offline Content installation package to the SO virtual appliance.
5. Extract the Content installation package:
# tar -xvf /filepath/fso-plugins-<version>.tar.gz
Listing Plug-Ins Available for Installation

To list plug-ins available in an installation package:

2. Go to the Content installer directory:
# cd fso-plugins-<version>
3. To list all plug-ins in the installation package, run the following command:
# ./fso_content_install --plugins-info
4. If you plan to install specific plug-ins by name, vendor, or category, note the plug-in
names and categories. (The plug-in vendor is the first part of the plug-in name.)
34 © 2019 FireEye
Release 4.2 Installing Plug-Ins by Name
Installing Plug-Ins by Name

Online installation requires Internet connectivity.
To install plug-ins by name:

3. To install a plug-in and its dependencies, run the following command (online
installation examples):
# ./fso_content_install --online --name <plug-in name>
For example, to install the FireEye HX (version 2.2.2) plug-in, run the following
command:
# ./fso_content_install --online --name fireeye.hx.2.2.2
Installing Plug-Ins by Vendor

To install plug-ins by vendor:

3. To install all plug-ins and dependencies for a specific plug-in vendor, run the
following command (online installation examples):
# ./fso_content_install --online --vendor <vendor name>
The plug-in vendor is the first part of the plug-in name. For example, to install
all plug-ins that integrate FireEye appliances and services, run the following
command:
# ./fso_content_install --online --vendor fireeye
Installing Plug-Ins by Category

To install plug-ins by category:
© 2019 FireEye 35

3. To install all plug-ins and dependencies for a specific plug-in category, run the
following command (online installation examples):
# ./fso_content_install --online --category <plug-in category>
Plug-in categories are not case sensitive. For example, to install all plug-ins in the
ThreatIntel category, run the following command:
# ./fso_content_install --online --category threatintel
If the plug-in category contains two or more words separated by spaces, enter the
first word only. For example, to install plug-ins in the Malware Analysis category,
run the following command:
# ./fso_content_install --online --category malware
Installing All Plug-Ins

To perform an offline installation of all plug-ins:
To perform offline installations, you must use the offline installation package. For more
information, see Obtaining Plug-In Installation Packages on page 34.

# cd fso-plugins-<version>-offline
3. To install all GA and EA plug-ins and dependencies, run the following command:
# ./fso_content_install --offline
Other examples:
l To install only GA plug-ins and dependencies, run the following command:
# ./fso_content_install --offline --general-availability
l To install only EA plug-ins and dependencies, run the following command:

# ./fso_content_install --offline --early-access
To perform an online installation of all plug-ins:


3. To install all GA and EA plug-ins and dependencies, run the following command:
# ./fso_content_install --online
Other examples:
36 © 2019 FireEye
Release 4.2 Verifying Installed Plug-Ins
l To install only GA plug-ins and dependencies, run the following command:

# ./fso_content_install --online --general-availability
l To install only EA plug-ins and dependencies, run the following command:

# ./fso_content_install --online --early-access
Verifying Installed Plug-Ins

Ensure that plug-ins have been installed correctly by checking the status of installed
plug-ins using the SO Web UI or CLI.
To check the status of installed plug-ins using the Web UI:
1. Log in to the SO Web UI as the admin user. See Accessing the Web UI on page 27.
2. In the Web UI, click Plug-Ins.
Multiple versions of a plug-in can be installed and available at the same

time. If multiple versions of a plug-in are installed, each plug-in version is
shown on a separate row.
3. Review the list of plug-ins, and ensure that warning icons do not appear in the list.
A red warning icon appears next to invalid plug-ins. A plug-in may be
invalid because it is not properly installed, its supporting third-party
modules are not installed, or it is incompatible with Security Orchestrator.
If this occurs, force the reinstallation of the plug-in and its dependencies
using the --force-reinstall argument, discussed in Content Installer
Arguments on page 33.
To check the status of installed plug-ins using the CLI:

The Cassandra driver must be installed to run the check-plugins command.
1. Log in to the SO virtual appliance as ixoperator.
2. Change to the plug-in development environment:

$ source /opt/fireeye/fso/config/iso_package_dev_env
3. List all installed plug-ins with their statuses:

$ check-plugins
4. To exit the plug-in development environment, run the following command:

$ deactivate
For instructions on viewing configured devices, adapters, and playbooks using

the CLI, see Viewing Content on page 99.
© 2019 FireEye 37
Loading Content Management Tools

Security Orchestrator Content releases include content management tools, the fsocontent
commands, that allow you to uninstall plug-ins, check the content version, and display
information about configured devices, adapters, and playbooks from the command line.
The content management tools are installed the first time you install plug-ins using the
Content installer (distributed in Content release 1.2.4 and later). However, the content
management tools cannot be used until you load the tools, as described in the following
procedure, or start a new terminal session for the SO virtual appliance.
To load the content management tools (the fsocontent commands):
l While logged in to the SO virtual appliance as ixoperator or root, run the

following command:
$ source /etc/profile
For instructions on using the content management tools, see Uninstalling Plug-Ins
below and Viewing Content on page 99.
Uninstalling Plug-Ins
To display information about the uninstaller tool, you can run the following command
(while logged in as ixoperator):
$ fsocontent uninstall --help
If the fsocontent command is not recognized or returns an error, see Loading

Content Management Tools above.
To uninstall specific plug-ins by name:

2. To list all installed plug-ins, run the following command:
$ fsocontent uninstall --specific --verbose
3. In the list, select the plug-ins you want to uninstall:

l To navigate the list, use the Up Arrow and Down Arrow keys.
l To select a plug-in, use the Spacebar. Other keyboard options for selecting
and deselecting multiple plug-ins are shown on screen.
4. Press Enter to continue.
The selected plug-ins are listed for confirmation.
5. Press Y to confirm that you want to uninstall the selected plug-ins.
38 © 2019 FireEye
Release 4.2 Installing Plug-Ins and Dependencies Independently
To uninstall all unused plug-ins without configured devices:

2. To list all plug-ins without configured devices, run the following command:
$ fsocontent uninstall --unused --verbose
3. Press A to select all plug-ins in the list.

4. Press Enter to continue.
The selected plug-ins are listed for confirmation.
5. Press Y to confirm that you want to uninstall the selected plug-ins.
Installing Plug-Ins and Dependencies

Independently
You can use the commands in this section to install plug-ins and their dependencies
independently, instead of using the Content installer command described in Content
Installer Arguments on page 33. You must use the commands in this section if you are
installing or uninstalling plug-ins not distributed by FireEye as part of a Security
Orchestrator Content release or if your Security Orchestrator system is not compatible with
the Content installer and uninstaller.
Before installing plug-ins:
l Disable all devices used in active adapters or playbooks.

l Close all Web browsers running the Security Orchestrator Web UI.
After installing plug-ins:
l Restart Security Orchestrator with service fso restart. For more

information, see Managing Services on page 89.
l Before re-enabling devices, wait for all Python workers to load.
© 2019 FireEye 39
Installing Plug-Ins (fso package command)

Follow these steps to install a plug-in with the fso package install command.
To install plug-ins with the fso package command:

2. To install a plug-in package, run the following command:
$ fso package install [--force-reinstall] (<path> | <package_file>)
--force-reinstall Forces the reinstallation or update of a plug-in package.
<path> Path to a directory containing the SO plug-in package files
to install. All plug-in packages in the directory will be
installed.
<package_file> Location and name of a single SO plug-in package file to

install, including the full package file name with the file
extension.
Installing Third-Party Modules

Follow these steps to install third-party modules (dependencies) required by plug-ins.
To install third-party modules:

2. Change to the plug-in development environment:
$ source /opt/fireeye/fso/config/iso_package_dev_env
3. Install any third-party Python modules that are required by a plug-in:

$ pip install <third_party_module_name>
Ensure that plug-ins and their dependencies were properly installed by following the
instructions in Verifying Installed Plug-Ins on page 37.
Uninstalling Plug-Ins (fso package command)

Follow these steps to uninstall a plug-in with the fso package uninstall command. If a
plug-in was installed with the Content installer (./fso_content_install), you should
uninstall it with the fsocontent uninstall command as described in Uninstalling Plug-
Ins on page 38.
40 © 2019 FireEye
Release 4.2 Installing Plug-Ins and Dependencies Independently
To uninstall a plug-in with the fso package command:

2. To list the installed plug-ins, run the following command:
$ fso package list
3. Note the name of the plug-in package you want to uninstall, including the full
plug-in name and version.
4. To uninstall the plug-in, run the following command:
$ fso package uninstall <package_name>
where <package_name> is the name of the plug-in package to uninstall. The package
name includes the full plug-in name, with the plug-in vendor and version.
© 2019 FireEye 41
42 © 2019 FireEye
SO System Administration Guide Manual Configuration
CHAPTER 6: Configuration
The steps in this section are not required. They are provided for reference and
troubleshooting purposes.
This section covers the following topics:
l Manual Configuration below

l Remote Access with Secure Shell (SSH) on page 50
l SNMP on page 55
Manual Configuration
This section covers the following topics:
l Networking Configuration below

l Hostname Configuration on the next page
l Web Configuration on page 46
l Firewall Configuration on page 47
l SSL Configuration on page 49
Networking Configuration
You can update network configuration settings in the ifcfg-eth0 file. The following is an
example of the file's contents:
DEVICE=eth0
BOOTPROTO=none
DHCP_HOSTNAME="myfsoserver"
HOSTNAME="myfsoserver"
IPV6INIT=yes
MTU=1500
NM_CONTROLLED=yes
© 2019 FireEye 43
SO System Administration Guide CHAPTER 6: Configuration
ONBOOT=yes
TYPE=Ethernet
UUID="ab222222-1cde-2200-12c1-1c1abc987456"
IPADDR=192.168.111.111
HWADDR=00:0a:11:22:d1:33
NETMASK=255.255.255.0
GATEWAY=192.168.111.1
DNS1=8.8.8.3
DNS2=8.8.8.4
USERCTL=no
PEERDNS=yes
To update network configuration settings:

2. Enter the following command to open the ifcfg-eth0 file for editing:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
3. Update the IP address, hostname, netmask, gateway, and DNS as needed.

4. Restart network services using the following commands:
# service network stop
# service network start
Hostname Configuration
Follow these steps to change the Security Orchestrator hostname or check the current
configuration, after you have initially configured the virtual appliance.
To reconfigure the SO hostname manually:

2. Run the following command to stop the fso service:
# service fso stop
3. Change the hostname in the /etc/sysconfig/network file:

a. Run the following command to open the file for editing:
# vi /etc/sysconfig/network
b. Modify the HOSTNAME line to reflect the desired hostname. Do not use a fully
qualified domain name for the hostname since dots in the hostname prevents
RabbitMQ from starting.
In the following example, myfsoserver is the hostname:
NETWORKING=YES
HOSTNAME=myfsoserver
c. Save and exit the file.
44 © 2019 FireEye
Release 4.2 Manual Configuration
4. Reconfigure the hostname and IP address in the /etc/hosts file:

# vi /etc/hosts
b. At the end of the first line, modify the hostname as desired.

In the following example, myfsoserver is the hostname at the end of the first
line:
127.0.0.1 localhost localhost.localdomain localhost4
localhost4.localdomain4 myfsoserver
c. Update or add a line containing the server's actual IP address, the hostname,
and the fully qualified domain name.
For example:
192.168.0.1 myfsoserver myfsoserver.mydomain.com
d. Save and exit the file.

5. Change the Web URL in the /etc/fireeye/fso/web.conf file:
# vi /etc/fireeye/fso/web.conf
b. Modify the following line to reflect the base URL of the server, using its
hostname or fully qualified domain name:
common.web_url = https://myfsoserver.mydomain.com

6. Change the Web URL in the /opt/rh/httpd24/root/etc/httpd/conf.d/zzz-fso-
system.conf file:

# vi /opt/rh/httpd24/root/etc/httpd/conf.d/zzz-fso-system.conf
b. Update the hostname in the Use AppHost line.

In the following example, myfsoserver is the hostname:
Use AppHost myfsoserver /opt/fireeye/fso/config
/opt/fireeye/fso/apps/web/priv/static localhost 4000

7. If a custom certificate and key are used for HTTPS, then generate a new key and
certificate with the certificate authority to match the new hostname. Save the key as
ssl.key, and save the certificate as ssl.crt in the following
directory: /opt/fireeye/fso/config/
8. Enter the following command to reboot the system:
# reboot
© 2019 FireEye 45
Web Configuration
You can locate the Web configuration files at: /etc/fireeye/fso/web.conf
Setting Description Default Value

core.hostname Can be a name, fully qualified domain IP or Hostname of the
name (FQDN), or IPv4 address. If a SO server
name or FQDN is used, it must be
resolvable to an IP address on the SO
server.
config.temporary_ Location on the SO server where all files /var/tmp/fso
files_rootdir
generated by a plug-in for consumption
internally to SO are stored.
common.web_url Configuration used internally by SO https://<IP/HostName>

Cases when resolving the “Case URL”
value. In most cases should match the
IP/hostname used in the core.hostname
field above.
common.encryption_ Unique base 64 encoded key used in all Unique per install
key
encrypted values stored internally to SO.
If this key is changed or lost,

SO will not be able to decode
encrypted values. Backup this
key and have it available
when migrating or restoring a
SO system. For more
information, see Managing
Snapshots on page 95.
engine.adapter_ Max time an adapter will allow a 60 seconds

command_timeout
plug-in command to run, will supersede
any configured value on the UI.
engine.task_ Max time a playbook device task will 60 seconds
command_timeout
allow a plug-in command to run. If a
plug-in has a long running command,
like submit file for analysis. This setting
must be lengthened to the max time that
command could take to complete.
46 © 2019 FireEye
Firewall Configuration
The SO virtual machine is hardened and includes strict firewall configuration. This may
prevent newly configured devices from working until a firewall rule is created to allow
traffic to the destination host. Similarly, when configuring socket adapters or HTTP listener
devices, additional inbound network ports will need to be opened. Use the iptables
command to create these firewall rules as shown in the following examples.
Best Practice: Whenever possible, specify the destination IP address for

outbound rules (-d <ip>) and the source IP for inbound rules (-s <ip>).
Allow Inbound Communication

The following commands allow the Security Orchestrator virtual appliance to receive
inbound communication from a system with IP address 192.168.1.1 on TCP port 6000:
sudo iptables -I INPUT -p tcp -m tcp --dport 6000 –s 192.168.1.1 6000 -m
comment --comment "This is an inbound example" -j ACCEPT
sudo service iptables save
Sample Inbound Firewall Rules

The rules added using these commands are applied immediately to the running
configuration but are not stored for persistent use. They must be saved in order for them to
persist after an iptables service restart.
Allow access to a Security Orchestrator socket adapter listening on TCP 4423:
sudo iptables -I INPUT -p tcp -m tcp --dport 4423 -j ACCEPT
Allow Outbound Communication

The following commands allow the Security Orchestrator virtual appliance to
communicate to a system with IP address 192.168.1.1 on TCP port 8080:
sudo iptables -I OUTPUT -p tcp -m tcp –dport 8080 -d 192.168.1.1/32 -m
comment --comment "This is an outbound example" -j ACCEPT
Sample Outbound Firewall Rules

The rules added using these commands are applied immediately to the running
configuration but are not stored for persistent use. They must be saved in order for them to
persist after an iptables service restart.
Allow access to a proxy at 10.0.0.2 listening on TCP 8080:
sudo iptables -I OUTPUT -p tcp -m tcp -d 10.0.0.2 --dport 8080 -j ACCEPT
Allow IMAP over TLS to any outbound address:

sudo iptables -I OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT
© 2019 FireEye 47
Allow POP3 to any outbound address:

Allow POP3 over TLS to any outbound address:

Allow SMTP to any outbound address:

Allow SMTP over TLS to any outbound address (depending on service):

Allow access to a third party Web API listening on TCP 8443 (e.g. McAfee ePO):
Allow access to Splunk:

Listing Rules
The firewall rules can be listed by chain (INPUT, FORWARD, OUTPUT) using the
following command:
sudo iptables -L
The individual rules can be listed using the following command:

sudo iptables --list-rules
Deleting a Rule
Using the --list-rules option, find the rule that you wish to delete. The rules will be
listed as arguments that can be passed to the sudo iptables command. Copy the desired
line and type or paste it into the sudo iptables command line as arguments but replace
the –A with a –D to delete rule instead of appending it. For example, the following
commands can be used to delete the sample outbound rule created above:
sudo iptables -D OUTPUT -p tcp -m tcp –dport 8080 -d 192.168.1.1/32 -m
comment --comment "This is an outbound example" -j ACCEPT
Backing Up the Existing Ruleset

Run the following command:
sudo iptables-save > <file_name>
Restoring from a Ruleset Backup

48 © 2019 FireEye
sudo iptables-restore < <file_name>
Saving All Applied Firewall Rules

This will save the currently applied rules to /etc/sysconfig/iptables, which is read
when the iptables service starts.
Stopping and Restarting the Firewall

When troubleshooting data access issues with Security Orchestrator, you may want to stop
the firewall to determine if the current firewall settings are the cause.
To stop the firewall, run this command:
sudo service iptables stop
To start the firewall, run this command:

sudo service iptables start
SSL Configuration
To configure the Security Orchestrator virtual appliance to use a custom certificate for
HTTPS:
1. Create a new certificate and key file pair in PEM format following instructions from
your Certificate Authority administrator.
2. The "subject" of the certificate is typically the hostname or fully qualified domain
name of the server. Ensure that the hostname resolves to the IP address of the SO
virtual appliance, from both the client system accessing the Web UI as well as from
the SO server itself.
3. Once you receive the files, name the certificate file ssl.crt and name the key file
ssl.key. This will save having to change the Apache configuration file, since we
are using the same file names.
4. Before copying the new certificate and key files over, back up the existing self-signed
certificate and key:
# mv /opt/fireeye/fso/config/ssl.crt
/opt/fireeye/fso/config/ssl.crt.orig
# mv /opt/fireeye/fso/config/ssl.key
/opt/fireeye/fso/config/ssl.key.orig
© 2019 FireEye 49
5. Stop Apache and SO services:

# service httpd24-httpd stop
# service fso stop
6. Copy the new ssl.crt and ssl.key files to /opt/fireeye/fso/config/.

7. Update the following configuration files to point to the subject hostname from the
certificate:
# vi /etc/fireeye/fso/web.conf
…
common.web_url = <https://your-ssl-cert-subject-hostname-here>
…
# vi /opt/rh/httpd24/root/etc/httpd/conf.d/zzz-fso-system.conf
…
Use AppHost <your-ssl-cert-subject-hostname-here>
/opt/fireeye/fso/config /opt/fireeye/fso/apps/web/priv/static localhost
4000
…
8. Start Apache and SO services:
# service httpd24-httpd start
# service fso start
Remote Access with Secure Shell (SSH)

This section contains:
l Configuring Remote Access Authentication below

l Generating RSA Keys for SSH Authentication on the facing page
l Connecting with PuTTy and Authorized Keys on page 52
Configuring Remote Access Authentication

By default, password-based authentication is enabled for remote SSH sessions to allow
users to log in remotely with a user name and password. For improved security, you can
turn off password-based authentication and allow users to connect with authorized key
authentication only. The setting is controlled in the /etc/ssh/sshd_config file. See the
example snippet below:
...
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
50 © 2019 FireEye
Release 4.2 Remote Access with Secure Shell (SSH)
PasswordAuthentication yes
...
Logging in through the console as root and changing PasswordAuthentication from yes to
no will prevent users from logging in remotely with a user name and password.
Generating RSA Keys for SSH Authentication

Use PuTTYgen to generate RSA keys for secure SSH authentication with OpenSSH. You
can use a pair of public and private keys to secure SSH access to the SO virtual appliance.
The private key provides 2048-bit encryption.
To generate RSA keys:
1. Download PuTTYgen from the PuTTY download page.

2. Open PuTTYgen on your desktop.
3. Click Generate to generate the public and private keys.
© 2019 FireEye 51
4. Enter a unique key passphrase and then confirm the passphrase in the Key
passphrase and Confirm passphrase fields.
5. Click Save public key to save the public key.
6. Click Save private key to save the private key.
7. Copy all the characters in the Public key for pasting into OpenSSH authorized_
keys file area. You need this key to allow the ixoperator user to log in to the SO
virtual appliance.
Connecting with PuTTy and Authorized Keys

The following steps can be used to configure PuTTy to use key-based authentication.
1. Launch PuTTy and navigate to Connection->SSH->Auth and click on the Browse

button.
52 © 2019 FireEye
Release 4.2 Remote Access with Secure Shell (SSH)
2. Navigate to the desired PuTTY Private Key File (*.ppk), select it, and then click
Open.
3. The full path to the chosen ppk file is now shown in the Private key file for
authentication: field. Click on Session from the Category list at the top left.
© 2019 FireEye 53
4. Enter the hostname or IP address in the required field and type in a name for the
session in the Saved Sessions field, then click on Save.
5. Click on Open to start the session.

6. If this is the first connection to the SO device, you will be prompted to accept the
target hosts key. Click on Yes.
54 © 2019 FireEye
Release 4.2 SNMP
7. You will be presented with a login prompt. Enter the user name associated with the
key file, and the key file passphrase provided in the credentials ZIP file.
You should now have access to the SO command line.
SNMP
Simple Network Management Protocol (SNMP) is an Internet-standard protocol for
collecting and organizing information about managed devices on IP networks and for
modifying that information to change device behavior. SNMP is widely used in network
management for network monitoring.
SNMP exposes management data in the form of variables on the managed systems
organized in a management information base (MIB) which describe the system status and
configuration. These variables can then be remotely queried (and, in some circumstances,
manipulated) by managing applications.
This section covers the following information:
l SNMP Installation below

l SNMP Configuration and Monitoring on the next page
SNMP Installation
SNMP is not installed in an out-of-the-box installation of Security Orchestrator. This is to
ensure that only appropriate deployments have SNMP installed and enabled. To use
SNMP, install SNMP and related utilities and then update the host firewall ruleset to allow
inbound traffic on UDP ports 161 and 162.
© 2019 FireEye 55
Installing SNMP
To install SNMP on an appliance with Internet access:

2. Install SNMP and SNMP utilities by running the following command:
# yum -y install net-snmp net-snmp-utils
3. Enable snmpd, the SNMP daemon, by running the following command:

# chkconfig snmpd on
4. Start the snmpd service by running the following command:

# service snmpd start
To install SNMP on an appliance without Internet:
1. Download the following files:

l http://mirror.centos.org/centos/6/os/x86_64/Packages/lm_sensors-3.1.1-
17.el6.x86_64.rpm
l http://mirror.centos.org/centos/6/os/x86_64/Packages/net-snmp-5.5-60.el6.x86_
64.rpm
l http://mirror.centos.org/centos/6/os/x86_64/Packages/net-snmp-libs-5.5-
60.el6.x86_64.rpm
l http://mirror.centos.org/centos/6/os/x86_64/Packages/net-snmp-utils-5.5-
60.el6.x86_64.rpm
2. Copy the downloaded files to the SO virtual appliance using secure copy (scp).
4. Change to the directory where the SNMP RPM files are located.
5. Install SNMP and SNMP utilities by running the following command:
# yum install *.rpm --disablerepo=*
6. Enable snmpd, the SNMP daemon, by running the following command:

# chkconfig snmpd on
7. Start the snmpd service by running the following command:

# service snmpd start
SNMP Configuration and Monitoring
Updating Host Firewall Rules

Once the SNMP tools are installed and configured the next step is to configure the host
firewall on Security Orchestrator virtual appliance to accept SNMP traffic. The SNMP
client needs to listen on UDP port 161 and UDP port 162.
56 © 2019 FireEye
Release 4.2 SNMP
The operator user can do this by running the following commands:

sudo iptables -I INPUT -p udp -m udp --dport 161 -j ACCEPT
sudo iptables -I INPUT -p udp -m udp --dport 162 -j ACCEPT
sudo /sbin/service iptables save
Updating SNMPD Configuration
The ixoperator user has been provisioned such that the user can perform privileged tasks
(listed below) necessary for management of the SNMP agent installed on the Security
Orchestrator virtual appliance.
l To start and stop SNMP related services, use the following:

snmpd
l To edit SNMP related configuration settings, use the following:

/etc/snmp/snmpd.conf
l To run SNMP utilities, use the following:

/usr/bin/net-snmp-create-v3-user
SNMP Read Configuration for SNMP v2

SNMP v2 and v3 connections are available on the Security Orchestrator virtual appliance.
SNMP v2 connection is used in the following examples to pool SNMP data.
The following settings must be configured in the snmpd.conf file to pool data from Security
Orchestrator virtual appliance. testCommunityString was chosen for the v2 community
string, so the same string is required in the Monitor Application settings to establish
SNMP connection:
# ssh ixoperator@<SO-SERVER>
# sudoedit /etc/snmp/snmpd.conf
…………
####
# First, map the community name "public" into a "security name"
# sec.name source community
com2sec notConfigUser default testCommunityString
####
# Second, map the security name into a group name:
# groupName securityModel securityName
#group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
####
# Third, create a view for us to let the group have rights to:
# Make at least snmpwalk -v 1 localhost -c public system fast again.
© 2019 FireEye 57
# name incl/excl subtree mask(optional)

view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
view systemview included .1.3.6
SNMP Process Monitoring Configuration

The SNMP process monitoring feature is enabled on the Security Orchestrator virtual
appliance, but the settings need to be modified to specify process names, to perform correct
monitoring at the Monitoring Application. Process details are listed under the
configuration changes:
# sudoedit /etc/snmp/snmpd.conf
…………
####################################################################
# Process checks.
#
# The following are examples of how to use the agent to check for
# processes running on the host. The syntax looks something like:
#
# proc NAME [MAX=0] [MIN=0]
#
# NAME: the name of the process to check for. It must match
# exactly (ie, http will not find httpd processes).
# MAX: the maximum number allowed to be running. Defaults to 0.
# MIN: the minimum number to be running. Defaults to 0.
#
# Examples (commented out by default):
#
# Make sure mountd is running
#proc mountd
# Make sure there are no more than 4 ntalkds running, but 0 is ok.
#proc ntalkd 4
proc run_erl 1 1 # fso-web
proc beam.smp 2 2 # fso-web, rabbitmq
proc java 2 2 # cassandra elastic-search
proc node 12 2 # fso-web
proc rabbitmq-server 2 2 # rabbitmq; queue manager
proc epmd 1 1 # rabbitmq; queue manager
58 © 2019 FireEye
Release 4.2 SNMP
proc httpd 255 7 # httpd; http server

# A snmpwalk of the process mib tree would look something like this:
#
# % snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.2
Process Names Process Counts While Running Related SO Module
run_erl MAX=1 MIN=1 fso-web
beam.smp MAX=2 MIN=2 fso-web, rabbitmq
java MAX=2 MIN=2 cassandra, elastic-search
node MAX=12 MIN=2 fso-web
rabbitmq-server MAX=2 MIN=2 rabbitmq; queue manager
epmd MAX=1 MiN=1 rabbitmq, queue manager
httpd MAX=255 MIN=7 httpd, http server
Setting SNMPD Restart Rights

By default, the ixoperator account does not have the right to restart the snmpd service
using sudo. An additional sudoers file can be added for snmpd to allow ixoperator to
restart the service. It is not recommended to modify the fso default sudoers file.
# su
# vi /etc/sudoers.d/snmpd
## SNMPD service commands
Cmnd_Alias SNMPD_SERVICE = /sbin/service snmpd start, /sbin/service snmpd
stop, /sbin/service snmpd restart, /sbin/service snmpd status
## Allow ixoperator to run SNMPD service options
ixoperator ALL= SNMPD_SERVICE
Restarting SNMPD
The ixoperator user has been provisioned such that the user can perform privileged
tasks necessary for management of the SNMP agent installed on the Security Orchestrator
virtual appliance. A restart is required after making the above configuration changes:
# sudo service snmpd restart
© 2019 FireEye 59
The SNMP Monitoring Application

SNMP Monitoring Application provides complete monitoring of SNMP. SNMP is an
“agentless” method of monitoring network devices and servers, and is often preferable to
installing dedicated agents on target machines. Thousands of different network devices
and operating systems from different vendors support SNMP for delivering critical
information on health and usage metrics, service state, and more.
OID/MIB Entries of Process Monitoring

The following OID Numbers are required for the Monitoring application to continuously
monitor SO internal processes. The monitoring team can send email alerts as an alert
mechanism.
Example monitoring of ‘run_erl’ process with OID numbers:
Process Name :
# snmpwalk -v2c -On -c testCommunityString 10.11.222.333
.1.3.6.1.4.1.2021.2.1.2.1
.1.3.6.1.4.1.2021.2.1.2.1 = STRING: "run_erl"
Error Flag :
.1.3.6.1.4.1.2021.2.1.100.1
.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0
Min Run:
.1.3.6.1.4.1.2021.2.1.3.1
.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 2
Max Run:
.1.3.6.1.4.1.2021.2.1.4.1
.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 2
Current Run:
.1.3.6.1.4.1.2021.2.1.5.1
.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 2
Last Error Message:
# snmpwalk -v2c -On -c public 10.11.222.333 .1.3.6.1.4.1.2021.2.1.101.1
.1.3.6.1.4.1.2021.2.1.101.1 = ""
The complete list of OIDs of monitored processes is shown below. You can monitor them
by using the OID numbers directly, or you can use the MIB file named UCD-SNMP-MIB.
This MIB file is generally added to SNMP libraries by default, and you can choose the
variables from it directly.
.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1
60 © 2019 FireEye
Release 4.2 SNMP
.1.3.6.1.4.1.2021.2.1.1.2 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.1.3 = INTEGER: 3
.1.3.6.1.4.1.2021.2.1.1.4 = INTEGER: 4
.1.3.6.1.4.1.2021.2.1.1.5 = INTEGER: 5
.1.3.6.1.4.1.2021.2.1.1.6 = INTEGER: 6
.1.3.6.1.4.1.2021.2.1.1.7 = INTEGER: 7
.1.3.6.1.4.1.2021.2.1.2.1 = STRING: run_erl
.1.3.6.1.4.1.2021.2.1.2.2 = STRING: beam.smp
.1.3.6.1.4.1.2021.2.1.2.3 = STRING: java
.1.3.6.1.4.1.2021.2.1.2.4 = STRING: node
.1.3.6.1.4.1.2021.2.1.2.5 = STRING: rabbitmq-server
.1.3.6.1.4.1.2021.2.1.2.6 = STRING: epmd
.1.3.6.1.4.1.2021.2.1.2.7 = STRING: httpd
.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.3.2 = INTEGER: 3
.1.3.6.1.4.1.2021.2.1.3.3 = INTEGER: 4
.1.3.6.1.4.1.2021.2.1.3.4 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.3.5 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.3.6 = INTEGER: 1
.1.3.6.1.4.1.2021.2.1.3.7 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.4.2 = INTEGER: 3
.1.3.6.1.4.1.2021.2.1.4.3 = INTEGER: 4
.1.3.6.1.4.1.2021.2.1.4.4 = INTEGER: 12
.1.3.6.1.4.1.2021.2.1.4.5 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.4.6 = INTEGER: 1
.1.3.6.1.4.1.2021.2.1.4.7 = INTEGER: 6
.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.5.2 = INTEGER: 3
.1.3.6.1.4.1.2021.2.1.5.3 = INTEGER: 4
.1.3.6.1.4.1.2021.2.1.5.4 = INTEGER: 12
.1.3.6.1.4.1.2021.2.1.5.5 = INTEGER: 2
.1.3.6.1.4.1.2021.2.1.5.6 = INTEGER: 1
.1.3.6.1.4.1.2021.2.1.5.7 = INTEGER: 6
.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: noError(0)
.1.3.6.1.4.1.2021.2.1.100.2 = INTEGER: noError(0)
.1.3.6.1.4.1.2021.2.1.100.3 = INTEGER: noError(0)
.1.3.6.1.4.1.2021.2.1.100.4 = INTEGER: noError(0)
© 2019 FireEye 61
.1.3.6.1.4.1.2021.2.1.100.5 = INTEGER: noError(0)

.1.3.6.1.4.1.2021.2.1.100.6 = INTEGER: noError(0)
.1.3.6.1.4.1.2021.2.1.100.7 = INTEGER: noError(0)
.1.3.6.1.4.1.2021.2.1.101.1 = STRING:
.1.3.6.1.4.1.2021.2.1.101.2 = STRING:
.1.3.6.1.4.1.2021.2.1.101.3 = STRING:
.1.3.6.1.4.1.2021.2.1.101.4 = STRING:
.1.3.6.1.4.1.2021.2.1.101.5 = STRING:
.1.3.6.1.4.1.2021.2.1.101.6 = STRING:
.1.3.6.1.4.1.2021.2.1.101.7 = STRING:
Example monitoring of ‘run_erl’ process with MIB variables:

Process Name :
# snmpwalk -v2c -On -c testCommunityString 10.11.222.333 UCD-SNMP-
MIB::prNames.1
UCD-SNMP-MIB::prNames.1 = STRING: "run_erl"
Error Flag :
MIB::prErrorFlag.1
UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: 0
Min Run:
MIB::prMin.1
UCD-SNMP-MIB::prMin.1 = INTEGER: 2
Max Run:
MIB::prMax.1
UCD-SNMP-MIB::prMax.1 = INTEGER: 2
Current Run:
MIB::prCount.1
UCD-SNMP-MIB::prCount.1 = INTEGER: 2
Last Error Message:
MIB::prErrMessage.1
UCD-SNMP-MIB::prErrMessage.1 = ""
MIB File
The MIB file can be downloaded at http://www.net-snmp.org/docs/mibs/UCD-SNMP-
MIB.txt. The MIB file has some related information about MIB variables and their
62 © 2019 FireEye
Release 4.2 SNMP
definitions. Detailed documentation can be downloaded at http://www.net-

snmp.org/docs/mibs/ucdavis.html.
The complete list of MIBs for monitored processes is shown below. You can monitor them
by using the following MIB variables:
UCD-SNMP-MIB::prIndex.1 = INTEGER: 1
UCD-SNMP-MIB::prNames.1 = STRING: run_erl
UCD-SNMP-MIB::prNames.2 = STRING: beam.smp
UCD-SNMP-MIB::prNames.3 = STRING: java
UCD-SNMP-MIB::prNames.4 = STRING: node
UCD-SNMP-MIB::prNames.5 = STRING: rabbitmq-server
UCD-SNMP-MIB::prNames.6 = STRING: epmd
UCD-SNMP-MIB::prNames.7 = STRING: httpd
© 2019 FireEye 63
UCD-SNMP-MIB::prErrorFlag.1 = INTEGER: noError(0)
UCD-SNMP-MIB::prErrMessage.1 = STRING:
Example Usage with PRTG Network Monitor

PRTG Network Monitor is a server up-time and utilization, network monitoring, and
bandwidth usage software package for server infrastructure. It can monitor and classify
bandwidth usage in a network using SNMP, packet sniffing, and net flow. It services
Microsoft Windows and Linux. It was derived from the open-source Multi-Router Traffic
Grapher (MRTG) project. A version with a limited number of sensors is available free of
charge.
It is a simple example for testing SNMP Monitoring on the application side. Add the MIBs
above to check that they are valid for monitoring and alerting. Usage examples are
available at: https://kb.paessler.com/en/topic/29403-monitoring-processes-in-linux. Add the
Security Orchestrator virtual appliance to PRTG as a device. Then, add the required MIBs
to the PRTG system as a sensor. All related sensors are SNMP sensors and CPU, Memory,
Network Interface, Disk Status, Storage Spaces, and Processes can be monitored with them.
Features in the UCD-SNMP-MIB are already added to Sensor database.
64 © 2019 FireEye
Release 4.2 SNMP
Example status of monitored sensors for Security Orchestrator:
You can stop the fso service to test the SNMP monitoring by running the following
command:
# sudo service fso stop
After stopping the fso service, you can set error flags to 1 so the monitoring application
can detect the crashing or closing processes:
Example status of monitored sensors after stopping the fso service:
After you see that the error flags are set, SNMP monitoring configuration can be marked as
completed and you can start the fso service again:
# sudo service fso start
© 2019 FireEye 65
Monitoring Other Security Orchestrator Features

CPU, Memory, Disks, and Network Status can also be monitored using SNMP OIDs/MIBs.
The monitoring application can periodically fetch this data from Security Orchestrator and
display it for further monitoring.
The Security Orchestrator 4.2 virtual appliance uses CentOS 6.9 and Net-SNMP is the
module used for the SNMPD service, so the standard SNMP sensors will work with
Security Orchestrator. CPU, Memory, Disks, and Network Status can be polled using the
default Linux SNMP readers in the monitoring application.
66 © 2019 FireEye
PART III: User Management
l About User Management on page 69

l Managing Groups on page 71
l Managing Users on page 81
© 2019 FireEye 67
SO System Administration Guide PART III: User Management
68 © 2019 FireEye
CHAPTER 7: About
User Management
Security Orchestrator (SO) provides role-based access control for the Web UI. You control
who can access the Web UI by creating users, and you control which features and
components a user can access by configuring groups and assigning users to groups.
By default, all users have access to the Dashboard and System Status pages. By assigning a
user to a group, you can also grant add, read, write, delete, and execute access to SO
components, such as playbooks, devices, adapters, and cases.
You create and manage users and groups using the SO Web UI. For information on
accessing the Web UI, see Accessing the Web UI on page 27.
You can also apply role-based permissions to specific playbooks, allowing user groups to
access some playbooks but not others. For information on granting access to specific
playbooks, see the Security Orchestrator Playbook Management Guide.
Playbooks are also referred to as courses of action (COAs) in this guide and in the
SO Web UI.
For information on managing groups and users, see the following sections:
l Managing Groups on page 71

l Managing Users on page 81
© 2019 FireEye 69
SO System Administration Guide CHAPTER 7: About User Management
70 © 2019 FireEye
SO System Administration Guide Access Permissions by Component
CHAPTER 8: Managing Groups

A group defines the types of access a user has to Security Orchestrator components, such
as courses of action, adapters, and devices. When configuring a group, you can grant add,
read, write, delete, and execute permissions for individual components.
Security Orchestrator has a default admin user, assigned to a default

Administrators group. The Administrators group has full access to all
components.
Do not delete or modify the Administrators group or the admin user.
For instructions on managing groups, see the following sections:
l Access Permissions by Component below

l Viewing Groups on page 76
l Creating a Group on page 77
l Modifying a Group on page 78
l Deleting a Group on page 79
Access Permissions by Component

You can set access permissions for the following Security Orchestrator components:
l Courses of Action on the next page

l Cases from COAs on the next page
l Plug-Ins on page 73
l Devices on page 73
l Adapters on page 74
l Users on page 74
l Current User on page 74
l User Groups on page 75
© 2019 FireEye 71
SO System Administration Guide CHAPTER 8: Managing Groups
l Scripts on page 75
l Tables on page 75
l Forms on page 75
You must grant Read (R) permission to a component to allow users to view and
access the component. Read permission is not automatically granted by granting
add (A), write (W), or delete (D) permission.
Courses of Action
Courses of Action permissions control user access to COAs and the cases and processes
generated by COAs. You can set the following permissions for COAs:
Permission Access Granted
Read (R) View the Playbook page.

View configuration details and workflows for all COAs.
View the Cases page and All Activity page.
View cases and processes generated by all COAs.
Write (W) Modify configuration details and workflows for all COAs.
Add (A) Create new COAs.

Publish COAs.
Delete (D) Delete COAs.
Execute (X) Run recommended COAs and pivot actions from a case or process.
You can also grant a user group access to only specific COAs (on the Playbook page),
instead of granting the group access to all COAs. For information on granting access to
specific COAs, see the Security Orchestrator Playbook Management Guide.
If provided a direct URL to a case or process, any authorized user (regardless of

access permissions) can view and modify the case or process.
Cases from COAs

Cases from COAs permissions control user access to cases and processes generated by
COAs. You can set the following permissions for cases from COAs:
72 © 2019 FireEye
Release 4.2 Access Permissions by Component
Read (R) View cases and processes generated by COAs.
Access to the Cases page is also provided by granting read

permission to the Courses of Action component or by
granting read permission to a specific COA (on the
Playbook page).
Write (W) Does not affect user access.
You can also grant a user group access to cases and processes generated by specific COAs
only (on the Playbook page), instead of granting the group access to cases and processes
generated by all COAs. For information on granting access to specific COAs, see the
Security Orchestrator Playbook Management Guide.
Plug-Ins
You can set the following permissions for plug-ins:
Add (A) Does not affect user access.
Delete (D) Does not affect user access.
Read (R) View the Plug-Ins page.

View details about all installed plug-ins.
Write (W) Modify plug-in descriptions and default parameter values.
Devices
You can set the following permissions for devices:
Read (R) View the Devices page.

View configurations of all devices.
To allow a group to view devices, you must also grant

the group Read (R) permission to Plugins.
Write (W) Modify configurations of all devices.
Add (A) Create new devices.
© 2019 FireEye 73
Delete (D) Delete devices.
Adapters
You can set the following permissions for adapters:
Read (R) View the Adapters page.

View configurations of all adapters.
To allow a group to view adapters, you must also grant

the group Read (R) permission to Plugins.
Write (W) Modify configurations of all adapters.
Add (A) Create new adapters.
Delete (D) Delete adapters.
Users
You can set the following permissions for users:
Read (R) View the Users page.

View user configurations.
Write (W) Modify all users, including profiles, passwords, and group assignments.
Add (A) Create new users.
Delete (D) Delete users.
Current User
You can set the following permissions for the currently logged-in user:
Read (R) Does not affect user access.
Write (W) Change the password of the currently logged-in user.
74 © 2019 FireEye
Release 4.2 Access Permissions by Component
User Groups
You can set the following permissions for user groups:
Read (R) View the Groups page.

View group configurations.
Write (W) Modify all groups on the Groups page.

Modify COA-specific group permissions on the Playbook page.
Add (A) Create new groups.
Delete (D) Delete groups.
Scripts
Access permissions for scripts are not enforced; access to scripts cannot be restricted. Since
scripts are embedded in COAs, users with access to a COA also have access to its scripts.
Tables
You can set the following permissions for tables:
Read (R) View the Tables page.

View table configurations and table data.
Write (W) Modify table configurations and table data.
Add (A) Create new tables

Publish tables.
Delete (D) Delete tables.
Forms
You can set the following permissions for summary forms:
To grant permissions to Forms, you must also grant the same permissions to
Tables. For example, a user group must have write permission for Tables and
Forms to modify a form. (This is because a form is a type of table.)
© 2019 FireEye 75
Read (R) View the Summary Forms page.
Write (W) Modify summary form configurations.
Add (A) Create new summary forms.

Publish summary forms.
Delete (D) Delete summary forms.
Viewing Groups
The Groups page displays the following information for each user group:
l Group name and description

l Users assigned to the group (in the Members column).
l Date and time the group was last updated
To view groups:
1. In the Web UI, point to Admin, and then click Groups.

2. To view group access permissions, select a group in the list and then click Access
on the right.
76 © 2019 FireEye
Release 4.2 Creating a Group
Creating a Group
Create a group to define access permissions for a group of users.
To create a new group:

2. Click + New Group.
3. In the Name box, enter a unique name for the user group that clearly identifies its
purpose. This will help you find and assign the correct user groups when
configuring users.
The name of a group cannot be modified after the group is created.
4. In the Description box, enter an optional description of the user group.

5. Under Access, select permissions for each component:
l A (add) permission—Allows a user group to create entities for the
component. Also allows a user group to publish entities, such as COAs,
summary forms, and tables.
l D (delete) permission—Allows a user group to delete entities for a
component.
l R (read) permission—Allows a user group to view entities for the component.
When granting add, delete, or write permission for a component, you should
also grant read permission to allow users to view the component.
l W (write) permission—Allows a user group to modify entities for the
component.
l X (execute) permission—Allows a user group to run recommended COAs and
pivot actions.
Granting add, delete, or write permission does not grant read permission.
When granting add, delete, or write permission, also grant read permission
to allow users to view the component.
To allow a group to view Devices or Adapters, you must also grant the
group read permission to Plugins.
To grant permissions to Forms, also grant the same permissions to Tables.
For example, to grant write permission to Forms, select W for Forms and
select W for Tables.
6. Click Create.
© 2019 FireEye 77
Modifying a Group
You can change a group's access permissions and description. You cannot change a
group's name.
Do not modify access permissions for the Administrators group.
To modify a group's access permissions:

2. In the list, select the group you want to modify.
3. On the right, click Access.
4. In the panel on the right, modify permissions for each component:
l A (add) permission—Allows a user group to create entities for the
component. Also allows a user group to publish entities, such as COAs,
summary forms, and tables.
l D (delete) permission—Allows a user group to delete entities for a
component.
l R (read) permission—Allows a user group to view entities for the component.
When granting add, delete, or write permission for a component, you should
also grant read permission to allow users to view the component.
l W (write) permission—Allows a user group to modify entities for the
component.
l X (execute) permission—Allows a user group to run recommended COAs and
pivot actions.
Granting add, delete, or write permission does not grant read permission.
When granting add, delete, or write permission, also grant read permission
to allow users to view the component.
To allow a group to view Devices or Adapters, you must also grant the
group read permission to Plugins.
To grant permissions to Forms, also grant the same permissions to Tables.
For example, to grant write permission to Forms, select W for Forms and
select W for Tables.
5. Click Save.
To modify a group's description:

2. In the list, select the user group you want to modify.
78 © 2019 FireEye
Release 4.2 Deleting a Group
3. On the right, click Details.

4. In the panel on the right, enter a description.
5. Click Save.
Deleting a Group
Deleting a group will remove the group assignment from all users, and may cause users to
lose access to components. Before deleting a group, review the list of users assigned to the
group. See Viewing Groups on page 76.
Do not delete the Administrators group.
To delete a group:

2. In the list, select the group you want to modify.
3. On the right, click Delete.
4. Click Confirm.
© 2019 FireEye 79
80 © 2019 FireEye
Release 4.2 Viewing Users
CHAPTER 9: Managing Users

A user is a user account, including a user name and password, for accessing the Security
Orchestrator Web UI. You control who can access the Web UI by creating users. You
control which features and components a user can access by creating groups and
assigning users to groups.
All users have access to the Dashboard and System Status pages. By assigning users to
groups, you can also grant add, read, write, delete, and execute access to additional
Security Orchestrator components.
Security Orchestrator has a default admin user, assigned to a default

Administrators group. The Administrators group has full access to all
components.
Do not delete or modify the Administrators group or the admin user.
For instructions on managing users, see the following sections:
l Creating a User on the next page

l Viewing Users below
l Changing User Details on page 83
l Changing User Passwords on page 83
l Resetting Passwords for Locked-Out Users on page 84
l Changing User Group Assignments on page 84
l Deleting a User on page 85
l Enabling or Disabling a User on page 85
Viewing Users
The Users page displays the following information for each user:
l User name
l The user's full name and email addresses
l Group assignments
l Enabled status (on or off)
l Date and time the user configuration was last updated
© 2019 FireEye 81
SO System Administration Guide CHAPTER 9: Managing Users
To view all users:
1. In the Web UI, point to Admin, and then click Users.

2. To view the user configuration panels, select a user in the list. Then click Details
and Groups on the right.
Creating a User
Create a user to give someone access to the Security Orchestrator Web UI.
User access to specific components, such as courses of action (playbooks),

adapters, and cases, is granted by creating groups and then assigning users to
groups. See Creating a Group on page 77 or Modifying a Group on page 78.
To create a new user:

2. Click + New User.
3. In the Username box, enter a unique user name for the user.
The user name cannot be modified after the user is created.
4. (Optional) In the Name boxes, enter the user's first, middle, and last names.
5. (Optional) Click +Add Email Address to enter an email address for the user.
If you enter multiple email addresses, click Main next to the email address you
want to appear in the summary list on the Users page.
82 © 2019 FireEye
Release 4.2 Changing User Details
6. In the Password and Confirm Password boxes, enter a temporary password for the
user.
7. In the Groups box, select group assignments for the user:
l To assign the user to a group, click in the Groups box and then select a group
name from the list. Select multiple groups if needed. The user is granted all
access permissions defined in the selected groups.
l To remove the user from a group, click x next to the group name.
8. Click Create.
The user can log in to the Security Orchestrator Web UI with the user name and temporary
password.
Changing User Details

You can change a user's full name and email addresses after the user is created.
You cannot change the user name after a user is created.
To change a user's full name and email addresses:

2. In the list, select the user you want to modify.
3. On the right, click Details.
4. In the Name boxes, edit the user's first, middle, and last names.
5. Edit or delete the listed email addresses as needed.
6. To enter a new email address, click +Add Email Address.
If you enter multiple email addresses, click Main next to the email address you
want to appear in the summary list on the Users page.
7. Click Save.
Changing User Passwords

The admin user can change any user's password. Users can change their own passwords
if they are assigned to a group with write permission for the Current User component. For
more information, see Current User on page 74.
© 2019 FireEye 83
To change a user's password:

3. On the right, click Password.
4. Click Reset Password.
5. In the New Password and Confirm Password boxes, enter the new password for the
user.
6. Click Apply.
Resetting Passwords for Locked-Out

Users
You must reset the password for a user who has been locked out of the SO Web UI after
reaching the limit of failed login attempts. The account will lock out after five (5) failed
login attempts.
You can reset the password using the CLI. See Resetting Passwords Using the CLI below.
You can also reset the password using the Web UI, while logged in as a user with write
permission for the Users component. See Changing User Passwords on the previous page.
Resetting Passwords Using the CLI

To reset a user's password using the CLI:
1. Log in to the SO virtual appliance as the ixoperator user.

2. Run the following command:
$ fso reset password --username <username>
where <username> is the user name of a Security Orchestrator user.

3. Enter the new password.
Changing User Group Assignments

You can add or remove groups in a user's configuration to change the user's access
permissions.
84 © 2019 FireEye
Release 4.2 Enabling or Disabling a User
User access to specific components, such as courses of action (playbooks),

adapters, and cases, is granted by creating groups and then assigning users to
groups. See Creating a Group on page 77 or Modifying a Group on page 78.
By default, Security Orchestrator has an admin user who is assigned to the

Administrators group, granting the admin user full access to all components. Do
not remove the admin user from the Administrators group.
To modify a user's group assignments:

3. On the right, click Groups.
4. In the Groups box, add and remove groups as needed:
l To assign the user to a group, click in the Groups box and then select a group
name from the list. Select multiple groups if needed. The user is granted all
access permissions defined in the selected groups.
l To remove the user from a group, click x next to the group name.
5. Click Save.
Enabling or Disabling a User

After a user is created, the user is automatically enabled and can log in to the Web UI.
Disabling a user prevents the user from logging in to the Web UI.
To enable or disable a user:

2. In the list, select the user you want to enable or disable.
3. In the Enabled column, slide the button to the right to enable the user, or slide the
button to the left to disable the user.
If you disabled a user, the user's access to the Web UI is denied the next time the user
attempts to log in.
Deleting a User
Deleting a user removes the user's login credentials and prevents the user from accessing
the Web UI. To deny a user access temporarily, consider disabling the user. See Enabling or
Disabling a User above.
© 2019 FireEye 85
To delete a user:

2. In the list, select the user you want to delete.
3. On the right, click Delete.
4. Click Confirm.
86 © 2019 FireEye
PART IV: Administration
l Managing Services on page 89

l Managing Logs on page 91
l Generating Log Bundles for Customer Support on page 93
l Managing Snapshots on page 95
l Upgrading Software on page 101
© 2019 FireEye 87
SO System Administration Guide PART IV: Administration
88 © 2019 FireEye
SO System Administration Guide Status of SO and Dependent Services
CHAPTER 10: Managing Services

While logged in as the ixoperator user, use the following commands to manage the
Security Orchestrator service:
sudo service fso stop|restart|start|status
The proper way to start and stop Security Orchestrator is by using the fso service. The
status of Security Orchestrator should also be checked using the fso service.
Depending on your Security Orchestrator configuration, the system can take a

considerable amount of time to start up or restart. Wait at least 90 seconds in
environments with a full configuration and large operational datasets. When the
Web UI is responsive, the system is fully operational.
Status of SO and Dependent Services

To check the status of fso and all dependent services:
While logged in as root, run the following commands:
# service httpd24-httpd status
# service fso status
# service cassandra status
# service elasticsearch status
# service rabbitmq-server status
# service crond status
Stop SO and Dependent Services

Use the commands below to stop SO and dependent services. This is only recommended
during SO troubleshooting.
© 2019 FireEye 89
SO System Administration Guide CHAPTER 10: Managing Services
Depending on your Security Orchestrator configuration, the system can take a

considerable amount of time to start up or restart. Wait at least 90 seconds in
environments with a full configuration and large operational datasets. When the
Web UI is responsive, the system is fully operational.
The service configuration is configured to stop all services in the correct order during
system shutdown. If any of the services is not running, it is recommended that you stop
and restart them in the order shown below.
To stop fso and all dependent services:
While logged in as root, run the following commands in the order shown:
# service crond stop
# service httpd24-httpd stop
# service fso stop
# service cassandra stop
# service elasticsearch stop
# service rabbitmq-server stop
Start SO and Dependent Services

To start fso and all dependent services:
While logged in as root, run the following commands in the order shown:
# service httpd24-httpd start
# service elasticsearch start
# service rabbitmq-server start
# service cassandra start
# service fso start
# service crond start
90 © 2019 FireEye
SO System Administration Guide Configuring Logging Levels
CHAPTER 11: Managing Logs

The web.log file is the main source for logs regarding errors with the Security Orchestrator
application, plug-ins, adapters, and Web UI.
To follow the log in real time, use the following command:
l tail -f /var/log/fireeye/fso/web/web.log
To follow only Web requests (useful for troubleshooting the Web UI), use the following
command:
l tail -f /var/log/fireeye/fso/web/web.log |grep request_id=
To follow everything except Web requests (useful for troubleshooting plug-ins and
adapters), use the following command:
l tail -f /var/log/fireeye/fso/web/web.log |grep -v request_id=
Configuring Logging Levels

To enable debug level logging for all plug-in loading and command execution, set the
following in /etc/fireeye/fso/web.conf:
engine.python.debug = true
To disable, set the option to false.

To change the SO application logging level, set the following in
/etc/fireeye/fso/web.conf:
logger.level = <Level>
<Level> can be debug, info, warn, error, or fatal. The default setting is info.
FireEye does not recommend setting logging levels to debug for extended periods
of time. Debug mode requires file I/O and consumes disk space each time a
command is executed. After you troubleshoot an issue with debug mode enabled,
reset logging levels to their defaults.
© 2019 FireEye 91
SO System Administration Guide CHAPTER 11: Managing Logs
RabbitMQ Service Logs

Logs generated by the RabbitMQ service can be used to troubleshoot issues with the event
queue.
The following example shows the tail command that can be used to monitor the main log
for RabbitMQ:
l tail -f /var/log/rabbitmq/rabbit\@<server_name>.log
RabbitMQ also writes specific logs at startup and shutdown and tracks errors in separate
logs. The following logs are included:
l /var/log/rabbitmq/startup_err
l /var/log/rabbitmq/startup_log
l /var/log/rabbitmq/shutdown_err
l /var/log/rabbitmq/shutdown_log
The RabbitMQ service may trigger an error message about log rotation. You can ignore
this. Log rotation succeeds and the RabbitMQ service continues to work correctly.
The error is:
/etc/cron.daily/logrotate:
Password: su: incorrect password
error: error running shared postrotate script for
'/var/log/rabbitmq/*.log '
92 © 2019 FireEye
CHAPTER 12: Generating Log

Bundles for Customer Support
Security Orchestrator allows you to generate a bundle of logs that can be sent to FireEye
Support for diagnostics and troubleshooting. This bundle can also be used by an
administrator to collect system logs for review.
Run the following command (as ixoperator) to generate a support bundle:
$ fso gen_support_bundle
The resulting file will have the following name format: fso_<MAC>_
logs.<timespstamp>.tbz2
The file is a tar archive compressed with bzip2. To extract the logs from the file, use the
following command:
$ tar jxf fso_<MAC>_logs.<timespstamp>.tbz2
The files are extracted to a directory named logs in the current working directory. This
includes log files for Cassandra, ElasticSearch, Security Orchestrator, and Apache.
© 2019 FireEye 93
SO System Administration Guide CHAPTER 12: Generating Log Bundles for Customer Support
94 © 2019 FireEye
CHAPTER 13: Managing

Snapshots
Security Orchestrator configuration snapshots contain the current versions (draft and
published) of configured entities. Snapshot configuration data includes the following:
l Users
l Groups
l Plug-ins
l Devices
l Adapters
l Courses of Action (Playbooks)
l Summary Forms
l Tables
The user configuration contains the hashed password and salt used to authenticate the SO
user. Course of action (playbook) configuration includes the current version of any custom
scripts and any templates configured within the course of action. Table contents are not
saved in a snapshot file. Only the definition and configuration of the table are saved in a
snapshot file.
You can also choose whether encrypted data is stored in a snapshot. The encrypted data
requires a separate secret key, which is contained in the /etc/fireeye/fso/web.conf file
as common.encryption_key.
© 2019 FireEye 95
SO System Administration Guide CHAPTER 13: Managing Snapshots
Creating a Snapshot
You can create a snapshot at any time without affecting the SO operational state.
Before creating a snapshot, you must do the following:
l Start the fso service, if it is not running.

l Ensure that the SO system is not processing events and that no users are logged in.
To capture the current SO configuration in a snapshot file, run the command:

$ fso snapshot save [--include-encrypted] <snapshot filename>
The --include-encrypted option allows you to include encrypted data in the snapshot. If
not specified, encrypted data is not stored in the snapshot file. User password hashes are
always saved as part of the snapshot, even if encrypted data is not included.
The separate secret key, stored in the /etc/fireeye/fso/web.conf file as

common.encryption_key, is required to access encrypted data in the snapshot.
Save a copy of the web.conf file, and ensure that the key is available to restore
encrypted data in the snapshot.
Restoring a Snapshot Without Encrypted

Data
All configuration and operational SO data is cleared before a snapshot file is loaded.
Before restoring a snapshot, do the following:

While a snapshot is being restored, SO is shut down, the new snapshot is loaded, and SO
restarts.
To restore a snapshot without encrypted data, run the command:
$ fso snapshot load <snapshot filename>
Restoring a Snapshot with Encrypted

Data
You can only restore encrypted data as part of a snapshot restore.
96 © 2019 FireEye
Release 4.2 Restoring a Snapshot with Encrypted Data
Before restoring a snapshot with encrypted data, do the following:

l If you are restoring the snapshot on a different SO system, edit the
/etc/fireeye/fso/web.conf file to include the common.encryption_key setting (the
secret key) from the system on which the snapshot was generated.
To restore a snapshot with encrypted data, run the command:

$ fso snapshot load --include-encrypted <snapshot filename>
The --include-encrypted option will only work on snapshots that include encrypted data
upon generation. If no encrypted data is contained in the snapshot, the option is ignored.
© 2019 FireEye 97
SO System Administration Guide CHAPTER 13: Managing Snapshots
98 © 2019 FireEye
CHAPTER 14: Viewing Content

Follow the instructions in this section to view information about plug-ins, devices,
adapters, and playbooks using the CLI.
To display more information about the content management tools discussed in this section,
run the following commands:
$ fsocontent help
$ fsocontent help status
If the fsocontent command is not recognized or returns an error, see Loading

Content Management Tools on page 38.
To view plug-ins, devices, adapters, and playbooks using the CLI:
1. Log in to the SO virtual appliance as ixoperator or root.
2. To list installed plug-ins, run the following command:

$ fsocontent status --plugins
For more information about installed plug-ins, see Verifying Installed Plug-Ins on
page 37.
3. To list all devices with their status and plug-in information, run the following
command:
$ fsocontent status --devices
4. To list devices that are currently using an older plug-in version (when a newer
version of the plug-in is installed and available), run the following command:
$ fsocontent status --upgradable-devices
The plug-in version currently used by the device is shown along with the newer
plug-in version available for upgrade. For instructions on upgrading devices, see the
Security Orchestrator Playbook Management Guide.
5. To list all adapters, run the following command:
$ fsocontent status --adapters
© 2019 FireEye 99
SO System Administration Guide CHAPTER 14: Viewing Content
6. To list all playbooks, run one of the following commands:

$ fsocontent status --playbooks
or
$ fsocontent status --playbook-details
You can also review information about plug-ins, adapters, devices, and
playbooks in the Web UI and troubleshoot issues with device (plug-in)
commands by reviewing the command trace within a case. For more
information, see the Security Orchestrator Playbook Management Guide.
To check the version of the most recently installed content:

Follow these steps to display the Content release number and the date and time of
installation for the latest plug-ins installed using the Content installer.
1. Log in to the SO virtual appliance as ixoperator or root.

2. Run the following command:
$ fsocontent version
100 © 2019 FireEye

SO System Administration Guide Obtaining the SO Upgrade Files
CHAPTER 15: Upgrading Software

This section describes the process for upgrading the Security Orchestrator virtual appliance
version 4.1.0, 4.1.1, 4.2.0, 4.2.1, or 4.2.2 to version 4.2.3.
Online and offline upgrade packages are provided. The offline package is for use in
environments without full Internet connectivity. Installations with the offline package will
not attempt to connect to the Internet.
Take a snapshot backup of your existing SO virtual appliance before upgrading.

See Managing Snapshots on page 95.
To determine the version of the current system, use the fso version command.
In older systems, use the fsoversion command.
Obtaining the SO Upgrade Files

To obtain the SO upgrade files:
1. Download the following files from the FireEye Customer Service portal:
l SO Release Readme file, which contains the SHA-256 checksums for the
SO upgrade files
l SO online upgrade package, fso-system-4.2.3-1.el6.tar.gz
l SO offline upgrade package, fso-system-4.2.3-1.el6-offline.tar.gz
2. Verify SHA-256 checksums for the SO upgrade files.
4. Copy the online or offline upgrade package (tar.gz) to the SO virtual appliance.
5. Create a directory to which you can extract the upgrade package:
# mkdir -p ~/tmp-fso/
6. Extract the upgrade package to the directory:

# tar xf fso-system-4.2.3-1.el6.tar.gz -C ~/tmp-fso/
© 2019 FireEye 101

SO System Administration Guide CHAPTER 15: Upgrading Software
Upgrading the SO Software

To upgrade SO software:

2. Go to the directory where the upgrade package was extracted:
# cd ~/tmp-fso
3. To upgrade, run the following command:

# ./4.2.3/fso_update
For information about additional options, run the following command:

# ./4.2.3/fso_update --help
For information on upgrading plug-ins, see Plug-In Installation on page 31.
102 © 2019 FireEye

Release 4.2 Documentation
Technical Support
For technical support, contact FireEye through the Support website:

https://www.fireeye.com/support/contacts.html
Documentation
Documentation for all FireEye products is available on the FireEye Documentation Portal
(login required):
https://docs.fireeye.com/
© 2019 FireEye 103

FireEye, Inc. | 601 McCarthy Blvd. | Milpitas, CA | 1.408.321.6300 | 1.877.FIREEYE
support@fireeye.com | www.fireeye.com/company/contact-us.html
© 2019 FireEye, Inc. All rights reserved. FireEye is a registered trademark of FireEye, Inc. All other brands, products, or
service names are or may be trademarks or service marks of their respective owners.

SO SAG 4.2.3 en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SO SAG 4.2.3 en

Uploaded by

Copyright:

Available Formats

F I R E E Y E T E C H N I C A L D O C U M E N T A T I O N

SECURITY ORCHESTRATOR / 2019

Copyright © 2019 FireEye, Inc. All rights reserved.

FireEye Contact Information:

PART I: Getting Started 7

CHAPTER 1: About Security Orchestrator 9

CHAPTER 2: System Requirements 13

PART II: Deployment 15

CHAPTER 3: Deployment Checklist 17

CHAPTER 4: Virtual Appliance Installation 19

CHAPTER 5: Plug-In Installation 31

PART III: User Management 67

CHAPTER 7: About User Management 69

CHAPTER 8: Managing Groups 71

CHAPTER 9: Managing Users 81

PART IV: Administration 87

CHAPTER 10: Managing Services 89

CHAPTER 11: Managing Logs 91

CHAPTER 12: Generating Log Bundles for Customer Support 93

CHAPTER 13: Managing Snapshots 95

CHAPTER 14: Viewing Content 99

CHAPTER 15: Upgrading Software 101

Technical Support 103

PART I: Getting Started

l About Security Orchestrator on page 9

CHAPTER 1: About Security

l FireEye appliances and tools

l SO Virtual Appliance below

Python Virtual SO uses a Python virtual environment for running plug-in

Erlang Redirects Erlang input and output streams on Unix systems.

Erlang Runtime Used by RabbitMQ and SO Web servers

Java Runtime Used by Cassandra and Elasticsearch databases

Cron Scheduler Daemon to execute scheduled commands, such as logrotate

SO Command-Line Interface (CLI)

Using GNU Screen

The error reported by Python is:

The workaround is to add the following line to ~ixoperator/.screenrc:

Then restart any existing GNU Screen sessions.

Web Browser Support

l Google Chrome versions 55 through 60

l Microsoft Internet Explorer

Virtual Appliance Requirements

Resource Minimum Requirement

Processor 64-bit quad-core processor

Disk space 220 GB

Description Source Destination Protocol Port

DNS resolution SO virtual appliance Internal DNS servers TCP/UDP 53

NTP SO virtual appliance Trusted NTP servers UDP 123

CLI using SSH Admin workstation SO virtual appliance TCP 22

Description Source Destination Protocol Port

Access to the SO Admin and analyst SO virtual appliance TCP 443

Description Source Destination Protocol Port

SNMP polling for SO SNMP Manager SO virtual appliance UDP 161

SNMP traps for SO SO virtual appliance SNMP Manager UDP 162

PART II: Deployment

l Deployment Checklist on page 17

Step 1: See System Requirements on page 13.

Step 2: 1. Download the deployment files. See Obtaining

Step 3: See Accessing the Web UI on page 27.

Step 4: See About User Management on page 69.

Step 5: See the following sections:

Optional Configuration Steps:

Configure firewall settings for the See Firewall Configuration on page 47.