Documentation Center
AlienVault® USM Appliance™

Raising Alarms on SSH Log-in Failure Events - Part 2

Version: 5.x
Deployment: All deployments

This topic is part 2 of "Raising Alarms on SSH Log-in Failure Events" and describes how to raise alarm on an SSH login failure event for specific high priority assets in a specific group.

It also goes into defining a child rule for the directive in order to increase the risk of an alarm based on events that occur following the initial triggering of the directive.

Step 1:Go to Configuration > Threat Intelligence > Directives and select New Directive:

Step 2:Name the directive, select relevant taxonomy values and select a priority for the directive. For example:

Step 3:Next, you need to name the rule. In this example and as we wish to alarm on a failed SSH login attempt, the rule was named Failed Login to High Priority Asset:

Step 4:Next, you need to select the particular event type plugin, in this case SSH was chosen using the search box to find the plugin by name:

Step 5: Now we need to select the particular event sub-types that we want to trigger the alarm.

In this case we only require the alarm to trigger on a Failed SSH password so SSHd: Failed password was selected.

Step 6: The next screen allows for specification of source and destination IP Addresses, networks, Ports etc.

In this case we selected a couple of high priority assets from a previously defined group that contains PCI Assets as the destination hosts for the directive.

The other criteria were left blank which implies any source IP and any source and destination ports.

Step 7:Next, we set a reliability value that will be used in the calculation of the overall risk so that an alarm can be triggered.

In this case we chose 4 as the reliability.

Step 8: You will have the option to define further conditions such as Protocol, Sensor etc by clicking "NEXT".

This was not required in this scenario so we select "FINISH".

​Step 9:Now we want to add an additional rule to this directive so that we can increase the alarm risk should further incorrect logins occur so we must select the plus (+) symbol.

Step 10: We must give this second rule a name. In this case we have called it "Multiple Failed Logins to High Priority Asset".

Step 11: As this is an additional rule instead of selecting individual Plugin Signatures we can simply re-use the Plugin SID from the previous rule which is exactly what we want in this case:

Step 12: In the next step we are given the option to modify the network criteria for the second rule.

In this scenario we want to increase the alarm risk only if the same source and destination are involved in the additional Login Failures.

We do this by using the "From a parent rule" drop-down box:

Step 13: Next we are given the option to change the Reliability of the second rule if triggered. In this scenario we wish to add 2 to the reliability of the parent rule thus increasing the overall risk of the alarm should this rule be triggered.

Step 14: Once the previous options have been selected we are presented with the Directives screen again where we can view and edit the new directive and its rules.

In this case we wish to change the occurrence value of the second rule from its default of "1" to "10" so that the second rule will only trigger on 10 Failed Login Attempts to the any one of the three High Priority Assets from the PCI Asset Group. We also wish for to set a timeout of 60 seconds for those 10 failed login attempts:

Step 15: Once editing is completed we need to restart the server for changes to take effect:

Step 16: Finally, to test the new directive triggers successfully we must perform a failed SSH Login to one of the High Priority Assets we have defined in our Directive.

Then we can check the alarm by going to Analysis > Alarms and filtering for the name of the alarm we created.