2024년도 KUCIS 프로젝트 - 클라우드 SIEM 솔루션

학과 동아리에서 2024 대학정보보호동아리(KUCIS)에 선정되었고, 클라우드 보안 솔루션으로 프로젝트를 준비하고 있다.

​

특히나 고객층으로 생각하는 타겟은 학부생 혹은 소규모 스타트업 서비스 기업들

 

현실적인 이유로 보안 측면을 고려하기 어려운 사람들에게 쉽게 적용할 수 있는 클라우드 상의 보안 솔루션이 있다면 충분히 수요가 있다고 판단했다.

​

SIEM(Security Information and Event Management)이란?

SIEM(Security Information and Event Management)은 소프트웨어 전체 범위에서 로그를 수집, 저장 및 분석한다. 종합적인 보안 보고 및 규제 준수 관리와 함께 신속한 공격 탐지, 차단 및 대응을 위해서 보안 위협을 실시간으로 모니터링하는 소프트웨어를 말한다.

 

우리는 ​KISA의 정보 보호 및 개인정보보호 관리 체계 인증(ISMS-P)의 2.11 사고 대응 및 복구 항목의 인증 기준을 준수하는 클라우드 SIEM 프로젝트를 목표로 하고 있다.

 

KISA 정보보호 및 개인정보보호관리체계 인증 ISMS-P 제도소개

 

수집할 데이터 종류에 따른 데이터 가공 (ELK의 Logstash에 해당)

모니터링을 통한 시각화 도구(Kibana 등)는 사용하지 않음

→ 수집한 DNS 데이터를 시각화하는 목적의 서비스가 아님. 따라서 대시보드 직접 설계

​

방법론 - 어떻게 하면 오판(False Negative, Positive)을 줄일 수 있을까?

 

🔥 로그 역추적을 용이하게 하기 위한 아키텍처

이벤트 로그에 대해서 의심 단계를 3단계로 나눈다.

1. 경고(Alert) : 초기 단계. 실제 위협인지 확실하지 않은 상태
   • ex) 비정상적인 로그인 시도, 평소보다 많은 데이터 전송, 권한 상승, 정책 부여 등
2. 의심(Suspicion) : 실제 위협일 가능성이 높은 활동으로 판명된 단계
   • ex) 비정상적인 접근 시도가 여러 번 반복되는 경우, 권한 제한이 여러 번 반복되는 경우 등
3. 확신(Confirmation) : 대응과 침해보고서 작성이 필요한 명확한 단계

피해 규모 산정과 로그 역추적이 필요

• 예시 : 데이터 유출이 발생한 경우? 피해 규모가 명확한 경우

​

🔥 예상 시나리오 : 권한 상승으로 중요한 데이터에 접근하려는 시도

1. 권한 부족으로 접근 시도 차단
   • 지속적인 차단시 의심
2. 권한 상승이 발생
   • 1번 발생 이후 권한 상승시 의심
   • 지속적인 권한 상승, 혹은 2개 이상의 정책 부여시 의심
3. S3 버킷 등 중요 데이터에 접근
   • 1,2번 상황 이후면 확신
   • 1번 혹은 2번 상황 이후면 의심

​

🔥 피해 규모 상정

로그를 역추적하지 않고, 시간 순서로 로그를 단계별 상승시켜서 수집하기에 로직 구현이 생각보다 어렵지 않아졌다.

어떤 권한을 얻어서, 어디에 접근했고, 어떤 활동을 했는지 탐색하여 피해 규모를 예측할 수 있다.

피해 규모는 당연히 최악의 상황을 상정해서 산정해야한다고 생각했다.

​

ex) 사용자의 개인 정보를 기록하는 특정 S3 버킷에 접근한 경우, 해당 버킷에 들어간 사용자 정보는 모두 유출된거니 사이즈만큼 피해 규모를 상정

​

🔥 예상되는 대응책

확신되는 경우, 리소스에 대한 쓰기나 삭제 작업 차단

False Negative 상황에 치명적일 수 있어서 아직 정해진게 없다. 

우선 정한건, 오판 가능성을 염두하여 읽기는 차단하지 않아야함

​

aws 환경에서 협업도 처음이라 제대로 해보고 싶어서 억지로 IAM 권한 최소한으로 부여하도록 고집부렸다.

근데 멍청해서 매번 작업하다가 '어.. 권한이 없어요...주세용...' 하는 일이 너무 잦다.

처음 시작때 작업할 Role에 필요한 권한을 잘 적어놔야하는데 그게 잘 안된다.