Khung Suy Nghĩ Của Người Kiểm Toán: Tư Duy Như Một Kiểm Toán Viên IS

Một kiểm toán viên IS không được thuê để tìm ra mọi lỗi hoặc cấu hình sai trong một hệ thống. Công việc hẹp hơn, và thành thật mà nói, khó hơn: xác định xem các kiểm soát đã được thực hiện có cung cấp sự đảm bảo hợp lý rằng các rủi ro đối với doanh nghiệp được quản lý hay không. Sự phân biệt này thay đổi cách bạn tiếp cận hầu hết mọi nhiệm vụ, từ đọc một bộ quy tắc tường lửa đến phỏng vấn chủ sở hữu hệ thống.

Rủi ro trước, công nghệ sau

Một tester thâm nhập hỏi "tôi có thể phá vỡ cái này không?" Một kiểm toán viên hỏi "cái này có quan trọng không, và nếu nó thất bại, điều gì sẽ xảy ra với doanh nghiệp?" Trước khi chạm vào một kiểm soát nào, một kiểm toán viên cố gắng hiểu hệ thống làm gì, nó chạm vào dữ liệu nào, và điều gì sẽ xảy ra nếu tính bảo mật, tính toàn vẹn hoặc tính sẵn có bị xâm phạm. Đây là lý do tại sao các chương trình kiểm toán thường bắt đầu bằng đánh giá rủi ro hoặc đi bộ, chứ không phải quét lỗ hổng.

Cụ thể: nếu bạn đang kiểm toán kiểm soát truy cập trên một hệ thống bảng lương, câu hỏi đầu tiên không phải là "MFA có được bật không?" Mà là "tác động nếu một người không được phép có thể thay đổi dữ liệu lương hoặc xem PII là gì?" Khi bạn biết tác động, bạn có thể đánh giá xem các kiểm soát hiện có (MFA, quy trình phê duyệt, tách rời nhiệm vụ) có tương xứng hay không.

Bằng chứng hơn là khẳng định

Chủ sở hữu hệ thống sẽ nói với bạn rằng mọi thứ hoạt động. Công việc của một kiểm toán viên là xác minh, không phải tin tưởng. Điều này có nghĩa là yêu cầu các tài liệu: ảnh chụp màn hình cấu hình, xuất bản dữ liệu quyền truy cập người dùng, vé thay đổi có dấu thời gian phê duyệt, mục nhật ký cho thấy kiểm soát thực sự hoạt động. Nếu ai đó nói "chúng tôi xem xét truy cập hàng quý," kiểm toán viên yêu cầu xem ba bản ghi xem xét gần nhất, chứ không chỉ chính sách quy định nó.

Thói quen dựa trên bằng chứng này là điều phân biệt một phát hiện kiểm toán khỏi một cuộc trò chuyện ở hành lang. Một phát hiện cần phải chịu được kiểm tra: cái gì được kiểm tra, quần thể nào được lấy mẫu, tiêu chí nào được sử dụng, và điều gì thực sự được quan sát. Các phát biểu mơ hồ như "kiểm soát có vẻ đủ" không được chứng minh trong một báo cáo mà quản lý và cơ quan quản lý sẽ đọc.

Thiết kế so với hiệu quả hoạt động

Một trong những phân chia tư duy hữu ích nhất trong lĩnh vực này là tách biệt thiết kế kiểm soát khỏi hoạt động kiểm soát. Chính sách mật khẩu yêu cầu 14 ký tự và MFA được thiết kế tốt trên giấy. Nhưng nếu lần xem xét truy cập cuối cùng là 11 tháng trước, hoặc nếu các tài khoản dịch vụ bị miễn trừ mà không có tài liệu, kiểm soát không hoạt động như dự định. Kiểm toán viên kiểm tra cả hai: kiểm soát có tồn tại như được mô tả hay không, và nó có thực sự được tuân thủ hàng ngày không?

Đây là lý do tại sao lấy mẫu quan trọng. Kiểm tra truy cập của một người dùng không cho bạn biết nhiều. Lấy một mẫu 25 nhân viên bị chấm dứt và kiểm tra xem các tài khoản của họ có bị vô hiệu hóa trong cửa sổ SLA (giả sử, 24 hoặc 48 giờ) không sẽ cung cấp cho bạn cơ sở có thể bảo vệ được để đưa ra kết luận.

Tách rời nhiệm vụ như một chủ đề thường xuyên

Một phần lớn các phát hiện kiểm toán có nguồn gốc từ tách rời nhiệm vụ (SoD): cùng một người yêu cầu thay đổi cũng phê duyệt nó, hoặc một nhà phát triển có truy cập trực tiếp cơ sở dữ liệu sản xuất cùng với quyền triển khai. Kiểm toán viên liên tục tìm kiếm những sự chồng lấp này, bởi vì các lỗi SoD là cách gian lận và lỗi vô ý trượt qua mà không có một set mắt thứ hai bắt được chúng.

Khi xem xét một môi trường, hãy hỏi: ai có thể bắt đầu một hành động, ai có thể phê duyệt nó, và ai có thể thực hiện nó? Nếu một người nắm giữ hai hoặc nhiều trong những vai trò đó mà không có kiểm soát bù đắp (như ghi nhật ký chi tiết được xem xét bởi người khác), đó là một khoảng trống đáng ghi chép.

Viết phát hiện được khắc phục

Một phát hiện chính xác về mặt kỹ thuật mà không ai thực hiện là một cuộc kiểm toán lãng phí. Những phát hiện tốt nêu rõ điều kiện (điều gì được quan sát), tiêu chí (chính sách hoặc tiêu chuẩn nó vi phạm), nguyên nhân (tại sao nó xảy ra), và ảnh hưởng (rủi ro nào cái này tạo ra) — cấu trúc 4C cổ điển nhiều cửa hàng kiểm toán sử dụng. Các phát hiện mơ hồ như "kiểm soát truy cập cần cải thiện" bị bỏ qua. Những cái cụ thể như "14 trong 25 nhân viên bị chấm dứt được lấy mẫu giữ lại truy cập VPN trong hơn 5 ngày sau ngày chấm dứt của họ, vi phạm SLA khử bỏ 24 giờ trong chính sách SEC-014" được khắc phục vì chủ sở hữu biết chính xác phải khắc phục cái gì.

Xây dựng thói quen

Bạn phát triển khung này bằng cách thực hành nó trên các hệ thống thông thường, không chỉ các cuộc tham gia chính thức. Chọn một ứng dụng bạn sử dụng hàng ngày và hỏi: rủi ro nếu nó thất bại là gì, kiểm soát nào tồn tại, và tôi sẽ chứng minh chúng hoạt động như thế nào? Làm cái này đủ lần và bản năng kiểm toán viên — sự hoài nghi kết hợp với yêu cầu bằng chứng — trở nên tự động.

Nếu loại tư duy kiểm soát và rủi ro này quan tâm đến bạn, hãy xem các phân đoạn của Korra Studio về các mô hình kiểm soát truy cập và các khung công việc quản trị bảo mật để có sự hiểu biết kỹ thuật sâu hơn.