1. 보안 평가 및 테스트 전략

보안평가 및 보안운영 기본

보안 평가 및 테스트 전략 — 범위·우선순위·리포트까지

평가를 “운영 가능한 개선 사이클”로 만드는 실무 정리입니다.

형태 운영 템플릿초점 Risk-based산출물 리포트·재검증

왜 ‘전략’부터 잡아야 하나요?

보안 평가는 무엇을 얼마나 깊게 볼지(범위), 어떤 위험을 먼저 줄일지(우선순위), 어떻게 안전하게 수행할지(안전장치)를 먼저 결정해야 합니다. 그렇지 않으면 결과가 좋아 보여도, 실제 운영 리스크는 그대로 남는 경우가 많습니다.

실무 관점 핵심

테스트는 ‘취약점 찾기’만이 아니라, 운영 가능한 개선 사항(조치·재검증·추적성)들을 확인하는 활동입니다.

범위/승인/실행/리포트/재검증으로 이어지는 평가 사이클 (PNG)

테스트 유형을 이렇게 나누면 덜 헷갈립니다

유형	목적	산출물	권장 주기
기술 점검(스캔/진단)	노출/기본 취약점 빠르게 탐지	리스트 + 우선순위	주/월
설정/구성 점검	기준선 대비 오탈자·취약 설정 탐지	차이(diff) + 수정안	변경 시/월
침투 테스트	공격 관점에서 ‘실제 악용 가능성’ 확인	재현 절차 + 영향도	분기/반기
테이블탑/시뮬레이션	대응 체계(사람·프로세스) 점검	개선 과제 목록	분기

범위 정의(Scorping)에서 반드시 적어야 할 것

• 대상: 시스템/서비스/망 구간, 주요 데이터(개인정보·계정·결제 등)
• 제외: 테스트 금지 자산, 운영 중단 우려 구간
• 시간: 테스트 윈도우(야간/주말), 사전 공지/연락체계
• 안전장치: 트래픽 한도, 계정 권한, 롤백, 장애 발생 시 즉시 중단 기준

‘보고서’가 운영에 먹히려면

• 증거: 스크린샷/로그/재현 명령 등
• 재현 가능: 단계별 절차(운영자가 따라 할 수 있게)
• 조치안: 단기 완화(워크어라운드) + 근본 조치(설정/코드/정책)
• 재검증: 수정 후 동일 조건으로 다시 확인(‘닫힘’의 근거)

예시: 테스트 계획을 ‘설정 파일’처럼 관리하기

문서로만 두지 말고, YAML/JSON 등으로 남겨두면 재현과 변경 이력이 쉬워집니다.

# security_test_plan.yaml (예시)
scope:
  in:
    - "public-web"
    - "vpn-gateway"
  out:
    - "production-db"   # 운영 중단 우려로 제외
safety:
  rate_limit_rps: 5
  stop_on:
    - "cpu_load_gt_80pct"
    - "error_rate_spike"
report:
  severity_model: "CVSS+업무영향"
  include:
    - "evidence"
    - "repro_steps"
    - "fix_recommendations"

운영자 체크리스트

• 테스트 전: 대상/금지구간/연락체계/중단기준이 문서로 합의되어 있나요?
• 테스트 중: 변경/트래픽 영향이 관측 가능한 모니터링이 준비되어 있나요?
• 테스트 후: 조치 담당/기한/재검증 일정이 티켓으로 남아 있나요?

 

참고 레퍼런스

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• NIST SP 800-53A Rev.5 — Assessing Security and Privacy Controls
• OWASP WSTG — Web Security Testing Guide
• CIS Benchmarks