2018년 5월 3일 사용자 스토리

Saas 기반의 보안 운영 다용도 도구의 일환으로 Elastic Stack 사용하기

By James Spiteri

이 글은 더 오래된 이름인 Elastic Cloud에서 제공하는 호스트형 Elasticsearch 제품에 대한 것입니다.이 글은 더 오래된 이름인 Elastic Cloud에서 제공하는 호스트형 Elasticsearch 제품에 대한 것입니다. Elastic Cloud는 이제 Elasticsearch Service라고 하며, Amazon Elasticsearch Service와는 다른 것이라는 점에 유의하세요. 더 자세한 내용은 AWS Elasticsearch 비교 페이지에서 확인해 보실 수 있습니다.

RS2에서 보안은 모든 업무의 핵심입니다. 우리 회사의 주력 제품인 BankWORKS는 장치 트랜잭션 수집에서 최종 정산 및 원장 통합에 이르는 전체 결제 처리에 필요한 모든 기능을 갖춘 엔드 투 엔드 통합 솔루션입니다. 규모와 복잡성을 막론한 전 세계의 은행, 프로세서, 결제 서비스 제공업체에서 이 소프트웨어를 사용하고 있습니다. 또한 우리 회사는 호스트형 관리 서비스의 일환으로 제품을 제공합니다.

팀으로서 우리는 데이터가 영향을 받거나 유출되는 위험을 확실하게 최소화하면서 동시에 여러 준수 요건을 충족시키고, 또한 이 모든 일을 일상적인 운영을 방해하지 않는 와중에 이뤄낼 책임을 집니다.

2017년 11월에 우리 회사는 보안 팀을 증원할 계획을 하고 있었습니다. 하지만 추가 채용에 대한 승인을 받기 전에, 사건과 보안 이벤트 처리에 관련된 일부 수동 절차를 줄일 필요가 있었습니다. 바로 그때 Elastic Stack과 우리 회사의 여정이 시작된 것입니다.

제안에서 생산에 이르는 여정

초기 단계

저는 이전에 다른 업무를 담당할 때와 개인 프로젝트에서 Elastic Stack을 사용해 본 적이 있었으므로, 제품을 팀에 소개하기를 원했습니다. 제품이 그 폭넓은 기능 세트와 확장성 덕분에 우리의 모든 요구 사항을 충족시켜줄 수 있으리라 느꼈던 것이죠.

RS2에서 새로운 직위를 맡은 처음 며칠 동안 저는 Elasticsearch와 Kibana 인스턴스(이 사례의 경우 버전 6)를 몇 가지 Beats(packetbeat, auditbeat, metricbeat, filebeat)가 VM에 설치된 랩탑의 가상 머신에서 스핀업했으며 모든 데이터를 Elasticsearch에 곧바로 전송했습니다. 전체 프로세스에는 약 한 시간(운영 체제 ISO 이미지 다운로드 및 설치에 소요된 40분 포함)이 소요되어 유의미한 데이터가 Kibana 내에 채워졌습니다.

저는 이를 동료에게 보여주었는데, 그는 망설임 없이 이 방식이 성공을 거둘 수 있을 것이라는 점에 동의했으며, 이에 우리는 경영진에게 시연하기 위해 실제 데이터가 사용되어 성능이 강조된 데모를 만들어야 했습니다. 우리는 제3자 통합을 비롯해 (다른 Beat 및 Logstash를 사용하여) 생산 네트워크에 어떤 변경도 필요 없는 일부 네트워크 장치 및 기존 서버를 포함시키기로 결정했습니다.

클라우드 평가

저는 이전에 담당한 업무에서 여러 서버를 대상으로 대규모 Elastic 배포를 호스트했습니다. 하지만 Elastic Cloud가 무엇을 제공하는지 제대로 살펴본 적은 없었습니다. RS2는 클라우드로의 즉각적인 마이그레이션으로 인해 “인프라 고정”을 하게 되었습니다. 이러한 점과 더불어, 촉박한 마감 시한 및 제한된 자원 때문에 Elastic Cloud에 대해 알아보게 되었습니다. 저는 보안 전문가로서 Elastic Cloud에 대해 회의적이었습니다. 저는 이 서비스가 제가 생각하는 수준의 보안으로 설계되었는지 확인하기를 원했습니다.

저는 클러스터를 확보하고 나서 몇 가지 간단한 보안 테스트를 수행하여 드러난 취약성이나 약점을 찾아낼 수 있는지 확인했습니다. 제가 발견한 점은 다음과 같습니다.

  • Elastic에서는 사용자가 백엔드 클라우드 제공자로 AWS와 GCP 둘 중 선택할 수 있게 해주며, 따라서 준수 자격과 함께 모든 보안 기능을 물려받게 됩니다.
  • 각 제공자에 대해 기본 서브넷이 사용되는 것이 아니라, 각 클러스터별로 분리된 네트워크가 사용됩니다.
  • Elasticsearch와 Kibana URL 모두에 대해 최신 TLS 설정 및 암호가 사용됩니다.
  • Elasticsearch 전송 포트가 무작위화됩니다.
  • 각 인스턴스의 URL 또한 완전히 무작위화되므로 고객 이름을 열거하는 것은 가능하지 않습니다.
  • 직접 IP 액세스는 클러스터 ID 없이 가능하지 않습니다.
  • 가장 최근에 출시된 Elastic Stack이 Java 8의 최신 버전과 함께 사용됩니다.

한 곳에 모으기

이제 클라우드 클러스터가 생겼기 때문에 데이터 흐름을 설계해야 했습니다. 아래의 다이어그램은 POC에 대한 아키텍처의 개요를 보여줍니다.

다이어그램 - POC에 대한 아키텍처

우리는 X-Pack을 이용할 수 있었기 때문에, 알림 프레임워크로서 Watcher를 많이 활용했습니다. 이는 Watcher 웹후크 조치를 통해 사용자 정의 Slackbot과 통합되었습니다.

데모 준비 – 데이터를 활용한 작업

첫 번째 단계는 가능한 많이 구문을 분석하고 로그를 강화하는 것이었습니다. 강화는 보안에 관련된 맥락에서 분석가가 조사에 들이는 시간을 크게 줄여주기 때문에, 사고를 신속하게 해결하는 비결입니다. 또한 가양성을 필터링하는 데 도움이 됩니다. 저는 여러 Logstash 필터 플러그인을 사용하여 이러한 작업을 쉽게 해낼 수 있었습니다. 거기에 더해, 기존 로그 아카이빙 도구를 제공하기 위해 여러 Logstash 출력이 데이터를 Elastic 클러스터와 기존 아카이빙 도구에 동시에 전송하도록 설정할 수 있었습니다.

다음은 우리가 구문 분석한 로그에 추가된 강화 운영 작업 목록의 일부입니다.

  • GeoIP 데이터(위치 및 ASN)
  • 맬웨어 IP 조회
  • 허가된 로그인 사용자 조회
  • 사용자 에이전트 구문 분석
  • URL 디코딩

이 목록은 POC에 대한 강화 설정의 일부입니다. 우리가 생산 단계로 이동한 이후에 훨씬 더 많은 것이 추가되었습니다.

이 모든 데이터의 구문 분석이 훌륭하게 이뤄졌기 때문에 사용자 정의 대시보드를 만들어서 내장된 기능과 함께 작동하여 이전에 언급된 강화 기능 일부가 강조되게 했습니다. 다음은 POC에 대해 개발된 사용자 정의 Kibana 대시보드의 몇 가지 사례입니다(민감한 데이터는 모두 삭제됨).

Kibana Dashboard 1.jpg

Kibana Dashboard 2.jpg

Kibana Dashboard 3.jpg

Kibana Dashboard 4

여기에 더해, 그 밖의 인기 있는 몇 가지 통합이 Elastic에 데이터를 추가하기가 얼마나 단순한지 시연할 목적으로 추가되었습니다. 결론적으로 말씀드리면 이는 또 다른 색인에 불과할 정도로 단순했습니다. 그 한 가지 예는 Troy Hunt의 인기 있는 서비스인 "Have I been Pwned"와의 통합이었습니다. 해당 서비스는 이메일 주소가 공개된 데이터 위반 건에서 감지될 때 사용자가 쿼리할 수 있게 해 주는 매우 간편한 REST API를 제공합니다. 도메인에 대한 새로운 항목을 알리는 조사식이 생성되었습니다.

알림

POC에서 알림 프레임워크 이면의 원리(나중에 생산 단계에서 사용됨)는 모든 것이 Slack을 통해 실행 가능하도록 하는 것입니다. 다음은 Slackbot 내에서 조작된 데이터의 몇 가지 예입니다. 분석가가 조사를 시작하기 위해 필요로 하는 모든 것을 포함합니다. 사용된 데이터는 Logstash를 통해 구문 분석된 네트워크 장치 로그와 다양한 Beats를 통해 수집되었습니다.

데이터 세트 가운데는 다음이 포함되어 있습니다.

  • SMTP 릴레이 로그, 인증 로그, 방화벽의 패킷 필터 로그
  • Packetbeat를 사용한 패킷 수준 DNS 요청
  • Wazuh와 Filebeat의 통합을 통한 SSH/SFTP 로그
  • Metricbeat를 통한 프로세스와 그 상태의 목록
  • *nix 시스템의 Auditbeat를 통한 아웃바운드 네트워크 소켓 모니터링

다음은 POC에 대해 개발된 Slackbot 알림의 몇 가지 사례입니다(민감한 데이터는 모두 삭제됨).

  • TeamViewer 연결 알림

    TeamViewer 연결 감지됨
  • 방화벽 로그인 알림

    RS2 - 보안 봇 - 방화벽 로그인 감지됨
  • 맬웨어 알림

    RS2 - 보안 봇 - 맬웨어 IP와의 통신 감지됨

결과

말할 필요도 없이 POC는 엄청나게 성공적이었으며 생산 단계로 진행해도 좋다는 승인을 받았습니다. 재차 말하자면, 우리가 이 POC를 이처럼 매끄럽게 진행할 수 있었던 핵심 요인은 다음과 같습니다.

  • Elastic Cloud와 포함된 모든 요소(상자 밖 통합 백업, 복원력, 고가용성, 배포 규모에 맞는 번들 형태의 X-Pack)의 사용이 엄청나게 쉽고 빠름.
  • 어떠한 데이터든 취하고 나서 유용하며 실행 가능한 무언가로 매우 신속하게 바꿔내는 성능(POC는 구문 분석, 대시보드, 강화, 알림 프레임워크 등 이 포스트에 언급된 모든 작업을 구현하는 데 그 시작부터 마칠 때까지 약 3일이 소요되었음).
  • 모든 기존 프로세스와 병행하여 중단 없이 이뤄질 수 있다는 사실.

업그레이드 처리

생산 단계에서 몇 주가 지난 뒤, Elastic에서 릴리스한 업데이트가 있었습니다. 이전에 X-Pack을 통해 대규모 Elastic 배포를 업그레이드한 적이 있는 저는 업그레이드가 그 회사의 자체 클라우드 플랫폼을 통해 어떤 방식으로 이뤄질지 매우 궁금했습니다. 알고보니, 드롭다운 메뉴에서 새로운 버전을 클릭하는 것만큼 단순했습니다. 그 밖의 모든 것은 중단 없이 자동으로 이뤄졌습니다.

결론

Elastic과 함께하는 우리의 여정은 그것으로 끝나지 않았습니다. 우리는 새롭게 발견한 위협 및 악성 활동에 기반해 이동 과정에서의 더 많은 데이터 소스, 더 많은 강화(사용자 휴가 데이터를 얻기 위한 HR 시스템과의 연계 및 건물 내에서 누군가의 소재 여부를 확인하는 실제 액세스 시스템), 알림을 지속적으로 추가하고 있습니다. 또한 우리가 사용하는 추가 내부 도구의 통합 작업도 하고 있습니다.

우리는 Elastic과 함께하는 보안 분석의 미래가 기대됩니다. 매번 업데이트를 통해 Elastic은 분석가들이 보다 편안하게 생활하고 만족스럽게 업무를 수행하도록 추가 구성 요소를 릴리스합니다. 또한 Elastic Cloud의 향후 업그레이드에 대해서도 같은 기대를 갖고 있습니다. 의문의 여지 없이 RS2는 보안 분석 뿐만 아니라 조직 전반을 위해 이 폭넓은 기능 세트의 장점을 계속 활용할 것입니다.