서문
지난주 보안 연구원 Mika Ayenson은 Elastic의 OnWeek 이벤트 시리즈에서 구현된 프록시를 통한 잠재적 탐지 전략과 LLM 콘텐츠 감사 프로토타입 솔루션을 강조하는 게시물을 작성했습니다. 이 포스팅에서는 다양한 환경에서 구현되는 LLM 기술의 안전성과 관련된 연구의 중요성과 Elastic Security Labs에서 중점적으로 진행하고 있는 연구에 대해 강조했습니다.
플랫폼에서 LLM 기술을 활용하여 보안 AI 도우미와 같은 기능을 강화하는 Elastic만의 유리한 지점을 고려할 때, 보다 공식적인 탐지 규칙, 통합 및 연구 콘텐츠에 대한 요구가 점점 더 커지고 있습니다. 이 간행물에서는 LLM 통합, 업계 표준에 부합하는 탐지에 대한 생각, ECS 필드 매핑에 대한 최근의 진전 사항을 중점적으로 다룹니다.
저희는 직접적인 사용자 기반 LLM 상호 작용뿐만 아니라 이를 둘러싼 광범위한 생태계를 보호하는 포괄적인 보안 전략에 전념하고 있습니다. 이 접근 방식에는 LLM 요청/응답뿐만 아니라 모델에서 사용하는 기본 시스템 및 통합을 처리하기 위한 여러 계층의 보안 탐지 엔지니어링 기회가 포함됩니다.
이러한 탐지 기회는 총체적으로 LLM 생태계를 보호하는 데 도움이 되며 크게 다섯 가지 범주로 분류할 수 있습니다:
- 프롬프트 및 대응: 점점 더 다양해지는 LLM 상호 작용을 기반으로 위협을 식별하고 완화하도록 설계된 탐지 메커니즘으로 모든 통신을 안전하게 감사할 수 있습니다.
- 인프라 및 플랫폼: 저장된 데이터, 처리 활동 및 서버 통신에 대한 위협 탐지를 포함하여 LLM(웨어러블 AI 핀 디바이스 포함)을 호스팅하는 인프라를 보호하기 위한 탐지 기능을 구현합니다.
- API 및 통합: LLM API와 상호 작용할 때 위협을 탐지하고 모델 출력을 수집하는 다른 애플리케이션과의 통합을 보호합니다.
- 운영 프로세스 및 데이터: 운영 프로세스(AI 에이전트 포함) 및 데이터 흐름을 모니터링하는 동시에 데이터의 수명 주기 동안 데이터를 보호합니다.
- 규정 준수 및 윤리: 탐지 전략을 잘 채택된 업계 규정 및 윤리 표준에 맞게 조정합니다.
LLM 생태계 보호: 5가지 범주
이러한 범주에 대한 또 다른 중요한 고려 사항은 누가 위험을 가장 잘 해결할 수 있는지 또는 LLM 시스템과 관련된 각 위험 범주에 대한 책임자가 누구인지로 확장됩니다.
기존의 공유 보안 책임 모델과 마찬가지로, Elastic은 탐지 엔지니어링 전략과 통합에 대한 연구를 계속 진행하면서 네 가지의 광범위한 범주를 평가했으며, 향후 이를 더욱 확장할 예정입니다. 이 문서에서는 대체로 다음과 같은 책임 소유자가 관련된 보안 보호를 고려합니다:
- LLM 크리에이터: LLM을 구축, 설계, 호스팅 및 교육하는 조직(예: OpenAI, Amazon Web Services 또는 Google)
- LLM 통합자: LLM 크리에이터가 제작한 기존 LLM 기술을 다른 애플리케이션에 통합하는 조직 및 개인.
- LLM 유지 관리자: 성능, 안정성, 보안 및 무결성 사용 사례에 대해 운영 중인 LLM을 모니터링하고 코드베이스, 인프라 및 소프트웨어 아키텍처의 유지 관리에 직접 관여하는 개인입니다.
- 보안 사용자: 기존의 테스트 메커니즘과 수단을 통해 시스템의 취약점을 적극적으로 찾는 사람들입니다. 이는 OWASP의 LLM Top 10에서 논의된 전통적인 위험을 넘어 이러한 시스템을 둘러싼 소프트웨어 및 인프라와 관련된 위험으로 확대될 수 있습니다.
이 광범위한 관점에서는 기본 Elastic 통합을 사용해 데이터를 수집하는 것으로 시작되는 LLM 탐색 엔지니어링에 대한 통합된 접근 방식을 보여드리며, 이 예에서는 AWS Bedrock 모델 호출 사용 사례를 중점적으로 살펴봅니다.
LLM 로그를 Elastic에 통합하기
Elastic 통합은 다양한 소스에서 Elastic으로 데이터 수집을 간소화하여 궁극적으로 보안 솔루션을 강화합니다. 이러한 통합은 Kibana의 Fleet을 통해 관리되므로 사용자는 Elastic 에이전트 내에서 데이터를 쉽게 배포하고 관리할 수 있습니다. 사용자는 Fleet을 통해 통합을 선택하고 구성하여 Elastic을 새로운 데이터 소스에 빠르게 적용할 수 있습니다. 자세한 내용은 Elastic과 시스템을 더 쉽게 통합하는 방법에 대한 Elastic의 블로그를 참조하세요.
팀이 수행한 초기 ONWeek 작업에는 Elastic Security AI Assistant와의 상호 작용에서 필드를 추출하는 간단한 프록시 솔루션이 포함되었습니다. 이 프로토타입은 Elastic Stack과 함께 배포되었으며 보안 감사 기능이 없는 공급업체 솔루션의 데이터를 사용했습니다. 이 초기 구현은 개념적으로는 흥미로웠지만, 클라우드 서비스 제공자 파트너 중 하나인 Amazon Web Services의 기존 Elastic 통합을 평가하는 데 시간을 투자하게 되었습니다. 이 방법론은 사용자에게 간소화된 접근성을 보장하며, 데이터 수집을 위한 원활한 원클릭 통합을 제공합니다. 모든 수집 파이프라인은 통합 패키지 내에서 대시보드를 포함한 포괄적인 콘텐츠를 포괄하는 ECS/OTel 정규화 표준을 준수합니다. 또한, 이 전략은 향후 LLM 중심의 통합을 위해 Azure 및 GCP와 같은 기존 통합을 추가로 활용할 수 있는 기반을 마련합니다.
공급업체 선택 및 API 기능
통합을 생성할 LLM 제공업체를 선택할 때 보안 사용 사례를 위해 수집해야 하는 필드 유형을 살펴보았습니다. 여기에 설명된 시작 규칙 집합의 경우 타임스탬프 및 토큰 수와 같은 정보가 필요했는데, Azure OpenAI와 같은 공급업체에서 프롬프트 및 생성된 콘텐츠에 대해 콘텐츠 중재 필터링을 제공한다는 사실을 알게 되었습니다. 데이터에 사용된 공급업체 유형(예: OpenAI, Bedrock 등)과 해당 메타데이터가 모두 포함되어 있는 LangSmith(LangChain 툴링의 일부)도 최고의 경쟁자였습니다. 하지만 이를 위해서는 사용자도 LangSmith를 설정해야 합니다. 이 구현에서는 LLM을 제공하는 공급업체의 퍼스트 파티 지원 로그를 사용하기로 결정했습니다.
잠재적인 통합에 대해 자세히 살펴보던 중 몇 가지 구체적인 이유로 AWS Bedrock을 사용하기로 결정했습니다. 첫째, 베드락 로깅은 Amazon CloudWatch Logs 및 Amazon S3에 대한 퍼스트 파티 지원을 제공합니다. 둘째, 로깅은 프롬프트 및 응답, 가드레일/콘텐츠 필터링 등 (다른 작업 및 머신 러닝 모델과 달리) LLM에 특정한 데이터를 포함하여 모델 호출을 위해 특별히 구축됩니다. 셋째, Elastic은 이미 AWS와의 강력한 통합 카탈로그를 보유하고 있기 때문에 특히 AWS Bedrock 모델 호출 로그에 대한 새로운 통합을 신속하게 생성할 수 있었습니다. 다음 섹션에서는 이 새로운 통합에 대해 자세히 알아보며, 이 통합을 사용하여 Elastic 스택에서 Bedrock 모델 호출 로그를 캡처할 수 있습니다.
Elastic AWS Bedrock 모델 통합
Overview
모델 호출 로그를 위한 새로운 Elastic AWS Bedrock 통합은 특히 모델에 초점을 맞춰 AWS 서비스에서 데이터를 신속하게 수집하고 분석할 수 있는 방법을 제공합니다. 이 통합은 로그 수집을 위한 두 가지 기본 방법을 제공합니다: Amazon S3 버킷과 Amazon CloudWatch입니다. 각 방법은 비용 효과와 성능 효율성을 고려하면서 강력한 데이터 검색 기능을 제공하도록 최적화되어 있습니다. 당사는 탐지 엔지니어링 목적으로 수집된 이러한 LLM 관련 필드를 사용합니다.
참고: 이 통합이 제안된 모든 필드를 포괄하는 것은 아니지만, 기존 AWS Bedrock 필드를 gen_ai 카테고리로 표준화합니다. 이 접근 방식을 사용하면 다양한 데이터 소스에서 탐지 규칙을 쉽게 유지 관리할 수 있으므로 각 LLM 공급업체에 대해 별도의 규칙이 필요하지 않습니다.
통합 데이터 수집 방법 구성
S3 버킷에서 로그 수집
이 통합을 통해 두 가지 다른 방법을 사용하여 S3 버킷에서 로그를 효율적으로 수집할 수 있습니다:
- SQS 알림: 기본 수집 방법입니다. 여기에는 AWS 단순 대기열 서비스(SQS) 대기열에서 S3 알림 이벤트를 읽는 작업이 포함됩니다. 이 방법은 직접 투표에 비해 비용이 적게 들고 더 나은 성능을 제공합니다.
- 직접 S3 버킷 폴링: 이 방법은 S3 버킷 내의 S3 개체 목록을 직접 폴링하며, SQS 알림을 구성할 수 없는 경우에만 권장됩니다. 이 접근 방식은 리소스를 더 많이 사용하지만 SQS가 불가능할 때 대안이 될 수 있습니다.
CloudWatch에서 로그 수집
CloudWatch에서 직접 로그를 수집할 수도 있는데, 이 통합은 filterLogEvents AWS API를 사용하여 지정된 로그 그룹 내의 모든 로그 스트림을 활용합니다. 이 방법은 S3 버킷을 아예 사용하지 않는 대안입니다.
통합 설치
통합은 일반적인 Elastic 설치 단계에 따라 Elastic 에이전트 내에서 설정할 수 있습니다.
- AWS Bedrock 통합으로 이동
- SQS의 경우
queue_url또는 직접 S3 폴링의 경우bucket_arn을 구성합니다.
암반 가드레일 구성
조직은 AWS 베드락 가드레일을 통해 LLM 상호 작용에서 유해하거나 바람직하지 않은 콘텐츠를 제한하는 정책을 설정하여 보안을 강화할 수 있습니다. 이러한 가드레일은 특정 주제를 차단하는 거부 주제와 프롬프트 및 응답에서 콘텐츠의 심각도를 조절하는 콘텐츠 필터를 포함하도록 사용자 지정할 수 있습니다. 또한, 단어 및 민감한 정보 필터는 욕설을 차단하고 개인 식별 정보(PII)를 가려주어 개인정보 보호 및 윤리 기준을 준수하는 상호작용을 보장합니다. 이 기능은 LLM에서 생성 및 소비되는 콘텐츠를 제어하고, 이상적으로는 악성 프롬프트와 관련된 위험을 줄이는 데 도움이 됩니다.
참고: 다른 가드레일 예로는 공급업체에 구애받지 않는 로깅을 위해 제안된 LLM 표준 필드에 캡처하고자 하는 Azure OpenAI의 콘텐츠 및 응답 필터가 있습니다.
LLM 상호작용 콘텐츠가 이러한 필터를 트리거하면 응답 개체는 가드레일 결과에 대한 세부 정보를 제공하는 amazon-bedrock-trace 및 amazon-bedrock-guardrailAction 필드와 입력이 콘텐츠 필터와 일치하는지 여부를 나타내는 중첩된 필드로 채워집니다. 세부 필터 결과를 통한 이러한 응답 개체 강화는 전반적인 데이터 품질을 향상시키며, 특히 이러한 중첩 필드가 ECS 매핑과 일치할 때 더욱 효과적입니다.
ECS 매핑의 중요성
필드 매핑은 통합 개발 프로세스의 중요한 부분으로, 주로 광범위하고 폭넓게 호환되는 탐지 규칙을 작성하는 능력을 향상시키는 데 사용됩니다. 데이터를 수집하고 분석하는 방법을 표준화함으로써, 조직은 Elastic으로 수집되는 로그, 특히 이 경우에는 LLM 로그에서 잠재적인 위협이나 이상 징후를 보다 효과적으로 탐지, 조사, 대응할 수 있습니다.
초기 매핑은 공급업체가 제공하는 필드와 기존 격차를 조사하는 것으로 시작하여 LLM 운영의 미묘한 차이에 맞춘 포괄적인 스키마를 구축합니다. 그런 다음 OpenTelemetry 시맨틱 규칙에 맞게 필드를 조정했습니다. 표에 표시된 매핑은 다양한 측면을 다룹니다:
- 일반 LLM 상호작용 필드: 여기에는 요청 및 응답의 내용, 토큰 수, 타임스탬프, 사용자 식별자 등 기본적이지만 중요한 정보가 포함되며, 이는 상호작용의 맥락과 범위를 이해하는 데 기초가 됩니다.
- 텍스트 품질 및 관련성 메트릭 필드: 텍스트 가독성, 복잡성 및 유사성 점수를 측정하는 필드는 모델 출력의 품질과 관련성을 평가하여 응답이 정확할 뿐만 아니라 사용자에게 적합한지 확인하는 데 도움이 됩니다.
- 보안 메트릭 필드: 이 메트릭 클래스는 정규식 패턴 일치 및 탈옥 시도, 프롬프트 인젝션, 환각 일관성 및 거부 응답과 같은 기타 보안 문제와 관련된 점수 등 잠재적인 보안 위험을 식별하고 정량화하는 데 중요한 역할을 합니다.
- 정책 시행 필드: 이 필드에는 콘텐츠 차단 또는 수정과 같이 상호 작용 중에 수행된 특정 정책 시행 조치에 대한 세부 정보를 캡처하고 이러한 조치의 신뢰 수준에 대한 인사이트를 제공하여 보안 및 규정 준수 조치를 강화합니다.
- 위협 분석 필드: 잠재적인 위협을 식별하고 정량화하는 데 중점을 둔 이 필드에서는 위험 점수, 탐지된 위협의 유형 및 이러한 위협을 완화하기 위해 취한 조치에 대한 자세한 분석을 제공합니다.
- 규정 준수 필드: 이 필드는 상호 작용이 다양한 규정 표준을 준수하는지 확인하는 데 도움이 되며, 감지된 규정 준수 위반 사항과 상호 작용 중에 트리거된 특정 규칙을 자세히 설명합니다.
- OWASP 상위 10대 특정 분야: 이러한 필드는 LLM 애플리케이션에 대한 OWASP 상위 10 위험에 직접 매핑되어 보안 조치를 인정된 업계 표준에 맞추는 데 도움이 됩니다.
- 감정 및 유해성 분석 분야: 이러한 분석은 응답의 어조를 측정하고 유해한 콘텐츠를 감지하여 결과물이 윤리 가이드라인 및 표준에 부합하는지 확인하는 데 필수적입니다. 여기에는 감정 점수, 유해성 수준, 부적절하거나 민감한 콘텐츠의 식별이 포함됩니다.
- 성능 메트릭 필드: 이러한 필드는 시스템 성능을 최적화하고 효율적인 운영을 보장하는 데 중요한 응답 시간 및 요청과 응답의 크기 등 LLM 상호 작용의 성능 측면을 측정합니다.
참고: 제안된 확장된 필드 표는 요약을 참조하세요.
이러한 필드는 LLM 통합을 통해 매핑되며 궁극적으로 탐지 내에서 사용됩니다. 위협 환경을 계속 파악해 나가면서 이러한 필드를 지속적으로 개선하여 다른 LLM 공급업체가 채우는 추가 필드를 표준화하여 매핑에 개념적으로 반영할 수 있도록 할 것입니다.
표준화의 광범위한 의미와 이점
LLM 에코시스템 내의 보안 분야(예: 사용자 상호작용 및 애플리케이션 통합)를 표준화하면 보안 도메인에 대한 통합된 접근 방식이 용이해집니다. Elastic은 일련의 표준 필드를 정의하고 홍보함으로써 이 분야를 선도하기 위해 노력하고 있습니다. 이러한 노력은 개별 조직의 보안 태세를 강화할 뿐만 아니라 더 안전한 산업을 조성하는 데도 도움이 됩니다.
보안 도구와의 통합: LLM 관련 보안 도구의 응답을 표준화하여 보안 솔루션에 원래의 LLM 공급업체 콘텐츠와 함께 제공될 수 있는 보안 분석 분야를 강화합니다. LLM 애플리케이션의 에코시스템에서 함께 운영되는 경우 보안 도구는 각 호출 요청과 응답을 감사할 수 있습니다. 그런 다음 보안팀은 이러한 필드를 활용하여 LLM 상호 작용 내에서 오용 또는 취약성의 미묘한 징후를 식별할 수 있는 복잡한 탐지 메커니즘을 구축할 수 있습니다.
공급업체 간 일관성: 모든 LLM 공급업체가 이러한 표준 필드를 채택하도록 주장하는 것은 모든 업계 사용자가 준수할 수 있는 기준선을 설정하는 방식으로 애플리케이션을 효과적으로 보호한다는 단일 목표를 추진합니다. 사용자는 플랫폼이나 도구에 관계없이 공통 스키마에 맞게 조정하는 것이 좋습니다.
향상된 탐지 엔지니어링: 이러한 표준 필드를 사용하면 탐지 엔지니어링이 더욱 강력해지고 오탐의 변화가 줄어듭니다. 보안 엔지니어는 다양한 모델, 상호 작용 및 에코시스템 전반에서 잠재적인 위협을 식별하는 효과적인 규칙을 만들 수 있습니다. 이러한 일관성은 여러 LLM 또는 보안 도구에 의존하고 통합 플랫폼을 유지해야 하는 조직에 특히 중요합니다.
LLM 관련 필드 샘플: AWS Bedrock 사용 사례
통합의 수집 파이프라인, 필드 매핑, 프로세서를 기반으로 AWS Bedrock 데이터는 정리되고 표준화되며 Elastic Common Schema(ECS) 필드에 매핑됩니다. 그런 다음 요청, 응답 및 토큰 수와 같은 모델 호출에 대한 세부 정보가 포함된 aws.bedrock 그룹 아래에 핵심 기반암 필드가 도입됩니다. 이 통합은 나중에 탐지에 사용되는 모델의 상호 작용에 대한 심층적인 인사이트를 제공하기 위해 LLM에 맞게 조정된 추가 필드를 채웁니다.
LLM 탐지 엔지니어링 사례
표준화된 필드와 Elastic AWS Bedrock 통합을 통해 다양한 복잡성을 가진 제안된 기능을 보여주는 탐지 엔지니어링 규칙을 만들 수 있습니다. 아래 예제는 ES|QL을 사용하여 작성되었습니다.
참고: 자세한 내용은 탐지 규칙 헌팅 디렉터리 및 aws_bedrock 규칙에서 이러한 쿼리에 대한 자세한 내용을 확인하세요.
민감한 콘텐츠 거부에 대한 기본 감지
조직 내 민감한 주제에 대한 현재의 정책과 표준을 고려할 때, LLM도 규정 준수 및 윤리 표준을 준수하도록 보장하는 메커니즘을 마련하는 것이 중요합니다. 조직은 LLM이 민감한 주제에 대한 응답을 직접 거부하는 사례를 모니터링하고 캡처할 수 있습니다.
샘플 감지:
from logs-aws_bedrock.invocation-*
| WHERE @timestamp > NOW() - 1 DAY
AND (
gen_ai.completion LIKE "*I cannot provide any information about*"
AND gen_ai.response.finish_reasons LIKE "*end_turn*"
)
| STATS user_request_count = count() BY gen_ai.user.id
| WHERE user_request_count >= 3탐지 설명: 이 쿼리는 모델이 잠재적으로 민감하거나 제한된 주제에 대한 정보 제공을 명시적으로 여러 번 거부하는 경우를 감지하는 데 사용됩니다. 미리 정의된 형식의 출력과 결합하여 출력 콘텐츠 내에 "" 에 대한 정보를 제공할 수 없습니다와 같은 특정 문구를 사용하는 것은 모델이 기밀 또는 부적절한 것으로 취급하도록 프로그래밍된 내용을 논의하라는 사용자 메시지에 의해 트리거되었음을 나타냅니다.
보안 관련성: LLM 거부를 모니터링하면 민감한 데이터에 대해 모델을 조사하거나 독점 또는 제한된 정보의 유출로 이어질 수 있는 방식으로 모델을 악용하려는 시도를 식별하는 데 도움이 됩니다. 보안팀은 이러한 거부의 패턴과 빈도를 분석하여 정보 보안 정책을 위반하려는 표적 시도가 있는지 조사할 수 있습니다.
잠재적인 서비스 거부 또는 리소스 고갈 공격
LLM의 엔지니어링 설계는 고도의 연산 및 데이터 집약적이기 때문에 리소스 고갈과 서비스 거부(DoS) 공격에 취약합니다. 높은 사용 패턴은 LLM의 가용성을 저하시키려는 악용 또는 악의적인 활동을 나타낼 수 있습니다. 프롬프트 요청 크기를 토큰 수와 직접적으로 연관시키는 것은 모호하므로, 프롬프트에서 토큰 수가 많을 때 항상 요청 본문이 커지는 것은 아닐 수 있으므로 그 의미를 고려하는 것이 중요합니다. 토큰 수와 문자 수는 특정 모델에 따라 달라질 수 있으며, 이는 임베딩 생성 방식과 관련이 있습니다.
샘플 감지:
from logs-aws_bedrock.invocation-*
| WHERE @timestamp > NOW() - 1 DAY
AND (
gen_ai.usage.prompt_tokens > 8000 OR
gen_ai.usage.completion_tokens > 8000 OR
gen_ai.performance.request_size > 8000
)
| STATS max_prompt_tokens = max(gen_ai.usage.prompt_tokens),
max_request_tokens = max(gen_ai.performance.request_size),
max_completion_tokens = max(gen_ai.usage.completion_tokens),
request_count = count() BY cloud.account.id
| WHERE request_count > 1
| SORT max_prompt_tokens, max_request_tokens, max_completion_tokens DESC탐지 설명: 이 쿼리는 남용 또는 서비스 거부(DoS) 공격 시도를 나타낼 수 있는 대량의 토큰 사용을 식별합니다. 비정상적으로 높은 토큰 수(입력 또는 출력)를 모니터링하면 시스템 속도를 늦추거나 과부하를 일으켜 잠재적으로 서비스 중단으로 이어질 수 있는 패턴을 감지하는 데 도움이 됩니다. 각 애플리케이션이 서로 다른 토큰 볼륨을 활용할 수 있다는 점을 감안하여 기본 사용 사례를 포괄할 수 있는 기존 경험을 바탕으로 간단한 임계값을 선택했습니다.
보안 관련성: 이러한 형태의 모니터링은 시스템 가용성 및 성능과 관련된 잠재적인 문제를 감지하는 데 도움이 됩니다. 합법적인 사용자의 서비스 품질을 저하시킬 수 있는 DoS 공격이나 악의적인 행동을 조기에 탐지하는 데 도움이 됩니다. 보안팀은 계정별 토큰 사용량을 집계하고 분석하여 잠재적으로 악의적인 트래픽의 출처를 찾아내고 적절한 조치를 취할 수 있습니다.
지연 시간 이상 모니터링
지연 시간 기반 지표는 시스템에 과부하를 주는 근본적인 성능 문제나 보안 위협을 나타내는 핵심 지표가 될 수 있습니다. 처리 지연을 모니터링함으로써 조직은 서버가 예상한 만큼 효율적으로 운영되고 있는지 확인할 수 있습니다.
샘플 감지:
from logs-aws_bedrock.invocation-*
| WHERE @timestamp > NOW() - 1 DAY
| EVAL response_delay_seconds = gen_ai.performance.start_response_time / 1000
| WHERE response_delay_seconds > 5
| STATS max_response_delay = max(response_delay_seconds),
request_count = count() BY gen_ai.user.id
| WHERE request_count > 3
| SORT max_response_delay DESC탐지 설명: 이 업데이트된 쿼리는 초기 응답 대기 시간에 초점을 맞춰 요청을 받은 후 LLM이 응답을 보내기 시작하는 데 걸리는 시간을 모니터링합니다. 실제 응답 시작과 일반적인 응답 시간을 비교하여 심각한 지연을 식별하고 이러한 지연이 비정상적으로 길어질 수 있는 경우를 강조 표시합니다.
보안 관련성: 비정상적인 지연 시간은 네트워크 공격(예: DDoS) 또는 해결해야 하는 시스템 비효율성과 같은 문제의 징후일 수 있습니다. 지연 시간 메트릭을 추적하고 분석함으로써 조직은 시스템이 효율적이고 안전하게 실행되고 있는지 확인하고 비정상적인 지연으로 나타날 수 있는 잠재적 위협에 신속하게 대응할 수 있습니다.
고급 LLM 탐지 엔지니어링 사용 사례
이 섹션에서는 Elastic Security 통합으로 해결할 수 있는 잠재적인 사용 사례를 살펴봅니다. 이러한 필드가 완전히 채워져 있고 필요한 보안 감사 강화 기능(예: 가드레일)이 AWS Bedrock 내에서 또는 LLM 공급업체가 제공하는 유사한 접근 방식을 통해 구현되어 있다고 가정합니다. 사용 가능한 데이터 소스 및 Elastic 통합과 함께, 이러한 Guardrail 요청 및 응답을 기반으로 탐지 규칙을 구축하여 배포 시 LLM의 오용을 탐지할 수 있습니다.
악성 모델 업로드 및 테넌트 간 에스컬레이션
최근 허깅 페이스 인터페이스 API에 대한 조사 결과 공격자가 악의적으로 조작된 모델을 업로드하여 임의의 코드를 실행할 수 있는 심각한 위험성이 발견되었습니다. 역직렬화하면 임베디드 악성 코드가 실행되는 파이썬 피클 파일을 사용하여 이를 달성했습니다. 이러한 취약점은 LLM부터 모델을 호스팅하는 인프라, 애플리케이션 API 통합에 이르기까지 서비스형 AI(AIAAS) 플랫폼의 모든 입력을 검사하고 살균하기 위한 엄격한 보안 조치의 필요성을 강조합니다. 자세한 내용은 이 도움말 문서를 참조하세요.
잠재적 탐지 기회: gen_ai.request.model.id, gen_ai.request.model.version, gen_ai.completion 와 같은 필드를 사용하여 비정상적인 모델과의 상호작용을 감지하세요. 모델 식별자 및 버전 번호의 비정상적인 값이나 패턴을 모니터링하고 요청된 콘텐츠를 검사(예: 일반적인 Python Pickle 직렬화 기술 찾기)하면 의심스러운 동작을 나타낼 수 있습니다. 마찬가지로 유사한 필드를 사용하여 모델을 업로드하기 전에 확인하면 업로드가 차단될 수 있습니다. gen_ai.user.id 같은 추가 필드를 상호 참조하면 이러한 유형의 활동을 수행하는 악의적인 교차 테넌트 작업을 식별하는 데 도움이 됩니다.
무단 URL 및 외부 커뮤니케이션
LLM이 운영 에코시스템에 더욱 통합됨에 따라 이메일이나 웹훅과 같은 외부 기능과 상호 작용하는 기능이 공격자에 의해 악용될 수 있습니다. 이러한 상호 작용으로부터 보호하려면 모델의 출력과 후속 통합을 기반으로 의심스러운 활동이나 무단 활동을 식별할 수 있는 탐지 규칙을 구현하는 것이 중요합니다.
잠재적 탐지 기회: gen_ai.completion, gen_ai.security.regex_pattern_count 과 같은 필드를 사용하여 악성 외부 URL 및 웹훅을 분류하세요. 이러한 정규식 패턴은 잘 알려진 의심스러운 패턴을 기반으로 미리 정의해야 합니다.
계층적 인스트럭션 우선순위 지정
LLM은 다양한 소스(예: ChatGPT 사용자 지정 지침)로부터 지침을 받는 환경에서 점점 더 많이 사용되고 있으며, 항상 선의의 의도가 있는 것은 아닐 수도 있습니다. 이러한 자체 모델 구축 워크플로에서는 모델이 모든 지침을 동일하게 중요하게 취급하고 이를 확인하지 않을 경우 다양한 잠재적 보안 취약점이 발생할 수 있습니다. 여기를 참조하세요.
잠재적 탐지 기회: gen_ai.model.instructions 및 gen_ai.completion 같은 필드를 모니터링하여 주어진 지침과 모델 응답 간의 불일치를 식별하고, 이는 모델이 모든 지침을 동등하게 취급하는 경우를 나타낼 수 있습니다. 또한 gen_ai.similarity_score 을 분석하여 원래 요청과 응답이 얼마나 유사한지 확인합니다.
추가 Elastic 규칙 유형을 갖춘 확장된 탐지 기능
이 섹션에서는 보다 미묘하고 강력한 보안 태세를 제공하기 위해 Elastic의 규칙 유형 중 일부인 임계값, 지표 일치 및 새 용어를 사용하는 추가 탐지 엔지니어링 기법을 소개합니다.
- 임계값 규칙: 악용 시도를 나타낼 수 있는 단기간 동안 거부된 요청의 빈도가 높은 요청을
gen_ai.user.id으로 그룹화하여 식별합니다. (예 OWASP의 LLM04) - 지표 일치 규칙: 알려진 악성 위협 인텔리전스 제공 지표(예:
gen_ai.user.id)와 이러한 사용자 속성이 포함된 LLM 사용자 ID를 일치시킵니다. (예arn:aws:iam::12345678912:user/thethreatactor) - 새로운 용어 규칙: 사용자 프롬프트에서 사용자 역할에 대한 일반적인 사용법을 벗어난 활동을 나타낼 수 있는 새롭거나 특이한 용어를 감지하여 새로운 악의적인 행동을 나타낼 수 있습니다.
요약
Elastic은 생성형 AI 환경 전반에서 LLM 기반 필드의 표준화를 선도하여 에코시스템 전반에서 보안 탐지를 가능하게 하고 있습니다. 이 이니셔티브는 지속적으로 개선되고 있는 LLM 통합 및 보안 전략에 부합할 뿐만 아니라 직접적인 사용자 상호 작용과 기본 시스템 아키텍처를 모두 보호하는 광범위한 보안 프레임워크를 지원합니다. 향상된 탐지 및 대응 기능을 위해 LLM 공급업체 간에 통일된 언어를 장려함으로써 전체 생태계를 보호하여 더욱 안전하고 신뢰할 수 있는 생태계를 만드는 것을 목표로 합니다. Elastic은 업계의 모든 이해관계자, 즉 제작자, 유지 관리자, 통합자 및 사용자가 이러한 표준화된 관행을 채택하여 집단적 보안 조치를 강화하고 업계 전반의 보호를 발전시키도록 초대합니다.
AWS Bedrock을 시작으로 통합을 계속 추가하고 개선해 나가면서, 다른 LLM 기반 통합을 우리가 설정한 새로운 표준에 맞춰 조정하여 Elastic 에코시스템 전반에 걸쳐 통합된 환경을 위한 기반을 마련할 전략을 세우고 있습니다. 기존 Elasticsearch 기능과의 완벽한 중첩을 통해 사용자는 LLM 데이터에서 직접 정교한 검색과 분석을 활용할 수 있으며, 기존 워크플로우를 사용자가 가장 익숙한 도구로 되돌릴 수 있습니다.
이러한 주제에 대해 자세히 설명하는 LLM 안전성 평가를 확인하세요.
이 게시물에서 설명된 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.