올바른 위협 인텔리전스 보고서의 요건
바야흐로 인텔리전스 홍수의 시대이다. 많은 보안 벤더들은 각자의 연구 결과를 인텔리전스 보고서나 블로그 형태로 발표하고 있으며, 하루에도 수많은 보고서, 기사, 블로그들이 RSS 피드를 가득 채우고 있다. 아침에 일을 시작하면서 이 중 필요한 글을 선별하여 읽는 것만 해도 많은 시간이 소요된다.
많은 사람들이 인텔리전스 보고서와 악성코드 분석 보고서를 같은 결과물로 생각하고 있다. 하지만 인텔리전스 보고서는 악성코드 분석 보고서보다는 좀 더 넓은 범위를 내용을 포함하고 있다. 물론 인텔리전스 보고서에서도 악성코드와 관련된 기술적인 분석 내용은 매우 중요한 부분을 차지하고 있으며, 가장 많은 리소스가 투입되는 부분이기도 하다. 하지만 그 외에도 사용된 인프라(Infrastructure)에 대한 분석, 공격 대상에 대한 정보, 공격의 배후에 존재하는 국가, 그룹, 개인에 등에 대한 정보(Attribution) 등 다양한 정보가 포함되며 무엇보다 중요한 것은 해당 공격에 충분한 정보를 바탕으로 대응할 수 있는 방안을 제시하는 것이다.
Elements of threat intelligence report일반적인 인텔리전스 보고서의 작성 과정은 다음과 같다. 보고서 작성의 시작은 보통 다양한 경로를 통하여 얻은 IOC(Indicator of Compromise)를 바탕으로 시작된다. 예를 들어 이전에 작성된 룰에 의하여 탐지된 악성코드나 SNS에 공유된 악성코드 등에서 시작된다. 이후 수집된 IOC를 바탕으로 비슷한 악성코드를 헌팅(Hunting) 하는 과정이 진행된다. 헌팅 과정에서는 해당 악성코드를 탐지할 수 있는 룰(i.e. Yara rule)을 생성한 뒤 스캔을 통하여 비슷한 유형의 악성코드를 탐지하는 과정이 진행된다. 이런 식으로 분석 대상 범위를 넓힌 뒤, 수집된 악성코드, 툴, 연관된 C2 서버 등을 분석하는 과정을 진행한다. 분석 과정에서 추가적인 IOC들이 발견되게 되며, 해당 과정을 지속적으로 반복한다. 이렇듯, 인텔리전스 보고서에서는 이전 공격과의 연관성이나 큰 맥락에서의 연관성이 필요하므로 하나의 악성코드에 대한 분석 보다는 좀 더 넓은 범위의 연구가 필요하다.
General threat intelligence research process하지만 안타깝게도 많은 인텔리전스 보고서, 특히 국내에서 발표되는 보고서를 보면 전체 공격 과정 중 Initial access 단계에서 사용되는 악성코드에만 집중하고 있다. 물론 최초 침투에 사용되는 악성코드에 대한 정보 전달도 중요하지만, 전체적인 공격 과정에 대한 분석 및 정보 전달을 위한 노력도 필요하다. 공격자 역시 Initial access 단계에 많은 공을 들이고 있기 때문에 이 단계에서 완벽한 탐지, 빠른 대응과 같은 마케팅 메시지는 이제는 통하지 않는 시대이다. 우리가 Initial access 단계의 악성코드를 발견했을 때 이미 공격자는 Exfiltration 단계까지 진행한 뒤 유유히 흔적들을 지우고 있을 수도 있다. 따라서 전체적인 공격 과정에서 사용되는 전략들에 대한 이해를 바탕으로 우리 조직에서는 어떤 식으로 탐지할 수 있고, 현재 탐지가 가능한 수준인지 파악하는 것이 중요하다.
Attack process인텔리전스 보고서를 생산하는 생산자의 입장에서 본인의 보고서가 최적의 보고서라는 말은 절대 아니다. 하지만 아래는 현재 직장에서 수년간 수십 개의 인텔리전스 보고서를 작성하면서 느낀 점에 대해서 정리한 것으로 항상 이런 점에 유의하면서 보고서를 작성하고자 노력하고 있다.
쉽지만 자세하게(Easy but detailed)
일반적으로 엔지니어들에게 가장 고통스러운 작업은 프로그래밍도, 악성코드 분석도 아닌 문서 작성이 가장 고되다는 얘기를 들은 적이 있다. 실제로 이과에 공대를 나온 엔지니어들에게 문서 작성은 고된 작업일 수밖에 없다. 하지만 문서화를 통해서 자신의 연구 성과를 공유할 수 있으므로 반드시 필요한 작업이다. 좋은 문서화란 어려운 내용을(악성코드에 대한 기술적으로 복잡한 과정을) 최대한 쉬운 언어로 설명하는 것이라 생각한다. 미사여구나 어려운 전문 용어를 남발하거나, 디버거의 스크린샷으로 도배하는 보고서보다는, 누구나 쉽게 이해할 수 있게 설명하는 것이 필요하다. 물론 쉬운 설명을 위해서는 충분한 기술적인 이해가 있어야 가능하다. 실제로 인텔리전스의 소비자 입장에서 하나의 보고서를 읽는 시간은 짧을수록 좋다.
단편적인 정보가 아닌 종합적인 정보의 제공(Contextual information)
SNS을 보면 단편적인 탐지나 공격 사례에 대한 정보가 넘쳐난다. 하나의 공격 시도에 대하여 빠르게 인지하고 대응하는 것도 물론 중요하다. 하지만 최근의 공격 양상을 봤을 때 이런 1:1 대응은 공격자의 뒤를 쫓는 라떼 시절의 모습일 수밖에 없다. 아래는 구글 Threat Analysis Group(TAG)의 Shane Huntley 트윗(@ShaneHuntly)이다.
Tweet of Shane Huntley(@ShaneHuntley)Original tweet: https://twitter.com/ShaneHuntley/status/1335392704134488065
요점은 “일반적으로 매우 활발한 공격 그룹 들은 지속적으로 공격을 진행하며(마치 우리의 일일 업무처럼), 코로나 바이러스처럼 사회적으로 큰 이슈를 공격에 이용하는 것은 당연한 것이다. 이런 단편적으로 발생하는 공격에 집중하면 선입견을 갖기 쉬우며, 전체적인 큰 그림을 보기 어렵다"라는 내용이다. 전적으로 공감되는 내용이다. 10년 전에는 1:1 단위의 대응이 가능했다. 악성코드를 발견하면 빠르게 패턴에 등록하는 과정을 통하여 얼마든지 대응이 가능했지만, 아직도 이런 대응을 고수하고 있다면 현재의 Threat Landscape를 제대로 이해하지 못하고 있다고 감히 말하고 싶다. 얼마 전 “폴리매스"라는 책에서 본 구절이다. 프랑스의 철학자이자 복잡성 이론의 아버지 에드가 모랭은 이런 말을 했다.
우리는 단절되고 구분된 지식을 연결하는 사고, 통합성을 인정하면서 다양성을 존중하는 사고, 상호의존성을 꿰뚫어보는 사고가 필요하다. 우리는 (문제의 근원에 접근하는) 급진적인 사고, 다차원적 사고, 조직적 혹은 시스템적 사고가 필요하다.
추론하고 종합하고 적용하는 사유 과정을 거쳐야 비로소 정보는 지식이 된다. 단편적인 구시대적인 방식의 대응이 아닌 전체적인 그림을 볼 수 있는 내용을 포함하는 인텔리전스 보고서의 작성이 중요하다.
자세한 기술적 정보의 중요성(Importance of technical details)
인텔리전스 보고서의 큰 기능 중 하나는 자세한 기술적 정보의 전달이다. 이런 자세한 정보를 통해 공격의 본질을 정확하게 이해할 수 있으며, 어떤 식으로 방어할 수 있을지에 대한 계획을 수립할 수 있다. 가령 악성코드의 기능에 대한 자세한 분석 정보를 통해 해당 악성코드가 실행 시 시스템에 어떤 흔적이 생성되며, 추가적으로 동일한 유형의 악성코드에 감염된 시스템을 찾아낼 수 있다. 또는 악성코드가 C&C 서버와 통신 시 어떤 특징이 있는지 파악하여 네트워크 탐지 룰을 생성할 수 있다.
인텔리전스 보고서 생산자 입장에서는 가장 많은 노력과 시간이 투입되는 부분이며, 가장 많은 정성이 필요한 부분이기도 하다. 최대한 자세한 정보 제공을 통해 소비자가 해당 공격에 대하여 최대한 정확하게 이해할 수 있게 해야 한다. 가령 보안회사에서 발표한 내용 중 악성코드 기능에 대하여 “백도어 기능을 수행한다”, “악의적인 기능을 수행한다.” 등으로 ‘퉁’치는 식의 발표를 하는 경우가 있다. 이는 정확한 정보를 전달하기에는 너무 부족하다. 가령 백도어 기능이 존재한다면 어떤 기능들이 존재하는지, 예를 들어 추가 파일을 생성 한다면 어느 경로에 생성하는지, 시스템을 손상할 수 있는 기능이 존재하는지, 특정 정보를 유출한다면 어떤 정보를 목표로 하는지 등의 정보가 필요하다. 이런 정보를 바탕으로 소비자는 해당 공격의 위협성을 자체적으로 판단할 수 있으며, 대응할 수 있는 방안을 마련할 수 있게 된다.
다시 한 번 강조하지만 개인적으로 자세한 기술적 정보의 제공은 인텔리전스 생산자의 입장에서는 일종의 의무이며, 그런 기술적 능력을 갖추기 위해 본인도 더욱더 많은 노력이 필요함을 항상 느끼고 있다.
절대 “추측되는", “예상으로는" 단어 사용하지 않기(Responsible sharing)
누군가에 의해 인텔리전스가 공개적으로 발표되고 나면 미디어, SNS 등을 통하여 순식간에 전파된다. 예전보다 확실히 그 영향력이 증가되었음을 느낀다. 하지만 아직도 많은 보고서에서 “~로 추정되는(suspected)", “~로 예상되는(possibly)" 등의 단어를 많이 보게 된다. 추정이나 예측은 (의무감을 갖고) 공개되는 보고서에서 사용되는 정보가 아닌 개인적인 리서치 노트에서 사용되는 것들이다.
특히, 공격의 배후를 밝히는 어트리뷰션(attribution)과 관련된 내용에서 이런 글들을 많이 본다. “A 그룹으로 추정되는", “B 국가의 지원을 받는 그룹으로 추정되는" 등의 글들을 자주 본다. 물론 어트리뷰션이란 제한된 정보로 바탕으로 배후를 밝히는 과정이다 보니 100%라는 것은 존재하지 않는다. 하지만 최대한 많은 증거 데이터를 수집하여 최대한 자신의 가설을 뒷받침할 수 있는 내용들을 함께 제공해야 한다. 아무런 기술적인 증거 없이 개인의 경험이나 직감을 바탕으로 추정에 가까운 글을 공개한다는 것은 이 분야의 연구원에게는 너무나 책임감 없는 행동이다. 이는 “책임감 있는 공유(responsible sharing)”를 위해 항상 조심해야 하는 부분이다. 우리는 직감으로 주장하는 점성술사가 아닌 증거를 바탕으로 주장하는 엔지니어가 되어야겠다.
소비되는 인텔리전스 보고서(Actionable items)
각자 인텔리전스 보고서를 읽는 목적은 상이할 것이다. 누군가는 기술적인 정보가 필요할 것이며, 누군가는 공격의 배후가 궁금할 것이다. 또 누군가는 가십거리가 필요할 것이다. 어떤 목적이 되었든, 보고서를 읽고 난 뒤 무엇인가 소비될 수 있는 컨텐츠를 포함하는 것이 중요하다. 그 중에서도 가장 중요한 것은 대응할 수 있는(actionable) 아이템을 포함하고 있는 것이다.
최근에는 많은 보안 벤더들이 이런 정보들을 제공하기 위해 노력하고 있다. 일반적인 IOC뿐만 아니라, MITRE ATT&CK, Yara rule, Snort rule, Sigma rule 등 다양한 적용 가능한 아이템을 제공하여, 보고서를 읽고 난 뒤 실제로 우리 조직에는 그럼 위협이 존재하지 않았는지, 또는 앞으로 발생할 위협을 탐지할 수 있는 아이템들을 제공하고 있다. 이는 인텔리전스 생산자의 입장에서도 중요한 부분이다. 아무리 “공격이 진행되고 있다.”고 외치는 것보다 하나의 적용 가능한 룰을 공유하는 것이 커뮤니티의 보안성 향상에 큰 도움이 된다.
몇 가지 생각나는 요건에 대해서 두서없이 정리해 보았다. 글을 쓴다는 것, 특히 기술적인 보고서를 작성한다는 것은 경력이 더 할수록 쉽지 않은 일이며, 많은 노력과 연습이 필요한 분야인 것은 확실하다. 이 글이 같은 분야에서 같은 일로 고민을 하는 사람들에게 작게나마 도움이 되었으면 한다.
