MTTD(평균 탐지 시간)는 사이버 보안 및 IT 운영 분야에서 보안 사고, 위협 또는 문제가 발생한 시점부터 이를 탐지하는 데 걸리는 평균 시간을 측정하기 위해 사용되는 핵심 성과 지표(KPI)입니다.
‘평균 식별 시간(MTTI)’ 및 ‘평균 탐지 시간(MTTD)’으로도 알려진 MTTD가 낮을수록 조직이 사고를 더 빠르게 식별하고 대응할 수 있음을 의미하며, 이는 잠재적 피해를 최소화하고 위험을 완화하는 데 매우 중요합니다.
기술에 대한 의존도가 높아짐에 따라, MTTD를 이해하고 개선하는 것은 비즈니스 중단 및 가동 중단 시간을 줄이고, 최종 사용자 경험을 향상시키며, 궁극적으로 수익성을 높이는 데 중요한 역할을 합니다.
MTTD를 정기적으로 추적하면 기존 보안 조치의 강점, 취약점 및 비효율성에 대한 귀중한 데이터 기반 통찰력을 얻을 수 있습니다.
이 글에서는 MTTD 지표와 그 중요성, 그리고 탐지 능력을 향상시키고 위협이 서비스 중단으로 확대되기 전에 이를 예측하고 예방하기 위해 활용할 수 있는 몇 가지 실질적인 조치와 관리 도구에 대해 살펴보겠습니다.
MTTD는 무슨 약자인가요?
MTTD는 ‘탐지까지의 평균 시간(Mean Time to Detect)’을 의미합니다. IT 사고 관리에서 이 핵심 지표는 비정상적인 활동을 발견하는 데 걸리는 평균 시간을 측정합니다.
MTTD를 추적하고 최소화하는 것은 다음과 같은 기존 보안 모니터링 및 사고 대응 역량의 효과를 파악하는 데 필수적입니다.
- 위협 탐지 프로세스의 속도와 효율성 평가
- 보안 운영에 대한 벤치마킹 및 지속적인 개선
- 기존 보안 통제 수단, 모니터링 솔루션 및 사고 대응 계획의 미비점이나 취약점을 파악합니다.
- 공격자가 탐지되지 않은 채 활동할 수 있는 총 시간을 제한함으로써, 데이터 손실, 최종 사용자의 업무 차질 및 시스템 손상을 잠재적으로 줄일 수 있습니다.
- 보안 프로그램의 성숙도 평가 및 개선
MTTD를 측정하는 것이 왜 중요한가요?
MTTD를 이해하는 것이 얼마나 중요한지 파악하기 위해 최근 발생한 공격 사례를 하나 살펴보겠습니다.
2024년 4월( )에 따르면, Dell은 무차별 대입 공격( )을 받아 결국 시스템이 침해당했습니다. The hacker, who goes by Menelik, sent over 5.000 requests a minute for nearly three weeks to a Dell partner portal page—more than 50 million requests.
델은 눈치채지 못했다. The hacker took 49 million customer records and then emailed Dell to let them know.
델은 웹 기반 공격을 탐지할 수 있는 포괄적인 보안 모니터링 시스템이 부족했거나, 해당 활동을 탐지하고 경고를 발령하도록 시스템을 구성하지 않았거나, 또는 사고 대응 및 데브옵스 팀이 오경보로 인해 과부하 상태에 빠져 경고를 놓쳤을 가능성이 있습니다.
델이 이 문제를 단발성 사건으로 간주한다면, 대응 방안은 취약점에 대한 패치 적용이나 비밀번호 정책 개선과 같은 임시방편에 집중될 가능성이 있다. 이러한 조치들이 메넬릭과 같은 향후 공격을 막을 수는 있겠지만, 근본적인 문제를 해결하지는 못할 것입니다. 더 나은 접근 방식은 각 팀의 평균 문제 해결 시간(MTTD)을 종합적으로 분석하여 사고 관리 프로세스의 추세를 파악하는 것입니다.
MTTR과 MTTD의 차이점은 무엇인가요?
, 평균 수리 시간(MTTR) 및 MTTD는 운영 효율성을 평가하는 데 필수적인 지표이지만, 각각 문제 대응 및 처리 과정의 서로 다른 측면을 측정하는 데 사용됩니다. 차이점은 다음과 같습니다:
- MTTR 은 문제 해결에 소요되는 시간을 측정하는 데 중점을 둡니다. MTTR이라는 약어는 종종 ‘평균 해결 시간(mean time to resolve)’이나 ‘평균 응답 시간(mean time to respond)’과 같은 다른 지표와 동의어로 사용됩니다.
그러나 ‘평균 해결 시간(mean time to resolve )’은 일반적으로 문제 탐지, 진단, 수리부터 서비스 복구에 이르는 전체 문제 해결 과정을 포괄합니다. 마찬가지로, 평균 문제 해결 시간( , )과 평균 대응 시간(,, )은 문제가 파악된 후 조직이 해당 문제에 대응하기까지 걸리는 시간을 측정합니다. - MTTD 는 사고 발생 시점부터 DevOps, IT, 사고 관리, 보안 운영 센터(SOC) 팀 등 관련 이해관계자가 이를 발견하기까지의 시간에만 초점을 맞춥니다. MTTD는 팀이 문제를 얼마나 신속하게 파악할 수 있는지에 중점을 두며, 특히 모니터링 및 경보 시스템의 효과성을 평가합니다.
MTTD와 관련된 두 가지 지표로는 평균 고장 시간(MTTF)과 평균 고장 간격(MTBF)이 있으며, 이를 통해 조직은 가동 시간과 관련된 문제를 파악할 수 있습니다:
- MTTF 는 수리할 수 없는 부품의 평균 수명을 측정하여, 팀이 부품 교체를 준비할 수 있도록 돕습니다.
- MTBF 는 수리 가능한 시스템이 정상적으로 작동하는 동안 시스템 고장 사이에 걸리는 평균 시간을 측정하는 지표입니다. 이 지표는 시스템의 전반적인 신뢰성을 나타냅니다.
이러한 지표들은 종합적으로 살펴볼 때, 조직의 사고 대응 프로세스, 사고 관리 전략, 시스템 안정성 확보 노력을 포괄적으로 파악할 수 있게 해주며, 대응 팀이 업무 흐름 최적화 및 인프라 개선이 필요한 부분을 파악하는 데 도움이 될 수 있습니다.
MTTD는 어떻게 계산하나요?
정확한 침입 탐지 데이터를 사용한다면 MTTD를 계산하는 것은 간단합니다. 사고가 발생한 시점부터 발견될 때까지의 시간을 측정한 다음, 해당 시간을 전체 장애 건수에 대해 평균을 구합니다.
예를 들어, 4건의 사고를 탐지하는 데 60분, 77분, 45분, 30 분이 걸렸다면, MTTD는 53 분이 됩니다.
53 = (60 + 77 + 45 + 30) / 4 공식은 다음과 같습니다: MTTD = (총 탐지 시간) / 총 사고 건수
특이치를 제거하거나 사고를 심각도별로 분류함으로써 MTTD 계산을 더욱 정교하게 다듬어, 다양한 문제에 대한 세밀한 분석 결과를 얻을 수 있습니다. 신뢰할 수 있는 MTTD 계산 결과를 확보하면, 사고 대응 역량의 지속적인 개선과 보안 모니터링 및 관리 목표의 전반적인 달성을 뒷받침하는 피드백 루프가 형성될 것입니다.
사고 대응 과정에서 MTTD에 영향을 미칠 수 있는 요인은 무엇인가?
일부 조직의 경우, 평균 탐지 시간을 단축하는 것이 쉽지 않을 수 있습니다. 다음은 진행 과정에서 걸림돌이 될 수 있는 몇 가지 일반적인 어려움입니다:
- 가시성 저하: 조직이 네트워크 구석구석에 있는 모든 엔드포인트를 완벽하게 파악하지 못한다면, 의심스러운 활동이 감지되지 않고 지나갈 수 있는 사각지대가 필연적으로 발생하게 됩니다. 이러한 사각지대는 탐지 시간이 길어짐을 의미합니다.
- 단절된 탐지 프로세스: 팀들이 표준화된 탐지 프로세스나 데이터에 대한 동일한 지침서를 따르지 않을 경우, 비효율성과 업무 중복이 발생하여 위협 식별 및 사고 대응이 지연될 수 있습니다.
- 제한된 자원: 많은 조직이 보안 팀의 규모가 작거나 업무 과부하로 인해 어려움을 겪고 있습니다. 적절한 전문 지식과 도구가 없다면 경보 및 잠재적 위협에 대응하는 데 더 많은 시간이 소요될 수 있으며, 이로 인해 MTTD를 낮게 유지하기가 어려워집니다.
- 구식 위협 정보: 해커들은 여가 시간을 이용해 새로운 사이버 공격 수법을 고안해 냅니다. 조직은 의 최신 위협 인텔리전스 를 꾸준히 파악하여, 위협의 수법을 한 수 앞서야 합니다. 뒤처진 상황을 만회하려다 보면 사고를 조기에 파악하기가 더 어려워집니다.
- 경고 피로: 팀이 수많은 경고, 특히 오경고에 시달리면 실제 위협을 간과하기 쉽습니다. 경보의 심각도 순으로 우선순위를 지정하고, 자동 필터링을 활용하며, 탐지 규칙을 세밀하게 조정하여 불필요한 알림을 줄이세요.
이러한 과제를 해결하면 MTTD를 줄이고 조직의 보안을 더욱 강화하는 데 도움이 될 수 있습니다.
조직은 MTTD를 줄이기 위해 어떤 전략을 시행할 수 있을까요?
MTTD 수치가 낮다는 것은 단순히 사고에 더 신속하게 대응한다는 의미만이 아니라, 문제가 확대되기 전에 선제적으로 탐지하고 해결할 수 있도록 하는 관행을 도입한다는 것을 의미합니다.
조직이 MTTD에 선제적으로 대응하기 위해 도입할 수 있는 5가지 모범 사례는 다음과 같습니다:
명확하게
사고 대응 계획
탐지 및 대응을 자연스럽게 습관화하여, 사고 발생 시 공격자의 다음 행보를 추측할 필요가 없도록 하십시오. 사고 발생 시 팀 구성원들이 수행해야 할 역할과 책임은 물론, 조사, 확산 방지, 복구 절차, 통지 양식 및 절차 등 사고 대응 단계별 조치를 명시한 계획을 수립하십시오. 분기마다 한 번씩 모의 훈련(흔히 ‘테이블탑 훈련’이라고도 함)을 실시하여 팀의 대응 능력과 사고 대응 계획을 최신 상태로 유지하십시오.
- 가시성(observability)을 높여주는 엔드포인트 관리 도구 에 투자하십시오.
시스템 전반에서 어떤 일이 일어나고 있는지 실시간으로 파악할 수 있어야 합니다. 이를 통해 팀은 다운타임이나 업무 중단을 최소화하면서, 종종 사용자에게 영향을 미치기 전에 문제를 더 쉽게 탐지하고, 원인을 파악하며, 해결할 수 있게 될 것입니다. 이러한 접근 방식은 문제 원인을 정확히 파악하기 어려운 클라우드 네이티브 애플리케이션이나 마이크로서비스와 같은 복잡하고 분산된 시스템에서 특히 중요합니다.
- 가능한 부분은 자동화하세요
자동화는 이상 징후를 신속하게 식별 및 표시하고, 미리 정의된 대응 프로토콜을 실행하며, 사고 통보 절차를 간소화함으로써 MTTD를 단축하는 데 도움이 됩니다. 의 표준 보안 자동화 기능 중 일부( )는 대응 담당자에게 즉각적인 정보를 제공하여 MTTD를 단축할 수 있으며, 여기에는 다음이 포함됩니다.
• 사고 탐지: 자동화된 모니터링 도구는 시스템에서 이상 징후를 지속적으로 스캔합니다.
• 경보 우선순위 지정: 자동화된 시스템은 미리 정의된 기준에 따라 경보를 분류하고 우선순위를 지정합니다.
• 초기 진단: 자동화된 스크립트는 사람의 개입 전에 문제에 대한 예비 정보를 수집합니다. - 지속적인 팀 교육
모니터링 도구는 방대한 양의 데이터를 생성합니다. 이 데이터를 효과적으로 활용하기 위해서는 팀들이 최신 위협 인텔리전스와 신기술 동향을 꾸준히 파악하는 동시에, 복잡한 패턴을 해석하고 이상 징후를 포착할 수 있는 역량을 키워야 합니다. 지속적인 교육을 통해 운영팀과 IT 팀이 데이터를 효과적으로 분석하고, 문제를 조기에 파악하며, 서비스 중단을 방지하기 위해 선제적으로 대응할 수 있게 될 것입니다.
비난 없는 사후 분석
사건이 발생한 후에는 서로를 탓하며 시간을 낭비하지 마세요. 오히려 그 경험을 성장의 기회로 삼으세요.
결점 없는 사후 분석은 무엇이 잘못되었는지 파악하고, 향후 문제를 더 빨리 발견할 수 있는 방법을 찾아낼 수 있습니다. 먼저, 이해관계자들이 비난이나 보복을 두려워하지 않고 편안하게 의견을 나눌 수 있는 안전한 공간을 마련하십시오.
조사 결과와 결정 사항을 문서화하고, 실행 과제 목록과 이행 일정을 제시하며 사후 검토를 마무리하십시오. 목표는 각 사고를 성장의 기회로 삼아 재발 가능성을 줄이는 동시에 MTTD와 MTTR을 개선하는 것입니다.
Tanium을 활용하여 MTTD를 개선하는 방법
보안 사고의 영향을 최소화하기 위해서는 평균 탐지 소요 시간을 단축하는 것이 매우 중요합니다. 다음과 같은 솔루션들
Tanium Incident Response
이는 조직이 이를 달성하는 데 있어 핵심적인 역할을 합니다.
Tanium을 통해 기업은 모든 엔드포인트에 대한 실시간 가시성을 확보할 수 있으며, 성능 및 보안 이상 징후가 보안 사고로 확대되기 전에 팀이 이를 신속하게 식별하고, 빠르게 진단하며, 즉각적인 조치를 취할 수 있도록 지원함으로써 어떤 위협도 놓치지 않도록 보장합니다. 이를 통해 기업의 MTTD를 단축하고 사고 처리 주기를 단축합니다.
AEM의 강력한 기능을 활용하기
Tanium 플랫폼은 위협 탐지 및 대응, 패치 관리, 기타 엔드포인트 관리 업무를 위한 차세대 AI 기반 분석 및 자동화 프로세스를 제공함으로써, 조직이 정교한 사이버 공격으로부터 네트워크와 엔드포인트를 보호할 수 있는 강력한 도구를 제공합니다.
조직이 Tanium을 활용하여 엔드포인트 전반에 걸쳐 보안 문제를 실시간으로 검색하고 탐지하는 방법을 확인해 보세요. 다음은 ‘ Log4j ’ 취약점에 대한 예시입니다:
Tanium은 팀들이 부서 간 협업을 하고, 실시간 데이터를 수집하며, 최종 사용자에게 불편을 주지 않고도 단일 플랫폼에서 문제를 해결할 수 있도록 지원합니다.
에서 귀사의 환경과 비즈니스 요구 사항에 맞춰 구성된 데모()를 신청하시면, 이러한 이점을 직접 체험해 보실 수 있습니다.
