기업의 정보보호 업무에서는 위협(Threat), 취약점(Vulnerability), 위험(Risk)이라는 용어가 반복해서 등장한다. 세 용어는 서로 연결되어 있지만 같은 의미는 아니다. 이 차이를 명확하게 구분하지 않으면 취약점 진단 결과를 그대로 위험 목록으로 사용하거나, 실제 업무 영향은 낮은 취약점에 과도한 대응 자원을 투입하는 문제가 생길 수 있다.
NIST는 위협을 조직이나 자산에 부정적인 영향을 줄 가능성이 있는 사건이나 상황으로, 취약점을 위협원에 의해 악용되거나 촉발될 수 있는 시스템·절차·통제·구현상의 약점으로 설명한다. 위험은 일반적으로 어떤 사건이 발생할 가능성과 그 사건이 발생했을 때의 부정적 영향이 결합된 개념으로 다룬다.
이 글에서는 세 개념의 차이부터 실제 기업에서 위험을 식별하고 평가하며 대응하는 기본 구조까지 단계적으로 살펴본다.
1. 위협, 취약점, 위험은 서로 다른 개념이다
위협은 문제를 일으킬 수 있는 원인이다
위협은 정보시스템이나 조직에 피해를 줄 수 있는 잠재적인 사건이나 행위자를 의미한다. 외부 공격자만 위협에 해당하는 것은 아니다. 악성코드 감염, 계정 탈취, 내부자의 오남용, 장비 장애, 정전, 자연재해, 작업자의 실수도 상황에 따라 위협이 될 수 있다.
예를 들어 인터넷에 공개된 업무 시스템이 있다고 가정해 보자. 공격자가 해당 시스템에 침입을 시도하는 행위는 위협이다. 시스템에 침입할 수 있는 약점이 아직 확인되지 않았더라도 공격 자체의 가능성은 존재할 수 있다.
취약점은 위협이 이용할 수 있는 약점이다
취약점은 시스템이나 보안 통제에 존재하는 약점이다. 패치되지 않은 소프트웨어 결함, 잘못된 접근권한, 취약한 비밀번호 정책, 과도하게 개방된 방화벽 정책, 미흡한 내부 절차 등이 모두 취약점이 될 수 있다.
중요한 점은 취약점이 존재한다고 해서 반드시 사고가 발생하는 것은 아니라는 것이다. 취약점은 위협이 실제 피해로 이어질 수 있도록 만드는 조건에 가깝다.
위험은 위협이 취약점을 이용했을 때 발생할 수 있는 손실 가능성이다
위험은 단순히 취약점의 개수나 심각도를 의미하지 않는다. 특정 위협이 취약점을 이용할 가능성과, 실제로 사건이 발생했을 때 조직이 받는 영향을 함께 고려해야 한다.
위험 ≈ 발생 가능성 × 영향도
이 식은 위험을 이해하기 위한 기본적인 표현이지 모든 조직이 동일한 계산식을 사용해야 한다는 의미는 아니다. 실제 위험평가는 조직의 방법론에 따라 정성평가, 반정량평가 또는 정량평가 방식으로 수행할 수 있다.
| 구분 | 의미 | 기업 환경의 예 |
|---|---|---|
| 위협 | 자산에 피해를 줄 수 있는 사건 또는 원인 | 공격자, 랜섬웨어, 계정 탈취, 내부자 오남용 |
| 취약점 | 위협이 이용할 수 있는 약점 | 미패치 서버, 취약한 인증, 과도한 권한 |
| 위험 | 위협이 취약점을 이용해 실제 손실로 이어질 가능성과 영향 | 고객정보 유출, 업무 중단, 금전 손실, 평판 저하 |
2. 위협과 취약점이 연결될 때 위험이 구체화된다
외부에서 접속할 수 있는 VPN 장비에 알려진 취약점이 존재한다고 가정해 보자.
- 자산: 사내 네트워크에 연결되는 VPN 서비스
- 위협: 외부 공격자의 침입 시도
- 취약점: 보안 업데이트가 적용되지 않은 VPN 장비
- 예상 사건: 취약점 악용을 통한 비인가 접속
- 영향: 내부 시스템 접근, 정보 유출, 추가 공격 확산
- 위험: 해당 공격이 실제 발생할 가능성과 조직에 미치는 영향의 조합
네트워크 접근통제, 다중요소인증, 침입탐지, 로그 모니터링 같은 보안 통제가 적용되어 있다면 실제 위험 수준은 달라질 수 있다. 따라서 취약점의 기술적 심각도와 조직의 실제 위험도는 항상 동일하지 않다.
3. 위험관리는 위험을 찾아내는 작업에서 끝나지 않는다
1단계: 범위와 중요 자산을 확인한다
전체 회사, 특정 서비스, 개인정보처리시스템, 클라우드 환경, 협력사 연계 시스템처럼 평가 범위를 명확히 하고 보호해야 할 자산을 식별한다.
2단계: 위협을 식별한다
외부 공격, 악성코드, 계정 탈취, 내부자 행위, 설정 오류, 장애, 재해 등 자산에 영향을 줄 수 있는 위협 시나리오를 확인한다.
3단계: 취약점과 기존 통제를 확인한다
취약점 진단 결과와 함께 계정관리, 접근통제, 패치관리, 백업, 로그관리 등 관리적·기술적 통제의 미흡사항과 이미 적용된 보호조치를 함께 확인한다.
4단계: 발생 가능성과 영향을 평가한다
위협의 현실성, 공격 난이도, 노출 정도, 취약점 상태, 기존 통제 등을 종합적으로 고려한다. 영향도는 정보 유출, 업무 중단, 고객 영향, 법적·계약상 책임, 재무적 손실, 기업 평판까지 포함해 평가한다.
5단계: 위험 수준을 결정하고 우선순위를 정한다
발생 가능성과 영향도를 조합해 위험 수준을 산정하고 어떤 위험을 먼저 처리할 것인지 결정한다. 동일한 취약점이라도 핵심 업무 서비스와 테스트 시스템의 위험 우선순위는 달라질 수 있다.
4. 위험 대응은 제거만을 의미하지 않는다
- 위험 완화: 보안 통제를 추가해 발생 가능성이나 영향을 낮춘다.
- 위험 회피: 업무나 시스템 사용 방식을 변경해 위험 원인을 제거한다.
- 위험 이전 또는 공유: 보험, 계약, 외부 서비스 등을 이용해 위험 일부를 분담한다.
- 위험 수용: 조직이 허용 가능한 수준으로 판단하고 관리하면서 유지한다.
보안 통제를 적용한 후에도 남아 있는 위험을 잔여위험(Residual Risk)이라고 한다. 최초 위험뿐 아니라 통제 이후 잔여위험이 조직의 허용 수준 안에 있는지를 확인하는 것이 중요하다.
5. 취약점 관리와 위험관리는 같은 업무가 아니다
취약점 관리는 어떤 약점이 존재하는지를 중심으로 한다. 위험관리는 그 약점이 어떤 위협과 결합되어 조직에 어떤 영향을 줄 수 있는지까지 판단한다.
높은 심각도의 취약점이라도 외부 접근이 차단되고 보완통제가 충분하다면 위험도가 낮아질 수 있다. 반대로 중간 수준의 취약점이라도 핵심 개인정보처리시스템이나 대외 서비스에 존재하고 실제 공격 가능성이 높다면 우선순위가 높아질 수 있다.
6. 기업에서 운영할 수 있는 기본 위험관리 항목
| 관리 항목 | 주요 내용 |
|---|---|
| 대상 자산 | 시스템, 데이터, 업무 프로세스 |
| 위협 | 발생 가능한 공격·사고·장애 |
| 취약점 | 기술적·관리적 약점 |
| 기존 통제 | 현재 적용된 보호·탐지·대응 조치 |
| 발생 가능성 | 위협이 현실화될 가능성 |
| 영향도 | 업무·정보·재무·법적·평판 영향 |
| 위험 등급 | 조직 기준에 따른 위험 수준 |
| 대응 계획 | 완화·회피·이전·수용 등 |
| 담당자·기한 | 조치 책임자와 완료 목표 |
| 잔여위험 | 대응 이후 남은 위험 |
| 재검토 시점 | 다음 평가 또는 모니터링 일정 |
7. 위험관리는 지속적인 운영 프로세스여야 한다
시스템 구조, 사용 기술, 외부 위협, 조직의 업무 환경은 계속 바뀐다. 신규 시스템 도입, 클라우드 전환, 외부 연계 추가, 조직 개편, 새로운 취약점 공개와 같은 변화는 기존 위험 수준을 바꿀 수 있다.
NIST Cybersecurity Framework 2.0은 사이버보안 위험관리를 조직 전체의 거버넌스와 연결하고 Govern, Identify, Protect, Detect, Respond, Recover의 여섯 기능을 통해 지속적으로 관리하는 구조를 제시한다.
실무자 관점: 위험평가의 목적은 점수를 만드는 것이 아니다
위험평가의 실제 목적은 위험을 숫자로 표현하는 것이 아니라 한정된 보안 자원을 어디에 먼저 투입할 것인지 결정하는 것이다. 취약점 진단 결과, 자산 중요도, 보안장비 로그, 실제 사고 이력, 외부 위협정보, 기존 통제 수준을 함께 연결해야 한다.
위험등록부에는 위험 등급만 남기기보다 대응 책임자와 기한, 현재 통제, 잔여위험, 재검토 시점을 함께 관리하는 것이 좋다. 그래야 위험평가가 감사 대응용 문서가 아니라 실제 보안 운영과 경영 의사결정에 활용될 수 있다.
결론
위협은 피해를 일으킬 수 있는 원인이고, 취약점은 그 위협이 이용할 수 있는 약점이며, 위험은 위협이 취약점을 이용해 조직에 손실을 발생시킬 가능성과 그 영향을 종합한 결과다.
정보보호 위험관리의 핵심은 모든 위험을 제거하는 것이 아니라 조직이 감당할 수 있는 수준으로 위험을 낮추고 중요한 위험부터 우선순위에 따라 관리하는 것이다.