보안의 오랜 친구 SIEM?

SIEM(Security Information and Event Management)은 오랜 시간 기업들의 보안을 맡아왔던 오래된 친구

국내에 ESM(Enterprise Security Management)이란 제품이 알려지기 시작한 게 2000년 말쯤이었으니 틀린 말은 아니다. SIEM으로 시작하더니 ESM은 또 뭘까? 그냥 같은 말이다. 포장지가 달라졌다고 보면 됨.

개인적으로 SIEM과 보안의 만남은 불행한 결말이 예정된 수순이라고 생각한다. 다들 좋다고 찬양인데 나는 왜 새드엔딩이라고 어깃장을 놓는 걸까(..)

SIEM의 유래는 1980년대에 등장한 NMS(Network Management System). NMS의 목적은 시스템의 상태 확인. 시스템이 죽었나, 살았나 또는 자원 사용량 등의 정보를 모아서 보여주는 것이 NMS의 목적이다.

NMS 대시보드

이때 시스템의 업/다운, 자원 사용량 등의 정보는 팩트, 즉 의심할 필요가 없다는 사실에 주목해야 한다. 정보 발생 자체에 의미가 있기 때문에, 결과적으로 대시보드만 보고 있어도, 색깔만 봐도 전체 현황을 파악할 수 있다는 얘기.

성격이 다르다

반면 1990년대 후반에 등장한 이후, 현재까지 네트워크 보안 분야에서 핵심으로 기능하고 있는 IDS 등의 패턴매칭 보안장비는 로그의 내용 열람을 통해 실제 공격 여부를 확인해야만 의미를 부여할 수 있다.

다음은 엘라스틱서치로 구현한 Snort 로그 대시보드. 전세계에서 다양한 공격(?)이 시도되고 있음을 보여준다. 뭔가 있어 보이고, 보안이 통합 관리되는 듯한 느낌은 덤.

그런데 그 느낌을 과연 믿어도 되는 걸까? 사실 해당 로그가 전부 진짜 공격이라면 대시보드를 볼 필요가 없다. 로그가 발생하는 즉시 차단해버리면 그만. 하지만 현실에서는 로그가 발생할 때마다 그 내용을 확인하는 과정이 반드시 뒤따라야 한다.

수십만, 수백만 라인의 로그를 하나하나 꼼꼼하게 확인하려면 기술적인 능력보다는 인성(?)적인 측면이 더 중요

왜 그래야 할까? 다음은 'cmd.exe'란 문자열이 존재하는 웹요청 트래픽을 탐지하는 snort 룰.

alert tcp any any -> any 80 (msg:"WEB-IIS cmd.exe access"; content:"cmd.exe"; http_uri; sid:1002;)

해당 룰의 탐지 결과는 다음과 같다.

정탐

오탐

첫 번째 그림은 웹서버의 시스템 명령어 실행을 시도하는 공격, 두 번째는 'cmd.exe'란 문자열이 단순히 검색어로 사용된 경우. 로그를 까보지 않으면 아무런 의미도 부여할 수 없는 패턴매칭 보안의 특징을 잘 보여준다. 부정확한 룰의 극단적 사례로 보이지만 보안관제 현장에서 가장 흔한 오탐 사례.

왜 이런 상황이 발생할까?

많은 이유가 있겠지만 일단 제조사들은 공격 패턴과 조금이라도 비슷하면 탐지하게끔 룰을 셋팅하려는 경향을 가지고 있다. 미탐, 즉 공격을 탐지하지 못했다는 고객 클레임이 발생하면 매우 피곤해지기 때문(..)

룰 정확도가 낮아지는 두 번째 이유는 장비가 어떤 환경에서 쓰일지 모르기 때문이다. 최종 검사할 트래픽의 특성을 모르는 상태에서 미탐을 방지하려면, 최대한 넓은 범위를 검사해야 하기 때문에, 결국 단순하고 범용적인 패턴을 사용할 수 밖에.

문제는 그런 셋팅 덕에 미탐 가능성은 줄겠지만, 반대로 오탐 가능성은 커진다는 것이다. 공격을 탐지해도 오탐 홍수에 묻히기 쉽다는 뜻.

대량 경보에 의한, 대량 정보가 수집되면 이 정보의 홍수 속에 정말 중요한 정보가 묻힐 가능성이 커진다. 이러한 대량 경보 발생 공격은 잘 만들어지지 않은 IDS 시그니처가 그 원인인 경우가 대부분 - 네트워크 보안 실무 (675 페이지)

결국 패턴매칭을 효과적으로 사용하는 방법은 검사 대상 트래픽의 특성이 반영된 룰 커스터마이징뿐이다. 기성복으로 핏 살리려면 별 수 있나. 기장 줄이고, 통 줄이고, 허리 줄이고(..)

해당 룰을 예로 들면 (소개된 로그만을 근거로 했을 때) 'cmd.exe' 이후 'dir'이란 문자열이 이어지는 트래픽만을 탐지하도록 수정하는 식.

alert tcp any any -> any 80 (msg:"WEB-IIS cmd.exe access"; content:"cmd.exe"; http_uri; content:"dir"; distance:0; sid:1002;)

하지만 이런 문제점은 기술 종주국인 미국에서조차 좀처럼 공론화되지 않고 있다. 나는 그 이유 중 하나가 SIEM의 성급한 대중화라고 본다.

(IDS 등) 기존 보안솔루션이 정상화되어야만 이들의 정보를 취합하는 ESM이 정상화될 수 있음에도, 정보를 화려하게 통합해주는 ESM에 사용자들이 매료되면서 정작 ESM에 정보를 제공해주는 보안솔루션의 정확도에 관한 관심이 사라져버린 것... 만약 ESM이 없었다면 IDS, IPS, 웹방화벽 등의 보안솔루션 벤더들은 지금보다 더 거센 사용자의 개선 요구를 받게 되었을 것이다. - IDS와 보안관제의 완성 (452페이지)

성격이 전혀 다른 NMS의 개념이 보안 분야로 전해지는 바람에 문제점이 드러나지 않고 있는 것. 그러나 문제점이 드러나지 않았다고해서 모르는 것은 아니다. 2009년 당시 안랩 CEO 김홍선씨는 이런 얘기를 했다.

보안 제품은... 사고가 나야만 그 혜택을 알 수 있는 제품이라 투자 효과가 크게 와 닿지 않는다. 그러다 보니 보안 담당자들은 보안을 잘 모르는 윗분들에게 보안 정보와 통계적 동향을 쉽게 보여줄 방법을 찾았다. 그 목적에 맞아 떨어진 것이 ESM... 보안을 잘 모르는 상사에게 어필하기 위해 사용되다 보니 초기 방향이 왜곡된 경향이 있다. 그 결과 ESM의 기능은 많은 네트워크 장비를 붙여서 네트워크 단에서 올라오는 정보를 눈에 띄게 보여주는 쪽으로 치중되었다.

CEO급에서 이런 식견을 보였다는 것은 사실상 업계 관계자라면 다 알고 있는 문제라는 얘기. 그런데 왜 개선이 안 될까? 이것 역시 이런저런 이유가 있겠지만 가장 큰 이유는 사용자의 니즈가 크지 않아서 아닐까 싶다.

그렇다고 사용자 잘못이라 하기도 어렵다. 잘못 꿴 첫단추 때문에 발생한 문제. 그리고 이제는 그 상황에 익숙해져버린 게 문제.

관련 글

• 보안의 오랜 친구 SIEM? - 2nd