File ingress trông như thế nào theo CCoP 2.0

Mọi bộ kiểm soát trong khu vực đều yêu cầu phòng thủ theo chiều sâu, và Cybersecurity Code of Practice for critical information infrastructure của Singapore cũng không ngoại lệ. Đây là một trong những cụm từ vẫn tồn tại qua các cuộc họp rà soát vì không ai có thể phản đối nó.

Nó cũng, nếu đọc theo nghĩa đen, là một tuyên bố về các loại kiểm soát trong một chuỗi hơn là số lượng của chúng. Sự khác biệt đó hầu như không có tác dụng trong phần lớn an ninh, nơi các lớp thực sự khác nhau, một firewall, một kiểm soát danh tính và một tác nhân endpoint không phải là những biến thể của cùng một ý tưởng. Nhưng nó lại có tác dụng rất lớn đối với file ingress, nơi mà các tổ chức thường xuyên chồng ba hoặc bốn kiểm soát đều trả lời cùng một câu hỏi bằng cùng một phương pháp.

Ai thuộc phạm vi áp dụng, và điều gì đã thay đổi

Cybersecurity Act 2018 trao cho Cyber Security Agency of Singapore quyền chỉ định hạ tầng thông tin trọng yếu trên mười một lĩnh vực: năng lượng, info-communications, nước, y tế, ngân hàng và tài chính, an ninh và dịch vụ khẩn cấp, hàng không, vận tải đường bộ, hàng hải, chính phủ và truyền thông. Việc chỉ định là điều biến Code of Practice từ hướng dẫn thành nghĩa vụ theo luật định.

Cybersecurity (Amendment) Act 2024 đã mở rộng đáng kể phạm vi. Từ ngày 31 tháng 10 năm 2025, một Part 3A mới áp dụng cho các nhà cung cấp dịch vụ thiết yếu không sở hữu hạ tầng mà họ phụ thuộc vào, cùng với các nhà cung cấp dịch vụ đám mây và nhà vận hành trung tâm dữ liệu. Nếu tổ chức của bạn vài năm trước đã kết luận rằng chế độ này thuộc về người khác vì bạn thuê chứ không sở hữu, thì kết luận đó đáng để kiểm tra lại.

CSA thông báo vào ngày 22 tháng 7 năm 2026 rằng Code sẽ được cập nhật một lần nữa, để xử lý các mối đe dọa dai dẳng nâng cao và các cuộc tấn công được hỗ trợ bởi AI, cùng với một Code riêng cho Cloud Services theo cùng lộ trình thời gian. Thông báo cũng đề cập đến chứng nhận Cyber Trust Mark Level 5 liên quan đến Code đã cập nhật, và đó là tín hiệu đáng theo dõi: một dấu chứng nhận tự nguyện được nêu cùng với một văn bản ràng buộc thường sẽ trở thành bộ lọc mua sắm đối với mọi bên bán vào lĩnh vực này, dù đã được chỉ định hay chưa.

File thực sự đi vào từ đâu

"File ingress" nghe như chỉ là một thứ. Trong môi trường CII, nó thường là bảy, và chúng hiếm khi do cùng một nhóm sở hữu.

1. Email attachments, thứ mà ai cũng đã nghĩ đến, và cũng là đường dẫn duy nhất mà hầu hết sơ đồ kiểm soát thể hiện.
2. Supplier and customer portals: biểu mẫu tải lên, nộp yêu cầu bồi thường, phản hồi đấu thầu, tài liệu onboarding. Thường do một nhóm ứng dụng xây dựng, được bảo vệ bằng bất cứ thứ gì framework ứng dụng cung cấp vào thời điểm đó.
3. Managed file transfer and scheduled exchanges với các đối tác, nơi kiểm soát được thiết kế xoay quanh tính sẵn sàng và đối soát hơn là nội dung.
4. OT vendor material: firmware images, configuration files, PLC project files, commissioning documents. Đường dẫn này mang hậu quả lớn nhất và mức kiểm tra ít nhất, vì các định dạng là độc quyền và cửa sổ bảo trì rất ngắn.
5. Removable media at the IT and OT boundary, mà chính sách chính thức thường cấm nhưng thực tế thường vẫn chấp nhận, vì một kỹ sư của nhà cung cấp đã đến cùng một laptop và một thời hạn.
6. Cloud storage and collaboration surfaces được chia sẻ với bên thứ ba, nơi file đi vào mà không đi qua bất kỳ thứ gì mà một người vận hành sẽ nhận ra là ranh giới.
7. Backup and restore paths, nơi đưa trở lại các file đã được chấp nhận ở một thời điểm trước đó, dưới bất kỳ kiểm soát nào đang tồn tại khi đó.

Hãy ghi ra bảy đường dẫn đó theo chính môi trường của bạn trước khi tranh luận về các engine. Bài tập này thường giúp làm rõ rủi ro hơn bất kỳ so sánh sản phẩm nào, vì phát hiện phổ biến không phải là một kiểm soát yếu. Mà là ba trong số bảy đường dẫn chưa bao giờ nằm trong phạm vi của bất kỳ kiểm soát nào.

Vì sao chồng các kiểm soát tương tự không phải là chiều sâu

Hãy lấy một đường dẫn được bảo vệ, và xem thứ gì đang bảo vệ nó.

Một chuỗi inbound điển hình chạy một gateway engine, rồi một engine thứ hai với chữ ký của nhà cung cấp khác, rồi có thể là một sandbox. Ba sản phẩm, ba hóa đơn, ba dashboard. Hãy hỏi mỗi thứ đang trả lời câu hỏi gì, và câu trả lời là giống hệt nhau: file này có độc hại không? Hãy hỏi mỗi thứ quyết định như thế nào, và các phương pháp cũng tương tự nhau: so khớp mẫu với những thứ đã biết là xấu, heuristic trên cấu trúc, và hành vi được quan sát trong một môi trường mà file có thể hoặc không thể chọn để bộc lộ chính nó.

Khi hai kiểm soát dùng chung một phương pháp, chúng cũng dùng chung điểm mù của phương pháp đó. Phát hiện dựa trên chữ ký bị chậm hơn các mẫu mới bao lâu thì còn tùy vào thời gian cần để mẫu được thu thập, phân tích và phân phối, và việc thêm một bộ chữ ký thứ hai chỉ thu hẹp cửa sổ đó mà không đóng nó lại. Một sandbox chỉ tốt bằng mức độ nó được thiết kế: một file kiểm tra xem có phải sandbox hay không, hoặc chờ đợi, hoặc cần một cú nhấp chuột mà sandbox sẽ không thực hiện, thì sẽ hoạt động hoàn hảo. Chạy nó hai lần chỉ tạo ra cùng một hành vi tốt hai lần.

Ba kiểm soát lấy mẫu cùng một câu hỏi là một bài kiểm tra tính nhất quán. Nó cho bạn biết các engine của bạn đồng ý với nhau. Nó không cho bạn biết file an toàn, và dưới một Code yêu cầu chiều sâu thì đó chỉ là một lớp, nhưng được báo cáo thành ba.

Độ sâu, theo đúng nghĩa mà cụm từ này tự nhận, đòi hỏi ít nhất một kiểm soát trong chuỗi đưa ra phán quyết bằng một con đường hoàn toàn khác. Đó là một hạng mục, không phải một sản phẩm, và có vài cách: allowlisting theo loại tệp và nguồn để các định dạng bất ngờ không bao giờ chạm tới parser; một sự ngắt giao thức buộc nội dung phải được tạo lại thay vì được chuyển tiếp; tái tạo xác định một tài liệu theo đặc tả định dạng của nó, tạo ra cùng một kết quả trên một tệp chưa ai từng thấy như trên một tệp mà ai cũng đã thấy; cô lập bước rendering để việc parsing diễn ra ở nơi không quan trọng.

Mỗi cách đều có chi phí thực, và đáng để nêu rõ thay vì giả vờ ngược lại. Allowlisting tạo ra các ngoại lệ, và các ngoại lệ tích tụ cho đến khi danh sách chỉ còn mang tính trang trí. Ngắt giao thức làm tăng độ trễ mà các cửa sổ bảo trì OT có thể không chịu được. Tái tạo làm thay đổi tệp, điều này quan trọng ở nơi một đối tác giao dịch kỳ vọng một tài liệu giống hệt từng byte hoặc một chữ ký vẫn còn nguyên. Cô lập chỉ chuyển rủi ro đi chỗ khác chứ không loại bỏ nó. Một bộ kiểm soát được chọn dựa trên cách nhìn trung thực về những chi phí đó sẽ khác nhau giữa bệnh viện và cảng biển.

Cách đọc vẫn đứng vững sau đánh giá

CCoP yêu cầu giám sát liên tục, phát hiện bất thường hành vi trên cả IT và OT, cùng với thời gian lưu giữ đủ để hỗ trợ điều tra và xác minh kiểm toán theo yêu cầu. Những nghĩa vụ đó là về việc nhìn thấy và chứng minh. Lập luận về độ sâu ở trên là về việc quyết định, và hai điều này gặp nhau ở một điểm thực tế: một người đánh giá hỏi một đường đi cụ thể được bảo vệ như thế nào sẽ chấp nhận một chuỗi các engine tương tự, nhưng mô tả về chuỗi đó tự viết thành một câu, và câu đó là mọi thứ trên đường đi này đều được quyết định theo cùng một cách.

Đối với các tổ chức tài chính, MAS Technology Risk Management Guidelines đặt ra kỳ vọng tương tự bằng những từ khác nhau: các tệp không đáng tin cậy đến qua email, cổng tải lên hoặc trao đổi với bên thứ ba được xử lý ở ranh giới thay vì được cho phép dựa trên một phán quyết rồi mới xem xét sau đó.

Không văn bản nào nêu tên một công nghệ, và cả hai cũng không nên làm vậy. Điều mà cả hai đang yêu cầu, xét cho cùng, là liệu nhà vận hành có thể mô tả đường đi của một tệp và lý do được áp dụng cho nó ở từng bước hay không. Bảy đường đi, một phương pháp cho mỗi bước, và một ghi chú trung thực bên cạnh những bước mà phương pháp lặp lại, tài liệu đó là công việc của một buổi chiều, và chính nó làm cho phần còn lại của cuộc trao đổi trở nên hợp lý.

Bản đồ kiểm soát đầy đủ hơn và chi tiết về văn bản có trên Singapore compliance page.