120 읽음
보안 패치관리 솔루션 필요성과 위험 기반 대응
IT조선
0기업이 사용하는 운영체제(OS)와 업무 프로그램 등 소프트웨어(SW), 서버·네트워크 장비의 펌웨어와 드라이버에는 보안 취약점과 오류를 고치기 위한 ‘패치’가 꾸준히 나온다. 문제는 기업이 관리해야 할 시스템이 많고 사용하는 제품과 버전이 장소, 구축된 시기, 사용자마다 제각각이라는 점이다. 이런 가운데 기업 IT 담당자는 어떤 패치를 어디에 먼저 적용할지를 판단하고, 적용 작업 후에는 재차 확인까지 해야 한다. 따라서 패치 적용 자체만큼 이를 관리하는 것도 중요할 수밖에 없다.
이 때문에 사용하는 것이 패치관리 솔루션이다. 기업이 보유한 PC와 서버 등 하드웨어 자산을 파악하고, 여기에 설치된 운영체제와 애플리케이션 등 소프트웨어의 버전을 확인해 필요한 패치가 무엇인지 찾아준다. 이후 패치 적용 대상을 정하고, 일정에 맞춰 패치를 배포하며, 설치가 제대로 끝났는지 확인하는 과정까지 관리할 수 있다.
패치관리 솔루션이 이처럼 자동화를 지원하는데도 패치 적용이 늦어지는 이유는 무엇일까. 먼저 새 패치가 기존 업무 프로그램이나 드라이버와 충돌하면 장애가 발생할 수 있어 신중을 기할 필요가 있다. 또 서버나 핵심 업무시스템은 재부팅이나 서비스 중단이 필요해 패치 적용 시간을 따로 잡아야 하는 경우도 있다. 패치를 모든 시스템에 한꺼번에 적용하기보다 일부 장비에서 먼저 시험한 뒤 적용 범위를 넓히는 이유다.
모든 패치가 같은 우선순위로 처리되지 않는다는 점도 패치 적용을 늦추는 요인이다. 보안 취약점이 계속 공개되는 가운데 해당 취약점이 실제 공격에 악용되고 있는지, 취약한 시스템이 인터넷에 노출돼 있는지 등을 따져 먼저 적용할 대상을 정해야 한다. 미국 사이버보안·인프라보안국(CISA)도 실제 공격에 악용된 취약점을 ‘알려진 악용 취약점(KEV)’ 목록으로 관리하며 우선적인 조치를 권고하고 있다. 이 과정에서 우선순위가 낮아진 패치는 장기간 미적용 상태로 남을 수 있고, 해당 취약점이 이후 실제 공격에 악용될 수도 있다.
이에 최근에는 패치관리 솔루션의 위험 기반 관리 기능도 강화되는 추세다. 패치가 적용되지 않은 소프트웨어의 취약점이 실제 공격에 악용되고 있는지, 해당 시스템이 외부에 노출돼 있는지, 기업의 핵심 자산인지 등을 분석해 우선 적용할 패치를 정하는 방식이다. 취약점 발견 속도가 빨라지고 패치 규모도 커지는 만큼 모든 패치를 단순히 빠르게 적용하는 것보다 위험도가 높은 대상을 먼저 찾아 안정적으로 적용하는 관리가 중요해지고 있다.
패치 적용은 단순히 소프트웨어를 설치하는 작업으로 끝나지 않는다. 이 때문에 패치관리 솔루션을 이용해 적용 전후 과정을 함께 관리할 필요가 있다. 기업은 어떤 시스템이 패치 대상인지 빠짐없이 파악하고, 사전에 영향을 확인한 뒤 실제 적용 여부까지 계속 추적해야 한다. 당장 패치를 적용하기 어려운 시스템은 접근 제한이나 별도 모니터링 같은 보완 조치를 적용하고, 이후 패치 적용이 가능한 시점을 다시 확인해야 한다.
정종길 기자
jk2@chosunbiz.com