회고
이번주는 탐지 정책을 설계하고 검증 하는데만 일주일을 다 썼다🫠 정말 실시간으로 눈이 뻑뻑하다 못 해 뿌옇게 흐려지고 스트레스도 정말 많이 받았던거 같다.
일단 어떤 행위를 탐지할 것인지, 이에 따라 어떤 함수를 이용할건지, 이 함수를 사용했을 때 성능적으로 부하는 어떻게 되는지 등 고려 해야하는 사항이 너무나도 많기도 했고, 우리가 사용하는 Tetragon이라는 도구는 레퍼런스로 볼만한게 논문, 공식문서뿐이라.. 뭔가 개척 해나가는 느낌이라 해야할까..? 스트레스 외에도 체력적으로도 많이 지쳤던 한 주였다.
그래도? 힘든만큼 얻어 가는게 많은 한 주였던거 같다. 커널에서 동작하는 함수들은 어떤게 있고 이들이 어떻게 동작하는지 찾아보면서 공부를 하고 정책에 적용 해보고 남들이 못 하는 일들을 내가 할 수 있는 능력을 키운다고 생각하면서 도 닦는 심정으로 시간을 보냈다.
Tetragon 정책 Bottom Up 방식의 고도화
1차적으로 MTIRE ATT&CK 테크닉을 기준으로 정책을 세웠더니 약 40개 정도의 정책이 나왔다. 근데 정책을 설계하다보니 우선 탐지 범위를 명확하게 하는 것에 어려움을 느꼈고, Tetragon의 TracingPolicy는 커널 레벨의 함수 호출(Function Call)과 그 인자(Arguments)를 대상으로 하기 때문에 복잡한 조건을 설정하거나 세밀한 MITRE ATT&CK Technique을 매핑하는 데 한계가 존재함을 확인했다.
특히 Hook Point에서 인자가 Pointer 형태로 전달될 경우 이를 역참조 해서 문자열 전체를 조건으로 거는 것은 기술적으로 매우 어렵다는걸 느꼈고 정책 설계시 유연성도 매우 떨어진다는 것을 느꼈다.
Tracing Policy
Tracing Policy는 eBPF를 기반으로 커널 수준의 System Call, Function Call, 네트워크 활동 등을 세밀하게 관찰하고 필터링하기 위해 정의하는 것을 의미한다.
우리 팀이 프로젝트 진행에 있어서 어떤 의사 결정을 해야하는 순간이 오면 일단 뭐든 한번 해보자라는 생각으로 빠르게 판단한다. 내가 이 팀의 팀장이기에 주로 내 결정에 따라 팀이 움직이게 되는데 그런 순간이 올 때마다 "완벽보다 실행에 집중한다", "신속하게 움직인다"라는 토스의 코어 벨류를 되세기는거 같다. 그리고 팀원들도 시원하게 머리 박자고 하면서 움직인다ㅋㅋㅋㅋ
다시 본론으로 돌아오면 아무래도 빠르게 결정하고 실행에 집중하다 보니 문제는 항상 터진다. 프로젝트 기간이 워낙 짧다보니 최대한 많은 경우의 수를 생각하고 들어가도 놓치는 부분들이 분명히 존재하기에 ..
그래서 우리는 이 문제를 해결하기 위해 Tetragon으로만 해결하려 하지 않고 Fluentd로 눈을 돌렸다. 팀에서 같이 Tetragon 정책을 설계하던 희수가 Fluentd에서 로그가 모이고 대시보드로 가니까 여기서 모든 필드를 파싱할 수 있고, 바이너리 경로 뿐만 아니라 구체적인 인자 값 등을 조합해서 조건 설정을 할 수 있을거 같다고 해서 해보자고 했고 결과적으로 앞서 말한 문제를 해결할 수 있었다.
따라서 1차 필터링을 Tetragon으로 2차 필터링 및 공격 태깅을 Fluentd로 정의했고, 동시에 Technique 별로 정책을 40개나 들고 관리하는게 상당한 비효율로 다가왔다.
따라서 우리는 Tetragon 정책을 File, Network, Process, Permission 네 가지로 정책을 재분류, 최적화 및 고도화하기로 했다. 이러한 접근이 더 효율적이고 정교한 탐지가 가능할 것이라고 생각했다.
딱히 의도한건 아니지만? 실제 공격 사례 기반인 MITRE ATT&CK 테크닉을 최소 단위로 분석하고, 이를 실행 관점의 4개 영역(File, Network, Process, Permission)으로 범주화하여 정책을 고도화하는 Bottom-Up 방식의 설계를 진행했다고 볼 수 있겠다.
희수가 fluentd 필터링을 전담하고 내가 Tetragon 정책 최적화를 맡았는데 1차 설계하는건 아무것도 아니었구나 싶었다... "세워진 정책을 범주화 해서 탐지 이벤트를 정리하고 어떤 함수를 사용하고 있고 이 함수는 중복되니까 탐지 범위를 묶고 이 탐지 포인트랑 저 탐지 포인트를 묶으려면 AND? OR? 같은 탐지 기능을 가졌다고 볼 수 있나?" 등 ..... 많은 생각을 했다 🤯
우여곡절이 많았지만... 우리는 그물망 짜듯이 탐지를 여러 레이어로 하기 때문에 설계가 끝나고 공격을 수행 해봐야 추가로 고도화를 하든 할 수 있어서 일단 여기서 마무리했다.. 고생했다 나 자신...
Open Search SIEM 솔루션
Tetragon 정책 설계를 마무리하고 우리 프로젝트의 다음 단계인 Open Search에서 탐지와 상관 분석을 위해 역할 배분을 다시 했다. 이미 Open Search는 민송이가 담당하고 있고 상관 분석 조사 및 설계 부분을 다른 팀원들이 담당하고 있어서 내가 Open Search에 붙고 희수는 상관 분석 조사 및 설계 부분에 붙게 되었다.
Open Search에선 탐지나 분석 관련해서 많은 기능을 지원하기 때문에 기능 파악을 우선적으로 진행했다. 또 지속적으로 Open Search에서 ML을 통한 Anomaly Detection 부분이 잘 안된다는 피드백이 나오고 있었어서 숨 돌릴 틈도 없이 움직였다.
Open Search
OpenSearch는 Elasticsearch와 Kibana에서 파생된 오픈 소스 기반의 분산 검색 및 분석 엔진으로 대용량 데이터의 실시간 검색, 시각화 및 로그 분석에 최적화되어 있다. 모든 기능이 오픈 소스로 제공되어 라이선스 제약 없이 SIEM이나 Observability 시스템을 구축하는 데 활용된다.
이 파트에 붙자마자 바로 문제를 발견했다. 앞서 말한거처럼 공식문서를 통해 기능 파악을 하는 와중에 릴리즈 노트를 보는데 우리가 2.13.0 버전을 사용하고 있었다. 근데? 최신 버전이 3.4.0이었다. 바로 민송이한테 우리 왜 이 버전 쓰고 있는거지..?
일단 더 확인 해본 결과 최신 버전을 사용하는게 맞았고 즉시 버전 업그레이드를 진행했다.
민송이가 너무 미안하다고ㅋㅋㅋㅋㅋ 막 수습하고 있는 모습을 보니 안쓰러웠다..ㅋㅋㅋㅋ
내가 한번 더 확인했어야 됐다고 앞으로 도구 사용할 때는 릴리즈 노트와 공식 문서를 먼저 읽는 습관을 들이자..!라고 하며 무탈?하게 넘어갔다.
사실 버전 업데이트할 때 뭔가 의존성이 있는 부분이 있거나 하면 되던게 안되는 상황이 벌어지는 경우가 많은데 정말 다행히도 그런 이슈는 발생하지 않았다.. 민송이한테 말은 안했지만 정말 쫄렸다.
다시 본론으로 들어가면 공식문서를 읽던 와중에 Security Analytics라는 기능을 발견했다.
이 기능은 Open Search가 제공하는 SIEM(Security Information and Event Management)솔루션이다.
로그 타입을 정의하고 Detector 설정을 할 수 있다. 우리가 실제 환경에서 Tetragon과 Hubble을 통해 런타임 탐지, Open Search에서 Network 정보를 이용한 이상행위탐지, 지식 기반 탐지 총 세 가지 탐지 레이어를 갖는데 Open Search에서 지원하는 Detector가 Sigma Rule 베이스로 동작을 해서 신뢰성 있는 지식 기반 탐지를 할 수 있다는 것을 확인했다.
지식 기반 탐지는 이미 잘 알려진 Feature들을 이용해서 탐지를 해야 신뢰성과 탐지 성능을 보장할 것이라고 생각했지만 어떤 규칙들을 이용해서 탐지를 해야하는지 고민이 많았는데 이걸 보자마자 혈이 뚫렸다. 그래서 나에게 주말과 다음주에 테스크로 Security Analytics 기능 활용 설계가 주어졌고 이와 관련해서 진행 사항은 다음주 TIL에 정리 해보도록 하겠다.
마무리
이 그림은 10월 말 즈음에 현재 프로젝트를 처음 설계할 때 그린 아키텍쳐다. 사용하는 도구, 구조 같은 것들이 많이 바뀌긴 했지만 그렸던 청사진이 하나씩 구체화 되어 가고 완성을 앞두고 있다는게 정말 신기하다.
그만큼 정말 쉼없이 달려왔구나 하는 생각이 든다.. 뭐 궁상 떠는건 아니고 사실 팀원들이 많이 지친거 같다는 느낌을 많이 받는다. 나도 마찬가지지만 본격적으로 프로젝트 수행하기 2주, 3주 전부터 지금까지 달려왔으니... 힘이 빠질만 하지 하면서도 이럴 때일수록 내가 팀의 중심을 잡아야 잘 마무리 할 수 있겠다는 팀장으로서 책임감도 많이 느끼게 되는거 같다.
어떻게 하면 이를 해소할 수 있을까 고민하다가 그냥 내가 더 열심히 하기로 했다. 우리 팀원들은 요행을 피우는 사람들은 아니어서 내가 더 뭔가 해오고 움직이면 따라 와줄걸 아니까 조금 힘들어도 열심히 해보려고 한다.
프로젝트를 위해서도 있지만 이 과정이 끝나고 뒤돌아 봤을 때 이게 최선이었나?라는 생각은 분명히 들겠지만 "그때의 최선이었어"라고 확신하고 싶다. 잘할 수 있겠지?
이번주 TIL은 여기서 마치도록 하겠다. 이번주도 고생 많으셨습니다!
