Quản lý sự cố an toàn thông tin là nơi hệ thống ISMS theo ISO/IEC 27001 thể hiện rõ nhất nó đang vận hành thật hay chỉ tồn tại trên giấy. Bài viết trình bày yêu cầu của tiêu chuẩn, trình tự ứng phó, và những chỗ khiến quy trình sự cố trở nên vô dụng đúng lúc cần nhất.

Quản lý và ứng phó sự cố an toàn thông tin theo ISO 27001
🔗 Tham khảo: Đánh giá rủi ro an toàn thông tin theo ISO 27001

Sự kiện, điểm yếu và sự cố — ba khái niệm khác nhau

  • Sự kiện an toàn thông tin — một tình huống được quan sát thấy, có thể liên quan tới an toàn thông tin. Ví dụ: nhiều lần đăng nhập thất bại liên tiếp.
  • Điểm yếu — một lỗ hổng chưa bị khai thác. Ví dụ: phát hiện máy chủ chạy phiên bản phần mềm có lỗ hổng đã công bố.
  • Sự cố an toàn thông tin — một hoặc nhiều sự kiện có khả năng gây tổn hại tới tài sản thông tin hoặc đe doạ hoạt động của tổ chức.

Phân biệt ba khái niệm này quan trọng vì cơ chế xử lý khác nhau: sự kiện cần đánh giá xem có phải sự cố không; điểm yếu đi vào quy trình quản lý điểm yếu kỹ thuật; sự cố kích hoạt quy trình ứng phó.

Tiêu chuẩn yêu cầu gì

Nhóm biện pháp về quản lý sự cố nằm trong nhóm tổ chức của Phụ lục A, bao gồm: hoạch định và chuẩn bị; đánh giá và quyết định về sự kiện; ứng phó; rút kinh nghiệm từ sự cố; và thu thập bằng chứng.

Ngoài ra còn hai biện pháp gắn chặt: báo cáo sự kiện an toàn thông tin (thuộc nhóm con người — mọi nhân viên phải biết báo cho ai và bằng cách nào) và hoạt động giám sát (thuộc nhóm công nghệ — phát hiện bất thường).

Danh mục đầy đủ các biện pháp xem tại bài Phụ lục A của ISO/IEC 27001:2022.

Chuẩn bị trước — quyết định phần lớn kết quả

Khi sự cố xảy ra, thời gian dành cho việc tra cứu ai làm gì là thời gian mất trắng. Cần xác định trước:

  • Ai có thẩm quyền tuyên bố sự cố và ai điều phối ứng phó.
  • Phân loại mức độ nghiêm trọng kèm tiêu chí rõ ràng, và thời hạn ứng phó tương ứng cho từng mức.
  • Danh sách liên hệ nội bộ và bên ngoài — nhà cung cấp hạ tầng, đơn vị pháp lý, cơ quan quản lý — cập nhật, không phải danh sách của hai năm trước.
  • Kênh liên lạc dự phòng — nếu hệ thống email nội bộ chính là thứ bị tấn công thì không thể dùng nó để điều phối.
  • Ai được phát ngôn với khách hàng, đối tác và truyền thông.
  • Nghĩa vụ thông báo theo hợp đồng với khách hàng và theo quy định pháp luật hiện hành.

Trình tự ứng phó

  1. Phát hiện và tiếp nhận — từ giám sát tự động, từ báo cáo của nhân viên, hoặc từ bên ngoài (khách hàng, nhà nghiên cứu bảo mật).
  2. Đánh giá và phân loại — có phải sự cố không, mức độ nào, phạm vi ảnh hưởng tới đâu.
  3. Ngăn chặn lan rộng. Ưu tiên trước mọi thứ khác. Cân nhắc: ngắt hệ thống có thể phá huỷ bằng chứng, nên quyết định này cần người có thẩm quyền.
  4. Thu thập và bảo toàn bằng chứng — log, ảnh chụp bộ nhớ, bản sao ổ đĩa; ghi lại chuỗi lưu giữ nếu có khả năng dẫn tới thủ tục pháp lý.
  5. Loại bỏ nguyên nhân và khôi phục — vá lỗ hổng, gỡ mã độc, khôi phục từ bản sao lưu sạch, đổi thông tin xác thực.
  6. Thông báo cho các bên theo nghĩa vụ đã xác định trước.
  7. Rút kinh nghiệm — đây là bước tiêu chuẩn yêu cầu riêng và cũng là bước hay bị bỏ nhất.

Phân loại mức độ và thời hạn ứng phó

Không phải sự cố nào cũng cần huy động toàn bộ nguồn lực. Một thang phân loại thực dụng thường gồm ba tới bốn mức, xác định theo hai trục: phạm vi ảnh hưởng (một máy trạm, một phòng ban, toàn tổ chức, hay có cả dữ liệu khách hàng) và loại thông tin bị ảnh hưởng (nội bộ thông thường, dữ liệu cá nhân, bí mật kinh doanh, thông tin xác thực).

Mỗi mức gắn với ba thứ: ai được thông báo, trong bao lâu, và ai có thẩm quyền quyết định các hành động can thiệp mạnh như ngắt hệ thống hoặc khoá tài khoản hàng loạt.

Thiếu thang phân loại, mọi sự cố hoặc bị xử lý như nhau — lãng phí ở mức thấp và chậm ở mức cao.

Bằng chứng và chuỗi lưu giữ

Tiêu chuẩn có biện pháp riêng về thu thập bằng chứng. Điều này quan trọng khi sự cố có khả năng dẫn tới thủ tục pháp lý, khiếu nại bảo hiểm, hoặc tranh chấp hợp đồng với nhà cung cấp.

Nguyên tắc thực tế:

  • Ưu tiên bảo toàn trước khi khắc phục ở những sự cố nghiêm trọng — khởi động lại máy chủ có thể xoá sạch dấu vết trong bộ nhớ.
  • Ghi lại ai đã làm gì, lúc nào trong suốt quá trình ứng phó. Dòng thời gian này vừa là bằng chứng vừa là nguyên liệu cho bước rút kinh nghiệm.
  • Sao chép thay vì thao tác trên bản gốc khi phân tích.
  • Xác định trước khi nào cần bên ngoài — tổ chức không có năng lực điều tra số cần biết trước sẽ gọi ai, thay vì tìm nhà cung cấp lúc đang khủng hoảng.

Diễn tập — thứ phân biệt quy trình sống và quy trình chết

Một quy trình chưa bao giờ chạy thử chỉ là giả thuyết. Vài cách diễn tập theo mức công sức tăng dần:

  • Diễn tập trên bàn — cả nhóm ngồi lại, đưa ra một kịch bản và cùng đi qua từng bước xem ai làm gì. Rẻ, làm được hằng quý.
  • Diễn tập chức năng — thử một phần thật, ví dụ khôi phục một hệ thống từ bản sao lưu và đo thời gian.
  • Diễn tập mô phỏng — dựng một tình huống gần thật, ví dụ gửi email lừa đảo giả lập để đo tỉ lệ báo cáo của nhân viên.

Điều cần đo trong mọi hình thức: thời gian từ lúc phát hiện tới lúc có người điều phối, thời gian tới lúc ngăn chặn được, và số bước trong quy trình không chạy như thiết kế. Biên bản diễn tập nào cũng “đạt yêu cầu” là dấu hiệu diễn tập đang hình thức.

Rút kinh nghiệm: bước tạo ra giá trị

Tiêu chuẩn yêu cầu tổ chức sử dụng kiến thức thu được từ sự cố để giảm khả năng xảy ra hoặc giảm tác động của sự cố tương lai. Cụ thể, sau mỗi sự cố đáng kể cần trả lời:

  • Nguyên nhân gốc là gì — không dừng ở “nhân viên bấm vào link lạ”, mà hỏi tiếp vì sao link đó tới được hộp thư, vì sao máy trạm cho phép thực thi, vì sao không phát hiện sớm hơn.
  • Có cần cập nhật đánh giá rủi ro không — sự cố này có nằm trong các rủi ro đã nhận diện hay là rủi ro chưa từng nghĩ tới.
  • Có cần thêm hoặc sửa biện pháp kiểm soát, dẫn tới cập nhật Tuyên bố áp dụng.
  • Quy trình ứng phó có chỗ nào không chạy như thiết kế.

Một tổ chức xử lý mười sự cố mà không có thay đổi nào trong hệ thống là tổ chức sẽ gặp sự cố thứ mười một giống hệt.

Những chỗ khiến quy trình sự cố vô dụng

  • Nhân viên không biết báo cho ai. Quy trình hoàn hảo mà người phát hiện đầu tiên không biết dùng thì vô nghĩa. Đây là lý do biện pháp về báo cáo sự kiện nằm ở nhóm con người, không phải công nghệ.
  • Văn hoá đổ lỗi. Nếu người báo cáo bị kỷ luật, lần sau không ai báo. Sự cố vẫn xảy ra, chỉ là tổ chức biết muộn hơn.
  • Không có ai trực ngoài giờ trong khi phần lớn tấn công diễn ra ngoài giờ hành chính.
  • Log không đủ để điều tra — không bật, không tập trung, hoặc thời hạn lưu ngắn hơn thời gian trung bình phát hiện ra sự cố.
  • Không diễn tập. Quy trình chưa bao giờ chạy thử là giả thuyết chưa kiểm chứng.
  • Bỏ qua sự cố của bên thứ ba. Nhà cung cấp đám mây hoặc đối tác bị tấn công cũng là sự cố của bạn nếu dữ liệu của bạn nằm ở đó.
  • Không phân biệt sự cố an toàn thông tin với sự cố vận hành. Máy chủ sập vì hỏng ổ cứng và máy chủ sập vì bị tấn công có cùng biểu hiện nhưng cần hai quy trình khác nhau. Nếu mọi thứ đều đi vào hàng đợi hỗ trợ kỹ thuật chung, dấu hiệu tấn công sẽ bị xử lý như một lỗi phần cứng và đóng lại.

Hồ sơ cần lưu

Quy trình quản lý sự cố kèm tiêu chí phân loại; sổ ghi nhận sự kiện và sự cố; hồ sơ từng sự cố gồm diễn biến theo thời gian, hành động đã thực hiện, người quyết định; bằng chứng thu thập được; hồ sơ thông báo cho các bên; báo cáo rút kinh nghiệm và các thay đổi phát sinh từ đó; hồ sơ diễn tập.

Kết quả xử lý sự cố là một trong những thứ đánh giá nội bộ xem kỹ nhất.

Bước tiếp theo

Cách kiểm tra quy trình sự cố của bạn có sống không: hỏi ngẫu nhiên ba nhân viên không thuộc bộ phận CNTT xem họ sẽ làm gì nếu nghi ngờ máy tính bị nhiễm mã độc. Nếu ba người trả lời khác nhau, quy trình chưa tới được nơi cần tới.

Bài kiểm tra thứ hai dành cho bộ phận CNTT: lấy sự cố gần nhất và truy xem nó dẫn tới thay đổi cụ thể nào trong hệ thống — một biện pháp mới, một cấu hình sửa lại, một mục cập nhật trong đánh giá rủi ro. Nếu không truy được, vòng rút kinh nghiệm chưa khép.

Xem thêm hướng dẫn triển khai ISO 27001 hoặc quy trình chứng nhận ISO 27001.

Hoa Linh là chuyên gia tư vấn và triển khai hệ thống quản lý theo tiêu chuẩn quốc tế ISO với hơn 8 năm kinh nghiệm hỗ trợ doanh nghiệp Việt Nam đạt chứng nhận ISO 9001, ISO 14001, ISO 45001, ISO 22000, ISO 27001 và ISO 50001. Với nền tảng kiến thức chuyên sâu về quản lý chất lượng, quản lý môi trường, an toàn lao động và an toàn thông tin, Hoa Linh đã đồng hành cùng hàng trăm doanh nghiệp trong đa dạng lĩnh vực như sản xuất, thực phẩm, logistics, xây dựng, dịch vụ thương mại và công nghệ. Khả năng phân tích hệ thống hiện tại của doanh nghiệp, tư vấn các giải pháp cải tiến phù hợp, xây dựng tài liệu ISO chuyên nghiệp, đào tạo đội ngũ nhân sự, đánh giá nội bộ và hỗ trợ doanh nghiệp làm việc với tổ chức chứng nhận quốc tế.
Hiện tại, Hoa Linh là chuyên gia của Viện Nghiên Cứu Phát Triển Chứng Nhận Toàn Cầu (GCDRI) và trực tiếp tham gia tư vấn - đào tạo - hỗ trợ doanh nghiệp đạt chứng nhận ISO theo yêu cầu của khách hàng và đối tác quốc tế.

4,9/5 (5.461 đánh giá)
Bạn thấy nội dung này thực sự hữu ích?
Cảm ơn bạn đã nhận xét!
Like fanpage GCDRI để nhận tin mới mỗi ngày!