KR20240034858A - 방화벽에서의 iot 보안 정책 - Google Patents

방화벽에서의 iot 보안 정책 Download PDF

Info

Publication number
KR20240034858A
KR20240034858A KR1020247006784A KR20247006784A KR20240034858A KR 20240034858 A KR20240034858 A KR 20240034858A KR 1020247006784 A KR1020247006784 A KR 1020247006784A KR 20247006784 A KR20247006784 A KR 20247006784A KR 20240034858 A KR20240034858 A KR 20240034858A
Authority
KR
South Korea
Prior art keywords
iot
network
devices
security
data
Prior art date
Application number
KR1020247006784A
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
Priority claimed from US17/489,159 external-priority patent/US20220095092A1/en
Application filed by 팔로 알토 네트웍스, 인크. filed Critical 팔로 알토 네트웍스, 인크.
Publication of KR20240034858A publication Critical patent/KR20240034858A/ko

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577Assessing vulnerabilities and evaluating computer system security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12Detection or prevention of fraud
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16YINFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00IoT infrastructure
    • G16Y30/10Security thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/303Terminal profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30Security of mobile devices; Security of mobile applications
    • H04W12/37Managing security policies for mobile devices or for controlling mobile applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices

Landscapes

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

Abstract

사물 인터넷(IoT) 디바이스 통신들 상에서 정책들을 시행하기 위한 기법들이 개시된다. IoT 디바이스의 네트워크 통신과 연관된 정보가 수신된다. 수신된 정보는 디바이스 유형을 포함하여, IoT 디바이스와 연관시킬 디바이스 프로필을 결정하기 위해 사용된다. 보안 기기에 의해 IoT 디바이스에 적용될 추천 보안 정책이 생성된다.

Description

방화벽에서의 IOT 보안 정책
다른 출원들에 대한 상호 참조
본 출원은 2020년 6월 1일에 출원된 IOT 디바이스 탐색 및 식별이라는 제목의, 미국 가 특허 출원 번호 제63/033,004호에 대한 우선권을 주장하는, 2020년 12월 23일에 출원된 IOT 디바이스 탐색 및 식별이라는 제목의, 현재 미국 특허 번호 제11,115,799호인, 미국 특허 출원 번호 제17/133,189호의 계속 출원인, 2021년 7월 20일에 출원된 IOT 디바이스 탐색 및 식별이라는 제목의, 미국 특허 출원 번호 제17/381,103호의 부분 계속 출원이며, 그 각각은 모든 목적들을 위해 본원에서 참조로서 통합된다.
비도덕적인 개인들은 다양한 방식들로 컴퓨터 시스템들을 손상하려고 시도한다. 일 예로서, 이러한 개인들은 이메일 첨부파일에 악성 소프트웨어("멀웨어")를 끼워넣거나 또는 그 외 포함하며 멀웨어를 전송하거나 또는 그것을 의심하지 않는 사용자들에게 전송되게 할 수 있다. 실행될 때, 멀웨어는 희생자의 컴퓨터를 손상시키며 부가적인 비도덕적 태스크들(예컨대, 민감한 데이터를 유출하는 것, 다른 시스템들로 전파하는 것 등)을 수행할 수 있다. 다양한 접근법들이 이러한 및 다른 손상들에 대해 컴퓨터들을 강화시키기 위해 사용될 수있다. 불운하게도, 컴퓨터들을 보호하기 위한 기존의 접근법들이 모든 컴퓨팅 환경들에서 반드시 적절한 것은 아니다. 뿐만 아니라, 멀웨어 저작자들은 검출을 피하기 위해 그 기법들을 계속해서 적응시키며, 멀웨어를 검출하고 다양한 상황들에서 그 유해성을 방지하기 위해 개선된 기법들에 대해 계속되는 요구가 존재한다.
본 발명은 프로세스; 장치; 시스템; 물질의 조성; 컴퓨터 판독 가능한 저장 매체 상에 구현된 컴퓨터 프로그램 제품; 및/또는 프로세서에 결합된 메모리 상에 저장되고 및/또는 그것에 의해 제공된 지시들을 실행하도록 구성된 프로세서와 같은 프로세서로서를 포함하는, 다수의 방식들로 구현될 수 있다. 본 명세서에서, 이들 구현예들, 또는 본 발명이 취할 수 있는 임의의 다른 형태는 기법들로서 불리울 수 있다. 일반적으로, 개시된 프로세스들의 단계들의 순서는 본 발명의 범위 내에서 변경될 수 있다. 달리 서술되지 않는다면, 태스크를 수행하도록 구성되는 것으로 설명된 프로세서 또는 메모리와 같은 구성요소는 정해진 시간에 태스크를 수행하도록 임시로 구성되는 일반 구성요소 또는 태스크를 수행하기 위해 제조되는 특정 구성요소로서 구현될 수 있다. 본원에서 사용된 바와 같이, 용어 '프로세서'는 컴퓨터 프로그램 지시들과 같은, 데이터를 프로세싱하도록 구성된 하나 이상의 디바이스들, 회로들, 및/또는 프로세싱 코어들을 나타낸다.
본 발명의 하나 이상의 실시예들의 상세한 설명은 이하에서 본 발명의 원리들을 예시하는 수반된 도면들과 함께 제공된다. 본 발명은 이러한 실시예들과 관련되어 설명되지만, 본 발명은 임의의 실시예에 제한되지 않는다. 본 발명의 범위는 단지 청구항들에 의해서만 제한되며 본 발명은 다수의 대안들, 수정들 및 등가물들을 포함한다. 다수의 특정 세부사항들은 본 발명의 철저한 이해를 제공하기 위해 다음의 설명에서 제시된다. 이들 세부사항들은 예시의 목적을 위해 제공되며 본 발명은 이들 특정 세부사항들 중 일부 또는 모두 없이 청구항들에 따라 실시될 수 있다. 명료함을 위해, 본 발명에 관련된 기술 분야들에서 알려진 기술 자료는 본 발명이 불필요하게 모호해지지 않도록 상세하게 설명되지 않았다.
본 발명의 다양한 실시예들이 다음의 상세한 설명 및 수반된 도면들에서 개시된다.
도 1은 악의적인 활동이 검출되며 그 유해성이 감소된 환경의 예를 예시한다.
도 2a는 데이터 기기의 실시예를 예시한다.
도 2b는 데이터 기기의 실시예의 논리 구성요소들의 기능 다이어그램이다.
도 2c는 IoT 서버와 IoT 모듈 간의 예시적인 이벤트 경로를 예시한다.
도 2d는 디바이스 탐색 이벤트의 예를 예시한다.
도 2e는 세션 이벤트의 예를 예시한다.
도 2f는 IoT 모듈의 실시예를 예시한다.
도 2g는 IoT 디바이스 분석을 구현하는 예시적인 방식을 예시한다.
도 3은 네트워크에서 IoT 디바이스에 대한 AAA 지원을 수동적으로 제공하기 위한 프로세스의 실시예를 예시한다.
도 4a 내지 도 4c는 다양한 실시예들에서 IoT 서버에 의해 IoT 디바이스를 대신하여 AAA 서버로 송신된 RADIUS 메시지들의 예들을 예시한다.
도 5는 IoT 모듈의 실시예를 예시한다.
도 6은 IoT 디바이스를 분류하기 위한 프로세스의 예를 예시한다.
도 7a 및 도 7b는 예시적인 방화벽 규칙들을 예시한다.
도 8 내지 도 10은 예시적인 인터페이스들의 부분들을 예시한다.
도 11은 IoT 디바이스를 수반한 통신에 적용할 정책을 생성하기 위한 프로세스의 예를 예시한다.
I. 개요
방화벽은 일반적으로 인가된 통신들이 방화벽을 통과하는 것을 허용하는 동안 인가되지 않은 액세스로부터 네트워크들을 보호한다. 방화벽은 통상적으로 네트워크 액세스를 위한 방화벽 기능을 제공하는 디바이스, 디바이스들의 세트, 또는 디바이스 상에서 실행된 소프트웨어이다. 예를 들어, 방화벽은 디바이스들(예컨대, 컴퓨터들, 스마트폰들, 또는 다른 유형들의 네트워크 통신 가능 디바이스들)의 운영 시스템들로 통합될 수 있다. 방화벽은 또한 컴퓨터 서버들, 게이트웨이들, 네트워크/라우팅 디바이스들(예컨대, 네트워크 라우터들), 및 데이터 기기들(예컨대, 보안 기기들 또는 다른 유형들의 특수 목적 디바이스들)과 같은, 다양한 유형들의 디바이스들 상에서 하나 이상의 소프트웨어 애플리케이션들로 통합되거나 또는 그것으로서 실행될 수 있으며, 다양한 구현예들에서, 특정한 동작들이 ASIC 또는 FPGA와 같은, 특수 목적 하드웨어에서 구현될 수 있다.
방화벽들은 통상적으로 규칙들의 세트에 기초하여 네트워크 전송을 거부하거나 또는 허용한다. 이들 규칙들의 세트들은 종종 정책들(예컨대, 네트워크 정책들 또는 네트워크 보안 정책들)로 불리운다. 예를 들어, 방화벽은 원치않는 바깥 트래픽이 보호된 디바이스들에 이르는 것을 방지하기 위해 규칙들의 세트 또는 정책들을 이용함으로써 인바운드 트래픽을 필터링할 수 있다. 방화벽은 또한 규칙들의 세트 또는 정책들을 이용함으로써 아웃바운드 트래픽을 필터링할 수 있다(예컨대, 허용, 차단, 모니터, 통지 또는 로그, 및/또는 다른 동작들이 방화벽 규칙들 또는 방화벽 정책들에서 특정될 수 있으며, 이는 본원에서 설명되는 바와 같은, 다양한 기준들에 기초하여 트리거될 수 있다). 방화벽은 또한 규칙들의 세트 또는 정책들을 유사하게 이용함으로써 국소 네트워크(예컨대, 인트라넷) 트래픽을 필터링할 수 있다.
보안 디바이스들(예컨대, 보안 기기들, 보안 게이트웨이들, 보안 서비스들, 및/또는 다른 보안 디바이스들)은 다양한 보안 기능들(예컨대, 방화벽, 멀웨어-방지, 침입 방지/검출, 데이터 손실 방지(DLP), 및/또는 다른 보안 기능들), 네트워킹 기능들(예컨대, 라우팅, 서비스 품질(Quality of Service; QoS), 네트워크 관련 리소스들의 작업부하 균형, 및/또는 다른 네트워킹 기능들), 및/또는 다른 기능들을 포함할 수 있다. 예를 들어, 라우팅 기능들은 소스 정보(예컨대, IP 어드레스 및 포트), 목적지 정보(예컨대, IP 어드레스 및 포트), 및 프로토콜 정보에 기초할 수 있다.
기본 패킷 필터링 방화벽은 네트워크를 통해 전송된 개개의 패킷들을 검사함으로써 네트워크 통신 트래픽을 필터링한다(예컨대, 패킷 필터링 방화벽들 또는 1세대 방화벽들, 이들은 무상태(stateless) 패킷 필터링 방화벽들임). 무상태 패킷 필터링 방화벽들은 통상적으로 개개의 패킷들 자체를 검사하며 검사된 패킷들에 기초하여(예컨대, 패킷의 소스 및 목적지 어드레스 정보, 프로토콜 정보, 및 포트 번호의 조합을 사용하여) 규칙들을 적용한다.
애플리케이션 방화벽들은 또한 애플리케이션 계층 필터링(예컨대, 애플리케이션 계층 필터링 방화벽들 또는 2세대 방화벽들, 이들은 TCP/IP 스택의 애플리케이션 레벨 상에서 작동함)을 수행할 수 있다. 애플리케이션 계층 필터링 방화벽들 또는 애플리케이션 방화벽들은 일반적으로 특정한 애플리케이션들 및 프로토콜들(예컨대, 하이퍼텍스트 전송 프로토콜(HTTP)을 사용한 웹 브라우징, 도메인 이름 시스템(DNS) 요청, 파일 전송 프로토콜(FTP)을 사용한 파일 전송, 및 Telnet, DHCP, TCP, UDP, 및 TFTP(GSS)와 같은 다양한 다른 유형들의 애플리케이션들 및 다른 프로토콜들)을 식별할 수 있다. 예를 들어, 애플리케이션 방화벽들은 표준 포트를 통해 통신하려고 시도하는 인가되지 않은 프로토콜들을 차단할 수 있다(예컨대, 상기 프로토콜에 대한 비-표준 포트를 사용함으로써 몰래 빠져나가려고 시도하는 인가되지 않은/정책 외 프로토콜이 일반적으로 애플리케이션 방화벽들을 사용함으로써 식별될 수 있다).
상태 유지(stateful) 방화벽들은 또한 각각의 패킷이, 패킷들의 상기 네트워크 전송의 흐름과 연관된 일련의 패킷들의 콘텍스트 내에서 조사되는 상태-기반 패킷 검사를 수행할 수 있다. 이러한 방화벽 기법은 일반적으로 그것이 방화벽을 통과하는 모든 연결들의 레코드들을 유지함에 따라 상태 유지 패킷 검사로서 불리우며 패킷이 새로운 연결의 시작, 기존의 연결의 부분, 또는 유효하지 않은 패킷인지를 결정할 수 있다. 예를 들어, 연결의 상태는 그 자체가 정책 내에서 규칙을 트리거하는 기준 중 하나일 수 있다.
고급 또는 차세대 방화벽들(advanced or next generation firewalls)은 상기 논의된 바와 같이 무상태 및 상태 유지 패킷 필터링 및 애플리케이션 계층 필터링을 수행할 수 있다. 차세대 방화벽들은 또한 부가적인 방화벽 기법들을 수행할 수 있다. 예를 들어, 때때로 고급 또는 차세대 방화벽들로서 불리우는 특정한 더 새로운 방화벽들은 또한 사용자들 및 콘텐트(예컨대, 차세대 방화벽들)를 식별할 수 있다. 특히, 특정한 차세대 방화벽들은 이들 방화벽들이 자동으로 식별할 수 있는 애플리케이션들의 리스트를 수 천개의 애플리케이션들까지 확대시킨다. 이러한 차세대 방화벽들의 예들은 Palo Alto Networks, Inc.로부터 상업적으로 이용 가능하다(예컨대, Palo Alto Network의 PA 시리즈 방화벽들). 예를 들어, Palo Alto Network의 차세대 방화벽들은 기업들이 다음과 같은, 다양한 식별 기술들을 사용하여 포트들, IP 어드레스들, 및 패킷들이 아닌, 애플리케이션들, 사용자들, 및 콘텐트를 식별하고 제어할 수 있게 한다: 정확한 애플리케이션 식별을 위한 APP-ID, 사용자 식별을 위한 User-ID(예컨대, 사용자 또는 사용자 그룹에 의한), 실시간 콘텐트 스캐닝을 위한 Content-ID(예컨대, 웹 서핑을 제어하고 데이터 및 파일 전송들을 제한함), 및 Device-ID(예컨대, IoT 디바이스 유형 식별을 위한). 이들 식별 기술들은 기업들이 종래의 포트-차단 방화벽들에 의해 제공된 종래의 접근법을 따르는 대신에, 비즈니스-관련 개념들을 사용하여 애플리케이션 사용을 안전하게 가능화하는 것을 허용한다. 또한, 차세대 방화벽들을 위한 특수 목적 하드웨어(예를 들어, 전용 기기들로서 구현됨)는 일반적으로 범용 하드웨어 상에서 실행되는 소프트웨어보다 애플리케이션 검사를 위한 더 높은 성능 레벨들을 제공한다(예컨대, 대기시간을 최소화하면서 네트워크 스루풋을 최대화하기 위해 단일-패스 소프트웨어 엔진과 긴밀하게 통합되는 전용, 기능 특정 프로세싱을 사용하는 Palo Alto Networks, Inc.에 의해 제공되는 보안 기기들과 같은).
고급 또는 차세대 방화벽들은 또한 가상화 방화벽들을 사용하여 구현될 수 있다. 이러한 차세대 방화벽들의 예들은 Palo Alto Networks, Inc.로부터 상업적으로 이용 가능하다(예컨대, 예를 들어, VMware® ESXi™ 및 NSX™, Citrix® Netscaler SDX™, KVM/OpenStack(Centos/RHEL Ubuntu®), 및 Amazon Web Services(AWS)를 포함한, 다양한 상업용 가상화 환경을 지원하는, Palo Alto Network의 VM 시리즈 방화벽들). 예를 들어, 가상화 방화벽들은 물리적 형태 인자 기기들에서 이용 가능한 유사한 또는 정확하게 동일한 차-세대 방화벽 및 고급 위협 방지 기능들을 지원하여, 기업들로 하여금 그들의 개인, 공개, 및 하이브리드 클라우드 컴퓨팅 환경들로, 및 그것에 걸쳐 흐르는 애플리케이션들을 안전하게 가능화하는 것을 허용한다. VM 모니터링, 동적 어드레스 그룹들, 및 REST-기반 API와 같은 자동화 기능들은 기업들로 하여금 상기 콘텍스트를 보안 정책들에 동적으로 공급하는 VM 변화들을 적극적으로 모니터링하도록 허용하며, 그에 의해 VM들이 변화할 때 발생할 수 있는 정책 래그를 제거한다.
II. 예시적인 환경
도 1은 악의적인 활동이 검출되고 그 유해성이 감소된 환경의 예를 예시한다. 도 1에 도시된 예에서, 클라이언트 디바이스들(104 내지 108)은 병원(또한, "Acme Hospital"로 불리움)의 기업 네트워크(110)에 존재하는 랩탑 컴퓨터, 데스크탑 컴퓨터, 및 태블릿(각각)이다. 데이터 기기(102)는 클라이언트 디바이스들(104 및 106)과 같은 클라이언트 디바이스들, 및 기업 네트워크(110)의 바깥쪽에 있는(예컨대, 외부 네트워크(118)를 통해 도달 가능한) 노드들 간의 통신들에 관한 정책들을 시행하도록 구성된다.
이러한 정책들의 예들은 트래픽 쉐이핑, 서비스 품질, 및 트래픽의 라우팅을 통제하는 것들을 포함한다. 정책들의 다른 예들은 인입(및/또는 송출) 이메일 첨부파일, 웹사이트 콘텐트, 인스턴트 메시징 프로그램들을 통해 교환된 파일들, 및/또는 다른 파일 전달들에서 위협들에 대한 스캐닝을 요구하는 것들과 같은 보안 정책들을 포함한다. 몇몇 실시예들에서, 데이터 기기(102)는 또한 기업 네트워크(110) 내에 머물러 있는 트래픽에 대한 정책들을 시행하도록 구성된다.
네트워크(110)는 또한 디렉토리 서비스(154) 및 인증, 인가, 및 과금(Authentication, Authorization, 및 Accounting; AAA) 서버(156)를 포함한다. 도 1에 도시된 예에서, 디렉토리 서비스(154)(또한 아이덴티티 제공자 또는 도메인 제어기로서 불리움)는 경량 디렉토리 액세스 프로토콜(Lightweight Directory Access Protocol; LDAP) 또는 다른 적절한 프로토콜들을 이용한다. 디렉토리 서비스(154)는 사용자 아이덴티티 및 크리덴셜 정보를 관리하도록 구성된다. 디렉토리 서비스(154)의 일 예는 마이크로소프트 액티브 디렉토리 서버이다. Kerberos-기반 시스템, 및 그에 따라 적응된 본원에서 설명된 기법들과 같은, 다른 유형들의 시스템들이 또한 액티브 디렉토리 서버를 대신하여 사용될 수 있다. 도 1에 도시된 예에서, AAA 서버(156)는 네트워크 허가 제어(network admission control; NAC) 서버이다. AAA 서버(156)는 네트워크에 대해 유선, 무선, 및 VPN 사용자들 및 디바이스들을 인증하고, 네트워크로의 액세스를 허가하기 전에 정책 준수를 위한 디바이스를 평가하며 교정하고, 규칙들에 기초하여 액세스를 구별하며, 그 후 누가 네트워크 상에 있는지를 감사하고 보고하도록 구성된다. AAA 서버(156)의 일 예는 원격 인증 다이얼-인 사용자 서비스(Remote Authentication Dial-In User Service; RADIUS)를 이용하는 시스코 아이덴티티 서비스 엔진(ISE) 서버이다. RADIUS가 아닌 프로토콜들을 사용하는 것들을 포함하여, 다른 유형들의 AAA 서버들이 본원에서 설명된 기법들과 함께 사용될 수 있다.
다양한 실시예들에서, 데이터 기기(102)는 디렉토리 서비스(154) 및/또는 AAA 서버(156)로/로부터의 통신들을 청취(예컨대, 메시지들을 수동적으로 모니터링함)하도록 구성된다. 다양한 실시예들에서, 데이터 기기(102)는 디렉토리 서비스(154) 및/또는 AAA 서버(156)와 통신하도록(즉, 그것과 메시지들을 활발히 통신하도록) 구성된다. 다양한 실시예들에서, 데이터 기기(102)는 디렉토리 서비스(154) 및/또는 AAA 서버(156)와 같은 다양한 네트워크 요소들과 통신하는(예컨대, 그것과 메시지들을 활발히 통신하는) 오케스트레이터(묘사되지 않음)와 통신하도록 구성된다. 다른 유형들의 서버들이 또한 네트워크(110)에 포함될 수 있고 적용 가능하다면 데이터 기기(102)와 통신할 수 있으며, 디렉토리 서비스(154) 및/또는 AAA 서버(156)는 또한 다양한 실시예들에서 네트워크(110)로부터 생략될 수 있다.
도 1에서 단일 데이터 기기(102)를 갖는 것으로 묘사되지만, 주어진 네트워크 환경(예컨대, 네트워크(110))은 개별적으로 또는 협력하여 동작하는지에 관계없이, 데이터 기기들의 다수의 실시예들을 포함할 수 있다. 유사하게, 용어 "네트워크"는 일반적으로 본원에서 단순성을 위해 단수형으로(예컨대, "네트워크(110)"로서) 언급되지만, 본원에서 설명된 기법들은 적용 가능한 경우, 다양한 네트워크 계층들에 걸쳐 다양한 네트워킹 프로토콜들(예컨대, TCP 및 UDP 및 기반시설(예컨대, 스위치들 및 라우터들)을 사용하여, 네트워킹 기술들(예컨대, 가상 및 물리)의 다양한 혼합들을 포함한, 다양한 크기들 및 토폴로지들의 다양한 네트워크 환경들에 배치될 수 있다.
데이터 기기(102)는 원격 보안 플랫폼(140)과 협력하여 작동하도록 구성될 수 있다. 보안 플랫폼(140)은, 멀웨어 샘플들에 대한 정적 및 동적 분석을 수행하는 것(예컨대, 샘플 분석 모듈(124)을 통해), 및 알려진-악성 파일들, 도메인들 등의 서명들의 리스트를, 구독의 부분으로서 데이터 기기(102)와 같은, 데이터 기기들로 제공하는 것을 포함하는, 다양한 서비스들을 제공할 수 있다. 이하에서 더 상세하게 설명될 바와 같이, 보안 플랫폼(140)은 또한 네트워크(110)와 같은 네트워크 내에 존재하는 IoT 디바이스들의 탐색, 분류, 관리 등과 연관된 정보를 제공할 수 있다(예컨대, IoT 모듈(138)을 통해). 다양한 실시예들에서, 서명들, 분석의 결과들, 및/또는 부가적인 정보(예컨대, 샘플들, 애플리케이션들, 도메인들 등에 에 관계된)가 데이터베이스(160)에 저장된다. 다양한 실시예들에서, 보안 플랫폼(140)은 통상적인 서버-클래스 운영 시스템들(예컨대, 리눅스)을 실행하는 하나 이상의 전용 상업적으로 이용 가능한 하드웨어 서버들(예컨대, 멀티-코어 프로세서(들), 32G+의 RAM, 기가비트 네트워크 인터페이스 어댑터(들), 및 하드 드라이브(들)를 가진)을 포함한다. 보안 플랫폼(140)은 다수의 이러한 서버들, 고체 상태 드라이브들 또는 다른 저장장치(158), 및/또는 다른 적용 가능한 고-성능 하드웨어를 포함한 확장 가능한 기반시설에 걸쳐 구현될 수 있다. 보안 플랫폼(140)은 하나 이상의 제3 자에 의해 제공되는 구성요소들을 포함한, 여러 분산형 구성요소들을 포함할 수 있다. 예를 들어, 보안 플랫폼(140)의 부분들 또는 모두는 Amazon Elastic Compute Cloud(EC2) 및/또는 Amazon Simple Storage Service(S3)를 사용하여 구현될 수 있다. 뿐만 아니라, 데이터 기기(102)와 마찬가지로, 보안 플랫폼(140)이 데이터를 저장하는 것 또는 데이터를 프로세싱하는 것과 같은, 태스크를 수행하는 것으로 언급될 때마다, 보안 플랫폼(140)의 서브-구성요소 또는 다수의 서브-구성요소들(개별적으로 또는 제3 자 구성요소들과 협력하는지에 관계없이)이 상기 태스크를 수행하기 위해 협력할 수 있다는 것이 이해될 것이다. 예들로서, 보안 플랫폼(140)은 하나 이상의 가상 기계(VM) 서버들과 협력하여 정적/동적 분석(예컨대, 샘플 분석 모듈(124)을 통해) 및/또는 IoT 디바이스 기능(예컨대, IoT 모듈(138)을 통해)을 수행할 수 있다. 가상 기계 서버의 예는 VMware ESXi, Citrix XenServer, 또는 Microsoft Hyper-V와 같은, 상업적으로 이용 가능한 가상화 소프트웨어를 실행하는 상업적으로 이용 가능한 서버-클래스 하드웨어(예컨대, 멀티-코어 프로세서, 32+ 기가바이트의 RAM, 및 하나 이상의 기가비트 네트워크 인터페이스 어댑터들)를 포함한 물리 기계이다. 몇몇 실시예들에서, 가상 기계 서버는 생략된다. 뿐만 아니라, 가상 기계 서버는 보안 플랫폼(140)을 관리하는 동일한 엔티티의 제어 하에 있을 수 있지만, 또한 제3 자에 의해 제공될 수 있다. 일 예로서, 가상 기계 서버는, 보안 플랫폼(140)의 나머지 부분들이 보안 플랫폼(140)의 조작자에 의해 소유되고 그것의 제어 하에 있는 전용 하드웨어에 의해 제공되는, EC2에 의존할 수 있다.
데이터 기기의 실시예가 도 2a에 도시된다. 도시된 예는 다양한 실시예들에서, 데이터 기기(102)에 포함되는 물리 구성요소들의 표현이다. 구체적으로, 데이터 기기(102)는 고성능 멀티-코어 중앙 프로세싱 유닛(CPU)(202) 및 랜덤 액세스 메모리(RAM)(204)를 포함한다. 데이터 기기(102)는 또한 저장장치(210)(하나 이상의 하드 디스크들 또는 고체 상태 저장 유닛들과 같은)를 포함한다. 다양한 실시예들에서, 데이터 기기(102)는 기업 네트워크(110)를 모니터링하고 개시된 기법들을 구현하는데 사용된 정보를 저장한다(RAM(204), 저장장치(210), 및/또는 다른 적적절한 위치들에 관계없이). 이러한 정보의 예들은 애플리케이션 식별자들, 콘텐트 식별자들, 사용자 식별자들, 요청 URL들, IP 어드레스 매핑들, 정책 및 다른 구성 정보, 서명들, 호스트명/URL 카테고리화 정보, 멀웨어 프로필들, 기계 학습 모델들, IoT 디바이스 분류 정보 등을 포함한다. 데이터 기기(102)는 또한 하나 이상의 선택적 하드웨어 가속기들을 포함할 수 있다. 예를 들어, 데이터 기기(102)는 암호화 및 복호화 동작들을 수행하도록 구성된 암호 엔진(206), 및 매칭을 수행하고, 네트워크 프로세서들로서 동작하며, 및/또는 다른 태스크들을 수행하도록 구성된 하나 이상의 필드 프로그램 가능한 게이트 어레이들(FPGA들)(208)을 포함할 수 있다.
본원에서 데이터 기기(102)에 의해 수행되는 것으로 설명된 기능은 다양한 방식들로 제공/구현될 수 있다. 예를 들어, 데이터 기기(102)는 전용 디바이스 또는 디바이스들의 세트일 수 있다. 주어진 네트워크 환경은 다수의 데이터 기기들을 포함할 수 있으며, 그 각각은 네트워크의 특정한 부분 또는 부분들로 서비스들을 제공하도록 구성될 수 있고, 네트워크의 특정한 부분 또는 부분들로 서비스들을 제공하도록 협력할 수 있다. 데이터 기기(102)에 의해 제공된 기능은 또한 범용 컴퓨터, 컴퓨터 서버, 게이트웨이, 및/또는 네트워크/라우팅 디바이스 상에서 소프트웨어로 통합되거나 또는 그것으로서 실행될 수 있다. 몇몇 실시예들에서, 데이터 기기(102)에 의해 제공되는 것으로 설명된 적어도 몇몇 기능은 대신에(또는 추가적으로) 클라이언트 디바이스 상에서 실행하는 소프트웨어에 의해 클라이언트 디바이스(예컨대, 클라이언트 디바이스(104) 또는 클라이언트 디바이스(106))로 제공된다. 본원에서 데이터 기기(102)에 의해 수행되는 것으로 설명된 기능은 또한 적어도 부분적으로 보안 플랫폼(140)에 의해 또는 그것과 협력하여 수행될 수 있으며, 및/또는 본원에서 보안 플랫폼(140)에 의해 수행되는 것으로 설명된 기능은 또한 적용 가능한 경우, 적어도 부분적으로 데이터 기기(102)에 의해 또는 그것과 협력하여 수행될 수 있다. 일 예로서, IoT 모듈(138)에 의해 수행되는 것으로 설명된 다양한 기능은 IoT 서버(134)의 실시예들에 의해 수행될 수 있다.
데이터 기기(102)가 태스크를 수행하는 것으로 설명될 때마다, 데이터 기기(102)의 단일 구성요소, 구성요소들의 서브세트, 또는 모든 구성요소들은 태스크를 수행하기 위해 협력할 수 있다. 유사하게, 데이터 기기(102)의 구성요소가 태스크를 수행하는 것으로 설명될 때마다, 서브구성요소는 태스크를 수행할 수 있으며 및/또는 구성요소는 다른 구성요소들과 함께 태스크를 수행할 수 있다. 다양한 실시예들에서, 데이터 기기(102)의 부분들은 하나 이상의 제3 자들에 의해 제공된다. 데이터 기기(102)에 이용 가능한 컴퓨팅 리소스들의 양과 같은 인자들에 의존하여, 데이터 기기(102)의 다양한 논리 구성요소들 및/또는 특징들이 생략될 수 있으며 본원에서 설명된 기법들이 그에 따라 적응된다. 유사하게, 부가적인 논리 구성요소들/특징들이 적용 가능한 경우 데이터 기기(102)의 실시예들에 포함될 수 있다. 다양한 실시예들에서 데이터 기기(102)에 포함된 구성요소의 일 예는 애플리케이션을 식별하도록(예컨대, 패킷 흐름 분석에 기초하여 애플리케이션들을 식별하기 위한 다양한 애플리케이션 서명들을 사용하여) 구성되는 애플리케이션 식별 엔진이다. 예를 들어, 애플리케이션 식별 엔진은 웹 브라우징 - 소셜 네트워킹; 웹 브라우징 - 뉴스; SSH; 등과 같은, 세션이 어떤 유형의 트래픽을 수반하는지를 결정할 수 있다. 다양한 실시예들에서 데이터 기기(102)에 포함된 구성요소의 또 다른 예는 이하에서 더 상세하게 설명되는, IoT 서버(134)이다. IoT 서버(134)는, 물리적인지 또는 가상화된 것인지에 관계없이, 독립형 서버(또는 서버들의 세트)로서를 포함하는, 다양한 형태들을 취할 수 있으며, 또한 적용 가능한 경우 데이터 기기(102)와 같은 장소에 배치되고/그것으로 통합될 수 있다(예컨대, 도 1에 도시된 바와 같이).
도 2b는 데이터 기기의 실시예의 논리 구성요소들의 기능 다이어그램이다. 도시된 예는 다양한 실시예들에서 데이터 기기(102)에 포함될 수 있는 논리 구성요소들의 표현이다. 달리 특정되지 않는다면, 데이터 기기(102)의 다양한 논리 구성요소들은 일반적으로, 하나 이상의 스크립트들(예컨대, 적용 가능한 경우, Java, python 등으로 기록된)의 세트로서를 포함하여, 다양한 방식들로 구현 가능하다.
도시된 바와 같이, 데이터 기기(102)는 방화벽을 포함하며, 관리 평면(212) 및 데이터 평면(214)을 포함한다. 관리 평면은, 이를테면 정책들을 구성하고 로그 데이터를 보기 위한 사용자 인터페이스를 제공함으로써, 사용자 상호작용들을 관리할 책임이 있다. 데이터 평면은, 이를테면 패킷 프로세싱 및 세션 핸들링을 수행함으로써, 데이터를 관리할 책임이 있다.
네트워크 프로세서(216)는 클라이언트 디바이스(108)와 같은, 클라이언트 디바이스들로부터 패킷들을 수신하며, 그것들을 프로세싱을 위해 데이터 평면(214)으로 제공하도록 구성된다. 흐름 모듈(218)이 패킷을 새로운 세션의 부분인 것으로 식별할 때마다, 그것은 새로운 세션 흐름을 생성한다. 후속 패킷들은 흐름 색인에 기초하여 세션에 속하는 것으로 식별될 것이다. 적용 가능한 경우, SSL 복호화가 SSL 복호화 엔진(220)에 의해 적용된다. 그렇지 않다면, SSL 복호화 엔진(220)에 의한 프로세싱은 생략된다. 복호화 엔진(220)은 데이터 기기(102)가 SSL/TLS 및 SSH 암호화 트래픽을 검사하고 제어하는 것을 도우며, 따라서 그 외 암호화 트래픽에 숨은 채로 있을 수 있는 위협들을 멈추도록 도울 수 있다. 복호화 엔진(220)은 또한 민감 콘텐트가 기업 네트워크(110)를 떠나는 것을 방지하도록 도울 수 있다. 복호화는 URL 카테고리, 트래픽 소스, 트래픽 목적지, 사용자, 사용자 그룹, 및 포트와 같은 파라미터들에 기초하여 선택적으로 제어(예컨대, 가능화 또는 불능화)될 수 있다. 복호화 정책들(어떤 세션들을 복호화할지를 특정하는) 외에, 복호화 프로필들이 정책에 의해 제어된 세션들에 대한 다양한 옵션들을 제어하기 위해 할당될 수 있다. 예를 들어, 특정 암호화 스위트(cipher suite)들 및 암호화 프로토콜 버전들의 사용이 요구될 수 있다.
애플리케이션 식별(APP-ID) 엔진(222)은 세션이 어떤 유형의 트래픽을 수반하는지를 결정하도록 구성된다. 일 예로서, 애플리케이션 식별 엔진(222)은 수신된 데이터에서 GET 요청을 인식하고 세션이 HTTP 디코더를 요구한다고 결론내릴 수 있다. 몇몇 경우들, 예컨대 웹 브라우징 세션에서, 식별된 애플리케이션이 변할 수 있으며 이러한 변화들은 데이터 기기(102)에 의해 주목될 것이다. 예를 들어, 사용자는 처음에 기업 Wiki로 브라우징하며("웹 브라우징 - 생산성"으로서 방문된 URL에 기초하여 분류됨) 그 후 그 다음에 소셜 네트워킹 사이트로 브라우징할 수 있다("웹 브라우징 - 소셜 네트워킹"으로 방문된 URL에 기초하여 분류됨). 상이한 유형들의 프로토콜들이 대응하는 디코더들을 가진다.
애플리케이션 식별 엔진(222)에 의해 이루어진 결정에 기초하여, 패킷들은 위협 엔진(224)에 의해, 정확한 순서로 패킷들(순서 외로 수신될 수 있는)을 모으고, 토큰화를 수행하며 정보를 추출하도록 구성된 적절한 디코더로 보내어진다. 위협 엔진(224)은 또한 패킷에 무엇이 일어나야 하는지를 결정하기 위해 서명 매칭을 수행한다. 요구된 대로, SSL 암호화 엔진(226)이 복호화된 데이터를 재암호화할 수 있다. 패킷들은 전송(예컨대, 목적지로)을 위해 포워드 모듈(228)을 사용하여 포워딩된다.
도 2b에 또한 도시된 바와 같이, 정책들(232)이 수신되며 관리 평면(212)에 저장된다. 정책들은 도메인 및/또는 호스트/서버 명들을 사용하여 특정될 수 있는, 하나 이상의 규칙들을 포함할 수 있으며, 규칙들은 이를테면, 모니터링된 세션 트래픽 흐름들로부터의 다양한 추출된 파라미터들/정보에 기초하여 가입자/IP 흐름들에 대한 보안 정책 시행을 위해, 하나 이상의 서명들 또는 다른 매칭 기준들 또는 휴리스틱을 이용할 수 있다. 인터페이스(I/F) 통신기(230)가 관리 통신들을 위해 제공된다(예컨대, (REST) API들, 메시지들, 또는 네트워크 프로토콜 통신들 또는 다른 통신 메커니즘들을 통해). 정책들(232)은 또한 IoT 디바이스들을 수반한 통신들을 관리하기 위한 정책들을 포함할 수 있다.
III. IOT 디바이스 탐색 및 식별
도 1로 돌아가면, 악의적인 개인(예컨대, 시스템(120)을 사용하는)이 멀웨어(130)를 생성하였다고 가정하자. 악의적인 개인은 취약한 클라이언트 디바이스들이 멀웨어(130)의 사본을 실행하여, 클라이언트 디바이스를 손상시키고 클라이언트 디바이스가 봇넷에서 봇이 되게 하기를 희망한다. 손상된 클라이언트 디바이스는 그 후 태스크들을 수행하고(예컨대, 암호 화폐 채굴, 서비스 공격들의 부정에 참여하는 것, 및 다른 취약한 클라이언트 디바이스들로 전파하는 것) 정보를 보고하거나 또는 그 외 데이터를 외부 엔티티(예컨대, 명령 및 제어(C&C) 서버(150))로 유출할 뿐만 아니라, 적용 가능한 경우 C&C 서버(150)로부터 지시들을 수신하도록 지시받을 수 있다.
도 1에 묘사된 몇몇 클라이언트 디바이스들은 기업 조직 내에서 통상적으로 사용되는 상용 컴퓨팅 디바이스들이다. 예를 들어, 클라이언트 디바이스들(104, 106, 및 108)은 각각 통상적인 운영 시스템들(예컨대, macOS, Windows, Linux, Android 등)을 실행한다. 이러한 상용 컴퓨팅 디바이스들은 종종 관리자들에 의해 공급되고 유지되며(예컨대, 각각 회사-발행 랩탑들, 데스크탑들, 및 태블릿들로서) 종종 사용자 계정들(예컨대, 사용자 아이덴티티 및 크리덴셜 정보를 갖고 구성된 디렉토리 서비스 제공자(또한 도메인 제어기로서 불리움)에 의해 관리됨)과 함께 동작된다. 일 예로서, 직원 앨리스(Alice)는 그녀가 ACME-관련 이메일을 액세스하고 다양한 ACME-관련 태스크들을 수행하기 위해 사용하는 랩탑(104)을 발행받을 수 있다. 다른 유형들의 클라이언트 디바이스들(본원에서 일반적으로 사물 인터넷 또는 IoT 디바이스들로서 불리움)이 또한 점점 더 네트워크들에서 존재하며 종종 IT 부서에 의해 "미관리"된다. 몇몇 이러한 디바이스들(예컨대, 원격회의 디바이스들)이 다양한 상이한 유형들의 기업들에 걸쳐 발견될 수 있다(예컨대, IoT 화이트보드들(144 및 146)로서). 이러한 디바이스들은 또한 수직 특정적일 수 있다. 예를 들어, 주입 펌프들 및 컴퓨터 단층촬영 스캐너들(예컨대, CT 스캐너(112))이 의료 기업 네트워크(예컨대, 네트워크(110)) 내에서 발견될 수 있는 IoT 디바이스들의 예들이며, 로봇 팔들은 제조 기업 네트워크에서 발견될 수 있는 디바이스들의 예이다. 뿐만 아니라, 소비자-지향 IoT 디바이스들(예컨대, 카메라들)이 또한 기업 네트워크에서 존재할 수 있다. 상용 컴퓨팅 디바이스들과 마찬가지로, 네트워크 내에 존재하는 IoT 디바이스들은 이러한 네트워크들의 내부 또는 외부 양쪽 모두에 있는(적용 가능한 경우, 둘 모두) 리소스들과 통신할 수 있다.
상용 컴퓨팅 디바이스들과 마찬가지로, IoT 디바이스들은 비도덕적인 개인들의 타겟이다. 불운하게도, 네트워크에서 IoT 디바이스들의 존재는 여러 고유 보안/관리 도전들을 제기한다. IoT 디바이스들은 종종 저-전력 디바이스들 또는 특수 목적 디바이스들이며 종종 네트워크 관리자들의 지식 없이 배치된다. 이러한 관리자들에게 알려진 경우에도, IoT 디바이스들에 엔드포인트 보호 소프트웨어 또는 에이전트들을 설치하는 것은 가능하지 않을 수 있다. IoT 디바이스들은 독점(또는 그 외 비-표준) 프로토콜들을 사용하여 제3 자 클라우드 기반시설에 의해 관리되며 그것과(예컨대, 클라우드 기반시설(126)과 직접 통신하는 산업용 온도계(152)와) 단독으로/직접 통신할 수 있다. 이는 위협 또는 공격이 디바이스에 대해 일어날 때에 대한 판단들을 하기 위해 이러한 디바이스들에서 또는 그 밖에 있는 네트워크 트래픽을 모니터링하려는 시도들을 혼동할 수 있다. 뿐만 아니라, 몇몇 IoT 디바이스들(예컨대, 의료 환경에서)은 미션 크리티컬이다(예컨대, 네트워크 연결 수술 시스템). 불운하게도, IoT 디바이스의 손상(예컨대, 멀웨어(130)에 의한) 또는 IoT 디바이스와 연관된 트래픽에 대한 보안 정책들의 오용은 잠재적으로 치명적인 영향을 줄 수 있다. 본원에서 설명된 기법들을 사용하여, IoT 디바이스들을 포함하는 이종 네트워크들의 보안이 개선될 수 있으며 이러한 네트워크에 제기된 유해성들이 감소될 수 있다.
다양한 실시예들에서, 데이터 기기(102)는 IoT 서버(134)를 포함한다. IoT 서버(134)는 몇몇 실시예들에서, 보안 플랫폼(140)의 IoT 모듈(138)과 협력하여, 네트워크(예컨대, 네트워크(110)) 내에서 IoT 디바이스들을 식별하도록 구성된다. 이러한 식별은 예컨대, 데이터 기기(102)에 의해, IoT 디바이스들과 연관된 트래픽에 관한 정책들을 만들고 시행하도록 돕기 위해, 및 네트워크(110)의 다른 요소들의 기능(예컨대, 콘텍스트 정보를 AAA(156)로 제공하는)을 시행하기 위해 사용될 수 있다. 다양한 실시예들에서, IoT 서버(134)는 트래픽을 수동적으로 캐내고/모니터링하도록 구성된 하나 이상의 네트워크 센서들을 포함한다. 이러한 네트워크 센서 기능을 제공하기 위한 하나의 예시적인 방식은 탭 인터페이스 또는 스위치 미러 포트로서이다. 트래픽을 모니터링하기 위한 다른 접근법들이 또한 적용 가능한 경우 사용될 수 있다(추가적으로 또는 대신에).
다양한 실시예들에서, IoT 서버(134)는 로그 또는 다른 데이터(예컨대, 네트워크(110)를 수동적으로 모니터링하는 것으로부터 수집됨)를 IoT 모듈(138)로 제공하도록 (예컨대, 프론트엔드(142)를 통해) 구성된다. 도 2c는 IoT 서버와 IoT 모듈 간의 예시적인 이벤트 경로를 예시한다. IoT 서버(134)는 디바이스 탐색 이벤트들 및 세션 이벤트들을 IoT 모듈(138)로 송신한다. 예시적인 탐색 이벤트 및 세션 이벤트는 각각 도 2d 및 도 2e에서 예시된다. 다양한 실시예들에서, 탐색 이벤트들은 그것이 디바이스의 아이덴티티를 고유하게 식별하거나 또는 확인할 수 있는 패킷을 관찰할 때마다(예컨대, DHCP, UPNP, 또는 SMB 패킷이 관찰될 때마다) IoT 서버(134)에 의해 송신된다. 디바이스가 가진 각각의 세션(디바이스의 네트워크 안이든 또는 밖이든 관계없이, 다른 노드들과의)은 세션에 대한 정보(예컨대, 소스/목적지 정보, 수신된/송신된 패킷들의 수 등)를 요약하는 세션 이벤트 내에서 설명된다. 적용 가능한 경우, 다수의 세션 이벤트들은 IoT 모듈(138)로 송신하기 전에 IoT 서버(134)에 의해 함께 배치될 수 있다. 도 2e에 도시된 예에서, 두 개의 세션들이 포함된다. IoT 모듈(138)은 디바이스 판정 이벤트들(234)을 통해 디바이스 분류 정보를 IoT 서버(134)에 제공한다.
IoT 모듈(138)을 구현하는 하나의 예시적인 방식은 마이크로서비스-기반 아키텍처를 사용하는 것이다. IoT 모듈(138)은 또한 적용 가능한 경우, 상이한 프로그래밍 언어들, 데이터베이스들, 하드웨어, 및 소프트웨어 환경들을 사용하여, 및/또는 메시징 가능화되고, 콘텍스트들에 의해 한정되고, 자체적으로 배치되고, 독립적으로 배치 가능하고, 분산화되며, 자동화 프로세스들과 함께 구축되고 출시되는 서비스들로서 구현될 수 있다. IoT 모듈(138)에 의해 수행된 하나의 태스크는 IoT 서버(134)에 의해 제공된(및 데이터 기기들(136 및 148)과 같은 데이터 기기들의 다른 실시예들에 의해 제공된) 데이터에서 IoT 디바이스들을 식별하고 이들 디바이스들에 대한 부가적인 콘텍스트 정보를 (예컨대, 다시 각각의 데이터 기기들로) 제공하는 것이다.
도 2f는 IoT 모듈의 실시예를 예시한다. 영역(285)은 모든 테넌트(tenant)들의 데이터에 걸쳐 간격을 두고 실행하는(예컨대, 5분마다, 매시간, 및 매일) 스파크(Spark) 애플리케이션들의 세트를 묘사한다. 영역(297)은 카프카(Kafka) 메시지 버스를 묘사한다. IoT 모듈(138)에 의해 수신된(예컨대, IoT 서버(134)로부터) 세션 이벤트 메시지들은 (예컨대, 대역폭을 보존하기 위해) IoT 서버(134)에서 관찰된 대로 다수의 이벤트들을 함께 묶는다. 변환 모듈(236)은 수신된 세션 이벤트들을 개개의 이벤트들로 평탄화하고 250에서 그것들을 공개하도록 구성된다. 평탄화된 이벤트들은 다양한 상이한 종합 규칙들을 사용하여 종합 모듈(238)에 의해 합쳐진다. 예시적인 규칙은 "시간 간격(예컨대, 5분) 동안, 특정 디바이스 및 그것이 사용한 각각의 (APP-ID) 애플리케이션에 대한 모든 이벤트 데이터를 모은다"이다. 또 다른 예시적인 규칙은 "시간 간격(예컨대, 1시간) 동안, 특정한 목적지 IP 어ㅡ레스와 통신한 특정 디바이스에 대한 모든 이벤트 데이터를 모은다"이다. 각각의 규칙에 대해, 종합 엔진(238)은 합쳐질 필요가 있는 속성들의 리스트(예컨대, 디바이스에 의해 사용된 애플리케이션들의 리스트 또는 목적지 IP 어드레스들의 리스트)를 추적한다. 특징 추출 모듈(240)은 속성들로부터 특징들(252)을 추출한다. 분석 모듈(242)은 디바이스 분류를 수행하기 위해(예컨대, 지도식 및 비지도식 학습을 사용하여) 추출된 특징들을 사용하며, 그것(254)의 결과들은 다른 유형들의 분석을 작동시키기 위해 사용된다(예컨대, 운영 지능 모듈(244), 위협 분석 모듈(246), 및 이상 검출 모듈(248)을 통해). 운영 지능 모듈(244)은 OT 프레임워크 및 운영 또는 비즈니스 지능(예컨대, 디바이스가 어떻게 사용되고 있는지)에 관련된 분석을 제공한다. 경보들(256)이 분석의 결과들에 기초하여 생성될 수 있다. 다양한 실시예들에서, MongoDB(258)는 종합된 데이터 및 특징 값들을 저장하기 위해 사용된다. 배경 서비스들(262)은 스파크 애플리케이션들에 의해 종합된 데이터를 수신하며 데이터를 MongoDB(258)로 기록한다. API 서버(260)는 프론트 엔드(142)로부터 수신된 요청들을 제공하기 위해 MongoDB(258)로부터 데이터를 끌어당기고 병합한다.
도 2g는 IoT 디바이스 식별 분석(예컨대, 분석 모듈(242) 및 관련 요소들의 실시예로서 IoT 모듈(138) 내에서)을 구현하는 예시적인 방식을 예시한다. 탐색 이벤트들 및 세션 이벤트들(예컨대, 각각 도 2d 및 도 2e에 도시된 바와 같이)은 카프카 토픽으로서 메시지 상에서 원시 데이터(264)로서 수신된다(및 또한 저장장치(158)에 저장된다). 특징들은 특징 엔진(276)(예를 들어, Spark/MapReducer를 사용하여 구현될 수 있음)에 의해 추출된다. 원시 데이터는 지리적 위치(geolocation) 정보(예컨대, 소스/목적지 어드레스들의)와 같은, 보안 플랫폼(140)에 의한 부가적인 콘텍스트 정보가 풍부하다(266). 메타데이터 특징 추출(268) 동안, IP 어드레스로부터 시간 간격 내에 송신된 패킷들의 수, 시간 간격 동안 특정한 디바이스에 의해 사용된 애플리케이션들의 수, 및 시간 간격 동안 디바이스에 의해 접촉된 IP 어드레스들의 수와 같은 특징들이 구성된다. 특징들은 실시간으로 인라인 분석 엔진(272)으로(예컨대, JSON 포맷으로) 전달되며(예컨대, 메시지 버스 상에서) 후속 질의를 위해(예컨대, 오프라인 모델링(299) 동안) 저장된다(예컨대, Apache Parquet/DataFrame과 같은 적절한 포맷으로 특징 데이터베이스(270)에).
메타데이터로부터 구축된 특징들 외에, 제2 유형의 특징들이 본원에서 분석 특징들로 불리우는, IoT 모듈(138)에 의해 구축될 수 있다(274). 예시적인 분석 특징은 종합 데이터를 사용하여, 시계열 데이터에 기초하여 시간에 걸쳐 구축된 것이다. 분석 특징들은 유사하게 실시간으로 분석 엔진(272)으로 전달되며 특징 데이터베이스(270)에 저장된다.
인라인 분석 엔진(272)은 메시지 핸들러를 통해 메시지 버스 상에서 특징들을 수신한다. 수행된 하나의 태스크는 활동 분류(278)이며, 이는 수신된 특징 값들/세션 정보에 기초하여 세션과 연관된 활동들(파일 다운로드, 로그인/인증 프로세스, 또는 디스크 백업 활동과 같은)을 식별하고 임의의 적용 가능한 태그들을 첨부하려고 시도한다. 활동 분류(278)를 구현하는 하나의 방식은 컨볼루션 신경망과 조합된 신경망-기반 다-층 퍼셉트론을 통한다.
활동 분류의 결과로서, 특정한 디바이스가 프린팅 활동들에 관여하고 있으며(즉, 프린팅 프로토콜들을 사용하여) 또한 HP에 의해 소유된 리소스들을 주기적으로 접촉한다는(예컨대, HP URL을 호출하고 상태 정보를 보고하기 위해 그것을 사용함으로써 업데이트들을 체크하기 위해) 것이 결정된다고 가정한다. 다양한 실시예들에서, 분류 정보는 클러스터링 프로세서(비지도식) 및 예측 프로세스(지도식) 양쪽 모두로 전달된다. 어느 하나의 프로세스가 디바이스의 성공적인 분류를 야기한다면, 분류는 디바이스 데이터베이스(286)에 저장된다.
디바이스는 스테이지 1 클러스터링 엔진(280)에 의해, 그 속성들 및 다른 거동 패턴들에 기초하여 다수의 클러스터들(예컨대, 프린터처럼 동작하고, HP 디바이스처럼 동작하는 등)로 클러스터링될 수 있다. 클러스터링 엔진(280)을 구현하는 하나의 방식은 극한 구배 부스팅 프레임워크(예컨대, XGB)를 사용하는 것이다. 스테이지 1 분류기는 이전에 보여지지 않았지만 기존의 알려진 디바이스들과 유사한 디바이스들을 분류하는데 유용할 수 있다(예컨대, 서모스탯들의 새로운 벤더가 알려진 서모스탯들과 유사하게 거동하는 서모스탯 디바이스들을 판매하기 시작함).
도 2g에 도시된 바와 같이, 활동 분류 정보는 또한 분류기들(282)의 세트로 제공되며 예측이 디바이스에 대한 제공된 특징들에 기초하여 수행된다. 두 개의 가능성들이 발생할 수 있다. 제1 시나리오에서, 디바이스가 알려진 디바이스 프로필(즉, 높은 신뢰 스코어)과 일치하는 높은 확률이 있다고 결정된다. 그렇다면, 디바이스에 대한 정보는 디바이스의 식별에 대한 최종 판정을 하며(예컨대, 그것이 제공된 정보 및 임의의 부가적인 적용 가능한 콘텍스트 정보를 사용하여) 그에 따라 디바이스 데이터베이스(286)를 업데이트하는 스테이지 2 분류기(284)로 제공된다. 스테이지 2 분류기를 구현하는 하나의 방식은 구배 부스팅 프레임워크를 사용하는 것이다. 제2 시나리오에서, 신뢰 스코어가 낮다고(예컨대, 디바이스는 50% 신뢰를 갖고 HP 프린터 및 HP 랩탑 양쪽 모두와 일치한다) 가정하자. 이 시나리오에서, 분류기들(282)에 의해 결정된 정보는 클러스터링 시 사용 가능한 부가적인 정보로서 클러스터링 엔진(280)으로 제공될 수 있다.
또한 도 2G에서 오프라인 모델링 모듈(299)이 도시된다. 오프라인 모델링 모듈(299)은 그것이 시간 제한적이지 않으므로 인라인 분석 엔진(272)과 대조된다(반면 인라인 분석 엔진(272)은 실시간으로 디바이스 분류 정보를 제공하려고 시도한다(예컨대, 메시지(234)로서)). 주기적으로(예컨대, 매일 한 번 또는 주당 한 번), 오프라인 모델링 모듈(299)(예컨대, Python을 사용하여, 구현됨)은 인라인 분석 모듈(272)에 의해 사용된 모델들을 재구축한다. 활동 모델링 엔진(288)은 활동 분류기(278)를 위한 모델들을 구축하며, 이는 또한 인라인 분석 동안 디바이스 식별을 위해 분류기들에 의해 사용되는 디바이스 유형 모델들(286)을 위해 사용된다. 베이스라인 모델링 엔진(290)은 디바이스 모델들의 베이스라인 거동들의 모델들을 구축하며, 이는 또한 킬 체인(kill chain)과 같은, 특정 유형들의 디바이스 이상들(292) 및 특정 유형들의 위협들(294)을 모델링할 때 사용된다. 생성된 모델들은 다양한 실시예들에서, 모델 데이터베이스(298)에 저장된다.
IV. 네트워크 엔티티 ID AAA
이전에 언급된 바와 같이, 앨리스가 ACME에 의해 랩탑(104)을 발행받는다고 가정하자. 네트워크(110)의 다양한 구성요소들은 그녀가 다양한 리소스들을 액세스하기 위해 그것을 사용함에 따라 앨리스의 랩탑을 인증하기 위해 협력할 것이다. 일 예로서, 앨리스가 랩탑(104)을 네트워크(110) 내에 위치된 무선 액세스 포인트(묘사되지 않음)에 연결할 때, 무선 액세스 포인트는 네트워크 액세스를 규정하는 동안 AAA 서버(156)와 통신할 수 있다(직접이든 또는 간접적이든). 또 다른 예로서, 앨리스가 그녀의 ACME 이메일을 액세스하기 위해 랩탑(104)을 사용할 때, 랩탑(104)은 그녀의 인박스 등을 가져오는 동안 디렉토리 서비스(154)와 통신할 수 있다(직접이든 또는 간접적이든). 상용 운영 시스템을 실행하는 상용 랩탑으로서, 랩탑(104)은 랩탑(104)이 그것이 요구하는 적절한 리소스들로의 액세스를 얻도록 돕는 적절한 AAA 메시지들(예컨대, RADIUS 클라이언트 메시지들)을 생성할 수 있다.
이전에 언급된 바와 같이, 110과 같은 네트워크에서 IoT 디바이스들(예컨대, 디바이스(146))에 의해 제기되는 하나의 문제는 종종 "미관리"(예컨대, 네트워크 관리자들에 의해 구성되고, 규정되고 관리되지 않는 등)이고, RADIUS와 같은 프로토콜들을 지원하지 않으며, 따라서 랩탑(104)과 같은 다른 디바이스들과 같은 AAA 서비스들과 통합될 수 없다. 다양한 접근법들이 네트워크(110) 내에서 네트워크 액세스를 IoT 디바이스들에 제공하기 위해 채택될 수 있으며, 그 각각은 단점들을 가진다. 하나의 옵션은 ACME에 대해 IoT 디바이스들을 게스트 네트워크의 사용에 제한하는 것이다(예컨대, 사전-공유 키를 통해). 불운하게도, 이는 그것이 합법적으로 액세스해야 하는 네트워크(110) 내에서 다른 노드들과 통신할 수 없다면 IoT 디바이스의 유틸리티를 제한할 수 있다. 또 다른 옵션은 IoT 디바이스들에 네트워크(110)로의 제한되지 않은 액세스를 허용하여, 분할된 네트워크를 가진 보안 이익들을 경감시키는 것이다. 또 다른 옵션은 ACME에 대해 주어진 IoT 디바이스가 어떻게 네트워크(110)에서 리소스들을 액세스할 수 있어야 하는지를 통제하는 규칙들을 수동으로 특정하는 것이다. 이 접근법은 일반적으로 다양한 이유들로 사용할 수 없고/작동 가능하지 않다. 일 예로서, 관리자들은 종종 IoT 디바이스들의 배치에 수반되지 않을 수 있으며 따라서 이러한 디바이스들에 대한 정책들이 (예컨대, 데이터 기기(102)에) 포함되어야 하는지를 알지 못할 것이다. 관리자들이 예컨대, 기기(102)에서 특정 IoT 디바이스들에 대한(예컨대, 디바이스(112)와 같은 디바이스들에 대한) 정책들을 수동으로 구성하는 경우에도, 이러한 정책들을 최신으로 유지하는 것은 에러가 발생하기 쉬우며 일반적으로 네트워크(110)에 존재할 수 있는 IoT 디바이스들의 순전한 숫자를 고려해볼 때 사용할 수 없다. 뿐만 아니라, 이러한 정책들은 단순할 가능성이 있을 것이며(예컨대, IP 어드레스 및/또는 MAC 어드레스에 의해 CT 스캐너(112)를 특정한 네트워크에 할당함) CT 스캐너(112)를 수반한(예컨대, 수술 디바이스들 대 판매 시점 관리 단말기들에 적용 가능한 정책들을 동적으로 포함하는) 연결들/정책들에 대한 보다 정교한 제어를 허용하지 않는다. 뿐만 아니라, CT 스캐너(112)가 이전에 언급된 바와 같이, 데이터 기기(102)에 수동적으로 포함되는 경우에도, IoT 디바이스들은 일반적으로 RADIUS와 같은 기술들을 지원하지 않을 것이며 이러한 AAA 서버들이 CT 스캐너(112)의 네트워킹 액세스를 관리할 때의 이익들은 이러한 기술들을 보다 완전히 지원하는 다른 유형들의 디바이스들(예컨대, 랩탑(104))과 비교하여 제한될 것이다. 이하에서 더 상세하게 설명될 바와 같이, 다양한 실시예들에서, 데이터 기기(102)(예컨대, IoT 서버(134)를 통해)는 수동형 방식으로 네트워크(110)에 존재하는 IoT 디바이스들에 AAA 기능에 대한 지원을 제공하도록 구성된다.
다음의 논의에서, ACME에서 앨리스의 부서는 앨리스가 다른 ACME 직원들뿐만 아니라 ACME의 밖에 있는 개인들(예컨대, 그 자신의 네트워크(114), 데이터 기기(136), 및 화이트보드(144)를 가진 베타 대학에서의 연구자인, 봅(Bob))과 협업할 수 있도록 상호작용 화이트보드(146)를 최근에 구매하였다고 가정한다. 화이트보드(146)의 초기 셋업의 부분으로서, 앨리스는 그것을 전원에 연결하며 그것에 유선 연결(예컨대, 회의실에서의 콘센트로) 또는 무선 크리덴셜들(예컨대, 회의실의 방문자들에 의한 사용을 위한 크리덴셜들)을 제공한다. 화이트보드(146)가 네트워크 연결을 규정할 때, IoT 서버(134)(예컨대, 상기 설명된 바와 같이 네트워크 센서와 같은 메커니즘을 통해)는 화이트보드(146)를 네트워크(110) 내에서 새로운 디바이스로서 인식할 것이다. 이러한 검출에 응답하여 취해진 하나의 동작은 보안 플랫폼(140)과 통신하는 것이다(예컨대, 화이트보드(146)에 대한 새로운 레코드를 데이터베이스(160)에 생성하는 것 및 화이트보드(146)와 연관된 임의의 현재 이용 가능한 콘텍스트 정보를 검색하는 것(예컨대, 화이트보드(146)의 제조사, 화이트보드(146)의 모델 등을 얻는 것)). 보안 플랫폼(140)에 의해 제공된 임의의 콘텍스트 정보는 적용 가능한 경우 결과적으로 이를 디렉토리 서비스(154) 및/또는 AAA 서버(156)로 제공할 수 있는 데이터 기기(102)로 제공될 수 있다(및 그것에 저장될 수있다). 적용 가능한 경우, IoT 모듈(138)은 그것이 이용 가능해짐에 따라 화이트보드(146)에 대한 업데이트된 콘텍스트 정보를 데이터 기기(102)로 제공할 수 있다. 데이터 기기(102)(예컨대, IoT 서버(134)를 통해)는 유사하게 화이트보드(146)에 대한 진행 중인 정보를 보안 플랫폼(140)에 제공할 수 있다. 이러한 정보의 예들은 화이트보드(146)와 같은 디바이스들에 대한 거동 프로필들을 구축하기 위해 보안 플랫폼(140)에 의해 사용될 수 있는 네트워크(110) 상에서의 화이트보드(146)의 거동들에 대한 관찰들(예컨대, 그것이 한 연결들에 대한 통계 정보)을 포함한다. 유사한 거동 프로필들이 다른 디바이스들(예컨대, 화이트보드(144))에 대한 보안 플랫폼(140)에 의해 구축될 수 있다. 이러한 프로필들은 이상 거동들을 검출하는 것을 포함하는, 다양한 목적들을 위해 사용될 수 있다. 일 예로서, 데이터 기기(148)는 온도계(152)가 온도계(152)의 이력 관찰들과 비교하여, 및/또는 유사한 모델, 제조사, 또는 보다 일반적으로 다른 네트워크들에 존재하는 온도계들을 포함한 다른 온도계들(묘사되지 않음)과 비교하여 이례적으로 동작하는지를 검출하기 위해 보안 플랫폼(140)에 의해 제공된 정보를 사용할 수 있다. 이상 거동이 검출된다면(예컨대, 데이터 기기(148)에 의해), 네트워크(116) 상에서 다른 노드들로의 온도계(152)의 액세스를 제한하는 것, 경보를 생성하는 것 등과 같은, 적절한 시정 조치가 자동으로 취해질 수 있다.
도 3은 네트워크에서 IoT 디바이스에 대한 AAA 지원을 수동적으로 제공하기 위한 프로세스의 실시예를 예시한다. 다양한 실시예들에서, 프로세스(300)는 IoT 서버(134)에 의해 수행된다. 프로세스는 302에서 IoT 디바이스에 의해 전송된 패킷들의 세트가 획득될 때 시작한다. 일 예로서, 화이트보드(146)가 먼저 네트워크(110) 상에서 규정될 때, 이러한 패킷들은 302에서 IoT 서버(134)에 의해 수동으로 수신될 수 있다. 패킷들은 또한 302에서 화이트보드(146)의 후속 사용 동안(예컨대, 앨리스가 화이트보드(144)를 통해 봅과 화이트보더링 세션들을 가짐에 따라) 수신될 수 있다. 304에서, 데이터 패킷들의 세트에 포함된 적어도 하나의 패킷이 분석된다. 304에서 수행된 프로세싱의 일 예로서, IoT 서버(134)는 302에서 수신된 패킷들이 화이트보드(146)에 의해 전송되고 있다고 결정한다. IoT 서버(134)가 취할 수 있는 하나의 동작은 화이트보드(146)를 네트워크(110) 상에서 새로운 IoT 디바이스로 식별하며 이용 가능하다면 IoT 모듈(138)로부터 콘텍스트 정보를 획득하는 것이다. 306에서, IoT 서버(134)는, IoT 디바이스를 대신하여, IoT 디바이스와 연관된 정보를 포함하는 AAA 메시지를 전송한다. 이러한 메시지의 예가 도 4에서 도시된다. 이전에 언급된 바와 같이, 화이트보드(146)는 RADIUS 프로토콜을 지원하지 않는다. 그러나, IoT 서버(134)는 화이트보드(146)를 대신하여 도 4a에 묘사된 바와 같은 메시지를 생성할 수 있다(예컨대, 적용 가능한 경우 302에서 및 또한 보안 플랫폼(140)으로부터 수신된 정보를 사용하여). 이전에 언급된 바와 같이, IoT 서버(134)가 화이트보드(146)에 대한 정보를 IoT 모듈(138)로 제공할 때, IoT 모듈(138)은 화이트보드(146)에 대한 레코드를 데이터베이스(160)에 생성하는 것 및 화이트보드에 대한 콘텍스트 정보를 가진 상기 레코드를 덧붙이는 것과 같은 다양한 동작들을 취할 수 있다. 화이트보드(146)에 대한 부가적인 콘텍스트 정보가 보안 플랫폼(140)에 의해 수집됨에 따라, 그 프로필은 업데이트되며 데이터 기기(102)로 전파될 수 있다. 화이트보드(146)가 처음에 네트워크(110) 내에서 규정될 때, 어떤 부가적인 콘텍스트 정보도 이용 가능하지 않을 수 있다(예컨대, 보안 플랫폼(140)은 이러한 부가적인 정보를 갖지 않을 수 있거나 또는 보안 플랫폼(140)에 의해 이러한 정보를 IoT 서버(134)로 제공하는 것은 즉각적이지 않을 수 있음). 따라서, 및 도 4a에 묘사된 바와 같이, 화이트보드(146)를 대신하여 IoT 서버(134)에 의해 생성된 RADIUS 메시지는 제한된 정보를 포함할 수 있다. 부가적인 콘텍스트 정보가 수신됨에 따라(예컨대, IoT 서버(134)에 의해 IoT 모듈(138)로부터), 화이트보드(146)를 대신하여 IoT 서버(134)에 의해 송신된 후속 RADIUS 메시지들은 이러한 부가적인 정보가 풍부할 수 있다. 이러한 후속 메시지들의 예들은 도 4b 및 도 4c에서 예시된다. 도 4b는 일단 화이트보드(146)에 대한 콘텍스트 정보가 IoT 모듈(138)(예컨대, 매우 다양한 IoT 디바이스들에 대한 콘텍스트 정보의 데이터베이스를 포함하는)에 의해 제공되었다면 IoT 서버(134)가 화이트보드(146)를 대신하여 송신할 수 있는 RADIUS 메시지의 예를 예시한다. 도 4b에 도시된 예에서, 화이트보드의 제조사(Panasonic) 및 디바이스의 특징(예컨대, 그것은 상호작용 화이트보드임)과 같은 콘텍스트 정보가 포함된다. 이러한 콘텍스트 정보는, 이를테면 원격회의 설비에 전용되는 서브네트워크 상에서 그것을 자동으로 규정함으로써, AAA 서비스들을 화이트보드(146)로 제공하기 위해(화이트보드(146)를 수정할 필요없이) AAA 서버(156)와 같은 AAA 서버들에 의해 사용될 수 있다. 다른 유형들의 IoT 디바이스들이 또한 디바이스 유형, 목적 등과 같은 속성들에 기초하여 자동으로 그룹핑될 수 있다(예컨대, 중대한 수술 장비는 이러한 장비에 전용되는 서브네트워크 상에서 자동으로 규정되며 따라서 네트워크 상에서 다른 디바이스들로부터 분리됨). 이러한 콘텍스트 정보는 소셜 네트워킹 패킷들(예컨대, APP-ID를 사용하여 결정된 바와 같이)을 통해 화이트보드(146) 패킷들에 우선 처리를 제공하는 정책과 같은, 트래픽 쉐이핑 정책들과 같은 정책들을 시행하기 위해 사용될 수 있다. 정교한 정책들이 중대한 수술 장비와의 통신들에 유사하게 적용될 수 있다(예컨대, 이러한 장비와의 통신에서 임의의 디바이스가 구형의 운영 시스템을 갖는 것을 방지하는 등). 도 4c에 도시된 예에서, 더 많은 부가적인 콘텍스트 정보가 IoT 서버(134)에 의해 화이트보드(146)를 대신하여 RADIUS 메시지들에 포함된다. 이러한 부가적인 콘텍스트 정보는 디바이스 모델, 운영 시스템, 및 운영 버전과 같은 부가적인 속성 정보를 포함한다. 화이트보드(146)가 처음에 네트워크(110)에서 규정될 때, 도 4c에 묘사된 콘텍스트 정보의 모두는 이용 가능하지 않을 가능성이 있을 것이다. 화이트보드(146)가 시간에 걸쳐 네트워크(110) 내에서 사용됨에 따라, 부가적인 콘텍스트 정보가 수집될 수 있다(예컨대, IoT 서버(134)가 계속해서 화이트보드(146)로부터 패킷들을 수동적으로 관찰하고 정보를 보안 플랫폼(140)에 제공함에 따라). 이러한 부가적인 정보는 정교한 정책들을 시행하기 위해 레버리징될 수 있다(예컨대, 데이터 기기(102)에 의해). 일 예로서, 도 4c에 도시된 바와 같이, 화이트보드(146)는 리눅스-기반이며 3.16의 버전을 가진 특정한 운영 시스템을 구동한다. 빈번하게, IoT 디바이스들은 업그레이드 가능하지 않으며/패치 가능하지 않은 운영 시스템들의 버전들을 구동할 것이다. 이러한 디바이스들은 익스플로잇(exploit)들이 이들 운영 시스템들을 위해 개발될 때 보안 위험들을 제기할 수 있다. 데이터 기기(102)는 이를테면 현재 운영 시스템들을 가진 것들로의 덜 제한적인 네트워크 액세스를 허용하면서 구형의 운영 시스템들을 가진 IoT 디바이스들을 네트워크(110)에서 다른 노드들로부터 분리함으로써(또는 그 외 그것들의 액세스를 제한함으로써) 콘텍스트 정보에 기초하여 보안 정책들을 구현할 수 있다.
도 4a 내지 도 4c는 RADIUS 액세스 요청 메시지들의 예들을 묘사한다. 적용 가능한 경우, IoT 서버(134)는 화이트보드(146)를 대신하여 다양한 유형들의 RADIUS 메시지들을 생성할 수 있다. 일 예로서, RADIUS 과금 시작 메시지들은 화이트보드(146)로부터의 트래픽이 처음 관찰될 때 트리거될 수 있다. 주기적인 RADIUS 과금 중간 업데이트 메시지들은 화이트보드가 사용 중인 동안 송신될 수 있으며, RADIUS 과금 중지 메시지들은 화이트보드(146)가 오프라인이 될 때 송신될 수 있다.
V. IOT 디바이스 탐색 및 식별
상기 논의된 바와 같이, 보안 플랫폼(140)(예컨대, IoT 모듈(138)을 통해)에 의해 수행된 하나의 태스크는 IoT 디바이스 분류이다. 예로서, IoT 서버(134)가 디바이스 탐색 메시지를 IoT 모듈(138)로 전송할 때, IoT 모듈(138)은 디바이스에 대한 분류를 결정하고 응답하려고(예컨대, 도 2c에 도시된 판정(234)으로) 시도한다. 디바이스는 적절한 경우, 디바이스의 후속 분류가 수행될 필요가 없도록(또는, 적용 가능한 경우, 그 외 수행될 것보다 덜 빈번하게 수행되는) IoT 모듈(138)에 의해 고유 식별자와 연관된다. 또한 상기 논의된 바와 같이, 결정된 분류는 디바이스로/로부터의 트래픽에 대해 정책들을 시행하기 위해 사용될 수 있다(예컨대, 데이터 기기(102)에 의해).
다양한 접근법들이 디바이스를 분류하기 위해 사용될 수 있다. 제1 접근법은 조직적 고유 식별자(OUI), 실행하는 애플리케이션들의 유형들 등과 같은, 디바이스의 정적 속성들을 레버리징하는 규칙들/휴리스틱스들의 세트에 기초하여 분류를 수행한다. 제2 접근법은 네트워크 트래픽으로부터 추출된 디바이스의 동적, 그러나 미리 정의된 속성들(예컨대, 날마다 송신된 패킷들의 수)을 레버리징하는 기계 학습 기법들을 사용하여 분류를 수행하는 것이다. 불운하게도, 이들 접근법들 양쪽 모두는 약점들을 가진다.
규칙-기반 접근법은 일반적으로 별개의 규칙이 IoT 디바이스의 각각의 유형(어떤 속성들/값들이 디바이스의 서명의 유형에 대한 서명으로서 사용되어야 하는지를 기술하는)에 대해 수동으로 생성될 것을 요구한다. 이 접근법에 의해 제기되는 하나의 도전은 어떤 서명들이 디바이스를 식별하는데 관련 있으며 다른 디바이스 서명들 중에서 고유한지를 결정하는데 있다. 뿐만 아니라, 규칙-기반 접근법을 갖고, 트래픽으로부터 쉽게 획득될 수 있는 제한된 수의 정적 속성들이 이용 가능하다(예컨대, 사용자 에이전트, OUI, URL 목적지 등). 속성들은 일반적으로 정규 표현이 일치할 수 있는 패턴에서 그것들이 나타내기에 충분히 단순할 필요가 있다. 또 다른 도전은 새로운 디바이스들이 시장에 진입함에 따라(예컨대, CT 스캐너의 새로운 브랜드 또는 모델이 제공된다) 존재하고/식별 가능할 수 있는 새로운 정적 속성들을 식별하는데 있다. 또 다른 도전은 규칙이 트리거되기 위해 네트워크 트래픽에서 모든 일치하는 속성들이 수집될 필요가 있다는 것이다. 더 적은 속성들로는 판정에 이를 수 없다. 예로서, 서명은 특정한 URL에 연결하기 위해 특정한 OUI를 가진 특정한 디바이스를 요구할 수 있다. OUI 자체를 갖는 것은 이미 디바이스의 아이덴티티의 충분한 표시자일 수 있지만, 서명은 URL이 또한 관찰될 때까지 트리거하지 않을 것이다. 이는 디바이스의 아이덴티티를 결정하는데 추가 지연을 야기할 것이다. 또 다른 도전은 시간에 따라 디바이스 변화(예컨대, 디바이스 또는 디바이스에 의해 사용된 서비스들에 대해 이루어진 업데이트들 때문에)를 위한 정적 속성들로서 서명들을 유지하고 업데이트하는 것이다. 예로서, 특정한 디바이스는 처음에 제1 유형의 네트워크 카드를 사용하여 제조되었지만, 시간에 걸쳐 제조사는 상이한 네트워크 카드(상이한 OUI를 보임)로 스위칭할 수 있다. 규칙-기반 시스템이 변화를 모른다면, 거짓 양성들이 발생할 수 있다. 또 다른 도전은 매일 온라인으로 가져온 새로운 IoT 디바이스들의 수가 수백만 개의 새로운 디바이스 인스턴스들에 도달할 때 서명 생성/검증을 스케일링하는데 있다. 그 결과, 새롭게 생성된 규칙들은 기존의 규칙들과 충돌하여 분류에서 거짓 양성들을 야기할 수 있다.
기계 학습-기반 접근법은 일반적으로 네트워크 트래픽으로부터 추천된 정적 및/또는 동적 특징들에 기초하여 트레이닝 모델들을 생성하는 것을 수반한다. 새로운 IoT 디바이스로부터의 네트워크 데이터에 대한 예측의 결과는 연관된 정확도를 가진 디바이스의 아이덴티티를 제공하는 사전-트레이닝된 모델들에 기초한다. 기계 학습 접근법이 가진 문제들의 예들은 다음과 같다. 원하는 정확도에 이르는데 요구되는 계산 시간은 수용 가능하지 않을 수 있으며, 여기에서 예측은 모든 새로운 디바이스, 또는 일정한/고유 ID(예컨대, MAC 어드레스)가 없는 디바이스 상에서 행해진다. 생성될 필요가 있는 수천 또는 수만 개의 특징들이 있을 수 있으며, 이들 특징들은 미리 정의된 시간 윈도우에 걸쳐 변환하여, 충분한 수의 특징들이 유효 예측을 하는데 이용 가능하기 전에 상당한 시간이 걸릴 수 있다(정책 시행의 목적을 좌절시킬 수 있다). 뿐만 아니라, 목표가 예측 시 지연을 최소화하는 것이면 네트워크 데이터를 스트리밍하기 위한 대형 데이터 파이프라인을 구축하고 유지하는 비용이 높을 수 있다. 또 다른 문제는 주어진 배치 환경에 특정적인 관련없는 특징들에 의해 유발되는 잡음이 예측의 정확도를 감소시킨다는 것이다. 디바이스 유형들의 수가 수만 개 이상에 이를 때 모델들을 유지하고 업데이트하는데 도전이 있다.
다양한 실시예들에서, 보안 플랫폼(140)은 분류에 하이브리드 접근법을 사용함으로써 두 개의 앞서 언급한 접근법들의 각각의 문제들을 처리한다. 예시적인 하이브리드 접근법에서, 네트워크 거동 패턴 식별자(또한 본원에서 패턴 ID로 불리움)가 디바이스의 각각의 유형에 대해 생성된다. 다양한 실시예들에서, 패턴 ID는 별개의 네트워크 거동 디스크립션을 형성하며 IoT 디바이스의 유형을 식별하기 위해 사용될 수 있는, 그 각각의 확률들(특징 또는 거동 카테고리에 대한 중요도 스코어들로서)과 조합된 속성들 또는 시퀀스 특징들의 리스트이다. 패턴 ID들은 저장되며(예컨대, 데이터베이스에) 디바이스들의 아이덴티티를 식별/검증하기 위해 사용될 수 있다.
속성들의 세트에 대해 트레이닝할 때, 극한 구배 부스팅 프레임워크(예컨대, XGB)와 같은, 특정한 접근법들이 중요한 특징들의 최상위 리스트를 제공할 수 있다(정적 속성들이든, 동적 속성들이든, 및/또는 종합된/변환된 값들이든 관계없이). 패턴 ID는 일단 수립되면 디바이스 유형을 고유하게 식별하기 위해 사용될 수 있다. 특정한 특징들이 디바이스에 대해 우세하다면(예큰대, 특정한 정적 특징(부트 시간에 매우-특정적인 URL을 접촉하는 것과 같은)은 98% 신뢰를 갖고 디바이스를 식별한다), 그것들은 규칙을 자동으로 생성하기 위해 사용될 수 있다. 우세한 특징들이 존재하지 않는 경우에도, 최상위 특징들의 표현이 그럼에도 불구하고 패턴 ID(예컨대, 다수의 특징들의 세트가 패턴으로 연쇄되는 경우)로서 사용될 수 있다. 모든 알려진 모델들(및 모든 알려진 IoT 디바이스들)을 포함하는 데이터 세트에 대해 트레이닝함으로써, 모델들/고유하게 식별한 특징들 간의 잠재적인 충돌이 회피될 수 있다. 뿐만 아니라, 패턴 ID는 인간-판독 가능할 필요가 없다(그러나 식별 목적들을 위해 저장되고, 공유되며, 및/또는 재사용될 수 있다). 이러한 접근법에 의해 상당한 시간 절약들이 또한 실현될 수 있으며, 따라서 그것은 근-실시간 분류에서 사용될 수 있다. 우세한 특징이 관찰되자마자, 특정한 디바이스의 분류가 발생할 수 있다(다수의 특징들이 발생할 때까지 기다려야하는 대신에).
"Teem Room Display iPad" 디바이스에 대한 패턴 ID를 생성하기 위해 사용될 수 있는 데이터의 예가 다음을 포함할 수 있다(전체 리스트는 바젼수 모델의 트레이닝 또는 다수의 이진 모델들을 트레이닝하는 것을 통해 자동으로 생성됨):
* Apple 디바이스(100%)
* 스페셜 iPad(>98.5%)
* Teem Room 앱(>95%)
* 회의 볼륨 패턴 VPM-17(>95%)
* 서버-인-더-클라우드(>80%)
하이브리드 접근법을 구현하는 예시적인 방식은 다음과 같다. 신경망-기반 기계 학습 시스템이 자동 패턴 ID 트레이닝 및 생성을 위해 사용될 수 있다. 신경망 모델을 트레이닝하기 위해 사용될 수 있는 특징들의 예들은 네트워크 트래픽으로부터 추출된 정적 특징들(예컨대, OUI, 호스트명, TLS 지문, 매칭된 L7 페이로드 서명들 등) 및 네트워크 트래픽으로부터 추출되지만 환경에 특정적이지 않은 시퀀스 특징들(예컨대, 애플리케이션들, 애플리케이션의 L7 속성들, 카테고리 특징들로 변환된 볼륨 범위 등) 양쪽 모두를 포함한다. 경량 데이터 파이프라인이 특징 생성을 위해 선택된 네트워크 데이터를 실시간으로 스트리밍하기 위해 사용될 수 있다. 모델들을 불러오고 예측 시 지연들을 최소화하기 위해 캐싱을 제공하는 예측 엔진이 사용될 수 있다. 예측 시, 짧은(예컨대, 분-기반) 종합이 선택된 시퀀스 특징들을 안정화시키기 위해 사용될 수 있다. 맞춤 데이터 정규화, 강화, 종합, 및 변환 기법들이 시퀀스 특징들을 엔지니어링하기 위해 사용될 수 있다. 보다 긴 취합 윈도우가 더 양호한 정확도를 위해 트레이닝 시 사용될 수 있다. 정확도는 특징들이 시간에 걸쳐 병합되고 종합되는 예측을 위해 개선될 수 있다. 백엔드 피드백 엔진은 패턴 ID 예측을 위해 사용된 속성들을 확대하도록 돕는 "느린 경로" 예측 시스템(예컨대, 디바이스 유형 모델링 서브시스템 및 디바이스 그룹 모델링 서브시스템을 포함하는 기계 학습-기반 접근법)의 결과들을 라우팅하기 위해 사용될 수 있다. 디바이스 그룹 모델은 수용 가능한 임계치(예컨대, 그 일부가 라벨링되지 않은 유사한 유형들의 디바이스들을 클러스터링하기 위해 또 다른 서브시스템을 동반하는, 미리 정의된 유형들의 세트에 기초하여 예측 결과들을 할당함)에 대한 정확도를 개선하기 위해, 충분한 샘플들 또는 특징들이 이용 가능하지 않을 때 디바이스 유형 모델을 갖고 이슈들을 보상하도록 트레이닝될 수 있다. 마지막으로, 판정 모듈이 실시간 예측 엔진으로부터의 결과들을 공개하기 위해 사용될 수 있다.
본원에서 설명되는 바와 같이 분류에 대한 하이브리드 접근법의 예시적인 이점들은 다음과 같다. 첫 번째로, 빠른 융합이 발생하여, 주어진 디바이스가 수 분 또는 수 초 내에 잠재적으로 식별되도록 허용할 수 있다. 두 번째로, 규칙-기반 및 기계 학습-기반 시스템들의 개개의 문제들을 처리한다. 세 번째로, 예측 결과들에 안정성 및 일관성을 제공한다. 네 번째로, 수 만개(또는 그 이상)의 상이한 유형들의 IoT 디바이스들을 지원하기 위한 확장 가능성을 가진다. 예측은 일반적으로 단지 새로운 디바이스들에 대해 요구된다(주어진 디바이스가 L3 네트워크 트래픽-기반 식별과 같은, 고유 ID 할당이 부족할지라도).
모듈(138)의 실시예가 도 5에 도시된다. IoT 모듈(138)을 구현하는 하나의 예시적인 방식은 서비스들이 정교하며 프로토콜들이 경량인 마이크로서비스-기반 아키텍처를 사용하는 것이다. 서비스들은 또한 적용 가능한 경우, 상이한 프로그래밍 언어들, 데이터베이스들, 하드웨어, 및 소프트웨어 환경들, 및/또는 메시징 가능화되고, 콘텍스트들에 의해 한정되고, 자체적으로 개발되고, 독립적으로 배치 가능하고, 분산화되며 자동 프로세스들로 구축되고 발매되는 비교적 작은 서비스들을 사용하여 구현될 수 있다.
이전에 언급된 바와 같이, 다양한 실시예들에서, 보안 플랫폼(140)은 네트워크(예컨대, 네트워크(110)) 상에서 IoT 디바이스들에 대한 정보를 (예컨대, 데이터 기기(102)로부터) 주기적으로 수신한다. 몇몇 경우들에서, IoT 디바이스들은 보안 플랫폼(140)에 의해 이전에 분류되었을 것이다(예컨대, 작년에 네트워크(110) 상에 설치된 CT 스캐너). 다른 경우들에서, IoT 디바이스들은 보안 플랫폼(140)에 의해 새롭게 보여질 것이다(예컨대, 처음 화이트보드(146)가 설치된다). 주어진 디바이스가 보안 플랫폼(140)에 의해 이전에 분류되지 않았다고 가정하자(예컨대, 고유 디바이스 식별자들의 세트 및 연관된 디바이스 정보를 저장하는 데이터베이스(286)에 디바이스에 대한 어떤 엔트리도 존재하지 않음). 도 5에 예시된 바와 같이, 새로운 디바이스에 대한 정보가 분류를 위해 두 개의 상이한 프로세싱 파이프라인들로 제공될 수 있다. 파이프라인(504)은 "빠른 경로" 분류 파이프라인(패턴 ID-기반 스킴(scheme)에 대응하는)을 나타내며 파이프라인(502)은 "느린 경로" 분류 파이프라인(기계 학습-기반 스킴에 대응하는)을 나타낸다.
파이프라인(504)에서, 빠른 경로 특징 엔지니어링은 디바이스의 적용 가능한 정적 및 시퀀스 특징들을 식별하기 위해 수행된다(508). 빠른 경로 예측은 패턴 ID들 또는 이전에 구축된 모델들(예컨대, 최상위 중요 특징들에 기초하여 오프라인 프로세싱 파이프라인(506)을 사용하여 구축된 모델들)을 사용하여 수행된다(510). 특정한 패턴에 일치하는 디바이스에 대한 신뢰 스코어가 결정된다(512). 디바이스에 대한 신뢰 스코어가 사전-트레이닝된 임계치를 충족하면(예컨대, 0.9와 같은, 모듈(138) 또는 그 구성요소들의 전체 예측 정확도에 기초하여), 분류가 디바이스에 할당되거나(디바이스 데이터베이스(516)에) 또는 적용 가능한 경우 업데이트될 수 있다. 처음에, 신뢰 스코어는 근-실시간 빠른 경로 프로세싱에 기초할 것이다. 이러한 접근법의 이점은 데이터 기기(102)가 정책들을 디바이스의 트래픽에 매우 빠르게 적용하기 시작할 수 있다는 것이다(예컨대, 모듈(138)이 디바이스를 신규/미분류로 식별하는 수분 내에). 기기(102)는 페일-세이프(예컨대, 다양한 네트워크 리소스들을 액세스하기 위한 디바이스의 능력을 감소/제한하는)하거나 또는 시스템(140)으로부터 분류 판정을 보류하는 페일-데인저(디바이스에 관범위한 액세스를 허용하는)하도록 구성될 수 있다. 부가적인 정보가 이용 가능함에 따라(예컨대, 느린 경로 프로세싱을 통해), 신뢰 스코어가, 적용 가능한 경우 상기 부가적인 정보에 기초할 수 있다(예컨대, 신뢰 스코어를 증가시키거나 또는 빠른 경로 분류 동안 이루어진 실수들을 개정/교정한다).
사용될 수 있는 특징들(예컨대, 정적 속성들 및 시퀀스 특징들)의 예들은 다음을 포함한다. 패턴 ID들은 포함된 논리 조건들과 이들 속성들의 임의의 조합일 수 있다:
* mac 어드레스에서의 OUI
* 디코딩된 프로토콜들로부터의 Ilostname 스트링
* HTTP로부터의 사용자 에이전트 스트링, 및 다른 명확한 텍스트 프로토콜들
* 디코딩된 SNMP 응답들로부터의 시스템 이름 스트링
* 디코딩된 LDAP 프로토콜들로부터의 OS, 호스트명, 도메인, 및 사용자명
* 디코딩된 DNS 프로토콜들로부터의 URL들
* 디코딩된 SMB 프로토콜들로부터의 SMB 버전들, 명령들, 에러들
* TCP 플래그들
* 디코딩된 DHCP 프로토콜들로부터의 옵션 스트링들
* 의료용 디지털 영상 및 통신(DICOM)과 같은 디코딩된 IoT 프로토콜들로부터의 스트링들
* 국소 네트워크로부터의 인바운드 애플리케이션들의 리스트
* 인터넷으로부터의 인바운드 애플리케이션들의 리스트
* 국소 네트워크로의 아웃바운드 애플리케이션들의 리스트
* 인터넷으로의 아웃바운드 애플리케이션들의 리스트
* 국소 네트워크로부터의 인바운드 서버 포트들의 리스트
* 인터넷으로부터의 인바운드 서버 포트들의 리스트
* 국소 네트워크로의 아웃바운드 서버 포트들의 리스트
* 인터넷으로의 아웃바운드 서버 포트들의 리스트
* 국소 네트워크로부터의 인바운드 IP들의 리스트
* 인터넷으로부터의 인바운드 URL들의 리스트
* 국소 네트워크로의 아웃바운드 IP들의 리스트
* 인터넷으로의 아웃바운드 URL들의 리스트
몇몇 경우들에서, 512에서 결정된 신뢰 스코어는 매우 낮을 수 있다. 이것이 발생할 수 있는 하나의 이유는 디바이스가 새로운 유형이며(보안 플랫폼(140)에 의해 이전에 분석되지 않은 새로운 유형의 IoT 장난감 또는 다른 유형의 제품) 보안 플랫폼(140) 상에서 디바이스에 대해 이용 가능한 대응하는 패턴 ID가 없기 때문이다. 이러한 시나리오에서, 디바이스에 대한 정보 및 분류 결과들이 예컨대, 디바이스 및 다른 애플리케이션 정보에 의해 보여지는 거동들에 대한 클러스터링(514)을 수행할 수 있는(예컨대, 디바이스가 무선 디바이스이고, 프린터처럼 동작하며, DICOM 프로토콜을 사용한다고 결정하기 위해) 오프라인 프로세싱 파이프라인(506)으로 제공될 수 있다. 클러스터링 정보는 라벨들로서 이용되고 적용 가능한 경우, 자동으로 함께 그룹핑되는 임의의 그 다음에 보여지는 유사한 디바이스들을 갖고, 부가적인 연구(518)를 위해 플래그될 수 있다. 연구의 결과로서, 주어진 디바이스에 대한 부가적인 정보가 결정되면(예컨대, 새로운 유형의 소비자-지향 IoT 육류용 온도계에 대응하는 것으로 식별된다), 디바이스(및 유사한 성질들을 가진 모든 다른 디바이스들)가 그에 따라 재라벨링되며(예컨대, 브랜드 XYZ 육류용 온도계) 연관된 패턴 ID가 생성되고 적용 가능한 경우(예컨대, 모델들이 재구축된 후) 파이프라인들(502.504)에 의해 사용 가능해질 수 있다. 다양한 실시예들에서, 오프라인 모델링(520)은 IoT 디바이스 식별을 위해 사용된 다양한 모델들(522)을 트레이닝하고 업데이트하기 위해 매일 구동하는 프로세스이다. 다양한 실시예들에서, 모델들은 새로운 라벨링된 디바이스들을 커버하기 위해 매일 리프레시되며, 거동 변화들(느린 경로 파이프라인(502)에 대한)을 반영하고 한 주 동안 부가된 새로운 특징들 및 데이터 통찰들을 수용하기 위해 매주 재구축된다. 보안 플랫폼(140)에 새로운 유형들의 다비이스들을 부가할 때(즉, 새로운 디바이스 패턴들을 생성할 때), 다수의 기존의 디바이스 패턴들이 영향을 받아서, 특징들의 리스트 또는 그것들의 중요 스코어들이 업데이트되는 것을 요구하는 것이 가능하다는 것을 주의하자. 프로세스는 자동으로 수행될 수 있다(및 규칙-기반 솔루션과 비교하여 중대한 이점이다).
빠른 경로 모델링을 위해, 신경망-기반 모델들(예컨대, FNN) 및 일반 기계 학습 모델들(예컨대, XGB)이 다변량 분류 모델들을 위해 광범위하게 사용된다. 이진 모델들이 또한 결과들을 개선하고 클러스터링에 입력을 제공하도록 돕기 위해 선택된 프로필들에 대해 구축된다. 이진 모델은 디바이스의 아이덴티티, 또는 디바이스의 특정한 거동들에 예/아니오 대답들을 준다. 예를 들어, 이진 모델은 디바이스가 IP 전화의 유형인지 또는 IP 전화일 가능성이 없는지를 결정하기 위해 사용될 수 있다. 다변량 모델은 1의 확률로 정규화된 많은 출력들을 가질 것이다. 각각의 출력은 디바이스의 유형에 대응한다. 이진 모델들이 일반적으로 더 빠를지라도, 그것은 디바이스가 올바른 "예" 대답을 찾을 수 있도록 예측 시 그것들 중 많은 것을 겪을 것을 요구할 것이다. 다변량 모델은 하나의 단계에서 그것을 달성할 수 있다.
느린 경로 파이프라인(502)은 특징들이 추출된다(524)는 점에서 파이프라인(504)과 유사하다. 그러나, 파이프라인(502)에 의해 사용된 특징들은 통상적으로 구축하는데 일정 시간이 걸릴 것이다. 일 예로서, "하루에 보내어지는 바이트들의 수"의 특징은 수집하는데 하루를 요구할 것이다. 또 다른 예로서, 특정한 사용 패턴들은 발생하고 측정되는데 일정 시간이 걸릴 수 있다(예컨대, CT 스캐너는 매시간 스캔들을 수행하기 위해 사용되고(제1 거동), 매일 데이터를 백업하며(제2 거동), 매주 업데이트들을 위해 제조사의 웹사이트를 체크한다(제3 거동)). 느린 경로 파이프라인(502)은 전체 세트의 특징들 상에서 새로운 디바이스 인스턴스를 분류하려는 시도로 다변량 분류기(526)를 호출한다 사용된 특징들은 정적 또는 시퀀스 특징들에 제한되지 않지만, 또한 볼륨 및 시계열 기반 특징들을 포함한다. 이는 일반적으로 스테이지 1 예측으로 불리운다. 특정한 프로필들에 대해 스테이지 1 예측 결과가 최적이 아닐 때(더 낮은 신뢰도를 갖는), 스테이지 2 예측이 결과를 개선하려는 시도로 사용된다. 느린 경로 파이프라인(502)은 새로운 디바이스 인스턴스를 분ㄹ하기 위해 부가적인 유입 디바이스 콘텍스트에 의해 지원되는 의사결정 트리 분류기들(528)을 호출한다. 부가적인 디바이스 콘텍스트가 외부 소스로부터 유입된다. 예로서, 디바이스가 연결한 URL은 특징으로 포함될 수 있는 위험-기반 평판 및 카테고리를 제공받을 수 있다. 또 다른 예로서, 디바이스에 의해 사용된 애플리케이션은 특징으로 포함될 수 있는 위험 기반 스코어 및 카테고리를 제공받을 수 있다. 스테이지 1 예측(526) 및 스테이지 2 예측(528)으로부터의 결과를 조합함으로써, 느린 경로 분류의 최종 판정은 도출된 신뢰 스코어로 도달될 수 있다.
일반적으로 느린 경로 파이프라인(502)에 포함된 두 개의 스테이지들이 있다. 느린 경로 파이프라인에서, 몇몇 실시예들에서, 스테이지 1 모델들은 신경망 기법들에 기초하여, 다변량 분류기들을 갖고 구축된다. 느린 경로 파이프라인의 스테이지 2는 일반적으로 스테이지 1의 확률-관련 예외들을 다루기 위해 부가적인 논리를 가진 의사결정-기반 모델들의 세트이다. 예측 시, 스테이지 2는 스테이지 1로부터의 입력을 통합하여, 스테이지 1 출력을 검증하고 느린 경로의 최종 출력을 생성하기 위해 규칙들 및 콘텍스트를 적용할 것이다. 최종 출력은 디바이스의 아이덴티티, 전체 신뢰 스코어, 미래 빠른 경로 파이프라인(504)을 위해 사용될 수 있는 패턴 ID, 및 설명 리스트를 포함할 것이다. 신뢰 스코어는 모델의 신뢰성 및 정확도(모델들은 또한 신뢰 스코어들을 가진다), 및 분류의 부분으로서 확률에 기초한다. 설명 리스트는 결과에 기여하는 특징들의 리스트를 포함할 것이다. 상기 언급된 바와 같이, 결과가 알려진 패턴 ID들로부터 벗어난다면 조사가 트리거될 수 있다.
몇몇 실시예들에서, 느린 경로 모델링을 위해, 두 개의 유형들의 모델들이 구축되며 하나는 개인 아이덴티티에 대한 것이고, 하나는 그룹 아이덴티티에 대한 것이다. 종종 예를 들어, 온도계로부터 프린터를 구별하기 위해 상이한 벤더들로부터 또는 상이한 모델들을 가진 두 개의 프린터들 간에 차이를 말하는 것은 더 어렵다(예컨대, 프린터들이 네트워크 거동을 보이고, 유사한 프로토콜들을 말하려는 경향이 있기 때문에). 다양한 실시예들에서, 다양한 벤더들로부터의 다양한 프린터들은 그룹으로 포함되며, "프린터" 모델은 그룹 분류를 위해 트레이닝된다. 이러한 그룹 분류 결과는 특정 프린터에 대한 특정 모델보다 양호한 정확도를 제공할 수 있으며 디바이스의 신뢰 스코어를 업데이트하거나, 또는 적용 가능한 경우, 개인 프로필 아이덴티티-기반 분류에 기준 및 검증을 제공하기 위해 사용될 수 있다.
도 6은 IoT 디바이스를 분류하기 위한 프로세스의 예를 예시한다. 다양한 실시예들에서, 프로세스(600)는 보안 플랫폼(140)에 의해 수행된다. 프로세스(600)는 또한 적용 가능한 경우 다른 시스템들에 의해 수행될 수 있다(예컨대, IoT 디바이스들과 사내 같은 장소에 배치된 시스템들). 프로세스(600)는 602에서 IoT 디바이스의 네트워크 통신과 연관된 정보가 수신될 때 시작한다. 일 예로서, 이러한 정보는 데이터 기기(102)가 주어진 IoT 디바이스에 대한 디바이스 탐색 이벤트를 그것에 전송할 때 보안 플랫폼(140)에 의해 수신된다. 604에서, 디바이스가 분류되지 않았다(또는, 적용 가능한 경우, 재-분류가 수행되어야 한다)는 결정이 이루어진다. 일 예로서, 플랫폼(140)은 디바이스가 분류되었는지 여부를 결정하기 위해 데이터베이스(286)에 질의할 수 있다. 606에서, 2-파트 분류가 수행된다. 예로서, 2-파트 분류는 606에서 플랫폼(140)에 의해 수행되어 디바이스에 대한 정보를 빠른 경로 분류 파이프라인(504) 및 느린 경로 분류 파이프라인(502) 둘 모두에 제공한다. 마지막으로, 608에서, 베이스라인 모델링(290)으로부터의 요약된 네트워크 거동과 함께, 606에서 수행된 분류 프로세스의 결과가 IoT 디바이스에 정책을 적용하도록 구성된 보안 기기로 제공된다. 이러한 요약된 네트워크 거동의 예들은 IoT 디바이스 프로필들에 대한 기계-학습 트레이닝된 베이스라인 모델들로부터 "추출"될 수 있는 보안 기기 정책을 형성하도록 도울 수 있는 가장 많이 사용된 애플리케이션들, URL들, 및 다른 속성들을 포함한다. 상기 언급된 바와 같이, 이는 매우 정교한 보안 정책들이 최소 관리 노력을 갖고 잠재적으로 미션 크리티컬 환경들에서 구현되는 것을 허용한다.
프로세스(600)를 수행하는 제1 예에서, Xbox One 게임 콘솔이 네트워크(110)에 연결되었다고 가정하자. 분류 동안, 디바이스가 다음의 우세한 특징들을 갖는다는 결정이 이루어질 수 있다: 100% 신뢰도를 가진 "벤더 = 마이크로소프트" 특징, 89.7% 신뢰도를 가진 "마이크로소프트 클라우드 서버와의 통신" 특징, 및 78.5% 신뢰도를 가진 "게임 콘솔" 특징과 일치한다. 이들 3개의 특징들/신뢰 스코어들은 전체로서 디바이스를 Xbox One 게임 콘솔인 것으로 식별하기 위해(즉, 512에서 임계치를 만족하는 프로필 ID 매치가 발견됨) 프로필 ID들의 세트에 대해 매칭될 수 있다(신경망-기반 예측에 의해 행해진 프로세스). 제2 예에서, AudioCodes IP 전화가 네트워크(110)에 연결되었다고 가정하자. 분류 동안, 디바이스가 100% 신뢰도를 가진 "벤더 = AudioCodes" 특징, 98.5% 신뢰도를 가진 "IP 오디오 디바이스인" 특징, 및 66.5%를 가진 "국소 서버처럼 동작" 특징과 일치한다는 결정이 이루어질 수 있다. 이들 3개의 특징들/신뢰 스코어들은 또한 프로필 ID들의 세트에 대해 매칭되지만, 이 시나리오에서 어떤 기존의 프로필 ID도 충분한 신뢰도를 갖고 매칭되지 않는다고 가정한다. 디바이스에 대한 정보는 그 후 클러스터링 프로세스(514)로 제공될 수 있으며, 적용 가능한 경우, 새로운 프로필 ID가 궁극적으로 생성되고 디바이스와 연관될 수 있다(및 미래 디바이스들을 분류하기 위해 사용될 수 있다).
적용 가능한 경우, 보안 플랫폼(140)은 이하에서 더 상세하게 설명되는, 결정된 분류 정보에 기초하여 특정한 정책들을 추천할 수 있다. 다음은 시행될 수 있는 정책들의 예들이다:
* 모든 주입 펌프들에 대한 인터넷 트래픽을 거부한다(벤더에 관계없이)
* GE 호스트들로부터/로를 제외하고 모든 GE ECC 기계들에 대한 인터넷 트래픽을 거부한다
* 모든 CT 스캐너들에 대해 화상 아카이빙 및 통신 시스템(PACS) 서버들로의 내부 트래픽만을 허용한다(벤더에 관계없이)
VI. 방화벽에서 IOT 보안 정책
상기 언급된 바와 같이, IoT 디바이스들은 종종 네트워크 상에서 관찰될 수 있는 미리 정의된 거동들을 가진 특수 목적 디바이스들(랩탑들과 같은 일반 컴퓨팅 디바이스들과 대조적으로)이다. 일 예로서, 제조사(예컨대, GE 또는 Fujitsu)에 관계없이, CT 스캐너는 하나 이상의 특정 프로토콜들을 사용하여 캡처된 환자 이미지들을 검사할 의료 스태프에 대한 네트워킹된 이미지 서버로(예컨대, 서버로의 인터페이스를 통해) 전송하는 것과 같이, 다른 CT 스캐너들과 마찬가지로 네트워크 상에서 유사한 기능을 가지며 유사한 거동들을 보일 것이다. 다른 유형들의 시스템들(예컨대, 난방, 환기, 및 냉방(HVAC) 시스템들)은 유사한 통상적으로 미리 정의된 거동들(즉, 특정한 프로토콜을 통해 1분에 한 번 온도 값을 서버로 보고하는)의 그 자신의 세트를 보일 것이다.
상기 언급된 바와 같이, 관찰된(예컨대, 데이터 기기(102)에 의해) 트래픽으로부터의 이들 거동들의 분석(예컨대, 보안 플랫폼(140)에 의해)은 특정한 IoT 디바이스들이 식별되는 것을 허용한다(디바이스의 특정한 인스턴스들, 디바이스의 모델, 디바이스의 제조사, 디바이스의 유형 등을 식별함으로써를 포함하여). 뿐만 아니라, 디바이스 식별의 부산물은 분류의 목적을 위해 트레이닝된(예컨대, 베이스라인 모델링 엔진(290)에 의해) 디바이스 베이스라인 모델을 가질 것이다. 적용 가능한 경우, 이상 검출 모듈(248)은 디바이스(또는 디바이스들의 그룹)에 대한 베이스라인을 생성할 때 알려진 이상 거동들을 걸러내기 위해 사용될 수 있다. 이러한 심층 기계 학습 모델은 상기 설명된 네트워크 거동을 캡처한다. 이러한 베이스라인 모델은 디바이스 아이덴티티 예측에서 사용될 뿐마 아니라, 또한 네트워크 거동이 디바이스 프로필에서 얼마나 인기있어 보이는지에 의해 랭크된 거동 요약들의 공통 리스트를 생성하기 위해 사용될 수 있다. 거동 요약에 대한 하나의 접근법은 XGB와 같은 ML 알고리즘들을 사용하여, 트레이닝 프로세스 동안 베이스라인 모델로부터 최상위 기여 특징들(디바이스 식별에서 사용된)을 추출하고 랭크하는 것이다. 다른 접근법들이 또한 사용되거나 또는 조합될 수 있다(예컨대, 휴리스틱 접근법들). 최상위 기여 특징들(신뢰성/신뢰도 임계치를 조건으로)은 필수적으로 트레이닝에서 사용된 수 천개의 속성들 또는 특징들로부터, 디바이스의 유형이 보이는 가장 일반적인 네트워크 거동들이 무엇인지를 강조하며 추천들에서 사용될 수 있다(예컨대, 특정한 URL들, 프로토콜들 등을 화이트리스팅/블랙리스팅함). 거동 요약들은 어떤 애플리케이션들이 사용되는지, 특정한 네트워크 도메인들에 어떤 연결들이 이루어지는지, 애플리케이션에서 어떤 페이로드가 운반되는지, 볼륨, 통신의 시간 및 빈도 등을 포함할 수 있다. 각각의 속성은 "드뭄", "종종" 또는 "규칙적"과 같은 빈도 카테고리를 할당받는다. 각각의 속성은 또한 "시간당 1MB 미만"과 같은 범위 카테고리를 할당받을 수 있다. 이상들(예컨대, 손상되거나 또는 오작동/오구성된 IoT 디바이스들)이 베이스라인들로부터의 편차들로서 검출될 수 있다(예컨대, 이상 검출 모듈(248)과 함께 작동하는 데이터 기기(102)에 의해). 이들 속성들(및 특정한 공격들에 대한 알려진 취약성들)은 특정한 IoT 디바이스, 디바이스의 유형 등과 연관된 네트워크 활동 등을 제한하기 위한 추천된 방화벽 정책을 자동으로 생성하기 위해 블루프린트로서 사용될 수 있다. 예를 들어, 규칙적으로 사용된 애플리케이션 및 URL은 "허용" 방화벽 정책을 구축하기 위해 사용될 수 있다. 또 다른 예에서, 베이스라인 거동의 부분이 아닌 애플리케이션은 "거부" 방화벽 정책을 구축하기 위해 사용될 수 있다. 사용자들은 수십 만개의 유사한 디바이스들로부터 요약된 네트워크 거동의 빈도에 기초하여 정책을 조정할 수 있을 것이다. 임의의 알려진 취약성들(예컨대, 특정한 공격에 대한 특정한 디바이스의 민감성)은 적용 가능한 경우, 별도로 모델링되며 추천된 정책들로 통합될 수 있다. 주어진 디바이스 유형에 대한 최상위 특징의 예는 디바이스가 특정한 URL(예컨대, www.siemens.com/updates)에서 거의 매일 한 번 업데이트를 체크하는 것이다. 디바이스 유형을 공유하는 임계 수의 디바이스들이 유사한 베이스라인 거동을 보인다면, 특징은 상기 디바이스 유형과 연관된 디바이스 프로필들에 대한 추천된 화이트리스트 아이템으로서 선택될 수 있다.
도 7a는 Acme가 네트워크(110) 내에 배치할 수 있는 CT 스캐너/이미지 서버에 관계된 정책들의 세트를 구현하는 제1 접근법을 예시한다. 특히, Acme는 두 개의 유형들의 CT 스캐너들(GE 및 Fujitsu에 의해 만들어짐)을 배치하였다고 가정하자. 네트워크(110)의 관리자(이후 찰리(Charlie)로 불리움)는 인터페이스(예컨대, 적용 가능한 경우 데이터 기기(120) 및/또는 보안 플랫폼(140)에 의해 제공되는)와 상호작용하며 네트워크(110) 내에서 각각의 CT 스캐너 및 이미지 서버에 대해, 그것들이 통신하도록 허용되는 프로토콜들, 포트들, 및 IP 어드레스들을 수동으로 특정할 수 있다. 불운하게도, 이 접근법은 시간 소모적이며 에러가 발생하기 쉬울 수 있다. 일 예로서, 새로운 CT 스캐너가 환경에 부가될 때, 찰리는 도 7a에 도시된 규칙들을 수동으로 부가하며, 또한 잠재적으로 규칙들 중 일부를 변경/제거할 필요가 있을 것이다(예컨대, 새로운 CT 스캐너가 기존의 것을 교체하고 및/또는 네트워크 정보가 변한다면). 환경에서 IoT 디바이스들의 총 수가 낮으며 IoT 디바이스들이 정적 IP 어드레스들을 할당받는다면, 도 7a에 도시된 바와 같은 규칙들의 수동적 유지관리는 실현 가능할 수 있다. 그러나, 실제로, 주어진 환경은 수백 또는 수천 개의 IoT 디바이스들(또는 그 이상)을 가질 수 있고, 및/또는 DHCP를 사용할 수 있으며, 규칙들의 수동적 유지관리는 실현 가능하지 않다.
대안적인 접근법은 본원에서 설명된 기법들에 따라, 애플리케이션들(예컨대, 의료용 이미징 정보를 전달하기 위해 사용된 네트워크 트래픽에 대응하는 특정한 프로토콜들/포트들 등을 나타내는 "DICOM-App") 및 디바이스 유형들(예컨대, GE-Xray-Device)을 추상화하는 것이다. 도 7a에 도시된 규칙들의 추상화는 도 7b에서 묘사된다. 물론, 찰리는 관련 있는 IP 어드레스들, 포트들, 또는 프로토콜들을 IoT 정책들에 제공할 필요가 없으며, 오히려 추상화 애플리케이션 유형들 및 디바이스 유형들을 사용할 수 있다. 도 7b에 도시된 바와 같은 정책들은 데이터 기기(102)에 의해 런타임 시 컴파일링되고 사용될 수 있다. 컴파일링 동안, 추상화 요소들(예컨대, GE-Xray-Device)은 데이터 기기에 저장된 정보(APP-ID 정보, IP 정보, 및/또는 디바이스 유형들의 사전과 같은)에 기초하여, 교체될 것이다(예컨대, 상기 디바이스 식별과 일치하는 각각의 IoT 디바이스의 IP 어드레스로).
찰리는 IoT 디바이스 규칙들을 수동으로 기록하는 것을 택할 수 있지만(예컨대, 원한다면 앞서 언급한 추상화들을 사용하여), 또한 보안 플랫폼(140)에 의해 정책 추천들을 제공받을 수 있다. 추천들은 다야한 실시예들에서, 디바이스 프로필들(디바이스 유형 또는 다른 정보를 포함하는) 및 다양한 특성들을 공유하는 디바이스들의 세트의 베이스라인/통상적인 거동(많은 상이한 고객 환경들/배치들에 걸쳐)에 기초한다. 찰리가 추천된 정책들을 수용한다면, 적절한 규칙들(예컨대, 도 7b에 도시된 바와 같은 규칙들)이 자동으로 생성되며(예컨대, 보안 플랫폼(140)에 의해) 시행을 위해 보안 기기(102)로 유입될 수 있다. 보안 기기(102)는 그것의 네트워크 상에서 IoT 디바이스들의 디바이스 프로필들을 학습하며 소스들 또는 목적지들로서 디바이스들에 적용 가능한 정책들을 매칭시킬 것이다. 적용 가능한 경우, 정책들은 네트워크 액세스 제어기들과 같은, 보안 기기(102) 외에 다른 기반시설의 유형들에 의해 사용 가능한 포맷들로 변환될 수 있다(예컨대, 보안 플랫폼(140)에 의해).
다음의 논의에서, Acme가 최근에 빌딩 자동화 디바이스들의 세트(예컨대, 배지 판독기들의 세트)를 구매하였고, 다양한 Acme 설비들 안에 그것들을 설치하였으며, 온라인으로 디바이스들을 네트워크(110)의 일 부분으로 가져왔다고 가정하자. 상기 설명된 디바이스 식별/분류 기법들을 사용하여, 보안 플랫폼(140)(데이터기기(102)와 함께 작동하는)은 Acme가 28개의 새로운 배지 판독기 디바이스들을 그 네트워크에 부가하였음을 식별하며 그것들이 동작함에 따라(예컨대, 한 주 또는 한 달의 초기 관찰 기간 동안) Acme의 네트워크 환경 내에서 이들 특정 배지 판독기 디바이스들에 의해 취해진 다양한 거동들을 학습할 것이다. 보안 플랫폼(140)에 의해 제공된 관리 인터페이스의 일 부분이 도 8에서 도시된다. 인터페이스(800)는 Acme가 현재 그 환경에서 동작하는 총 65개의 종류의 IoT 디바이스들(대응하는 프로필들을 가짐)을 갖는다고 나타낸다. 새롭게 부가된 배지 판독기들이 로우(802)에 묘사된다.
찰리가 링크(804)를 클릭하면, 그는 도 9에 도시된 인터페이스로 가게 될 것이다. 영역(902)은 보안 플랫폼(140)이 28개의 새로운 디바이스들을, 높은 신뢰도를 갖고 Siemens Building Technology Device 프로필과 일치하는 것으로 식별하였음을 나타낸다. Acme 환경 내에서 동작하는 동안 28개의 디바이스들에 대해 수집된 거동 정보가 또한 도시되며, 영역(904)에서 요약된다. 전체로서, 28개의 디바이스들은 Acme 환경에서 8개의 애플리케이션들을 구동하고, 23개의 목적지들(22개의 Acme 내이며 하나는 밖)과 통신하며, 현재 56의 위험 스코어를 가진다. 28개의 디바이스들 중 얼마나 많이 Acme 환경 내에서 각각의 애플리케이션을 사용하고 있는지에 대한 카운트가 영역(906)에 도시되며, 목적지들이 내부인지 또는 외부인지가 영역(908)에 도시된다. 이들 디바이스들(동일한 Siemens Building Technology Device 프로필을 공유하는)이 보안 플랫폼(140)의 다른 고객들의 환경들에 걸쳐 어떻게 거동하는지와 대조적으로 Acme 환경에서 Siemens Building Technology Device 디바이스들에 의해 사용된 애플리케이션들의 수의 비교가 영역(910)에 포함된다. 영역(910)에 표시된 바와 같이, Siemens Building Technology Device들의 통상적인 고객 배치는 3개 내지 5개의 애플리케이션들(912)을 사용하여, Acme의 배치가 통상적인 범위(914) 밖이도록 한다. 찰리가 그의 커서를 영역(912) 위에서 맴돈다면, 그는 다음과 같은, 비교에 대한 부가적인 정보를 제공하는 박스를 제공받을 것이다:
"8개의 상이한 애플리케이션들이 이 프로필에서 디바이스들에 의해 사용되었다. 모든 IoT 보안 고객들로부터의 데이터에 기초하여, 사용된 애플리케이션들의 최소 수는 3이고, 평균은 3이며, 최대는 5였다. 당신의 Siemens Building Technology Device 디바이스들에 의한 애플리케이션 사용은 평소보다 높았다. 애플리케이션 리스트를 검토하시오".
찰리는 인터페이스(900)를 더 아래로 스크롤함으로써 애플리케이션 리스트를 검토할 수 있다. 도 10에 도시된 바와 같이, 찰리는 이러한 스크롤링 후 "dhep" 및 "bacnet" 애플리케이션들의 배지 판독기 디바이스들에 의한 사용을 검토한다. "사용" 목적지(1002)느 네트워크 사용 패턴들의 빈도(디바이스 프로필 + 애플리케이션 + URL(예컨대, "www.siemens.com/update")) 및/또는 프로필을 공유하는 IoT 디바이스들에 대한 목적지 프로필(예컨대, "PACS 서버")을 나타낸다. 다양한 실시예들에서, 각각의 애플리케이션에 대한 사용은 한 달의 처음 수집된 트래픽에 기초하여 생성된다. 찰리는 그가 특정한 거동들을 허용 또는 차단하기를 원하는지를 결정하는데 사용 정보를 사용할 수 있다. 예를 들어, 그는 bacnet이 빈번하지 않게 사용된다는 것을 고려할 때, 단지 내부 도메인들만이 허용되거나, 또는 단지 미리 결정된 외부 도메인들에만 허용되어야 한다(예컨대, Acme의 환경에 대한 그의 지식에 기초하여)는 것을 학습할 수 있다.
찰리가 인터페이스(900)의 영역(916)을 클릭하면, 그는 배지 판독기 디바이스들에 적용될 수 있는 정책들의 세트를 생성하기 위한 두 개의 옵션들을 제공받을 것이다. 이전에 언급된 바와 같이, 찰리는 배지 판독기 디바이스들에 대한 그 자신의 정책 세트(들)를 수동으로(예컨대, 인터페이스(900)의 실시예의 다양한 요소들과 상호작용함으로써) 생성할 수 있다. 찰리는 또한 보안 플랫폼(140)이 보안 플랫폼(140)의 다른 고객들의 환경들로부터 획득된 베이스라인/다른 정보를 사용하여 생성한 추천된 정책 세트를 로딩하기로 택할 수 있다. 일단 영역(916)을 클릭하고 추천된 정책 세트(이용 가능하다면)를 사용하기로 택한다면, 보안 플랫폼(140)은 임의의 이용 가능한 추천된 정책 세트들을 나열할 것이며 찰리는, 적용 가능한 경우 정책들을 개선/조정할 능력을 갖고(예컨대, 인터페이스(800)에 의해 제공된 다양한 기능과 상호작용함으로써), 그것들을 Acme 환경으로 다운로드/적용할 수 있다.
도 11은 IoT 디바이스를 수반한 통신에 적용할 정책을 생성하기 위한 프로세스의 예를 예시한다. 다양한 실시예들에서, 프로세스(1100)는 보안 플랫폼(140)에 의해 수행된다. 프로세스(1100)는 또한 적용 가능한 경우 다른 시스템들(예컨대, Iot 디바이스들을 갖고 사내 같은 장소에 배치된 시스템)에 의해 수행될 수 있다. 프로세스(1100)는 1102에서 IoT 디바이스의 네트워크 통신과 연관된 정보가 수신될 때 시작한다. 일 예로서, 이러한 정보는 보안 플랫폼(140)에 의해, 데이터 기기(102)가 주어진 IoT 디바이스(예컨대, 배지 판독기 디바이스)에 대한 디바이스 탐색 이벤트를 그것에 전송할 때 수신된다. 1104에서, 수신된 정보는 IoT 디바이스와 연관시킬 디바이스 프로필을 결정하기 위해 사용된다. 예로서, IoT 디바이스가 특정한 일련/MAC 어드레스, 특정한 IP 어드레스 등을 가진, Simens SIMATEC RF10000 디바이스라는 결정이 이루어진다. 이 예에서, 결정된 "디바이스 유형"는 "Siemens Building Technology Device"일 수 있다. 디바이스 유형들(예컨대, 배지 판독기 디바이스) 및 디바이스 프로필들(예컨대, Siemens Building Technology Device)은 일반적으로 이 섹션에서 상호 교환 가능하게 참조된다. 그러나, 다수의 프로필들이 주어진 디바이스 유형(예컨대, Acme의 연구소 영역 대 Acme의 소매점 영역에 위치된 Siemens Building Technology Device 디바이스들)에 대해 생성될 수 있으며, 주어진 프로필은 적용 가능한 경우 다수의 디바이스 유형들을 포함할 수 있다(예컨대, Siemens Building Technology Device 프로필은 배지 판독기 디바이스들 및 모션 트리거 센서들을 포함할 수 있다). 마지막으로, 1106에서, 보안 기기에 의해 IoT 디바이스에 적용될 추천 정책이 생성된다. 일 예로서, 도 9에 도시된 모두 8개의 애플리케이션들로의 액세스를 허용하는 대신에, 보안 기기(140)는 영역(910)에 도시된 정보에 대응하는 단지 3개의 가장 흔히 사용된 배지 판독기 애플리케이션들(또는 5개의 가장 흔히 사용된 배지 판독기 애플리케이션들)을 허용하는 정책 세트를 추천할 수 있다. 일단 추천 정책을 다운로드하고 적용한다면, 찰리가 추천 세트에 대한 조정들(예컨대, 화이트리스트 bacnet)을 할 필요가 있다면, 그는 그렇게 할 수 있다(예컨대, 인터페이스(800)에 의해 제공된 "편집" 옵션과 상호작용함으로써).
앞서 말한 실시예들은 이해의 명료함을 위해 약간 상세히 설명되었지만, 본 발명은 제공된 세부사항들에 제한되지 않는다. 본 발명을 구현하는 많은 대안적인 방식들이 있다. 개시된 실시예들은 예시적이며 제한적이지 않다.

Claims (17)

  1. 시스템에 있어서,
    프로세서로서:
    사물 인터넷(IoT) 디바이스의 네트워크 통신과 연관된 정보를 수신하고;
    상기 IoT 디바이스와 연관시키도록 디바이스 유형을 포함하는 디바이스 프로필을 결정하기 위해 상기 수신된 정보를 사용하고;
    상기 디바이스 프로필에 적어도 부분적으로 기초하여, 보안 기기에 의해 상기 IoT 디바이스에 적용될 추천 보안 정책을 생성하도록 구성된, 상기 프로세서; 및
    상기 프로세서에 결합되어 상기 프로세서에 지시들을 제공하도록 구성된 메모리를 포함하는, 시스템.
  2. 제1항에 있어서, 상기 프로세서는 또한 상기 IoT 디바이스가 이전에 분류되었는지를 결정하도록 구성되는, 시스템.
  3. 제2항에 있어서, 상기 프로세서는 또한, 상기 IoT 디바이스가 이전에 분류되지 않았음을 결정하는 데 응답하여, 분류 프로세스를 수행하도록 구성되는, 시스템.
  4. 제3항에 있어서, 상기 분류 프로세스를 수행하는 것은 인라인 분류 및 상기 인라인 분류의 후속 검증을 수행하는 것을 포함하는, 시스템.
  5. 제1항에 있어서, 상기 프로세서는 또한 상기 보안 정책을 적용하기 위해 상기 보안 기기에 의해 사용 가능한 지시들을 생성하도록 구성되는, 시스템.
  6. 제5항에 있어서, 상기 지시들을 생성하는 것은 상기 보안 정책을 벤더-특정 지시들로 변환하는 것을 포함하는, 시스템.
  7. 제1항에 있어서, 상기 정보는 상기 보안 기기로부터 수신되는, 시스템.
  8. 제1항에 있어서, 상기 수신된 정보는 네트워크 트래픽 메타데이터를 포함하는, 시스템.
  9. 제1항에 있어서, 상기 프로세서는 상기 디바이스 프로필을 복수의 다른 디바이스 프로필들에 비교하는 것에 의해 적어도 부분적으로 기초하여 상기 추천 보안 정책을 생성하도록 구성되는, 시스템.
  10. 제9항에 있어서, 상기 복수의 다른 디바이스 프로필들은 디바이스 유형을 공유하는 복수의 다른 디바이스들에 대응하는, 시스템.
  11. 제10항에 있어서, 상기 IoT 디바이스는 제1 네트워크 환경에 위치하고 상기 IoT 디바이스와 디바이스 유형을 공유하는 적어도 하나의 다른 디바이스는 상기 제1 네트워크 환경과 상이한 제2 네트워크 환경에 위치하는, 시스템.
  12. 제10항에 있어서, 상기 디바이스 프로필을 상기 복수의 다른 디바이스 프로필들에 비교하는 것은 상기 디바이스 유형을 공유하는 복수의 다른 디바이스들 중 적어도 일부로부터 상기 IoT 디바이스의 거동 편차(behavioral deviation)를 결정하는 것을 포함하는, 시스템.
  13. 제1항에 있어서, 상기 디바이스 유형은 상기 IoT 디바이스의 특정한 모델을 특정하는, 시스템.
  14. 제1항에 있어서, 상기 디바이스 유형은 상기 IoT 디바이스의 특정한 벤더를 특정하는, 시스템.
  15. 제1항에 있어서, 상기 디바이스 유형은 상기 디바이스에 의해 제공된 기능을 특정하는, 시스템.
  16. 방법으로서:
    사물 인터넷(IoT) 디바이스의 네트워크 통신과 연관된 정보를 수신하는 단계;
    상기 IoT 디바이스와 연관시키도록 디바이스 유형을 포함하는 디바이스 프로필을 결정하기 위해 상기 수신된 정보를 사용하는 단계; 및
    상기 디바이스 프로필에 적어도 부분적으로 기초하여, 보안 기기에 의해 상기 IoT 디바이스에 적용될 추천 보안 정책을 생성하는 단계를 포함하는, 방법.
  17. 유형의 컴퓨터 판독 가능한 저장 매체(tangible computer readable storage medium)에 저장된 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 프로그램은 컴퓨터 지시들을 포함하고,
    상기 컴퓨터 지시들은:
    사물 인터넷(IoT) 디바이스의 네트워크 통신과 연관된 정보를 수신하고;
    상기 IoT 디바이스와 연관시키도록 디바이스 유형을 포함하는 디바이스 프로필을 결정하기 위해 상기 수신된 정보를 사용하고;
    상기 디바이스 프로필에 적어도 부분적으로 기초하여, 보안 기기에 의해 상기 IoT 디바이스에 적용될 추천 보안 정책을 생성하기 위한 것인, 컴퓨터 프로그램 제품.
KR1020247006784A 2021-09-29 2022-09-28 방화벽에서의 iot 보안 정책 KR20240034858A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/489,159 2021-09-29
US17/489,159 US20220095092A1 (en) 2020-06-01 2021-09-29 Iot security policy on firewall
PCT/US2022/045113 WO2023055851A1 (en) 2021-09-29 2022-09-28 Iot security policy on a firewall

Publications (1)

Publication Number Publication Date
KR20240034858A true KR20240034858A (ko) 2024-03-14

Family

ID=85780858

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020247006784A KR20240034858A (ko) 2021-09-29 2022-09-28 방화벽에서의 iot 보안 정책

Country Status (2)

Country Link
KR (1) KR20240034858A (ko)
WO (1) WO2023055851A1 (ko)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10511620B2 (en) * 2016-10-31 2019-12-17 Armis Security Ltd. Detection of vulnerable devices in wireless networks
US20190089747A1 (en) * 2017-09-19 2019-03-21 Cisco Technology, Inc. Protecting secure session from iot gateways
US11115799B1 (en) * 2020-06-01 2021-09-07 Palo Alto Networks, Inc. IoT device discovery and identification

Also Published As

Publication number Publication date
WO2023055851A1 (en) 2023-04-06

Similar Documents

Publication Publication Date Title
US11722875B2 (en) IoT device discovery and identification
US11496461B2 (en) Gateway management for a zero trust environment
US11520792B2 (en) Distributed cardinality optimization
US20210377215A1 (en) Automating iot device identification using statistical payload fingerprints
US20230231860A1 (en) Iot device identification by machine learning with time series behavioral and statistical features
US20240098062A1 (en) Iot device application workload capture
US11799858B2 (en) Network entity ID AAA
US20230125310A1 (en) Iot device identification with packet flow behavior machine learning model
US20220095092A1 (en) Iot security policy on firewall
US20230095870A1 (en) Iot security event correlation
US20230188540A1 (en) Iot adaptive threat prevention
KR20240034858A (ko) 방화벽에서의 iot 보안 정책
US11683345B2 (en) Application identity-based enforcement of datagram protocols
US20240129297A1 (en) Domain ownership verification for a ztna service platform
US20230082289A1 (en) Automated fuzzy hash based signature collecting system for malware detection
US20230231857A1 (en) Deep learning pipeline to detect malicious command and control traffic