솔루션 컨설턴트인 저는 일반적으로 어떤 문제를 볼 때 기술적인 측면, 구체적으로는 솔루션과 기능 측면에서 먼저 생각합니다. ‘ID 위협 탐지 및 대응(Identity Threat Detection and Response, ITDR)’이라는 용어를 처음 접했을 때도 마찬가지였습니다.
ITDR은 무엇이고 왜 존재하며, 실제로 어떻게 작동할까요? 이번 포스팅에서 자세하게 살펴보겠습니다.
ITDR이란?
ITDR은 ID를 주요 공격 벡터로 인식하고 이를 방어하는 데 필요한 프로세스와 도구를 정의합니다. 가트너는 2022년 ITDR이라는 용어를 처음 사용하면서 “ID 시스템을 보호하기 위한 위협 인텔리전스, 베스트 프랙티스, 지식 기반, 툴 및 프로세스를 포괄하는 보안 분야로, 탐지 메커니즘을 구현하고 의심스러운 상태 변화와 활동을 조사하고 공격에 대응하여 ID 인프라의 무결성을 복원하는 방식으로 작동한다”라고 설명했습니다.
ITDR이 중요한 이유
저는 ITDR을 세부적으로 살펴보면서 ITDR이 중요한 이유와 그 작동 방식을 이해하는 데 도움이 되는 3가지 중요한 점을 알게 되었습니다.
1) ID는 복잡하며, 자체적인 보안 영역이 필요하다
약 25년 전 제가 정보기술 분야에서 처음 일을 시작했을 당시에는 많은 조직이 보안과 네트워크팀을 동일시했습니다. 네트워크팀은 오래전부터 방화벽과 네트워크 패킷 검사 기술을 통해 공격자의 침입을 막아왔습니다. 이것이 바로 네트워크 기반 위협을 탐지하고 대응하는 방법을 기술하는 ‘네트워크 탐지 및 대응(Network Detection and Response, NDR)’ 분야입니다.
점점 많은 컴퓨팅이 네트워크 경계의 바깥에서 수행되기 시작하면서 엔드포인트(워크스테이션, 노트북 또는 모바일 기기)는 공격자가 빈번하게 악용하는 표적이 됐습니다. 여기서도 마찬가지로 ‘엔드포인트 탐지 및 대응(Endpoint Detection and Response, EDR)’이라는 보안 영역이 등장했습니다. EDR은 엔드포인트를 보호하기 위한 툴과 프로세스, 베스트 프랙티스 모음입니다.
지금은 ID가 새로운 경계입니다. 조직은 사용자가 위치와 기기에 관계없이 애플리케이션과 데이터에 액세스하도록 하고 있으며, 여기서는 사용자의 ID가 액세스를 위한 핵심적인 통제 수단입니다. 사용자 ID와 이런 ID를 관리하는 인프라에 대한 공격이 증가한 것은 자연스러운 일이었습니다.
오늘날 ID 플랫폼 보호의 어려움에 대해 생각해 보십시오. 적어도 대부분 조직은 인증 및 권한 부여를 제공하는 2개의 핵심 디렉토리 서비스인 마이크로소프트 액티브 디렉토리(Active Directory, AD)와 애저 액티브 디렉토리(Azure Active Directory)를 운영합니다. 그게 전부가 아닐 수 있습니다. 자체 ID가 있는 레거시 메인프레임 또는 *nix 기반 시스템, 레드햇이나 오라클과 같은 LDAP 디렉토리, 구글 워크스페이스 또는 옥타(Okta) 같은 클라우드 기반 ID도 있습니다.
이들 시스템은 서로 상당히 다릅니다. 각기 고유한 구조와 컨트롤이 있고 감사 및 위협 신호도 고유합니다. 또한 디렉토리는 마이크로소프트 애저 AD 커넥트(Microsoft Azure AD Connect)와 같은 특정 툴셋을 사용해서 다른 디렉토리와 동기화되도록 구성되는 경우가 많으며, 이로 인해 복잡성이 더욱 커집니다.
디렉토리 시스템은 많은 보안 신호를 생성합니다. AD가 대표적인 예입니다. 내장된 보안 이벤트 로그, 이벤트 로그와 별개로 AD를 감사/분석하는 소프트웨어(예를 들어, 퀘스트의 체인지 오디터(Change Auditor) 또는 ID용 마이크로소프트 디펜더(Microsoft Defender for Identity)), 이런 신호를 분석해서 ‘더 높은 수준의’ 신호를 생성하는 소프트웨어(예를 들어 퀘스트의 온디멘드 오디트(On Demand Audit))가 있습니다. 또한 라이선스 수준에 따라 보안 신호가 달라질 수 있는 애저 AD도 있습니다. 기본 Azure AD에는 기본 감사 및 보안 신호가 있고 Azure AD 프리미엄 P2에는 통합 위험 계산이 추가됩니다.
많은 조직은 이런 디렉토리 플랫폼을 관리하기 위해 온갖 종류의 3글자로 된 기술을 추가합니다. IAM(Identity and Access Management), 그 확대집합인 IGA(Identity Governance Administration), 특권에 중점을 둔 PAM(Privilege Access Management) 등이 있습니다. 이들 시스템은 디렉토리의 일부 또는 전체 관리에 사용할 수 있으며, 디렉토리 내에서 일부 ID만 담당하는 경우도 많습니다. 가령 IGA 시스템은 서비스 ID(소프트웨어, 관리형 서비스 계정 또는 Azure AD ‘엔터프라이즈 애플리케이션’을 통해 자동화된 방식으로 사용되는 사용자)를 관리하지 않는 경우가 많으며, PAM 시스템은 일반적으로 소프트웨어에 사용되는 관리 계정과 사용자 계정만 관리합니다. 또한 각 시스템에는 자체적인 감사 및 보안 인텔리전스 신호가 있고 대응 및 완화 기능도 제각기 다릅니다.
이게 전부가 아닙니다. 그 외에도 MFA(Multi-factor Authentication)을 제공하기 위한 시스템, CIEM(Cloud Infrastructure Entitlement Management), SOAR(Security Orchestration, Automation, and Response) 시스템 등 훨씬 많은 시스템이 있습니다. 이런 모든 플랫폼은 사용자 ID를 관리하고 보호하는 데 중요한 역할을 하지만, 그 자체가 공격 표적이 되어 역설적으로 조직의 위험 표면을 증가시킬 수 있습니다.
2) ID 복잡성에도 강점은 있다
ID에 관여하는 이렇게 많은 시스템으로 인한 어려움을 감안하면, 한 업체의 솔루션이나 기술 스택으로 통합하고 싶은 생각이 들 수 있습니다. 각양각색의 플랫폼과 감사 신호, 대응 방법을 최대한 단순화하는 것이 합리적이지 않을까요?
그렇지 않습니다. 다음과 같은 이유 때문입니다.
우선, 모든 달걀을 한 바구니에 담는 것은 한 시스템에서 침해가 발생했을 때 신뢰할 수 있는 다른 ID가 없다는 의미입니다. 모든 ID 침해에서 첫 번째 단계는 다양한 디렉토리를 상호 격리하는 것입니다. AD가 침해된다면 애저 AD 커넥트를 종료해서 이메일이 계속해서 작동하도록 해야 할 것입니다.
다양성의 강점은 ID 툴을 위한 지원 시스템에도 적용됩니다. 비로 여러 툴셋을 관리하는 것이 수월하지는 않지만, ID 인프라는 워낙 특정적이고 복잡해서 동종 최고의 솔루션을 활용하는 편이 합리적인 경우가 많습니다. 예를 들어, AD 복구 프로세스는 특정 솔루션에 맡기는 편이 가장 좋습니다.
ITDR을 특정 솔루션, 심지어 솔루션의 범주로 생각하지 말고, 많은 플랫폼 및 툴셋 간에 연결 조직을 제공하는 영역이라고 생각하는 것이 좋습니다.
3) NIST 사이버 보안 프레임워크는 ITDR 이해에 도움이 된다
퀘스트는 고객을 위해 해결하는 문제를 설명하기 위해 NIST 사이버 보안 프레임워크를 참조하는 경우가 많은데, 이 프레임워크는 ID 보안에서 ITDR이 채워야 하는 공백을 이해하는 데도 도움이 됩니다. NIST 프레임워크는 다음의 5가지 요소로 구성됩니다.
식별(Identify) – 기존 정책을 평가하여 취약점을 찾고 위험을 파악합니다.
보호(Protect) – 위험을 제한하기 위한 예방적 통제 수단을 마련합니다.
탐지(Detect) – 보안 및 감사 신호에서 문제를 찾습니다.
대응(Respond) – 감사 신호에 따라 조치를 취합니다.
복구(Recover) – 영향을 받은 서비스 또는 기능을 복원합니다.
ID 위협 ‘탐지’ 및 ‘대응’이라는 이름에서 짐작할 수 있듯이 ITDR은 NIST 프레임워크의 처음 2가지 요소인 ‘식별’과 ‘보호’에 대해서는 그다지 관심을 두지 않습니다. 그렇다고 해서 이 2가지가 중요하지 않다는 뜻은 아니며, 모든 조직은 효과적인 ITDR 프로그램의 피드백을 받아 ID 솔루션을 더욱 잘 분석하고 제어하는 데 사용해야 합니다.
ITDR 프로그램은 탐지 대상을 정의하는 프레임워크를 제공합니다
제가 잘 아는 플랫폼인 AD로 구체적인 예들 들자면, ITDR 프로그램은 플랫폼별 ITDR 툴을 사용해서 AD 그룹 정책(Group Policy) 인프라의 오용을 탐지하고 경고하는 기능을 제공할 수 있습니다. 그룹 정책은 강력하면서 복잡한 시스템 관리 기능으로, AD ID 플랫폼에 긴밀하게 통합돼 있는 공격자의 일반적인 집중 공격 대상입니다. ITDR 툴은 GPO(Group Policy Object) 변경과 이런 변경이 영향을 미칠 수 있는 ID를 탐지하는 기술적 기능을 제공합니다.
ITDR 프로그램은 대응 방법을 결정하는 프레임워크를 제공합니다
문제될 가능성이 있는 신호가 발견되면 누가 조사하나요? 대답하기 어려운 질문입니다. ID 시스템의 복잡성으로 인해 하나의 팀이 모든 관련 기술의 주제별 전문가가 될 수는 없기 때문입니다. AD 전문가라도 애저 AD에 대해서는 전문가가 아닐 수 있고, 2요소 인증에 집중하는 리소스와 같이 각 전문 영역에는 하위 분야도 존재할 수 있습니다. 이 글에서 예로 든 그룹 정책의 경우 대응 흐름은 AD와 그룹 정책의 플랫폼 소유자를 참여시키는 것일 수 있습니다. 이들은 ITDR에 다음 단계가 무엇인지를 포함한 자체적인 프레임워크를 정의했을 수 있습니다. 여기에는 다음에 누구에게 알릴지에 대한 정보는 확실히 포함되며, AD와 애저 AD 간의 ID 동기화 비활성화와 같은 구체적인 완화 지침도 포함될 수 있습니다.
ITDR 프로그램은 IT 시스템과 프로세스를 복구/복원하는 프로세스를 정의합니다
ITDR 프로그램에는 복구의 기술적 측면과 복구 의사 결정을 누가 내려야 하는지에 대한 내용이 모두 포함됩니다. 이 예에서 복구는 GPO 거버넌스 소프트웨어를 사용해서 GPO를 이전 버전으로 복원하거나 AD 복구 솔루션을 사용해 백업에서 복구하는 것일 수 있습니다. ITDR 프로그램에는 간단한 개별 ID 복구부터 전체 ID 플랫폼 복구에 이르기까지 모든 것을 포괄하는 절차가 있어야 합니다.
결론
ITDR이 새로운 기술 범주가 아니라 기술과 제도화된 베스트 프랙티스, 프로세스를 활용해서 ID에 대한 최신 위협을 탐지하고 대응하기 위한 강력한 수단임을 이해하는 데 이번 포스팅이 도움이 되었기를 바랍니다.
복잡한 ID 관리에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다.
솔루션 컨설턴트인 저는 일반적으로 어떤 문제를 볼 때 기술적인 측면, 구체적으로는 솔루션과 기능 측면에서 먼저 생각합니다. ‘ID 위협 탐지 및 대응(Identity Threat Detection and Response, ITDR)’이라는 용어를 처음 접했을 때도 마찬가지였습니다.
ITDR은 무엇이고 왜 존재하며, 실제로 어떻게 작동할까요? 이번 포스팅에서 자세하게 살펴보겠습니다.
ITDR이란?
ITDR은 ID를 주요 공격 벡터로 인식하고 이를 방어하는 데 필요한 프로세스와 도구를 정의합니다. 가트너는 2022년 ITDR이라는 용어를 처음 사용하면서 “ID 시스템을 보호하기 위한 위협 인텔리전스, 베스트 프랙티스, 지식 기반, 툴 및 프로세스를 포괄하는 보안 분야로, 탐지 메커니즘을 구현하고 의심스러운 상태 변화와 활동을 조사하고 공격에 대응하여 ID 인프라의 무결성을 복원하는 방식으로 작동한다”라고 설명했습니다.
ITDR이 중요한 이유
저는 ITDR을 세부적으로 살펴보면서 ITDR이 중요한 이유와 그 작동 방식을 이해하는 데 도움이 되는 3가지 중요한 점을 알게 되었습니다.
1) ID는 복잡하며, 자체적인 보안 영역이 필요하다
약 25년 전 제가 정보기술 분야에서 처음 일을 시작했을 당시에는 많은 조직이 보안과 네트워크팀을 동일시했습니다. 네트워크팀은 오래전부터 방화벽과 네트워크 패킷 검사 기술을 통해 공격자의 침입을 막아왔습니다. 이것이 바로 네트워크 기반 위협을 탐지하고 대응하는 방법을 기술하는 ‘네트워크 탐지 및 대응(Network Detection and Response, NDR)’ 분야입니다.
점점 많은 컴퓨팅이 네트워크 경계의 바깥에서 수행되기 시작하면서 엔드포인트(워크스테이션, 노트북 또는 모바일 기기)는 공격자가 빈번하게 악용하는 표적이 됐습니다. 여기서도 마찬가지로 ‘엔드포인트 탐지 및 대응(Endpoint Detection and Response, EDR)’이라는 보안 영역이 등장했습니다. EDR은 엔드포인트를 보호하기 위한 툴과 프로세스, 베스트 프랙티스 모음입니다.
지금은 ID가 새로운 경계입니다. 조직은 사용자가 위치와 기기에 관계없이 애플리케이션과 데이터에 액세스하도록 하고 있으며, 여기서는 사용자의 ID가 액세스를 위한 핵심적인 통제 수단입니다. 사용자 ID와 이런 ID를 관리하는 인프라에 대한 공격이 증가한 것은 자연스러운 일이었습니다.
오늘날 ID 플랫폼 보호의 어려움에 대해 생각해 보십시오. 적어도 대부분 조직은 인증 및 권한 부여를 제공하는 2개의 핵심 디렉토리 서비스인 마이크로소프트 액티브 디렉토리(Active Directory, AD)와 애저 액티브 디렉토리(Azure Active Directory)를 운영합니다. 그게 전부가 아닐 수 있습니다. 자체 ID가 있는 레거시 메인프레임 또는 *nix 기반 시스템, 레드햇이나 오라클과 같은 LDAP 디렉토리, 구글 워크스페이스 또는 옥타(Okta) 같은 클라우드 기반 ID도 있습니다.
이들 시스템은 서로 상당히 다릅니다. 각기 고유한 구조와 컨트롤이 있고 감사 및 위협 신호도 고유합니다. 또한 디렉토리는 마이크로소프트 애저 AD 커넥트(Microsoft Azure AD Connect)와 같은 특정 툴셋을 사용해서 다른 디렉토리와 동기화되도록 구성되는 경우가 많으며, 이로 인해 복잡성이 더욱 커집니다.
디렉토리 시스템은 많은 보안 신호를 생성합니다. AD가 대표적인 예입니다. 내장된 보안 이벤트 로그, 이벤트 로그와 별개로 AD를 감사/분석하는 소프트웨어(예를 들어, 퀘스트의 체인지 오디터(Change Auditor) 또는 ID용 마이크로소프트 디펜더(Microsoft Defender for Identity)), 이런 신호를 분석해서 ‘더 높은 수준의’ 신호를 생성하는 소프트웨어(예를 들어 퀘스트의 온디멘드 오디트(On Demand Audit))가 있습니다. 또한 라이선스 수준에 따라 보안 신호가 달라질 수 있는 애저 AD도 있습니다. 기본 Azure AD에는 기본 감사 및 보안 신호가 있고 Azure AD 프리미엄 P2에는 통합 위험 계산이 추가됩니다.
많은 조직은 이런 디렉토리 플랫폼을 관리하기 위해 온갖 종류의 3글자로 된 기술을 추가합니다. IAM(Identity and Access Management), 그 확대집합인 IGA(Identity Governance Administration), 특권에 중점을 둔 PAM(Privilege Access Management) 등이 있습니다. 이들 시스템은 디렉토리의 일부 또는 전체 관리에 사용할 수 있으며, 디렉토리 내에서 일부 ID만 담당하는 경우도 많습니다. 가령 IGA 시스템은 서비스 ID(소프트웨어, 관리형 서비스 계정 또는 Azure AD ‘엔터프라이즈 애플리케이션’을 통해 자동화된 방식으로 사용되는 사용자)를 관리하지 않는 경우가 많으며, PAM 시스템은 일반적으로 소프트웨어에 사용되는 관리 계정과 사용자 계정만 관리합니다. 또한 각 시스템에는 자체적인 감사 및 보안 인텔리전스 신호가 있고 대응 및 완화 기능도 제각기 다릅니다.
이게 전부가 아닙니다. 그 외에도 MFA(Multi-factor Authentication)을 제공하기 위한 시스템, CIEM(Cloud Infrastructure Entitlement Management), SOAR(Security Orchestration, Automation, and Response) 시스템 등 훨씬 많은 시스템이 있습니다. 이런 모든 플랫폼은 사용자 ID를 관리하고 보호하는 데 중요한 역할을 하지만, 그 자체가 공격 표적이 되어 역설적으로 조직의 위험 표면을 증가시킬 수 있습니다.
2) ID 복잡성에도 강점은 있다
ID에 관여하는 이렇게 많은 시스템으로 인한 어려움을 감안하면, 한 업체의 솔루션이나 기술 스택으로 통합하고 싶은 생각이 들 수 있습니다. 각양각색의 플랫폼과 감사 신호, 대응 방법을 최대한 단순화하는 것이 합리적이지 않을까요?
그렇지 않습니다. 다음과 같은 이유 때문입니다.
우선, 모든 달걀을 한 바구니에 담는 것은 한 시스템에서 침해가 발생했을 때 신뢰할 수 있는 다른 ID가 없다는 의미입니다. 모든 ID 침해에서 첫 번째 단계는 다양한 디렉토리를 상호 격리하는 것입니다. AD가 침해된다면 애저 AD 커넥트를 종료해서 이메일이 계속해서 작동하도록 해야 할 것입니다.
다양성의 강점은 ID 툴을 위한 지원 시스템에도 적용됩니다. 비로 여러 툴셋을 관리하는 것이 수월하지는 않지만, ID 인프라는 워낙 특정적이고 복잡해서 동종 최고의 솔루션을 활용하는 편이 합리적인 경우가 많습니다. 예를 들어, AD 복구 프로세스는 특정 솔루션에 맡기는 편이 가장 좋습니다.
ITDR을 특정 솔루션, 심지어 솔루션의 범주로 생각하지 말고, 많은 플랫폼 및 툴셋 간에 연결 조직을 제공하는 영역이라고 생각하는 것이 좋습니다.
3) NIST 사이버 보안 프레임워크는 ITDR 이해에 도움이 된다
퀘스트는 고객을 위해 해결하는 문제를 설명하기 위해 NIST 사이버 보안 프레임워크를 참조하는 경우가 많은데, 이 프레임워크는 ID 보안에서 ITDR이 채워야 하는 공백을 이해하는 데도 도움이 됩니다. NIST 프레임워크는 다음의 5가지 요소로 구성됩니다.
식별(Identify) – 기존 정책을 평가하여 취약점을 찾고 위험을 파악합니다.
보호(Protect) – 위험을 제한하기 위한 예방적 통제 수단을 마련합니다.
탐지(Detect) – 보안 및 감사 신호에서 문제를 찾습니다.
대응(Respond) – 감사 신호에 따라 조치를 취합니다.
복구(Recover) – 영향을 받은 서비스 또는 기능을 복원합니다.
ID 위협 ‘탐지’ 및 ‘대응’이라는 이름에서 짐작할 수 있듯이 ITDR은 NIST 프레임워크의 처음 2가지 요소인 ‘식별’과 ‘보호’에 대해서는 그다지 관심을 두지 않습니다. 그렇다고 해서 이 2가지가 중요하지 않다는 뜻은 아니며, 모든 조직은 효과적인 ITDR 프로그램의 피드백을 받아 ID 솔루션을 더욱 잘 분석하고 제어하는 데 사용해야 합니다.
ITDR 프로그램은 탐지 대상을 정의하는 프레임워크를 제공합니다
제가 잘 아는 플랫폼인 AD로 구체적인 예들 들자면, ITDR 프로그램은 플랫폼별 ITDR 툴을 사용해서 AD 그룹 정책(Group Policy) 인프라의 오용을 탐지하고 경고하는 기능을 제공할 수 있습니다. 그룹 정책은 강력하면서 복잡한 시스템 관리 기능으로, AD ID 플랫폼에 긴밀하게 통합돼 있는 공격자의 일반적인 집중 공격 대상입니다. ITDR 툴은 GPO(Group Policy Object) 변경과 이런 변경이 영향을 미칠 수 있는 ID를 탐지하는 기술적 기능을 제공합니다.
ITDR 프로그램은 대응 방법을 결정하는 프레임워크를 제공합니다
문제될 가능성이 있는 신호가 발견되면 누가 조사하나요? 대답하기 어려운 질문입니다. ID 시스템의 복잡성으로 인해 하나의 팀이 모든 관련 기술의 주제별 전문가가 될 수는 없기 때문입니다. AD 전문가라도 애저 AD에 대해서는 전문가가 아닐 수 있고, 2요소 인증에 집중하는 리소스와 같이 각 전문 영역에는 하위 분야도 존재할 수 있습니다. 이 글에서 예로 든 그룹 정책의 경우 대응 흐름은 AD와 그룹 정책의 플랫폼 소유자를 참여시키는 것일 수 있습니다. 이들은 ITDR에 다음 단계가 무엇인지를 포함한 자체적인 프레임워크를 정의했을 수 있습니다. 여기에는 다음에 누구에게 알릴지에 대한 정보는 확실히 포함되며, AD와 애저 AD 간의 ID 동기화 비활성화와 같은 구체적인 완화 지침도 포함될 수 있습니다.
ITDR 프로그램은 IT 시스템과 프로세스를 복구/복원하는 프로세스를 정의합니다
ITDR 프로그램에는 복구의 기술적 측면과 복구 의사 결정을 누가 내려야 하는지에 대한 내용이 모두 포함됩니다. 이 예에서 복구는 GPO 거버넌스 소프트웨어를 사용해서 GPO를 이전 버전으로 복원하거나 AD 복구 솔루션을 사용해 백업에서 복구하는 것일 수 있습니다. ITDR 프로그램에는 간단한 개별 ID 복구부터 전체 ID 플랫폼 복구에 이르기까지 모든 것을 포괄하는 절차가 있어야 합니다.
결론
ITDR이 새로운 기술 범주가 아니라 기술과 제도화된 베스트 프랙티스, 프로세스를 활용해서 ID에 대한 최신 위협을 탐지하고 대응하기 위한 강력한 수단임을 이해하는 데 이번 포스팅이 도움이 되었기를 바랍니다.
복잡한 ID 관리에 어려움을 겪고 계시거나 관련 솔루션에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어코리아로 문의주시기 바랍니다.