지난 5월 영국 중앙은행(Bank of England)에 이어, 유럽중앙은행(ECB)도 기관들에게 AI 기반 사이버 공격에 대비한 대응 계획을 수립할 것을 요구하고 있습니다. (새 탭에서 열림). 그러나 그것이 원하는 것은 전략 문서가 아니라 작전 준비 태세의 입증이다:
7 July에 ECB 은행감독국은 약 110 개의 금융 서비스 기관에 서한을 보냈습니다. 지침: 31st October 2026까지 AI 기반 사이버 공격에 대응하기 위한 구체적인 실행 계획을 제출하십시오. ECB가 이 주제를 다루고 있다는 사실은 누구에게도 놀라운 일이 아니다. 눈에 띄는 점은 그 내용이 얼마나 구체화되었는가 하는 것이다. 단순히 전략 문서에 대한 답변만으로는 더 이상 충분하지 않으며, 필요한 것은 작전 수행 능력에 대한 입증이다. 이는 패치 속도 측면에서 필수 요소로 간주됩니다. 예전에는 취약점을 해결하는 데 3개월이 걸려도 타당하다고 여겨졌지만, 오늘날에는 몇 시간 이내에 대응하는 것이 중요합니다. 그리고 이에 대한 책임은 경영진에 있습니다. 이제는 선택 사항이 아닙니다.
그 편지는 IT 부서가 아닌 고위 경영진을 대상으로 의도적으로 작성된 것이었다. 이와 함께 미국 엔터테인먼트 소프트웨어 등급 위원회(ESRB, 25th June )는 AI 모델로 인해 발생하는 체계적인 사이버 위험에 대한 경고를 발표했으며, 동시에 감독 당국은 연례 IT 위험 설문조사 실시를 연기했다. 그 신호는 분명합니다. 이 주제는 이제 이사회 차원에서 다루어야 할 사안이 되었습니다.
행동 계획의 기초
요구되는 실행 계획에는 새로운 규칙이 필요하지 않습니다. 이는 DORA가 이미 요구하고 있는 사항을 구체화한 것이지만, 속도와 검증 가능성에 대한 요구 수준은 훨씬 더 높습니다. 디지털 운영 복원력에 관한 (EU) 규정 제 2022/2554 호는 17th January 2025부터 전면적으로 적용되고 있습니다. 이는 금융 부문의 회복탄력성을 ICT 위험 관리, ICT 관련 사고의 처리 및 보고, 디지털 회복탄력성 테스트, 제3자 위험 관리, 정보 공유라는 다섯 가지 축으로 체계화합니다.
AI 사이버 행동 계획은 기존 방식을 완전히 새롭게 바꾸는 것이 아닙니다. AI 기반 공격의 압박 속에서 이 세 가지 핵심 요소를 강화해야 합니다.: ICT 위험 관리 (보호해야 할 대상이 무엇인지 알고 있는가? (얼마나 빨리 대응할 수 있을까?), 복원력 테스트 (실제 스트레스 상황에서도 내 가정이 타당할까?), 제3자 위험 (내가 어느 정도 의존하고 있으며, 누구에게 의존하고 있는가?). 이미 DORA를 진지하게 받아들인 사람들은 처음부터 다시 시작할 필요가 없습니다. 이 일을 단순한 기록 작업으로만 여겼던 사람들은 이제 어디에 허점이 있는지 실감하게 될 것이다.
담당자가 이행 상황을 어떻게 평가할 것인가
관련 합동 감독팀은 문서의 문구 자체를 검토하지는 않겠지만, 그 이면에 담긴 실질적인 내용을 검토할 것입니다. 탄탄한 계획과 단순한 의향 표명을 구분 짓는 네 가지 요소는 다음과 같습니다:
- 원칙 대신 구체적인 조치: 해당 계획에는 어떤 시스템이 영향을 받는지, 어떤 순서로 처리될지, 그리고 어떤 목표치가 적용되는지가 명시되어야 합니다. 모호한 개선 의지만으로는 충분하지 않습니다.
- 단순히 위원회가 아닌, 구체적인 인물을 지명해야 합니다: 필요한 것은 해당 계획을 책임지고 추진할 인물을 임명하는 것입니다. 단순히 책임만 지는 것이 아니라, 실질적인 권한을 부여받은.
- 배정된 자원: 예산과 인력. 막연한 약속이 아닌, 눈에 띄게 확고한 의지를 보여줍니다.
네 번째 요소는 동시에 결정적인 질문이기도 합니다. 즉, 자신이 주장하는 바를 증명할 수 있습니까? 여기서 ‘증명’이란 요청이 있을 경우 다음 세 가지 증거를 제시할 수 있는 것을 의미합니다:
- 패치 적용 속도에 관하여: 이 분석 자료는 최근 공개된 중대한 취약점들에 대해, 공개 시점부터 전체 시스템에 패치가 적용되기까지 얼마나 많은 시간(시간 또는 일)이 소요되었는지를 보여줍니다. 해당 수치를 분포 형태로, 또한 시간 경과에 따른 추이를 타임스탬프와 함께 제시해야 합니다. 대충 둥글게 산출한 평균치는 상사를 만족시키지 못할 것입니다. 예를 들어, 심각한 CVE의 95%가 72 시간 이내에 해결되었습니다.
- 자산 투명성에 관하여: 실제로 파악된 자산 현황과 CMDB 간의 대조 결과를 통해 차이를 명확히 확인할 수 있습니다. 이 글은 공식 목록에 포함되지 않은 엔드포인트, 서버, 클라우드 워크로드가 얼마나 많은지, 그리고 이러한 관리되지 않거나 구식인 시스템을 어떤 방법으로 추적할 수 있는지를 보여줍니다. 그 불일치 자체가 가장 결정적인 증거입니다.
- 진행 상황: 단 몇 분 만에, 단일 데이터 소스를 기반으로 생성할 수 있으며, 날짜가 명시되고 추적 가능한 보고서입니다. 만약 JST가 오늘 문의한다면, 답변은 이미 준비되어 있어야 하며, 먼저 여러 시스템에서 정보를 일일이 모아 수동으로 정리할 필요가 없어야 합니다.
공통점: 신뢰할 수 있는 출처에서 나온, 타임스탬프가 포함된 수치이며, 언제든지 재현이 가능하다는 점입니다.
실무에서 어려움이 발생하는 부분
그 요건들은 자명해 보입니다. 많은 기관들이 이러한 문제들로 어려움을 겪을 가능성이 높은 것은 의지의 문제가 아니라, 오랜 시간에 걸쳐 형성된 구조의 문제입니다. 다음과 같은 다섯 가지 패턴이 끊임없이 반복됩니다:
- 분산된 도구 환경: 자산 관리, 취약점 관리, 패치 적용 및 보고 기능이 각각 별도의 솔루션에 분산되어 있습니다. 상사의 모든 질문은 시스템 경계를 넘나드는 데이터 수집 작업으로 이어집니다.
- 뒤처진 CMDB: 이 구성 데이터베이스는 실제 상태가 아닌 목표 상태를 반영하고 있습니다. 현실과 데이터베이스 사이에는 누구도 실시간으로 메울 수 없는 간극이 존재한다.
- 사각지대. 관리되지 않는 기기, 섀도우 IT, 구식 시스템은 목록에 나타나지 않습니다. 바로 그 지점들이 공격자들이 집중하는 진입점입니다.
- IT와 보안의 별개의 세계: 취약점을 발견한 사람이 바로 그 취약점을 해결하는 사람은 아닌 경우가 많습니다. 모든 업무 인계에는 시간이 소요되는데, 요즘은 시간이 부족합니다.
- 유지보수 기간에 대한 의존성: AI가 단 몇 시간 만에 취약점을 악용하는 상황에서, 사후 대응 방식의 주기적인 패치 주기만으로는 더 이상 충분하지 않습니다.
게다가, 많은 조직에서는 여전히 누군가가 밤새 작성한 스프레드시트를 이용해 관리자를 위한 자료를 수작업으로 작성하고 있습니다. 이는 재현 가능하지도 않고 안정적이지도 않으며, JST가 갑작스럽게 요청할 경우 확장성도 부족합니다.
성공할 조직은 마감 기한을 지루한 규정 준수 절차로만 보지 않고, 오랫동안 미뤄왔던 자동화 및 운영상의 변화를 추진하는 계기로 삼는 조직일 것입니다.
앞으로 몇 주간의 로드맵
31st October가 시작되기까지 남은 짧은 시간 동안 중요한 것은 이 계획의 운영적 기반을 이루는 요소들입니다:
- 전체 재고 목록을 작성하십시오. 관리되지 않는 시스템 및 구형 시스템을 포함하여 모든 엔드포인트, 서버 및 클라우드 워크로드에 대한 포괄적이고 실시간의 현황을 파악할 수 있습니다. 결과를 CMDB와 대조해 보십시오. 차이가 발생하면 그 차이가 바로 위험 요소가 되기 때문입니다. 무엇을 운영하고 있는지 파악해야만 우선순위를 정할 수 있습니다.
- 진척 상황을 측정 가능하게 만드세요. 중대한 취약점이 공개된 시점부터 전체 함대에 패치가 적용되기까지의 시간을 지표(패치까지의 평균 소요 시간)로 정의하고, 이를 기록하기 시작하십시오. 측정 기준을 유지보수 기간과 분리하십시오. 그렇지 않으면 대응 능력이 아니라 단순히 일정을 측정하게 될 뿐입니다.
- 증거를 준비하십시오. 단일 데이터 소스에서 버튼 하나만 누르면 진행 상황을 확인할 수 있도록 하고, 타임스탬프가 포함되어 있으며 JST에 제출할 준비가 되어 있어야 합니다. 몇 분 만에 작성할 수 있는 보고서가 며칠을 들여 작성한 보고서보다 더 설득력이 있습니다.
- 책임성을 확고히 다진다. 권한과 예산을 부여받은 책임자를 지정하고, 상사가 귀하를 평가할 때 사용하는 것과 동일한 지표를 기준으로 해당 주제를 이사회 정기 안건으로 상정하십시오.
실무에서의 단계: 먼저 투명성과 지표 수립, 그 위에 자동화와 근거를 구축하고, 처음부터 거버넌스를 병행하여 운영한다. 이러한 패턴을 따르는 조직은 ‘ 31st October’에 따라 계획을 수립할 뿐만 아니라, 무엇보다도 이를 뒷받침할 근거를 갖추게 될 것입니다.
계획에서 입증 가능한 현실로
자율 IT 플랫폼인 Tanium은 자산 현황, 취약점, 패치 관리 및 증거 정보를 공유되고 항상 최신 상태로 유지되는 데이터 기반에 통합합니다. 이를 통해 경량 에이전트가 파편화된 도구 환경을 대체하게 됩니다. 그 결과: 모든 엔드포인트에 대한 실시간 가시성, 자동화된 패치 적용 및 자율적인 대응 능력이 확보됩니다. 따라서 신뢰할 수 있는 실행 계획은 감독 당국의 면밀한 검토를 견뎌낼 수 있는, 명백히 입증 가능한 운영상의 현실이 된다.
마감일이 정해졌습니다. 문제는 계획을 제출할 수 있는지 여부가 아니라, 그 계획이 탄탄한지 여부입니다.
