Chương IV: CÁC POLICY LIÊN QUAN
3.6.6Kiểm tra văn bản rõ ràng thủ tục quản lý yêu cầu các kiến thức phân chia
quản lý yêu cầu các kiến thức phân chia và kiểm soát kép của các khóa.
R3.6.7 Phòng ngừa thay đổi trái phép của các khóa mã hóa.
P3.6.7 Xác minh rằng các thủ tục quản lý quan trọng được thực hiện để đòi hỏi công tác phòng chống thay đổi trái phép của các khóa.
R3.6.8 Yêu cầu người quản khóa mã hóa để chính thức thừa nhận rằng họ hiểu và chấp nhận trách nhiệm giám sát của họ.
P3.6.8 Xác minh rằng các thủ tục quản lý quan trọng được thực hiện để yêu cầu người quản lý chính thừa nhận (bằng văn bản hoặc điện tử ) họ hiểu và chấp nhận trách nhiệm giám sát của họ.
Yêu cầu 4: Mã hóa thông tin thẻ trong đường truyền trong quá trình giao dịch.
Thông tin nhạy cảm phải được mã hóa trong quá trình giao dịch qua mạng vì thông tin dễ dàng truy cập bởi các cá nhân gây hại. Mạng không dây gây hại, các lỗ hỏng trong mã hóa và giao thức xác thực là mục tiêu của các cá nhân gây hại – những người khai thác lỗ hỏng này để đạt được quyền truy cập đến môi trường dữ liệu thẻ thanh toán.
R4.1 Sử dụng mật mã và giao thức bảo mật mạnh mẽ (SSL/ TLS, IPSEC, SSH, …) để bảo vệ dữ liệu nhạy cảm của chủ thẻ trong quá trình truyền, giao dịch trên mạng cộng đồng.
Ví dụ về giao dịch mở, mạng cộng đồng mà trong phạm vi của PCI DSS bao gồm:
Internet
Công nghệ wireless
- Hệ thống toàn cầu cho thông tin di động (GSM)
- Dịch vụ GPRS
P4.1 Kiểm tra việc sử dụng các giao thức bảo mật bất cứ nơi nào dữ liệu chủ thẻ được truyền đi hoặc được nhận trên giao dịch mở, mạng công cộng.
Xác minh các mật mã mạnh được sử dụng trong quá trình truyền tải.
P4.1.a Chọn ngẫu nhiên một giao dịch khi họ nhận được và thực hiện giao dịch để xác minh dữ liệu chủ thẻ được mã hóa trong quá trình truyền tải.
P4.1.b Xác minh chỉ các khóa hoặc các giấy chứng nhận tin cậy được chấp nhận.
P4.1.c Xác minh các giao thức được thưc hiện để sử dụng cấu hình an toàn
và không hỗ trợ các phiên bản cấu hình không an toàn.
P4.1.d Xác minh việc mã hóa mạnh thích hợp cho các phương pháp mã hóa được sử dụng (khuyến nghị kiểm tra các nhà cung cấp/thực hiện tốt nhất).
P4.1.e Đối với việc triển khai SSL/ TLS:
- Xác minh https xuất hiện như một thành phần của các trình duyệt (URL). - Xác minh rằng không có dữ liệu chủ thẻ được yêu cầu khi https không xuất hiện trong URL.
R4.1.1 Đảm bảo mạng không dây truyền dữ liệu chủ thẻ hoặc kết nối với môi trường dữ liệu chủ thẻ phải sử dụng ngành công nghiệp thực hiện tốt nhất (ví dụ, IEEE 802.11i) để thực hiện mã hóa mạnh mẽ nhằm xác thực và truyền dẫn.
P4.1.1 Đối với các mạng không dây truyền dữ liệu chủ thẻ hoặc kết nối với môi trường dữ liệu chủ thẻ , kiểm tra ngành công nghiệp thực hiện tốt nhất (ví dụ , IEEE 802.11i ) được sử dụng để thực hiện mã hóa mạnh mẽ nhằm xác thực và truyền dẫn.
Yêu cầu 5: Sử dụng mà thường xuyên cập nhật các phần mềm và chương trình diệt virus.
Phần mềm độc hại , thường được gọi là “malware” - bao gồm virus ,sâu và Trojan - vào mạng trong khi nhiều hoạt động kinh doanh đã được phê duyệt bao gồm cả hoạt động nhân viên e-mail và sử dụng Internet, máy tính di động, và các thiết bị lưu trữ, dẫn đến việc khai thác các lỗ hổng hệ thống . Phần mềm chống virus phải được sử dụng trên tất cả các hệ thống thường bị ảnh hưởng bởi phần mềm độc hại để bảo vệ hệ thống khỏi các mối đe dọa phần mềm độc hại hiện tại và sau này.
R5.1 Triển khai phần mềm chống virus trên tất cả các hệ thống thường bị ảnh
P5.1 Đối với các thành phần hệ thống bao gồm tất cả các loại hệ điều hành
hưởng bởi các phần mềm độc hại (đặc biệt là máy tính cá nhân và máy chủ ).
thường bị ảnh hưởng bởi phần mềm độc hại thì phải xác minh rằng phần mềm chống virus được triển khai nếu có công nghệ chống virus tồn tại.
R5.1.1 Đảm bảo rằng tất cả các chương trình chống virus có khả năng phát hiện, loại bỏ, bảo vệ và chống lại tất cả các loại phần mềm độc hại. (adsbygoogle = window.adsbygoogle || []).push({});
P5.1.1 Đối với các thành phần hệ thống, kiểm tra tất cả các chương trình chống virus phát hiện , loại bỏ bảo vệ và chống lại tất cả các loại phần mềm độc hại được biết đến (ví dụ: virus, trojan, sâu, phần mềm gián điệp, phần mềm quảng cáo, và rootkit ).
R5.2 Đảm bảo rằng tất cả các cơ chế chống virus hiện tại tích cực hoạt động, và tạo ra các báo cáo kiểm toán.
P5.2 Xác minh rằng tất cả các phần mềm chống virus hiện tại tích cực hoạt động, và tạo ra các bản ghi bằng cách thực hiện như sau:
P5.2.a Kiểm tra chính sách và xác minh đòi hỏi định nghĩa và cập nhật phần mềm chống virus.
P5.2.b Xác minh các cài đặt chủ của phần mềm được kích hoạt tự động cập nhật và quét định kỳ.
P5.2.c Đối với các thành phần hệ thống bao gồm tất cả các loại hệ điều hành thường bị ảnh hưởng bởi phần mềm độc hại, xác minh bản cập nhật tự động và quét định kỳ được kích hoạt.
P5.2.d Đối với các thành phần hệ thống, kiểm tra chống virus, phần mềm ghi được kích hoạt và các bản ghi đó được giữ lại theo quy định của PCI DSS Yêu cầu 10.7 .
Yêu cầu 6: Phát triển và duy trì hệ thống và các ứng dụng đảm bảo an ninh mạng.
Những cá nhân có mục đích xấu dùng những lỗ hổng bảo mật để có được quyền truy cập vào hệ thống. Nhiều lỗ hỗng bảo mật được sửa lại bằng các bản vá bảo mật của nhà cung cấp được cài đặt bởi bộ phận quản lý hệ thống. Tất cả các hệ thống quan trọng phải có bản phát hành mới nhất, các bản vá phần mềm thích hợp để chống lại sự khai thác và gây nguy hại đến dữ liệu thẻ thanh toán bởi các phần mềm độc hại.
Ghi chú: Bản vá lỗi phần mềm thích hợp là những bản vá đã được đánh giá, thử nghiệm đầy đủ nhằm xác định bản vá đó phù hợp với cấu hình bảo mật hiện tại. Đối với các nhà phát triển ứng dụng, vô số các lỗ hổng có thể tránh được bằng cách sử dụng quá trình phát triển hệ thống tiêu chuẩn và các kỹ thuật mã hóa an toàn.
R6.1: Đảm bảo rằng tất cả các thành phần hệ thống cũng như phần mềm được bảo vệ khỏi các lỗ hỗng đã được biết tới bằng việc cài đặt bản vá bảo mật mới nhất của nhà cung cấp. Cài đặt các bản vá lỗi bảo mật quan trọng trong vòng 1 tháng phát hành.
P6.1.a Lấy ví dụ một thành phần hệ thống và phần mềm liên quan, so sánh danh sách các bản vá bảo mật đã cài đặt trên mỗi hệ thống với danh sách bản vá bảo mật hiện tại của nhà cung cấp để xác nhận rằng các bản vá hiện tại của nhà cung cấp đã được cài đặt.
P6.1.b Kiểm tra các chính sách liên quan đến việc cài đặt bản vá bảo mật để xác minh rằng họ yêu cầu cài đặt tất cả các bản vá bảo mật trong vòng 1 tháng. R6.2 Thiết lập một quá trình để để nhận dạng và phân loại thứ hạng rủi ro đối với những lỗ hổng bảo mật mới được phát hiện. S6.2 Nhận dạng lỗ hổng.
P6.2.a Trao đổi với nhân viên chịu trách nhiệm để xác nhận những quá trình đang được triển khai để nhận dạng các lỗ hỗng bảo mật mới, và bảng xếp hạng rủi ro được phân đến các lỗ hổng. G6.2.a Tối thiểu, những lỗ hỗng rủi ro cao nhất nên được xếp hàng là ‘Cao’.
P6.2.b Xác nhận những quá trình nhận dạng lỗ hỗng bảo mật mới. G6.2.b Sử dụng nguồn tài nguyên bên ngoài đối với thông tin lỗ hỗng bảo mật
R6.3 Phát triển các phần mềm ứng dụng (nội bộ và bên ngoài, và kèm theo quản trị truy cập trên website cho các ứng dụng) phù hợp với PCI DSS (ví dụ như chứng thực an toàn và logging), và dựa trên ngành công nghiệp hiện đại. Kết hợp bảo mật thông tin trong suốt vòng đời phát triển phần mềm.
P6.3.a Xác nhận các quy trình này dựa trên tiêu chuẩn ngành công nghiệp. G6.3.a Thu nhận và kiểm tra quy trình phát triển phần mềm trên giấy P6.3.b Xác nhận thông tin bảo mật luôn gắn liền với vòng đời sản phẩm. G6.3.b-c Kiểm tra quy trình phát triển phần mềm bằng văn bản P6.3.c Xác nhận rằng các phần mềm ứng dụng được phát triển phù hợp với PCI DSS.
P6.3.d Từ các lần kiểm tra về quy trình phát triển phần mềm trên giấy, và trao đổi với nhân viên phát triển phần mềm, xác nhận:
R6.3.1 Loại bỏ các tài khoản ứng dụng tùy chỉnh, ID người dùng và password trước khi các ứng dụng được kích hoạt hoặc được đưa đến khách hàng.
P6.3.1 Các tài khoản tùy chỉnh, ID người dùng và password bị xóa bỏ trước khi hệ thống trở thành sản phẩm hay được giao đến khách hàng.
R6.3.2 Xem xét các mã tùy chỉnh trước khi phát hành sản phẩm hay đưa đến người dùng để xác nhận lại bất kì lỗ hổng lập trình có thể xảy ra.
P6.3.2.a Xem lại các chính sách để chắc chắn rằng tất cả những sự thay đổi mã ứng dụng tùy chỉnh phải được kiểm tra lại (bằng tay hay bằng quy trình tự động)
- Thay đỗi mã được kiểm tra lại bởi những cá nhân không nằm trong nhóm viết code, và bởi những cá nhân có kiến thức về kỹ thuật kiểm tra code và thực hiện an toàn mã hóa.
- Đảm bảo mã được phát triển theo nguyên tắc mã hóa an toàn.
- Việc tùy chỉnh thích hợp được triển khai trước khi phát hành.
- Kết quả xem xét mã được duyệt lại và được quản lý đồng ý trước khi phát hành.
P6.3.2.b Chọn một ví dụ về sự thay thổi ứng dụng tùy chỉnh hiện tại và xác nhận rằng mã ứng dụng tùy chỉnh đã được kiểm tra như 6.3.2.a
R6.4 Thực hiện các quy trình và thủ tục kiểm soát thay đổi với tất cả những thay đổi trong thành phần hệ thống. Quy trình bao gồm:
P6.4 Từ việc kiểm tra quy trình kiểm soát thay đổi, khảo sát hệ thống và các nhà quản trị mạng, và kiểm tra các dữ liệu liên quan (tài liệu hướng dẫn cấu hình mạng, dữ liệu sản xuất và thử nghiệm, …), xác minh được:
R6.4.1 Tách biệt môi trường phát triển/thử nghiệm và sản xuất. (adsbygoogle = window.adsbygoogle || []).push({});
P6.4.1 Môi trường phát triển/thử nghiệm được tách biệt từ môi trường sản xuất, thực hiện kiểm soát truy cập tại chỗ để bắt buộc việc tách biệt trên.
R6.4.2 Phân biệt rõ nhiệm vụ giữa môi trường phát triển/thử nghiệm và sản xuất.
P6.4.2 Sự phận biệt rõ về nhiệm vụ giữa nhân viên được phân công làm việc tại môi trường làm việc về phát triển/thử nghiệm và những người được phân công tại môi trường sản xuất.
R6.4.3 Dữ liệu sản xuất không được dùng trong quá trình thử nghiệm hay phát triển.
P6.4.3 Dữ liệu sản xuất không được dùng trong quá trình thử nghiệm hay phát triển.
R6.4.4 Loại bỏ các dữ liệu và tài khoản thử nghiệm trước khi hệ thống sản phẩm được đưa vào hoạt động.
P6.4.4 Dữ liệu và tài khoản thử nghiệm phải được loại bỏ trước khi một hệ thống sản phẩm được đưa vào hoạt động.
R6.4.5 Thay đổi các thủ tục kiểm soát trong việc triển khai các bản vá bảo mật và sửa đổi phần mềm. Các thủ tục đó bao gồm:
P6.4.5.a Xác minh rằng các thủ tục kiểm soát thay đổi liên quan đến việc triển khai các bản vá bảo mật và sửa đổi phần mềm được lưu lại và
P6.4.5.b Lấy ví dụ một thành phần hệ thống và bản vá lỗi bảo mật/bản vá thay đổi gần đây, theo dõi những thay đổi dựa trên tài liệu hướng dẫn kiểm soát thay đổi có liên quan. Đối với mỗi sự thay đổi, thực hiên như sau:
S6.4.5.1 Tài liệu về sự tác động P6.4.5.1 Xác minh tài liệu về sự tác động được đính kèm trong tài liệu kiểm soát thay đổi đối với mỗi ví dụ. R6.4.5.2 Ghi nhận lại sự chấp
thuận về thay đổi bởi bên được ủy quyền
P6.4.5.2 Xác minh rằng sự chấp thuận được ghi lại bởi bên được ủy quyền là đại diện cho mỗi ví dụ thay đổi. R6.4.5.3 Kiểm tra các chức
năng để chắn chắn rằng việc sửa đổi không gây ảnh hưởng xấu tới an ninh hệ thống.
P6.4.5.3.a Đối với mỗi thay đổi mẫu, xác minh rằng chức năng kiểm tra vẫn hoạt động để chắc chắn các thay đổi không gây ảnh hưởng xuất tới an ninh hệ thống.
P6.4.5.3.b Đối với thay đổi mã tùy chỉnh, xác nhận rằng tất cả các bản cập nhật đã được test phù hợp với yêu cầu của PCI DSS trước khi triển khai vào sản phẩm.
S6.4.5.4 Thủ tục back-out P6.4.5.4 Xác nhận các thủ tục back-out được chuẩn bị cho mỗi thay đổi mẫu.
R6.5 Phát triển các ứng dụng dựa trên những nguyên tắc mã hóa an toàn. Ngăn chặn các lỗ hỗng mã hóa phổ biến trong quy trình phát triển phần mềm, bao gồm:
P6.5.a Thu thập và xem xét quá trình phát triển phần mềm. Xác nhận rằng các quy trình yêu cầu sự đào tạo về kỹ thuật mã hóa an toàn cho các nhân viên phát triển phần mềm, dựa trên các hướng dẫn và thực tiễn nền công nghiệp hiện đại.
P6.5.b Trao đổi với một số nhân viên phát triển phần mềm và có được bằng chứng rằng họ có hiệu biết về kỹ thuật mã hóa an toàn.
P6.5.c Xác nhận các quy trình được đưa ra đảm bảo các ứng dụng khó bị xâm phạm ở mức tối thiểu, như sau:
R6.5.1 Lỗ hổng tiêm nhiễm, đặc biệt là SQL Injection. Cần phải xem xét OS Command Injection, LDAP và lỗ hổng XPath Injection cũng như các sai sót khác.
P6.5.1 Lỗ hổng tiêm nhiễm, đặc biệt là SQL Injection (Thông qua input để xác nhận dữ liệu người dùng không thể sửa đổi ý nghĩa câu lệnh và câu truy vấn, dùng tham số truy vấn, …)
R6.5.2 Buffer overflow (Lỗi tràn bộ nhớ đệm)
P6.5.2 Lỗi tràn bộ nhớ đệm (thông qua ranh giới vùng đếm và rút ngắn chuỗi input)
R6.5.3 Lưu trữ mật mã không an toàn
P6.5.3 Lưu trữ mật mã không an toàn (ngăn chặn tràn mật mã).
R6.5.4 Những thông tin không an toàn
P6.5.4 Mã hóa chính xác tất cả các thông tin cần xác thực và nhạy cảm. R6.5.5 Xử lý lỗi sai P6.5.5 Xử lý lỗi sai. G6.5.5 không làm rò rỉ thông tin qua các tin nhắn lỗi.
R6.5.6 Tất cả các lỗ hổng ‘Cao’ được xác định trong quá trình xác nhận lỗ hổng (như 6.2) (adsbygoogle = window.adsbygoogle || []).push({});
P6.5.6 Tất cả các lỗ hổng ‘Cao’ được xác định theo yêu cầu của PCI DSS trong 6.2.
R6.6 Đối với các ứng dụng web công cộng, giải quyết các mối đe dọa mới và các lỗ hổng trên cơ sở liên tục và đảm bảo những ứng dụng này được bảo vệ để chống lại các cuộc tấn công đã biết.
S6.6 Tường lửa P6.6 Đối với các ứng dụng web cộng đồng, đảm bảo áp dụng một trong hai phương pháp sau:
- Xác nhận rằng các ứng dụng web cộng đồng được duyệt lại (bằng tay hoặc công cụ hay phương thức đánh giá lỗ hổng bảo mật tự động) như sau:
+ Ít nhất mỗi năm một lần
+ Sau bất kì thay đổi nảo
+ Bởi một tổ chức có chuyên môn về ứng dụng bảo mật.(*)
+ Tất cả các lỗ hổng đều được sửa chữa + Ứng dụng được đánh giá lại sau khi sửa chữa.
-Xác nhận rằng tường lửa của ứng dụng web được cài đặt trước khi đưa vào sử dụng trong cộng đồng. G6.6 Chống lại các cuộc tấn công bằng một trong các phương thức: - Rà soát các ứng dụng web công cộng bằng tay hoặc các công cụ hay phương thức đánh giá lỗ hổng bảo mật ứng dụng tự động, ít nhất mỗi năm một lần và sau mỗi lần thay đổi. - Cài đặt tường lửa ứng dụng web cho các ứng dụng web công cộng.
Yêu cầu 7: Hạn chế việc truy cập vào dữ liệu thẻ thanh toán
Để đảm bảo dữ liệu quan trọng chỉ có thể được truy cập bởi những người được ủy quyền, hệ thống và các tiến trình phải được áp dụng việc hạn chế truy cập dựa trên