출처 medium.com/rapids-ai/cybert-28b35a4c81c4#cid=av01_so-twit_en-us

 

cyBERT

Neural network, that’s the tech; To free your staff from, bad regex

medium.com

Neural network, that’s the tech; To free your staff from, bad regex

신경망, 그것이 기술이로다 - 나쁜 정규식으로부터 벗어나기

 

로그는 무엇일까

 

태초부터 인간은 로그(통나무) 때문에 고군분투했습니다. 나무를 세워 만든 집은 증가하는 인구에 비해 비효율적이었기에, 인류는 통나무를 수확하고 분쇄하여 기존 통나무집보다 뛰어나고 복잡한 건물을 짓게 됩니다. 인간은 통나무를 연료로 써 불을 유지합니다. 컴퓨터와 통신의 발달로 다른 종류의 통나무가 중요해진 것은 놀랍지 않습니다. 불행히도, 훨씬 다루기가 어려워졌죠.

 

 

보안 로그는 조직에 걸쳐 발생하고 *엔드포인트(컴퓨터, 노트북, 서버), 통신, 주변 장치(VPN노드, 방화벽)에 이릅니다. 직원 1,000명 규모의 작은 회사로 따지자면, 낮게 잡아도 22,000 이상의 *EPS 피크값에 하루 100GB 이상의 로그가 발생한다고 볼 수 있습니다. 어떤 로그 데이터는 사용자와 네트워크 활동에 의해 생성되고, 또 어떤 로그 데이터는 네트워크와 보안 장치에 의해 생성됩니다.

 

*엔드포인트: 엔터프라이즈 네트워크에 연결하는 모든 사용자 장치

*EPS(Event Per Second): 초당 발생하는 이벤트

 

왜 로그 파싱일까

 

시작은 심플했습니다. 중요한 이벤트들을 위해 로그를 저장해야 했습니다. 검증과 감사를 위해 은행 거래를 기록해야 했습니다. 커뮤니케이션 시스템이 복잡해지면서, 시스템의 안성정을 보장하기 위해 추가적인 로그를 저장했습니다. 인터넷은 커뮤니케이션, 상업 활동, 그리고 정보 교환의 새 시대를 열었습니다. 중요한 정보들을 놓치지 않기 위해, 믿을 만한 커뮤니케이션을 입증하기 위해 로그가 더 필요하게 되었습니다. 스토리지의 가격이 떨어지자, 보안 전문가들은 조직으로 하여금 더 많은 로그와 데이터를 모으게 했습니다. 그것은 성공적이었습니다.

 

오늘날 조직에서는 훨씬 많은 데이터를 수집하고, 저장하고, 분석합니다. 로그는 출처, 형식, 시간에 있어서 다차원적입니다. 데이터를 분석하기 위해서는 먼저 데이터를 파싱해야 합니다. 실용적인 필드(Actionable fields)를 raw 로그에서 추출해야 합니다. 오늘날 로그는 복잡한 경험적 지식과 정규 표현식을 사용해 파싱하고 있습니다. 이러한 경험적 지식들은 융통성이 없고, 로그가 특정 형식에서 벗어날 경우 실패할 가능성이 높습니다. 아래와 같은 상황들을 살펴볼 수 있습니다.

  • 새로운 센서/어플리케이션이 새로운 로그 형식으로 적용된다면? 현재의 로그 파서가 이 새로운 로그와 비슷한 형식의 데이터를 다룰 수 있다고 하더라도, 새로운 파서를 만들어야 합니다. (정규식이 이런 경우에 꽤 엄격합니다)
  • 저하된 로그라면? 모든 파이프라인이 먹통이 될까, 아니면 그 로그를 모두 잃게 되는 걸까? 통합로그관리시스템(SIEM) 회사나 독립 소프트웨어 개발(ISV) 회사라면 자신들의 로그에 맞는 파서를 쓰겠지만, 우리는 일반적인 형식에 적용되지 않는 내부 어플리케이션를 위한 파서를 써야 합니다.
  • 보안팀에서 로그를 수집해 어떤 정보가 실용적이고 어떤 정보가 필요한지 평가하고자 한다면? 오늘날 이러한 작업은 반복적인 처리를 요구합니다. 안 그래도 인원이 부족한 보안팀에게 파싱된 로그를 평가하게 하는 것은 부담입니다.

쉽게 말해서 로그를 더 융통성 있고 탄력 있게 파싱하는 방법이 필요한 것입니다. 무엇을 할 수 있는지 보죠. 대부분 조직에서는 상당한 크기의 로그 히스토리를 가지고 있습니다. raw 로그와 파싱된 로그를 보관하고 있는 것은 어렵지 않습니다. 많은 샘플 데이터에 접근할 수 있다는 것은 딥러닝에 적합해보입니다, 특히 심층신경망 말입니다. 하지만 그 많은 선택지 중에서, 어디서부터 시작해야 할까요?

 

자연어처리는 무엇이며, 왜 그것을 써야 할까

 

로그와 보안데이터를 처리하는 방법은 다양합니다. 여기서 우리는 인간이 사물간(M2M)에 교환되는 정보를 기록하기 위해 규정한 로그를 파싱하는 데 집중합니다. 자연어 처리(NLP)와 같은 기술에 눈을 돌릴 필요가 있습니다. 자연어 처리는 전통적으로 텍스트 번역, 상호작용 챗봇, 가상 비서와 같은 프로그램에 사용됩니다. 현대 자연어처리 기술의 첫 단계는 텍스트나 발화를 수학적으로 표현하는 것입니다. 이 의미들(representations)은 문자를 숫자로 변환하는 룩업(look-up)처럼 간단명료할 수도 있고, 사전 학습된 신경망(Word2Vec, GloVe, BERT, GPT-2)의 출력을 활용하는 것처럼 훨씬 복잡해질 수도 있습니다. 이 신경망 의미들은 영어 위키피디아처럼 거대한 학습 말뭉치에서 단어들의 동시 출현을 기반으로 단어 간 관계를 비지도 학습합니다. 이러한 의미들을 사용함으로써, 이상적인 출력물이 나오도록 머신러닝 모델들을 학습합니다. 클러스터링이나 분류가 그 예입니다. 기존 연구에서는 보안 데이터를 일종의 자연어로 보는 것이 효과적일 수 있다고 주장합니다.

 

 

왜 BERT일까

기능적인 측면에서, 자연어 처리를 위해 사전 학습된 단어 의미들(word representations)은 부족하지 않습니다. Word2vec과 같은 오래된 신경망 단어 의미들은 문맥을 반영하지 않습니다. Word2vec은 단어마다 하나의 임베딩을 가지기 때문에 다의적인 단어를 구별하지 못합니다. 최근 모델들(ULMFit, ELMo)에서 단어는 맥락에 따라 다수의 임베딩을 가집니다. 문장에서 이전 단어들까지 동원해 의미를 구성하기 때문에 가능한 것입니다.

 

BERT도 맥락에 따른 의미를 만들어냅니다. 다만 주변 문맥을 양방향(단어의 앞과 뒤)으로 고려합니다. 이렇게 맥락 정보를 인코딩하는 것은 본질적으로 순서적인 사이버 로그를 이해하는 데 있어서 중요합니다. 예컨대 다양한 로그 타입에서 송신 주소(source address)는 목적지 주소(destination address) 이전에 발생합니다. 자연어 처리 모델을 사이버 로그에 적용할 때의 또다른 어려움은, 사이버 로그의 많은 "단어"들이 영어 단어가 아니라는 점입니다. 로그에는 파일 경로나 16진수 값, IP주소 같은 요소가 포함됩니다. 다른 언어 모델은 모르는 단어가 있을 때 "out-of-dictionary" 엔트리를 리턴하지만, BERT는 사이버 로그 속 단어들을 사전상 WordPieces로 쪼갤 것입니다. 예를 들어 ProcessID(프로세스아이디)는 Process와 ##ID라는 두 개의 WordPieces로 나눠집니다. 추가적으로 BERT는 2018년 말 구글에서 공개한 오픈소스이기 때문에 매력적입니다. 허깅페이스 트랜스포머 라이브러리에는 파이토치로 사전학습해 사용하기 쉬운 모델이 공개되어 있습니다. 트랜스포머 라이브러리는 임베딩 레이어에 파인튜닝 레이어를 추가할 수 있어 개체명 인식(NER)의 특정 로그 분류 테스크(specific downstream classification)를 수행할 수 있습니다. 마지막으로 로그 파싱에 BERT를 선택했을 때 이점은, 끝장판 cyBERT를 이용할 수 있다는 것입니다.

 

cyBERT 실험

다차원 보안 데이터 로그를 탄력 있게 파싱하기 위해, 트랜스포머 신경망을 훈련시키고 최적화시켜 cyBERT를 실험하고 있습니다. cyBERT는 CLX의 한 부분으로, CLX는 RAPIDS를 활용한 사이버 특화 어플리케이션입니다. BERT는 인간의 자연어나 질문-응답과 같은 전통적인 자연어 처리 태스크를 위해 설계되었기 때문에, (로그 데이터) 적용에 있어서 여러 어려움을 넘어서야 했습니다. 인간 언어에서 융통성 있게 구성되는 문장과 다르게 어떤 로그들은 확고한 순서를 가지기 때문에, 모델이 필드의 상대적인 위치보다 절대적인 위치를 학습하게 될 수 있습니다. 또다른 어려움은, 많은 로그가 BERT에서 하나의 입력 시퀀스에 올 수 있는 토큰(WordPieces)의 최대 개수 512개를 넘어선다는 점입니다. 게다가 긴 시퀀스들은 불균형하게 비용이 드는데, 어텐션 매카니즘의 시간이 시퀀스 길이에 *2차적이기 때문입니다. 융통성을 더 확보하기 위해서 우리는 다양한 길이와 시작점을 가진 로그 조각들로 모델을 파인튜닝했습니다. 추론에 앞서 로그를 겹치는 조각들(overlapping pieces)로 나눠 모델의 입력 사이즈에 맞췄습니다. 라벨링된 로그들은 후처리에서 다시 합쳤습니다. 지금까지 다양한 입력 시퀀스 사이즈, 학습 데이터 사이즈, 로그 유형, 그리고 학습 에포크로 실험을 해왔습니다.

 

*2차적: 선형적으로 증가한다는 뜻

*추론과 예측이 어떻게 다른 거지? blog.naver.com/call0712/222217882588

 

예를 들어 512 사이즈의 BERT 모델은 20.3ms였습니다. 그러나 이것이 모든 걸 보여주는 것은 아닙니다. 시퀀스 사이즈가 256인 WordPiece로 로그를 파싱하기 위해서는 두 가지 이상의 부분(more than 2 parts)을 모델에 먹여야 합니다. 로그 조각 사이 중복을 고려하기 위함입니다. 하나의 로그를 512 사이즈의 WordPiece로 파싱하는 것과 같은 효과를 내기 위해서는 256 WordPiece 시퀀스 모델에서 세 개의 시퀀스를 돌릴 필요가 있습니다(it is necessary to run 3 sequences through a 256 WordPiece sequence model). 그림1은 전체 로그를 파싱하면서 다양한 WordPiece 시퀀스 사이즈로 모델을 수행한 특성값(선)과 시간(바)을 나타냅니다.

 

그림1. 모델 수행도 vs. 시퀀스 사이즈

 

로그의 평균 토큰 개수가 512개 이상이라면 가능한 최대 WordPiece를 사용해야 합니다. 속도도 빠를 뿐더러, 모든 평가 지수에 있어서 최고에 가까운 수행도를 보여줍니다. 그러나 현실적으로 보안 운영 센터(Security Operation Center)는 이렇게 많은 양의 토큰에 접근하지 않을 수도 있습니다. 이 경우 최대 토큰 개수와 수행도 사이에서 절충을 해야 합니다.  64 사이즈의 WordPiece를 상상해봅시다. (512 사이즈 시퀀스 하나와 비교했을 때) 다양한 시퀀스를 가진 로그를 모두 파싱하기 위해서는 15개의 시퀀스가 필요합니다. 이때 시간은 ~5ms씩 증가합니다. 만약 로그가 전형적으로 작다면 64사이즈의 시퀀스 하나에 걸리는 추론 시간은 18.9ms입니다. 토큰 개수를 줄이더라도 모든 수행 지표가 여전히 높습니다. 즉, 모든 조직에 적용할 수 있는 규격화된 하나의 cyBERT는 없습니다. 로그의 타입과 전반적인 구성을 살펴봐야 합니다. 우리 데이터에 가장 맞는 파라미터를 적용한 cyBERT 코드는 CLX 저장소에서 찾아볼 수 있습니다.

 

결과

사전학습된 기본 BERT 모델을 파인튜닝하여 로그의 엔트리를 필드명으로 라벨링하는 것은 꽤 강력합니다. 처음에는, 하나의 입력 시퀀스에 맞출 수 있을 만큼 작은 로그에 모델을 학습·테스트하여 micro-F1 스코어에서 0.9995를 기록했습니다. 그러나 이 모델에서는 최대 입력 시퀀스보다 큰 로그들을 파싱할 수가 없습니다. 같은 테스트셋 로그가 다양한 시작 위치를 가지도록 변형되거나(micro-F1: 0.9634) 작은 조각들로 쪼개졌을 때는(micro-F1: 0.9456) 수행도가 좋지 않았습니다. 모델이 필드의 절대적인 위치를 학습하지 않도록 하기 위해서 로그 조각들을 훈련시키기로 했습니다. 그 결과, 시작 위치가 고정적일 때와 비슷한 정확도를 기록했고 로그 조각들이 다양한 시작 위치를 가질 때에도 잘 작동했습니다(micro-F1: 0.9938)

로그 조각으로 모델을 학습할 때 가장 좋은 결과가 나왔습니다. 추론 이전에 각 로그를 겹치는 조각들로 나눠 정확도를 계산했고, 그 다음에는 각 로그 조각의 중간 이후부터 합치고 예측을 합니다. 이렇게 했을 때 모델이 추론에 있어서 가장 많은 맥락을 양방향으로 가질 수 있습니다. cyBERT의 가장 멋진 특징 중 하나는 로그 유형들을 훈련셋 밖에서 파싱할 수 있다는 것입니다. 9개 다른 윈도우의 이벤트 로그 유형 중에서 1000개만을 샘플로 훈련시켰을 때, 처음 보는 윈도우 이벤트 로그 유형도 파싱할 수 있었습니다. (micro-F1: 0.9645, 그림2 참고)

 

 

다음 단계

BERT 기본 모델이 높은 정확도를 보였기 때문에, 이제는 cyBERT를 더 유연하고 탄력있게 만들 차례입니다. 현재 모델은 윈도우 이벤트 로그로만 훈련되었기 때문에, 추가적인 윈도우 이벤트 로그와 아파치(apache) 웹 로그까지 다양한 훈련용 로그셋을 수집할 계획입니다. 로그 언어는 BERT 토크나이저, 신경망이 학습하는 영어 말뭉치와 같지 않습니다.대량 로그 코퍼스(cratch on a large corpus of cyber logs)로 학습한 의미(representation)와 토크나이저를 조정한다면 모델의 속도와 정확도를 향상시킬 수 있을 것입니다. 예를 들어, 'AccountDomain'은 현재 BERT WordPiece 토크나이저로 A ##cco ##unt ##D ##oma ##in로 쪼갤 수 있습니다. 로그 언어에서 의미를 가진 WordPieces보다 세부적(granular)이라고 생각합니다. 다량의 로그를 빠르게 처리하기 위해 우리의 파서는 네트워크 상에서 작동해야 합니다. 앞으로 우리는 모든 전처리, 토크나이징, 그리고 후처리 과정을 GPU로 이동해, 호스트 메모리와 오가며 커뮤니케이션할 필요 없이 빠르게 파싱할 수 있도록 할 것입니다.  

 

결론

cyBERT는 인간 대 로그라는 긴 싸움에서 희망적인 출발을 알렸습니다. 인공 보안 로그를 자연어로 처리한다면, 정규식을 기본으로 하는 전통 매카니즘은 구식이 되고 로그 파싱 아키텍쳐에 완전히 다른 수준의 유연함을 부여할 수 있습니다. 로그를 효율적이고 정확하게 파싱하는 것은 어떤 보안 업체에서나 중요합니다. cyBERT를 통해 이용자는 광범위한 정규식 라이브러리 없이도 이 목표를 달성할 수 있습니다. 게다가, cyBERT로 전후처리의 속도를 높일수록, 새로운 파서로 아카이빙된 로그를 재생하는 것이 가능할 것입니다. 보안 전문가들은 오래된 로그에서 새로운 정보를 빠르게 추출할 수 있게 되는 것이죠. 

We’re excited about the future of cyBERT and sharing our work with the larger cybersecurity community!

복사했습니다!