KR20210012962A

KR20210012962A - I2nsf nsf 모니터링 양 데이터 모델

Info

Publication number: KR20210012962A
Application number: KR1020200092121A
Authority: KR
Inventors: 정재훈
Original assignee: 성균관대학교산학협력단
Priority date: 2019-07-24
Filing date: 2020-07-24
Publication date: 2021-02-03
Also published as: US11388197B2; US20210029167A1

Abstract

본 명세서는 I2NSF(Interface to Network Security Functions) 프레임워크에서 네트워크 보안 기능(Network Security Functions, NSF) 모니터링을 위한 정보 모델과 데이터 모델을 예시한다.

Description

I2NSF NSF 모니터링 양 데이터 모델{I2NSF NSF MONITORING YANG DATA MODEL}

본 명세서는 데이터 모델에 관한 것으로서, 보다 상세하게 I2NSF(Interface to Network Security Functions) 프레임워크에서 네트워크 보안 기능(Network Security Functions, NSF) 모니터링을 위한 정보 모델과 이에 상응하는 양(YANG) 데이터 모델을 정의하기 위한 것이다.

네트워크를 전세계에 연결하면 지리적 거리에 관계없이 신속하게 정보에 액세스할 수 있다. 인터넷은 본질적으로 서로 다른 레벨들의 계층 구조가 서로 연결된 수많은 네트워크이다.

인터넷은 IETF (Internet Engineering Task Force)에서 공표 한 TCP / IP (전송 제어 프로토콜/인터넷 프로토콜)에 따라 운영되며, TCP/IP는 RFC (Request For Comments) 703 및 IETF에서 발행 한 RFC 791에서 찾을 수 있다.

본 명세서의 목적은, I2NSF 보안 관리 시스템에서 네트워크 보안 기능(NSF) 모니터링을 위한 정보 모델과 이에 상응하는 양(YANG) 데이터 모델을 구현하기 위한 것이다.

본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 명세서의 일 양상은, 보안 관리 시스템에서 보안 컨트롤러가 모니터링하기 위한 방법에 있어서, I2NSF(Interface to Network Security Functions) 사용자로부터 소비자 직면(Consumer-Facing) 인터페이스를 통해, 상위 레벨(High-Level)의 제1 보안 정책을 수신하며, 상기 제1 보안 정책은 상기 보안 관리 시스템에서 발생하는 특정 이벤트에서 트리거되는 정책을 포함함; 상기 제1 보안 정책을 하위 레벨(Low-Level)의 제2 보안 정책으로 번역하는 단계; 상기 제2 보안 정책을 NSF(Network Security Function)에게 설정하기 위한 상기 제2 보안 정책을 포함하는 패킷을 상기 NSF로 전송하는 단계; 및 상기 NSF로부터, NSF 직면(NSF-Facing) 인터페이스를 통해, 모니터링 데이터를 수신하는 단계; 를 포함하며, 상기 모니터링 데이터는 1) 상기 모니터링 데이터의 타입정보 및 2) 상기 NSF의 정보를 포함할 수 있다.

또한, 상기 타입정보는 알람, 경보, 이벤트, 로그 또는 카운터를 지시할 수 있다.

또한, 상기 모니터링 데이터는 상기 타입정보가 알람을 지시하는 경우, 상기 보안 관리 시스템의 컴포넌트(component)와 관련된 알람정보를 더 포함하며, 상기 컴포넌트는 메모리, CPU, 디스크, 하드웨어 및 인터페이스를 포함할 수 있다.

또한, 상기 모니터링 데이터는 상기 타입정보가 이벤트를 지시하는 경우, 상기 보안 관리 시스템과 관련된 이벤트 정보 또는 상기 NSF에서 감지되는 이벤트 정보를 더 포함할 수 있다.

또한, 상기 모니터링 데이터는 상기 타입정보가 로그를 지시하는 경우, 상기 보안 관리 시스템과 관련된 로그 정보 또는 상기 NSF의 로그 정보를 더 포함할 수 있다.

또한, 상기 모니터링 데이터는 상기 타입정보가 카운터를 지시하는 경우, 상기 보안 관리 시스템과 관련된 카운터 정보 또는 상기 NSF와 관련된 카운터 정보를 더 포함할 수 있다.

또한, 상기 NSF에서 감지되는 이벤트 정보는 상기 제1 보안 정책에 근거하여, 생성될 수 있다.

또한, 상기 I2NSF 사용자로 상기 모니터링 데이터를 전송하는 단계;를 더 포함할 수 있다.

또한, 개발자 관리 시스템(Developer's Management System)으로 상기 모니터링 데이터를 전송하는 단계; 를 더 포함할 수 있다.

본 명세서의 또 다른 일 양상은, 보안 관리 시스템에서 모니터링을 위한 보안 컨트롤러에 있어서, 송수신기; 상기 송수신기를 기능적으로 제어하는 프로세서;를 포함하며, 상기 프로세서는 I2NSF(Interface to Network Security Functions) 사용자로부터 소비자 직면(Consumer-Facing) 인터페이스를 통해, 상위 레벨(High-Level)의 제1 보안 정책을 수신하며, 상기 제1 보안 정책은 상기 보안 관리 시스템에서 발생하는 특정 이벤트에서 트리거되는 정책을 포함하고, 상기 제1 보안 정책을 하위 레벨(Low-Level)의 제2 보안 정책으로 번역하며, 상기 제2 보안 정책을 NSF(Network Security Function)에게 설정하기 위한 상기 제2 보안 정책을 포함하는 패킷을 상기 NSF로 전송하고,

상기 NSF로부터, NSF 직면(NSF-Facing) 인터페이스를 통해, 모니터링 데이터를 수신하며, 상기 모니터링 데이터는 1) 상기 모니터링 데이터의 타입정보 및 2) 상기 NSF의 정보를 포함할 수 있다.

본 명세서를 통해, I2NSF 보안 관리 시스템에서 네트워크 보안 기능(NSF) 모니터링을 위한 정보 모델과 이에 상응하는 양(YANG) 데이터 모델을 구현할 수 있다.

본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

도 1은 본 명세서의 일 실시 예에 따른 I2NSF(Interface to Network Security Functions) 시스템을 예시한다.
도 2는 본 명세서의 일 실시예에 따른 I2NSF 시스템의 아키텍처를 예시한다.
도 3은 본 명세서가 적용될 수 있는 전체 I2NSF 정보 모델 디자인의 일 예를 나타낸다.
도 4a 내지 도 4h는 본 명세서가 적용될 수 있는 NSF 모니터링 정보 모델의 예시이다.
도 5a 내지 도 6i는 본 명세서가 적용될 수 있는 모니터링 데이터 모델의 예시이다.
도 7은 본 명세서가 적용될 수 있는 일 실시예이다.
본 명세서에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 명세서에 대한 실시 예를 제공하고, 상세한 설명과 함께 본 명세서의 기술적 특징을 설명한다.

이하, 본 명세서에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 명세서의 예시적인 실시형태를 설명하고자 하는 것이며, 본 명세서가 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 명세서의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 명세서가 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 명세서의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심능력을 중심으로 한 블록도 형식으로 도시될 수 있다.

이하의 설명에서 사용되는 특정 용어들은 본 명세서의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 명세서의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.

최근에는, NFV-based security function을 위한 기본 표준 인터페이스가 I2NSF(Interface to Network Security Functions) 워킹 그룹에 의해 개발되고 있다. 이는 인터넷 엔지니어링 태스크 포스(IETF: Internet Engineering Task Force)로 불리는 국제 인터넷 표준 기구의 일부이다.

I2NSF의 목적은 다수의 보안 솔루션 벤더(security solution vendor)들에 의해 제공되는 이종의(heterogeneous) 네트워크 보안 능력(들)(NSF: network security function)을 위한 표준화된 인터페이스를 정의하기 위함이다.

I2NSF 아키텍처(architecture)에서, NSF(들)의 관리에 대하여 상세히 고려할 필요 없이(NSF의 관리는 결국 보안 정책의 시행(enforce)을 요구한다), 사용자는 사용자의 네트워크 시스템 내 네트워크 자원을 보호하기 위한 보호 정책을 정의할 수 있다. 또한, 다수의 vendor들로부터 NSF(들)로의 표준화된 인터페이스는 이종의 NSF(들)에 대한 태스크(task)의 설정 및 관리를 단순화할 수 있다.

도 1은 본 명세서의 일 실시 예에 따른 I2NSF(Interface to Network Security Functions) 시스템을 예시한다.

도 1을 참조하면, I2NSF 시스템은 I2NSF 사용자(User), 네트워크 운영 관리 시스템(Network Operator Management System), 개발자 관리 시스템(Developer's Management System) 및/또는 적어도 하나의 NSF을 포함한다.

I2NSF 사용자는 I2NSF 소비자-직면 인터페이스(I2NSF Consumer-Facing Interface)를 통해 네트워크 운영 관리 시스템과 통신한다. 네트워크 운영 관리 시스템은 I2NSF NSF-직면 인터페이스(I2NSF NSF-Facing Interface)를 통해 NSF(들)과 통신한다. 개발자 관리 시스템은 I2NSF 등록 인터페이스(I2NSF Registration Interface)를 통해 네트워크 운영 관리 시스템과 통신한다. 이하에서는 I2NSF 시스템의 각 컴포넌트(I2NSF 컴포넌트) 및 각 인터페이스(I2NSF 인터페이스)에 설명한다.

I2NSF 사용자

I2NSF 사용자는 다른 I2NSF 컴포넌트(예컨대, 네트워크 운영 관리 시스템)에서 정보를 요청하거나 및/또는 다른 I2NSF 컴포넌트(예컨대, 개발자 관리 시스템)에 의해 제공되는 서비스(예컨대, 네트워크 보안 서비스)를 사용하는 I2NSF 컴포넌트이다. 예를 들면, I2NSF 사용자는 오버레이 네트워크 관리 시스템, 기업 네트워크 관리자 시스템, 다른 네트워크 도메인 관리자 등일 수 있다.

이러한 I2NSF 사용자 컴포넌트에 할당된 역할을 수행하는 대상은 I2NSF 소비자로 지칭될 수 있다. I2NSF 소비자의 예로는, 일정 기간(time span) 동안 패킷의 특정 필드에 기초하여 흐름을 허용, 속도-제한(rate-limit), 또는 거부하기 위해 언더레이 네트워크(underlay network)에 동적으로 알릴 필요가 있는 화상 회의 네트워크 관리자(video-conference network manager), 특정 흐름에 대한 특정 I2NSF 정책을 시행(enforce)하기 위해 제공자 네트워크를 요청할 필요가 있는 기업 네트워크 관리자(Enterprise network administrators) 및 관리 시스템(management systems), 특정 조건의 세트와 일치하는 흐름을 차단하기 위해 언더레이 네트워크에 요청을 전송하는 IoT 관리 시스템(IoT management system)가 포함될 수 있다.

I2NSF 사용자는 상위 레벨(high-level) 보안 정책(security policy)을 생성 및 배포할 수 있다. 구체적으로 설명하면, I2NSF 사용자는 다양한 악의적인(malicious) 공격으로부터 network 트래픽(traffic)을 보호하기 위하여 네트워크 보안 서비스(network security service)를 이용할 필요가 있다. 이 보안 서비스를 요청하기 위하여, I2NSF 사용자는 자신이 원하는 보안 서비스에 대한 상위 레벨 보안 정책을 생성하고 네트워크 운영 관리 시스템에게 이를 알릴 수 있다.

한편, 상위 레벨 보안 정책을 준비하는 과정에서, I2NSF 사용자는 각 NSF(들)를 위한 보안 서비스 또는 보안 정책 규칙 구성(security policy rule configuration)을 실현하기 위하여 요구되는 NSF(들)의 타입에 대하여 고려하지 않을 수 있다.

또한, I2NSF 사용자는 네트워크 운영 관리 시스템에 의해 기본적인(underlying) NSF(들) 내에서 발생되는 보안 이벤트(들)(security event)를 통지 받을 수 있다. 이들의 보안 이벤트(들)을 분석함으로써, I2NSF 사용자는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 상위 레벨 보안 정책을 업데이트(또는 생성)할 수 있다. 이와 같이, I2NSF 사용자는 보안 정책을 정의, 관리 및 모니터링할 수 있다.

네트워크 운영 관리 시스템

네트워크 운영 관리 시스템은 보안 제공, 모니터링 및 기타 동작을 위한 수집(collection) 및 배포(distribution) 지점(point)의 역할을 수행하는 컴포넌트이다. 예를 들면, 네트워크 운영 관리 시스템은 보안 제어기(Security Controller)일 수 있다. 이러한 네트워크 운영 관리 시스템은 네트워크 보안 관리자에 의해 관리될 수 있고, I2NSF 관리 시스템으로 지칭될 수도 있다.

네트워크 운영 관리 시스템(또는 보안 제어기)의 주요한 역할 중 하나는 I2NSF 사용자로부터의 상위 레벨 보안 정책(또는 정책 규칙)을 특정 NSF(들)을 위한 하위 레벨(low-level) 보안 정책 규칙으로 번역(translate)하는 것이다. 네트워크 운영 관리 시스템(또는 보안 제어기)은 상위 레벨 보안 정책을 I2NSF 사용자로부터 수신한 후, 우선 I2NSF 사용자에 의해 요구되는 정책을 시행하기 위하여 요구되는 NSF(들)의 타입을 결정할 수 있다. 그리고, 네트워크 운영 관리 시스템(또는 보안 제어기)은 요구되는 각 NSF(들)을 위한 하위 레벨(low-level) 보안 정책을 생성할 수 있다. 결국, 네트워크 운영 관리 시스템(또는 보안 제어기)은 생성된 하위 레벨 보안 정책을 각 NSF(들)에게 설정할 수 있다.

또한, 네트워크 운영 관리 시스템(또는 보안 제어기)은 시스템 내 구동 중인 NSF(들)을 모니터링하고, 각 NSF(들)에 대한 다양한 정보(예를 들어, 네트워크 액세스(access) 정보 및 작업로드(workload) 상태 등)를 유지할 수 있다. 또한, 네트워크 운영 관리 시스템(또는 보안 제어기)은 개발자 관리 시스템의 도움을 받아 NSF 인스턴스의 동적인 수명시간(life-cycle) 관리를 통해 NSF 인스턴스(instance)의 풀(pool)을 동적으로 관리할 수 있다.

NSF

NSF는 보안 관련 서비스를 제공하는 논리적 엔티티(logical entity) 또는 소프트웨어 컴포넌트이다. 예를 들면, NSF는 하위 레벨 보안정책을 수신하고, 이에 기초하여 악의적인 네트워크 트래픽을 감지하고, 이를 차단하거나 완화할 수 있다. 이를 통해, 네트워크 통신 스트림의 무결성(integrity) 및 기밀성(confidentiality)이 보장될 수 있다.

개발자 관리 시스템

개발자 관리 시스템은 다른 I2NSF 컴포넌트(예컨대, I2NSF 사용자, 네트워크 운영 관리 시스템)으로 정보를 보내거나, 및/또는 서비스(예컨대, 네트워크 보안 서비스)를 제공하는 I2NSF 컴포넌트이다. 개발자 관리 시스템은 벤더 관리 시스템(Vendor's Management System)으로 지칭될 수도 있다. 이러한 개발자 관리 시스템에 할당된 역할을 수행하는 대상은 I2NSF 생산자(producer)로 지칭될 수 있다.

개발자 관리 시스템은 네트워크 운영 관리 시스템에게 NSF(들)을 제공하는 제3자(third-party) 보안 벤더에 의해 관리될 수 있다. 다양한 보안 벤더의 다수의 개발자 관리 시스템(들)이 존재할 수 있다.

I2NSF 소비자-직면 인터페이스(간단히, 소비자-직면 인터페이스(CFI))

CFI는 I2NSF 사용자와 네트워크 운영 관리 시스템 사이에 위치하는, 사용자의 I2NSF 시스템으로의 인터페이스이다. 이렇게 설계됨으로써, 하위(underlying) NSF(들)의 상세한 내용을 숨기고, 사용자에게 NSF(들)의 추상적인 시각(abstract view)만을 제공한다.

이 CFI는 주어진 I2NSF 시스템의 상이한 사용자가 관리 도메인 내의 특정 흐름(flow)에 대한 보안 정책을 정의, 관리 및 모니터링할 수 있게 하기 위해 사용될 수 있다. I2NSF 사용자에 의해 생성된 상위 레벨 보안 정책(또는 정책 규칙)은 이 CFI를 통해 네트워크 운영 관리 시스템으로 전달될 수 있다.

I2NSF NSF-직면 인터페이스(간단히, NSF-직면 인터페이스(NFI))

NFI는 네트워크 운영 관리 시스템(또는 보안 제어기)과 NSF(들) 사이에 위치하는 인터페이스이다.

NFI는 하나 이상의 NSF에 의해 시행되는 흐름-기반(flow-based) 보안 정책을 지정하고 모니터링하기 위해 사용될 수 있다. 예를 들면, I2NSF 시스템은 흐름-기반 NSF를 사용할 수 있다. 여기서, 흐름-기반 NSF는 보안 특성을 강화하기 위해 정책의 세트에 따라 네트워크 흐름을 검사하는 NSF이다. 이러한 흐름-기반 NSF에 의한 흐름-기반 보안은 수신된 순서대로 패킷들이 검사되고, 검사 프로세스에 따라 패킷에 대한 수정이 없는 것을 의미한다. 흐름-기반 NSF에 대한 인터페이스는 다음과 같이 분류될 수 있다:

- NSF 운영 및 관리 인터페이스(NSF Operational and Administrative Interface): NSF의 운영 상태를 프로그래밍하기 위해 I2NSF 관리 시스템에 의해 사용되는 인터페이스 그룹; 이 인터페이스 그룹은 또한 관리 제어 능력을 포함한다. I2NSF 정책 규칙은 일관된 방식으로 이 인터페이스 그룹을 변경하는 한가지 방법을 나타낸다. 어플리케이션 및 I2NSF 컴포넌트가 그들이 송신 및 수신하는 트래픽의 동작을 동적으로 제어할 필요가 있기 때문에, I2NSF 노력(effort)의 대부분이 이 인터페이스 그룹에 집중된다.

- 모니터링 인터페이스(Monitoring Interface): 하나 이상의 선택된 NSF로부터의 모니터링 정보를 획득하기 위해 I2NSF 관리 시스템에 의해 사용되는 인터페이스 그룹; 이 인터페이스 그룹의 각 인터페이스는 쿼리 또는 리포트 기반 인터페이스일 수 있다. 둘 사이의 차이점은 쿼리 기반 인터페이스는 정보를 획득하기 위해 I2NSF 관리 시스템에 의해 사용되고, 이에 반하여 리포트 기반 인터페이스는 정보를 제공하기 위해 NSF에 의해 사용된다는 것이다. 이 인터페이스 그룹의 능력은 또한 SYSLOG[RFC5424] 및 DOTS(DDoS Open Threat Signaling)[RFC8612]와 같은 다른 프로토콜에 의해 정의될 수 있다. I2NSF 관리 시스템은 정보의 수신에 기초하여 하나 이상의 동작(action)을 취할 수 있다. 이는 I2NSF 정책 규칙에 의해 지정되어야 한다. 이 인터페이스 그룹은 NSF의 운영 상태를 변경하지 않는다.

이와 같이, NFI는 흐름-기반 패러다임을 사용하여 개발될 수 있다. 흐름-기반 NSF의 공동 특성(common trait)은 수신된 패킷의 콘텐츠(예컨대, 헤더/페이로드) 및/또는 컨텍스트(예컨대, 세션 상태 및 인증 상태)에 기초하여 패킷을 처리하는 것이다. 이 특징은 I2NSF 시스템의 동작을 정의하기 위한 요구사항(requirement) 중 하나이다.

한편, I2NSF 관리 시스템은 주어진 NSF의 모든 능력들을 사용할 필요가 없으며, 모든 사용 가능한 NSF들을 사용할 필요도 없다. 따라서, 이 추상화(abstraction)는 NSF 특징(feature)을 NSF 시스템에 의해 빌딩 블록(building block)으로 취급될 수 있게 해준다. 그러므로, 개발자는 벤더 및 기술에 독립적인 NSF에 의해 정의되는 보안 능력을 자유롭게 사용할 수 있게 된다.

I2NSF 등록 인터페이스(간단히, 등록 인터페이스(RI))

RI는 네트워크 운영 관리 시스템 및 개발자 관리 시스템 사이에 위치하는 인터페이스이다. 상이한 벤더에 의해 제공되는 NSF는 상이한 능력(capability)을 가질 수 있다. 따라서, 상이한 벤더에 의해 제공되는 여러 유형의 보안 능력을 이용하는 프로세스를 자동화하기 위해, 벤더가 그들의 NSF의 능력을 정의하기 위한 전용 인터페이스를 가질 필요가 있다. 이러한 전용 인터페이스는 I2NSF 등록 인터페이스(RI)로 지칭될 수 있다.

NSF의 능력은 미리 구성되거나 또는 I2NSF 등록 인터페이스를 통해 동적으로 검색될 수 있다. 만일 소비자에게 노출되는 새로운 능력이 NSF에 추가된다면, 관심 있는(interested) 관리 및 제어 엔티티가 그것들을 알 수 있도록, 그 새로운 능력의 capability가 I2NSF 등록 인터페이스를 통해 I2NSF 레지스트리(registry)에 등록될 필요가 있다.

도 2는 본 명세서의 일 실시예에 따른 I2NSF 시스템의 아키텍처를 예시한다. 도 2의 I2NSF 시스템은 도 1의 I2NSF 시스템에 비하여 I2NSF 사용자 및 네트워크 운영 관리 시스템의 구성을 더 구체적으로 나타낸다. 도 2에서는 도 1에서 상술한 설명과 중복된 설명은 생략한다.

도 2를 참조하면, I2NSF 시스템은 I2NSF 사용자, 보안 관리 시스템(Security Management System), 및 NSF 인스턴스(instances) 계층을 포함한다. I2NSF 사용자 계층은 어플리케이션 로직(Application Logic), 정책 업데이터(Policy Updater), 및 이벤트 수집기(Event Collector)을 컴포넌트로서 포함한다. 보안 관리 시스템 계층은 보안 제어기 및 개발자 관리 시스템을 포함한다. 보안 관리 시스템 계층의 보안 제어기는 보안 정책 관리자(Security policy manager) 및 NSF 능력 관리자(NSF capability manager)를 컴포넌트로서 포함한다.

I2NSF 사용자 계층은 소비자-직면 인터페이스를 통해 보안 관리 시스템 계층과 통신한다. 예를 들면, I2NSF 사용자 계층의 정책 업데이터 및 이벤트 수집기는 소비자-직면 인터페이스를 통해 보안 관리 시스템 계층의 보안 제어기와 통신한다. 또한, 보안 관리 시스템 계층은 NSF-직면 인터페이스를 통해 NSF 인스턴스 계층과 통신한다. 예를 들면, 보안 관리 시스템 계층의 보안 제어기는 NSF-직면 인터페이스를 통해 NSF 인스턴스 계층의 NSF 인스턴스(들)과 통신한다. 또한, 보안 관리 시스템 계층의 개발자 관리 시스템은 등록 인터페이스를 통해 보안 관리 시스템 계층의 보안 제어기와 통신한다.

도 2의 I2NSF 사용자 계층, 보안 관리 시스템 계층의 보안 제어기 컴포넌트, 보안 관리 시스템 계층의 개발자 관리 시스템 컴포넌트 및 NSF 인스턴스 계층은 각각 도 1의 I2NSF 사용자 컴포넌트, 네트워크 운영 관리 시스템 컴포넌트, 개발자 관리 시스템 컴포넌트 및 NSF 컴포넌트에 대응된다. 또한, 도 2의 소비자-직면 인터페이스, NSF-직면 인터페이스 및 등록 인터페이스는 도 1의 소비자-직면 인터페이스, NSF-직면 인터페이스 및 등록 인터페이스에 대응된다. 이하에서는, 각 계층에 포함된 새로 정의된 컴포넌트들에 대하여 설명한다.

I2NSF 사용자

상술한 것처럼, I2NSF 사용자 계층은 다음 3 개의 컴포넌트를 포함한다: 어플리케이션 로직(Application Logic), 정책 업데이터(Policy Updater), 및 이벤트 수집기(Event Collector). 각각의 역할 및 동작을 설명하면 다음과 같다.

어플리케이션 로직은 상위 레벨 보안 정책을 생성하는 컴포넌트이다. 이를 위해, 어플리케이션 로직은 이벤트 수집기로부터 상위 레벨 정책을 업데이트(또는 생성)하기 위한 이벤트를 수신하고, 수집된 이벤트에 기초하여 상위 레벨 정책을 업데이트(또는 생성)한다. 그 이후에, 상위 레벨 정책은 보안 제어기로 배포하기 위해 정책 업데이터로 보내진다. 상위 레벨 정책을 업데이트(또는 생성)하기 위해, 이벤트 수집기는 보안 수집기에 의해 보내진 이벤트를 수신하고, 그들을 어플리케이션 로직으로 보낸다. 이 피드백에 기초하여, 어플리케이션 로직은 상위 레벨 보안 정책을 업데이트(또는 생성)할 수 있다.

도 2에서는, 어플리케이션 로직, 정책 업데이터 및 이벤트 수집기를 각각 별도의 구성으로 도시하고 있으나, 본 명세서의 이에 한정되지 않는다. 다시 말해, 각각은 논리적인 컴포넌트로서, I2NSF 시스템에서 하나 또는 2 개의 컴포넌트로 구현될 수도 있다.

보안 관리 시스템

상술한 것처럼, 보안 관리 시스템 계층의 보안 제어기는 보안 정책 관리자(Security policy manager) 및 NSF 능력 관리자(NSF capability manager)와 같은 2개의 컴포넌트를 포함한다

보안 정책 관리자는 CFI를 통해 정책 업데이터로부터 상위 레벨 정책을 수신하고, 이 정책을 여러 하위 레벨 정책으로 매핑할 수 있다. 이 하위 레벨 정책은 NSF 능력 관리자에 등록된 주어진 NSF 능력과 관련된다. 또한, 보안 정책 관리자는 이 정책을 NFI를 통해 NSF(들)로 전달할 수 있다.

NSF 능력 관리자는 주어진 NSF 능력과 관련된 하위 레벨 정책을 생성하기 위해, 개발자 관리 시스템에 의해 등록된 NSF의 능력을 지정하고, 그것을 보안 정책 관리자와 공유할 수 있다. 새로운 NSF가 등록될 때마다, NSF 능력 관리자는 등록 인터페이스를 통해 NSF 능력 관리자의 관리 테이블에 NSF의 능력을 등록하도록 개발자 관리 시스템에 요청할 수 있다. 개발자 관리 시스템은 새로운 NSF의 능력을 NSF 능력 관리자로 등록하기 위한 보안 관리 시스템의 다른 부분에 해당한다.

도 2에서는, 보안 정책 관리자 및 NSF 능력 관리자를 각각 별도의 구성으로 도시하고 있으나, 본 명세서의 이에 한정되지 않는다. 다시 말해, 각각은 논리적인 컴포넌트로서, I2NSF 시스템에서 하나의 컴포넌트로 구현될 수도 있다.

NSF 인스턴스(NSF Instances)

도 2에 도시된 것처럼, NSF 인스턴스 계층은 NSF들을 포함한다. 이때, 모든 NSF들은 이 NSF 인스턴스 계층에 위치된다. 한편, 상위 레벨 정책을 하위 레벨 정책에 매핑한 후에, 보안 정책 관리자는 NFI를 통해 정책을 NSF(들)로 전달한다. 이 경우, NSF는 수신된 하위 레벨 보안 정책에 기초하여 악의적인 네트워크 트래픽을 감지하고, 이를 차단하거나 완화할 수 있다.

가상화 시스템의 신속한 개발을 위해서는 다양한 시나리오에서 고급 보안 능력이 필요하다(예를 들면, 엔터프라이즈 네트워크의 네트워크 장치, 모바일 네트워크의 사용자 장비, 인터넷의 장치 또는 거주자 액세스 사용자 등).

여러 보안 업체에서 생산한 NSF는 고객에게 다양한 보안 능력을 제공할 수 있다. 즉, NSF는 물리적 또는 가상 능력으로 구현되었는지 여부와 관계없이 여러 NSF가 함께 결합되어 주어진 네트워크 트래픽에 대한 보안 서비스를 제공 할 수 있다.

보안 능력은 보안 정책 시행 목적으로 사용할 수 있는 일련의 네트워크의 보안과 관련된 능력을 말한다. 보안 능력은 실제 구현되는 보안 제어 메커니즘과는 독립적이며, 모든 NSF는 NSF에서 제공할 수 있는 능력들의 세트가 등록되어 있다.

보안 능력은 특정 NSF가 제공하는 보안 능력을 모호하지 않게 설명함으로써 맞춤형 보안 보호를 정의 할 수 있는 방법을 제공하는 마켓 리더이다. 또한, 보안 능력을 통해 보안 능력의 공급 업체의 중립적인 방식으로 설명 할 수 있다.

즉, 네트워크를 설계할 때 특정 제품을 언급할 필요가 없으며, 능력별로 특징이 고려될 수 있다.

앞에서 살펴본 바와 같이 보안 정책 제공에 사용될 수 있는 I2NSF 인터페이스는 아래와 같이 두 가지 유형이 존재할 수 있다.

- I2NSF 사용자와 응용 프로그램 간의 인터페이스 및 보안 컨트롤러 (Consumer-Facing Interface): NSF 데이터 및 서비스 사용자와 네트워크 운영 관리시스템(또는 보안 제어기) 사이에 통신 채널을 제공하는 서비스 지향 인터페이스.

I2NSF Consumer-Facing Interface는 보안 정보가 다양한 애플리케이션(예를 들면: OpenStack 또는 다양한 BSS(Business Support System) / OSS(Operations Support System) 구성 요소)과 보안 컨트롤러간의 교환에 사용될 수 있다. Consumer-Facing Interface의 설계 목표는 보안 서비스의 스펙을 구현과 분리하는데 있다.

- NSF 간의 인터페이스(예를 들면: 방화벽, 침입 방지 또는 안티 바이러스) 및 보안 컨트롤러 (NSF-Facing Interface): NSF-Facing Interface는 보안 관리 체계를 NSF 집합과 여러 가지 구현에서 분리하는 데 사용되며 NSF가 구현되는 방식(예를 들면: 가상 머신 또는 실제 appliances 등)에서 독립적이다.

이하, 연관된 I2NSF 정책 객체와 함께 네트워크 보안, 콘텐츠 보안 및 공격 완화 능력에 대한 객체 지향 정보 모델에 대해 살펴보도록 한다.

본 명세서에서 정보 모델에 사용되는 용어는 다음과 같이 정의될 수 있다

AAA: Access control, Authorization, Authentication

ACL: Access Control List

(D)DoS: (Distributed) Denial-of-Service (attack)

ECA: Event-Condition-Action

FMR: First Matching Rule (resolution strategy)

FW: Firewall

GNSF: Generic Network Security Function

HTTP: HyperText Transfer Protocol

I2NSF: Interface to Network Security Functions

IPS: Intrusion Prevention System

LMR: Last Matching Rule (resolution strategy)

MIME: Multipurpose Internet Mail Extensions

NAT: Network Address Translation

NSF: Network Security Function

RPC: Remote Procedure Call

SMA: String Matching Algorithm

URL: Uniform Resource Locator

VPN: Virtual Private Network

정보 모델 설계

능력 정보 모델(Capability Information Model)의 설계의 출발점은 보안 능력의 유형을 분류하는 것이다. 예를 들어, "IPS", "안티 바이러스" 및 "VPN 집중 장치"와 같은 보안 능력의 유형을 분류하는 것이다.

또는, "패킷 필터"는 다양한 조건(예를 들면: 발신 및 수신 IP 주소, 발신 및 수신 포트 및 IP 프로토콜 유형 필드 등)에 따라 패킷 전달을 허용하거나 거부 할 수 있는 저장 장치로 분류될 수 있다.

그러나, 상태 기반 방화벽이나 응용 프로그램 계층 필터와 같은 다른 장치의 경우 더 많은 정보가 필요하다. 이러한 장치는 패킷이나 통신을 필터링하지만 패킷과 통신들을 카테고리화하고 유지하는 상태에서 차이가 있다.

아날로그적 고려사항은 채널 보호 프로토콜들에서 고려될 수 있다. 여기서 채널 보호 프로토콜들은 비대칭 암호로 협상될 수 있는 대칭 알고리즘을 통해 패킷을 보호할 수 있으며, 서로 다른 계층에서 작동하고 서로 다른 알고리즘과 프로토콜을 지원할 수 있다.

안전한 보호를 위해 이러한 프로토콜은 무결성, 선택적으로 기밀성, anti-reply 보호 및 피어 인증이 적용되어야 한다.

능력 정보 모델 오버뷰(Capability Information Model Overview)

능력 정보 모델은 NSF의 자동 관리를 위한 토대를 제공하는 보안 능력 모델을 정의한다. 능력 정보 모델은 보안 컨트롤러가 NSF를 적절하게 식별 및 관리 할 수 있도록 하고, NSF가 능력들을 올바른 방법으로 사용할 수 있도록 적절하게 선언하는 것을 허용하는 것도 포함한다.

보안을 위한 몇 가지 기본 설계 원칙 및 이를 관리해야 하는 시스템은 다음과 같다.

- 독립성(Independence): 각 보안 능력은 다른 능력에 최소한의 중첩 또는 종속성을 갖는 독립적 인 능력이어야 한다. 이를 통해 각 보안 능력을 자유롭게 사용 및 조합 할 수 있다. 더 중요한 것은, 하나의 능력으로의 변경이 다른 능력에 영향을 미치지 않는다는 것이다.

이것은 Single Responsibility Principle [Martin] [OODSRP]을 따른다.

- 추상성(Abstraction): 각 능력은 벤더 독립적인 방식으로 정의되어야 하며 잘 알려진 인터페이스와 연결되어 처리 결과를 기술하고 보고할 수 있는 표준화 된 능력을 제공해야 한다. 따라서, 다중 공급 벤더와의 상호 운용성이 향상될 수 있다.

- 자동화(Automation): 시스템은 보안 능력(즉, 사용자 개입없이)을 자동 검색, 자동 협상 및 자동 업데이트 할 수 있어야 한다. 이러한 자동화 능력은 다수의 NSF를 관리하는 데 특히 유용하다.

채택 된 보안 체계에 대한 스마트 서비스(예를 들면: 분석, 정제, 능력 추론 및 최적화)를 추가하는 것은 필수적이다. 이러한 능력은 Observer Pattern [OODOP], Mediator Pattern [OODMP] 및 Message Exchange Patterns [Hohpe]와 같은 많은 디자인 패턴에서 지원된다.

- 확장성: 관리 시스템에는 scale up/down 또는 scale in/out 능력이 있어야 한다. 따라서, 이러한 확장성으로 인하여 변경 가능한 네트워크 트래픽 또는 서비스 요청에서 파생된 다양한 성능 요구 사항을 충족 할 수 있다. 또한, 확장성의 영향을 받는 보안 능력은 보안 컨트롤러에 보고통계를 지원해야 스케일링을 호출해야 하는지 여부를 결정하는 데 도움이 될 수 있다.

위의 원칙에 따라 표준 인터페이스를 갖춘 추상 및 벤더 중립 능력 집합이 정의될 수 있다. 이것은 주어진 시간에 필요한 NSF 세트를 사용할 수 있게 해주는 Capability 모델과 사용된 NSF 세트에 의해 제공되는 보안의 모호하지 않도록 정의를 제공한다.

보안 컨트롤러는 사용자 및 응용 프로그램의 요구 사항을 현재 사용할 수 있는 능력 집합과 비교하여 해당 요구 사항을 충족하는데 필요한 NSF를 선택한다.

또한, NSF에 의해 알려지지 않은 위협(예를 들어, zero-day exploits 및 unknown malware)이 보고 될 때, 새로운 능력이 생성될 수 있고 및/또는 기존의 능력이 업데이트 될 수 있다(예를 들어, 그의 서명 및 알고리즘을 업데이트함으로써). 그 결과 새로운 위협에 대처하기 위해 기존의 NSF를 강화(및/또는 새로운 NSF를 생성)하게 된다.

새로운 능력은 중앙 리포지토리(Repository)에 전송되어 저장되거나 벤더의 로컬 리포지토리에 개별적으로 저장 될 수 있다. 두 경우 모두 표준 인터페이스가 업데이트 프로세스가 용이하게 수행되도록 한다.

ECA 정책 모델 오버뷰(ECA Policy Model Overview)

"Event-Condition-Action"(ECA) 정책 모델은 I2NSF 정책 규칙의 설계를 위한 기초로 사용된다. 이때, I2NSF 정책과 관련된 용어는 아래와 같이 정의될 수 있다([I-D.draft-ietf-i2nsf-terminology] 참조):

- 이벤트: 이벤트는 관리되는 시스템이 변경될 때 및/또는 관리되는 시스템의 환경에서 중요한 시점에 발생한다. 이벤트는 I2NSF 정책 규칙의 컨텍스트에서 사용될 때 I2NSF 정책 규칙의 조건 절을 평가할 수 있는지 여부를 결정하는 데 사용될 수 있다. I2NSF 이벤트의 예로는 시간 및 사용자 동작(예를 들면: 로그온, 로그 오프 및 ACL을 위반하는 동작)이 있을 수 있다.

- 조건(Condition): 조건은 알려진 속성, 특징 및/또는 값의 세트와 비교될 속성, 능력 및/또는 값의 집합으로 정의되어 그(명령형) I2NSF 정책 규칙을 실행하거나 실행하지 않을 수 있다. I2NSF 조건의 예에는 패킷 또는 흐름의 일치하는 속성과 NSF의 내부 상태를 원하는 상태와 비교하는 것이 포함될 수 있다.

- 동작(Action): 동작은 이벤트 및 조건 절이 충족될 때 흐름 기반 NSF의 측면을 제어하고 모니터링하는데 사용된다. NSF는 다양한 액션을 실행하여 보안 능력을 제공한다. I2NSF 작업의 예에는 침입 탐지 및 / 또는 보호, 웹 및 플로우 필터링, 패킷 및 플로우에 대한 심층 패킷 검사 제공이 포함될 수 있다.

I2NSF 정책 규칙은 Event 절, Condition 절 및 Action 절의 세 가지 Boolean 절로 구성된다.

Boolean 절은 TRUE 또는 FALSE로 평가되는 논리문을 의미하며, 하나 이상의 용어로 구성 될 수 있습니다.

두 개 이상의 용어가 있는 경우 Boolean 절은 논리 연결 요소(즉, AND, OR 및 NOT)를 사용하여 용어를 연결한다. 이때, 논리적 연결 요소는 아래의 표 1과 같은 의미를 가질 수 있다.

기술적으로 "정책 규칙"은 실제로 메타 데이터뿐 아니라 앞에서 설명한 “이벤트”, “동작” 및 “조건”을 집계하는 컨테이너 역할을 수행할 수 있다.

앞에서 설명한 ECA 정책 모델은 매우 일반적이며 쉽게 확장 할 수 있으며 일반 보안 능력 구현을 제한 할 수 있는 잠재적 제약을 피할 수 있다.

외부 정보 모델과의 관계

도 3은 본 명세서가 적용될 수 있는 전체 I2NSF 정보 모델 디자인의 일 예를 나타낸다.

I2NSF NSF-Facing Interface는 NSF의 능력을 사용하여 NSF를 선택 및 관리하며, 이는 아래와 같은 접근법을 이용하여 수행된다.

1) 각 NSF는 "참여"할 때 관리 시스템에 능력을 등록하므로 관리 시스템에서 해당 능력을 사용할 수 있다.

2) 보안 컨트롤러는 관리하는 모든 사용 가능한 NSF에서 보안 서비스의 요구 사항을 충족시키는 데 필요한 능력 집합을 선택한다.

3) 보안 컨트롤러는 Capability 정보 모델을 사용하여 선택한 능력을 공급 업체와 독립적인 NSF로 일치시킨다.

4) 보안 컨트롤러는 위의 정보를 가져 와서 능력 정보 모델의 하나 이상의 데이터 모델을 생성 또는 사용하여 NSF를 관리한다.

5) 제어 및 모니터링을 시작할 수 있다.

이러한 접근법은 외부 정보 모델이 ECA 정책 규칙 및 그 구성 요소(예를 들면: 이벤트, 조건 및 조치 객체 등)의 개념을 정의하는 데 사용된다고 가정할 수 있다. 이를 통해 외부 정보 모델로부터 I2NSF 정책 규칙을 하위 클래스로 분류 할 수 있다(I-D.draft-ietf-i2nsf-terminology 참조).

본 명세서에서 데이터 모델은 데이터의 저장소, 데이터 정의 언어, 쿼리 언어, 구현 언어 및 프로토콜에 의존하는 형식으로 환경에 대한 관심의 컨셉을 나타낸 것이다.

또한, 정보 모델은 데이터 저장소, 데이터 정의 언어, 쿼리 언어, 구현 언어 및 프로토콜과 독립적인 형태로 환경에 대한 관심 컨셉을 나타낸 것이다.

능력은 클래스(예를 들면: 공통된 특성 및 행동 집합을 나타내는 객체의 집합)로 정의될 수 있다(I-D.draft-ietf-supa-generic-policy-info-model 참조).

각 능력은 시스템의 다른 모든 객체와 구별되는 하나 이상의 모델 요소(예를 들면: 속성, 메소드 또는 관계)로 구성될 수 있다. 능력은 일반적으로 일종의 메타 데이터(즉, 객체의 행동을 설명 및 / 또는 처방하는 정보)이다.

따라서, 각 능력은 외부 정보 모델이 메타 데이터를 정의하는데 사용될 수 있다(클래스 계층 구조의 형태가 바람직함). 따라서, 능력들은 외부 메타 데이터 모델에서 하위 클래스로 분류될 수 있다.

능력 하위 모델은 NSF가 포함된 장치의 유형 및 공급 업체와 독립적인 특정 보안 능력 세트를 광고, 생성, 선택 및 관리하는데 사용된다.

즉, NSF-Facing Interface의 사용자는 NSF가 가상화 되거나 호스팅되는지, NSF 공급 업체가 누구인지, NSF가 통신하는 엔티티 세트(예를 들면, 방화벽 또는 IPS)를 고려하지 않는다.

대신 사용자는 NSF가 가지고 있는 패킷 필터링이나 딥 패킷 검사와 같은 능력 세트만을 고려한다.

이러한 전체 ISNSF 정보 모델의 설계는 도 3과 같다.

도 3에 도시된 외부 모델은 모두 SUPA 정보 모델을 기반으로 할 수 있다(I-D.draft-ietf-supa-generic-policy-info-model 참조). 능력 하위 모델의 클래스는 외부 메타 데이터 정보 모델에서 메타 데이터 집계(Metadata Aggregate)의 집합을 이어받는다.

도 3에 도시된 외부 ECA 정보 모델은 일반 ECA 정책 규칙을 나타내는 최소한의 클래스 집합과 일반 ECA 정책 규칙에 의해 집계 될 수 있는 이벤트, 조건 및 동작을 나타내는 클래스 집합을 제공한다.

이를 통해, I2NSF는 이러한 일반 모델을 다른 목적으로 재사용 할 수 있을 뿐만 아니라 I2NSF 관련 개념을 표현하기 위해 새로운 하위 클래스를 생성하거나 속성 및 관계를 추가 할 수 있다.

본 명세서에서 외부 ECA 정보 모델은 메타 데이터를 수집하는 능력을 가지고 있다고 가정한다. 능력들은 외부 메타 데이터 정보 모델의 적절한 클래스에서 하위 클래스로 분류될 수 있다.

이는 ECA 개체가 메타 데이터와 기존의 집계를 사용하여 메타 데이터를 적절한 ECA 개체에 추가할 수 있게 한다.

이하 정보 모델의 각 부분에 대해서 살펴보도록 한다.

I2NSF 능력 정보 모델: 운영 이론(I2NSF Capability Information Model: Theory of Operation)

능력은 일반적으로 호출할 수 있는 NSF 함수를 나타내는 데 사용된다. 능력은 객체이므로 I2NSF ECA 정책 규칙의 이벤트, 조건 및/또는 액션을 설명하는 절에서 사용할 수 있다.

I2NSF 능력 정보 모델은 사전 정의된 메타 데이터 모델을 구체화한다. I2NSF 능력의 적용은 능력 집합을 사용, 관리 또는 조작하는 방법을 정의하는 사전 정의된 ECA 정책 규칙 정보 모델을 수정함으로써 수행될 수 있다. 이러한 접근법에서 I2NSF 정책 규칙은 이벤트 절, 조건 절 및 작업 절의 세 가지 절로 구성된 컨테이너 역할을 수행할 수 있다.

I2NSF 정책 엔진이 일련의 이벤트를 수신하면 해당 이벤트를 활성 ECA 정책 규칙의 이벤트와 일치시킨다. 이벤트가 일치하면 일치하는 I2NSF 정책 규칙의 조건절의 평가를 트리거한다. 조건 절이 평가되고, 이것이 일치하는 경우, 일치하는 I2NSF 정책 규칙에 있는 일련의 행동이 실행될 수 있다.

초기 NSFs 능력 카테고리(Initial NSFs Capability Categories)

이하, 네트워크 보안, 콘텐츠 보안 및 공격 완화의 세 가지 일반적인 기능에 대해서 살펴본다. 본 명세서에서 살펴보는 특정 카테고리 내의 카테고리 수와 기능 유형은 모두 확장될 수 있다.

네트워크 보안 능력(Network Security Capabilities)

네트워크 보안은 미리 정의 된 보안 정책을 사용하여 네트워크 트래픽을 검사하고 처리하는 방법을 설명하기 위한 카테고리이다.

검사 부분은 직접적으로 또는 패킷이 연관된 흐름의 맥락에서 네트워크를 통과하는 패킷을 검사하는 패킷 처리 엔진일 수 있다. 패킷 처리의 관점에서 볼 때 구현할 수 있는 패킷 헤더 및/또는 페이로드의 깊이, 유지할 수 있는 다양한 흐름 및 컨텍스트 상태, 패킷 또는 흐름에 적용 할 수 있는 동작이 구현에 따라 달라질 수 있다.

콘텐츠 보안 능력(Content Security Capabilities)

콘텐츠 보안은 응용 프로그램 계층에 적용되는 보안 기능의 또 다른 카테고리이다. 예를 들어, 응용 프로그램 계층에서 전달되는 트래픽 내용을 분석하여 콘텐츠 보안 기능을 사용함으로써 필요한 다양한 보안 기능을 식별 할 수 있다.

여기에는 침입에 대한 방어, 바이러스 검사, 악의적 인 URL 또는 정크 메일 필터링, 불법적 인 웹 액세스 차단 또는 악의적인 데이터 검색 방지가 포함될 수 있다.

일반적으로 콘텐츠 보안의 각 위협 유형에는 고유한 특성 집합이 있으며 해당 유형의 콘텐츠에 고유한 메서드 집합을 사용하여 처리해야 한다. 따라서 이러한 기능은 고유한 콘텐츠 별 보안 기능을 특징으로 한다.

공격 완화 능력(Attack Mitigation Capabilities)

공격 완화 능력은 다양한 유형의 네트워크 공격을 탐지하고 완화하는데 사용된다. 오늘날 일반적인 네트워크 공격은 아래와 같이 정의될 수 있다.

- DDoS 공격:

네트워크 계층 DDoS 공격: SYN flood, UDP flood, ICMP flood, IP fragment flood, IPv6 routing header attack 및 IPv6 duplicate address detection 공격을 예로 들 수 있다.

응용 프로그램 계층 DDoS 공격: 예를 들어 HTTP flood, HTTPS flood, 캐시 우회 HTTP floods, WordPress XML RPC floods 및 SSL DDoS가 있습니다.

- 단일 패킷 공격:

스캐닝 및 스니핑 공격: IP 스윕, 포트 스캐닝 등

잘못된 패킷 공격: Ping of Death, Teardrop 등

특별 패킷 공격: 특대 ICMP, Tracert, IP 타임 스탬프 옵션 패킷 등

각 유형의 네트워크 공격에는 고유한 네트워크 동작 및 패킷/흐름 특성이 있다. 따라서, 각 유형의 공격에는 탐지 및 완화를 위해 능력 집합으로 알리는 특수 보안 기능이 필요하다. 이러한 보안 범주의 구현 및 관리 공격 완화 제어 기능은 콘텐츠 보안 제어 범주와 매우 유사할 수 있다.

본 명세서는 I2NSF(Interface to Network Security Functions) 프레임워크에서 네트워크 보안 기능(NSF) 모니터링을 위한 정보 모델과 이에 상응하는 양(YANG) 데이터 모델을 제안한다. NSF에 대한 모니터링이 종합적으로 수행된다면, 악의적인 활동 또는 변칙적인 행동이나 서비스 거부 공격의 잠재적 징후가 적시에 감지될 수 있다. 이러한 모니터링 기능은 NSF에 의해 생성되는 모니터링 정보에 기초한다. 따라서 본 명세서는 양 데이터 다이어그램과 함께 NSF 모니터링을 위한 정보 모델뿐만 아니라 NSF 모니터링을 위한 해당 양 데이터 모델을 설명한다.

[ID.ietf-i2nsf-terminology]를 참고하면, NSF(Network Security Function) (예 : 방화벽, IPS, Anti-DDoS 또는 안티 바이러스 기능)에서 관리 엔터티 (예 : 보안 컨트롤러)로 제공하는 원격 관리 활성화(즉, 구성 및 모니터링)를 위한 인터페이스를 I2NSF NSF-직면 인터페이스라고 한다[I-D.ietf-i2nsf-nsf-facing-interface-dm].

모니터링 절차는 동작중인 데이터 (예 : 쿼리, 알림 및 이벤트)를 통해 NSF (예 : 알람, 레코드 및 카운터)와 관련하여 중요한 유형의 데이터를 수집한다. NSF의 모니터링이 적시, 포괄적 방식으로 수행되는 경우, 전체 보안 프레임 워크에서 중요한 역할을 수행할 수 있다. NSF에 의해 생성된 모니터링 정보는 서비스 거부 공격 (DoS)과 같은 비정상적인 동작 또는 악의적인 활동을 조기에 잘 나타낼 수 있다.

본 명세서는 보안 컨트롤러를 위한 NSF에 대하여, 가시성을 제공하는 포괄적 인 NSF 모니터링 정보 모델을 정의한다. 또한, NSF-직면 인터페이스를 통해 NSF를 확장 가능하고 효율적인 방식으로 모니터링하기 위해 필요한 정보를 NSF가 제공 할 수 있도록 하는 방법을 설명한다. 본 명세서에서 제공된 모니터링 정보 모델은 [I-D.ietf-i2nsf-capability]에서 지정된 NSF-직면 인터페이스의 보안 정책 프로비져닝 기능에 대한 정보 모델의 보완 정보 모델이다.

본 명세서는 또한, NSF 모니터링을 위한 정보 모델에서 파생 된 NSF 모니터링을 위한 YANG [RFC7950] 데이터 모델을 정의한다.

NSF 모니터링 데이터의 사용 케이스

전술한 바와 같이, 모니터링은 전체 보안 프레임 워크에서 중요한 역할을 한다. NSF의 모니터링은 프로비저닝 된 보안 상태를 유지 관리 할 때, 보안 컨트롤러에 매우 유용한 정보를 제공한다. 이 외에도 NSF를 모니터링해야하는 다른 이유는 다음과 같다.

o I2NSF 사용자로서 보안 관리자는 NSF 또는 네트워크에서 발생하는 특정 이벤트에서 트리거되는 정책을 구성 할 수 있다 [RFC8329] [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 보안 컨트롤러가 지정된 이벤트를 감지하면 정책에 정의 된대로 추가 보안 기능을 구성한다.

o SIEM (Security Information and Event Management)은 보안 정책 위반의 결과로 NSF에 의해 트리거 된 이벤트를 사용하여 더 큰 상관(correlation) 컨텍스트에서 의심스러운 활동을 감지 할 수 있다.

o NSF의 이벤트 및 활동 로그를 사용하여 동작 및 예측 모델과 같은 고급 분석을 구축하여 대규모 배포시 보안 상태를 개선 할 수 있다.

o 보안 컨트롤러는 NSF의 이벤트를 사용하여 고 가용성(availability)을 달성 할 수 있다. 실패한 NSF 재시작 및 NSF 수평적 확장(horizontally scaling up)과 같은 수정 조치를 취할 수 있다.

o NSF의 이벤트 및 활동 로그는 운영 문제의 근본 원인 분석에 도움이 되므로 디버깅을 향상시킬 수 있다.

o NSF의 활동 로그를 사용하여 운영 및 비즈니스상의 이유로 기록 데이터를 작성할 수 있다.

NSF 모니터링 데이터의 분류

강력한 보안 상태를 유지하려면 NSF의 보안 정책을 구성하여야 할 뿐만 아니라 수집 가능하고 관찰 가능한 정보를 사용하여 NSF를 지속적으로 모니터링 해야한다. 이를 통해 보안 관리자는 네트워크 토폴로지의 상태를 적시에 평가할 수 있다. 정적인 보안 상태로는 모든 내부 및 외부 위협을 차단할 수 없다. 지속적인 가시성이 요구되는 동적 보안 조치를 사용하여 보다 실용적인 접근 방식이 지원될 수 있다. 본 명세서는 NSF에서 획득될 수 있고, NSF 모니터링 정보로 사용할 수 있는 일련의 정보 엘리먼트 (및 해당 스코프(scope))를 정의한다. 즉, 이러한 유형의 모니터링 정보는 여러 수준의 세분성에 대한 지속적인 가시성(visibility)을 지원하기 위해 활용 될 수 있으며, 대응되는 기능을 통해 사용될 수 있다.

본 명세서는 시스템 엔터티 [RFC4949] 또는 NSF에서 발생하는 모니터링 정보에 관한 세 가지 기본 영역을 예시한다.

o 보유 및 방출(Retention and Emission)

o 알림 및 이벤트(Notifications and Events)

o 요청하지 않은 폴링 및 요청 된 푸시(Unsolicited Poll and Solicited Push)

[RFC3877]의 알람 관리 프레임 워크는 관심있는 무언가가 발생한 것으로 이벤트를 정의한다. 또한, 결함(fault)을 상태 변경, 임계 값 초과 또는 시스템에 대한 외부 입력으로 정의한다. I2NSF 도메인에서, I2NSF 이벤트 [I-D.ietf-i2nsf-terminology]는 생성되며, 알람 관리 프레임 워크의 이벤트 스코프는 광범위한 정의를 갖으므로, 적용 가능하다. 본 명세서에 제시된 모델은 NSF 모니터링의 컨텍스트(context)에서 I2NSF 이벤트를 생성하는 워크 플로와 초기 I2NSF 이벤트가 생성되는 방식에 대해 예시한다.

I2NSF 구성 요소와 마찬가지로 모든 일반 시스템 엔터티에는 해당 시스템 엔터티의 컨텍스트, 구성, 구성, 상태 또는 동작에 대한 정보를 생성하는 일련의 능력(capabilities) [I-D.ietf-i2nsf- terminology]이 포함될 수 있다. 이러한 정보는 다른 소비자에게 제공될 수 있으며, 본 명세서는 NSF 정보 모니터링을 자동화 된 방식으로 다루는 방법을 예시한다.

1) 보유 및 방출

일반적으로 시스템 엔터티는 SNMP, NETCONF, 또는 RESTCONF 와 같은 표준화 된 인터페이스를 덧붙이고, NSF-Facing Interface [I-D.ietf-i2nsf-terminology]를 통해 생성된 정보를 제공하고 직접 방출한다. 또는 생성된 정보는 NSF-Facing Interfaces를 통해 직접 노출되지 않는 레코드 또는 카운터를 통해 시스템 엔터티(또는 복합적인 장치의 시스템 엔터티 계층) 내부에 유지될 수 있다.

표준화 된 인터페이스를 통해 방출 된 정보는 I2NSF 인터페이스 (예 : [ID.ietf-i2nsf-consumer-facing-interface-interface- dm])뿐만 아니라 일반 시스템 엔터티가 제공하는 표준화 된 인터페이스를 보완하는 인터페이스를 통해서도 가능하다.

시스템 엔터티에 보유되는 정보는 일반적으로 로그 파일 또는 데이터베이스 형식의 정보 레코드에 해당 I2NSF 사용자의 액세스가 요구된다. 예를 들어, Syslog 프로토콜 [RFC5424] 또는 TCP를 통한 Syslog [RFC6587]를 통해, 네트워크를 이용하여 다른 시스템 엔터티에서 생성된 레코드를 집계하는 방법이 있다. 그러나 레코드가 전달 되더라도, 그 결과는 다른 시스템 엔터티의 더 큰 레코드 집계 형태와 동일한 종류의 보유일 수 있다.

I2NSF 사용자는 해당 I2NSF 인터페이스를 통하여 다른 I2NSF 구성 요소에 적시 제공을 위해, I2NSF 기능을 통해 생성된 새로운 [RFC4949] 레코드를 프로세스 해야 한다. 이러한 프로세스는 특정 유형의 레코드에 액세스하고, 이를 보유하거나 방출 할 때, 모니터링 프로세스를 지원하는 데 필요한 정보를 워크 플로우의 어느 시점에서 I2NSF 사용자가 처리해야하는 정보로 변환 할 수 있는지에 대한 균질화 기능에 근거한다. 이러한 I2NSF 사용자의 일반적인 위치는 다음과 같다.

o 정보를 생성하는 시스템 엔티티

o 레코드 집계를 보유하는 시스템 엔티티

o I2NSF 구성 요소가 아닌 다른 시스템 엔티티가 제공하는 표준화 된 인터페이스를 사용하는 기능을 포함하는 I2NSF 구성 요소

o 정보를 생성하는 I2NSF 구성 요소

2) 알림 및 이벤트

I2NSF 사용자의 구체적인 임무는 I2NSF 정책 규칙 [I-D.ietf-i2nsf-terminology]을 처리하는 것이다. 정책 규칙은 이벤트, 조건 및 동작의 세 가지 절로 구성된다. 결과적으로 I2NSF 이벤트가 I2NSF 정책 규칙을 트리거하도록 지정된다. 이러한 I2NSF 이벤트는 관리되는 시스템 및/또는 [ID.ietf-i2nsf-terminology]에서 관리되는 시스템 환경에서 시간이 지남에 따라 발생하는 중요한 이벤트로 정의될 수 있다[RFC3877].

본 명세서에서 설명되는 모델은 전달된 알림이 될 수 있는 보완적인 유형의 정보를 예시한다.

알림(Notification) : I2NSF 사용자가 직접 또는 간접적으로 관찰 할 수 있고, I2NSF 정책 규칙의 이벤트-절에 대한 입력으로 사용될 수 있는 시스템 엔터티의 컨텍스트, 구성, 설정, 상태 또는 동작의 변경을 일으킨다.

알림는 I2NSF 구성 요소가 아닌 시스템 엔티티에 의해 작성되고, 그 중요성이 평가되지 않았다는 점을 제외하면, I2NSF 이벤트와 유사하다. 예를 들어, 알림은 I2NSF의 컨텍스트에서 I2NSF 이벤트가 아니지만, 정확히 동일한 정보 또는 데이터 모델을 사용할 수 있다. [RFC3877]과 관련하여 알림은 이벤트의 특정 서브셋의 집합으로, 관심있는 무언가가 발생한 것에 대한 정보를 전달하기 때문이다.

결과적으로 알림에는 표현력 또는 관련성이 매우 낮은 정보가 포함될 수 있다. 따라서 I2NSF 정책 규칙의 이벤트-절에 필요한 표현 수준을 충족시키기 위해 집계(aggregation), 상관성(correlation) 또는 간단한 이상 탐지(anomaly detection)와 같은 추가 사후 처리 기능을 사용해야 할 수도 있다.

알림의 소비자(관찰자)는 생산자와 달리, 알림의 중요성을 평가한다는 점에서 주의해야 한다. 생산자는 중요도(심각도에 대한 메타 데이터)를 평가할 때 관찰자를 지원하는 알림에 메타 데이터를 포함 할 수 있지만, 결정하는 엔티티는 I2NSF 사용자이다.

3) 요청하지 않은 폴링 및 요청 된 푸시

모니터링되는 정보의 신선도는 획득 방법에 따라 다르다. 이상적으로, I2NSF 사용자는 I2NSF 구성 요소에 대한 모든 관련 정보에 액세스하고 I2NSF 이벤트를 모니터 엔티티(예 : 보안 컨트롤러 및 I2NSF 사용자) NSF에게 적시에 방출할 수 있다. pubsub / broker 모델, 피어 2 피어 메시 또는 정적 정의 채널을 통한 이벤트 게시는 요청된 I2NSF 이벤트 푸시를 용이하게 하는 방법에 대한 몇 가지 예이다.

예를 들어, 해당 관리 인터페이스는 I2NSF 정책 규칙에 의해 요구되는 경우, 특정 간격으로 또는 요청시에 쿼리되어야 한다. 경우에 따라 정보 수집은 시스템 엔터티에서 제공하는 로그인 기법을 통해 수행되어야 한다. 이러한 종류의 원치 않는 폴링을 통해 정보 레코드에 액세스하면 모니터링되는 정보의 최신성과 관련하여 상당한 대기 시간이 발생할 수 있다.

4) 보유 정보에 대한 I2NSF 모니터링 용어

레코드 : 알림을 통해 방출된 정보 및 이벤트와 달리, 레코드는 분석자의 즉각적인 주의가 요구되지는 않지만, 가시성 및 소급적인 사이버 포렌식 (forensic)에 유용 할 수 있다. 레코드 형식에 따라 구조 및 세부 사항과 관련하여 다른 품질이 있을 수 있다. 레코드는 일반적으로 시스템 엔터티 또는 NSF의 로그 파일 또는 데이터베이스에 저장된다. 로그 파일 형식의 레코드에는 일반적으로 시스템 엔터티의 특성 변경과 관련하여 더 적은 구조이지만 잠재적으로 더 자세한 정보가 포함될 수 있다. 반대로 데이터베이스는 종종 더 엄격한 방식 또는 데이터 모델을 사용하므로 더 나은 구조를 구현할 수 있다. 그러나 이러한 모델과 매치되지 않는 정보("closed world assumption ")는 저장하지 않는다. I2NSF 생산자(Producer) 역할을 하는 특정 I2NSF 에이전트가 레코드를 지속적으로 처리 할 수 *?*있으며, 특정 유형의 레코드에 맞는 기능을 통해 이벤트를 방출한다. 일반적으로 레코드는 NSF 또는 시스템 엔터티가 운영 및 정보 데이터 또는 사용자 활동, 네트워크 / 트래픽 상태 및 네트워크 활동과 같은 시스템 특성의 다양한 변경에 대해 생성한 정보이다. 이는 디버깅, 감사 및 보안 포렌식에 중요하다.

카운터: 잠재적으로 높은 빈도로 발생하는 정보 요소의 연속적인 가치 변동을 나타내는 구체적인 표현, 대표적인 예로, 네트워크 인터페이스 카운터(예: PDU amount or byte amount, drop counters, and error counters)가 있다. 카운터는 NSF의 작동 동작에 대한 디버깅과 가시성에 유용하다. 카운터의 진행을 관찰하는 I2NSF 에이전트는 I2NSF 생산자 역할을 할 수 있으며 I2NSF 정책 규칙과 관련하여 이벤트를 방출할 수 있다.

NSF 모니터링 정보의 전달

NSF 모니터링 데이터의 사용 케이스에 따라, I2NSF 능력 및 워크플로우에 의해 부과된 요건에 근거하여, 다양한 I2NSF 소비자에게 정보를 전달할 필요가 있다. 다음과 같은 요청 당사자에게 모니터링 정보의 방출과 관련하여 고려해야 할 여러 측면이 있다.

o Pull-Push 모델: 데이터 셋은 NSF가 요청 당사자에게 푸시하거나 NSF에서 요청 당사자가 가져올 수 있다. 다양한 요구사항을 가진 여러 I2NSF 소비자가 있는 경우 특정 유형의 정보는 두 모델을 동시에 필요로 할 수 있다. 일반적으로 높은 심각도 평가를 포함한 I2NSF 이벤트는 매우 중요한 것으로 간주되며 가능한 한 빨리 처리되어야 한다(푸시 모델). 이와는 대조적으로, 레코드는 일반적으로 그만큼 중요하지는 않다(풀 모델).

o Pub-Sub 모델: I2NSF 제공자(Provider)가 모니터링 정보를 여러 해당 I2NSF 소비자에게 푸시하기 위해, 두 가지 I2NSF 구성 요소에 의해 가입을 유지할 수 있다. 사용 가능한 모니터링 정보의 검색은 브로커 역할을 수행하므로 등록을 지원하는 I2NSF 기능을 포함하는 I2NSF 컨트롤러에 의해 지원될 수 있다.

o Export Frequency: 모니터링 정보는 NSF가 I2NSF 소비자를 요청하기 위해 생성 즉시 방출되거나 주기적으로 푸시될 수 있다. 데이터를 내보내는 빈도는 데이터의 크기와 적시의 유용성에 따라 달라진다. 이는 I2NSF의 스코프를 벗어나 각 NSF 구현에 맡긴다.

o 인증(Authentication): 중요한 정보가 기밀로 유지되도록 하기 위해 I2NSF 모니터링 정보 생산자와 해당 I2NSF 소비자 사이에 인증이 필요할 수 있다. I2NSF의 범위에서의 인증도 그에 상응하는 콘텐츠 인증을 요구할 수 있다. 예를 들어, NSF가 관리 영역 외부의 I2NSF 소비자에게 모니터링 정보를 방출하는 경우 이것은 요구될 수 있다. I2NSF 아키텍처는 특정 인증이 구현되어야 하는 시기와 방법을 요구하지 않는다.

o 데이터 전송 모델(Data-Transfer Model): 모니터링 정보는 지속적인 연결이 필요한 비연결 모델을 사용하여 NSF에 의해 푸시되거나 영구 연결을 통해 스트리밍될 수 있다. 적절한 모델은 I2NSF 소비자 요구사항과 전달되는 정보의 의미에 따라 달라진다.

o 동작 중인 데이터에 대한 데이터 모델 및 상호 작용 모델(Data Model and Interaction Model for Data in Motion): IP, UDP, TCP 등의 많은 전송 메커니즘이 존재한다. 시스템 카운터(예: IPFIX [RFC7011] 및 NetFlow [RFC3954])와 같은 특정 데이터 집합에 대한 오픈 소스 구현도 있다. I2NSF는 주어진 데이터 세트에 대해 어떤 구체적인 방법을 의무화하지 않기 때문에 각 구현에 달려 있다.

1) 정보유형 및 획득방법(Information Types and Acquisition Methods)

본 명세서에서 대부분의 정의된 정보 유형은 값 변화(예: 알람 및 레코드)와 관련하여 높은 가시성으로부터 이익을 얻는다. 이와는 대조적으로, 연속적인 방식으로 단조롭게 변하는 값들은 이러한 높은 가시성의 혜택을 받지 못한다. 반대로, 각각의 변화를 방출하는 것은 쓸모없는 양의 값 갱신을 초래할 것이다. 따라서 카운터와 같은 값은 주기적인 간격으로 획득되는 것이 바람직하다.

YANG Push [I-D.ietf-netconf-양-push]와 YANG Subscribed Notifications[I-D.ietf-netconf-subscribed-notification]에서 제공하는 메커니즘은 이러한 요구 사항을 정확하게 다룬다. 또한, YANG은 데이터 저장소 또는 이벤트 스트림에 대한 가입뿐만 아니라 의미론적으로 잘 구성된 정보를 가능하게 한다.

따라서 본 명세서의 정보 모델은 잠재적으로 가입 메커니즘에 의해 촉진되는 요청되거나 요청되지 않은 이벤트 스트림에 사용되는 데이터 모델을 지원하기 위한 것이다.

모든 모니터링 데이터의 기본 정보 모델(Basic Information Model for All Monitoring Data)

전술한 바와 같이, NSF에서 이용할 수 있는 다양한 데이터가 모니터링될 수 있다. 첫째로, 소비자가 메시지의 메타 데이터를 식별할 수 있도록 NSF로부터 전송된 각 모니터링 메시지에 대한 일반적인 정보가 있어야 하며, 이 정보는 다음과 같다.

o message_version: 데이터 형식의 버전을 나타내며 01부터 시작하는 두 자리 소수점 숫자다.

o message_type: Event, Alert, Alarm, Log, Counter 등

o time_properties: 메시지가 생성된 시간을 나타낸다.

o vendor_name: NSF 공급업체의 이름.

o NSF_name: 메시지를 생성하는 NSF의 이름(또는 IP)

o Module_name: 메시지를 출력하는 모듈 이름.

o Severity: 그것은 로그의 수준을 나타낸다. 0부터 7까지 총 8단계가 있다. 숫자가 작을수록 심각도가 높다.

데이터 모니터링을 위한 확장 정보 모델(Extended Information Model for Monitoring Data)

이 절에서는 시스템 메시지와 관련된 추가 정보를 다룬다. 확장 정보 모델은 알람과 같은 구조화된 데이터만을 위한 것이다. 구조화되지 않은 데이터는 기본 정보 모델에서만 지정된다.

1) System Alarms

Characteristics:

o acquisition_method: subscription

o emission_type: on-change

o dampening_type: no-dampening

(1) Memory Alarm

메모리 알람은 다음의 정보를 포함할 수 있다.

o event_name: MEM_USage_ALAM

o module_name: 이것은 이 알람을 발생시키는 NSF 모듈을 나타낸다.

o usage: 사용되는 메모리 양

o threshold: 알람을 트리거하는 임계값

o severity: 심각, 높음, 중간, 낮음 등의 경보 심각도

o message: 메모리 사용량이 임계값을 초과함

(2) CPU Alarm

CPU Alarm은 다음 정보를 포함할 수 있다.

o event_name: CPU_USAGE_ALARM

o usage: CPU 사용량을 지정.

o threshold: 이벤트를 트리거하는 임계값

o severity: 심각, 높음, 중간, 낮음 등의 경보 심각도

o message: CPU 사용량이 임계값을 초과함.

(3) Disk Alarm

Disk Alarm은 다음 정보를 포함한다.

o event_name: DISK_USAGE_ALARM

o usage: 사용된 디스크 공간의 양

o threshold: 이벤트를 트리거하는 임계값

o severity: 심각, 높음, 중간, 낮음 등의 경보 심각도

o message: 디스크 사용량이 임계값을 초과함.

(4) Hardware Alarm

Hardware Alarm은 다음 정보를 포함한다:

o event_name: HW_FAILURE_ALARM

o component_name: 이 알람을 발생시키는 HW 구성부품을 표시.

o threshold: 알람을 트리거하는 임계값

o severity: 심각, 높음, 중간, 낮음 등의 경보 심각도

o message: HW 구성 요소가 고장나거나 성능이 저하.

(5) Interface Alarm

Interface Alarm은 다음 정보를 포함한다:

o event_name: IFNET_STATE_ALARM

o interface_Name: 인터페이스 이름

o interface_state: UP, DOWN, CONGESTED

o threshold: 이벤트를 트리거하는 임계값

o severity: 심각, 높음, 중간, 낮음 등의 경보 심각도

o message: 현재 인터페이스 상태

2) System Events

Characteristics:

o acquisition_method: subscription

o emission_type: on-change

o dampening_type: on-repetition

(1) Access Violation

이러한 이벤트는 다음과 같은 정보를 포함한다:

o event_name: ACCESS_DENIED

o user: 사용자 이름

o group: 사용자가 속한 그룹

o login_ip_address: 사용자의 로그인 IP 주소

o authentication_mode: 사용자 인증 모드(예: 로컬 인증, 타사 서버 인증, 인증 면제, SSO(Single Sign-On) 인증)

o message: 엑세스가 거부됨.

(2) Configuration Change

이러한 이벤트는 다음과 같은 정보를 포함한다:

o event_name: CONFIG_CHANGE

o user: 사용자 이름

o group: 사용자가 속한 그룹

o login_ip_address: 사용자의 로그인 IP 주소

o message: 설정이 수정됨.

3) NSF Events

Characteristics:

o acquisition_method: subscription

o emission_type: on-change

o dampening_type: none

(1) DDoS Event

DDoS 이벤트는 다음의 정보를 포함한다:

o event_name: SEC_EVENT_DDoS

o sub_attack_type: SYN flood, ACK flood, SYN-ACK flood, FIN/RST flood, TCP Connection flood, UDP flood, ICMP flood, HTTPS flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 등.

o dst_ip: 공격 대상 피해 IP 주소

o dst_port: 공격 트래픽이 목표로 하는 포트 번호.

o start_time: 공격이 시작된 시기를 나타내는 타임스탬프

o end_time: 공격이 종료된 시간을 나타내는 타임스탬프. 알람을 보낼 때 여전히 공격이 진행 중이라면 이 필드는 비어 있을 수 있다.

o attack_rate: 공격 트래픽의 PPS

o attack_speed: 공격 트래픽의 bps

o rule_id: 트리거되는 규칙의 ID

o rule_name: 트리거되는 규칙 이름

o profile: 트래픽이 매치되는 보안 프로필.

(2) Session Table Event

세션은 다음의 정보를 포함한다.

Table Event:

o event_name: SESSION_USAGE_HIGH

o current: 현재 세션의 수

o max: 세션 테이블이 지원할 수 있는 최대 세션 수

o threshold: 이벤트를 트리거하는 임계값

o message: 세션 테이블 수가 임계값을 초과.

(3) Virus Event

Virus Event는 다음의 정보를 포함한다:

o event_Name: SEC_EVENT_VIRUS

o virus_type: 바이러스 유형(예: 트로이 목마, 웜, 매크로 바이러스 유형)

o virus_name: 바이러스 이름

o dst_ip: 바이러스가 발견된 패킷의 대상 IP 주소

o src_ip: 바이러스가 발견된 패킷의 원본 IP 주소

o src_port: 바이러스가 발견된 패킷의 원본 포트

o dst_port: 바이러스가 발견된 패킷의 대상 포트

o src_zone: 바이러스가 발견된 패킷의 원본 보안 영역

o dst_zone: 바이러스가 발견된 패킷의 대상 보안 영역

o file_type: 바이러스가 위치하는 파일의 유형

o file_name: 바이러스가 있는 파일의 이름

o virus_info: 바이러스의 간단한 소개

o raw_info: 벤트를 트리거하는 패킷을 설명하는 정보.

o rule_id: 트리거되는 규칙의 ID

o rule_name: 트리거되는 규칙 이름

o profile: 트래픽이 일치하는 보안 프로필.

(4) Intrusion Event

Intrusion Event는 다음의 정보를 포함한다:

o event_name: 이벤트 이름(예: SEC_EVENT_Intrusion)

o sub_attack_type: 공격 유형, 예, brutal force , buffer overflow

o src_ip: 패킷의 소스 IP 주소

o dst_ip: 패킷의 대상 IP 주소

o src_port: 패킷의 소스 포트 번호

o dst_port: 패킷의 대상 포트 번호

o src_zone: 패킷의 원본 보안 영역

o dst_zone: 패킷의 대상 보안 영역

o protocol: 채택된 전송 계층 프로토콜, 예:TCP 및 UDP

o app: 채택된 애플리케이션 계층 프로토콜, 예:HTTP 및 FTP

o rule_id: 트리거되는 규칙의 ID

o rule_name: 트리거되는 규칙 이름

o profile: 트래픽이 매치되는 보안 프로파일

o intrusion_info: 침입에 대한 간단한 설명

o raw_info: 이벤트를 트리거하는 패킷을 설명하는 정보

(5) Botnet Event

Botnet Event는 다음의 정보를 포함한다:

o event_name: 이벤트 이름. 예: SEC_EVENT_Botnet

o botnet_name: 탐지된 봇넷의 이름

o src_ip: 패킷의 소스 IP 주소

o dst_ip: 패킷의 대상 IP 주소

o src_port: 패킷의 소스 포트 번호

o dst_port: 패킷의 대상 포트 번호

o src_zone: 패킷의 원본 보안 영역

o dst_zone: 패킷의 대상 보안 영역

o protocol: 채택된 전송 계층 프로토콜, 예:TCP 및 UDP

o app: 채택된 애플리케이션 계층 프로토콜, 예:HTTP 및 FTP

o role: 봇넷에서 통신 파티의 역할:

1. 좀비 호스트에서 공격자에게 보내는 패킷

2. 공격자가 좀비 호스트로 전송하는 패킷

3. IRC/WEB 서버에서 좀비 호스트로의 패킷

4. 좀비 호스트에서 IRC/WEB 서버로 가는 패킷

5. 공격자가 IRC/WEB 서버로 전송하는 패킷

6. IRC/WEB 서버에서 공격자에게 보내는 패킷

7. 좀비 호스트에서 피해자에게 보내는 패킷

o botnet_info: Botnet에 대한 간단한 설명

o rule_id: 트리거되는 규칙의 ID

o rule_name: 트리거되는 규칙 이름

o profile: 트래픽이 매치되는 보안 프로파일

o raw_info: 이벤트를 트리거하는 패킷을 설명하는 정보.

(6) Web Attack Event

Web Attack Alarm은 다음의 정보를 포함한다:

o event_name: 이벤트 이름. e.g., SEC_EVENT_WebAttack

o sub_attack_type: Concrete web attack 타입. e.g., SQL injection, command injection, XSS, CSRF

o src_ip: 패킷의 소스 IP 주소

o dst_ip: 패킷의 대상 IP 주소

o src_port: 패킷의 소스 포트 번호

o dst_port: 패킷의 대상 포트 번호

o src_zone: 패킷의 원본 보안 영역

o dst_zone: 패킷의 대상 보안 영역

o req_method: 요구 방법. 예를 들어 HTTP의 "PUT" 및 "GET"

o req_url: Requested URL

o url_category: Matched URL category

o filtering_type: URL 필터링 유형. e.g., Blacklist, Whitelist, User-Defined, Predefined, Malicious Category, and Unknown

o rule_id: 트리거되는 규칙의 ID

o rule_name: 트리거되는 규칙 이름

o profile: 트래픽이 매치되는 보안 프로파일

4) System Logs

Characteristics:

o acquisition_method: subscription

o emission_type: on-change

o dampening_type: on-repetition

(1) Access Log

액세스 로그는 장치에서의 관리자의 로그인, 로그아웃 및 작업 기록을 기록한다. 이를 분석하면, 보안 취약점을 파악할 수 있다. 운영보고서(operation report)는 다음 정보를 포함한다:

o Administrator: 장치에서 작동하는 관리자

o login_ip_address: 관리자가 로그인할 때 사용하는 IP 주소

o login_mode: 모드에서 관리자 로그 지정 e.g., root, user

o operation_type: 관리자가 실행하는 작업 유형, e.g., login, logout, and configuration.

o result: 명령 실행 결과

o content: 관리자가 로그인한 후 수행하는 작업.

(2) Resource Utilization Log

실행 보고서는 장치 시스템의 실행 상태를 기록하는데, 이것은 장치 모니터링에 유용하다. 실행 보고서는 다음 정보를 포함한다:

o system_status: 현재 시스템 실행 상태

o CPU_usage: CPU 사용량을 지정.

o memory_usage: 메모리 사용량을 지정.

o disk_usage: 디스크 사용량을 지정.

o disk_left: 남은 사용 가능한 디스크 공간을 지정.

o session_number: 총 동시 세션.

o process_number: 총 시스템 프로세스 수.

o in_traffic_rate: 총 인바운드 트래픽 속도(pps)

o out_traffic_rate: 총 아웃바운드 트래픽 속도(pps)

o in_traffic_speed: 총 인바운드 트래픽 속도(bps)

o out_traffic_speed: 총 아웃바운드 트래픽 속도(Gbps)

(3) User Activity Log

사용자 활동 로그는 사용자의 온라인 기록(로그인 시간, 온라인/잠금 기간, 로그인 IP 주소 등)과 사용자가 수행하는 작업에 대한 가시성을 제공한다. 사용자 활동 리포트는 사용자의 로그인 및 네트워크 액세스 활동 중 예외를 식별하는 데 유용하다.

o user: 사용자 이름

o group: 사용자가 속한 그룹

o login_ip_address: 사용자의 로그인 IP 주소

o authentication_mode: 사용자 인증 모드. e.g., Local Authentication, Third-Party Server Authentication, Authentication Exemption, SSO Authentication

o access_mode: 사용자 액세스 모드. e.g., PPP, SVN, LOCAL

o online_duration: 온라인 기간

o lockout_duration: 잠금 기간

o type: 사용자 활동. e.g., Successful User Login, Failed Login attempts, User Logout, Successful User Password Change, Failed User Password Change, User Lockout, User Unlocking, Unknown

o cause: 사용자 작업 실패의 원인

5) NSF Logs

Characteristics:

o acquisition_method: subscription

o emission_type: on-change

o dampening_type: on_repetition

(1) DDoS Log

DDoS 알람의 필드 외에 다음 정보가 DDoS Log에 포함된다:

o attack_type: DDoS

o attack_ave_rate: 기록된 시간 내에 공격 트래픽의 평균 pps

o attack_ave_speed: 기록된 시간 내에 공격 트래픽의 평균 bps

o attack_pkt_num: 기록된 시간 내에 공격 패킷 수

o attack_src_ip: 공격 트래픽의 소스 IP 주소. IP 주소가 많은 경우 다른 규칙에 따라 특정 수의 리소스를 선택.

o action: DDoS 공격에 대한 작업. e.g., Allow, Alert, Block, Discard, Declare, Block-ip, and Block-service.

(2) Virus Log

바이러스 경보의 필드 외에 다음 정보가 Virus Log에 포함된다:

o attack_type: Virus

o protocol: 전송 계층 프로토콜

o app: 애플리케이션 계층 프로토콜 이름

o times: 바이러스를 탐지하는 시간

o action: 바이러스에 대한 동작. e.g., alert and block

o os: 바이러스가 영향을 미치는 OS. e.g., all, android, ios, unix, and windows

(3) Intrusion Log

침입 알람의 필드 외에 다음 정보가 침입 로그에 포함된다:

o attack_type: Intrusion

o times: 침입이 발생한 시간

o os: 침입이 영향을 미치는 OS. e.g., all, android, ios, unix, and windows

o action: 침입을 처리하는 동작. e.g., Allow, Alert, Block, Discard, Declare, Block-ip, and Block-service

o attack_rate: NUM the pps of attack traffic

o attack_speed: NUM the bps of attack traffic

(4) Botnet Log

Botnet Alarm의 필드 외에 다음 정보가 Botnet Log에 포함된다:

o attack_type: Botnet

o botnet_pkt_num: 탐지된 봇넷으로 또는 봇넷에서 보낸 패킷 수

o action: 탐지된 패킷을 처리하는 동작. e.g., Allow, Alert, Block, Discard, Declare, Block-ip, and Block-service.

o os: 공격이 목표로 하는 OS. e.g., all, android, ios, unix, and windows.

(5) DPI Log

DPI Log는 업로드/다운로드된 파일과 데이터에 대한 통계, 주고 받은 전자 메일, 웹 사이트에 대한 경고 및 차단 레코드를 제공한다. 위험한 사용자 행동과 일부 URL에 대한 액세스가 경고 레코드로 차단되거나 허용되는 이유를 학습하는 것이 도움이 된다.

o type: DPI action types. e.g., File Blocking, Data Filtering, and Application Behavior Control

o file_name: 파일 이름

o file_type: 파일 형식

o src_zone: 트래픽의 소스 보안 영역

o dst_zone: 트래픽의 대상 보안 영역

o src_region: 트래픽의 소스 영역

o dst_region: 트래픽의 대상 영역

o src_ip: 트래픽의 소스 IP 주소

o src_user: 트래픽을 생성하는 사용자

o dst_ip: 트래픽의 대상 IP 주소

o src_port: 트래픽 소스 포트

o dst_port: 대상 트래픽 포트

o protocol: 트래픽의 프로토콜 유형

o app: 트래픽의 응용 프로그램 유형

o policy_id: 트래픽이 매치되는 보안 정책 ID

o policy_name: 트래픽과 매치되는 보안 정책 이름

o action: 트래픽이 매치하는 파일 차단 규칙, 데이터 필터링 규칙 또는 응용 프로그램 동작 제어 규칙에 정의된 작업.

(6) Vulnerability Scanning Log

Vulnerability Scanning Log는 수정해야 하는 대상 호스트 및 관련 취약성 정보를 기록한다. 리포트에는 다음 정보가 포함된다:

o victim_ip: 취약성이 있는 공격 대상 호스트의 IP 주소

o vulnerability_id: 취약성 ID

o vulnerability_level: 취약성 수준(예: 높음, 중간 및 낮음)

o OS: 공격 대상 호스트의 운영 체제

o service: 공격 대상 호스트에 취약성이 있는 서비스

o protocol: 프로토콜 유형. e.g., TCP and UDP

o port: 포트 번호

o vulnerability_info: 취약성에 대한 정보

o fix_suggestion: 취약성에 대한 해결 제안.

(7) Web Attack Log

Web Attack Alarm의 필드 외에 다음 정보가 Web Attack Report에 포함된다:

o attack_type: Web Attack

o rsp_code: Response code

o req_clientapp: 클라이언트 응용 프로그램

o req_cookies: Cookies

o req_host: 요청한 호스트의 도메인 이름

o raw_info: 이벤트를 트리거하는 패킷을 설명하는 정보.

6) System Counter

Characteristics:

o acquisition_method: subscription or query

o emission_type: periodical

o dampening_type: none

(1) Interface counter

Interface counters NSF로 들어오고 나가는 트래픽과 대역폭 사용에 대한 가시성을 제공한다.

o interface_name: NSF에서 구성된 네트워크 인터페이스 이름

o in_total_traffic_pkts: Total inbound packets

o out_total_traffic_pkts: Total outbound packets

o in_total_traffic_bytes: Total inbound bytes

o out_total_traffic_bytes: Total outbound bytes

o in_drop_traffic_pkts: Total inbound drop packets

o out_drop_traffic_pkts: Total outbound drop packets

o in_drop_traffic_bytes: Total inbound drop bytes

o out_drop_traffic_bytes: Total outbound drop bytes

o in_traffic_ave_rate: Inbound traffic average rate in pps

o in_traffic_peak_rate: Inbound traffic peak rate in pps

o in_traffic_ave_speed: Inbound traffic average speed in bps

o in_traffic_peak_speed: Inbound traffic peak speed in bps

o out_traffic_ave_rate: Outbound traffic average rate in pps

o out_traffic_peak_rate: Outbound traffic peak rate in pps

o out_traffic_ave_speed: Outbound traffic average speed in bps

o out_traffic_peak_speed: Outbound traffic peak speed in bps

7) NSF Counters

Characteristics:

o acquisition_method: subscription or query

o emission_type: periodical

o dampening_type: none

(1) Firewall counter

Firewall counters 트래픽 서명, 대역폭 사용 및 구성된 보안 및 대역폭 정책이 적용된 방법에 대한 가시성을 제공한다.

o src_zone: 트래픽의 소스 보안 영역

o dst_zone: 트래픽의 대상 보안 영역

o src_region: 트래픽의 소스 영역

o dst_region: 트래픽의 대상 영역

o src_ip: 트래픽의 소스 IP 주소

o src_user: 트래픽을 생성하는 사용자

o dst_ip: 트래픽의 대상 IP 주소

o src_port: 트래픽 소스 포트

o dst_port: 대상 트래픽 포트

o protocol: 트래픽의 프로토콜 유형

o app: 트래픽의 응용 프로그램 유형

o policy_id: 트래픽이 매치되는 보안 정책 ID

o policy_name: 트래픽과 매치되는 보안 정책 이름

o in_interface: Inbound interface of traffic

o out_interface: Outbound interface of traffic

o total_traffic: Total traffic volume

o in_traffic_ave_rate: Inbound traffic average rate in pps

o in_traffic_peak_rate: Inbound traffic peak rate in pps

o in_traffic_ave_speed: Inbound traffic average speed in bps

o in_traffic_peak_speed: Inbound traffic peak speed in bps

o out_traffic_ave_rate: Outbound traffic average rate in pps

o out_traffic_peak_rate: Outbound traffic peak rate in pps

o out_traffic_ave_speed: Outbound traffic average speed in bps

o out_traffic_peak_speed: Outbound traffic peak speed in bps

(2) Policy Hit Counter

Policy Hit Counters 트래픽과 일치하는 보안 정책과 적중 횟수를 기록한다. 이를 통해, 정책 설정이 올바른지 확인할 수 있다.

o src_zone: 트래픽의 소스 보안 영역

o dst_zone: 트래픽의 대상 보안 영역

o src_region: 트래픽의 소스 영역

o dst_region: 트래픽의 대상 영역

o src_ip: 트래픽의 소스 IP 주소

o src_user: 트래픽을 생성하는 사용자

o dst_ip: 트래픽의 대상 IP 주소

o src_port: 트래픽 소스 포트

o dst_port: 대상 트래픽 포트

o protocol: 트래픽의 프로토콜 유형

o app: 트래픽의 응용 프로그램 유형

o policy_id: 트래픽이 매치되는 보안 정책 ID

o policy_name: 트래픽과 매치되는 보안 정책 이름

o hit_times: 보안 정책이 지정된 트래픽과 매치되는 hit times.

I2NSF에서 NSF 모니터링 관리

관리자가 NSF에서 생성된 모니터링 데이터를 확인하기 위해서는 데이터 모니터링 표준 모델이 필요하다. 관리자는 다음과 같은 과정을 통해 모니터링 데이터를 확인할 수 있다. 표준 형식에 해당하는 NSF 모니터링 데이터가 생성되면 NSF는 이를 보안 컨트롤러에 전달한다. 보안 컨트롤러는 관리자가 I2NSF 프레임워크의 상태를 알 수 있도록 I2NSF 소비자(사용자) 또는 Developer's Management System(DMS)에 전달한다.

다른 구성 요소와 통신하기 위해, I2NSF 프레임워크 [RFC8329]에는 인터페이스가 필요하다. I2NSF 프레임워크의 3가지 주요 인터페이스는 다음과 같은 모니터링 데이터를 전송하는데 사용된다.

o I2NSF 소비자 직면 인터페이스 [I-D.ietf-i2nsf-consumer-facing-interface-dm]: I2NSF 사용자가 보안 정책을 만들어 소비자 직면 인터페이스(Consumer-Facing Interface)를 통해 보안 컨트롤러에 전달하면, 위협 방지를 위한 위협 피드(Threat Feed), 사용자 지정 목록, 악성 코드 검색 그룹 및 이벤트 맵 그룹이 설정될 수 있다. 이들은 NSF에 의해 감시되는 이벤트로 사용될 수 있다.

o I2NSF 등록 인터페이스 [I-D.ietf-i2nsf-registration-interface -dm]: NFV(Network Functions Virtualization) 아키텍처는 Ve-Vnfm 인터페이스를 통한 VNF(Virtual Network Function)의 라이프사이클 관리를 제공한다. Ve-Vnfm의 역할은 VNF 라이프사이클 관리(예: NSF의 인스턴스화 및 해제, NSF 간의 로드 밸런싱), 네트워크 서비스에 대한 교환 구성 정보 및 교환 상태 정보를 요청하는 것이다. I2NSF 프레임워크에서 DMS는 NSF의 라이프사이클 관리를 위해 리소스 상태 및 네트워크 트래픽에 대한 데이터를 관리한다. 따라서 NSF에서 생성된 모니터링 데이터는 등록 인터페이스를 통해 보안 컨트롤러에서 DMS로 전달된다. 이러한 데이터는 DMS에서 NFV(Network Functions Virtualization) 시스템의 관리 및 조정(Management and Orchestration, MANO)에 있는 VNF(Virtual Network Function) 매니저로 전달된다[I-D.dang-i2nsf-nfv 아키텍처].

o I2NSF NSF-직면 인터페이스 [I-D.ietf-i2nsf-nsf-facing-interface-dm]: I2NSF 사용자의 상위 레벨의 보안 정책을 Security Controller의 보안 정책 번역기[I-D.dang-i2nsf-security-policy-translation]에 의해 번역된 보안 정책(즉, 하위 레벨의 정책)이 NSF-Facing Interface를 통해 NSF에 적용된다. 모니터링 데이터 모델은 NSF-Facing Interface를 통해 ECA(Event-Condition-Action) 정책을 트리거할 수 있는 이벤트 목록을 지정한다.

도 4a 내지 도 4h는 본 명세서가 적용될 수 있는 NSF 모니터링 정보 모델의 예시이다.

도 5a 내지 도 6i는 본 명세서가 적용될 수 있는 모니터링 데이터 모델의 예시이다.

도 7은 본 명세서가 적용될 수 있는 일 실시예이다.

도 7을 참조하면, 보안 컨트롤러는 I2NSF(Interface to Network Security Functions) 사용자로부터 소비자 직면(Consumer-Facing) 인터페이스를 통해, 상위 레벨(High-Level)의 제1 보안 정책을 수신한다(S7010). 예를 들어, 상기 제1 보안 정책은 상기 보안 관리 시스템에서 발생하는 특정 이벤트에서 트리거되는 정책을 포함할 수 있다.

보안 컨트롤러는 상기 제1 보안 정책을 하위 레벨(Low-Level)의 제2 보안 정책으로 번역한다(S7020).

보안 컨트롤러는 상기 제2 보안 정책을 NSF(Network Security Function)에게 설정하기 위한 상기 제2 보안 정책을 포함하는 패킷을 상기 NSF로 전송한다(S7030).

보안 컨트롤러는 상기 NSF로부터, NSF 직면(NSF-Facing) 인터페이스를 통해, 모니터링 데이터를 수신한다(S7040).

예를 들어, 상기 모니터링 데이터는 1) 상기 모니터링 데이터의 타입정보 및 2) 상기 NSF의 정보를 포함할 수 있다.

이상에서 설명된 실시 예들은 본 명세서의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 명세서의 실시 예를 구성하는 것도 가능하다. 본 명세서의 실시 예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시 예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시 예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.

본 명세서에 따른 실시 예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 명세서의 일 실시 예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

펌웨어나 소프트웨어에 의한 구현의 경우, 본 명세서의 일 실시 예는 이상에서 설명된 능력 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.

본 명세서는 본 명세서의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 명세서의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 명세서의 등가적 범위 내에서의 모든 변경은 본 명세서의 범위에 포함된다.

산업상 이용가능성

본 명세서는 다양한 보안 관리 시스템에 적용될 수 있다.

Claims

보안 관리 시스템에서 보안 컨트롤러가 모니터링하기 위한 방법에 있어서,
I2NSF(Interface to Network Security Functions) 사용자로부터 소비자 직면(Consumer-Facing) 인터페이스를 통해, 상위 레벨(High-Level)의 제1 보안 정책을 수신하며, 상기 제1 보안 정책은 상기 보안 관리 시스템에서 발생하는 특정 이벤트에서 트리거되는 정책을 포함함;
상기 제1 보안 정책을 하위 레벨(Low-Level)의 제2 보안 정책으로 번역하는 단계;
상기 제2 보안 정책을 NSF(Network Security Function)에게 설정하기 위한 상기 제2 보안 정책을 포함하는 패킷을 상기 NSF로 전송하는 단계; 및
상기 NSF로부터, NSF 직면(NSF-Facing) 인터페이스를 통해, 모니터링 데이터를 수신하는 단계;
를 포함하며,
상기 모니터링 데이터는 1) 상기 모니터링 데이터의 타입정보 및 2) 상기 NSF의 정보를 포함하는, 방법.
제1항에 있어서,
상기 타입정보는
알람, 경보, 이벤트, 로그 또는 카운터를 지시하는, 방법.
제2항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 알람을 지시하는 경우, 상기 보안 관리 시스템의 컴포넌트(component)와 관련된 알람정보를 더 포함하며,
상기 컴포넌트는 메모리, CPU, 디스크, 하드웨어 및 인터페이스를 포함하는, 방법.
제2항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 이벤트를 지시하는 경우, 상기 보안 관리 시스템과 관련된 이벤트 정보 또는 상기 NSF에서 감지되는 이벤트 정보를 더 포함하는, 방법.
제2항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 로그를 지시하는 경우, 상기 보안 관리 시스템과 관련된 로그 정보 또는 상기 NSF의 로그 정보를 더 포함하는, 방법.
제2항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 카운터를 지시하는 경우, 상기 보안 관리 시스템과 관련된 카운터 정보 또는 상기 NSF와 관련된 카운터 정보를 더 포함하는, 방법.
제4항에 있어서,
상기 NSF에서 감지되는 이벤트 정보는
상기 제1 보안 정책에 근거하여, 생성되는, 방법.
제2항에 있어서,
상기 I2NSF 사용자로 상기 모니터링 데이터를 전송하는 단계;
를 더 포함하는, 방법.
제8항에 있어서,
개발자 관리 시스템(Developer's Management System)으로 상기 모니터링 데이터를 전송하는 단계;
를 더 포함하는, 방법.
보안 관리 시스템에서 모니터링을 위한 보안 컨트롤러에 있어서,
송수신기;
상기 송수신기를 기능적으로 제어하는 프로세서;를 포함하며,
상기 프로세서는
I2NSF(Interface to Network Security Functions) 사용자로부터 소비자 직면(Consumer-Facing) 인터페이스를 통해, 상위 레벨(High-Level)의 제1 보안 정책을 수신하며, 상기 제1 보안 정책은 상기 보안 관리 시스템에서 발생하는 특정 이벤트에서 트리거되는 정책을 포함하고,
상기 제1 보안 정책을 하위 레벨(Low-Level)의 제2 보안 정책으로 번역하며,
상기 제2 보안 정책을 NSF(Network Security Function)에게 설정하기 위한 상기 제2 보안 정책을 포함하는 패킷을 상기 NSF로 전송하고,
상기 NSF로부터, NSF 직면(NSF-Facing) 인터페이스를 통해, 모니터링 데이터를 수신하며,
상기 모니터링 데이터는 1) 상기 모니터링 데이터의 타입정보 및 2) 상기 NSF의 정보를 포함하는, 장치.
제10항에 있어서,
상기 타입정보는
알람, 경보, 이벤트, 로그 또는 카운터를 지시하는, 장치.
제11항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 알람을 지시하는 경우, 상기 보안 관리 시스템의 컴포넌트(component)와 관련된 알람정보를 더 포함하며,
상기 컴포넌트는 메모리, CPU, 디스크, 하드웨어 및 인터페이스를 포함하는, 장치.
제11항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 이벤트를 지시하는 경우, 상기 보안 관리 시스템과 관련된 이벤트 정보 또는 상기 NSF에서 감지되는 이벤트 정보를 더 포함하는, 장치.
제11항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 로그를 지시하는 경우, 상기 보안 관리 시스템과 관련된 로그 정보 또는 상기 NSF의 로그 정보를 더 포함하는, 장치.
제11항에 있어서,
상기 모니터링 데이터는
상기 타입정보가 카운터를 지시하는 경우, 상기 보안 관리 시스템과 관련된 카운터 정보 또는 상기 NSF와 관련된 카운터 정보를 더 포함하는, 장치.
제13항에 있어서,
상기 NSF에서 감지되는 이벤트 정보는
상기 제1 보안 정책에 근거하여, 생성되는, 장치.
제11항에 있어서,
상기 프로세서는
상기 I2NSF 사용자로 상기 모니터링 데이터를 전송하는, 장치.
제17항에 있어서,
상기 프로세서는
개발자 관리 시스템(Developer's Management System)으로 상기 모니터링 데이터를 전송하는, 장치.