Prompting cho Security Analysis & Threat Modeling: Tạo Threat Scenarios và Mitigation Suggestions

Prompting cho Phân tích Bảo mật & Mô hình Đe dọa: Cách anh Hải “Security” làm sạch hệ thống trước khi code một dòng

Giới thiệu: Tại sao cần “Prompt” trước khi viết code?

🛡️ Lỗi bảo mật không phải lỗi runtime – nó là lỗi thiết kế.
Hàng năm, báo cáo từ OWASP Top 10 chứng minh: 85% lỗ hổng bắt nguồn từ giai đoạn thiết kế và yêu cầu. Khi mình xây hệ thống xử lý 10.000 người dùng/giây hay xử lý dữ liệu 50GB, việc phân tích rủi ro trước không chỉ là tốt – đó là yêu cầu bắt buộc để tránh bị “đánh mặt” sau này.

Tôi sẽ hướng dẫn cách dùng Prompting như một công cụ đi trước code, giúp phát hiện điểm yếu trước khi viết một dòng code nào cả.

Use Case Kỹ thuật 1: Hệ thống API xử lý thanh toán tại tỷ lệ 15.000 RPS

Kịch bản:

Hệ thống payment API xây trên Node.js 20, sử dụng Redis 7.4 cho session và PostgreSQL 16 cho giao dịch. Truy vấn DB có index đầy đủ, nhưng chưa có cơ chế rate limiting.

Bước 1: Xây dựng Prompt phân tích rủi ro

# Ví dụ prompt cho LLM (ví dụ: Gemini/Pro)
prompt = """
Phân tích rủi ro cho hệ thống API thanh toán với các thông số:
- Ngôn ngữ: Node.js 20
- Cơ sở dữ liệu: PostgreSQL 16 + Redis 7.4
- Tỷ lệ chuyển tiếp: 15.000 yêu cầu/giây
- Tính năng chính: Xác thực thanh toán qua thẻ, cập nhật tài khoản người dùng

Liệt kê theo phương pháp STRIDE:
1. **S**poofing: Ai có thể giả mạo người dùng?
2. **T**ampering: Dữ liệu truyền được chỉnh sửa được không?
3. **R**epudiation: Giao dịch có thể bị từ chối sau này không?
4. **I**nformation Disclosure: Thông tin nhạy cảm lộ ra ngoài?
5. **D**DoS: Ai có thể làm hệ thống không hoạt động?
6. **E**levation of Privilege: Kẻ tấn công có thể tăng quyền hạn?

Với mỗi rủi ro, đề xuất giải pháp kỹ thuật cụ thể (ví dụ: code snippet, cấu hình).
"""

Kết quả phân tích từ Prompt

⚠️ Cảnh báo quan trọng:
Luôn kiểm tra secret key trong .env, không để cứng trong code. Sử dụng dotenv để load biến môi trường.

Use Case Kỹ thuật 2: Xử lý Dữ liệu Big Data 50GB trên AWS

Kịch bản:

Hệ thống ETL sử dụng Python 3.12, đọc file CSV 50GB từ S3, xử lý bằng Pandas, lưu kết quả vào Redshift. Không có cơ chế mã hóa dữ liệu khi chuyển tiếp.

Prompt Phân tích cho Kịch bản này

prompt = """
Phân tích rủi ro cho pipeline ETL xử lý file 50GB trên AWS:
- Ngôn ngữ: Python 3.12
- Thư viện: Pandas, Boto3
- Dịch vụ: S3, Redshift
- Quy trình: Đọc file CSV -> Xử lý -> Lưu vào Redshift

Theo phương pháp DREAD, đánh giá:
- **D**amage Potential: Thiệt hại nếu dữ liệu lộ?
- **R**eproducibility: Dễ tái sản xuất lỗi không?
- **E**xploitability: Kẻ tấn công cần công cụ gì?
- **A**ffected: Ai bị ảnh hưởng?
- **D**iscoverability: Dễ phát hiện không?

Đề xuất giải pháp mã hóa dữ liệu trong quá trình chuyển tiếp.
"""

Giải pháp từ Prompt

Mã hóa dữ liệu khi chuyển từ S3 → Redshift:

# Sử dụng AWS KMS + SSL
import boto3
from botocore.exceptions import ClientError

def copy_file_with_encryption(bucket, key, table):
    client = boto3.client('redshift-data', region_name='us-east-1')
    try:
        # Tạo statement mã hóa
        response = client.execute_statement(
            Database='analytics',
            DbUser='admin',
            Sql=f"""
                COPY {table}
                FROM 's3://{bucket}/{key}'
                CREDENTIALS 'aws_access_key_id={AWS_ACCESS_KEY};aws_secret_access_key={AWS_SECRET_KEY}'
                ENCRYPTION 'SSE-KMS'
                SSL 'TRUE'
            """,
            WithEvent=True
        )
        return response
    except ClientError as e:
        logger.error(f"Lỗi mã hóa: {e}")
        raise

💡 Ghi chú:
SSE-KMS (Server-Side Encryption với AWS Key Management Service) đảm bảo dữ liệu được mã hóa trên server trước khi truyền đi.

Bảng So sánh: Công cụ Phân tích Rủi ro Tự động vs Thủ công

Nguồn:
GitHub Octoverse 2024: “AI Security Tooling Adoption Rate”

Công thức Tính Đánh giá Rủi ro

(A) Công thức tiếng Việt không dùng LaTeX
Rủi ro = (Độ nghiêm trọng của Lỗ hổng) × (Khả năng khai thác) × (Giá trị tài sản)

(B) Công thức LaTeX bằng tiếng Anh hoàn toàn

Giải thích tiếng Việt:
Công thức này giúp đánh giá mức độ ưu tiên xử lý rủi ro. Ví dụ:
– Severity = 9 (Lộ toàn bộ dữ liệu khách hàng)
– Exploitability = 3 (Cần công cụ chuyên dụng)
– Asset Value = 10 (Dữ liệu khách hàng là tài sản cốt lõi)
→ Risk = 9 × 3 × 10 = 270 (Rủi ro cao cần xử lý ngay)

3 Bước Triển khai Prompting cho Security Analysis

1. Xây dựng Prompt Chi tiết
   • Mô tả kỹ hệ thống (ngôn ngữ, dịch vụ, luồng dữ liệu).
   • Chọn phương pháp phân tích (STRIDE/DREAD).
   • Yêu cầu giải pháp kèm code snippet.
2. Chạy Prompt và Phân tích Kết quả
   • Sử dụng LLM có chuyên môn bảo mật (ví dụ: Microsoft Sentinel, AWS GuardDuty).
   • Kiểm tra tính hợp lý của giải pháp đề xuất.
3. Tích hợp vào Pipeline CI/CD

   # Ví dụ trong GitHub Actions
   name: Security Analysis
   on: [push]
   jobs:
    security-scan:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - name: Chạy Prompt Security
          run: |
            python security_prompt.py --use-case payment-api
   

Key Takeaways

1. Prompt là “bộ lọc” đầu tiên để loại bỏ rủi ro thiết kế trước khi code.
2. Mã hóa dữ liệu luôn là giải pháp bắt buộc khi xử lý thông tin nhạy cảm.
3. Tích hợp phân tích rủi ro vào CI/CD giúp phát hiện lỗ hổng sớm, giảm chi phí sửa lỗi.

Câu hỏi thảo luận

Anh em đã từng gặp lỗi SQL Injection hay SSRF trong dự án chưa? Giải quyết thế nào?

Gợi ý công cụ

Nếu anh em đang cần tự động hóa quy trình phân tích bảo mật, thử ngó qua Serimi App – API tích hợp sẵn các mô hình LLM cho security scanning, khá ổn cho việc scale.