조회를 넘어 탐지로 — CTI로 완성하는 위협 인텔리전스

로그는 남아 있었다. 그것이 악성인지 몰랐을 뿐이다

침해사고 사후 분석을 몇 차례 진행해 보면 패턴이 비슷하다. 막상 들여다보면 로그는 온전히 다 남아 있다. 방화벽도, 웹서버도, IPS도 제 역할을 했다. 그런데 공격이 두 달간 진행된 뒤에야 발견된다. 이유는 단순하다. 그 시점에 누구도 "지금 들어온 이 IP가 이미 전 세계에서 C2로 신고된 주소"라는 사실을 몰랐기 때문이다.

로그를 수집하는 일과 위험을 인지하는 일은 다른 문제다. 관제 환경에서는 하루에 억 단위 로그가 들어오는데, 그중 어떤 항목이 위험한지를 사람이 일일이 눈으로 걸러낼 수는 없다. 판단 기준을 외부에서 가져와 자동으로 대조하는 것, 그것이 CTI(Cyber Threat Intelligence)다. 거창한 개념이 아니라 "이미 위험하다고 정리된 목록"을 우리 로그와 대조하는 일이다.

그런데 현장에서 보면 위협 인텔리전스 화면을 조회용 대시보드로만 쓰는 경우가 많다. 지구본을 살펴보고 경보 단계를 확인한 뒤 닫는다. 그러면 이 기능의 대부분을 활용하지 못하는 셈이다. 핵심은 이 데이터를 수집 로그에 연동해 자동 탐지로 돌리는 데 있다. 이 글은 거기까지 도달하는 과정을 다룬다.

CTI가 제공하는 7가지, 그리고 반드시 구분해야 할 한 가지

LogCenter의 위협 인텔리전스는 외부 피드 16종을 7개 유형으로 묶어 매시간 갱신한다. 인터넷이 연결된 환경이든 폐쇄망이든 모두 동작한다(폐쇄망은 수동 Import라는 점만 다르다). 7개 유형은 다음과 같다.

여기서 한 가지는 반드시 기억해야 한다. 탐지에 연동되는 것은 위협 IP·URL·Malware 해시 세 가지뿐이다. 이 셋은 우리 로그 필드와 직접 매칭되므로 자동 탐지의 재료가 된다. 나머지 넷(CVE·Exploit·Google Hacking·보안 뉴스)은 분석가가 직접 확인하는 참고 자료다. 이 구분을 모른 채 "CVE를 등록했는데 왜 탐지가 안 되느냐"며 오래 헤매는 경우를 실제로 보았다. CVE는 등록해서 탐지하는 대상이 아니다.

매칭은 어디서 일어나는가 — 정규화가 핵심이다

CTI를 제대로 활용하려면 데이터가 어디서 들어와 어디서 대조되는지를 알아야 한다. 흐름 자체는 단순하다.

CTI 매칭은 세 번째 칸, 분석·상관 단계에서 일어난다. 앞단(Syslog·Agent·NetFlow 등)이 로그의 src_ip, url 같은 필드를 표준 형태로 정리해 두면, 처리·저장 레이어에 적재되는 동시에 CTI DB와 대조된다.

그래서 정규화가 핵심이다. 경험상 CTI 탐지가 "설정했는데 동작하지 않는다"는 경우는 대부분 필드 매핑 문제다. 위협 IP가 분명히 들어왔는데도 비교 대상 필드(src_ip)가 다른 이름으로 적재돼 있으면 시스템은 대조할 대상이 없어 그대로 넘어간다. 오류 메시지도 남지 않는다. 이 점이 가장 위험하다. 따라서 탐지 룰을 만들기 전에 "방화벽 로그에서 출발지 IP가 어떤 필드명으로 들어오는지"부터 확인하는 것이 순서다.

본론 — 실시간 교차 탐지 연동하기

화면에서 위협 IP를 확인하는 것은 여기까지다. 이제 수집 로그와 CTI DB가 자동으로 대조되도록 연결한다. 단계는 세 가지이며, 각 단계에서 실제로 막히는 지점을 함께 정리한다.

1. CTI 업데이트부터

당연하지만 데이터가 없으면 탐지도 없다. 설정 → 인사이트 → CTI 정보에서 환경에 맞는 방식을 선택한다.

폐쇄망에서는 이 Import 주기가 곧 탐지 신선도를 결정한다. 한 달에 한 번 받아 적용하는 곳도 있는데, 그렇게 하면 지난 한 달간 새로 등재된 악성 IP는 탐지하지 못한다. 망 사정이 허락하는 한 주 단위 적용을 권한다.

2. 실시간 탐지에 CTI 유형 등록

설정 → 탐지&알림 → 실시간 탐지 → 추가에서 CTI Malware 또는 CTI IP&URL을 선택한다. 그리고 어떤 로그 필드를 대조할지 지정하는데, 이것이 사실상 이 작업의 핵심이다.

# 매칭 로직은 결국 이렇다
log.src_ip    이(가) CTI 위협 IP 목록에 있으면     → 탐지
log.url       이(가) CTI 위협 URL 목록에 있으면    → 탐지
log.file_hash 이(가) CTI Malware 해시에 있으면     → 탐지

# 대상 필드가 정규화돼 있지 않으면 비교 대상이 없어
# 오류 없이 탐지가 누락된다. (앞에서 강조한 바로 그 함정)

방향도 정해야 한다. 외부에서 들어오는 위협을 탐지하려면 src_ip를, 내부 감염 PC가 악성 C2로 나가는 트래픽을 탐지하려면 dst_ip를 대조해야 한다. 둘 다 중요하지만 목적이 다르다. 개인적으로는 아웃바운드 매칭을 더 중요하게 본다. 인바운드 스캔은 워낙 흔해 알람 피로를 유발하지만, 내부 자산이 알려진 C2와 통신하기 시작했다는 것은 이미 감염됐다는 신호이기 때문이다.

3. 탐지 결과 확인

매칭이 발생하면 탐지 결과 페이지와 종합 탐지 현황에 실시간으로 표시된다. 탐지된 IP를 위협 인텔리전스의 위협 IP 탭에서 바로 열면 국가·포트·최초 발견일 같은 맥락이 함께 나타난다. "탐지 → 어떤 IP인지 확인 → 대응"이 하나의 흐름으로 이어진다는 점이 이 도구의 장점이다.

CVE와 MITRE는 이렇게 연결한다

조회 전용 유형도 탐지와 연결하면 활용 가치가 생긴다. CVE가 대표적이다. 단순한 취약점 사전으로만 보면 활용도가 낮지만, 탐지 로그와 연결하면 이야기가 달라진다.

MITRE ATT&CK은 성격이 조금 다르다. CTI가 "이 IP가 악성인가"라는 하나의 점을 찍어 준다면, ATT&CK은 그 점들을 이어 공격자가 현재 어느 단계까지 왔는지를 보여준다. 초기 침투인지, 내부 이동 중인지, 데이터를 유출하는 중인지를 파악하면 다음 단계를 예측해 미리 대비할 수 있다.

실무에서 의외로 유용한 것은 View Only Detected Techniques를 꺼 보는 것이다. 그러면 전체 매트릭스가 표시되면서 아직 탐지 룰로 덮지 못한 기법이 그대로 드러난다. 일종의 커버리지 점검이다. 또한 ATT&CK은 업계 공통 언어이므로, 탐지 결과를 T-번호로 정리해 두면 보고서를 작성하거나 외부와 협업할 때 의사소통이 한결 수월해진다.

실전 케이스 스터디 — CTI가 실제로 잡아낸 것들

지금까지의 설정이 실제 상황에서 어떻게 작동하는지, 현장에서 자주 마주치는 네 가지 시나리오로 정리한다. 모두 앞에서 다룬 CTI 유형·교차 탐지·CVE/MITRE 연계가 어떻게 맞물리는지를 보여주는 사례다.

네 사례가 공통으로 말하는 것은 하나다. CTI의 가치는 화면을 보는 데 있지 않고, 매칭이 탐지·티켓·증적으로 흘러가도록 연결해 둔 설계에 있다. 같은 데이터라도 연동 여부에 따라 결과가 갈린다.

컴플라이언스 관점에서의 가치

CTI를 탐지 도구로만 보면 절반만 보는 것이다. 공공·금융·의료처럼 로그 보존 의무가 있는 환경에서는 이것이 곧 증적이 된다.

공공은 감사 대비, 금융은 전자금융감독규정과 금융보안원 기준, 의료는 개인정보보호법과 의료법의 이중 규제를 받는다. 이런 환경에서 로그만 보존하는 것과, "그 외부 접속을 당시 알려진 위협 정보와 대조한 결과까지" 함께 보존하는 것은 사고 발생 시 큰 차이를 만든다. 후자는 "그 시점에 이것이 악성임을 알 수 있었는지"를 입증할 수 있기 때문이다.

사고가 발생하면 감독기관이 묻는 것은 "탐지했는가"만이 아니다. "탐지할 수 있는 체계를 갖추고 있었는가"를 함께 묻는다. CTI 자동 업데이트가 켜져 있고(최신성), 교차 탐지 룰이 등록돼 있으며(설계), 매칭 이력이 보존돼 있다면(증적), 이 세 가지가 곧 합리적 보안 조치를 했다는 증거가 된다. 규칙 기반 탐지에 CTI 매칭, UBA 이상행위, ML 이상 탐지를 함께 운영하면 탐지 범위가 넓어질 뿐 아니라, 무엇보다 "왜 이렇게 판단했는지"를 설명할 수 있게 된다. 규제 대응에서는 이 설명 가능성이 생각보다 크게 작용한다.

마지막으로, 현장에서 자주 겪는 문제들

설정 자체는 어렵지 않다. 문제는 대개 다음과 같은 지점에서 발생한다.

• 피드가 멈춘 것을 인지하지 못한다. 자동 업데이트 토글이 ON이어도 마지막 갱신이 2주 전이면 의미가 없다. 갱신 시각을 주기적으로 확인하고, 폐쇄망 Import는 일정에 등록해 둔다.
• 필드 매핑이 어긋난다. 방화벽·IPS·웹서버마다 src_ip 필드명이 다르다. 탐지 룰을 만들기 전에 이를 먼저 확인해야 한다. 그렇지 않으면 오류 없이 탐지가 누락된다.
• 탐지 방향을 정하지 않는다. 인바운드만 보고 아웃바운드를 놓치는 경우가 흔하다. 감염 PC의 C2 통신은 dst_ip 쪽에서 탐지된다.
• 경보 단계 대응이 문서화돼 있지 않다. KISA 경보가 올라갔을 때 무엇을 어떻게 강화할지 대응 절차서가 없으면 그 순간 혼란이 생긴다.
• 커버리지를 점검하지 않는다. ATT&CK 매트릭스의 빈 칸(미탐지 기법)을 분기에 한 번은 점검해야 한다.
• UBA·ML을 너무 일찍 활성화한다. 학습 데이터가 최소 2~4주는 쌓여야 의미 있는 결과가 나온다. 구축 직후 켜면 오탐·미탐만 보고 "쓸 수 없다"고 판단해 꺼 버리기 쉽다. 아까운 일이다.

심층 사례 — 악성 메일에서 시작된 C2 통신, 아웃바운드에서 끊다

앞의 짧은 사례들을 하나의 타임라인으로 이어 보면, CTI 교차 탐지가 침해 사슬의 어디에서 작동하는지가 분명해진다. 실제 관제에서 자주 마주치는 흐름이다.

보안 담당자를 위한 활용 방안

CTI는 켜두면 알아서 굴러가는 기능이 아니다. 운영 자산으로 관리할 때 비로소 탐지 커버리지가 외부 위협 지식만큼 넓어진다. SOC·관제 실무에서 챙겨야 할 활용 방안을 정리한다.

결론은 한 문장으로 정리된다. CTI는 조회하기 위한 기능이 아니라 우리 로그에 연동하기 위한 기능이다. 외부 위협 지식을 매시간 우리 환경에 연결하고, 매칭되는 순간 탐지·알람·증적으로 이어지게 만들어 두면, 같은 인력으로도 탐지 역량이 달라진다. 화면을 열어 보고 닫는 것에 그치지 말고, 한 번은 끝까지 연동해 보기를 권한다.