현재 ArcSight 로 기업내 모든 보안 이벤트 로그를(서비스,사용자 PC) 수집중이다.
ArcSight도 훌륭한 SIEM 솔루션 이나, 실무 운영 관점에서 몇가지 불편한 점이 있다.
– 다중 조건 로그 검색시 숙련이 되지 않으면 사용하기가 어려움
– 운영시 초기 학습 곡선 및 진입 장벽이 높음
– UI 가 직관적이지 못함
– 커스터마이징이 어려움(대시보드, 검색 조건등)
– 다양한 기능 대비 실제 운영 환경에서 활용도가 낮음 (관리자 마다 틀리겠죠)
요약 하자면, 잘 만들어진 SIEM 솔루션임에도 불구하고 전반적으로 실무에서 운영함에 있어 뭔가 불편하고 어려우며 쉽게 친해지기 어렵다. (적극적으로 활용하여 잘쓰고 있는 곳도 있을 것이므로, 위 내용은 지극히 필자의 주관적인 생각임)
어떻게 하면 ArcSight SIEM을 좀더 편하게 쉽게 활용할수 있을까 고민 하던중 우연히 elastic 사이트에서 “Elastic Stack ArcSight Integration” 페이지를 발견하게 되었다. 쉽게 풀이 하자면 ArcSight로 모든 Log 를 수집 / “Smart Connector” -> ELK 스택 으로 보내주는것이다. ELK 스택이 추가 Output 이 되는 것이다.
ArcSight Output 방법에는 두가지가 있다. Smart Connector Event Broker(추가 비용 발생) 방식. 이 글에서는 Smart Connector 를 사용한 방법이다. 아래 그림을 보면 쉽게 이해가 될것이다.
기존 ArcSight 구성
ELK 스택 추가 구성 (본 포스팅 에서 kafka 는 제외함)
ArcSight 에 ELK (Elasticsearch, Logstash, Kibana) 스택을 붙이면 어떤 이점이 있을까?
– elasticsearch lucene 검색 쿼리는 조금만 학습하면 누구나 쉽게 복잡한 조건의 검색을 할수 있다.
– 단일 명령어로 복잡한 조건의 검색도 쉽게 할수 있다.
예) IPS 로그 검색시
deviceProduct:xxxIPS && deviceSeverity:High && !destination.country_code2:(KR || US) && !sourceAddress:11.xx.x5.x7 && !name:(SNMP* || DRDOS*)
풀이하자면, 장치명이 xxxIPS고 Serverity가 High 이면서 목적지가 한국,미국이 아닌 / 출발지가 특정 아이피가 아니며, name필드에 SNMP,DRDOS 라는 키워드를 제외한 보안 로그만 검색.
위 문장을 ArcSight에서 조건을 만들려면 꽤나 복잡하고 숙련된 사용자가 아니라면 그리 쉽지는 않을것이다.
– Kibana 도구로 직관적인 실시간 시각화가 가능하다 (유연한 커스터마이징 가능)
– 오픈소스 활용으로 비용대비 업무 효율성 향상을 가져올수있다.
보안 관점에서 보자면,
– 실시간 보안 분석이 가능하여 신속한 판단및 신속한 위협 대응이 가능하다.
– 대시보드를 통한 보안 가시성과 통찰력을 향상 시킬수 있다.
– 실시간 사이버 위협 탐지를 위한 대화형 탐색이 가능하다.
– 다양한 조건의 쿼리 조합으로 보안 장비간 상관 관계 분석이 가능하다.
– 복잡하고 다양한 “보안 이벤트 로그 데이터” 유형을 취급할수 있는 유연성이 확보된다.
개발 과정 (실제 Production 환경 LOG -> POC 진행)
ELK 5.6.4 버전
logstash * 2대 / CPU 8 Core / Memory 16G
elastic master node * 2 / CPU 4 Core / Memory 8G
elastic data node *3 / CPU 10 Core / Memory 32G / data 영역 서버당 SSD 300G
문제 발생 (덕분에 고생)
– 대시보드 kibana 시각화시 -> 기간이 길면(예:24시간) Data Node OOM발생 (out of memory)
– search 시 검색 기간이 길면 Data Node GC overhead 발생
– 이외 짜잘한 것들 몇가지
해결책 및 튜닝 포인트
– OS 레벨에서의 대용량 처리 튜닝 (sysctl 커널 파라메터 등등)
– 적절한 Memory 할당 (heap 포함) / 특히 data node
– 적절한 shard 갯수 / 무턱대고 늘리거나 너무 적어도 낭패
– thread_pool.search.queue_size: / thread_pool.bulk.queue_size: 적절하게 조정
– indices.memory.index_buffer_size 조정
– “_all” : { “enabled” : false} / 6.0 에서는 기본으로 false라고 함
– number_of_replicas” : “0” / 리플리카는 0으로 (용도에 따라 다름)
– “refresh_interval” : “30s”
– indices.breaker.fielddata.limit
– indices.fielddata.cache.size
– kibana -> Index Patterns -> source filter 34개 적용
수많은 메모리 관련 이슈에 대해 검색 해보면 가장 좋은 대안은 “node 확장을 통한 메모리 사용 분산” 이라고 한다.
이외에도 “프로덕션” 환경에서는 다양한 부분에서 추가적인 최적화(튜닝)나 구성 변경 등이 필요할것으로 생각된다.
예를들어 인덱싱 처리량이 많고 data 보관 기간이 길다면 hot, worm 아키텍처도 고려해 볼만 하다.
대용량 이벤트 처리시에는 logstash 앞단에 kafka 를 구성 하는 것도 고려 사항이다.
ELK 스택의 용도 및 서비스 관점에서의 튜닝 포인트는 많은 차이가 있다. (예: 검색위주냐 , 저장소 용도냐 등등)
개발 결과
curl http://x.x.x.x:9200/_cat/health?v (클러스터 상태)
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1512374044 16:54:04 nz-secops green 5 3 48 32 0 0 0 0 – 100.0%
curl http://x.x.x.x:9200/_cat/nodes?v (노드 상태)
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
2xx.xx.xx.xx 70 92 0 0.18 0.12 0.05 d – es-data01
2xx.xx.xx.xx 72 96 0 0.00 0.00 0.00 d – es-data02
2xx.xx.xx.xx 9 81 0 0.00 0.00 0.00 m – es-master02
2xx.xx.xx.xx 70 92 1 0.02 0.02 0.00 d – es-data03
2xx.xx.xx.xx 12 73 0 0.00 0.00 0.00 m * es-master01
* 1시간 평균 보안 이벤트수 -> 9백만 건
* 1일 보안 이벤트 수 -> 평일 기준 약 1억 7천 1백만 건
* Network Traffic IN/OUT 초당 50~60M 정도
* 1일 스토리지 저장되는 DATA 용량 / 약 400GB (ArcSight -> CEF 포맷 -> ELK 스택 (CEF 포맷 Parsing 이유로 용량 증가)
* 위와 같은 구성으로 운영시 ELK 스택 클러스터 정상 운영 / LogStash 2대, Master Node 2대 , Data Node 3대
* 실제 프로덕션 환경에서는 적절하게 각 node를 추가하거나 / node별 컴퓨팅 자원을 늘리는것을 고려해야함
보안 위협 검색 활용 사례
“비트코인 악성코드 감염 호스트 검색”
검색 쿼리 : destinationPort:7777 AND NOT destination.country_code2:KR AND NOT sourceAddress:(1.2.x.x)
설명 : 목적지 포트가 7777이며 목적지 IP가 한국이 아니며 출발지 IP가 xxxx가 아닌 로그 검색
(전제: 비트코인 악성 코드 감염 호스트 1대가 7777로 통신하는건 인지 하고 있었음)
검색 결과 : “비트코인 마이너 악성코드” 감염 서버 추가 발견
“PC 사용자 영역 IPS 의심 로그 검색”
검색 쿼리 : deviceProduct:XXXIPS AND deviceSeverity:High AND !destination.country_code2:(KR OR US) AND !sourceAddress:2.X.15.xxx AND !name:(SNMP* OR DRDOS*)
설명 : 장치명 XXXIPS에서 로그 레벨이 High / 목적지가 한국,미국이 아니며 / 출발지 IP가 모니터링 서버(snmp통신)가 아니며
IPS탐지 name이 SNMP DRDOS 문자열이 아닌 보안 로그 검색
검색 결과 : 사용자 PC -> 다수 해외 IP (홍콩,프랑스,싱가폴 등) -> SQL 인젝션, Dos, Brute Force 공격 호스트 발견 (악성코드 감염)
“의심스러운 포트 접속 활동 호스트 검색”
검색 쿼리 : deviceAddress:2.xx.17.x AND !destination.country_code2:(US OR KR) AND !(destinationPort:25 OR 53 OR 80 OR 443)
설명 : 특정 서비스존(2.xx.17.x) 에서 목적지가 한국, 미국이 아니며 / 목적지 포트가 메일,DNS,웹 서비스가 아닌 이상 포트로
접속하는 모든 호스트 검색
검색 결과 : 다수의 해외 IP로 -> 이상 포트(well known port 가 아닌)로 접속하는 호스트 다수 발견 (대부분 악성 코드 감염)
* 사례와 같이 ElasticSearch -> 단일 명령으로 다양한 조건 쿼리 조합 -> 유연하고 탄력적인 검색 -> 결과 도출 ->
-> 신속한 보안 위협 대응 가능
* 이외 elastic 은 “머신러닝” 기능도 제공한다. (단, 비용 발생)
– 예: 한달 동안 ftp 프로세스가 없는 서버에서 갑자기 ftp 프로세스가 생성되면 의심 프로세스 분류되며 alert도 가능
– 예: DNS 쿼리 요청의 하위 도메인 필드에 비정상적인 양의 엔트로피(“정보 콘텐트”)가 존재하는 것을 식별
DNS 프로토콜을 통해 데이터가 유출되고 있다는 징후일 가능성을 제시하고 비정상적인 요청을 생성한 IP 주소를 식별함.
실시간 장비별 보안 이벤트 DASHBOARD
실시간 의심스러운 보안 이벤트 DASHBOARD
요즘 트렌드는 “빅데이터” 라는 단어에 온갖 용어를 조합하여 인터넷이나 기사에 마케팅 용어로 도배를 하고 있다. 정보 보안 분야에도 몇년전 부터 빅데이터라는 수식이 엄청나게 붙기 시작…
빅데이터 기반 차세대 SIEM, 빅데이터를 통한 차세대 보안, 빅데이터 보안 분석 솔루션 등등등… 좋은 말들이고 좋은 취지다. 문제는 비용 들여 상용 제품을 운영하던, 자체적으로 개발하여 운영을 하던 “빅데이터”를 제대로 활용해야 한다는 것이다. 빅데이터를 통해 가치 있는 데이터를 창출하고 업무나 기업 차원에서 이점이 있어야 “빅데이터” 로서의 의미가 있는것이다.
돈들이고 인력 들여서 빅데이터 사업한다고 포장해서 투자 대비 재미 못보는곳이 허다하다. 빅데이터를 활용하여 정보보안 업무에 접목 하고자 한다면 전담 인력이 반드시 꾸려져야 하며, 관련 업무 프로세스가 정립이 되야하며, 그리고, 현재 업무보다 개선되고 가치있는 일이 되어야한다.
어디서 들은 이야기지만 수천 ~ 수억건의 보안 이벤트가 올라오지만 그중 1~2%만 서비스 관점에서 정탐(위협)이라는 말도 있다. 이처럼 1~2%의 data 를 걸러내기 위해서는 무단한 노력이 필요하다.
요즘 AI, 머신러닝 기반의 보안 솔루션들도 엄청 나게 쏟아져 나오고 있다 몇몇 APT 보안 장비를 테스트해본 결과 현재 시점은 어찌되었건 사람의 손이 가야 한다는 것이다. 누군가는 수시로 확인하여 오탐에 대한 필터를 해야 한다는 것…
짧은 생각은, 빅데이터, AI, 머신러닝…등등 기술이 발전하면 IT 종사자로서의 자세는 부정적으로만 바라보지말고 분석하고 들여다 보는것이 현명한 자세라 생각된다. 그리고 새로운 기술 도입시에는 과연 업무에 효율적일까? 개선 및 도움이 될까? 나아가 기업과 서비스 관점에서 플러스가 될까? 등 수많은 고민 끝에 결정 해야만 투자 대비 최대의 효과를 거둘수 있다.
참고: Integrating the Elastic Stack with ArcSight SIEM