You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently received an alert from our Cisco ASA agentless check that the configuration had changed. The alert contained all lines which had not changed and none which had.
As it turned out, the change had been done via the ASDM (GUI). The ASA decided to move a block of lines that had not changed somewhere else and append the line that had changed to the block. The OSSEC alert truncated the diff and so the real addition was not seen, while other lines that had not really changed were in the alert.
Pedantically speaking, this is correct. Those lines were moved, so the whole config changed. This works well for patches, but not for IDS alerts.
I propose an enhancement that does some post-processing before sending the alert. It should do something like sort the output and then compare them, or loop through the left side and compare the right, or compare the diff of the left with the right... or something. The traditional diff could still be available, but the alert should draw attention to true changes.
While this is technically not a bug, it leads to a false sense of what may or may not have changed and obscure what really did. An IDS should present a view useful to an IDS analyst, not necessarily the traditional programmatic diff viewpoint.
The text was updated successfully, but these errors were encountered:
We recently received an alert from our Cisco ASA agentless check that the configuration had changed. The alert contained all lines which had not changed and none which had.
As it turned out, the change had been done via the ASDM (GUI). The ASA decided to move a block of lines that had not changed somewhere else and append the line that had changed to the block. The OSSEC alert truncated the diff and so the real addition was not seen, while other lines that had not really changed were in the alert.
Pedantically speaking, this is correct. Those lines were moved, so the whole config changed. This works well for patches, but not for IDS alerts.
I propose an enhancement that does some post-processing before sending the alert. It should do something like sort the output and then compare them, or loop through the left side and compare the right, or compare the diff of the left with the right... or something. The traditional diff could still be available, but the alert should draw attention to true changes.
While this is technically not a bug, it leads to a false sense of what may or may not have changed and obscure what really did. An IDS should present a view useful to an IDS analyst, not necessarily the traditional programmatic diff viewpoint.
—
Reply to this email directly or view it on GitHub.
I think the "More changes..." at the bottom could be more prescriptive. Maybe something like "Alert truncated. Additional details available on the manager."
Well, not really, but let me explain...
We recently received an alert from our Cisco ASA agentless check that the configuration had changed. The alert contained all lines which had not changed and none which had.
As it turned out, the change had been done via the ASDM (GUI). The ASA decided to move a block of lines that had not changed somewhere else and append the line that had changed to the block. The OSSEC alert truncated the diff and so the real addition was not seen, while other lines that had not really changed were in the alert.
Pedantically speaking, this is correct. Those lines were moved, so the whole config changed. This works well for patches, but not for IDS alerts.
I propose an enhancement that does some post-processing before sending the alert. It should do something like sort the output and then compare them, or loop through the left side and compare the right, or compare the diff of the left with the right... or something. The traditional diff could still be available, but the alert should draw attention to true changes.
While this is technically not a bug, it leads to a false sense of what may or may not have changed and obscure what really did. An IDS should present a view useful to an IDS analyst, not necessarily the traditional programmatic diff viewpoint.
The text was updated successfully, but these errors were encountered: