Elastic Security를 통한 AWS 및 Okta 클라우드 플랫폼 보호 | Elastic Blog
엔지니어링

보안 운영: Elastic Security를 통한 클라우드 모니터링 및 탐지

많은 조직에서 인프라, 애플리케이션과 데이터를 클라우드 제품으로 마이그레이션하면서 범죄자들도 지적 재산 절도, 사업 운영 방해 또는 조직의 데이터를 볼모 삼아 몸값을 요구하는 등 목표를 이루기 위해 운영 역량을 클라우드 환경으로 확장하고 있습니다. 이러한 공격으로부터 사용자의 데이터를 지키기 위해 Elastic Security Intelligence & Analytics Team에서는 클라우드 엔드포인트에서 공격자의 행동을 탐지하는 규칙을 연구 및 개발하고 있습니다.

이 포스팅에서는 클라우드 모니터링과 보안 운영팀이 마주하는 탐지 관련 애로 사항을 살펴보고 왜 클라우드 환경에 대한 공격이 성공으로 끝나는 경우가 많은지 설명합니다. 당사의 무료 클라우드 탐지 규칙(Elastic Security 7.9에서 출시된 신규 버전 참조)에 대한 상세 정보를 공유하고 어떻게 Elastic Security 사용자들에게 도움이 되는지 살펴보겠습니다.

또한 Elastic의 광범위한 클라우드 플랫폼에서 로그를 수집하는 방식과 Elastic Common Schema(ECS)를 통해 검색, 모니터링과 감지가 어떻게 쉬워지는지에 대해서도 설명합니다.

클라우드 모니터링과 탐지 애로 사항

Security 팀에서 조직의 클라우드 환경 위협 모니터링, 탐지 및 응답을 요청받으면 보통 다음과 같은 애로 사항을 하나 이상 겪습니다.

  • 리소스 제약: 클라우드 기술과 변화를 거듭하는 데이터 소스를 알아가고 이해하려면 상당히 많은 시간이 소요될 수 있습니다. 많은 보안 운영팀에서는 이러한 지속적인 노력에 할당할 리소스가 없는 실정입니다.
  • 적대적 스파이 기법 이해: Windows 등 잘 알려져 있는 플랫폼에서의 공격 행동은 폭넓게 연구되어 보안 커뮤니티에 공유되어 있습니다. 그러나 보안팀은 클라우드 환경에서는 공격자들이 어떻게 움직이는지와 조직을 보호하기 위해 공격 및 방어 기술을 실현해보는 테스트 환경을 프로비저닝하는 능력에 대해 심도 있는 이해를 하지 못할 가능성이 높습니다.
  • 사각지대: 효과적인 모니터링 및 감지를 위해서는 보안 실무자가 이용할 수 있는 데이터가 관련성이 높고 정확하며 시기적절해야 합니다. SIEM에 전송되는 클라우드 로그는 보안팀이 데이터 품질을 신뢰할 수 있을 때에만 감지 및 응답에 사용할 수 있습니다.
  • 데이터 정규화: 대부분의 클라우드 플랫폼에는 자체적인 로그 분류와 이벤트 스키마가 있습니다. 로그를 공통 스키마로 정규화하는 것은 사소하거나 일회적인 작업이 아닙니다. 예를 들어 일부 보안팀에는 SIEM에 색인한 데이터 소스 전반에서 호스트 이름에 대해 다양한 필드 이름이 있습니다. 정규화 및 기록된 스키마가 없으면 분석, 특히 경험이 적은 경우에 검색 쿼리를 쓰거나 데이터 소스 전반의 이벤트를 효과적으로 적용시키는 것이 어렵습니다.

Elastic으로 클라우드 로그 수집 및 검색

Elastic에는 Amazon Web Services(AWS), Azure, Okta, Office 365 등의 클라우드 플랫폼을 비롯해 다양한 로그 형식을 공통 스키마로 수집, 파싱, 그리고 시각화를 간소화하는 데 사용할 수 있는 방대한 양의 Filebeat 모듈 모음이 있습니다. 새로운 Filebeat 모듈의 빠른 개발이 진행 중입니다.

Elastic Common Schema(ECS)는 연결된 데이터 소스(예: AWS/Okta)를 Elasticsearch로 로그를 수집하는 데 대한 공통 필드 세트를 정의합니다. 로그 데이터는 다양한 필드 이름을 쿼리에 사용하여 데이터 소스 전반에서 행동을 관련시키는 형식으로 정규화됩니다. 이와 같은 작업이 보안과 IT 운영팀에게 유용한 이유가 몇 가지 있습니다.

실무자와 관리자는 필드 이름이 자체 공통 스키마를 따르도록 수집한 로그를 변환 또는 정규화하는 데 수많은 시간을 보낼 필요가 없습니다. 이렇게 스키마를 관리하는 것은 쉬운 일이 아니며 지속적인 노력이 필요합니다. Elastic에서는 보안팀이 데이터를 빠르고 효율적으로 검색하기 위해 공통 필드 이름 세트를 믿고 맡길 수 있도록 ECS(사용자의 시간 및 리소스 절약)를 관리합니다.

최종 사용자는 여러 데이터 소스에서 검색 시 쿼리에 동일한 필드 이름을 사용할 수 있으며 여기에는 다음과 같은 이점이 있습니다.

  • 검색에 대한 일관적인 스키마가 있으면 보안 분석가의 시간이 절약되며 신규 분석가를 위한 진입 장벽이 낮아집니다. 분석가는 다양한 필드 이름과 각각의 데이터 소스에 대한 목적을 모두 알거나 기억할 필요가 없습니다.
  • 분석가는 엔드포인트, 프록시, 방화벽 등 데이터 소스 전반에서 이벤트를 관련시킬 수 있으며 이로 인해 더욱 효율적으로 데이터에 대한 질문을 할 수 있으며 조사, 인시던트 또는 헌팅 시 올바른 결정을 내리는 데 도움이 됩니다.
  • 분석가가 타임라인을 만들거나 발생한 활동의 시각화를 빌드하는 것이 쉽습니다.

클라우드 환경에서의 공격자 운영 감지

적대적 스파이 기법에 대한 Elastic Security Intelligence & Analytics Team의 연구는 작은 보안팀도 큰 영향을 끌어낼 수 있도록 하는 역량, 즉 규칙과 머신 러닝 작업과 같은 새로운 감지 기능으로 이어지게 되었습니다. 이와 같은 보안 기능은 공격자들의 공격 비용을 높입니다. Elastic Security 사용자는 클라우드 공격 비용을 증가시키는 데 지속적인 중점을 두는 것을 기대할 수 있습니다.

이 블로그 포스팅의 나머지 부분에서는 AWS와 Okta 클라우드 환경에 대한 공격 기술을 시뮬레이션 해보겠습니다. 의심스러운 활동으로 인해 발생하는 경보(Alert)와 Elastic Security를 사용해 분석가가 최초 분류를 수행하고 조사를 완료하는 방법을 검토합니다. 또한 분석가가 양성 이벤트를 필터링하고 의심 행동을 계속해서 경고할 수 있도록 감지 규칙에 예외 사항을 추가하는 방법도 보여드립니다.

AWS CloudTrail 로그 모니터링으로 의심 행동 감지

AWS와 같은 클라우드 플랫폼에 마이그레이션하거나 새로운 인프라를 프로비저닝하면서 위에 설명한 일반적인 도전 과제에 직면합니다. 다행히 Elastic Security에는 강력하고 다양한 AWS 규칙7.9에서 무료로 사용이 가능해 AWS 환경에서 의심스러운 행동을 감지할 수 있습니다.

AWS용 Filebeat 모듈은 Elastic Security에서의 모니터링 및 감지를 위해 CloudTrail, Simple Storage Service(S3), Elastic Load Balancing(ELB), 가상 비공개 클라우드(VPC) 플로우 로그를 Elasticsearch로 쉽게 전송할 수 있게 해줍니다. CloudTrail 데이터를 활용한 공격 및 방어 시나리오를 살펴보겠습니다. CloudTrail은 AWS 관리 콘솔, AWS 소프트웨어 개발 키트(SDK), 명령줄 도구 및 기타 AWS 서비스를 통해 취한 조치를 비롯한 AWS 계정 활동의 이벤트 이력을 제공합니다. 이러한 이벤트 이력은 보안 감지, 분석과 조사를 간소화하는 데 도움이 됩니다.

AWS를 향한 많은 공격은 공격자가 액세스 키 및/또는 비밀 액세스 키 상세 정보를 얻으면서 시작됩니다. 이러한 키는 피싱, 데이터 침해, GitHub 리포지토리, 스크린샷, 오류 메시지, 스냅샷 데이터, 또는 단순한 잘못된 키 관리 방식 등을 통한 다양한 방식으로 획득하게 됩니다. 공격자는 키를 획득하여 AWS 인프라에 다양한 조치를 취할 수 있습니다.

진행 가능한 다양한 공격 시나리오 중 하나를 살펴보겠습니다. 다음 예시에서는 공격자가 AWS 계정에 대해 구성한 트레일과 모니터링 역량을 열거합니다. 이들은 이러한 활동 이후 감지를 피하고 기밀 사항을 획득하기 위해 트레일과 구성 레코더를 비활성화합니다.

AWS에서 공격자 행동 모의 실험

이 시연에서는 Pacu를 사용해 공격을 수행합니다. Pacu는 AWS 인프라를 이용하기 위한 대중적인 프레임워크로 Rhino Security Labs에서 개발 및 유지관리합니다. Pacu는 Metasploit와 Koadic과 같은 기타 개발 프레임워크와 유사하게 모듈식으로 공격자가 AWS 계정 내의 구성 결함을 활용할 수 있게 합니다. 공격자는 Pacu를 사용해 모듈을 실행하기 전에 잠입한 계정에 필요한 허가가 할당되었는지 확인할 수 있습니다. 이는 공격자의 입장에서 불필요한 노이즈나 로그를 발생시키지 않고 궁극적으로 실패할 모듈을 실행하여 방어자의 추가적인 주의를 끌지 않기 때문에 유용합니다.

공격자는 detection__enum_services 모듈을 사용해 서비스를 열거하는 것으로 시작해 AWS 계정에 대해 어떤 로깅 및 모니터링 서비스가 활성화되어 있는지 판단합니다.

1-enumerating-services-blog-secops-cloud-platform-monitoring.png

그림 1 - Pacu의 detection__enum_services 모듈을 사용한 서비스 나열

공격자는 여덟 가지의 트레일과 열 가지의 구성 규칙, 레코더와 전송 채널을 발견했습니다. 기본적으로 나열 스크립트는 특정 AWS API 호출을 쿼리해 환경에 대한 관련 정보를 나열하거나 설명합니다. 모듈의 코드를 검토하면 대상 API를 확인할 수 있습니다.

DescribeSubscription
GetSubscriptionState
DescribeTrails
ListDetectors
DescribeConfigRules
DescribeConfigurationRecorders
DescribeConfigurationRecorderStatus
DescribeDeliveryChannels
DescribeDeliveryChannelStatus
DescribeConfigurationAggregators
DescribeAlarms
DescribeFlowLogs

어떤 서비스가 실행 중인지 공격자가 판단하고 나면 다음 논리적 단계는 탐지를 피하기 위해 트레일, 경보, 탐지기 또는 레코더를 비활성화하여 로깅과 모니터링을 방해하는 것이 됩니다. 이러한 목표를 달성하기 위해 detection__disruption라는 다른 모듈을 사용하여 brentlog라는 트레일을 비활성화하고 default라는 이름의 구성 레코더를 중지시키겠습니다.

2-disabling-trail-blog-secops-cloud-platform-monitoring.png

그림 2 - Pacu의 detection__disruption 모듈을 사용한 트레일 비활성화 및 구성 레코더 중지

이 시점에서 트레일 로깅은 중단되었고 구성 레코더는 리소스 변경 추적이 꺼진 상태로 공격자는 비밀 관리자에서 사용할 수 있는 자격 증명, API 키 또는 토큰이 있는지 확인하고 있다면 수집할 것입니다. 이 시나리오에서는 공격자가 enum_secrets 모듈을 사용해 디렉터리에서 하나의 비밀(/sessions/brent/downloads/secrets/secrets_manager)을 찾아냅니다. 이러한 비밀을 수집하는 것은 공격자가 측면 이동 및/또는 권한 확대를 달성할 수 있도록 할 수 있습니다.

3-searching-aws-blog-secops-cloud-platform-monitoring.png

그림 3 - Pacu의 enum__secrets 모듈을 사용한 AWS 비밀 검색

4-viewing-aws-blog-secops-cloud-platform-monitoring.png

그림 4 - 발견 이후 AWS 비밀 확인

이제 가상의 공격 시나리오는 여기에서 중단하지만 공격자가 그 다음으로 무엇을 할 수 있을지 궁금하다면 다음과 같은 Google 검색으로 몇 가지 예시를 볼 수 있습니다. intitle:"AWS" intext:("attack" | "breach"). 다음 섹션에서는 이와 같은 행동이 방어자의 관점에서는 어떻게 보이는지, 그리고 이러한 행동을 감지하기 위해 Elastic Security를 어떻게 사용할 수 있는지 살펴봅니다.

AWS에서의 의심 행동 감지 및 조사

이전에 언급한 API의 사용 모니터링 중에는 해롭지 않은 활동과 공격자의 환경 나열 등 의심스러운 행동을 구분하는 것이 어려울 수 있습니다. 생산 환경에서는 이러한 행동이 일반적이기 때문에 이러한 API에 대한 호출을 모니터링하는 것에 노이즈가 클 수 있습니다. 이러한 드물고 잠재적 의심이 가는 행동을 확인하기 위해 사용할 수 있는 AWS 탐지 규칙 이외에도 비정상적 행동 패턴 등 일반적인 탐지 규칙을 사용해 파악하기 힘든 이상값을 파악하는 데 도움이 될 AWS CoudTrail만을 위한 머신 러닝 작업을 7.9에 배포했습니다.

이전 공격에서의 탐지 페이지를 살펴보면 여러 개의 경보가 발생한 것을 확인할 수 있습니다. 당사의 무료 기본 제공 탐지 규칙은 트레일 중단, 구성 레코더 중지비밀 관리자에서 민감한 정보 분리 기술을 파악했습니다. 기타 경보는 AWS 명령에 대한 비정상적 국가사용자의 비정상적 AWS 명령이라는 머신 러닝 작업으로부터 확인된 것으로 일반적으로 명령을 사용하지 않는 명령 또는 사용자 맥락에서 비정상적인 지역(국가)를 파악합니다.

5-viewing-detection-alerts-blog-secops-cloud-platform-monitoring.png

그림 5 - Elastic Security에서 탐지 경보 확인

머신 러닝 경보 중 하나를 중점으로 하면 비정상적인 CloudTrail 이벤트 분석 시 분석가를 잠재적 워크플로우로 안내하는 기본 제공 조사 가이드와 함께 탐지한 행동의 설명을 확인할 수 있습니다.

6-machine-learning-alert-blog-secops-cloud-platform-monitoring.png

그림 6 - 머신 러닝 경보의 상세 정보 확인

7-viewing-investigation-notes-blog-secops-cloud-platform-monitoring.png

그림 7 - 비정상적 CloudTrail 이벤트에 대한 조사 메모 확인

이제 중지된 AWS 구성 레코더 경보에서 타임라인 뷰로 상세 정보를 확인해보겠습니다. 특별히 관심을 기울이는 필드는 API 호출, 사용자 에이전트 스트링, 사용자 신원 유형, 요청 파라미터와 전체 이벤트의 원시 텍스트입니다. 

8-alert-details-timeline-blog-secops-cloud-platform-monitoring.png

그림 8 - 타임라인에서 경보 상세 정보 분석

경보를 분석함으로써 다음을 빠르게 판단할 수 있습니다.

필드

Description

event.action

실행된 AWS API 호출 StopConfigurationRecorder을 알려줍니다

request_parameters

요청에서 무엇을 전송했는지에 대한 상세 정보를 제공하며 이 경우에는 구성 레코더 이름 default입니다

user.name

요청을 보낸 사람이 누구인지 알려줍니다, pacu

user_identity.type

신원 및 액세스 관리(IAM) 신원 유형에 대한 상세 정보를 포함합니다. 이 경우에는 IAMUser입니다. 루트는 규칙을 구축한 또 다른 사용자의 신원 유형입니다.

user_agent

HTTP 사용자-에이전트 헤더 값입니다. 사용자 에이전트 스트링은 쉽게 수정할 수 있으나 계정이 API 호출에 대해 일반적으로 AWS Java SDK를 사용하고 이것이 변경된 경우 이례적인 사용자 에이전트 스트링의 감지는 빠른 승리가 될 수 있습니다.

event.original

처리하지 않은 경보 상세 정보를 제공합니다

표 1 - 경보 필드 분석

경보를 분석하고 난 후에는 이벤트를 종합하여 경보 직전(해당하는 경우 이후)에 사용자가 어떤 조치를 취했는지 살펴볼 수 있습니다. 여기에서도 공격자의 나열을 확인할 수 있습니다. 

9-event-history-blog-secops-cloud-platform-monitoring.png

그림 9 - 타임라인에서 사용자 Pacu에 대한 이벤트 이력 확인

또한 특정 API 호출에 대한 환경을 검색하여 자체 환경에서는 의심스러울 수 있는 다른 사용자 또는 호스트를 통해, 다른 IP로부터 또는 다른 시간대에 적용된 것인지 확인하는 것이 좋습니다.

10-api-history-blog-secops-cloud-platform-monitoring.png

그림 10 - 타임라인에서 StopConfigurationRecorder API에 대한 호출 이력 확인

또한 시각화를 생성하여 환경에서 가장 일반적이지 않은 API 콜을 살펴보고 이를 중점으로 시작할 수 있습니다. AWS의 경우 API 콜은 event.action 필드에 있습니다. 

11-visualization-api-calls-blog-secops-cloud-platform-monitoring.png

그림 11 - 시각화를 사용하여 주어진 환경에서 가장 일반적이지 않은 API 호출 확인


시연한 대로 AWS에 대해 무료 기본 제공 규칙은 이러한 행위뿐 아니라 기타 여러가지 잠재적 공격 시나리오를 탐지할 수 있습니다. 당사에서는 규칙 리포지토리를 개방해 관심이 있는 경우 살펴보고, 기여할 수 있는 방법을 알아보시는 것을 권장합니다. 

Okta 로그의 의심 행동 감지

Okta 싱글 사인온(SSO)은 단일 사용자 계정을 사용한 중심화 과정을 통해 조직에서 사용자가 다양한 시스템에 로그인할 수 있는 클라우드 솔루션입니다. 최종 사용자에게 열 가지 이상의 값 대신 하나의 사용자 이름과 비밀번호만 기억해도 된다고 하면 잘못된 비밀번호 사용을 줄이게 하고 시스템 관리자가 강력한 비밀번호 정책을 시행하게 할 수 있습니다. 또한 공격자의 진입 장벽을 높일 수 있는 다단계 인증(MFA) 정책도 Okta에 구성할 수 있습니다. 많은 공격자들은 공격 대상의 네트워크나 사용자 계정에 MFA를 시행하는 것을 발견하면 이를 건너뛰고 단순히 더 쉬운 공격 대상을 찾게 됩니다.

SSO 솔루션은 편리한 사용자 경험을 제공하고 조직에 대한 사이버 보안 위험을 줄이는 반면 많은 시스템과 애플리케이션에 곁쇠 유형을 제공하는 이러한 중앙집중 시스템은 공격자에게 매력적인 공격 대상이 될 수 있습니다. 예를 들어 공격자가 Okta 관리자의 자격 증명 또는 API 토큰을 수집하게 되는 경우 이들은 대략 다음과 같은 행동을 시도할 수 있습니다.

  • 피해자의 보안 제어를 약화시키기 위해 하나 이상의 애플리케이션에 대해 MFA 정책을 수정 또는 비활성화합니다.
  • 새로운 사용자 계정 또는 API 토큰을 생성해 공격 대상의 환경에 잔존하며 “잠입”하여 탐지를 피하는 방식을 시도합니다.
  • Okta 네트워크 구역을 수정, 삭제 또는 비활성화해 사용자나 관리자가 로그인할 수 있는 지역 제한을 약화시킵니다.
  • 애플리케이션이나 다른 구성을 삭제 또는 비활성화해 서비스 거부(DoS) 상태를 만들어 회사의 사업 운영에 영향을 미칩니다.

보안팀이 Okta 환경에서 의심 활동을 모니터링하려면 당사의 Okta Filebeat 모듈에서 Okta 시스템 로그 이벤트를 수집해 Elasticsearch에 전송하여 색인할 수 있습니다. Okta의 시스템 로그는 조직에 관련된 이벤트를 기록해 플랫폼 활동을 이해하는 데 사용할 수 있는 트레일 감사를 제공합니다. Elastic Security Intelligence & Analytics Team은 무료 규칙이 있어 Okta 로그에서 의심 활동을 감지하고 추후에도 계속해서 활동을 추가하게 됩니다.

다음 예시에서는 공격자가 조직의 네트워크에 최초로 접근한 이후 API 토큰을 획득했다고 가정해보겠습니다. API 토큰에는 관리자 권한이 있으며 공격자는 공격 대상의 Okta 환경에서 일부 조치를 실행합니다.

  • 보안팀이 현재 API 토큰이 노출되었음을 확인한 경우 공격 대상 환경에서 존재감을 유지하기 위해 사용자 계정을 생성하고 관리 허가를 할당합니다
  • 공격 대상의 보안 제어를 약화시키기 위해 사인온 정책을 비활성화합니다
  • 공격자가 침입 시 모든 지역에서 인증을 받을 수 있도록 네트워크 구역을 비활성화합니다

Okta Filebeat 모듈은 Okta 시스템 로그 이벤트를 Elasticsearch에 전송하고 Okta 규칙이 Elastic Security에서 활성화되도록 구성되었습니다. 아래 그림 12에 나온 것과 같이 의심 활동은 세 가지의 경보를 발생시켰습니다.

12-okta-alerts-blog-secops-cloud-platform-monitoring.png

그림 12 - 의심 활동으로 인해 생성된 Elastic Security에서의 Okta 경보

경보 중 하나를 클릭하면 분석가의 규칙이 탐지한 행동의 설명, 보안 및 위험 점수, 관련 MITRE ATT&CK® 전술 및 기법을 비롯해 규칙에 대해 더 많은 정보를 검토할 수 있습니다. 분석가는 페이지 아래로 스크롤을 내려 타임라인의 경보 조사를 시작할 수 있습니다.

Elastic에서 ATT&CK를 어떻게 지원하는지 알아보시려면 다음 프리젠테이션을 확인하세요. 헌팅 계획 및 실행 방법.

13-rule-information-blog-secops-cloud-platform-monitoring.png

그림 13 - 규칙 정보 및 설정 확인

보안 실무자는 모든 조직의 네트워크가 상이하다는 것을 알고 있습니다. 한 곳의 환경에서 의심스러워 보이는 행동도 다른 곳에서는 무해한 것일 수 있습니다. 보안팀에서 “소음에서의 신호”를 발견하도록 하려면 무해한 이벤트를 필터링하고 의심 이벤트에 대한 경보를 지속하도록 사용자가 탐지 규칙에 예외 사항을 추가할 수 있습니다. 그림 14에서는 Okta 규칙에 추가한 예외 사항이 나와 있습니다.

14-adding-exception-blog-secops-cloud-platform-monitoring.png

그림 14 - Elastic Security에서 규칙에 예외 사항 추가

지금까지 “임계점” 규칙 유형을 소개했습니다. 임계점 규칙은 일치하는 이벤트가 일정 임계점을 초과할 때 쿼리 결과를 종합하고 경보를 생성합니다. 아래 예시 규칙은 단일 소스 IP 주소에서 25가지의 Okta 사용자 인증 실패가 발생할 때 경보를 생성합니다. 이는 강제 침입 또는 비밀번호 스프레이 공격을 나타내는 것일 수 있습니다.

15-okta-brute-force-blog-secops-cloud-platform-monitoring.png

그림 15 - Okta 강제 침입 공격 감지를 위해 구성된 임계정 규칙 검토

타임라인에서 임계점 규칙으로 생성된 경보를 확인하면 분석가는 규칙을 트리거한 이벤트를 검토하고 분류 과정 또는 조사를 시작할 수 있습니다.

16-reviewing-alert-blog-secops-cloud-platform-monitoring.png

그림 16 - 타임라인에서 실패한 Okta 인증 임계점 규칙으로부터 경보 검토

결론

Verizon의 최신 데이터 침해 조사 보고서에 따르면 작년에 검토한 보고서에서 3,950건 데이터 침해건의 24%에 클라우드 자산이 포함되어 있었다고 합니다. 조직에서 데이터와 사업 운영을 클라우드로 계속 이전하면 이러한 수치도 증가할 것으로 예상합니다.

이 블로그 포스팅에서는 조직의 클라우드 환경에서 의심 행동을 모니터링, 탐지 및 조사할 때 보안팀이 직면하는 몇 가지 도전 과제를 살펴보았습니다. 공격자가 클라우드 환경에서 어떻게 행동하며 Elastic Security가 이러한 기술을 어떻게 탐지하는지 일부 실질적인 예시도 살펴보았습니다.

Elastic Security Intelligence & Analytics Team은 클라우드를 비롯한 다양한 플랫폼에 대한 적대적 스파이 기법을 연구하고 새로운 탐지 규칙 및 머신 러닝 작업을 개발하고 있습니다. 사용자들은 당사에서 클라우드 공격의 비용을 증가시키는 데 초점을 맞추는 것을 계속 기대하실 수 있습니다.

당사의 Filebeat 모듈을 구성해 손쉽게 Elasticsearch에 로그를 전송하고 Elastic Security에 탐지 규칙을 활성화할 수 있습니다. 당사의 무료 탐지 규칙은 보안팀에서 팀의 규모와 관계없이 이러한 로그를 모니터링하고 의심 행동을 탐지할 수 있게 해줍니다. 분석가는 Elastic Security를 통해 이러한 경보를 빠르고 효율적으로 분류 및 조사할 수 있습니다.

Elastic Security에 대해 더 자세히 알아보고 싶다면 무료로 다운로드하거나 Elastic Cloud 14일 무료 체험판에 가입하세요.