보안 블루팀 회사에서 일하는 해커의 경고
AI가 보안의 난제를 해결할 것이라는 착각은 멈춰야 합니다. 물론 도움이 될 것입니다. 이미 도움이 되고 있습니다. 하지만 공격자와 방어자 모두 생성형 AI를 사용할 수 있게 되었다는 이유만으로 방어자가 공격자를 ‘따라잡을 수 있다’는 생각은 환상에 불과합니다.
저는 레드팀 관점에서 이 문제를 바라봅니다. 수년 동안 공격자처럼 사고해 왔습니다. 지금은 실제 시스템을 방어하는 블루팀 회사에서 일하고 있습니다. 그러니 분명하게 보이는 것이 있습니다.
AI는 공격자를 더 빠르게 만들고, 방어자는 여전히 패치하지 못합니다.
이것이 바로 병목이고, 전체 계획의 결함입니다. AI 지원 패치라고 해도 수천 가지 자산·팀·승인 체계의 규제를 받는 15년 된 취약한 코드베이스를 구원해 주지 못합니다. 2015년에 속도를 느리게 만들었던 모든 문제가 여전히 남아 있습니다. 이런 모든 것들이 곧 공격자의 무기로 활용될 것입니다.
Respond faster with Sumo Logic Dojo AI
Cut through the noise, detect threats faster, and resolve issues before they disrupt your operations.
레거시 기술의 부채는 AI도 해결하지 못합니다
요즘 보안 업계에는 AI를 취약점 관리에 적용하면 기본적으로 안전한 소프트웨어가 출시될 것이라는 희망 섞인 기대가 있습니다.
하지만 실제 엔터프라이즈 환경의 현실은 다음과 같습니다.
- 수명이 다한 시스템이 여전히 생산 중.
- OS 업데이트마다 깨지는 취약한 통합
- 6년간 업데이트되지 않은 펌웨어
- 패치가 불가능한 Windows XP로 실행되는 OT 네트워크.
기술의 부채를 ‘AI로 해결’할 수 없습니다.
보안은 옵저버빌리티이고, 옵저버빌리티는 보안입니다. 보이지 않으면 방어할 수 없는 것입니다. 그리고 패치할 수 없다면 아무리 많은 대시보드가 있어도 안전하지 않습니다.
이는 근본적으로 아키텍처 문제입니다. 특히 오래된 시스템에서 더욱 그렇습니다. 이러한 설계상의 실패는 이제 대규모로 되돌려야 합니다. 물론 AI가 프리 클라우드 시대에 만들어진 취약한 소프트웨어를 위해 기적의 핫픽스를 작성해 줄 일은 없습니다.
코드형 인프라(IaC)와 Kubernetes가 만능 해결책이 아닙니다
이제 코드형 인프라, Kubernetes, 컨테이너 같은 현대 스택에 대해 이야기해 보겠습니다. 여기부터 제대로 해야 한다고 생각할 수 있습니다.
절반 정도는 맞는 생각입니다.
물론 IaC와 K8s를 사용할 때 일관되고 빠르며 안전한 패치가 될 가능성이 큽니다. 하지만 그렇게 사용하는 경우에만 가능합니다. 현실은 어떨까요?
대부분의 조직은 그렇게 사용하지 않습니다.
몇 년 전 블로그 게시물에서 복사해 온 YAML을 사용하며 여전히 수동으로 구성되는 Kubernetes 클러스터가 얼마나 많은지 알고 계시면 놀랄 것입니다. IaC 템플릿도 다른 코드와 마찬가지로 부패하며 부패하면 또 다른 문제가 됩니다.
- RBAC 제어 없이 생성된 클러스터.
- 패치되지 않은 베이스 레이어를 기반으로 한 이미지.
- Helm 차트 안의 시크릿.
- 퍼블릭 버킷에 있는 테라폼 상태 파일.
등이 그 예입니다. 일시적이고 재배포 가능한 인프라를 마치 정적 데이터센터처럼 취급하기도 했습니다. 기회의 상실은 필연적으로 보안 재앙을 초래합니다.
AI가 Kubernetes 환경 패치를 도와주기를 원한다면 먼저 깨끗하고 버전 관리되며 잘 유지되는 IaC 베이스라인이 필요합니다. 그리고 이를 실제로 사용하는 팀이 필요합니다. 그건 당연한 일이 아닙니다.
최신 도구라고 해서 오래된 습관이 변할 리가 없습니다. 오히려 문제가 터졌을 때 피해 범위가 더 확장될 뿐입니다.
팀 이탈과 함께 사라진 아키텍처
지식 최근 몇 년간 조직의 구조조정과 이직이 가속화됐습니다.
지난 2~3년 동안 팀 이탈과 해고가 뉴스의 주요 헤드라인이었습니다. 인력 감축, 팀 구조 변경 혹은 구성원의 이직 등으로 조직은 내부 아키텍처를 실제로 이해하던 사람들을 잃었습니다. 그들은 왜 이 통합이 이렇게 동작하는지 알고 있던 사람들이었고, 잊혀진 라이브러리에 커스텀 패치를 적용했던 걸 기억하던 사람들이었으며, 2주짜리 티켓 사이클 없이도 4개 서비스에 발생한 인증 흐름의 문제점을 바로 추적할 수 있었던 사람들입니다.
그들은 이제 없습니다.
그리고 그들의 지식과 노하우 역시 함께 사라졌습니다. 문서로 남겨지지도 않았습니다. 핵심 지식과 노하우였는데도 말입니다. 그러한 노하우는 슬랙의 스레드와 워룸, 그리고 인간의 기억 속에만 있었던 것입니다.
이제 아무도 전체적으로 이해하지 못하는 시스템을 패치하려 하고 이런 작업이 왜 몇 주씩 걸리는지 의아해하는 상황입니다. 이건 엔지니어링의 실패가 아닙니다. 조직 차원의 문제입니다.
AI는 이 문제를 해결하지 못합니다. 프롬프트 몇 줄로 조직 차원의 기억을 되살릴 수는 없는 것입니다.
보안 업계의 조용한 타협
솔직히 말하면 우리에게도 일부 책임이 있습니다.
많은 보안 기업, 특히 대형 업체는 실제 시스템을 안전하게 만드는 본래의 임무보다 제품화와 수익을 우선시해 왔습니다. 플랫폼도 구축하고 대시보드, 알림도 만들었습니다. 하지만 근본 문제, 패치와 아키텍처의 취약함은 해결되지 않았습니다. 그런 건 데모에 잘 나오지 않기 때문입니다.
‘1년에 걸쳐 기술 부채 제거에 시간을 썼습니다’라고 해 봤자 아무도 주목하지 않습니다.
‘4,000개 엔드포인트에서 패치 속도를 20% 향상했습니다’라는 모토로 RSA에 부스를 차릴 수도 없습니다.
하지만 진짜 싸움은 바로 거기서 시작됩니다.
시스템이 취약하다는 걸 아는 것과 그 취약점을 실제로 고칠 수 있는 것 사이의 간극, 이는 전쟁이며 여기에는 화려함도 없습니다.
다음과 같은 진짜 실행이 필요합니다
우리의 가장 큰 약점은 정보가 아니라 운영이라는 불편한 진실을 직시해야 합니다.
모든 것을 알고, 모든 것을 보고, 모든 것을 경고해도 패치를 제때 적용하지 못해 결국 공격에 당할 수 있습니다.
그렇다면 어떻게 해야 할까요?
- ‘패치 불가능’이란 말부터 중단해야 합니다. 중요한데 업데이트가 불가능하다면 교체하거나 격리하거나 제거해야 합니다. 패치 적용 = 다운타임 = 비즈니스 리스크로 이어지는 시스템은 구축하면 안 됩니다.
- 도구 개선보다 조직 개선이 먼저입니다. 보안, 운영, 개발, 컴플라이언스 팀 간의 사일로가 대응 속도를 느려지게 합니다. AI도 이를 해결해 주지 못합니다. 소통만이 답입니다.
- 기본적으로 안전한 소프트웨어가 필요합니다. 벤더에게 패치 가능하고 자동 업데이트되는 모듈형 컴포넌트를 공급하라고 압박해야 합니다. 더 이상 변명을 받아주면 안 됩니다.
- 실제 필요한 곳을 자동화해야 합니다. 대시보드를 늘리기보다 패치 검증, 롤아웃, 재부팅을 자동화해야 합니다. AI로 셸 스크립트를 작성한다면 패치 가능한 스크립트로 작성해야 합니다.
- 실패를 염두에 두고 시스템을 설계해야 합니다. 패치 적용도 지연된다고 전제해야 합니다. 격리, 세분화, 롤백 기능이 아키텍처에 내장되도록 합니다.
- 통제를 늘리는 팀보다 위험을 줄이는 팀을 보상해야 합니다. 조용한 10,000개의 엔드포인트 패치가 새롭고 화려한 AI 기능보다 훨씬 큰 승리입니다.
결론
공격자는 언제나 속도 면에서 우위에 있었습니다. AI는 그 격차를 더 벌려놓았습니다. 방어자가 여전히 변경 관리를 위해 패치에 전념하는 동안 공격자는 실시간으로 다형성 익스플로잇을 생성하고 있습니다.
이는 도구의 문제가 아닙니다. 위협 인텔리전스의 문제도 아닙니다. 이 문제는 보안의 가장 오래된 문제, 즉 문제를 발견한 뒤 그것을 실제로 고치는 방법을 해결하지 못한다는 데 있습니다.
AI 시대를 살아남고 싶다면 패치를 운영의 부담이 아닌 전략적 우선순위로 다뤄야 합니다. 그리고 지금 당장 그렇게 해야 합니다.
공격자는 기다려주지 않습니다. 단 한 번도 기다린 적이 없습니다.
그렇다면 실제로 무엇을 해야 할까요? 첫째는 효과적인 보안 프로그램을 구축하고 좋은 로깅 체계를 갖추며 Sumo Logic 같은 클라우드 SIEM 솔루션을 도입하는 것입니다. 하지만 이 문제를 진짜로 해결하려면 많은 인재들이 문제 해결에 뛰어들어 커뮤니티에 도움이 되어야 합니다. 다른 블로그를 통해서도 여러 답을 이야기하도록 하겠습니다.
