Transcript Security Policy Protocol

IDS 표준화동향
2000. 12. 8
이화여자대학교 컴퓨터학과
채 기 준
[email protected]
목
차
IDWG 개요
Intrusion Detection Exchange
Requirements
Intrusion Detection Exchange Format
Data Model
IAP: Intrusion Alert Protocol
결 론
정보통신연구실
2
IDWG 개요(1/3)
Chairs:
 Michael Erlinger ([email protected])
 Stuart Staniford-Chen
([email protected])
제 43차 회의 시 첫 모임 (98. 12)
General Discussion:[email protected]
To Subscribe: [email protected]
Archive: http://www.semper.org/idwg-public/
정보통신연구실
3
IDWG 개요 (2/3)
목적
IDS와 대응 시스템, 그리고 이들과 상호 작동하는
관리시스템 사이의 정보를 공유하기 위한 데이터
포맷 및 교환 절차에 대하여 정의
WG의 Outputs
 Requirements documents
 Common intrusion language specification
(Data formats)
 Framework documents
정보통신연구실
4
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
정보통신연구실
5
Intrusion Detection Message
Exchange Requirements
<draft-ietf-idwg-requirements-02.txt>
개요
IDS, 대응 시스템, 관리 시스템 사이의
통신을 위한 high-level 요구사항을 기
술함 (이론적 해석 및 시나리오 포함)
IDEF
IDS가 의심스럽다고 간주하는 이벤트를 보
고하기 위하여 사용하는 표준 포맷
정보통신연구실
7
IDS 용어 및 관계
Data
Source
Operator
Activity
Sensor
Notification
Event
Response
Analyzer
Alert
Manager
Security
Policy
Administrator
정보통신연구실
8
구조상의 가정들
Analyzer는 sensor에 의해 수집된 의심스러
운 이벤트에 대하여 어떻게 할 것인가를 결정
하고, manager에게 alert을 보냄
Alert의 포맷과 통신하는 방법을 IDEF에서 표
준화
Analyzer와 manager는 별개의 구성요소로 가
정하고, 서로간에 TCP/IP 네트워크를 통하여
통신한다고 가정
정보통신연구실
9
요구사항
일반 요구사항
메시지 포맷 요구사항
통신메커니즘 요구사항
메시지 내용 및 의미 요구사항
이벤트 정의 및 정의절차 요구사항
정보통신연구실
10
일반 요구사항
IDEF는 기존에 출간된 RFC들을 참조하
고 사용해야 함
IDEF는 IPv4와 IPv6의 구현을 포함하는
환경에서 운용 가능하여야 함
정보통신연구실
11
메시지 포맷 요구사항
IDEF 메시지 포맷들은 완전한 국제화와
지역화를 지원해야 함
IDEF 메시지는 manager에 의한 데이터
의 filtering/aggregation을 지원해야 함
정보통신연구실
12
통신메커니즘 요구사항(1/2)
IDEF는 메시지의 신뢰성있는 전송을 지원해
야함
IDEF는 보안을 위협하지 않으면서 방화벽 경
계를 가로질러 있는 IDS 구성요소들간의 메시
지 전송을 지원해야 함
IDEF는 analyzer와 manager 상호간에 인증
을 제공해야 함
IDEF는 메시지 교환 동안 메시지 내용의 기밀
성을 제공해야 함
정보통신연구실
13
통신메커니즘 요구사항(2/2)
IDEF 메시지 내용의 무결성을 보장해야
함
IDEF 통신 메커니즘은 IDEF 메시지의
근원지에 대한 부인봉쇄를 보장해야 함
IDEF 통신 메커니즘은 서비스 거부 공
격을 막을 수 있어야 함
IDEF 통신 메커니즘은 메시지의 유해한
복사를 막을 수 있어야 함
정보통신연구실
14
메시지 내용(1/5)
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
정보통신연구실
15
메시지 내용(2/5)
IDEF 메시지의 내용은 알려진 이벤트의 경우,
그 이벤트의 알려진 이름을 포함하여야 함
IDEF 메시지는 포함되는 이벤트와 관련된 어
떤 보안적 상황들을 추론할 수 있어야 함
IDEF 메시지는 특정의 이벤트와 관계된 추가
적인 상세 데이터를 참조할 수 있어야 함
(Optional)
IDEF 메시지는 이벤트의 소스와 타겟의 식별
자가 알려진 경우 그들을 포함하여야 함
정보통신연구실
16
메시지 내용(3/5)
IDEF 메시지는 다른 종류의 device address
를 표현할 수 있어야 함
IDEF 메시지는 타겟상에서 이벤트의 가능한
영향력에 대한 기술을 포함하여야 함
IDEF 메시지는 이벤트에 대한 대응으로
analyzer에 의해 취해지는 자동적인 행위에
대한 정보를 제공하여야 함
IDEF 메시지는 이벤트를 보고했던 각각의
analyzer를 식별하고 찾을 수 있도록 하는 정
보를 포함하여야 함
정보통신연구실
17
메시지 내용(4/5)
IDEF 메시지는 구현자의 식별자와 이벤트를
탐지하는 도구을 포함해야 함
IDEF 메시지는 보고의 기밀성의 정도를 기술
할 수 있어야 함 (Optional)
IDEF 메시지는 다른 IDEF 메시지와 구분될
수 있도록 독특하게 식별 가능하여야 함
IDEF는 각 이벤트에 대하여 alert 생성 날자와
시간을 보고해야 함 (추가적으로 이벤트 탐지
날짜와 시간도 보고할 수 있음)
정보통신연구실
18
메시지 내용(5/5)
시간은 메시지를 생성하는 시스템상의 현지시
간과 time zone offset으로 보고되어야 함
날짜를 보고하는 형식은 2000년에 대한 현재
의 표준을 따라야 하고, 2038년을 지난후의
날짜 보고 능력도 가져야 함
이벤트 메시지 내의 시간의 세분성은 IDEF에
의해 정의될 필요는 없음
IDEF 메시지는 구현자들이 특정 구현 데이터
를 정의하기 위해 사용할 확장 메커니즘을 지
원해야 함 (Optional)
IDEF 메시지의 의미는 잘 정의되어야 함
정보통신연구실
19
Alert 식별자와 Alert 식별자
정의 절차
IDEF alert의 표준 리스트는 확장 가능
하여야 함
IDEF 그 자체도 확장 가능하여야 함
Alert 식별자의 표준 list는 구현자와 관
리자에 의해 확장 가능하여야 함
새로운 alert 식별자가 정의되고 표준화
되는 절차는 구현과 독립적이어야 함
정보통신연구실
20
Intrusion Detection Exchange
Format Data Model
<draft-ietf-idwg-data-model-03.txt>
개 요 (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에 대한 좀 더 많은 정보를 제공하기 위한
유연성 제공
정보통신연구실
22
개 요 (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 사이의 관계를 기술하는 방법을
제공하여야 함
정보통신연구실
23
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 등
정보통신연구실
24
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
를 악용
정보통신연구실
25
Data analysis (3/3)
분석 요약
 같은 attack에 대해서 다른 IDS들에 의해 보고되
는 정보는 상당히 다를 수 있음
 Data model은 alert을 기술하는데 있어 공통적으
로 중요하다고 여겨지는 정보와 IDS vendor에 의
해 제공되는 부가적인 정보 사이에 균형을 이루어
야함
 Data model은 support class를 이용하여 sensor
가 같은 종류의 정보를 다른 방식 (names/formats)
으로 보고하는 문제를 해결함
 Data model은 alert의 attribute 또는 별도의 alert
으로 대책 정보를 전달할 수 있어야 함
정보통신연구실
26
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..* = Zero or More
1..* = One or More
정보통신연구실
0..1 = Zero or One
5..8 = Specific Range (5,6,7 & 8)
27
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을 포맷팅하는 표준 구조를
제공
정보통신연구실
28
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
정보통신연구실
29
Data model (4/9)
1
ALERT <>--------
ANALYZER
0..1
<>-------- CLASSIFICATION
0..*
<>--------
0..*
----- PROCESS
SOURCE
<>------
0..1
<>------
0..1
NODE
<>------ SERVICE
NODE
<>------
0..1
-------
<>--------
USER
0..1
0..1
TARGET
----------------
-----
1..*
USER
0..1
------ PROCESS
정보통신연구실
30
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 정보 제공
정보통신연구실
31
Data model (6/9)
1
ALERT
<>--------
INTEGER
INTEGER
ENUM
TIME
version=1
alertID
impact
time
ANALYZER
INTEGER ident
NODE host
PROCESS process
1..* CLASSIFICATION
<>-------------------------------------
ENUM origin
STRING name
STRING url
0..*
<>------- TARGET
0..*
<>------- SOURCE
STRING name
STRING command
INTEGER[] alertIDs
정보통신연구실
CORRELATIONALERT
INTEGER[] alertIDs
-----
TOOLALERT
------
--------
/_\
-----------------------------------------------------
OVERFLOWALERT
INTEGER size
BYTE buffer
STRING program
32
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 트래픽과 관련된 추가적인 정보
제공
정보통신연구실
33
Data model (8/9)
IDENT
INTEGER ident
/_\
------
STRING
INTEGER
INTEGER
STRING
name
dport
sport
protocol
/_\
---
-
-------------------
WEBSERVICE
SNMPSERVICE
STRING
STRING
STRING
STRING
STRING Oid
STRING Community
STRING command
url
cgi
method
args
정보통신연구실
STRING name
STRING location
INTEGER domain
--- USER
INTEGER
STRING
INTEGER
STRING
INTEGER
STRING
category
name
uid
group
gid
serialID
0..*
---------
pid
name
path
arguments
environ
NODE
0..*
<>---- ADDRESS
0..*-
-------------
INTEGER
STRING
STRING
STRING[]
STRING[]
SERVICE
---
PROCESS
----------------------
---
------------------- ----------------------- -----------------------
INTEGER category
STRING address
STRING netmask
<>--
34
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
정보통신연구실
35
Example
Teardrop attack
공격자가 변칙의 조각화된 패킷을 전송하는 서비스 거부 공격
Alert.version
=
Alert.alertID
=
Alert.impact
=
Alert.time
=
Alert.Analyzer.ident
=
Alert.Classification[0].origin
=
Alert.Classification[0].name
=
Alert.Classification[0].url
=
Alert.Target[0].Node.Address.category
Alert.Target[0].Node.Address.data
Alert.Source[0].Node.Address.category
Alert.Source[0].Node.Address.data
정보통신연구실
1
14285812
6
1999/12/02 10:01:25.34125 UTC+2
123123123
3
GENERIC-MAP-NOMATCH
iap://my.ids.vendor/doc/teardrop
= 2
= 123.234.231.121
= 2
= 222.121.111.112
36
Security considerations
통신하는 entity들 사이에 데이터를 전
송하기 위해 사용되는 수송 프로토콜은
안전해야 함
Data model 자체는 security
consideration을 가지고 있지 않음
정보통신연구실
37
Intrusion Alert Protocol
(IAP/0.3)
<draft-ietf-idwg-iap-01.txt>
개요
정 의
IAP는 IP 네트워크 상에서 침입탐지 구성 요소들 사이
(sensor/analyzers 와 managers)에 침입 경보 데이터
(Intrusion alert data)를 교환하기 위한 응용 계층의 프
로토콜
목 적
 신중을 요하는 alert data를 IP 네트워크를 통해 전달
하기 위해 필수적인 전송 및 보안 특성을 제공할 수 있
도록 설계
 응용계층에서 침입탐지 sensor/analyzers를 구성하고,
응답을 보낼 수 있도록 설계
IAP는 수송계층 프로토콜로 TCP를 사용
정보통신연구실
39
Operation (1/2)
Sensor/analyzer가 alert data를 manager
에게 전송
 Sensor/analyzer : 잠재적인 침입을 감지하고
alert data를 만듬
 Manager : Alert data를 받아서 운용자에게 보여
주거나, 데이터베이스에 기록하거나,
적절한 조치를 취함
정보통신연구실
40
Operation (2/2)
The simplest case :
SA
M
More than one intermediaries :
SA
P
IAP
SA : Sensor/Analyzer,
정보통신연구실
G
IAP
M : Manager
M
The native protocol
supported by M
41
IAP Communication Model
IAP 통신은 TCP 상에서 발생함
TCP 연결은 HTTP와 유사한 request/response
를 전달함 (차이: Initiator가 SA/M 가능)
Phases
 Setup phase
 Data phase
Proxies
 IAP 식별자를 가지고 있지 않음
 내용을 이해하지 않고 단지 중계함
 Alert의 보안 요소에 영향을 주지 않으며 Rewrite 가능
정보통신연구실
42
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의 종류를 결정
정보통신연구실
43
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을
보냄
정보통신연구실
44
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-upgraderequest | iap-channel-request |
iap-content | iap-response) CRLF
 Version
iap-t-version = “ IAP/0.3 ”
 TCP connection initiator의 역할
sender-receiver = “ Sender ” | “ Receiver ”
정보통신연구실
46
IAP Wire Protocol – 메시지 (1/2)
iap-response
version
SP
3DIGIT
CRLF
iap-connect-request
Iap-t-connect-request
version
SP “CONNECT” SP
host
CRLF
(iap-t-via)*
version SP “Via:”
SP host
CRLF
iap-upgrade-request
version SP “Upgrade:TLS/1.0” CRLF
정보통신연구실
47
IAP Wire Protocol – 메시지 (2/2)
iap-channel-setup-request
version
SP “IAP-Version:0.3” CRLF “IAP-Role:”
SP sender/receiver
CRLF
iap-content
iap-t-content-header CRLF
iap-content-type
iap-t-content-body
Iap-transfer-encoding
“Content-Length:” SP
“Content-Type:” SP
정보통신연구실
CRLF
“application/x-idef-alert”
+DIGIT CRLF
CRLF
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 방식에 적합
정보통신연구실
51
결 론
IDS의 사용 확산 추세
다양한 IDS간의 상호운용성 확보를 위한
표준화 시급 => IDWG의 역할
표준에 기반한 IDS 개발
IEFT 등의 국제 표준화 기구에 의견 반영
을 통한 국내 기술의 국제화
정보통신연구실
52