강좌 강좌
침해지표(IoC) 입문: 침입의 흔적으로 침해 여부를 조사하기
시스코가 자사 제품의 취약점을 알리며 안내한 로그 점검을 처음부터 끝까지 따라가며 '침해지표'의 뜻과 한계를 알아봅니다.
한 문장으로 이해하기
침해지표는 영어로 Indicator of Compromise, 줄여서 IoC라고 부릅니다. 뜻을 말로 정의하기보다 이번 강좌에서 끝까지 따라갈 사례에서 출발하는 편이 빠릅니다. 시스코는 자사 제품의 취약점을 알리면서, access.log라는 기록에서 지정된 사용자 이름 항목이 있는지 찾아보라고 권고했습니다. 이렇게 침해 가능성을 조사할 때 실제로 찾아서 확인하는 흔적이 침해지표입니다. 흔적이 나오면 침해를 의심할 근거가 되고, 나오지 않았다고 해서 안전이 증명되지는 않습니다. 이 강좌를 마치면 침해지표의 뜻을 자기 말로 설명하고, 점검이 어떤 순서로 이루어지는지 설명하고, 침해지표를 신뢰할 수 있는 조건과 어려운 상황을 구분할 수 있습니다. 사전지식은 거의 필요 없습니다. 이번 사례에서 확인하는 access.log가 장비에 남는 접속 기록이라는 점과 사용자 계정이라는 말의 뜻만 알면 충분합니다.
왜 필요한가
어떤 취약점은 정상적인 확인 절차를 건너뛰고 시스템에 접근하도록 허용합니다. 이번에 따라갈 시스코 제품의 취약점이 그렇습니다. 이 취약점은 프로그램끼리 요청을 주고받는 접점인 API 엔드포인트의 인증 통제가 충분하지 않아, 인증되지 않은 원격 공격자가 인증을 우회할 수 있게 합니다. 그래서 담당자에게는 무엇을 확인해야 하는지가 문제가 됩니다. 시스코는 이 취약점을 알리면서 access.log의 지정된 항목을 점검 대상으로 안내했습니다. 확인할 대상이 정해지면 점검이 막연한 수색에서 구체적인 작업으로 바뀝니다.
어떻게 이루어지는가
이번 시스코 사례에서 침해지표를 활용하는 과정은 다음 단계를 따랐습니다. 모든 취약점 공개가 이런 정보를 함께 제공하지는 않습니다.
- 제조사가 취약점과 실제 악용 사실을 공개하면서, 점검할 흔적과 확인 방법을 함께 알려 줍니다.
- 담당자는 자기 조직이 해당 제품을 쓰고 있는지 확인합니다.
- 알려 준 기록을 열어 지정된 항목이 있는지 찾습니다.
- 장비가 여러 노드로 나뉘어 운영된다면 모든 노드의 기록을 빠짐없이 확인합니다. 여기서 노드는 하나의 시스템을 여러 대로 나누어 운영할 때 그 개별 시스템 한 대를 가리키는 말입니다.
- 해당 항목이 나오면 제조사가 권고한 조치로 넘어갑니다.
- 흔적이 없더라도, 취약점 자체에 대한 대응으로 수정된 버전을 적용합니다.
하나의 예시로 따라가기
앞에서 꺼낸 시스코 ISE 점검 안내를 끝까지 따라가 보겠습니다. ISE는 Identity Services Engine의 약자로, IT 관리자가 사용자와 기기의 네트워크 자원 접근을 관리하는 중앙 정책 플랫폼입니다. 시스코는 이 제품의 취약점이 실제 공격에 악용되고 있다고 경고했습니다. 이 취약점에는 여러 사람이 같은 취약점을 가리킬 수 있도록 붙이는 공개 식별 번호인 CVE 번호가 있으며, 번호는 CVE-2026-76460입니다. 취약점의 심각도를 점수로 표시하는 체계인 CVSS 기준으로 출처에 제시된 점수는 10.0입니다. 시스코는 침해지표 확인 방법으로 access.log에서 수상한 사용자 이름을 찾도록 권고했으며, 제시한 점검 명령은 dummyuser가 포함된 항목을 찾습니다. 즉 아무 사용자 이름이나 나온다고 악성 활동인 것은 아니고, 지정된 항목이 대상입니다. 분산 배포 환경이라면 각 노드의 로그를 모두 검토해야 합니다. 명령의 출력에 해당 항목이 있으면 악성 활동일 가능성이 높으며, 이때 시스코는 영향받은 노드를 다시 설치하고 필요하면 설정 백업에서 복구하도록 권고했습니다. 흔적을 정하고, 정해진 위치에서 찾고, 발견되면 권고된 조치로 넘어가는 흐름이 그대로 보입니다.
언제 쓰고 언제 쓰지 않는가
침해지표는 만능 판정 도구가 아닙니다. 가장 중요한 한계는 흔적이 지워질 수 있다는 점입니다. 이 사례에서 시스코는 취약점 악용에 성공한 공격자가 시스템에서 가장 높은 권한인 root 권한으로 명령을 실행하고 악용 증거나 침해지표를 제거하거나 숨길 수 있다고 경고했습니다. 그래서 “찾아봤는데 없었다"가 “안전하다"를 뜻하지는 않습니다. 침해지표 점검이 의미를 가지려면 확인할 기록이 남아 있어야 하고, 관련된 모든 노드를 빠짐없이 확인해야 합니다. 또 이번 사례에서 로그 점검은 흔적을 확인하는 데 쓰이고, 취약점 자체에 대한 대응은 따로 권고됐습니다. 시스코는 이 취약점에 우회 방법이 없다며 수정된 소프트웨어 버전으로 업그레이드하도록 권고했습니다. 미국 사이버보안·인프라보안국(CISA)도 이 취약점을 알려진 악용 취약점 목록에 추가했습니다.
핵심 정리와 확인문제
침해지표는 침해 가능성을 조사할 때 확인하는 관찰 가능한 흔적입니다. 흔적이 나오면 침해를 의심할 근거가 되지만, 흔적이 없다는 사실이 안전을 증명하지는 않습니다.
확인문제
- 침해지표(IoC)를 한 문장으로 설명하면 무엇인가요?
- 이번 시스코 사례에서 침해지표 점검은 어떤 순서로 이루어졌나요? 주요 단계를 순서대로 말해 보세요.
- 침해지표를 확인했는데 아무것도 나오지 않았다면 안전하다고 결론지어도 될까요?
정답과 해설
- 정답: 침해 가능성을 조사할 때 시스템에서 확인하는, 관찰 가능한 흔적입니다. 해설: 감이 아니라 확인 가능한 흔적을 근거로 침해를 의심하게 해 준다는 점이 핵심입니다.
- 정답: 제조사가 취약점과 점검 방법을 공개하고, 담당자가 해당 제품 사용 여부를 확인하고, 알려 준 기록에서 지정된 항목을 찾고, 분산 배포라면 모든 노드를 확인하고, 항목이 나오면 권고된 조치로 넘어가고, 흔적이 없어도 수정된 버전을 적용하는 순서입니다. 해설: 이번 사례에서 확인 대상은 access.log의 dummyuser 항목이었고, 발견 시 권고는 영향받은 노드 재설치와 필요 시 설정 백업 복구였습니다.
- 정답: 아닙니다. 해설: 시스코는 이 취약점 악용에 성공한 공격자가 root 권한으로 악용 증거나 침해지표를 제거하거나 숨길 수 있다고 경고했습니다. 흔적이 없다는 사실은 침해가 없었다는 증명이 되지 않습니다.