2023년 추수감사절 Cloudflare 보안 사건

 (blog.cloudflare.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Cloudflare는 2023년 11월 23일 자체 호스팅 Atlassian 서버에서 위협 행위자를 탐지했지만, 고객 데이터·고객 시스템·글로벌 네트워크 시스템과 설정은 영향받지 않았다고 발표함
  • 침입 경로는 2023년 10월 Okta 침해 이후 회전되지 않은 1개 액세스 토큰과 3개 서비스 계정 자격 증명이었고, 접근은 Jira, Confluence, Bitbucket 등 Atlassian 환경에 집중됨
  • 위협 행위자는 11월 14~17일 정찰과 내부 문서 접근을 수행한 뒤, 11월 22일 ScriptRunner for Jira를 통해 Sliver를 설치해 지속 접근을 확보함
  • Cloudflare는 “Code Red” 대응으로 5,000개 이상 프로덕션 자격 증명을 회전하고, 4,893개 시스템을 포렌식 선별 조사했으며, 글로벌 네트워크의 모든 머신과 Atlassian 제품을 재이미징·재부팅함
  • CrowdStrike의 독립 조사에서도 누락된 활동은 발견되지 않았고, 마지막 위협 활동 증거는 2023년 11월 24일 10:44 UTC로 확인됨

사건 개요와 영향 범위

  • Cloudflare는 2023년 11월 23일 자체 호스팅 Atlassian 서버에서 위협 행위자를 탐지함
    • 보안팀은 즉시 조사에 착수하고 접근을 차단함
    • 11월 26일 CrowdStrike 포렌식 팀을 불러 독립 분석을 진행함
  • 이번 사건으로 고객 데이터나 고객 시스템은 영향받지 않음
    • 서비스는 연루되지 않았음
    • 글로벌 네트워크 시스템이나 설정 변경도 없었음
    • 접근 제어, 방화벽 규칙, 자체 Zero Trust 도구로 강제한 하드웨어 보안 키가 측면 이동을 제한함
  • 위협 행위자의 접근 범위는 내부 위키인 Atlassian Confluence, 버그 데이터베이스 Jira, 소스 코드 관리 시스템 Bitbucket, 그리고 Atlassian이 실행되는 서버로 제한됨

침입에 사용된 자격 증명

  • 침입은 2023년 10월 Okta 침해 이후 유출됐지만 회전되지 않은 1개 서비스 토큰과 3개 서비스 계정에서 시작됨
    • Moveworks 서비스 토큰: Atlassian 시스템 원격 접근에 사용됨
    • Smartsheet 서비스 계정: Atlassian Jira 인스턴스 관리자 권한을 가짐
    • Bitbucket 서비스 계정: 소스 코드 관리 시스템 접근에 사용됨
    • AWS 환경 계정: 글로벌 네트워크, 고객 데이터, 민감 데이터에는 접근 권한이 없었음
  • 해당 토큰과 계정은 사용되지 않는다고 잘못 판단돼 회전 대상에서 빠짐
  • Cloudflare는 이 문제가 Atlassian, AWS, Moveworks, Smartsheet의 오류가 아니라 Cloudflare가 자격 증명을 회전하지 못한 결과라고 명시함

공격 타임라인

  • 11월 14일 09:22:49부터 위협 행위자가 시스템 탐색과 정찰을 시작함
    • Okta 인스턴스 로그인 시도는 거부됨
    • Cloudflare Dashboard 접근도 차단됨
    • Cloudflare Apps 마켓플레이스를 구동하는 AWS 환경에는 접근했지만, 이 환경은 글로벌 네트워크와 고객 데이터에서 분리되어 있었음
  • 11월 15일 16:28:38에 Atlassian Jira와 Confluence 접근에 성공함
    • Moveworks 서비스 토큰으로 게이트웨이를 통과하고 Smartsheet 서비스 계정으로 Atlassian 제품군에 접근함
    • 위키에서 remote access, secret, client-secret, openconnect, cloudflared, token 등을 검색함
    • 2,059,357개 Jira 티켓 중 36개, 194,100개 위키 페이지 중 202개에 접근함
    • 접근한 Jira 티켓에는 취약점 관리, secret 회전, MFA 우회, 네트워크 접근, Okta 사건 대응 관련 항목이 포함됨
  • 11월 16일 14:36:37에는 Smartsheet 자격 증명으로 일반 Cloudflare 사용자처럼 보이는 Atlassian 계정을 만들고 여러 그룹에 추가함
    • Smartsheet 서비스 계정이 제거돼도 Atlassian 환경에 계속 접근하려는 조치였음
  • 11월 17일 14:33:52부터 11월 20일 09:26:53까지는 짧은 접근 테스트를 제외하고 Cloudflare 시스템 접근이 중단됨
  • 11월 22일 14:18:22에는 Smartsheet 서비스 계정의 Jira 관리자 권한을 이용해 ScriptRunner for Jira 플러그인으로 Sliver Adversary Emulation Framework를 설치함
    • Sliver는 레드팀과 공격자가 C2, 연결성, 지속적·은밀한 접근을 위해 사용하는 도구 및 프레임워크임
    • 이를 통해 Atlassian 서버에 지속 접근하고 측면 이동을 시도함
    • São Paulo, Brazil의 아직 프로덕션에 투입되지 않은 데이터센터에 있는 비프로덕션 콘솔 서버 접근 시도는 실패함

소스 코드와 문서 접근

  • 위협 행위자는 11월 22일 이후 하루 동안 11,904개 저장소 중 120개 코드 저장소를 조회함
    • 이 중 76개 저장소는 Atlassian Bitbucket의 git archive 기능을 사용해 Atlassian 서버로 다운로드됨
    • Cloudflare는 외부 유출 여부를 확인하지 못했지만, 유출된 것으로 간주하고 대응함
  • 76개 저장소는 대부분 다음 영역과 관련됨
    • 백업 동작 방식
    • 글로벌 네트워크 설정 및 관리
    • Cloudflare의 ID 시스템
    • 원격 접근
    • Terraform과 Kubernetes 사용
  • 일부 저장소에는 암호화된 secret이 포함되어 있었고, Cloudflare는 강하게 암호화되어 있었더라도 즉시 회전함
  • Cloudflare는 소스 코드 자체보다 코드에 포함된 내장 secret, 취약점, 이후 공격에 활용될 수 있는 경로를 중점적으로 조사함
    • Cloudflare는 많은 소스 코드를 오픈소스로 공개해 왔고, 블로그를 통해 사용하는 알고리듬과 기법을 공개적으로 다뤄 왔다고 설명함

탐지와 차단

  • 11월 23일 16:00에 보안팀이 위협 행위자 존재에 대한 알림을 받음
    • 15:58: 위협 행위자가 Smartsheet 서비스 계정을 관리자 그룹에 추가함
    • 16:00: 해당 변경에 대한 자동 알림이 보안팀에 전달됨
    • 16:12: Cloudflare SOC가 조사 시작
    • 16:35: Smartsheet 서비스 계정 비활성화
    • 17:23: 위협 행위자가 만든 Atlassian 사용자 계정 발견 및 비활성화
    • 17:43: 내부 Cloudflare incident 선언
    • 21:31: 위협 행위자의 알려진 IP 주소를 차단하는 방화벽 규칙 적용
  • 11월 24일에는 마지막 활동과 Sliver 제거가 확인됨
    • 10:44: 마지막으로 알려진 위협 행위자 활동
    • 11:59: Sliver 제거
  • 위협 행위자는 내부 지표, 네트워크 설정, 빌드 시스템, 알림 시스템, 릴리스 관리 시스템 등 다양한 시스템 접근을 시도했지만 성공하지 못함
  • 글로벌 네트워크, 데이터센터, SSL 키, 고객 데이터베이스 또는 설정 정보, Cloudflare Workers, AI 모델, 네트워크 인프라, Workers KV, R2, Quicksilver 같은 데이터 저장소 접근 증거는 발견되지 않음

“Code Red” 대응과 강화 작업

  • Cloudflare는 11월 24일 위협 행위자를 환경에서 제거한 뒤, 침입 조사와 접근 범위 확인을 위해 회사 전반의 인력을 투입함
  • 11월 27일부터는 보안팀 안팎의 많은 기술 인력이 Code Red 프로젝트에 집중함
    • 향후 침입에 대비해 환경의 통제를 강화·검증·수정함
    • 위협 행위자가 계속 접근할 수 없는지 검증함
    • 모든 시스템, 계정, 로그를 조사해 지속 접근 여부와 접근·시도 대상을 확인함
  • 주요 조치는 다음과 같음
    • 5,000개 이상 프로덕션 자격 증명 회전
    • 테스트 및 스테이징 시스템의 물리적 분리
    • 4,893개 시스템 포렌식 선별 조사
    • 글로벌 네트워크의 모든 머신 재이미징 및 재부팅
    • Jira, Confluence, Bitbucket 등 모든 Atlassian 제품 재이미징 및 재부팅
  • São Paulo 데이터센터 장비는 제조사로 반환됨
    • 제조사 포렌식 팀이 접근 또는 지속성 확보 여부를 조사함
    • 아무것도 발견되지 않았지만 Cloudflare는 하드웨어를 교체함
  • 추가로 업데이트되지 않은 소프트웨어 패키지, 생성됐을 수 있는 사용자 계정, 사용되지 않는 활성 직원 계정, Jira 티켓이나 소스 코드에 남아 있을 수 있는 secret, 위키에 업로드된 HAR 파일을 조사함
    • HAR 파일은 토큰이 포함됐을 가능성에 대비해 삭제됨
  • 즉각적인 Code Red 작업은 2024년 1월 5일 종료됐지만, 자격 증명 관리, 소프트웨어 강화, 취약점 관리, 추가 알림 개선 작업은 계속됨

CrowdStrike 조사와 IOCs

  • CrowdStrike는 위협 행위자 활동의 범위와 지속성 증거를 독립적으로 평가함
    • Cloudflare 조사에서 놓친 활동은 발견되지 않음
    • 마지막 위협 활동 증거는 2023년 11월 24일 10:44 UTC로 결론남
  • Cloudflare는 업계 및 정부 동료들과의 협력을 바탕으로, 이번 공격이 Cloudflare 글로벌 네트워크에 대한 지속적이고 광범위한 접근을 얻으려는 국가 지원 공격자에 의해 수행됐다고 판단함
  • Cloudflare는 Okta 침해 영향을 받았을 수 있는 다른 조직이 로그를 확인할 수 있도록 침해 지표를 공개함
    • 193.142.58[.]126: 주요 위협 행위자 인프라, M247 Europe SRL 소유
    • 198.244.174[.]214: Sliver C2 서버, OVH SAS 소유
    • idowall[.]com: Sliver 페이로드 제공 인프라
    • jvm-agent: Sliver 페이로드 파일명, SHA256 bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Cloudflare의 이런 공개 분석과 대응 때문에 내 데이터와 비즈니스를 맡길 수 있다고 봄
    완벽하진 않고 동의하지 않는 일도 하지만, 회사 전반에 공유된 엔지니어링 마인드셋과 이런 일을 심각하게 다루는 태도 때문에 신뢰할 만하다고 느낌

    • 그러면 광고는 성공한 셈임
      경쟁사보다 더 높은 무결성을 갖췄다고 강조하고, 최근 보안 사고 뒤 몇 가지 운영 조사를 공유하는 방식임
      하지만 Cloudflare는 PCI/DSS 결제카드 처리자로서의 SOC 위험 분석을 제공하지 않고, 왜 권한이 높아진 계정을 놓쳤는지나 그 계정들이 처음에 어떻게 침해됐는지도 설명하지 않음. 책임보다는 remediation만 설명함
      제3자 감사를 언급하지만, 그건 사용자를 생각해서가 아니라 PCI/DSS가 결제카드 정보가 침해된 조직에 매년 현장 감사를 요구하기 때문임. 안 그러면 주요 카드사가 결제 처리를 중단했을 것임
    • 완벽한 회사는 없지만 Cloudflare는 확실히 신뢰를 줌. 특히 문제와 해결 과정을 숨기지 않고 말하는 사례들이 좋고, 이런 설명이야말로 어떤 도전도 넘길 수 있는 역량을 보여준다고 봄
    • 우리는 Cloudflare의 꽤 큰 엔터프라이즈 고객인데, 이런 대응 덕분에 갱신 승인을 받기가 쉬워짐. 엔지니어들을 계속 공유 대상에 넣어 주는 게 내부 설득에 큰 도움이 됨
    • 침입자가 KB와 티켓에 접근했는데 가치 있는 정보를 못 얻었다고 정말 믿는 건가? Jira가 무엇에 쓰이는지 알고, 온프레미스로 운영할 정도라면 거기에 저장할 가치 있는 게 있다는 뜻임
      아무것도 잃지 않았다는 말은 믿기 어렵고, 내가 본 대부분의 Jira/Confluence에는 비밀 정보가 잔뜩 들어 있었음
    • Cloudflare의 CEO가 싫어할 말을 하지 말고, 계속 좋은 쪽에 남아 있길 바라야 함

  • “접근한 위키 페이지, 버그 데이터베이스 이슈, 소스 코드 저장소를 분석해 보니 글로벌 네트워크의 아키텍처, 보안, 관리에 관한 정보를 찾고 있었던 것으로 보인다”는 대목을 보면, 국가 행위자에게 가장 쉬운 방법은 충성스러운 시민을 목표 회사 직원으로 들여보내고 그 사람이 해당 정보를 보내게 하는 것임
    재미있는, 다만 사실 여부는 불확실한 얘기로, 10년도 더 전에 Google의 SRE 사교 모임에서 몇 명이 자국 정보기관 급여를 받고 있다고 인정한 적이 있었다고 함

    • 그 사람들이 Google의 동의를 받은 정부 협력 업무를 하고 있었고, 서로에게 공개 가능한 관계였던 건가?
      아니라면 그런 모임에서 얼마나 강한 약이 돌았길래 그렇게 끔찍한 작전 보안 실패가 벌어졌는지 궁금함
    • 급여를 받는다고? 너희는 돈도 받음?
      호주인은 시민권의 기본 조건처럼 그런 종류의 스파이 활동에 참여할 “기회”를 얻음 https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
      장점이라면 제로 트러스트 절차와 시스템 개발에서 좋은 관행을 강제하는 데 도움이 될 수는 있겠음
    • 정확함. 특히 미국 기업이라면 더 그렇다. 열쇠와 허가를 둘 다 갖고 있는데 왜 자물쇠를 따겠음?
    • 그런 시민이 제재 대상이라면 아니겠지. Code Red. 힌트임

  • “우리는 두 번째로 Okta 시스템 침해의 피해자가 됐다”는 부분을 보면, Cloudflare가 Okta 사용을 재검토하고 있는지 궁금함

    • 이번 건은 Okta의 추가 실패라기보다는, 원래 Okta 침해 때 유출된 자격 증명을 Cloudflare가 회전하지 못한 사건에 가까움
      Okta도 비판받아야 하지만, 이건 Cloudflare가 자기 실수를 덮으려고 아래로 책임을 미루는 느낌임
    • 우리 회사는 Okta 관리 시스템이 미리 설치된 새 노트북만 지급함
      나는 “초창기”에 받은 오래된 MacBook을 그대로 쓰고 있어서 관리 소프트웨어가 전혀 없음. 당시에는 IT가 없었고 그냥 손대지 않은 새 노트북을 받았음
      회사가 M1/M2 Pro로 업그레이드해 주겠다고 했지만, 업무용 컴퓨터에 개인 비밀번호나 키가 하나라도 있다면 Okta 로그인 시스템을 쓰고 싶지 않다고 거절했음
      그래서 업무에 큰 차질이 생기기 전까지는 업그레이드할 수 없음. 이런 사고를 IT 부서에 내 생각을 정당화하는 근거로 쓸 수 있을지도 모르겠음
    • 문제는 Cloudflare의 요구사항을 감당할 수 있는 대안이 누가 있느냐임. 다음 단계는 자체 구축일 텐데, 그건 당연히 삼키기 어려운 선택임

  • “서비스 토큰 하나와 계정 세 개는 사용되지 않는다고 잘못 믿어 회전하지 않았다”는 말이 이상함. 사용하지 않는 거라면 왜 아예 폐기하지 않았는지 모르겠음
    뭔가 빠졌거나 전달 과정에서 사라진 내용이 있겠지만, 문장 그대로는 잘 이해가 안 됨

    • 여기서 “믿었다”는 표현은 개인의 적극적인 판단이라기보다 설정 상태에 가까운 의미였을 것 같음
      예를 들어 데이터베이스 어딘가에 해당 서비스 계정이 “폐기됨”이나 “정리됨” 같은 비활성 상태로 표시되어 있었지만, 그 표시가 틀렸던 상황일 수 있음. 그래서 활성 계정의 비밀번호는 모두 회전했지만 비활성 계정은 건너뛰었을 것임
      내가 잘 아는 공개키 기반 구조와 인증서 폐기 맥락만 놓고 보면, 인증서가 만료되게 두는 것, “더 이상 사용하지 않음”으로 표시하는 것, 완전히 폐기하는 것은 꽤 다름. 인증기관은 첫 경우 아무것도 안 해도 되고, 둘째는 아무것도 안 하거나 폐기할 수 있으며, 셋째는 폐기 목록을 적극적으로 유지하고 배포해야 함. 누가 “개인키를 실수로 덮어썼으니 새 키에 대한 인증서를 달라”고 하면 보통 예전 인증서를 폐기 목록에 넣지는 않음
    • 아마 비난 없는 사후 분석일 가능성이 큼
      “이는 AWS, Moveworks, Smartsheet의 오류가 전혀 아니며, 우리가 회전하지 못한 자격 증명일 뿐이다”라고 명확히 쓴 건 좋은 짚기임
    • 회전 작업이 수동이었고 담당자가 시간을 아끼려 했을 수도 있음. 스트레스도 영향을 줬을 수 있고
    • 이제 침해 대응 절차서에 새 항목이 생겼을 듯함 :-)

  • Cloudflare는 공격자의 접근이 제한적이었다고 믿고 나중에 확인했음에도, 프로덕션 자격 증명 5,000개 이상을 모두 회전하고 테스트·스테이징 시스템을 물리적으로 분리했으며, 4,893개 시스템을 포렌식 점검하고 전 세계 네트워크의 모든 머신을 재이미징·재부팅함
    아직 프로덕션에 투입되지 않은 São Paulo 데이터센터의 콘솔 서버 접근 시도도 실패했지만, 브라질 데이터센터 장비를 제조사로 돌려보내 포렌식을 받게 했고 아무것도 발견되지 않았는데도 하드웨어를 교체함
    이렇게까지 하지 않아도 됐고 안 하기도 쉬웠을 텐데, 실제로 했다는 점은 칭찬받을 만함

    • 오히려 그렇게까지 해야 했다고 봄
      새 데이터센터 구축의 초기 단계에 침투하는 건 거의 궁극의 익스플로잇임. 새 Meet-Me room(https://en.wikipedia.org/wiki/Meet-me_room) 한가운데 들어가 핵심 스위치에 지속 접근권을 얻는 상황을 상상해 보면 됨
      Cloudflare 데이터센터는 엄청난 양의 데이터 트래픽 허브인 경우가 많음. 공격자가 “프로덕션 전” 데이터센터의 가치를 알았다는 사실은, 정규 보안 체계가 갖춰지기 전에 거기에 발판이 생기면 100% 게임오버라는 걸 Cloudflare도 깨달았다는 뜻일 것임. 구축·기동 중인 데이터센터 안에 누군가 자리 잡는 데 성공하면 회사가 끝날 수 있는 사건임
      데이터센터 구축 초반에는 모든 스위치와 장비가 기본값 또는 빈 root 비밀번호(admin/admin)를 쓰고, 펌웨어도 오래되어 취약점이 많다는 점도 기억해야 함. 자동화가 전체 펌웨어를 패치하기 전에 이런 공격이 벌어졌다면, “모든 장비를 반품하고 제조사가 새 장비를 보내게 하자” 수준의 사건임
    • “제조사의 포렌식 팀이 모든 시스템을 검사했고 접근이나 지속성이 없음을 확인했다. 아무것도 발견되지 않았지만 그래도 하드웨어를 교체했다”라니, 오래된 신뢰 하드웨어 교체 트릭이군
    • 내가 본 DEFCON 발표 수가 많지는 않지만, 그 정도까지는 당연히 했을 것 같음
    • 침해에 대한 핵폭탄급 대응은 표준 업무 관행이어야 하고, 거기서 벗어나는 게 예외여야 함
      증명 가능한 접근 범위만 공격자가 접근했다고 가정하면, 공격자가 살아남을 구멍을 남기는 셈임. 이걸 하지 않아도 된다고 말하려면 여러 명의 정족수 승인이 필요해야 함
      물론 이상적인 세계의 얘기임. 우리 팀이 직접적인 금전적·사용자 이득이 없는 기능을 구현할 시간을 부여받는 건 다행이라고 생각함
    • 그래서 오래된 보안 운영·기업 보안 담당자들이 탁상훈련에 그렇게 집착하고, Twitter의 BadThingsDaily†가 훌륭한 것임
      이런 종류의 자격 증명 회전을 실행할 준비를 갖추려면 규율과 준비가 필요하고, 솔직히 대부분의 팀은 그 투자를 하지 않음. 똑똑하고 자원도 많은 팀들도 마찬가지임
      Cloudflare 보안팀이 모든 비밀을 회전하고 모든 머신을 재이미징하자고 결정할 수 있고, 그게 합리적인 시간 안에 실제로 일어난다면 꽤 인상적임
      † https://twitter.com/badthingsdaily?lang=en

  • 여기서 가장 놀라운 부분은 Cloudflare가 Bitbucket을 쓴다는 것임

    • 왜 놀라운지 모르겠음. 이미 쓰는 다른 Atlassian 제품들과 잘 통합됨
    • Jira와 다른 Atlassian 도구들과 통합되고, 결국에는 또 하나의 Git 서버일 뿐임
    • 그럴 수도 있고 아닐 수도 있음. 나는 Bitbucket을 좋아하지 않지만, 대기업 중에는 자기 사업 축 중 하나에서 경쟁사가 소유한 서비스를 쓰는 걸 걱정하는 곳이 꽤 있음
    • Scriptrunner for Jira가 얼마나 강력한지 궁금함. 보안 인증은 받았지만 얼마나 샌드박스 처리되어 있는지는 모르겠음
    • 아주 큰 회사들이 Bitbucket을 많이 씀. GitLab/GitHub보다 훨씬 비용 효율적이기 때문임

  • 데이터 유출은 한 번 밖으로 나가면, 이번 경우엔 소스 코드가 영구히 밖에 있는 셈이고 누가 가져가는지 전혀 통제할 수 없음
    사고 후 강화는 원하는 만큼 할 수 있고 그걸 아무리 말해도, 막으려던 일은 이미 벌어졌음. 풀어 버린 달걀은 다시 되돌릴 수 없음

    • 동의함. 이건 Cloudflare에 꽤 큰 사건이라고 봄. 특히 Confluence 문서까지 결합되면 향후 계획과 설계, 조직도, 회의록이 들어 있을 가능성이 큼
      오래된 코드에서는 다른 이스터에그도 찾을 수 있음. 거의 모든 회사에는 문서화되지 않은 백도어가 있음
      고객 데이터 유출이 더 나쁘긴 하겠지만, 이것도 정말 좋지 않음
    • 그래서 요점이 뭐임?
    • 내년의 소스 코드는 올해의 소스 코드와 같지 않음
      내년의 고객 데이터도 올해의 고객 데이터와 같지 않음

  • Atlassian의 Confluence에서는 내장 Apache Lucene 검색 엔진만으로도 민감 정보가 새어 나갈 수 있고, 이런 접근은 추적·식별이 매우 어려울 수 있음
    민감 정보가 검색 결과 페이지에 이미 표시된다면 공격자는 Confluence 페이지를 열 필요조차 없음

  • “서비스 토큰 하나와 계정 세 개는 사용되지 않는다고 잘못 믿어 회전하지 않았다”는 대목이 이상함. 사용하지 않는 자격 증명은 회전이 아니라 삭제해야 할 가능성이 큼

    • 이건 이상한 냄새가 남. 누가 그 특정 자격 증명들을 회전하지 않기로 했는지 살펴볼 것 같음
      “이 계정들은 뭐지?” “아, 안 쓰는 거야. 로그에도 안 나와” “그래도 회전해야지” “아니, 침해됐을지도 모르는 예전 자격 증명을 가진 임의 계정들을 그냥 두자… 이유는 뭐 대충 있고” 같은 상황인가?
    • 동의함. 이 글 전체가 “나는 피해자다”처럼 읽히지만, 눈덩이처럼 커진 단 하나의 실수는 인정하지 않음

  • Okta 사고 뒤에 유출된 자격 증명을 회전했다면, 그 위에 허니팟을 걸어 두고 공격자들이 뭘 하는지 기다렸어야 한다고 봄
    허니팟은 발각될까 봐 공격자가 계속 진행하지 못하게 만드는 효과도 있음

답변달기