Một báo cáo bảo mật tốt cho người không chuyên trả lời bốn câu ngay trong trang đầu: chuyện gì đang xảy ra hoặc có thể xảy ra, ảnh hưởng tới công việc thế nào, cần làm gì theo thứ tự nào, và cần người đọc quyết định điều gì. Chi tiết kỹ thuật vẫn có, nhưng nằm ở phần sau cho đội kỹ thuật.
Trong nghề bảo mật, một phát hiện không được hiểu thì không được sửa. Người làm nghề giỏi kỹ thuật mà không viết được cho sếp, cho khách hàng hay cho bộ phận khác đọc thường thấy công việc bế tắc: cảnh báo không ai nghe, đề xuất không ai duyệt. Bài này đưa ra một khung viết, cách diễn đạt mức độ rủi ro, và cách trình bày trong cuộc họp ngắn.
Vì sao báo cáo kỹ thuật hay bị bỏ qua
Lý do phổ biến nhất là viết theo thứ tự người viết làm việc chứ không theo thứ tự người đọc cần. Người làm bảo mật kể từ lúc nhận cảnh báo, qua từng bước điều tra, tới cuối trang mới nói kết luận. Lãnh đạo đọc ba đoạn đầu toàn thuật ngữ, không thấy điều mình cần quyết, và gác lại.
Lý do thứ hai là không nối rủi ro với công việc của người đọc. Câu "máy chủ chưa vá lỗ hổng mức nghiêm trọng cao" không nói gì với chủ doanh nghiệp. Câu "máy chủ chứa toàn bộ đơn hàng đang có một lỗi đã được công bố rộng rãi; nếu bị khai thác, cửa hàng có thể ngừng nhận đơn và lộ thông tin khách" thì có.
Lý do thứ ba là đề xuất quá nhiều, ngang nhau. Danh sách hai mươi việc không thứ tự khiến người đọc không biết bắt đầu từ đâu và dễ chọn không làm gì. Lãnh đạo cần ba việc quan trọng nhất, kèm chi phí công sức ước lượng và hậu quả nếu không làm.
Khung báo cáo năm phần
Khung dưới dùng được cho báo cáo sự cố, báo cáo đánh giá định kỳ hay đề xuất một biện pháp. Độ dài từng phần tuỳ tình huống, nhưng giữ đúng thứ tự.
- Tóm tắt cho người quyết định (tối đa một trang). Chuyện gì, ảnh hưởng gì, mức độ rủi ro, ba việc cần làm, điều cần người đọc quyết định và hạn chót.
- Bối cảnh. Phạm vi báo cáo: hệ thống nào, khoảng thời gian nào, ai thực hiện, dựa trên dữ liệu gì.
- Phát hiện. Mỗi phát hiện một mục: mô tả bằng lời thường, bằng chứng, mức độ rủi ro, ảnh hưởng tới nghiệp vụ.
- Đề xuất theo thứ tự ưu tiên. Việc gì, ai làm, công sức ước lượng theo mức (thấp, vừa, cao), hậu quả nếu trì hoãn.
- Phụ lục kỹ thuật. Chi tiết cấu hình, dòng nhật ký, bước tái hiện cho đội kỹ thuật. Phần này có thể dài, vì người cần nó sẽ đọc.
Thử nghiệm đơn giản: đưa riêng trang tóm tắt cho một người không làm kỹ thuật đọc, rồi hỏi họ cần quyết định gì. Nếu họ không trả lời được, trang tóm tắt chưa đạt.
Diễn đạt mức độ rủi ro bằng ngôn ngữ người đọc
Mức độ rủi ro nên ghép hai yếu tố: khả năng xảy ra và mức ảnh hưởng. Bảng dưới gợi ý cách nói cho từng mức, dùng ví dụ giả định ở một cửa hàng bán hàng trực tuyến.
| Mức | Cách hiểu | Cách diễn đạt cho lãnh đạo | Thời hạn xử lý gợi ý |
|---|---|---|---|
| Nghiêm trọng | Dễ xảy ra, ảnh hưởng lớn | Có thể làm ngừng bán hàng hoặc lộ dữ liệu khách trong thời gian ngắn | Ngay, trong vài ngày |
| Cao | Có thể xảy ra, ảnh hưởng đáng kể | Nếu xảy ra sẽ gây gián đoạn hoặc tổn thất tiền rõ ràng | Trong vài tuần |
| Trung bình | Ít khả năng hoặc ảnh hưởng vừa | Gây phiền toái, tốn công khắc phục, chưa đe doạ hoạt động chính | Đưa vào kế hoạch quý |
| Thấp | Khó xảy ra, ảnh hưởng nhỏ | Nên làm khi thuận tiện, ví dụ lúc nâng cấp hệ thống | Khi có dịp |
Hai lưu ý. Thứ nhất, đừng thổi phồng mức độ để được duyệt nhanh: người đọc bị doạ vài lần sẽ không tin nữa. Thứ hai, ghi rõ mức độ chắc chắn của nhận định, ví dụ "đã xác nhận" khác "nghi ngờ, cần thêm dữ liệu". Lãnh đạo cần biết họ đang quyết dựa trên sự thật hay giả thuyết.
Viết câu cho người không chuyên đọc
Mỗi thuật ngữ cần một lần giải thích. Lần đầu nhắc "xác thực hai lớp", thêm nửa câu: "ngoài mật khẩu, người đăng nhập phải nhập thêm mã gửi về điện thoại". Từ lần sau dùng thuật ngữ bình thường.
Nói bằng hậu quả, không bằng cơ chế. Người đọc không cần biết lỗi hoạt động thế nào; họ cần biết nếu nó xảy ra thì cửa hàng mất gì, khách hàng bị gì, công ty phải làm gì.
Dùng so sánh đời thường, nhưng đúng mức. Chia sẻ một mật khẩu cho cả phòng giống như cả phòng dùng chung một chìa khoá không ghi tên: mất đồ không biết ai mở cửa. So sánh tốt làm người đọc hiểu nhanh; so sánh sai làm họ hiểu lệch.
Một đoạn, một ý. Đoạn văn dài trộn ba phát hiện khiến người đọc không nhớ được cái nào. Tách ra, mỗi phát hiện một đoạn có tiêu đề ngắn.
Không đổ lỗi cá nhân. Báo cáo nhắm vào quy trình và cấu hình, không nêu tên nhân viên bấm nhầm. Đổ lỗi khiến lần sau người ta giấu sự cố thay vì báo sớm.
Trình bày trong cuộc họp mười lăm phút
Nhiều quyết định về bảo mật được đưa ra trong một cuộc họp ngắn chứ không phải lúc đọc báo cáo. Chuẩn bị như sau: hai phút đầu nói đúng nội dung trang tóm tắt; năm phút cho ba phát hiện quan trọng nhất, mỗi cái kèm một câu về hậu quả; năm phút cho đề xuất và điều cần quyết; thời gian còn lại để hỏi đáp.
Đừng mang toàn bộ chi tiết kỹ thuật lên màn hình. Nếu có câu hỏi sâu, trả lời ngắn và hẹn gửi phụ lục. Khi bị hỏi "có chắc không", hãy trả lời đúng mức độ chắc chắn mình có, kể cả khi câu trả lời là "chưa chắc, cần thêm hai ngày để kiểm".
Một kỹ thuật hữu ích: đưa ra hai hoặc ba phương án thay vì một. Ví dụ giả định: phương án A làm ngay, tốn nhiều công sức, giảm rủi ro gần hết; phương án B làm một phần trong tháng này, phần còn lại quý sau; phương án C chấp nhận rủi ro, kèm hậu quả có thể xảy ra. Lãnh đạo có quyền chọn C, và việc của bạn là ghi lại quyết định đó bằng văn bản.
Ví dụ giả định: viết lại một phát hiện cho lãnh đạo
Bản kỹ thuật, đúng nhưng khó đọc: "Tài khoản quản trị của hệ thống bán hàng không bật xác thực đa yếu tố; nhật ký cho thấy nhiều lần đăng nhập thất bại từ địa chỉ nước ngoài trong tuần qua; mật khẩu chưa đổi từ khi triển khai."
Bản cho chủ doanh nghiệp: "Tài khoản quản lý trang bán hàng hiện chỉ cần mật khẩu để vào, và mật khẩu này chưa đổi từ ngày mở trang. Tuần qua có người lạ liên tục thử đăng nhập vào tài khoản này. Nếu họ đoán trúng, họ có thể sửa giá, xem thông tin khách hoặc tắt trang. Đề xuất: hôm nay đổi mật khẩu và bật thêm bước nhập mã từ điện thoại khi đăng nhập; việc này mất khoảng một giờ, không ảnh hưởng bán hàng. Cần anh chị đồng ý để thông báo cho ba nhân viên đang dùng chung tài khoản."
So sánh hai bản: bản thứ hai dài hơn nhưng trả lời đủ bốn câu người quyết định cần, có việc cụ thể, có công sức ước lượng, và kết thúc bằng điều cần người đọc làm. Nó cũng lộ thêm một vấn đề mà bản kỹ thuật bỏ sót: ba người dùng chung một tài khoản. Viết cho người không chuyên buộc người viết nghĩ kỹ hơn về hậu quả thật.
Báo cáo rút kinh nghiệm sau sự cố
Sau khi sự cố đã được xử lý xong, nhiều tổ chức có một buổi rút kinh nghiệm và một báo cáo ngắn. Đây là loại báo cáo dễ bị làm qua loa nhất, cũng là loại có giá trị lâu dài nhất, vì nó quyết định sự cố có lặp lại hay không.
Báo cáo rút kinh nghiệm tốt gồm dòng thời gian (phát hiện lúc nào, ai báo, mất bao lâu để khoanh vùng, bao lâu để khôi phục), những gì đã làm tốt, những chỗ chậm hoặc lúng túng, nguyên nhân gốc, và danh sách việc cải thiện có người phụ trách và hạn chót. Nguyên tắc quan trọng nhất là không đổ lỗi: mục tiêu là sửa quy trình, cấu hình, công cụ, không phải tìm người để phạt.
Người làm bảo mật thường là người viết báo cáo này. Hãy theo dõi danh sách việc cải thiện sau một hai tháng và báo lại tiến độ. Một báo cáo rút kinh nghiệm mà không ai theo dõi việc sau đó thì chỉ là biên bản.
Dùng AI hỗ trợ viết báo cáo mà không lộ dữ liệu
Chatbot giúp viết nhanh và dễ đọc hơn, nhưng báo cáo bảo mật thường chứa đúng loại thông tin nhạy cảm nhất của tổ chức. Một quy trình an toàn:
- Viết nháp kết luận và đề xuất bằng lời của mình trước; dùng AI để làm câu văn rõ hơn chứ không để AI đưa ra kết luận.
- Trước khi dán vào chatbot, thay tên công ty, tên hệ thống, địa chỉ IP, tên người dùng, tên khách hàng bằng nhãn giả.
- Không dán phần phụ lục kỹ thuật chứa cấu hình hay dòng nhật ký thật vào công cụ không được công ty cho phép.
- Câu lệnh mẫu: "Viết lại đoạn sau cho chủ doanh nghiệp không làm kỹ thuật đọc, giữ nguyên các con số và mức độ chắc chắn, không thêm thông tin mới".
- Đọc lại bản AI viết, kiểm xem nó có thêm thông tin không có trong nháp, hoặc làm mềm đi mức độ rủi ro không.
Câu "không thêm thông tin mới" trong lệnh mẫu không phải thừa: chatbot hay tự thêm lời khuyên chung chung hoặc con số nghe hợp lý nhưng không có căn cứ, và trong báo cáo bảo mật đó là lỗi nghiêm trọng.
Câu hỏi thường gặp
Báo cáo sự cố nên gửi khi đã điều tra xong hay gửi sớm?
Nên gửi sớm một bản ngắn ngay khi xác định có sự cố đáng kể, ghi rõ đây là thông tin ban đầu và sẽ cập nhật. Lãnh đạo cần biết sớm để chuẩn bị các quyết định như thông báo khách hàng hay tạm dừng dịch vụ. Báo cáo đầy đủ gửi sau khi điều tra xong.
Sếp không quan tâm tới báo cáo bảo mật thì làm gì?
Thử đổi cách nói sang ngôn ngữ của sếp: tiền, khách hàng, uy tín, thời gian ngừng hoạt động. Đưa một ví dụ giả định cụ thể sát với công ty thay vì số liệu chung. Nếu vẫn không được, ghi lại bằng văn bản rằng đã báo rủi ro và đề xuất, để trách nhiệm rõ ràng.
Có nên ghi số tiền thiệt hại ước tính trong báo cáo không?
Chỉ nên ghi khi bạn có cơ sở tính toán và nêu rõ cách tính, kèm chữ ví dụ giả định hoặc ước lượng. Con số không có căn cứ dễ bị bác bỏ và làm giảm uy tín của cả báo cáo. Nhiều khi mô tả hậu quả bằng lời, như ngừng bán hàng vài ngày, đã đủ thuyết phục.
Báo cáo cho khách hàng khác báo cáo nội bộ thế nào?
Báo cáo cho khách hàng cần cẩn trọng hơn về thông tin của bên thứ ba, cần thống nhất cách diễn đạt với người phụ trách hợp đồng, và thường cần nêu rõ phạm vi công việc đã thoả thuận. Nội dung vẫn theo khung năm phần, nhưng phần tóm tắt nên viết cho người ký hợp đồng bên khách.
Làm sao luyện kỹ năng viết báo cáo khi chưa đi làm bảo mật?
Viết báo cáo cho các bài tập lab và các thử thách CTF đã kết thúc theo đúng khung năm phần, rồi nhờ một người không làm kỹ thuật đọc phần tóm tắt. Luyện viết lại các tin cảnh báo an ninh công khai thành bản tin ngắn cho nhân viên văn phòng cũng là bài tập tốt.