이상징후 분석의 한계
일반로그의 이상징후 분석은 쉽다고 얘기했었는데, 그렇다고 로그에서 이상징후가 알아서 툭 튀어나오지는 않는다. 저번에 응답코드 404 발생 건수 변화 추적을 통해 이상징후를 포착하는 과정을 살펴봤었는데, 그때 파일 확장자 발생 개수 조건을 참고하면 판단이 조금은 쉬워진다는 사실을 알 수 있었다. 흔한 상관분석 시나리오.
단순히 발생 추이만을 볼 게 아니라, 이상징후 관점에서 판단의 정확도를 높여줄 상관 조건을 찾아보자. 뭐가 있을까? 500 에러 발생은 사용자가 처리 곤란한 요청을 했다는 뜻. 사용자의 요청 내역은 모두 URI에 기록된다. 하지만 내역을 일일이 확인하는 작업은 꽤 귀찮을 뿐더러, 숫자의 변화를 추적하려는 이상징후 분석의 취지와도 맞지 않다.
URI를 숫자로 바꿔서 변화를 추적해보자. 그런데 URI의 어떤 상태를 숫자로 바꾸면 이상징후 분석을 할 수 있을까? URI의 길이는 정상과 비정상을 구분하는 데 꽤 쓸만한 기준이 될 수 있다. URI 길이, 그중에서도 사용자 요청이 기록되는 URI 변수의 길이를 재보자.
- 참고 : Logstash 필터 ruby
다음은 'ext:asp AND status:500' 조건에서 변수 길이 합의 변화를 선그래프로 표현한 것이다. 키바나는 점이 연결된 선그래프에서 점의 크기(Dot Size)에 다른 값을 할당함으로써 다양한 정황의 비교 분석을 가능하게 해준다.
변수 길이의 총합이 가장 길었던 시간대의 상세 내역은 다음과 같다. sql injection 공격 때문에 변수 길이가 늘어났음을 알 수 있다.
그렇다면 응답코드 500 발생 상황에서 변수 길이의 증가는 해킹 징후의 바로미터일까? 다음은 변수 길이의 총합이 앞선 사례의 10/1밖에 안 되는 상황.
버젓이 공격 시도가 확인된다. 시도된 공격 코드가 짧은 탓도 있고, 정상적인 로그도 섞이고 등등의 결과. (500 에러는 시스템 오류 등, 공격이 아닌 상황에서도 얼마든지 발생 가능) 정상적인 변수에 의해서도 얼마든지 늘어날 수 있는 길이값을 너무 믿어서는 안 된다는 얘기.
아 귀찮아. 그냥 500 에러면 무조건 적색경보 발령해버릴까 싶은 충동이 들 때쯤, 사용자 요청이 정상 처리됐음을 의미하는 응답코드 200 상황에서도 공격 시도가 확인된다. 시큐어코딩 미비로 인해 웹서버가 정상 처리해버린 것.
이상징후 분석의 한계
찾아보면 정확도를 더 높일 수 있는 방법이 있겠지만, '절대'적인 무언가를 찾기는 쉽지 않다. 흔히들 업무 시간 이후, 로그인 흔적이나 파일 접근 등의 비정상을 얘기하지만, 업무 시간대에 발생했다고 해서 모두 정상이라고 단정할 수도 없지 않은가?
패턴매칭에 비해 이상징후 분석은 쉽다. 분석이 가능한 상태를 만들 수 있고, 분석을 원하는 상태에 대한 이해가 완벽하다면. 아니면 원하는 상태가 포함된 로그만 분석하거나. (소개한 사례가 그럴듯해 보이는 이유는 실제 사고가 발생했던 시스템의 로그였기 때문)
결국 최선의 방법은 서로의 사각지대를 보완할 수 있도록 패턴매칭과 이상징후 분석 체계를 병행하면서 장기적인 분석 작업을 통해 보호하려는 조직과 영역의 정상 상태를 수치화하는 것.
정상을 알면 비정상은 쉽게 구분되기 때문인데, 이게 당연히 어렵다. 어떤 부분이 가장 어려울까? 답은 다음 발표 자료로 대신한다. (마지막 결론이 청중이 아닌, 발표자 자신이 몸 담고 있는 회사를 향한다는 느낌을 받았다면 그저 착각일까?)
카카오의 이상징후 분석