2.4.100 hotfix 20240903

alerts.rst

@@ -78,8 +78,7 @@ Detailed View
 
 If you click a value in the grouped view and then select the Drilldown option, the display will switch to the detailed view. This shows all search results and allows you to then drill into individual search results as necessary. Clicking the table headers allows you to sort ascending or descending. Starting from the left side of each row, there is an arrow which will expand the result to show all of its fields. To the right of that arrow is the ``Timestamp`` field. Next, a few standard fields are shown: ``rule.name``, ``event.severity_label``, ``source.ip``, ``source.port``, ``destination.ip``, and ``destination.port``. Depending on what kind of data you're looking at, there may be some additional data-specific fields as well. 
 
-When you click the arrow to expand a row in the Events table, it will show all of the individual fields from that event. Field names are shown on the left and field values on the right. When looking at the field names, there are two icons to the left. Th
-e Groupby icon, the left most icon, will add a new groupby table for that field. The Toggle Column icon, to the right of the Groupby icon, will toggle that column in the Events table, and the icon will be a blue color if the column is visible. You can click on values on the right to bring up the context menu to refine your search or pivot to other pages. 
+When you click the arrow to expand a row in the Events table, it will show all of the individual fields from that event. Field names are shown on the left and field values on the right. When looking at the field names, there are two icons to the left. The Groupby icon, the left most icon, will add a new groupby table for that field. The Toggle Column icon, to the right of the Groupby icon, will toggle that column in the Events table, and the icon will be a blue color if the column is visible. You can click on values on the right to bring up the context menu to refine your search or pivot to other pages. 
 
 Context Menu
 ------------

elastalert-fields.rst

@@ -3,10 +3,7 @@
 Elastalert Fields
 =================
 
-The following lists field names as they are formatted in Elasticsearch.
-Elastalert provides its own template to use for mapping into Elastalert,
-so we do not current utilize a config file to parse data from
-Elastalert.
+The following lists field names as they are formatted in Elasticsearch. Elastalert provides its own template to use for mapping into Elastalert, so we do not current utilize a config file to parse data from Elastalert.
 
 ``index:*:elastalert_status``
 

pfsense.rst

@@ -40,8 +40,7 @@ First, add the pfSense integration and configure the pfSense firewall:
 #. On the ``Edit pfSense integration`` screen, go to the ``Syslog Host`` field and change ``localhost`` to ``0.0.0.0``.
 #. Click the ``Save and continue`` button and then click ``Save and deploy changes``.
 
-Next, allow the traffic from the pfSense firewall to port 9001. These instructions assume that this is the first firewall change you have made and therefore refer to ``customhostgroup0`` and ``customportgroup0``. If those have already been 
-used, select the next available hostgroup and portgroup.
+Next, allow the traffic from the pfSense firewall to port 9001. These instructions assume that this is the first firewall change you have made and therefore refer to ``customhostgroup0`` and ``customportgroup0``. If those have already been used, select the next available hostgroup and portgroup.
 
 #. Navigate to :ref:`administration` --> Configuration.
 #. At the top of the page, click the ``Options`` menu and then enable the ``Show advanced settings`` option.

release-notes.rst

@@ -8,6 +8,11 @@ Known Issues
 
 - The ``malwarehashregistry`` analyzer (Case -> Observables Tab) is no longer working as of 2.4.100. This is due to a stale third-party library that is incompatible with the latest Python version. `#13571 <https://github.com/Security-Onion-Solutions/securityonion/issues/13571>`_
 
+2.4.100 Hotfix [20240903] Changes
+---------------------------------
+
+- FIX: Missing mappings for WEL Templates
+
 2.4.100 [20240829] Changes
 --------------------------
 

security.rst

@@ -6,15 +6,12 @@ Security
 Vulnerability Disclosure
 ------------------------
 
-If you have any security concerns regarding Security Onion or believe
-you have uncovered a vulnerability, please send an email to 
-security@securityonion.net per the following guidelines:
+If you have any security concerns regarding Security Onion or believe you have uncovered a vulnerability, please send an email to security@securityonion.net per the following guidelines:
 
 -  Include a description of the issue and steps to reproduce
 -  Use plain text format in the email (no Word documents or PDF files)
 
-Please do NOT disclose publicly until we have had sufficient time to 
-resolve the issue.
+Please do NOT disclose publicly until we have had sufficient time to resolve the issue.
 
 .. note::
 

soc-customization.rst

@@ -75,7 +75,7 @@ Action Menu
 
 ::
 
-  ,{ "name": "AbuseIPDB", "description": "Search for this value at AbuseIPDB", "icon": "fa-external-link-alt", "target": "_blank","links": [ "https://www.abuseipdb.com/check/{value}" ]}
+  { "name": "AbuseIPDB", "description": "Search for this value at AbuseIPDB", "icon": "fa-external-link-alt", "target": "_blank","links": [ "https://www.abuseipdb.com/check/{value}" ]}
 
 You can also create background actions that don't necessarily result in the user being taken to a new page or tab. For example, if you want to have a new action submit a case to JIRA, you would define it as a background POST action. When it completes the POST, it will show an auto-fading message in SOC telling you that the action completed. Alternatively, instead of the auto-fading message you can have it pop a new tab (or redirect SOC tab) to JIRA. Because of CORS restrictions, SOC can't expect to have visibility into the result of the background POST so there is no attempt to parse the response of any background action, other than the status code/text from the request's response.
 

soup.rst

@@ -64,7 +64,6 @@ Detections
 Starting in Security Onion 2.4.70, there is a new :ref:`detections` interface. To prepare for migration to :ref:`detections`, soup will do the following:
 
 - Playbook Plays will be backed up to ``/nsm/backup/detections-migration/`` and any active Elastalert rules will be backed up and removed.
-
 - Suricata tuning configurations will be backed to ``/nsm/backup/detections-migration/`` and any thresholds will be migrated over to :ref:`detections`.
 
 Log
@@ -85,9 +84,7 @@ Airgap
 When you run ``soup`` on an :ref:`airgap` install, it will ask for the location of the upgrade media. You can do one of the following:
 
 - burn the latest ISO image to a DVD and insert it in the DVD drive
-
 - flash the ISO image to a USB drive and insert that USB drive
-
 - simply copy the ISO file itself to the airgapped manager
 
 You can also specify the path on the command line using the ``-f`` option. For example (change this to reflect the actual path to the ISO image):
@@ -96,10 +93,14 @@ You can also specify the path on the command line using the ``-f`` option. For e
 
 	sudo soup -y -f /home/YourUser/securityonion-2.4.XYZ-YYYYMMDD.iso
 
-Agents
-------
+Elastic
+-------
+
+If soup updated to a new version of the Elastic stack, then you'll want to go to :ref:`elastic-fleet` and:
 
-If soup updated to a new version of the Elastic stack, then you might need to update your Elastic Agents via :ref:`elastic-fleet`.
+- drill into each of your active agent policies, check the Agent Binary Download setting, and adjust if necessary for your deployment
+- check for any integrations that need to be upgraded
+- check for any agents that need to be upgraded (grid node agents should automatically upgrade so you should just need to look for any additional endpoint agents that you've deployed)
 
 log_size_limit
 --------------
@@ -194,7 +195,7 @@ If you have a distributed deployment with a manager node and separate sensor nod
 
 .. warning::
 
-    Just because the update completed on the manager does NOT mean the upgrade is complete on other nodes in the grid. Do not manually restart anything until you know that all the search/heavy nodes in your deployment are updated. This is especially important if you are using true clustering for :ref:`elasticsearch`.
+    Just because the update completed on the manager does NOT mean the upgrade is complete on other nodes in the grid. Do not manually restart anything until you know that all the search nodes and heavy nodes are updated.
 
     Each minion is on a random 15 minute check-in period and things like network bandwidth can be a factor in how long the actual upgrade takes. If you have a heavy node on a slow link, it is going to take a while to get the containers to it. Depending on what changes happened between the versions, :ref:`elasticsearch` might not be able to talk to said heavy node until the update is complete.
 
@@ -218,4 +219,3 @@ When you run ``soup`` on the manager, it does the following:
 - Issues a command to all minions to update :ref:`salt` if necessary. This is important to note as it takes time to to update the :ref:`salt` minion on all minions. If the minion doesn't respond for whatever reason, it will not be upgraded at this time. This is not an issue because the first thing that gets checked when a minion talks to the master is if :ref:`salt` needs to be updated and will apply the update if it does.
 - Nodes connect back to the manager and actually perform the upgrade to the new version.
 
-