에스코어 인사이트
원문에 앞서 국내 개발·보안 조직이 함께 점검할 만한 사항을 간단히 정리했습니다.
•
AI 에이전트 자산 관리: 현재 운영 중인 에이전트와 외부 노출 범위를 인벤토리화하고, EASM(External Attack Surface Management) 관점에서 접근 가능한 시스템과 데이터 범위를 함께 점검합니다.
•
권한 최소화: 외부에 노출된 AI 에이전트가 사용할 수 있는 도구, 명령, 데이터와 민감 시스템 접근 권한을 실제 업무에 필요한 최소 범위로 제한합니다.
•
결정론적 통제 적용: 민감 시스템 접근이 필요한 경우 프롬프트나 LLM 판단과 별개로 정책 기반의 결정론적 차단·승인 계층을 두어, 에이전트가 속더라도 허용되지 않은 작업을 수행할 수 없게 합니다.
지난주는 제가 Black Hat에 참석한 두 번째 기회였습니다. 첫 참석은 10년도 더 전이었는데, 그동안 행사가 확실히 커졌습니다. 브리핑과 특히 키노트의 완성도는 놀라웠고, 벤더 공간은 더 크고 화려해졌으며, 참가자도 훨씬 많아져 말 그대로 북적였습니다. 세계적인 주요 보안 컨퍼런스 중 하나라는 점을 생각하면 당연한 변화이기도 합니다.
지난번 참석했을 때의 화두는 IoT였습니다. 올해는 예상했듯 제가 들은 거의 모든 키노트, 브리핑, 대화에서 AI가 언급됐습니다. 올해 행사에서 제가 반복적으로 관찰한 주요 화두는 다음과 같습니다.
CVSS가 제대로 작동하지 않는다
Mythos가 공개를 앞둔 수천 개의 취약점을 찾아내고 있다는 이야기가 퍼지고 있습니다. 그런 이야기를 제외하더라도 Sonatype이 올해 등록하게 될 취약점 수는 지난해의 두 배 수준으로 늘어날 것으로 보고 있습니다. 그 결과 거대한 의존성 체인을 가진 수많은 모놀리식 애플리케이션을 보호해야 하는 보안팀과 개발팀에는 취약점 우선순위 지정이 큰 과제로 떠올랐습니다.
전통적인 방식은 CVSS 점수를 기준으로 취약점의 우선순위를 정하고, 점수가 높음 또는 심각 범주에 해당하는 취약점의 조치에 집중하는 것입니다. 저는 이 전략에 대해 두 가지 주요 비판을 들었습니다.
첫 번째는 점수 자체의 성격입니다. 우리가 흔히 사용하는 CVSS-B는 취약점이 제기하는 구체적인 위협이나 실제 위험이 아니라 취약점의 심각도를 측정합니다. CVSS를 관리하는 FIRST도 이를 알고 있기 때문에 보완적인 threat와 environment 메트릭을 제공합니다. 이들을 CVSS-BTE로 함께 사용하면 실제 위험과 더 높은 상관관계를 보이지만, 추가 메트릭에도 나름의 문제가 있습니다.
익스플로잇 성숙도를 측정하는 위협 메트릭은 계속 변하는 대상입니다. 오늘 익스플로잇이 없다고 해서 내일도 없다는 뜻은 아닙니다. 또한 확인한 정보의 정확성에 최대한 확신을 가지려면 다크웹에서 익스플로잇을 찾아낼 수 있는 일정 수준의 위협 인텔리전스 역량이 필요하지만, 이는 대부분의 조직이 갖추기 어려운 능력입니다.
“익스플로잇 성숙도를 측정하는 위협 메트릭은 계속 변합니다. 오늘 익스플로잇이 없다고 해서 내일도 없다는 뜻은 아닙니다.”
우리가 살고 있는 AI의 새로운 세계에서는 이 문제 자체가 의미를 잃을 가능성도 있습니다. AI에게 취약점용 익스플로잇을 만들게 하는 일이 거의 사소한 수준이 됐기 때문입니다. 물론 많은 AI가 이를 거부하겠지만, 로컬에서 직접 AI를 실행하거나 AI를 설득해 실행하게 만드는 식으로 쉽게 우회할 수 있습니다. 이 부분은 뒤에서 다시 다루겠습니다. 반면 환경 메트릭은 각자의 환경에 매우 특화돼 있으므로 인터넷에서 찾아서 적용할 수 있는 정보가 아닙니다.
제 경험상, 그리고 행사에서 많은 사람이 이야기하는 방식을 봤을 때 결과적으로 모두가 CVSS-B를 사실상 위험도와 동일시하고 있습니다. 그래서 CVSS-B 점수를 직접 산정해 본 사람이라면 기술적으로는 올바른 메트릭 조합을 선택했는데도, 점수만 직접 정할 수 있었다면 부여했을 값보다 훨씬 높은 결과가 나오는 딜레마에 공감할 것입니다.
Black Hat에서 이 문제를 처음 언급한 사람은 첫날 CISA의 Acting Director Nick Andersen이 포함된 패널에 있었습니다. 그는 점수를 매기는 접근 자체가 이미 한계에 도달했을 수 있으며, 방어자가 가장 중요하게 보는 속성에 따라 행동할 수 있는 속성 기반 시스템으로 바꿀 수 있다고 제안했습니다.
이 문제는 여러 패널에서 언급됐지만, 제게 결정적인 순간은 행사장에서 Jeremiah Grossman과 Robert “RSNAKE” Hansen을 만났을 때였습니다. 두 사람은 취약점 우선순위 문제를 다룬 책을 직접 썼고, 그 책 The End of Guessing에서는 특히 CVSS만으로 우선순위를 정하는 것이 바람직하지 않다고 설명합니다.
AI는 역량 증폭기다
연구자들이 AI를 이용해 새로운 취약점을 찾아낸 사례를 다룬 발표가 여러 개 있었고, 그 대표적인 사례가 목요일 아침 Yan Shoshitaishivili의 키노트였습니다. 이 발표들에는 공통점이 하나 있었습니다. 연구자가 수작업으로 했을 과정을 모방해 직접 만든 워크플로를 통해 AI의 행동을 매우 구체적으로 지시했다는 점입니다.
발표할 만한 의미 있는 결과를 얻은 연구자 가운데 AI Agent를 어떤 대상에 그냥 연결하고 “취약점과 익스플로잇을 찾아라”라고 지시한 사람은 없었습니다. AI는 본질적으로 역량 증폭기 역할을 했고, 연구자들이 합리적인 시간 안에 조사할 수 있는 범위를 크게 확장했습니다.
그렇다고 수작업과 정확히 1대1로 대응하는 것도 아니었습니다. 제가 들은 거의 모든 사례에서 연구자들은 처음에 AI가 AI답게 만들어낸 터무니없는 오탐을 많이 받았습니다. 그 때문에 AI 에이전트 특유의 이상한 동작을 처리하도록 워크플로를 조정해야 했습니다.
제가 가장 마음에 들었던 우회 방법은 Jamie Kettle의 발표에서 나왔습니다. 그의 AI는 실제 취약점이 아닌 특정 오탐 결과에 집착하며 그것이 유효한 취약점이라고 확신했습니다. 결국 그는 에이전트가 잘못된 결과에 매달리지 않고 다음 단계로 넘어가도록, AI가 받아들일 만한 가짜 데이터인 일종의 placebo를 제공해야 했습니다. AI로 얻는 결과가 놀라울 수는 있지만, 그런 결과를 얻는 과정 자체가 간단한 것은 아닙니다.
AI는 내부자 위협이다
브리핑과 워크숍 전반에서 프롬프트 인젝션에 대한 이야기가 많았습니다. Arsenal Labs의 한 워크숍에서는 프롬프트 인젝션 방법을 설명하면서 일부 컴퓨터에 프롬프트 인젝션 CTF를 구성해 뒀습니다. 저는 누군가 포기하고 자리를 떠난 컴퓨터 앞에 갔고, 제가 해야 할 일은 모델이 알고 있는 정보를 탐색해 어떤 AI 모델을 사용하는지 알아낸 뒤 그 모델 이름을 플래그로 제출하는 것이었습니다.
중간에 참여했기 때문에 무슨 상황인지 완전히 이해하지 못한 채, AI에게 각 행의 첫 글자가 제가 찾아야 할 비밀 플래그가 되도록 두문자시(acrostic poem)를 만들어 달라고 했습니다. 그러자 정말로 모델 이름이 한 글자씩 나타났습니다.
또 다른 때에는 다른 참가자들이 무엇을 하는지 지켜보고 있었습니다. 강사가 한 참가자에게 도움이 필요한지 물으러 왔을 때 강사의 표정에 놀람이 스치는 것을 봤습니다. 원래 여러 번의 프롬프트가 필요하도록 설계된 단계였는데, 그 참가자는 단 한 번의 프롬프트로 이미 에이전트에서 플래그를 꺼낸 상태였습니다.
이런 프롬프트 장난은 CTF에만 국한되지 않았습니다. 특히 Rein Security 연구진의 한 발표에서는 한 식료품 체인의 AI 채팅 어시스턴트를 설득해 서버 침해를 돕게 만든 사례를 다뤘습니다. 해당 기업은 사용자 프롬프트를 평가하고 의도에 따라 분류하는 또 다른 guardian AI를 두어 프롬프트 인젝션으로부터 AI를 보호하려고 했습니다.
하지만 연구진은 요청을 교묘하게 난독화해 guardian이 요청을 어떻게 분류해야 할지 확신하지 못하도록 만들었습니다. guardian은 요청을 통과시켰지만, 동시에 실제 채팅 AI 어시스턴트는 그 정도 난독화 속에서도 사용자의 의도를 알아챌 수 있었습니다.
그런데 실제로는 guardian이 사용자가 상품을 검색하고 있다고 믿게 만드는 편이 훨씬 쉬운 우회 방법이었습니다. 그러면 프롬프트 일부가 별도의 검색 필드에 나타났고, 이 필드는 전혀 평가되지 않은 채 그대로 채팅 AI 어시스턴트의 컨텍스트로 전달됐습니다. 결국 식료품점의 채팅 AI 어시스턴트는 해당 기업 서버에서 임의의 Python 코드를 실행하게 됐습니다.
내부자 위협이라고 하면 흔히 복수를 노리는 불만 많은 직원이나, 몰래 기업 스파이 활동을 벌이는 악의적인 계약직을 떠올립니다. 하지만 행사에서 한 발표자는 내부자 위협이 반드시 적극적으로 악의를 가진 사람만을 의미하는 것은 아니며, 조직 안에서 쉽게 타락하거나 조종될 수 있는 존재도 포함한다고 지적했습니다. 안타깝게도 앞선 사례가 보여주듯, AI Agent는 바로 그런 “쉽게 조종될 수 있는” 존재입니다.
AI Agent는 해커를 대신해 행동하도록 설득될 수 있는 내부자 위협이 됩니다. 더 나쁜 점은 다음 주제에서 더 설명하겠지만 AI 에이전트에 사실상 무제한에 가까운 접근 권한이 부여되는 경우가 많다는 것입니다. 이런 점 때문에 내부자 AI 위협은 실제로 매우 위험합니다.
“안타깝게도 이러한 사례가 보여주듯 AI Agent는 쉽게 조종될 수 있습니다. 해커를 대신해 행동하도록 설득될 수 있는 내부자 위협이 되는 것입니다.”
이 모든 문제는 AI Agent가 비결정론적 LLM에 의존한다는 특성에서 비롯됩니다. 올해 Black Hat에서 얻은 가장 큰 인상 중 하나는 아무리 프롬프트를 정교하게 만들고 AI 에이전트 컨텍스트 가드를 적용하더라도, 누군가 AI를 설득해 해서는 안 될 일을 하게 만드는 위험에서 완전히 안전해질 수는 없다는 점입니다. 그렇다면 외부에 공개된 AI 에이전트가 접근할 수 있는 모든 것을 그 자체로 외부에 공개된 것처럼 취급해야 할까요? 어쩌면 그래야 할지도 모릅니다.
Black Hat의 절반쯤 되는 벤더는 물론 자신들이 판매하는 서비스를 구매한다는 조건으로 그 질문에 “아니다”라고 답할 것처럼 보였습니다. 그 주장이 실제로 어떻게 될지는 시간이 지나야 알 수 있을 것입니다.
보안의 기본으로 돌아가야 한다
AI는 새로운 기술입니다. 겉보기에는 단순해 보이지만 실제로는 매우 복잡하고, 기존 코드만으로는 어려웠던 많은 일을 할 수 있으며, 답변에 필요한 충분한 컨텍스트가 없으면 환각하기도 합니다. 이 새로운 기술을 최대한 활용하려는 과정에서 많은 조직이 AI 에이전트에 가능한 한 많은 접근 권한을 주고 있으며, 사실상 일반 직원과 비슷한 수준의 권한을 부여하고 있습니다. 이유는 이해하기 쉽습니다. 사람이 하듯 도구와 명령을 실행할 수 있게 하면 AI 에이전트가 훨씬 강력해지기 때문입니다.
정확한 답변에 필요한 컨텍스트를 제공할 데이터에 접근할 수 있으면 사실을 지어낼 가능성도 줄어듭니다. 그리고 다른 많은 신기술과 마찬가지로 아직 모두가 합의한 보안 모범 사례가 정립되지 않았기 때문에, 주변의 보호 장치도 제각각이고 일관되지 않게 적용되는 경우가 많습니다.
행사 초반의 “AI and the Future of Cyber Defense Panel”에서는 이후 계속 반복해서 등장한 한 가지 주제를 제기했습니다. 바로 보안의 기본으로 돌아가야 한다는 것입니다. AI 에이전트를 보호하기 위한 복잡한 솔루션을 판매하는 벤더는 많았지만, AI 에이전트가 일으키는 문제의 상당수는 최소 권한, 피해 범위 제한, 적절한 ID 관리 등 기본 보안 원칙만 엄격히 지켜도 크게 줄일 수 있습니다.
예를 들어 사람들이 상품을 찾도록 돕기 위한 식료품 체인의 AI 챗봇이 임의의 Python 코드를 실행할 권한까지 가져야 할까요? 저는 그럴 필요가 없다고 봅니다.
이 밖에도 반복적으로 등장한 여러 흐름이 있었지만, 제가 Black Hat에서 계속해서 다시 들었던 주요 화두는 이 정도였습니다. AI와 그 활용 방식은 여전히 빠르게 발전하고 있으며, 올바른 사람이 사용하면 놀라울 정도로 강력할 수 있지만 잘못된 사람이 사용하면 엄청난 파괴력을 가질 수도 있습니다. 제가 방어해야 할 조직을 맡고 있다면 Black Hat 참석 후 즉시 다음 세 가지를 실행할 것입니다.
1.
실행 중인 에이전트를 인벤토리화하되, 특히 EASM(External Attack Surface Management)에 중점을 둡니다.
2.
외부에 공개된 에이전트가 수행할 수 있는 일을 꼭 필요한 최소 범위로 제한합니다.
3.
민감한 시스템에 접근해야 한다면, 속은 에이전트가 해서는 안 될 일을 수행하지 못하도록 막는 결정론적 통제 메커니즘을 반드시 둡니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide