KR20060076152A - 웹 서비스 구성의 보안 검사 방법 - Google Patents

웹 서비스 구성의 보안 검사 방법 Download PDF

Info

Publication number
KR20060076152A
KR20060076152A KR1020050037233A KR20050037233A KR20060076152A KR 20060076152 A KR20060076152 A KR 20060076152A KR 1020050037233 A KR1020050037233 A KR 1020050037233A KR 20050037233 A KR20050037233 A KR 20050037233A KR 20060076152 A KR20060076152 A KR 20060076152A
Authority
KR
South Korea
Prior art keywords
policy
security
endpoints
message
configuration
Prior art date
Application number
KR1020050037233A
Other languages
English (en)
Inventor
앤디 고든
세드릭 푸르네
크리스토퍼 지. 캘러
카디케얀 브하가밴
리카도 퓨첼라
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20060076152A publication Critical patent/KR20060076152A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Paper (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

분산 시스템의 보안 목표를 검사하기 위한 시스템 및 방법이 제공된다. 한 양태에서, 상세화된 보안 정책은 모델로 변환된다. 상세화된 보안 정책은 하나 이상의 엔드포인트 간에서의 메시지 교환 동안 시행된다. 하나 이상의 엔드포인트는 분산 오퍼레이팅 시스템 내에 네트워크화된 각각의 주체를 호스트한다. 모델이 평가되어, 상세화된 보안 정책이 하나 이상의 엔드포인트 중 적어도 한 엔드포인트의 하나 이상의 보안 목표를 시행하는지가 판정된다.
보안 정책, 보안 목표, 보안 검사, 모델, 주체

Description

웹 서비스 구성의 보안 검사 방법{CHECKING THE SECURITY OF WEB SERVICES CONFIGURATIONS}
도 1은 웹 서비스를 위한 보안 정책을 자동적으로 생성하고, 웹 서비스 구성의 보안을 검사하기 위한 예시적인 컴퓨팅 장치를 나타낸 도면.
도 2는 웹 서비스 구성의 보안을 검사하기 위하여 시스템 디스크립션을 분석할 때의 예시적인 데이터 흐름을 나타낸 도면.
도 3은 구성 데이터 파일 생성 및 웹 서비스 구성의 보안을 검사하기 위한 보안 정책 분석에 대한 예시적인 데이터 흐름을 나타낸 도면.
도 4는 웹 서비스를 위한 보안 정책을 자동적으로 생성하는 예시적인 프로시져를 나타낸 도면.
도 5는 웹 서비스 구성의 보안을 검사하기 위한 예시적인 프로시져를 나타낸 도면.
도 6은 웹 서비스를 위한 보안 정책을 자동적으로 생성하고, 웹 서비스 구성의 보안을 검사하기 위하여 이하에 설명되는 시스템, 장치 및 방법이 완전하게 또는 부분적으로 구현될 수 있는 예시적인 적합한 컴퓨팅 환경을 나타낸 도면.
도 7은 예시적인 정책 어드바이저 아키텍쳐를 나타낸 도면.
<도면의 주요 부분에 대한 부호의 설명>
102 : 컴퓨팅 디바이스
108 : 프로그램 모듈
110 : 프로그램 데이터
112 : 런타임
114 : 분석기 모듈
116 : 검사기 모듈
118 : 구성 데이터
120 : 기타 프로그램 모듈
122 : 모델
124 : 생성기 모듈
126 : 추상 링크 디스크립션
127 : 기타 데이터
128 : 보안 목표 모듈
본 발명의 시스템 및 방법은 분산 시스템 보안에 관한 것이다.
현존하는 프로토콜 검증기는 보안 프로토콜의 핸드라이팅된 애드혹(ad-hoc) 추상 디스크립션에 작용한다. 핸드라이팅된 디스크립션과 실행 코드 간의 갭은 에러를 유발할 수 있다. 핸드라이팅된 디스크립션을 검사하고 유지보수하는 것은 실 질적으로 노동집약적이고 시간소모적이라는 점에 있어서 문제점은 더 심각해진다.
분산 시스템의 보안 목표(security goal)를 검사하기 위한 시스템 및 방법이 설명된다. 한 양태에서, 상세화된 보안 정책들은 모델로 변환된다. 상세화된 보안 정책들은 하나 이상의 엔드포인트 간의 메시지 교환시에 시행된다. 하나 이상의 엔드포인트는 분산 오퍼레이팅 환경 내에 네트워크화된 각각의 주체(principal)를 호스트한다. 상세화된 보안 정책이 하나 이상의 엔드포인트 중 적어도 한 엔드포인트의 하나 이상의 보안 목표를 시행하는지를 판정하기 위하여, 모델이 평가된다.
도면들에서, 구성요소의 참조 번호의 가장 앞자리 숫자는 해당 구성요소가 처음으로 나타나는 특정 도면의 번호를 나타낸다.
개관
비보안 전송(insecure transport)을 통하여 송신되는 SOAP 메시지들은 내장된 보안 헤더들을 통해 보호될 수 있다. 그리고, WS-Security 스펙은, 이러한 헤더들이 서명이나 암호문과 같은 암호화 요소들, 및 특정 주체를 식별하는 토큰과 같은 소정 범위의 보안 토큰들을 어떻게 포함할 수 있는지를 정의한다. 라이브러리 내에서의 일반적인 구현에 의존하여, 웹 서비스 개발자는 자신의 보안 목표에 따라 자신의 메시지를 위한 헤더 및 토큰을 선택함으로써, SOAP 기반 규약 상에서 자기 자신의 어플리케이션 레벨 프로토콜을 설계할 수 있다.
암호화를 통해 보안되는 모든 네트워크화된 시스템들과 마찬가지로, WS-Security를 사용하는 웹 서비스들은 소정 유형의 공격에 취약할 수 있으며, 그러한 경우 공격자는 하위의 암호 알고리즘은 손상시키지 않으면서 메시지를 인터셉트하고 계산하고 인젝션할 수 있다. 버퍼 초과 실행, SQL 인젝션 등과 같은 웹 서비스 구현예에서의 공격들과는 달리, SOAP 보안의 설정에서의 그러한 공격들은 XML(extended markup language) 재작성 공격(rewrite attack)으로 칭해진다.
WS-Security의 WSE(Web Wervices Enhancement) 2.0 구현예에서 (또는 기타 구현예에서), 보안 헤더의 프로세싱은 명령형의 코드(런타임 내에서 실행되기 위하여 직접적으로 컴파일되는 코드)와는 별개인 선언적인 구성 파일(declarative configuration file)을 통해 프로그래밍될 수 있다. WSE 2.0은 WS-SecurityPolicy 스펙을 따르는 XML 메타데이터 파일에 따라, 인출 보안 헤더를 생성하고 인입 보안 헤더를 검사한다. 이것은 보안 시스템을 구축할 때, 보안 검사를 메시지 프로세싱의 다른 양태들로부터 분리시켜 인간에 의한 보안 검토를 도울 것을 서술하는 원칙을 따른 것이다. 그러나, 이러한 시스템은 여전히 문제점을 갖는다. 예를 들어, WS-SecurityPolicy는 개별 보안 헤더를 구축 및 검사하기 위한 로우레벨의 (즉, 매우 상세화된) 언어이다. 이러한 로우레벨의 언어를 사용하여 메시지 인증이나 비밀성과 같은 하이레벨의 목표에 정책들을 관련시킬 직접적인 방법은 존재하지 않는다. 기존의 시스템에 관련된 또다른 문제점은, XML 재기입 공격에 대한 엔터티의 취약성을 대부분 결정하는 구성 파일(예를 들어, SOAP 기반 시스템의 WS-SecurityPolicy 파일)의 사용에 관한 것이다. 프로그래머는 거의 완전히 자유롭 게, 새롭게 발명된 다른 암호화 프로토콜을 사용하여 구성 파일을 수정할 수 있다. 이러한 프로토콜은 어떠한 구실로도 곧바로 얻기가 어렵다. 이는, 런타임 구성 파일에 대한 수정이 요망되고 있는 임의의 보안 목표를 손상시킬 수 있음을 의미한다.
본 명세서에 설명되는 시스템 및 방법은, 이러한 문제점들을 해결하기 위한 새로운 언어 및 새로운 도구를 제안한다. 예를 들어, 이하의 설명은 SOAP 프로세서들 간에서 흐르는 메시지들에 대하여 의도된 비밀화 및 인증 목표를 기술하기 위한 하이레벨(추상형) 링크 디스크립션을 제시한다. 링크 언어는, 예를 들어 사용자 인터페이스(또는 마법사) 및/또는 시스템 모델링 도구로부터 발생될 수 있는 메시지 흐름의 일반적인 경우들을 포괄하는 간단한 표시법이다. 웹 서비스 구성의 보안을 검사하기 위한 시스템 및 방법은, "생성기" 컴퓨팅 모듈(이하에서 도 1을 참조하여 상세하게 설명됨)을 이용하여, 링크 디스크립션을 구성 파일/데이터로 컴파일한다. 부분적으로는 구성 파일의 정교한 의미론으로 인해, 구성 파일을 직접 작성하는 것보다, 추상 링크 디스크립션으로부터 구성 파일을 자동적으로 생성하는 것이 훨씬 더 안전하고 에러가 적을 가능성이 많다. 설명 및 예시적인 구현을 위하여, 구성 파일이 WS-SecurityPolicy 파일로 종종 언급되긴 하지만, 구성 파일은 그러한 데이터 포맷이나, WS-SecurityPolicy를 구현하는 환경으로 국한되지 않는다.
또한, 웹 서비스 구성의 보안을 검사하기 위한 시스템 및 방법은, 실행 전에 "분석기" 컴퓨팅 모듈을 이용하여, 주어진 WS 구현예에서 링크 디스크립션의 보안 목표가 달성되었는지를 검사한다. 이러한 구현예에서, 분석기는 예를 들어 WS-SecurityPolicy 파일(들)과 같은 구성 파일들의 컬렉션 및 추상 링크 디스크립션을 입력으로서 취한다. 분석기는, 이러한 구성을 위한 모델을 SOAP 프로세서들의 세트로서, 그 프로세서들이 수행하는 보안 검사와 함께 구성한다. 모델은 링크 디스크립션 내에 서술된 보안 목표의 형식적인 스펙도 포함한다. 한 구현예에서, 예시 및 설명의 목적으로, 이러한 모델은 그러한 분산된 구현을 표현하도록 개발된 파이 계산법(pi calculus)의 다이어렉트(dialect)인 TulaFale 스크립팅 언어로서 표현된다. 이러한 구현예에서, 모델의 보안 목표가 임의의 XML 재작성 공격에 취약한지를 자동적으로 검사하기 위하여, TulaFale을 위한 기존의 도구들이 실행된다.
이상을 고려할 때, 웹 서비스 구성의 보안을 검사하기 위한 시스템 및 방법은, WS-Security를 위한 암호화 프로토콜의 추상 디스크립션의 자동 분석에 대하여 형식적인 의미론을 제공한다. 도구들이 분석을 위한 모델(예를 들어, TulaFale 모델)을 자동적으로 구성하게 하면, 모델을 손으로 직접 구성함으로써 발생되는 임의의 인간 오류가 실질적으로 없어지게 되고, 또한 웹 서비스를 전개하는 데에 사용되는 구성 파일들을 체계적으로 검증할 수 있게 된다. 이러한 시스템 및 방법은, 로버스트하고 선언적인 보안 정책들을 구성 및 지원함으로써, 어플리케이션들 간에서 실질적으로 강한 엔드-투-엔드 보안을 보증한다. 즉, 2개의 어플리케이션이 주어지거나 또는 단지 그들의 보안 설정만이 주어지면, 상술한 도구들을 사용하여 정적인 분석이 행해질 수 있다. 또한, 런타임에서는 상술한 도구들을 사용하여 동적인 분석도 행해질 수 있다. 예를 들어, 다른 서비스에 액세스하기 전에, 그 서비 스를 위한 데이터가 획득된 후, 그 보안 설정에 기초하여 안전한 통신이 가능한지의 여부를 판정하기 위한 분석이 행해진다.
다른 구현예에서, 구성 데이터의 보안 목표의 스펙에 대한 하이레벨 링크 디스크립션이 없는 경우, 웹 서비스 구성의 보안을 검사하기 위한 시스템 및 방법은 소정의 문제있는 구성 설정을 자동적으로 식별하여 사용자에게 경고한다. 이로 인해, 이러한 구현예는 구성 데이터 또는 구성 데이터의 객체 모델에 대한 직접적인 쿼리들의 세트를 실행하는 정책 어드바이저를 구현한다. 정책 어드바이저는 사용자에게 보고하기 위하여 결과들을 수집한다. 각각의 쿼리는 구문론적 조건(즉, 구성 데이터의 전부 또는 일부에 의하여 만족될 수도 있고 만족되지 않을 수도 있는 테스트)에 의하여 트리거되며, 리스크의 레포트(어떤 종류의 보안 취약성이 존재할 수 있는지를 나타내는 텍스트 레포트) 및 치료 동작(취약성을 제거 또는 감소시키기 위하여 구성 데이터를 어떻게 수정해야 하는지를 제안하는 텍스트 레포트)을 발생시킬 수 있다. 한 구현예에서, 각각의 쿼리의 결과는 사용자에게 보고된다. 또한, 치료 동작은 예를 들어 사용자로부터의 허가를 획득한 후에 자동적으로 수행될 수 있다. 또한, 정책 어드바이저는 인간 사용자가 어떤 것이 보증되는지를 이해하고 잠재적인 에러를 알아내는 것을 돕기 위하여, 구성 데이터를 요약하는 긍정 레포트를 생성한다.
보안 목표를 자동 검사하기 위한 예시적인 시스템
도 1은 웹 서비스를 위한 보안 정책을 자동적으로 생성하고, 웹 서비스 구성의 보안을 검사하기 위한 예시적인 시스템(100)을 도시하고 있다. 이러한 구현예 에서는 보안 목표가 인간에 의해 작성되지만, 다른 구현예에서는 보안 목표가 예를 들어 자동적으로 생성된 다른 소스들로부터 유도될 수 있다. 시스템(100)은 네트워크(106)를 통하여 하나 이상의 원격 컴퓨팅 디바이스(들)(104)에 접속된 컴퓨팅 디바이스(102)를 포함한다. 컴퓨팅 디바이스(102)는 컴퓨터 프로그램 모듈(108) 및 프로그램 데이터(110)를 포함한다. 컴퓨터 프로그램 모듈(108)은, 예를 들어 런타임 프로그램 모듈(112), 분석기 프로그램 모듈(114) 및 검사기 프로그램 모듈(116)을 포함한다.
런타임(112)(예를 들어, .NET 런타임)은 하나 이상의 원격 컴퓨팅 디바이스(104) 간에서와 같이, 다수의 머신들 간에 분산될 수 있는 런타임 환경을 제공한다. 이러한 구현예에서, 런타임(112)은 구성 데이터(118)에 적어도 부분적으로 기초하는 통신을 위한 암호화 보안 프로토콜, 또는 스크립트를 사용한다. 런타임(112)은, 예를 들어 오퍼레이팅 시스템, 인터넷 정보 서비스(IIS) 및 WSE 라이브러리를 비롯한 다른 소프트웨어 컴포넌트들과 인터페이스한다. 설명을 위하여, 이러한 다른 소프트웨어 컴포넌트들은 "기타 프로그램 모듈"(120)의 부분으로서 각각 표현된다.
구성 데이터(118)는 예를 들어 시스템(100)의 컴퓨팅 디바이스들(머신들)의 주소 및 논리 구성과 디바이스들 간의 관계와 같은 시스템(100) 전개에 관한 정보를 포함한다. 이러한 정보는 암호화, 복호화, 서명 계산, 서명 검증, 키 요소 또는 프레시 넌스(fresh nounce) 생성, 메시지 내의 아이덴티티 또는 넌스 검사, 암호 알고리즘의 세트로부터의 선택을 위한 동작, 및 예를 들어 WS-Security 데이터 포맷으로 된 소정 범위의 보안 토큰의 프로세스를 위한 동작과 같이, 암호화 요소의 프로세싱을 결정할 수 있다. 이러한 구현예에서, 예를 들어 구성 데이터(118)는 SOAP 엔드포인트들의 세트의 디스크립션이며, 이들 각각은 WS-SecurityPolicy 언어(WS-Security 언어의 특별한 경우)의 용어로 된 정책 디스크립션의 컬렉션(즉, 선언적 보안 정책들)과 관련된다. PolicyLanguage 데이터는 WS-SecurityPolicy 언어로 된 XML 파일이지만, 보안 정책 언어의 다른 마크업도 사용될 수 있다.
분석기(114) 및 검사기(116)는 함께 조합되어 구성 데이터(118)를 검사하여 그 보안 실행을 검증(또는 시행)하기 위한 형식적인 도구를 제공한다. 분석기(114)는 구성 데이터(118)의 적어도 일부를 모델(122)로 번역한다. 이러한 구현예에서, 모델은 ProcessModel 언어로 표현된다. ProcessModel은 메시지들의 필터링 및 프로세싱을 표현하는 논리적 술어(logical predicate)들을 포함한다. 이러한 구현예에서, ProcessModel 데이터는 TulaFale 구문으로 된 파이 계산법 프로세스(pi-calculus process)들이지만, 다른 구문도 사용될 수 있다. 예를 들어, 분석기(114)는 PolicyLanguage를 검사기(116)에 대한 입력으로서 사용되는 논리적인 Predicate로 번역한다 (PolicySemantics : PolicyLanguage -> Predicates). 이러한 구현예에서, 술어들은 TulaFale 구문 내의 논리적 술어들을 정의하는 절이다 (즉, 암호화의 기호 표현을 갖는 XML 데이터 상의 프롤로그 스타일 술어).
검사기(116)는 예를 들어 SecurityAssertion 언어로 표현된 ProcessModel의 속성들을 검사/평가하기 위한 자동 또는 반자동 도구이다. SecurityAssertion 언어로 표현될 수 있는 속성들의 예로는, 머신들 간에서 교환되는 소정의 정보에 대 한 기밀성 속성(confidentiality property), 및 이러한 머신들에 의해 수행되는 로컬 동작들 간의 대응(correspondence)으로서 표현되는 확실성 속성(authenticity property)이 포함된다. SecurityAssertion은 서비스의 품질 또는 프라이버시(예를 들어 아이덴티티 또는 데이터 보호)에 관련된 보안 속성도 표현할 수 있다. 이러한 구현예에서, SecurityAssertion 언어는 (형식적 대응을 통한) 인증 또는 비밀성 속성의 TulaFale 어써션을 포함하지만, 어써션의 다른 표현도 사용될 수 있다.
예시적인 프로세스는, 런타임(112)의 구성 C[구성 데이터(118)] 및 인간에 의해 생성된 비교적 짧은 SecurityAssertion A를 고려하여 시스템(100)을 사용한다. 검사기(116)는 어써션 A를 고려하여 구성 C를 프로세싱하는 분석기(114)로부터의 출력을 평가한다. 검사기(116)는 오케이(어써션이 만족됨을 의미함), 또는 반증(조사를 사용하고 C 내의 보안 취약성을 나타낼 수 있음) 또는 모름(검사기가 실패하여 종료한 것을 포함하며 조사를 다시 지정함) 중 하나를 나타내는 결과를 출력한다.
이상을 고려하여, 런타임(112)의 실행이 공격에 취약할 수 있는지의 여부를 직접 판정하기 위하여, 런타임(112)에 의해 직접 실행되는 구성 데이터(118)가 분석기(114) 및 검사기(116)에 의하여 프로세싱된다. 이것은, 프로토콜 검증기가 보안 프로토콜의 핸드라이팅된 애드혹 추상 디스크립션에 작용하고, 핸드라이팅된 디스크립션과 실행 코드 간의 갭이 에러를 유발하며, 검사 및 유지보수가 장황한 종래의 시스템과는 대조적이다. 즉, 런타임(112)과 검사기(116)를 체계적으로 링크시키는 분석기(114)는 신규한 것이다.
시스템(100)의 다른 구현예는, 예를 들어 XML이나 임의의 마크업은 전혀 사용하지 않고 WS-Security를 사용하는 암호화 프로토콜의 임의의 정책 구동되는 구현일 수 있는 런타임(112)을 포함한다. 구성 데이터(118)는 일부 구현예에서 직접 실행될 수 있는 ProcessModel 자체 또는 소정의 혼합을 포함할 수 있다. 예를 들어, TulaFale과 WS-SecurityPolicy의 혼합 내에 지정된 선언적인 구성을 지원하기 위하여 WSE를 확장할 수 있다. 또한, 분석기(114)를 사용하여 ProcessModel을 획득한 후, 검사기(116) 이외의 광범위한 기술 및 도구를 적용할 수 있다.
검사기(116)의 이러한 구현예는 TulaFale 도구에 더하여, 해결책 기반의 정리 증명기(resolution-based theorem prover)인 ProVerif를 사용한다. 다른 구현예에서는 다른 정리 증명기(예를 들어 TAPS)가 적용되며, 그에 더하여 모델 검사기, 타입 검사기 등도 적용된다. 다른 유용한 기술들로는, 예를 들어 시스템의 구현에 대한 모델 기반 테스트, 및 그 런타임 거동의 모델 기반 모니터링 또는 필터링이 포함된다. 분석기(114) 및 검사기(116)는 부분적인 구성들에 적용되기 위하여, 예를 들어 시스템 내의 모든 머신이 아닌 일부 머신을 위한 정책을 기술하도록 세밀하게 구별(refinement)될 수 있다. 이러한 세밀한 구별은, 소정의 보안 속성들이, 알려지지 않거나 신뢰되지 않은 로컬 구성을 갖는 일부 머신들에 상관없이 유지되는지를 검사하는 데에 유용하다.
웹 서비스를 위한 보안 정책의 자동 생성
도 1은 웹 서비스를 위한 보안 정책을 자동적으로 생성하기 위한 예시적인 시스템(100)을 도시하고 있다. 이러한 구현예에서, 컴퓨팅 디바이스(102)는 링크 언어(126)로부터 구성 파일(118)을 생성하는 생성기(Generator) 모듈(124), 및 링크 언어(126)(링크 디스크립션)를 모델(122) 내에 내장될 수 있는 (인증을 위한) 대응 및 비밀성 어써션(예를 들어, 한 구현예에서 이러한 양태들은 TulaFale 스크립트에 내장됨)에 맵핑하는 보안 목표(SecurityGoal) 모듈(128)을 더 포함한다. 모델(122) 내에 내장하기 위한 보안 목표 모듈의 출력은 프로그램 데이터(110)의 각 부분이다. 더 상세하게는, 보안 목표 모듈의 출력은 일련의 대응 및 비밀성 어써션들이다. 대응은 메시지의 수신기가 메시지의 송신기에게 동의할 수 있는 데이터의 세트를 나타내며, 그러한 데이터로는 수신기 및 송신기의 아이덴티티, 메시지의 컨텐츠, 타임스탬프와 같은 메시지의 헤더, 메시지 식별자 및 라우팅 정보와, 대화 내의 임의의 선행 메시지에 대한 현재 메시지의 관계가 포함될 수 있다. 비밀성 어써션은 특정 데이터(암호 키 요소를 포함함)가 공격자에 대해 비밀로 유지됨을 의미한다.
LinkLanguage는 엔드포인트들 간의 보안 링크의 단순한 언어이다. 생성기(124)는 이러한 링크를 WS-SecurityPolicy에 맵핑한다. 보다 상세하게, LinkLanguage(1160)("L")는 SOAP 엔드포인트들 간의 보안 링크, 일반적으로는 클라이언트와 서버의 역할을 하는 주체들의 세트들 간의 보안 링크를 기술하기 위한 추상의 또는 하이레벨의 포맷이다. 각각의 링크에 대하여, 포맷은 링크의 의도된 목표를 기술하며, 그러한 의도된 목표는 메시지 인증, 기밀성, 익명성, 요청과 응답의 상관관계, 주체들 간의 신뢰 관계, 리플레이 또는 DOS 보호 등을 포함할 수 있으며, 또한 의도된 인증 메커니즘[예를 들어, 공유 패스워드, 공개키 서명, 커버로 스 토큰(Kerberos token), WS-SecureConversation 토큰 등]과 같은 소정의 구현 세부사항에 관한 것일 수 있다. 또한, 포맷은 하이레벨의 어플리케이션 구성을 형성하기 위한 링크들의 조성을 기술한다.
LinkLanguage(126)는 구성 데이터(118)보다 훨씬 더 추상적이므로(예를 들어, 덜 표현적이므로), LinkLanguage 디스크립션의 보안성을 검토하는 것은 구성 데이터(118) 내의 모든 세부사항의 보안 암시를 이해하는 것보다 훨씬 더 쉽다. 예를 들어, LinkLanguage(126) 및 생성기(124)는, 임의의 생성된 구성(118)이 핸드라이팅된 구성에서 표현될 수 있었던 흔한 에러 패턴들을 회피함으로써, 런타임(112)에 대하여 "디폴트에 의한 보안(security by default)"을 제공하도록 설계될 수 있다.
이러한 입력 L이 주어지면, 구성 C = Generator(L)은 L 내의 모든 링크들에 대해 의도된 보안 속성을 달성하기 위하여 런타임(112)을 구동하도록 의도된다. 또한, SecurityAssertions A = SecurityGoals(L)은 의도된 보안 속성들의 자동 검사에 적합한 형식적인 표현이다. 첫번째의 예시적인 사용은, 임의의 링크 디스크립션 L에 대하여, ok 또는 반증을 리턴할 검사기(116)(Analyzer(Generator(L)), SecurityGoals(L))를 실행시킴으로써, 생성기(124)가 보안 정책을 생성하고 있는지를 검사할 수 있다는 것이다. 이러한 검사는, 고정되거나 랜덤하게 생성된 입력 L의 세트에 대한 생성기 펑션(124)의 통상적인 테스트 실행 동안, 또는 생성기(124)의 실제 전개 동안 행해져서, 생성기(124)가 구성 C=Generator(L)을 생성하도록 실행될 때마다, 우리는 C를 런타임(112)에 전달하기 전에 C의 보안성을 검사할 수 있 게 된다.
두번째의 예시적인 사용은, 의도된 링크를 기술하는 링크 디스크립션 L과, 기존의 또는 핸드라이팅된 정책을 포함하는 구성 C가 주어진 때, Checker(Analyzer(C), SecurityGoals(L))을 실행시킴으로써, C가 L의 목표를 만족시키는지를 검사할 수 있다는 것이다.
세번째 예시적인 사용은, 링크 디스크립션 L과, 아마도 설치 후에Generator(L)을 편집함으로써 획득된 구성 C가 주어진 때, Checker(Analyzer(C), SecurityGoals(L))을 실행시킴으로써, 보안성이 유지되는지를 검사할 수 있다는 것이다.
생성기가 구성의 일부분만을 생성하고, 구성의 나머지 부분은 변경되지 않은 채로 남아있는 경우에는, 이러한 사용들이 결합될 수 있다. 보안 목표는 Checker(Analyzer(C+Generator(L)),SecurityGoals(L))을 실행함으로써 테스트될 수 있다.
한 구현예에서, 검사기(116)는 이론 입증 및/또는 타입 검사 어플리케이션과 협동하여 실행된다. 그러한 구현예에서, 검사기 동작은 예를 들어 타입 주석(type annotation)과 같은 하나 이상의 추가의 힌트에 의해 용이하게 된다. 예를 들어, 타입 주석은 다양한 타입을 이용하여 표현될 수 있으며, (MSR/DePaul University Crytyc Projection에서 작성된 것과 같은) 시스템 및 의존 타입 시스템을 달성할 수 있었다. 변화는 생성기(124)와 협동하여 실행될 헬퍼 펑션(helper function)을 도입하는 것이다. 설명을 위하여, 그러한 헬퍼 펑션은 도 6의 기타 프로그램 모듈 (들)(636)의 각 부분으로서 도시되어 있다. 예를 들면, 다음과 같다.
Helper(도 1에는 나타나 있지 않음) : LinkLanguage -> Hints
SemiAutomaticChecker(도 1에는 나타나 있지 않음):
ProcessModel, SecurityAssertions, Hints -> ok, 또는 반증, 또는 모름
한 구현예에서는 헬퍼 펑션이 생성기와 협동하여 실행되고, 다른 구현예에서는 헬퍼 펑션이 생성기에 의해 구현된다. 어떤 구현예에서든, 헬퍼 펑션은 예를 들어 키 요소의 의도된 타입과 같이, 생성된 구성에 적합한 힌트를 구성한다. A=SecurityGoals(L)에 대하여 C=Generator(L)을 테스트하기 위하여, 이전의 자동 테스트로서 SemiAutomaticChecker(Analyzer(C),A,Helper(L))를 실행할 수 있다. 우리는 이러한 반자동화된 변화는 구현하지 않았다.
웹 서비스를 위한 보안 정책
웹 서비스 및 그 구성
시스템(100)은 SOAP 프로세서들이 복수의 머신[예를 들어, 컴퓨팅 디바이스(102 및 104)] 간에 분산되어 있는 것으로 간주한다. 각각의 프로세서는 다양한 서비스를 위한 SOAP 엔벨로프(130 및 132)를 송수신할 수 있다. 엔벨로프 포맷은 소정의 선언적인 구성 파일에 의해 유도된 일반 시스템 라이브러리들에 의해 프로세싱되는 한편, 엔벨로프 페이로드는 명령 어플리케이션 코드(imperative application code)에 의해 프로세싱된다. (보호되지 않은) 단순 엔벨로프는 예를 들어 다음과 같은 형태를 가질 수 있다.
Figure 112005023408994-PAT00001
이러한 엔벨로프는 서비스에서의 메쏘드 호출을 나타내는 메시지 본문을 가지며, 그러한 메시지 본문의 앞에는 타겟 서비스 및 동작의 URI와 고유한 메시지 식별자를 제공하는 선택적인 헤더가 있다. 상기의 예에서, GetOrder(20)의 결과를 리턴하기 위하여, 서비스는 헤더 <RelatesTo>uuid:5ba86b04...</RelatesTo>를 갖는 엔벨로프를 사용하여 요청자에게 응답을 라우팅할 수 있다.
SOAP 엔벨로프는 적절한 보안 토큰을 수집하는 추가의 보안 헤더를 사용하여 보호될 수 있다. 예를 들어, 메시지 무결성(message integrity)은 XML 디지탈 서명을 내장한 서명 토큰에 의하여 보호될 수 있는 한편, 송신기의 아이덴티티는 X.509 인증서를 내장한 제2 토큰으로서 전달될 수 있다. 또한, 엔벨로프의 부분들은, 가능하게는 복호화 키를 어떻게 유도해야 하는지를 나타내는 제3 토큰을 사용하여 암호화될 수 있다. 종래의 전송 프로토콜에 비하여, 이러한 접근방식은 성능 및 복잡성에 관련된 비용면에서 유연성을 강조한다. 실제로, WS-Security는 보안 토큰에 대하여 정밀한 문법(grammar) 및 디폴트 프로세싱을 제공하지만, 특정한 프로토콜을 규정하지는 않는다.
어플리케이션 작성자들은, 보안 토큰을 조작하기 위하여 어플리케이션 프로그램 인터페이스(API)를 사용하는 것보다는, 생성기 모듈(124)에 의해 구성 데이터 파일(118) 내의 보안 정책들의 상세화된 세트로 자동 변환되도록, 보안 조건들을 추상 링크 언어(126)로 기술할 것을 독려받는다. 이러한 구현예에서, 시스템(100)은 예를 들어 주어진 서버에 의해 지원되는 서비스 및 동작들과, 클라이언트와 서버(예를 들어 102와 104, 또는 그 역) 간의 신뢰 관계를 기술함으로써 구성된다. 그 결과, 구성 데이터(118)는 서명을 암호화, 복호화, 계산하고, 서명을 검증하고, 키 요소 또는 프레시 넌스를 생성하며, 메시지 내의 아이덴티티 또는 넌스를 검사하고, 암호 알고리즘을 선택하기 위한 동작들과, WS-Security 포맷 내의 소정 범위의 보안 토큰들을 프로세싱하기 위한 동작들과 같이, 암호 요소의 프로세싱을 완전히 결정할 수 있다. [넌스는, 주로 라이브니스(liveness)를 보장함으로써 리플레이 공격에 대한 검출 및 보호를 행하기 위하여, 프로토콜에 의해 교환되는 데이터 내에 포함되는 랜덤 또는 비반복값이다].
예시적인 설명을 위하여, 시스템(100)은 .NET 런타임의 최상위에서 실행되는 웹 서비스 WSE 2.0을 구현하지만, 다른 웹 서비스와 런타임의 조합도 마찬가지로 사용될 수 있다. 도구들이 WSE 2.0과 동일한 XML 엔벨로프 및 구성 파일을 소비 및 생성하는 것을 검사하기 위하여, 이하의 설명은 예시의 목적으로 그 보안 의미론을 포착한다. 이러한 접근 방식은 그러한 예시적인 스펙에 의존하는 다른 시스템들에 적용될 수 있다.
WS-Policy 및 WS-SecurityPolicy
예를 들어 WS-Policy[5], WS-PolicyAssertion[6] 및 WS-SecurityPolicy[7]와 같은 일련의 웹 보안 표준들은, 클라이언트측 및 웹 서비스측에 대하여, 어떤 보안 토큰이 송신 메시지에 내장될지 및 수신 메시지 상에서 어떤 보안 토큰이 검사될지에 관한 선언을 허용한다. 그 명칭과 달리, 정책들은 일반적으로 매우 추상적이지는 않다. 정책들은 기밀성 또는 인증 목표보다는, 엔벨로프의 엘리먼트들을 암호화 및 서명하기 위한 메커니즘을 기술한다. WS-Policy 구조 정책은 결합을 위한 연산자 All[...] 및 분리를 위한 연산자 OneOrMore[...]를 사용하여 구성될 수 있는 기본 어써션에 대한 논리적인 법칙으로서 파일링한다. 이러한 구현예에서, ExactlyOne[...] 연산자와 같은 WS-Policy의 다른 특징들은 보안을 위하여 거의 사용되지 않으며, Rejected 및 Optional 수정자도 사용되지 않는다.
WS-SecurityPolicy는 무결성 및 기밀성을 위한 2개의 기본 어써션을 정의한다. 각각의 어써션은 X.509 인증서로부터의 키, 또는 클라이언트에 관련된 공유 비밀로부터 유도된 키를 참조한다. SOAP 엔벨로프에서, 이것은 X.509 토큰이나 유저네임 토큰을 보안 헤더 내에 내장함으로써 구현된다. 런타임에서 로컬 데이터베이스로부터 실제 키가 제공되긴 하지만, 어써션은 구체적으로 서브젝트 네임을 요청할 수 있다. 각각의 어써션은 암호화되거나 결합적으로 서명될 엔벨로프의 타겟 엘리먼트를 나타내는 부분들의 리스트에 의해 파라미터화된다. 각각의 부분은 그 헤더 네임에 의해, 또는 보다 일반적으로는 XPATH 표현을 사용하여 지정될 수 있다. 각각의 무결성 어써션에 대하여, XML 디지털 서명 토큰은 보안 헤더 내에 내장된다. 각각의 암호화된 부분에 대하여, 타겟 엘리먼트는 그 암호로 대체된다.
수신기 측에서, SOAP 엔벨로프는 유효한 것으로 받아들여지며, 어플리케이션의 정책이 해당 엔벨로프에 대하여 만족되는 경우에는 그 어플리케이션에 전달된 다. 반면에, 송신기 측에서, 프로토콜 스택은 그 정책을 만족시키는 SOAP 엔벨로프를 생성한다. 한 구현예에서, 기능적 정확성을 위하여, 송신기 정책은 적어도 수신기 정책만큼의 요구를 하는 것이다. 이것은 보조적인 프로토콜을 사용하여, 사전에 미리 정책들을 교환 및 비교하는 것에 의하여 시행될 수 있다.
다음으로, 정책들을 위한 추상 구문을 정의한다. 본 명세서에서, 정규화(canonicalization), 보안 해시, 공유 키 암호화를 위한 알고리즘에 대한 명시적인 선택은 생략되며, 각각의 목적을 위하여 고정된 명확한 알고리즘을 가정한다. (반대로, 본 발명의 도구는 웹 서비스 스펙 내에 정의되며 WSE 2.0에 의해 사용되는 정책들에 대하여 구체적인 XML 구문을 소비 및 생성한다.)
정책
Figure 112005023408994-PAT00002
예를 들어, 다음의 정책은, 서비스의 X.509 공개 암호키를 사용하여 메시지 본문을 암호화하고 또한 클라이언트에 관련된 공유 비밀을 사용하여 모든 엘리먼트들을 서명함으로써, 상기에 나타난 예시적인 SOAP 엔벨로프를 보안하는 데에 사용될 수 있다.
Figure 112005023408994-PAT00003
(예를 들어, WSE 2.0에서의) 정책 맵
SOAP 프로세서는 다양한 보안 조건을 갖는 다수의 서비스를 호스트 (및 인터랙션)할 수 있으므로, 정책들이 서비스 및 엔벨로프와 어떻게 연관되는지가 지정된다. WSE 2.0에서, 이것은 인입 엔벨로프와 인출 엔벨로프 각각에 대하여 SOAP 엔드포인트로부터 개별 정책으로의 2개의 (XML의) 부분적인 맵을 제공하는, HTTP를 통해 전송되는 SOAP를 디스패치하는 데에 사용되는 로컬 구성 파일 내에 표현된다. (이러한 로컬 구성 파일은, HTTP 서버에 대해서는 서비스와 동일한 IIS 가상 디렉토리 내에 있는 Web.config 파일이며, 클라이언트에 대해서는 어플리케이션 코드와 동일한 로컬 디렉토리 내에 있는 app.config 파일이다.) 본 명세서에서는, 정책 구성에 대하여 추상 구문을 사용한다.
구성
Figure 112005023408994-PAT00004
예를 들어, 상기에 주어진 요청 및 응답을 지원하는 클라이언트를 위한 구성 이 제공된다. 클라이언트는 다음과 같이 요청을 송신하고 응답을 수신한다.
Figure 112005023408994-PAT00005
정책들을 분석하기 위한 도구 : 아키텍쳐
한 구현예에서, 웹 서비스 구성의 보안을 검사하기 위한 일반적인 접근방식이 도 1에 도시되어 있다. 도시된 바와 같이, 이러한 예시적인 접근 방식은 (1) 자신의 실제 전개를 근접하여 반영하고 (2) 보안 속성의 자동화된 검증을 지원하는 웹 서비스의 동작 모델을 개발한다. WSE 2.0을 사용하여 웹 서비스 어플리케이션을 실제로 실행시키는 대신에, XML 보안 프로토콜을 표현하기 위한 스크립팅 언어인 TulaFale을 사용하여 보안을 기호적으로 검증하기로 한다.
도 2는 TulaFale 스크립트로서 작성된 시스템 디스크립션을 분석할 때의 예시적인 데이터흐름이다. 일부 스크롤들은 핸드라이팅되거나 다른 스크립트로부터 컴파일된 스크립트를 나타내고, 다른 사각형의 스크롤들은 한 스크립트를 다른 스크립트로 컴파일하거나 스크립트를 분석하는 도구를 나타내고 있다. ProVerif 도구는 중간 파이 계산법(intermediate pi calculus)으로 표현된 보안 프로토콜을 분석하는 제3자 소프트웨어이다. TulaFale 도구는 그 입력 스크립트의 타입 검사를 수행한 후, ProVerif에 의한 분석을 위하여 그것을 중간 파이 계산법으로 컴파일한 다.
웹 서비스를 위한 보안 도구 -TulaFale(검토)
TulaFale[2]은 암호화 프로토콜 검증자인 ProVerif[3,4]의 최상위에 구축된 XML 프로세싱에 대한 지원을 갖는 적용된 파이 계산법에 기초하여 타입화된 언어이다. 언어는 용어(term), 술어(predicate) 및 프로세스를 갖는다. 용어는 재작성 규칙들의 세트에 의해 파라미터화된 기호적인 "블랙박스" 암호와 XML을 조합한다. 예를 들어, TulaFale에서 AES 대칭 암호화 및 복호화는 다음과 같이 정의된다.
Figure 112005023408994-PAT00006
프롤로그 스타일의 술어(prolog-style predicate)들은 용어에 적용된다. 이러한 술어들은 웹 서비스 스펙의 구문 및 정보 의미론을 반영하는 데에 사용된다. 예를 들어, 부록 A에서 사용되는 다음의 술어는, 이 XML 토큰을 어떻게 구축하고 유저네임 u, 비밀 pwd, 타임스탬프 t 및 넌스 n으로부터 유도된 키를 어떻게 계산하는지를 기술함으로써, WS-Security 유저네임 토큰의 형식적인 보고를 제공한다.
Figure 112005023408994-PAT00007
프로세스들은 이러한 술어들을 사용하여, 용어들을 송신, 수신 및 변환하는 주체들의 구성을 표현한다. 스코프에 의존하여, 이들은 비밀, 넌스 및 메시지 식별자를 모델링하는 프레시 네임들을 생성할 수 있다.
공격자는 임의의 (프로세스) 컨텍스트를 찾아 돌아다니며, 그에 따라 통신, 암호 및 XML 재작성을 결합한 임의의 능동적인 공격을 시도할 수 있다. 유일한 제한은, 공격자가 처음에는 프레시 네임들을 이용할 수 없다는 것이다.
또한, 형식적인 보안 속성들은 TulaFale로 표현될 수 있다. 우리는 스크립트를 컴파일한 후, 해결책 기반의 프로토콜 검증자인 ProVerif를 인보크한다. 각각의 속성에 대하여, ProVerif는 성공하여 임의의 컨텍스트 내의 모든 런에 대하여 속성을 확립하거나, (통상적으로) TulaFale 런으로 디컴파일될 수 있는 트레이스(trace)를 남기고 실패하거나, 또는 분기한다. 속성들은 기밀성(소정의 네임은 모든 런에 대하여 비밀로 유지됨) 및 확실성(진행을 마킹하기 위하여 프로세스들에 의해 수행되는 특별한 이벤트들 간의 대응으로서 표현됨)을 포함한다. TulaFale 스크립트는 프로세스들을 정의하므로, 예를 들어 상보적인 속성들을 손으로 증명하거나, 또는 자동적으로 증명된 속성들을 일반화하기 위하여, 파이 계산법의 일반적인 이론이 유용하게 적용될 수 있다.
정책 구성들로부터 TulaFale 스크립트를 생성
선언적인 SOAP 구성의 검증을 용이하게 하기 위하여, 우선 그러한 구성을 TulaFale 스크립트로 컴파일함으로써 그 스펙에 대한 정밀한 동작적 의미론(operational semantics)을 제공하는 도구를 사용하여 본 발명의 프레임워크를 확장한다. 우리의 "구성 컴파일러"[예를 들어, 도 1의 생성기 모듈(124)]의 핵심은, WS-SecurityPolicy 법칙들을 WS-Security에 기초하는 예시적인 모델에 대하여 적용하도록 구성된 엔벨로프들 상의 TulaFale 술어들로 번역하는 것을 포함한다. 프로그램적으로, 본 발명의 도구는 WSE 2.0 구현의 정책 맵을 수집하고, 그 TulaFale 스크립트를 자동적으로 생성할 수 있다. 이러한 관점에서, 구성을 위한 비교적 짧은 보안 속성들을 핸드라이팅하고, 그 속성들을 TulaFale을 사용하여 검증할 수 있다. 더 상세하게는, 도구는 인증되지 않은 라우팅 정보와 같이, 정책 구성 내의 흔한 에러(종종 TulaFale에서 명백함)들을 검출 및 보고할 수 있다.
본 발명의 도구 및 실제 웹 서비스 런타임은 동일한 정책 구성을 입력으로서 취한다. 그러므로, 웹 서비스가 공격에 취약할지를 직접적으로 판정할 수 있다. 반면에, 종래의 방법에서, 프로토콜 검증자는 보안 프로토콜의 핸드라이팅된 애드혹 추상 디스크립션에 작용하며, 핸드라이팅된 디스크립션과 실행 코드 간의 갭은 에러를 유발할 수 있고 또한 검사 및 유지보수하기에는 너무 장황하다. 즉, 현재, 암호화 프로토콜을 검증하기 위한 많은 형식적인 기술들이 이용가능하지만, 이러한 프로토콜의 실제 분산된 전개를 반영하는 체계적인 어플리케이션은 신규한 것이다.
추상 구성을 위한 보안 목표 및 정책을 생성
하이레벨 보안 목표를 표현하기 위한 스펙이 존재하지 않는 경우에, 링크 디스크립션(126)은 클라이언트와 서버로서 기능하는 주체들의 세트를 호스트하는 SOAP 엔드포인트들 간의 보안 링크를 기술하기 위하여 단순 포맷을 사용한다. 이러한 포맷은 메시지 인증과 같은 몇개의 기본적인 보안 속성을 언급하여, 정책 맵보다 링크들이 훨씬 더 쉽고 안전하게 구성될 것을 보장할 수 있다. 링크 디스크립션으로부터, 자동 검사에 적합한 의도된 보안 속성들과, 그러한 속성들을 만족시키는 WSE 구성 둘다의 TulaFale 표현을 생성하는 도구가 제공된다.
링크 디스크립션(126)의 언어는 추상적이고 정책 맵보다 덜 표현적이므로, 링크 디스크립션의 보안을 검토하는 것은 구성 내의 모든 세부사항의 보안 암시를 이해하는 것보다 훨씬 더 쉽다. 예를 들어, 링크 디스크립션은, 자동 생성된 구성이 흔한 함정(common pitfall)을 피함으로써, "디폴트에 의한 보안"을 갖는 웹 서비스 구성을 제공하게 하도록 설계될 수 있다.
임의의 링크 디스크립션에 대하여, 우리는 다수의 도구를 조합할 수 있으며, 구성 데이터(118) 내의 관련 정책들을 모델(122)(예를 들어, TulaFale이나 다른 방식으로 표현됨)로 변환하고 검사기(116)(검증자)를 실행시킴으로써, 그 정책들이 실제로 올바른지를 검사할 수 있다. 또한, 다른 (또는 수정된) 구성은, 예를 들어 정책들의 일부를 핸드라이팅하고 정정된 구성이 본래의 보안 목표를 여전히 만족시킴을 검사함으로써 사용될 수 있다. 이러한 구현예에서, 우리는 TulaFale 스크립트를 수동으로 조작할 필요없이, 형식적인 보안 보증을 자동적으로 검증한다. 예를 들어, 실행중인 구성을 수정한 후에 목표가 검증될 수 있다.
도 3은 암호 구성 데이터 파일 생성과, 웹 서비스 구성의 보안을 검사하기 위한 보안 정책 분석의 예시적인 데이터흐름을 나타낸 도면이다. 첫째로, 예시적인 "참조 구현"으로서 보여지는 모델(우측)은 타겟 시스템(좌측)의 모듈러 구성을 따른다는 점에 유의해야 한다. 실제로, 예를 들어 WS-Security의 모델링은, 일련의 예들에 대한 WSE에서 실험적으로 관측된 것들에 대응하는 TulaFale 엔벨로프들을 검사하고, TulaFale과 WSE에서 수행된 보안 토큰들에 대한 동적 검사를 비교함으로써, 하이레벨 스펙에 무관하게 개발되고 완전하게 테스트되었다. 두번째 단계에서, 정책들의 컴파일이 확인된다. 정책들의 컴파일은, 생성된 정책들이 WSE 2.0 에 의해 수용되었고 또한 기대되는 SOAP 엔벨로프들을 산출할 것을 보장하기 위해서도 검사된다. 독립적으로, 도구는 정책 생성의 정확성을 (예측하기 보다는) 검사한다.
이러한 구현예에서, SOAP 프로세서 및 공격자에 대한 예시적인 모델은 다소 임의적이다. 본 명세서에서는 공격자에 대하여 추가의 능력을 제공하는 추가의 API를 프로그래밍함으로써, TulaFale 내에 몇몇 변화를 구현하였다. 설명된 시스템 및 방법은 여전히 임의적인 XML 재작성 공격과, 다양한 서비스 및 동작에 대한 병렬 세션에서의 상이한 역할들에 대하여 동일한 키를 잠재적으로 재사용하는 SOAP 프로세서들에 의해 호스트되는 무제한적인 개수의 주체들을 설명한다. 더 상세하게는, 한 구현예에서, 선언적인 SOAP 구성을 검증하기 위하여, 구성을 TulaFale 스크립트로 컴파일함으로써 그 스펙에 대하여 정밀한 동작적 의미론을 제공하는 도구를 사용하여, 프레임워크가 확장된다. "구성 컴파일러"는 WS-SecurityPolicy로부터 WS-Security에 기초하는 엔벨로프들 상의 TulaFale 술어로의 번역을 구현한다. 이 도구는 또한 WSE 구현의 정책 맵들을 수집하여, 그 TulaFale 스크립트를 자동적으로 생성한다. 이러한 관점으로부터 볼 때, 구성에 대하여 비교적 짧은 보안 속성들이 핸드라이팅될 수 있으며, 또한 그 속성들은 TulaFale을 시용하여 검증될 수 있다.
또한, 시스템(100)은 인증되지 않은 라우팅 정보와 같이, 정책 구성 내에서 흔한 에러들(종종 TulaFale에서 명백함)을 검출 및 보고할 수 있다. 도구와 실제 웹 서비스 런타임은 동일한 정책 구성을 입력으로 취한다. 그러므로, 시스템 및 방법은 구성 데이터 정책 파일의 잘못된 구성에 의해 유발되는 웹 서비스 취약성을 직접 결정할 수 있다. 반면에, 종래의 기술들에서, 프로토콜 검증자는 보안 프로토콜의 핸드라이팅된 애드혹 추상 디스크립션에 작용하며, 핸드라이팅된 디스크립션과 실행 코드 간의 갭은 에러를 유발하고 또한 검사 및 유지보수하기에는 너무 장황하다. 이러한 관점으로부터 볼 때, 시스템(100)에서 설명된 시스템 및 방법은 어플리케이션 내의 암호화 프로토콜들을 검증하여, 그들의 실제의 분산된 전개를 반영한다.
정책 분석: 구현
SOAP 프로세서들을 사용하는 주체
이하에서는, 모델(122)의 비형식적인 개관을 먼저 설명한 후에, 파이 계산법에 대한 본 발명의 변형인 TulaFale로의 예시적인 모델 코딩을 상세하게 설명하기로 한다. 본 발명의 시스템은 공개 네트워크에 의해 접속된 머신들 상에서 실행되는 SOAP 프로세서들을 포함한다. 예를 들어, 시스템(100)을 보면, 신뢰 및 비신뢰(공격자에 의해 제어됨) 프로세서들이 구현될 수 있다. 프로세서들은 주체들을 대신하여 SOAP 엔벨로프를 송수신한다. 한 구현예에서, 주체들은 어떤 엔벨로프를 송신할지 및 수신된 엔벨로프로 무엇을 해야할지를 설명하는 코드를 제공한다. 편의상, 주체들은 인증 토큰에 나타나는 대로의 자신의 (스트링) 네임, 즉 X.509 에서 서브젝트 네임과 UsernameToken에서의 유저네임에 의해 식별된다. 주체들은 자신의 관련 비밀에 대한 액세스를 제어하기 때문에 문제가 된다. 이러한 분산된 시스템은 프로세서들에 비밀을 분배하기 위하여 추상적인 메커니즘을 이용한다.
(예를 들어, 단 하나의 프로세서가 수개의 주체에 의하여 서명된 엔벨로프들을 송신하는 경우에서와 같이) 단 하나의 프로세서가 다수의 주체를 호스트할 수 있다. 게다가, 다수의 프로세서가 (예를 들어, 서비스를 복제하기 위하여) 동일한 주체를 호스트할 수 있다. 그러므로, 본 발명에서는 다음에 의해 파라미터화되는 일반 SOAP 프로세서를 사용한다.
● SOAP 엔드포인트로부터 정책으로의 부분적인 맵을 나타내는, SOAP 메시지를 송신하고 수신하기 위한 2개의 선언적인 구성
● 공유된 패스워드 및 X.509 인증서와, 호스트 주체에 대한 비밀키를 기록하는 로컬 데이터베이스
예를 들어, SOAP 엔벨로프의 URI 및 동작에 관련된 수신 정책에 의해 표현되는 조건이 데이터베이스 내에 기록되어 있는 비밀들 중의 일부를 이용하여 만족될 수 있는 경우에, 그 SOAP 엔벨로프는 수용된다. 한 구현예에서, 파이 계산법은 공격자에게 풍부한 인터페이스를 제공한다. 환경은 주체의 생성, 주체의 파괴, 및 인증서와 공유키의 생성을 제어한다.
이하에서는, 순응 주체(compliant principal)들의 세트를 구별하여, 그 주체들이 액세스할 수 있는 모든 비밀이 이러한 SOAP 프로세서들에 의해서만 사용되게 한다. 물론, SOAP 프로세싱은 순응 주체들의 지식에 의존하지 않는다. 이러한 지식은 예시적인 보안 속성을 지정하는 데에만 사용된다. 일단 순응 주체들이 식별되고 나면, SOAP 프로세서들 간에서의 그들의 분배는 형식적으로 무관계하게 된다. 형식적으로, 임의의 그러한 구성이 모든 순응 주체들을 호스트하는 단일의 프로세 서를 갖는 구성, 즉 모든 로컬 맵핑 및 데이터베이스를 병합하는 포괄적인 정책 맵핑 및 데이터베이스를 갖는 구성과 관측상 등가라는 점을 밝혔다.
정책 구동되는 SOAP 시스템의 모델링
예시적인 모델(122)의 스크립트는 라이브러리 및 메인 TulaFale 프로그램으로서 부록에 제시되어 있다. 이러한 예시적인 스크립트는 상세화된 형식적인 의미론의 예를 제공한다. 이하에서는, 이러한 스크립트들의 중요한 부분들을 부분적으로 예를 들어 설명한다. 본 발명의 SOAP 구성의 최상위 레벨 구조는 다음과 같이 병렬로 실행되는 4개의 반복된 프로세스를 포함한다.
(UsernameGenerator()｜X509Generator()｜GenericSender()｜GenericReceiver())
유저네임 생성기
유저네임 생성기는 genUPChan 채널 상에서 (공격자로부터) 주체 네임 u를 취하고, 새로운 패스워드 "pwdu"를 생성한다. 패스워드 및 유저네임은 dbChan 상의 반복된 출력으로서, 비밀 데이터베이스에 추가될 새로운 엔트리를 형성한다. 따라서, 이러한 엔트리는 dbChan을 공유하는 임의의 정직한 프로세서(honest processor)에게 이용가능하게 된다.
Figure 112005023408994-PAT00008
유효한 패스워드를 갖는 비신뢰 주체를 모델링하기 위하여, 본 발명에서는 유저네임 생성기에 유사한 구조를 갖는 또다른 반복된 프로세스를 추가한다. 이러한 프로세스는 genLeakUPChan 상에서 주체 네임 u를 취하고, 새로운 패스워드를 생성하여 공개 채널 publishChan 상에서 공격자에게 누설하며, 유저네임 및 패스워드를 데이터베이스에 삽입한다. 패스워드를 누설하기 전에, 프로세스는 주체 u가 더 이상 신뢰될 수 없음을 나타내는 begin LogP(u)를 인보크한다. 이러한 이벤트는 시스템 내의 모든 프로세스들에 비가시적이며, 단순히 본 발명의 입증 목표를 지정하기 위해서만 사용된다.
마찬가지로, X509Generator(부록 E에 정의됨)는 공개 채널 genXchan 및 genLeakXChan 상에서, 비밀 서명 키 sr을 서명하는 비밀을 제어하는 단일의 인증 기관을 신뢰하는 2개의 서버를 구현한다.
일반 송신기
예시적인 설명을 위하여, SOAP 송신기 및 수신기는 각각 컴퓨팅 디바이스(102)와 컴퓨팅 디바이스(104)로 표시된다. SOAP 송신기는 술어 mkConformant 내에 코딩된 자신의 송신 정책 구성에 의존하며, 그렇지 않으면 일반적이다. SOAP 송신기는 채널 initChan 상에서 공격자로부터 엔벨로프를 취하고, 의도된 목적지에 대하여 송신 정책 구성을 시행하며, httpChan 상에서 송신되는 새로운 정책 순응 엔벨로프(policy-complian envelope)를 생성한다.
술어 mkConformant는 송신 정책을 고르고, 입력 엔벨로프 상에 암호화 연산을 수행함으로써 주체들의 일부 세트에 대해 그 송신 정책을 시행하려고 시도한다. 주체들과 그 관련 비밀의 세트는 리스트 idents에 의해 나타난다. 이 리스트는 데이터베이스로부터 적정한 수의 아이덴티티를 추출함으로써 채워진다. 또한, 술어는 프레시 키 또는 넌스로서 사용될 수 있는 프레시 네임들의 리스트를 제공받는다.
Figure 112005023408994-PAT00009
일반 수신기
SOAP 수신기는 채널 httpChan 상에서 공격자로부터 엔벨로프를 취하고, 의도된 목적지에 대하여 수신 정책 구성을 시행하며, 엔벨로프가 수용가능하다는 증거를 생성한다. 술어 isConformant는 수신 정책을 고르고, 암호화 연산을 수행함으로써 주체들의 소정의 세트에 대하여 엔벨로프가 그 정책에 순응하는지를 검사한다. 송신기에 관하여, 주체들과 그 관련 비밀의 세트는 데이터베이스의 서브세트를 나타내는 리스트 idents에 의해 나타난다.
Figure 112005023408994-PAT00010
정책의 의미론
SOAP 시스템(100)의 정책 구성(118)은 2개의 술어, 즉 mkConformant와 isConformant로서 코딩된다. 더 상세하게는, 송신 정책 맵은 mkConformant절에 의해 표현되고, 수신 정책 맵은 isConformant절에 의해 표현된다. 이번 섹션에서는, 주어진 정책 구성으로부터 이러한 절들을 생성하는 도구를 설명할 것이다. 여기에서는, 하나의 송신 정책 및 하나의 수신 정책을 갖는 섹션 2의 클라이언트측 구성 ClientConfig로부터 생성된 샘플 절들이 제시된다. 송신 정책은 패스워드 기반 키를 이용하는 5개의 메시지 부분의 디지탈 서명을 이용한다. 예를 들어, 이러한 정책은 링크 디스크립션(126)으로부터 이하의 술어로 [구성(118) 내에서] 번역된다.
Figure 112005023408994-PAT00011
우선, 술어는 패스워드 기반의 키를 생성하기 위한 3개의 프레시 네임, 즉 엔벨로프에 대한 메시지 id, 넌스 및 타임스탬프를 추출한다. 후속하는 4개의 hasXxx 호출은 5개의 메시지 부분 중에서 서명에 사용될 4개를 추출한다. 그 다음, 술어는 새로운 메시지 id를 갖는 새로운 <MessageId> 엘리먼트를 생성한다. 술어 getUsernameToken은 idents 데이터베이스로부터 임의의 유저네임 및 패스워드를 추출하고, 프레스 넌스 및 타임스탬프를 사용하여 새로운 유저네임 토큰 utok와 패스워드 기반 키 k를 생성한다. mkSignature 술어는 키 k를 사용하여 5개의 메시지 부분 모두에 서명하는 XML 서명 sig를 구성한다. 마지막으로, mkSignature 술어는 입력 메시지 부분들, 새로운 메시지 id, 및 새로운 유저네임 토큰 및 서명을 모두 갖는 출력 엔벨로프 outenv를 구성한다.
hasSendPolicyClientToService는 각각의 구성(들)(118) 내에 기술된 클라이언트 송신 정책을 시행한다. 대응하는 송신 정책 맵은 mkConformant 술어절로 번역된다. 처음에, 이러한 절은 메시지의 목적 서비스 및 동작을 정책 맵 내의 어드레스에 일치시킨 후, hasSendPolicyClientToService 술어를 인보크한다.
Figure 112005023408994-PAT00012
clientConfig(118) 내의 제2 정책은 응답 메시지 내의 5개의 메시지 부분들이 주체 BobsPetShop에 발행된 X509 인증서로 서명되었는지를 검사하는 수신 정책이다.
Figure 112005023408994-PAT00013
대응하는 수신 정책 맵은 단순히 hasRecvPolicyServerToClient를 인보크하는 isConformant 술어절로 번역된다.
Figure 112005023408994-PAT00014
부록 C는 정책 구성을 술어로 번역하기 위한 예시적인 규칙을 상세화한 일반적인 경우의 예를 제시하고 있다. 이것은 도 1의 분석기 모듈(114)에 의해 수행된다.
정책 구성 및 보안 목표의 생성
링크 스펙의 추상적인 구문
링크는 웹 서비스와 그 클라이언트들 간에서의 SOAP 세션에 대한 하이레벨의 보안 목표를 정의한다. 링크 디스크립션(126)은 (관심있는 모든 웹 서비스들에 대한) 링크들의 세트를 포함한다. 웹 서비스는 그 서비스 URI인 suri에 의해 식별되며, SOAP 동작 URI에 의해 식별되는 웹 메쏘드들의 세트를 제공한다.
예시적인 설명을 위하여, 클라이언트와 웹 서비스 간에 정의되는 3가지 다른 종류의 SOAP 세션이 존재한다. 본 섹션의 대부분에서 고찰되는 첫번째 경우에서, 세션은 하나의 메시지를 포함한다. 각각의 링크는 2개의 세션을 지정하는데, 그러한 세션들 중 하나는 클라이언트로부터 서비스로의 요청을 위한 것이고, 다른 하나는 서비스로부터 클라이언트로의 응답을 위한 것이다. 링크는 각 방향으로의 메시지들이 서명되고 선택적으로 암호화될 것을 지정하며, 서명이 웹 서비스, 메시지 본문 및 고유한 메시지 식별자를 공동으로 인증해야만 한다는 것을 지정한다. 이러한 경우에 대하여, 링크 스펙은 각 서비스에 대하여 최대 하나의 링크(suri)를 정의한다. 상세하게는, 이것은 서비스의 모든 동작들이 동일한 보안 목표를 갖는다는 것을 의미한다. 2개의 웹 메쏘드가 상이한 보안 보증서를 사용하는 경우, 그 웹 메쏘드들은 별개의 웹 서비스로서 구현된다. 다른 유형의 세션들에 대해서는, 이러한 가정이 완화된다.
두번째 경우에서, 세션은 요청-응답 교환을 포함한다. 이러한 경우에서, 링크는 응답이 요청과 올바르게 상관될 것을 더 지정한다. 세번째 경우에서, 세션은 WS-SecureConversation 스펙에 의해 정의된 것과 같은, 클라이언트와 서버 간의 보안 멀티메시지 대화이다.
예시적인 링크들의 구문은 다음과 같다. 이것은 ML 스타일 리스트(브래킷 내에서 쉼표로 구분된 엘리먼트들의 시퀀스)로의 참조를 위하여 구성기 리스트를 사용한다.
링크
Figure 112005023408994-PAT00015
이러한 구현예에서, 링크 디스크립션(126) 내에 기술되는 각각의 링크(보안 링크)는 웹 서비스 URI, suri, 허용되는 동작들의 세트, 동작, 클라이언트의 역할을 하는 주체(clientPrin) 또는 웹 서비스의 역할을 하는 주체(servicePrin)의 네임, 및 양 방향에서의 메시지의 비밀성 레벨을 포함한다. 주체 네임이 사용자-패스워드 조합에서는 유저네임이고, X.509 인증서에서는 서브젝트 네임이라는 점을 상기해야 한다. 특별한 경우로서, 여기에서는 클라이언트(또는 서비스) 주체들에 관한 빈 리스트는, 어떠한 주체라도 링크에 대한 클라이언트(또는 서비스)의 역할을 할 수 있게 하는 것으로서 해석된다. 비밀성 레벨은 암호화되지 않음을 의미하는 Clear 또는 요청과 응답 둘다가 암호화된 본문을 가짐을 의미하는 Encrypted일 수 있다. 암호화를 위하여, 클라이언트와 서버 주체 둘다 X.509 인증서를 사용해야만 한다.
예를 들어, 다음과 같은 링크를 고찰하기로 한다.
Figure 112005023408994-PAT00016
이 링크는 http://bobspetshop.com/service.asmx에서의 웹 서비스가 2개의 동작 http://petshop/premium 및 http://petshop/regular를 제공하며, 그 클라이언트가 임의의 신뢰된 주체를 대신하여 동작할 수 있으며, 서비스는 BobsPetShop을 대신해서만 동작할 수 있음을 기술하고 있다. 양 방향으로의 메시지가 인증되지만, 암호화는 행해지지 않는다. 나중의 섹션에서, 이러한 링크의 암호화된 버전은 EncLink로서 칭해질 것이다.
링크 스펙으로부터 정책 구성을 생성
이하에서는, 링크 디스크립션(126) 내의 링크들의 리스트를 정책 맵의 리스트를 포함하는 구성(118)으로 번역하는 모듈(124)의 생성기 펑션을 설명한다. 우선, 상기에 주어진 예의 번역으로부터 시작하기로 한다. 첫번째로, 웹 서비스의 각각의 동작과 클라이언트들을 위한 어드레스를 (addr 표기법으로) 정의한다.
Figure 112005023408994-PAT00017
요청 메시지(130 또는 132)에 대하여, 정책은 소정의 신뢰된 주체에 의해 서명되는 메시지의 디지탈 서명을 이용한다. 이러한 서명은 메시지 무결성 및 신뢰성을 보증한다. 이러한 requestPolicy는 다음과 같다.
Figure 112005023408994-PAT00018
메시지 컨텐츠(Body), 목적지(To, Action) 및 식별자(MessageId, Created)는, 메시지 내에 포함되며 서비스에 의해 신뢰되는 소정의 주체의 패스워드 또는 X509 인증서에 기초하는 디지탈 서명에 의해 보호된다.
응답 메시지(130 또는 132)에 대하여, BobsPetShop에 발행된 X509 인증서에 기초하는 디지탈 서명인 responsePolicy가 사용된다.
Figure 112005023408994-PAT00019
응답 메시지는 그 RelatesTo 헤더 내에, 선행 요청의 메시지 식별자를 포함한다. 응답의 목적지는 암시적으로 그 요청 메시지를 송신한 클라이언트이다. 정책은 서비스 URI(From)과 요청 id(RelatesTo)가 응답 식별자(MessageId, Created) 및 응답 컨텐츠(Body)와 함께 디지탈 서명에 의해 보호될 것을 지정한다.
서비스에서의 정책 구성(118)은 요청을 위한 수신 정책 및 응답을 위한 송신 정책을 포함한다.
Figure 112005023408994-PAT00020
일반적으로, 서비스 구성(118)은 각각의 (동작, 클라이언트 주체, 서버 주 체) 튜플에 대한 하나의 수신 정책과, 각각의 (클라이언트 주체, 서버 주체) 쌍에 대한 송신 구성을 포함한다. 반대로, 클라이언트에서, 정책 구성(118)은 요청을 위한 송신 정책과 응답을 위한 수신 정책을 포함한다.
Figure 112005023408994-PAT00021
부록 D는 정책 구성을 생성하기 위한 예시적인 규칙을 보여주고 있다.
보안 목표를 내장
링크 디스크립션(126)의 링크는 클라이언트 주체들 중 하나를 대신하여 동작하는 클라이언트와 서비스 주체들 중 하나를 대신하여 동작하는 웹 서비스 간의 세션을 위한 보안 목표를 지정한다. 확실성 목표는, 서비스 주체가 클라이언트 주체에 의해 송신된 요청 메시지만을 수용하고, 클라이언트 주체가 서비스 주체에 의해 송신된 (미해결 요청에 대한) 응답 메시지만을 수용하는 것이다. 또한, 링크가 비밀성을 사용하는 경우, 메시지의 본문은 그 링크에 참여하지 않는 임의의 주체에 대해서는 비밀로 유지된다. 본 섹션에서는 이러한 보안 목표를 공식화하고, 또한 그러한 보안 목표가 TulaFale 스크립트에 어떻게 내장되는지를 설명한다.
Asserts 펑션은 링크 스펙(126)를 취하고, 확실성 및 비밀성 어써션을 제어하는 hasLinkAssert 및 mkLinkEnvelope 술어에 대한 절을 생성한다. 이것은 도 1의 분석기 모듈(114)에 의해 수행된다.
정직한 SOAP 프로세서에 의해 송신 또는 수용되는 엔벨로프는 소정의 링크 L 상의 요청 또는 응답이다. 이러한 엔벨로프 각각에 대하여, hasLinkAssert는 메시지 및 엔벨로프 컨텐츠의 방향에 기초하여 무결성 어써션("ass")을 계산한다. 정직한 SOAP 프로세서가 메시지 env를 송신할 때마다, 그 SOAP 프로세서는 이벤트 begin Log(ass)를 인보크한다. 반대로, 정직한 SOAP 프로세서가 env를 수용할 때마다, 그 프로세서는 end Log(ass)를 인보크한다. 본 발명의 확실성 목표는, 모든 end Log(ass)가 일치하는 begin Log(ass)에 후속하는 것이다.
상기에 정의된 예시적인 SimpleLink에 대하여, 생성되는 절은 예를 들면 다음과 같다.
Figure 112005023408994-PAT00022
술어의 처음 두 행은 엔벨로프의 목적지 서비스 및 동작을 검사함으로써, 그 엔벨로프가 SimpleLink에 속하는지를 검사한다. 그 다음, 관심의 대상이 되는 3개의 다른 필드, 즉 본문, 메시지 id 및 생성 타임스탬프를 추출한다. 마지막으로, 보호하고자 하는 5개의 메시지 부분으로 연쇄된 클라이언트 및 서버 주체 네임을 포함하는 어써션을 리턴한다. 링크는 서비스 주체만을 언급하므로, 클라이언트 주체는 임의적인 주체를 나타내는 "*"로 대체된다.
응답 메시지에 대하여, 계산된 어써션은 목적지 서비스(To) 및 동작 필드가 소스 서비스(From) 및 RelatesTo 필드로 대체된다는 점을 제외하고는 상당히 유사 하다.
Figure 112005023408994-PAT00023
여기에서, 링크는 From 필드를 링크 서비스 URI에 일치시킴으로써 식별된다. 전술한 바와 같이, 메시지 부분들이 추출되고, 주체 네임들이 알려져 있는 경우에는 그러한 네임들로 연쇄된다.
본 발명의 일반 SOAP 송신기는 공격자로부터의 엔벨로프를 취하여, 소정의 보안 헤더 및 암호화된 블럭을 추가한 후에 그 엔벨로프를 송신한다. 링크가 비밀성을 사용하는 경우, 엔벨로프의 본문은 공격자로부터 보호된다. 이것을 모델링하기 위하여, SOAP 송신기가 암호화된 링크 상에서 엔벨로프를 보낼 것을 요청받을 때마다, SOAP 송신기는 mkLinkEnvelope 술어를 사용하여, 메시지의 본문을 비밀 본문 B로 치환한다. 그러면, 비밀성 어써션은 공격자가 상이한 링크들 상에서 수개의 메시지를 관찰하더라도 B를 결코 알 수 없는 것으로 된다.
Figure 112005023408994-PAT00024
암호화된 링크 EncLink의 예에 대하여, 요청 메시지에 대한 mkLinkEnvelope절은 다음과 같이 주어지며, 응답 메시지들은 유사하다.
Figure 112005023408994-PAT00025
이러한 절은 엔벨로프가 EncLink에 속하는지를 검사하고, 본문을 비밀 본문(B)으로 치환한다. 데이터 B는 우리가 비밀로 유지하고자 하는 시스템 내의 모든 데이터를 나타낸다. 그러므로, 데이터 B는 암호화된 링크 상에서만 송신될 수 있다. 반대로, 비밀이 아닌 데이터는 어떠한 링크 상으로도 송신될 수 있고, 이것은 엔벨로프를 변경되지 않은 채로 유지하는 mkLinkEnvelope절에 의해 모델링된다.
부록 D는 링크들의 보안 목표로의 예시적인 맵핑을 나타내고 있다.
링크 스펙 및 구성에 의해 정의된 스크립트를 분석
특정한 정책 구성이 링크 디스크립션/스펙(126)에 의해 정의된 보안 목표를 달성하는지를 검사하기 위하여 TulaFale 스크립트를 어떻게 구성하는지를 정의하기로 한다. 링크 L이 주어지면, 생성기(124)는 술어 hasLinkAssert 및 mkLinkEnvelope를 위한 절을 생성한다. 구성 C가 주어지면, 생성기(124)는 술어 mkConformant 및 isConformant를 위한 절을 생성한다. 이러한 4개의 술어는 SOAP 프로세서의 TulaFale 모델 내에 내장된다. 그러면, 송신기는 mkLinkEnvelope를 사용하여 비밀 본문을 이용할 수 있고, 그리고 hasLinkAssert를 이용하여 무결성 어써션을 계산하고, begin Log(ass)를 인보크하며, mkConformant를 사용하여 정책 순응 인출 엔벨로프를 계산하고, 메시지를 네트워크 상에서 송신한다. 반면에, 수신기는 isConformant를 사용하여 인입 엔벨로프가 정책에 순응하는지를 검사한 후, emd Log(ass)를 인보크하기 전에 hasLinkAssert를 사용하여 무결성 어써션을 계산한다.
정책 구성이 링크 보안 스펙을 만족시키는 것을 검증하기 위하여, 검사기(116)는 TulaFale을 실행하는 확실성 및 보안성 목표를 검사한다. 이러한 구현예에서, 일반적인 정의는 예를 들어 다음을 포함한다.
정의 4.1 수신기 프로세스가 end Log([u]＠ ass)를 인보크할 때마다, begin Log([u]＠ ass)를 미리 인보크한 소정의 송신기 프로세스 또는 begin LogP(u)를 미리 인보크한 소정의 토큰 생성기가 존재하는 경우, TulaFale 프로세스는 Log, LogP에 대하여 로버스트하게 안전하다고 말해진다.
공격자가 B를 알고 있을 때마다, 소정의 토큰 생성기 프로세스가 begin LogP(u)를 미리 인보크하거나 소정의 송신기 프로세스가 begin LogS(u,B)를 미리 인보크하게 하는 주체 u가 존재하는 경우, TulaFale 프로세스는 LogP, LogS를 위한 B의 비밀성을 보전한다고 말해진다.
end Log(ass)가 실질적으로 인보크되게 하는 프로세스의 실행이 존재하는 경우, TulaFale 프로세스는 Log(ass)에 대하여 기능적으로 적절하다고 말해진다.
링크 스펙 SimpleLink로부터 생성된 정책 구성 SimpleConfig를 고찰하기로 한다. 다음의 정리는 이러한 구성이 링크에 의해 지정된 확실성 목표를 보전한다는 것을 기술한다.
정리 4.1 (SimpleLink, SimpleConfig에 대하여 로버스트한 안전) SimpleLink 및 SimpleConfig로부터 생성된 TulaFale 스크립트는 Log, LogP에 대하 여 로버스트하게 안전하다.
마찬가지로, 다음의 정리는 EncLink로부터 생성된 정책 구성 EncConfig가 EncLink의 비밀성 목표를 보존한다는 것을 기술한다.
정리 4.2 (EncLink, EncConfig에 대한 확실성) EncLink 및 EncConfig로부터 생성된 TulaFale 스크립트는 LogP, LogS에 대한 B의 비밀성을 보존한다.
EncLink가 SimpleLink보다 단연코 더 강한 스펙이므로, 우리는 EncLink 및 EncConfig로부터 생성된 스크립트에 대하여 로버스트한 안전을 확립할 수 있다. 다음 섹션에서는, 분석을 다시 실행하지 않고서도 이러한 속성을 유도할 수 있게 해 주는 일반적인 정리들이 제시된다.
우리가 생성한 스크립트들 둘다가 소정의 어써션에 대하여 기능적으로 적합한 것으로 보여질 수 있다. 다음의 정리는 SimpleLink 및 SimpleConfig로부터 생성된 스크립트에 대하여 이러한 속성을 기술한다.
정리 4.3 (SimpleLink, SimpleConfig에 대한 기능적인 적합성) SimpleLink 및 SimpleConfig로부터 생성된 TulaFale 프로세스가 Log(ass)에 대하여 기능적으로 적합해지게 하는 어써션 ass가 존재한다.
정책들의 논리적 이론
이전의 섹션에서는, 시스템(100)이 링크 스펙(126)에 대하여 고정된 정책 구성(118)의 정확성을 어떻게 검증하는지를 설명하는 예가 제시되었다. 그러나, 도 1-6과 관련하여 여기에서 설명되는 시스템 및 방법은 보다 더 일반적이며, 예를 들어 이하에 설명되는 바와 같이, 정책 구성 및 링크 스펙의 일반적인 클래스에 관한 정리를 기술 및 증명하는 데에 사용될 수 있다.
정책을 위한 논리적 의미론
보안 정책들은 결합(conjuction) 및 분리(disconjunction)를 사용하여 조합된 원자적인 제안(atomic proposition)들로서의 무결성 및 신뢰성 어써션을 갖는 논리적인 법칙으로서 취급될 수 있다. 이것은, 하나의 정책을 만족시키는 임의의 메시지가 다른 정책도 만족시키면, 그 정책은 다른 정책을 세밀화(refine)한다는 본질적인 세밀화의 개념으로 유도된다.
TulaFale로의 컴파일은 논리의 모델을 제공한다. 기본적인 공리가 적용되며, 프로세스 구성으로 추진될 수 있다(예를 들어, 서버의 병렬 구성들을 정책의 분리들과 비교함). 그리고, 우리는 우리의 모델에 적용되는 추가의 법칙들, 예를 들어 유저네임 토큰에 대한 서명이 없는 인증 및 프레시 네임을 공유하는 복수의 서명의 이행성(transivity)을 설명할 것이다. 이러한 논리적인 속성들은, 논리가 WS-Policy인 경우에서도 유용하다.
구체적으로는, 정책 상세화가 보안 속성의 보존으로 번역하는 경우, 정책이 보안 목표에 일치하는지를 검사하기 위하여, 이것은 정책이 TF를 사용하여 검사되었음을 (모델 내에서 논리적으로) 상세화하기에 충분하다.
보조 정리 1 ([1]로부터 변형) TulaFale 스크립트로서 표현된 소정 클래스의 프로토콜에 대하여, 최상위 레벨의 술어들의 논리적인 암시는 로버스트한 안전을 보존한다.
보조 정리 2 정책 P1이 P2를 상세화하는 경우, P1으로부터 생성된 송신(수신) 술어는 P2로부터 생성된 송신(수신) 술어를 암시한다.
논리적 상세화는 정책 구성으로 확장될 수 있다. C1이 C2를 점별로(pointwise) 상세화하는 구성 C1'의 서브세트인 경우, 구성 C1은 C2를 상세화한다.
정리 5.1 링크 L과 정책 구성 C가 주어지면, L 및 C로부터 생성된 TulaFale 스크립트가 로버스트하게 안전한 경우, C'가 C를 상세화한다면 L 및 C'로부터 생성된 스크립트도 로버스트하게 안전하다.
본 명세서에서는, 본 발명의 주요한 결과를 확립하기 위하여, 수동과 자동 증명의 조합을 이용한다.
링크에 의해 생성된 정책
링크 스펙으로부터 직접 생성된 정책 구성은 항상 안전하다. 이것은 다음의 정리에 의해 공식화된다.
정리 5.2 (확실성) 모든 링크 L에 대하여, C가 L로부터 생성된 정책 구성이라고 하면, L 및 C로부터 생성된 TulaFale 스크립트는 (내부인에 대하여) Log에 대해 로버스트하게 안전하다.
정리 5.3 (비밀성) 모든 링크 L에 대하여, C가 L로부터 생성된 정책 구성이라고 하면, L 및 C로부터 생성된 TulaFale 스크립트는 (내부인에 대하여) B의 비밀성을 보존한다.
정리 5.4 (기능적 적합성) 모든 링크 L에 대하여, C가 L로부터 생성된 정책 구성이라고 하면, L 및 C로부터 생성된 TulaFale 스크립트는 기능적으로 적합하다.
링크 및 송신 정책
구성에 대한 세밀화 정리들은, 송신 정책의 강화가 정책 구성의 로버스트한 안전을 보존함을 기술한다. 일부 경우에서, 강한 송신 정책은 약한 서버 정책까지도 보상할 수 있다.
한편, 서버 정책이 링크 스펙을 유효화할 수 있을만큼 강한 경우, 송신 정책은 확실성에 대하여 중요하지 않다.
정리 5.5 (확실성) 임의의 링크 L에 대하여, C가 L로부터 생성된 정책 구성이라고 하고, R이 C 내의 모든 수신 정책 맵을 포함한다고 하자. 그러면, 송신 정책 맵의 임의의 세트 S에 대하여, L 및 S＠R로부터 생성된 TulaFale 스크립트는 로버스트하게 안전하다.
반대로, 비밀성은 송신 정책에만 의존한다.
정리 5.6 (비밀성) 임의의 링크 L에 대하여, C가 L로부터 생성된 정책 구성이라고 하고, S가 C 내의 모든 수신 정책 맵을 포함한다고 하자. 그러면, 수신 정책 맵의 임의의 세트 R에 대하여, L 및 S＠R로부터 생성된 TulaFale 스크립트는 비밀성을 보존한다.
웹 서비스를 위한 보안 정책을 생성하기 위한 예시적인 프로시져
도 4는 웹 서비스 구성의 보안을 검사하기 위한 예시적인 프로시져(400)를 도시하고 있다. 설명을 위하여, 프로시져의 동작들은 도 1의 컴포넌트들과 관련하 여 설명된다 (모든 참조번호는 해당 컴포넌트가 처음으로 나온 도면의 번호로 시작한다). 블럭(402)에서, 클라이언트 서버 오퍼레이팅 환경 내에서 네트워크된 엔드포인트들 간의 보안 링크가 기술된다. 보안 링크는 하이레벨 링크 언어(126)(도 1) 내에 기술된다. 보안 링크는 하나 이상의 세션 동안의 머신들 간의 메시지 교환을 위한 보안 목표를 나타낸다. 여기에서, 세션은 클라이언트 주체를 대신하여 동작하는 클라이언트와 서비스 주체를 대신하여 동작하는 웹 서비스 간에 이루어진다. 보안 목표는 메시지들이 서명, 암호화되거나, 관련 서명 및 조합을 갖는 각각의 클라이언트 및/또는 웹 서비스 주체를 인증하게 한다는 표시를 포함할 수 있다. 보안 목표의 확실성 목표는, 서비스 주체가 클라이언트 주체에 의해 송신된 요청 메시지만을 수용한다는 것을 나타내거나, 클라이언트 주체가 서비스 주체로부터의 응답 메시지만을 수용한다는 것을 나타내거나, 링크 내에 참여하고 있지 않은 클라이언트 또는 서비스 주체에 대해서는 임의의 메시지가 비밀로 유지된다는 것을 나타낼 수 있다.
한 구현예에서, 보안 링크들의 링크는 웹 서비스의 URI, 허용된 동작들의 세트, 클라이언트 또는 웹 서비스로서 기능할 수 있는 주체들의 네임의 세트, 또는 하나 이상의 세션에서의 머신들 간의 메시지 교환의 비밀성 레벨을 나타낸다. 세션은 요청 및 응답 교환을 포함한다. 세션은 클라이언트와 서버 간의 보안 멀티-메시지 대화일 수 있다.
블럭(402)의 동작은 수신 정책을 갖는 서비스 구성 및 송신 구성을 포함하는 보안 정책 구성에 대하여, 추상적인 고정 알고리즘 구문을 소비하는 것을 포함할 수 있다. 수신 정책은 동작, 클라이언트 주체 또는 서버 주체에 대응한다. 송신 구성은 각각의 클라이언트 주체와 서버 주체의 쌍에 대응한다. 또한, 블럭(402)의 동작은, 보안 정책 구성에 대하여 추상적인 고정 알고리즘 구문을 소비하는 것을 포함할 수 있으며, 웹 서비스의 클라이언트 디바이스에 대하여 송신 요청 정책과 수신 응답 정책을 포함한다.
블럭(404)에서, 생성 모듈(124)은 링크 언어(126)로부터 구성 데이터(118)를 자동적으로 생성한다. 구성 데이터는 런타임(112)에 의해 사용되는 보안 프로토콜에 관련된 선언적인 보안 정책들을 포함한다. 구성 데이터는 서버에 의해 지원되는 동작들의 서비스, 및 클라이언트와 서버 간의 신뢰 관계의 표시를 더 포함할 수 있다. 구성 데이터에 관한 또다른 양태들은, 도 5와 관련하여 이하에서 설명되는 분산 시스템의 보안 목표를 검사하는 예시적인 프로시져에서 더 설명될 것이다.
분산 시스템의 보안 목표를 검사하기 위한 예시적인 프로시져
도 5는 웹 서비스 구성의 보안을 검사하기 위한 예시적인 프로시져(500)를 도시하고 있다. 설명을 위하여, 프로시져(500)의 동작들은 도 1의 컴포넌트들과 관련하여 설명된다 (모든 참조 번호는 해당 컴포넌트가 처음으로 등장하는 도면의 번호로 시작한다). 블럭(502)에서, 분석기 모듈(114, 도 1)은 구성 데이터(118) 내의 정보를 모델(122)로 번역한다. 구성 데이터는 런타임(112)에 의해 구현되는 보안 프로토콜에 관련된 선언적인 보안 정책들을 포함한다. 한 구현예에서, 선언적인 보안 정책은 기본 어써션에 대한 논리적인 법칙들을 포함한다. 모델(122)은 분산 컴퓨팅 시스템(100, 도 1) 내의 컴퓨팅 디바이스들 간에서 전달되는 메시지들 의 필터링 및 프로세싱을 표현하는 술어들을 포함한다.
한 구현예에서, 구성 데이터(118)는 도 4와 관련하여 상기에서 설명된 예시적인 프로시져를 통하여 생성된다.
블럭(504)에서, 검사기 모듈(116)은 모델(122)을 평가하여, 런타임(112)의 선언적인 보안 정책이 시스템(100)의 보안 목표를 시행하는지를 판정한다. 이러한 평가 동작은 선언적인 보안 정책이 재작성 공격에 취약한지를 자동적으로 판정하는 것을 포함한다. 블럭(506)에서, 검사기 모듈(116)은 모델의 평가를 고려하여, 분산 시스템(100)이 보안 공격에 취약한지를 판정한다.
한 구현예에서, 구성 데이터(118)는 제1 및 제2 컴퓨터 프로그램 어플리케이션에 관련된 보안 세팅에 대응한다. 이러한 구현예에서, 블럭들(502 내지 506)의 동작은 보안 공격에 대한 시스템(100)의 취약성에 관한 정적인 분석 또는 런타임 분석의 일부로서 수행된다.
예시적인 오퍼레이팅 환경
웹 서비스의 보안 정책을 자동적으로 생성하고 웹 서비스 구성의 보안을 검사하기위한 시스템 및 방법은, 퍼스널 컴퓨터에 의해 실행되는 컴퓨터 실행가능 명령어들(프로그램 모듈들)의 일반적인 문맥으로 설명된다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 시스템 및 방법이 이러한 문맥으로 설명되긴 하지만, 이하에 기술되는 동작 및 연산은 하드웨어로도 구현될 수 있다.
도 6은, 예를 들어 도 1 내지 도 6과 관련하여 도시 및 설명된 바와 같이, 웹 서비스의 보안 정책을 자동으로 생성하고 웹 서비스 구성의 보안을 검사하는 시스템 및 방법이 완전하게 또는 부분적으로 구현될 수 있는 적합한 컴퓨팅 환경의 일례를 도시하고 있다. 예시적인 컴퓨팅 환경(600)은 적합한 컴퓨팅 환경의 일례일 뿐이며, 본 명세서에 개시된 시스템 및 방법의 용도 또는 기능성의 범위에 어떠한 제한을 가하기 위한 것이 아니다. 컴퓨팅 환경(600)은 컴퓨팅 환경(600) 내에 도시된 컴포넌트들 중의 어느 하나 또는 그들의 조합에 관련된 어떠한 종속성이나 요구조건을 갖는 것으로 해석되어서는 안 된다.
본 명세서에 개시된 방법 및 시스템은 기타의 다양한 일반 목적 또는 특수 목적 컴퓨팅 시스템 환경 또는 구성에 적용될 수 있다. 이용에 적합할 수 있는 공지된 컴퓨팅 시스템, 환경 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 및 상기 개시된 시스템 또는 디바이스들 중 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 포함되지만, 이들로 제한되는 것은 아니다. 또한, 프레임워크의 컴팩트 또는 서브세트 버전들은, 핸드핼드 컴퓨터 또는 기타 컴퓨팅 디바이스와 같이 한정된 자원을 갖는 클라이언트에서 구현될 수 있다. 본 발명은 통신 네트워크를 통해 링크된 원격 프로세싱 디바이스들에 의하여 태스크가 수행되는 분산 컴퓨팅 환경에서 실현된다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 디바이스 둘 다에 위치될 수 있다.
도 6을 참조하면, 웹 서비스 구성의 보안을 검사하기 위한 예시적인 시스템 은 컴퓨터(610)의 형태로 된 일반 목적 컴퓨팅 디바이스를 포함한다. 이하에 설명되는 컴퓨터(610)의 양태들은 도 1의 컴퓨팅 디바이스(102 또는 104)의 예시적인 구현예이다. 컴퓨터(610)의 컴포넌트들로는 프로세싱 유닛(들)(620), 시스템 메모리(630), 및 시스템 메모리를 비롯한 다양한 시스템 컴포넌트들을 프로세싱 유닛(620)에 연결하는 시스템 버스(621)가 포함되지만, 이들로 제한되지는 않는다. 시스템 버스(621)는 메모리 버스나 메모리 컨트롤러, 주변 버스, 및 다양한 버스 아키텍쳐들 중 임의의 것을 사용하는 로컬 버스를 포함하는 다양한 유형의 버스 구조 중 임의의 것일 수 있다. 예를 들어, 이러한 아키텍쳐는 ISA(Industrial Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌 버스로도 알려져 있는 PCI(Peripheral Component Interconnect) 버스를 포함하지만, 이들로 제한되지는 않는다.
일반적으로, 컴퓨터(610)는 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(610)에 의해 액세스될 수 있는 임의의 가용 매체일 수 있으며, 휘발성 및 비휘발성 매체와 분리형 및 비분리형의 매체를 포함한다. 예를 들어, 컴퓨터 판독 가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하지만, 이들로 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성의 분리가능 및 분리불가능 매체를 포함한다. 예를 들어, 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모 리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장장치, 자기 카세트, 자기 테입, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 원하는 정보를 저장하기 위하여 사용될 수 있고 컴퓨터(610)에 의하여 액세스될 수 있는 임의의 기타 매체를 포함하지만, 이들로 제한되지는 않는다.
통신 매체는 통상적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 반송파나 기타 전송 메커니즘과 같은 변조된 데이터 신호로 된 기타 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는, 그 특성 중 하나 이상이 신호 내에 정보를 인코딩하는 방식으로 설정 또는 변경된 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접 유선 접속과 같은 유선 매체, 및 음향, RF, 적외선 및 다른 기타 무선 매체와 같은 무선 매체를 포함하지만, 이들로 제한되지는 않는다. 또한, 이들의 임의의 조합도 컴퓨터 판독가능 매체의 범위에 포함된다.
시스템 메모리(630)는 판독 전용 메모리(ROM)(631) 및 랜덤 액세스 메모리(RAM)(632)와 같은 휘발성 및/또는 비휘발성 메모리의 형태로 된 컴퓨터 저장 매체를 포함한다. 시동 중과 같은 때에 컴퓨터(610) 내의 구성요소들 간에 정보를 전달하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(BIOS)(633)은 일반적으로 ROM(631) 내에 저장된다. RAM(632)은 일반적으로 프로세싱 유닛(620)에 의해 즉각적으로 액세스 가능하고/하거나 현재 실행중이 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들어, 도 6은 오퍼레이팅 시스템(634), 어플리케이션 프로그램(635), 기타 프로그램 모듈(636) 및 프로그램 데이터(637)를 도시하고 있지만, 이 들로 제한되지 않는다. 한 구현예에서, 어플리케이션 프로그램(635)은, 예를 들어 도 1의 프로그램 모듈(108), 및 주체를 대신하여 SOAP 엔벨로프를 송수신하는 "프로세서"(어플리케이션)와 같은 기타 컴퓨터 프로그램 모듈을 포함한다. 프로그램 데이터(638)는, 예를 들어 도 1의 프로그램 데이터(110)를 포함한다.
컴퓨터(610)는 다른 분리가능/분리불가능의 휘발성/비휘발성 컴퓨터 저장 매체도 포함할 수 있다. 단지 예시를 위한 목적으로, 도 6은 분리불가능한 비휘발성 자기 매체에 대한 판독 또는 기입을 수행하는 하드디스크 드라이브(641), 분리가능한 비휘발성 자기 디스크(651)에 대한 판독 또는 기입을 수행하는 자기 디스크 드라이브(652), 및 CD-ROM 또는 기타 광학 매체와 같은 분리가능한 비휘발성 광 디스크(656)에 대한 판독 및 기입을 수행하는 광 디스크 드라이브(655)를 도시하고 있다. 예시적인 운영 환경에서 사용될 수 있는 기타의 분리가능/분리불가능한 휘발성/비휘발성 컴퓨터 저장 매체는, 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지탈 비디오 테이프, 고체상태 RAM, 고체상태 ROM 등을 포함하지만, 이들로 제한되지는 않는다. 하드디스크 드라이브(641)는 인터페이스(640)와 같은 분리형 메모리 인터페이스를 통해 시스템 버스(621)에 접속되고, 자기 디스크 드라이브(651) 및 광 디스크 드라이브(655)는 일반적으로 인터페이스(650)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(621)에 접속된다.
도 6에 도시되고 상기에서 논의된 드라이브들 및 그 관련 컴퓨터 판독가능 매체는 컴퓨터에 대하여 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 6에서, 예를 들어, 하드디스크 드라이브(641) 는 오퍼레이팅 시스템(644), 어플리케이션 프로그램(645), 기타 프로그램 모듈(646) 및 프로그램 데이터(648)를 저장하는 것으로 도시되어 있다. 이러한 컴포넌트들은 오퍼레이팅 시스템(634), 어플리케이션 프로그램(635), 기타 프로그램 모듈(636) 및 프로그램 데이터(638)와 동일할 수도 있고 상이할 수도 있다는 점에 유의해야 한다. 본 명세서에서는, 오퍼레이팅 시스템(644), 어플리케이션 프로그램(645), 기타 프로그램 모듈(646) 및 프로그램 데이터(648)가 적어도 상이한 복사본임을 나타내기 위하여, 상이한 참조번호를 부여했다.
사용자는, 키보드(662), 및 통상적으로 마우스, 트랙볼 또는 터치패드로 칭해지는 포인팅 장치(661)와 같은 입력 장치를 통하여 커맨드 및 정보를 컴퓨터(610)에 입력할 수 있다. 다른 입력 장치(도시되지 않음)로는 마이크로폰, 조이스틱, 게임패드, 위성접시, 스캐너 등이 있을 수 있다. 이러한 입력 장치 및 기타 입력 장치는 시스템 버스(621)에 연결된 사용자 입력 인터페이스(660)를 통해 프로세싱 유닛(620)에 접속되지만, 병렬 포트, 게임 포트 또는 USB 포트 등과 같은 다른 인터페이스 및 버스 구조에 의해서도 접속될 수 있다.
모니터(691) 또는 기타 유형의 표시 장치도 비디오 인터페이스(690)와 같은 인터페이스를 통해 시스템 버스(621)에 접속된다. 모니터(691) 이외에, 컴퓨터는 스피터(697) 및 프린터(696)와 같이, 출력 주변 인터페이스(695)를 통해 접속될 수 있는 다른 주변 출력 장치들(도시되지 않음)을 통상적으로 포함한다.
컴퓨터(610)는 원격 컴퓨터(들)(680)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(들 )(680)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 공통 네트워크 노드일 수 있고, 도 6에는 메모리 장치(681)만이 도시되어 있지만, 그 특정 구현으로서 컴퓨터(610)에 관해 상술된 구성요소들의 다수 또는 전부를 포함할 수 있다. 도 6에 도시된 논리적 접속은 근거리 통신망(LAN)(671) 및/또는 원거리 통신망(WAN)(683)을 포함하지만, 다른 네트워크들도 포함할 수 있다. 이러한 네트워크 환경은 사무실, 기업내 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.
LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(610)는 네트워크 인터페이스 또는 어댑터(670)를 통하여 LAN(671)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(610)는 일반적으로 인터넷과 같은 WAN(673)을 통하여 통신을 확립하기 위한 모뎀(672) 또는 기타 수단을 포함한다. 외장형 또는 내장형일 수 있는 모뎀(672)은 사용자 입력 인터페이스(660) 또는 기타 적절한 메커니즘을 통하여 시스템 버스(621)에 접속된다. 네트워크화된 환경에서, 컴퓨터(610)와 관련하여 도시된 프로그램 모듈들 또는 그 일부는 원격 메모리 저장 장치(도시되지 않음)에 저장될 수 있다. 예를 들어, 도 6은 원격 어플리케이션 프로그램(685)을 메모리 장치(681)에 상주하는 것으로서 도시하고 있지만, 이에 제한되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 간의 통신 링크를 확립하기 위한 다른 수단들도 사용될 수 있다.
예시적인 개발 도구 통합
이상으로부터 볼 때, 도 1 내지 도 6의 시스템 및 방법은 안전하고 신뢰할 수 있는 컴퓨팅을 제공한다. 이러한 컴퓨팅은 예를 들어 다음과 같은 시스템(100) 분석 동작을 포함할 수 있다.
● 정적인 단일 분석(Static Singleton Analysis) - 단일의 프로젝트 및 그 관련 지원 데이터가 주어지면, 원하는 보안 목표가 만족되는지를 판정하고, 실패 또는 기타의 추천을 식별한다. 이것은 서비스에 대한 명백한 공격을 결정한다.
● 정적인 그룹 분석(Static Group Analysis) - 2개 (또는 그 이상의) 프로젝트 및 그 관련 지원 데이터가 주어지면, 원하는 보안 목표가 만족되는지를 판정하고, 실패 또는 기타의 추천을 식별한다. 이것은 하나의 프로젝트를 사용하여 다른 프로젝트를 손상시키는 간접 공격과 같은 또다른 공격들을 결정한다.
● 동적 분석 - 한 서비스가 다른 서비스에 접속되려고 할 때에, 그 한 서비스에 대한 지원 데이터가 실시간으로 (가능하게는, 캐시로부터 또는 보조 프로토콜을 사용하여) 획득되고, 그 통신이 소유된 목표를 만족시키는지에 대한 보안 평가가 이루어진다. 목표를 만족시키지 못하는 경우, 이의가 제기되거나 호출이 차단될 수 있다. 이러한 분석은 상이한 장소에서 발생할 수 있으며, 그러한 장소에 대한 두가지의 예를 들면 CLR 런타임과 통신 기반구조가 있다.
이러한 예들과 지원 데이터는 달라질 수 있다. 지원 데이터는, 예를 들어 코드 주석, 코드 분석의 결과, 보안 데이터, 구성 정보, 정책 정보, 알려진 서비스분석들의 라이브러리, 알려진 공격 및 공격 패턴들의 라이브러리 등을 포함한다. 데이터가 많을수록 평가는 (일반적인 규칙으로서) 더 정확해지지만, 시스템(100)은 이용가능한 데이터가 주어진 때에 가장 양호한 평가를 행하고, 데이터의 부재에 기 초하여 그 평가를 저하시키도록 구성될 수 있다. 또한, 이용가능한 데이터의 일부만이 신뢰될 수 있다. 이러한 경우에서, 안전 평가는 이용가능한/제한된 데이터를 사용하여 행해질 수 있다.
대안적인 구현예 - 예시적인 정책 어드바이저
주어진 구성(118)에 의해 시행되는 보안 보증은 이해하기 어려울 수 있다. 예를 들어, WSE 구성 및 정책 파일은 이러한 보증을 대부분 결정하지만, 바로 획득하기가 어려울 수 있다. 핸드라이팅된 WSE 정책의 내부 보안 검토는 일정 범위의 미세한 에러를 드러냈다. 이를 해결하기 위하여, 시스템(100)은 정책들의 컬렉션에 의해 제공되는 긍정적인 보안 보증에 대한 논평(commentary), 및 잠재적인 보안 취약성에 대한 어드바이스 둘다를 제공하는 정책 어드바이저를 제공한다. 한 구현예에서, 정책 어드바이저는 검사기 모듈(116)의 각 부분일 수 있다. 다른 구현예에서, 정책 어드바이저는 "기타 프로그램 모듈"(120)로서 나타난다.
정책 어드바이저는, 예를 들어 각각의 엔드포인트에서 익스포트(export)되는 동작(들), 각각의 동작에 관계되는 메쏘드 및 정책, 및 어떤 엘리먼트들이 인증 및 암호화되는지에 관한 정책의 요약의 리스트를 포함하는 긍정 레포트(positive report)를 생성한다. 긍정문은, 예를 들어 그들이 특정한 위협 모델 등에 대한 특정 상황에만 적용되는지의 여부를 나타낸다 (긍정 레포트에 대해서는 나중에 더 상세하게 설명된다). 또한, 정책 어드바이저는 예를 들어 특정 헤더를 서명 또는 검사하는 데에 실패한 것, 메시지들을 상관시키는 데에 실패한 것, 흔한 철자오류(typo) 등에 대한 표시를, 그러한 취약성을 정정하기 위한 소정의 어드바이스와 함 께 포함하는 부정 레포트(negative report)도 포함할 수 있다. 잠재적인 취약성의 레포트는 제안된 해결법을 포함할 수 있으므로, 어드바이저는 웹 어플리케이션에 대한 기존의 침해 도구들이 SOAP로 확장되는 것에 대한 방어가 될 수 있다. 설명을 위하여, 긍정 및 부정 레포트는 "기타 데이터"(127)의 각 부분으로서 나타난다.
정책 어드바이저는 구성(118), 정책 파일의 모델(122), 또는 정책 파일을 나타내는 소정의 다른 오브젝트 상에서 정적으로 실행된다. 설명을 위하여, 이러한 기타 오브젝트는 "기타 데이터"(127)의 각 부분으로서 나타난다. 그러한 실행 동안, 정책 어드바이저는 로컬 인증서 보관소 및 임의의 이용가능한 메시지 로그와 같은 기타 데이터(127)를 참고할 수 있다.
한 구현예에서, 정책 어드바이저는 WSE 설치 시에 개발자, 테스터 또는 오퍼레이터에 의해 사용되기 위한 것이다. 예를 들어, 정책 어드바이저는 초기의 설계 프로세스에서, 설계자가 상이한 WSE 세팅들을 실험할 때 즉각적인 피드백을 제공하기 위한 하나의 방식으로서, 개발 동안의 디버그 프로세서의 일부로서, 및/또는 예를 들어 정정된 구성을 제품에 전개하기 전의 보안 평가 및 검토의 일부로서 사용될 수 있다. 한 구현예에서, 정책 어드바이저는 자동적으로 (또한 가능하다면 원격적으로) 검사를 행하고, 새로운 이슈가 검출된 때 등에 경고를 트리거하기 위한 하나 이상의 어플리케이션 프로그래밍 인터페이스(API)를 노출시킨다. 한 구현예에서, 정책 어드바이저는 그래픽 분산 시스템 설계자에 통합된다.
예시적인 정책 어드바이저 아키텍쳐
도 7은 정책 어드바이저에 대한 예시적인 아키텍쳐를 도시하고 있다. 설명 을 위하여, 도 7의 컴포넌트들은 도 1의 컴포넌트들과 관련하여 설명된다. 도면에서, 컴포넌트의 참조 번호의 가장 앞자리 숫자는 해당 컴포넌트가 처음으로 등장하는 특정 도면을 나타낸다. 예를 들어, 블럭(702)은 정책 어드바이저를 나타내며, 이것은 프로그램 모듈(120)에 맵핑된다. 커맨드 라인 클라이언트(704) 및 ASP.NET 웹 서비스(706)는 정책 어드바이저에 의해 분석되는 구성 데이터(118)를 나타낸다. 정책 어드바이저는 각각의 서버 및 클라이언트 컴포넌트에 적용되기 위하여, 분산 시스템(100)의 서버(102) 및 클라이언트(106) 컴포넌트 상에서 실행될 수 있는 컴포넌트이다.
도 7을 참조하면, 정책 어드바이저는 WSE 설치에 관하여 자신이 결정할 수 있는 것을 반영하도록 구축한 내부 데이터 구조[블럭(704)의 동작과 도 1의 "기타 데이터"(127)의 각 부분으로 나타남]에 대하여 실행되는 쿼리(708)들의 라이브러리에 의하여 파라미터화된다. 각각의 쿼리는 정책에 관한 긍정 또는 부정 레포트(들)를 생성할 수 있으며, 이들은 관련 엔드포인트, 동작 및 웹 메쏘드로 우선순위화 및 상관될 수 있다. 일반적으로, 입력들은 WSE를 사용하여 구현되는 하나 이상의 SOAP 노드에 관련된 아래에 점들로 표시된 리스트 내에 있는 유형의 것들이다. 입력들 중의 일부는 웹 서버 디렉토리 트리, 또는 IDE(Interactive Development Environment)의 프로젝트 파일들로부터 수집될 수 있다. 아래의 리스트에 그 일부가 제시되어 있는 입력들의 대부분은 선택적인 것이며, 정책 어드바이저는 이용가능한 입력들로부터 가능한 한 정확한 레포트를 제공한다. 가장 기본적인 모드는 구성(118) 또는 모델(122)의 단일 PolicyCache 파일[아래의 3번째 게시 항목 참조] 을 분석하는 것일 것이다.
● 각각의 웹 서비스에 대한 Web.config 파일,
● 각각의 커맨드 라인 또는 윈도우즈 어플리케이션에 대한 App.config 파일,
● 정책들을 포함하는 PolicyCache 파일,
● 웹 서비스를 위한 asmx 및 DLL 파일 (이로부터 웹 서비스 상의 각 동작에 대응하는 소스 코드가 결정됨),
● 웹 서비스 클라이언트를 위한 exe 파일 (이로부터 클라이언트에 알려지는 노드들이 결정됨),
● 인입 및 인출 SOAP 메시지의 트레이스를 포함하는 파일 (일반적으로, .webinfo),
● 국부적으로 설치된 X.509 인증서 (이로부터 검사에 이용될 수 있는 서브젝트 네임 등이 결정될 수 있음), 및/또는
● 보안 세팅 도구에 의하여 수집되고, 정책을 생성하는 데에 사용되는 파라미터
예시적인 쿼리
쿼리들은 도 7의 박스(708)에 나타난 바와 같이, 간단한 구문적 검사로부터 보다 상세한 검증에 이르기까지의 6개의 카테고리로 분류된다. 한 구현예에서, 이러한 쿼리들 중 임의의 것이 실제로는 아무것도 잘못되지 않은 경우에 "긍정 오류(false positive)"를 생성하는 경우, 시스템(100)은 사용자에게 간단한 UI를 제공 하여, 검사를 행한 후의 긍정 오류를 억제한다. 6개의 카테고리는 다음과 같다.
● 스키마 및 스코핑에 관한 쿼리(표 1),
● 각각의 노드 구성에 관한 쿼리(표 2),
● 정책 디스패치에 관한 쿼리(표 3),
● 각각의 정책에 관한 쿼리(표 4 및 5),
● 정책 호환성에 관한 쿼리, 및
● 커스텀 쿼리
표 1은 정책 어드바이저에 의해 사용될 식별자들의 스키마 검사 및 스코핑에 관한 예시적인 쿼리들을 나타내고 있다.
쿼리 조건 리스크 치료 동작
스키마 이 정책 문서는 정책 어드바이저에 의해 기대되는 스킴에 순응하지 않는다. WSE는 이러한 정책 문서를 잘못 해석할 수 있다. 그러나, 이들은 정책 어드바이저의 스코프 외부에 있음에도 불구하고 WSE에 의해 수용될 수 있기 때문에 이러한 경고를 트리거하는 소정의 구성이 존재한다. 이러한 구성은 커스텀 정책 어써션 및 커스텀 보안 토큰을 포함한다. 스키마에 순응
맵- 다수의 인증서 동일한 인증서가 다수의 서비스에 의해 사용되는지를 검사. 리디렉션의 리스크 개별 서비스에 대한 개별 인증서를 신중하게 사용
맵/트레이스 - 알려지지 않은 X509 이용가능한 인증서들을 검사함으로써 발견된 알려지지 않은 X509 서브젝트 네임을 경고. 허가가 인증서 보관소로의 액세스에 적합한지도 검사 정책이 만족되지 않는다. 서브젝트 네임을 정정, 허가를 정정
스키마 사용 사용 속성을 wsp로 설정: 임의의 정책 어써션 상에서 거부 등으로 설정 정책을 시행할 때, 즉 메시지가 송신될 때, WSE가 이러한 속성을 무시하기 때문에, 잘못된 거동이 발생할 수 있다.
<스키마 검사 및 식별자 스코핑에 관한 예시적인 쿼리>
쿼리 조건 리스크 치료 동작
구성- 토큰 발행기 웹 서비스는 SCT를 자동 발행하기 위한 <tokenIssuer> 섹션은 갖지만, SCT를 서명하기 위한 <serverToken> 엘리먼트는 갖지 않도록 구성된다. 서명되지 않은 SCT를 수용할 리스크 <tokenIssuer> 섹션 내에 <serverToken> 엘리먼트를 포함
구성- 리플레이 토큰 타입들이 사용 중인 경우, 리플레이 검출을 지원하는 토큰 타입(유저네임 및 2개의 커버로스 타입)에 대한 리플레이 보호를 스위치온하는 데에 실패. 리플레이의 리스크 <securityTokenManager> <replayDetection enabled="true" windowInseconds="300"/> </securityTokenManager> 등을 포함
<어플리케이션 또는 웹 구성 세팅에 대한 예시적인 쿼리>
쿼리 조건 리스크 치료 동작
맵- 미사용 정책 이 정책은 라벨을 갖지 않거나, 참조되지 않는 라벨을 갖는다. 이 정책은 실수로 미사용될 수 있다. 정책을 사용하거나 제거
맵- 디폴트 디폴트 정책은 특정 정책보다 더 많은 것을 요구해야만 한다. 서비스가, 보다 더 강한 특정 정책 대신에 디폴트 정책을 할당받는다. 디폴트 정책을 강화
<정책 디스패치를 위한 예시적인 쿼리>
요청 응답/폴트
SOAP. WSS, WS-Addressing 헤더 메시지 술어 메시지 부분 메시지 술어 메시지 부분
wsp:Body() X X
wse:Timestamp() X X X X
wse:UsernameToken()
wsp:Header(wsa:MessageId) X X X X
wsp:Header(wsa:Relatesto) X X
wsp:Header(wsa:To) X X X X
wsp:Header(wsa:Action) X X X X
wsp:Header(wsa:From)
wsp:Header(wsa:ReplyTo) X X
wsp:Header(wsa:FaultTo) X
<개별 정책에 대한 예시적인 쿼리>
표 4의 쿼리(개별 정책에 대한 쿼리)와 관련하여, 시스템(100)은 각각의 (요청, 응답, 폴트) 트리플의 메시지 패턴을 다음과 같이 분류한다.
● requestAction이 "RST/SCT"이면, RST/RSTR 핸드쉐이크에 적용
● 그와 달리, 응답이 비어 있으면, 원샷 메시지에 적용
● 그렇지 않으면, RPC 핸드쉐이크에 적용
각각의 (요청, 응답, 폴트) 트리플에 대하여, 정책 어드바이저는 그 분류, 및 아래의 추천으로부터의 임의의 편이(deviation)를 보고한다. 원샷 메시지의 경우에서, 정책 어드바이저는 Request 칼럼을 적용한다. 다른 경우에서, 정책 어드바이저는 Request 및 Response/Fault 칼럼 둘다를 적용한다. 로우 H와 칼럼 P 아래의 X는, 헤더 H가 엘리먼트 P에 반드시 포함되어야 한다는 것을 의미하며, 그렇지 않은 경우에는 에러가 존재한다. 한편, 모든 X가 만족되는 경우, 적어도 내부 공격자가 없다면, 메시지 패턴 상의 상관에 대한 동의가 얻어져야만 한다.
쿼리 조건 리스크 치료 동작
정책- Request 요청들이 서명되지 않는다. 공격자가 검출되지 않고서 요청을 대체 또는 수정할 수 있다. wsse:Integrity 어써션을 포함하는 요청에 대한 정책을 지정
정책- Response/Fault 응답 정책은 존재하지만, 폴트 정책은 존재하지 않는다. 응답 또는 폴트로 탬퍼링할 리스크 wsse:Integrity 어써션을 포함하는 응답 및 폴트 둘다에 대한 정책을 지정
정책- Body 엘리먼트 wsp:Body()가 서명 내에 포함되지 않는다. 공격자가 검출되지 않고서 본문을 대체 또는 수정할 수 있다. wsse:Integrity 어써션의 wsse:MessageParts 내에 wsp:Body()를 포함
정책- Replay wsse:MessageParts 또는 wsse:MessagePredicate로부터, wse:Timestamp 또는 wsa:MessageID가 누락된다. 메시지가 검출되지 않고서 이러한 서비스에 리플레이될 수 있다. wsse:Integrity 어써션의 wsse:MessageParts 및 wsse:MessagePredicate 어써션 둘다에 wse:Timestamp() 및 wsp:Header(wsa:MessageID)를 포함
정책- RelatesTo wsse:MessagePredicate 또는 wsse:MessageParts로부터 헤더 wsa:RelatesTo가 누락된다. 응답 또는 폴트가 잘못된 요청과 상관될 수 있다. wsse:Integrity 어써션의 wsse:MessageParts 및 wsse:MessagePredicate 어써션 둘다에 wsp:Header(wsa:RelatesTo)를 포함
정책- Redirection wsse:MessageParts 또는 wsse:MessagePredicate로부터 wsa:To 또는 wsa:Action이 누락된다. 메시지가 검출되지 않고서 다른 서비스에 리디렉션될 수 있다. wsse:Integrity 어써션의 wsse:MessageParts 및 wsse:MessagePredicate 어써션 둘다에 wsp:Header(wsa:To) 및 wsp:Header(wsa:Action)을 포함
맵- Fault 응답들은 서명되지만, 폴트들은 서명되지 않는다. 공격자가 검출되지 않고서 폴트를 대체 또는 수정할 수 있다. wsse:Integrity 어써선을 포함하는 폴트 메시지에 대한 정책을 지정
정책- ReplyTo wsse:MessageParts 또는 wsse:MessagePredicate로부터 헤더 wsa:ReplyTo가 누락된다. 공격자가 검출되지 않고서 가짜의 wsa:ReplyTo를 삽입할 수 있기 때문에, 응답이 잘못 디렉션될 수 있다. 또한, 응답이 기대되는 경우에는, 이러한 엘리먼트를 규정하는 WS-Addressing이 반드시 존재해야 한다. wsse:Integrity 어써션의 wsse:MessageParts 및 wsse:MessagePredicate 어써션 둘다에 wsp:Header(wsa:ReplyTo)를 포함
정책- FaultTo 요청 정책에서, wsa:FaultTo가 wsse:MessageParts에 포함되지 않는다. 공격자는 폴트 메시지를 송신기로부터 리디렉션하기 위하여, 가짜의 wsa:FaultTo를 삽입할 수 있다. wsse:Integrity 어써션의 wsse:MessageParts 내에 wsp:Header(wsa:FaultTo)를 포함
정책- Dictionary 유저네임 토큰으로부터 유도된 키로부터 계산된 서명이 존재하고, 유저네임 토큰은 암호화되지 않는다. 공격자는 사용자 패스워드 상에 사전 공격(dictionary attack)을 탑재하기 위하여, 서명의 SignatureValue를 활용할 수 있다. wsse:Confidentiality 어써션의 wsse:MessageParts 둘다에 wse:UsernameToken()을 포함
정책- UnboundId entityToken 응답 정책은 속성 wse:IdentityToken="true"를 갖는 wssp:SecurityToken을 포함하지만, 요청 정책은 아무것도 포함하지 않는다. 응답 정책이 만족되지 않는다. 요청 정책 내에 IdentityToken을 선택
정책- Confidentiality wsse:Confidentiality 어써션이 "true"로 설정된 wse:IdentityToken 및 임의의 특정한 wsse:Claims를 갖지 않는 wsse:Confidentiality 어써션에서 사용되는 wssp:Security 토큰 메시지를 암호화하는 데에 부적절한 키가 사용될 수 있다. wse:IdentityToken을 "true"로 설정하거나, 특정한 wsse:Claims 엘리먼트를 포함
<개별 정책에 대한 다른 예시적인 쿼리>
정책 호환성에 관한 쿼리와 관련하여, 시스템(100)은,
● 임의의 2개의 접속된 엔드포인트에 대한 정책의 교차(intersection)를 계산하고, 그러한 교차의 속성을 기술하고,
● 호환불가능한 클라이언트와 서비스 정책을 경고하고/하거나,
● 편집된 정책을 경고하고, 그러한 편집된 정책이 정책 생성 동안 수집된 보안 개념(security intention)을 계속 제공하는지를 검사한다.
커스텀 쿼리와 관련하여, 시스템(100)은 다음을 허용한다.
● 특정 헤더의 포함을 명령하거나 특정 알고리즘을 반대하도록 커스텀 쿼리를 정의하기 위한 조직, 및/또는
● 로그파일 eg <Password> 등에서 개인적으로 식별가능한 정보(PII)를 검출하기 위한 프라이버시 도구의 실행. 이러한 구현예에서, 정책 어드바이저는 유저네임 또는 인증서 서브젝트로서 아이덴티티를 노출하는 것과 같은 보안 헤더 내에서의 프라이버시 발행을 경고한다.
예시적인 긍정 레포트
잠재적인 에러들을 보고하는 쿼리들 이외에, 정책 어드바이저는 구성 데이터(118)를 요약하여, 인간 사용자가 그 암시를 이해하고 에러일 수 있는 비정규성을 찾아내는 것을 돕는 긍정 레포트를 생성한다. 한 구현예에서, 정책 어드바이저는 예를 들어 다음과 같은 것들 중 하나 이상을 수행한다.
● 할당된 정책(명시적으로 또는 디폴트로 할당됨)과 함께, 정책 파일 내의 알려진 엔드포인트 및 동작을 디스플레이한다. 또한, 정책 어드바이저는 메시지 트레이스에 의해 행해진 것을 디스플레이한다.
● 트레이스 내의 메시지의 서명되고 암호화된 부분을 강조한다.
● 각각의 엔드포인트 및 동작에 대하여, 각각의 메시지가 수용된 후에 송신기와 수신기 간에 어떤 동의가 유지되는지에 관한 긍정문(positive statement)을 제공한다. 동의는 다음과 같은 수개의 메커니즘으로부터 이루어질 수 있다.
○ 요청을 수용한 후, 요청의 서명된 컨텐츠에 관한 동의가 존재할 수 있다 (즉, 서명된 엘리먼트와 서명자의 아이덴티티).
○ 요청에 대한 응답을 수용한 후, 응답의 서명된 컨텐츠, 및 요청의 서명된 컨텐츠(적절하게 상관되어 있는 경우)에 관한 동의가 존재할 수 있다.
○ RST/RTSR 핸드쉐이크에 의해 확립된 보안 컨택스트가 주어지면, 송신 및 수신된 메시지의 서명된 컨텐츠 및 보안 컨텍스트(송신기 및 수신기의 아이덴티티를 포함할 수 있음)에 관한 동의가 존재할 수 있다.
● 메시지 트레이스 내에 발생하는 임의의 비표준 헤더들을, 암호화 또는 서명 여부를 나타내는 표시와 함께 보고한다.
● 예를 들어, 서브젝트 네임, 키 식별자, 유저네임 등과 같이, 메시지 트레이스 또는 정책 파일 내의 모든 "아이덴티티"을 보고한다.
예시적인 정책 어드바이저 출력
표 6은 인입 메시지(132)의 서명 및 암호화를 명령하는 단순 정책으로 구성된 서버(102) 상에서 실행되는 정책 어드바이저의 예시적인 출력을 나타낸 것이다.
아래의 웹 메쏘드(...)를 익스포트하는 머신 MSRC-XXX의 로컬 구성에 관한 레포트 ● 서비스 http://server/MyApp/MyAppService.asmx는 커스텀 토큰 관리자 UsernameSignPolicyService.CustomUsernameTokenManager를 사용한다. ? 이 클래스는 패스워드 검증에 관한 완전한 제어를 갖는다. ● 디폴트 "널" 정책은 http://server/MyApp/MyAppService.asmx 및 동작 http://Contoso.com/MyRequest에 송신된 메시지들에 관련된 응답 및 폴트 메시지에 적용된다. - 이 메시지는 서명되지도 않고 암호화되지도 않는다. - 누구라도 이러한 메시지를 위조할 수 있다. ● serverPolicyCache.xml의 13행에 있는 username-token-signed-x509-encrypted 정책은 동작 http://Contoso.com/MyRequest와 함께 http://server/MyApp/MyAppService.asmx에 송신된 요청 메시지에 적용되며, MyAppService.asmx.cs의 82행에 있는 웹메쏘드 MyRequest를 인보크한다. + 웹메쏘드 논증(argument)을 포함하는 본문은 서명된다. + 웹 메쏘드 논증을 포함하는 본문은 암호화된다. - 중요한 헤더(<To>, <Action>)는 선택적이며, 존재하는 경우에만 서명된다. - 유저네임 토큰은 암호화되지 않으며, 도청자에게 개인 식별자를 드러낼 수 있다 (샘플 메시지 참고). + <Created> 타임스탬프가 서명된다. - 요청은 과거 5분 이내에 이미 프로세싱된 요청의 리플레이일 수 있다 (서명된 <Created> 및 <MessageId> 엘리먼트를 사용하여 리플레이를 방지하는 방법에 대해서는 WSE 샘플 참고). - 요청은 암호화되지만 응답은 암호화되지 않을 수 있다. 응답 본문은 요청으로부터의 비밀 데이터를 드러낼 수 있다. - 응답이 서명되지 않기 때문에, 응답은 요청과 상관될 수 없다.
<개별 정책에 대한 다른 예시적인 쿼리>
결론
웹 서비스 구성의 보안을 검사하기 위한 시스템 및 방법이 구조적 특징 및/또는 방법론적인 동작이나 동작에 특정한 언어로 설명되었지만, 첨부된 특허청구범위에 정의되어 있는 구현예들은 여기에 설명된 특정한 특징이나 동작들로만 제한되는 것이 아니라는 점을 알 것이다. 예를 들어, 한 구현예에서, 모델(122)이 (예를 들어, TulaFale 스크립팅을 사용하여) 모델로서 설명된다. 따라서, 특정한 특징 및 동작들은 청구된 발명의 사상을 구현하는 예시적인 형태로서 개시된 것이다.
웹 서비스 구성의 보안을 검사하기 위한 시스템 및 방법이 제공된다.
<참고문헌>
[1]
"웹 서비스 인증을 위한 의미론(A semantics for web services authentication)" :
K.Bhargavan, C.Fournet, A.D.Gordon
프로그래밍 언어의 원리에 관한 제31차 ACM 심포지엄(POPL'04)의 198-209 페이지(2004년). 확장된 버전은 마이크로소프트 연구 기술 보고서 MSR-TR-2003-83
[2]
"TulaFale: 웹 서비스를 위한 보안 도구(TulaFale: A security tool for webservices)" :
K.Bhargavan, C.Fournet, A.D.Gordon, R.Pucella
공개용으로 제출됨. http://securing.ws에서 입수가능(2003년 3월).
[3]
"프롤로그 규칙에 기초하는 효율적인 암호화 프로토콜 검증기(An efficient cryptographic protocol verifier based on Prolog rules)" :
B.Blanchet
제14차 IEEE 컴퓨터 보안 기구 워크샵의 회보의 82-96 페이지. IEEE 컴퓨터 소사이어티 프레스(2001년).
[4]
"보안 프로토콜의 비밀성으로부터 확실성까지(From secrecy to authenticity in security protocols)" :
B.Blanchet
제3차 국제 정적 분석 심포지엄(SAS'02)의 회보. 컴퓨터 과학 강의 노트 볼륨 2477의 342-359 페이지. Springer-Verlag(2002년).
[5]
"웹 서비스 정책 프레임워크(WS-Policy)(Web services policy framework)"
D.Box, F.Curbera, M.Hondo, C.Kaler, D.Langworthy, A.Nadalin, N.Nagaratnam, M.Nottingham, C.von Riegen, J.Shewchuk
(2003년 5월)
[6]
"웹 서비스 정책 어써션 언어(WS-PolicyAssertions)(Web services policy assertions language)"
D.Box, M.Hondo, C.Kaler, H.Maruyama, A.Nadalin, N.Nagaratnam, P.Patrick, C.von Riegen, J.Shewchuk
(2003년 5월)
[7]
"웹 서비스 보안 정책 언어(WS-SecurityPolicy)(Web services security policy language)"
G.Della-Libera, P.Hallam-Baker, M.Hondo, T.Janczuk, C.Kaler, H.Maruyama, N.Nagaratnam, A.Nash, R.Philpott, H.Prafullchandra, J.Shewchuk, E.Waingold, R.Zolfonoon
(2002년 12월)
부록 A
예시적인 라이브러리 스크립트
Figure 112005023408994-PAT00026
Figure 112005023408994-PAT00027
Figure 112005023408994-PAT00028
Figure 112005023408994-PAT00029
Figure 112005023408994-PAT00030
부록 B
예시적인 샘플 정책
Figure 112005023408994-PAT00031
Figure 112005023408994-PAT00032
Figure 112005023408994-PAT00033
부록 C
정책 구성으로부터 술어로의 예시적인 변환
필터를 위한 규칙
Figure 112005023408994-PAT00034
Figure 112005023408994-PAT00035
Figure 112005023408994-PAT00036
부록 D
링크로부터 정책 및 어써션으로의 예시적인 변환
Figure 112005023408994-PAT00037
Figure 112005023408994-PAT00038
부록 E
예시적으로 작성된 TulaFale 스크립트
Figure 112005023408994-PAT00039
Figure 112005023408994-PAT00040
Figure 112005023408994-PAT00041
Figure 112005023408994-PAT00042
Figure 112005023408994-PAT00043
Figure 112005023408994-PAT00044

Claims (20)

  1. 하나 이상의 엔드포인트 간에서의 메시지 교환 동안 시행되는 상세화된 보안 정책(detailed security policy)을 모델로 번역하는 단계 - 상기 하나 이상의 엔드포인트는 분산 오퍼레이팅 환경 내에서 네트워크화된 각각의 주체(principal)를 호스트함 -, 및
    상기 모델을 평가하여, 상기 상세화된 보안 정책이 상기 하나 이상의 엔드포인트 중 적어도 한 엔드포인트의 하나 이상의 보안 목표를 시행하는지를 판정하는 단계
    를 포함하는 컴퓨터 구현 방법.
  2. 제1항에 있어서,
    상기 상세화된 보안 정책은 상기 하나 이상의 엔드포인트에 대한 구성 데이터 내에 지정되는 컴퓨터 구현 방법.
  3. 제1항에 있어서,
    상기 상세화된 보안 정책은, 엔드포인트들 간의 신뢰 관계, 상기 하나 이상의 엔트포인트 중 한 엔드포인트에 의해 지원되는 서비스, 및 상기 하나 이상의 엔드포인트 중 한 엔드포인트에 의해 지원되는 동작 중 하나 이상을 나타내는 컴퓨터 구현 방법.
  4. 제1항에 있어서,
    상기 모델은 동시적인 프로세스들(concurrent process)의 계산법(calculus)을 사용하여 상기 하나 이상의 엔드포인트를 나타내는 것을 더 포함하는 컴퓨터 구현 방법.
  5. 제1항에 있어서,
    상기 모델은 논리적 술어(logical predicate)들을 사용하여 메시지 필터링 및 프로세싱을 나타내는 것을 더 포함하는 컴퓨터 구현 방법.
  6. 제1항에 있어서,
    상기 모델은 상기 하나 이상의 엔드포인트에 관련된 링크 디스크립션 내에 기술된 상기 하나 이상의 보안 목표의 형식적인 스펙(formal specification)을 더 포함하는 컴퓨터 구현 방법.
  7. 제1항에 있어서,
    상기 상세화된 보안 정책은 기본 어써션(base assertion) 상의 논리적 법칙(들)(logical fomula)을 포함하는 선언적인 데이터로 지정되는 컴퓨터 구현 방법.
  8. 제1항에 있어서,
    상기 하나 이상의 엔드포인트는 클라이언트 및 서버를 포함하는 다수의 엔드포인트인 컴퓨터 구현 방법.
  9. 제1항에 있어서,
    상기 하나 이상의 보안 목표 중 한 보안 목표는 상기 메시지들에 관련된 컨텐츠의 적어도 서브세트의 비밀성(secrecy) 또는 무결성(integrity)에 관한 것인 컴퓨터 구현 방법.
  10. 제1항에 있어서,
    상기 모델을 평가하는 단계는, 상기 하나 이상의 엔드포인트들 중 한 엔드포인트가 교환되는 메시지들에 대한 재작성 공격(rewriting attack)에 취약한지를 자동적으로 판정하는 단계를 포함하는 컴퓨터 구현 방법.
  11. 제1항에 있어서,
    상기 번역하는 단계에서, 상기 상세화된 보안 정책에 관련된 정보의 서브세트는 상기 모델을 생성하는 데에 이용될 수 없고,
    상기 모델을 평가하는 단계는, 상기 서브세트를 자동적으로 시뮬레이션하여, 상기 적어도 하나의 엔드포인트의 상기 하나 이상의 보안 목표가 상기 정보의 서브세트에 무관하게 시행되는지를 판정하는 단계를 더 포함하는 컴퓨터 구현 방법.
  12. 제1항에 있어서,
    상기 상세화된 보안 정책이 수정된 것으로 판정하는 단계,
    상기 판정에 응답하여, 상기 모델을 평가하여, 수정된 대로의 상기 상세화된 보안 정책이 상기 하나 이상의 엔드포인트의 보안 목표(들)를 시행하는지를 판정하는 단계, 및
    상기 보안 목표(들)가 만족되는 경우에만, 수정된 대로의 상기 상세화된 보안 정책을 시행하는 단계
    를 더 포함하는 방법.
  13. 프로세서에 의해 실행될 수 있는 컴퓨터 프로그램 명령어들을 포함하는 컴퓨터 판독가능 매체로서,
    상기 컴퓨터 프로그램 명령어들은,
    하나 이상의 엔드포인트 간에서의 메시지 교환 동안 시행되는 상세화된 보안 정책을 모델로 변환하는 단계 - 상기 하나 이상의 엔드포인트는 분산 오퍼레이팅 환경 내에서 네트워크화된 각각의 주체를 호스트함 -, 및
    상기 모델을 평가하여, 상기 상세화된 보안 정책이 상기 하나 이상의 엔드포인트 중 적어도 한 엔드포인트의 하나 이상의 보안 목표를 시행하는지를 판정하는 단계
    를 수행하기 위한 것인 컴퓨터 판독가능 매체.
  14. 제13항에 있어서,
    상기 상세화된 보안 정책은, 엔드포인트들 간의 신뢰 관계, 상기 하나 이상의 엔트포인트 중 한 엔드포인트에 의해 지원되는 서비스, 및 상기 하나 이상의 엔드포인트 중 한 엔드포인트에 의해 지원되는 동작 중 하나 이상을 나타내는 컴퓨터 판독가능 매체.
  15. 제13항에 있어서,
    상기 하나 이상의 엔드포인트는 클라이언트 및 서버를 포함하는 다수의 엔드포인트인 컴퓨터 구현 방법.
  16. 제13항에 있어서,
    상기 변환하는 단계를 위한 컴퓨터 프로그램 명령어에서, 상기 상세화된 보안 정책에 관련된 정보의 서브세트는 상기 모델을 생성하는 데에 이용될 수 없고,
    상기 모델을 평가하기 위한 컴퓨터 프로그램 명령어는, 상기 서브세트를 자동적으로 시뮬레이션하여, 상기 적어도 하나의 엔드포인트의 상기 하나 이상의 보안 목표가 상기 정보의 서브세트에 무관하게 시행되는지를 판정하는 컴퓨터 프로그램 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  17. 제13항에 있어서,
    상기 상세화된 보안 정책이 수정된 것으로 판정하는 단계,
    상기 판정에 응답하여, 상기 모델을 평가하여, 수정된 대로의 상기 상세화된 보안 정책이 상기 하나 이상의 엔드포인트의 보안 목표(들)를 시행하는지를 판정하는 단계, 및
    상기 보안 목표(들)가 만족되는 경우에만, 수정된 대로의 상기 상세화된 보안 정책을 시행하는 단계
    를 위한 프로세서에 의해 실행될 수 있는 컴퓨터 프로그램 명령어들을 더 포함하는 컴퓨터 판독가능 매체.
  18. 스키마 검사 또는 식별자 스코핑(scoping) 쿼리, 엔드포인트 구성 세팅 쿼리, 정책 디스패치 쿼리, 개별 정책 쿼리, 정책 호환성 쿼리, 또는 커스텀 쿼리 중 하나 이상을 이용하여, 상세화된 보안 정책에 쿼리를 행하는 단계 - 상기 보안 정책은 분산 오퍼레이팅 환경 내에서 네트워크화된 각각의 주체를 호스트하는 하나 이상의 엔드포인트 간에서의 메시지(들)의 교환에 관련됨-, 및
    상기 쿼리에 응답하여, 긍정 또는 부정 보안 레포트를 생성하는 단계
    를 포함하는 컴퓨터 구현 방법.
  19. 제18항에 있어서,
    상기 상세화된 보안 정책은 구성 파일 또는 오브젝트 모델 내에 있는 컴퓨터 구현 방법.
  20. 제18항에 있어서,
    상기 긍정 레포트는 정책을 할당받은 엔드포인트 및 동작의 디스크립션, 트레이스(trace) 내의 메시지의 서명되거나 암호화된 부분의 표시, 메시지가 수용된 후의 송신기와 수신기 간의 동의에 관한 긍정문(positive statement), 및 메시지 트레이스 내에서 발생한 임의의 비표준 헤더의 표시 중 하나 이상을 포함하고,
    상기 부정 레포트는 특정 메시지 헤더의 서명 또는 검사에 대한 실패의 표시, 메시지 상관의 실패, 철자오류(typo), 및 취약성을 어떻게 정정할지에 관한 어드바이스 중 하나 이상을 포함하는 컴퓨터 구현 방법.
KR1020050037233A 2004-05-04 2005-05-03 웹 서비스 구성의 보안 검사 방법 KR20060076152A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US56813804P 2004-05-04 2004-05-04
US60/568,138 2004-05-04
US11/025,488 US20050268326A1 (en) 2004-05-04 2004-12-29 Checking the security of web services configurations
US11/025,488 2004-12-29

Publications (1)

Publication Number Publication Date
KR20060076152A true KR20060076152A (ko) 2006-07-04

Family

ID=34939629

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050037233A KR20060076152A (ko) 2004-05-04 2005-05-03 웹 서비스 구성의 보안 검사 방법

Country Status (9)

Country Link
US (1) US20050268326A1 (ko)
EP (1) EP1596557A2 (ko)
JP (1) JP2005322234A (ko)
KR (1) KR20060076152A (ko)
AU (1) AU2005201743A1 (ko)
BR (1) BRPI0503008A (ko)
CA (1) CA2506265A1 (ko)
MX (1) MXPA05004863A (ko)
RU (1) RU2005113389A (ko)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1540446A2 (en) 2002-08-27 2005-06-15 TD Security, Inc., dba Trust Digital, LLC Enterprise-wide security system for computer devices
US8635661B2 (en) 2003-12-23 2014-01-21 Mcafee, Inc. System and method for enforcing a security policy on mobile devices using dynamically generated security profiles
US7559080B2 (en) * 2004-05-04 2009-07-07 Microsoft Corporation Automatically generating security policies for web services
US7559087B2 (en) * 2004-12-10 2009-07-07 Microsoft Corporation Token generation method and apparatus
US8572676B2 (en) * 2008-11-06 2013-10-29 Mcafee, Inc. System, method, and device for mediating connections between policy source servers, corporate repositories, and mobile devices
US8495700B2 (en) 2005-02-28 2013-07-23 Mcafee, Inc. Mobile data security system and methods
US20060294383A1 (en) * 2005-06-28 2006-12-28 Paula Austel Secure data communications in web services
US20070169199A1 (en) * 2005-09-09 2007-07-19 Forum Systems, Inc. Web service vulnerability metadata exchange system
ATE401614T1 (de) * 2006-05-26 2008-08-15 Sap Ag Verfahren und vorrichtung zum sicheren nachrichtenverkehr in einem netzwerk
US7970746B2 (en) * 2006-06-13 2011-06-28 Microsoft Corporation Declarative management framework
US8259568B2 (en) 2006-10-23 2012-09-04 Mcafee, Inc. System and method for controlling mobile device access to a network
US20090070853A1 (en) * 2007-09-12 2009-03-12 International Business Machines Corporation Security Policy Validation For Web Services
US20090077615A1 (en) * 2007-09-13 2009-03-19 Chung Hyen V Security Policy Validation For Web Services
US8677141B2 (en) * 2007-11-23 2014-03-18 Microsoft Corporation Enhanced security and performance of web applications
US8732838B2 (en) * 2008-06-26 2014-05-20 Microsoft Corporation Evaluating the effectiveness of a threat model
US7747742B2 (en) * 2008-06-27 2010-06-29 Microsoft Corporation Online predicate checking for distributed systems
US8291433B2 (en) * 2008-06-27 2012-10-16 Microsoft Corporation Unified, configurable services stack for integration of enterprise applications
US8290841B2 (en) * 2008-08-21 2012-10-16 International Business Machines Corporation System and method for automatically generating suggested entries for policy sets with incomplete coverage
US8141158B2 (en) * 2008-12-31 2012-03-20 International Business Machines Corporation Measuring coverage of application inputs for advanced web application security testing
US8078870B2 (en) * 2009-05-14 2011-12-13 Microsoft Corporation HTTP-based authentication
US9111004B2 (en) * 2009-12-17 2015-08-18 International Business Machines Corporation Temporal scope translation of meta-models using semantic web technologies
US8631071B2 (en) * 2009-12-17 2014-01-14 International Business Machines Corporation Recognition of and support for multiple versions of an enterprise canonical message model
US9026412B2 (en) * 2009-12-17 2015-05-05 International Business Machines Corporation Managing and maintaining scope in a service oriented architecture industry model repository
US9544143B2 (en) 2010-03-03 2017-01-10 Duo Security, Inc. System and method of notifying mobile devices to complete transactions
US9532222B2 (en) 2010-03-03 2016-12-27 Duo Security, Inc. System and method of notifying mobile devices to complete transactions after additional agent verification
US8572710B2 (en) * 2010-03-18 2013-10-29 Microsoft Corporation Pluggable token provider model to implement authentication across multiple web services
US8935384B2 (en) 2010-05-06 2015-01-13 Mcafee Inc. Distributed data revocation using data commands
CA2711855A1 (en) 2010-08-25 2010-11-03 Ibm Canada Limited - Ibm Canada Limitee Secure third party scripting environment
US20120117656A1 (en) * 2010-11-10 2012-05-10 Sap Ag Security Validation of Business Processes
US8935743B2 (en) * 2011-01-27 2015-01-13 Sap Se Web service security cockpit
US9646171B2 (en) * 2011-02-24 2017-05-09 Adobe Systems Incorporated Method and apparatus for correctly binding form objects to encrypted XML data
US9130937B1 (en) * 2011-03-07 2015-09-08 Raytheon Company Validating network communications
US9224010B2 (en) 2011-09-01 2015-12-29 International Business Machines Corporation Secure document creation from potentially unsecure source templates
US20130073704A1 (en) * 2011-09-16 2013-03-21 Tripwire, Inc. Methods and apparatus for remediating policy test failures, including promoting changes for compliance review
US8819491B2 (en) 2011-09-16 2014-08-26 Tripwire, Inc. Methods and apparatus for remediation workflow
US8862941B2 (en) 2011-09-16 2014-10-14 Tripwire, Inc. Methods and apparatus for remediation execution
US20130254553A1 (en) * 2012-03-24 2013-09-26 Paul L. Greene Digital data authentication and security system
WO2014050431A1 (ja) 2012-09-26 2014-04-03 三菱電機株式会社 プログラム検証装置、プログラム検証方法およびプログラム検証プログラム
US9112851B2 (en) 2013-06-18 2015-08-18 Sap Se Integrating web protocols with applications and services
EP3304336B1 (en) 2015-06-01 2019-10-09 Duo Security, Inc. Method for enforcing endpoint health standards
CN105743643A (zh) * 2016-04-26 2016-07-06 百度在线网络技术（北京）有限公司 通信安全的检测方法及装置
US10523695B2 (en) * 2017-07-24 2019-12-31 Sap Se Threat modeling tool using machine learning
US10412113B2 (en) * 2017-12-08 2019-09-10 Duo Security, Inc. Systems and methods for intelligently configuring computer security
US11080564B2 (en) * 2018-09-28 2021-08-03 Microsoft Technology Licensing, Llc Content classification tool with re-classification techniques
US11658962B2 (en) 2018-12-07 2023-05-23 Cisco Technology, Inc. Systems and methods of push-based verification of a transaction
CN112787820B (zh) * 2021-01-02 2022-02-11 浙江大学 一种适用于硬件实现的轻量级认证加密解密实现方法
US11575687B2 (en) * 2021-02-09 2023-02-07 Sap Se Holistic and verified security of monitoring protocols

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002056176A (ja) * 2000-06-01 2002-02-20 Asgent Inc セキュリティポリシー構築方法及び装置並びにセキュリティポリシー構築を支援する方法及び装置
US20030061506A1 (en) * 2001-04-05 2003-03-27 Geoffrey Cooper System and method for security policy
US20030014644A1 (en) * 2001-05-02 2003-01-16 Burns James E. Method and system for security policy management
US20050193222A1 (en) * 2004-03-01 2005-09-01 Greene William S. Providing secure data and policy exchange between domains in a multi-domain grid by use of a service ecosystem facilitating uses such as supply-chain integration with RIFD tagged items and barcodes

Also Published As

Publication number Publication date
MXPA05004863A (es) 2006-05-31
EP1596557A2 (en) 2005-11-16
AU2005201743A1 (en) 2005-11-24
JP2005322234A (ja) 2005-11-17
CA2506265A1 (en) 2005-11-04
US20050268326A1 (en) 2005-12-01
BRPI0503008A (pt) 2006-01-10
RU2005113389A (ru) 2006-11-10

Similar Documents

Publication Publication Date Title
KR20060076152A (ko) 웹 서비스 구성의 보안 검사 방법
US7559080B2 (en) Automatically generating security policies for web services
Bhargavan et al. Verifying policy-based security for web services
Sassaman et al. Security applications of formal language theory
Wei et al. Preventing SQL injection attacks in stored procedures
Bhargavan et al. An advisor for web services security policies
King et al. Implicit flows: Can’t live with ‘em, can’t live without ‘em
Bhargavan et al. Verified interoperable implementations of security protocols
US9268945B2 (en) Detection of vulnerabilities in computer systems
Bhargavan et al. Secure sessions for web services
Almorsy et al. Supporting automated vulnerability analysis using formalized vulnerability signatures
US7934087B2 (en) Techniques for secure event recording and processing
Bhargavan et al. Verified reference implementations of WS-Security protocols
Santos et al. An empirical study of tactical vulnerabilities
Jürjens Model-based security engineering with UML
Rocha et al. Towards static flow-based declassification for legacy and untrusted programs
Gegick et al. On the design of more secure software-intensive systems by use of attack patterns
Backes et al. A calculus of challenges and responses
Bhargavan et al. Verifying policy-based web services security
Xu et al. Practical dynamic taint analysis for countering input validation attacks on web applications
Rahaman et al. From theory to code: identifying logical flaws in cryptographic implementations in C/C++
Rodrigues et al. Engineering secure web services
Thakkar Heartbleed: A formal methods perspective
Anantharaman Protecting Systems from Exploits Using Language-Theoretic Security
Jaamour Securing web services

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid