Amazon IoT Device Defender troubleshooting guide

A: If you want to use device-reported metrics, you must first deploy an agent on your Amazon IoT connected devices or device gateways. Devices must provide a consistent client identifier or thing name.

A: When a check is enabled, data collection starts immediately. However, if your account has a large amount of data to collect (for example, certificates, things, or policies), the results of the check might not be available for some time after you have enabled it.

A: Start by creating a security profile behavior with low thresholds and attach it to a thing group that contains a representative set of devices. You can use Amazon IoT Device Defender to view the current metrics, and then fine-tune the device behavior thresholds to match your use case.

A: When you define a behavior, you are specifying how you expect your device to behave normally. For example, if you have a security camera that only connects to one central server on TCP port 8888, you don't expect it to make any other connections. To be alerted if the camera makes a connection on another port, you define a behavior like this:

{
  "name": "Listening TCP Ports",
  "metric": "aws:listening-tcp-ports",
  "criteria": {
    "comparisonOperator": "in-port-set",
    "value": {
      "ports": [ 8888 ]
    }
  }
}

If the camera makes a TCP connection on TCP port 443, the device behavior would be violated and an alert would be triggered.

A: Alarms clear after the device returns to expected behavior, as defined in the behavior profiles. Behavior profiles are evaluated upon receipt of metrics data for your device. If the device doesn't publish any metrics for more than two days, the violation event is set to alarm-invalidated automatically.

A: Deleting a behavior stops all future violations and alerts for that behavior. Earlier alerts must be drained from your notification mechanism. When you delete a behavior, the record of violations of that behavior is retained for the same time period as all other violations in your account.

A: Check that your metrics reports are being accepted by subscribing to the following MQTT topics:

$aws/things/THING_NAME/defender/metrics/FORMAT/rejected
$aws/things/THING_NAME/defender/metrics/FORMAT/accepted

THING_NAME is the name of the thing reporting the metric and FORMAT is either "JSON" or "CBOR," depending on the format of the metrics report submitted by the thing.

After you have subscribed, you should receive messages on these topics for each metric report submitted. A rejected message indicates that there was a problem parsing the metric report. An error message is included in the message payload to help you correct any errors in your metric report. An accepted message indicates that the metric report was parsed properly.

A: An empty list of ports or IP addresses is always considered in conformity with the corresponding behavior. If the corresponding behavior was in violation, the violation is cleared.

If you have one or more security profiles attached to all things or to all unregistered things, Amazon IoT Device Defender includes metrics from unregistered things. If you want to exclude metrics from unregistered things, you can attach the profiles to all registered devices instead of all devices.

Verify that you are sending a well-formed metrics report using one of the supported formats. For information, see Device metrics document specification. Verify that the unregistered devices are using a consistent client identifier or thing name. If the thing name contains control characters or is longer than 128 bytes of UTF-8 encoded characters, messages reported by devices are rejected .

A: If a device is added to or removed from the registry:

A: Use a unique value for each metric report, expressed as a positive integer. A common practice is to use a Unix epoch timestamp.

A: A separate MQTT connection is not required.

For devices (things) that are in the Amazon IoT registry, use the registered thing name. For devices that are not in the Amazon IoT registry, use a consistent identifier when you connect to Amazon IoT. This practice helps match the violations to the thing name.

It is possible to publish metrics on behalf of another thing. You can do this by publishing the metrics to the Amazon IoT Device Defender reserved topic for that device. For example, Thing-1 would like to publish metrics for itself and also on behalf of Thing-2. Thing-1 collects its own metrics and publishes them on the MQTT topic:

$aws/things/Thing-1/defender/metrics/json

Thing-1 then obtains metrics from Thing-2 and publishes those metrics on the MQTT topic:

$aws/things/Thing-2/defender/metrics/json

A: See Amazon IoT Device Defender Endpoints and Quotas.

A: A role that allows Amazon IoT Device Defender to publish alerts on an alert target (SNS topic) requires two things:

A: The type number only takes a single metric value as an input, but while submitting the metrics value in the DeviceMetrics report, it must be passed as an array with a single value. Make sure you're submitting the metric value as an array.

Error payload:

{"header":{"report_id":12334567,"version":"1.0"},"metrics":{"network_stats":{"bytes_in":30680,"bytes_out":10652,"packets_in":113,"packets_out":118}},"custom_metrics":{"my_custom_metric":{"number":0}}}

Error message:

{"thingName":"myThing","status":"REJECTED","statusDetails":{"ErrorCode":"InvalidPayload","ErrorMessage":"Malformed metrics report"},"timestamp":1635802047699}

No-error payload:

{"header":{"report_id":12334567,"version":"1.0"},"metrics":{"network_stats":{"bytes_in":30680,"bytes_out":10652,"packets_in":113,"packets_out":118}},"custom_metrics":{"my_custom_metric":[{"number":0}]}}

Response:

{"thingName":"myThing","12334567":1635800375,"status":"ACCEPTED","timestamp":1635801636023}