공격에 필요한 도구를 따로 만들지 않아도 된다. 이미 사용자 시스템에 설치된 것들만 잘 이용해도 충분히 공격이 가능하기 때문이다. 그래서 사용자가 가지고 있는 자원을 공격에 활용하는 LOTL 전술이 최근 해커들 사이에서 각광 받고 있다. 이에 정부 기관들까지 나섰다.
[보안뉴스 문가용 기자] 요 몇 년 사이버 공격자들은 ‘리빙 오프더 랜드(Living off the Land, LOTL)’라는 공격 기법을 꾸준히 사용해 왔다. 피해자의 컴퓨터나 네트워크에 이미 설치되어 있는 여러 가지 자원들을 공격에 활용하는 수법으로, 정상적으로 발생하는 트래픽과 공격자들이 발생시키는 그것을 구분하기 힘들며, 따라서 공격 지속성을 크게 높일 수 있다는 장점을 가지고 있다. 최근 정보 탈취가 공격자들의 중요한 목표가 되고 있는 가운데, 장시간 공격을 이어갈 수 있게 해 주는 LOTL은 점점 더 커다란 위협이 되어가고 있다.
[이미지 = gettyimagesbank]
그래서 이번 주 세계 여러 정보 보안 관련 기관들이 협력하여 LOTL 공격에 대비하는 데 도움이 될 만한 가이드라인을 작성해 발표했다. 여기에 참여한 국가와 기관들은 다음과 같다.
1) 호주 : 호주신호국(ASD)
2) 미국 : 사이버보안 및 인프라 보안국(CISA), 연방수사국(FBI), 국가안보국(NSA)
3) 영국 : 국가사이버보안센터(NCSC-UK)
4) 캐나다 : 사이버보안센터(CCCS)
5) 뉴질랜드 : 국가사이버보안센터(NCSC-NZ), 컴퓨터긴급대응팀(CERT-NZ)
6) 대한민국 : 국가정보원(NIS), 국가사이버보안센터(NCSC-Korea)
7) 일본 : 국가사이버안전센터(NISC), 컴퓨터긴급대응협력센터(JPCERT/CC)
8) 싱가포르 : 사이버보안국(CSA)
9) 네덜란드 : 일반정보보안국(AIVD), 군사정보보안국(MIVD)
들어가기에 앞서
이 기관들은 LOTL 공격에 대한 방어책으로 ‘이벤트 로그 관리’와 ‘네트워크 가시성 확보’를 내세웠다. 이번에 발표된 지침은 이 두 가지를 기반으로 하되 자원에 제한이 있다는 것을 고려하고, 피해 조직의 사이버 복원력을 향상시키는 것을 궁극적 목표로 설정했다는 특징을 가지고 있다. 되도록 많은 조직들이 적용하기 편하게 기술적인 난이도를 크게 높이지 않았다는 것도 중요하다.
이 가이드라인에 의하면 효과적인 이벤트 로그 솔루션들은 다음과 같은 목적을 달성하는 데 도움을 준다고 한다.
1) 중요한 소프트웨어 구성 변경이나 새로운 소프트웨어 솔루션이 설치될 때 네트워크 담당자(보안 담당자)에게 경고를 보낸다.
2) 침해의 범위와 심각성을 밝힘으로써 보다 정교하게 대응할 수 있게 한다.
3) 정책이 잘 적용되도록 하며, 위반 여부를 모니터링할 수 있게 해 준다.
4) 오탐과 노이즈를 줄여 저장 공간과 요청 시간 관련 비용을 절감한다.
5) 보안 담당자들이 정보를 바탕으로 결정을 내릴 수 있게 해 준다.
6) 보안 분석가들에게 유용한 로그와 플랫폼을 제공한다.
또한 로그 관리와 관련하여 모범 사례를 설정하고 준수할 때 고려해야 할 네 가지 핵심 요소를 다음과 같이 꼽기도 했다.
1) 기업에서 승인된 이벤트 로그 정책
2) 중앙 집중식 이벤트 로그 접근 및 상관 분석
3) 저장된 데이터의 보안 및 이벤트 로그 무결성
4) 관련 위협에 대한 탐지 전략
“로그와 관련된 정책을 조직 차원에서 개발하고 구현할 필요가 있습니다. 로그를 일관적으로 개발하고 관리할 때, 악성 행위를 탐지할 가능성이 높아집니다. 좋은 로그 정책에는 다음과 같은 내용들이 포함되어야 합니다.”
1) 어떤 이벤트를 로깅할 것인가를 정의
2) 이벤트 로깅을 어떤 시스템으로 할 것인가를 규정
3) 어떤 방법을 동원해 로그를 모니터링 할 것인가를 설정
4) 이벤트 로그를 어느 정도 기간 동안 보존할 것인가를 결정
5) 로그 수집 관련 정책을 어떤 시점에 재평가 할 것인가를 정의
[이미지 = gettyimagesbank]
가장 중요한 건 로그의 품질
이벤트 로그를 관리할 때 고려해야 할 또 다른 중요한 요소는 로그의 품질이다. “로그가 아무리 풍부히 많아도 그 내용이 부정확하면 분석 결과에 오류가 있을 수밖에 없습니다. 따라서 이벤트 로그 품질을 중점으로 한 정책이 필요합니다. 보통 많은 기업과 기관들이 ‘로그를 하고 있다’는 것 자체에 의의를 두지, 이것을 평상시에 관리하려는 생각을 하지 못합니다. 그럴 때 로그 품질이 떨어지는데요, 유의해야 할 부분입니다. 로그 품질은 네트워크 환경, 지켜야 할 자산의 종류, 조직의 보안성 등에 따라 달라질 수 있습니다.” 가이드라인에 나온 내용이다.
품질 좋은 이벤트 로그는 무엇일까? 가이드라인에 따르면 “보안 담당자와 분석가가 오탐에 쏟는 시간을 줄일 수 있는 로그가 가장 좋은 로그”라고 간단히 정의한다. “로그만보고 가짜인지 진짜인지를 100% 파악할 수는 없습니다. 하지만 전반적으로 분석 시간이 줄어들고 오탐 확률이 낮아진다면 그 로그는 품질이 좋다고 할 수 있습니다. 이렇게 로그 품질을 높이면 진짜처럼 보이는 게 본질인 LOTL 공격에도 효과적으로 대응할 수 있습니다.”
LOTL 기법을 사용하는 공격자들은 주로 다음과 같은 로그를 수집해 파악할 수 있다고 가이드라인은 설명한다.
1) 리눅스 기반 시스템의 경우 : curl, systemctl, systemd, python 등이 활용됐을 때 포착되는 로그
2) 윈도 기반 시스템의 경우 : wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe 등의 활용됐을 때 포착되는 로그. PowerShell 명령 실행, 스크립트 차단, 모듈 실행 등과 관련된 로그도 유용.
3) 클라우드 환경의 경우 : API 호출, 최종 사용자 로그인 등 모든 제어 관련 로그. 읽기와 쓰기 활동, 환경 설정 변경, 각종 로그인 및 인증 이벤트가 포착되도록 구성하는 게 알맞음.
이벤트 로그는 세부 정보를 풍부히 갖추고 있으면 있을수록 좋다. 그렇지 않을 경우 목적에 맞게 활용하는 게 어려워진다. 특히 보안과 관련된 세부 사항은 반드시 포함해야 하는데, 그것은 애초에 로그를 관리하는 게 대부분 보안 강화를 목적으로 하기 때문이다. 가이드라인에 따르면 다음 세부 내용들은 반드시 포함되어야 한다고 한다. 이 정도는 갖추고 있어야 품질 좋은 로그라고 할 수 있다는 것이다.
1) 올바르게 포맷되고 정확한 타임스탬프(밀리초 단위가 이상적)
2) 이벤트 유형
3) 장치 식별자의 맥주소 또는 기타 고유 식별자
4) 세션/트랜잭션 ID
5) 자율 시스템 번호
6) 출처 및 도착지 IP(IPv4 및 IPv6 포함)
7) 상태 코드
8) 응답 시간
9) 추가 헤더(예: HTTP 헤더)
10) 사용자 ID(해당되는 경우)
11) 실행된 명령(해당되는 경우)
12) 이벤트 상관 관계를 돕기 위한 고유 이벤트 식별자(가능한 경우)
하지만 로그 품질을 이상적으로만 높일 수는 없다고 가이드라인은 지적한다. “OT 요소를 포함하고 있는 네트워크의 관리자라면 이 OT 장치들을 고려해야 합니다. 대부분의 OT 장치는 메모리 또는 프로세서에 부하를 주는 임베디드 소프트웨어를 사용합니다. 과도한 로그는 OT 장치의 운영에 악영향을 미칠 수 있다는 뜻이지요. 또한, 이러한 OT 장치는 상세한 로그를 생성할 수 없는 경우가 많으므로, 센서를 사용하여 로그 기능을 보완할 수 있습니다. 임베디드 장치의 제한된 로깅 기능을 보완하기 위해 기존 통신의 오류 코드 및 페이로드를 기반으로 로그를 생성하거나, 대역 외 로그 통신을 사용할 수 있습니다.”
[이미지 = gettyimagesbank]
로그 품질을 높이는 요소들
로그의 품질을 높이는 요소들을 위에서 언급했는데, 이를 좀 더 세부적으로 설명하면 다음과 같다.
1) 이벤트 로그는 중앙에서 관리해야 한다. 중앙에서는 로그의 형식과 순서, 스키마를 일관되게 유지하는 작업을 해야 한다. 로그를 표시하는 방법에 있어서도 구성이 갖춰져 있는 게 좋다. 아무렇게나 된 로그를 중앙에서 받아 통일시키는 작업을 하는 것보다, 로그가 엔드포인트에서 생성되고 전달될 때부터 중앙에서 정한 형식이 적용되도록 하는 게 효과적이다. 그러나 모든 로그가 정해진 형식을 따를 수 있는 건 아니므로 구조를 자동으로 갖춰주는 방법론을 마련하는 것도 필요하다.
2) 로그에 찍히는 타임스탬프가 오류 없이 생성되도록 관리해야 한다. 이벤트가 발생한 ‘순서’가 로그 분석 시에 대단히 중요하게 작용하는데, 타임스탬프가 뒤죽박죽이 되어버리면 아무리 품질 좋은 로그가 생성된다 하더라도 소용이 없다. 그러려면 엔드포인트부터 네트워크에 연결된 모든 장비들이 같은 날짜와 시간으로 설정되어 있어야 하고, 심지어 날짜와 시간을 표기하는 방법도 같아야 한다. 네트워크가 분산된 상황에서는 이 시간 관련 설정을 통일하지 않게 되는데, 이 때문에 로그 품질이 저하된다. UTC 시간을 권장한다. ISO 8601 표준에 의하면 연도-월-일-시간-분-초 순서로 시간을 표기하는 게 알맞다.
3) 모든 환경에서 시간 서버가 동기화 되고, 장치 부팅 및 재부팅과 같은 중요하지만 사소한 이벤트들이 빠짐없이 포착되어야 한다.
로그의 보존
품질 좋은 로그라 하더라도 정작 필요할 때 쓸 수 없으면 말짱 도루묵이다. 따라서 로그가 보존되는 기간이 충분해야 한다. 여러 로그 시스템에 미리 설정되어 있는 기본 로그 시간은 거의 대부분 불충분하다고 가이드라인은 지적한다. 그렇다면 어느 정도가 적당할까? “로그 보존 기간은 조직의 위협 평가를 기준으로 해야 합니다. 어떤 보안 사건은 발견되는 데에만 18개월이 걸리기도 합니다. 심지어 어떤 악성 코드들은 아예 70일에서 200일 동안 슬립 모드로 있기도 하지요. 이런 것들을 전부 고려해야 합니다.”
이걸 조직이 단독으로 정하지 못할 때도 있다. “어떤 국가나 지역, 혹은 산업에서는 로그 보존 기간이 정책적으로 정해져 있기도 합니다. 규제 사항으로 못 박혀 있을 때도 있지요. 그런 기본적인 요소들까지 전부 고려하고, 규정에서 어긋나지 않도록 해야 합니다.” 어떤 로그냐에 따라 보존 기간을 달리하는 것도 중요하다. “불법 침투와 관련된 로그, 그 침투 요소가 활동한 내용에 대한 로그 같은 경우 좀 더 오래 보존하는 게 좋습니다.”
오랜 기간 로그를 보존하려면 저장 공간이 충분해야 한다. 즉 기한 설정을 할 때 조직이 보유하고 있는 저장 공간도 중요한 고려 사항이 된다는 뜻이다. “로그를 잘 하지 못하는 가장 큰 이유 중 하나가 저장 공간의 부족입니다. 이걸 처음부터 고려하지 않고 로깅을 시작한다거나, 로깅을 한참 하고 저장 공간이 부족해질 때 문제를 해결하지 않는다거나, 그냥 과거 로그에 덮어쓰기를 하는 경우들이 참 많습니다. 이럴 때 로깅은 사실상 유용하지 못한 정보가 됩니다.”
요즘 사이버 공격자들은 피해자 시스템의 로그를 일부러 조작하거나 삭제하는 공격을 실시한다. 심지어 로그 정보를 훔쳐가는 경우도 있다. 그렇기 때문에 로그에 대한 접근 역시 철저하게 관리해야 하는데, “공식적으로 업무 권한을 가진 사용자만, 승인된 환경과 조건 내에서 로그에 접근하도록 정책을 정하는 게 좋다.” 또한 로그를 저장할 때 망을 분리하여 공격자가 쉽게 다가갈 수 없도록 하는 것도 중요하다. “로그가 보존된 곳에 대한 보안도 강화해야 한다는 뜻입니다.”
우선순위
그렇기에 기업들은 로그 우선순위를 정해서 저장 및 관리하는 게 좋다. 저장 공간을 무한대로 늘릴 수 있는 기업이라면 필요 없겠지만, 그렇지 않은 대부분의 기업들이 참고해야 할 내용이라고 가이드라인은 강조하는데, 이는 다음과 같다. “LOTL의 맥락에서 기업의 망은 공격자들이 사용하기 좋은 도구들로 가득합니다. 따라서 그런 도구들과 관련하여 로그의 우선순위를 정하는 게 효과적입니다.”
1) 공격 표적이 될 가능성이 높은 중요 시스템과 데이터
2) 원격 접근, 네트워크 메타데이터, 기본 서버 OS, 인터넷 연결 서비스
3) 신원 및 도메인 관리 서버
4) 기타 중요한 서버
5) 네트워크 외곽에 있는 라우터와 방화벽 등
6) 관리자의 관리 작업을 위한 워크스테이션
7) 환경 설정, 시스템 모니터링, CI/CD, 취약점 스캔, 비밀 관리, 권한 관리에 사용되는 시스템
8) 데이터 저장소
9) 보안 소프트웨어
10) 사용자 컴퓨터
11) 사용자 애플리케이션
12) 웹 프록시
13) DNS 서비스
14) 이메일 서버
15) DHCP 서버
16) 오래된 레거시 IT 자산
17) 하이퍼바이저 호스트
18) 프린터 등 부수적인 IT 장치
19) 애플리케이션 게이트웨이 등 네트워크 구성 요소
요즘은 OT 환경을 간과할 수 없는 게 사이버 보안이다. 때문에 이번 가이드라인에서는 OT 환경을 위한 로그의 우선순위도 제안했는데, 이는 다음과 같다.
1) 안전 및 서비스 제공에 중요한 OT 장치
2) 공공 인터넷과 연결된 OT 장치
3) 네트워크 외곽선을 통과했을 때 접근이 가능해지는 OT 장치
4) 로깅 기능이 없는 OT 장치(이 경우 OT 장치의 네트워크 트래픽을 모니터링)
또한 코로나 이후 원격 근무 체제가 급증했다는 것 역시 가이드라인은 놓치지 않고 있다. “모바일 컴퓨팅이 기업들의 자산이자 위협이 되고 있습니다. 집에서 근무하는 직원 개개인이 아무래도 회사보다는 보안이 취약하므로 공격자들이 엔드포인트를 자주 노리고 있기도 하지요. 이 때문에 엔드포인트에서의 로깅도 대단히 중요해지는데, 로그들은 다음과 같은 순서로 중요합니다.”
1) 사용자가 사용하는 웹 프록시
2) 회사/기관에서 운영 혹은 사용하는 DNS 서비스
3) 조직에 공식 등록된 장치들의 보안 상황
4) 조직에 공식 등록된 장치들의 행동 패턴
5) 사용자 계정에서 발생하는 활동(예 : 로그인)
6) VPN 솔루션
클라우드 컴퓨팅 환경에서 로깅할 때의 우선순위에 대해서는 다음과 같은 언급이 있었다. “IaaS, PaaS, SaaS 등 어떤 플랫폼이냐, 어떤 유형이냐에 따라 이벤트 로깅 방식을 조정하는 게 좋습니다. 예를 들어 IaaS는 테넌트에게 상당한 로깅 책임을 부여하지만 SaaS는 서비스 제공 업체에게 더 많은 책임이 있습니다. 즉, 사용자 기업은 서비스 제공 업체와 긴밀히 협조하여 로깅 문제를 해결하고 교통정리를 해놓아야 합니다. 클라우드 컴퓨팅 환경에서의 로그 우선순위는 다음과 같습니다.”
1) 표적이 될 가능성이 높은 중요 시스템과 데이터
2) 공공 인터넷에 직접 연결된 서비스
3) 클라우드 서비스에 직접 접근하고 관리하는 테넌트의 계정
4) 환경 설정
5) 모든 보안 관련 계정(생성, 삭제, 수정 등)
6) 서드파티 인증 서비스를 활용할 때(성공/실패 로그)
7) 클라우드 서비스에서 생성된 로그, 클라우드 API 로그, 네트워크 이벤트 등
[이미지 = gettyimagesbank]
LOTL, 어떻게 탐지하나
위에서 설명했지만 LOTL이라는 공격 기법이 점점 더 인기를 높이는 건, 탐지가 어렵기 때문이다. 이 때문에 로그를 수집할 때 아주 사소한 이상 행동이라도 탐지해 기록할 수 있어야 한다. 이번 가이드라인에서는 LOTL 공격에서 자주 발견되는 비정상적인 행동 패턴을 다음과 같이 정리하고 있다.
1) 비정상적인 시간대에 사용자 로그인이 발생(근무 외 시간, 공휴일 등)
2) 사용자가 일반적으로 접근하지 않는 서비스에 접근 혹은 접근 시도
3) 비정상적인 장치를 활용한 로그인 및 로그인 시도
4) 비정상적으로 빈번한 로그인 시도
5) 물리적으로 불가능한 로그인 시도(한꺼번에 여러 지역에서 동시 로그인을 하는 등)
6) 대량의 데이터 다운로드 및 외부 유출
7) 정상 인증 단계를 거치지 않은 로그인
8) 다양한 사용자 ID로 접근하는 단일 IP 주소
9) 사용자 계정 생성 / 비활성화 된 계정의 재활성화(특히 관리자 계정0
10) 일반적으로 통신 트래픽이 없는 장치에서 트래픽이 발생
11) 비정상적인 스크립트 실행
12) 갑작스러운 로그 삭제
13) 비정상적인 프로세스 생성 및 실행
14) 보안 소프트웨어 및 로깅 소프트웨어의 환경 설정 변경
물론 위의 행위들이 반드시 악성 행위인 것만은 아니다. 정상적인 상황에서도 발생할 수 있다. 따라서 이런 현상들이 하나 나타났다고 해서 반드시 ‘악성’이라고 판단을 내리기보다 추가 조사를 통해 보안 사고에 해당하는 일인지 아닌지를 판단하는 게 중요하다. 그 외에 다음과 같은 방법을 동원하여 LOTL 공격을 보다 확실하게 탐지할 수도 있다.
1) 프로세스 생성 이벤트 / 명령줄 감사 등 상세 로깅을 늘 활성화 상태로 유지한다. 이렇게 했을 때 로그 가시성이 향상된다.
2) 조직 내에서 사용할 수 있는 정상 바이너리의 기준을 정해둔다. 그렇게 했을 때 비정상 바이너리가 자연스럽게 결정된다.
3) 진화하는 위협에 따라 다양한 운영 체제에 대한 탐지 규칙을 만들어둔다. 예를 들어 윈도의 경우 powershell.exe나 cmd.exe, regedit.exe 등에 대한 상세 탐지 규칙이 큰 도움이 된다. 리눅스의 경우 curl, systemctl, python 등에 유의하는 게 좋다.
OT 환경이라면 어떨까? 이런 환경에서 주의 깊게 살펴야 할 이벤트들은 다음과 같다.
1) 비정상적인 혹은 예상하기 힘든 도구의 활용
2) 벤더나 서드파티의 갑작스러운 접근
3) 유지보수나 원격 모니터링을 위한 도구의 비정상적인 사용
4) 운영 체제, 소프트웨어, 펌웨어, 환경, 데이터베이스 등의 무단 변경 및 무단 업데이트
5) 제어 시스템과 외부 네트워크 간의 비정상적인 통신
6) 평소에 통신 활동이 없던 구성 요소 간에 발생하는 통신
7) 비정상적인 스크립트 실행
“앞으로도 LOTL 공격은 증가할 것이 분명해 보입니다. LOTL이라는 공격 기법이 공격자들에게 가져다주는 이득이 너무나 많고, 이걸 근본적으로 막는 방법이 우리에게는 너무나 부족하기 때문입니다. 따라서 네트워크와 시스템을 면밀히 관찰하고 수시로 로그를 들여다보면서 조금이라도 수상한 일이 생길 때 조치를 취하는 게 좋습니다. 이 가이드라인에서 제시한 로깅 방법론을 적용하면 LOTL을 빠르게 막아내는 데에 도움이 될 것입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 요 몇 년 사이버 공격자들은 ‘리빙 오프더 랜드(Living off the Land, LOTL)’라는 공격 기법을 꾸준히 사용해 왔다. 피해자의 컴퓨터나 네트워크에 이미 설치되어 있는 여러 가지 자원들을 공격에 활용하는 수법으로, 정상적으로 발생하는 트래픽과 공격자들이 발생시키는 그것을 구분하기 힘들며, 따라서 공격 지속성을 크게 높일 수 있다는 장점을 가지고 있다. 최근 정보 탈취가 공격자들의 중요한 목표가 되고 있는 가운데, 장시간 공격을 이어갈 수 있게 해 주는 LOTL은 점점 더 커다란 위협이 되어가고 있다.
[이미지 = gettyimagesbank]
그래서 이번 주 세계 여러 정보 보안 관련 기관들이 협력하여 LOTL 공격에 대비하는 데 도움이 될 만한 가이드라인을 작성해 발표했다. 여기에 참여한 국가와 기관들은 다음과 같다.
1) 호주 : 호주신호국(ASD)
2) 미국 : 사이버보안 및 인프라 보안국(CISA), 연방수사국(FBI), 국가안보국(NSA)
3) 영국 : 국가사이버보안센터(NCSC-UK)
4) 캐나다 : 사이버보안센터(CCCS)
5) 뉴질랜드 : 국가사이버보안센터(NCSC-NZ), 컴퓨터긴급대응팀(CERT-NZ)
6) 대한민국 : 국가정보원(NIS), 국가사이버보안센터(NCSC-Korea)
7) 일본 : 국가사이버안전센터(NISC), 컴퓨터긴급대응협력센터(JPCERT/CC)
8) 싱가포르 : 사이버보안국(CSA)
9) 네덜란드 : 일반정보보안국(AIVD), 군사정보보안국(MIVD)
들어가기에 앞서
이 기관들은 LOTL 공격에 대한 방어책으로 ‘이벤트 로그 관리’와 ‘네트워크 가시성 확보’를 내세웠다. 이번에 발표된 지침은 이 두 가지를 기반으로 하되 자원에 제한이 있다는 것을 고려하고, 피해 조직의 사이버 복원력을 향상시키는 것을 궁극적 목표로 설정했다는 특징을 가지고 있다. 되도록 많은 조직들이 적용하기 편하게 기술적인 난이도를 크게 높이지 않았다는 것도 중요하다.
이 가이드라인에 의하면 효과적인 이벤트 로그 솔루션들은 다음과 같은 목적을 달성하는 데 도움을 준다고 한다.
1) 중요한 소프트웨어 구성 변경이나 새로운 소프트웨어 솔루션이 설치될 때 네트워크 담당자(보안 담당자)에게 경고를 보낸다.
2) 침해의 범위와 심각성을 밝힘으로써 보다 정교하게 대응할 수 있게 한다.
3) 정책이 잘 적용되도록 하며, 위반 여부를 모니터링할 수 있게 해 준다.
4) 오탐과 노이즈를 줄여 저장 공간과 요청 시간 관련 비용을 절감한다.
5) 보안 담당자들이 정보를 바탕으로 결정을 내릴 수 있게 해 준다.
6) 보안 분석가들에게 유용한 로그와 플랫폼을 제공한다.
또한 로그 관리와 관련하여 모범 사례를 설정하고 준수할 때 고려해야 할 네 가지 핵심 요소를 다음과 같이 꼽기도 했다.
1) 기업에서 승인된 이벤트 로그 정책
2) 중앙 집중식 이벤트 로그 접근 및 상관 분석
3) 저장된 데이터의 보안 및 이벤트 로그 무결성
4) 관련 위협에 대한 탐지 전략
“로그와 관련된 정책을 조직 차원에서 개발하고 구현할 필요가 있습니다. 로그를 일관적으로 개발하고 관리할 때, 악성 행위를 탐지할 가능성이 높아집니다. 좋은 로그 정책에는 다음과 같은 내용들이 포함되어야 합니다.”
1) 어떤 이벤트를 로깅할 것인가를 정의
2) 이벤트 로깅을 어떤 시스템으로 할 것인가를 규정
3) 어떤 방법을 동원해 로그를 모니터링 할 것인가를 설정
4) 이벤트 로그를 어느 정도 기간 동안 보존할 것인가를 결정
5) 로그 수집 관련 정책을 어떤 시점에 재평가 할 것인가를 정의
[이미지 = gettyimagesbank]
가장 중요한 건 로그의 품질
이벤트 로그를 관리할 때 고려해야 할 또 다른 중요한 요소는 로그의 품질이다. “로그가 아무리 풍부히 많아도 그 내용이 부정확하면 분석 결과에 오류가 있을 수밖에 없습니다. 따라서 이벤트 로그 품질을 중점으로 한 정책이 필요합니다. 보통 많은 기업과 기관들이 ‘로그를 하고 있다’는 것 자체에 의의를 두지, 이것을 평상시에 관리하려는 생각을 하지 못합니다. 그럴 때 로그 품질이 떨어지는데요, 유의해야 할 부분입니다. 로그 품질은 네트워크 환경, 지켜야 할 자산의 종류, 조직의 보안성 등에 따라 달라질 수 있습니다.” 가이드라인에 나온 내용이다.
품질 좋은 이벤트 로그는 무엇일까? 가이드라인에 따르면 “보안 담당자와 분석가가 오탐에 쏟는 시간을 줄일 수 있는 로그가 가장 좋은 로그”라고 간단히 정의한다. “로그만보고 가짜인지 진짜인지를 100% 파악할 수는 없습니다. 하지만 전반적으로 분석 시간이 줄어들고 오탐 확률이 낮아진다면 그 로그는 품질이 좋다고 할 수 있습니다. 이렇게 로그 품질을 높이면 진짜처럼 보이는 게 본질인 LOTL 공격에도 효과적으로 대응할 수 있습니다.”
LOTL 기법을 사용하는 공격자들은 주로 다음과 같은 로그를 수집해 파악할 수 있다고 가이드라인은 설명한다.
1) 리눅스 기반 시스템의 경우 : curl, systemctl, systemd, python 등이 활용됐을 때 포착되는 로그
2) 윈도 기반 시스템의 경우 : wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe 등의 활용됐을 때 포착되는 로그. PowerShell 명령 실행, 스크립트 차단, 모듈 실행 등과 관련된 로그도 유용.
3) 클라우드 환경의 경우 : API 호출, 최종 사용자 로그인 등 모든 제어 관련 로그. 읽기와 쓰기 활동, 환경 설정 변경, 각종 로그인 및 인증 이벤트가 포착되도록 구성하는 게 알맞음.
이벤트 로그는 세부 정보를 풍부히 갖추고 있으면 있을수록 좋다. 그렇지 않을 경우 목적에 맞게 활용하는 게 어려워진다. 특히 보안과 관련된 세부 사항은 반드시 포함해야 하는데, 그것은 애초에 로그를 관리하는 게 대부분 보안 강화를 목적으로 하기 때문이다. 가이드라인에 따르면 다음 세부 내용들은 반드시 포함되어야 한다고 한다. 이 정도는 갖추고 있어야 품질 좋은 로그라고 할 수 있다는 것이다.
1) 올바르게 포맷되고 정확한 타임스탬프(밀리초 단위가 이상적)
2) 이벤트 유형
3) 장치 식별자의 맥주소 또는 기타 고유 식별자
4) 세션/트랜잭션 ID
5) 자율 시스템 번호
6) 출처 및 도착지 IP(IPv4 및 IPv6 포함)
7) 상태 코드
8) 응답 시간
9) 추가 헤더(예: HTTP 헤더)
10) 사용자 ID(해당되는 경우)
11) 실행된 명령(해당되는 경우)
12) 이벤트 상관 관계를 돕기 위한 고유 이벤트 식별자(가능한 경우)
하지만 로그 품질을 이상적으로만 높일 수는 없다고 가이드라인은 지적한다. “OT 요소를 포함하고 있는 네트워크의 관리자라면 이 OT 장치들을 고려해야 합니다. 대부분의 OT 장치는 메모리 또는 프로세서에 부하를 주는 임베디드 소프트웨어를 사용합니다. 과도한 로그는 OT 장치의 운영에 악영향을 미칠 수 있다는 뜻이지요. 또한, 이러한 OT 장치는 상세한 로그를 생성할 수 없는 경우가 많으므로, 센서를 사용하여 로그 기능을 보완할 수 있습니다. 임베디드 장치의 제한된 로깅 기능을 보완하기 위해 기존 통신의 오류 코드 및 페이로드를 기반으로 로그를 생성하거나, 대역 외 로그 통신을 사용할 수 있습니다.”
[이미지 = gettyimagesbank]
로그 품질을 높이는 요소들
로그의 품질을 높이는 요소들을 위에서 언급했는데, 이를 좀 더 세부적으로 설명하면 다음과 같다.
1) 이벤트 로그는 중앙에서 관리해야 한다. 중앙에서는 로그의 형식과 순서, 스키마를 일관되게 유지하는 작업을 해야 한다. 로그를 표시하는 방법에 있어서도 구성이 갖춰져 있는 게 좋다. 아무렇게나 된 로그를 중앙에서 받아 통일시키는 작업을 하는 것보다, 로그가 엔드포인트에서 생성되고 전달될 때부터 중앙에서 정한 형식이 적용되도록 하는 게 효과적이다. 그러나 모든 로그가 정해진 형식을 따를 수 있는 건 아니므로 구조를 자동으로 갖춰주는 방법론을 마련하는 것도 필요하다.
2) 로그에 찍히는 타임스탬프가 오류 없이 생성되도록 관리해야 한다. 이벤트가 발생한 ‘순서’가 로그 분석 시에 대단히 중요하게 작용하는데, 타임스탬프가 뒤죽박죽이 되어버리면 아무리 품질 좋은 로그가 생성된다 하더라도 소용이 없다. 그러려면 엔드포인트부터 네트워크에 연결된 모든 장비들이 같은 날짜와 시간으로 설정되어 있어야 하고, 심지어 날짜와 시간을 표기하는 방법도 같아야 한다. 네트워크가 분산된 상황에서는 이 시간 관련 설정을 통일하지 않게 되는데, 이 때문에 로그 품질이 저하된다. UTC 시간을 권장한다. ISO 8601 표준에 의하면 연도-월-일-시간-분-초 순서로 시간을 표기하는 게 알맞다.
3) 모든 환경에서 시간 서버가 동기화 되고, 장치 부팅 및 재부팅과 같은 중요하지만 사소한 이벤트들이 빠짐없이 포착되어야 한다.
로그의 보존
품질 좋은 로그라 하더라도 정작 필요할 때 쓸 수 없으면 말짱 도루묵이다. 따라서 로그가 보존되는 기간이 충분해야 한다. 여러 로그 시스템에 미리 설정되어 있는 기본 로그 시간은 거의 대부분 불충분하다고 가이드라인은 지적한다. 그렇다면 어느 정도가 적당할까? “로그 보존 기간은 조직의 위협 평가를 기준으로 해야 합니다. 어떤 보안 사건은 발견되는 데에만 18개월이 걸리기도 합니다. 심지어 어떤 악성 코드들은 아예 70일에서 200일 동안 슬립 모드로 있기도 하지요. 이런 것들을 전부 고려해야 합니다.”
이걸 조직이 단독으로 정하지 못할 때도 있다. “어떤 국가나 지역, 혹은 산업에서는 로그 보존 기간이 정책적으로 정해져 있기도 합니다. 규제 사항으로 못 박혀 있을 때도 있지요. 그런 기본적인 요소들까지 전부 고려하고, 규정에서 어긋나지 않도록 해야 합니다.” 어떤 로그냐에 따라 보존 기간을 달리하는 것도 중요하다. “불법 침투와 관련된 로그, 그 침투 요소가 활동한 내용에 대한 로그 같은 경우 좀 더 오래 보존하는 게 좋습니다.”
오랜 기간 로그를 보존하려면 저장 공간이 충분해야 한다. 즉 기한 설정을 할 때 조직이 보유하고 있는 저장 공간도 중요한 고려 사항이 된다는 뜻이다. “로그를 잘 하지 못하는 가장 큰 이유 중 하나가 저장 공간의 부족입니다. 이걸 처음부터 고려하지 않고 로깅을 시작한다거나, 로깅을 한참 하고 저장 공간이 부족해질 때 문제를 해결하지 않는다거나, 그냥 과거 로그에 덮어쓰기를 하는 경우들이 참 많습니다. 이럴 때 로깅은 사실상 유용하지 못한 정보가 됩니다.”
요즘 사이버 공격자들은 피해자 시스템의 로그를 일부러 조작하거나 삭제하는 공격을 실시한다. 심지어 로그 정보를 훔쳐가는 경우도 있다. 그렇기 때문에 로그에 대한 접근 역시 철저하게 관리해야 하는데, “공식적으로 업무 권한을 가진 사용자만, 승인된 환경과 조건 내에서 로그에 접근하도록 정책을 정하는 게 좋다.” 또한 로그를 저장할 때 망을 분리하여 공격자가 쉽게 다가갈 수 없도록 하는 것도 중요하다. “로그가 보존된 곳에 대한 보안도 강화해야 한다는 뜻입니다.”
우선순위
그렇기에 기업들은 로그 우선순위를 정해서 저장 및 관리하는 게 좋다. 저장 공간을 무한대로 늘릴 수 있는 기업이라면 필요 없겠지만, 그렇지 않은 대부분의 기업들이 참고해야 할 내용이라고 가이드라인은 강조하는데, 이는 다음과 같다. “LOTL의 맥락에서 기업의 망은 공격자들이 사용하기 좋은 도구들로 가득합니다. 따라서 그런 도구들과 관련하여 로그의 우선순위를 정하는 게 효과적입니다.”
1) 공격 표적이 될 가능성이 높은 중요 시스템과 데이터
2) 원격 접근, 네트워크 메타데이터, 기본 서버 OS, 인터넷 연결 서비스
3) 신원 및 도메인 관리 서버
4) 기타 중요한 서버
5) 네트워크 외곽에 있는 라우터와 방화벽 등
6) 관리자의 관리 작업을 위한 워크스테이션
7) 환경 설정, 시스템 모니터링, CI/CD, 취약점 스캔, 비밀 관리, 권한 관리에 사용되는 시스템
8) 데이터 저장소
9) 보안 소프트웨어
10) 사용자 컴퓨터
11) 사용자 애플리케이션
12) 웹 프록시
13) DNS 서비스
14) 이메일 서버
15) DHCP 서버
16) 오래된 레거시 IT 자산
17) 하이퍼바이저 호스트
18) 프린터 등 부수적인 IT 장치
19) 애플리케이션 게이트웨이 등 네트워크 구성 요소
요즘은 OT 환경을 간과할 수 없는 게 사이버 보안이다. 때문에 이번 가이드라인에서는 OT 환경을 위한 로그의 우선순위도 제안했는데, 이는 다음과 같다.
1) 안전 및 서비스 제공에 중요한 OT 장치
2) 공공 인터넷과 연결된 OT 장치
3) 네트워크 외곽선을 통과했을 때 접근이 가능해지는 OT 장치
4) 로깅 기능이 없는 OT 장치(이 경우 OT 장치의 네트워크 트래픽을 모니터링)
또한 코로나 이후 원격 근무 체제가 급증했다는 것 역시 가이드라인은 놓치지 않고 있다. “모바일 컴퓨팅이 기업들의 자산이자 위협이 되고 있습니다. 집에서 근무하는 직원 개개인이 아무래도 회사보다는 보안이 취약하므로 공격자들이 엔드포인트를 자주 노리고 있기도 하지요. 이 때문에 엔드포인트에서의 로깅도 대단히 중요해지는데, 로그들은 다음과 같은 순서로 중요합니다.”
1) 사용자가 사용하는 웹 프록시
2) 회사/기관에서 운영 혹은 사용하는 DNS 서비스
3) 조직에 공식 등록된 장치들의 보안 상황
4) 조직에 공식 등록된 장치들의 행동 패턴
5) 사용자 계정에서 발생하는 활동(예 : 로그인)
6) VPN 솔루션
클라우드 컴퓨팅 환경에서 로깅할 때의 우선순위에 대해서는 다음과 같은 언급이 있었다. “IaaS, PaaS, SaaS 등 어떤 플랫폼이냐, 어떤 유형이냐에 따라 이벤트 로깅 방식을 조정하는 게 좋습니다. 예를 들어 IaaS는 테넌트에게 상당한 로깅 책임을 부여하지만 SaaS는 서비스 제공 업체에게 더 많은 책임이 있습니다. 즉, 사용자 기업은 서비스 제공 업체와 긴밀히 협조하여 로깅 문제를 해결하고 교통정리를 해놓아야 합니다. 클라우드 컴퓨팅 환경에서의 로그 우선순위는 다음과 같습니다.”
1) 표적이 될 가능성이 높은 중요 시스템과 데이터
2) 공공 인터넷에 직접 연결된 서비스
3) 클라우드 서비스에 직접 접근하고 관리하는 테넌트의 계정
4) 환경 설정
5) 모든 보안 관련 계정(생성, 삭제, 수정 등)
6) 서드파티 인증 서비스를 활용할 때(성공/실패 로그)
7) 클라우드 서비스에서 생성된 로그, 클라우드 API 로그, 네트워크 이벤트 등
[이미지 = gettyimagesbank]
LOTL, 어떻게 탐지하나
위에서 설명했지만 LOTL이라는 공격 기법이 점점 더 인기를 높이는 건, 탐지가 어렵기 때문이다. 이 때문에 로그를 수집할 때 아주 사소한 이상 행동이라도 탐지해 기록할 수 있어야 한다. 이번 가이드라인에서는 LOTL 공격에서 자주 발견되는 비정상적인 행동 패턴을 다음과 같이 정리하고 있다.
1) 비정상적인 시간대에 사용자 로그인이 발생(근무 외 시간, 공휴일 등)
2) 사용자가 일반적으로 접근하지 않는 서비스에 접근 혹은 접근 시도
3) 비정상적인 장치를 활용한 로그인 및 로그인 시도
4) 비정상적으로 빈번한 로그인 시도
5) 물리적으로 불가능한 로그인 시도(한꺼번에 여러 지역에서 동시 로그인을 하는 등)
6) 대량의 데이터 다운로드 및 외부 유출
7) 정상 인증 단계를 거치지 않은 로그인
8) 다양한 사용자 ID로 접근하는 단일 IP 주소
9) 사용자 계정 생성 / 비활성화 된 계정의 재활성화(특히 관리자 계정0
10) 일반적으로 통신 트래픽이 없는 장치에서 트래픽이 발생
11) 비정상적인 스크립트 실행
12) 갑작스러운 로그 삭제
13) 비정상적인 프로세스 생성 및 실행
14) 보안 소프트웨어 및 로깅 소프트웨어의 환경 설정 변경
물론 위의 행위들이 반드시 악성 행위인 것만은 아니다. 정상적인 상황에서도 발생할 수 있다. 따라서 이런 현상들이 하나 나타났다고 해서 반드시 ‘악성’이라고 판단을 내리기보다 추가 조사를 통해 보안 사고에 해당하는 일인지 아닌지를 판단하는 게 중요하다. 그 외에 다음과 같은 방법을 동원하여 LOTL 공격을 보다 확실하게 탐지할 수도 있다.
1) 프로세스 생성 이벤트 / 명령줄 감사 등 상세 로깅을 늘 활성화 상태로 유지한다. 이렇게 했을 때 로그 가시성이 향상된다.
2) 조직 내에서 사용할 수 있는 정상 바이너리의 기준을 정해둔다. 그렇게 했을 때 비정상 바이너리가 자연스럽게 결정된다.
3) 진화하는 위협에 따라 다양한 운영 체제에 대한 탐지 규칙을 만들어둔다. 예를 들어 윈도의 경우 powershell.exe나 cmd.exe, regedit.exe 등에 대한 상세 탐지 규칙이 큰 도움이 된다. 리눅스의 경우 curl, systemctl, python 등에 유의하는 게 좋다.
OT 환경이라면 어떨까? 이런 환경에서 주의 깊게 살펴야 할 이벤트들은 다음과 같다.
1) 비정상적인 혹은 예상하기 힘든 도구의 활용
2) 벤더나 서드파티의 갑작스러운 접근
3) 유지보수나 원격 모니터링을 위한 도구의 비정상적인 사용
4) 운영 체제, 소프트웨어, 펌웨어, 환경, 데이터베이스 등의 무단 변경 및 무단 업데이트
5) 제어 시스템과 외부 네트워크 간의 비정상적인 통신
6) 평소에 통신 활동이 없던 구성 요소 간에 발생하는 통신
7) 비정상적인 스크립트 실행
“앞으로도 LOTL 공격은 증가할 것이 분명해 보입니다. LOTL이라는 공격 기법이 공격자들에게 가져다주는 이득이 너무나 많고, 이걸 근본적으로 막는 방법이 우리에게는 너무나 부족하기 때문입니다. 따라서 네트워크와 시스템을 면밀히 관찰하고 수시로 로그를 들여다보면서 조금이라도 수상한 일이 생길 때 조치를 취하는 게 좋습니다. 이 가이드라인에서 제시한 로깅 방법론을 적용하면 LOTL을 빠르게 막아내는 데에 도움이 될 것입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
.jpg)
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.JPG){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
.jpg){kind=small}
