데이터 침해 ‘극과 극’… 모범·최악 대응 사례 5가지

같은 데이터 침해 사건이라도 어떻게 대응하느냐에 따라 다르다. 차이는 실수를 인정하고 재빨리 움직이느냐, 아니면 실수를 부인하고 어물쩍 대처하느냐에 있다. 
 

원칙적으로 따지자면 모든 기업은 데이터 침해를 대비해 보안 조치를 마련해놓아야 한다. 침해 사건이 발생했을 때 대응 방안에 대한 상세한 계획도 수립해야 하며, 정기적으로 시뮬레이션을 해봐야 실전에 대응할 수 있다. 

이제는 사고 대응 방안에 관한 모범 사례가 업계 전반에 잘 확립되어 있다. 사이버 보안 트레이닝 업체 노비포(KnowBe4)의 데이터 드리븐 보안 전도사(data-driven defense evangelist) 로저 그라임스는 “기본적 데이터 침해 대책이 갖추어져 있다고 함은 적시 적소에, 투명하게 피해자와의 소통할 수 있다는 뜻이다. 이해 관계자에게 향후 공격을 막기 위해 어떤 절차를 밟을 예정인지 확실하게 알려줄 수 있어야 한다”라고 말했다. 

그러나 전 헤비급 파이터 마이크 타이슨은 "모든 사람은 그럴듯한 계획을 세운다. 얼굴에 정통으로 펀치를 맞을 때까지 말이다"라고 말했다. 즉, 기업이 정작 데이터 침해 사건을 당하면 모든 계획이 수포가 되는 경우도 종종 있다.

이미 엎질러진 물을 주워담을 수는 없으니 이럴 때 중요한 건 어떻게 대응하느냐다. 데이터가 유출됐음에도 허술하게 대응한 조직 3곳과 책임감을 가지고 투명하게 조처를 한 조직 2개를 소개한다. 
 

최악 1: 캐시 앱(Cash App)

직원이 퇴사할 때 민감한 고객 데이터에 대한 접근을 차단하지 않는 것만으로도 큰 실수다. 그렇다면 2021년 12월, 데이터 침해를 발견하고도 2022년 4월 미국 증권거래위원회(SEC)에 해당 사안을 제출할 때까지 위반 사실을 숨기는 건 어떨까. 

모바일 결제 업체 캐시앱(Cash App)를 제공하는 회사 블록(Block)의 이야기다. SEC에 제출된 서류에 따르면 회사에 근무하는 동안 고객 계정 데이터에 정기적으로 접근한 직원이 "고용이 끝난 후에도 허가 없이" 해당 데이터에 접근했다. 

블록에 따르면 다운로드 된 820만 명의 고객 데이터에 포함된 정보는 사용자 이름, 비밀번호, 주민등록번호, 은행 계좌 정보 등이 아니었다. 현금 앱 투자에서 사용자의 주식 활동을 식별하는 데 사용되는 이름과 중개 계좌 번호였다. 

서류에 따르면 "거래일 동안 증권 포트폴리오 가치, 증권 포트폴리오 보유 및/또는 주식 거래 활동 등의 정보가 유출됐다." 

블록은 어떻게 이런 일이 일어났는지, 그리고 이를 공개하는 데 오랜 시간이 걸린 이유에 관해 완전한 설명을 내놓지 못한 상황이다. 

투자자들은 2022년 8월 블록의 '방임' 행위로 손해배상을 청구하는 집단소송을 제기했다. 투자자들은 일부 고객이 알 수 없는 요금을 청구 당했으며, 캐시앱이 데이터 침해 사실을 알리지 않아 “제때 공개했다면 피할 수 있었던” 피해를 초래했다고 주장했다. 

소송에서 투자자들은 블록이 데이터 침해 피해자들에게 뒤늦게 보낸 통지가 “늦었을 뿐 아니라 어설펐다”라고 주장했다. 이런 혐의는 법정에서 입증되지 않았다. 블록은 이전 직원이 어떻게 고객 정보에 접근할 수 있었는지, 데이터가 암호화되어 있었는지, 혹은 어떻게 위반 사실을 알게 되었는지에 대한 세부 사항을 제공하지 않았다. 블록은 또한 데이터를 침해당한 당사자에게 신용 또는 신원 도용 모니터링 서비스를 제공하지도 않았다. 
 

모범 1: 국제 적십자 위원회(ICRC)

해커 집단은 주로 학교와 병원을 겨냥한다. 그래서 2021년 말 적십자사를 강타한 사이버 공격은 큰 충격이었다. 공격자들은 전쟁과 자연재해로 가족과 떨어진 51만 5천 명의 이름, 주소, 연락처가 들어있는 데이터베이스에 접속했다.

적십자사는 분개했다. 로버트 마르디니 ICRC(International Committee of the Red Cross) 사무총장은 이번 공격에 대해 "인류에 대한 모욕"이라고 신랄하게 비판하며 해커들에게 데이터를 악용하지 말라고 공개 요청했다. 그 외에도 적십자사의 대응은 신속하고, 투명하며, 처음부터 끝까지 모든 것을 책임졌다. 
 

적십자사는 재빠르게 데이터 침해 사건과 대응을 설명하는 긴 FAQ를 웹사이트에 게시했다. 즉시 손상된 서버를 오프라인으로 전환했으며, 2단계 인증과 첨단 위협 탐지 등 보안 조치를 강화하고 외부 침투 테스트를 진행한 뒤에야 가족을 위한 복구 서비스를 재개했다.

게다가, 적십자사는 전화, 핫라인, 공고, 편지, 그리고 어떤 경우에는 사람들에게 직접 알리기 위해 팀을 멀리 떨어진 지역 사회에 보내기까지 했다. 피해를 본 모든 사람과 접촉하기 위해 특별한 노력을 기울였다. 

무엇보다 적십자사는 해킹 수법에 관해 매우 자세한 설명을 내놓았다. 사이보 보안 컨설턴트가 ICRC 서버에서 이상 징후를 처음 발견한 것이 사건의 발단이었다. 조사 결과 2021년 11월 9일 해킹이 발생해 해커들이 2개월 이상 기관 시스템 내부에 있다가 적발된 것으로 파악됐다.

기본적으로 해커는 인증 모듈의 패치되지 않은 중요한 취약점을 침투했다. 이를 통해 관리자 자격 증명을 얻어 수평 이동을 수행했고, 레지스트리 하이브(registry hive)와 액티브 다이렉토리 파일을 유출했다. 해커들은 자신을 합법적인 사용자나 관리자로 위장해 암호화된 데이터에 접근했다. 

적십자사는 “ICRC 서버에 실행하도록 설계된 코드를 발견했다. 이는 해커가 적십자사를 직접 공격 대상으로 노렸다는 뜻이다”라고 말했다. 기관은 또한 “패치 적용은 사이버 보안의 기본이지만 제때 패치를 적용하지 못했다”라며 잘못을 시인했다. 

적십자는 계속해서 최신 정보를 발표하고 있다. 기관은 "해커들과 어떠한 접촉도 하지 않았고 몸값 요구도 하지 않았다. 우리가 아는 한, 아직 탈취된 개인 정보는 공개되거나 거래되지 않았다”라고 밝혔다. 
 

최악 2: 라스트패스

데이터 침해 사건의 심각성과 책임을 논할 때 정상 참작을 적용해야 할까? 예컨대 시골에 있는 작은 학교가 랜섬웨어 공격을 받으면 IT 팀이 자원이 부족할 가능성이 큼으로 어느 정도 눈을 감아줘야 할까?

또 반대의 경우라면 어떨까? 만약 어떤 회사의 사업 자체가 사용자의 비밀번호를 보호하는 것이라면, 이 회사가 해킹당했을 때 더 가혹하게 심판해야 할까? 

이미 눈치챘는지 모르겠지만, 바로 라스트패스의 이야기다. 2022년 8월 처음 발견된 사건은 애플리케이션 개발 환경에만 국한된 사소한 문제로 시작했다. 그러나 12월에 회사 이름, 최종 사용자 이름, 청구 주소, 이메일 주소, 전화 번호 및 IP 주소를 포함한 고객 데이터가 유출되는 사건이 발생했다. 



일단 투명도 측면에서 회사는 높은 점수를 받을만하다. 회사는 8월 이후 계속해서 공개 업데이트를 발표했다. 그러나 각각의 업데이트는 이전 진술의 정확성에 대한 의문을 제기했다. 몇 가지 기본적인 보안 프로세스에 문제가 있어 보인다는 지적이 나왔다. 
 

2022년 8월 25일, 라스트패스 CEO 카림 투바가 라스트패스 개발 환경 내에서 비정상적인 활동을 감지했다고 발표했다. 라스트패스는 공격자가 일부 소스 코드를 훔쳤으나 고객들에게 상황 정리가 끝났다며 "더 이상의 무단 활동 증거는 없다"라고 장담했다.

하지만 11월 30일, 라스트패스는 해커가 8월 사건에서 얻은 정보를 사용해 백업 클라우드 서비스에 저장된 고객 정보에 접근했다는 보안 업데이트를 발표했다. 회사는 고객에게 암호가 안전하게 암호화되었음을 다시 한번 강조했다. 

안타깝게도 상황은 더 나빠졌다. 12월 22일, 라스트패스는 공격자가 클라우드 기반 백업에 저장된 고객 데이터에 접근하고, 암호를 해독하는 데 사용된 자격 증명과 키를 얻기 위해 8월에 도난당한 정보를 다른 직원을 대상으로 사용했다는 사실을 인정해야 했다. 라스트패스는 고객이 방문한 웹사이트 URL이 암호화되지 않았다는 점도 인정해야 했다.

라스트패스는 고객들이 기본 마스터 비밀번호를 사용한다면 해커들이 비밀번호를 알아내기 위해 무차별 암호 대입 공격을 수행해도 소용없을 것이라며 사용자를 안심시켰다. 마스터 비밀번호는 다른 모든 비밀번호에 대한 접근을 제어하는 가장 중요한 비밀번호며, 기본 마스터 비밀번호란 라스트패스가 자동으로 생성해주는 안전한 비밀번호다. 

그러나 고객이 기본 마스터 암호를 사용하지 않았다면 이러한 주장은 무용지물이 된다. 라스트패스는 "마스터 암호를 직접 만들었다면 무차별 대입 공격으로 발견될 가능성이 커진다”라며 “이런 경우에는 다른 웹사이트의 비밀번호를 변경해 추가 피해를 예방하는 수밖에 없다"라고 말했다. 

라스트패스는 또한 위협 행위자가 피싱 공격, 크리덴셜 스터핑(credential stuffing) 또는 기타 무차별 대입 공격을 수행할 수 있다고 경고했다. 

회사는 고객에게 계속해서 어떤 조치를 취하고 있는지 알렸다. 해킹된 개발 환경을 해체하고 처음부터 새로 구축했으며, 주요 관리 엔드포인트 탐지 및 대응 벤더와 같이 이차 방어선을 구축했다. 승인되지 않은 이상 작업이 탐지되면 기록되며 경보를 전송하는 시스템을 갖췄다.

노비포(KnowBe4)의 그라임스는 라스트패스가 이미 돌아갈 수 없는 강을 건넜다고 말했다. “라스트패스는 항상 저장된 고객 데이터가 안전하다고 말했다. 데이터 침해 사건이 일어났을 때 비밀번호 데이터는 안전하다는 게 밝혀졌지만 로그인 아이디, 웹 사이트 링크 및 기타 고객별 개인 정보는 유출된 것으로 드러났다”라며 “해커에 손에 이런 정보가 들어갔다면 사용자가 방문하는 사이트를 해커가 훤히 들여다볼 수 있다. 자주 방문하는 웹사이트를 활용해 개인맞춤형 피싱 공격을 하기도 쉽다. 게다가 마지막으로 라스트패스가 제일 중요한 마스터 비밀번호에 여전히 약한 비밀번호를 허용한다는 허점이 드러난 셈이다”라고 말했다. 
 

모범 1: 랙스페이스(Rackspace)

관리형 클라우드 서비스 제공업체 랙스페이스는 2022년 12월 플레이(PLAY) 사이버 범죄 집단의 교묘한 랜섬웨어 공격을 받았다고 발표했다. 이 해킹의 여파로 3만 명이 넘는 고객의 MS 익스체인지 계정이 잠겼으며, 사용자들은 몇 주 동안 이메일을 쓸 수 없었다. 
 

랙스페이스의 대응은 신속했다. 문제를 발견하자마자 익스체인지 연결을 끊었다. 정황을 밝히고자 보안업체 크라우드스트라이크에 도움을 요청했다. 얼마 지나지 않아 호스팅된 익스체인지 비즈니스 서비스를 영원히 종료할 것이라 밝히고, 고객이 오피스 365로 이전하도록 지원할 계획이라 밝혔다. 정말 발 빠른 대응이 아닐 수 없다. 

크라우드스트라이크 조사 결과 랙스페이스는 프록시노트셸(ProxyNotShell) 익스플로잇에 대응하는 첫 번째 패치 하나를 설치했었다. 두 번째 패치도 있었는데, 이 패치가 정말 필요한지는 아직 명확히 밝혀지지 않았다. 결과적으로 랙스페이스는 두 번째 패치를 설치하지 않았으며 해커들은 두 가지 취약점을 통해 익스체인지 서버에 접근할 수 있었다. 

업계 베테랑 폴 로비쇼는 “랙스페이스는 거의 완벽한 모범 사례다. 사건의 자초지종을 낱낱이 공개하고, 크라우드스트라이크를 고용해 사건의 경위를 파헤치기 위해 최선을 다했으며, 그 결과를 투명하게 밝혔다”라며 랙스페이스를 호평했다. 
 

최악 3: 잭스 투자 리서치(Jacks Investment Research)

잭스 인베스트먼트 리서치는 미국에서 가장 큰 독립 주식, ETF 및 뮤추얼 펀드 리서치 제공업체 중 하나다. 무려 82만 명의 고객에게 영향을 미친 데이터 유출 사태를 겪었다. 데이터 침해는 2021년 11월부터 2022년 8월까지 무려 9개월 동안 진행됐다. 회사는 12월 말까지 침해 사실을 알아차리지 못하고 2023년 1월이 돼서야 긴급 성명을 발표했다. 
 

현재까지 잭스 인베스트먼트 리서치는 유출된 데이터에 웹사이트에 사용된 이름, 주소, 전화번호, 이메일 주소, 비밀번호가 포함되어 있다는 것 외에는 다른 정보를 밝힌 바 없다. 다만 회사는 유출된 데이터가 1995년과 2005년 사이 웹사이트에 가입했던 오래된 고객 정보라고 해명했다. 해킹된 계정의 접근을 차단해 고객이 비밀번호를 재설정하도록 하는 조치를 취했다. 또한 회사는 영향받은 고객에게 신용 모니터링 서비스를 제공하지 않을 것이라 밝혔다. 

그라임스는 “암호가 유출되었다는 사실을 알아차리고 고객에게 알리는 데 한달이나 걸렸다는 사실은 쉽게 넘어가기 힘들다”라며 “어떤 고객이든 자신의 개인 정보가 유출됐다면 최소한 며칠이나 몇 주 안에 알기를 원할 것”이라고 말했다. ciokr@idg.co.kr