2019년 5월 1일 수요일

알고 보면 쉬운 이상징후 분석 - 3rd

다음은 변수 길이 급증 시점의 변수 내역. 'create table'로 시작하는 SQL문이 눈에 띈다.


변수 영역에 SQL문이 포함되면 이상한 걸까? 이상할 수도 있고, 아닐 수도 있고(..) 이때 두 가지 정도의 판단법을 써볼 수 있다. SQL문의 실행 성격을 파악하거나, 웹의 목적 또는 의도를 이해하거나.

문득 참 보안하기 힘들다는 생각이 든다.
대부분의 분야에서 개발은 기능이 동작하느냐, 마느냐의 문제다. 그래서 기능이 동작하면 모두가 해피엔딩. 기능이 동작하고 나면 더 빨리, 더 많이 할 수 있느냐, 없느냐의 문제로 확장되겠지만 결론은 마찬가지. 그런데 보안은 여기에 해결해야 할 문제가 하나 더 추가된다. 기능이 동작한 결과가 보안 관점에서 이로운가? 해로운가?

네트워크나 웹, DB 등 각 분야의 원리를 이해한 후, 본연의 목적이나 의도에 반하는 방향으로 동작했는지 여부까지 판단해야 한다. 그런데 그런 역량을 발휘한다고 돈을 더 준다거나 하지는 않는다(..)

도구는 죄가 없다

일단 SQL문 실행 성격 파악은 꽤 높은 전문성을 요구한다. (그런 전문성을 가지고 있다면 난 그냥 DB 개발자로 살련다 -_-) 그런데 부족한 전문성을 탓하기 전에 SQL문 좀 쓰면 안 되나? SQL문이 원래 나쁜 건가?

도구보다 도구가 쓰인 배경, 도구를 사용한 이의 의도 파악이 중요하다. 상황이나 의도에 따라 사시미칼은 훌륭한 요리 도구가 될 수도 있고, 끔찍한 범죄 도구가 될 수도 있다는 얘기.

SQL 사용은 DB에 직접 명령을 날리는 행위. 내부 DB 관리를 목적으로 접근이 제한된 웹이라면 SQL문 발생은 정상일 가능성이 높다. 반면 대외 서비스 용도라면? 누군지도 모르는 사용자가 DB에 직접 명령을 날리는 상황이 정상일까?

해당 웹서버의 용도를 파악했다면 변수 길이가 평균일 때와 아닐 때의 변수 내역을 비교해볼 수도 있다. SQL문 발생이 정상이라면 발생이 없을 때보다 있을 때가 더 많아야 하지 않을까? 세상엔 그래도 비정상보다 정상이 더 많으니깐.
정상인 상태를 정량적 측정을 통해 수치화함으로써 조직의 로그 발생 특성을 파악해야 한다. 정상을 알아내는 이상징후 분석이 먼저 실행됐을 때 비정상을 알아내는 이상징후 분석으로 이어질 수 있는 것
어떤 행위가 발생하지 않았다는 것을 아는 것은 발생했다는 것을 아는 것만큼 중요하다 - 네트워크 보안 실무 (376페이지) 
정상을 알면 비정상은 쉽게 구분된다 - IDS와 보안관제의 완성 (439페이지)

이런 과정이 쉬울까? 쉽다고 했지만 거짓말이다. 지겹고 지겨운 노가다를 거쳐야 얻을 수 있는 것들이기 때문. 진짜 궁금한 사람, 궁금증을 해소하지 않고는 못 배기겠는 사람만이 버틸 수 있다.
아주 똑똑한 학생이나 엔지니어도 자신이 만지는 데이터에 대해 놀라울 정도로 호기심을 보이지 않는 경우가 많다. 대부분 뭘 궁금해해야 하는지를 모른다. 데이터를 그냥 가로 세로 줄 맞춘 다음 블랙박스 모델에 집어넣으면 첨단 알고리즘이 알아서 해줄 것이라 기대한다. 당연히 실패한다.

결국 모든 분석이 그렇듯 이상징후 분석 역시 원동력은 호기심. 여기에 도메인 지식과 간단한 통계적 기법을 추가하면, 특정 행동을 의미하는 상태를 세는 것만으로도 의미있는 결과를 얻을 수 있다.

가능성을 높이는 팁

뇌는 감각기관이 수집한 정보를 경험, 기억, 감정 등을 바탕으로 왜곡한다. 그래서 사람은 있는 그대로 보지 않는다. 좋아할 때는 아름답게 보다가, 그 감정이 사라지면 같은 사람을 추하게 본다.


로그도 마찬가지. 눈에 익은 패턴만 보고 있으면 '이상한 것'은 좀처럼 나타나지 않는다. 그래서 같은 패턴도 다른 관점에서, 다른 형태로 보는 훈련이 필요하다. 창의력을 발휘할수록 얻어 걸릴(?) 가능성이 높아진다.

미생 84수

관련 글

댓글 없음:

댓글 쓰기

크리에이티브 커먼즈 라이선스