jonrau1/syntheticsun서버리스 AWS 보안 자동화 프레임워크로, 위협 인텔리전스를 수집하고 ML 기반 이상 탐지(RCF, IP Insights)를 적용하며, Kibana에서 보안 텔레메트리를 보강하여 자동화된 위협 예방, 탐지 및 대응을 수행합니다.
SyntheticSun은 위협 인텔리전스, 머신 러닝, 관리형 AWS 보안 서비스 및 서버리스 기술을 활용하여 지속적으로 위협을 예방, 탐지 및 대응하는 심층 방어 보안 자동화 및 모니터링 프레임워크입니다.
당신은 깨진 유리 조각 속에서 잠들고
당신의 모습이 비치지만,
당신은 살아 있다고 느끼나요?
네, 묻겠습니다,
당신은 살아 있다고 느끼나요?
- Norma Jean, 2016
SyntheticSun은 Malware Information Sharing Platform(MISP) 및 Anomali의 LIMO를 사용하여 구축되었습니다. 이들은 다양한 유형의 손상 지표(IoC)를 제공하는 커뮤니티 기반 위협 인텔리전스 플랫폼(TIP)입니다. 정규화 및 중복 제거된 위협 인텔리전스는 거의 실시간으로 조회되어 다양한 네트워크 트래픽 유형에서 알려진 위협을 신속하게 식별합니다. 잠재적 위협 식별에 역동성을 추가하기 위해 IP Insights 모델이 배포되어 IP 주소와 엔티티(IAM 주체 ID, 사용자 에이전트 등) 간의 쌍에서 이상(및 그 안의 잠재적 위협)을 찾습니다. 기본 RCF 감지기는 Elasticsearch에서 사용되어 실시간 보안 텔레메트리가 Kibana로 스트리밍될 때 이상을 찾습니다. 보안 팀 내에서 ML 모델의 사용 및 미세 조정을 민주화하기 위해 IP Insights 모델을 훈련하는 유틸리티가 핵심 솔루션에 추가 기능으로 제공됩니다.
보안 텔레메트리의 오케스트레이션, 자동화 및 추출, 변환, 로드(ETL)를 Kibana로 수행하기 위해 AWS Lambda, Amazon DynamoDB, AWS CodeBuild와 같은 다양한 AWS 서버리스 기술이 사용됩니다. 이러한 서버리스 기술은 확장성, 사용 편의성, 무거운 MapReduce 또는 Glue ETL 기반 솔루션에 비해 상대적으로 저렴한 비용 때문에 사용됩니다. 솔루션의 대부분은 CloudFormation을 통해 배포되며, 다양한 단계에 걸쳐 Python 및 셸 도우미 스크립트가 제공되어 채택과 지속적 통합 파이프라인에서의 잠재적 배포를 촉진합니다.
솔루션의 "내부"를 최대한 가볍게 유지하기 위해 boto3, requests, json, ipaddress, socket 및 re와 같은 기본 Python 모듈이 다운스트림 서비스로의 대부분의 추출, 변환 및 로드(ETL)를 수행합니다. 모든 지리적 위치 정보는 ip-api.com에서 제공되므로 계정이나 유료 등급이 필요하지 않으며 응답 헤더에 속도 제한 정보를 포함하는 훌륭한 API를 가지고 있습니다. Elasticsearch 및 Kibana 종속성의 대부분은 코드(인덱스, 매핑, 시각화 등)로 제공되어 수동 구성의 부담을 줄입니다.
SyntheticSun은 솔루션의 크기와 필요한 종속성으로 인해 세 단계(Stage)로 나뉩니다. 모든 아키텍처 및 설치 지침(및 해당되는 경우 FAQ)은 각 단계 내에 있습니다. 추가 기능 모듈(부록이라고 함)도 제공되어 기능을 확장하며, 여기에는 자체 아키텍처 및 설치 지침이 포함되어 있습니다.
SyntheticSun은 GitHub에서 찾은 것이므로 개념 증명이며, 따라서 첫 번째 릴리스에서 모든 것을 완벽하게 강화하기 위해 추가 노력을 기울이지 않았습니다. 제가 필요한 변경을 아직 하지 않은 시점에 이 글을 읽고 있다면, 이 솔루션을 프로덕션 환경(또는 보안 요구 사항이 높은 모든 환경)에 배포하기 전에 다음 사항을 고려하십시오. 이러한 항목은 로드맵에 추가하고 적절히 업데이트하겠습니다.
SyntheticSun은 AWS Cloud에서 엣지 보안 사용 사례를 위해 사이버 위협 인텔리전스와 머신 러닝을 시작하는 쉬운 방법으로, 하나 이상의 상용 도구에 투자하거나 보안 팀을 위해 데이터 과학자를 고용할 필요가 없습니다(이상적으로는 후자를 해야 하지만). 초기 구성 후 이 솔루션은 완전히 자동화되어 기계 속도로 위협을 식별하고 대응할 수 있습니다. 마지막으로, 이 솔루션은 침해 대응 팀이 위협 대응에 사용할 기본 시각화(예: 허용된 인바운드 또는 아웃바운드 연결, 악성 IP 주소 또는 도메인에 대한 DNS 쿼리 등)를 제공합니다. 솔루션의 핵심은 매우 가벼운 자동화 및 데이터 엔지니어링 파이프라인에 의존하며, 이론적으로 다단계 정규화 및 강화 또는 예약된 빠른 배치 작업이 필요한 다른 목적으로 재사용할 수 있습니다.
첫째, Amazon GuardDuty 및/또는 AWS WAF를 사용하고 있다면 이 솔루션을 평가하는 것이 합리적이지만, 또한 요구 사항이기도 합니다. 이점을 얻을 수 있는 명확한 사용자는 전체 스택의 보안을 담당하지만 머신 러닝 알고리즘을 모델링, 훈련 및 배포하거나 사이버 위협 인텔리전스 피드를 의미 있게 운영할 자본이나 전문 지식이 부족한 제품 팀입니다. 앞서 언급한 사용자는 보안 엔지니어링, SecOps/SOC 분석가 및 엔지니어, 또는 DevSecOps 엔지니어일 가능성이 높지만, 이 목록이 완전한 것은 아니며 제품/애플리케이션에 국한될 필요는 없습니다. 중앙 팀도 이를 사용할 수 있습니다. 또 다른 용도는 중앙 팀에서 일하는 동일한 사용자(SecOps, 보안 엔지니어링)가 방화벽 및 침입 방지 시스템용 동적 차단 목록을 만들고자 할 때이며, CodeBuild 프로젝트를 재사용하여 거의 모든 위치(예: Palo Alto 방화벽, Squid 순방향 프록시 URL 필터 등)에 CSV 또는 플랫 파일을 드롭할 수 있습니다.
SyntheticSun은 현재 주요 로그 소스(특히 S3 Access Logs 및 CloudFront Access Logs)를 완전히 포괄하지 못합니다. 이는 많은 사람들이 서비스를 제공하는 방식(특히 S3 버킷의 SPA)에 필수적입니다. 이상 탐지는 IP Insights에 대한 집착과 데이터 과학 훈련의 완전한 부족(진심으로 pandas나 numpy도 사용할 줄 모릅니다)으로 인해 WAF, API Gateway Access Logs 또는 CloudTrail을 넘어 확장되지 않습니다. 로그에서 일치를 시도하는 것 외에 원시 위협 인텔리전스 Ioc에 대한 심층 분석은 없습니다.
조직을 위해 이 솔루션을 배포하는 가장 쉬운 방법은 중앙 집중식 보안 서비스 계정에 배포하는 것입니다. VPC Flow Logs 및 WAF Logs와 같은 하위 수준 텔레메트리의 경우, AWS Service Catalog를 통해 도우미 스크립트 또는 CloudFormation 템플릿을 제공하여 하위 환경에서의 활성화를 촉진해야 합니다. Elasticsearch Service의 샤드 소비 및 인덱스 순환과 중앙 위치에 게시하는 계정 간 Kinesis Data Firehose 전송 스트림이 있는 경우 권한을 평가해야 합니다. 이 솔루션은 개인 샌드박스 계정에서 구축했기 때문에 위의 고려 사항 중 어느 것도 솔루션에 포함하지 않았습니다. 이 점을 염두에 두고 PR 작업을 기꺼이 할 것이며, 미래에 직접 수행할 수도 있습니다.
2020년 7월 31일 현재 AWS Firewall Manager Policies는 WAF 로깅의 다중 계정 집계를 지원하므로 이를 훨씬 덜 고통스럽게 만드는 데 한 걸음 더 가까워졌습니다...
주의: 저는 데이터 과학자가 아니며 이 답변은 길어질 것입니다. 요약: 이상 탐지기이며, 그렇다고 생각합니다?
저는 데이터 과학자와 거리가 멀고 훈련을 받은 적이 없으므로 문서를 읽는 것이 더 좋습니다. 그럼에도 불구하고 제 비전문가적인 설명을 드리겠습니다: IP Insights는 IPv4 주소와 엔티티(예: 계정 번호, 사용자 이름, 사용자 에이전트) 간의 관계를 학습하는 비지도 머신 러닝 알고리즘입니다. 그런 다음 IP Insights는 엔티티가 해당 IPv4 주소를 사용할 가능성이 얼마나 되는지 판단하려고 시도합니다. IP Insights의 배후에는 이러한 엔티티와 IPv4 주소의 잠재 벡터 표현을 학습하는 신경망이 있습니다. 이러한 벡터화된 표현 간의 거리는 엔티티가 IPv4 주소와 연관되는 것(예: IPv4 주소에서 요청 보내기)이 얼마나 이상(또는 정상)한지를 나타냅니다.
신경망은 이름 그대로 거의 정확히 인간 두뇌와 유사하게 동작하도록 설계된 머신 러닝 시스템으로, 컴퓨터화된 뉴런과 시냅스를 갖추고 있습니다. 비지도 머신 러닝에서 알고리즘은 모든 IPv4 주소와 쌍을 이루는 엔티티 간의 연관성을 살펴봄으로써 "좋은"(즉, 참 음성) 것이 "나쁜"(즉, 참 양성) 것과 어떻게 보이는지를 파악할 수 있습니다. 이 연관성은 "거리"에 의해 어떤 벡터가 다른 벡터와 유사한지 식별하기 위해 평가됩니다. IP Insights의 경우, IPv4 주소를 검색한 다음 모든 엔티티를 클러스터로 해싱하는 사전 구축된 인코더가 제공됩니다. 그런 다음 벡터화를 사용하여 반복합니다. 벡터화는 값 목록(예: 수천만 개의 값을 포함하는 "For" 루프)을 반복하는 대신 행렬로 계산을 수행하는 방법입니다.
IP Insights 모델을 훈련할 때, 실제로는 거리가 먼(즉, 매우 이상한) IPv4 주소와 엔티티를 쌍으로 만들어 자체적으로 거짓 긍정을 생성하며, 이는 실제로 발생할 가능성이 낮습니다. 이제 모델은 참 양성, 거짓 양성 및 참 음성을 구분할 수 있습니다. 이는 "교차 엔트로피"(일명 "로그 손실", 더 나아진 것은 아니지만)라는 또 다른 미친 용어를 방지하기 위해 수행되며, 이진 분류라는 또 다른 용어를 도입합니다. IP Insights는 본질적으로 "이 IP 주소와 이 엔티티가 쌍을 이룰 때 이상할 확률은 얼마인가?"라고 묻습니다. 이것이 이진 분류를 만드는 이유라고 생각합니다. 따라서 "예, 나쁩니다" 또는 "아니요, 그렇지 않습니다". 확률은 0과 1 사이의 값으로 표현되며, 모든 머신 러닝 모델의 목표는 이를 가능한 한 0에 가깝게 만드는 것입니다. 따라서 실제로 1인(알려진 참 양성) 것을 0.01로 예측하면 매우 높은 로그 손실이 발생합니다. 따라서 모든 것을 말씀드리자면, 의도적으로 쓰레기 데이터를 만들어 IP Insights가 훈련 중에 로그 손실(즉, 잘못된 예측)을 줄이는 데 도움을 줍니다.
그것이 엔드포인트의 출력으로 이어집니다. 이를 쿼리할 때(배치로 또는 InvokeEndpoint API를 사용하여 거의 실시간으로) 응답은 음수 또는 양수가 될 수 있는 무제한 부동 소수점입니다. 0보다 높을수록 이상할 가능성이 높으며, 이는 여러분의 작업이 시작되는 지점입니다. 이 솔루션에서는 0.03 이상을 선택했는데, 이는 대체로 개념적인 것입니다. 진실에 더 가까워지기 위해 엔드포인트에 참 양성을 제공하고 응답이 무엇인지 확인해야 합니다. 이러한 결과를 바탕으로 점수에 따라 애플리케이션이 2차 인증 문제를 발행하거나, 경고를 발생시키거나, 완전히 차단하는 계층적 접근 방식을 구성할 수 있습니다. 두 번째 질문에 대한 답변은 "예, 그렇다고 생각합니다"입니다. 사용자 에이전트를 IP와 쌍으로 훈련하는 것은 실제로 꽤 불안정합니다. 계정 번호, 사용자 이름, IAM 사용자와 같은 덜 변동적인 엔티티의 경우 의도된 사용 방식처럼 느껴집니다.
솔루션에서 사용해야 할 몇 가지 예제 피드를 제공합니다. 일부는 사이버 범죄 도메인 피드, Emerging Threats 및 CI-badguys와 같이 상당히 명백합니다. 실제 업무에서 저는 세계에서 가장 재능 있는 사이버 위협 인텔리전스 전문가 중 한 명(농담이 아니고 그녀는 대단합니다!)과 함께 일하며, 그녀도 선택에 영향을 미쳤습니다. 머신 러닝 모델 및 구축할 다른 모든 것과 마찬가지로 현재 위협 환경에 맞게 위협 인텔리전스 피드와 집계를 조정해야 합니다. 중복은 MISP에서 식별되며, DynamoDB 테이블에서 고유성을 강제하기 위해 해시 키만 지정되므로 동일한 IPv4 주소를 보고하는 5개의 피드가 있더라도 하나만 테이블에 저장됩니다.
InfoBlox 또는 Recorded Future와 같은 자체 상용 위협 인텔리전스 플랫폼 및 피드를 이 솔루션에 가져올 수도 있으며, 유사한 구문을 사용하여 DynamoDB 테이블을 가리키면 됩니다.
대부분의 AWS 로그 전달은 "최선의 노력"이므로 공식 SLA는 게시되지 않았습니다. 그러나 약 99.5 - 99.9%로 가정하며, 마지막 0.5 - 0.1%는 전달되지 않을 것입니다. "프로덕션" 트래픽은 AWS에서 일등석입니다. 네트워크 대역폭 제약이 있는 경우 로그를 보내는 것보다 클라이언트에 대한 연결을 복구하는 것이 기본값입니다. 더 가능성이 높은 이벤트는 원시 로그 파일이 Lambda가 전체를 처리하기에는 너무 큰 경우입니다. 이는 동일한 클라이언트 IP에서 DOS 또는 크롤러에 의해 공격을 받을 때 자주 발생합니다. WAF 및 ALB는 (제가 알기로) 호출자별로 로그 파일을 묶습니다. 따라서 수백 개의 요청을 흡수하면 로그 파일이 매우 커질 수 있습니다.
예, 그러나 다음 중 하나를 수행해야 합니다:
이에 따른 추가 비용이 있습니다. VPC의 Lambda, 특히 수십 개의 동시 호출의 경우 ENI가 남아 RFC1918 공간을 잠식하는 문제가 발생할 가능성이 높습니다. 규정 준수 요구 사항을 충족하기 위해 모든 트래픽을 VPC 내에서 격리해야 하는 절대적인 필요가 없다면 그 길을 선택하지 않을 것입니다.
예, 솔루션을 수정하여 최종 형식의 로그를 Kinesis Data Firehose에 게시하고 Splunk를 가리키도록 하면 됩니다.
향후 Route 53 DNS Logs, S3 Access Logs, CloudFront Access Logs 및 API Gateway Access Logs와 일부 호스트 기반 로그를 지원할 계획입니다.
솔직히 Kinesis Data Agent를 사용하고 싶었지만, 많은 문제를 발견했습니다: Amazon Linux 2에 기본 포함되어 있지 않으며, Ubuntu 18.04 LTS AMI에 Java 11이 사전 설치되어 있어 OpenJDK 8 또는 9가 없으면 빌드가 실패하기 때문에 에이전트와의 역호환성 문제가 발생했습니다. CloudWatch Agent는 새로운 기능으로 자주 업데이트되고 구성용 Systems Manager 문서 지원이 있으며 설치 마법사도 있기 때문에 설치하기가 훨씬 쉬웠습니다. AWS가 Kinesis Data Agent를 CloudWatch Agent만큼 진지하게 지원한다면, 특정 호스트 기반 로그(Suricata, Squid, Nginx, Apache)의 경우 CloudWatch Logs를 중개자로 사용하는 것보다 Kinesis Data Firehose에 직접 게시하는 것을 선호하기 때문에 전환할 수도 있습니다.
Issues 또는 Project Board에서 "Help Wanted"로 태그된 항목에 대한 PR을 기꺼이 수락합니다. 프로젝트의 정신에 부합한다면 다른 제안된 PR도 검토하겠습니다.
SyntheticSun을 미세 조정하는 데 귀중한 피드백, 테스트 및 기여를 제공한 David Dorsey와 Ryan Nolette에게 특별히 감사드립니다.
이 라이브러리는 GNU General Public License v3.0(GPL-3.0) 라이선스에 따라 라이선스가 부여됩니다. LICENSE 파일을 참조하십시오.
