회고
이번주는 프로젝트 진행에 있어서 답답함을 느끼던 부분을 해결한 한 주였던거 같다. 그와 동시에 나 자신에 대해 많은 생각을 했던 한 주였다. 우리 프로젝트 팀장으로서 내가 잘했을까? 이런 생각을 많이 했던거 같다.
암튼 이번주 TIL도 있었던 일들과 수행했던 작업들을 정리 해보겠다.
프로젝트 수행일지
프로젝트에 대해 궁금하다면 이 시리즈를 읽어 보세요!
프로젝트 Deadlock
우리 프로젝트의 핵심은 탐지 고도화이다. 따라서 우리는 Tetragon을 활용하여 런타임 환경에서 행위 기반 탐지를 하고 이 탐지 결과에 대해 시그마 룰을 활용한 지식 기반 탐지를 하여 각 탐지 기법이 갖는 단점을 서로 보완하여 탐지 Hole을 최소화 시키는 것을 목표로 했다.
시그마 룰은 ECS(Elastic Common Schema) 포맷을 따라 설계되어 있다. 하지만 우리가 사용하는 Tetragon이 남기는 로그는 ECS 포맷이 아니기 때문에 로그 타입을 새롭게 정의하여 룰이 가리키는 Condition을 우리 로그 포맷에 맞게 진행 해주는 작업이 필요했다.
이런 과정을 거쳐 Open Search 대시보드에서 지원하는 Detector에 룰을 설정을 하면 Tetragon이 남긴 로그를 룰과 비교하여 위협 행위를 탐지하는 식으로 동작한다.
Sigma Rule 도입 제안과 설계를 내가 했기 때문에 내가 이 작업을 맡아 진행을 할까 했지만 Correlation 분석 설계와 우리 프로젝트에서 활용할 공격 시나리오 검증 등 내가 더 힘을 실어서 진행해야 할 Task들이 많았고 반복적인 작업에 가까웠기 때문에 다른 팀원들에게 이 작업을 맡기게 되었다.
공격 시나리오 정리 -> Detector 설정 -> 공격 수행 -> 탐지 결과 정리 -> 분석
이 작업들이 연속적이기 때문에 선행 단계가 완료가 되어야 후속 작업들을 할 수 있었다.
프로젝트 준비 과정에서 MCP 설계라던지 어떤 공격을 수행할 수 있는지 등 정리 해놓았기 때문에 공격 시나리오를 하루만에 끝내고 주말동안 최대한 시그마 룰 작업을 끝낼 수 있게 시간 확보를 해주고자 밤을 세워서 다음날 점심즈음에 작업을 마무리해서 넘겼다.
근데 주말 이틀 간 마무리하기로 한 시그마 룰 작업이 끝나지 않았고 원인조차 명확히 파악을 못하고 있는 상황이 발생했다. 사실 이해가 가지 않았다. 이 작업을 위해 로그 정규화도 이미 진행한 상태여서 데이터 소스에는 문제가 전혀 없었을텐데 .. 사실 완수를 하지 못했다라는 점보다 원인 파악을 명확히 하지 못했다는 점에서 화가 났던거 같다.
다음날 와서 회의를 진행하는데 담당 팀원들이 원인을 명확히 파악하지 못하고 있는 상태였다. 희수가 안될리가 없다며 바로 조금 만져봤는데 된다고 한다. 정확히 Alert가 발생한 것까지 확인한 것이다. 그리고 내가 룰 필드 매핑한 것을 봤는데 같은 값을 서로 다른 필드로 참조하고 있는 것을 확인했다.
이에 대해서 왜 이렇게 설정을 한 거냐고 물어봤지만 명확한 답변을 얻지 못했다. 이런 과정에서 담당 팀원들의 감정이 조금 상한게 보였다.
룰 양이 180개가 넘어가다 보니 힘든건 이해한다만 내 입장에서는 프로젝트를 이끌어 가야하고 내가 한 질문에 대해 명확하게 답변을 못 받았고, 개개인의 능력 차이는 당연히 존재하겠지만 한 사람이 조금 만져서 해결된 일을 이렇게까지 끌고 갈 일인가? 싶었다.
결단
시그마 룰이 끝나기까지 마냥 기다릴 수는 없었기에 후속 작업들을 끌고와서 진행하기로 했다. 일단 우리 프로젝트에서 탐지 고도화 부분은 검증을 해야 알 수 있었고, 방법론적인 측면에서 더이상 뭘 추가하거나 그럴 이유가 없었기에 분석에 집중을 하기로 했다.
근데 우리 프로젝트에서 분석에 대한 수준이 너무 낮은듯한 생각이 들었다. 그래서 희수랑 민송이랑 이에 대한 주제로 한 1시간 ~ 2시간 가량 토론?을 했던거 같다.
결론은 분석을 고도화 하기 위한 추가적인 수단이 필요하다는 것이었다. 그래서 각자 분석을 어떻게 고도화 시킬 것인가에 대해 방법론적으로 설계를 해오자는 것이었다.
나는 Risk Score 도입을 설계를 했다. Open Search Security Analytics에서 제공하는 Correlation Engine은 Detector가 잡아낸 결과를 통해 동작한다. 즉, Rule Based Detection의 결과를 상관분석을 하는 것이기 때문에 Anomaly Detection 결과를 반영하지 못 한다고 생각하면 되고 이렇게 해서 분석을 끝내면 우리 프로젝트에서 분석의 깊이가 너무 얕다는 판단이 들었다.
그렇다면 외부에서 상관분석을 해야할까? 이는 의미가 없다고 생각했다. 이미 설정한 Detection Rule에 의해 탐지된 시스템, 네트워크 로그를 상관분석이 이루어지기 때문에 상관 분석을 외부에서 추가로 진행하는 것은 분석 고도화 측면에서 설득력이 없다고 생각했다.
정리 해보면 Rule Based, Anomaly(Baseline Based), Behavior Based Detection에 의해 탐지된 결과와 상관분석 결과를 가지고 다른 분석 기법을 통해 분석을 진행하는 것이 분석 고도화에 부합하고, 상관분석은 Security Analytics에서 지원하는 기능을 하는 것으로 마무리 짓는 것이 맞다는 판단을 해서 Risk Score를 이용한 정량적 위협 모델링을 설계하기 시작했다.
Risk Score를 이용한 정량적 위협 모델링
우선 Risk Score에 대한 정의를 내릴 필요가 있었다. 먼저 생각한건 우리 프로젝트의 탐지 결과에서 정량적인 지표로 뽑을 수 있는게 무엇일까?라는 생각을 했다. 그리고 상관 분석 결과를 이와 어떻게 결합할지를 생각 해봤다.
지표화
지표화 단계에서는 “각 탐지 레이어 별 탐지 결과” + “상관 분석 결과”를 Input으로 사용한다.
- Rule Based Detection에서 지표
- 탐지 된 규칙에 대한 Rule Severity
- Baseline Based Detection에서 지표
- Anomaly Grade (평소와 얼마나 다른가)
- Confidence (그 판단이 얼마나 신뢰성을 갖는가)
- Behavior Based Detection에서 지표
- 실행 Process 정보 (기준을 정하여 수치로 환산)
- 실행 Process의 부모 프로세스 정보 (기준을 정하여 수치로 환산)
- Cohesion(응집도) 지표
- 동일한 pod_name 또는 container_id에서 발생 여부
- 각 탐지 레이어에서 설정한 Timewindow(1분 ~ 5분)내에 이벤트들이 밀집해 있는지 여부
- Correlation Result에서 지표
- 상관 관계의 강도
정리를 해보니 이렇게 지표화 할 수 있는 것을 뽑을 수 있었고, 정말 간단히 이에 대한 수식을 다음과 같이 세워봤다.
시그마 룰에 부여된 Severity Score와 이상 탐지 결과와 신뢰도의 곱과 실행 프로세스 정보를 수치로 환산한 값을 모두 더하고 이를 응집도를 곱한 수식이다.
우선 이렇게 러프하게 설계해서 팀원들한테 공유를 했고, 대부분 긍정적인 반응이었지만 이 지표에 대한 신뢰성 문제, 가중치 설정, 수식 구체화 과정에서 사용하는 알고리즘 등 남은 기간동안 논리적 결핍없이 완수할 수 있을까?라는 의문은 풀리지 않았다.
그래서 시각화 단계에서 보조 도구로서 활용을 할까도 생각했지만 오히려 우리 프로젝트에서 마이너스 요소로 작동할 수도 있다는 생각이 풀리지 않아 폐기했다.
STRIDE
공격 행위를 여섯가지 범주로 나눈 모델이다. 해당 위협 모델을 통해 얻을 수 있는 것은 어떤 유형의 공격이 일어났는지를 범주화 할 수 있다.
- Spoofing
무단 액세스를 위해 다른 사용자 또는 시스템 구성 요소를 사칭하는 것을 의미한다.
스푸핑 공격은 인증 메커니즘을 손상시켜 공격자가 합법적인 사용자 또는 장치로 가장할 수 있도록한다. - Tampering
변조는 데이터 또는 코드의 무단 변경을 의미한다. 실행 중인 애플리케이션의 파일, 데이터베이스, 소프트웨어 코드, 배포 파이프라인 또는 메모리를 수정하여 데이터 무결성을 저하 시키는 공격이 이에 해당한다. - Repudiation
사용자가 특정 활동(데이터 삭제, 설정 변경, 권한 오용 등)을 수행한 후, 이를 입증할 증거가 없음을 악용하는 공격이다. 로그 삭제와 같은 공격이 이에 해당한다. - Information disclosure
권한이 없는 사용자나 프로세스가 보호되어야 할 민감한 정보에 접근하여 읽게 되는 위협을 의미한다. 파일 및 데이터 유출과 같은 공격이 이에 해당한다. - Denial of service
과도한 요청으로 시스템을 압도하거나 시스템 취약점을 악용하여 서비스의 가용성을 저해하는 것을 목표로 하는 공격이 이에 해당한다. - Elevation Of Privilege
공격자가 시스템 취약점을 악용하여 권한 상승을 하는 것을 의미한다. 컨테이너 탈출과 같은 공격이 이에 해당한다.
원래 STRIDE와 Risk Score를 결합하려고 했는데, Risk Score가 우리 프로젝트에서 폐지되면서 STRIDE는 Detector 분리 작업에 사용하게 됐다.
Click House 도입
이건 희수가 찾아왔고 결론적으로 우리 프로젝트에 결핍으로 작용했던 분석의 깊이가 얕다는 점을 완벽하게 메워줘서 한층 풍성해진 결과를 얻어낼 수 있었다.
ClickHouse는 대규모 데이터의 실시간 분석을 위해 설계된 열 지향(Column-oriented) 분산 데이터베이스 관리 시스템이다. 데이터를 행이 아닌 열 단위로 저장하여, 특정 컬럼에 대한 집계 작업(SUM, AVG 등) 속도가 매우 빠르고 압축 효율이 높다는 특징을 가지고 있고 CPU의 SIMD 지침을 활용하여 데이터를 한 번에 대량으로 처리함으로써 압도적인 쿼리 성능을 제공한다고 한다.
Toss, kakao 등 큰 기업들에서도 많이 사용하는 도구로 알려져 있어 검증이 된 도구라는 생각이 들었다. 희수가 데모를 진행해서 결과를 가지고 왔는데 정말 충격적(Positive)이었다.
위 두 사진은 Click House를 이용해서 탐지 결과를 분석한 것이다. 결과를 보면 Tetragon이 가지는 가장 강력한 기능중 하나인 프로세스 계보 추적의 결과가 그대로 녹아져 있고, 허블 로그를 활용한 네트워크 분석 결과도 시각적으로 훌륭하게 나왔다.
우리 프로젝트의 퀄리티가 한층 더 업그레이드 된 순간이었던거 같다. 사실 나는 어떤 도구를 추가적으로 도입하기 보단 방법론적으로 설계해서 진행 해야한다고 생각했는데 잘못 생각했던거 같다. 암튼 우리는 이 도구를 사용하기로 결정했고, 이를 활용해서 탐지 결과를 분석하고 결과물에 대한 가시성을 좋게 만들기 위해 작업중에 있다.
마무리
처음에 말했듯이 프로젝트 팀장으로서 내가 잘하고 있을까?라는 의문은 이번주에 있었던 문제를 해결 해나가는 과정을 돌이켜 봤을 때 잘못된 판단을 했다는 생각과 함께 증폭했던거 같다. 사람의 성향에 맞춰 대응을 할 것인가 온전히 일적으로 팀에 도움이 되는 방향으로 대응을 할 것인가 항상 고민이었다.
시그마 룰을 담당한 팀원들의 성향은 MBTI로 따지면 F 성향이 강하다고 생각한다. 그래서 팀 전체적으로 봤을 때 온전히 일적으로 어떤 결정을 내리기엔 감정이 상한다던가 그런 이슈가 발생해서 빨리 진행해야 한다라던지 그런 내용을 전달할 시 해당 팀원들의 일적인 효율이 떨어진다라는 판단을 했다. 그래서 기다리기로 했고, 진행상황만 정기적으로 물어보며 상황을 체크했다.
모든 결정에는 Trade Off가 있다. 역시 이 판단에도 존재한다. 그렇게 일정이 지연될 경우 다른 팀원들과 내가 그 무게를 견뎌야 했기 때문에 남은 사람들의 부담이 가중된다. 또, 다른 팀원들이 이에 답답함을 많이 느낀다는걸 체감했다.
뭐가 맞는 판단이었을까? 사실 잘 모르겠다. 그당시 내가 할 수 있었던 두 가지 판단 중 다른 판단을 했다고 해서 더 좋은 결과를 가져올 수 있다는 확신도 없고 더 안좋은 결과를 가져올 수 있다는 확신도 없다.
머리는 아프지만 이런거 또한 배움의 과정인거 같다. 프로젝트 진행하면서 기술적인 성장도 당연히 있겠지만 팀장으로서 어떤 의사결정을 위한 고민들, 팀원들을 대하는 태도 등 팀장을 하지 않았다면 할 수 있었던 고민들은 아니니 좋은쪽으로 생각하려고 한다. 실수하면서 실패하면서 다 배우는거 같다.
나의 판단의 상처 받거나 답답함을 느끼는 모두에게 미안하지만 프로젝트가 잘 됐으면 하는 마음을 팀원들이 느끼게 하면 용서? 받을 수 있지 않을까ㅋㅋㅋㅋㅋ하는 생각이다.
뭐 근데 그렇다고 해서 이해를 바라거나 그러진 않는다. 나도 워낙 결과론적인 사람이라.. 결과로 증명하자.
이번주 TIL은 여기서 마치도록 하겠다. 이번주도 고생 많으셨습니다!
