본문 바로가기

Arcsight & Elasticsearch 연동, 보안 로그 분석 플랫폼 개발 사례

알찬IT 2025. 4. 17.
반응형

제가 근무중인 회사는 ArcSight SEIM을 도입하여 현재 기업 내 모든 보안 이벤트 로그(서비스 및 사용자 PC)를 수집하고 있습니다. 평일기준 1일 용량은 Elastic 문서수 기준으로 약 6억~7억건 정도 됩니다. 아크사이트도 우수한 SIEM 솔루션이지만, 실제 운영 측면에서 몇 가지 문제점이 있어 개선하고자 Elastic Stack과 통합하는 프로젝트를 진행하게 되었습니다.

 

내가 생각하는 기존 Arcsigh 문제점 정리

 

  • 여러 조건이 걸린 로그를 검색할 때 능숙하지 않으면 다루기가 힘듦.
  • 처음 운영 시 학습 곡선 및 진입 장벽이 높게 느껴질 수 있음.
  • 사용자 인터페이스(UI)가 명확하지 않음.
  • 사용자 맞춤 설정이 어려움(대시보드, 검색 조건 등).
  • 여러 기능이 있지만 실제 운영 환경에서의 활용도는 관리자마다 다를 수 있음

 

간략하게 말하면, 완성도 높은 SIEM 솔루션이지만 실제 업무에서 활용할 때 다소 불편하고 까다로우며 익숙해지는 데 시간이 필요합니다. (효과적으로 활용해서 만족스럽게 사용 중인 곳도 있을테니, 위 내용은 개인적인 견해임).

 

ArcSight SIEM을 더 편리하게 사용할 방법을 모색하던 중 Elastic 사이트에서 "Elastic Stack ArcSight Integration" 페이지를 구글 검색을하다 우연히 발견하였습니다. 간단히 말하면 ArcSight에서 모든 로그를 수집하고 "Smart Connector"를 통해 ELK 스택으로 전송하는 것입니다.

 

즉, Arcsight로 수집된 로그를 ELK Stack에 저장하고 kibana 화면을 통해 보다 쉽고 빠르게 다양한 로그를 분석할수 있다는 것입니다.

 

ArcSight 출력 방식에는 두 가지 유형이 존재합니다.

 

  • Smart Connector Event Broker 방식((부가 비용 있음)
  • Smart Connector 방식(무료)

 

다음 이미지를 보시면 기존 Legacy 방식의 구성이 어떻게 되어 있는지 쉽게 이해하실 수 있을 겁니다.

 

Arcsight 구성도

 

ELK 스택에 추가 구성 요소 설치 (이 포스팅에서는 Kafka는 다루지 않음).

 

ArcSight와 ELK 스택을 통합 했을때 장점

 

Elastic-search-STACK-통합
ELK 스택 통합

 

Elasticsearch와 lucene을 이용한 검색 쿼리는 약간의 학습만으로도 누구든지 복잡한 조건의 검색을 능숙하게 할 수 있습니다.

간단한 명령어로 여러 조건(다중 조건)이 포함된 검색도 간편하고 쉽게 진행 할 수 있습니다.

 

예) 해외에서 RDP 접속 시도를 하는 로그만 추출하는 예제

 

- 상세 설명 : 장비명 AADevice에서 발생되는 로그중 RDP 프로토콜에 대해서 KR(한국)은 제외하고 특정 IP 두개는 제외한 결과

deviceHostName:AADevice && applicationProtocol:RDP && name:"Successful logon - RDP" && !source.country_code2:KR  && !sourceAddress:(192.x.x.x  
|| 172.x.x.x)

 

 

만약 위에서 예시를 든 Elastic 쿼리를 ArcSight에서 조건 생성하려면 다소 복잡하며, 능숙하지 않은 사용자에게는 쉽지 않을 수 있습니다. 또한, 기간이 예를들어 1개월일 경우 결과 도출시 시간이 오래 걸릴수도 있습니다.

 

  • Kibana 도구를 이용하면 데이터를 실시간으로 시각화 할 수 있고, 사용자가 원하는 대로 유연하게 커스터마이징도 가능하다.
  • Elastic STACK 오픈소스를 이용하면 저렴한 비용으로도 업무의 효율성을 높일 수 있다.

 

보안 관제 측면의 장점

 

Elasticsearch 통합 관제화면
Elasticsearch 보안관제 화면 예시

 

  • 실시간으로 보안 상황을 분석할 수 있어 빠른 판단과 대처가 가능.
  • 대시보드를 통해 보안 상황에 대한 파악과 이해를 높일 수 있음.
  • 실시간으로 사이버 위협을 탐지하기 위해 대화 형식의 검색 기능을 제공.
  • 여러 상황(다중 조건)의 쿼리 결합으로 보안 시스템 간 연관성 분석 가능.
  • 여러 형태의 "보안 이벤트 로그 데이터"를 다룰 수 있는 기능을 제공.

 

Elasticsearch, Logstash, Kibana EKK STACK 환경 이렇게 구성

 

Logstash 서버 Log Data 수집 처리  CPU 8 Core ~ 3대 ~
(Parsing,Filter,Output) Memory 16G ~
Master 서버 ELK 클러스터 관리 CPU 4 Core ~ 3대 ~
Memory 8G ~
Data 서버 DATA 저장 CPU 10 Core ~ 6대 ~
Memory 32G ~

 

여러가지 트러블 슈팅 및 문제 봉착했던 부분

 

- 대시보드 Kibana 시각화 시, 데이터 기간이 긴 경우(예: 24시간)에는 데이터 노드에서 메모리 초과(OOM) 현상이 발생합니다.

- 검색 시 검색 기간이 길어지면 데이터 노드의 가비지 컬렉션 오버헤드가 발생합니다.

 

하기 해결 방안 참고(실제 구축하는 환경이나 유입되는 로그에 따라 문제점은 다양하게 발생할수 있습니다.)

 

- Linux OS 환경에서의 대용량 서비스에 맞게 최적화 진행 (sysctl 커널 파라메터 등등)

- shard 갯수 (Shard 갯수를 너무 많이 해도 읽기 성능에 영향을 미칠수 있음)

- Memory 할당 (heap 포함) / data node 의 경우 가급적이면 물리 Memory 64G, Heap Memory 32G 적절

- "refresh_interval" : "30s"

- indices.memory.index_buffer_size 변경

- thread_pool.search.queue_size: / thread_pool.bulk.queue_size:  변경

- "_all" : { "enabled" : false}  

- number_of_replicas" : "0"  / 저희 회사는 복제본을 저장하지 않기로 결정(서비스 환경에 맞게 설정 바람)

- kibana -> Index Patterns -> source filter 64개 적용

- indices.fielddata.cache.size 적절하게 조정

- indices.breaker.fielddata.limit 적절하게 조정

 

특히, Elasticsearch는 JAVA 기반인데요 Memory 문제들에 대해 찾아보면 대부분의 해결책은 "노드 확장을 통해 메모리 사용량 분산"이라는 권장 사항들을 많이 찾아볼수 있습니다. 즉, 예를들어 data노드등 성능 문제가 발생한다면 data 노드 서버를 늘리는 방향을 고려해야합니다. 먼저, Scale UP 리소스를 늘려보시고 그래도 별 변화가 없다면 Scale Out을 고려해 보시기 바랍니다.

 

이 밖에도 인덱싱 처리량이 많고 데이터 보관 기간이 길다면 핫, 웜 아키텍처도 고려해 볼 만합니다. 많은 양의 방대한 로그 이벤트를 처리 할 때는 logstash 앞에 kafka를 구성하는 것도 고려해 보는것도 좋은 대안이 될수 있습니다.

 

필자의 생각 정리

 

최근에는 "빅데이터"라는 키워드에 다양한 용어들을 결합하여 인터넷이나 언론 매체에서 마케팅 용도로 빈번하게 사용되고 있습니다. 몇 년 전부터 정보 보안 업계에서도 빅데이터라는 용어가 많이 쓰이기 시작하면서...현재 시점에는 인공지능 AI가 이슈화 되고 있습니다.

 

대용량 데이터 처리 기반의 최신 SIEM, 대규모 데이터를 활용한 보안 시스템, 방대한 데이터에서의 보안 분석 도구, AI를 활용한 보안관제 등등 신기술 키워드를 접목한 수많은 마케팅 용어들이 등장하고 있는데요.

 

여기서 가장 중요한 점은 돈을 써서 상용 제품을 사용하든, 독자적으로 구축해서 관리하던 "대용량 데이터"를 효과적으로 이용해야 한다는 의견입니다. 즉, 방대한 데이터 처리가 핵심 과제 입니다.

 

빅데이터란 대량의 데이터로부터 유용한 정보를 추출하고 분석하여 업무나 기업 활동에 적용함으로써 가치를 창출할 수 있어야 의미가 있습니다. 많은 비용과 인력을 투입하여 빅데이터 사업을 추진하지만, 투자 대비 성과를 얻지 못하는 경우가 많습니다.

 

대용량 데이터를 분석해서 보안업무에 적용하고자 한다면

 

전담 팀을 필수적으로 구성해야 하며,

해당 업무 절차가 체계화 되어야 하며,

또한, 현재 담당하고 있는 업무보다 더 발전적이고 의미있는 일이어야 한다는 생각입니다.

 

보안 업계에서 자주 언급되는 말에 따르면 수천 건에서 수억 건에 달하는 보안 이벤트 중 실제로 위협적인 보안 이벤트는 1~2%에 불과하다는 이야기도 있습니다. 이렇게 1~2%의 데이터를 선별하기 위해서는 정말 많은 노력이 필요합니다. 최근에는 AI 인공지능 기술을 활용한 보안 솔루션들이 매우 다양하게 출시되고 있습니다.

 

AI 기술이 급속도로 발전하고 있지만 어쨋든 지금 상황에서는 인력(사람)이 투입되어야 한다는 것입니다. 주기적으로 점검해서 오탐을 걸러내는 필터가 필요한데요. 이와 같은 일은 현재로서는 사람이 개입할수 밖에는 없습니다.

 

끝으로 제 견해는, 대규모 데이터, 인공지능(AI)등 기술이 발전하더라도 IT 분야에 종사하는 사람으로서 가져야 할 바람직한 태도는 내 자리가 없어질까 두려워하기 보는등 부정적으로 생각하지 말고, 이와 같은 기술들을 적극 수용하고 분석, 탐구하는 해야 뒤쳐지지 않고 나 자신도 발전할수 있다는 것입니다.

 

반응형

댓글

티스토리툴바