LogParser 활용(Windows Logon Event 이상징후 분석)

웹로그만 쳐다보고 있으니 지겨워서 다른 걸 해볼까 한다. 2월쯤에 잠깐 언급하다 말았던 윈도우 이벤트 로그. 대부분의 사용자가 윈도우를 사용하는 현실, 그리고 APT, 내부정보 유출, 랜섬웨어 등의 부각으로 윈도우 이벤트 로그 분석의 중요성은 점점 커지고 있는 추세다. 더불어 할 일도 증가(..)

하지만 LogParser와 엑셀이 있으니 괜찮;;

보안 알파고?

마케팅 비용이 쏠리는 곳에 기회가 있다

빅데이터에 대한 특집 방송이 편성되고, 해외 사례가 소개되고, 온갖 장미빛 청사진을 담은 기사들이 쏟아지던 2012년이 떠오른다. 그 열풍은 조금 사그라든 듯하지만 빅데이터는 아직 현재진행형이다.

개인적으로는 긍정적으로 평가하는 편이다. 실제 눈으로 확인할 수 있는 효과나 소위 '가성비'와는 별개로 어쨌든 사람들을 데이터에 주목하게 만들었고, 데이터의 활용 가치에 눈 뜨게 만들었으니까. 물론 순기능이 있으면 언제나 그렇듯이 역기능이 따라온다.

프리즘 사태 등으로 확인된 빅브라더의 가능성과 함께 무분별한 마케팅으로 인한 맹신과 만능주의 확산이 바로 그것. 마케팅 비용이 쏠리는 곳에 거품이 형성된다고나 할까? 뭐 신기술의 필수 통과 의례 정도가 아닐까 한다. 거품이 초기 투자를 이끌어내는 긍정(?)적인 측면도 있고.

LogParser 활용(Web Log 이상징후 분석 - 6th)

이미 얘기했지만 이상징후 분석이 어려운 이유는 피해자 또는 공격자라는 힌트가 없기 때문이다. (피해자나 공격자를 알고 있다면 이러고 있을 필요도 없고) 그래서 이상징후 분석 체계가 성공적으로 자리잡기 위해서는 정상 상태를 정의한다는 관점의 접근이 필요하다.

LogParser 활용(Web Log 이상징후 분석 - 5th)

4회에 걸쳐서 웹 응답코드 및 웹 문서 종류의 개수라는 로그의 단일 요소를 기준으로 이상징후 분석을 시도했었다. 그런데 이상징후 분석에 대한 오해가 생길 수도 있을 것 같아서 오늘은 좀 다른 얘기를 해볼까 한다.

지난 분석 사례에서 공격 징후 포착이 나름 수월(?)했었다. 이상징후 분석은 원래 이렇게 쉬운 걸까? 그럴리가 해당 사례의 분석이 쉬웠던 이유는 사고 발생이 알려지고 난 뒤에 이루어진 분석이기 때문.

피해자라는 힌트가 있었기 때문에 피해 시스템에서 피해가 발생한 일시의 로그만을 분석하는데 어려울 턱이 있나. 그런데 만약 공격이 발생하지 않았다면 어땠을까? 수많은 시스템과 서비스에서 발생하는 대량의 로그라는 어려움을 겨우 극복해서 분석했음에도 정작 발생한 공격이 없다면?