top of page
Tìm kiếm

PENTEST là gì? Hướng dẫn đánh giá xâm nhập hệ thống cho doanh nghiệp

PENTEST, viết đầy đủ là Penetration Testing, là hoạt động mô phỏng có kiểm soát các kỹ thuật tấn công nhằm kiểm chứng liệu điểm yếu trong ứng dụng, API, hạ tầng mạng, tài khoản hoặc cấu hình bảo mật có thể bị khai thác và gây ảnh hưởng thực tế hay không.

Tại Việt Nam, hoạt động này còn được biết đến là kiểm thử xâm nhập, kiểm thử xâm nhập hệ thống hoặc đánh giá xâm nhập hệ thống.

Điểm khác biệt quan trọng của PENTEST là doanh nghiệp không chỉ nhận một danh sách lỗi. Kết quả kiểm thử cần giúp trả lời những câu hỏi sát với rủi ro kinh doanh:

  • Kẻ tấn công có thể tiếp cận hệ thống từ đâu?

  • Điểm yếu nào thực sự có khả năng bị khai thác?

  • Nhiều lỗi riêng lẻ có thể kết hợp thành một chuỗi tấn công hay không?

  • Dữ liệu, tài khoản và quy trình kinh doanh nào có thể bị ảnh hưởng?

  • Đội kỹ thuật cần khắc phục điều gì trước?

  • Biện pháp sửa lỗi đã thực sự hiệu quả hay chưa?

Một chương trình PENTEST hoàn chỉnh thường đi qua hành trình: 

Xác định mục tiêu → Lựa chọn phạm vi → Chuẩn bị kiểm thử → Thực hiện khai thác có kiểm soát → Báo cáo và khắc phục → Retest.

PENTEST vì thế không chỉ là một hoạt động kỹ thuật. Với doanh nghiệp Việt Nam, doanh nghiệp FDI hoặc tổ chức vận hành hệ thống tại Việt Nam, đây còn là một công cụ để quản trị rủi ro, hỗ trợ đánh giá nhà cung cấp, chuẩn bị cho yêu cầu của khách hàng và kiểm chứng hiệu quả của các biện pháp bảo mật đang được áp dụng.

1. PENTEST là gì?

Theo cách định nghĩa của NIST, penetration testing là hoạt động kiểm tra mức độ một hệ thống, thiết bị hoặc quy trình có thể chống lại các nỗ lực chủ động nhằm xâm phạm an ninh của nó. NIST SP 800-115 cũng đặt PENTEST trong một quy trình rộng hơn gồm lập kế hoạch, thực hiện kiểm tra, phân tích phát hiện và xây dựng chiến lược giảm thiểu.

pentest-la-gi
PENTEST là gì?

Trong thực tế, đội kiểm thử sẽ sử dụng một số phương pháp và kỹ thuật tương tự kẻ tấn công, nhưng mọi hành động phải nằm trong phạm vi được doanh nghiệp cho phép.

Một chương trình PENTEST cần có ít nhất:

  • Văn bản hoặc thỏa thuận cho phép kiểm thử.

  • Danh sách tài sản nằm trong phạm vi.

  • Hệ thống và kỹ thuật bị loại trừ.

  • Thời gian bắt đầu và kết thúc.

  • Điều kiện dừng kiểm thử.

  • Đầu mối liên hệ khẩn cấp.

  • Quy định về thu thập, lưu trữ và xóa dữ liệu.

  • Cơ chế thông báo sớm nếu phát hiện rủi ro nghiêm trọng.

PENTEST không đồng nghĩa với việc cố gắng xâm nhập sâu nhất có thể. Chuyên gia kiểm thử chỉ cần tạo ra bằng chứng đủ để chứng minh rủi ro, tránh truy cập hoặc sao chép dữ liệu vượt quá mức cần thiết.

PENTEST không thể chứng minh điều gì?

PENTEST không chứng minh rằng hệ thống “an toàn tuyệt đối”.

Kết quả chỉ phản ánh:

  • Những tài sản nằm trong phạm vi.

  • Trạng thái hệ thống tại thời điểm kiểm thử.

  • Tài khoản và thông tin được cung cấp.

  • Kỹ thuật được phép thực hiện.

  • Thời lượng và nguồn lực của dự án.

PENTEST cũng không thay thế:

  • Quét lỗ hổng thường xuyên.

  • Quản lý bản vá.

  • Secure Software Development Life Cycle.

  • Giám sát SOC hoặc MDR.

  • Kiểm soát truy cập và quản trị danh tính.

  • Sao lưu và khôi phục sau thảm họa.

  • Điều tra và ứng phó sự cố.

  • Đánh giá tuân thủ toàn diện.

Sau một thay đổi lớn về ứng dụng, hạ tầng, Cloud hoặc quyền truy cập, kết quả PENTEST cũ có thể không còn phản ánh đầy đủ trạng thái hiện tại.

2. PENTEST khác quét lỗ hổng, đánh giá bảo mật và Red Team thế nào?

Các khái niệm này thường bị dùng thay thế cho nhau, trong khi mục tiêu và đầu ra rất khác biệt.

Hoạt động

Câu hỏi chính

Phương pháp

Đầu ra điển hình

Quét lỗ hổng

Hệ thống có dấu hiệu của lỗ hổng đã biết không?

Chủ yếu dùng công cụ tự động

Danh sách cảnh báo và tài sản liên quan

Đánh giá lỗ hổng

Lỗ hổng nào tồn tại và cần ưu tiên?

Công cụ kết hợp xác minh chuyên gia

Danh sách lỗ hổng đã phân tích

PENTEST

Điểm yếu có thể bị khai thác và gây tác động gì?

Mô phỏng tấn công có kiểm soát

Bằng chứng, đường tấn công và khuyến nghị

Security Audit

Hệ thống có đáp ứng tiêu chí hoặc chính sách không?

Rà soát tài liệu, cấu hình và kiểm soát

Khoảng cách so với yêu cầu

Red Team

Tổ chức có phát hiện và ngăn chặn một chiến dịch thực tế không?

Mô phỏng đối kháng trên phạm vi rộng

Kết quả về phòng thủ, phát hiện và phản ứng

Máy quét có thể phát hiện phần mềm lỗi thời, dịch vụ đang mở hoặc cấu hình có dấu hiệu không an toàn. Tuy nhiên, công cụ thường khó đánh giá đầy đủ lỗi logic nghiệp vụ, chuỗi tấn công hoặc tác động của lỗ hổng trong bối cảnh doanh nghiệp cụ thể.

PENTEST tiến thêm một bước bằng cách kiểm chứng khả năng khai thác.

Ví dụ, một lỗi phân quyền có thể cho phép người dùng của khách hàng A xem dữ liệu của khách hàng B. Lỗi này có thể không nổi bật trong kết quả quét tự động nhưng lại tạo ra rủi ro lớn về dữ liệu và hợp đồng.

Ngược lại, một cảnh báo có mức điểm kỹ thuật cao chưa chắc khai thác được nếu chức năng bị ảnh hưởng không được kích hoạt, hệ thống có biện pháp giảm thiểu hoặc tài sản không thể tiếp cận từ vị trí của kẻ tấn công.

Doanh nghiệp có thể xem phân tích chuyên sâu tại bài phân biệt kiểm thử xâm nhập và quét lỗ hổng bảo mật.

3. Doanh nghiệp có thể PENTEST những hệ thống nào?

Phạm vi PENTEST nên được xác định theo tài sản, dữ liệu và kịch bản rủi ro, không nên chỉ tính bằng số lượng địa chỉ IP hoặc URL.

3.1. Ứng dụng web

Web Application PENTEST đánh giá các vấn đề liên quan đến:

  • Xác thực và quản lý phiên.

  • Phân quyền.

  • Xử lý dữ liệu đầu vào.

  • Upload file.

  • Logic nghiệp vụ.

  • Giao dịch.

  • Tích hợp với dịch vụ bên thứ ba.

  • Khả năng truy cập dữ liệu trái phép.

OWASP Web Security Testing Guide là một trong những tài liệu tham khảo phổ biến cho kiểm thử ứng dụng web và dịch vụ web. OWASP duy trì riêng một phiên bản ổn định để các tổ chức và chuyên gia sử dụng làm khung kiểm thử.

3.2. API

API PENTEST đặc biệt phù hợp với nền tảng SaaS, ứng dụng di động, hệ thống tích hợp đối tác và kiến trúc microservices.

Phạm vi thường bao gồm:

  • Xác thực API.

  • Quản lý token.

  • Phân quyền theo đối tượng.

  • Phân quyền theo chức năng.

  • Giới hạn truy cập.

  • Kiểm soát dữ liệu trả về.

  • Logic giao dịch.

  • Khả năng lạm dụng chức năng tự động.

3.3. Ứng dụng di động

Mobile Application PENTEST có thể kiểm tra:

  • Dữ liệu lưu trên thiết bị.

  • Giao tiếp với API.

  • Quản lý phiên đăng nhập.

  • Bảo vệ thông tin xác thực.

  • Liên kết sâu.

  • Cơ chế cập nhật.

  • Khả năng can thiệp vào ứng dụng.

Doanh nghiệp có nhu cầu kiểm thử sản phẩm số có thể tham khảo dịch vụ kiểm thử xâm nhập cho ứng dụng web và di động.

3.4. Hạ tầng mạng bên ngoài

External Network PENTEST đánh giá những tài sản có thể được tiếp cận từ Internet như:

  • Máy chủ.

  • VPN.

  • Firewall.

  • Thiết bị mạng.

  • Cổng quản trị.

  • Dịch vụ remote access.

  • Hệ thống email hoặc cộng tác.

Mục tiêu là xác định một tác nhân bên ngoài có thể tìm thấy và khai thác đường truy cập nào trước khi có tài khoản nội bộ.

3.5. Mạng nội bộ và Active Directory

Internal PENTEST thường bắt đầu từ giả định rằng một tài khoản hoặc thiết bị trong mạng đã bị xâm nhập.

Đội kiểm thử sẽ đánh giá:

  • Phân đoạn mạng.

  • Mật khẩu và chính sách xác thực.

  • Tài khoản dịch vụ.

  • Quyền truy cập dư thừa.

  • Đường leo thang đặc quyền.

  • Khả năng di chuyển ngang.

  • Cấu hình Active Directory.

  • Khả năng tiếp cận máy chủ và dữ liệu quan trọng.

3.7. Môi trường Cloud

Cloud PENTEST không nên bị hiểu đơn giản là quét các máy chủ đặt trên AWS, Microsoft Azure hoặc Google Cloud.

Phạm vi có thể bao gồm:

  • Identity and Access Management.

  • Tài nguyên lưu trữ.

  • Security group và cấu hình mạng.

  • Secrets và access key.

  • Container và workload.

  • CI/CD.

  • Serverless.

  • Dịch vụ được quản lý.

  • Ranh giới trách nhiệm giữa khách hàng và nhà cung cấp Cloud.

Doanh nghiệp đang vận hành workload trên đám mây có thể xem thêm dịch vụ kiểm thử xâm nhập Cloud.

3.8. Hệ thống AI

Khi doanh nghiệp tích hợp AI agent, chatbot hoặc mô hình ngôn ngữ vào quy trình vận hành, phạm vi kiểm thử có thể phát sinh thêm:

  • Prompt injection.

  • Truy cập trái phép kho tri thức.

  • Lạm dụng công cụ được kết nối.

  • Rò rỉ dữ liệu qua output.

  • Quyền của AI agent.

  • Tương tác với API nội bộ.

  • Hành động tự động vượt ngoài mục tiêu ban đầu.

PENTEST hệ thống AI cần một phương pháp và tiêu chí đánh giá riêng, không thể chỉ áp dụng máy móc checklist của ứng dụng web truyền thống. Chủ đề này được trình bày chi tiết hơn trong bài PENTEST hệ thống AI.

Doanh nghiệp chưa biết nên kiểm thử phạm vi nào trước có thể sử dụng ma trận lựa chọn loại PENTEST.




4. Black-box, grey-box và white-box khác nhau thế nào?

Ba mô hình này mô tả lượng thông tin và quyền truy cập mà doanh nghiệp cung cấp cho đội PENTEST.

4.1. Black-box PENTEST

Đội kiểm thử nhận rất ít thông tin ban đầu và tiếp cận hệ thống gần giống một tác nhân bên ngoài.

Mô hình này phù hợp khi doanh nghiệp muốn đánh giá:

  • Bề mặt tấn công công khai.

  • Khả năng khám phá tài sản.

  • Rủi ro từ vị trí chưa có quyền truy cập.

  • Hiệu quả của lớp bảo vệ bên ngoài.

Hạn chế là một phần thời gian dự án sẽ được sử dụng cho việc tìm kiếm thông tin và xác định tài sản.

4.2. Grey-box PENTEST

Đội kiểm thử được cung cấp một phần thông tin hoặc tài khoản theo vai trò.

Grey-box phù hợp với:

  • Kiểm tra phân quyền.

  • Logic nghiệp vụ.

  • Cổng khách hàng.

  • Nền tảng SaaS.

  • Ứng dụng có nhiều loại người dùng.

  • API yêu cầu xác thực.

Đây thường là phương án cân bằng giữa tính thực tế và độ bao phủ.

4.3. White-box PENTEST

Đội kiểm thử được cung cấp nhiều thông tin hơn, có thể bao gồm:

  • Tài liệu kiến trúc.

  • Tài khoản theo nhiều vai trò.

  • Sơ đồ luồng dữ liệu.

  • Cấu hình.

  • Mã nguồn hoặc tài liệu API.

White-box giúp chuyên gia tập trung vào chiều sâu thay vì sử dụng phần lớn thời gian để tái khám phá những thông tin doanh nghiệp đã biết.

Không có mô hình nào luôn tốt hơn. Lựa chọn phải xuất phát từ câu hỏi doanh nghiệp muốn trả lời.

5. Quy trình PENTEST được thực hiện như thế nào?

5.1. Xác định mục tiêu kinh doanh

Mục tiêu không nên dừng ở câu “tìm lỗ hổng”.

Doanh nghiệp cần xác định rõ:

  • Muốn bảo vệ tài sản nào?

  • Lo ngại kịch bản tấn công nào?

  • Cần kiểm chứng trước sự kiện gì?

  • Kết quả sẽ được dùng cho kỹ thuật, quản trị hay yêu cầu khách hàng?

Ví dụ, mục tiêu có thể là kiểm tra khả năng truy cập trái phép dữ liệu khách hàng, đánh giá đường leo thang đặc quyền hoặc xác minh mức độ an toàn trước khi đưa một nền tảng mới vào vận hành.

5.2. Xác định phạm vi

Phạm vi có thể gồm:

  • Tên miền.

  • Địa chỉ IP.

  • Ứng dụng.

  • API.

  • Tài khoản thử nghiệm.

  • Mobile app.

  • Cloud subscription.

  • Active Directory domain.

  • Phân đoạn mạng.

Doanh nghiệp cũng phải ghi rõ những tài sản bị loại trừ.

5.3. Thống nhất Rules of Engagement

Rules of Engagement là tập hợp các quy tắc kiểm soát hoạt động PENTEST.

Nội dung nên bao gồm:

  • Thời gian kiểm thử.

  • Kỹ thuật được phép.

  • Kỹ thuật bị cấm.

  • Giới hạn khai thác.

  • Quy định kiểm thử production.

  • Điều kiện dừng.

  • Kênh liên hệ khẩn cấp.

  • Cách xử lý dữ liệu.

  • Cơ chế thông báo phát hiện nghiêm trọng.

Đây là một yêu cầu đặc biệt quan trọng đối với doanh nghiệp FDI, nơi việc phê duyệt PENTEST có thể liên quan đồng thời đến trụ sở tập đoàn, đội IT tại Việt Nam, nhà cung cấp Cloud và chủ sở hữu ứng dụng ở quốc gia khác.

5.4. Chuẩn bị đầu vào

Tùy mô hình kiểm thử, doanh nghiệp có thể cần cung cấp:

  • Danh sách tài sản.

  • Chủ sở hữu từng hệ thống.

  • Tài khoản theo vai trò.

  • Tài liệu API.

  • Kiến trúc hoặc luồng dữ liệu.

  • Danh sách IP được phép.

  • Môi trường staging hoặc production.

  • Lịch bảo trì.

  • Hệ thống giám sát liên quan.

  • Đầu mối phản ứng khẩn cấp.

Checklist chuẩn bị kiểm thử xâm nhập giúp đội IT hạn chế các vấn đề như thiếu tài khoản, sai phạm vi hoặc trì hoãn lịch kiểm thử.

5.5. Thu thập thông tin và lập bản đồ bề mặt tấn công

Đội PENTEST xác định các thành phần, dịch vụ, vai trò người dùng và luồng dữ liệu liên quan đến mục tiêu.

5.6. Phát hiện và xác minh điểm yếu

Công cụ tự động có thể được sử dụng để tăng độ bao phủ, nhưng kết quả phải được chuyên gia phân tích.

Các lỗi logic, phân quyền và chuỗi tấn công thường cần kiểm thử thủ công.

5.7. Khai thác có kiểm soát

Chuyên gia tạo bằng chứng đủ để xác nhận rủi ro mà không tiếp tục truy cập sâu hơn mức cần thiết.

Nếu phát hiện có nguy cơ gây ảnh hưởng nghiêm trọng, đội kiểm thử cần sử dụng kênh thông báo đã thống nhất thay vì chờ đến báo cáo cuối kỳ.

5.8. Phân tích tác động

Mỗi phát hiện cần được đặt trong bối cảnh:

  • Tài sản bị ảnh hưởng.

  • Quyền truy cập cần thiết.

  • Khả năng tái hiện.

  • Dữ liệu liên quan.

  • Chuỗi tấn công.

  • Tác động vận hành.

  • Tác động đến khách hàng và hợp đồng.

5.9. Báo cáo

Báo cáo phải phục vụ đồng thời hai nhóm:

  • Người quản lý cần hiểu rủi ro và mức độ ưu tiên.

  • Đội kỹ thuật cần đủ thông tin để tái hiện và khắc phục.

5.10. Khắc phục và retest

Retest xác nhận rằng biện pháp sửa lỗi:

  • Đã giải quyết đúng nguyên nhân.

  • Không chỉ che dấu triệu chứng.

  • Không tạo thêm lỗ hổng mới.

  • Có hiệu quả trong môi trường thực tế.

6. Báo cáo PENTEST cần có gì?

Một báo cáo chất lượng không được đo bằng số trang hoặc số lượng lỗ hổng.

Báo cáo nên bao gồm:

  • Executive summary.

  • Mục tiêu kiểm thử.

  • Phạm vi và giới hạn.

  • Thời gian thực hiện.

  • Phương pháp.

  • Danh sách phát hiện đã xác minh.

  • Điều kiện khai thác.

  • Bằng chứng phù hợp.

  • Tài sản và dữ liệu bị ảnh hưởng.

  • Chuỗi tấn công nếu có.

  • Mức độ rủi ro và cơ sở đánh giá.

  • Khuyến nghị khắc phục.

  • Trạng thái sau retest.

Báo cáo cũng cần phân biệt:

  • Lỗ hổng đã được khai thác.

  • Điểm yếu có khả năng khai thác nhưng không được phép kiểm thử sâu hơn.

  • Cảnh báo chưa thể xác minh.

  • Hạn chế do phạm vi hoặc thời gian.

Sau khi nhận báo cáo, doanh nghiệp có thể tham khảo cách đọc báo cáo PENTEST và khắc phục lỗ hổng.

Đánh giá một đợt PENTEST thành công bằng tiêu chí nào?

Không nên đánh giá dự án bằng việc nhà cung cấp tìm được bao nhiêu lỗ hổng.

Các tiêu chí phù hợp hơn gồm:

  • Phạm vi được thực hiện đúng cam kết.

  • Phát hiện có thể tái hiện.

  • Bằng chứng đủ rõ nhưng không thu thập dữ liệu quá mức.

  • Rủi ro được gắn với tài sản và tác động kinh doanh.

  • Đội kỹ thuật hiểu cách khắc phục.

  • Các phát hiện nghiêm trọng được ưu tiên.

  • Retest xác nhận hiệu quả sửa lỗi.

  • Bài học được đưa trở lại quy trình phát triển và vận hành.

Doanh nghiệp có thể tham khảo thêm hướng dẫn khắc phục lỗ hổng từ báo cáo kiểm thử xâm nhập.

7. Pháp luật Việt Nam có bắt buộc doanh nghiệp PENTEST không?

Không nên khẳng định rằng mọi doanh nghiệp tại Việt Nam đều bắt buộc phải thực hiện PENTEST theo một chu kỳ giống nhau.

Nghĩa vụ cụ thể còn phụ thuộc vào:

  • Loại hình tổ chức.

  • Hệ thống đang vận hành.

  • Cấp độ của hệ thống thông tin.

  • Ngành nghề.

  • Loại dữ liệu được xử lý.

  • Yêu cầu của cơ quan quản lý.

  • Hợp đồng với khách hàng.

  • Tiêu chuẩn mà doanh nghiệp cam kết áp dụng.

Tuy nhiên, bối cảnh pháp lý năm 2026 làm cho việc kiểm chứng hiệu quả bảo mật trở nên đáng chú ý hơn.

Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 có hiệu lực từ ngày 1/1/2026. Chính phủ đồng thời ban hành Nghị định 356/2025/NĐ-CP để quy định chi tiết một số điều và biện pháp thi hành Luật.

Luật An ninh mạng số 116/2025/QH15 được ban hành ngày 10/12/2025 và có hiệu lực từ ngày 1/7/2026.

Đối với hệ thống thuộc phạm vi bảo đảm an toàn hệ thống thông tin theo cấp độ, Thông tư 12/2022/TT-BTTTT quy định chi tiết và hướng dẫn một số nội dung của Nghị định 85/2016/NĐ-CP. Chỉ thị 09/CT-TTg ngày 23/2/2024 tiếp tục yêu cầu tăng cường tuân thủ các quy định về an toàn hệ thống thông tin theo cấp độ.

Các văn bản này không nên được diễn giải thành một tuyên bố đơn giản rằng “doanh nghiệp nào cũng phải PENTEST”. PENTEST là một trong những phương pháp kỹ thuật có thể hỗ trợ doanh nghiệp:

  • Kiểm chứng một số biện pháp bảo vệ.

  • Xác định điểm yếu có khả năng ảnh hưởng đến dữ liệu.

  • Tạo bằng chứng cho hoạt động quản trị rủi ro.

  • Hỗ trợ đánh giá trước khi kết nối hoặc đưa hệ thống vào vận hành.

  • Chuẩn bị cho đánh giá của khách hàng, tập đoàn hoặc cơ quan có thẩm quyền.

Doanh nghiệp cần đối chiếu nghĩa vụ với tư vấn pháp lý, yêu cầu ngành và phạm vi hệ thống cụ thể.

8. Doanh nghiệp FDI cần lưu ý gì khi PENTEST tại Việt Nam?

Doanh nghiệp FDI thường có môi trường phức tạp hơn do tài sản, dữ liệu và trách nhiệm được phân bổ giữa nhiều quốc gia.

Trước khi kiểm thử, doanh nghiệp nên làm rõ:

8.1. Quyền phê duyệt

Đội IT tại Việt Nam chưa chắc là chủ sở hữu cuối cùng của hệ thống. Việc PENTEST có thể cần phê duyệt từ:

  • Trụ sở tập đoàn.

  • Chủ sở hữu ứng dụng.

  • Đội Cloud toàn cầu.

  • Đội bảo mật khu vực.

  • Nhà cung cấp dịch vụ.

  • Khách hàng sở hữu dữ liệu.

8.2. Vị trí tài sản và dữ liệu

Ứng dụng được vận hành tại Việt Nam nhưng dữ liệu có thể nằm ở khu vực khác. Ngược lại, ứng dụng do tập đoàn quản lý ở nước ngoài có thể xử lý dữ liệu của nhân viên hoặc khách hàng tại Việt Nam.

Scope cần xác định rõ:

  • Hệ thống nằm ở đâu.

  • Dữ liệu nào có thể xuất hiện trong bằng chứng.

  • Ai được phép tiếp cận báo cáo.

  • Báo cáo và dữ liệu kiểm thử được lưu ở đâu.

  • Thời gian lưu trữ.

  • Quy trình xóa dữ liệu sau dự án.

8.3. Ngôn ngữ báo cáo

Doanh nghiệp FDI có thể cần:

  • Báo cáo kỹ thuật bằng tiếng Anh.

  • Executive summary bằng tiếng Việt.

  • Bảng theo dõi remediation dùng chung.

  • Phân loại rủi ro phù hợp với framework của tập đoàn.

  • Buổi trình bày cho cả đội Việt Nam và đội khu vực.

8.4. Production và múi giờ

Hoạt động kiểm thử có thể ảnh hưởng người dùng ở nhiều quốc gia. Rules of Engagement cần ghi rõ múi giờ, maintenance window và quy trình escalation.

8.5. Nhà cung cấp Cloud và bên thứ ba

Một số nhà cung cấp có chính sách riêng đối với security testing. Doanh nghiệp phải kiểm tra điều khoản dịch vụ và trách nhiệm hợp đồng trước khi bắt đầu.

9. Khi nào doanh nghiệp nên PENTEST?

Các thời điểm thường cần cân nhắc gồm:

  • Trước khi đưa ứng dụng quan trọng vào vận hành.

  • Trước khi mở hệ thống cho khách hàng hoặc đối tác.

  • Sau thay đổi lớn về kiến trúc.

  • Sau khi triển khai API mới.

  • Sau khi di chuyển lên Cloud.

  • Sau thay đổi lớn về Active Directory hoặc Identity.

  • Sau sáp nhập và kết nối hai môi trường mạng.

  • Sau sự cố an ninh mạng.

  • Trước yêu cầu đánh giá của khách hàng.

  • Theo yêu cầu hợp đồng hoặc tiêu chuẩn.

  • Sau khi khắc phục lỗ hổng nghiêm trọng.

  • Khi xuất hiện lỗ hổng mới liên quan trực tiếp đến công nghệ đang sử dụng.

CISA duy trì Known Exploited Vulnerabilities Catalog để giúp tổ chức ưu tiên các lỗ hổng có bằng chứng bị khai thác trong thực tế. Việc một lỗ hổng được khai thác ngoài thực tế cho thấy đánh giá rủi ro không nên chỉ dựa trên điểm số lý thuyết; doanh nghiệp cần xem xét tài sản có bị ảnh hưởng, có thể tiếp cận và đã có biện pháp giảm thiểu hay chưa.

Đối với doanh nghiệp phát hành phần mềm thường xuyên, một đợt PENTEST duy nhất mỗi năm có thể không đủ. PENTEST nên gắn với các thay đổi có rủi ro cao, trong khi quét lỗ hổng và kiểm tra bảo mật tự động được thực hiện thường xuyên hơn.

10. Chi phí PENTEST phụ thuộc vào yếu tố nào?

Chi phí PENTEST thường phụ thuộc vào:

  • Loại hệ thống.

  • Số lượng tài sản.

  • Số vai trò người dùng.

  • Số API hoặc luồng nghiệp vụ.

  • Black-box, grey-box hay white-box.

  • Mức độ phức tạp của kiến trúc.

  • Môi trường production hay staging.

  • Thời gian kiểm thử.

  • Yêu cầu báo cáo.

  • Số vòng retest.

  • Yêu cầu làm việc ngoài giờ.

  • Ngôn ngữ và yêu cầu phối hợp quốc tế.

Hai ứng dụng có cùng số URL có thể cần khối lượng công việc rất khác nhau. Một nền tảng SaaS có nhiều tenant, vai trò và luồng thanh toán thường cần kiểm thử sâu hơn một website giới thiệu doanh nghiệp.

Do đó, báo giá chỉ dựa trên số IP hoặc số URL có thể không phản ánh đúng rủi ro.

Doanh nghiệp đang lập ngân sách có thể tham khảo bài chi phí PENTEST định kỳ.

11. Cách lựa chọn đơn vị PENTEST tại Việt Nam

Doanh nghiệp nên đánh giá nhà cung cấp từ giai đoạn xác định phạm vi, không chỉ dựa vào báo cáo mẫu hoặc chứng chỉ.

Các câu hỏi cần đặt ra gồm:

  • Nhà cung cấp có hỏi về mục tiêu kinh doanh không?

  • Có kinh nghiệm với loại tài sản cần kiểm thử không?

  • Phạm vi có nêu rõ phần bao gồm và loại trừ không?

  • Rules of Engagement có đầy đủ không?

  • Dữ liệu kiểm thử được bảo vệ như thế nào?

  • Ai được tiếp cận bằng chứng?

  • Báo cáo có phân biệt cảnh báo công cụ với phát hiện đã xác minh không?

  • Khuyến nghị có phù hợp với kiến trúc thực tế không?

  • Có buổi trình bày kỹ thuật không?

  • Retest có được bao gồm không?

  • Có thể cung cấp báo cáo song ngữ không?

  • Có khả năng phối hợp với đội IT nước ngoài không?

  • Quy trình xử lý xung đột hoặc sự cố trong thời gian kiểm thử là gì?

Không nên chọn nhà cung cấp dựa trên cam kết “tìm được nhiều lỗ hổng nhất”.

Một báo cáo chứa hàng trăm cảnh báo tự động nhưng không xác minh tác động có thể gây tốn thời gian hơn một báo cáo ngắn, tập trung vào những đường tấn công thực sự quan trọng.

Kết luận

PENTEST giúp doanh nghiệp chuyển từ câu hỏi “Hệ thống có lỗ hổng không?” sang câu hỏi thiết thực hơn:

Điểm yếu nào có thể bị khai thác, tài sản nào sẽ bị ảnh hưởng và chúng ta cần xử lý điều gì trước?

Một chương trình đánh giá xâm nhập hệ thống hiệu quả cần:

  • Bắt đầu từ rủi ro kinh doanh.

  • Xác định phạm vi rõ ràng.

  • Có văn bản cho phép và Rules of Engagement.

  • Kết hợp công cụ với kiểm thử thủ công.

  • Kiểm soát dữ liệu trong suốt dự án.

  • Báo cáo được cho cả quản lý và kỹ thuật.

  • Có kế hoạch remediation.

  • Retest sau khắc phục.

Đối với doanh nghiệp Việt Nam và doanh nghiệp FDI, phạm vi PENTEST còn phải phù hợp với cơ cấu phê duyệt, vị trí dữ liệu, hợp đồng, chính sách của tập đoàn và khung pháp lý đang áp dụng tại Việt Nam.

IPSIP cung cấp dịch vụ PENTEST và đánh giá xâm nhập hệ thống cho ứng dụng web, API, ứng dụng di động, Cloud và hạ tầng doanh nghiệp. Phạm vi được xây dựng theo tài sản, kịch bản rủi ro và mục tiêu thực tế thay vì áp dụng một checklist giống nhau cho mọi hệ thống.

-------

Câu hỏi thường gặp

PENTEST có làm gián đoạn hệ thống không?

PENTEST có thể tạo rủi ro vận hành nếu được thực hiện trên production. Doanh nghiệp cần kiểm soát bằng phạm vi, maintenance window, điều kiện dừng, giám sát và kênh liên hệ khẩn cấp. Các kỹ thuật có nguy cơ gây gián đoạn không nên được thực hiện nếu chưa có phê duyệt rõ ràng.

Không. Quét lỗ hổng phù hợp với giám sát thường xuyên và độ bao phủ rộng. PENTEST tập trung vào xác minh khả năng khai thác, lỗi logic và chuỗi tấn công. Hai hoạt động bổ trợ cho nhau.

Tần suất phụ thuộc vào mức độ quan trọng của tài sản, tốc độ thay đổi, mức độ tiếp xúc Internet, yêu cầu khách hàng và kết quả kiểm thử trước. Ngoài lịch định kỳ, doanh nghiệp nên PENTEST sau những thay đổi lớn có ảnh hưởng đến bảo mật.

Có, đặc biệt với phát hiện nghiêm trọng. Retest giúp xác nhận biện pháp sửa lỗi đã giải quyết đúng nguyên nhân và không tạo ra điểm yếu mới.

-----------------

Nguồn tham khảo

Bình luận

theo dõi ipsip việt nam trên google news.png
conact-ipsip-vietnam
zalo
đặt lịch hẹn
bottom of page