Skip to content

Kiểm thử bảo mật cho thiết bị nhúng

Trang này tổng quan về kiểm thử bảo mật (security testing) cho thiết bị nhúng và các phương pháp, guide được dùng phổ biến. Nội dung đi theo thứ tự: các loại hoạt động kiểm thử, mức hiểu biết của người kiểm thử về hệ thống, các lớp của thiết bị cần kiểm thử, so sánh các phương pháp và guide, cách chọn phương pháp theo mục tiêu, và quy trình chung của một đợt kiểm thử. Chi tiết từng guide nằm ở các trang con, hiện có OWASP WSTG.

Các loại hoạt động kiểm thử

Thuật ngữ "kiểm thử bảo mật" bao gồm nhiều hoạt động khác nhau. Mỗi hoạt động trả lời một câu hỏi riêng, nên không thay thế được cho nhau.

Năm loại hoạt động kiểm thử bảo mật và câu hỏi mỗi loại trả lời

Hoạt động Câu hỏi Cách làm Trang liên quan
Quét lỗ hổng (vulnerability scanning) Thiết bị đang chứa lỗ hổng đã biết nào? Công cụ tự động đối chiếu phiên bản phần mềm, dịch vụ với cơ sở dữ liệu lỗ hổng; chạy định kỳ CVE, InsightVM (Rapid7)
Review mã nguồn Mã có điểm yếu nào trước khi được build? Đọc mã thủ công kết hợp công cụ phân tích tĩnh
Penetration test (pentest) Kẻ tấn công khai thác được gì trong phạm vi đã thỏa thuận? Người kiểm thử đóng vai kẻ tấn công, kết hợp công cụ và thao tác thủ công, trong thời gian giới hạn OWASP WSTG
Red team Tổ chức có phát hiện và phản ứng được với một cuộc tấn công thật không? Mô phỏng tấn công theo kịch bản mối đe dọa, nhắm vào cả con người, quy trình và hệ thống
Audit tuân thủ Sản phẩm có đáp ứng yêu cầu của một tiêu chuẩn không? Chạy test case do tiêu chuẩn định nghĩa và thu thập bằng chứng Chứng nhận và tuân thủ bảo mật

Quét lỗ hổng chỉ tìm được lỗ hổng đã có trong cơ sở dữ liệu, và không phát hiện được lỗi logic hay lỗi phân quyền riêng của sản phẩm. Pentest tìm được các lỗi đó nhưng chỉ trong phạm vi và thời gian đã thỏa thuận, nên không chứng minh được sản phẩm không còn lỗi. Với thiết bị nhúng, nhà sản xuất thường kết hợp quét lỗ hổng trong quy trình build, pentest trước mỗi bản phát hành lớn, và audit theo tiêu chuẩn khi cần chứng nhận. Red team thường áp dụng cho tổ chức vận hành hệ thống hơn là cho một sản phẩm.

Mức hiểu biết của người kiểm thử

Người kiểm thử được cung cấp càng nhiều thông tin thì càng tìm được nhiều lỗi trong cùng một khoảng thời gian, nhưng kết quả càng ít giống góc nhìn của kẻ tấn công bên ngoài.

Mức Thông tin được cung cấp Ví dụ với thiết bị nhúng Ưu điểm Hạn chế
Black-box Chỉ có thiết bị, như một khách hàng Một chiếc router mua trên thị trường Giống góc nhìn kẻ tấn công không có thông tin nội bộ Tốn thời gian cho trinh sát; dễ bỏ sót nhánh mã ít dùng
Gray-box Một phần thông tin nội bộ Ảnh firmware, tài khoản quản trị, tài liệu giao diện Cân bằng giữa độ sâu và tính thực tế; phổ biến nhất khi pentest sản phẩm Kết quả phụ thuộc thông tin được chọn để cung cấp
White-box Toàn bộ thông tin Mã nguồn, cấu hình build, sơ đồ mạch, kết quả threat model Bao phủ rộng nhất trong cùng thời gian Ít phản ánh mức khó khai thác thực tế

WSTG nhận định rằng pentest kiểu black-box cho kết quả trực quan nhưng không phải cách hiệu quả nhất để bảo đảm an toàn; khi có mã nguồn, nên cung cấp cho người kiểm thử.

Các lớp của thiết bị cần kiểm thử

Một thiết bị nhúng có nhiều lớp, và mỗi lớp có guide kiểm thử riêng. Một đợt pentest sản phẩm đầy đủ thường đi qua nhiều lớp, và lỗ hổng nghiêm trọng thường nằm ở chỗ nối giữa các lớp: ví dụ trích xuất firmware qua cổng UART ở lớp phần cứng, rồi tìm thấy mật khẩu cố định dùng cho giao diện web.

Sáu lớp của thiết bị nhúng và guide kiểm thử thường dùng cho mỗi lớp

Lớp Đối tượng kiểm thử Guide thường dùng
Ứng dụng di động, cloud đi kèm Ứng dụng điều khiển thiết bị, API phía server OWASP MASTG; WSTG cho phần API
Giao diện web và API Trang quản trị, REST API, WebSocket OWASP WSTG
Dịch vụ mạng SSH, Telnet, SNMP, UPnP, giao thức riêng Khung chung như PTES, NIST SP 800-115; với thiết bị viễn thông, yêu cầu trong 3GPP TS 33.117
Giao tiếp vô tuyến Wi-Fi, BLE, Zigbee, LTE/5G OSSTMM (kênh không dây), PTF (Bluetooth, wireless)
Firmware và hệ điều hành Ảnh firmware, thành phần mã nguồn mở, cấu hình Linux, cơ chế cập nhật OWASP FSTM
Phần cứng Cổng UART, JTAG, SWD; chip flash; secure element OWASP ISVS; FSTM cho bước trích xuất firmware

Todo

Viết trang riêng cho kiểm thử firmware và phần cứng (FSTM, ISVS, UART, JTAG, đọc flash).

So sánh các phương pháp và guide

Các tài liệu kiểm thử bảo mật thuộc ba tầng khác nhau, cộng thêm hai nhóm không phải phương pháp kiểm thử nhưng thường được nhắc cùng:

Bản đồ các phương pháp: khung tổ chức, guide chi tiết, test case theo tiêu chuẩn, red teaming và công nhận năng lực

Khung tổ chức một đợt kiểm thử

Các khung này mô tả các giai đoạn của một đợt kiểm thử và cách lập kế hoạch, ít đi vào thao tác cho từng loại hệ thống.

Phương pháp Tổ chức Nội dung chính Dùng khi
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment NIST (Mỹ) Kỹ thuật review; nhận diện và phân tích mục tiêu; xác minh lỗ hổng; lập kế hoạch, thực hiện và xử lý sau đánh giá Cần khung được cơ quan nhà nước công nhận; môi trường chịu quản lý của Mỹ
Penetration Testing Execution Standard (PTES) Cộng đồng pentester 7 giai đoạn: thỏa thuận trước kiểm thử, thu thập thông tin, threat model, phân tích lỗ hổng, khai thác, sau khai thác, báo cáo; kèm hướng dẫn kỹ thuật về công cụ Cần khung đầy đủ từ lúc ký thỏa thuận tới lúc báo cáo
Open Source Security Testing Methodology Manual (OSSTMM) ISECOM Kiểm thử an ninh vận hành qua nhiều kênh: con người, vật lý, không dây, viễn thông, mạng dữ liệu; có metric định lượng và mẫu báo cáo STAR Cần đo lường định lượng; phạm vi rộng hơn hệ thống CNTT, gồm cả vật lý và con người
PCI DSS Penetration Testing Guidance PCI Security Standards Council Thành phần của pentest, năng lực người kiểm thử, phương pháp, hướng dẫn báo cáo; gắn với yêu cầu pentest của PCI DSS Hệ thống xử lý dữ liệu thẻ thanh toán

Guide chi tiết theo lớp của hệ thống

Guide Tổ chức Đối tượng Ghi chú
Web Security Testing Guide (WSTG) OWASP Ứng dụng web, API 97 test case trong bản 4.2; xem OWASP WSTG
Mobile Application Security Testing Guide (MASTG) OWASP Ứng dụng Android, iOS Đi cùng bộ yêu cầu MASVS
Firmware Security Testing Methodology (FSTM) OWASP Firmware IoT Các bước từ thu thập thông tin, trích xuất, phân tích tới emulation và khai thác
IoT Security Verification Standard (ISVS) OWASP Toàn bộ thiết bị IoT Bộ yêu cầu, gồm cả phần cứng và hệ sinh thái
Penetration Testing Framework (PTF) vulnerabilityassessment.co.uk Theo từng loại đối tượng Danh sách thao tác và công cụ cho Bluetooth, Cisco, VoIP, wireless, an ninh vật lý

Test case theo tiêu chuẩn thiết bị

Nhóm này không phải phương pháp pentest tổng quát. Đây là các bộ test case do tiêu chuẩn định nghĩa, dùng để lấy bằng chứng khi đánh giá sự phù hợp.

Bộ test case Tổ chức Dùng cho Trang liên quan
ETSI TS 103 701 ETSI Đánh giá IoT tiêu dùng theo ETSI EN 303 645 Consumer IoT
3GPP SCAS (TS 33.117 và các TS 33.5xx) 3GPP Thiết bị mạng 5G; đầu vào của GSMA NESAS Telecom & RAN
O-RAN WG11 Security Test Specifications O-RAN Alliance O-RU, O-DU và các giao diện mở của O-RAN Telecom & RAN
IEC 62443-4-1, nhóm thực hành kiểm thử xác minh và thẩm định (practice 5) IEC Thiết bị và phần mềm cho hệ thống điều khiển công nghiệp Chưa có trang

Theo các tài liệu thứ cấp, practice 5 của IEC 62443-4-1 gồm yêu cầu kiểm thử lỗ hổng (SVV-3: fuzz testing, phân tích bề mặt tấn công, quét lỗ hổng đã biết) và yêu cầu penetration test (SVV-4). Tiêu chuẩn yêu cầu nhà cung cấp có quy trình cho các hoạt động này nhưng không quy định kỹ thuật cụ thể.

Todo

Đối chiếu phần practice 5 của IEC 62443-4-1 với văn bản tiêu chuẩn đã công bố.

Red teaming và công nhận năng lực

Hai nhóm sau thường được nhắc cùng các phương pháp kiểm thử nhưng có vai trò khác:

Khung Tổ chức Vai trò
TIBER-EU Ngân hàng Trung ương châu Âu (ECB) Khung red teaming dựa trên thông tin về mối đe dọa (threat intelligence) cho tổ chức tài chính. Bản cập nhật tháng 01/2025 căn chỉnh theo yêu cầu kiểm thử xâm nhập dựa trên mối đe dọa (Threat-Led Penetration Testing, TLPT) của Đạo luật về khả năng chống chịu số (DORA), bắt buộc giai đoạn purple teaming và đổi tên White Team thành Control Team
CBEST Ngân hàng Trung ương Anh Khung red teaming dựa trên thông tin về mối đe dọa cho ngành tài chính Anh
CHECK Trung tâm An ninh mạng Quốc gia Anh (NCSC) Chương trình phê duyệt công ty được pentest hệ thống của khu vực công và hạ tầng trọng yếu tại Anh
CREST Tổ chức thành viên phi lợi nhuận quốc tế Công nhận công ty và cấp chứng chỉ cho người kiểm thử; các kỳ thi của CREST là một trong các con đường đạt chuẩn của CHECK

Các khung red teaming tài chính ít liên quan tới việc kiểm thử một sản phẩm nhúng. CHECK và CREST hữu ích khi chọn đơn vị pentest bên ngoài, vì chúng cho biết năng lực của bên kiểm thử, không phải phương pháp kiểm thử.

Chọn phương pháp theo mục tiêu

Trong thực tế, một đợt kiểm thử thường ghép một khung tổ chức với các guide chi tiết cho từng lớp có trong phạm vi:

Mục tiêu Kết hợp thường dùng
Pentest một sản phẩm nhúng trước khi phát hành PTES hoặc NIST SP 800-115 làm khung; WSTG cho giao diện web; FSTM cho firmware; kiểm thử phần cứng nếu thiết bị nằm ngoài tầm kiểm soát vật lý của nhà sản xuất
Kiểm thử riêng trang quản trị web hoặc API WSTG, chọn test case từ checklist
Lấy bằng chứng cho CE RED hoặc ETSI EN 303 645 Test case của ETSI TS 103 701 và yêu cầu của EN 18031; kết quả WSTG dùng làm bằng chứng bổ sung cho phần web. Xem CE marking và RED
Bán thiết bị mạng cho nhà mạng 3GPP SCAS qua GSMA NESAS; O-RAN WG11 cho O-RU, O-DU
Thiết bị cho hệ thống điều khiển công nghiệp Quy trình kiểm thử theo IEC 62443-4-1; yêu cầu thành phần theo IEC 62443-4-2
Thuê đơn vị pentest bên ngoài Yêu cầu nêu rõ phương pháp (ví dụ PTES kết hợp WSTG và FSTM) và phiên bản; có thể dùng CREST hoặc CHECK làm tiêu chí năng lực

Quy trình chung của một đợt kiểm thử

Các khung tổ chức như PTES và NIST SP 800-115 có cùng bộ khung chung, gồm các bước:

  1. Thỏa thuận phạm vi và quy tắc kiểm thử (rules of engagement). Văn bản cho phép kiểm thử, danh sách mục tiêu và địa chỉ, thời gian, mức hiểu biết (black-box, gray-box, white-box), các thao tác bị cấm, cách xử lý dữ liệu thu được, đầu mối liên lạc khi có sự cố.
  2. Chuẩn bị môi trường. Với thiết bị nhúng, nên kiểm thử trên thiết bị trong lab thay vì thiết bị đang vận hành, và chuẩn bị sẵn cách khôi phục (cổng UART, JTAG, ảnh firmware gốc) vì một số test có thể làm thiết bị không khởi động được.
  3. Thu thập thông tin và threat model. Xác định bề mặt tấn công của từng lớp trong phạm vi.
  4. Phân tích lỗ hổng và khai thác. Kết hợp công cụ tự động và kiểm tra thủ công theo guide của từng lớp.
  5. Báo cáo. Tóm tắt cho quản lý, bảng phát hiện kèm mức rủi ro, chi tiết cách tái hiện và cách khắc phục. Mức rủi ro có thể chấm theo CVSS; xem CVE. Cấu trúc báo cáo cụ thể theo WSTG xem OWASP WSTG.
  6. Kiểm thử lại (retest). Sau khi nhà phát triển sửa, kiểm tra lại các phát hiện để xác nhận đã được khắc phục.

Báo cáo nên ghi rõ phương pháp, guide và phiên bản đã dùng, để người đọc biết những gì đã được kiểm tra và những gì nằm ngoài phạm vi.

Liên quan

Tài liệu tham khảo