[STCON 2024] OWASP Top 10 for LLMs 및 대응 방안

 

STCON 2024 DAY 2

부서명에 S.C.P를 넣었는데 짤렸다 ㅠㅠ

10월 25일에 STCON 2024 컨퍼런스의 DAY 2를 들으러 갔다왔다.

그 중, AWS 신은수 수석님의 OWASP Top 10 for LLM 및 대응 방안에 대한 발표가 인상깊어 한 번 정리를 해보려 한다.

 

 

🐝 OWASP Top 10 for LLMs

OWASP Top 10 for LLMs는 대규모 언어 모델(LLM) 애플리케이션에서 발생할 수 있는 주요 보안 취약점을 정리한 목록이다.

OWASP Top 10 for LLM Applications V E R S I O N 1 . 1

 

1️⃣ LLM01: 프롬프트 삽입(Prompt Injection)

교묘한 입력을 통해 LLM을 조작해 예기치 않은 행동을 유도하는 공격이다.

LLM은 Nondeterministic(답변이 항상 일관적이지 않음) 하기 때문에 프롬프트 인젝션이 발생하는 것이다.

 

쉽게 말해, 모델이 가지고 있는 데이터를 악의적으로 사용하기 위해 프롬프트 삽입 공격이 이용된다.

 

이 공격 방식은 직접(Direct) / 간접(Indirect)으로 나뉜다.

• 직접적인 프롬프트 인젝션(Direct Prompt Injection)
  • 시스템 프롬프트를 덮어쓰거나 노출시키는 것
  • 흔히 탈옥, jailbreaking 방식이 직접 프롬프트 인젝션임
• 간접적인 프롬프트 인젝션(Indirect Prompt Injection)
  • 외부 소스에 숨겨진 프롬프트 인젝션으로 인해 대화의 흐름을 조작하는 것
  • 공격자가 파일 등에 프롬프트 인젝션을 숨겨둘 수 있음
  • 예를 들어 AI가 이력서를 검토할 때, 사람 눈에는 보이지 않는 흰 글자로 프롬프트를 작성해 숨겨놓는다면 이는 간접 프롬프트 인젝션이 될 수 있음

🛡️ 대응 방안

• 권한을 제한하기: LLM이 할 수 있는 일을 제한하고, 각 사용자 역할에 맞는 권한을 부여
• 사용자 확인: 중요한 작업을 수행할 경우, 사용자 승인 절차를 거쳐야 함
• 컨텐츠 분리: 신뢰할 수 없는 컨텐츠와 사용자 프롬프트를 따로 처리하여 모델에 직접 영향을 주지 않도록 처리

→ 입력에 대한 꾸준한 검증이 요구됨

 

2️⃣ LLM02: 안전하지 않은 출력 핸들링(Insecure Output Handling)

LLM의 출력을 제대로 검토하지 않고 그대로 받아들일 때 발생하는 취약점이다.

예를 들어, XSS를 유발하는 코드를 생성하거나, LLM의 출력이 시스템 쉘에서 실행되어 악성 코드가 실행될 수 있다.

🛡️ 대응 방안

• Zero-Trust 접근법: LLM의 출력을 신뢰하지 않을 것
• 출력 인코딩: LLM의 출력을 자바스크립트나 Markdown에서 코드로 실행되지 않도록 인코딩

→ 출력에 대한 값도 적절하게 검증해야 함

 

3️⃣ LLM03: 훈련 데이터 오염(Training Data Poisoning)

중독 공격(poisoning)이라고도 하며, 사전 훈련 데이터(pre-training data) 또는 미세 조정(fine-tuning) 또는 임베딩 프로세스와 관련된 데이터를 조작하여 취약점. 백도어 또는 편향을 추가하는 것을 의미한다.

이로인해 데이터 셋이 손상되면 모델의 보안, 성능, 윤리적 행동이 손상될 수 있다.

 

쉽게 말해, 모델이 사용하는 데이터를 공격하는 것이라고 할 수 있다.

🛡️ 대응 방안

• 공급망 확인: 외부 데이터 소스가 신뢰할 수 있는지 확인
• 데이터 정당성 검증: 학습 과정 전체에서 데이터가 올바르고 신뢰할 수 있는지 확인
• 용도별 모델 학습: 용도에 맞는 모델을 따로 만들어 사용

→ 학습 데이터에 대한 보안 강화가 중요함

 

4️⃣ LLM04: 모델 서비스 거부 공격(Model Denial of Service)

공격자가 LLM을 사용할 때 많은 리소스를 사용하게 하여 서비스 성능 저하 또는 높은 비용을 초래하는 공격이다.

많은 자원을 소모하는 LLM의 특성과 사용자 입력을 예측 할 수 없으므로 취약성이 확대된다.

 

단순히 모델에게 많은 질의를 하는 것이라고 이해해도 좋다.

🛡️ 대응 방안

• 입력 검증: 입력값을 검토하고 컨텐츠를 필터링
• 리소스 제한: 요청당 사용할 수 있는 리소스를 제한
• API 요청 제한: 사용자나 IP 주소당 요청 횟수를 제한
• 인터넷에 노출된 애플리케이션에 대한 DDoS 방어 서비스 이용

 

5️⃣ LLM05: 공급망 취약점(Model Denial of Service)

LLM의 학습 데이터, ML 모델, 배포 플랫폼을 손상시켜 편향된 결과를 초래하거나 보안 침해, 시스템 오류를 발생시킬 수 있는 위험이다.

취약한 소프트웨어나 사전 학습 모델, 오염된 학습 데이터, 안전하지 않은 플러그인 사용 등에서 비롯될 수 있다.

🛡️ 대응 방안

• 공급업체 평가: 신뢰할 수 있는 공급업체인지 정책과 함께 확인
• 플러그인 테스트: 검증된 안전한 플러그인 사용
• 사용 자산 최신화: 소프트웨어와 모델을 항상 최신 상태로 유지

→ 꾸준한 취약점 관리, 위협 관리가 필요함

6️⃣ LLM06: 민감 정보 유출(Sensitive Information Disclosure)

LLM 애플리케이션이 의도치 않게 민감 정보, 독점 알고리즘, 기밀 데이터를 공개하여 무단 접근, 지적 재산권 침해, 개인정보 유출 등의 위험을 초래하는 것이다.

참고로, LLM은 블랙박스로 작동하기 때문에 이미 학습한 내용은 지우기가 불가능하다.

🛡️ 대응 방안

• 입력 검증: 악의적인 입력을 필터링해 모델 오염을 방지
• 모델 학습 주의: 모델 학습 중 민감한 정보 사용 금지
• 데이터 접근 제어: 데이터의 중요도나 민감도에 따라 접근 권한을 최소화

 

7️⃣ LLM07: 안전하지 않은 플러그인 디자인(Insecure Plugin Design)

플러그인이 악의적인 요청에 취약하여 데이터 유출, 원격 코드 실행, 권한 상승 등의 피해를 초래할 수 있는 상태를 의미한다.

이는 접근 제어가 부적절하게 구성되었거나, 입력 검증이 미흡할 때 발생할 수 있다.

🛡️ 대응 방안

• 엄격한 파라미터 검증: 파라미터 입력을 엄격히 적용하고, 입력에 대한 검증 및 정제를 수행
• 최소 권한 접근 제어: 안전하지 않은 입력에 대한 악용을 최소화
• 적절한 인증 사용

 

7️⃣ LLM08: 과도한 권한(Excessive Agency)

LLM이 과도한 기능이나 권한을 부여받아 예기치 않은 출력에 따라 위험한 행동울 수행할 수 있는 취약점이다.

이는 프롬프트 인젝션, 악성 플러그인, 환각 현상(hallucination) 등에 의해 발생할 수 있다.

🛡️ 대응 방안

• 권한 제어: 필요한 최소한의 권한만 부여
• 사용자 인증: LLM의 작업 수행이 현재 사용자에 맞게 이루어지도록 보장
• 사용자 승인: 작업에 대해 인간의 승인을 요구
• 세분화된 기능 사용: 필요한 작업만 할 수 있도록 특정한 플러그인만 사용

 

9️⃣ LLM09: 과도한 의존(Overreliance)

LLM이 제공한 정보를 과도하게 신뢰할 때 발생하는 문제이다.

환각(hallucination)으로 인해 사실과 다른 내용을 출력할 수 있어, 이를 과도하게 신뢰할 시 심각한 문제가 발생할 수 있다.

🛡️ 대응 방안

• 검증
  • 교차 검증: 신뢰할 수 있는 출처와 LLM 출력을 비교하여 검증
  • 모니터링: LLM의 출력을 정기적으로 검토하고 일관성을 확인
• 사용자 고지: 사용자에게 LLM의 한계와 사용 가이드라인을 제공

 

🔟 LLM10: 모델 도난(Model Theft)

LLM 모델에 대한 무단 접근 및 유출을 말한다.

도난된 LLM으로 인해 경제적 손실, 민감한 데이터 노출이 발생할 수 있다.

즉, 노출된 모델을 추론해 내부 데이터를 탈취할 수 있다는 이야기이다.

🛡️ 대응 방안

• 접근 제어와 인증: 강력한 접근 제어와 인증을 적용
• 네트워크 제한: LLM 접근에 대한 자원과 API를 제한
• 모니터링 및 감사: 정기적으로 접근 로그를 모니터링