7월, 모르고 있었다는 사실이 가장 큰 사고였던 한 달

안녕하세요, 베이스스톤 구독자님! 👋

이번 달은 국내에서 유독 씁쓸한 소식이 있었어요. 바로 외교부 해킹 사고인데요, 침해 자체보다 그 침해를 10개월 가까이 아무도 몰랐다는 사실이 더 충격적이었습니다. 오늘은 이 사고를 중심으로 7월 한 달의 국내외 보안 이슈를 정리해봤어요 🔐

📌 오늘의 글, 한눈에 요약해보기

• 🇰🇷 외교부, 제로데이 취약점으로 국립외교원 서버 장악당해 외교관 등 최대 1만 명 개인정보 유출 — 침해는 작년 4~5월부터, 발견은 올해 2월, 공개는 7월 21일에야 이뤄져
• 일본 KDDI, 통신 고객 1,200만 명 규모 개인정보 유출
• SplitVPN, "노로그 정책"을 내걸었음에도 5,800만 건의 VPN 접속 로그가 그대로 노출
• 국내외 랜섬웨어 동향: Clop이 PTC 소프트웨어 취약점을 악용한 광범위 캠페인 전개, Fairlife(코카콜라 계열)는 랜섬웨어로 생산 라인까지 중단

🔍 무슨 일이 있었나

🇰🇷 외교부 해킹, 10개월을 몰랐던 침해

7월 21일, 외교부는 전현직 외교관과 재외공관 직원 등의 개인정보가 유출된 정황을 공식적으로 알렸습니다. 공격자는 소프트웨어 제조사조차 인지하지 못했던 제로데이 취약점을 악용해 국립외교원 온라인 교육 시스템 서버에 접근했고, 이름과 아이디, 이메일, 암호화된 비밀번호, 직책과 소속 부서 정보 등이 유출됐어요. 국가정보원 요원이나 국방부 무관 등 다른 부처 소속 인력의 정보도 함께 포함된 것으로 알려졌습니다. 다행히 주민등록번호나 휴대전화번호, 주소 같은 민감정보는 유출 항목에 포함되지 않았어요.

이 사고에서 가장 눈여겨봐야 할 대목은 시간이에요. 공격자는 작년 4~5월경 서버를 장악한 뒤 약 10개월 동안 수시로 접속했고, 외교부가 유출 정황을 처음 파악한 건 올해 2월이었습니다. 그런데 이 사실이 외부에 공개된 건 그로부터 다시 5개월이 지난 7월 21일이었어요. 외교부는 "해당 시스템과 기관이 국가안보와 무관하지 않기 때문"이라고 설명했지만, 발견 이후에도 5개월간 공개를 미뤘다는 점에서 늑장 대응이라는 비판을 피하기 어려웠습니다.

일본 KDDI, 1,200만 명 규모 통신 고객정보 유출

7월 8일에는 일본의 대형 통신사 KDDI에서 약 1,200만 명 규모의 고객정보가 유출된 사실이 확인됐습니다. 통신사가 보유한 고객 데이터의 특성상 유출 규모가 크고 파급력이 넓을 수밖에 없는 사고였어요. 같은 날 액센츄어에서도 소스코드를 포함한 데이터가 탈취되는 등, 7월 초부터 대형 기업들의 유출 소식이 잇따랐습니다.

"노로그"를 약속했던 VPN 업체의 로그 유출

7월 29일 공개된 SplitVPN 사고는 아이러니한 사례예요. 접속 기록을 남기지 않는다는 "노로그 정책"을 내세워온 VPN 서비스였지만, 실제로는 5,800만 건에 달하는 사용자 접속 로그가 그대로 노출된 것으로 드러났습니다. VPN처럼 프라이버시를 핵심 가치로 내세우는 서비스일수록, 실제 운영 방식이 약속과 일치하는지 검증하기가 더 어렵다는 걸 보여준 사고였어요.

랜섬웨어와 자격증명 탈취, 여전히 반복되는 패턴

7월에는 랜섬웨어 그룹 Clop이 PTC의 Windchill과 FlexPLM 소프트웨어 취약점을 악용해 광범위한 공격 캠페인을 벌였고, 코카콜라 계열 유제품 회사 Fairlife는 랜섬웨어 공격으로 생산 라인 운영까지 중단해야 했습니다. 스위스의 철도 제조사 Stadler Rail은 Anubis 랜섬웨어 조직으로부터 약 1억 2,300만 달러 규모의 몸값을 요구받았지만 지불을 거부했어요. 이 외에도 패스트푸드 체인 칙필레가 자격증명 스터핑 공격으로 1만 3천여 고객 계정이 무단 접근당했고, 회계 및 컨설팅 기업 EY는 ShinyHunters 그룹이 제3자 플랫폼을 침해해 직원 정보를 탈취하는 피해를 입었습니다.

🧭 왜 지금 중요한가

침해 사실을 아는 데 걸리는 시간이 피해 규모를 결정합니다

외교부 사고에서 실제 피해 항목(이름, 이메일, 직책 등)만 보면 상대적으로 제한적으로 보일 수 있어요. 하지만 10개월이라는 침해 기간과 5개월의 공개 지연을 더하면 이야기가 달라집니다. 얼마나 민감한 정보가 유출됐는지 못지않게, 그 침해를 얼마나 빨리 알아차렸는지가 사고의 실질적인 심각성을 좌우합니다.

"정책"과 "실제 운영"은 다른 이야기입니다

SplitVPN의 노로그 정책 사례는 좋은 교훈을 줘요. 정책 문서에 어떻게 쓰여 있는지와 실제 시스템이 어떻게 동작하는지는 별개의 문제라는 거예요. 특히 프라이버시나 보안을 핵심 가치로 내세우는 서비스일수록, 그 약속이 실제 아키텍처와 로그 관리 방식으로 뒷받침되고 있는지 주기적으로 검증할 필요가 있습니다.

소프트웨어 공급망의 취약점 하나가 광범위한 피해로 이어집니다

Clop의 PTC 소프트웨어 공격처럼, 특정 소프트웨어 하나의 취약점이 그 소프트웨어를 쓰는 모든 고객사로 피해가 번지는 구조는 계속 반복되고 있어요. 우리 조직이 사용하는 소프트웨어의 공급망 리스크를 정기적으로 점검하는 일이 갈수록 중요해지고 있습니다.

✅ 이번 달 사고에서 확인해야 할 4가지

• 우리 조직의 침해 탐지 체계가 마지막으로 몇 달 전부터 있었던 이상 징후를 잡아낸 적이 있는지, 탐지까지 걸린 평균 시간을 알고 있는가
• 침해를 인지한 시점부터 내부 보고, 경영진 보고, 외부 신고(KISA 등 법정 기한 24시간)까지 걸리는 시간을 실제로 시뮬레이션해본 적이 있는가
• 프라이버시나 보안을 핵심 가치로 내세우는 외부 서비스(VPN, 클라우드 저장소 등)를 쓰고 있다면, 그 서비스의 정책 문서와 실제 운영 방식이 일치하는지 최근에 검증한 적이 있는가
• 핵심 업무에 쓰이는 소프트웨어의 CVE 공지를 얼마나 빠르게(당일, 1주일, 1개월 등) 파악하고 패치를 적용하는지 최근 사례로 확인해봤는가

⚠️ 현장에서 자주 놓치는 지점

오래된 시스템일수록 모니터링에서 소외되기 쉽습니다

외교부 사고의 발단이 된 시스템은 온라인 교육 시스템이라는, 핵심 업무 시스템에 비해 상대적으로 관심이 덜한 영역이었어요. 하지만 공격자 입장에서는 조직 내부로 들어가는 또 하나의 문일 뿐입니다. 중요도가 낮아 보이는 시스템도 동일한 수준의 모니터링 대상에 포함돼야 하는 이유예요.

신고 지연의 이유가 항상 합리적으로 받아들여지지는 않습니다

국가안보 등 민감한 이유로 공개를 미루는 경우도 있지만, 그 판단이 조직 내부에서만 이뤄지고 외부에 설명되지 않으면 신뢰 문제로 이어지기 쉬워요. 지연이 불가피하다면 그 사유와 기준을 사전에 정리해두는 편이 사고 대응 단계에서 훨씬 유리합니다.

"침해의 심각성은 무엇이 유출됐는가보다, 그것을 알아차리는 데 얼마나 걸렸는가로 더 정확히 가늠할 수 있습니다." — Basestone Security Research Team

🚀 작게 시작하는 방법

가장 먼저 할 수 있는 건 우리 조직에서 상대적으로 관심이 덜한 시스템 목록을 뽑아보는 거예요. 온라인 교육 시스템, 사내 포털, 오래된 협업 도구처럼 "중요하지 않아 보이는" 시스템일수록 모니터링 공백이 있을 가능성이 높습니다.

지난달 있었던 인증과 접근 통제 관련 사고들도 함께 살펴보고 싶다면 정적 인증과 방치된 접근 권한이 부른 6월 보안 사고 총정리를 이어서 읽어보세요.