구성 1개가 변경됐습니다. 아무도 알아차리지 못했죠.

실제로 격차가 열리는 지점

오전 2시 14분, 도메인 컨트롤러에서 레지스트리 값이 바뀝니다. /etc/ssh/sshd_config의 파일에 한 줄이 추가됩니다. 지역 사무실의 스위치에 있는 방화벽 ACL이 새 허용 규칙을 받아들입니다. 이중 어느 것도 SIEM 경고를 유발하지 않습니다. 무엇 하나도 당장 고장 나게 만들지 않습니다. 또한 취약점 스캔 결과에도 나타나지 않습니다. 스캐너가 어제 실행됐고 다음 주까지 다시 실행되지 않기 때문입니다.

그 격차는 이미 열려 있습니다. 공격자는 당신보다 먼저 그것을 읽습니다. 바로 그 작은 일탈, 기록되지 않은 변경, 아무도 책임지지 않는 드리프트를 찾아보고 있기 때문입니다.

그래서 file integrity monitoring 을 사후 대책처럼 해서는 효과가 없습니다. 이벤트 로그를 가져와 4663을 grep으로 찾는 건, 지연된 중계 화면으로 경기를 보는 것과 같습니다. 그때그때 강하게 누르는 게 아니라, 나중에 반응하는 셈입니다. 일탈은 실제로 신뢰하는 기준선(baseline)과 비교하여, 발생하는 순간 I/O 계층에서 감지되어야 합니다.

커널에서의 압박

Windows의 Gen 7 Agent는 고도 388790에서 Filter Manager에 minifilter 드라이버를 등록합니다. 모든 파일 I/O 작업(생성, 쓰기, 삭제, 이름 변경, 속성 변경)은 필터 스택을 통과하며, 드라이버는 추적 템플릿과 일치하는 이벤트를 메모리 버퍼에 기록합니다. 에이전트는 100밀리초마다 해당 버퍼를 폴링합니다. 파일 잠금이 없습니다. I/O를 수정하지 않습니다. 활성화에 재부팅이 필요하지 않습니다.

이게 바로 “press”입니다. 로그가 플러시되길 기다리지 않습니다. 5분 간격으로 파일시스템을 폴링하면서 그 사이에 아무 일도 일어나지 않길 바라는 방식이 아닙니다. I/O 경로 자체에 연결되어, 실시간으로 모든 접점을 읽고, 사용자가 정의한 형태와 비교합니다.

Linux에서는 Gen 7 Agent가 Sysdig를 사용해 동일한 수준의 파일 무결성 변경과 그 변경을 수행한 사용자 신원을 캡처합니다. 무엇이 바뀌었는지뿐만 아니라 누가 변경했는지도 확인합니다. 왜냐하면 “누군가 /etc/pam.d/sshd를 수정했다”는 경고의 절반에 불과하기 때문입니다. “서비스 계정 svc-backup 이(가) 유지보수 창 밖의 세션에서 02:14에 /etc/pam.d/sshd를 수정했다”는 것은 판단(결정)으로 이어집니다.

에이전트리스(Agentless) 방식의 커버리지가 나머지를 처리합니다. SSH를 통한 네트워크 장비. 포트 445의 원격 레지스트리를 통해 Windows 호스트. 셸을 통해 Linux 및 Unix. PowerCLI를 통해 ESXi 및 vCenter. 공급자 API를 통해 클라우드 플랫폼. 백라인 전체에 대해 하나의 기준선(baseline)을 적용하며, 서로 다른 아홉 가지 도구로 아홉 군데를 따로 감시하는 방식이 아닙니다.

루프를 닫다

맥락 없이 실시간 탐지는, 지나가는 모든 선수를 파울하는 미드필더와 같습니다. 20분쯤 지나면 10명으로 줄어들고 벤치에서는 소리치기 시작하죠.

실제 환경에서 발생하는 대부분의 변경은 정당합니다. 패치가 적용되고, 관리자는 관리자의 할 일을 하고, 예약된 작업이 파일에 손을 대죠. 그 모든 것에 대해 FIM tool 이 전부 알림을 띄운다면 그건 노이즈고, 노이즈는 무시되며, 무시는 아무것도 없는 것보다 더 나쁩니다. 이제는 도구는 있지만 보장 범위에 대한 잘못된 확신만 갖게 되는 거죠.

Change Tracker 감지된 모든 변경을, 실제로 일어나야 했던 내용과 대조해 조정합니다. Sync Service는 ServiceNow, BMC Remedy, Cherwell, ManageEngine, ChangeGear, OpenText SMAX, Samanage에서 승인된 변경 요청을 가져옵니다. 각 RFC는 예정된 변경 일정(스케줄 윈도우), 구성 항목(구성 요소), 그리고 ServiceNow의 경우 AssignedTo 필드까지 포함한 Planned Change로 변환되므로, 이벤트를 단지 ‘언제’가 아니라 ‘누가’ 변경을 해야 했는지에 맞춰 매칭할 수 있습니다. 감지된 이벤트는 planned change 규칙 세트에 따라 평가되고 분류됩니다.

계획됨. 승인됨. 필터링됨.

계획되지 않음. 노출됨. 조사됨.

이것이 바로 폐루프입니다. 어떤 실행은 미끼이고 어떤 실행이 실제 위협인지 파악한 다음, 중요한 것에만 집중하는 것이죠.

티켓이 없고, 변경 사항에 해당하는 RFC가 없으며, 기록된 정당한 사유도 없다면 Change Tracker는 해당 사고를 ServiceNow 로 자동으로 다시 올려, 구성 항목의 담당자에게 라우팅할 수 있습니다. 승인되지 않은 변경은 이를 해결하는 작업 항목을 생성합니다. 압박은 단지 공을 따내는 데서 끝나지 않습니다. 카운터를 시작하죠.

기준선은 포메이션이다

형태가 없는 백포는 그저 한 경기장 위에 선 네 명의 선수일 뿐입니다. 기준선이 없는 탐지는 똑같아요. 정상적인 상태를 정의하지 않았다면, 편차를 드러낼 수 없습니다.

기준 구성(Baseline Configuration) 기능은 코치가 전술 세팅을 준비하듯이 이것을 다룹니다. 소스 장치를 선택하세요. 즉, 골드 이미지나 강화된 기준 빌드를 말합니다. 그 상태를 캡처합니다. 파일 무결성(File integrity). 설치된 소프트웨어. 실행 중인 프로세스. 서비스와 그 상태. 로컬 계정. 열린 포트. Windows의 레지스트리 키입니다. 기준선은 포메이션이 되고, 그룹의 다른 모든 장치는 그 기준과 비교하여 측정됩니다. 드리프트는 예외로 나타납니다. 예외는 검토됩니다. 승인된 드리프트는 기준선으로 승격(업데이트)됩니다. 승인되지 않은 드리프트는 시정(remediation)됩니다.

이것이 NERC CIP-010-4 및 5가 허가된 기준 구성(authorized baseline configurations)과 35일 변경 모니터링에 대해 이야기할 때 요구하는 것입니다. 이것이 PCI DSS 요구사항 11.5가 변경 탐지 메커니즘(change detection mechanisms)에 대해 말할 때 원하 는 것입니다. 그리고 이것이 CIS Control 4 가 기업 자산의 안전한 구성(secure configuration)에 대해 말할 때 원하는 것입니다. 모든 프레임워크는 다른 말로 동일한 것을 설명합니다. 즉, 형태를 정의하고(define the shape), 그 형태를 유지하며(hold the shape), 편차를 드러내는(surface the deviation) 것입니다. Change Tracker는 바로 이 정확한 루프를 기반으로 구축되어 있으며, 250개 이상의 사전 제작된 규정 준수 보고서가 기준선을 감사자가 3월에 확인하고자 할 프레임워크와 연결해(매핑) 제공합니다.

기록 없이는 어떤 것도 움직이지 않습니다

대시보드는 초록색입니다. 티켓은 관리 가능한 수준입니다. 팀도 편안한 상태입니다.

그 순간이 경기에서 가장 위험한 때입니다.

어딘가에서 환경이 막 바뀌었습니다. 도구가 결국 이를 알아차릴지 여부가 아닙니다. 중요한 건 공격자가 공격 기회가 열린 순간부터 실제로 탐지가 작동한 순간까지 몇 번이나 공격을 이어갔는지입니다.

더 일찍 압박하세요. 변화가 일어난 지점에서 플레이를 읽으세요. 형태를 정의하고 그 형태를 유지하며, 기록 없이 아무것도 움직이지 않게 하세요.

그게 해야 할 일입니다. 그게 기준입니다. 그것이 바로 당신의 것을 지키는 방법입니다.