How Devices are Added to Organizations

When you initiate device discovery for organizations, the way in which those devices are added to organizations depends on whether you are using Collectors in your deployment.

For organizations with Collectors, discovery is carried out by the Collector, and the Collector assigns devices to the organization with which it is associated. If organizations have an overlapping IP range, deploying Collectors and assigning them to a specific IP range and organization will ensure that the device is added to the correct organization.

For organizations without Collectors, discovery is carried out by the Supervisor. In this case, the Include/Exclude IP Range you defined when you set up the organization is used to add the device to the organization.

If a device matches only one defined organization IP Range, then it is assigned to that organization

If a device matches multiple defined IP Ranges, then it is assigned to the Super organization

You can change a device’s assigned organization manually, and FortiSIEM will automatically update the Include/Exclude IP Range for that organization. This updated IP range definition will then be used in the next discovery process. However, this may create confusing IP range definitions for the organization, so you may want to re-define the organization’s IP range and rediscover devices.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Dynamic Distribution of Events per Second (EPS) across Collectors

In multi-tenant deployments, the service provider is licensed a certain amount of EPS. The service provider distributes these EPS among the various collectors during collector setup by setting the Guaranteed EPS. Because an organization can have multiple collectors, the guaranteed EPS for an organization is the sum total of guaranteed EPS for all collectors belonging to that organization. This total must be no more than the total EPS licensed to the service provider. The remaining EPS (the difference between the service provider EPS and the total EPS across all collectors), if any, is allocated to the super-local organization, the service provider’s core system, if that needs to be monitored. To monitor this system, FortiSIEM recommends creating a new organization to monitor the service’s own network, and to install another Collector to monitor that organization.

The redistribution algorithm uses three metrics for each Collector.

Guaranteed EPS	Defined during the collector configuration process while setting up an organization, FortiSIEM ensures that the collector can always send EPS at this rate. This is a constant that never changes during the operation of the algorithm, unless you edit the Collector definition.
Incoming EPS	This is the EPS that the Collector sees. This changes continuously. You can view this metric for a Collector in Admin > Collector Health.
Allocated EPS	This is the EPS that is currently allocated to the Collector by the redistribution algorithm. You can view this metric for a Collector in Admin > Collector Health.

 

Each Collector periodically reports Incoming EPS to the Supervisor, which then determines the Allocated EPS and pushes this control down to the collectors. Allocated EPS is set to Guaranteed EPS initially, but if for some Collector, Incoming EPS is greater than Allocated EPS, the Supervisor examines all Collectors and determines excess capacity as sum total of max (0,Allocated – Incoming) for all Collectors. If there is a Collector with excess capacity, its Allocated EPS is reduced and the excess amount is given to the Collector that needs the excess EPS. If the collector that gave up EPS, that is, Allocated EPS is less than Guaranteed EPS, subsequently needs the EPS, then EPS is taken away from the collectors with Allocated greater than Guaranteed and given back. This continuous readjustment is centrally coordinated by the Supervisor node.

 

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Deleting Organizations

1. Log into your Supervisor node as a Super/Global user.
2. Go to Admin > Setup Wizard > Organizations.
3. Write down the ID of the organization you want to delete.
4. Go to Admin > Collector Health.

Note the IP Address and Collector Name of any Collectors associated with the organization you want to delete.

5. Log out of your Supervisor node.
6. SSH into the Collector hosts for the organization as root.
7. Using phTools, stop the Collector processes.
8. Power down the Collector.
9. Log back into your Supervisor node as an Admin user for the organization you want to delete.
10. Go to CMDB > Devices.
11. Delete all devices in both the Device View and the VM View.
12. Go to CMDB > Device View > Users, and delete all users except for the default admin account under which you are currently logged in.
13. Go to Admin > Setup Wizard > Synthetic Transaction Monitoring and delete all STM tests.
14. Log out of your Supervisor node, and then log back in as the Super/Global user.
15. Go to Admin > Collector Health.
16. Delete the organization’s Collectors.

Issues with Deleting Collectors Because of In-Memory Processes

You may encounter issues with deleting Collectors if there are processes in memory on the Supervisor that are related to Collector status that are updated to the CMDB. If you encounter these issues, please contact FortiSIEM Support.

17. Delete the organization.
18. Log out of your Supervisor node.
19. SSH into the Supervisor host machine as root.
20. In the /data directory, delete the eventdb database for that organization.

Finding the Right EventDB Database

You can tell which EventDB belongs to the organization you want to delete based on the organization ID that you wrote down in Step 3. For example, if the organization ID is 2005, you would look for /data/eventdb/CUSTOMER_2005 as the database to delete. Be careful that you don’t delete the EventDB for a continuing organization.

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Managing Organizations for Multi-Tenant Deployments

Organizations can be created with or without Collectors. If you are using Collectors in a clustered deployment that includes Workers, please make sure you have followed the instructions in Configuring Worker Settings before you have registered your Collectors with the Supervisor in order to make sure your Collectors properly upload information to the Workers.

1. Log in to your Supervisor node as a Super/Global users.
2. Go to Admin > Setup Wizard > Organization.
3. Click Add.
4. Enter information for the organization.
5. If your organization uses Collectors, click New under
6. Complete the Collector information.

For Guaranteed EPS, enter the events per second from this collector that FortiSIEM will accept. See the topic Dynamic Distribution of Events per Second (EPS) across Collectors for more information. For Start Time and End Time, enter the dates for which the Collector license is valid.

7. Click Save.
8. For Max Devices, enter the maximum number of devices discovered by this collector that the system will accept.
9. Click Save.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Configuring FortiSIEM

Initial System Configuration

Before you can initiate discovery and monitoring of your IT infrastructure, you will need to configure several general settings, add users, and add organizations for multi-tenant deployments.

Setting Up the Email Gateway

Before you can set up notifications, you have to set up the email gateway that your system will use for all alerts and system notifications.

1. Log into your Supervisor node.
2. Go to Admin > General Settings > Email Settings.
3. Enter the Email Gateway Server.
4. Enter any additional account or connection information.
5. Click Save.

Setting Up Routing Information for Reports and Incident Notifications

Topics in this section describe how to set up email addresses to send alerts to when a scheduled report runs, and distribution information for notifications associated with incidents. You can also automate the sending of tickets to a Remedy system when an incident occurs. These are all general settings, in that you don’t need to have any rules or reports defined before you configure them. For information on configuring specific notification policies for rules and incidents, see Incident Notifications. For information on configuring Remedy to work with FortiSIEM notifications, see Configuring Remedy to Accept Incident Notifications from FortiSIEM.

Setting Up Email Alert Routing for Scheduled Reports

Setting Up SNMP Traps for Incident Notifications

Setting Up XML Message Routing for Incident Notifications

Setting Up Routing for Remedy Tickets

Related Links

Scheduling Reports

Incident Notifications

Configuring Remedy to Accept Incident Notifications from FortiSIEM

 

Setting Up Email Alert Routing for Scheduled Reports

You can schedule reports to run and send email notifications to specific individuals. This setting is for default email notifications that will be sent when any scheduled report completes.

1. Log into your Supervisor node.
2. Go to Admin > General Settings > Analytics.
3. Click +.

If you haven’t configured your email gateway yet, you will see an error message.

4. Select SMS or Email for the delivery method.
5. Enter the email address or SMS number.
6. Click OK.
7. Click Save All when you are done.

Sending Alerts to the Console

Select Send an alert to console if you also want to send alerts to the console. Alerts are always displayed in the Incidents tab, while the alerts sent to the console are immediately displayed but without any grouping by rule name, incident source, incident target, or other detail information.

Empty Reports

Sometimes a report may be empty because there are no matching events. If you don’t want to send empty reports to users, select Do not send scheduled emails if report is empty. If you are running a multi-tenant deployment, and you select this option while in the Super/Global view, this will apply only to Super/Global reports. If you want to suppress delivery of empty reports to individual organizations, you will have to configure this option in the organizational view.

Related Links

Setting Up the Email Gateway Scheduling Reports

Setting Up SNMP Traps for Incident Notifications

You can define SNMP traps that will be notified when an event triggers an incident.

1. Log in to your Supervisor node.
2. Go to Admin > General Settings > Analytics.
3. Enter the SNMP Trap IP Address.
4. Enter the SNMP Community String that will authorize sending the trap to the SNMP trap IP address.
5. Select the SNMP Trap Type.
6. Select a Protocol.
7. Click Test SNMP to check the connection.
8. Click Save All.

Related Links

Incident Notifications

 

Setting Up XML Message Routing for Incident Notifications

You can configure FortiSIEM to send an XML message over HTTP(s) when an a incident is triggered by a rule.

1. Log in to your Supervisor.
2. Go to Admin > General Settings > Analytics.
3. For HTTP(S) Server URL, enter the URL of the remote host where the message should be sent.
4. Enter the Username and Password to use when logging in to the remote host, and then Reconfirm the password.
5. Click Test HTTP to check the connection.
6. Click Save All.

Setting Up Routing for Remedy Tickets

You can set up Remedy to accept notifications from FortiSIEM and generate tickets from those notifications, as described in Configuring Remedy to Accept Incident Notifications from FortiSIEM. These instructions explain how to set up the routing to your Remedy server.

1. Log in to your Supervisor node.
2. Go to Admin > General Settings > Analytics.
3. For WSDL, enter the URL of the Remedy Server.
4. Enter the Username and Password associated with your Remedy server, and then Reconfirm the password.
5. Click Test Remedy to test the connection.
6. Click Save All.

Related Links

Configuring Remedy to Accept Incident Notifications from FortiSIEM

Setting Up User Roles

FortiSIEM has a wide operational scope – it provides performance, availability, and environmental alerts, as well as change and security monitoring for network devices, servers and applications. It is difficult for one admin to monitor across the entire spectrum of available information. In addition, devices may be in widely distributed geographical and administratively disjointed locations. Role-based access control provides a way to partition the FortiSIEM administrative reponsibilities across multiple admins.

A role defines two aspects of a user’s interaction with the FortiSIEM platform:

Which user interface elements a user can see and the ability to use the associated Read/Write/Execute permissions. As an example, the built-in Executive role can see only the dashboard, while the Server Admin role cannot see network devices. Role permissions can be defined to the attribute level in which, for example, a Tier1 Network Admin role can see network devices but not their configurations.

What data can the user see. For example, consider a Windows Admin role and a Unix Admin role. They both can run the same reports, but the Windows admins sees only logs from Windows devices. This definition can also be fine-grained, for example one Windows admin sub-role can be defined to see Windows performance metrics, while another Windows admin sub-role can see Windows authentication logs.

Topics in this section explain how to use the Default roles that come with FortiSIEM, and how to define new ones.

Default Roles

Creating Custom User Roles

 

Default Roles

To perform any action with FortiSIEM, a user must be assigned a role with the required permissions. The roles listed in this table are default roles. You can create custom roles and permissions by following the instructions in the topic Creating Custom User Roles.

Role	Permissions
Full Admin	Full access to the GUI and full access to the data. Only this role can define roles, create users and map users to roles.
Network Admin	Full access to the network device portion of the GUI and full access to logs from network devices
System Admin	Full access to the Server/Workstation/Storage part of the GUI and full access to logs from those devices
Server Admin	Full access to the Server part of the GUI and full access to logs from those devices
Windows Server Admin	Full access to the Windows Server part of the GUI and full access to logs from those devices
Unix Server Admin	Full access to the Unix Server part of the GUI and full access to logs from those devices
Security Admin	Full access to Security aspects of all devices
Storage Admin	Full access to the Storage device part of the GUI and full access to logs from those devices
DB Admin	Full access to the database servers part of the GUI and full access to logs from those devices
Helpdesk	Access to the Admin, CMDB, and Dashboard tabs, with view and run permissions for the the Analytics and Incidents tabs
Read Only Admin	View access to all tabs and permission to run reports
Executive	View access to the Business Service dashboard and personalized My Dashboard tabs, but reports can be populated by logs from any device

 

 

Creating Custom User Roles

1. Log in to your Supervisor node.
2. Go to Admin > Role Management.
3. Click New.
4. Enter a Role Name and Role Description.
5. Enter the Data Conditions for this role.

This restricts access to the event/log data that is available to the user, and will be appended to any query that is submitted by users with this role. This applies to both Real-Time and Historical searches, as well as Report and Dashboard information.

6. Enter the CMDB Report Conditions for this role.

This restricts access to the reports for devices, users, and monitors that are available to the user with this role.

7. Select the UI Access Conditions for this role.

This defines the user interface elements that can be accessed by users with this role. By default, child nodes in the tree inherit the permissions of their immediate parent, however you can override those default permissions by explicitly editing the permission of the child node. Options for these settings are:

Setting	Description
Full	No access restrictions
Edit	The role can make changes to the UI element
Run	The role can execute processes for the UI element
View	The role can only view the UI element
Hide	The UI element is hidden from the role

Adding Users for Enterprise Deployments

Adding users to enterprise deployments involves first deciding if you are going to use external authentication, or local authentication credentials defined within each user profile. You can then add users on an individual basis, or, if you are using LDAP authentication, you can discover users within Active Directory over LDAP. For mutt-tenant deployments you can add individual users to an organization as described in these topics, but if you need to add users who have a role in more than one organization (Global users), see the topics under Adding Users to Multi-Tenant Deployments.

Setting Up External Authentication

Adding a Single User

Adding Users from Active Directory via LDAP

Adding Users from Okta

Adding 2-factor Authentication via Duo Security

Setting Up External Authentication

You have three options for setting up external authentication for your FortiSIEM deployment. The first option, LDAP, is discussed in detail in Addin g Users from Active Directory via LDAP. The other options, RADIUS and Okta, follow the same authentication set up process.

2. Go to Admin > General Settings > External Authentication.
3. Click Add.
4. If you are setting up authentication for an organization within a multi-tenant deployment, select the Organization.
5. Select the Protocol.
6. Complete the protocol settings.

Protocol	User-Defined Settings
LDAP	Access IP Select Set DN Pattern to open a text field in which you can enter the DN pattern if you want to override the discovered pattern, or you want to add a specific LDAP user. See Adding Users from Active Directory via LDAP for more information about configuration settings for LDAP.
RADIUS	Access IP Shared Secret Select CHAP if you are using encrypted authentication to your RADIUS server
Okta	Certificate See Configuring Okta Authentication for more information.

7. Click Test, and then enter credentials associated with the protocol you selected to make sure users can authenticate to your deployment.

You can now associate users to this authentication profile as described in Adding a Single User.

 

Configuring Okta Authentication

To use Okta authentication for your FortiSIEM deployment, you must set up a SAML 2.0 Application in Okta, and then use the certificate associated with that application when you configure external authentication.

1. Log into Okta.
2. In the Applications tab, create a new application using Template SAML 2.0 App.
3. Under General Settings, configure these settings:

Post Back URL	https:///phoenix/okta
Destination	https:///phoenix/okta
Recipient	FortiSIEM
Audience Restriction	Super
authnContextClassRef	PasswordProtectedTransport
Request	Uncompressed

4. Click Save.
5. In the Sign On tab, click View Setup Instructions.
6. Click Download Certificate.
7. Follow the instructions in Setting Up External Authentication and enter the downloaded certificate for Okta authentication.

 

Adding a Single User

1. Log in to your Supervisor node.
2. Go to CMDB > Users.
3. Click New.
4. Complete the User Name and user profile information.
5. For System Administrator, select Yes.
6. Select a Default Role for the user.

See the topic Default Roles for a list of default roles and permission. You can also create new roles as described in Creating Custom User Roles, which will be available in this menu after you create them.

7. For System Account Enabled, select Yes.
8. For Session Timeout, enter the number of minutes after which an inactive user will be logged out.
9. For User Lockout, enter the number of minutes the user will be unable to log into the system after three successive authentication failures.
10. For System Password Reset, enter the number of days after which a user’s current password for logging in to the system will automatically expire.

If left blank, the user’s password will never expire.

11. For Password, select Local or External.

If you select Local, enter and then reconfirm the user password. See Setting Up External Authentication for more information about using external authentication.

Multiple Authentication Profiles

If more than one authentication profile is associated with a user, then the servers will be contacted one-by-one until a connection to one of them is successful. Once a server has been contacted, if the authentication fails, the process ends, and the user is notified that the authentication failed.

 

12. Click Save.

Related Links

Default Roles

Creating Custom User Roles

Adding Users from Active Directory via LDAP

If you want to add users to your FortiSIEM deployment from an Active Directory server over LDAP, you must first add the login credentials for your server and associate them to an IP range, and then run the discovery process on the Active Directory server. If the server is discovered successfully, then all the users in that directory will be added to your deployment. You then need to set up an authentication profile, which will become an option you can associate with users as described in Adding a Single User.

Create Login Credentials and Associate with an IP Address

1. Log in to your Supervisor node.
2. Go to Admin > Setup Wizard > Credentials.
3. Enter a Name.
4. For Device Type, select Microsoft Windows.
5. Select your Access Protocol.

FortiSIEM supports these LDAP protocols:

Protocol	Port
LDAP	Non-secure version on port 389
LDAPS	Secure version on port 636
LDAP Start TLS	Secure version on port 389

6. For Used For, select Microsoft Active Directory.
7. For Base DN, be sure to enter the root of the LDAP user tree.
8. Enter the NetBIOS/Domain for your LDAP directory.
9. Enter the User Name for your LDAP directory.

For user discovery from OpenLDAP, specify the full DN as the user name. For Active Directory, use your server login name.

10. Enter and confirm the Password for your User Name.
11. Click Save.

Your LDAP credentials will be added to the list of Credentials.

12. Under Enter IP Range to Credential Associations, click Add.
13. Select your LDAP credentials from the list of Credentials.
14. Enter the IP range or host name for your Active Directory server.
15. Click OK.

Your LDAP credentials will appear in the list of credential/IP address associations.

16. Click Test Connectivity to make sure you can connect to the Active Directory server.

Discover the Active Directory Server and Users

1. Go to Admin > Discovery.
2. Click Add.
3. For Name, enter Active Directory.
4. For Include Range, enter the IP address or host name for your Active Directory server.
5. Leave all the default settings, but clear the Discover Routes
6. Click OK.

Active Directory will be added to the list of discoverable devices.

7. Select the Active Directory device and click Discover.
8. After discovery completes, go to CMDB > Users to view the discovered users.

You may need to click Refresh for the user tree hierarchy to load.

Adding Users from Okta

Create an Okta API Token

1. Log in to Okta using your Okta credentials.
2. Got to Administration > Security > API Tokens.
3. Click Create Token.

You will use this token when you set up the Okta login credentials in the next section. Note that this token will have the same permissions as the person who generated it.

Create Login Credentials and Associate Them with an IP Address

1. Log in to your Supervisor node.
2. Go to Admin > Setup Wizard > Credentials.
3. Enter a Name.
4. For Device Type, select com.
5. For Access Protocol, select Okta API.
6. Enter the NetBIOS/Domain associated with your Okta account.

For example, FortiSIEM.okta.com.

7. For Pull Interval, enter how often, in minutes, you want FortiSIEM to pull information from Okta.
8. Enter and reconfirm the Security Token you created.
9. Click Save.

Your LDAP credentials will be added to the list of Credentials.

10. Under Enter IP Range to Credential Associations, click Add.
11. Select your Okta credentials from the list of Credentials.
12. Enter the IP range or host name for your Okta account.
13. Click OK.

Your Okta credentials will appear in the list of credential/IP address associations.

14. Click Test Connectivity to make sure you can connect to the Active Directory server.

Discover Okta Users

1. Go to Admin > Discovery.
2. Click Add.
3. For Name, enter Okta.
4. For Include Range, enter the IP address or host name for your Active Directory server.
5. Leave all the default settings, but clear the Discover Routes
6. Click OK.

Okta will be added to the list of discoverable devices.

7. Select the Okta device and click Discover.
8. After discovery completes, go to CMDB > Users to view the discovered users.

You may need to click Refresh for the user tree hierarchy to load.

Adding 2-factor Authentication via Duo Security

Obtain keys for FortiSIEM to communicate with Duo Security

1. Sign up for a Duo Security account: This will be admin account for Duo Security.
2. Log in to Duo Security Admin Panel and navigate to Applications
3. Click Protect an Application. Locate Web SDK in the applications.
4. Get Duo Server Name, Integration key, Secret key from the page. You will need it when you configure FortiSIEM.
5. Generate Application key as a long string. This is a password that Duo Security will not know. You can choose any 40 character long string or generate it as follows using python

Create and Manage FortiSIEM users in Duo Security

This determines how the 2-factor authentication response page will look like in FortiSIEM and how user will respond to the second factor authentication challenge

1. Log in to Duo Security as admin user
2. Choose the Logo which will be shown to users as they log on
3. Choose the super set of 2-factor Authentication Methods.
4. Optional – you can create the specific users that will logon via FortiSIEM. If the users are not pre-created here, then user accounts will be created automatically when they attempt 2-factor authentication for the first time.

Add 2-factor authentication option for FortiSIEM users

1. Create a 2-factor authentication profile
   1. Go to Admin > General Settings > External Authentication. b. Click Add
      1. Enter Name
      2. Set Organization to be the scopre of the users who will be authenticated.
         1. For AO-VA, specify System.
         2. For AO-SP, specify System if this will be used globally. Else specify a specific organization

• Set Protocol as Duo

1. Set IP/Host as the host name of Duo Security Server from Step 4 in “Obtain keys for FortiSIEM to communicate with

Duo Security”

1. Set Integration key, Secret key from Step 4 in “Obtain keys for FortiSIEM to communicate with Duo Security”
2. Set Application key from Step 5 in “Obtain keys for FortiSIEM to communicate with Duo Security” vii. Click Save

2. Add the 2-factor authentication profile to an user
   1. Go to CMDB > User
   2. Select a specific user
   3. Check Second Factor checkbox
   4. Select the 2-factor authentication profile created in Step 1
   5. Click Save

Login to FortiSIEM using 2-factor authentication

Before logging in to FortiSIEM with 2-factor authentication, make sure that the three steps are completed.

Obtain keys for FortiSIEM to communicate with Duo Security

Create and Manage FortiSIEM users in Duo Security

Add 2-factor authentication option for FortiSIEM users

Follow these steps

1. Logon to FortiSIEM normally (first factor) using the credential defined in FortiSIEM – local or external in LDAP
2. If the 2-factor authentication is enabled, the user will now be redirected to the 2-factor step
   1. If the user is not created in Duo system (by Duo admin), a setup wizard will let you set some basic information like phone number and ask you download the Duo app.
   2. If the user already exists in FortiSIEM, then follow the authentication method and click Log in The user will be able to log in to FortiSIEM

 

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Upgrading a FortiSIEM Single Node Deployment

These instructions cover the upgrade process for an FortiSIEM Enterprise deployment with a single Supervisor.

1. Using SSH, log in to the FortiSIEM virtual appliance as the root user.

Your console will display the progress of the upgrade process.

6. When the upgrade process is complete, your FortiSIEM virtual appliance will reboot.
7. Log in to your virtual appliance, and in the Admin > Cloud Health page, check that you are running the upgraded version of FortiSIEM.

Upgrading a FortiSIEM Cluster Deployment

Overview

Upgrading Supervisors and Workers

Upgrading Collectors

Overview

Follow these steps while upgrading a VA cluster

1. Shutdown all Workers. Collectors can be up and running.
2. Upgrade Super first (while all workers are shutdown)
3. After Super is up and running, upgrade worker one by one.
4. Upgrade collectors

Step #1 prevents the accumulation of Report files while Super is not available during upgrade (#2). If these steps are not followed, Supervisor may not be able to come up after upgrade because of excessive unprocessed report fie accumulation.

Note: Both Super and Worker MUST be on the same FortiSIEM version, else various software modules may not work properly. However, Collectors can be in older versions – they will work except that they may not have the latest discovery and performance monitoring features in the Super/Worker versions. So FortiSIEM recommends that you also upgrade Collectors within a short period of time.

If you have Collectors in your deployment, make sure you have configured an image server to use as a repository for the Collector

Upgrading Supervisors and Workers

For both Supervisor and Worker nodes, follow the upgrade process described here, but be sure to upgrade the Supervisor node first.

1. Using SSH, log in to the FortiSIEM virtual appliance as the root user.

Your console will display the progress of the upgrade process.

6. When the upgrade process is complete, your FortiSIEM virtual appliance will reboot.
7. Log in to your virtual appliance, and in the Admin > Cloud Health page, check that you are running the upgraded version of FortiSIEM.

Upgrading Collectors

The process for upgrading Collectors is similar to the process for Supervisors and Workers, but you must initiate the Collector process from the Supervisor.

1. Log in to the Supervisor node as an administrator.
2. Go to Admin > General Settings.
3. Under Image Server Settings, enter the download path to the upgrade image, and the Username and Password associated with your license.
4. Go to Admin > Collector Health.
5. Click Download Image, and then click Yes to confirm the download.

As the download progresses you can click Refresh to check its status.

6. When Finished appears in the Download Status column of the Collector Health page, click Install Image.

The upgrade process will begin, and when it completes, your virtual appliance will reboot. The amount of time it takes for the upgrade to complete depends on the network speed between your Supervisor node and the Collectors.

7. When the upgrade is complete, make sure that your Collector is running the upgraded version of FortiSIEM.

Upgrading FortiSIEM Windows Agent and Agent Manager

Upgrade from V1.0 to V1.1

Upgrade from V1.1 to V2.0

Upgrade from V2.0 to V2.1

Upgrading Windows Agent License

Uninstalling Agents

Upgrade from V1.0 to V1.1

Version 1.0 and 1.1 Backward Incompatibility

Note 1.0 Agents and Agent Managers communicate only over HTTP while 1.1 Agents and Agent Managers communicate only over HTTPS. Subsequently, 1.1 Agents and Agent managers are not backward compatible with 1.0 Agents and Agent Managers. You have to completely upgrade the entire system of Agents and Agent Managers.

1. Uninstall V1.0 Agents
2. Close V1.0 Agent Manager Application. 3. Uninstall V1.0 Agent Manager
3. Bind Default Website with HTTPS as described in Pre-requisite in Installing FortiSIEM Windows Agent Manager.
4. Install V1.1 Agent Manager following Installing FortiSIEM Windows Agent Manager.
   1. In Database Settings dialog, enter the V1.0 database path as the “FortiSIEM Windows Agent Manager” SQL Server database path (Procedures Step 6 in Installing FortiSIEM Windows Agent Manager).
   2. Enter the same Administrator username and password (as the previous installation) in the Agent Manager Administrator account creation dialog
5. Install V1.1 Agents
6. Assign licenses again. Use the Export and Import feature.

Upgrade from V1.1 to V2.0

Windows Agent Manager

1. Enable TLS 1.2 on Agent Manager – FortiSIEM Supervisor/Worker 4.6.3 and above enforces the use of TLS 1.2 for tighter security. However, by default only SSL3 / TLS 1.0 is enabled in Windows Server 2008-R2. Therefore, enable TLS 1.2 for Windows Agent Manager 2.0 for operating with FortiSIEM Supervisor/Worker 4.6.3 and above.
   1. Start elevated Command Prompt (i.e., with administrative privilege) to Windows Agent Manager 1.1
   2. Run the following commands sequentially as shown.
   3. Restart computer
2. Uninstall Agent Manager 1.1
3. Install SQL Server 2012-SP1 Feature Pack on Agent manager available at https://www.microsoft.com/en-in/download/details.aspx?id=35
   1. Select the language of your choice and mark the following two MSIs (choose x86 or x64 depending on your platform) for download:
      1. msi
      2. msi
   2. Click on the Download button to download those two MSIs. Then double-click on those MSIs to install those one by one.
4. Install Agent Manager 2.0
   1. In Database Settings dialog, set the old database path as AccelOpsCAC database path.
   2. Enter the same Administrator username and password (as in the previous installation) in the new Agent Manager Administrator account creation dialog.
5. Run Database migration utility to convert from 1.1 to 2.0
   1. Open a Command Prompt window
   2. Go to the installation directory (say, C:\Program Files\AccelOps\Server)
   3. Run AOUpdateManager.exe with script.zip as the command line parameter. You will find script.zip alongside the MSI.
6. Register Windows Agent Manager 2.0 to FortiSIEM.

 Windows Agent

1. Uninstall V1.0 Agents
2. Install Agents

Upgrade from V2.0 to V2.1

Windows Agent Manager

1. Uninstall Agent Manager 2.0
2. Install Agent Manager 2.1
   1. In Database Settings dialog, set the old database path as AccelOpsCAC database path.
   2. Enter the same Administrator username and password (as in the previous installation) in the new Agent Manager Administrator account creation dialog.
3. Run Database migration utility to convert from 2.0 to 2.1
   1. Open a Command Prompt window
   2. Go to the installation directory (say, C:\Program Files\AccelOps\Server)
   3. Run AOUpdateManager.exe with script.zip as the command line parameter. You will find script.zip alongside the MSI.
4. Register Windows Agent Manager 2.1 to FortiSIEM.

 Windows Agent

1. Uninstall V2.0 Agents
2. Install 2.1 Agents

Upgrading Windows Agent License

Follow these steps if you have bought additional Windows Agent licenses or extended the term of the license.

1. Login to AccelOps Supervisor using admin account
2. Go to Admin > License Management and make sure that the license is updated
3. Go to Admin > Setup Wizard > Windows Agent
4. Edit each Windows Agent Manager entry and modify the agent count and license expiry date if needed

The new license will be automatically pushed to each Windows Agent Manager. You can now logon to each Windows Agent Manager and allocate the additional licenses if needed.

Uninstalling Agents

Single Agent

Simply uninstall like a regular Windows service

Multiple Agents using Group Policy

Go to the Group Policy you created during Agent installation. Right click and select Edit

In the Group Policy Management Editor, go to MyGPO > Computer Configuration > Policies > Software Settings > Software

Installation

Right click on FortiSIEM Windows Agent <version>

Click All Tasks > Remove

In Remove Software dialog, choose the option Immediately uninstall the software from users and computers. Then click OK.

The FortiSIEM Windows Agent <version> entry will disappear from the right pane. Close the Group Policy Management Editor. Force the group policy update

On Domain Controller > cmd, run gpupdate /force

On Agent server > cmd, run gpupdate Restart each Agent Computer to complete the uninstall.

Automatic OS Upgrades during Reboot

In order to patch CentOS and system packages for security updates as well as bugfixes and make the system on-par with a fresh installed FortiSIEM node, the following script is made available. Internet connectivity to CentOS mirrors should be working in order for the following script to be successful, otherwise the script will print and error and exit. This script is available on all nodes starting from 4.6.3: Supervisor, Workers,

Collectors, and Report Server

/opt/phoenix/phscripts/bin/phUpdateSystem.sh

The above script is also invoked during system boot up and is invoked in the following script:

/etc/init.d/phProvision.sh

The ensures that the node is up to date right after an upgrade and system reboot. If you are running a node that was first installed in an older release and upgraded to 4.6.3, then there are many OS/system packages that will be downloaded and installed the first time. Therefore, upgrade time is longer than usual. On subsequent upgrades and reboots, the updates will be small.

Nodes that are deployed in bandwidth constrained environments can disable this by commenting out the line phUpdateSystem.sh in phProvision.sh above. However, it is strongly recommended to keep this in-place to ensure that your node has security fixes from CentOS and minimize the risk of an exploit. Alternatively, in bandwidth constrained environments, you can deploy a freshly installed collector to ensure that security fixes are up to date.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Upgrading to 4.6.3 for TLS 1.2

Enforcing TLS 1.2 requires that the following steps be followed in strict order for upgrade to succeed. Additional steps for TLS 1.2 compatibility are marked in bold.

1. Remove /etc/yum.repos.d/accelops* and Run “yum update” on Collectors, Worker(s), Supervisor and to get all TLS 1.2 related libraries up to date. Follow this yum update order Collectors Worker(s) 
2. If your environment has a collector and it is running AccelOps 4.5.2 or earlier (with JDK 1.7), then first patch the Collector for TLS 1.2 compatibility (see here). This step is not required for Collectors running AccelOps 4.6.1 or later.
3. Pre-upgrade step for upgrading Supervisor: Stop FortiSIEM (previously AccelOps) processes all Workers by running “phtools –stop ALL”.

Collectors can be up and running. This is to avoid build up of report files.

4. Upgrade Supervisor following usual steps.
5. If your environment has Worker nodes, Upgrade Workers following usual steps.
6. If your environment has AccelOps Windows Agents, then upgrade Windows Agent Manager from 1.1 to 2.0. Note there are special pre-upgrade steps to enable TLS 1.2 (see here).
7. If your environment has Collectors, upgrade Collectors following usual steps.

Setting Up the Image Server for Collector Upgrades

If you want to upgrade a multi-tenant deployment that includes Collectors, you must set up and then specify an image server that will be used as a repository for the Collector upgrade files. You can use a standard HTTP server for this purpose, but there is a preferred directory structure for the server. These instruction describe how to set up that structure, and then add a reference to the image server in your Supervisor node.

Setting Up the Image Server Directories

1. Log into the image server with Admin rights.
2. Create the directory images/collector/upgrade.
3. Download the latest collector image upgrade file from https://images.FortiSIEM.net/upgrade/offline/co/latest4/ to images/collector/u

pgrade.

4. Untar the file.
5. Test the image server locations by entering one of the following addresses into a browser:

http://images.myserver.net/vms/collector/upgrade/latest/ https://images.myserver.net/vms/collector/upgrade/latest/

Setting the Image Server in the Supervisor

1. Log in to your Supervisor node.
2. Go to Admin > General Settings > System.
3. Under Image Server, enter the URL or IP address for your image server.
4. Enter the authentication credentials for your image server.
5. Click Save.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Migrating a KVM NFS-based Deployment via a Staging System

Overview

In this migration method, the production 3.7.x FortiSIEM systems are left untouched. A separate mirror image 3.7.x system is first created, and then upgraded to 4.2.1. The NFS storage is mounted to the upgraded 4.2.1 system, and the collectors are redirected to the upgraded 4.2.1 system. The upgraded 4.2.1 system now becomes the production system, while the old 3.7.6 system can be decommissioned. The collectors can then be upgraded one by one. The advantages of this method is minimal downtime in which incidents aren’t triggered, and no upgrade risk. If for some reason the upgrade fails, it can be aborted without any risk to your production CMDB data. The disadvantages of this method are the requirement for hardware to set up the mirror 3.7.x mirror system, and longer time to complete the upgrade because of the time needed to set up the mirror system.

The steps in this process are:

Overview

Prerequisites

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Mounting the NFS Storage on Supervisors and Workers

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Create the 3.7.x CMDB Archive

1. Log in to your running 3.7.x production AccelOp virtual appliance as root.
2. Change the directory to /root.
3. Copy the migration script ao-db-migration-4.2.1.tar to the /root
4. Untar the migration script.
5. Make sure that the owner of ao-db-migration.sh and ao-db-migration-archiver.sh files is root.
6. Run the archive script, specifying the directory where you want the archive file to be created.
7. Check that the archived files were successfully created in the destination directory.

You should see two files, cmdb-migration-*.tar, which will be used to migrate the 3.7.x CMDB, and opt-migration-*.tar, which contains files stored outside of CMDM that will be needed to restore the upgraded CMDB to your new 4.2.1 virtual appliance.

8. Copy the cmdb-migration-*.tar file to the 3.7.x staging Supervisor, using the same directory name you used in Step 6.
9. Copy the opt-migration-*.tar file to the /root directory of the 4.2.1 Supervisor.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Mounting the NFS Storage on Supervisors and Workers

Follow this process for each Supervisor and Worker in your deployment.

1. Log in to your virtual appliance as root over SSH.
2. Run the mount command to check the mount location.
3. Change to the 3.7.x mount path location in the /etc/fstab file on the Supervisor or Workers.
4. Reboot the Supervisor or Worker.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully

Migrating Collectors

1. After migrating all your Supervisors and Workers to 4.2.1, install the 4.2.1 Collectors.
2. SSH to the 3.7.x Collector as root.
3. Change the directory to /opt/phoenix/cache/parser/events.
4. Copy the files from this directory to the same directory on the 4.2.1 system.
5. Change the directory to /opt/phoenix/cache/parser/upload/svn.
6. Copy the files from this directory to the same directory on the 4.2.1 system.
7. Power off the 3.7.x Collector.
8. SSH to the 4.2.1 Collector and change its IP address to the same as the 3.7.x Collector by running the vami_config_net
9. In a browser, navigate to https://<4.2.1_Collector_IP_address>:5480 and fill in the administration information to complete the Collector setup/

 

 

Migrating the SVN Repository to a Separate Partition on a Local Disk

If you are using NFS storage, your SVN repository will be migrated to a local disk to improve performance and reliability. If you are using local storage only, the SVN repository will be moved out of the /data partition and into an /svn partition.

3. Download ao-svn-migration.sh script from image server. (https://images.FortiSIEM.net/upgrade/va/4.3.1)
4. Copy or move the ao-svn-migration.sh script to /root.
5. Run ls -al to check that root is the owner of ao-svn-migration.sh.
6. Run chmod to change the permissions on ao-svn-migration.sh to 755.
7. Reboot the machine.
8. Log into the Supervisor as root.
9. When the script executes, you will be asked to confirm that you have 60GB of local storage available for the migration. When the script completes, you will see the message Upgrade Completed. SVN disk migration done.
10. Run df –h to confirm that the /svn partition was completed.

Special pre-upgrade instruction for 4.3.3

1. SSH as root into the Supervisor node
2. Download “phupdateinstall-4.3.3.sh” script
3. Copy or move the phupdateinstall-4.3.3.sh script to /root
4. Run chmod to change the permissions on phupdateinstall-4.3.3.sh to 755

Special pre-upgrade instruction for 4.6.1

Instructions for Supervisor node

Run the following command as root.

Instructions for Collector  nodes

Run the following command as root on each collector prior to upgrading the collector from the GUI, or the upgrade will fail:

Enabling TLS 1.2 Patch On Old Collectors

Older AccelOps collectors 4.5.2 or earlier running JDK 1.7 do not have TLS 1.2 enabled. To enable them to communicate to FortiSIEM 4.6.3, follow these steps

1. SSH to Collector and edit /opt/phoenix/bin/runJavaAgent.sh

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!