What's New in 7.2.3

This release contains the following bug fixes.

• Bug Fixes
• Implementation Notes

Bug Fixes

The following issues are resolved.

Bug ID	Severity	Module	Description
1072348	Major	App Server	Unable to correctly save FortiSIEM rule with Clear Conditions.
1071492	Major	App Server	Occasionally GUI is not available, which can be caused by Appserver PostGreSQL Query idle in transaction. This is likely to happen in environments with too many Incidents or Incidents that remain open for long period of time.
1074944	Major	Content Update	Content update on upgraded 7.2.3 HA + DR environment is not working - no 'Download Content' job created for Follower Supervisor node.
1050095	Major	Parser	Socket leak during handling of Syslog-over-TLS events. This was introduced in FortiSIEM 7.1.6. This only impacts environments where FortiSIEM is receiving Syslog over TCP and secured by TLS. Because of this bug, file resources may be totally consumed and Collector may not be able to process events.
1048967	Major	Parser	High phParser process CPU usage caused by incorrect handling of Syslog over TLS. This was introduced in FortiSIEM 7.1.6 and only impacts environments where Syslog is received over TCP and secured by TLS. In this case, event processing may be slow on the Collector.
1074165	Minor	App Server	Sometimes event status in CMDB tab does not show correctly for registered agents, but events are being ingested.
1070821	Minor	App Server	Appserver may fail to show latest Device Event Status in CMDB when there are a large number of reporting hosts.
1067116	Minor	App Server	Sometimes FortiSIEM may fail to perform FortiGuard IOC Lookup during Incident Threat Analysis.
1057137	Minor	App Server	SQL Exception while accessing CMDB > Applications > Ungrouped folder with large number of entries.
1075779	Minor	Data work	Discrepancy between WinOSWmiParser and WinOSXML Parser for Security Event ID 4740. This may cause some rules to not trigger.
1066143	Minor	Parser	Windows XML parser does not parse event type names correctly for Win-Sysmon-17/18/23 events.
1064024	Minor	Performance Monitoring	Custom JDBC Monitoring for Oracle 19c fails.
1057944	Minor	System	openSSL binaries exist in phAnomaly and phGenerativeAI paths /opt/phoenix/cache/_MEIxxxxxxxx.
1073564	Enhancement	Generative AI	Upgrade the GPT model to GPT-4o to prevent the impact of GPT-3.5.x shutdown around September 2024.
1074018	Enhancement	Linux Agent	Add Linux Agent support for Ubuntu 24.

Implementation Notes

• Linux Agent Related
• PostGreSQL Related
• Collector HA Related
• Identity and Location Related
• Post-Upgrade ClickHouse IP Index Rebuilding

Linux Agent Related

If you are running Linux Agent on Ubuntu 24, then Custom Log File monitoring may not work because of App Armor configuration. Take the following steps to configure App Armor to enable FortiSIEM Linux Agent to monitor custom files.

1. Login as root user.

2. Check if rsyslogd is protected by AppArmor by running the following command.

   aa-status | grep rsyslogd

   If the output displays rsyslogd, then you need to modify AppArmor configuration as follows.

3. Verify that the following line exists in the file /etc/apparmor.d/usr.sbin.rsyslogd

   include if exists <rsyslog.d>

   If it does not, then add the above line to the file.

4. Create or modify the file /etc/apparmor.d/rsyslog.d/custom-rules and add rules for the monitored log file as needed.

   Examples:

   If you want to monitor /testLinuxAgent/testLog.log file, then add the following line that allows rsyslogd to read the file:

   /testLinuxAgent/testLog.log r,

   Always add the following line that allows rsyslogd to read the FortiSIEM log file. This is needed:

   /opt/fortinet/fortisiem/linux-agent/log/phoenix.log r,

5. Run the following command to reload the rsyslogd AppArmor profile and apply the changes above.

   apparmor_parser -r /etc/apparmor.d/usr.sbin.rsyslogd

PostGreSQL Related

FortiSIEM 7.2.3 includes PostGreSQL v13.14 containing the patch for CVE-2024-0985.

• If you are doing a fresh install of FortiSIEM 7.2.3, then the patch is included and there is nothing to do.

• If you have upgraded to FortiSIEM 7.1.5 or later, then the patch is included and there is nothing to do.

• If you want to remain on FortiSIEM 7.1.4 or earlier, then you can't get this patch by running yum upgrade, since Postgres changed the repo gpg key as per this change
  (https://yum.postgresql.org/news/pgdg-rpm-repo-gpg-key-update/). To get this Postgres patch, on the Supervisor, run the following script:

curl -s https://os-pkgs-cdn.fortisiem.fortinet.com/postgres/misc/switch-pgdg-repo-and-upgrade-to-pg13.14.sh | bash -xe

Collector HA Related

1. If you have FortiSIEM Windows/Linux Agents reporting through Collectors and you decide to form a HA Collector Group with those Collectors, then you need to add all the Collectors in the HA Group to Admin > Setup > Windows Agent > Host to Template Associations and click Apply.

2. If you add a new Collector to an existing HA Collector Group, then the new Collector must be added as a Follower.

3. If a Collector is part of High Availability (HA) Cluster and you want to delete the Collector, then follow these procedures.

   Case 1: If the Collector is a Follower, then follow these steps:

   1. Remove the Collector from the High Availability (HA) Collector Cluster in Admin > Settings > System > Cluster Config.

   2. Click Save.

   3. Delete the Collector from CMDB.

   Case 2: If the Collector is a Leader, then follow these steps:

   1. Make the Collector a Follower Cluster in Admin > Settings > System > Cluster Config.

   2. Click Save.

   3. Remove the Collector from the High Availability (HA) Collector Cluster in Admin > Settings > System > Cluster Config.

   4. Click Save.

   5. Delete the Collector from CMDB.

4. Collector High Availability (HA) Failover Triggers:

   • Logs are sent to a VIP in VRRP based Failover - In this case, when VRRP detects node failure, then Follower becomes a Leader and owns the VIP and events are sent to the new Leader. If a process is down on a node, then VRRP may not trigger a Failover.

   • Logs sent to Load Balancer - In this case, the Load balancing algorithm detects logs being sent to a different Collector. If a process is down on a node, then Failover may not trigger.

   • For event pulling and performance monitoring, App Server redistributes the jobs from a Collector if App Server failed to receive a task request in a 10 minute window.

Identity and Location Related

If you are upgrading to 7.2.3, then please update the following entry in the /opt/phoenix/config/identityDef.xml file in Supervisor and Workers to get Identity and location entries populated for Microsoft Office365 events. Then restart IdentityWorker and IdentityMaster processes on Supervisor and Workers.

Pre-7.2.3 Entry

<identityEvent>
     <eventType>MS_OFFICE365_UserLoggedIn_Succeeded</eventType>
     <eventAttributes>
        <eventAttribute name="userId" identityAttrib="office365User" reqd="yes"/>
        <eventAttribute name="srcDomain" identityAttrib="domain" reqd="no"/>
        <eventAttribute name="srcIpAddr" identityAttrib="ipAddr" reqd="yes"/>
        <eventAttribute name="srcGeoCountry" identityAttrib="geoCountry" reqd="no"/>
        <eventAttribute name="srcGeoCountryCodeStr" identityAttrib="geoCountryCode" reqd="no"/>
        <eventAttribute name="srcGeoState" identityAttrib="geoState" reqd="no"/>
        <eventAttribute name="srcGeoCity" identityAttrib="geoCity" reqd="no"/>
        <eventAttribute name="srcGeoLatitude" identityAttrib="geoLatitude" reqd="no"/>
        <eventAttribute name="srcGeoLongitude" identityAttrib="geoLongitude" reqd="no"/>
     </eventAttributes>
  </identityEvent>

7.2.3 Entry

<identityEvent>
     <eventType>MS_OFFICE365_UserLoggedIn_Succeeded,MS_OFFICE365_EntraID_UserLoggedIn,MS_OFFICE365_EntraID_StsLogon_UserLoggedIn</eventType>
     <eventAttributes>
        <eventAttribute name="user" identityAttrib="office365User" reqd="yes"/>
        <eventAttribute name="srcDomain" identityAttrib="domain" reqd="no"/>
        <eventAttribute name="srcIpAddr" identityAttrib="ipAddr" reqd="yes"/>
        <eventAttribute name="srcGeoCountry" identityAttrib="geoCountry" reqd="no"/>
        <eventAttribute name="srcGeoCountryCodeStr" identityAttrib="geoCountryCode" reqd="no"/>
        <eventAttribute name="srcGeoState" identityAttrib="geoState" reqd="no"/>
        <eventAttribute name="srcGeoCity" identityAttrib="geoCity" reqd="no"/>
        <eventAttribute name="srcGeoLatitude" identityAttrib="geoLatitude" reqd="no"/>
        <eventAttribute name="srcGeoLongitude" identityAttrib="geoLongitude" reqd="no"/>
     </eventAttributes>
  </identityEvent>

Post-Upgrade ClickHouse IP Index Rebuilding

If you are upgrading ClickHouse based deployment from pre-7.1.1 to 7.2.3, then after upgrading to 7.2.3, you need to run a script to rebuild ClickHouse indices. If you are running 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.2.0, 7.2.1, or 7.2.2 and have already executed the rebuilding steps, then nothing more needs to be done.

For details about this issue, see Release Notes 7.1.3 Known Issue.

The rebuilding steps are available in Release Notes 7.1.4 - Script for Rebuilding/Recreating pre-7.1.1 ClickHouse Database Indices Involving IP Fields.