1 / 51

IDS 표준화동향

IDS 표준화동향. 2000. 12. 8 이화여자대학교 컴퓨터학과 채 기 준 kjchae@ewha.ac.kr. 목 차. IDWG 개요 Intrusion Detection Exchange Requirements Intrusion Detection Exchange Format Data Model IAP: Intrusion Alert Protocol 결 론. IDWG 개요 (1/3). Chairs: Michael Erlinger ( mike@cs.hmc.edu )

genera
Download Presentation

IDS 표준화동향

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IDS 표준화동향 2000. 12. 8 이화여자대학교 컴퓨터학과 채 기 준 kjchae@ewha.ac.kr

  2. 목 차 • IDWG 개요 • Intrusion Detection Exchange Requirements • Intrusion Detection Exchange Format Data Model • IAP: Intrusion Alert Protocol • 결 론

  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 • Intrusion Detection Exchange Format Data Model • IAP: Intrusion Alert Protocol • 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-02.txt>

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

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

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

  10. 요구사항 • 일반 요구사항 • 메시지 포맷 요구사항 • 통신메커니즘 요구사항 • 메시지 내용 및 의미 요구사항 • 이벤트 정의 및 정의절차 요구사항

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

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

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

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

  15. IDEF 메시지는 현재와 미래에 유용할 모든 종류의 침입탐지 메커니즘을 포함 해야 함 Signature-based detection system Anomaly-based detection system Correlation-based detection system Network-based detection system Host-based detection system Application-based detection system 메시지 내용(1/5)

  16. 메시지 내용(2/5) • IDEF 메시지의 내용은 알려진 이벤트의 경우, 그 이벤트의 알려진 이름을 포함하여야 함 • IDEF 메시지는 포함되는 이벤트와 관련된 어떤 보안적 상황들을 추론할 수 있어야 함 • IDEF 메시지는 특정의 이벤트와 관계된 추가적인 상세 데이터를 참조할 수 있어야 함(Optional) • IDEF 메시지는 이벤트의 소스와 타겟의 식별자가 알려진 경우 그들을 포함하여야 함

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

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

  19. 메시지 내용(5/5) • 시간은 메시지를 생성하는 시스템상의 현지시간과 time zone offset으로 보고되어야 함 • 날짜를 보고하는 형식은 2000년에 대한 현재의 표준을 따라야 하고, 2038년을 지난후의 날짜 보고 능력도 가져야 함 • 이벤트 메시지 내의 시간의 세분성은 IDEF에 의해 정의될 필요는 없음 • IDEF 메시지는 구현자들이 특정 구현 데이터를 정의하기 위해 사용할 확장 메커니즘을 지원해야 함 (Optional) • IDEF 메시지의 의미는 잘 정의되어야 함

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

  21. Intrusion Detection Exchange Format Data Model<draft-ietf-idwg-data-model-03.txt>

  22. 개 요 (1/2) • IDEF를 위해 제안된 data model 정의 IDS에서 사용되는 정보 (alert)를 표현하기 위한 data model 기술 • Object-oriented model을 제안 (1) Alert 정보가 다양함 ☞ Aggregation/subclassing을 통한 확장 (2) Tool 환경이 다름 (network traffic/OS logs/application audit info.) ☞ 여러 data source들을 수용하는 support class들을 정의 (3) Tool 능력이 다름 (lightweight / complex tool) ☞ Subclassing/association을 통한 확장 (4) 운영 환경이 다름 (network/operating system) ☞ NODE/SERVICE support class를 이용하여 보고의 유연성 제공 (5) 제조업자들의 목적이 다름 ☞ OO 방법을 이용하여 alert에 대한 좀 더 많은 정보를 제공하기 위한 유연성 제공

  23. 개 요 (2/2) • Design goals • Representing events • Analyzer/sensor의 능력에 따라 simple/complex alert 생성 • Alert을 표현하는 표준화된 data model 제공 • Content driven • 컴퓨터 취약성을 분류하고 이름을 붙이는 것은 매우 어렵고 주관적임 • Data model은 명확해야 함 • Relationship between alerts • Alert은 여러 level로 전송 가능 (simple/complex alerts) • Low level과 high level alert 사이의 관계를 기술하는 방법을 제공하여야 함

  24. Data analysis (1/3) • 다양한 IDS에 의해 수집된 data들을 비교 • 5개의 Network-based vendors • 3개의 Host-based vendors • 1개의 Anomaly-based vendor 참여 • IDS 메커니즘 별 common/unique data elements 조사 • Common data elements • NB : Source/Dest. IP addr., Source/Dest. port number, Protocol, Priority, Time, Packet data, String/Pattern, SA ID • HB : Time, Attack source, Destination, Event/Activity naming • Unique data elements • NB : Number of attacks, Data collected on attack 등 • HB : Policy, System software ID, Process ID, Priority level 등

  25. Data analysis (2/3) • 다섯 가지 attack을 당했을 때, 3개의 다른 IDS들이 보고한 내용을 보여줌 • Port scan attack • Host가 제공하는 서비스들을 알아내는 예비적인 attack • IP spoofing • Originator의 IP 주소를 속이는 attack • SYN flood attack • 시스템 자원을 고갈시켜 호스트가 connection request에 응답하는 것을 막는 서비스 거부 공격 • Buffer overflow • 들어오는 data의 size boundary를 적절히 check하지 못하게 함 • PHF attack • Apache 웹서버의 초기 버전에 있는 침입에 취약한 PHF script를 악용

  26. Data analysis (3/3) • 분석 요약 • 같은 attack에 대해서 다른 IDS들에 의해 보고되는 정보는 상당히 다를 수 있음 • Data model은 alert을 기술하는데 있어 공통적으로 중요하다고 여겨지는 정보와 IDS vendor에 의해 제공되는 부가적인 정보 사이에 균형을 이루어야 함 • Data model은 support class를 이용하여 sensor가 같은 종류의 정보를 다른 방식 (names/formats)으로 보고하는 문제를 해결함 • Data model은 alert의 attribute 또는 별도의 alert으로 대책 정보를 전달할 수 있어야 함

  27. Data model (1/9) • UML(Universal Modeling Language)을 이용하여 기술 • Entity와 그들의 관계를 표현하기 위한 framework 제공 • Entity를 class로 정의 • Class를 관련된 attribute로 식별 • 두개의 관계 (relationship)를 사용 • Inheritance (↑) : superclass/subclass type “is-a” or “kind-of” relationship • Aggregation (<>) : “part-of” relationship multiplicity indicators 사용 * Multiplicity indicators : class에 연결된 object 수 1 = Exactly One 0..1 = Zero or One 0..* = Zero or More 5..8 = Specific Range (5,6,7 & 8) 1..* = One or More

  28. Data model (2/9) • Overview • ALERT class : main component • ANALYZER class : alert의 sender • CLASSIFICATION class : alert의 subject • Zero or more TARGET/SOURCE class • Subclassing을 통해 추가적인 alert data 포함 가능 • Data model은 alert이 어떻게 분류되고 식별되는지를 명시하는 것이 아니라, 일단 alert type이 결정되면 그 alert을 포맷팅하는 표준 구조를 제공

  29. Data model (3/9) • Attribute의 Types • BOOLEAN: TRUE/FALSE • INTEGER • CHARACTER • STRING • BYTE: 8 bits, no parity • TIME: 시간을 나타내는 structure/schema • ENUM: INTEGER-based enumerated type

  30. 1 ANALYZER ALERT <>-------- 0..1 USER ----- 1..* ---------------- CLASSIFICATION <>-------- 0..1 ----- PROCESS 0..* 0..1 0..1 <>-------- <>------ NODE <>------ SERVICE TARGET 0..* 0..1 SOURCE <>------ NODE 0..1 USER <>-------- <>------ ------- 0..1 ------ PROCESS Data model (4/9)

  31. Data model (5/9) • Core of the data model • ALERT class : central component of the data model • TOOLALERT class : attack tool이나 trojan horse의 사용과 관련된 추가적인 정보 제공 • CORRELATIONALERT class : alert 정보와 상호 관련이 있는 추가적인 정보 제공 • OVERFLOWALERT class : overflow attack과 관련된 추가적인 정보 제공 • ANALYZER class : alert을 제공하는 analyzer를 identify • CLASSIFICATION class : alert과 관련된 취약성을 명명 • TARGET class : alert의 target에 대한 정보 제공 • SOURCE class : alert의 (possible) source 정보 제공

  32. 1 ANALYZER ALERT <>-------- INTEGER ident NODE host PROCESS process INTEGER version=1 INTEGER alertID ENUM impact TIME time 1..* CLASSIFICATION ENUM origin STRING name STRING url <>------------------------------------- 0..* <>------- TARGET 0..* <>------- SOURCE /_\ -------- ----------------------------------------------------- ------ ----- TOOLALERT OVERFLOWALERT CORRELATIONALERT STRING name STRING command INTEGER[] alertIDs INTEGER size BYTE buffer STRING program INTEGER[] alertIDs Data model (6/9)

  33. Data model (7/9) • Support classes : 중요한 역할을 수행하는 entities • IDENT class : 모든 support class들의 superclass. Analyzer와 manager에 의해 미리 정의된 object에 대한 reference 제공 • ADDRESS class : 주소 정보 제공 (N/W, H/W, Appl. Addr.) • USER class : 사용자를 identify하는 다양한 방법을 제공 • NODE class : 호스트나 네트워크 상의 장비를 identify 하는 다양한 방법을 제공 • PROCESS class : 실행중인 프로세스들에 대한 정보 수집 • SERVICE class : 네트워크 상에서 수행되는 네트워크 서비스 요구를 identify • WEBSERVICE class : 웹 트래픽과 관련된 추가적인 정보 제공 • SNMPSERVICE class : SNMP 트래픽과 관련된 추가적인 정보 제공

  34. Data model (8/9) IDENT INTEGER ident /_\ ------ ------------------- ----------------------- ----------------------- --- ---------------------- --- --------- PROCESS SERVICE NODE 0..* INTEGER pid STRING name STRING path STRING[] arguments STRING[] environ STRING name INTEGER dport INTEGER sport STRING protocol STRING name STRING location INTEGER domain 0..* <>---- ADDRESS 0..* - INTEGER category STRING address STRING netmask ------------- /_\ --- USER ------------------- --- - INTEGER category STRING name INTEGER uid STRING group INTEGER gid STRING serialID <>-- WEBSERVICE SNMPSERVICE STRING url STRING cgi STRING method STRING args STRING Oid STRING Community STRING command

  35. Data model (9/9) • Data model의 확장 • Alert과 관련된 추가적인 정보를 전달하기 위해 vendor들에 의해 확장 가능하여야 함 • Aggregation에 의한 확장 •기존의 class들 중 하나에 새 class를 aggregate 함 예) Associate NAME class with ALERT class • Subclassing에 의한 확장 • Model에 의해 정의된 class들 중 하나를 specialize 함 예) Specialize SERVICE class into WEBSERVICE class

  36. Example • Teardrop attack 공격자가 변칙의 조각화된 패킷을 전송하는 서비스 거부 공격 Alert.version = 1 Alert.alertID = 14285812 Alert.impact = 6 Alert.time = 1999/12/02 10:01:25.34125 UTC+2 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 3 Alert.Classification[0].name = GENERIC-MAP-NOMATCH Alert.Classification[0].url = iap://my.ids.vendor/doc/teardrop Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.231.121 Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 222.121.111.112

  37. Security considerations • 통신하는 entity들 사이에 데이터를 전송하기 위해 사용되는 수송 프로토콜은 안전해야 함 • Data model 자체는 security consideration을 가지고 있지 않음

  38. Intrusion Alert Protocol (IAP/0.3)<draft-ietf-idwg-iap-01.txt>

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

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

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

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

  43. 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 TLS 1.0 protocol : 프로토콜의 버전, 암호 알고리즘, 상호 인증을 협상하고 공개키 생성 (analyzer가 시작) • Channel setup • TLS record layer를 사용하여 데이터 전달, 공격 차단 • iap-channel-setup-request/iap-response를 이용하여 IAP 버전을 확인하고, 데이터를 전달할 payload의 종류를 결정

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

  45. IAP Wire Protocol-Syntax • IAP는 IDEF alert을 보내기 위해 HTTP/1.1 syntax의 일부를 사용함 (단, request/response는 setup phase 동안 IAP version number로 prefix 됨) • Request/response는 CRLF로 끝남 • IAP 메시지 iap-message=(iap-connect-request | iap-upgrade- request | iap-channel-request | iap-content | iap-response) CRLF • Version iap-t-version = “ IAP/0.3 ” • TCP connection initiator의 역할 sender-receiver = “ Sender ” | “ Receiver ”

  46. version SP 3DIGIT CRLF Iap-t-connect-request (iap-t-via)* version SP “Via:” SP host CRLF version SP “CONNECT” SP host CRLF version SP “Upgrade:TLS/1.0” CRLF IAP Wire Protocol –메시지 (1/2) • iap-response • iap-connect-request • iap-upgrade-request

  47. version SP “IAP-Version:0.3” CRLF “IAP-Role:” SP sender/receiver CRLF iap-t-content-header CRLF iap-t-content-body CRLF iap-content-type Iap-transfer-encoding “Content-Length:” SP +DIGIT CRLF “Content-Type:” SP “application/x-idef-alert” CRLF IAP Wire Protocol –메시지 (2/2) • iap-channel-setup-request • iap-content

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

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

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

More Related