Những rủi ro cần kiểm soát trong bảo mật IoT

Rủi ro phải được đánh giá trên toàn bộ chuỗi hoạt động:

Thiết bị thu nhận dữ liệu → dữ liệu được truyền qua mạng → nền tảng xử lý dữ liệu → người dùng hoặc hệ thống gửi lệnh điều khiển → thiết bị thực hiện hành động trong môi trường vật lý.

Chỉ cần một mắt xích bị xâm phạm, kẻ tấn công có thể đọc dữ liệu, thay đổi cấu hình, chiếm tài khoản, làm gián đoạn dịch vụ hoặc phát lệnh trái phép. Với những thiết bị tác động trực tiếp đến máy móc, môi trường, sức khỏe hoặc hạ tầng, sự cố an ninh mạng còn có thể chuyển thành hậu quả vật lý.

Khung năng lực cốt lõi NISTIR 8259A xác định sáu nhóm năng lực nền tảng cho thiết bị IoT: nhận dạng thiết bị, cấu hình thiết bị, bảo vệ dữ liệu, kiểm soát truy cập logic vào giao diện, cập nhật phần mềm và nhận biết trạng thái an ninh mạng. Đây là dấu hiệu cho thấy bảo mật IoT phải bao phủ đồng thời thiết bị, dữ liệu, quyền truy cập, phần mềm và khả năng vận hành an toàn.

Rủi ro thiết bị bị nhận dạng sai hoặc bị giả mạo

Mỗi thiết bị IoT cần có một danh tính đủ tin cậy để hệ thống biết chính xác thiết bị nào đang kết nối, gửi dữ liệu hoặc nhận lệnh. Nếu danh tính thiết bị không được quản lý tốt, một thiết bị giả có thể được hệ thống coi là thiết bị hợp lệ.

Rủi ro thường phát sinh khi:

·         Nhiều thiết bị sử dụng chung một thông tin xác thực

·         Khóa hoặc chứng thư được sao chép giữa các thiết bị

·         Mật khẩu mặc định không được thay đổi

·         Danh tính chỉ dựa trên địa chỉ mạng hoặc mã định danh dễ giả mạo

·         Thiết bị mất hoặc bị thay thế nhưng thông tin xác thực cũ vẫn còn hiệu lực

·         Hệ thống không có danh mục tài sản IoT đầy đủ

Kẻ tấn công có thể dùng danh tính giả để gửi dữ liệu sai, truy cập dịch vụ nội bộ hoặc nhận quyền điều khiển vốn dành cho thiết bị hợp lệ. Ngược lại, nếu hệ thống không xác thực máy chủ, thiết bị cũng có thể kết nối nhầm tới máy chủ giả và làm lộ dữ liệu hoặc thông tin xác thực.

Vì vậy, bảo mật IoT phải hỗ trợ xác thực hai chiều khi cần thiết: nền tảng xác minh thiết bị, đồng thời thiết bị xác minh nền tảng. Mỗi thiết bị nên có danh tính riêng, có thể thu hồi và thay thế mà không ảnh hưởng đến toàn bộ hệ thống.

Việc có danh tính riêng không đồng nghĩa thiết bị đã an toàn. Nếu khóa xác thực được lưu ở vị trí dễ trích xuất hoặc quy trình cấp phát khóa không đáng tin cậy, danh tính hợp lệ vẫn có thể bị sao chép.

Rủi ro xác thực yếu và phân quyền không đúng

Sau khi xác định danh tính, hệ thống còn phải quyết định chủ thể đó được phép làm gì. Đây là hai vấn đề khác nhau:

·         Xác thực trả lời câu hỏi “Ai đang truy cập?”

·         Phân quyền trả lời câu hỏi “Chủ thể này được phép thực hiện hành động nào?”

Một thiết bị hoặc tài khoản đã đăng nhập thành công không nên mặc nhiên có toàn quyền. Nếu quyền được cấp quá rộng, một tài khoản người dùng thông thường có thể thay đổi cấu hình quản trị, một cảm biến có thể gửi lệnh điều khiển hoặc một thiết bị bị xâm phạm có thể truy cập toàn bộ hệ thống.

Các điểm yếu phổ biến gồm mật khẩu yếu, mật khẩu dùng chung, tài khoản mặc định, token tồn tại quá lâu và API chỉ kiểm tra đăng nhập mà không kiểm tra quyền đối với từng đối tượng. OWASP xếp mật khẩu yếu, dễ đoán hoặc được mã hóa cứng vào nhóm rủi ro nổi bật của hệ sinh thái IoT.

Bảo mật IoT cần áp dụng nguyên tắc đặc quyền tối thiểu:

·         Mỗi người dùng, dịch vụ và thiết bị chỉ nhận quyền cần thiết

·         Quyền đọc dữ liệu được tách khỏi quyền thay đổi cấu hình

·         Quyền vận hành được tách khỏi quyền quản trị

·         Lệnh nhạy cảm cần xác minh lại danh tính hoặc áp dụng nhiều lớp phê duyệt

·         Thông tin xác thực phải có khả năng xoay vòng và thu hồi

·         Phiên đăng nhập và token phải có thời hạn phù hợp

Xác thực đa yếu tố hữu ích đối với tài khoản quản trị nhưng không thay thế việc phân quyền. Một quản trị viên được xác thực mạnh nhưng có quyền quá rộng vẫn tạo ra điểm rủi ro tập trung.

Rủi ro từ phần mềm nhúng và cơ chế cập nhật

Firmware và phần mềm nhúng quyết định thiết bị xử lý dữ liệu, giao tiếp và thực hiện lệnh như thế nào. Lỗ hổng trong thành phần này có thể tồn tại trên hàng nghìn hoặc hàng triệu thiết bị cùng loại.

Các rủi ro quan trọng gồm:

·         Sử dụng thư viện có lỗ hổng đã biết

·         Dịch vụ gỡ lỗi vẫn hoạt động trên sản phẩm thương mại

·         Thông tin bí mật được ghi trực tiếp trong mã nguồn hoặc firmware

·         Firmware có thể bị trích xuất và phân tích dễ dàng

·         Thiết bị chấp nhận bản cập nhật không có chữ ký hợp lệ

·         Kênh tải bản cập nhật không bảo đảm tính toàn vẹn

·         Không có cơ chế quay lại phiên bản ổn định khi cập nhật lỗi

·         Nhà sản xuất ngừng hỗ trợ trong khi thiết bị vẫn được sử dụng

Cơ chế cập nhật không an toàn có thể biến tính năng bảo trì thành đường phân phối mã độc. Thiết bị phải xác minh nguồn phát hành, chữ ký và tính toàn vẹn của gói cập nhật trước khi cài đặt. Hệ thống cũng cần chống hạ cấp để kẻ tấn công không ép thiết bị quay về phiên bản cũ có lỗ hổng.

Tuy nhiên, khả năng cập nhật mới chỉ giải quyết một phần vấn đề. Nhà sản xuất còn phải duy trì quy trình tiếp nhận báo cáo lỗ hổng, đánh giá ảnh hưởng, phát hành bản vá và thông báo thời hạn hỗ trợ. NIST nhấn mạnh rằng an ninh IoT phụ thuộc cả vào năng lực kỹ thuật của thiết bị lẫn hoạt động hỗ trợ của nhà sản xuất và các bên liên quan.

Trong các hệ thống không thể dừng tùy ý, cập nhật phải được thử nghiệm trước, triển khai theo từng nhóm và có phương án khôi phục. Một bản vá bảo mật gây mất chức năng vận hành cũng là một dạng rủi ro.

Rủi ro từ giao diện và dịch vụ không cần thiết

Thiết bị IoT có thể cung cấp nhiều giao diện: cổng mạng, Bluetooth, Wi-Fi, giao diện web, cổng USB, giao diện bảo trì, API cục bộ hoặc giao thức quản lý từ xa. Mỗi giao diện đều làm tăng bề mặt tấn công.

Rủi ro xuất hiện khi:

·         Dịch vụ không cần thiết vẫn được bật

·         Cổng quản trị có thể truy cập từ Internet

·         Giao diện bảo trì không yêu cầu xác thực

·         API không kiểm tra dữ liệu đầu vào

·         Giao thức cũ hoặc không an toàn vẫn được sử dụng

·         Thông báo lỗi làm lộ cấu trúc hệ thống

·         Thiết bị cho phép thử mật khẩu không giới hạn

·         Cấu hình mặc định ưu tiên tiện lợi hơn an toàn

Kẻ tấn công thường không cần phá vỡ thuật toán mã hóa nếu có thể truy cập một dịch vụ quản trị bị bỏ quên. Do đó, kiểm soát hiệu quả nhất không phải luôn là bổ sung thêm lớp phòng vệ mà là loại bỏ những thành phần không cần thiết.

Hệ thống cần duy trì danh sách giao diện, dịch vụ và cổng được phép hoạt động. Mọi thành phần ngoài danh sách phải bị vô hiệu hóa. Giao diện quản trị nên được tách khỏi mạng công cộng, giới hạn nguồn truy cập và ghi lại đầy đủ hành động quản trị.

Việc đóng cổng mạng không loại bỏ hoàn toàn rủi ro nếu cùng chức năng vẫn có thể truy cập qua ứng dụng di động, API đám mây hoặc giao diện không dây gần thiết bị. Đánh giá bề mặt tấn công phải bao phủ toàn bộ sản phẩm thay vì chỉ quét địa chỉ IP của thiết bị.

Rủi ro nghe lén, sửa đổi và chuyển hướng kết nối

Dữ liệu IoT thường đi qua nhiều đoạn kết nối: từ cảm biến đến gateway, từ gateway đến đám mây, từ đám mây đến ứng dụng và từ ứng dụng trở lại thiết bị. Một đoạn được bảo vệ không có nghĩa toàn bộ đường truyền đã an toàn.

Ba rủi ro chính trên kết nối là:

·         Nghe lén để thu thập dữ liệu hoặc thông tin xác thực

·         Sửa đổi nội dung thông điệp trong quá trình truyền

·         Chuyển hướng thiết bị tới máy chủ hoặc dịch vụ giả mạo

Mã hóa đường truyền giúp bảo vệ tính bí mật nhưng phải đi kèm xác thực điểm cuối và kiểm tra tính toàn vẹn. Nếu thiết bị mã hóa dữ liệu tới một máy chủ giả, nội dung vẫn bị lộ. Nếu khóa hoặc chứng thư không được kiểm tra đúng, giao thức an toàn có thể bị triển khai theo cách không an toàn.

Ngoài kết nối Internet, cần kiểm soát cả mạng cục bộ và giao thức tầm gần. Kẻ tấn công có thể hoạt động trong cùng mạng Wi-Fi, ở gần thiết bị hoặc thông qua một gateway đã bị xâm phạm.

Phân đoạn mạng giúp giới hạn hậu quả. Thiết bị IoT không nên mặc nhiên nằm cùng vùng tin cậy với máy chủ quan trọng hoặc máy tính người dùng. Quy tắc mạng nên giới hạn rõ thiết bị được kết nối tới đâu, qua giao thức nào và theo chiều nào.

Mã hóa không ngăn được tấn công làm nghẽn kết nối, cũng không bảo vệ dữ liệu sau khi đã được giải mã tại điểm cuối. Vì vậy, bảo mật kết nối phải kết hợp với khả năng phục hồi dịch vụ và bảo vệ dữ liệu lưu trữ.

Rủi ro lộ lọt, sử dụng sai và lưu trữ quá mức dữ liệu

Thiết bị IoT có thể thu thập dữ liệu vị trí, hình ảnh, âm thanh, thông số môi trường, thói quen sử dụng hoặc trạng thái vận hành. Nhiều dữ liệu tưởng như không nhạy cảm khi đứng riêng lẻ có thể tiết lộ thông tin quan trọng khi được tổng hợp theo thời gian.

Rủi ro dữ liệu không chỉ là bị đánh cắp. Nó còn bao gồm:

·         Thu thập nhiều hơn mức cần thiết

·         Sử dụng dữ liệu ngoài mục đích đã công bố

·         Lưu giữ dữ liệu quá lâu

·         Chia sẻ với bên thứ ba không được kiểm soát

·         Không tách dữ liệu giữa các khách hàng

·         Sao lưu nhưng không bảo vệ bản sao

·         Không xóa dữ liệu khi thiết bị được bán, chuyển giao hoặc ngừng sử dụng

·         Nhật ký vô tình chứa khóa, token hoặc dữ liệu cá nhân

Bảo mật IoT phải bảo vệ ba thuộc tính của dữ liệu:

·         Tính bí mật: người không có quyền không đọc được dữ liệu

·         Tính toàn vẹn: dữ liệu không bị thay đổi trái phép

·         Tính sẵn sàng: dữ liệu cần thiết vẫn truy cập được khi hệ thống vận hành

Tính toàn vẹn đặc biệt quan trọng đối với dữ liệu dùng để ra quyết định. Nếu dữ liệu cảm biến bị sửa đổi, nền tảng có thể đưa ra lệnh sai dù không thành phần nào bị mất quyền truy cập.

Biện pháp kiểm soát nên bắt đầu bằng giảm thiểu dữ liệu: chỉ thu thập trường dữ liệu cần thiết, với độ chính xác và thời gian lưu phù hợp. Sau đó mới áp dụng mã hóa, phân quyền, quản lý khóa, kiểm toán truy cập và quy trình xóa dữ liệu.

ETSI EN 303 645 đặt ra các yêu cầu nền tảng cho IoT tiêu dùng, trong đó có bảo vệ dữ liệu cá nhân, giao tiếp an toàn, lưu trữ thông tin bảo mật, giảm thiểu bề mặt tấn công và hỗ trợ xóa dữ liệu người dùng.

Rủi ro chiếm quyền điều khiển và phát lệnh trái phép

Khả năng điều khiển tạo ra khác biệt quan trọng giữa nhiều hệ thống IoT và hệ thống thông tin thông thường. Một lệnh điện tử có thể làm thiết bị thay đổi trạng thái vật lý, mở hoặc khóa cơ cấu, điều chỉnh máy móc hay dừng một quy trình.

Quyền điều khiển có thể bị chiếm đoạt khi:

·         API kiểm tra đăng nhập nhưng không kiểm tra quyền ra lệnh

·         Lệnh không được ký hoặc xác minh tính toàn vẹn

·         Hệ thống chấp nhận lệnh cũ được gửi lại

·         Phiên điều khiển không có thời hạn

·         Thiết bị không kiểm tra phạm vi giá trị của lệnh

·         Tài khoản quản trị bị chiếm

·         Nền tảng đám mây hoặc ứng dụng điều khiển bị xâm phạm

·         Quyền điều khiển vẫn còn sau khi người dùng hoặc thiết bị đã bị thu hồi

Để kiểm soát rủi ro, hệ thống phải xác minh không chỉ người gửi mà còn tính hợp lệ của từng lệnh. Một lệnh hợp lệ thường cần đáp ứng đồng thời các điều kiện:

·         Đến từ chủ thể được phép

·         Hướng đến đúng thiết bị

·         Nằm trong phạm vi quyền được cấp

·         Chưa hết thời hạn

·         Không phải thông điệp được phát lại

·         Có giá trị nằm trong giới hạn vận hành

·         Phù hợp với trạng thái hiện tại của thiết bị

Đối với hành động quan trọng, thiết bị không nên thực hiện lệnh chỉ vì lệnh đã được xác thực về mặt kỹ thuật. Cần bổ sung quy tắc an toàn tại thiết bị, chẳng hạn từ chối giá trị vượt ngưỡng, yêu cầu xác nhận bổ sung hoặc chuyển về trạng thái an toàn khi thông tin không nhất quán.

Cơ chế an toàn vật lý không thay thế an ninh mạng. Ngược lại, xác thực mạnh cũng không thay thế giới hạn vận hành tại thiết bị. Hai lớp này phải hoạt động độc lập để tránh một lỗi đơn lẻ tạo ra hậu quả nghiêm trọng.

Rủi ro từ nền tảng đám mây, API và ứng dụng quản lý

Thiết bị có thể được thiết kế tốt nhưng toàn bộ sản phẩm vẫn không an toàn nếu ứng dụng di động, API hoặc nền tảng đám mây có điểm yếu. Trong nhiều hệ thống, thiết bị chỉ là một thành phần của hệ sinh thái lớn hơn.

Các rủi ro thường gặp gồm:

·         API làm lộ dữ liệu của người dùng khác

·         Kiểm soát quyền chỉ được thực hiện trên giao diện ứng dụng

·         Khóa API được nhúng trong ứng dụng di động

·         Kho lưu trữ đám mây được cấu hình công khai

·         Dịch vụ bên thứ ba nhận quá nhiều quyền

·         Môi trường phát triển và sản xuất không được tách biệt

·         Tài khoản hỗ trợ có thể truy cập dữ liệu khách hàng quá rộng

·         Một tài khoản trung tâm điều khiển quá nhiều thiết bị

Kẻ tấn công thường chọn mắt xích dễ nhất. Thay vì tấn công trực tiếp phần cứng, họ có thể khai thác API để truy cập cùng dữ liệu hoặc chức năng điều khiển.

Vì vậy, phạm vi kiểm thử phải bao gồm thiết bị, firmware, giao thức, ứng dụng, API, nền tảng và quy trình vận hành. OWASP IoT Security Testing Guide cũng tổ chức hoạt động kiểm thử theo mô hình hệ sinh thái thay vì xem thiết bị là thành phần cô lập.

Hệ thống còn cần giới hạn phạm vi ảnh hưởng của tài khoản và dịch vụ trung tâm. Một thông tin xác thực bị lộ không nên cho phép truy cập toàn bộ khách hàng hoặc mọi thiết bị trong hệ thống.

Rủi ro chuỗi cung ứng và thành phần bên thứ ba

Sản phẩm IoT thường sử dụng vi điều khiển, hệ điều hành nhúng, thư viện mã nguồn mở, bộ công cụ phát triển, dịch vụ đám mây và module kết nối từ nhiều nhà cung cấp. Một lỗ hổng trong thành phần dùng chung có thể ảnh hưởng đến nhiều dòng sản phẩm.

Chuỗi cung ứng tạo ra các rủi ro như:

·         Thành phần có lỗ hổng nhưng không được theo dõi

·         Không biết firmware chứa những thư viện nào

·         Gói phần mềm hoặc công cụ xây dựng bị sửa đổi

·         Nhà cung cấp ngừng hỗ trợ thành phần

·         Bản cập nhật của bên thứ ba không được đánh giá

·         Thiết bị giả hoặc linh kiện bị thay thế trong quá trình phân phối

·         Khóa bí mật bị lộ tại khâu sản xuất

·         Quyền truy cập của nhà thầu không được thu hồi

Quản lý chuỗi cung ứng đòi hỏi khả năng truy vết: sản phẩm dùng thành phần nào, phiên bản nào, đến từ nguồn nào và đang tồn tại trên những thiết bị nào. Khi một lỗ hổng được công bố, tổ chức phải xác định nhanh phạm vi ảnh hưởng thay vì kiểm tra thủ công từng sản phẩm.

Danh mục thành phần phần mềm hỗ trợ truy vết nhưng không tự động chứng minh sản phẩm an toàn. Tổ chức vẫn phải đánh giá khả năng khai thác, mức độ ảnh hưởng, điều kiện vận hành và phương án khắc phục.

Rủi ro gián đoạn dịch vụ và thiết bị bị biến thành công cụ tấn công

Thiết bị IoT thường có tài nguyên xử lý, bộ nhớ và năng lượng hạn chế. Kẻ tấn công có thể làm cạn kiệt các tài nguyên này bằng lượng lớn kết nối, yêu cầu bất thường hoặc thông điệp được tạo có chủ đích.

Hậu quả có thể gồm:

·         Thiết bị mất kết nối

·         Pin cạn nhanh

·         Bộ nhớ bị chiếm hết

·         Dữ liệu bị trì hoãn hoặc mất

·         Gateway quá tải

·         Nền tảng không thể tiếp nhận lệnh hợp lệ

·         Thiết bị liên tục khởi động lại

·         Chức năng vật lý không còn hoạt động đúng

Thiết bị bị xâm phạm còn có thể được tập hợp thành mạng botnet để quét mạng, gửi lưu lượng tấn công hoặc phát tán mã độc. Khi đó, rủi ro không chỉ ảnh hưởng chủ sở hữu thiết bị mà còn ảnh hưởng các hệ thống khác trên Internet.

Bảo vệ tính sẵn sàng cần kết hợp giới hạn tốc độ, giới hạn tài nguyên, phân đoạn mạng, phát hiện hành vi bất thường và cơ chế phục hồi. Thiết bị phải có trạng thái an toàn khi mất kết nối hoặc không thể xác minh lệnh.

Không có hệ thống nào bảo đảm dịch vụ luôn sẵn sàng trong mọi tình huống. Mục tiêu thực tế là duy trì chức năng quan trọng, giới hạn phạm vi gián đoạn và khôi phục trong khoảng thời gian phù hợp với mức độ quan trọng của thiết bị.

Rủi ro truy cập vật lý và can thiệp trực tiếp vào thiết bị

Không giống nhiều dịch vụ đám mây, thiết bị IoT có thể được đặt ở nhà ở, nhà máy, phương tiện, khu vực công cộng hoặc vị trí không được giám sát. Kẻ tấn công có thể tiếp cận trực tiếp thiết bị thay vì chỉ tấn công qua mạng.

Truy cập vật lý có thể được dùng để:

·         Tháo thiết bị và đọc bộ nhớ

·         Trích xuất firmware hoặc khóa bí mật

·         Sử dụng cổng gỡ lỗi

·         Thay thế cảm biến

·         Can thiệp đường truyền giữa các linh kiện

·         Khôi phục thiết bị về trạng thái mặc định không an toàn

·         Gắn thêm phần cứng để duy trì quyền truy cập

·         Thay đổi dữ liệu đầu vào từ môi trường

Biện pháp kiểm soát phụ thuộc vào mô hình đe dọa. Thiết bị trong khu vực được bảo vệ có yêu cầu khác thiết bị triển khai ở nơi công cộng. Các biện pháp có thể bao gồm vô hiệu hóa giao diện gỡ lỗi, bảo vệ khóa bằng phần cứng, khởi động an toàn, phát hiện tháo mở và xác minh tính toàn vẹn của phần mềm.

Chống can thiệp vật lý tuyệt đối thường không khả thi. Mục tiêu là tăng chi phí tấn công, bảo vệ bí mật quan trọng và phát hiện khi thiết bị không còn đáng tin cậy. Nếu một thiết bị bị xâm phạm vật lý, hệ thống phải có khả năng thu hồi danh tính của riêng thiết bị đó thay vì thay đổi toàn bộ hệ thống.

Rủi ro cấu hình sai và trạng thái mặc định không an toàn

Nhiều sự cố không bắt nguồn từ lỗ hổng kỹ thuật mới mà từ cấu hình không phù hợp. Sản phẩm có thể hỗ trợ các tính năng bảo mật nhưng chúng bị tắt, khó sử dụng hoặc không được cấu hình trong quá trình triển khai.

Cấu hình sai thường gồm:

·         Giữ nguyên mật khẩu mặc định

·         Mở quyền truy cập từ Internet

·         Dùng chung tài khoản quản trị

·         Không bật mã hóa dù thiết bị hỗ trợ

·         Cho phép giao tiếp giữa các thiết bị không cần thiết

·         Không đồng bộ thời gian, làm giảm giá trị của nhật ký

·         Không thu hồi thiết bị đã loại bỏ

·         Dùng môi trường thử nghiệm cho dữ liệu thật

·         Cấp quyền quá rộng cho ứng dụng tích hợp

Thiết kế an toàn theo mặc định giúp giảm sự phụ thuộc vào người dùng. Khi khởi tạo, thiết bị nên buộc thiết lập danh tính riêng, chỉ bật chức năng cần thiết và không công khai dịch vụ quản trị.

Tuy nhiên, cấu hình mặc định an toàn không bảo đảm cấu hình sẽ luôn an toàn. Thay đổi trong mạng, tài khoản, tích hợp hoặc mục đích sử dụng có thể tạo ra rủi ro mới. Do đó, cấu hình phải được kiểm tra định kỳ và so sánh với trạng thái chuẩn đã được phê duyệt.

Rủi ro thiếu giám sát, nhật ký và khả năng ứng phó

Nếu hệ thống không quan sát được trạng thái thiết bị, tổ chức có thể không biết thiết bị đã bị xâm phạm, đang gửi dữ liệu bất thường hoặc đã ngừng nhận bản cập nhật.

Khả năng giám sát cần trả lời được các câu hỏi:

·         Thiết bị nào đang hoạt động

·         Thiết bị đang chạy phiên bản phần mềm nào

·         Ai đã thay đổi cấu hình

·         Lệnh điều khiển nào đã được gửi

·         Thiết bị đang kết nối tới dịch vụ nào

·         Có hành vi nào khác với trạng thái bình thường

·         Thiết bị có còn nhận được hỗ trợ bảo mật hay không

Nhật ký phải đủ để điều tra nhưng không nên chứa thông tin bí mật không cần thiết. Nhật ký lưu cục bộ có thể bị mất khi thiết bị bị phá hủy hoặc khôi phục, trong khi nhật ký gửi tập trung có thể làm tăng lưu lượng và rủi ro riêng tư. Thiết kế cần cân bằng giữa khả năng điều tra, tài nguyên thiết bị và mức độ nhạy cảm của dữ liệu.

Nhận biết trạng thái an ninh mạng là một trong các năng lực cốt lõi của NISTIR 8259A. Thiết bị hoặc hệ thống hỗ trợ cần cung cấp thông tin đủ để phát hiện, đánh giá và xử lý trạng thái bất thường.

Kế hoạch ứng phó cũng phải tính đến đặc điểm IoT. Cô lập một máy tính bị nhiễm thường ít ảnh hưởng hơn ngắt kết nối một thiết bị đang duy trì chức năng vận hành. Trước khi cô lập, cần xác định thiết bị có thể chuyển sang trạng thái an toàn hay không.

Rủi ro trong toàn bộ vòng đời thiết bị

Rủi ro IoT không kết thúc sau khi thiết bị được bán hoặc lắp đặt. Nó thay đổi trong toàn bộ vòng đời:

·         Thiết kế và phát triển

·         Sản xuất và cấp phát danh tính

·         Phân phối và lắp đặt

·         Cấu hình và vận hành

·         Bảo trì và cập nhật

·         Chuyển giao quyền sở hữu

·         Ngừng hỗ trợ

·         Thu hồi hoặc tiêu hủy

Một thiết bị có thể an toàn khi mới triển khai nhưng trở nên rủi ro khi mật khẩu không được xoay vòng, chứng thư hết hạn, thư viện xuất hiện lỗ hổng hoặc nhà sản xuất ngừng cung cấp bản vá.

Khi chuyển giao thiết bị, dữ liệu và thông tin xác thực của chủ sở hữu cũ phải được xóa. Khi ngừng sử dụng, danh tính thiết bị phải bị thu hồi để thiết bị không thể tiếp tục truy cập nền tảng. Khi hết thời hạn hỗ trợ, tổ chức cần thay thế, cô lập hoặc áp dụng biện pháp bù trừ.

CISA lưu ý rằng đặc tính kết nối bằng phần mềm và khả năng tác động đến thế giới vật lý làm gia tăng rủi ro của công nghệ IoT. Điều đó đòi hỏi tổ chức xem xét an ninh ngay từ trước khi mua, trong quá trình sử dụng và khi loại bỏ thiết bị.

Cách xác định mức ưu tiên kiểm soát rủi ro IoT

Không phải mọi rủi ro đều có mức độ nghiêm trọng như nhau. Việc ưu tiên nên dựa trên sự kết hợp giữa khả năng xảy ra và mức độ hậu quả.

Các yếu tố cần đánh giá gồm:

·         Thiết bị có thể bị truy cập từ Internet hay không

·         Thiết bị có thu thập dữ liệu nhạy cảm hay không

·         Thiết bị có quyền phát lệnh hoặc tác động vật lý hay không

·         Một tài khoản có thể điều khiển bao nhiêu thiết bị

·         Thiết bị có thể hoạt động an toàn khi mất kết nối hay không

·         Có thể cập nhật và thu hồi thiết bị từ xa hay không

·         Sự cố có lan sang hệ thống khác hay không

·         Nhà sản xuất còn hỗ trợ bảo mật trong bao lâu

·         Tổ chức có thể phát hiện và phục hồi sau sự cố hay không

Một rủi ro có xác suất thấp vẫn cần ưu tiên cao nếu hậu quả có thể ảnh hưởng đến an toàn hoặc làm mất quyền điều khiển trên quy mô lớn. Ngược lại, một điểm yếu thường xuyên xuất hiện nhưng chỉ làm lộ dữ liệu không nhạy cảm trong phạm vi nhỏ có thể được xử lý sau những rủi ro có hậu quả nghiêm trọng hơn.

Các biện pháp kiểm soát nên được tổ chức theo nhiều lớp:

1.    Giảm bề mặt tấn công ngay từ thiết kế

2.    Xác thực và phân quyền cho người dùng, thiết bị, dịch vụ

3.    Bảo vệ kết nối, dữ liệu và khóa mật mã

4.    Xác minh phần mềm và cập nhật an toàn

5.    Giới hạn hành động điều khiển tại thiết bị

6.    Phân đoạn mạng và hạn chế phạm vi lan truyền

7.    Theo dõi trạng thái, phát hiện bất thường và ứng phó

8.    Quản lý hỗ trợ, chuyển giao và loại bỏ thiết bị

Không có một biện pháp đơn lẻ nào bảo vệ được toàn bộ hệ thống. Mật khẩu mạnh không sửa được firmware lỗi; mã hóa không ngăn được tài khoản có quyền gửi lệnh sai; cập nhật an toàn không ngăn được cấu hình sai; giám sát không thay thế việc giới hạn quyền.

Bảo mật IoT phải kiểm soát bốn tài sản trung tâm: thiết bị, kết nối, dữ liệu và quyền điều khiển. Tuy nhiên, bốn tài sản này luôn phụ thuộc vào firmware, ứng dụng, API, nền tảng đám mây, chuỗi cung ứng và quy trình vận hành.

Một hệ thống IoT được bảo vệ tốt phải nhận dạng đúng từng thiết bị, xác thực và phân quyền chặt chẽ, giảm bề mặt tấn công, bảo vệ dữ liệu trong khi truyền và lưu trữ, xác minh mọi bản cập nhật, giới hạn lệnh điều khiển, duy trì khả năng phục hồi và theo dõi trạng thái trong toàn bộ vòng đời.

Mục tiêu không phải loại bỏ tuyệt đối mọi nguy cơ. Mục tiêu là ngăn một điểm yếu đơn lẻ dẫn đến mất toàn bộ quyền kiểm soát, giới hạn hậu quả khi sự cố xảy ra và bảo đảm thiết bị có thể được phát hiện, cô lập, khôi phục hoặc loại bỏ một cách an toàn.