패치 적용의 역설: 보안에서 AI의 현실

보안 블루팀 회사에서 일하는 해커의 경고

AI가 보안의 난제를 해결할 것이라는 착각은 멈춰야 합니다. 물론 AI는 도움이 될 것이고, 이미 도움이 되고 있습니다. 하지만 공격자와 방어자 모두 생성형 AI를 사용할 수 있게 되었다는 이유만으로 방어자가 공격자를 ‘따라잡을 수 있다’는 생각은 환상에 불과합니다.

저는 레드팀 관점에서 이 문제를 바라봅니다. 수년 동안 공격자처럼 사고해 왔습니다. 지금은 실제 시스템을 방어하는 블루팀 회사에서 일하고 있습니다. 그러니 분명하게 보이는 것이 있습니다.

AI는 공격자가 더 빠르게 움직일 수 있도록 하고, 방어자는 여전히 패치하지 못합니다.

이것이 바로 병목 지점이자 계획의 결함입니다. AI 지원 패치로는 수천 개의 자산과 팀, 승인 체계에 얽혀 있는 15년 된 취약한 코드베이스의 문제를 해결할 수 없습니다. 2015년에 속도 저하를 일으켰던 문제들이 여전히 남아 있으며, 이런 모든 것들이 곧 공격자의 무기로 활용될 것입니다.

레거시 기술의 부채는 AI도 해결하지 못합니다

요즘 보안 업계에는 AI를 취약점 관리에 적용하면 기본적으로 안전한 소프트웨어가 출시될 것이라는 희망 섞인 기대가 있습니다.

하지만 실제 엔터프라이즈 환경의 현실은 다음과 같습니다.

• 수명이 다한 시스템이 여전히 생산 중.
  
• OS 업데이트마다 깨지는 취약한 통합
  
• 6년간 업데이트되지 않은 펌웨어
  
• 패치가 불가능한 Windows XP로 실행되는 OT 네트워크.
  

기술의 부채를 ‘AI로 해결’할 수 없습니다.

보안이 곧 옵저버빌리티이고, 옵저버빌리티가 곧 보안입니다. 보이지 않으면 방어할 수 없고, 패치할 수 없다면 아무리 대시보드가 많아도 안전하지 않습니다.

이는 근본적으로 아키텍처 문제입니다. 특히 오래된 시스템에서 더욱 그렇습니다. 이러한 설계상의 실패는 이제 전사적 차원에서 해결해야 하며, AI는 클라우드 이전 시대에 만들어진 취약한 소프트웨어를 위한 기적 같은 핫픽스를 작성해 주지 않을 것입니다.

코드형 인프라(IaC)와 Kubernetes가 만능 해결책이 아닙니다

이제 코드형 인프라, Kubernetes, 컨테이너 같은 최신 스택에 대해 이야기해 보겠습니다. 이러한 최신 스택을 사용하면 문제를 해결할 수 것이라 기대할 수 있습니다.

어느 정도 맞는 생각입니다.

물론 IaC와 K8s는 일관되고 신속하며 안전한 패칭을 가능하게 합니다. 단, 적절한 방식으로 사용하는 경우에만 가능합니다. 그러나 현실은 어떨까요?

대부분의 조직은 그렇게 사용하지 않습니다.

2년 전 블로그 게시물에서 복사해 온 YAML을 사용하며 여전히 수동으로 구성되는 Kubernetes 클러스터가 얼마나 많은지 아시면 놀라실 겁니다. IaC 템플릿도 다른 코드와 마찬가지로 노후화되며, 그렇게 되면 또 다른 취약점이 됩니다.

• RBAC 제어 없이 생성된 클러스터.
  
• 패치되지 않은 베이스 레이어를 기반으로 한 이미지.
  
• Helm 차트 안의 시크릿.
  
• 퍼블릭 버킷에 있는 테라폼 상태 파일.
  

일시적이고 재배포 가능한 인프라를 구현할 수 있었지만, 이를 또 다른 정적 데이터 센터처럼 취급했습니다. 이렇게 문제를 해결할 기회를 놓치면 보안 문제가 일어날 수밖에 없습니다.

AI가 Kubernetes 환경 패치를 지원해주길 바란다면, 먼저 깨끗하고 버전 관리되며 체계적으로 유지되는 IaC 베이스라인이 필요합니다. 그리고 이를 실제로 사용하는 팀이 있어야 합니다. 그건 당연한 일이 아닙니다.

최신 도구가 오래된 습관의 문제를 해결해주진 않습니다. 오히려 문제가 터졌을 때 폭발 반경을 더 넓힐 뿐입니다.

팀 이탈과 함께 사라진 아키텍처

구조 조정과 팀 인력 이탈이 가속화되었다는 잔인한 사실도 잊지 말아야 합니다.

지난 몇 년 동안 팀 내 인력 이탈과 구조 조정이 뉴스 헤드라인을 장식해 왔습니다. 인력 감축, 팀 구조 개편, 팀원의 보직 이동 등으로 인해 조직은 내부 아키텍처를 제대로 이해하던 인력을 잃었습니다. 그들은 이 통합이 왜 그렇게 작동하는지 알고 있었고, 잊혀진 라이브러리에 적용된 커스텀 패치를 기억하며, 2주짜리 티켓 사이클 없이도 4개 서비스에서 중단된 인증 흐름을 추적할 수 있었습니다.

그들은 떠났습니다.

그리고 그들과 함께 조직 내 암묵지도 사라졌습니다. 이런 지식은 문서화되지 않았고, 대체할 수 없으며, Slack 스레드와 워룸, 그리고 사람들의 기억 속에만 남아 있습니다.

이제 아무도 완전히 이해하지 못하는 시스템을 패치하려 애쓰며, 이런 작업이 왜 몇 주씩 걸리는지 의아해하고 있습니다. 이건 엔지니어링의 실패가 아닌, 조직의 실패입니다.

AI로는 이 문제를 해결할 수 없습니다. 프롬프트로 조직 내 암묵지를 되살릴 수는 없습니다.

보안 업계의 조용한 타협

솔직히 말하면 우리에게도 일부 책임이 있습니다.

많은 보안 기업, 특히 대형 업체는 시스템 보안이라는 본래 임무보다 제품화와 수익을 우선시해 왔습니다. 우리는 플랫폼, 대시보드, 경고 시스템들을 구축해 왔습니다. 하지만 근본 문제인 패치와 아키텍처의 취약성은 해결되지 않았습니다. 그런 건 데모에 잘 나오지 않기 때문입니다.

‘1년에 걸쳐 기술 부채 제거에 시간을 썼습니다’라고 해 봤자 아무도 주목하지 않습니다.

‘4,000개 엔드포인트에서 패치 속도를 20% 향상했습니다’라는 모토로 RSA에 부스를 차릴 수도 없습니다.

하지만 진짜 싸움은 바로 거기서 시작됩니다.

시스템이 취약하다는 걸 아는 것과 그 취약점을 실제로 고칠 수 있는 것 사이의 간극, 이는 전쟁이며 여기에는 화려함도 없습니다.

다음과 같은 진짜 실행이 필요합니다

우리의 가장 큰 약점은 정보가 아니라 운영이라는 불편한 진실을 직시해야 합니다.

모든 것을 알고, 모든 것을 보고, 모든 것을 경고해도 패치를 제때 적용하지 못해 결국 공격에 당할 수 있습니다.

그렇다면 어떻게 해야 할까요?

1. ‘패치 불가능’이란 말부터 중단해야 합니다. 중요하지만 업데이트할 수 없는 경우 교체하거나 격리하거나 제거해야 합니다. 패치 적용 = 다운타임 = 비즈니스 리스크로 이어지는 시스템은 구축하면 안 됩니다.
   
2. 도구 개선보다 조직 개선이 먼저입니다. 보안, 운영, 개발, 컴플라이언스 팀 간의 사일로가 대응 속도를 느려지게 합니다. AI도 이를 해결해 주지 못합니다. 소통만이 답입니다.
   
3. 기본적으로 안전한 소프트웨어가 필요합니다. 벤더에 패치 가능하고 자동 업데이트되는 모듈형 컴포넌트를 공급하라고 압박해야 합니다. 더 이상 변명을 받아주면 안 됩니다.
   
4. 실제 필요한 부분을 자동화해야 합니다. 대시보드를 늘리기보다 패치 검증, 롤아웃, 재부팅을 자동화해야 합니다.AI로 셸 스크립트를 작성한다면 패치 가능한 스크립트로 작성해야 합니다.
   
5. 실패를 염두에 두고 시스템을 설계해야 합니다. 패치 적용도 지연된다고 전제해야 합니다. 격리, 세분화, 롤백 기능이 아키텍처에 내장되도록 합니다.
   
6. 통제를 늘리는 팀보다 위험을 줄이는 팀을 보상해야 합니다. 조용한 10,000개의 엔드포인트 패치가 새롭고 화려한 AI 기능보다 훨씬 큰 승리입니다.
   

결론

공격자는 언제나 속도 면에서 우위에 있었습니다. AI는 그 격차를 더 벌려놓았습니다. 방어자가 여전히 변경 관리를 위해 패치에 전념하는 동안 공격자는 실시간으로 다형성 익스플로잇을 생성하고 있습니다.

이는 도구의 문제가 아닙니다. 위협 인텔리전스의 문제도 아닙니다. 이 문제는 보안의 가장 오래된 문제, 즉 문제를 발견한 뒤 그것을 실제로 고치는 방법을 해결하지 못한다는 데 있습니다.

AI 시대에서 살아남고 싶다면 패치를 운영의 부담이 아닌 전략적 우선순위로 다뤄야 합니다. 그리고 지금 당장 그렇게 해야 합니다.

공격자는 기다려주지 않습니다. 단 한 번도 기다린 적이 없습니다.

그렇다면 실제로 무엇을 해야 할까요? 첫째는 효과적인 보안 프로그램을 구축하고 좋은 로깅 체계를 갖추며 Sumo Logic 같은 Cloud SIEM 솔루션을 도입하는 것입니다. 하지만 이 문제를 진짜로 해결하려면 많은 인재들이 문제 해결에 뛰어들어 커뮤니티에 도움이 되어야 합니다. 다른 블로그를 통해서도 여러 답을 이야기하도록 하겠습니다.