방화벽이 접속을 차단하고 보안 시스템이 경고를 보냈는데도 사고가 커질 수 있다. 경고를 받은 사람이 무엇을 확인해야 하는지 모르거나, 계정을 중지할 권한이 없어 조치가 늦어지는 경우다. 개별 장비는 작동했지만 조직의 대응은 이어지지 않은 것이다.
예방은 공격의 성공 가능성과 영향을 줄이고, 탐지는 이상 징후를 찾아 판단하며, 대응은 확인된 위협의 확산과 피해를 줄이는 역할을 한다. 이 세 가지를 연결하는 것은 제품 간 연동만이 아니다. 판단에 필요한 기록, 조치 권한, 결과를 확인하는 절차가 함께 있어야 한다.
1. 예방·탐지·대응은 함께 작동하는 역할이다
보안 통제는 위험을 줄이기 위한 정책, 절차, 기술적 조치 등을 뜻한다. 예방·탐지·대응은 이를 목적에 따라 이해하는 실무적 구분이다. 모든 제품을 세 상자 중 하나에만 넣는 분류법은 아니다.
| 구분 | 핵심 역할 | 예시 | 다음 활동에 필요한 정보 |
|---|---|---|---|
| 예방 | 공격 가능성과 피해 범위 축소 | 다중요소 인증, 최소 권한, 보안 패치 | 적용 대상, 예외, 허용·차단 기록 |
| 탐지 | 이상 징후 발견과 의미 분석 | 로그인 분석, 단말 행위 탐지 | 계정·단말 식별값, 시각, 근거, 영향 범위 |
| 대응 | 확산 억제와 원인 제거 | 계정 제한, 단말 격리, 악성 요소 제거 | 실행 결과, 남은 위험, 복구 인계 사항 |
단말의 행위를 관찰하는 EDR은 이상 행위를 탐지하면서 단말 격리도 수행할 수 있다. 방화벽의 차단 기록은 탐지 분석의 재료가 된다. 따라서 장비 이름보다 어떤 기능을 실제로 설정하고 운영하는지가 중요하다.
NIST CSF 2.0은 거버넌스·식별·보호·탐지·대응·복구라는 여섯 기능을 제시하며, 이를 순서대로 끝내는 단계로 보지 않는다. 이 글의 세 역할은 설명을 위한 범위이며, CSF 전체를 대체하지 않는다. 특히 정상 업무로 돌아가는 복구는 별도로 계획해야 한다. NIST — CSF 2.0
2. 예방에서 탐지로 넘어갈 때는 기록의 품질이 중요하다
다중요소 인증을 적용했다는 사실만으로 의심스러운 계정 사용을 모두 알아낼 수는 없다. 적용 예외가 있는지, 어떤 계정이 어느 단말에서 인증했는지, 인증 이후 어떤 작업을 했는지 확인할 수 있어야 한다.
예를 들어 로그인 성공 기록과 파일 다운로드 기록에 서로 다른 사용자 식별값이 남으면 두 활동을 연결하기 어렵다. 시스템의 시계가 어긋나면 사건의 선후관계도 잘못 해석할 수 있다. 로그가 저장되고 있다는 사실과 분석에 사용할 수 있다는 사실은 다르다.
CIS Control 8은 감사 로그의 수집·검토·보존 절차와 시간 동기화 등을 다룬다. 운영에 적용할 때는 탐지하려는 행위를 먼저 정하고, 그 행위를 판단하는 데 필요한 기록이 실제로 남는지 확인하는 편이 효율적이다. CIS — Audit Log Management
실무 점검에서는 다음 질문을 사용할 수 있다.
- 중요 서비스의 로그인과 권한 변경 기록을 수집하는가?
- 계정·단말·대상 시스템을 공통 식별값으로 연결할 수 있는가?
- 로그가 끊겼을 때 수집 장애 자체를 알아차릴 수 있는가?
- 조사에 필요한 기간 동안 기록을 보관하고 접근을 제한하는가?
수집량을 무조건 늘리면 저장 비용과 분석 부담도 커진다. 사용자 행위가 담긴 로그는 그 자체로 민감한 자료가 될 수 있으므로, 수집 목적과 열람 권한을 함께 정해야 한다. 기록이 없어서 놓치는 위험과 필요 이상으로 모으는 부담을 함께 관리하는 것이 핵심이다.
3. 탐지 경고를 실행 가능한 대응으로 바꾸는 조건
경고는 확인할 신호이며, 그 자체로 침해 확정 판정은 아니다. 낯선 지역의 접속도 출장이나 접속 경로 변경 때문일 수 있다. 반대로 정상 계정의 인증 성공이 정상 업무를 보장하지는 않는다.
다음은 통제의 연결을 설명하기 위한 가상 시나리오다. 한 직원 계정에서 평소와 다른 접속 환경이 관찰되고, 이어 중요 문서 다운로드가 급증했다고 가정하자. 분석자는 인증 기록, 단말 정보, 업무 일정을 함께 확인한다. 무단 사용을 뒷받침하는 근거가 모이면 사전에 정한 기준에 따라 사고로 분류하고 조치를 요청한다.
이때 알림에 경고명만 있으면 담당자는 처음부터 다시 조사해야 한다. 최소한 대상 계정과 단말, 발생 시각, 관찰된 행위, 관련 증거, 예상 영향, 요청 조치를 함께 전달해야 한다. 업무상 필요한 접근인지 확인한 내용도 남기면 같은 확인을 반복하는 시간을 줄일 수 있다.
연결 구조를 운영 문서로 만들 때는 다음처럼 정리할 수 있다. 아래는 조직에 맞게 조정할 수 있는 설계 예시다.
| 연결 지점 | 전달할 내용 | 완료 확인 |
|---|---|---|
| 탐지 → 분석 | 경고 근거와 관련 기록 | 정상 활동인지, 추가 조사가 필요한지 기록 |
| 분석 → 조치 | 영향 범위, 요청 사항, 승인 근거 | 지정 담당자가 요청을 인수했는지 확인 |
| 조치 → 재확인 | 실행 결과와 실패 사유 | 실제 접근 제한과 추가 이상 행위 여부 확인 |
| 재확인 → 개선 | 누락된 로그와 지연 원인 | 담당자·기한을 정해 수정 후 재검증 |
4. 대응 속도는 승인 권한과 업무 영향에 달려 있다
계정 중지나 단말 격리는 피해를 줄일 수 있지만 정상 업무도 중단시킬 수 있다. 개인용 PC와 생산 시스템을 같은 기준으로 자동 격리하면 조치 자체가 장애를 만들 수 있다. 긴급 차단을 누가 실행할 수 있는지, 어떤 대상은 별도 승인이 필요한지 미리 합의해야 한다.
CIS Control 17은 사고 처리 책임자와 대체 담당자, 연락처, 신고 및 대응 절차를 다룬다. 외부 업체를 쓰더라도 내부에서 그 업무를 감독할 책임자를 지정하도록 한다. CIS — Incident Response Management
이를 실제 운영에 적용하면 관제 담당자는 판단 근거를 전달하고, 시스템 담당자는 조치를 실행하며, 서비스 책임자는 업무 영향과 복구 조건을 확인하는 식으로 역할을 나눌 수 있다. 소규모 조직에서는 한 사람이 여러 역할을 맡더라도 부재 시 연락할 사람과 실행 권한은 남겨 두어야 한다.
자동화 범위도 구분할 필요가 있다. 관련 로그를 모으고 사건 기록을 만드는 작업부터 자동화한 뒤, 업무 중단을 일으키는 조치는 대상과 신뢰도에 따라 승인 조건을 정하는 방식이다. 자동화에 사용하는 계정의 권한이 과도하면 잘못된 규칙 하나의 영향도 커진다.
조치 명령이 접수됐다고 차단이 끝난 것은 아니다. 단말이 오프라인이거나 관리 권한이 부족하면 실행에 실패할 수 있다. 성공 응답뿐 아니라 대상의 실제 상태, 실패 시 수동 조치 경로, 임시 차단을 해제할 조건까지 확인해야 대응이 닫힌다.
5. 복구와 개선이 다음 예방·탐지의 품질을 바꾼다
격리는 확산을 막기 위한 조치이지 원인 제거의 완료 선언이 아니다. 침해 경로와 남아 있는 위험을 조사하고, 업무 재개 조건을 확인해야 한다. 계정 제한을 해제하거나 단말을 다시 연결하는 결정도 대응 계획에 포함해야 한다.
2025년 4월 발행된 NIST SP 800-61 Rev. 3은 사고 대응을 조직의 위험관리 전반과 연결하고, 활동 중 얻은 교훈을 지속적으로 반영하도록 설명한다. 개선 사항을 반드시 모든 복구가 끝날 때까지 미룰 필요는 없다. NIST — SP 800-61 Rev. 3
앞의 가상 사례에서 인증 예외가 원인이었다면 예외 승인과 만료 절차를 보완할 수 있다. 다운로드 기록이 누락됐다면 수집 설정을 고치고, 승인자를 찾느라 지연됐다면 비상 연락 체계를 수정한다. 탐지 규칙만 추가하면 해결되지 않는 문제가 각각 다른 담당 업무로 이어지는 것이다.
개선의 완료 기준은 문서 수정이나 설정 저장에 머물지 않아야 한다. 안전한 시험 계정과 승인된 범위에서 같은 유형의 신호를 재현해 경고 생성, 담당자 인수, 조치 결과 확인까지 연결되는지 검증해야 한다.
6. 장비 보유 현황보다 연결이 끊기는 지점을 점검한다
조직의 통제 수준을 점검하려면 중요 업무 하나와 사고 시나리오 하나를 골라 처음부터 끝까지 따라가 보는 편이 유용하다. 탐지에 필요한 기록이 있는지, 야간에도 담당자가 받는지, 조치를 실행할 권한이 있는지, 정상화는 누가 승인하는지를 확인한다.
운영 지표도 이 흐름에 맞춰 설계할 수 있다. 경고 발생부터 담당자 인수까지 걸린 시간, 조치 요청 중 실제 성공이 확인된 비율, 중요한 로그의 수집 공백, 모의훈련에서 누락된 인계 항목 등이 예시다. 모두 조직이 정의할 지표이며 보편적인 합격 수치는 아니다.
경고가 줄었다는 이유만으로 개선됐다고 판단해서는 안 된다. 오탐이 줄었을 수도 있지만 수집 장애나 규칙 비활성화 때문일 수도 있다. 처리 속도와 함께 탐지 범위, 판단의 정확성, 업무 영향을 살펴야 한다.
다음 투자나 개선 과제는 이 점검에서 발견한 가장 큰 공백을 기준으로 정할 수 있다. 로그가 없으면 수집을, 판단이 늦으면 분석 기준을, 실행이 막히면 권한과 연락 체계를 먼저 손봐야 한다. 보안 통제의 연결은 경고를 보냈다는 기록이 아니라, 필요한 조치와 그 결과를 확인할 수 있을 때 성립한다.
참고자료
자료 확인 기준: 2026년 10월 9일. 가상 시나리오, 인계 표, 운영 지표는 아래 자료를 바탕으로 구성한 실무 설계 예시이며 특정 기업의 실제 사례나 의무 기준이 아니다.