4. • 시스템 로그 (UNIX or Linux)
– Syslog daemon 으로 대표되는 log facility 가 존재
– 전용 remote syslog server 를 구축하지 않은 경우 Log
의 위변조가 손쉽게 일어남
– Wtmp, utmp, btmp,
lastlog 와 같은 binary
로그의 경우 agent 설치
없이는 incremental 하게
원격 전송이 어려움
– OS 자체 로그 못지않게
설치된 application 로그의
관리가 중요
5. • Windows 로그
– 로그관리의 큰 발전
• 예: Windows 2000~ Windows XP 의 event viewer vs.
Windows 7 의 event viewer
• 중앙 집중식 event log 관리 및 기초 트렌드 파악이 용이
• 과거 EventCombNT 와 같은 취합/필터링 툴 Logparser 와 같은
유용한 분석툴
– OS 자체 로그 못지않게 설치된 application 로그의 관리가
중요
6. • In-house 로그
– 가장 중요도가 높은 로그임과 동시에 가장 관리 (생성, 유지, 분석,
백업)가 안되는 로그
– 정형화된 방법론이나 툴이 없음 (자체 해결이 최선)
• 로그 포맷의 통일이 안되어 있음
– 보다 향상된 로그분석과 이를 통한 정보를 활용하기 위해서는 이 로
그 생성/관리에 집중해야 함
• Security Intelligence 의 첫걸음!
• 예시
– 시스템 내에 웹로그 (access_log) 외에 웹서비스의 가입자 로그,
결제시스템 로그를 교차분석
• 가입자들의 비정상적인 가입
• 대량결제, 대량 환불 등 비정상적인 결제 행위 감지
• 기존의 access_log 분석에서는 보지 못하던 business fraud 탐지
7. 예: In-house log Data Mining 을 통한 BOT/불량유저 detection
불만 표출 대상의 목적 및 원인 파악
- Black consumer 파악
- Black consumer 로부터 피해를 입은 고객
- 잠재적 Black consumer 분류
위험 요소 제거 및 피해 고객 보상
- BOT detection 능력 강화
- Clean 게임환경 조성, 유저 이탈 방지
고객 이탈 방지
- 매출 기여
- 고객 감동
8. • 과거
– 능숙한 관리자들이 수작업, 육안을 의한 분석
– 상용화된 전문적인 로그분석툴의 부족
– 증거로써의 가치가 떨어짐
• 현재
– 관리자 전문가의 분석영역으로 상향되고 있음 (단순모니터
링으로는 부족)
– 다양한 로그분석툴들이 존재
• 예: MS logparser (http://support.microsoft.com/kb/910447/ko)
– Forensic readiness 를 위한 가장 기본적인 step
9. • 참고
– Forensic readiness
• DFI (Digital Forensic Investigation) 능력을 향상시킴
– Six categories of policies to facilitate DFI (by Yasinsac and
Manzano (2002))
– Retaining Information
– Planning the Response
– Training
– Accelerating the Investigation
– Preventing Anonymous Activities
– Protecting the Evidence
• Forensic readiness 의 목표 (by Tan (2002))
– Maximizing an environment’s ability to collect credible digital
evidence;
– Minimizing the cost of forensics during an incident response.
10. • 현시점에서의 가장 큰 도전과제는?
– 분석 툴의 부재는 아님
• SMS (Server Management System), 전문 상용화된 로그분석 도구,
무료 로그분석 도구, 저장장치의 비용감소 등 로그분석에 유리한 환경
이 되어 감
– 분석의 양이 문제
• 너무나 방대한 로그 – 분석 시간 문제
• 무슨 로그를 어느 주기로 분석해야 하는가
• 무슨 로그를 분석하면 ‘무엇을’ 알 수 있는가
• OS, DBMS, Application 의 로그분석에만 국한되어 있지는 않은가
• 분석결과의 적시성 문제
– 로그량이 너무 방대하여, daily result 가 나오지 못하고 있는가?
– 원하는 주기에 분석 정보를 얻으려면 어떤 분석 infra 가 필요한가
11. • System Infrastructure 차원
– 가장 중요한 의사결정 포인트
• DB? File system? Agent based polling? Storage?
– 로그파일을 수작업으로 ftp 로 옮겨와서 수작업 분석?
– Syslog daemon 을 이용해서 여러 서버들의 로그를 중앙취합?
– SMS/NMS 와 같은 framework 을 이용?
– Agent polling 방식으로 로그를 전송하여 DB 에 conversion 하여 저
장?
– File level 에서의 로그분석에 특화된 file system
• 별도의 전용 file system 을 디자인하여 DB conversion 없이 file
에 직접 query 를 날림
– MS Logparser 를 연상 (C:Logs>logparser "SELECT cs-uri-stem
FROM ex*.log WHERE time-taken > 10000" i:IISW3C)
– 사례: 엔씨소프트 게임로그데이터 분석
12. • Human Infrastructure 차원
– 분석할 전문인력집단 필요
• 현재의 단순 이벤트 모니터링에 의한 단순한 보안관제 아웃소싱으로는
부족
• 통계적 모델링, 분석시스템 개발, DB/file system 관리 등 개발인력,
운영관리인력, 분석인력의 3개군이 필요
• 참고사례: NHN, 엔씨소프트
13. • Data Analysis Infrastructure 차원
– 무엇을 언제 어떻게 분석할 것인가
– 무엇을 알고 싶은가, 그것을 위한 로그는 생성되고 있는가?
– 자기 조직에 최적화 된 분석 방법론 개발 필요
– 데이터마이닝, 자기유사도, 기계학습, 분산처리 고려
– 목표 정보획득 주기를 결정하는 것이 중요
• D-1? H-6? Real-time?
14. • 방법론 예시
– RFM Analysis (http://en.wikipedia.org/wiki/RFM)
• Recency - How recently a customer has purchased?
• Frequency - How often she purchases?
• Monetary Value - How much does she spend?
– 원래는 CRM (Customer Relationship Management) 에
쓰이는 개념이나 R, F, M 값의 정의에 따라 시스템 로그분석
및 이상증후 감지에 용이한 분석 개념
15. • RFM analysis
– 개인별 이상증후 발생시 탐지 가능 계정도용, 휴면계정이 작업장에 악
용되는 행위 탐지에 응용
– R, F1, M1, M2 를 이용하여 거래 패턴에 대해 vector 를 design
가입단 (subscription layer)
게임단 (in-game layer)
결제단
(Billing
Payment
Layer)
Factor vector
(작업장 거래패턴)
R F1 M1 M2
values 최근 거래 시간
거래 후 다음 거래
시도까지의 평균
interval time
거래 횟수
기준 기간 내 평균
거래금액
16. • 전통적인 UNIX, Windows 로그분석 상세 기법
– http://www.hksecurity.net/home/pds 에서 KISA-
0146.pdf 참조
• RFM 기반 로그분석 기법
– Huy Kang Kim, Kwang Hyuk Im, SangChan Park,
“DSS for Computer Security Incident Response
applying CBR and collaborative response”, Volume
37, Issue 1, pp. 852-870
– http://bit.ly/ryu25t 참조
18. • 로그분석 및 보안관제의 trend
– 1세대 : 단순 로그 취합 (1990~2000년대 초반의 ESM)
– 2세대 : 로그 표준화 시도 및 초기단계의 교차분석 (2000년
후반기의 ESM)
– 3세대 : Logical information + Physical information 간
Convergence, 시각화 (Security Visualization) 추구
Spider-1, ArcSight, enVision 은 어디쯤?
19. • 다양한 시각화 기법 적용
– vizsec.org, secviz.org
– DAVIX (security analysis and visualization live CD)
• http://www.vizsec.org/davix/
– 예: parallel coordinate chart 응용
• PCAV http://ccs.korea.ac.kr/PCAV/
20. • 여전한 문제는
– 기본적으로 로그가 너무 많다는 것
– 요약된 필터링 정보와 교차분석된 정보는 정보가 과다하게 손
실압축되어 있음
– Top N, threshold 위주의 감지와 대응이라는 점
– 알려진 패턴위주의 분석인 경우 이상증후 감지에 실패
• 어느 시점을 기점으로 집중해서 timeline 분석을 하면 좋을까?
21. • 예:
– 로그분석을 각 서버별로 daily 로 열심히 하면 APT 공격을
탐지할 수 있나요? No 에 가까움 (나무만 보게 되는 경
우, 현실적으로 인력, 자원 한계상 불가능함)
– ESM 을 열심히 관찰하면 APT 공격을 탐지할 수 있나요?
많은 ESM tool 이 basis 값을 IDS/IPS 에 의존하는 경
우가 많음. Zero-day attack 이나 비 volume 형 공격
(RFM 중 R(interval)이 길고, F가 낮고, M이 낮은 critical
attack) 인 경우는 감지 못함
• 농담: 그러면 top 10 을 볼게 아니라 top -10 을 보면 될게 아닌가!
22. • 기존의 로그분석 인프라 및 ESM 인프라를 최대한 활용
하며 이상증후 감지 시기 (집중분석 필요 구간)을 감지
해 주는 방법론
– 자기유사도 (self-similarity) 기반 방법론
23. • 자기유사도 (self-similarity) 기반 방법론
Types of EventLog
EventLog
RecordNumber
TimeGenerated
TimeWritten
EventID
EventType
EventTypeName
EventCategory
EventCategoryName
SourceName
String
ComputerName
SID
Message
Data
…
Numberofevents
24. • 자기유사도 (self-similarity) 기반 방법론
SID
EventID
Number
of event
When normal,
cosine distance
Gt, Gt+1, …Gt+n
varies a little.
When anomaly,
cosine distance
varies a lot
27. • 자기유사도 (self-similarity) 기반 방법론
Attack
Self-similarity is recovered.
Attack
stopped
getting self-
similarity
getting more
self-similarity
28. • Windows 의 경우 Logparser 와 접목하여 손쉽게 자체
구현 가능
• 예: 각 사용자 별 이벤트 종류별 발생횟수를 정기 모니터링
C:logparser -i:EVT "select to_date(timegenerated),
quantize(to_time(timegenerated),
3600), sid, eventtypename, eventcategoryname, sourcename,
eventid,
count(*) from .security.evt group by to_date(timegenerated),
quantize(to_time(timegenerated),3600),
sid, eventtypename, eventcategoryname, sourcename, eventid
order by sid, to_date(timegenerated),
quantize(to_time(timegenerated),3600), eventid desc" -
o:datagrid
29. • 예시 시나리오:
– 100일간 로그를 적재하였고, 침해사고가 발생하여 백도어가
설치되었음을 발견함
– 알려져 있는 패턴기반으로는 탐지된 로그가 없었음
– 100일간의 로그를 sequential 하게 다 review 하지 않고,
이상증후가 발생하였을 것으로 판단되는 시점들을 자기유사도
변이가 높았던 시점으로 추출함
– 해당 시점에 대해서 집중 분석
31. • Security Intelligence in APT attack age
– 과거: 어디에서 공격했는가, 어떻게 공격했는가
– 현재/미래: 누가 공격했는가, 왜 공격했는가, 또 언제 공격을
하게 될것인가
– IP 와 공격기법은 시기에 따라 바뀌지만, 만약 당신의 회사가
보유한 정보자산에 관심이 있다면 해커/해커집단은 계속 공격
을 해올 것임
• 예: Sony, Mitsubishi
• 군/정보기관에서의 security intelligence 영역 민간
으로 확대될 필요가 있음
32. • Cyber Genome Project
– 해커들을 identify 하기 위한 지문/DNA 채취에 비견
• “Cyber Genome”
– to produce revolutionary cyber defense and
investigatory technologies for the collection,
identification, characterization, and presentation of
properties and relationships from collected digital
artifacts of software, data, and/or users
• 악성코드의 패턴, 코드작성자의 습성 (변수명, 함수명),
코드작성에 이용한 개발툴, 최초 감염지역, 공격에 즐겨
쓰는 통신프로토콜 등 정보 수집
34. • Security Intelligence
– 꼭 보안장비, 시스템로그가 아니더라도 회사에서 서비스 중인
서비스관련 로그를 분석하여 다양한 대응이 가능하도록 함
• 예: 계정도용
• 자사 서비스에 대한 이해도를 바탕으로 시나리오 기법, 스코어링 기법
등 다양하게 응용 가능
35. • Security Intelligence – 온라인게임 서비스 응용 예
BOT
사냥 패턴
- Zone A 에서 300초
내에 20마리 사냥 완료
플레이타임
- 사용시간 12시간 이상
이상 단계
State 2
Final state
이상 단계
이상 단계
이상캐릭터명
- 의미없는 캐릭터명 사용
해킹시도
-탐지IP사용
State 1
제재전과
- 제재이력 있는 SSN
36. • Security Intelligence – 온라인게임 서비스 응용 예
유
저
수
점수
이
상
유
저
정상유저
의
심
유
저
불
량
유
저
특이유저
X1 X2 X3 X4X0
전체 사용자
불량
기준
1
불량
기준
2
불량
기준
3
불량
기준
4
불량
기준
5
기준 점수 합산
특이 사용자
불량 유저 의심 유저 이상유저
기준 점수 환산 근거
0 ~ 12시간 0 일반 유저 계층
12 ~ 18시간 1 하드코어 유저 및 BOT 의심 유저
18 ~ 24시간 2 하드코어 유저 및 BOT 유저 계층
37. • DARPA Cyber Genome Project
– http://publicintelligence.net/hbgary-general-dynamics-
darpa-cyber-genome-program-proposal/
– https://www.fbo.gov/utils/view?id=5e23cdf66ec75088ce
98c1351729b3a3
• ATP Secrets in ASIA
– http://www.hitcon.org/hit2011/downloads/06_APT_Secr
ets_In_Asia.pdf