[보안칼럼] 랩서스 공격으로 드러난 관제 사각지대
지난 3월 남미의 해킹조직 랩서스가 MS, 엔비디아, 옥타, 삼성전자 등 글로벌 대기업을 공격해 화제가 됐다. 이들은 기업 기밀을 탈취한 후 돈을 주지 않으면 정보를 유출하겠다는 협박을 자행했고, 텔레그램 등을 통해 행적을 과시하는 대담함을 보였다.
보안 관계자가 충격을 받은 지점은 랩서스가 보안이 견고하다고 알려진 다수 기업을 너무나 쉽게 침투했다는 사실이다. 이들 기업은 인증도 단순 암호가 아닌 다중 인증(MFA)을 사용했을 뿐만 하니라 방화벽, 침입탐지시스템, 엔드포인트 위협 탐지 및 대응 (EDR), 매체제어 솔루션 등 수많은 보안 계층을 유지했다. 그런데 어떻게 이런 보안 계층을 모두 우회했을까.
공통적으로 드러난 주목할 만한 특징은 사회공학적 기법 사용이다. 이를 통해 인증을 우회하고 임직원으로 위장해서 상대적으로 감시가 취약한 SaaS 서비스와 퍼블릭, 프라이빗 클라우드를 공략했다. 이러한 사실은 옥타가 침해 사실을 부인하자 랩서스는 텔레그램을 통해 세부 사항을 밝히며 반박한 대목에서 나타난다.
이는 광범위하게 사용되는 슬랙(Slack)과 같은 협업 툴의 공개된 채널에서 임직원이 AWS 크리덴셜을 공유하는 행위가 전혀 모니터링 및 조처되지 않고 있음을 의미한다. AWS와 슬랙을 사용하고 있다면 같은 사례가 존재하지 않는지 AKIA로 검색해 보길 바란다.
랩서스는 익스체인지 온라인의 메일 플로 룰을 변경해서 숨은 참조로 모든 메일을 포워딩하고 내부 정보를 획득했다. 오피스 365의 중요 변경 사항에 대한 보안 감사를 수행하는 조직은 아직 매우 드물 것이다.
랩서스는 또 셰어포인트(SharePoint), 컨플루언스(Confluence), 지라(JIRA), 깃허브(GitHub) 등 다양한 SaaS 서비스를 탐색하며 민감한 정보에 접근하고 더 높은 계정의 크리덴셜을 확보했다. 정보 유출을 완료한 후에는 프라이빗 클라우드의 가상머신을 삭제하는 파괴적 행위를 한 후 침해대응 팀이 어떻게 움직이는지 관찰하는 여유로움마저 보였다.
이 모든 과정을 돌아보면 통합보안관제 체계가 전통 종심방어 모델에 함몰된 게 얼마나 위험한지 깨닫게 된다. 코로나19는 재택근무와 SaaS 도입을 가속화했고, 기업의 중요한 정보 자산은 더 이상 내부에만 존재하지 않게 됐다. 그러나 전통적 통합보안관제 시스템은 여전히 DDoS, 방화벽, IPS, 웹방화벽 위주의 네트워크 관제 체계에 갇혀 있고 SaaS 역시 데이터 통합에 필요한 감사 API를 제공하는 서비스는 아직까지 소수인 것이 현재 직면한 현실이다.
SaaS의 경우 IT나 보안 부서가 아닌 현업 부서에서 직접 도입해 사용하는 경우가 많다. 세일즈포스에는 민감한 매출 정보가 많은데 이에 대한 보안은 누가 책임져야 할까. 영업이나 재무팀일까, 보안팀일까“ HR팀이 도입해서 사용하는 그리팅에는 많은 개인정보가 집적돼 있는데 누가 어떤 이력서에 접근하고 있는지 모니터링할 수 있을까?
현업을 담당하든 보안을 담당하든 SaaS 서비스를 개발하든 우리는 이제 SaaS 보안 문제에 대해 깊이 검토하고 해결해 나가야 한다. 정보 보안은 우리 모두의 책임이기 때문이다.
현업의 역할은 명확하다. 사내에 보안 조직이 있다면 SaaS 도입 시 보안관제 체계에 통합될 수 있도록 검토 프로세스에 포함해야 한다.
만약 별도 보안 조직이 없다면 권한과 정보 공유를 필수 범위로 최소화하는 원칙을 세우고 준수하자. 그렇게 해야만 SaaS 서비스에 내부자 공격이 들어왔을 때 피해 범위를 최소화 할 수 있게 된다.
IT 및 보안 역할도 있다. 재택근무와 SaaS 전환으로 인해 전에 없던 많은 공격 경로가 생성됐을 수 있다. SaaS 및 클라우드 침해 발생 시 리스크를 종합적으로 검토해 보고 보안운영 플랫폼에 SaaS 및 클라우드 감사 로그를 통합해 인증 이상 징후, 취약점, 내부 정보 공개 노출, 중요 구성 변경에 대해 모니터링해야 한다.
SaaS 서비스는 감사 API 기능 제공에 높은 비용을 책정하는 경향이 있는데 침해 사고가 발생하면 서비스 공급자도 책임을 피해 갈 수 없다.
자체 로그 저장 비용이 문제라면 최소한 고객 소유의 오브젝트 스토리지에 저장 혹은 웹훅 등을 통해서 외부 시스템에 감사 데이터를 통합할 수 있는 기능을 제공해야 한다. 사용자 인증이나 OAuth 애플리케이션 인증 기록은 필수적이다. 정보 조회 등 행위 이력이 모두 기록되면 가장 좋지만, 주요 설정 변경에 대해 통지하는 것만으로도 많은 문제를 예방할 수 있다.
보안운영플랫폼 역할도 필요하다. 관제시스템은 전통적 온프레미스 위주의 보안관제에서 벗어나 새로운 시대적 요구에 부응해야 한다. 온프레미스 환경에 보안관제시스템을 구축했다 하더라도 SaaS 서비스의 구성 정보 및 감사 로그를 취합해서 경보 및 대응 조치를 적시에 수행할 수 있도록 API 통합을 서둘러야 한다.
특히 사회공학적 기법을 사용한 침투는 정상행위와 잘 구분되지 않는 내부자 유출 탐지와 유사한 문제이기 때문에 외부침해관제(SIEM)와 내부유출탐지(UEBA)가 하나로 통합된 보안관제 체계를 제공해야 문제를 해결할 수 있다.
오래 전부터 알려져 있듯이, 보안 시스템은 딱 '가장 약한 연결 고리' 수준의 힘을 갖는다. 공격자는 이미 공개출처 정보 (OSINT), 임직원 매수, 다크웹 크리덴셜 구매, SIM 스와핑 등 다양한 수단을 이용하여 인증 절차를 우회하고 있다.
따라서 내부 접속을 신뢰하지 않는 제로트러스트 기반의 접근 방법이 필요하며 공동의 노력을 통해 SaaS라는 관제의 사각지대를 해소해야만 당면한 문제를 해결하고 공격자의 침투를 훨씬 더 어렵게 만들 수 있다.
보안 로그만을 기반으로 알려진 위협에 대응하는 전통적인 보안관제체계에서 SaaS를 포함한 IT 운영 및 보안 전 영역의 데이터를 보안운영(SecOps) 플랫폼에 통합할 때 궁극적으로 알려지지 않은 위협에 포괄적으로 대비할 수 있다.
아직 SaaS 관제 통합에 대해 완전한 해답을 찾은 조직이나 벤더는 없지만 SaaS 데이터 통합의 필요성에 대한 공동체 인식이 곧 문제 해결의 첫걸음이 될 것이다.
[https://www.etnews.com/20220607000249](https://www.etnews.com/20220607000249)
2022-06-09
