디지털화의 가속화와 함께 사이버 공격은 과거보다 정교하고 지능적으로 진화하고 있습니다. 단순한 포트 스캐닝에서 악성코드 유포, 정보 탈취, 봇넷 연결 등 네트워크를 통한 공격은 탐지 시스템의 허점을 노리는 형태로 진화하고 있고, 트래픽이나 payload를 암호화하고, 의도적으로 조작한 패킷 구조를 통해 보안 시스템을 우회하고 있습니다[1]. 과거에는 이러한 네트워크 공격을 탐지하기 위해 주로 정형화된 메타 정보인 포트 번호, 플로우 길이, 세션 지속 시간 등을 기반으로 통계적 이상 탐지 방식이 주로 사용되었습니다[2]. 이 방법은 비교적 가볍고 실시간 처리가 용이하다는 장점이 있었지만, 공격자의 공격 방법이 고도화되면서 단순한 패턴으로만 탐지하기 어려운 한계에 봉착하게 되는 문제가 발생합니다[3].
이러한 한계를 극복하고자 최근에는 자연어 처리(NLP) 기술을 활용하여 비정형 데이터인 payload를 이용한 탐지 방식이 등장하고 있습니다. payload는 실제 공격 명령어나 악성 코드의 일부가 포함된 트래픽의 내용 그 자체 이기 때문에, 텍스트 패턴을 분석하는 NLP 기반 모델(BERT, GPT 등)이 상대적으로 높은 탐지 성능을 가지게 됩니다[4]. 하지만 현실의 네트워크 트래픽을 들여다보면 모든 데이터가 유의미한 payload를 가지고 있는 것은 아닙니다. 암호화된 트래픽, keep-alive 메시지, 정상적인 HTML/JSON 통신 등은 탐지에 큰 도움이 되지 않으며, 오히려 노이즈로 작용하기도 하기도 하고, 일부 악성 트래픽은 payload 자체가 없거나 완전히 비어 있는 경우도 많습니다. 예를 들어, C2(Command and Control) 연결 수립 단계, 비콘(Beaconing) 패킷, 포트 스캔과 같은 정찰 활동에서는 의도적으로 payload를 최소화하거나 제거하여 탐지를 우회하는 전략이 흔히 사용됩니다[5][6]. 그래서 최근 보안 분야에서는 정형 데이터(플로우 통계 정보)와 비정형 데이터(payload)를 함께 활용하는 하이브리드 탐지 모델이 각광받고 있습니다. 이 접근법은 서로 다른 형태의 데이터를 결합하여 보다 풍부한 정보 기반 탐지를 가능하게 하며, 정확도와 탐지 범위를 동시에 향상시킬 수 있습니다. 본 블로그 시리즈의 첫 번째 글인 이번 글에서는 하이브리드 모델을 위한 데이터 전처리의 기본 원칙과 실제 수행 과정을 소개합니다. 이어지는 시리즈에서는 탐지 모델 설계, 설명 가능한 인공지능(XAI) 적용까지 단계적으로 설명할 예정입니다.
전처리 : 탐지 모델의 기초 체력
그림 1. Wireshark로 확인한 Raw pacp 파일의 포트 스캔 트래픽 예시
네트워크 사이버 위협 탐지에서 가장 먼저 마주하는 데이터는 바로 pcap(packet capture) 파일입니다. pcap은 네트워크 상의 모든 패킷을 시간 순서대로 기록한 형식으로, 탐지 모델의 학습과 예측을 위한 원천 데이터(raw data)로 사용됩니다. 이러한 pcap 파일을 사람이 시각적으로 쉽게 분석할 수 있도록 도와주는 도구가 바로 Wireshark입니다. Wireshark는 네트워크 패킷을 실시간으로 캡처하고 분석할 수 있는 대표적인 오픈소스 네트워크 분석 툴로, 전처리 이전에 트래픽 흐름의 특성을 빠르게 파악하거나 탐지 조건을 검증하는 데 유용하게 활용됩니다. 그림 1은 Wireshark를 이용해 실제 포트 스캔 트래픽을 시각화한 예시입니다. 이 예시에서는 192.168.10.120이 다수의 목적지 포트(예: 30718, 64869, 60145 등)에 대해 빠르게 연결을 시도하고 있으며, 각 패킷은 FIN, ACK, RST 등의 플래그를 포함하여 포트가 열려 있는지를 탐색하는 전형적인 포트 스캐닝 행위를 보여줍니다.
하지만, 이러한 데이터는 사람이 바로 이해하거나 머신러닝 모델이 학습하기에는 구조가 너무 복잡합니다. 따라서 이를 정형 정보(Flow 통계)와 비정형 정보(payload)로 나누고, 각각의 목적에 맞게 가공하는 전처리 과정이 필수적입니다. 특히 하이브리드 탐지 모델은 정형 데이터(Flow 통계 정보)와 비정형 데이터(payload)를 동시에 학습하는 구조이기 때문에, 서로 다른 형식의 데이터를 결합하기 위해서는 각 데이터의 특성에 맞는 전처리 하여 정확하게 정제하고 구조화하는 것이 탐지 성능의 기초 체력을 결정짓습니다.
정형 데이터는 주로 ‘Flow Duration’, ‘Packet Length’, ‘Idle Time’ 등과 같이 네트워크 흐름의 통계적 특징을 포함하고 있으며, 머신러닝 모델(MLP, XGBoost 등)에 바로 사용할 수 있도록 정규화 및 정형화된 수치 정보로 구성됩니다. 반면, 비정형 데이터인 payload는 패킷 내부의 실제 전송 내용으로, 대부분 텍스트 또는 바이너리 형태로 구성되어 있으며, 자연어 처리 기반 모델(BERT 등)에 입력하기 위해선 문자열 디코딩, 토큰화, 필터링 등 별도의 가공 과정이 필요합니다.
즉 pcap -> Flow/payload 추출 -> 전처리 -> 모델 입력 이라는 구조로 진행되며 다음과 같은 전처리 과정을 병행해야 합니다:
- 정형 데이터 → 통계 기반 피처 정제 및 결측치 처리
- 비정형 데이터 → 텍스트 기반 payload 변환 및 토크나이징
- 모델 입력 → 병합 또는 병렬 구조로 변환
그렇다면 이제부터 각각의 전처리 과정을 하나씩 살펴보겠습니다.
정형 데이터 전처리: 네트워크 흐름의 통계 정보 다듬기
정형 데이터 전처리는 네트워크 트래픽의 원천인 pcap 파일에서 Flow 단위의 통계 피처를 추출하는 과정으로 시작됩니다. pcap파일은 개별 패킷의 송수신 정보를 시간 순서대로 저장한 형식이며, 이를 그대로 사용하는 것은 탐지 모델에 부담이 크기 때문에 플로우(Flow) 단위로 집계하고, 각 흐름에 대한 수치적 특징을 추출하는 방식이 일반적입니다.
Flow는 일반적으로 5가지 혹은 7가지 정보가 동일한 집합으로 아래 구성과 같습니다.
표 1. 네트워크 플로우 구성 시 사용되는 주요 식별 키
| key 이름 | 설명 |
| Source IP | 통신을 시작한 장치의 IP 주소 (발신 측) |
| Destination IP | 통신을 수신하는 장치의 IP 주소 (수신 측) |
| Source Port | 출발지 애플리케이션을 구분하기 위한 포트 번호 |
| Destination Port | 목적지 애플리케이션을 구분하기 위한 포트 번호 |
| Protocol | 트랜스포트 계층의 프로토콜 정보 (예: TCP, UDP, ICMP 등) |
| Source Mac Address | 발신 장치의 MAC 주소 (L2 계층) 5 tuple key일 경우 해당 없음 |
| Destination Mac Address | 수신 장치의 MAC 주소 (L2 계층) 5 tuple key일 경우 해당 없음 |
이러한 5(7)-tuple이 동일한 패킷들을 일정 시간 동안 하나의 세션(Flow)으로 묶어, 그 흐름에서의 전송량, 시간, 패킷 수 등을 통계적으로 집계합니다. 즉, 같은 주체 간에 오간 모든 패킷을 하나의 통신 단위로 묶은 개념입니다.
그럼 네트워크 데이터인 PCAP파일을 통해 Flow기반 전처리 도구는 어떤걸 사용할까요? pcap 파일에서 Flow 기반 통계 피처를 추출하기 위해 표 2와 같은 도구가 널리 사용됩니다
표 2. pcap 처리 도구 비교
| 도구 이름 | 특징 및 용도 |
| CICFlowMeter | pcap 파일을 읽고 양방향 Flow를 구성하여, 약 80여 개의 통계 피처를 CSV 형식으로 출력함. 학습용 정형 데이터 생성에 특화되어 있으며, 실험 재현성이 높고 사용이 간편함. |
| Zeek(Bro) | 네트워크 트래픽을 분석하여 다양한 계층별 로그 파일(HTTP, SSL, DNS 등)을 생성. 보안 이벤트 추적 및 정책 기반 분석에 유리함. |
| Argus | 실시간 또는 저장된 pcap에서 Flow 흐름을 빠르게 요약하며, 경량 분석 또는 대용량 네트워크 감시에 적합함. |
본 연구에서는 아래와 같은 4가지 이유로 CICFlowMeter를 전처리 도구로 채택했습니다. 첫 번째, 정형 데이터 학습에 최적화된 구조를 가지고 있습니다. CICFlowMeter는 머신러닝 모델에 바로 입력 가능한 구조로 csv를 출력해주며, 학습을 위한 통계 피처가 포맷과 필드명이 일관되어 있습니다. 두 번째, 양방향 플로우 처리를 지원합니다. TCP 세션을 단방향이 아닌 클라이언트 ↔ 서버 양방향 흐름 기준으로 집계하기 때문에, 공격 패턴 식별에 더욱 유리합니다. 세 번째, 재현 가능한 실험 환경 제공하기 때문입니다. 동일한 pcap 파일에 대해 항상 동일한 결과를 출력하기에 재현성과 실험 관리가 용이합니다. 마지막으로 현재 학계에서 널리 활용하고 있습니다. CICIDS2017, CSE-CIC-IDS2018 등 주요 공개 데이터셋에서도 CICFlowMeter가 사용되어 연구 결과의 비교에 유리합니다[7].
CICFlowMeter는 약 80여개의 통계 피처를 생성할 수 있습니다. 표 3의 CICFlowMeter는 pcap 파일을 입력으로 받아 각 플로우 단위로 약 80여 개의 통계 피처를 계산합니다. 이 피처들은 크게 시간 정보, 패킷 전송량, 속도 및 비율, TCP 플래그 상태, 헤더/윈도우 구조 등으로 구분되며, 각 피처는 탐지 모델에서 정상과 비정상을 구분짓는 수치 기반 근거로 활용됩니다. 그중에서도 악성 트래픽 탐지에 실질적인 영향을 미치는 핵심 피처들을 정리한 것으로, 특히 Fwd/Bwd 방향성, 세그먼트 크기, IAT(Inter-Arrival Time), 플래그 발생 빈도 등은 정상적인 플로우와 공격 플로우를 구분하는 데 중요한 역할을 합니다. 모델 학습에 앞서 이들 피처는 스케일링, 결측치 처리, 이상값 필터링 등의 전처리 작업을 거치게 됩니다.
표 3. CICFlowMeter에서 추출되는 주요 통계 피처 목록
| 카테고리 | 피처명 | 설명 |
| 플로우 시간 | Flow Duration | 시작~종료까지의 시간 (ms) |
| Idle Mean | 패킷 간 유휴 시간 평균 | |
| Fwd IAT Mean | 전방향 패킷 간 평균 시간 간격 | |
| Bwd IAT Std | 후방향 패킷 간 시간 간격 표준편차 | |
| 패킷 수 / 크기 | Tot Fwd Pkts | 전방향 총 패킷 수 |
| Tot Bwd Pkts | 후방향 총 패킷 수 | |
| TotLen Fwd Pkts | 전방향 패킷 전체 길이 합 | |
| Pkt Len Mean | 전체 패킷 길이 평균 | |
| Pkt Len Std | 전체 패킷 길이 표준편차 | |
| 플래그 / 상태 | Flag Count | PSH, URG, FIN 등의 TCP 플래그 횟수 |
| URG Flag Count | URG 사용 횟수 | |
| Fwd PSH Flags | 전방향 PSH 플래그 발생 수 | |
| 속도 및 전송률 | Flow Bytes/s | 초당 전송된 바이트 수 |
| Flow Pkts/s | 초당 전송된 패킷 수 | |
| Avg Bwd Segment Size | 후방향 TCP 세그먼트 평균 크기 | |
| 헤더 / payload 구조 | Fwd Header Len | 전방향 전체 헤더 길이 |
| Subflow Fwd Bytes | 하나의 세션 내 서브플로우 전방향 바이트 | |
| Init Fwd Win Bytes | 초기 전방향 윈도우 크기 | |
| Fwd Act Data Pkts | 전방향 실제 데이터가 있는 패킷 수 |
비정형 데이터 전처리: 패킷 Payload 다듬기
정형적인 Flow 정보 외에도, 패킷 내부의 payload는 악성 행위의 실질적인 단서를 담고 있을 수 있습니다. 예를 들어 명령어 기반 공격(CMD/PowerShell), 악성 URL, base64 인코딩된 Shell코드 등이 payload에 포함되어 있을 수 있습니다. 이처럼 텍스트 기반의 공격 특성을 학습시키기 위해서는, payload 데이터를 자연어 처리 모델(BERT 등)이 이해할 수 있는 형태로 가공하는 과정이 필요합니다.
일반적인 전처리에서는 pcap에서 payload를 직접 추출하거나, 일부 도구에서 제공하는 간략한 문자열 기반 필드를 사용하는 경우가 많습니다. 하지만 본 연구에서는 보다 정밀한 분석을 위해, CICFlowMeter 자체를 수정하여 각 Flow 단위에 실제 payload를 직접 포함하도록 구조를 변경하였습니다. 기본 CICFlowMeter는 통계 피처만 제공하며, 실제 트래픽 내용(payload)은 포함하지 않습니다. 따라서 다음과 같은 방식으로 기능을 확장했습니다.
- 각 패킷을 재조합하여 하나의 Flow로 병합할 때, 양방향 payload를 함께 누적
- RawDataExtractor 모듈을 추가하여 Flow 내 Byte형 payload를 디코딩하여 문자열로 저장
- 결과 CSV에 ‘payload’ 컬럼을 추가하여, 정형 피처와 함께 NLP 입력을 준비
이렇게 추출된 payload는 단순 바이너리이기 때문에, 의미 있는 정보로 활용하기 위해 추가적인 디코딩이 필요합니다. 일반적인 UTF-8 디코딩은 많은 오류와 노이즈를 발생시킬 수 있기 때문에, 본 프로젝트에서는 포트 번호 및 프로토콜 정보를 활용하여 payload를 맞춤형으로 디코딩하는 방식을 적용했습니다. 본 프로젝트에서는 다음과 같이 다양한 애플리케이션/전송 계층 포트 번호에 맞춰 맞춤형 디코딩 로직을 구성하였습니다. 이들 포트는 실제 트래픽에서 자주 사용되는 Well-Known Port로 의미 있는 payload가 포함될 확률이 높은 프로토콜들입니다
표 4. 커스텀 디코딩이 적용된 Well-Known Port 및 프로토콜 목록
| 포트 번호 | 프로토콜/서비스 | 설명 |
| 20, 21 | FTP | 파일 전송(데이터/제어 채널) |
| 25, 587, 465 | SMTP / SMTPS | 메일 전송 / 보안 메일 |
| 80, 8080, 443 | HTTP / HTTPS | 웹 통신 / 보안 웹 통신 |
| 110, 143, 993 | POP3 / IMAP / IMAPS | 메일 수신 프로토콜 |
| 53 | DNS | 도메인 이름 시스템 |
| 67, 68 | DHCP | IP 주소 자동 할당 |
| 123 | NTP | 시간 동기화 프로토콜 |
| 139, 445 | NetBIOS / SMB | 윈도우 파일 공유, 네트워크 탐색 |
| 5353, 5355 | mDNS / LLMNR | 로컬 네트워크 이름 확인 |
| 137, 138 | NetBIOS Name / Datagram | 이름 서비스 및 메시지 브로드 캐스트 |
| 161, 162 | SNMP | 네트워크 관리 프로토콜 |
| 389, 636 | LDAP / LDAPS | 디렉토리 접근 프로토콜(일반 / 보안) |
| 111, 135, 88 | RPC / DCE-RPC / Kerberos | 인증, 리모트 프로시저 호출 등 |
| 30301-30305 | Ethereum Node Comm. | 이더리움 네트워크 통신(P2P) |
| 5060 | SIP | VoIP 세션 제어 프로토콜 |
| 6667 | IRC | 실시간 채팅, 악성 봇 통신에서 자주 사용 |
| 1883 | MQTT | IoT 메시징 프로토콜 |
| 1900, 3702 | SSDP / WS-Discovery | 장치 검색 프로토콜 |
| 6881 | BitTorrent | P2P 파일 공유 프로토콜 |
| 43 | WHOIS | 도메인 정보 조회 |
| 5500 | VNC | 원격 데스크탑 프로토콜 |
| 873 | rsync | 파일 동기화 프로토콜 |
| 500 | IPSec | 보안 네트워크 터널링 |
| 5683 | CoAP | 경량 IoT 디바이스 통신 |
표 4는 이처럼 사전에 정의한 디코딩 가능한 포트 번호와 그에 대응하는 프로토콜 목록을 정리한 것입니다. 예를 들어, 포트 80이나 8080은 HTTP로 간주하고 UTF-8 디코딩 및 헤더/URI 파싱을 수행하며, 포트 53은 DNS 포맷에 따라 도메인 쿼리 정보와 타입을 추출합니다. 반면, TLS(443), IPSec(500)과 같은 암호화된 프로토콜은 디코딩을 생략하거나 버전 정보 등 일부 메타 정보만을 추출합니다.
이러한 포트 기반 디코딩 전략은 다음과 같은 장점을 가집니다:
- 디코딩 오류율 감소: 잘못된 텍스트 해석으로 인한 탐지 오류 방지
- 탐지 정밀도 향상: 프로토콜 구조에 맞는 정보 추출 가능
- 유연한 확장성 확보: 추후 새로운 포트를 추가할 때 구조 일관성 유지
따라서 이 포트-프로토콜 매핑 목록은 정형 + 비정형 전처리의 중간 단계에서 핵심 역할을 하며, 최종적으로 NLP 모델로 전달되는 payload 텍스트의 품질을 결정짓는 요소가 됩니다.
그림 2. 포트 기반 프로토콜 식별 비율
그러나 실제 네트워크 환경에서는 포트 번호만으로는 어떤 프로토콜인지 정확하게 판단하기 어려운 경우가 많습니다. 그림 2는 실제 악성 네트워크 트래픽을 포트별로 분석한 결과로, 전체 트래픽 중 약 99%가 사전에 정의된 포트 목록으로는 프로토콜을 식별할 수 없는 `Unknown` 상태로 분류되었으며, 실제로 known 포트에서 탐지 가능한 비율은 1%에 불과합니다. 공격자들은 흔히 비표준 포트를 사용하거나 정상 포트를 위장한 커스텀 프로토콜을 사용하는 방식으로 탐지를 우회하려 합니다. 이는 포트 번호만으로는 대부분의 트래픽의 실제 목적을 알 수 없고, 공격자는 주로 비표준 포트, 혹은 동적으로 할당된 포트를 통해 우회하며 커스텀 C2, 봇넷 통신, 익스플로잇 툴킷 등은 포트 고정성이 없다는 의미입니다. 따라서 포트 기반 탐지는 유의미하지만, 단독으로는 매우 제한적이기 때문에 이를 보완하기 위해, payload 자체의 구조와 패턴을 기반으로 프로토콜을 자동 감지하는 `detect_protocol()` 함수를 설계하였습니다.
detect_protocol 함수는 포트 정보가 없는 경우에도 payload만으로 프로토콜을 유추할 수 있으며 잘 알려지지 않은 커스텀 C2, 봇넷, 파일 전송, 암호화 채널들을 식별하며 자동화된 디코딩 라우팅 프로토콜 등을 탐지하여 알맞은 디코딩 방식을 적용하기 위해 설계되었습니다. 해당 함수는 먼저 payload의 헤더(4~5Byte)를 확인하여 정형 프로토콜 패턴을 먼저 감지했습니다. DNS, DHCP, NetBIOS, SMB, TLS, HTTP, FTP 등 표준 프로토콜의 시그니처를 통해 확인이 가능합니다. 또한 여러 커스텀 시그니처를 만들어 Revenge_RAT, Powershell, Base64 C2, C2 Beacon, 정보 탈취, 프린터 명령 등의 특수 목적 패턴을 확인하여 프로토콜을 선정하였습니다. 표5는 포트 정보 없이도 payload 내 특정 문자열, 명령어 패턴을 기반으로 프로토콜을 식별하는 시그니처 규칙들입니다.
표 5. 엔트로피 기반 암호화 탐지
| 감지 이름 | 조건 예시 |
| TLS | ‘\x16\x03\x01’ 또는 ‘http://ocsp’ 포함 |
| Revenge-RAT | b’Revenge-RAT’, b’JAB’ |
| BitTorrent_DHT | b’get_peers’, b’info_hash’ 등 포함 |
| windows-cmd-obfuscated | b’cmd /V. b’rundll32’, b’PS C:\\… |
| CUSTOM_POWERSHELL_C2 | b’powershell, b’PS C:\\ |
| Ethereum DevP2P | b’hello’, b’devp2p’, b’status’ |
전처리 방식의 통합
앞서 살펴본 정형 데이터(통계 피처)와 비정형 데이터(payload)는 각각 별도의 전처리 과정을 거쳤지만, 실제 탐지 시스템에서는 이 둘을 함께 활용하는 통합 전처리 구조가 필요합니다. 그림 3은 하이브리드 전처리 파이프라인의 전체 흐름을 시각화한 것입니다.
그림 3. 하이브리드 전처리 통합 구조
이 구조는 다음과 같은 두 가지 경로를 통해 데이터를 가공합니다. 정형 처리 경로는 CICFlowMeter를 통해 생성된 Flow-level 통계 피처 (예: Duration, Bytes/s, Packet Count 등)를 생성한 후 결측치 처리 및 정규화를 거쳐 모델 입력에 활용합니다. 비정형 데이터는 Flow에 포함된 Raw payload(Encoded payload)를 모두 결합한 후 포트로 식별되지 않거나 비표준인 경우 `detect_protocol()`을 통해 자동 탐지가 이루어지며 최종적으로 NLP 모델(BERT 등)에 적합한 형태로 변환합니다. 이러한 병렬 전처리 구조를 통해, 시스템은 포트 기반 탐지의 한계를 보완하면서도 구조화된 통계 정보의 신뢰성도 함께 확보할 수 있습니다
전처리 후 데이터를 통합할 때 주요한 쟁점은 모든 Flow가 항상 payload를 가지고 있는 것이 아니란 점입니다. 실제 네트워크 환경에서는 TCP 핸드셰이크(3-way handshake), ACK-only 패킷이나 TLS, SSH, IPSec의 초기 연결 프로토콜 또는 비콘 트래픽이나 포트 스캔과 같은 경우에는 payload가 존재하지 않거나 무의미한 경우가 자주 발생합니다. 이에 따라 본 시스템에서는 모든 Flow에 대해 통계 정보는 필수로 지정했고, payload는 존재하는 경우에만 처리했습니다. 실제로 본 프로젝트에서 사용한 데이터는 총 3,744,242개의 Flow 데이터를 가지고 있지만, 그 중 payload는 2,362,488개로 payload가 존재하는 Flow는 전체의 약 63.1%에 해당합니다.
결론
이번 글에서는 네트워크 사이버 위협 탐지를 위한 첫 단계로서, 데이터 전처리의 구조와 설계 철학을 살펴보았습니다. 네트워크 트래픽에서 추출한 Flow는 모두 통계 정보를 갖고 있지만, 유의미한 payload를 가진 경우는 제한적이며, 이를 고려한 정형-비정형 이중 전처리 체계가 필요함을 확인했습니다.
정형 데이터는 CICFlowMeter 기반으로 수십 개의 통계 피처를 생성하고, 비정형 데이터는 포트 기반 디코딩과 `detect_protocol()`을 활용한 페이로드 중심 분석을 통해 NLP 모델 입력에 적합한 형태로 정제됩니다. 이 과정을 통해 공격자가 포트를 우회하거나 난독화한 페이로드를 사용하는 경우에도 탐지 가능성을 극대화할 수 있습니다.
다음 글에서는 이렇게 전처리된 데이터를 바탕으로 어떤 피처들을 최종적으로 선택하고, 정형/비정형 정보를 어떻게 결합하여 탐지 모델의 입력으로 구성하는지, 즉 피처 추출(Feature Engineering) 과정에 대해 상세히 다룰 예정입니다.
References
[1] Oh, C., Ha, J., & Roh, H. (2021). A survey on TLS-encrypted malware network traffic analysis applicable to security operations centers. Applied Sciences, 12(1), 155.
[2] Moore, A. W., & Papagiannaki, K. (2005, March). Toward the accurate identification of network applications. In International workshop on passive and active network measurement (pp. 41-54). Berlin, Heidelberg: Springer Berlin Heidelberg.
[3] Gringoli, F., Salgarelli, L., Dusi, M., Cascarano, N., Risso, F., & Claffy, K. C. (2009). Gt: picking up the truth from the ground for internet traffic. ACM SIGCOMM Computer Communication Review, 39(5), 12-18.
[4] Stein, K., Mahyari, A., Francia, G., & El-Sheikh, E. (2024, May). A transformer-based framework for payload malware detection and classification. In 2024 IEEE World AI IoT Congress (AIIoT) (pp. 105-111). IEEE.
[5] Bar-Yanai, R., Langberg, M., Peleg, D., & Roditty, L. (2010, May). Realtime classification for encrypted traffic. In International Symposium on Experimental Algorithms (pp. 373-385). Berlin, Heidelberg: Springer Berlin Heidelberg.
[6] Cesare, S., Xiang, Y., & Zhou, W. (2013). Control flow-based malware variantdetection. IEEE Transactions on Dependable and Secure Computing, 11(4), 307-317. [7] Sharafaldin, I., Lashkari, A. H., & Ghorbani, A. A. (2018). Toward generating a new intrusion detection dataset and intrusion traffic characterization. ICISSp, 1(2018), 108-116.
손진혁 연구원은 컴퓨터공학과를 학부, 석사과정을 졸업했다. 현재 카이스트 사이버보안연구센터 AI기술보안 팀원으로 XAI를 활용한 인공지능의 보안 연구를 진행하고 있다.