IDWG 표준화 동향

1. IDWG 표준화 동향 2001. 5. 10 채기준 이화여자대학교 Kjchae@ewha.ac.kr

2. 목 차 • IDWG 개요 • Intrusion Detection Exchange Requirements • IAP: Intrusion Alert Protocol • The Intrusion Detection Exchange Protocol (IDXP) • The Tunnel Protocol • IDMEF XML Document Type Definition • IDMEF Comparison of SMI and XML Implementations • 결론

3. IDWG 개요(1/3) • Chairs: • Michael Erlinger (mike@cs.hmc.edu) • Stuart Staniford-Chen (stanifor@cs.ucdavis.edu) • 제 43차 회의 시 첫 모임 (98. 12) • General Discussion:idwg-public@zurich.ibm.com To Subscribe: idwg-public-request@ zurich.ibm.com Archive: http://www.semper.org/idwg-public/

4. IDWG 개요 (2/3) • 목적 IDS와 대응 시스템, 그리고 이들과 상호 작동하는 관리시스템 사이의 정보를 공유하기 위한 데이터 포맷 및 교환 절차에 대하여 정의 • WG의 Outputs • Requirements documents • Common intrusion language specification (Data formats) • Framework documents

5. IDWG 개요 (3/3) • Internet-Drafts • Intrusion Detection Exchange Requirements • IAP: Intrusion Alert Protocol • The Intrusion Detection Exchange Protocol (IDXP) • The TUNNEL Profile • Intrusion Detection Message Exchange Format Extensible Markup Language (XML) Document Type Definition • Intrusion Detection Message Exchange Format Comparison of SMI and XML Implementations • No RFC

6. Intrusion Detection Message Exchange Requirements<draft-ietf-idwg-requirements-05.txt>

7. 개 요 • IDS, 대응 시스템, 관리 시스템 사이의 통신을 위한 high-level 요구사항을 기술함 (이론적 해석 및 시나리오 포함) • IDMEF IDS가 의심스럽다고 간주하는 이벤트를 보고하기 위하여 사용하는 표준 포맷

8. IDS 용어 및 관계 Data Source Operator Activity Sensor Notification Event Response Analyzer Alert Manager Security Policy Administrator

9. 구조상의 가정들 • Analyzer는 sensor에 의해 수집된 의심스러운 이벤트에 대하여 어떻게 할 것인가를 결정하고, manager에게 alert을 보냄 • Alert의 포맷과 통신하는 방법을 IDMEF에서 표준화 • Analyzer와 manager는 별개의 구성요소로 가정하고, 서로간에 TCP/IP 네트워크를 통하여 통신한다고 가정

10. 요구사항 • 일반 요구사항 • 메시지 포맷 요구사항 • IDMEF 통신프로토콜 (IDP) 요구사항 • 메시지 내용 및 의미 요구사항 • 이벤트 정의 및 정의절차 요구사항

11. 일반 요구사항 • IDMEF는 기존에 출간된 RFC들을 참조하고 사용해야 함 • IDMEF는 IPv4와 IPv6의 구현을 포함하는 환경에서 운용 가능하여야 함

12. 메시지 포맷 요구사항 • IDMEF 메시지 포맷들은 완전한 국제화와 지역화를 지원해야 함 • IDMEF 메시지는 manager에 의한 데이터의 filtering/aggregation을 지원해야 함

13. IDMEF 통신프로토콜 (IDP) 요구사항(1/2) • IDP는 메시지의 신뢰성있는 전송을 지원해야 함 • IDP는 보안을 위협하지 않으면서 방화벽 경계를 가로질러 있는 IDS 구성요소들간의 메시지 전송을 지원해야 함 • IDP는 analyzer와 manager 상호간에 인증을 제공해야 함 • IDP는 메시지 교환 동안 메시지 내용의 기밀성을 제공해야 함

14. IDMEF 통신프로토콜 (IDP) 요구사항(2/2) • IDP는 메시지 내용의 무결성을 보장해야 함 • IDP는 IDMEF 메시지의 근원지에 대한 부인봉쇄를 보장해야 함 • IDP는 서비스 거부 공격을 막을 수 있어야 함 • IDP는 메시지의 유해한 복사를 막을 수 있어야 함

15. 메시지 내용(1/5) IDMEF는 다양한 IDS들이 “어떻게 (How)”가 아닌 “무엇을(What)”을 탐지하느냐에 초점을 맞추어 설계되어야 함 Signature-based detection system Anomaly-based detection system Correlation-based detection system Network-based detection system Host-based detection system Application-based detection system

16. 메시지 내용(2/5) • IDMEF 메시지의 내용은 알려진 이벤트의 경우, 그 이벤트의 알려진 이름을 포함하여야 함 • IDMEF 메시지는 alert에 의해 보고되는 이벤트의 배경 정보를 수신자가 찾을 수 있도록 송신자에 의해 제공되는 정보를 포함하여야 함 • IDMEF 메시지는 특정의 이벤트와 관계된 추가적인 상세 데이터를 참조할 수 있어야 함(Optional) • IDMEF 메시지는 이벤트의 소스와 타겟의 식별자가 알려진 경우 그들을 포함하여야 함

17. 메시지 내용(3/5) • IDMEF 메시지는 다른 종류의 device address를 표현할 수 있어야 함 • IDMEF 메시지는 타겟상에서 이벤트의 가능한 영향력에 대한 기술을 포함하여야 함 • IDMEF 메시지는 이벤트에 대한 대응으로 analyzer에 의해 취해지는 자동적인 행위에 대한 정보를 제공하여야 함 • IDMEF 메시지는 이벤트를 보고했던 각각의 analyzer를 식별하고 찾을 수 있도록 하는 정보를 포함하여야 함

18. 메시지 내용(4/5) • IDMEF 메시지는 구현자의 식별자와 이벤트를 탐지하는 analyzer에 대한 정보를 포함해야 함 • IDMEF 메시지는 보고의 기밀성의 정도를 기술할 수 있어야 함 (Optional) • IDMEF 메시지는 다른 IDMEF 메시지와 구분될 수 있도록 독특하게 식별 가능하여야 함 • IDMEF는 각 이벤트에 대하여 alert 생성 날자와 시간을 보고해야 함 (추가적으로 이벤트 탐지 날짜와 시간도 보고할 수 있음)

19. 메시지 내용(5/5) • 시간은 다른 time zone에 있는 여러 analyzer로부터의 이벤트를 manager가 받았을 때 각 analyzer의 local time을 추론할 수 있도록 보고되어야 함 • 날짜를 보고하는 형식은 2000년에 대한 현재의 표준을 따라야 하고, 2038년을 지난후의 날짜 보고 능력도 가져야 함 • 이벤트 메시지 내의 시간의 세분성 및 정확성은 IDMEF에 의해 정의될 필요는 없음 • IDMEF 메시지는 구현자들이 특정 구현 데이터를 정의하기 위해 사용할 확장 메커니즘을 지원해야 함 (Optional) • IDMEF 메시지의 의미는 잘 정의되어야 함

20. Alert 식별자와 Alert 식별자 정의 절차 • IDMEF alert의 표준 리스트는 확장 가능하여야 함 • IDMEF 그 자체도 확장 가능하여야 함 • Alert 식별자의 표준 list는 구현자와 관리자에 의해 확장 가능하여야 함 • 새로운 alert 식별자가 정의되고 표준화되는 절차는 구현과 독립적이어야 함

21. Intrusion Alert Protocol (IAP/0.5)<draft-ietf-idwg-iap-05>

22. 개 요 • 정 의 IAP는 IP 네트워크 상에서 침입탐지 구성 요소들 사이 (sensor/analyzers 와 managers)에 침입 경보 데이터 (Intrusion alert data)를 교환하기 위한 응용 계층의 프로토콜 • 목 적 • 신중을 요하는 alert data를 IP 네트워크를 통해 전달하기 위해 필수적인 전송 및 보안 특성을 제공할 수 있도록 설계 • 응용계층에서 침입탐지 sensor/analyzers를 구성하고, 응답을 보낼 수 있도록 설계 • IAP는 수송계층 프로토콜로 TCP를 사용

23. Operation (1/2) • Sensor/analyzer가 alert data를 manager 에게 전송 • Sensor/analyzer : 잠재적인 침입을 감지하고 alert data를 만듬 • Manager : Alert data를 받아서 운용자에게 보여 주거나, 데이터베이스에 기록하거나, 적절한 조치를 취함

24. Operation (2/2) SA M SA P G M The native protocol supported by M IAP IAP • The simplest case : • More than one intermediaries : SA : Sensor/Analyzer, M : Manager P : Proxy, G : Gateway

25. IAP Communication Model • IAP 통신은 TCP 상에서 발생함 • TCP 연결은 HTTP와 유사한 request/response를 전달함 (차이: Initiator가 SA/M 가능) • Phases • Setup phase • Data phase • Proxies • IAP 식별자를 가지고 있지 않음 • 내용을 이해하지 않고 단지 중계함 • Alert의 보안 요소에 영향을 주지 않으며 Rewrite 가능

26. IAP Setup Phase (1/2) • TCP setup • iap-connect-request/iap-response (success : 200, failure : 403) • Proxy : iap-proxy-via를 덧붙이고, receiving entity로 넘겨줌 • Security setup • iap-upgrade-request/iap-response가 연결의 보안을 upgrade 하기 위해 사용됨 • Handshake for TLS 1.0 protocol : 프로토콜의 버전, 암호 알고리즘, 상호 인증을 협상하고 공개키 생성 • TLS handshake는 TLS connection originator에 의해 시작 • Channel setup • TLS record layer를 사용하여 데이터 전달, 공격 차단 • iap-channel-setup-request/iap-response를 이용하여 IAP 버전을 확인하고, 데이터를 전달할 payload의 종류를 결정

27. IAP Setup Phase (2/2) • Secured data transport • 인코드된 IDMEF alerts가 TLS record layer 상에서 sensor/analyzer에 의해 manager로 전달됨 • Termination • Sender: TLS close-notify alert을 보냄 • Recipient: 응답으로 close-notify alert을 보냄

28. Analyzer Proxy Manager [ Setup Phase] iap-connect-request iap-connect-request [Proxy is now a transparent forwarding agent] iap-response iap-response iap-upgrade-request iap-response (TLS handshake negotiation initiated by analyzer) [TLS handshake completed : data sent using the TLS record layer] iap-channel-setup-request iap-response [Data Phase] iap-content iap-response

29. IAP Wire Protocol (1/6) • IAP syntax는 HTTP/1.1과 유사 (request/response 프로토콜) • Request/response는 CRLF로 끝남 • IAP 메시지 iap-message=(iap-request | iap-response) • Version iap-version = “ IAP/0.5 ” • TCP connection initiator의 역할 sender-receiver = “ Sender ” | “ Receiver ”

30. IAP Wire Protocol (2/6) iap-request-start-line CRLF [message-body] *(message-header) • IAP request iap-reuest-start-line = ( iap-connect-request | iap-upgrade-request iap-channel-setup-request | iap-content-request)

31. IAP Wire Protocol (3/6) “CONNECT” SP HOST “:” port SP iap-version CRLF “PUT” SP iap-config-url SP iap-version CRLF “/iap/config” • iap-connect-request • iap-upgrade-request • Message-header에 포함되어야 하는 내용 “Upgrade: TLS/1.0” CRLF

32. IAP Wire Protocol (4/6) “PUT” SP iap-config-url SP iap-version CRLF “IAP-Version: 0.5” CRLF “IAP-Role: ” SP (“Sender”|”Receiver”) CRLF • iap-channel-setup-request • Message-header에 포함되어야 하는 내용

33. IAP Wire Protocol (5/6) “PUT” SP iap-config-url SP iap-version CRLF “/iap/alert” “Content-Type: ” “Content-Length: ” SP SP “Appl./xml” +DIGIT CRLF CRLF • iap-content-request • Message-header에 포함되어야 하는 내용 • Content Length • Content Type

34. IAP Wire Protocol (6/6) iap-response-start-line CRLF [message-body] *(message-header) iap-version SP 3*DIGIT CRLF • IAP Responses

35. Scenario • Simple analyzer • 단지 연결만을 초기화하고, 한번에 하나의 manager와 연결이 가능함 • Manager의 IP주소와 인증서의 명세서를 포함 • Simple analyzer with proxy • Proxy의 IP 주소를 포함 • Proxy는 manager의 주소를 포함 • Proxy는 TLS handshake에 참여하지 않음 • Manager design considerations • 복수의 sensor/analyzer로부터의 연결을 받아들일 수 있어야 함

36. Implementation Consideration(1/2) • TCP connection initiation • SA는 보안경계 밖에 있고, M은 안에 있을 때 => M이 초기화 • Service provider가 관리하는 remote SA -> SA는 우선 경계에 있는 proxy에 접속한 후 M에 연결 • Urgent Data • IAP를 사용하는 entity는 TCP 계층에서의 urgent data를 사용해서는 안됨 • 종단은 urgent data를 받으면 그것을 무시해야하고,연결을 종료할 수도 있음 • TLS/1.0 프로토콜을 사용해야 함 • 이전 버전 프로토콜과의 협상을 거부해야 함

37. Implementation Consideration(2/2) • Sensor/analyzer의 인증이 필수적임 • TLS handshake동안 인증 내용을 검증함 • 공개키 인증서에 기반하여 IAP 클라이언트와 서버는 서로의 identity를 검증할 수 있어야 함 • 악의적으로 IAP 세션을 종료시키려는 외부의 공격 가능성 때문에, TLS close-notify alert을 받지 못했다면 TLS session을 재개할 수 있어야 함

38. Security Considerations • Fast unreliable delivery => SNMP trap을 이용하여 alert을 표현 가능 • TCP가 연결설정을 위해 3-message handshake 사용시 서비스 거부 공격 가능 • 노드에 접속이 허락된 IP 주소를 제한 • 각각의 알려진 peer에 허가된 연결의 수를 제한 • 알려진 peer들의 집합에 허가된 연결의 수를 제한 • pkix WG에서 정의하고 있는 공개키 메커니즘을 사용 가능 • 메시지의 길이를 이용하여 alert의 종류 식별 가능 => 데이터를 pad하여 메시지 길이가 특정 분포가 되게 함 • Proxy는 보안 정책을 파괴할 수 없도록 설계되어야 함

39. The Intrusion Detection Exchange Protocol (IDXP)<draft-ietf-idwg-beep-idxp-01>

40. 개 요 • 침입탐지 엔티티 사이에 데이터를 교환하기 위한 응용계층 프로토콜 • BEEP (Blocks Extensible Exchange Protocol) profile에 기반을 둠 • 연결지향 프로토콜 위에서 상호인증, 무결성, 기밀성을 제공 • IDMEF 메시지, unstructured text, binary data의 교환을 지원 • 여러 개의 Beep Session 생성 가능 • 하나의 Beep session에 여러 개의 Beep channel 사용 가능

41. Connection Provisioning (1/3) • Proxy가 없는 경우 [1] ‘initial’ initiates a transport connection to ‘final’, Triggering the exchange of BEEP greeting messages. [2] both entities negotiate the use of a BEEP security profile. [3] both entities negotiate the use of the IDXP profile.

42. Connection Provisioning (2/3) • Proxy가 있는 경우

43. Connection Provisioning (3/3) [1] Instead of immediately acknowledging the request from ‘initial’ to start TUNNEL, ‘proxy1’ attempts to establish use of TUNNEL with ‘proxy2’. ‘proxy2’ also delays its acknowledgment to ‘proxy1’. [2] ‘final’ acknowledges the request from ‘proxy2’ to start TUNNEL, and this acknowledgment propagates back to ‘initial’ so that a TUNNEL application-layer tunnel is established from ‘initial’ to ‘final’

44. Data Transfer (1/2) • Single BEEP Channel Note that the arrowhead for the BEEP channel using the IDXP profile points from client to server.

45. Data Transfer (2/2) • Multiple BEEP Channels

46. The Tunnel Profile • Beep peer들이 응용계층 터널을 형성하도록 돕기 위한 메커니즘을 제공하는 Beep profile • Peer들은 source route를 기술하는 터널 요소를 교환함 • 권한을 부여받은 사용자가 firewall을 통해 서비스에 접근할 수 있도록 함 • SASL을 통해 협상된 사용자 ID에 기초하여 서버 밖으로의 연결을 제한함 • 양 종단간에 연결이 설정되면, 터널링 프록시는 더 이상의 데이터 번역을 하지 않음 • 프록시가 교환되는 정보에 접근할 수 없다는 보장하에 양 종단간에 인증 정보를 교환하는 TLS 협상을 함

47. IDMEF XML Document Type Definition • XML DTD • XML의 element, attribute, value를 정의 • XML DTD와 Data Model의 통합 • XML은 IDMEF의 필수 요구사항을 만족 • 메시지 포맷이 국제화/지역화를 지원 • 메시지 포맷이 filtering/aggregation을 지원 • IDMEF의 alert 메시지를 XML로 구현함

48. IDMEF Comparison of SMI and XML Implementations • SMI : MIB에서 사용하는 datatype을 식별하고, MIB 자원의 표현 및 명명하는 방법 규정 • 2000년 2월 회의에서 XML 채택 • XML의 확장성 • XML은 텍스트 기반 => 용이한 압축과 적은 용량 • XML은 표준 및 제조업자들이 지원하는 Tell-only 방식에 적합

49. 결 론 • IDS의 사용 확산 추세 • 다양한 IDS간의 상호운용성 확보를 위한 표준화 시급 => IDWG의 역할 • 표준에 기반한 IDS 개발 • IETF 등의 국제 표준화 기구에 의견 반영을 통한 국내 기술의 국제화