Question & Answer
Question
Why are offenses not generating after changes were made to related default Building Blocks or the Network Hierarchy?
Cause
Some of the default Building Blocks are associated with False Positive Rules and Building Blocks and some of them which are associated with False Positive Rules, also utilize the Network Hierarchy.
Consider the following situation for example. An administrator makes changes to the default NAT_Ranges entry, found within the Network Hierarchy. The administrator then notices that Offenses, related to the CIDR range added to the NAT_Ranges entry, are no longer being generated.
Consider the following situation for example. An administrator makes changes to the default NAT_Ranges entry, found within the Network Hierarchy. The administrator then notices that Offenses, related to the CIDR range added to the NAT_Ranges entry, are no longer being generated.
Answer
A search for the Network Hierarchy entry or Building Block should be conducted, to see if its related to a False Positive Rule and Building Block. Using our previous example of the NAT_Ranges Network Hierarchy entry, we would copy the entries name exactly as it appears within the Network Hierarchy.
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/0.248.gif)
Navigate to the Offenses tab, and then click Rules, found on the menu on the left of the page.
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/1.1F30.gif)
With Rules selected in the Display list, input the name into the search field and press Enter on the keyboard. If the search results listed the FalsePositive: False Positive Rules and Building Blocks rule, then this would be the cause of Offenses no longer being created, relating to the change made. In this example the search did not list a false positive rule, as seen in the image below:
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/2.21D0.gif)
Select Building Blocks from the Display list. The search is conducted again, this time against all Building Blocks. If the search results contained the name of a Building Block, beginning with FalsePositive: this would be the cause of Offenses no longer being created, relating to the change made. In this example the search did not list a false positive Building Block, as seen in the image below:
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/5.4CEE.gif)
In the image above we can see the search resulted in finding the BB:NetworkDefinition: NAT Address Range Building Block, as it contains a rule condition where the local network is NAT_Ranges. You will notice that this Building Block is not a False Positive Building Block, however this Building Block could be utilized by another Rule or Building Block that is a False Positive. The same search steps conducted above, against both Rules and Building Blocks, will need to be repeated; this time searching for the BB:NetworkDefinition: NAT Address Range Building Block.
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/12.8C.gif)
In the image above, we can see the search results contained the FalsePositive: False Positive Rules and Building Blocks rule. which utilizes the BB:NetworkDefinition: NAT Address Range Building Block; which in turn utilizes the NAT_Ranges Network Hierarchy entry.
Another way to determine the cause of an Offense not generating, would be from the perspective of the Event or Flow that should have triggered a Rule, which is outlined in the Technote linked below:
QRadar: Rule not matched, even though all Rule conditions are met.
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/0.248.gif)
Navigate to the Offenses tab, and then click Rules, found on the menu on the left of the page.
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/1.1F30.gif)
With Rules selected in the Display list, input the name into the search field and press Enter on the keyboard. If the search results listed the FalsePositive: False Positive Rules and Building Blocks rule, then this would be the cause of Offenses no longer being created, relating to the change made. In this example the search did not list a false positive rule, as seen in the image below:
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/2.21D0.gif)
Select Building Blocks from the Display list. The search is conducted again, this time against all Building Blocks. If the search results contained the name of a Building Block, beginning with FalsePositive: this would be the cause of Offenses no longer being created, relating to the change made. In this example the search did not list a false positive Building Block, as seen in the image below:
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/5.4CEE.gif)
In the image above we can see the search resulted in finding the BB:NetworkDefinition: NAT Address Range Building Block, as it contains a rule condition where the local network is NAT_Ranges. You will notice that this Building Block is not a False Positive Building Block, however this Building Block could be utilized by another Rule or Building Block that is a False Positive. The same search steps conducted above, against both Rules and Building Blocks, will need to be repeated; this time searching for the BB:NetworkDefinition: NAT Address Range Building Block.
![](/support/pages/system/files/support/swg/sectech.nsf/0/a21771fd58d1cdc485257fd30046f3be/Content/12.8C.gif)
In the image above, we can see the search results contained the FalsePositive: False Positive Rules and Building Blocks rule. which utilizes the BB:NetworkDefinition: NAT Address Range Building Block; which in turn utilizes the NAT_Ranges Network Hierarchy entry.
Another way to determine the cause of an Offense not generating, would be from the perspective of the Event or Flow that should have triggered a Rule, which is outlined in the Technote linked below:
QRadar: Rule not matched, even though all Rule conditions are met.
[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwthAAA","label":"Offenses"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.3.0;7.4.0;7.5.0"}]
Was this topic helpful?
Document Information
Modified date:
24 April 2024
UID
swg21992680