KR20060042149A

KR20060042149A - 소프트웨어 취약성의 이용을 방지하기 위한 통신 필터링 방법 및 시스템

Info

Publication number: KR20060042149A
Application number: KR1020050015398A
Authority: KR
Inventors: 알프 주전매어; 천싱 구오; 다니엘 알. 시몬; 제이슨 감스; 재 헬렌 왕
Original assignee: 마이크로소프트 코포레이션
Priority date: 2004-02-24
Filing date: 2005-02-24
Publication date: 2006-05-12
Also published as: KR101109393B1; US20050198110A1; CN1728706B; JP4864333B2; EP3544259A1; CN1728706A; EP1569413B1; US7694022B2; EP1569413A3; EP1569413A2; JP2005276185A

Abstract

통신 기반 취약성의 이용으로부터 통신 프로토콜을 구현하는 애플리케이션을 보호하기 위한 방법 및 시스템이 제공된다. 보호 시스템은 특정 취약성을 노출시키는 메시지를 어떻게 인식하는지를 지정하고 취약성이 노출된 때 취할 동작을 지정하는 보호 정책을 제공한다. 보호 정책은 취약성을 노출시키는 메시지들의 시퀀스 및 이들의 페이로드 특성을 지정한다. 보호 시스템은 메시지 프로토콜 상태 머신을 이용하여 메시지들의 시퀀스를 지정할 수 있다. 애플리케이션의 메시지 프로토콜 상태 머신은 애플리케이션이 다양한 메시지를 수신할 때 애플리케이션이 전이하는 상태들을 표현한다. 보호 정책의 메시지 프로토콜 상태 머신은 취약성에 관한 애플리케이션의 메시지 프로토콜 상태 머신의 일부일 수 있다. 보호 시스템은 메시지 프로토콜 상태 머신을 이용하여 취약성을 노출시키는 상태들을 추적한다.

소프트웨어 취약성, 상태 머신, 메시지 프로토콜

Description

소프트웨어 취약성의 이용을 방지하기 위한 통신 필터링 방법 및 시스템{METHOD AND SYSTEM FOR FILTERING COMMUNICATIONS TO PREVENT EXPLOITATION OF A SOFTWARE VULNERABILITY}

도 1은 일 실시예의 보호 시스템을 나타내는 블록도.

도 2는 일 실시예에서 취약성 사양에 정의되는 메시지 프로토콜의 일부를 나타내는 상태도.

도 3은 일 실시예의 보호 시스템의 아키텍쳐를 나타내는 블록도.

도 4는 일 실시예에서 상태 머신 엔진의 처리를 나타내는 흐름도.

도 5는 일 실시예에서 취약성 사양의 테스트를 나타내는 블록도.

도 6은 일 실시예에서 취약성 사양의 생성을 나타내는 블록도.

<도면의 주요 부분에 대한 부호 설명>

110: 보호 시스템

111: 취약성 사양 저장소

112: 보호 컴포넌트

120: 애플리케이션

130: 클라이언트

140: 통신 링크

301: 정책 로더

302: 취약성 사양 저장소

303: 애플리케이션 디스패쳐

304: 세션 디스패쳐

305: 상태 머신 엔진

306: 해석기

307: 애플리케이션/세션 상태 저장소

<관련 출원의 상호 참조>

본 출원은 본 발명에 참조로서 합체된, 발명의 명칭이 "소프트웨어 취약성의 이용을 방지하기 위한 통신 필터링 방법 및 시스템"인 2004년 2월 24일자로 출원된 미국 가출원 제60/547,131호의 우선권을 주장한다.

본 발명은 애플리케이션의 취약성의 이용의 검출 및 방지에 관한 것이다.

인터넷이 컴퓨터 시스템들 간의 통신을 용이하게 하고 전자 상거래를 가능하게 하는 데 크게 성공하였지만, 인터넷에 접속된 컴퓨터 시스템들은 이들의 동작을 정지시키려고 하는 해커들에 의해 계속적인 공격을 받고 있다. 대부분의 공격은 컴퓨터 시스템 상에서 실행되는 애플리케이션 프로그램 또는 다른 컴퓨터 프로그램 의 취약성을 이용하고자 한다. 컴퓨터 시스템을 공격하는 가장 파괴적인 방법 중 하나는 컴퓨터 시스템에 "웜"을 전송하는 것이었다. 웜은 컴퓨터 시스템을 제어하고 이 컴퓨터 시스템을 이용하여 동일한 취약성을 가진 다른 컴퓨터 시스템에 대한 공격을 시작함으로써(즉 동일한 웜을 전송함으로써) 취약성을 이용하는 자체 전파 공격이다. 웜은 수신하는 컴퓨터 프로그램의 취약성을 이용하도록 설계된 메시지 또는 메시지들의 시퀀스이다. 컴퓨터 프로그램은 메시지 또는 메시지들의 수신시 웜이 컴퓨터 시스템을 제어할 수 있게 하는 소정의 동작을 수행한다.

애플리케이션의 개발자 및 컴퓨터 시스템의 관리자는 취약성을 식별하고 제거하기 위해 많은 노력과 비용을 들인다. 그러나 애플리케이션의 복잡성으로 인해, 애플리케이션이 배포되기 전에 모든 취약성을 식별하고 제거하는 것은 실제로 불가능하다. 애플리케이션이 배포된 후에 개발자는 다양한 방법으로 취약성을 알게 될 수 있다. 악의가 없는 자가 애플리케이션 내의 취약성을 식별하고 개발자에게 비밀로 통지하여, 해커가 그 취약성을 식별하고 이용하기 전에 취약성이 제거될 수 있다. 해커가 먼저 취약성을 식별한 경우, 개발자는 그것이 이용되어 종종 재앙적인 결과를 낳을 때까지 취약성을 모를 수 있다.

개발자가 어떻게 취약성을 발견하는지에 관계없이, 개발자는 일반적으로 취약성을 제거하는 "패치"를 개발하여 시스템 관리자에게 배포한다. 취약성이 아직 이용되지 않은 경우(예를 들어, 해커에게 알려지지 않을 수 있다), 개발자는 통제된 방식으로 패치를 설계하고, 구현하고, 테스트하고 배포할 수 있다. 취약성이 이미 널리 노출된 경우, 개발자는 정상적인 환경하에서 이용되는 동일한 주의 없이 서둘러 패치를 배포할 수 있다. 패치가 컴퓨터 시스템의 관리자에게 배포될 때, 관리자는 취약성을 제거하기 위한 패치의 스케쥴링 및 설치를 담당한다.

불행하게도, 관리자는 종종 다양한 이유로 취약성을 제거하기 위한 패치의 설치를 연기한다. 패치가 설치될 때, 패치가 실행되고 있는 애플리케이션 및 가능하게는 컴퓨터 시스템은 셧다운되고 재시동되어야 할 수 있다. 취약성이 조직의 성공에 중요한 애플리케이션에 존재하는 경우, 관리자는 애플리케이션을 계속 유지하고 그와 관련된 공격의 위험성을 갖고 실행하는 것과, 패치를 설치하기 위해 중요 자원을 셧다운시키는 것의 균형(tradeoff)을 분석할 필요가 있다. 어떤 관리자는 성급한 배포로 인해 패치가 적절히 테스트되지 못하여 의도하지 않은 부작용을 가질 수 있다는 두려움 때문에 패치의 설치를 미룰 수 있다. 패치가 의도하지 않은 부작용을 갖는 경우, 애플리케이션(또는 컴퓨터 시스템)은 패치 자체의 의해 셧다운될 수 있다. 관리자는 패치를 설치할 것인지를 결정할 때 의도하지 않은 부작용의 가능성을 고려할 필요가 있다. 이러한 관리자는 다른 사람들의 경험에 의해 의도하지 않은 심각한 부작용이 없다는 것을 알게 될 때까지 패치의 설치를 미룰 수 있다.

애플리케이션의 취약성의 이용을 방지하기 위해 다른 방법들이 이용될 수 있다. 예를 들어, 이용의 소스가 알려진 경우, 그 소스로부터의 모든 메시지는 애플리케이션에 도달하기 전에 인터셉트되어 폐기될 수 있다. 그러나 공격의 소스는 정확하게 식별하지 못할 수 있어, 많은 좋은 소스로부터의 메시지들도 폐기될 수 있다. 다른 예로서, 취약성을 이용하려고 하는 메시지는 애플리케이션으로 전송되 기 전에 검출되고 폐기될 수 있는 특성(예를 들어, 너무 긴 파일명)을 가질 수 있다.

취약성의 이용을 방지하기 위한 현재의 방법들은 다양한 이유로 완전히 만족스럽지 못하다. 어떤 관리자들은 정말로 취약성의 이용을 방지할 수 있을 만큼 충분히 신속하게 패치를 설치할 수 없기 때문에 패치의 설치는 완전히 만족스럽지 못하다. 더욱이, 패치 자체가 취약성의 이용보다 더 위험한 부작용을 가질 수 있다. 시도되는 이용을 식별하기 위한 메시지의 인터셉트도, 식별이 알려진 이용에 기초하고 동일 취약성의 알려지지 않은 이용을 방지할 수 없기 때문에 완전히 만족스럽지 못하다. 패치를 필요로 하지 않고 취약성의 임의의 특정 이용과 무관한 방식으로 취약성의 이용을 방지하는 것이 바람직하다.

컴포넌트의 통신 프로토콜의 조건이 언제 만족되는지를 식별하기 위한 방법 및 시스템이 제공된다. 일 실시예에서, 시스템은 통신 프로토콜의 적어도 일부(즉, 통신 프로토콜의 모델)를 지정하고 통신 프로토콜의 지정된 일부 내에 조건이 언제 만족되는지를 표시하는 사양을 제공한다. 컴포넌트에 대한 통신이 수신된 때, 시스템은 컴포넌트에 의한 통신의 처리 전에 수신된 통신이 제공된 사양에 의해 지정된 조건을 만족시키는지를 판정한다. 그러면, 시스템은 조건이 만족되는지의 여부에 따라 적당한 동작을 취할 수 있다. 예를 들어, 조건이 컴포넌트의 취약성의 노출에 관한 것인 경우, 시스템은 취약성의 노출을 방지하기 위하여, 조건이 만족된 때 컴포넌트에 통신을 제공하지 않는 동작을 취할 수 있다.

통신 기반 취약성의 이용으로부터 통신 프로토콜(예를 들어, 메시지 기반 또는 스트림 기반 프로토콜)을 구현하는 애플리케이션과 같은 컴포넌트를 보호하기 위한 방법 및 시스템이 제공된다. 일 실시예에서, 보호 시스템은 특정 취약성을 노출시키는 메시지를 어떻게 인식할 것인지를 지정하고 취약성이 노출된 때 취할 동작들을 지정하는 "보호 정책"을 제공한다. 보호 정책은 취약성을 노출시키는 메시지들의 시퀀스 및 이들의 페이로드 특성을 지정한다. 보호 시스템은 메시지 프로토콜 상태 머신을 이용하여 메시지들의 시퀀스를 지정할 수 있다. 애플리케이션의 메시지 프로토콜 상태 머신은 애플리케이션이 다양한 메시지를 수신할 때 애플리케이션이 전이하는 상태들을 표현한다. 보호 정책의 메시지 프로토콜 상태 머신은 취약성에 관한 애플리케이션의 메시지 프로토콜 상태 머신의 일부일 수 있다. 보호 시스템은 메시지 프로토콜 상태 머신을 이용하여 취약성을 노출시키는 상태들을 추적한다. 보호 정책은 현재의 상태 및 수신된 또는 현재의 메시지에 따라 수행될 동작들을 지정할 수 있다. 이러한 동작들은 소정의 조건들이 만족되는지를 판정하기 위하여 메시지의 페이로드를 검사하는 것, 메시지 프로토콜 상태 머신에 대한 다음 상태를 식별하는 것, 메시지를 폐기하는 것, 메시지의 소스로부터 분리하는 것 등을 포함할 수 있다. 보호 정책은 취약성과 관련된 메시지 프로토콜에 기초하므로 취약성의 임의의 이용과 무관하다. 따라서 보호 시스템은 취약성의 노출과 같은 조건이 검출되고 방지될 수 있도록 애플리케이션에 의해 사용되는 통신 기반 프로토콜을 모델링한다.

일 실시예에서, 보호 정책은 애플리케이션의 취약성, 및 이 취약성의 이용을 방지하기 위한 동작들을 설명한다. 보호 정책은 2개 부분을 가진다. 제1 부분은 프로토콜 상태, 이벤트, 및 사용 포트, 이벤트 타입의 위치, 세션 식별자, 및 패킷 내의 시퀀스 번호 및 메시지 경계 마커와 같은 일반적인 애플리케이션 레벨 프로토콜 정보를 정의한다. 제2 부분은 핸들러(즉, 동작들의 세트) 및 메시지 페이로드 분석 명령을 정의한다. 핸들러는 실행 시간에 실행되어 메시지 페이로드를 검사하고 임의의 취약성 이용을 식별하며 대응 조치를 취해 그 이용을 방지하거나 이용의 추후 식별을 위해 필요한 세션 정보를 기록한다. 실행 시간 전에, 보호 시스템은 핸들러 및 보호 정책의 페이로드 명령을 분석하고, 실행 시의 보다 효율적인 처리를 위해 이들을 신택스 트리에 저장한다. 보호 시스템은 보호 정책의 제1 부분 및 신택스 트리를 "취약성 사양"으로서 저장한다. 취약성 사양은 상태, 이벤트 및 핸들러의 트리플릿을 포함할 수 있다.

메시지가 애플리케이션으로 전송되기 전에 보호 시스템이 메시지를 수신한 때, 보호 시스템은 메시지에 대응하는 이벤트 및 애플리케이션의 메시지 프로토콜 상태 머신의 현재 상태를 식별한다. 이어서, 보호 시스템은 트리플릿에 의해 지시된 바와 같이 현재 상태 및 현재 이벤트와 관련된 핸들러를 식별하고 실행한다. 핸들러는 메시지를 그 페이로드를 포함하여 분석하여, 취약성 노출의 원인이 되는 특성이 존재하는지를 결정하고, 현재 상태를 메시지의 특성에 의존하는 다음 상태로 변경하고, 다른 메시지가 수신될 때 후속 결정을 행하는 데 필요한 상태 정보를 저장하고, 식별된 이용에 대한 대응 동작을 행하는 등등의 작업을 행할 수 있다. 보호 시스템이 메시지가 취약성을 노출시키는 것으로 판정하는 경우, 보호 시스템은 애플리케이션에 메시지를 제공하지 않는다. 따라서, 보호 시스템은 애플리케이션의 패치 없이 애플리케이션의 취약성의 이용을 방지한다. 더욱이, 보호 시스템은 많은 다른 메시지 기반 애플리케이션에 대해 취약성의 이용을 방지하는 데 사용될 수 있는 범용 프레임워크를 제공한다.

일 실시예에서, 보호 시스템은 네트워크 프로토콜의 전송 계층과 애플리케이션 계층 사이에서 동작한다. 그러나, 당업자는 보호 시스템이 다양한 네트워크 프로토콜 계층들과 다수의 프로토콜 계층들 사이에서 또는 그 안에서 동시에 동작할 수 있다는 것을 알 것이다. 예를 들어, 어떤 애플리케이션들은 애플리케이션이 메시지의 처리를 행하기 전에 메시지를 사전 처리하기 위한 후크들을 제공할 수 있다. 이러한 애플리케이션에서, 보호 시스템은 애플리케이션 계층에서 동작하여 애플리케이션이 메시지를 처리하기 전에 메시지를 처리할 수 있다. 보호 시스템이 취약성이 노출된 것으로 판정한 경우, 보호 시스템은 메시지를 폐기하거나, 애플리케이션을 폐기하거나, 소정의 다른 적절한 동작을 취할 수 있다.

다수의 클라이언트에게 서비스하는 애플리케이션은 어느 클라이언트가 메시지를 전송하는지를 식별하는 데 이용하기 위한 세션 식별자를 각각의 클라이언트에게 할당할 수 있다. 단일 클라이언트는 다수의 세션, 따라서 다수의 세션 식별자를 가질 수 있다. 어느 경우에나, 세션 식별자는 클라이언트의 특정 세션을 식별한다. 세션 내의 메시지들의 시퀀스는 취약성을 노출시킬 수 있다. 따라서, 보호 시스템은 세션 단위로 메시지의 상태를 추적한다. 보호 시스템은 새로운 세션이 식별된 때 새로운 상태 정보의 인스턴스를 생성한다. 각각의 메시지는 타겟 애플리케이션 및 세션을 식별한다. 메시지가 수신될 때, 보호 시스템은 메시지로부터 애플리케이션 및 세션을 식별한다. 보호 시스템은 메시지의 헤더 정보에 저장된 포트 번호에 기초하여 애플리케이션을, 세션 정보가 메시지 내의 어디에 저장되어 있는지에 대한 애플리케이션 특정 표시에 기초하여 세션을 식별할 수 있다. 애플리케이션의 취약성 사양은 이 애플리케이션과 관련된 포트 번호를 지정할 수 있으며, 이 애플리케이션의 메시지 내에 세션 식별자의 위치를 설명할 수 있다. 또한, 애플리케이션의 취약성 사양은 메시지 내에 메시지 타입의 위치 및 메시지 경계의 위치와 같은 다른 정보의 위치를 지정할 수 있다. 메시지가 세션의 첫째이면, 보호 시스템은 이 세션에 대해 상태 정보 데이타 구조를 할당할 수 있다. 애플리케이션의 취약성 사양은 메시지들 사이에서 저장될 필요가 있는 정보에 기초하여 데이타 구조를 정의할 수 있다. 보호 시스템은 상태 정보를 초기화하는데, 이는 세션의 현재 상태를 취약성 사양에 의해 정의되는 초기 상태로 설정하는 것을 포함할 수 있다. 새로운 메시지가 수신될 때마다, 보호 시스템은 애플리케이션 및 세션을 식별하고, 이 애플리케이션 및 세션에 대한 상태 정보를 검색한 후, 상태 머신 엔진을 호출하여 현재 상태 및 수신된 메시지에 지정된 이벤트에 기초하여 실행될 핸들러를 선택한다.

일 실시예에서, 보호 시스템은 단일 메시지 단위로 도달할 수 없는 애플리케이션 레벨의 메시지들을 처리한다. 단일 애플리케이션 레벨 메시지의 다수의 메시지 단위로서의 분산 도달은 TCP 혼잡 제어, 애플리케이션의 특정 메시지 처리 구현 등의 결과일 수 있다. 예를 들어, UDP 서버가 다수의 호출을 행하여 단일 애플리케이션 레벨 메시지를 수신할 수 있다. 이 경우, 보호 시스템은 애플리케이션 레벨 메시지의 다수의 메시지 단위의 도달을 인식한다. 세션 식별자 또는 메시지 타입이 단일 메시지 단위로 수신되지 않거나, 핸들러가 메시지의 처리를 끝내기에 충분한 애플리케이션 레벨 메시지가 수신되지 않은 경우, 보호 시스템은 애플리케이션 레벨 메시지가 핸들러에 의해 처리될 수 있을 때까지 각각의 메시지 단위의 필요한 부분들의 사본을 만든다. 보호 시스템은 세션 단위로 부분 메시지 정보를 저장할 수 있는데, 이는 각 세션에 대한 버퍼의 할당을 필요로 할 수 있다. 그러나 다수의 세션이 동일 소켓을 통해 전송될 때, 보호 시스템은 소켓 단위로 부분 메시지 정보를 저장할 수 있다. 소켓들은 일반적으로 다른 메시지의 임의의 부분이 동일 소켓을 통해 수신되기 전에 세션에 대한 완전한 메시지가 수신되는 특성을 갖는다. 세션들보다 적은 소켓들이 있을 수 있기 때문에, 세션 단위로 정보를 저장할 때, 보다 적은 버퍼들이 할당될 필요가 있을 수 있다. 세션 식별자가 수신되기 전에는 하나의 버퍼가 단 하나의 소켓에만 연관될 수 있다. 세션 식별자가 수신되면, 버퍼는 세션과 연관될 수 있다.

일반적으로, 보호 시스템은 부분적으로 도달한 필드들을 저장할 필요가 없으며, 수신된 애플리케이션 레벨 메시지의 전 부분을 저장할 필요도 없다. 예를 들어, 4 바이트 세션 식별자 중 2개 바이트가 수신된 경우, 보호 시스템은 이 2 바이트의 메시지만을 저장하면 된다. 보호 시스템은 애플리케이션 레벨 메시지당 하나의 필드 분석 상태를 이용하여 어느 필드가 분석되고 있는지, 얼마나 많은 바이트 가 수신되었는지를 추적할 수 있다. 보호 시스템은 메시지가 이용의 원인이 되지 않는 것으로 판정된 때에도 각각의 애플리케이션 레벨 메시지에 대해 분석되고 있는 현재 필드의 분석 상태를 유지한다. 상태가 유지되지 않은 경우, 애플리케이션 레벨 메시지의 다른 부분들이 새로운 메시지로서 취급될 수 있다. 이 경우, 해커에 의해 메시지가 가공되어, 애플리케이션의 실제 메시지 상태와 보호 시스템의 에뮬레이트된 메시지 상태 사이에 불일치가 발생할 수 있다.

보호 시스템은 순서 없이 수신되는 애플리케이션 레벨 메시지들을 순서대로 처리될 수 있도록 버퍼링할 수 있다. 예를 들어, UDP가 사용될 때, 애플리케이션 레벨 메시지는 순서 없이 수신될 수 있다. 보호 시스템은 애플리케이션에 대한 보호 정책에 지정된 바와 같이 시퀀스 번호를 이용한다. 또한, 어떤 애플리케이션 메시지 프로토콜들은 애플리케이션 레벨 메시지의 단편화 및 재결합을 허용한다. 단편들은 순서대로(예를 들어 TCP에서) 또는 순서 없이(예를 들어 UDP에서) 수신될 수 있다. 보호 시스템은 순서대로 수신된 단편들을 전술한 부분 필드 처리와 유사한 방식으로 처리할 수 있다. 단편들이 순서 없이 수신되는 경우, 보호 시스템은 이들을 저장하여 순서대로 처리할 수 있다.

일 실시예에서, 보호 시스템의 원리는 메시지 프로토콜을 향상시키는 데 이용될 수 있다. 예를 들어, 메시지 프로토콜의 소정 상태에서 인증 처리를 추가함으로써 애플리케이션의 보안성을 향상시키는 것이 바람직할 수 있다. 그러나 애플리케이션 개발자는 그렇게 하는 것이 싫을 수 있다. 이 경우, 보호 시스템과 유사한 시스템(예를 들어 인증 시스템)이 구현될 수 있다. 인증 시스템은 서버측 및 클라이언트측을 가질 수 있다. 서버측은 상태, 이벤트 및 핸들러의 사양과, 인증을 행해야 할 때 적절한 상태 및 이벤트를 식별하기 위한 상태 머신 엔진을 사용한다. 이 상태 및 이벤트에 대한 핸들러는 애플리케이션에 메시지를 제공하기 전에 클라이언트에게 공격(challenge)을 전송할 수 있다. 공격의 수신시, 인증 시스템의 클라이언트측은 공격이 수신되었음을 검출하고 적절한 응답을 전송할 수 있다. 클라이언트측은 사양 및 공격을 검출하기 위한 상태 머신 엔진을 가질 수 있다. 서버측이 응답을 수신할 때, 서버측은 응답을 확인하고, 적절한 때 메시지를 애플리케이션에 제공할 수 있다. 보다 일반적으로, 메시지 프로토콜의 상태를 추적하고 타겟 애플리케이션에 의해 처리되기 전에 원하는 처리를 행할 수 있는 일반 아키텍쳐가 제공된다. 아키텍쳐는 클라이언트 및 서버 상에 대칭적일 수 있지만, 사양은 서버 및 그의 클라이언트의 상이한 처리의 필요성으로 인해 비대칭적이다. 일반 아키텍쳐는 암호화 스킴, 메시지의 로깅, 문제의 디버깅 등을 구현하는 데 사용될 수 있다.

일 실시예에서, 보호 시스템은 메시지를 처리하기 위해 애플리케이션 프로그래밍 인터페이스(API)를 계장하여(instrumenting) 메시지를 인터셉트할 수 있다. 예를 들어, 소켓 계층 API의 수신 기능은 하부의 계장되지 않은 수신 기능을 호출한 후 메시지를 포함하는 버퍼를 보호 컴포넌트에 전송하도록 계장될 수 있다. 메시지가 취약성을 이용할 것으로 보호 컴포넌트가 판정하는 경우, 보호 컴포넌트는 메시지를 폐기하거나 통신 세션을 해제할 수 있으며, 계장된 수신 기능은 에러를 반환할 수 있다. 그렇지 않은 경우, 계장된 수신 기능은 계장되지 않은 수신 기능 이 하는 것처럼 버퍼를 반환할 수 있다. 보호 시스템은 API들의 계층 구조의 다양한 레벨에서 메시지 또는 메시지의 부분들을 인터셉트하는 데 사용될 수 있다. API들의 계층 구조는 보다 낮은 레벨의 API들을 호출하는 API들을 포함하는데, 이보다 낮은 레벨의 API들은 또한 그보다 더 낮은 레벨의 API들을 호출한다. 애플리케이션의 프로그래머는 일반적으로 최상 레벨의 API들을 호출하도록 애플리케이션을 개발한다. 예를 들어, 애플리케이션은 고객으로부터의 새로운 주문을 검색하기 위해 고객 관계 관리 시스템("CRM") API의 주문 취득 기능을 호출할 수 있다. 주문 취득 기능은 헤더 취득 기능을 호출하고, 보다 낮은 레벨의 주문 API의 라인 항목 취득 기능을 반복적으로 호출하여 애플리케이션에 반환할 주문 정보를 수집할 수 있다. 라인 항목 취득 기능은 소켓 계층 API의 수신 기능을 호출하여, 고객으로부터 전송되는 다음 라인 항목 메시지를 검색할 수 있다. CRM API의 주문 취득 기능은 새로운 주문을 보호 시스템에 전송하도록 계장될 수 있다. 보호 시스템은 새로운 주문 파라미터를 분석하기 위한 핸들러를 가질 수 있으며, 새로운 주문 파라미터가 취약성을 이용할 것인지를 판정할 수 있다. 보호 시스템은 여기서 취약성을 이용하는 파라미터들을 검출하고 수정하는 데 사용될 수 있다. 예를 들어, 보호 시스템은 고객으로부터의 새로운 주문이 인증될 수 있는지를 판정하는 데 사용될 수 있다. 새로운 주문이 인증될 수 없는 경우, 보호 시스템은 새로운 주문을 폐기하고 애플리케이션에 에러를 반환할 수 있다. 따라서, 보호 시스템은 다양한 추상화 레벨에서 메시지의 시맨틱을 분석하는 데 사용될 수 있다.

도 1은 일 실시예의 보호 시스템을 나타내는 블록도이다. 보호 시스템(110) 은 통신 링크(140)를 통해 클라이언트(130)에, 그리고 애플리케이션(120)에 접속된다. 보호 시스템 및 애플리케이션은 동일한 컴퓨터 시스템 상에서, 또는 다른 컴퓨터 시스템 상에서 각각, 또는 이들의 소정의 조합으로 실행될 수 있다. 보호 시스템은 취약성 사양 저장소(111) 및 보호 컴포넌트(112)를 포함한다. 취약성 사양 저장소는 각각의 애플리케이션에 대한 취약성 사양을 포함한다. 메시지가 통신 링크를 통해 클라이언트로부터 수신될 때, 보호 컴포넌트는 메시지를 보낼 애플리케이션 및 이 애플리케이션 내의 세션을 식별한다. 보호 컴포넌트는 애플리케이션에 대한 취약성 사양에 기초하여 세션에 대한 메시지 상태를 전이시킨다. 취약성을 이용하지 않는 메시지는 애플리케이션으로 직접 전송된다. 반대로, 보호 시스템은 취약성을 이용하는 메시지를 폐기하고, 세션을 해제하는 등의 적절한 동작을 취할 수 있다. 취약성 사양 저장소는 새로운 취약성들이 발견될 때 보호 시스템의 동작을 인터럽트하지 않고 동적으로 새로운 사양으로 로드 및 언로드될 수 있다.

도 2는 일 실시예에서 취약성 사양에 정의되는 메시지 프로토콜의 일부를 나타내는 상태도이다. 상태들(211-215)은 취약성에 관한 애플리케이션의 메시지 프로토콜 상태들을 나타낸다. 이 상태들은 애플리케이션의 메시지 상태들의 서브세트이다. 핸들러들(221-224)은 메시지가 수신될 때 상태들 간의 세션 전이와 관련된 메시지 상태로서 이행되는 동작들의 세트를 나타낸다. 상태 211은 세션의 초기 상태로서, 세션이 RPC 바인드 메시지를 기다리고 있다는 것을 나타낸다. 상태 211에 있고 RPC 바인드 메시지가 수신된 때, 보호 시스템은 RPC 바인드 핸들러(221)를 실행한다. RPC 바인드 핸들러는 세션의 다음 상태를, RPC 바인드 수신 확인을 기 다리는 상태 212로, 또는 세션의 최종 상태인 상태 215로 설정한다. 상태 212에 있고, RPC 바인드 수신 확인 메시지가 수신된 때, 보호 시스템은 RPC 바인드 수신 확인 핸들러(222)를 실행한다. RPC 바인드 수신 확인 핸들러는 상태 213으로 전이하여 RPC 요구를 기다리거나, 최종 상태인 상태 215로 전이한다. 상태 213에서 있고, RPC 요구 메시지가 수신된 때, 보호 시스템은 RPC 요구 핸들러(223)를 실행한다. 메시지의 컨텐츠에 기초하여 취약성이 이용될 것으로 RPC 요구 핸들러가 판정하는 경우, 이 핸들러는 다음 상태를 세션을 해제할 것을 나타내는 상태 214로 설정하며, 그렇지 않으면 최종 상태인 상태 215로 설정한다. 상태 214에 있고 해제 요구가 수신 확인된 때, 보호 시스템은 세션 해제 수신 확인 핸들러(224)를 호출하여 세션의 해제를 완료하고, 최종 상태인 상태 215로 전이한다. 핸들러들 221 및 222는 메시지가 애플리케이션으로 전송되도록 할 수 있으나, 핸들러 223은 다음 상태가 상태 214일 때 메시지 애플리케이션으로 전송되는 것을 허용할 수 없다.

도 3은 일 실시예의 보호 시스템의 아키텍쳐를 나타내는 블록도이다. 보호 시스템은 정책 로더(301), 애플리케이션 디스패쳐(303), 세션 디스패쳐(304), 상태 머신 엔진(305) 및 해석기(306)를 포함한다. 보호 시스템은 또한 취약성 사양 저장소(302) 및 애플리케이션/세션 상태 저장소(307)를 포함한다. 정책 로더는 취약성에 대한 보호 정책을 수신하고, 보호 정책을 취약성 사양으로 변환하여, 취약성 사양 저장소에 저장한다. 정책 로더는 동일 애플리케이션에 대한 취약성 사양들을 자동적으로 결합하여, 각각의 애플리케이션이 단 하나의 취약성 사양을 갖도록 할 수 있다. 보호 시스템에 의해 수신되는 메시지는 애플리케이션 디스패쳐에 의해 먼저 처리된다. 애플리케이션 디스패쳐는 메시지 헤더로부터 메시지와 관련된 포트를 식별한 후, 취약성 사양 저장소에 그 포트 번호와 관련된 애플리케이션을 식별하도록 요구한다. 취약성 사양 저장소는 애플리케이션 식별자로 응답한다. 그러면, 애플리케이션 디스패쳐는 애플리케이션 식별자 및 메시지를 세션 디스패쳐로 전송한다. 세션 디스패쳐는 메시지와 관련된 세션을 식별한다. 세션 디스패쳐는 취약성 사양 저장소에게 애플리케이션 식별자와 관련된 세션 식별 정보를 제공하도록 요구한다. 취약성 사양 저장소는 메시지 내의 세션 식별자의 위치를 설명하는 정보로 응답하며, 메시지 타입 및 메시지 경계의 위치 및 다른 헤더 또는 페이로드 설명 정보를 제공할 수도 있다. 이어서, 세션 디스패쳐는 위치 정보를 이용하여 메시지로부터 세션 식별자를 검색한다. 세션 디스패쳐는 또한 메시지를 분석하여 메시지와 관련된 메시지 이벤트를 식별할 수 있다. 일 실시예에서, 메시지 타입과 이벤트 사이에 일대일 대응이 있을 수 있다. 상태 머신 엔진은 세션 디스패쳐로부터 애플리케이션 식별자, 세션 식별자, 현재 이벤트 및 메시지를 수신한다. 상태 머신 엔진은 애플리케이션 식별자를 취약성 사양 저장소에 제공하며, 애플리케이션 식별자와 관련된 상태 머신 트리플릿을 요구한다. 상태 머신 엔진은 또한 애플리케이션 식별자 및 세션 식별자를 애플리케이션/세션 상태 저장소에 제공하고, 관련된 상태 정보를 요구한다. 트리플릿 및 상태 정보의 수신시, 상태 머신 엔진은 현재 상태 및 현재 이벤트와 일치하는 트리플릿을 검색한다. 일치가 발견된 때, 상태 머신 엔진은 해석기에게 일치 트리플릿과 관련된 핸들러를 실행하도록 지시한다. 해석기는 핸들러를 실행하고, 핸들러는 대응하는 보호 정책에 의해 정의된 동 작들을 수행한다. 이 동작들은 애플리케이션/세션 상태 저장소에 다음 상태 등의 상태 정보를 저장하는 것을 포함할 수 있다. 핸들러는 또한 예를 들어 세션의 이전 메시지를 처리하는 핸들러에 의해 저장된 정보를 애플리케이션/세션 상태 저장소로부터 검색할 수 있다.

보호 시스템이 구현되는 컴퓨팅 장치는 중앙 처리 장치, 메모리, 입력 장치(예를 들어, 키보드 및 포인팅 장치), 출력 장치(예를 들어 표시 장치) 및 저장 장치(예를 들어, 디스크 드라이브)를 포함할 수 있다. 메모리 및 저장 장치는 보호 시스템을 구현하는 명령들을 포함할 수 있는 컴퓨터 판독 가능 매체이다. 또한, 데이타 구조 및 메시지 구조가 저장되거나, 통신 링크 상에서 신호 등과 같은 데이타 전송 매체를 통해 전송될 수 있다. 인터넷, 근거리 통신망, 원거리 통신망 또는 점대점 다이얼업 접속과 같은 다양한 통신 링크가 이용될 수 있다.

도 3은 보호 시스템이 구현될 수 있는 적당한 운영 환경의 일례를 나타낸다. 이 운영 환경은 단지 적당한 운영 환경의 일례일 뿐 보호 시스템의 이용 또는 기능의 범위에 대한 임의의 제한을 제시하는 의도는 없다. 이용에 적당한 다른 공지 컴퓨팅 시스템, 환경 및 구성은 개인용 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 라우터, 스위치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 프로그래머블 고객 전자 기기, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 임의의 상기 시스템들 또는 장치들을 포함하는 분산 컴퓨팅 환경 등을 포함한다.

보호 시스템은 하나 이상의 컴퓨터 또는 다른 장치들에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행 가능 명령들과 관련하여 설명될 수 있다. 일반적으 로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상 데이타 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이타 구조 등을 포함한다. 일반적으로, 프로그램 모듈의 기능은 다양한 실시예에서 원하는 대로 결합되거나 분산될 수 있다. "애플리케이션"이라는 용어는 드라이버, 커널 모드 코드, 운영 체제, 시스템 유틸리티, 웹 서버, 데이타베이스 서버 등과 같은 임의 타입의 실행 소프트웨어를 말한다.

도표 1은 일 실시예의 보호 정책의 일부를 나타낸다. 보호 정책은 특수 언어를 이용하여 개발될 수 있다. 보호 정책은 애플리케이션 및 상태 머신 정보를 가진 제1 부분과 핸들러 및 페이로드 명령을 가진 제2 부분을 구비한다. "#"으로 시작하는 라인들은 주석이다. 애플리케이션 정보(라인 1-5)는 위치 및 포트 번호를 설명한다. 상태 머신 정보(라인 6-28)는 상태, 이벤트 및 트리플릿을 설명한다. 핸들러(라인 46-67)는 수행될 처리를 정의한다. 페이로드 명령(라인 29-45)은 애플리케이션의 메시지의 필드를 분석하는 방법을 지정한다. 페이로드 명령은 이용을 검출하는 데 사용되는 필드를 정의하기 위해서만 필요하다. 다른 필드들은 필드 분석 동안 합쳐지거나 스킵될 수 있다. 핸들러는 이론적으로 어떠한 프로그래밍 언어로도 작성될 수 있다. 보호 정책 자체를 공격하기 어렵게 하는 언어가 사용되어야 한다. 이러한 공격의 방지를 돕기 위한 특수 프로그래밍 언어가 개발되어 왔다. 도표 1의 핸들러에서, 언어는 부울, 카운터(예를 들어 정수), 및 워드 및 바이트 어레이의 데이타 타입을 사용한다. 언어는 또한 메시지의 폐기, 세션의 해제, 메시지 길이의 결정 등과 같은 다양한 연산을 제공한다. 연산 ">>payload"( 예를 들어 라인 49)는 지정된 페이로드 명령에 따라 페이로드(예를 들어 페이로드는 "P_RPCRequest 버퍼 크기이다)를 분석하는 것을 나타낸다. 언어는 또한 if-then 명령문, 특수 목적의 for 루프 등과 같은 명령문을 허용할 수 있다. 특수 for 루프는 반복적인 페이로드 구조에 대해 사용된다. 일 실시예에서, 핸들러는 해석기에 의해 실행 시간에 해석된다.

도표 1

도 4는 일 실시예에서 상태 머신 엔진의 처리를 나타내는 흐름도이다. 엔진은 현재 이벤트, 애플리케이션 식별자, 세션 식별자 및 메시지를 전달받는다. 블록 401에서, 엔진은 애플리케이션 식별자 및 세션 식별자를 애플리케이션/세션 상태 저장소에 제공한다. 블록 402에서, 엔진은 애플리케이션/세션 상태 저장소로부터 애플리케이션 식별자 및 세션 식별자에 대한 현재 상태를 수신한다. 블록 403에서, 엔진은 애플리케이션 식별자를 취약성 사양 저장소에 제공한다. 블록 404에서, 엔진은 취약성 사양 저장소로부터 애플리케이션 식별자에 대한 상태 머신 트리플릿을 수신한다. 블록 405-407에서, 엔진은 트리플릿이 현재 상태 및 현재 이벤 트와 일치하는지를 판정하는 루프를 실행한다. 블록 405에서, 엔진은 다음 트리플릿을 선택한다. 판정 블록 406에서, 모든 트리플릿이 이미 선택된 경우, 엔진은 종료하며, 그렇지 않으면 블록 407에서 계속한다. 트리플릿들의 세트는 어떠한 다른 트리플릿도 현재 상태 및 현재 이벤트와 일치하지 않을 경우에 실행될 핸들러를 식별하는 디폴트 트리플릿을 포함할 수 있다. 또한, 트리플릿의 상태 및 이벤트는 트리플릿과 일치하는 상태 및 이벤트를 정의하는 규칙적인 표현식일 수 있다. 판정 블록 407에서, 트리플릿의 상태가 현재 상태와 일치하고, 트리플릿의 이벤트가 현재 이벤트와 일치하는 경우, 엔진은 블록 408에서 계속하고, 그렇지 않으면 엔진은 블록 405로 루프하여 다음 트리플릿을 선택한다. 블록 408에서, 엔진은 핸들러, 애플리케이션 식별자, 세션 식별자, 현재 이벤트 및 메시지를 분석하는 해석기를 호출한다. 이어서 엔진은 종료한다.

도 5는 일 실시예에서의 취약성 사양의 테스트를 나타내는 블록도이다. 보호 시스템(510)은 테스트될 취약성 사양(511)을 포함한다. 보호 시스템은 또한 도 3의 애플리케이션 디스패쳐, 세션 디스패쳐, 상태 머신 엔진 및 해석기에 대응할 수 있는 보호 컴포넌트(512)를 포함한다. 보호 시스템은 취약성 사양에 의해 표현되는 취약성을 가진 애플리케이션(501)에 메시지를 제공한다. 네트워크 시뮬레이터(502)는 메시지를 보호 시스템으로 전달한다. 메시지는 애플리케이션에 제공된 일반적인 메시지 시퀀스들로부터 수집된 네트워크 데이타(503)로부터 검색되거나, 대표적인 트래픽의 종합 테스트 모음일 수 있다. 보호 시스템은 애플리케이션에 대한 패치가 아니므로, 테스트는 간단하게 된다. 특히, 보호 시스템과 관련된 부 작용이 일반적인 애플리케이션보다 쉽게 제거될 수 있다. 애플리케이션의 관점에서, 보호 시스템은 메시지를 제공하거나 폐기한다. 네트워크 데이타가 취약성을 노출시키는 메시지들의 시퀀스를 포함하지 않는 경우, 모든 메시지는 보호 시스템을 통해 전달되고 애플리케이션에 제공되어야 한다. 메시지가 보호 시스템에 의해 폐기되는 경우, 이것은 취약성 사양의 문제를 나타내거나 취약성의 노출이 검출되었음을 나타낼 수 있다.

도 6은 일 실시예에서의 취약성 사양의 생성을 나타내는 블록도이다. 취약성 사양은 애플리케이션의 메시지 프로토콜 상태 머신에 대한 표준 정의에 기초하여 자동 또는 반자동으로 생성될 수 있다. 사양 생성자(610)는 표준 정의를 이용하여 정의된 애플리케이션에 대한 메시지 프로토콜 상태 머신 설명서(601)를 입력한다. 사양 생성자는 상태 머신을 처리하여 적절한 취약성 사양(602)을 출력한다. 사양 생성자는 취약성 상태 머신 식별 컴포넌트(611), 핸들러 생성 컴포넌트(612) 및 사양 생성 컴포넌트(613)를 포함한다. 취약성 상태 머신 식별 컴포넌트는 사용자 입력을 수신하여 취약성을 노출시키는 상태 머신의 부분을 식별한다. 사용자 입력은 취약성을 노출시키는 상태들을 선택할 수 있으며, 상태들에 대한 다양한 조건을 제공하여 각각의 상태가 어떻게 어떤 인스턴스에서 취약성을 노출시키는 것으로 간주되는지를 표시할 수 있다. 예를 들어, 소정의 메시지가 취약성을 노출시키지만, 이전 메시지가 소정의 컨텐츠를 포함한 경우에만 그러할 수 있다. 핸들러 생성 컴포넌트는 사용자 입력에 기초하여 자동으로 핸들러를 생성할 수 있다. 사양 생성 컴포넌트는 취약성 상태 머신 및 핸들러로부터 취약성 사양 또는 보호 정 책을 생성한다.

보호 시스템의 특정 실시예들이 예시의 목적으로 본 명세서에 설명되었지만, 본 발명의 사상 및 범위로부터 벗어나지 않는 다양한 변형례가 만들어질 수 있다는 것을 당업자는 이해할 것이다. 예를 들어, 메시지의 페이로드가 암호화되는 경우, 보호 시스템은 애플리케이션에게 해독 키를 요구할 수 있다. 그러면, 보호 시스템은 메시지를 해독하고 해독된 메시지를 처리할 수 있다. 보호 시스템은 해독되지 않은 메시지 버젼을 애플리케이션에 제공할 수 있다. 대안으로, 보호 시스템은 애플리케이션의 키 저장소로부터 해독 키를 검색할 수 있다. 해독 키는 시스템 관리자 또는 키 애스크로 시스템에 의해 보호 시스템에 제공될 수도 있다. 다른 예로서, 포트들이 애플리케이션에 동적으로 할당되는 경우, 이러한 포트를 검출하고 애플리케이션에 대한 포트를 취약성 사양 저장소에 등록하도록 취약성 사양이 개발될 수 있다. 보호 시스템이 주로 메시지 기반 프로토콜과 관련하여 설명되었지만, 보호 시스템의 원리는 스트림 기반 프로토콜에도 적용될 수 있다. 또한, 보호 정책은 유한 상태 머신 대신에 규칙적인 표현식을 사용할 수 있다. 보호 시스템은 본 명세서에 참고된 2004년 2월 23일자로 출원된 "동적 시스템 보호 방법 및 시스템"이라는 제목의 미국 특허 가출원 번호 60/547,415(대리인 서류 번호 41826.8018US)에 설명되어 있는 기술과 함께 사용될 수 있다. 이 출원서에 설명되어 있는 바와 같이, 보호 정책은 애플리케이션에 적용된 패치에 따라 자동으로 인에이블 또는 디스에이블될 수 있다. 보호 시스템은 애플리케이션의 애플리케이션 프로그래밍 인터페이스(API)의 호출에 기초하여 취약성 이용의 시도를 검출하는 데 사용될 수 있 다. API는 프로그램이 애플리케이션의 서비스에 액세스할 수 있는 인터페이스를 제공한다. 인터페이스는 프로그램이 애플리케이션과 통신할 수 있는 통신 프로토콜을 정의한다. 따라서, "통신 프로토콜"이라는 용어는 컴포넌트들 간의 통신을 위한 프로시져 및 규칙을 말하며, ISO 프로토콜 스택의 프로토콜들에 한하지 않는다. 따라서, 본 발명은 첨부된 청구범위에 의해서만 제한된다.

본 발명에 따르면, 통신 기반 취약성의 이용으로부터 통신 프로토콜을 구현하는 애플리케이션과 같은 컴포넌트를 보호하기 위한 방법 및 시스템이 제공된다.

Claims

컴퓨터 시스템에서 컴포넌트와의 통신 조건이 언제 만족되는지를 식별하기 위한 방법으로서,

통신 프로토콜의 적어도 일부를 지정하고, 상기 통신 프로토콜의 지정 부분에 상기 조건이 언제 만족되는지를 표시하는 사양을 제공하는 단계;

상기 컴포넌트에 대한 통신을 수신하는 단계; 및

상기 수신된 통신이 상기 컴포넌트에 의해 처리되기 전에, 상기 수신된 통신이 상기 제공된 사양에 의해 지정되는 상기 조건을 만족시키는지를 판정하는 단계

를 포함하는 방법.
제1항에 있어서, 상기 수신된 통신이 상기 조건을 만족시키는 것으로 판정된 경우, 상기 수신된 통신을 상기 컴포넌트에 제공하지 않는 단계를 포함하는 방법.
제2항에 있어서, 상기 수신된 통신이 상기 조건을 만족시키지 못하는 것으로 판정된 경우, 상기 수신된 통신을 상기 컴포넌트에 제공하는 단계를 포함하는 방법.
제1항에 있어서, 상기 제공된 사양은 통신의 처리를 제어하기 위한 상태 머신을 정의하는 방법.
제4항에 있어서, 상기 상태 머신은 상기 통신 프로토콜의 상태들, 및 상태들 사이의 전이에 대한 이벤트들을 정의하는 방법.
제1항에 있어서, 상기 조건은 컴포넌트의 취약성을 노출시키는 방법.
제6항에 있어서, 상기 제공된 사양은 통신의 처리를 제어하기 위한 상태 머신을 정의하는 방법.
제7항에 있어서, 상기 상태 머신은 상기 통신 프로토콜의 상태들, 및 상태들 사이의 전이에 대한 이벤트들을 정의하는 방법.
제8항에 있어서, 상기 사양은 상태들 사이에서 전이할 때 수행되는 동작을 지정하는 방법.
제9항에 있어서, 취약성이 노출될 때 상기 수신된 통신을 상기 컴포넌트에 제공하는 것을 하나의 동작이 억제하는 방법.
제9항에 있어서, 상기 판정 단계는 상태 머신 엔진에 의해 수행되며, 상기 상태 머신 엔진은 상기 사양, 현재 상태 및 현재 이벤트를 입력하고, 상기 현재 상 태 및 상기 현재 이벤트에 대해 상기 사양에서 식별되는 핸들러를 선택하며, 하나의 동작을 수행하도록 상기 핸들러의 실행을 지시하는 방법.
제7항에 있어서, 컴포넌트 단위로 상태 정보가 저장되는 방법.
제7항에 있어서, 세션 단위로 상태 정보가 저장되는 방법.
제6항에 있어서, 상기 컴포넌트는 다수의 세션을 처리하며, 상기 판정 단계는 한 세션의 통신에만 기초하는 방법.
제6항에 있어서, 상기 사양은 상기 취약성의 임의의 이용에 무관한 방법.
제1항에 있어서, 상기 통신은 전송 계층으로부터 수신되는 방법.
제1항에 있어서, 통신이 패킷화될 때, 상기 통신의 모든 패킷이 수신될 때까지 소켓 단위로 상기 통신의 패킷들을 저장하는 단계를 포함하는 방법.
제1항에 있어서, 통신이 암호화될 때, 상기 컴포넌트의 해독 키를 검색하여 상기 통신을 해독하는 단계를 포함하는 방법.
애플리케이션의 취약성이 언제 상기 애플리케이션으로 전송되고 있는 메시지의 결과로서 노출되는지를 검출하기 위한 시스템으로서,

메시지가 언제 상기 애플리케이션의 취약성을 노출시키는지를 표시하며 상기 애플리케이션에서 사용되는 통신 프로토콜에 기초하는 상태 머신을 정의하고, 상기 애플리케이션의 취약성의 노출을 방지하기 위해 취할 동작을 정의하는 상기 애플리케이션에 대한 사양;

상기 애플리케이션에 대한 상기 상태 머신의 현재 상태를 저장하는 상태 저장소; 및

상기 애플리케이션에 대한 메시지를 수신하고, 상기 애플리케이션에 대한 상기 상태 머신의 현재 상태를 검색하며, 상기 애플리케이션에 대한 사양으로부터 상기 검색된 현재 상태에 있고 상기 메시지가 수신될 때 수행할 동작들을 식별하는 엔진

을 포함하는 시스템.
제19항에 있어서, 상기 상태 저장소는 상태 정보를 세션 단위로 저장하는 방법.
제19항에 있어서, 상기 사양을 이용하여, 메시지의 타겟인 애플리케이션을 상기 메시지의 포트 식별자에 기초하여 식별하는 디스패쳐를 포함하는 시스템.
제19항에 있어서, 상기 애플리케이션에 대한 사양에 의해 정의되는 메시지 내의 세션 식별자의 위치에 기초하여 메시지와 관련된 세션을 식별하는 디스패쳐를 포함하는 시스템.
제19항에 있어서, 다수의 취약성이 애플리케이션에 대해 정의될 때, 단일 사양이 상기 취약성들을 지정하는 데 사용되는 시스템.
제19항에 있어서, 전체 메시지가 수신될 때까지 메시지의 부분들을 포함하는 저장소를 포함하는 시스템.
제24항에 있어서, 상기 메시지의 부분들은 소켓 단위로 저장되는 시스템.
애플리케이션의 취약성을 지정하는 데이타 구조를 포함하는 컴퓨터 판독 가능 매체로서,

상기 데이타 구조는

상기 애플리케이션의 메시지들 내의 정보의 위치들을 설명하는 설명서;

상태, 이벤트 및 동작 정의를, 현재 상기 상태에 있고 상기 이벤트가 발생할 때 상기 동작 정의의 동작이 수행되도록 각각 지정하는 트리플릿들; 및

상기 취약성의 노출을 식별하여 방지하고 다음 상태를 식별하는 동작들을 정의하는 동작 정의

를 포함하는 컴퓨터 판독 가능 매체.
제26항에 있어서, 동작 정의가 수신된 메시지를 분석하는 컴퓨터 판독 가능 매체.
제26항에 있어서, 상기 트리플릿은 상기 애플리케이션의 메시지 프로토콜의 일부를 정의하는 컴퓨터 판독 가능 매체.
제26항에 있어서, 상기 데이타 구조의 사양은 상기 취약성의 임의의 이용과 무관한 컴퓨터 판독 가능 매체.
컴퓨터 시스템에서 취약성 상태 머신 사양을 생성하기 위한 방법에 있어서,

애플리케이션의 메시지 프로토콜의 상태들 및 상태들 사이의 전이에 대한 메시지 이벤트들을 정의하는 상기 메시지 프로토콜의 상태 머신 정의를 제공하는 단계;

상기 애플리케이션의 취약성을 노출시킬 수 있는 상기 상태 머신 정의의 일부의 식별을 수신하는 단계;

상기 상태 머신의 각각의 상태에서 다양한 메시지 이벤트의 발생시에 수행할 동작들의 정의를 생성하는 단계; 및

상기 식별되는 상기 상태 머신 정의의 일부 및 상기 생성되는 동작들의 정의 에 기초하여 취약성 상태 머신 사양을 생성하는 단계

를 포함하는 방법.
하나의 방법에 의해, 애플리케이션의 메시지 프로토콜의 조건이 언제 만족되는지를 식별하도록 컴퓨터 시스템을 제어하기 위한 컴퓨터 판독 가능 매체로서,

상기 방법은

상기 메시지 프로토콜의 적어도 일부를 지정하고, 상기 메시지 프로토콜의 상기 지정 부분에 상기 조건이 언제 만족되는지를 표시하는 사양을 제공하는 단계;

상기 애플리케이션에 대한 메시지를 수신하는 단계; 및

상기 수신된 메시지가 상기 제공된 사양에 의해 지정되는 상기 조건을 만족시키는지를 판정하는 단계

를 포함하는 컴퓨터 판독 가능 매체.
제31항에 있어서, 상기 수신된 메시지가 상기 조건을 만족시키는 것으로 판정된 경우 상기 수신된 메시지를 상기 애플리케이션에 제공하지 않는 단계를 포함하는 컴퓨터 판독 가능 매체.
제32항에 있어서, 상기 수신된 메시지가 상기 조건을 만족시키지 않는 것으로 판정된 경우, 상기 수신된 메시지를 상기 애플리케이션에 제공하는 단계를 포함하는 컴퓨터 판독 가능 매체.
제31항에 있어서, 상기 제공된 사양은 메시지의 처리를 제어하기 위한 상태 머신을 정의하는 컴퓨터 판독 가능 매체.
제34항에 있어서, 상기 상태 머신은 상기 메시지 프로토콜의 상태들, 및 상태들 사이의 전이에 대한 이벤트들을 정의하는 컴퓨터 판독 가능 매체.
제31항에 있어서, 상기 조건은 상기 애플리케이션의 취약성을 노출시키는 컴퓨터 판독 가능 매체.
제36항에 있어서, 상기 제공된 사양은 메시지의 처리를 제어하기 위한 상태 머신을 정의하는 컴퓨터 판독 가능 매체.
제37항에 있어서, 상기 상태 머신은 상기 메시지 프로토콜의 상태들, 및 상태들 사이의 전이에 대한 이벤트들을 정의하는 컴퓨터 판독 가능 매체.
하나의 방법에 의해, 컴포넌트의 통신 프로토콜의 상태를, 상기 컴포넌트가 상기 상태에 들어가기 전에 식별하도록 컴퓨터 시스템을 제어하기 위한 컴퓨터 판독 가능 매체에 있어서,

상기 방법은

상기 컴포넌트의 통신 프로토콜의 일부의 모델을 제공하는 단계-상기 모델은 상기 컴포넌트의 외부에 있음-;

상기 컴포넌트에 대한 통신을 수신하는 단계; 및

상기 컴포넌트에 상기 통신을 제공하기 전에, 상기 모델을 이용하여, 상기 컴포넌트가 상기 통신을 수신할 때 상기 컴포넌트가 들어가는 상태를 식별하는 단계

를 포함하는 컴퓨터 판독 가능 매체.
제39항에 있어서, 상기 상태는 상기 컴포넌트의 취약성을 노출시키는 컴퓨터 판독 가능 매체.