MITRE ATLAS를 AI 보안 위협 목록으로만 보지 않고, ATT&CK와 D3FEND를 함께 연결해 실제 방어 점검표로 바꾸는 방법입니다.
소개
AI 서비스를 운영할 때 보안 점검은 모델 성능 평가만으로 끝나지 않습니다. 데이터 수집, 학습 파이프라인, 모델 배포, 프롬프트 입력, 응답 기록, 권한 관리, 외부 도구 연동까지 함께 봐야 합니다. 이 과정에서 일반 IT 보안 점검표만 사용하면 AI 시스템 특유의 위험을 놓치기 쉽습니다.
MITRE ATLAS는 AI 시스템을 대상으로 하는 공격 전술, 기법, 사례를 정리한 지식 기반입니다. ATT&CK가 일반적인 사이버 공격자의 전술과 기법을 설명하는 기준이라면, ATLAS는 AI 모델과 머신러닝 시스템에서 나타나는 위협을 더 직접적으로 다룹니다. D3FEND는 이 위협을 방어 기능과 통제 점검 항목으로 바꿀 때 도움이 됩니다.
이 글은 공격 절차를 재현하기 위한 안내가 아닙니다. 방어자가 AI 서비스를 운영하거나 도입하기 전에 어떤 질문을 던져야 하는지, 어떤 증거를 확인해야 하는지, 어떤 항목을 점검표에 넣어야 하는지를 정리합니다.
1. ATLAS를 먼저 보는 이유
AI 시스템은 일반 웹 애플리케이션과 다른 공격 표면을 갖습니다. 입력값 검증, 인증, 로그, 네트워크 통제 같은 기본 보안은 여전히 중요하지만, 여기에 학습 데이터, 모델 파일, 추론 결과, 프롬프트, 임베딩 저장소, 플러그인 또는 외부 API 호출이 추가됩니다.
ATLAS를 먼저 보면 AI 시스템에서 공격자가 노릴 수 있는 지점을 구조적으로 나눌 수 있습니다. 예를 들어 데이터 단계에서는 학습 데이터의 품질과 출처를 확인해야 하고, 운영 단계에서는 프롬프트 입력과 모델 응답이 민감 정보나 내부 정책을 노출하지 않는지 봐야 합니다. 모델이 외부 도구를 호출한다면 권한과 실행 범위도 별도 통제로 다뤄야 합니다.
운영자가 점검표를 만들 때 가장 먼저 해야 할 일은 “우리가 AI를 어디에 쓰는가”를 적는 것입니다. 내부 검색인지, 고객 응대인지, 코드 작성 보조인지, 보안 분석 보조인지에 따라 위험이 달라집니다. 같은 모델을 쓰더라도 연결된 데이터와 권한이 다르면 보안 수준도 달라집니다.
2. ATT&CK와 연결해 공격 흐름을 이해합니다
ATLAS가 AI 시스템의 특수 위험을 보여준다면, ATT&CK는 공격 흐름을 더 넓은 사이버 침해 관점에서 정리할 수 있게 합니다. AI 서비스가 침해되는 과정은 모델만 공격하는 방식으로 끝나지 않을 수 있습니다. 계정 탈취, 클라우드 권한 오용, 외부 노출 API, 로그 저장소 접근 같은 일반적인 공격 흐름과 결합될 수 있습니다.
따라서 AI 보안 점검에서는 ATLAS 항목을 보고 끝내지 말고, ATT&CK의 전술 흐름으로 이어지는 지점을 찾아야 합니다.
- 초기 접근은 어떤 계정, API, 관리 콘솔에서 발생할 수 있는가
- 권한 상승이나 측면 이동이 AI 운영 환경까지 이어질 수 있는가
- 데이터 수집 단계에서 민감한 학습 데이터나 프롬프트 기록이 노출될 수 있는가
- 외부 도구 호출이 명령 실행이나 데이터 반출 경로가 될 수 있는가
- 영향 단계에서 모델 결과 조작, 서비스 신뢰도 하락, 내부 정보 노출이 발생할 수 있는가
이 질문은 공격 절차를 실행하기 위한 것이 아니라 방어자가 로그와 통제 범위를 정하기 위한 것입니다. 특히 AI 서비스가 클라우드 계정, 데이터베이스, 문서 저장소, 보안 도구와 연결되어 있다면 일반 ATT&CK 관점의 권한과 접근 경로를 반드시 함께 봐야 합니다.
3. D3FEND로 방어 점검 항목을 만듭니다
ATLAS와 ATT&CK로 위협을 이해했다면, 다음 단계는 방어 점검표입니다. D3FEND는 방어 기술과 대응 개념을 구조화하는 데 사용할 수 있습니다. 중요한 점은 D3FEND 용어를 문서에 넣는 것이 아니라, 실제 운영자가 확인할 수 있는 질문으로 바꾸는 것입니다.
AI 보안 점검표는 다음 항목을 포함해야 합니다.
| 점검 영역 | 확인 질문 | 확인 증거 |
|---|---|---|
| 데이터 출처 | 학습 또는 검색 데이터의 출처와 권한이 확인되는가 | 데이터 목록, 승인 기록 |
| 입력 통제 | 프롬프트와 사용자 입력에서 민감 정보가 걸러지는가 | 입력 정책, 필터 로그 |
| 출력 통제 | 모델 응답이 개인정보, 내부 문서, 보안 정책을 노출하지 않는가 | 응답 샘플, 차단 기록 |
| 권한 범위 | 모델 또는 에이전트가 호출할 수 있는 도구가 제한되는가 | API 권한, 역할 설정 |
| 로그 관리 | 프롬프트, 응답, 오류 로그의 보관 기간과 마스킹 기준이 있는가 | 로그 정책, 샘플 로그 |
| 변경 관리 | 모델, 프롬프트, 검색 인덱스 변경 이력이 남는가 | 배포 기록, 승인 기록 |
| 사고 대응 | 이상 응답이나 데이터 노출 의심 시 중지 절차가 있는가 | 대응 절차, 담당자 |
이 표는 특정 제품의 보안 기능 목록이 아닙니다. 운영자가 자신의 AI 서비스 구조에 맞게 증거를 붙일 수 있어야 합니다. “필터 있음”보다 “어떤 입력을 차단하고, 어떤 로그로 확인하며, 누가 예외를 승인하는가”가 더 중요합니다.
4. 운영자가 실제로 확인할 질문
AI 보안 점검은 기술팀만의 일이 아닙니다. 서비스 기획, 데이터 담당자, 보안 담당자, 운영자가 같은 기준으로 확인해야 합니다. 다음 질문에 답할 수 없으면 아직 승인용 운영 상태로 보기 어렵습니다.
- AI 서비스가 접근하는 데이터 목록이 정리되어 있는가
- 개인정보와 내부 문서가 프롬프트나 로그에 남지 않도록 기준이 있는가
- 모델 응답 오류를 사용자가 신고하거나 운영자가 회수할 절차가 있는가
- 외부 도구 호출 기능이 있으면 권한과 실행 범위가 제한되어 있는가
- 모델 또는 프롬프트 변경 시 누가 검토하고 승인하는가
- 보안 사고가 의심될 때 모델 사용을 중지하거나 로그를 보존할 수 있는가
- ATLAS에서 다루는 AI 특수 위협을 최소 1년에 한 번 이상 재검토하는가
블로그 자동화 운영 관점에서도 이 기준은 중요합니다. AI로 초안을 만들고 게시하는 시스템은 작성 지시문, 초안, 검수 기록, 출처 링크를 다룹니다. 이 정보가 공개 글에 노출되지 않도록 분리하고, 게시 전 검수 절차를 남기는 것이 기본 통제입니다.
5. 사이버레인지와 훈련 시나리오로 바꾸는 방법
ATLAS 기반 점검표는 문서로만 끝내지 말고 훈련 시나리오로 바꾸는 것이 좋습니다. 다만 훈련도 공격 실행 절차를 상세히 재현하는 방향이 아니라, 방어자가 어떤 신호를 보고 어떤 판단을 해야 하는지 확인하는 방식이어야 합니다.
훈련 시나리오는 다음 흐름으로 만들 수 있습니다.
1. 보호 대상 AI 서비스를 정합니다.
2. ATLAS에서 관련 위협 유형을 고릅니다.
3. ATT&CK 관점에서 계정, API, 데이터 저장소 접근 경로를 정리합니다.
4. D3FEND 관점에서 필요한 방어 기능과 증거를 정합니다.
5. 로그, 알림, 승인 기록, 변경 이력을 확인하는 훈련 질문을 만듭니다.
6. 훈련 후 탐지 누락, 권한 과다, 로그 부족, 책임자 불명확 항목을 개선 과제로 남깁니다.
이 방식은 공격 방법을 자세히 알려주는 글보다 AdSense 승인과 검색 품질 양쪽에서 더 안정적입니다. 독자에게 실제 도움이 되는 판단 기준을 제공하면서도 악용 가능한 절차를 공개하지 않기 때문입니다.
6. 정리
MITRE ATLAS는 AI 보안 위협을 이해하는 출발점입니다. 하지만 ATLAS만 보면 AI 시스템 안의 위험 목록에 머물 수 있습니다. ATT&CK를 함께 보면 일반 사이버 침해 흐름과 연결할 수 있고, D3FEND를 함께 보면 방어 통제와 운영 증거로 바꿀 수 있습니다.
AI 보안 점검의 핵심은 “모델이 안전한가”라는 추상적인 질문이 아닙니다. 어떤 데이터에 접근하는지, 어떤 권한을 갖는지, 어떤 입력과 출력을 남기는지, 이상 상황에서 누가 무엇을 확인하는지를 구체적으로 묻는 것입니다. 이 기준을 갖추면 AI 서비스를 도입할 때도, 블로그 자동화처럼 작은 운영 시스템을 만들 때도 방어 관점의 검수 품질을 높일 수 있습니다.
더 확인할 자료
아래 링크는 이 글의 기준과 배경을 확인할 수 있는 공식 자료입니다.