‘완벽한 보안은 없다’에 매몰되지 말자 — 정의하고 준비하면 ‘완벽’은 가능하다

By PLURA

한 줄 문구
“완벽은 선언이 아니라 증거다 — 문제를 정확히 정의하고 충분히 준비하면, 우리는 ‘완벽’을 운영할 수 있다.”

캠페인 선언 — Stop Fear Marketing in Security
이 글은 “완벽한 보안은 없다”는 식의 공포 마케팅을 멈추자는 문제의식에서 출발합니다.

“완벽한 보안은 없다”는 말은 경계심을 주지만,
현장에서는 종종 준비 부족과 실행 부족을 정당화하는 문장으로도 사용됩니다.

핵심은 “완벽”이라는 단어 자체가 아니라,
무엇을 지킬 것인지, 어떤 위협을 상정하는지, 어떤 수준을 달성해야 하는지, 그리고 그것을 무엇으로 입증할 것인지를 명확히 정의하는 것입니다.

이 글에서 말하는 ‘완벽’은
절대 무오류나 무한대의 안전을 뜻하지 않습니다.

명시된 범위와 위협 모델 안에서,
합의한 목표 수준(SLO)을 지속적으로 충족하고,
그 사실을 증거로 입증할 수 있는 상태
— 이것을 우리는 ‘정의된 완벽(Defined Perfection)’이라 부릅니다.

정의된 완벽

1) 왜 “완벽한 보안은 없다”가 반복될까? — 문제의 구조

이 말이 반복되는 데에는 분명한 이유가 있습니다.

복잡성

현대 시스템은
하드웨어 → OS → 런타임 → 라이브러리 → 클라우드 → 서드파티 → 공급망
으로 이어지는 다층 구조 위에 존재합니다.
상호의존성이 커질수록 리스크는 더 복잡해집니다.

인간 요소

피싱, 권한 남용, 절차 우회, 설정 실수, 운영 부주의 등
보안은 항상 사람의 영향을 받습니다.
기술만으로 모든 변수를 제거하기는 어렵습니다.

경제적 제약

보안은 언제나
일정, 예산, 인력, 레거시, 기술부채와의 타협 위에 놓입니다.
이 때문에 “이론적으로 가능하다”와 “현실적으로 운영 가능하다”는 다를 수 있습니다.

이론적 한계

일반 프로그램의 결함 0을 증명하는 문제나,
모든 악성 행위를 전 우주적 범위에서 완전 탐지하는 문제는
이론적으로도 한계가 있습니다.

하지만 이 말은
절대적이고 무한한 안전이 어렵다는 뜻일 뿐입니다.

그것이 곧
현실 세계의 특정 범위와 위협 모델 안에서
운영 가능한 완벽을 만들 수 없다는 뜻은 아닙니다.

2) 프레임 전환 — ‘정의된 완벽(Defined Perfection)’

보안에서 정말 필요한 것은
“완벽은 불가능하다”는 패배주의가 아니라,
완벽을 어떻게 정의하고 운영할 것인가에 대한 기준입니다.

정의

우리는 명시된 범위와 위협 모델에 대해,
합의한 SLO(목표 수준) 를 지속적으로 충족하고,
그 상태를 증거로 입증한다.
이 상태를 ‘완벽’이라 부른다.

이렇게 정의하면,

  • 구호가 운영 기준으로 바뀌고
  • “무엇이 완벽인가?”가 수치와 증거로 바뀌며
  • 책임과 기대가 명확한 언어로 정리됩니다.

즉, 완벽은 감정이 아니라
계약 가능한 상태,
운영 가능한 목표,
검증 가능한 결과가 됩니다.

3) 중요한 전제 — 정의된 완벽도 영원하지는 않다

여기서 반드시 분명히 해야 할 점이 있습니다.

정의된 완벽 역시 영구적인 상태는 아닙니다.

예를 들어,

  • 공급망 공격으로 전제가 달라지거나
  • 로그가 조작·삭제되거나
  • 새 자산이 범위 밖에서 추가되거나
  • 위협 모델 자체가 바뀌거나
  • 탐지 커버리지가 떨어지거나
  • 운영팀이 바뀌어 통제가 약화되면

기존에 선언한 ‘완벽’은 더 이상 유효하지 않을 수 있습니다.

즉, 완벽은 한 번 획득하면 끝나는 배지가 아닙니다.

완벽은 계속 검증되어야 하고,
기준에서 벗어나면 회수되어야 하는 운영 상태입니다.

이 점을 인정할 때,
‘완벽’은 위험한 슬로건이 아니라
오히려 가장 정직한 보안 운영 방식이 됩니다.

4) ‘완벽’을 가능하게 하는 5가지 요소

정의된 완벽은 추상적인 선언이 아니라,
다음 다섯 요소 위에서 운영됩니다.

1. 범위(Scope)

무엇에 대한 완벽인가?

  • 특정 서비스인가
  • 고객 개인정보 처리 경로인가
  • 클라우드 계정인가
  • 핵심 생산 시스템인가

완벽은 언제나 범위가 있어야 성립합니다.

2. 위협 모델(Threat Model)

누구의, 어느 수준의, 어떤 공격을 상정하는가?

  • 외부 공격자
  • 내부자
  • 계정 탈취
  • 원격 코드 실행
  • 공급망 위협
  • 랜섬웨어
  • 데이터 탈취

위협 모델이 없으면
완벽도 없습니다.

3. 목표 수준(SLO)과 금지되는 실패

어디까지를 “완벽”이라 부를 것인가?

  • 어떤 항목은 0건
  • 어떤 항목은 시간 기준
  • 어떤 항목은 커버리지 기준
  • 어떤 항목은 정밀도 기준

으로 정의해야 합니다.

4. 증거(Assurance Evidence)

정말 그 상태를 유지하고 있다는 근거는 무엇인가?

  • 로그
  • 테스트 결과
  • 탐지 시나리오
  • 자동화 이력
  • 리허설 결과
  • 감사 기록
  • 제3자 평가

완벽은 주장으로 유지되지 않습니다.
증거로만 유지됩니다.

5. 유효기간과 회수 트리거

언제까지 유효하며, 어떤 경우에 회수되는가?

예를 들어,

  • SLO 미충족
  • 커버리지 저하
  • 미검증 변경 발생
  • 로그 공백 발생
  • 핵심 통제 비활성화

와 같은 조건이 발생하면,
‘완벽’ 상태는 자동 회수되어야 합니다.

5) 현실적으로 강한 SLO 예시

“완벽”을 운영하려면
숫자가 필요합니다.
다음은 현실적으로 강한 SLO 예시입니다.

예방(Prevent)

  • 인터넷 노출 CVSS 9.0+ 취약점 MTTR ≤ 72시간
  • 특권 계정 100% MFA
  • 하드코딩 시크릿 0건

탐지(Detect)

  • 핵심 ATT&CK 전술 탐지 시나리오 커버리지 ≥ 90%
  • P1 경보 정밀도 ≥ 80%
  • 평균 경보 지연 ≤ 5분

대응(Respond)

  • P1 MTTD ≤ 15분
  • P1 MTTR ≤ 2시간
  • 격리·차단 자동화율 ≥ 70%

복구(Recover)

  • RTO ≤ 4시간
  • RPO ≤ 15분
  • 분기 1회 복구 리허설
  • 백업 무결성 점검 주기 ≤ 7일

팁:
“0건” 목표는 제한된 영역에만 사용하는 것이 좋습니다.
예를 들어 무단 외부 공개, 특권 계정 비인가 사용, 하드코딩 시크릿 같은 영역입니다.
나머지는 탐지·대응·복구 SLO로 관리하는 것이 현실적이고 강력합니다.

6) ‘완벽 선언 카드’ 템플릿

아래 템플릿은
‘완벽’을 추상 명사가 아니라 운영 문서로 바꾸기 위한 최소 단위입니다.

[시스템/제품명] 보안 ‘완벽’ 선언 (vYYYY.MM.DD)

1. 범위:
   - 예: 고객 PII 저장·처리 경로(ingest → store → export)

2. 위협 모델:
   - 외부 공격자(원격 RCE / 자격증명 탈취 / 피싱)
   - 악성 내부자는 별도 카드로 분리

3. 목표 수준(SLO / 금지되는 실패):
   - CVSS 9.0+ 취약점 MTTR ≤ 72h
   - 특권 계정 비인가 사용 0건/분기
   - ATT&CK 탐지 커버리지 ≥ 90%
   - P1 MTTD ≤ 15m, MTTR ≤ 2h
   - RTO ≤ 4h, RPO ≤ 15m

4. 증거 / 검증:
   - 주간 취약점 리포트
   - EDR 커버리지 스냅샷
   - 분기별 침투테스트 요약
   - 테이블탑 / 게임데이 결과
   - 접근권한 리뷰 기록
   - 시크릿 회전 로그

5. 잔여 리스크와 승인:
   - 예: 공급망 라이브러리 X는 임시 완화 상태(서명 검증/격리)
   - CISO 승인 및 유효기간 명시

6. 유지 조건 / 회수 트리거:
   - SLO 미충족 2주 연속
   - 커버리지 100% 미달
   - 미검증 변경 발생
   - 로그 공백 발생 시 ‘완벽’ 배지 자동 회수

Owner: 보안 책임자 / 서비스 오너
다음 갱신일: YYYY.MM.DD

이 카드의 목적은 “완벽하다”라고 말하기 위한 것이 아니라, 언제 완벽이라고 말할 수 없게 되는지까지 미리 쓰는 것입니다.

7) 왜 이 접근이 팀을 강하게 만드는가

“완벽한 보안은 없다”는 말에 매몰되면 팀은 점점 다음 상태에 빠지기 쉽습니다.

  • 우선순위가 흐려지고
  • 목표가 모호해지고
  • 예산과 인력 요청이 약해지며
  • 자동화와 개선이 늦어집니다

반대로 정의·수치·증거로 운영하는 보안은

  • 목표를 분명히 하고
  • 예산과 인력, 자동화를 정당화하며
  • 경영진과 현업, 감사인에게 검증 가능한 언어를 제공합니다.

즉, 정의된 완벽은 팀을 압박하는 구호가 아니라, 팀을 움직이게 만드는 운영 프레임입니다.

8) PLURA-XDR로 ‘완벽’을 운영하는 방법

PLURA-XDR은 가시성(수집) → 탐지(분석) → 대응(자동화) → 증거(보존/감사) 흐름을 하나의 체계로 연결해, 앞서 말한 5요소와 SLO를 증거 기반으로 운영할 수 있게 돕습니다.

여기서 중요한 것은 단순히 로그를 많이 모으는 것이 아닙니다.

핵심은,

공격 행위를 ATT&CK 관점으로 맵핑하고, 탐지·대응·증거를 동일한 시간축 위에서 연결하는 것입니다.

즉, SLO는 선언만으로 유지되지 않습니다. 실제 수집·분석·자동화·감사 가능한 데이터 흐름으로만 유지됩니다.

PLURA-XDR이 지원하는 운영 방식

  • 가시성 100% 지향 엔드포인트 / 네트워크 / 클라우드 / 애플리케이션 로그를 단일 타임라인으로 연결

  • 탐지 시나리오 맵핑 MITRE ATT&CK 기준 유스케이스 운영으로 커버리지 수치화

  • 대응 자동화 격리, 차단, 키 회전, 티켓 발행 등 런북 자동화로 MTTD / MTTR 지원

  • 증거 포트폴리오 경보 맥락, 아티팩트, 대응 이력, 리허설 결과를 감사 가능한 형태로 보존

결국 PLURA-XDR은 ‘완벽 선언 카드’의 증거 칸을 자동으로 채우고, 회수 트리거를 대시보드화함으로써 구호가 아니라 운영되는 완벽을 만들도록 돕습니다.

9) 당장 시작하는 1주 플랜

이 개념은 거창한 프로젝트부터 시작할 필요가 없습니다.

Day 1

핵심 경로 1개를 선택합니다. 예: 고객 결제, 고객 PII 처리, 관리자 로그인 경로

Day 2

그 경로에 대해 완벽 선언 카드를 작성합니다.

Day 3

지금 이미 측정 가능한 SLO 5개만 먼저 넣습니다. 예: 패치, MFA, EDR 커버리지, 백업, 탐지 1~2개

Day 4

각 SLO에 대한 증거 링크를 붙입니다.

Day 5

회수 트리거 2개를 자동화합니다. 예:

  • Critical MTTR 초과
  • EDR 커버리지 미달
  • 로그 공백 발생

Day 6~7

팀 위키에 공개하고, 다음 주부터 주간 10분 점검으로 갱신합니다.

중요한 것은 처음부터 완벽하게 만드는 것이 아니라, 완벽을 운영 가능한 형태로 시작하는 것입니다.

결론

“완벽한 보안은 없다”는 말에 매몰될 이유는 없습니다.

문제를 정확히 이해하고, 범위를 정의하고, 위협 모델을 합의하고, 수치와 증거로 준비한다면,

우리는 범위 내에서 운영 가능한 완벽에 도달할 수 있습니다.

그 완벽은 절대적 신화도 아니고, 광고 문구도 아닙니다.

지속적으로 유지·검증되고, 필요하면 회수되는 운영 상태입니다.

완벽은 포기해야 할 단어가 아니라, 정의하고 관리해야 할 목표입니다.

한 줄 재확인 “완벽은 선언이 아니라 증거다 — 정의하고 준비하면, 보안의 완벽은 가능하다.”

Tags