1. 개요
- 세계 여러 정보 보안 관련 기관이 협력하여 LotL 공격 대비 가이드라인 발표 [1]
- 장시간 공격을 유지할 수 있게 해 주는 LotL 공격이 공격자들 사이에서 인기
- ‘이벤트 로그 관리’를 방어책으로 내세움
2. 주요내용
2.1 LotL (Living off the Land)
- 이미 사용자 시스템에 설치된 여러 자원을 공격에 활용하는 방법
- 정상적으로 발생하는 트래픽과 공격으로 발생한 트래픽의 구분이 힘들며, 공격 지속성을 크게 높일 수 있는 장점
2.2 이벤트 로깅 (Event logging)
- 이벤트 로깅은 네트워크 가시성을 지원해 운영과 시스템의 보안 및 복원력을 개선
구분 | 개요 |
효과적인 이벤트 로깅 솔루션 | ① 중요한 소프트웨어 구성 변경 또는 설치시 담당자에게 경고 잔송 ② LotL 공격 또는 침해 후 횡적 이동 등의 보안 사고를 나타낼 수 있는 보안 이벤트 식별 ③ 침해의 범위와 정도를 밝혀 사고 대응 지원 ④ 정책이 잘 적용되도록 하며, 위반 여부 모니터링 ⑤ 오탐과 노이즈를 줄여 저장 공간과 요청 시간 관련 비용을 절감 ⑥ 보안 담당자들이 정보를 바탕으로 결정을 내릴 수 있게 지원 ⑦ 보안 분석가들에게 유용한 로그와 플랫폼을 제공 |
핵심 고려 요소 | ① 기업에서 승인된 이벤트 로그 정책 ② 중앙 집중식 이벤트 로그 접근 및 상관 분석 ③ 저장된 데이터의 보안 및 이벤트 로그 무결성 ④ 관련 위협에 대한 탐지 전략 |
로그 정책 | ① 어떤 이벤트를 로깅할 것인지 정의 ② 어떤 시스템에 이벤트 로깅을 적용할 것인지 정의 ③ 이벤트 로그를 모니터링하는 방법 정의 ④ 이벤트 로그를 얼마나 보관할 것인지 정의 ⑤ 로그 수집 관련 정책의 재평가 시기 정의 |
2.3 로그의 품질
- 사고 대응 및 위협 탐지의 맥락에서 이벤트 로그의 품질은 얼마나 잘 포맷 되었는지가 아닌, 수집된 이벤트 유형에 의해 결정
- 유용한 이벤트 로그는 보안 이벤트를 평가하여 정오탐을 식별하는 능력을 강화
> OT 장치를 포함하는 경우 해당 장치에 대한 고려가 필요
> OT 장치는 메모리와 프로세스에 부하를 주는 임베디드 소프트웨어를 사용하며, 과도한 로깅은 장치의 운영에 악영향을 미칠 수 있음
> OT 장치는 자세한 로그를 생성할 수 없으므로 센서를 사용하여 로그 기능을 보완할 수 있음
> 대역 외 로그 통신 또는 오류 코드와 기존 통신의 페이로드를 기반으로 로그를 기록
- LotL을 사용하는 공격자들은 주로 다음과 같은 로그를 수집해 파악할 수 있음
구분 | 설명 |
Linux 기반 | - curl, systemctl, systemd, python 등을 사용했을 때 기록되는 로그 - 기타 일반적인 LOLBin의 사용와 관련된 로그 |
Windows 기반 | - wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe 등을 사용했을 때 기록되는 로그 - 명령 실행, 스크립트 차단, PowerSehll용 모듈 로그, 관리 작업에 대한 로그 |
Cloud 환경 | - API 호출 및 최종 사용자 로그인을 포함한 모든 컨트롤 플레인 작업을 기록 - 컨트롤 플레인 로그는 읽기 및 쓰기 활동, 관리 변경 사항 및 인증 이벤트를 기록하도록 구성 |
- 이벤트 로그는 대응을 돕기에 충분한 세부 정보가 포함되어 있는 것이 좋음
미국 관리예산국 M-21-312의 로그에 포함되어야 하는 내용 |
① 올바르게 포맷되고 정확한 타임스탬프 (밀리초 단위가 이상적) ② 이벤트 유형 ③ 장치 식별자의 MAC 주소 또는 기타 고유 식별자 ④ 세션/트랜잭션 ID ⑤ 자율 시스템 번호 ⑥ 출처 및 도착지 IP (IPv4 및 IPv6 포함) ⑦ 상태 코드 ⑧ 응답 시간 ⑨ 추가 헤더 (Ex. HTTP 헤더) ⑩ 사용자 ID (해당되는 경우) ⑪ 실행된 명령 (해당되는 경우) ⑫ 이벤트 상관 관계를 돕기 위한 고유 이벤트 식별자 (가능한 경우) ※ 모든 데이터는 추출을 더 쉽게 하기 위해 "키-값 쌍" 형식으로 포맷 (가능한 경우) |
- 로그의 품질을 높이는 요소들
구분 | 설명 |
콘텐츠 및 형식 일관성 | - 로그를 중앙 집중화할 때 JSON과 같은 구조화된 로그 형식을 사용 - 형식, 순서, 스키마를 일관되게 유지 - 로그가 생성될 때부터 일관된 형식을 유지하는 것이 좋음 - 그러나, 모든 로그가 정해진 형식을 따를 수 있는 것은 아니므로 자동화된 로그 정규화 방법론을 마련할 필요 |
타임스탬프 일관성 | - 모든 시스템에서 동일한 날짜-시간 형식과 표기법을 사용 - ISO 8601 형식은 연도-월-일-시-분-초-밀리초 순서 권고 |
로그 보존 | - 시스템에 대한 위험 평가 결과에 따라 로그 보관 기간 결정하며, 침입과 영향을 평가하는 로그는 좀 더 오래 보존 - 조직에 적용되는 모든 규제에 어긋나지 않도록 보존 - 조직이 보유하고 있는 저장 공간도 고려 - 공격자들이 로그를 삭제할 수 있으므로, 로그에 대한 접근 또한 강화 ※ 어떤 경우 사고를 발견하는 데 최대 18개월이 걸리고, 어떤 악성코드의 경우 70~200일 동안 네트워크에 거주하는 것을 고려 |
2.4 로깅 우선순위
- 조직 내에서 로그 소스를 우선순위를 둘 것과 우선순위가 낮은 로그도 모니터링할 것을 권장
구분 | 설명 |
로깅 우선순위 | - LotL 맥락에서 기업의 망은 공격자들이 사용하기 좋은 도구들이 많음 > 해당 도구들과 관련하여 로그의 우선순위를 정하는 것이 효과적 ① 공격 대상이 될 가능성이 높은 중요 시스템과 데이터 ② 원격 접근, 네트워크 메타데이터, 기본 서버 OS, 인터넷 연결 서비스 ③ ID 및 도메인 관리 서버 ④ 기타 중요 서버 ⑤ 네트워크 외곽에 있는 라우터와 방화벽 등 ⑥ 관리자의 관리 작업을 위한 워크스테이션 ⑦ 환경 설정, 시스템 모니터링, CI/CD, 취약점 스캔, 비밀 관리, 권한 관리에 사용되는 시스템 ⑧ 데이터 저장소 ⑨ 보안 소프트웨어 ⑩ 사용자 컴퓨터 ⑪ 사용자 애플리케이션 ⑫ 웹 프록시 ⑬ DNS 서비스 ⑭ 이메일 서버 ⑮ DHCP 서버 ⑯ 오래된 레거시 IT 자산 ⑰ 하이퍼바이저 호스트 ⑱ 프린터 등 부수적인 IT 장치 ⑲ 애플리케이션 게이트웨이 등 네트워크 구성 요소 |
OT 환경 로깅 우선순위 |
- 최근 OT 네트워크에 대한 공격이 증가 ① 안전 및 서비스 제공에 중요한 OT 장치 (Air-Gap 시스템 제외) ② 공공 인터넷과 연결된 OT 장치 ③ 네트워크 외곽선을 통과했을 때 접근이 가능해지는 OT 장치 ④ 로깅 기능이 없는 OT 장치 (OT 장치의 네트워크 트래픽 모니터링 필요) |
엔드포인트 로깅 우선순위 |
- 팬데믹 등으로 재택 근무의 증가 ① 사용자가 사용하는 웹 프록시 ② 회사/기관에서 운영 혹은 사용하는 DNS 서비스 ③ 조직에 공식 등록된 장치들의 보안 상황 ④ 조직에 공식 등록된 장치들의 행동 패턴 ⑤ 사용자 계정에서 발생하는 활동 ⑥ VPN 솔루션 ⑦ MDM 및 모바일 애플리케이션 관리(MAM) |
클라우드 컴퓨팅 로깅 우선순위 |
- IaaS, PaaS, SaaS 등 플랫폼과 유형에 따라 이벤트 로깅 방식을 조정 > Ex. IaaS : 테넌트에 로깅 책임을 부여 / SaaS : 서비스 제공 업체에 로깅 책임 부여 > 기업(사용자)과 제공자(CSP) 간 긴밀한 협조 필요 ① 표적이 될 가능성이 높은 중요 시스템과 데이터 ② 공공 인터넷에 직접 연결된 서비스 ③ 클라우드 서비스에 직접 접근하고 관리하는 테넌트의 계정 ④ 환경 설정 ⑤ 모든 보안 관련 계정 (생성, 삭제, 수정 등) ⑥ 서드파티 인증 서비스를 활용할 때(성공/실패 로그) ⑦ 클라우드 서비스에서 생성된 로그, 클라우드 API 로그, 네트워크 이벤트 등 |
2.5 이벤트 로그의 안전한 저장 및 무결성
- 중앙 집중식 이벤트 로깅 시스템을 구축한 후 SIEM, XDR과 같은 분석 도구로 로그를 전달할 것을 권장
> 충분한 저장 용량을 갖출 것 (침해가 발생하였으나, 과거 이벤트 로그가 없으면 사고 대응에 부정적 영향을 미침)
> 별도의 네트워크 또는 세분화된 네트워크에 보관하며, 로그 변조의 위험을 줄이기 위한 추가 보안 제어 기능이 필요
- 이벤트 로그의 안전한 전송 및 무결성을 보장하기 위해 TLS 1.3 및 암호화 검증 등의 보안 메커니즘 구현 권장
> 공격자들은 로그를 수정하거나 삭제하며, 로그에서 유용하면서 민감한 데이터를 확인할 수도 있음
> 적정한 요건을 갖춘 사용자만이 이벤트 로그에 접근할 수 있는 권한을 부여
2.6 LotL 탐지
- 아주 조금의 이상 행동이라도 탐지 및 기록해야 함
구분 | 설명 |
이상 (비정상적) 행동 | ① 비정상적인 시간대에 발생한 사용자 로그인 (근무 외 시간, 공휴일 등) ② 사용자가 일반적으로 접근하지 않는 서비스에 접근 혹은 접근 시도 ③ 비정상적인 장치를 활용한 로그인 및 로그인 시도 ④ 비정상적으로 빈번한 로그인 시도 ⑤ 물리적으로 불가능한 로그인 시도 (불가능한 이동(Impossible Travel) 등) ⑥ 대량의 데이터 다운로드 및 외부 유출 ⑦ 정상 인증 단계를 거치지 않은 로그인 ⑧ 다양한 사용자 ID로 접근하는 단일 IP 주소 ⑨ 사용자 계정 생성 / 비활성화 된 계정의 재활성화(특히 관리자 계정) ⑩ 일반적으로 통신 트래픽이 없는 장치에서 트래픽이 발생 ⑪ 비정상적인 스크립트 실행 ⑫ 갑작스러운 로그 삭제 ⑬ 비정상적인 프로세스 생성 및 실행 ⑭ 보안 소프트웨어 및 로깅 소프트웨어의 환경 설정 변경 |
추가 분석 | ① 프로세스 생성 이벤트 / 명령줄 감사 등 상세 로깅 활성화 상태로 유지 > 로그 가시성 향상 가능 ② 조직 내에서 사용할 수 있는 정상 바이너리의 기준 생성 > 비정상 바이너리가 자연스럽게 결정 ③ 진화하는 위협에 따라 다양한 운영 체제에 대한 탐지 규칙 생성 Windows : powershell.exe, cmd.exe, regedit.exe 등에 대한 상세 탐지 규칙 Linux : curl, systemctl, python 등에 유의 |
OT 환경 | ① 비정상적인 혹은 예상하기 힘든 도구의 활용 ② 벤더나 서드파티의 갑작스러운 접근 ③ 유지보수나 원격 모니터링을 위한 도구의 비정상적인 사용 ④ 운영 체제, 소프트웨어, 펌웨어, 환경, 데이터베이스 등의 무단 변경 및 무단 업데이트 ⑤ 제어 시스템과 외부 네트워크 간의 비정상적인 통신 ⑥ 평소에 통신 활동이 없던 구성 요소 간에 발생하는 통신 ⑦ 비정상적인 스크립트 실행 |
3. 참고
[1] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3880942/nsa-joins-allies-in-releasing-best-practices-for-event-logging/
[2] https://www.boannews.com/media/view.asp?idx=132371&page=1&kind=1
'취약점 > 기타' 카테고리의 다른 글
NVIDIA Container Toolkit TOCTOU 취약점 (CVE-2024-0132, CVE-2024-0133) (5) | 2024.10.11 |
---|---|
Kia 차량 해킹 (3) | 2024.10.03 |
Air-Gap RAMBO(Radiation of Air-gapped Memory Bus for Offense) Attack (0) | 2024.09.11 |
Windows Downdate (CVE-2024-38202, CVE-2024-21302) (0) | 2024.08.13 |
SmartScreen 및 Windows Smart App Control 설계상 취약점 (0) | 2024.08.10 |