보안 로그·이벤트 분석·취약점·패치

핵심 요약

로그 분석은 기록된 사건을 연결해 보안 문제를 찾아내는 활동이다. 취약점 분석은 약점이 실제 환경에 존재하고 악용 가능한지 확인하는 활동이고, 패치 관리는 수정의 필요성 판단부터 설치·재검증까지 포함한다.

‘경보가 발생했다’, ‘스캐너가 취약하다고 표시했다’, ‘패치 설치가 성공했다’는 각각 조사·검증의 시작점이지 최종 안전성의 증명이 아니다.

1. 이벤트·로그·경보·사고

모든 이벤트가 반드시 로그로 남는 것은 아니다. 기록 정책이 꺼져 있거나 수집이 실패할 수 있다. 반대로 경보가 있다고 실제 침해가 확정되는 것도 아니다. 정상적인 사용자의 실수나 업무 변화가 원인일 수 있다.

2. 주요 로그와 필요한 정보

기본적으로 언제, 누가, 무엇을 대상으로, 어떤 행위를 했고, 결과가 무엇인지를 확인할 수 있어야 한다. 여러 시스템의 시간을 맞추지 않으면 사건의 선후 관계가 뒤바뀌어 보일 수 있다.

비밀번호·개인키·세션 토큰 등 비밀값을 그대로 기록하지 않는다. 필요한 식별 정보와 최소한의 진단 정보를 남기며 로그 접근권한과 변경·삭제 권한을 통제한다. 사용자가 입력한 줄바꿈이나 제어문자가 거짓 로그 행처럼 보이지 않도록 처리한다.

3. 로그 분석의 흐름

수집 → 시간·형식 정리 → 관련 기록 연결 → 이상 징후 분석 → 사실 확인 → 대응과 개선으로 이해한다.

서로 다른 형식의 필드를 공통 기준으로 맞추는 것이 정규화다. 정규화된 결과만으로 부족할 때 원본과 대조할 수 있어야 한다. 같은 사용자·주소·자산·시간대·요청 식별자를 연결하는 것이 상관분석에 도움이 된다.

예를 들어 여러 번의 로그인 실패 뒤 낯선 장치에서 성공하고, 직후 권한 변경과 대량 자료 조회가 발생했다면 개별 사건을 따로 볼 때보다 중요한 의심 근거가 된다. 그러나 시간상 이어졌다는 사실만으로 동일 공격자가 수행했다는 인과관계까지 확정하지는 않는다.

수집 중단·로그 삭제·시간 불일치도 중요한 관찰 대상이다. ‘기록에 공격이 없었다’와 ‘공격이 없었다’는 동일하지 않다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

Syslog 심각도

Syslog는 여러 시스템에서 로그 전달에 사용하는 형식·프로토콜 계열이다. Facility는 메시지의 출처 범주를, Severity는 심각도를 나타내는 데 사용한다.

숫자가 작을수록 더 심각하다. 이 값은 취약점의 CVSS 점수나 조직의 업무 위험 등급과 같은 척도가 아니다.

4. SIEM·SOAR와 경보 판단

SIEM은 여러 시스템의 로그를 수집·정규화·상관분석하여 탐지와 조사를 지원한다. SOAR는 정해진 대응 절차를 여러 도구와 연결하고 자동화한다. 분석용 시스템과 대응 절차 자동화의 중심 역할을 구분한다.

정상을 공격으로 판단하면 오탐, 공격을 놓치면 미탐이다. 경보가 너무 많으면 실제 중요한 사건을 놓칠 수 있으므로 규칙을 조정한다. 그러나 경보 수를 줄이는 것 자체가 보안 향상의 증거는 아니다. 기록 누락이나 탐지 기능 비활성화 때문일 수도 있다.

5. 취약점 관련 용어

CVSS가 높더라도 해당 제품을 사용하지 않거나 취약한 기능이 존재하지 않으면 적용 여부를 먼저 확인해야 한다. 반대로 점수만 상대적으로 낮다는 이유로 외부에 노출되어 실제 악용되는 중요 자산의 문제를 뒤로 미루어서는 안 된다.

실제 악용 정보, 외부 노출, 자산 중요도, 업무 영향, 보완 통제, 수정 가능성을 함께 보아 조치 우선순위를 정한다.

6. 취약점 분석과 검증

취약점 스캔은 알려진 취약점·설정 문제 등을 도구로 찾고, 침투시험은 허가된 범위에서 실제 침해 가능성과 영향을 검증한다. 정적 분석·동적 분석·구성 점검도 확인 대상과 방법이 다르다.

인증 정보를 제공하는 점검은 내부 설정·상태를 더 자세히 볼 수 있고, 인증 없이 수행하는 점검은 외부에 드러난 관점에 가깝다. 어느 방식이 모든 취약점을 빠짐없이 찾아낸다고 단정할 수는 없다.

스캔 결과는 실제 제품·실행 버전, 취약 기능 사용 여부, 접근 가능한 경로, 수정 적용 여부와 대조한다. 제품 이름이 비슷하거나 버전 문자열이 오래 보인다는 이유만으로 취약함을 확정하지 않는다. 공급자가 기존 버전에 보안 수정을 반영했을 수도 있다.

점검은 대상·범위·허가를 정한 뒤 수행한다. 운영 서비스를 손상시키거나 권한 없이 타인의 시스템을 시험하는 것은 정당한 검증 절차가 아니다.

7. 패치 관리 절차

패치는 기능 오류·보안 취약점 등을 수정하기 위한 소프트웨어 변경이다. 패치 관리에는 설치만이 아니라 무엇을 적용할지 판단하고 적용 결과를 검증하는 과정이 포함된다.

여러 서버가 같은 서비스를 제공하면 일부만 수정된 상태를 전체 완료로 기록해서는 안 된다. 설치 프로그램의 성공 메시지가 나와도 재시작하지 않아 이전 코드가 실행 중일 수 있다. 재점검과 정상 업무 확인이 필요하다.

8. 패치가 즉시 불가능한 경우

서비스 영향이나 공급자의 수정 지연 때문에 즉시 패치하지 못할 수 있다. 이때 취약 기능 비활성화, 외부 접근 제한, 격리, 권한 축소, 탐지 강화 같은 임시 완화를 검토한다.

완화는 노출과 피해 가능성을 줄이는 것이며 취약한 코드 자체를 제거한 것과 다를 수 있다. 예외에는 책임자·보완 통제·재검토 시점을 두고 무기한 방치하지 않는다. 지원 종료(EOL) 자산은 교체·이전·종료 계획을 검토해야 한다.

이미 침해가 발생했다면 패치만으로 공격자가 남긴 계정·백도어·유출 영향이 없어지지 않는다. 취약점 수정과 사고 대응은 연결되지만 같은 작업은 아니다.

취약점 식별과 로그 해석의 경계

Syslog 심각도는 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, 7 Debug이다. 숫자가 작을수록 높은 심각도를 뜻한다. PRI는 facility×8+severity로 계산하므로 PRI를 8로 나눈 몫은 facility, 나머지는 severity이다. 예를 들어 PRI 166은 facility 20, severity 6이다. 이 값은 메시지 생산 측의 분류이며 사건의 실질 위험을 자동 확정하지 않는다.

로그 상관분석에서는 시각 기준, 주체, 대상, 동작, 성공·실패와 연결 식별자를 함께 본다. 여러 사용자가 같은 NAT 공인 IP를 공유할 수 있으므로 공인 IP 하나를 한 사람으로 단정하지 않는다. 시간에 맞는 주소·포트 변환 기록과 인증·세션 기록 등을 대조해야 한다. 로그 누락·시간 오차·변조 가능성도 확인한다.

패치 우선순위는 노출 여부, 자산 중요도, 악용 가능성, 기존 통제와 업무 영향을 함께 검토한다. 적용 순서도 의존성·호환 조건을 따라야 한다. A2가 B2를 요구하고 B2는 A1에도 호환된다면 A1·B1→A1·B2→A2·B2의 중간 상태는 호환되지만 A2·B1은 호환되지 않는다. 변경 시험, 백업·복구 준비, 승인, 적용 후 확인을 연결한다.

탐지 경보는 조사할 단서이며 단일 기록에서 계정 탈취·공격자의 신원을 확정하지 않는다. 점검 결과 '발견하지 못했다'는 것과 '취약점이 존재하지 않는다'는 것도 다르다. 검사한 대상·기간·방식·한계가 함께 기록되어야 결과를 올바르게 해석할 수 있다.