CATRA 리스크신뢰평가

CATRA 리스크신뢰평가 접근법

“리스크 평가”는 많은 조직에서 하고 있지만, 실제 운영에서는 종종 이런 문제가 생깁니다. 같은 상황인데도 팀마다 판단이 달라지고, 예외가 쌓이며, 통제가 “정책 문서”로만 남는 경우가 많습니다.

CATRA 접근법은 이 문제를 줄이기 위해, 리스크(위험)와 신뢰(Trust)를 한 번에 다루는 방식으로 정리할 수 있습니다. 즉 “위험이 얼마나 큰가”만 보지 않고, “지금 이 요청(접근/행위)을 신뢰해도 되는가”를 증거 기반으로 점수화해 허용/제한/차단 같은 운영 결정을 일관되게 만드는 데 초점을 둡니다.

이 글의 목표
• CATRA를 “점수 모델”로 이해하고 실무에 적용할 수 있게 정리
• 평가 요소(자산/행위/통제/위협/보증)를 분해해서 운영 규칙으로 바꾸는 방법 제시
• 표/박스 형태로 바로 복사해 정책·체크리스트로 쓰기 좋게 구성

1️⃣ CATRA가 다루는 핵심 개념

CATRA는 이름 그대로 “리스크(위험)와 신뢰(Trust)를 함께 평가”하는 관점으로 설명할 수 있습니다. 실무에서는 아래 5가지 축으로 나눠 보는 것이 가장 깔끔합니다.

CATRA 5축(실무형 해석)
• C: Context(맥락) - 누가, 어디서, 어떤 상태로 요청했나
• A: Asset/Action(자산/행위) - 무엇에 접근하고 어떤 행위를 하려는가
• T: Threat(위협) - 지금 시점에 어떤 공격/오용 가능성이 큰가
• R: Risk(리스크) - 발생 가능성×영향도를 수치화한 위험 크기
• A: Assurance(보증/증거) - 통제와 검증으로 “신뢰할 근거”가 얼마나 있는가

중요한 포인트는 “신뢰는 선언이 아니라 증거”라는 관점입니다. 인증(로그인)만 통과했다고 신뢰 점수가 높아지는 게 아니라, 기기 상태, 네트워크, 권한 범위, 데이터 민감도, 탐지/차단 통제, 이상행위 감시 같은 증거가 쌓일수록 신뢰가 올라갑니다. 이때 CATRA는 “증거를 구조화하고 점수로 연결”하는 도구로 쓰기 좋습니다.

2️⃣ 평가 구조: 리스크 점수와 신뢰 점수 분리

실무에서는 “리스크 점수(Risk Score)”와 “신뢰 점수(Trust Score)”를 분리해 계산한 뒤, 둘을 결합해 최종 의사결정(Allow/Limit/Deny)을 내리는 형태가 운영하기 편합니다. CATRA는 이 구조와 궁합이 좋습니다.

추천 구조(간단하고 잘 굴러감)
• Risk Score = 영향도(Impact) × 가능성(Likelihood) × 노출도(Exposure)
• Trust Score = 보증(Assurance) + 환경적 신뢰(Context Trust) - 이상징후(Penalty)
• Decision = f(Risk Score, Trust Score, 정책 임계값)

흔한 실패 패턴
• 리스크만 높고 낮음을 판단하고 “예외”로 뚫어버림
• 신뢰를 “사용자 직급/부서”로만 판단(증거가 없음)
• 점수는 있는데 차단/제한으로 연결되지 않음(운영 규칙 미정)

3️⃣ 평가 항목 설계: 무엇을 점수화할 것인가

아래 표는 CATRA 관점에서 가장 많이 쓰는 평가 항목 묶음입니다. 조직에 맞게 “가중치”만 조정하면 프레임을 그대로 가져가도 됩니다.

영역	평가 질문	예시 지표	점수 범위 예
자산 민감도	이 자산/데이터는 얼마나 중요한가	개인정보/금융/소스코드/관리자 콘솔/핵심DB	1~5
행위 위험도	이 접근/행위는 얼마나 위험한가	조회/다운로드/삭제/권한변경/배포/원격명령	1~5
노출도	공격 표면이 얼마나 열려 있나	인터넷 노출, VPN, 내부망, 제한망, 점프서버	1~5
위협 수준	지금 공격 가능성이 얼마나 큰가	최근 취약점, 캠페인, IOC, 스캔 증가, 경보	1~5
보증(통제/증거)	신뢰할 근거가 얼마나 강한가	MFA, 기기 준수, EDR 정상, 패치, 최소권한, 기록	0~5(가점)
이상징후 패널티	지금 의심스러운 징후가 있나	비정상 위치/시간, 실패 로그인, 새 기기, 대량 요청	0~5(감점)

실무 팁(항목 수를 줄이는 방법)
• 처음부터 항목을 너무 많이 만들면 운영이 안 됨
• “자산 민감도 + 행위 위험도 + 보증 + 이상징후” 4개만으로도 시작 가능
• 이후 사고/장애 사례가 생길 때마다 항목을 보강하는 방식이 현실적

4️⃣ 점수 모델 예시: 임계값으로 정책을 자동화

아래는 “바로 적용 가능한” 단순 모델 예시입니다. 조직 상황에 따라 숫자와 가중치는 달라질 수 있지만, 구조는 그대로 쓰기 좋습니다. 여기서도 CATRA는 “어떤 증거로 신뢰를 올리고, 어떤 위험에서 제한을 거는가”를 깔끔히 표현해줍니다.

예시 스케일(권장)
• 각 요소 1~5점(보증은 0~5 가점, 패널티는 0~5 감점)
• Risk Score 최대: 5×5×5 = 125
• Trust Score 최대: 5(보증)+5(맥락)-0(패널티) = 10(예시)

// 1) Risk Score
Risk = (AssetSensitivity * ActionRisk * Exposure) + ThreatLevelWeight

// 2) Trust Score
Trust = (Assurance + ContextTrust) - AnomalyPenalty

// 3) Decision (예시 룰)
if (Risk >= 80 && Trust < 6)  => 차단(Deny)
if (Risk >= 80 && Trust >= 6) => 제한(Just-In-Time 승인, 세션 격리)
if (Risk < 80 && Trust < 5)   => 제한(MFA 추가, 읽기전용, 다운로드 금지)
if (Risk < 80 && Trust >= 5)  => 허용(Allow)

제한(Limit)에서 자주 쓰는 조치
• 추가 인증(MFA 재확인, 단계 인증)
• 읽기전용 전환(다운로드/삭제/권한변경 차단)
• 세션 시간 단축, 재인증 주기 단축
• 승인 워크플로우(2인 승인, 일시 권한 부여)
• 격리 경로(점프서버, VDI, 프록시 강제)

5️⃣ CATRA 운영 절차: 설계→적용→검증

CATRA는 문서로 끝내면 의미가 없고, “평가 → 정책 결정 → 강제 적용 → 로그/지표로 검증”까지 이어져야 효과가 납니다.

운영 절차(권장 6단계)
1) 범위 정의: 어떤 시스템/행위에 CATRA를 적용할지 정함
2) 분류 체계: 자산 민감도/행위 위험도 레벨을 만든다
3) 증거 수집: MFA, 기기 상태, EDR, 패치, 네트워크 구간 등 신뢰 증거를 연결
4) 점수·임계값: Risk/Trust 계산식과 차단/제한/허용 기준을 확정
5) 강제 적용: 접근제어/프록시/게이트웨이/정책엔진에서 룰로 집행
6) 검증·개선: 오탐/미탐, 예외 요청, 사고 사례로 가중치를 조정

현실적인 시작 방법
• “관리자 콘솔 + 다운로드/권한변경” 같은 고위험 행위부터 적용
• 처음에는 제한(Limit)을 많이 두고, 안정화되면 허용 범위를 넓히는 방식이 안전
• 예외는 점수 모델 안으로 끌어들여야 함(예외가 많아지면 모델이 죽음)

6️⃣ 평가 결과를 표준 산출물로 만드는 방법

평가 결과는 “한 장짜리”로도 감사/점검/운영에 충분히 쓸 수 있어야 합니다. 아래 박스 템플릿을 그대로 쓰면 CATRA 결과를 표준 산출물로 만들기 쉽습니다.

CATRA 평가 기록 템플릿(복붙용)
• 대상 자산: (시스템/데이터/서비스)
• 요청 행위: (조회/다운로드/삭제/권한변경/배포 등)
• 사용자/주체: (역할/그룹/업무)
• 맥락: (접속 위치/네트워크/시간/기기 상태)
• Risk Score 구성: 자산 민감도 __ / 행위 위험도 __ / 노출도 __ / 위협수준 __
• Trust Score 구성: 보증 __ / 맥락 신뢰 __ / 이상징후 패널티 __
• 결론: 허용/제한/차단
• 제한 시 조치: (추가 인증/승인/JIT/격리/로그강화 등)
• 근거 로그/증거: (EDR 상태, MFA, 패치, 정책 링크, 티켓 번호 등)

7️⃣ 적용 예시 시나리오

예를 들어 “관리자 콘솔에서 권한을 변경”하는 행위는 대부분의 조직에서 고위험입니다. CATRA로는 아래처럼 결정을 구조화할 수 있습니다.

항목	예시 값	해석
자산 민감도	5	관리자 콘솔/권한은 조직 전체 영향
행위 위험도	5	권한 변경은 즉시 피해로 연결
노출도	3	VPN 경유지만 여전히 원격
위협 수준	4	최근 스캐닝/공격 캠페인 경보
보증(증거)	4	MFA + 준수 기기 + EDR 정상
이상징후 패널티	2	평소와 다른 시간대 접속

결론 예시
• Risk가 매우 높으므로 기본은 제한(Limit)로 설계
• Trust가 충분하면 “2인 승인 + 10분 JIT 권한 + 세션 기록 강화”로 조건부 허용
• Trust가 낮으면 차단(Deny) 후 보안확인 절차로 전환

8️⃣ CATRA를 잘 굴리기 위한 체크포인트

마지막으로, CATRA는 “모델”보다 “운영”이 핵심입니다. 아래 체크를 통과하면 장기적으로 유지되는 평가 체계가 됩니다.

운영 체크리스트
• 점수가 정책 집행으로 연결되는가(차단/제한/허용이 자동으로 동작하는가)
• 증거 데이터가 신뢰할 만한가(기기 준수/EDR/MFA가 실제로 검증되는가)
• 예외가 점수 모델 안으로 들어오는가(예외가 무한정 늘어나지 않는가)
• 오탐/미탐을 조정할 수 있는가(가중치/임계값 개선 루프 존재)
• 로그로 사후 설명이 가능한가(“왜 차단/왜 허용”이 증거로 남는가)

가장 많이 놓치는 것
• 신뢰 점수(Trust)를 올리는 “증거”를 붙이지 않고, 사람 판단으로만 승인
• 고위험 행위를 그냥 막아버려 업무 우회(섀도우 계정/우회 경로) 생성
• 그래서 “제한(Limit) 설계”가 중요함(업무는 가능하지만 위험은 줄이는 방식)

정리하면, CATRA는 리스크를 “평가”에서 끝내지 않고, 신뢰(Trust)를 증거로 점수화해 운영 결정까지 이어지게 만드는 실전형 접근입니다. 조직에 맞는 항목/가중치/임계값을 정하고, 제한(Limit) 옵션을 풍부하게 설계하면 훨씬 안정적으로 굴러갑니다.