침해 탐지 시간 단축: 로그 데이터의 가용성

안녕하세요! 이전 기사에서, 가상 또는 전체 규모의 SOC를 구축할 때 특히 SIEM을 SOC의 핵심 기술로 운영화하는 것이 중요한 역할을 한다는 것을 이미 확인했습니다. 또한 자동화가 현대의 위협과 SIEM 및 SOC 기술에서 발생하는 오버헤드를 따라잡는 길이라는 것도 확립했습니다. if one wants to keep up with modern threats and overhead that is produced by SIEM & SOC technologies. 오늘은 SIEM 배포 및 운영 구성 요소를 하나씩 분석하기 시작합니다. 가장 먼저 떠오르는 것은 데이터 가용성입니다. 침해 탐지 시간에 영향을 미치는 많은 요소가 있으며 2015년 현재도 평균 200일 이상입니다. 이는 SIEM이 침해 탐지를 위한 기술로 선택되기 때문이 아닙니다. SIEM은 데이터 입력을 기반으로 출력만을 제공할 수 있으며, 입력에서 일부를 놓치면 출력이 전체적이고 실행 가능하지 않거나 때로는 출력 자체가 없을 수도 있습니다.로그(및 사건)를 놓치면 정말 SIEM의 잘못일까요? 예, 이는 여러 요인에 따라 다르며, SIEM이 지속적으로 작동하도록 유지하기 위해서는 관리/유지를 담당하는 사람이 언제든지 다음 두 질문에 대한 충분한 정보를 가지고 있어야 합니다: “모든 범위의 로그 데이터가 수집되고 있습니까?” 그리고 첫 번째 질문의 답이 아니라면, “SIEM 측에 문제가 있습니까 아니면 외부에 문제가 있습니까?” 첫 번째 질문에 대한 답이 아니라고 한다면, 중요한 문제를 놓치고 있다는 것을 확신해야 하며, 이러한 문제는 사건 탐지 시간과 정확도에 직접적인 영향을 미칩니다. 솔직히, 어떤 SIEM 솔루션도 이 질문에 자동으로 답하지 않습니다. 이는 항상 수작업으로 응답해야 하는 작업입니다.네트워크 로그 데이터 가용성이 85%라고 말하는 SIEM을 본 적이 있습니까? 저는 본 적이 없습니다. 그러나 여전히 시스템이 첫 번째 질문에 답할 수 없기 때문에 두 번째 질문이 분명히 답변되지 않은 상태로 남아 있으며, 충분한 조사 를 하거나 수동적으로 시간을 투자하면 답을 찾을 수 있습니다.몇 가지 예를 들어보겠습니다 하나가 로그 데이터를 수집하는 방식에 따라 가장 일반적인 로그 수집 메커니즘부터 시작합니다 – syslog. syslog을 전혀 사용하지 않는 SIEM 구현을 언급하기는 어려울 것입니다. syslog에서는 데이터 손실이 발생할 수 있는 많은 방법이 있습니다: 수집 구성이 중단되면 파이프 수집 방법에서 데몬이 데이터 손실을 유발할 수 있으며, 기본 UDP syslog 프로토콜은 패킷 전송을 보장하지 않습니다. 높은 양의 syslog 트래픽(UDP 및 TCP 모두)이 버퍼 크기 제한과 대역폭 제한 및 특정 NIC의 패킷 처리 사양에 의해 방해받을 수 있습니다. 로그 데이터를 파일에서 읽어오는 경우에도 파일 회전과 무결성을 고려해야 합니다. 이러한 문제의 진단은 항상 SIEM 구성 요소 자체의 진단 로그를 읽는 것을 포함하는 수동 루틴 작업입니다. 진단 데이터가 있다면 말이죠! 가장 못생긴 진단 데이터라도 전혀 없을 때보다는 낫고 “오, 우리의 SIEM은 너무 마법 같아서 오류가 없어요!” 같은 싼 변명보다는 낫습니다. 그 다음에는 로그 흐름 양상 및 편차를 기반으로 초류 상관 관계 내용을 작성(또는 재사용?)하게 바쁠 것입니다(그런 내용의 결과에 만족하는 사람은 누구인가요? 그 리소스를 얼마나 먹어 치우나요?), 패킷 드롭 비율을 확인하기 위해 TCPdump를 실행하고 외부 소스를 통해 구성 요소 가용성을 모니터링하기도 합니다… 잠시 기다려 보십시오, 간단한 질문인 “내 네트워크 로그 데이터 가용성은 몇 %입니까?”에 답하기 위해 SIEM에 추가해야 할 3개의 추가 도구를 떠올리는 것 같습니다. 이를 자동화하려는 명확한 시도가 필요한 경우, 예를 들어 Splunk on Splunk, 실제로 효율적입니까? 얼마나 추가적인 라이선스 비용을 추가해야 SIEM/로그 관리 플랫폼을 자체 진단할 수 있게 되고 이 가장 인기 있는 앱이 얼마나 성능 오버헤드를 초래합니까?..

좋아요, syslog와 Splunk를 잠시 한쪽에 두고 두 번째로 인기 있는 로그 소스를 생각해 봅시다 – Microsoft Windows 이벤트 로그. 문제를 간단히 하자면: 로그 회전, 네트워크 대역폭, 인증 오류 / 비밀번호 잠금, WMI 및 JCIFS 불안정성, 바쁜 Windows 서버의 높은 부하(파일 감사, Active Directory 등). 이를 모니터링하기 위해서는 또 다른 도구 세트가 필요할 것이고, 이 도구들은 syslog 모니터링 도구와 비교할 때 다를 것입니다! 우리는 데이터베이스, 방화벽/ngfw/ips/ngips/utm(안녕 OPSEC & SDEE) 등을 포함한 긴 목록을 이어갈 수 있으며, SIEM 외부의 더 많은 일이 발생하고 있으며, SIEM에 영향을 미치지 않지만 알고 있어야 하는 일들을 발견할 것입니다(!) 그리고 이것들은 관리자가 신속하고 정확하게 이 정보를 제공해야 합니다. 그러나 여기까지 읽은 분들께는 좋은 소식이 있습니다. 대부분의 SIEM은 읽기 쉬운(거의) 진단 로그를 가지고 있기 때문입니다. 찾아보기 힘든 진단 파일들, 숨겨진 API 호출 또는 다중 라인 자바 스택 트레이스에서는 위에서 제기된 많은 문제들에 대한 답을 제공할 수 있는 정보의 비트와 바이트가 포함되어 있습니다. 그리고 이를 결합하고 의미 있는 프로파일링 지표를 적용함으로써 미션 크리티컬한 보안 탐지 플랫폼이 의도된 대로 작동하고 있는지, 문제를 무시하고 절반만 해결하는 것이 얼마나 다른지를 이해할 수 있습니다. 자동화는 프로젝트에서 계획된 대로, 조직/고객이 요구한 대로 로그 데이터가 사용 가능하며 SIEM 투자에 적절한 수익을 얻고자 하는 모든 사람들을 위한 것입니다. 이 글이 생각할 거리를 제공해 드렸기를 바랍니다. 곧 다시 돌아오겠습니다!

추신. 혹시 HPE ArcSight 전문가 중 한 명인 경우, 더 좋은 소식이 있습니다! 전 세계적으로 SIEM 플랫폼이 가치를 전달하고 SIEM 전문가들의 시간을 절약할 수 있도록 SOC Prime에서는 에이전트.log 파일을 먹고 5분 이내에 상위 5개의 치명적인 문제와 해결책을 제공하는 무료 온라인 즉석 SIEM 상태 점검 서비스를 제공합니다. 에이전트.log가 있습니까? 여기로 던져보십시오 보세요 .