글로벌 칼럼 | 네트워크 인프라 보안을 위해 꼭 필요한 것

로그4j의 위협이 주는 교훈은 분명하다. 애플리케이션을 움직이는 소프트웨어 안에 무엇이 있는지 이해하는 것은 보안 상태를 이해하는 데도 중요하다. 이는 네트워크 분야에서도 적용된다. 기업 네트워크 인프라는 여전히 데이터센터의 하드웨어와 LAN, WAN에 관한 것이지만, 이제는 점점 더 ‘소프트웨어에 관한 것’이 되어가고 있다.

ⓒ Getty Images Bank

SDN(Software-defined Network)의 시대인 오늘날에는 점점 많은 수의 네트워크 어플라이언스가 일반 스위칭 하드웨어 또는 추가 네트워크 카드가 있는 바닐라 x86 서버에서 실행되는 독점 소프트웨어에 불과한 것이 되어가고 있다. 주안점이 하드웨어에서 소프트웨어로 이동하면서 네트워크를 실행하는 소프트웨어 스택은 사이버보안에 대한 새로운 위험과 우려의 원인으로 떠올랐다.

서비스에 대한 액세스를 제공하는 IT팀의 역할과 더 나아가 기업 데이터의 무결성은 네트워크와 네트워크 관리 소프트웨어를 기반으로 구축된다. 하지만 네트워크와 관리 소프트웨어의 토대는 것은 무엇일까? 네트워크팀도 아마 모를 것이다.

우리가 아는 오픈소스

일반적으로 기업에서 볼 수 있는 네트워크 소프트웨어는 오픈소스, 오픈소스가 포함된 독점 소프트웨어, 완전한 독점 소프트웨어 3가지 유형으로 나뉜다.

OSS(Open Source Software) 네트워크 구성요소는 클리어OS(ClearOS), 오픈 v스위치(Open vSwitch), ONOS(Open Network Operating System), 덴트(DeNT), pf센스(pfSense), 소닉(SoNIC), 스트레이튬(Stratum), 언탱글(Untangle) 등 아주 많으며, 이를 중심으로 상용 서비스가 제공된다. 이에 따라 스위칭, 라우팅, 보안에 대한 옵션 수도 증가하고 있으며, 개별 패키지도 성숙 단계에 접어들고 있다. 칵티(Cacti), 체크mk(checkmk), 나지오스(Nagios), 판도라(Pandora), 프로메테우스(Prometheus), 자빅스(Zabbix)처럼 네트워크 모니터링 및 관리에 사용하는 훨씬 광범위한 툴셋을 사용하면 선택폭이 훨씬 넓어진다.

문제는 대부분 기업이 이런 툴에 무엇이 들어 있는지 모른다는 것이다. 주어진 툴에 알려진 취약점이 없더라도, log4j 같은 취약점이 발견되면 영향을 받을 것이 분명하다. 그리고 해당 취약점의 악용 사례가 발견된 시간과 정보가 IT업계에 도달하는 시간이 불편할 정도로 오래 걸릴 수 있다.

모두가 코드에 취약한 구성요소가 포함되어 있는지 확인하기 위해 모든 코드를 감사하지는 않겠지만, 모두가 이런 종류의 시스템에서 자동화된 코드 분석을 수행하거나 이런 툴을 사용할 준비를 해야 한다.

우리가 모르는 오픈소스

OSS가 네트워크에 있는 몇몇 독점 소프트웨어 아래에 숨겨져 있을 수 있다는 점도 고려해야 한다. 바로 이것이 log4j 혼란을 야기한 주요 원인이었다. OSS는 모든 종류의 사내 및 상용 애플리케이션에서 사용되고 있다. 개발자들은 알고 있을 수 있지만, 네트워크팀원들은 모를 수 있다.

수학 라이브러리, 그래픽 라이브러리, 데이터베이스처럼 일반적으로 사용되는 수십 개의 OSS 프로젝트를 포함한 모든 종류의 독점 네트워크 툴 및 플랫폼에서 log4j와 같은 사례가 발생할 수 있다. 소프트웨어 개발자가 속도와 혁신이라는 이름으로 처음부터 끝까지 모든 것을 개발하는 경우는 거의 없다. 하나의 큰 소프트웨어 패키지는 다른 패키지에 의존할 수 있다.

숨은 종속성 찾기

때로는 OSS 패키지가 아닌 독점 소프트웨어에도 종속성이 숨어있다. 지난 10년 동안 상업용 TCP/IP 스택에 영향을 미친 수많은 취약점이 발견된 것을 보면 알 수 있다. 트렉(Treck) TCP/IP 스택에 영향을 미친 취약점 세트인 리플20(Ripple20), 익스프레스 로직(Express Logic) 넷X(NetX), 시멘스 뉴클러스 넷 타임(Siemens Nucleus Net time) 등 다른 스택에 영향을 미친 네임:렉(Name:Wreck)이 대표적이다. 이런 종류의 취약점은 네트워크 인프라의 보안에도 영향을 준다.

현재로서는 IT 부서가 보안을 위해 모든 애플리케이션의 모든 코드 라인을 검토할 수 있다고 주장하는 사람은 없다. 그러나 미국 연방 정부는 솔루션 업체가 보안 개발 관행을 따르거나, 그렇지 않을 때는 위험을 완화하는 방법과 시기를 입증하도록 요구함으로써 이런 문제의 개선을 주도하고 있다. 솔루션 업체들은 요청 시 전체 SBOM(Software Bill of Material)을 생성해야 한다.

이제 기업은 구매하고 실행하는 소프트웨어, 특히 네트워크 인프라를 구축하는 소프트웨어에 대한 SBOM을 적극적으로 확인해야 할 것이다.
editor@itworld.co.kr

John Burke editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지