Đánh giá bảo mật trong thế giới PCI DSS
Tài liệu "Reporting Instructions" đã đề cập đến một danh sách các lỗ hổng được liệt kê trong một yêu cầu khác của PCI DSS (6.5), đây là các lỗ hổng tối thiểu phải được kiểm tra khi tiến hành đánh giá an ninh ứng dụng :
6.5.1 Injection flaws, SQL injection, OS Command Injection, LDAP và XPath Injection
6.5.2 Buffer overflow
6.5.3 Insecure cryptographic storage
6.5.4 Insecure communications
6.5.5 Improper error handling
6.5.6 Tất cả các lỗ hổng được xếp hạng “High” trong quá trình xác định lỗ hổng (PCI DSS Yêu cầu 6.2).
Và một số lỗ hổng khác đối với các ứng dụng trên nền tảng Web :
6.5.7 Cross-site scripting (XSS)
6.5.8 Improper Access Control
6.5.9 Cross-site request forgery (CSRF)
Việc đánh giá an ninh ứng dụng nếu làm chuyên sâu cũng có thể gây ra rắc rối đối với việc xác định phạm vi; có nên bao gồm cả việc viết các mã khai thác đặc biệt đối với các ứng dụng được phát triển in-house ít người biết đến hay không ? Điều này thường không phải là mong muốn của các QSAs, họ chỉ cần tiến hành thử nghiệm khai thác các lỗ hổng ứng dụng Web như SQL Injection và Insecure Session Handling. Không cần phải Fuzzing đối với ứng dụng in-house !
Ngoài việc xác định phạm vi còn có 4 yêu cầu phụ rất quan trọng đối với đánh giá bảo mật mà tổ chức cần phải xem xét :
- Đánh giá bảo mật nên được thực hiện ít nhất mỗi năm một lần
- Thực hiện đánh giá bảo mật sau khi có bất kỳ sự thay đổi đáng kể diễn ra bên trong hệ thống
- Việc đánh giá cần được lặp đi lặp lại để xác nhận các lỗ hổng tìm thấy đã được khắc phục
- Việc đánh giá nên được thực hiện bởi một bên thứ ba chuyên trách độc lập đối với việc đánh giá bảo mật
Đánh giá bảo mật ít nhất mỗi năm một lần là điều không có gì mới mẻ, đó là điều mà hầu hết các doanh nghiệp ngày nay ở Việt Nam đã thực hiện; Tuy nhiên, đánh giá bảo mật sau khi có bất kỳ "sự thay đổi đáng kể diễn ra" và lặp đi lặp lại để xác nhận rằng các lỗ hổng tìm thấy đã được khắc phục có thể làm gia tăng số lượng các đợt đánh giá.
Vì lý do đó, phương pháp đánh giá cho các loại nhu cầu này nên có tính thích nghi đặc biệt. Cách tiếp cận được khuyến nghị ở đây là xác định một cách hợp lý hơn các kịch bản đánh giá trong đợt kiểm tra hàng năm, song song đó giữ lại những kịch bản để đánh giá nhanh mỗi khi có sự thay đổi diễn ra bên trong hệ thống.
Toàn bộ vấn đề liên quan đến việc đánh giá sau khi có "những sự thay đổi đáng kể" diễn ra là một "câu chuyện" rất lớn cần phải được thảo luận trong quá trình đánh giá PCI.
Để bắt đầu, chúng ta chỉ cần xác định những gì được xem là "thay đổi đáng kể" có thể làm cho các chuyên gia bảo mật trong tổ chức phải bận rộn trong nhiều tháng trời. Tiêu chuẩn PCI DSS bản thân nó không giúp ích được gì nhiều trong vấn đề này, vì nó cho rằng việc nâng cấp hệ điều hành là một ví dụ về sự thay đổi đáng kể.
Chúng ta nên dựa vào kinh nghiệm của chính bản thân đội ngũ CNTT trong tổ chức để cân nhắc xem việc nâng cấp một máy chủ nội bộ từ Windows 2003 lên Windows 2008 có phải là một sự thay đổi đáng kể để kích hoạt việc đánh giá bảo mật External hay không ?
Đó chính là loại câu hỏi sẽ khiến cho các QSAs trở nên bận rộn khi đánh giá yêu cầu 11.3. Cách tốt nhất dành cho tổ chức để giải quyết vấn đề này chính là phải xác định rõ ràng kiến giải của riêng mình về "những sự thay đổi đáng kể", đồng thời xác minh lại với QSA trước khi đánh giá.
Đối với các tổ chức có nhu cầu thuê bên thứ ba để thực hiện việc đánh giá, điều quan trọng là phải hiểu chúng ta đang cần gì để thuê cho đúng mục đích.
(Xem thêm bài Thị Trường Penetration Test tại Việt Nam)
Thuê bên thứ ba để tiến hành cuộc đánh giá bảo mật lớn hàng năm là vấn đề phổ biến, tuy nhiên trong PCI DSS còn khuyến khích nên có một hợp đồng dài hạn với bên thứ ba để họ chịu trách nhiệm thực hiện các cuộc đánh giá nhanh "theo yêu cầu" khi có những sự thay đổi diễn ra. Tuy nhiên phương án này khá tốn kém chi phí. Điều này bình thường trong thời buổi thắt lưng buộc bụng, việc sử dụng ngân sách hiệu quả là một việc rất nên làm.
Vì lý do tiết kiệm ngân sách, bên thứ ba vẫn có thể được sử dụng cho cuộc đánh giá lớn trong năm và các cuộc đánh giá bảo mật phức tạp hơn, nhưng đội ngũ bên trong nội bộ có thể được huấn luyện đào tạo để thực hiện các kịch bản đánh giá nhanh khi có sự thay đổi diễn ra.
Ngay cả khi bạn nghĩ sẽ không có nhiều sự thay đổi diễn ra thì cũng rất quan trọng bạn cần phải nhớ rằng các cuộc đánh giá cần phải được lặp đi lặp lại khi các lỗ hổng được tìm thấy.
PCI DSS đòi hỏi chuyên gia phải "đủ năng lực chuyên môn" để thực hiện các kịch bản đánh giá, do đó người đánh giá cần phải có chứng chỉ chuyên môn cao cấp và các kỹ năng chuyên sâu khác để đảm bảo các cuộc đánh giá sẽ được chấp nhận bởi QSA.
Ngoài ra còn có một yêu cầu vô cùng quan trọng đối với các bên thứ ba khi tham gia đánh giá, đó chính là tính độc lập, các bên thứ ba có ngành nghề chủ yếu là tư vấn chiến lược, kiểm toán an ninh hoặc kiểm toán tính tuân thủ (Compliance) sẽ tốt hơn so với các bên thứ ba vừa đánh giá vừa bán sản phẩm/giải pháp.
DNA Headquarter