Quy trình pentest tại Trustline: Từ xác định phạm vi đến re-test

Khách hàng không chỉ mua số ngày pentester gõ bàn phím. Họ mua một quy trình biến phạm vi mơ hồ thành bằng chứng có kiểm soát, rồi biến bằng chứng thành backlog khắc phục có thể xác minh. Đây là cách Trustline vận hành một engagement pentest B2B từ đầu đến cuối.

Giai đoạn 1: Scoping theo rủi ro

Chúng tôi làm rõ tài sản, môi trường, vai trò, tenant, workflow, tích hợp, loại dữ liệu và mốc kinh doanh. Một domain có thể là brochure tĩnh hoặc chứa hàng chục luồng thanh toán và quyền admin; vì vậy số URL một mình không đủ để ước lượng effort.

• Mục tiêu kinh doanh: go-live, assurance cho khách hàng, kiểm tra thay đổi lớn hay xác minh sau sự cố.
• Attack surface: web, API, mobile, cloud, external infrastructure hoặc tổ hợp có quan hệ.
• Vai trò và workflow: user, manager, admin, support, tenant khác nhau và các luồng giá trị cao.
• Giới hạn: production hay staging, hành vi cấm, third-party service và dữ liệu không được chạm.
• Đầu ra: báo cáo kỹ thuật, executive summary, workshop, re-test và bằng chứng bổ sung theo nhu cầu khách hàng.

Giai đoạn 2: Kickoff và Rules of Engagement

Trước khi gửi request đầu tiên, hai bên xác nhận người liên hệ, nguồn IP, khung giờ, tài khoản, dữ liệu mẫu, hành vi được phép và cơ chế dừng. Với production, ngưỡng an toàn được đặt chặt hơn; stress test, DoS, social engineering hoặc truy cập dữ liệu thật không tự động nằm trong phạm vi.

Giai đoạn 3: Reconnaissance và kiểm thử có chiều sâu

Automation được dùng để tăng độ phủ cho inventory, header, dependency và dấu hiệu phổ biến. Phần quyết định chất lượng nằm ở kiểm thử thủ công: phân quyền, multi-tenant, logic nghiệp vụ, state transition, upload, integration, session, API object access và khả năng ghép nhiều điểm yếu thành một đường tấn công.

Pentester duy trì nhật ký bằng chứng và giả thuyết trong quá trình làm. Các phát hiện được xác minh để giảm false positive; khai thác chỉ đi đến mức đủ chứng minh tác động trong giới hạn đã thống nhất. Chúng tôi không lấy thêm dữ liệu chỉ để ảnh báo cáo trông kịch tính.

Giai đoạn 4: Báo critical sớm

Khi phát hiện nghiêm trọng đã đủ bằng chứng, Trustline gửi thông báo ngắn ngay: phạm vi bị ảnh hưởng, tác động, bằng chứng tối thiểu, biện pháp containment và bước tiếp theo. Báo cáo cuối vẫn phân tích đầy đủ, nhưng khách hàng không phải duy trì phơi nhiễm thêm nhiều ngày vì quy trình bàn giao cứng nhắc.

Giai đoạn 5: Báo cáo cho hai nhóm người đọc

• Executive summary: đường tấn công quan trọng, tài sản bị ảnh hưởng, chủ đề kiểm soát và quyết định cần ưu tiên.
• Technical findings: điều kiện, bước tái hiện, bằng chứng đã làm sạch, tác động, nguyên nhân và hướng khắc phục.
• Coverage và giới hạn: những gì đã kiểm, vai trò đã dùng, trở ngại và phần không thể kết luận.
• Remediation roadmap: sắp xếp theo risk reduction và dependency thay vì chỉ xếp theo điểm CVSS.

Giai đoạn 6: Workshop bàn giao

Workshop không phải buổi đọc lại PDF. Trustline đi qua các đường tấn công, trả lời câu hỏi của engineering, làm rõ điều kiện tái hiện và thảo luận phương án sửa phù hợp kiến trúc. Nếu một biện pháp lý tưởng chưa thể làm ngay, hai bên phân biệt containment ngắn hạn với remediation bền vững.

Giai đoạn 7: Re-test và đóng vòng

Re-test dùng lại điều kiện ban đầu và kiểm tra cả khả năng bypass, không chỉ xác nhận dòng code đã thay đổi. Trạng thái được cập nhật thành fixed, partially fixed hoặc unresolved kèm bằng chứng. Với thay đổi có tác động rộng, Trustline ghi rõ nếu cần regression test ngoài phạm vi re-test ban đầu.

Những điều Trustline không hứa

• Không hứa hệ thống “an toàn 100%” sau một engagement có giới hạn thời gian và phạm vi.
• Không đổi nhãn vulnerability scan thành penetration test.
• Không giấu giới hạn hoặc false negative risk để báo cáo trông chắc chắn hơn.
• Không giữ critical đến cuối dự án chỉ để tạo màn trình bày bất ngờ.
• Không upsell Red Team nếu bài toán hiện tại chỉ cần kiểm kê và đóng vệ sinh bảo mật cơ bản.