USM Anywhere Sensors sometimes disconnect from the USM Anywhere service (for example, during an update process). There is a process every hour to verify if the sensor Sensors are deployed into an on-premises, cloud, or multi-cloud environment to collect log and other security-related data. This data is normalized and then securely forwarded to USM Anywhere for analysis and correlation. has been disconnected for 30 minutes or longer. When this happens, USM Anywhere informs users in a Manager role by email and generates an event. A new event is generated every 30 minutes until the sensor reconnects.
Note: Logs, including NXLog messages, are cached locally and will be forwarded to USM Anywhere when the connection resumes.
When a sensor disconnects from the USM Anywhere service, it sends an email notice within two hours to the email address you used to sign into USM Anywhere (as long as you are in a Manager role). This notice informs you that your sensor is not connected. You can immediately take action to restore your service either by working with AT&T Cybersecurity Technical Support or by making an environmental, network connectivity change.
The notification will be generated daily until the sensor is reconnected. After seven days, the notifications will no longer be issued.
USM Anywhere checks every hour to verify whether the sensor has been reconnected. After your sensor reconnects, you receive an email notification informing you that your service has been restored. Because of this automated notification, you do not have to log in to the product to check the sensor connection status. USM Anywhere generates an event when a sensor reconnects.
Creating an Alarm Rule from these Events
Although USM Anywhere informs users in a Manager role by email when a sensor has been disconnected from the service and when the sensor has been reconnected, you can create an alarm rule to have more control when these events occur. The following activity is an example of how to create an alarm rule from the sensor offline event. You can do the same for the sensor reconnected event by entering reconnected in step 2.
To create an alarm rule from the Sensor Appears Offline event
- Go to Activity > Events.
- Enter offline in the Enter search phrase field.
- Click one of the events.
- Select Create Rule > Create Alarm Rule.
The Create Alarm Rule dialog box opens.
Select a packet type in the Match drop-down list. The first match criteria for all rules must be the packet_type detail field:
Logs: Use this packet type for event-based rules.
Warnings: Use this packet type for configuration issues-based rules1.
Vulnerabilities: Use this packet type for vulnerabilities-based rules.
- Click Add Conditions and select the property values you want to include in the rule to create a matching condition.
- (Optional.) Click Add Group to group your conditions.
- Click Next.
- Enter a name for the rule.
- Select an intent.
- Enter a method.
- Select a strategy.
- Enter a priority.
- Configure a mute value.
Modify these two options:
- Occurrences: Specify the number of event occurrences that produce a match on the conditional expression to trigger the rule. You can enter the number of occurrences or use the arrow to scroll the value up or down. You need to enter a number between 1 and 100.
Length: Specify the length of the timespan used to identify a match for multiple occurrences. Enter the number and choose a value of seconds, minutes, or hours.
This duration identifies the amount of time that transpires from the beginning to end of the occurrence. If the number of occurrences is not met within this period, the rule is not a match.
In this example, the rule applies when the configured conditions happen five times every three hours.
These two options function together to specify the number of occurrences within a time period that will produce a match for the rule. For example, you can define a rule to trigger an alarm Alarms provide notification of an event or sequence of events that require attention or investigation. for an unauthorized access An incident-type categorization that may be a precursor to other actions or stages of an attack. attempt when a failed SSH Program to securely log into another computer over a network, execute commands in a remote machine, and move files from one machine to another through Secure Copy (SCP). login Log in (verb): Process in which an individual gains access to a computer system after providing sufficient credentials to authenticate their unique identity. Login (noun): User credentials, typically a username and matching password. occurs three times within a five-minute window.
(Optional.) Select the fields that you want to display in the generated alarm.
You can select or remove the fields you want to include in the details of the alarm. A field passes from one column to the other by clicking it.
- (Optional.) Enter a description for identifying this rule.
The created rule displays in the list of rules. You can see it from Settings > Rules > Orchestration Rules. See Orchestration Rules for more information.
Note: If the field is related to the name of a country, you should use the country code defined by the ISO 3166.
Note: The Sources or Destinations field needs to match the universally unique identifier (UUID) of the event or alarm. You can use the Source Name or Destination Name field instead.
Important: Instead of using the equals and equals, case insensitive operators for array fields, AT&T Cybersecurity recommends the use of the in or contains operators.
Note: If you need to add a property value that maps with a property key, you need to know the mapping of the field. See Determining the Mapping of a Field for more information.
Note: See Operators in the Orchestration Rules for more information.
Note: The current rule box shows you the syntax of your rule, and the rule verification box checks that syntax before saving the rule.
Important: A dialog box opens if there are warning messages. Click Cancel to review the warning messages, or click Accept to continue creating the rule.
The intent describes the context of the behavior that is being observed. These intents roughly map to the stages of the intrusion kill chains, but are collapsed to ensure that each is discrete. See Intent for more information about the available threat categories.
If known, it is the method of attack or infiltration Indicator that specifies the method of attack that generated an alarm. For Open Threat Exchange® (OTX™) pulses, this method is the pulse name. associated with the indicator that generated the alarm.
Note: This is a required field; if you do not complete this field, the Save button remains inactive.
The strategy describes the broad-based strategy or behavior that is detected. The intention is to describe the strategy the malicious Activity in a system that exceeds or misuses that access in a manner that negatively affects the confidentiality, integrity, or availability of the organization's information systems. user is using to achieve their goal.
See Priority Field for Alarms for more information.
Once an alarm is created, you can set the time that USM Anywhere will not create a new alarm based on the same conditions. This configured time is the mute value and you can specify it in seconds, minutes, and hours.