정보보호 거버넌스와 국제 표준: ISO 27001·27005·NIST CSF의 역할
1장 개념과 보호 목표#
정보보호 거버넌스는 경영 목표에 맞춰 위험 허용 수준, 책임과 투자 우선순위를 정하고 감독하는 활동입니다. 관리자가 기술 설정을 운영하는 일과 연결되지만 의사결정과 책임의 관점이 다릅니다.
2장 원리와 구분#
ISO/IEC 27001은 정보보호 관리체계 요구사항, 27002는 통제 지침, 27005는 위험관리 지침, 27014는 거버넌스에 관련됩니다. NIST CSF 2.0은 Govern·Identify·Protect·Detect·Respond·Recover 기능으로 보안 활동을 조직합니다. Common Criteria의 평가는 특정 평가 대상과 가정에, FIPS 140-3 검증은 특정 암호 모듈·버전·운영 환경에 관한 것입니다.
3장 비교와 판단 기준#
| 기준 | 주요 목적 | 적용 시 구분 |
|---|---|---|
| ISO/IEC 27001 | 관리체계 요구사항 | 관리체계 범위 |
| ISO/IEC 27005 | 정보보호 위험관리 | 평가·처리 방법 |
| NIST CSF 2.0 | 보안 활동 조직화 | 현재·목표 상태 |
| CC·FIPS 140-3 | 제품·모듈 평가 | 대상 버전·환경·조건 |
4장 경영진이 결정할 위험과 운영의 역할#
보안 제품의 운영과 사업 위험의 수용은 다른 책임입니다. 핵심 업무의 중단·유출·법적 의무·투자 우선순위를 적절한 의사결정권자가 판단하도록 합니다. 위험 소유자·통제 운영자·승인자·독립 검증을 연결하면 처리되지 않은 문제가 누구의 결정인지 보입니다.
flowchart TB
B["사업 목표와 위험 허용"] --> G["경영 감독과 투자 결정"]
G --> P["정책·책임·계획"]
P --> O["통제 운영"]
O --> V["증거·점검·독립 검증"]
V --> B5장 ISO/IEC 27001의 관리체계 요구#
조직의 범위·위험·통제·운영·평가·개선을 연결하는 관리체계 관점입니다. 제품 인증과 같은 대상이라고 설명하지 않습니다. 실제 서비스·외부 의존성·조직 책임과 범위를 정의하고 운영 증거를 확보해야 합니다.
통제 목록을 그대로 장비 구매 목록으로 바꾸지 않습니다. 어떤 위험을 줄이기 위해 어떤 정책·절차·기술을 선택했고 그 효과를 어떻게 검증하는지 연결합니다.
6장 27002·27005·27014의 다른 역할#
통제 지침·위험관리 지침·거버넌스의 관점이 다릅니다. 같은 27000 계열이라도 요구사항·구현 참고·의사결정의 용도를 구분합니다. 조직이 적용한 판본과 범위를 남겨야 문서 사이의 표현 차이를 이해할 수 있습니다.
기술적 통제만으로 인적 책임·공급망·예외 승인·사업 연속성이 완성되지는 않습니다. 위험을 실제 업무와 자산으로 옮기는 과정이 필요합니다.
7장 NIST CSF 2.0의 여섯 기능#
Govern·Identify·Protect·Detect·Respond·Recover로 보안 결과를 조직할 수 있습니다. Govern은 책임·정책·사업 맥락을, 나머지는 자산 파악·보호·탐지·대응·복구를 연결합니다. 항상 일방향 순서로 한 번씩 끝내는 생명주기가 아닙니다.
Govern: 방향과 책임
Identify: 알아야 할 자산과 위험
Protect: 보호를 위한 통제
Detect: 이상 관측
Respond: 조치와 영향 제한
Recover: 복구와 개선8장 현재 프로파일과 목표 프로파일#
현재 상태와 목표하는 결과의 차이를 개선 계획으로 연결합니다. 핵심 업무·자산·위험에 맞는 우선순위·담당자·기한·증거가 있어야 실행 가능한 계획입니다. 항목을 모두 적용한다고 선언하는 것보다 실제 차이를 설명하는 것이 유용합니다.
목표가 바뀌면 위험과 자산의 변화도 기록합니다. 수집 범위가 늘어 위험 건수가 증가한 경우와 실제 통제 실패가 늘어난 경우를 구분해서 보고합니다.
9장 위험 수용은 근거와 권한을 요구한다#
발생 가능성·영향·대안·비용·잔여 위험을 제시하고 적절한 주체가 승인합니다. 낮음이라고 적는 것만으로 책임 있는 수용이 되지는 않습니다. 만료·변경·사고의 재검토 조건도 정합니다.
보안팀은 위험 분석과 통제 운영을 지원할 수 있지만 사업자가 감수하는 모든 영향을 대신 결정하는 것은 아닙니다. 역할과 보고 경로를 명확히 합니다.
10장 Common Criteria의 평가 대상#
제품·평가 대상·버전·설정·환경 가정과 보안 목표를 확인합니다. 구매한 제품이 평가된 구성과 같은지, 실제 배포가 가정을 충족하는지 비교합니다. 평가가 전체 시스템의 모든 위험을 보증하는 것으로 확대하지 않습니다.
업데이트 후 버전과 지원 조건이 바뀌면 검증 근거도 다시 확인합니다. 인증서의 로고보다 범위와 사용 조건이 실제 판단에 중요합니다.
11장 FIPS 140-3의 암호 모듈#
특정 암호 모듈·버전·운영 환경의 검증입니다. 애플리케이션의 업무 인가·키 정책·Nonce 관리까지 자동으로 보장하지 않습니다. 검증된 모드와 실제 사용 경로가 일치하는지도 확인해야 합니다.
| 평가·기준 | 확인할 대상 |
|---|---|
| 관리체계 인증 | 조직과 범위의 관리 과정 |
| 제품 평가 | 정해진 제품·가정·구성 |
| 암호 모듈 검증 | 모듈·버전·모드·환경 |
| 전체 위험평가 | 실제 업무·연결·데이터·운영 |
12장 경영 보고의 지표#
장비 수·경보 수보다 핵심 자산의 노출·미해결 위험·중단 가능성·조치 기한·잔여 위험을 보여 줍니다. 탐지 범위와 업무 영향도 함께 표시해야 숫자의 증감이 무엇을 뜻하는지 판단할 수 있습니다.
통제 실패·사고·훈련·감사 결과를 개선 계획에 연결합니다. 문서·평가·제품·운영의 근거를 구분하면 표준을 실제 의사결정에 사용할 수 있습니다.
13장 적용 사례와 운영 방법#
경영 보고는 제품 수보다 핵심 자산의 위험, 중단 가능성, 통제 실패와 잔여 위험을 보여줘야 합니다. 인증 제품을 구매할 때도 실제 사용하는 버전과 환경이 평가 범위에 있는지 확인합니다. 연구 논문 발표와 표준 확정, 제품 검증을 같은 수준의 근거로 취급하지 않습니다.
14장 경영진의 위험 결정과 운영자의 조치를 연결한다#
거버넌스는 누가 어느 위험을 감수하고 어떤 투자를 승인하는지를 정합니다. 위험 소유자·의사결정권자·통제 운영자·독립 검증의 역할을 연결하면 해결되지 않은 문제가 누구의 판단을 기다리는지 명확해집니다. 보안팀이 모든 사업 위험을 대신 수용하는 구조는 적절하지 않습니다.
NIST CSF 2.0의 현재 프로파일과 목표 프로파일은 조직의 보안 결과를 비교하고 개선 우선순위를 정하는 데 활용할 수 있습니다. 프레임워크의 성과 항목과 구체적 제품 설정·검증 증거를 연결해야 실행 계획이 됩니다. 기능 목록 자체를 장비 구매 목록으로 바꾸면 목적을 놓칠 수 있습니다.
15장 인증·제품 검증·위험 개선을 다른 지표로 보고하기#
ISO/IEC 27001 관리체계 인증, Common Criteria 제품 평가, FIPS 140-3 암호 모듈 검증은 평가 대상이 다릅니다. 제품의 특정 버전과 운영 조건이 평가 범위인지 확인하고 전체 서비스의 위험평가에 활용합니다. 평가된 모듈의 안전성 주장으로 애플리케이션 인가까지 보증할 수는 없습니다.
경영 보고에는 핵심 업무의 중단·데이터 노출 위험, 개선 기한, 잔여 위험과 승인 근거를 담습니다. 취약점 건수의 증감만 보고하면 수집 범위가 확대된 효과와 실제 악화가 섞일 수 있으므로 자산·노출·조치 상태를 함께 제시합니다.
16장 적용 전 확인할 사항#
- 경영 승인·운영 책임·독립 검증을 연결한다
- 표준별 목적과 적용 범위를 구분한다
- 평가·인증의 버전과 사용 조건을 확인한다
17장 자주 묻는 질문#
인증된 제품이면 시스템도 자동으로 안전한가요?#
설치 환경과 설정, 권한과 운영 절차가 평가 범위를 벗어날 수 있습니다. 제품 검증과 전체 시스템 위험평가를 함께 수행해야 합니다.
NIST CSF를 적용하면 ISO 인증도 자동으로 얻나요?#
프레임워크 적용과 특정 인증의 심사 요구는 다릅니다. 공통 통제를 활용할 수 있어도 인증 범위·요구사항·증거를 별도로 충족해야 합니다.
잔여 위험은 낮다고 적기만 하면 수용되나요?#
평가 근거·업무 영향·수용 권한과 재검토 조건이 필요합니다. 위험을 설명하고 적절한 의사결정권자가 승인해야 합니다.