지난 한 해 동안 생성형 AI(인공지능)가 부상하면서 다목적 대규모 언어 모델(LLM)도 대중의 관심을 받게 되었습니다. 많은 조직은 이제 LLM의 기능을 활용하여 고객 서비스, 작업 최적화, 콘텐츠 제작, 전반적인 생산성을 개선하고자 경쟁하고 있습니다.

LLM 같은 AI 기반 애플리케이션이 빠르게 성장하면서 관련 취약점의 위험도 증가하고 있습니다. 많은 조직에서 시장 선점을 목표로 삼고 있는데, 안타깝게도 이로 인해 보안의 우선순위가 뒤로 밀리곤 합니다.

그러나 다른 모든 새로운 애플리케이션처럼 이러한 애플리케이션도 관련 보안 조치를 평가해야 합니다. 기존 애플리케이션 평가 접근방식과 유사한 점도 있지만, AI 기반 애플리케이션을 전반적으로 설계, 빌드, 평가할 때 고려해야 하는 미묘한 차이점도 있습니다.

^{LLM은 광범위한 데이터 세트를 학습한 대규모 신경망입니다. LLM이 학습하는 데이터 세트의 유형에 따라 텍스트 생성, 번역, 요약, 일반적인 질의 응답 등 다양한 작업을 수행하도록 맞춤설정할 수 있습니다.}

^{대부분의 조직은 웹 기반 방식으로 LLM을 배포합니다. 따라서 고객과 사용자는 익숙한 형식(웹 애플리케이션)으로 LLM과 상호작용할 수 있으며, 개발자는 노출된 웹 애플리케이션 프로그래밍 인터페이스(API)를 사용하여 잘 정의된 방식으로 LLM을 활용할 수도 있습니다.} 

^{LLM은 범용 언어 생성을 일상적으로 수행하며, 사용자와 사용자의 맞춤형 쿼리를 '이해'하는 능력을 모방합니다. 따라서 웹 기반 LLM은 챗봇, 검색엔진, 가상 어시스턴트 등 사용자 경험 향상이라는 목표에 특히 적합합니다.}

모든 범용 웹 기반 LLM은 4가지 흥미로운 특징을 갖고 있습니다.

첫 번째는 프롬프트입니다. 프롬프트는 애플리케이션의 프런트엔드를 통해 최종 사용자가 제공하는 쿼리로, LLM과 사용자의 상호작용에 대한 컨텍스트를 설정하고 대화의 성격을 안내하는 데 도움이 됩니다. 프롬프트가 구체적일수록 LLM은 사용자 질문에 답할 때 데이터 세트를 더 잘 활용할 수 있습니다.

두 번째는 노출된 API입니다. LLM은 최종 애플리케이션에서 사용할 수 있도록 API 인터페이스를 의도적으로 노출합니다. 이러한 API를 사용하면 기존 웹 애플리케이션에서 LLM의 기능을 활용할 수 있습니다.

세 번째는 데이터입니다. 데이터는 사용자의 프롬프트에 답하는 데 필요한 정보를 모델에 제공합니다. 양과 구체성 못지않게 품질도 중요합니다. LLM이 사용자의 쿼리를 더 잘 처리하고 사용자에게 유용하면서도 정확한 답변을 도출하는 데 품질이 영향을 미치기 때문입니다.

네 번째는 학습 세트입니다. 학습 세트는 최종 목적에 적합한 모델이 되기 위해 모델이 처음 학습한 데이터입니다. 여기서도 품질이 중요합니다.

웹 애플리케이션이 지속적으로 발전하고 보편화되면서 안타깝게도 이와 관련된 취약점의 수와 유형 역시 증가하고 있습니다. OWASP(Open Web Application Security Project)에서는 공개적으로 보고된 웹 애플리케이션 취약점의 수와 유형을 집계한 후 가장 흔한 주요 취약점 10가지를 몇 년마다 발표합니다. 

비슷한 방식으로 LLM 전용 애플리케이션에 대한 새로운 OWASP 주요 10가지 취약점 목록도 게시되었습니다.

웹 기반 LLM으로 인해 사용자가 기존 시스템과 상호작용하는 방식에 혁신이 일어나면서, 이제 잘 정의되고 구조화된 쿼리가 필요 없게 되었습니다. 대신 사용자는 애플리케이션 및 시스템과 대화하듯이 더욱 자연스럽게 상호작용할 수 있으며, 인간의 호기심과 창의력이 진화함에 따라 이 기술의 적용 분야가 계속 확장되고 있습니다.

웹 기반 LLM 애플리케이션은 기존 웹 애플리케이션과 거의 동일한 방식으로 평가할 수 있습니다. 출력 인코딩, 인증 및 승인, 데이터 보호, API 보안과 같은 제어 기능은 다년간의 애플리케이션 보안 테스트 및 익스플로잇 사례를 통해 잘 정의되어 있습니다.

앞으로 보안 전문가는 애플리케이션 보안 평가 방법론을 발전시켜 확률적 테스트 전략도 포함해야 합니다. 확률적 테스트를 통합하면 웹 기반 LLM 애플리케이션 평가를 개선하고 이를 프롬프트 인젝션, 에이전트에 과도한 권한 부여, 과도한 의존으로부터 더 강력하게 보호하여 복원력이 우수한 최신 보안 접근방식을 유지할 수 있습니다.

2024년에도 보안 정보 및 이벤트 관리(SIEM) 시스템은 여전히 많은 보안 운영 센터(SOC)의 핵심 요소입니다. SIEM은 조직 전반의 보안 데이터를 수집하고 분석하여 위협을 식별 및 조사하고 대응하는 데 사용되어 왔지만, 사실 현재 사용 중인 SIEM은 15년 전에 구축된 SIEM과는 완전히 다릅니다. 최신 SIEM에는 클라우드 네이티브 아키텍처와 사용자 엔터티 행위 분석(UEBA), 보안 조정, 자동화, 대응(SOAR), 공격 표면 관리, 인공지능(AI) 등의 기능이 포함되어 있습니다.

레거시 SIEM은 대부분 느리고 번거로우며 사용하기 어렵습니다. 레거시 아키텍처 때문에 대량의 로그 소스를 수집하도록 확장하기가 어렵고, 최신 위협을 파악하거나 최신 기능과 역량을 지원하지 못하기도 합니다. 조직의 구체적인 요구사항을 지원하는 데 필요한 유연성을 제공하지 않거나, 오늘날의 조직 대부분이 채택하는 멀티 클라우드 전략에 적합하지 않을 수도 있습니다. 마지막으로, 레거시 SIEM은 AI와 같은 최신 기술 발전을 활용하기에 적합하지 않을 수 있습니다.

최근 SIEM 분야에서는 그 중요성을 간과할 수 없는 지각 변동이 일어났습니다. 이러한 발전 때문에 레거시 SIEM 플랫폼에서 최신 플랫폼으로의 마이그레이션이 앞당겨지며, 많은 조직은 마이그레이션 여부가 아닌 마이그레이션 시기를 고민하게 될 것입니다. 

지난 한 해 동안 SIEM 시장에서 일어난 주요 변화는 다음과 같습니다. 

2023년 9월:

• Cisco, Splunk 인수 의향 발표

2024년 5월:

• Crowdstrike, 새 SIEM 제품 출시
• Exabeam과 LogRhythm, 합병 의향 발표
• IBM, Qradar 클라우드 비즈니스를 Palo Alto Networks에 매각하고 Qradar 온프렘 고객을 위한 신규 개발 중단

Google Cloud Security 전문가들은 수십 년 동안 수백 건의 SIEM 마이그레이션을 관찰하고 안내해 왔으며, 이를 통해 규모와 상관없이 모든 조직에서 적용할 수 있는 권장사항에 대한 인사이트를 확보할 수 있었습니다. 2024년 SIEM 마이그레이션을 위한 주요 팁을 살펴보겠습니다.

새로운 SIEM 플랫폼을 평가할 때는 먼저 자신과 보안팀에 다음 질문을 던져 각 SIEM 옵션의 강점과 약점을 파악하고 조직의 니즈를 충족할 수 있는지 확인해야 합니다.

진화하는 위협 환경에 대응하려면 적당한 때에 레거시 SIEM을 최신 플랫폼으로 반드시 마이그레이션해야 합니다. 매우 어려운 일처럼 보이겠지만, 마이그레이션 계획을 잘 세우고 효과적으로 실행하면 조직의 위협 탐지, 조사 및 대응 역량과 전반적인 보안 상황을 크게 개선할 수 있습니다.

SIEM 마이그레이션에 관한 자세한 가이드는 '효과적인 SIEM 마이그레이션: 혁신 가이드' 전문을 확인하세요.

Google의 최신 클라우드 네이티브 SecOps 플랫폼에 대해 자세히 알아보려면 웹페이지를 방문하세요.

디지털 네이티브 환경이 증가함에 따라 이제 보안팀, 특히 레드팀과 블루팀은 이러한 새로운 생태계와 관련된 보안 과제를 반드시 이해해야 합니다. 기존 온프레미스 배포 환경과는 전혀 다른 독특한 특성이 있기 때문입니다. 어떤 독특한 과제가 있으며, 이러한 과제를 해결하려면 사이버 보안 전문가에게 어떤 기술이 필요할까요? 

공격자와 방어자는 더 이상 도메인 컨트롤러나 인증서 서비스 같은 몇몇 주요 인프라 애셋을 확보하기 위해 군비 경쟁을 벌이지 않습니다. 대신 모든 클라우드 리소스, SSO 애플리케이션, 데이터 연결이 조직에 동일한 위협 요소가 됩니다. 디지털 네이티브 아키텍처가 API, IAM, Kubernetes, Docker, 서버리스 함수, 마이크로서비스, 클라우드 데이터베이스, 스토리지, 네트워킹, CI/CD 파이프라인 또는 기타 게이트웨이와 같은 기술로 구동되면 이러한 모든 요소는 공격자가 침입할 수 있는 잠재적인 진입점이 됩니다. 철저한 보안 테스트를 수행하지 않으면 조직은 서드 파티 SaaS 애플리케이션의 보안 침해를 통해 공격자가 클라우드 환경에 무제한으로 액세스할 수 있다는 사실을 알 수 없습니다. 성숙한 디지털 네이티브 환경에서 발견되는 높은 상호 연결성 수준은 서드 파티 애플리케이션과 조직의 '핵심 요소' 간의 경계를 모호하게 만듭니다. 

디지털 네이티브 환경에서 보안팀이 직면하는 또 다른 독특한 과제는 공격 수행에 사용되는 프로토콜입니다. 디지털 네이티브 환경은 주로 직원의 웹브라우저를 통해 액세스할 수 있도록 설계된 애플리케이션과 서비스로 구성되어 있으므로, 많은 공격은 HTTP와 같은 일반적인 최종 사용자 프로토콜을 통해 조직 리소스와의 상호작용이 이루어지는 일곱 번째 계층에서 발생합니다. 따라서 보안 전문가는 이러한 환경에서 사용자의 역할을 맡아 전용 명령줄 유틸리티 대신 주로 웹브라우저를 통해 애플리케이션 및 서비스와 상호작용해야 합니다. 이러한 제한 때문에 새로운 디지털 네이티브 환경에서 적절하게 상황을 인식하는 데 필요한 수작업이 대폭 증가했습니다. 

그러나 이러한 제한의 부수적 결과로, 기존 엔드포인트 감지 및 대응(EDR) 솔루션의 효과가 크게 떨어졌습니다. 합법적인 사용자와 악의적인 사용자가 동일한 방식으로 환경과 상호작용하면, 실질적인 위협과 무해한 사용자 요청을 구별하기 위해 방어자가 해야 하는 수동 검토의 양이 대폭 증가합니다. 이러한 관점에서 보면 디지털 네이티브 환경을 보호하는 일은 SSO와 클라우드 플랫폼 신뢰 관계로 연결된 일련의 개별 웹 애플리케이션을 보호하는 일과 비슷해지고 있습니다. 

또한 기업마다 기능 수행에 필요한 애플리케이션과 서비스가 다르므로, 한 기업 환경에 대해 얻은 정보는 다른 기업 환경을 이해하는 데는 거의 도움이 되지 않습니다. 이러한 표준화 부족 때문에 보안 전문가에게 더 높은 수준의 창의성과 독창성이 요구됩니다.

Mandiant는 일선에서 관찰한 디지털 네이티브 공격자 트렌드를 레드팀 활동에 사용하는 방법론에 반영합니다. 한 사례에서는 대규모 디지털 네이티브 조직이 Mandiant와 함께 내부 관리 웹 애플리케이션에 대한 액세스 권한을 획득하는 협업 목표를 설정했습니다. 조직에서는 이 애플리케이션을 핵심 요소로 규정했습니다. 

이 핵심 애플리케이션은 최근 서드 파티 코드 감사를 받았으며, 인증을 위해 잘 알려진 SSO 제공업체를 사용했습니다. 애플리케이션 자체가 일반적인 웹 공격을 잘 받지 않는다는 사실을 알고 있었던 Mandiant 레드팀은 핵심 애플리케이션과 연결될 수 있는 동일한 환경 내 다른 SSO 애플리케이션에 대한 테스트를 우선적으로 수행했습니다. 이러한 추가 애플리케이션에는 액세스 요청 관리 플랫폼, Kubernetes 관리자, API 개발 도구가 포함되었습니다. Mandiant는 이러한 연결을 꼼꼼하게 문서화하고 각 연결에 사용할 수 있는 액세스 수준을 평가하기 시작했습니다. 

평가를 진행하면서 Mandiant는 내부 자동화 도구 개발에 사용하는 SaaS 개발 애플리케이션에 대한 관리 액세스를 허용하는 권한 에스컬레이션 벡터를 발견했습니다. 평가 시작 시점에서 이 SaaS 개발 애플리케이션은 '저위험'으로 분류되었습니다. 애플리케이션 내부의 사용자들이 여전히 SSO 제공업체를 통해 할당된 역할과 권한만 이용할 수 있었기 때문입니다. 처음에는 이 애플리케이션의 관리자가 환경 내 다른 SSO 애플리케이션에 대한 추가 액세스 권한을 얻을 수 있다는 징후가 없었습니다. 

Mandiant는 SaaS 개발 애플리케이션에 대한 관리 액세스 권한을 사용하여, 직원 다수가 매시간 해당 애플리케이션에 인증하고 하나 이상의 내부 도구를 실행하고 있음을 발견했습니다. 그 결과 레드팀은 이러한 독특한 사용자 워크플로를 이해하고, 환경 내 권한이 필요한 다른 리소스에 액세스하기 위해 이러한 워크플로의 보안을 침해하는 방법을 파악하는 방향으로 초점을 맞추게 되었습니다.

이러한 관리 관점에서 SaaS 개발 애플리케이션을 추가로 정찰한 결과, 사용자를 핵심 애플리케이션에 연결하는 데 사용되는 설정을 수정할 권한이 Mandiant에 있음이 드러났습니다. Mandiant는 이러한 권한을 사용하여 각 사용자의 SSO 인증 흐름 끝에 추가 요청을 삽입하고, 이를 통해 일반 텍스트 SSO 토큰을 Mandiant에서 제어하는 서버로 전송할 수 있었습니다. 이 새로운 구성을 저장한 후 Mandiant 레드팀은 핵심 애플리케이션의 합법적인 사용자로부터 인증 요청을 받았습니다. 이러한 요청에는 Mandiant가 요청 사용자로 가장하는 데 활용할 수 있는 사용자 인증 정보가 포함되어 있었습니다. 이 삽입을 밤새 실행한 레드팀은 높은 수준의 권한을 보유한 관리 권한 사용자의 SSO 토큰을 캡처하여 핵심 애플리케이션으로 피벗하는 데 성공했습니다.

디지털 네이티브 조직과 이러한 조직이 존재하는 클라우드 기반 환경은 끊임없이 변화하고 있습니다. 새로운 기술이 그 어느 때보다 빠르게 개발되고 구현되거나 지원 중단되고 있습니다. 이러한 조직에 있어 사이버 범죄자는 조직이 새로운 환경에 익숙해질 때까지 기다려주지 않는다는 점만은 확실합니다. 따라서 적절한 사이버 방어를 구축하려면 지속적인 사이버 방어 제어와 레드팀 구성, 특화된 클라우드 보안 전문성을 포함한 선제적 보안 조치를 반드시 적용해야 합니다.