AWS IoT Device Defender คืออะไร? การแนะนำฟังก์ชันของ AWS IoT ในปี 2023

ปัจจุบัน IoT Device Defender ได้ถูกรวมเข้ากับ IoT Core โปรดอย่าตกใจเมื่อทำการค้นหา IoT Device Defender แล้วเข้าไปในหน้าต่าง IoT Core แทนครับ

บทนำ

ในบทความนี้เราจะมาแนะนำเกี่ยวกับ AWS IoT Device Defender ที่เป็นบริการเกี่ยวกับ "การดำเนินการตรวจสอบความปลอดภัยด้านอุปกรณ์และ Cloud และบรรเทาปัญหาใดๆ ที่พบ" ซึ่งจะขอเรียกย่อๆว่า "Device Defender" ครับ
ซึ่งในบทความนี้จะมีจะเป็นการทำการทดลองจริง โดยนำเนื้อหามาจากบทความ Workshop ต่อไปนี้ที่เป็นภาษาญี่ปุ่น แต่ผมจะมาเรียบเรียงเป็นภาษาไทยให้อ่าน

สำหรับใครที่สนใจอยากทดลองทำ Hands-on ของ Device Defender มีบทความภาษาอังกฤษที่เนื้อหาคล้ายๆ กัน สามารถเข้าไปอ่านได้ที่ลิ้งค์ต่อไปนี้

AWS IoT Device Defender คืออะไร

ถ้าจะให้สรุปในประโยคเดียวก็จะได้คำว่า "Managed service ที่ดำเนินการตรวจสอบความปลอดภัยด้านอุปกรณ์และ Cloud และบรรเทาปัญหาใดๆ ที่พบ"

จากมุมมองด้านความปลอดภัย คุณสามารถตรวจสอบการตั้งค่า cloud และตรวจสอบพฤติกรรมของอุปกรณ์เป็นประจำเพื่อตรวจจับพฤติกรรมที่ผิดปกติได้ นอกจากนี้ยังสามารถเปลี่ยนสถานะเป็นไม่มีความเสี่ยงต่อปัญหาที่ตรวจพบได้โดยอัตโนมัติ

โดยจะมีรายละเอียดตามนี้ครับ

• ตรวจสอบการตั้งค่าความปลอดภัยฝั่ง Cloud
  • ตัวอย่างที่ 1: ตรวจสอบว่า certificate policies ไม่มีสิทธิ์มากเกินไป
  • ตัวอย่างที่ 2: ตรวจสอบว่า certificate หมดอายุแล้วหรือไม่
• การตรวจจับพฤติกรรมผิดปกติที่ไม่ได้รับอนุญาตที่ฝั่งอุปกรณ์
  • ตัวอย่างที่ 1: ตรวจสอบว่ามีการ Listen Port ที่ไม่จำเป็นหรือไม่
  • ตัวอย่างที่ 2: ตรวจสอบว่ามีการรับส่ง traffic ที่ไม่คาดคิดหรือไม่

นอกจากนี้ หากตรวจพบความผิดปกติในระหว่างการตรวจสอบเหล่านี้ ก็สามารถที่จะดำเนินการ "Mitigation actions" และเปลี่ยนการตั้งค่าปัญหาโดยอัตโนมัติเพื่อลดความเสี่ยง ตัวอย่างเช่น "หาก certificate หมดอายุ คุณจะสามารถถอด certificate เก่าออกได้โดยอัตโนมัติ และออก/ติดตั้ง certificate ใหม่" อีกครั้งได้

ด้วยวิธีนี้ จากมุมมองด้านความปลอดภัย การตั้งค่า Cloud และพฤติกรรมของอุปกรณ์จะสามารถตรวจสอบได้อย่างต่อเนื่อง และหากพบปัญหา ช่องโหว่สามารถแก้ไขได้ด้วยการดำเนินการ Mitigation actions ผลกระทบที่กำหนดไว้ล่วงหน้า

Cloud side security audit

ในการตรวจสอบด้าน Cloud รวมถึงการตรวจสอบสิทธิ์ของ IoT Policy ที่มอบให้กับอุปกรณ์, การตรวจสอบวันหมดอายุของ certificate อุปกรณ์ และการแชร์ certificate อุปกรณ์

ตัวอย่างเช่น หาก IoT Policy สำหรับอุปกรณ์บางตัวมีสิทธิ์การใช้งานมากเกินไป ก็อาจทำให้เกิดปัญหาได้หากอุปกรณ์ถูกใช้ในทางที่ผิด ดังนั้นคุณจึงสามารถตรวจสอบได้ว่าสิทธิ์นั้นเหมาะสมหรือไม่

การตรวจสอบเหล่านี้ดำเนินการกับรายการที่กำหนดไว้ล่วงหน้าโดย AWS โดยมีรายละเอียดเนื้อหาการตรวจสอบที่กำหนดไว้ล่วงหน้ามีดังนี้

• Revoked CA certificate still active - AWS IoT Core
• Device certificate shared - AWS IoT Core
• Device certificate key quality - AWS IoT Core
• CA certificate key quality - AWS IoT Core
• Unauthenticated Cognito role overly permissive - AWS IoT Core
• Authenticated Cognito role overly permissive - AWS IoT Core
• AWS IoT policies overly permissive - AWS IoT Core
• Role alias overly permissive - AWS IoT Core
• Role alias allows access to unused services - AWS IoT Core
• CA certificate expiring - AWS IoT Core
• Conflicting MQTT client IDs - AWS IoT Core
• Device certificate expiring - AWS IoT Core
• Revoked device certificate still active - AWS IoT Core
• Logging disabled - AWS IoT Core

คุณสามารถตรวจสอบรายการทั้งหมดหรือเฉพาะรายการที่คุณต้องการ
นอกจากนี้ รายการตรวจสอบเหล่านี้กำหนดระดับความรุนแรงของปัญหาสี่ระดับ คือ "Critical" "High" "Medium" และ "Low"

Scaling

คุณสามารถกำหนดค่าระยะเวลาของการตรวจสอบฝั่ง Cloud ได้ดังนี้:

• ทุกวัน
• วันที่ระบุของสัปดาห์/ทุกสัปดาห์
• สิ้นเดือน/ต้นเดือน/วันที่ระบุ (เช่น วันที่ 16 ของทุกเดือน)
• ไม่ได้ตั้งค่า (รันด้วยตนเองในแต่ละครั้ง)

ด้วยการดำเนินการตรวจสอบอย่างสม่ำเสมอตามเวลาที่กำหนด เราจะรักษาระดับความปลอดภัยที่ดีอย่างต่อเนื่องได้ นอกจากนี้ เมื่อลองตรวจสอบตามความต้องการในสถานะเริ่มต้น มันใช้เวลาประมาณหนึ่งชั่วโมงจึงจะเสร็จสมบูรณ์ ดังนั้นโปรดรออย่างอดทนหลังจากเริ่มการตรวจสอบ

Mitigation actions

จากการดำเนินการตรวจสอบจาก "รายการ security audit" ที่กล่าวถึงข้างต้น หากพบปัญหาด้านความปลอดภัย คุณสามารถดำเนินการ Action เพื่อลดปัญหานั้นได้ สิ่งนี้เรียกว่า "Mitigation actions" ในเอกสารประกอบและ console

Action นี้ ช่วยให้คุณสามารถดำเนินการ Action ที่ลงทะเบียนไว้ล่วงหน้าใน AWS โดยขึ้นอยู่กับรายการที่คุณเลือกไว้ว่าจะดำเนินการ

ยกตัวอย่างเช่น สำหรับรายการ "ค้นหา Policy ที่มีสิทธิ์มากเกินไป" คุณสามารถดำเนินการ "Action บรรเทาการเปลี่ยนแปลงสิทธิ์เป็น Policy เริ่มต้น" ได้

ดูจากภาพด้านล่าง ให้เราทำการสร้าง Mitigation action เตรียมไว้ โดยในกรณีของ Console ให้เปิดหน้า IoT Core แล้วเลือกที่ "Mitigation action" แล้วกด "Create"

ตั้งชื่อ Action อะไรก็ได้ครับ โดยสำหรับ Action type ให้เลือกเป็น "Replace default policy version (Audit mitigation only)" (Action type นี้จะเปลี่ยน Policy ของเป้าหมายให้เป็น Policy ที่ปลอดภัยครับ)

สุดท้ายให้เราใส่ IAM Role ที่จำเป็นครับ

หน้าจอต่อไปนี้เป็นผลของการรันการตรวจสอบ คุณจะเห็นว่าพบ 3 Policy ที่มีสิทธิ์มากเกินไปในระดับ critical

ต่อไปลองตั้งค่าการ Mitigation actions สำหรับปัญหานี้กันดูครับ โดยเราจะมาลองจัดการปัญหานี้โดยเลือก Policy "GreengrassV2IoTThingPolicy" แล้วเลือก "Start mitigation actions" ครับ

ตั้งชื่อ Task name ว่า "tartest-policy-mitigration" เลือก action ที่เราสร้างขึ้น(ของผมคือ tartest) แล้วกด "Start task" ครับ

หลังจากนั้นจะใช้เวลาสักครู่ แล้วในหน้าต่าง Action task จะแสดง task ที่เราสั่งใช้งานเมื่อกี้ไปครับ

พอเข้าไปดูข้างในจะเห็นว่า task ของเราเสร็จสิ้นไปด้วยดี

และเมื่อเราเข้าไปดู Policy ของ "GreengrassV2IoTThingPolicy" ที่เขียนอยู่ในรูปแบบ JSON จะเห็นได้ว่า Policy version 1 และ 2 มีความแตกต่างกัน เนื้อหาใน policy ถูกปรับให้มีสิทธิ์เท่าที่จำเป็นเท่านั้น

สำหรับการตรวจสอบผลลัพท์แบบอื่นๆ หรือ Action ที่สามารถทำได้แบบอื่นๆ มีเขียนรายละเอียดไว้ในเอกสารด้านล่างนี้ สามารถเข้าไปตรวจสอบได้ครับ

AWS IoT Device Defender Detect

ต่อไปเรามาดูสิ่งที่ต้องตรวจสอบที่ฝั่งอุปกรณ์กันดีกว่า Device Defender ยังสามารถตรวจสอบพฤติกรรมที่ฝั่งอุปกรณ์เพื่อตรวจจับพฤติกรรมที่ผิดปกติได้อีกด้วย สิ่งนี้เรียกว่า AWS IoT Device Defender Detect

การตรวจสอบอุปกรณ์สามารถกำหนดได้โดยใช้ Metric 2 ประเภท

• Metric ฝั่ง Cloud
• Metric ฝั่งอุปกรณ์

Metric ฝั่ง Cloud

ฝั่ง Cloud จะกำหนดว่าพฤติกรรมนั้นผิดปกติหรือไม่ โดยพิจารณาจากสิ่งต่างๆ เช่น "ขนาดของข้อความที่ได้รับจากอุปกรณ์" และ "จำนวน error ในการรับรองความถูกต้องเมื่อเชื่อมต่อจากอุปกรณ์ไปยัง cloud" โดยมีหลักเกณฑ์การตัดสินตามเที่เราตั้งค่าไว้ (สามารถใช้ Machine learning ในการตัดสินได้ ซึ่งในส่วนนี้จะอธิบายในภายหลัง)

Metric ฝั่งอุปกรณ์

ในด้านอุปกรณ์ คุณสามารถส่งค่า Metric ไปยัง AWS เพื่อตรวจสอบพฤติกรรม เช่น อุปกรณ์กำลังรับฟังพอร์ตที่ไม่คาดคิดหรือไม่ หรืออุปกรณ์กำลังส่งแพ็กเก็ตที่มีขนาดที่ไม่คาดคิดหรือไม่

ในการรวบรวม Metric แล้วทำการส่ง จำเป็นต้องเปิดใช้งาาน Agent บน อุปกรณ์ โดยเราแนะนำให้ใช้ Agent "AWS IoT Device Client" เพราะใช้งานได้ง่ายดี

เมื่อใช้ "AWS IoT Device Client" คุณจะสามารถรับ Metric ฝั่งอุปกรณ์และส่งไปยัง AWS IoT Core ได้

มี Metric หลายประเภทให้เลือก เช่น "Bytes out (aws:all-bytes-out)" และ "Listening TCP port count (aws:num-listening-tcp-ports)" โดยสามารถดูรายละเอียดของ Metric ทุกประเภทได้จากเอกสารด้านล่าง

หากการลง Agent บนอุปกรณ์เป็นเรื่องที่เป็นไปได้ยาก คุณสามารถดำเนินการตรวจสอบโดยใช้ Metric แค่ฝั่งคลาวด์อย่างเดียวก็ได้ครับ
ประเภทของ Metric ที่อยู่ในฝั่ง Cloud และ ฝั่งอุปกรณ์ สามารถตรวจสอบได้จากเอกสารต่อไปนี้

การแก้ไขปัญหาฝั่งอุปกรณ์

หากคุณต้องการแก้ไขปัญหาที่ Device Defender Detect ตรวจพบ คุณสามารถใช้ฟังก์ชันการทำงานของ AWS IoT Management เพื่อแก้ไขปัญหาดังกล่าวได้ (Device Defender จะไม่มีฟังก์ชันแบบ standalone ให้ใช้)

ในบทความนี้จะไม่ลงลึกเกี่ยวกับ AWS IoT Management แต่จะขอเขียนคร่าวๆ เกี่ยวกับขั้นตอนโดยรวมไปประมาณนี้

• ลงทะเบียน Job ตามเนื้อหาที่ตรวจพบ
  • อาจจะทำ Job's Document
• รัน Job ให้ ฝั่งอุปกรณ์รับ Job
• ดำเนินการประมวลผลที่เหมาะสมในด้านอุปกรณ์ตามเนื้อหางาน
• ปัญหาหายไป

กระบวนการที่ทำงานบนอุปกรณ์ที่ได้รับงานนั้นขึ้นอยู่กับอุปกรณ์ ดังนั้นจึงต้องดำเนินการโดยผู้ใช้ สิ่งนี้ยังใช้กับกรณีที่ใช้ฟังก์ชันงานของ IoT Management แยกต่างหากอีกด้วย (อีกวิธีหนึ่งในการพูดคือ "ใช้ฟังก์ชันงานเพื่อแก้ไขปัญหา")

ลองใช้งาน AWS IoT Device Defender Detect

เอาล่ะ มาดูการวินิจฉัยและแก้ไขปัญหาที่เกิดขึ้นกับอุปกรณ์กัน โดยอิงจากสถานการณ์สมมติต่อไปนี้

การกำหนดและตรวจสอบพฤติกรรมปกติ

ก่อนอื่น เราต้องสร้าง "Security Profile" เพื่อกำหนดพฤติกรรมปกติที่คาดหวังสำหรับอุปกรณ์
โดยเข้าไปที่หน้าต่าง IoT Core -> Manage -> Security -> Intro ครับ

ในหน้าต่างต่อไปให้เราตั้งค่า "Rule-based anormaly Detect profile" ที่ใช้สำหรับสร้างการตรวจสอบความผิดปกติต่างๆในอุปกรณ์ IoT ของเรา
โดยเมื่อ "Security Profile" ตรวจพบความผิดปกติ ให้เราทำการแจ้งเตือนไปยัง Topic ของ SNS

ตามด้านล่างนี้ เราจะลองทำการตั้งค่า

โดยในหัวข้อที่เราสามารถตรวจสอบพฤติกรรมปกติที่คาดหวังสำหรับอุปกรณ์จะมีรายการ(Metric type)ประมาณเท่านี้ครับ
และเราสามารถสร้าง Custom Metric type เองได้ด้วยในหัวข้อ "Metrics" (มีอธิบายเพิ่มเติมในหัวข้อต่อไป)

ตั้งค่าทุก Step เสร็จแล้วก็ทำการกด "Create" ครับ

พอสร้างเสร็จแล้ว เราก็จะได้รายการแบบนี้

เมื่อคลิกเข้าไปที่ชื่อ เราจะสามารถตรวจจสอบรายการต่างๆ ได้

เมื่อเราดู Alarms จะเห็นว่าไม่มี Alarms ที่ขึ้นมาตอนนี้ เพราะไม่มีความผิดปกติตอนนี้

หากเราเจอความผิดปกติ เมื่อเราเข้าไป จะไปโผล่ที่หน้าต่าง Alarms ครับ

แก้ไขความผิดปกติโดยใช้ฟังก์ชัน Job

ในหัวข้อนี้เราจะมาทำการนำเสนอเกี่ยวกับฟังก์ชัน Job ที่ใช้ในการแก้ไขปัญหาต่างๆ ในฝั่ง Device กันบ้างครับ

ทำไมถึงใช้ฟังก์ชัน Job

โดยปกติแล้ว สภาพแวดล้อมของอุปกรณ์จะแตกต่างกันไป ดังนั้นแม้ว่าคุณจะต้องการแก้ไขปัญหาที่ตรวจพบ คุณก็จำเป็นต้องพิจารณาวิธีการแก้ไขด้วยวิธีที่แตกต่างกันไปเช่นกัน

ตัวอย่างเช่น ภาษาการเขียนโปรแกรม วิธีการควบคุม OS ฯลฯ ที่สามารถใช้กับอุปกรณ์ดังกล่าวจะแตกต่างกันไปขึ้นอยู่กับสภาพแวดล้อมและอุปกรณ์ ดังนั้นแม้จะตรวจพบปัญหาในกรณีมีความผิดปกติที่ฝั่งเครื่องก็ไม่สามารถแก้ไข “ปัญหาทั้งหมด” บน “อุปกรณ์ทั้งหมด” ได้อย่างง่ายดายด้วยฟังก์ชันเดียว

ในส่วนนี้นี่เอง คุณสามารถแก้ไขปัญหาได้โดยการเขียนเนื้อหาที่คุณต้องการประมวลผลโดยใช้ฟังก์ชัน Job ใน Job File หรือโดยการอ่านเนื้อหาใน Job File และดำเนินการตามกระบวนการการแก้ปัญหาที่ต้องการ

แน่นอนว่า หากคุณมีระบบหรือกลไกการจัดการอุปกรณ์ที่มีอยู่แยกจากฟังก์ชัน Job และสามารถดำเนินการประมวลผลบางอย่างบนอุปกรณ์ได้ ก็ไม่จำเป็นต้องใช้ฟังก์ชัน Job
คุณจะใช้ระบบที่คุณมีอยู่ในการตรวจสอบและแก้ไขปัญหาเองก็ได้

สำหรับ Job File คุณสามารถเลือกเป็นไฟล์ที่เก็บไว้ใน S3 ได้

และ นี่คือคือตัวอย่างหน้าตา Job ที่ผมสั่งใช้งานไปครับ

ดำเนินการจัดการปัญหาด้วย Mitigation actions

จนถึงจุดนี้ เราได้เห็นแล้วว่าปัญหาด้านอุปกรณ์ที่ตรวจพบโดย Device Defender Detect สามารถแก้ไขได้โดยใช้ฟังก์ชัน "Jobs"

อย่างไรก็ตาม คุณอาจสังเกตเห็นว่าหน้าจอ "Alarms" มีปุ่ม "Start mitigation actions" ด้วยเช่นกัน

ในตรงนี้เองผมก็คิดกับตัวเองอยู่ครู่หนึ่งว่า "บางทีนี่อาจดำเนินการจัดการปัญหาด้วยปุ่มนี้ กับปัญหาที่ตรวจพบโดยไม่ต้องใช้ฟังก์ชัน Job ได้" อย่างไรก็ตาม เนื่องจากปัญหาด้านอุปกรณ์ขึ้นอยู่กับอุปกรณ์ จึงไม่สามารถแก้ไขได้ด้วยปุ่มเดียวบนฝั่ง AWS

"Mitigation actions" เพียงอย่างเดียวที่สามารถทำได้ที่นี่คือการดำเนินการที่กำหนดไว้ล่วงหน้า คุณสามารถระบุ "Mitigation actions" ที่สร้างขึ้นในส่วน "การตรวจสอบความปลอดภัยฝั่งคลาวด์" ได้

โปรดทราบว่าในบรรดาการกระทำหลายประเภทนั้น ประเภทการกระทำที่สามารถดำเนินการด้วย "Mitigation actions" นั้นมีข้อจำกัด สามารถระบุได้เฉพาะประเภทการดำเนินการที่รองรับ "การตรวจจับ" เป็นการดำเนินการลดผลกระทบสำหรับ "Mitigation actions" ได้

ในฟังก์ชัน Job ของ Device Management เราสามารถเลือก Group ที่เราสามารถใช้คำสั่ง Job ได้ ทำให้การใช้ mitigation actions สามารถใช้งานได้ง่ายขึ้น

Custom Metric

จนถึงจุดนี้ เราได้เลือกและกำหนด "การทำงานของอุปกรณ์ตามปกติ" จาก Metric ที่ AWS มอบให้ หากคุณต้องการกำหนดลักษณะการทำงานที่ไม่มีอยู่ในตัวเลือก คุณยังสามารถกำหนดลักษณะการทำงานใดๆ ให้เป็น Metric ที่กำหนดเองได้

หากคุณต้องการใช้ คุณจะต้องดำเนินกระบวนการเพื่อรวบรวม Metric บนอุปกรณ์ของคุณและส่งไปยัง AWS ด้านล่างนี้เป็นเอเจนต์ตัวอย่างที่ใช้ "AWS IoT Device Defender Agent SDK (Python)" ตัวอย่างนี้ใช้การใช้งาน CPU เป็น Custom Metric

วิธีการใช้แยกกับ CloudWatch

เมื่อพูดถึง คีย์เวิร์ด Custom Metrics เรามักจะนึกถึง CloudWatch แต่ Device Defender เป็นฟังก์ชันสำหรับการตรวจสอบความปลอดภัยโดยเฉพาะ

ดังนั้นคุณลักษณะของ Device Defender จึงมีจุดเด่นมีความสามารถในการบรรเทาช่องโหว่ได้อย่างง่ายดายด้วยการดำเนินการ Mitigation actions และฟังก์ชัน Job ที่ทำงานได้หลายอย่าง

AWS IoT Device Defender ML Detect

จากเนื่อหาในหัวข้อที่ผ่านมา เพื่อตรวจจับความผิดปกติของอุปกรณ์ เราต้องกำหนดพฤติกรรมที่คาดหวังไว้ล่วงหน้าว่าเป็น "การทำงานปกติ" ไว้ก่อน แต่อย่างไรก็ตาม ลักษณะการทำงานอาจเปลี่ยนแปลงระหว่าง "วันหยุดสุดสัปดาห์และวันธรรมดา" หรือ "กลางวันและกลางคืน" โดยขึ้นอยู่กับอุปกรณ์

ในกรณีแบบนี้ เราสามารถใช้ Machine Learning ในการตรวจสอบความผิดปกติต่างๆได้
ด้วยการตรวจสอบจาก Machine Learning เราจะสามารถตรวจสอบความผิดปกติของอุกรณ์ได้โดยการให้เรียนรู้การกระทำต่างๆของอุปกรณ์

เนื่องจาก ML Detect เป็น Machine Learning คุณจึงต้องเตรียมข้อมูลที่จำเป็นสำหรับการเรียนรู้ล่วงหน้า โดยข้อกำหนดขั้นต่ำคือ "25,000 Datapoint ต่อ Metric ในช่วง 14 วันที่ผ่านมา"

นอกจากนี้ Custom Metrics ก็มีทั้งอันนี้รองรับ และ ยังไม่รองรับอยู่ตอนนี้ หากต้องการพิจารณาการใช้งาน ผมแนะนำให้ตรวจสอบเอกสารด้านล่างนี้ก่อนครับ

ทิ้งท้าย

แม้จะเรียกสรุปสั้นๆได้ง่ายๆว่า "การตรวจสอบอุปกรณ์(Device Defender)" แต่เนื้อหาก็มีหลากหลาย ทำให้ผมต้องใช้เวลาพอสมควรในการพิจารณาว่าจะเริ่มเขียนจากตรงไหน

หากคุณกำลังใช้งาน AWS IoT การเริ่มต้นด้วย Device Defender ก็เป็นอะไรที่ดีเพราะมีหลาย Use case ที่สามารถใช้กับหลายๆสถานการณ์ได้

นี่เป็นบทความที่ค่อนข้างยาว แต่ผมหวังว่าจะเป็นประโยชน์กับใครบางคนที่กำลังใช้ หรือกำลังจะเริ่มใช้ AWS IoT นะครับ

บทความอ้างอิง

• AWS IoT 再入門ブログリレー AWS IoT Device Defender 編 | DevelopersIO (Japanese)
• デバイスのセキュリティ監査ができる「AWS IoT Device Defender」が一般提供開始になりました！！ | DevelopersIO (Japanese)
• レポート IoTデバイスを安全に保つ #reinvent #IOT205 | DevelopersIO (Japanese)
• AWS IoT Device Defender workshop (Japanese)
• Audit checks - AWS IoT Core (English)
• Audit - AWS IoT Core (English)
• Mitigation actions - AWS IoT Core (English)
• New AWS IoT Device Client simplifies onboarding to AWS IoT Core, AWS IoT Device Management, and AWS IoT Device Defender (English)
• awslabs/aws-iot-device-client: The AWS IoT Device Client provides device-side functionality for AWS IoT Services. (English)
• Device-side metrics - AWS IoT Core (English)
• Security use cases - AWS IoT Core (English)
• Custom metrics - AWS IoT Core (English)
• aws-iot-device-defender-agent-sdk-python/README.rst at master · aws-samples/aws-iot-device-defender-agent-sdk-python (English)
• ML Detect - AWS IoT Core (English)