2025 ACDC (AI Cyber Defense Contest)
12.1에 1일차 시행됨.
Microsoft
Microsoft에서 AI red team이 시행되고 있음.
시스템의 어느 부분에서 피해를 자동화하기 시작할지 생각하자.
그러면 AI 사고를 계속 예방할 수 있다.
Check out our PyRIT website and repo(레드티밍 모델 관련 MCsoft 연구내용): https://github.com/Azure/PyRIT
Recent Paper: https://ashy-coast-00aeb501e.6.azurestaticapps.net/MS_AIRT_Lessons_eBook.pdf
(레드 티밍 모델에서 얻은 100가지 교훈이 담긴 최근 논문이 있다고 함.)
Latest training series(10 video episodes): https://learn.microsoft.com/en-us/security/ai-red-team/training
LG전자 신종호
AI 시큐리티 R&D 담당, 오펜시브 시큐리티 + AI시큐리티
생성형ai --> agentic ai --> physical ai
physical ai 사례: 호주에서 robot vacuum cleaner를 해킹해서 사생활 침해가 될 수 있는 기술 사례
AI Security(생성형ai)
인풋 --> 모델 --> 아웃풋
완전히 deterministic하지는 않지만 비슷한 인풋에서는 비슷한 아웃풋을 생성하게 됨. http프로토콜처럼 stateless하다.
생성형 ai의 비결정론적(non-deterministic) 특성
- Deterministic(결정론적): 동일한 인풋이 주어지면 항상 동일한 아웃풋을 내는 시스템
ex. 2+2=4 이런 컴퓨터 계산..
- 완전히 deterministic하지 않다: 생성형 ai 모델은 난수(randomness)나 확률적 요소 를 사용하여 아웃풋을 생성한다.
따라서 정확히 같은 인풋을 여러 번 주더라도 아웃풋이 매번 조금씩 다를 수 있다.
ex. 똑같은 그림 요청에 조금씩 다른 디테일의 이미지를 생성
- 비슷한 인풋 --> 비슷한 아웃풋: 모델은 학습 데이터의 통계적인 패턴을 기반으로 작동하기 때문에, 인풋이 매우 유사하면 아웃풋 역시 의미론적으로 또는 구조적으로 유사한 경향이 있음.
ex. 개에 대한 질문과 강아지에 대한 질문은 비슷한 대답을 이끌어냄.
요약: 결과가 항상 똑같지는 않지만, 유사한 입력은 유사한 결과를 낳음.
LLM에서는 무상태성을 가지지만, 제미나이 같은 경우 한 번 물어보고 한번 응답하는 그 세트가 하나의 프롬프트이고, 각각의 프롬프트는 개별인데, 동일한 채팅 세션에서 전체 대화가 하나의 연속된 컨텍스트로 처리되기 때문에 이전 대화를 기억하는 것처럼 보이는 것임. 이전 발화가 현재 발화의 일부가 되는것.
- http 프로토콜처럼 stateless하다: 애초에 http 프로토콜은 상태를 비저장하는 stateless한 특성을 가지고 있음. 웹에서 데이터를 주고받을 때 기본적으로 현재의 요청은 이전의 요청이나 거래 내역을 기억하지 않고 독립적으로 구현된다는 것임.
모델이 stateless하다는 건 생성형 ai 모델 자체도 기본적으로 이전의 인풋/아웃풋 이력을 기억하지 않고 새로운 프롬프트 B를 처리할 때 이전 프롬프트 A와 A에 대한 아웃풋을 자동으로 활용하지 않는다는 것임.
ex. 채팅형 ai를 사용할때 이전 대화 내용을 기억하고 있는 것처럼 보이는 것은 모델 자체가 아니라 시스템이 이전 대화 내용을 현재 인풋에 포함(context injection)하여 모델에 전달하기 때문임.
Attack vectors
prompt injection, jailbreak, hallucination, model extraction, RAG manipulation, MLOps Pipeline Attack
어떤 범위안에서 예측가능하고 모델이 학습된 데이터의 분포 및 범위 내에서, 그리고 가진 구조적 제약 하에서 출력 값의 범위가 제한될 수 있다.(bounded되어있고 predictable하다)
--> 모델이 state를 가지고 있는게 아니기 때문에 새로운 인풋이 들어올때마다 새로 시작하는거라 생각하면 됨.
Agent Security(agentic ai)
스스로 판단하고 행위들을 하게되는 ai
New Attack vectors
아까는 모델 레이어에서 벡터들이 있었다면,
이제는 액션 레이어에서 새로운 벡터들이 생김.
tool injection, action hijacking, delegated misbehavior, multi-agent escalation, state manipulation, goal drift / value hijack
그림) 포르투갈쪽 침투테스트(펜테스팅)에서 나왔던 사례
ai tool calling(도구 호출)이 되는 거다보니
base64로 인코딩된 파이썬 코드가 있고 이걸 디코딩해서 실행하고 결과를 달라고 한 예제.
민감한 api키들, 환경변수값들을 가져올 수 있음.
프롬프트 인젝션으로 인해서 시스템을 장악할 수 있는 환경.
Physical ai security
피지컬 ai는 ai 에이전트의 확장이라고 볼수있음.
physical world에서 reason, plan, act 하는거
ex. robot vacuums, humanoids, industrial robots, self-driving car/drone, smart home
VLA(vision language action) model
: 텍스트, 비디오, 시연 등의 인풋을 받아서 act를 생성하는 로봇 모델
퍼셉션 레이어(물리적인 환경과 상호작용하면서 정보를 수집하는 역할)에서 여러 오동작들을 일으킬 수 있다.
vla 모델에 특화된 모델 poisoning 같은게 문제가 될 수 있음.
아까는 OS 환경변수 정도 바꿔서 할수있었다면 이제는 사람을 공격할 수 있는 환경.
Complexity and impact explosion
보호해야할 영역이 넓어짐.
ai security: 모델 보호
agent security: 액션 보호
physical ai security: real world를 보호
AI models: Linear Complexity
선형적으로 복잡해짐(ai 모델이 처리해야하는 데이터 양이나 문제 크기가 커짐에 따라 문제를 해결하는데 필요한 시간이나 메모리 같은 컴퓨터 자원도 그 크기에 비례해서 증가함)
Agentic AI: the inflection point of non-determinism
ai model 단에서는 bounded하고 predictable한 걸 예상할 수가 있었는데,
agent로 넘어오면 agent가 state값을 갖기 시작한다. 여러 planning에 따라 동작하려다 보니 state값을 갖게 돼서 예상치를 넘어서서 action레이어에서 공격이 일어날 수 있고,
취약점이 단순히 모델이 아니고 agent간에 역학적이 관계로 취약점이 나오게 된다.
Combinatorial Explosion
툴, 환경변수 이런게 복합적으로 추가되면서 complexity가 겁나 커짐.
introduction of environment: infinite variables
환경변수들이 겁나 많아짐: light, temperature, sound, obstacles, human motion, random noise, sensor uncertainty..
단순히 쉽게 컨트롤할수 없는 영역으로 넘어옴.
물리적인 것들로 공격이 오게됨.
방어체계를 그러면 어떻게?
동적인 방어 체계도 필요.
Google AI Innovation (Rao Surapaneni)
에이전트를 담당하는 구글 클라우드 ai 조직의 vpgm이라 함.
ai 애플리케이션 로켓
어떻게 하면 기능을 안전하게 전달할지..
자동화를 제공하는 많은 애플리케이션들이 있음.
생산 코드의 약 40~50%가 ai 생성 에이전트에 의해 생성된다고 함.
근데 이렇게 생산적이라는 건 동시에 위험 허용 오차가 낮다는 것임. 어떻게 하면 더 많은 에이전트에게 더 많은 자율성을 부여할 수 있을지가 현재 이 사업을 붙잡고 있음.
캘린더 초대 같은 프롬프트를 삽입하여 llm이 해서는 안되는 일을 단순히 읽고 수행하는 예도 있다.
에이전트는 수행하는데 있어서 최소한의 요구만 있으면 되고 더 많은 에이전시를 가지지 않게 해야함.(필요한 것보다 권한을 더 많이 가지는건 위험하다)
모델 생성부터 데이터들을 모니터링하고.. 데이터 중독이 발생하지는 않는지.. 전체 모델 가중치도 안전한지.. 입출력 부작용이 안전한지..
ai보안은 모든 계층에서의 보안이다.
에이전트가 더 많은 일을 하려고 하는것에 주목하고 있는 구글. 그리고 에이전트에 자율성을 부여하려고 할 때 에이전트는 액션을 제안할 수 있는데, 그런 다음 항상 방화벽이나 뭘 결정하는 정책 엔진?과 결합해야 한다.(단계 단계마다 보안적인 장치가 있어야함)
프로토콜을 정의하는데 시간을 쏟아야 함.
사용자가 에이전트에게 위임을 했는지, 에이전트 아이덴티티가 뭔지, 사용자가 의도를 확인한다는 걸 어떻게 보장하는지
--> 에이전트에게 위임을 했다는 것을 보장하기 위해서 암호화 로깅을 하고있음.
Q&A
ai에이전트가 엔터프라이즈 환경에서 소비자 에이전트로 이동함에 따라서 어떤 새로운 보안이 도입됐는지?
: 사용자 id 뿐 아니라 에이전트 id가 필요함. 프로토콜 구축해야함. 환각이란건 안전상의 위험임. 외부에서 작동하고 가드레일 구축하는 것도 필요.. 기억중독, 환각 등으로부터 보호하는 에이전틱 방화벽이 필요.
지금까지는 enterprise ai application이었지만 이제 consumer ai application이 나오고 있어서 여기에 맞춰서 어떻게 보안을 해야하는지 그리고 consumer에 맞춘것이 보안적으로 더 위험할 수 있다는 의견.
업계 전반에서 에이전트 보안을 개선하기 위해 의도 검증이나 프로토콜 수준 표준화와 같은 액션 게이팅 같은 접근 방식이 모색되고 있는데 가장 괜찮아 보이는 접근 방식?
: 소비자 측면을 하면 아이덴티티는 신뢰를 쌓는 요소인데 사용자 아이덴티티 이외에 에이전트 아이덴티티가 필요함.(사용자 의도를 확인하는데 기능) 에이전트 대 에이전트..
에이전트에게 뭘 해달라 해서 한거를 추후에 어떻게 증명할 수 있고, 예측가능한 범위 안에서 할 수 있는지
(근데 그냥 세션 토큰 같은 거처럼 하면 안되나)
에이전트 보안
1. 식별 및 신원 파악(탈중앙화된 id, 검증된 자격 증명)
2. 아키텍처 방어(계층별로)
3. 무결성과 동적 벤치마킹을 평가할 수 있는 기능(의도를 이해하고 이 에이전트가 지원할 수 있는 것의 목표를 이해할 수 있어야하고 그런 다음에 이게 공격인지 사용자 상호작용인지 평가)
4. 가디언 에이전트(런타임 내에서 감지하고 공격을 탐지하고 그러는거)
AI가 변화시킬 보안의 미래(윤인수)
LLM의 발전
llm은 '바나나'같은 토큰을 예측하는건데 사람의 생각의 로직들이 들어있음.
이것들이 복잡하게 동작하는게 llm agent.
ai 해커..라는 생각을 작년에 하고있었는데
XBOW가 취약점을 발견할 수 있었는데,
버그바운티 플랫폼 hacker one에서 XBOW라고 하는게 버그바운터 중에서 미국 1등을 했음.(여러 웹사이트를 동시에 체크할 수 있음. 복제가 돼서. 근데 깊이감을 충족시킬수는 없다고함.)
이렇게 xbow가 발전하고있다는건 base model이 점점 발전하면서 ai를 사용한 취약점 점검이 발전하고있음. ex. 구글의 big sleep이 브라우저 취약점을 ai가 찾음.
atlantis라고 하는 시스템에 대한 설명
AIxCC에서 발표함.
예선
1. 취약점 증명(취약점을 트리거할 수 있는 입력을 찾는 것)
2. 발견한 취약점에 대해 패치를 만드는 태스크
본선
1. 정적 분석으로 나온 결과가 진탐이냐 오탐이냐를 구분하는 태스크가 추가됨.
2. 리포지토리 코드가 주어진 상태에서 취약점을 찾는게 아니라 diff에서 새로운 기능이 추가됨으로 생긴 취약점들이 뭔지를 찾는 delta scan 모드 추가.
LLM의 보편화
ai coding assistants들이 나오고 기업가치가 치솟고 있음.
모드가 발전됨으로서 악의적인 입력이 프롬프트에 들어가서 ai 동작을 조작할 수 있음. (정보유출이나 뭐 띄우고 이런거)
LLM의 도입
공격의 전 과정에서 LLM이 활용되고있음. 완전 자동화된 공격을 시도하고있음.
LLM이 점점 더 복잡해지기 때문에 인프라나 클라우드가 많이 필요해서 이게 중요해짐.
AI 기업과 협력을 하는 방향..
보안 때문에 AI를 못쓰고있다고들 하는데 유연적으로 산업을 하는걸 지금까지 미뤘기 때문에, 해야한다고 생각한다고 함.
조직이 잘되려면 변화하기 쉬운 구조여야함.
반복적으로 시스템을 완성하고 개선하는..
한 명이 1000명의 일을 하게되는.. 보안업계..
새로운 취약점을 ai 가 발견하지 못할 것
+ai가 할루시네이션이 생겼을때 검증을 해야하기때문에 인간이 필요
최근 보안사고들의 관찰과 고찰(스틸리언 박찬암)
공격자입장에서의 AI의 의미
과거에는 음파를 개념으로 키 입력을 알아맞추는 것을 하려 했다면
이제는 입력을 할 때 각 키에 대해 각종 벡터에 대해서 3차원 시각화를 시키고 이걸 ai를 통해서 읽게 해서 패스워드를 맞추는 이런게 가능성이 좀 더 높아짐.
주로 ai관련 해킹은 웹 기반으로 하고, 기존 취약점 도구들을 많이 활용하는 느낌이 강했다.
현업에서의 AI 해커
CTEM, 펜테스트 gpt 써보니까, 아직까지 여기서 정의해둔 프로세스보다 사람이 할 수 있는게 더 많은 거 같은데 이런걸 쓰면 본인 생각이 더 갇혀서 닫히는 느낌..? 이라고들 했다고 함.
자체 LLM 견적상 너무 비싸고 gpt같은걸 쓸때보다 성능이 탁월하게 좋지도 않다고 함.
우리 시스템인 경우에 환각이런게 생기면 가용성이나 안정성 문제에서 이슈가 될 수 있겠다는 고민.
아직까지는 대체보다는 학습을 증폭시키는 용도로 발전하는 게 좋겠고 그냥 '좋은 툴' 느낌으로 쓰는게..
(너무 과대평가됨)
공격 표면을 줄이면 이렇게 되는데..
(올해 사고 터지면서.. 주된 얘기가 공격 표면을 확인하고 취약점을 알아내자는 거였음)
근본적으로 보안 수준을 높이려면(뚫리지 않으려면) 대체 어떻게 해야하나에 대한 고찰
- 뚫린 이유
레거시: 오래됐지만 여전히 사용되거나 영향을 미치는것
(알았는데 조치가 안 됐거나, 보안 조직이 너무 작아서 할 수 있는게 별로 없는 경우..)
- 모의해킹 결과
취약점 알고 패치하고.. 이거는 그냥 대중적인 얘기고
조직 구조나 개발 현실상 보안을 고려해서 개발을 하는거.. 개발에 대해서도 납기일을 못 맞추는데..
- 개선을 하려면 본질적으로
보안 부서가 요청을 하면 개발이나 운영과 같은 부서에서도 보안 마인드셋이 있어야 하는데.. 남일이라 생각하면.. 문제가 계속 발생함.
다 알고있는 내용인데 안되고있는..
개발이나 ciu 조직에서도 보안 입장에서 레거시 장비를 다시 생각해야하고 권한도 c레벨에서 책임지고 하라고 하는게.. 권한개선이 많이 되어야 한다고 생각.
ex. 통신사는 가용성과 호환성이 가장 우선되다보니 보안이 밀려나는 경우가 많았음. 금융 같은 경우 보안이 좀 중요하게 올라와있음.
외주업체에 의존하는것, 장비 사놓고 안 쓰는것도 있고
내 자산인줄 알았다가 아니었던 일도 있었다고 함.
자산식별관리체계를 각 회사에 맞게 고민이 있어야 함.
(이사를 해야만 집에 물건이 있는게 아니라.. 회사 자산을 잘 알고있어야함)
보안에 대한 기본기가 없어서 뚫린것이 대부분이었다.
보안 문제의 본질이 너무 깊은 곳에 있어서
본원적인 경쟁력 확보를 위해서 노력해야한다는 입장
AI 시대 보안 : 복잡성에서 맥락으로(비바리퍼블리카 이종호)
예전에는 단순한 구조라서 경계기반 보안이었는데,
요즘 서비스 보안과는 맞지않다는 생각이들었음.
최근에는 자동화도구가 개발이 되면서 배포속도랑 개발 편의성은 많이 올라갔는데, 보안 입장에서는 이걸 추적해야하기 때문에 난도가 상당히 올라감.
원래는 새로운 기술이 등장하면 그 밑에 레이어가 하나가 추가돼서 그것에 대한 보안기술이 등장하면 되는데
ai의 경우, 모든 아키텍처에 다 녹아들어있는 상황이라 별도의 체크가 필요함.
요청 관점에서 , 요청하면 웹서버 .. db..
이렇게 2,3개의 컴포넌트 정도로만 데이터플로우가 도달을 했는데
지금은 한번의 요청에 20개의 컴포넌트..
캐싱.. 로깅.. 인증 이런것들이 각각 조금씩 달라서
미세한 불일치가 생기게 되고
이 미세한 불일치들이 모여서 취약점이 됨.
코드보다 흐름에서 생기는 차이가 더 위험한 시대가 됨.
공격 기법보다도, 현재의 문제들이 코드 밖에서 이루어진다는 점이다.
ai가 코드를 어떻게 이해하는가로 분석 레이어가 확장되면서,
공격 표면이 확장됨.
전통적으로는 물리적인 자산정도로 파악하고 끝내는 경우가 많았는데, 지금은 데이터가 어디서 어떻게 생성되고 변형되고 이동하는지, 마이크로 서비스가 어떤식의 신뢰관계를 가지고 있는지, 인증 및 권한이 어떻게 바뀌는지, 어떤 api조합이 어떤 의미를 만들어내는지 등 정적 목록이 아니라 변화하는 그래프 모양으로 전체 서비스가 변화함.
자동화된 도구들이 코드 레벨의 취약점에 대해서는 잘 잡아주는데, 코드가 안전하다고 해서 서비스가 안전하다고 보는건 어렵다.
서비스간 호출, 상태 전이 방식, 큐나 배치의 흐름, ai의 의사결정 문제 등
misconfiguration(인적오류), 상태불일치, 조합 기반 문제에서 취약점들이 많이 나옴.
이전 코드 레벨에서는 블루팀이 공격 페이로드를 탐지하면되는데
이제는 로그에서 이게 정상이나 이상행위냐 판단하는게 어려워짐. 실제 개발자의 행동 이벤트와 공격자의 행동 이벤트가 단일 이벤트로 봤을때 둘다 정상으로 판단이 되는..
흐름상으로 보면 비정상인..(상관관계 분석을 해보니까 30초이내의 토큰을 재발급..)
탐지를 위해서도 ai 기반의 맥락 추론을 해야함.
위는 맥락 추론시 비정상과 정상을 판단할 때 고려해야할 부분들이다.
순서: abc 인데 acb로 호출이 된다던지 빠지거나
시간: 짧은 주기나 이상한 타이밍 어택
각 지점별로 인증, 권한 이런 처리방식이 조금씩 다름.
어디는 강하고 어디는 약하고
함수가 안전한가 < 전체 프로세스가 일관된 상태를 유지하는가(ex. 일관된 파싱)
정적 분석 도구, 동적 분석 도구들의 커버리지, 정확도가 많이 올라감.
실제 서비스에서는 동시 요청이 발생하기 때문에 상태 전이가 잘못돼서 취약점 발견되는 경우가 생김.
전체적인 맥락을 고려해서 보안성 평가를 진행해야됨.
기능들이 이어지면서 취약점이 발생하는데, 이어지는 방식이 달라지면 인증 강도 불일치.. 권한 상승 경로, race condition, 상태 전이 오류 취약점이 생길 수 있음
그래서 코드만 보고는 어떤 식으로 동작할지 예측이 불가능해지고 기능들이 정상이어도 조합에서 문제가 생기게 됨
서비스 전체를 일정한 기준으로 정리해서 바라봐야함(표준화)
표면상에 드러날 수 있는게 뭐가있는지
상태나 권한 구조는 어떤지
데이터 흐름에 대한 무결성 검증
정책 기반의 맥락을 사람이 정의해줘야 한다고 생각함.
완전한 표준화라기보다 정밀도를 조금씩 높여나가는 것.
복잡성을 구조적으로 다루는 방식이 앞으로의 보안체계에서 필수적인 역할이 될것.
AI 브라우저부터 바이브코딩까지 새로열린 공격 표면들(sk쉴더스 이호석)
sk쉴더스 프롬프트 인젝션 예시영상
: https://www.youtube.com/watch?v=9OD3-7aTdDo
멀티 에이전트: 에이전트 묶인것
에이전틱ai: 업무를 보면 안에있는 에이전트들끼리 서로 소통하고 맞는지 안맞는지 되물어보고 다시 처리를 하는 팀 단위 업무
자율의사결정: 명시를 했음에도 불구하고 ai가 잘못한다거나
슬롭스쿼팅: ai가 있지도 않은 패키지를 보내주는 것(대규모 언어 모델 (LLM)이 출력에서 환각을 일으킬 수 있는 존재하지 않는 소프트웨어 패키지 이름을 등록하는 행위)
악성코드를 깃허브에 올려놓고 그 페이지를 참조해서 개발해달라고 하고 리워드 주면서 악성 패키지를 요청하면서 공격하는 것도 슬롭스쿼팅이라 할 수 있고, 이게 바이브코딩 하면서 일어날 수 있다.
품질 면에서는 바이브 코딩에서 사용자가 요청하는거는 잘 해주는데, 시큐어 코딩은 아직까지 잘 못해주고있고
시큐어 코딩과 관련한 별도의 LLM은 없고 상용화되지는 않았음.
바이브 코딩 위협 사례
개발자가 보안을 잘 모르고 바이브코딩으로 앱을 개발함. 파베 스토리지를 아무나 다운받을수있게 해놨고
시큐어코딩 신경안쓰고 그냥 돌아가기만 하면 올려놓는다는게
본인이 어떻게 시큐어코딩을 해야하는지 모르니까
바이브 코딩에서는 할루시네이션이 일어났을때도 문제가 커지는..
- 프롬프트 인젝션 사례 영상
RAG: 검색 증강 생성(Retrieval-Augmented Generation)의 약자로, LLM이 답변을 생성할 때 외부 데이터베이스에서 관련 정보를 검색(Retrieval)하고, 이를 바탕으로 답변을 증강(Augmentation)하여 최종 답변을 생성(Generation)하는 기술이다.
이는 LLM이 학습한 데이터만으로 답변하는 대신, 최신 정보나 특정 내부 지식을 참조하여 정확하고 신뢰할 수 있는 답변을 제공하도록 돕는다.
