[강은성 보안칼럼] AI의 사이버 공격에 대응하기 위하여(하)
지난 칼럼 'AI의 사이버 공격, 어떻게 대응할까?(1)'에서는 사이버 보안 능력이 뛰어난 프론티어 AI 모델 등장으로 디지털 제품·서비스의 취약점 관리에서 예방 중요성이 더욱 커졌으며, 버그 바운티 등을 통한 '취약점 탐지 속도전'이 필요하다고 지적했다. 발견된 취약점이 설정 변경이나 권한 관리로 해결할 수 있다면 신속한 대응이 가능하지만, 개발사가 보안 패치를 제공해야 하고, 그것을 우리 회사에 적용해야 한다면, 문제가 더 어려워진다. 국내 개발·제조사의 개발 단계 또는 출시 이후의 취약점 관리·대응 체계가 미흡한 것이 현실이다. 소프트웨어 시장 중 시스템 통합 비중이 매우 크고, 소프트웨어 제품에 대해서조차 커스터마이징을 요구해서 취약점 식별과 대응이 쉽지 않은 우리나라 소프트웨어 시장의 특성도 걸림돌이다. 보안 패치와 PSIRT 역할 버그관리체계가 있는 개발회사라면, 취약점을 일종의 버그로서 관리할 수 있는데, 버그와는 달리 취약점은 위협 분석을 바탕으로 발생 가능성과 영향도를 평가해 위험 수준을 산정하고, 이를 기준으로 개발 우선순위와 일정이 결정된다. 취약점을 관리할 별도 주체가 있는 까닭이다. 제품 취약점을 관리·대응하는 팀이 제품보안 사고대응팀(PSIRT: Product Security Incident Response Team)이다. 세계적으로 디지털 제품·서비스를 개발하는 많은 기업이 PSIRT와 함께 제품보안 사고대응 프로세스를 갖추고 있다. 시스코 PSIRT는 자사 제품과 클라우드 기반 서비스에 대한 보안사고를 아래와 같은 프로세스로 관리한다. 즉, PSIRT가 중심이 되어 제품의 취약점을 접수하고(1단계), 신고자와의 소통, 취약점 분류, 위험 평가 등 취약점을 적극적으로 관리하며(2단계), 개발팀과 협업해 보안 패치를 개발하고(3단계), 보안 권고문 등을 통해 고객과 이해관계자에게 알린다(4단계). 평범해 보이는 이 프로세스에서 PSIRT는 신고자로부터 취약점에 대한 추가 정보를 확보하거나 취약점 공개 조건과 일정 등에 관해 긴밀하게 소통하는 것은 물론, 제품보안팀, 개발팀, IT운영팀, 홍보팀, 법무팀, 영업팀 등 여러 사내·외 이해관계자와 소통하고 협업한다. PSIRT를 처음 구축하려는 기업은 아래의 PSIRT (사실상) 표준을 참고하면 좋다. 국제침해사고대응팀협의회(FIRST), “PSIRT 서비스 프레임워크”, 2020. https://www.first.org/standards/FRAMEworks/psirts/psirt_services_FRAMEwork_v1.1 보안 패치 자동 생성, 아직은··· 취약점 탐지와 그것을 악용한 사이버 공격이 급속도로 자동화하는 상황에서 패치 개발이 병목이 됨에 따라 보안 패치를 자동으로 생성하는 연구도 활발해졌다. 대표적인 것이 2023년~2025년 미국 국방고등연구계획국(DARPA)이 개최한 AixCC이다. 참여팀이 개발한 AI 기반의 사이버 추론 시스템(CRS)을 가지고 리눅스 등 오픈소스에 있는 취약점을 탐지·수정하는 대회다. 취약점을 자동 탐지할 뿐 아니라 보안 패치 역시 자동으로 생성하는 것이 중요하다. LLM과 AI 에이전트가 비약적으로 발전한 지금은 오픈AI의 Codex Security, 구글의 codemender, 앤트로픽의 Claude Security가 취약점을 발굴·분석하고 패치를 생성하는 데까지 상당한 성능을 보이고 있다. 자동 패치 생성의 한계도 분명하게 존재한다. AI가 보안 패치 개발을 위해 개발자가 할 일을 크게 줄여줬지만, 제품·서비스에 보안 패치를 적용하는 일은 다른 차원의 일이다. 단 한 줄의 소스 코드만 고쳐도 그 영향이 크거나 여러 곳에서 호출되는 경우, 더욱이 빌드 체인이 복잡하게 구성되어 있다면, 빌드와 테스트의 난이도는 크게 높아진다. ERP의 한 모듈에 취약점이 있다면, 보안 패치를 ERP에 적용하는 것은 고급 엔지니어의 신중한 검토와 판단, 실행이 필수적이다. Secure SDLC, DevSecOps, 보안 활동 자동화! 보안 패치 개발은 제품 개발 프로세스에서 이뤄진다. 패치 릴리즈 수준의 간단한 변경일 수도 있지만, 마이너 업그레이드가 될 수도 있다. 따라서, Secure SDLC에서 각 개발 단계의 보안 활동을 자동화하는 것은 AI의 사이버 공격에 대응하기 위한 필요 조건이 된다. 자동화를 구현하기 위한 DevSecOps가 매우 중요한 이유다. 아래 '그림 3'은 실제로 많이 사용되는 자동화 도구이다. 오픈소스는 오픈소스 라이선스에 따라 다른 부분이 있으므로, 라이선스를 꼼꼼하게 살펴봐야 한다. 부분 오픈소스는 기본 기능은 무료인데, 그 이상을 사용하려면 유료인 소프트웨어 등을 말한다. 각 기업의 사업 환경과 제품의 특성, 개발 프로세스를 살펴서 몇 가지라도 보안 활동을 자동화해 개발팀에서 직접 활용할 수 있게 하면 개발 속도와 보안 수준을 함께 높일 수 있다. 디지털 공급망에서의 취약점 수정 디지털 공급망을 고려하면 보안 패치는 좀 더 복잡해진다. 보안 패치는 해당 디지털 제품·서비스 개발사에서만 개발할 수 있어서다. 예를 들어 스마트 가전 제조사 A사가 가전용 소프트웨어 개발에 사용하기 위해 도입한 라이브러리에서 취약점이 발견됐다는 신고를 접수하면, 해당 개발사에 신고하라고 안내하는 것이 보통이다. 만일 개발사가 신고자의 취약점 신고에 제대로 대응하지 않는다면, A사는 상당히 어려움을 겪을 수 있다. 최근 활발하게 논의되는 소프트웨어 구성 명세서(SBOM)가 소프트웨어 공급망 인프라로 작동한다면, 라이브러리에서 취약점이 발견될 때 이를 사용하는 디지털 제품·서비스를 손쉽게 알 수 있다. 하지만, 여전히 개발업체의 패치 제공이 문제를 해결하는 데 관건이다. A사가 이러한 문제에 대응하려면, 제품보안 역량이 있는 기업의 라이브러리를 구매하고, “취약점 발견 시 지체 없이 보안 패치를 제공할 것”을 구매 계약서에 명시할 필요가 있다. 좀 더 나아간다면, 공급망에서 PSIRT 사이의 통지 체계 또는 협력 체계를 갖추는 것도 고려할 수 있을 것이다. 해당 라이브러리가 오픈소스라면, 다른 소스로 대체하거나 보안 패치를 확보하는 등 A사가 자신의 제품에 대해 전적으로 책임질 수밖에 없다. 오픈소스를 선정할 때 고려해야 할 중요한 기준의 하나인 셈이다. 포털, 쇼핑몰, 온라인 게임 등 웹 기반 서비스를 제공하거나 웹사이트를 운영하는 기업은 스마트 제품 개발보다 더 복잡한 디지털 공급망과 연결되어 있다. CVE 등의 취약점과 보안 패치가 종종 나온다면, 24시간 365일 돌아가야 할 백엔드 서버에 대해서는 정기적으로 또는 보안 패치가 발생할 때 전체 서버에 적용할 수 있는 보안 패치 프로세스를 준비해야 한다. Heartbleed 취약점(OpenSSL), Log4shell 취약점(Log4j)처럼 서버에 광범위하게 영향을 미치는 취약점이 발생하면 몇 주에 걸쳐서 서버를 패치해야 하는 상황이 생길 수 있다. 취약점 수정 의무화? 유럽연합의 사이버복원력법(CRA)에서는 유럽연합 시장에 출시한 디지털 제품(순수 소프트웨어 포함) 개발사나 제조사에 “디지털 제품에 대한 위험과 관련하여, 보안 업데이트 제공 등을 통해 지체 없이 취약점을 수정”할 것을 의무화하였다(부속서 I 파트 II 제2호). 사이버 공격이 “유럽연합 경제뿐 아니라 민주주의, 소비자 안전 및 건강에도 심각한 영향”(전문 제1호)이 있다고 봤기 때문이다. IT 기반 사회인 우리나라도 유럽연합의 상황과 크게 다르지 않다. 중·장기적으로 일정 요건에 해당하는 취약점에 대해서는 이와 같은 제도를 검토할 필요가 있다.
