리스트로 사고하는 방어자들, 그래프로 사고하는 공격자들 (2015)

• 네트워크 방어는 자산을 나열하고 우선순위를 매기는 데서 출발하지만, 실제 공격 표면은 자산 간 보안 의존성 그래프로 형성됨
• 공격자는 가장 강한 자산을 정면 공격하기보다, 약하게 보호된 워크스테이션이나 관리 경로를 따라 고가치 자산의 우회 경로를 찾음
• Windows 네트워크에서는 로그온 방식, 자격 증명, Kerberos TGT, NTLM 해시, 공통 로컬 관리자 암호, 로그온 스크립트 같은 요소가 모두 그래프의 간선이 될 수 있음
• 방어자는 자산 목록을 그래프로 바꾸고, 인프라 분할·자격 증명 사일로·권한 최소화·2단계 인증·자격 증명 순환으로 연결성을 줄여야 함
• 공격자는 오래된 다이어그램이 아니라 실제 인프라를 조각별로 학습하므로, 방어자는 현재 네트워크의 연결 관계를 더 정확히 파악해야 우위를 가질 수 있음

---

목록으로 보는 방어가 놓치는 것

• 많은 네트워크 방어는 공격자와 접촉하기 전부터 전장을 잘못 이해하면서 어긋남
• 방어자는 자산을 보호하고, 우선순위를 정하고, 워크로드와 비즈니스 기능별로 정렬하는 데 집중함
• 시스템 관리 서비스, 자산 인벤토리 데이터베이스, BCDR 스프레드시트에는 자산 목록이 넘쳐남
• 하지만 실제로 방어자가 다뤄야 하는 것은 개별 자산 목록이 아니라, 자산들이 보안 관계로 연결된 그래프임
• 공격자는 스피어피싱(spearphishing) 같은 기법으로 그래프의 어느 지점에 착지한 뒤, 취약한 시스템을 찾아 네트워크 안을 이동함
• 이 그래프는 외부에서 주어진 것이 아니라 네트워크를 설계하고 운영하는 방어자 자신이 만듦

네트워크 안의 그래프가 의미하는 것

• 네트워크의 그래프는 자산 사이에 동등성 클래스를 만드는 보안 의존성의 집합임
• 그래프에 영향을 주는 요소는 크게 네 가지임
  • 네트워크 설계
  • 네트워크 관리 방식
  • 네트워크에서 쓰는 소프트웨어와 서비스
  • 사용자의 행동
• 도메인 컨트롤러 사례에서는 약한 관리 경로 하나가 고가치 자산 전체의 보안 수준을 낮춤
  • Bob이 워크스테이션에서 도메인 컨트롤러를 관리함
  • 해당 워크스테이션이 도메인 컨트롤러만큼 보호되지 않으면, 도메인 컨트롤러도 침해될 수 있음
  • Bob의 워크스테이션에 관리자 권한을 가진 다른 계정도 Bob과 도메인 컨트롤러를 침해할 수 있음
  • 그 관리자들은 업무상 하나 이상의 다른 머신에 로그온함
  • 공격자가 그중 하나를 침해하면 도메인 컨트롤러로 가는 경로가 생김

Six Degrees of Mallory: 그래프를 따라가는 측면 이동

• 공격자는 침해한 머신에서 대기하며 mimikatz 같은 암호 덤퍼로 고가치 계정의 로그온을 기다릴 수 있음
• 예시 그래프의 왼쪽 클러스터는 수백 명의 사용자가 쓰는 단일 Terminal Server임
  • 공격자가 이 머신을 침해하면 시간이 지나며 많은 사용자의 자격 증명을 덤프할 수 있음
• 그래프 검색을 통해 High Value Asset으로 향하는 여러 경로가 드러남
  • Terminal Server 침해로 User46과 User128도 침해 가능해짐
  • User46은 Machine2821의 관리자이고, User128은 Machine115의 관리자임
  • 해당 워크스테이션을 침해하면 User1과 User34를 침해할 수 있음
  • User1과 User34는 모두 High Value Asset의 관리자임
• High Value Asset을 보호하려면 여기에 의존하는 모든 요소가 High Value Asset만큼 철저히 보호되어야 하며, 이들이 하나의 동등성 클래스를 이룸

보안 의존성을 만드는 관계들

• Windows 네트워크에서 사용자가 Interactive, Terminal Server 등 특정 로그온을 수행하면, 기반 호스트가 침해됐을 때 사용자의 자격 증명이 도난에 노출됨
  • 노출 대상에는 자격 증명뿐 아니라 Kerberos TGT, NTLM 해시 같은 싱글 사인온 동등물이 포함됨
• 보안 의존성은 일상적인 관리 관계에서도 만들어짐
  • 공통 암호를 쓰는 로컬 관리자 계정: 한 시스템에서 로컬 관리자 암호를 덤프한 뒤, 같은 암호를 쓰는 다른 호스트에 사용할 수 있음
  • 많은 사용자에게 실행되는 로그온 스크립트를 담은 파일 서버와 소프트웨어 업데이트 서버
  • 사용 시 클라이언트 머신에 프린트 드라이버를 전달하는 프린트 서버
  • 스마트카드 로그온에 유효한 인증서를 발급하는 인증기관
  • 권한 있는 사용자로 실행되는 데이터베이스 서버 컨텍스트에서 코드를 실행할 수 있는 데이터베이스 관리자
• 간접 관계도 그래프의 일부가 됨
  • 취약점이 있는 머신이 침해되면 공격자가 그래프에 새 간선을 만들 수 있음
  • 사용자가 신뢰 관계가 없는 두 도메인에 같은 암호의 계정을 갖고 있으면 도메인 사이에 숨은 간선이 생김

그래프를 줄이는 방어 방법

• 방어자의 첫 단계는 자산 목록을 그래프로 바꿔 네트워크를 시각화하는 것임
• 이후 큰 연결성 폭발을 만드는 원치 않는 간선을 찾아 그래프를 가지치기해야 함
  • 인프라 분할과 자격 증명 사일로를 구현함
  • 관리자 수를 줄이고, Just-In-Time / Just Enough 기법으로 권한을 최소화함
  • 특정 간선 이동을 완화하기 위해 2단계 인증을 사용함
  • 사용자 계정 침해에 대비해 견고한 자격 증명 순환 방식을 적용함
  • forest trust 관계를 재검토함

공격자보다 나은 현실 모델 만들기

• 방어자는 전장을 시각화할 때 공격자에게 우위를 넘겨주지 않아야 함
• 방어자는 자신의 네트워크에 대한 전체 정보를 가질 수 있지만, 공격자는 네트워크를 조각별로 학습해야 함
• 공격자는 부정확한 정신 모델, 불완전한 자산 인벤토리 시스템, 오래된 네트워크 다이어그램이 아니라 현재 존재하는 인프라를 연구함
• 방어자도 현실을 기준으로 네트워크를 관리해야 준비된 방어자 사고방식에 가까워짐

더 읽을거리

• Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph: J. Dunagan, D. Simon, A. Zheng
• Two Formal Analyses of Attack Graphs: S. Jha, O. Sheyner, J. Wing
• Using Model Checking to Analyze Network Vulnerabilities: P. Ammann, R. Ritchey
• A Graph-Based System for Network-Vulnerability Analysis: C. Phillips, L. Swiler
• Automated Generation and Analysis of Attack Graphs: J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
• Modern Intrusion Practices: Gerardo Richarte
• Attack Planning in the Real World: Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute

[GN⁺]

Hacker News 의견들

• 공격자는 보통 한 가지 임무, 예를 들어 중요한 데이터 유출, 대상 불안정화, 랜섬웨어 같은 목표를 갖고 있으며, 임무를 달성할 때까지 필요한 만큼 깊게 탐색할 수 있음
  반면 방어자는 동시에 많은 신호와 위협 벡터를 추적해야 하므로 목록으로 사고할 수밖에 없고, 규제 때문에 조치해야 하는 항목까지 우선순위를 매겨야 함
  그래프 곳곳에 방어자가 임의로 배치되어 흥미로운 활동을 찾는 식이 아니라면, 방어자가 어떻게 그래프로 사고할 수 있을지 모르겠음. 글쓴이가 제안한 것들도 결국 방어자가 대조해야 할 목록 속 신호가 될 뿐임

  • 이에 동의하지 않음. 내 경험상 레드팀은 고가치 자산으로 가는 경로를 그리기 위해 반복적으로 그래프 기법을 썼고, 방어자는 그런 접근을 전혀 생각하지 못하고 있었음
    방어자가 그 방식을 도입하자 레드팀이 실행하기 전에 잠재 공격을 식별할 수 있었음. 똑똑한 팀은 예를 들어 AWS를 그래프로 크롤링해 낮은 가치 계정에서 높은 가치 계정으로 가는 경로를 찾는 레드팀 기술을 바로 채택할 것임
    제로섬이나 대전환의 문제는 아니지만, 방어자도 공격자처럼 더 많이 사고하고 공격자 도구를 방어에 더 자주 활용할 수 있음
  • 자동차 보호를 예로 들면, 자동차 소프트웨어에 대한 공격은 무수히 많지만 가장 흔한 공격자의 목표는 차량 절도임
    그러면 그 목표로 가는 경로를 보호해야 하고, 그 경로가 어떻게 생겼는지 또는 소프트웨어에 국한되는지와는 무관함
    공격자가 CVE를 악용해 엔터테인먼트 시스템을 서비스 거부 상태로 만들 수도 있겠지만, 실제로 그런 일이 얼마나 중요한지는 의문임
  • “공격자는 보통 한 가지 임무를 갖고 있다”는 건 흔한 오해임
    실제 공격의 대다수는 “무엇을 찾을 수 있는지 둘러보고, 그걸 어떻게 쓸지는 나중에 보자”에 가까움. 정보 수집, 영향 공작, 선전 같은 많은 공격 활동도 마찬가지임

• 방어자가 목록을 쓰는 이유는 수백, 수천 개의 자산을 동시에 관리해야 하기 때문임. 많은 것을 관리해야 할 때는 목록을 만들고, 그 목록을 훑고, 점검표를 적용하게 됨
  물론 방어자도 의존성 그래프를 만들어야 하지만, 먼저 목록을 만들고 최신 상태인지, 제한적 신뢰를 가정하는지, 리소스가 격리되어 있는지 확인한 다음 의존성 그래프를 만들어야 함
  방어자는 목록과 그래프를 모두 생각하며 엄청난 수의 항목을 관리해야 하고, 공격자는 몇 가지만 보면 됨

  • 달리 말하면, 자산의 그래프 작성은 점검표의 일부여야 함
  • 이 시나리오에서는 목록이 그래프의 기반이라고 말하는 셈인데, 그 자체가 글쓴이의 요지이며 방어자가 문제에 접근하는 방식에서 미묘하지만 중요한 차이임
    목록을 그래프로 전환할 통찰이 없으면, 결국 핵심 자산 목록만 들고 자신이 고려하지 못한 수만 가지 접근 경로를 두더지 잡기식으로 막게 됨
  • 결국 너비와 깊이의 차이임

• 이 글은 너무 깊이 들어간 느낌임. 혹은 이유는 맞지만 원인은 틀렸을 수도 있음. 방어자의 일은 방어 자체가 아님
  사이버 보안은 명확하고 대등한 목표와 번갈아 맡는 포지션이 있는 스포츠 경기가 아니라, 방어자가 본업으로 하려는 다른 비즈니스 옆의 부대 행사이자 산만함에 가까움
  반대로 공격자의 일 전체는 시스템을 공격하는 것임. 공격을 약화시킬 다른 목적이나 부차적 주인, 고려사항이 없음
  공격자가 이기는 이유는 Microsoft가 Cisco보다 운영체제 출시를 더 잘하는 이유와 같음. Cisco에게 운영체제는 수단이지만, Microsoft에게는 목적임

  • 사이버 보안을 본행사 옆의 부대 행사로 보는 프레이밍이 훌륭함
    기업이 데이터 유출로 시장에서 거의 처벌받지 않는 이유도 설명해 줌
  • 대부분의 조직이 보안을 예산 목록의 맨 끝에 두는 것이 핵심 문제라고 봄
  • 방어자는 비용 센터이고 공격자는 수익 센터라는 식으로 보면 요지가 더 분명해짐
  • “공격자의 일 전체는 시스템을 공격하는 것이고, 다른 목적은 없다”는 건 꽤 심각한 오해로 보임
    사이버 공격에는 데이터 절도, 서비스 방해 등 분명한 목적이 있음. 그냥 부수고 혼란을 만들려는 미숙한 행위자에게는 맞을 수 있지만, 국가 행위자나 금전 동기의 범죄자를 고려하면 완전히 빗나간 관점임
  • 정확히 맞음. 근본적인 비대칭성도 있음. 방어자는 모든 것을 맞혀야 하지만, 공격자는 취약점 하나만 찾으면 됨. 대개는 인간 행동 기반의 취약점임

• 이 글은 오히려 충분히 깊게 들어가지 않은 느낌임 :-)
  “목록”은 구성요소의 축약 표현이고, “그래프”는 상호운용의 축약 표현임. 구성요소 관점은 분석이고, 상호작용 관점은 아직 좋은 단어가 없지만 글에서 말하듯 종종 공격 표면이 됨
  복잡 적응계는 구성요소와 메시지 버스를 갖고, 이 버스가 구성요소들이 상호운용할 방법을 제공한다는 점이 중요함. 개미를 하나씩 잡을 수도 있지만, 정말 막으려면 페로몬 흔적을 남기는 능력을 없애야 함
  상호운용 방식을 이해하는 데도 “분석” 같은 단어가 있으면 좋겠음. Gestaltysis 같은 것?

• 잠깐 사이버 보안 회사에서 일한 적이 있는데, 왜 그 제품이 싫었고 그 회사와 업계 상당 부분의 접근이 결국 가짜처럼 느껴졌는지 말로 표현하지 못했음
  이제 알겠음. 우리는 사이버 보안에서 가장 쓸모없는 실천, 즉 조직 수준의 점검표를 지원하는 도구를 만들고 있었음

  • 그래도 점검표를 못 하면 다른 것도 할 수 없음
    모든 활동의 중심에는 목록과 반복 일정이 있음. 정기적으로 나타나서 해야 할 일을 해야 함
    물론 그 “해야 할 일” 단계에서는 더 깊고 나은 접근이 필요하다는 데 동의함
  • 그게 거의 전체 사이버 보안 업계임. 회사들은 일이 터졌을 때 손가락질할 방폭문 같은 용도로 이런 도구를 삼
    “우리는 모든 점검표를 따랐고 보안 소프트웨어가 잡지 못했으니 우리 잘못이 아니다”라고 말하기 위한 것임
    회사가 보안을 진짜로 신경 쓴다면 신호 대 잡음비가 1% 미만인 쓸모없는 스캐너에 돈을 내는 대신 레드팀을 고용할 것임
  • 점검표가 왜 존재하는지, 해야 할 일을 얼마나 정확히 모델링하는지, 얼마나 엄격히 따르는지에 달렸을 수 있음
    항공을 보면 조종사는 점검표에 의존해 살아감. 비행 중 문제가 절대 생기지 않는다는 보장은 아니지만, 점검표를 따르지 않거나 가볍게 대하는 건 재난을 부르는 일임. 그런 점검표는 수년간의 값비싼 경험 위에 만들어짐
    다만 단지 “점검표가 있다”고 말하기 위해 존재하거나, 현실 조건에 맞춰 정기적으로 검토하고 갱신하지 않는 점검표는 무의미함
  • 더 정교하게 말하면, 운영 보안은 보안 태세를 강화할 수 있지만 사이버 보안의 진짜 요령은 조치를 도입하는 것만이 아니라 시간이 지나도 유지하는 데 있음. 바로 거기서 점검표가 필요해짐
    많은 회사가 이걸 잘못 이해함. 점검표 자체가 보안이라고 생각하지만, 실제로 점검표는 예전에 제대로 한 일을 계속 유지하라고 상기시키는 도구일 뿐임. 점검표를 목표처럼 다루는 순간 길을 벗어남

• 침투 테스터 입장에서 말하면, 공격자도 꼭 그래프로 사고하지는 않음
  BloodHound를 제외하면 그래프를 쓰는 도구가 잘 떠오르지 않음
  웹 보안에서도 “그래프 사고”가 적용되는 것이 생각나지 않음. 대신 테스트할 공격 목록은 매우 큼: https://portswigger.net/web-security/all-topics
  그리고 침투 테스트 보고서 안에 결국 들어가는 건 그래프가 아니라 할 일 목록임. 예를 들면 SMB 서명, 모든 머신을 관리하는 데 도메인 관리자 계정을 쓰지 말 것, 기타 등등
  이 문구가 인기 있는 주된 이유는 해커 커뮤니티의 자존심을 건드리기 때문임. “우리는 똑똑한 쪽이고, 방어자는 엑셀 시트만 만진다”는 식임
  다만 진실의 조각은 있음. 방어자는 별로 중요하지 않은 일에 상당한 시간을 쓸 수 있음. 모든 서버에 CIS 벤치마크를 손으로 적용하는 동안, 강한 보안 태세를 만들어 줄 낮은 매달린 과일을 놓치는 식임
  많은 회사에서 방어자는 무엇에 집중해야 할지 모르는 시스템 관리자일 뿐임

  • 요지는 이해하지만, 침투 테스터도 웹 보안을 포함해 충분히 그래프로 사고할 수 있다고 봄
    바로 떠오르는 예가 버그 체인임. CVSS 4~7 수준 취약점 몇 개를 묶으면 완전한 원격 코드 실행 같은 9.8급 결과로 바뀔 수 있음. 이런 버그 연결은 본질적으로 침해 요소를 통한 그래프 순회임
    BloodHound는 훌륭하고, 공격 그래프를 개념화하기 좋은 시각 도구지만, 공격자 관점에서 대상 도메인을 이해하는 과정의 일부일 뿐임
    웹 침투 테스트에는 BloodHound 같은 깔끔한 도구가 없는 이유가, 침해 체인을 단순히 도구 형태로 환원하기 어렵기 때문임. AD는 보안 경계가 어느 정도 이해되고 코드화되어 있지만, 웹 앱의 체인은 기반 프레임워크보다 해당 애플리케이션에 특화되는 경우가 많음
    침투 테스트 보고서에 SMB 서명이나 “DA 계정으로 전부 관리하지 말 것” 같은 항목이 들어가는 건, 그것들이 침해 체인의 매우 초기에 뜨겁게 빛나는 노드이기 때문임. 현실에서 자주 그런 식으로 털림
    침투 테스터가 그래프 사고를 이해하지 못해서라기보다는, 그래프의 첫 노드가 사실상 완전한 침해를 의미하니 더 순회할 이유가 없는 경우에 가까움

• 이건 방어자가 모든 진입점을 지켜야 하는 반면 공격자는 약점 하나만 찾으면 된다는 말을 멋있게 바꾼 것에 가까움

  • 격언처럼 최고의 방어는 좋은 공격임. Microsoft와 Google도 조직적 해킹 그룹을 방해하는 보안 프로젝트를 갖고 있지만, 더 나아가야 할 수도 있음
    예를 들어 허니팟을 사용해 제로데이 익스플로잇을 공격자 장비로 되먹임하는 방식도 가능하지 않을까 함. Google, Microsoft 등의 제품에 의도적으로 설계된 것일 수도 있음
    일종의 그럴듯한 부인 가능성을 둔 채 완전히 블랙햇처럼 가서, 랜섬웨어 공격자에게 랜섬웨어를 먹이는 식임
    쓰다 보니 SF에 나오는 사악한 전능 기업 같아 보이는데, 그런 기업들은 보통 적 암살까지 하긴 함
  • 말하자면 방어의 비대칭성임

• 사고 대응도 해봤고 침투 테스트와 레드팀 경험도 있음. 축약된 표현이긴 하지만 어느 정도 맞고, 글이 말하는 것만큼 부정적일 필요는 없다고 봄
  방어는 여러 요소로 이뤄짐. 예를 들어 보안 사건의 위험과 영향을 줄이는 효과적인 통제 개발, 공격과 침해 식별, 사건 대응이 있음. 표준과 대응의 목록은 잘 작동함
  방어에는 이런 통제를 설계하기 위해 네트워크 그래프를 생각해야 하는 아키텍처 결정도 포함됨. 방어 분야도 아키텍처/엔지니어링, 위험 관리, 사고 대응, 애플리케이션 보안, 교육, 위협 인텔리전스 등 다양함
  글쓴이가 방어를 목록으로 사고하는 게 문제라고 암시한 다음, 방어 개선을 위해 고려할 항목의 목록을 제시했다는 점도 흥미로움

• 공격자가 이기는 이유는 약점을 찾은 뒤 한 번만 성공하면 되기 때문임. 방어자는 모든 것을 동시에 지켜야 함

• 각 네트워크에는 침입자를 잡기 위한 허니팟이 하나 이상 필요해 보임. 가짜 암호화폐 자격 증명, 가짜 비밀번호 저장소 같은 것들이 해당됨