너무 많고, 시간은 없고, 알아야 할 것도 많고... 어떻게 해결하나?
.jpg)
[보안뉴스 문가용] 랜섬웨어의 새 장이 열렸다. 오래된 안드로이드 버전만을 노리는 랜섬웨어가 등장한 것이다. “사용자가 패치만 하면 되잖아?”라고 생각할지 모르지만, 이건 사용자 입장을 전혀 모르는 이야기다. 최근 IT 관리자들 사이에서 하소연 섞인 용어가 나돌고 있다. 바로 ‘패치 피곤증(patching fatigue)’으로 기업 네트워크를 안전하게 보호하기 위해 해야 할 패치 작업이 너무 많다는 걸 뜻한다.
지난 18년의 패치 역사를 정리한 2016년 IBM 보안 보고서에 의하면, 알려진 취약점은 10만개 이상으로 이는 한 해 평균 5천개 정도라고 대략적인 계산이 가능하다. 이걸 전부 패치한다고 생각해보라. (이상적으로는 다 패치해야 맞다.) 당연히 패치 작업이 많을 수밖에 없다. 365/5000=13.7... 하루에 13~14번 패치하지 않으면 안 되는 게 정상인 것이다.
또, 트립와이어(Tripwire)는 500개의 IT 전문가들을 대상으로 설문을 조사한 바 있는데, 주제는 역시 패치였다. 해당 설문을 통해 패치에 대한 가장 빈번한 ‘컴플레인’ 다섯 가지가 드러났는데, 다음과 같다. 해결법 혹은 제안도 병기했다.
컴플레인 1 : 시간이 너무 오래 걸린다
조직의 크기가 어떻든 한 달에 패치 스케줄만 계산해도 수백 시간은 너끈히 넘는다. 게다가 패치 중 시스템을 다시 시작해야 하는 경우가 꽤나 많은데, 만약 서버에 이런 패치가 적용되었다고 한다면 사업적으로 큰 손해가 발생할 가능성이 생긴다.
그럴 땐 이렇게 1
패치 스케줄을 주말이나 한밤 중 등 사업에 가장 영향이 적은 시간대로 잡고 패치를 자동으로 해주는 패치 관리 툴을 설치하고 사용한다. 스케줄 관리에 신경 쓰고, 자동 패치툴을 적용하는 것만으로도 자연스럽게 가장 패치가 시급한 부분이 드러나고, 덩달아 가장 취약한 곳도 어느 정도 파악이 가능하다.
컴플레인 2 : 마이크로소프트 관련 패치는 다 했는데?
일반적으로 패치라고 하면 여기 저기 컴퓨터마다 공통으로 보이는 윈도우나 여러 MS 관련 제품들을 먼저 그 대상으로 떠올리는데, 그게 다가 아니다. 이 프로그램들에 따라 붙는 써드파티 프로그램 혹은 플러그인들도 패치가 필요하다. 게다가 어도비, 오라클 등의 소프트웨어들도 꽤나 많이 사용되고, 사고도 자주 일으킨다. 문제는 이런 잡다한 프로그램들의 경우 패치가 불규칙적으로 제각각 나온다는 것. 보통 자바나 플래시 관련된 것들이 성가시고 머리가 아프다.
그럴 땐 이렇게 2
어지간한 자동 패치툴들은 MS뿐 아니라 어도비나 오라클과 같은 대형 기업들의 패치들도 관리한다. 중요한 건 지금 내가 사용하고 있는 시스템에 어떤 소프트웨어가 설치되어 있는지를 아는 것이다. 조직 단위로 보자면, 전체 네트워크에서 운영되고 있는 소프트웨어 전부를 파악해야 한다는 뜻이 된다. 이를 단순히 파악하는 걸 넘어, 부서별로 혹은 기능별로 묶어서 관리하면 패칭 시간과 노력이 줄어든다.
컴플레인 3 : 자바랑 플래시, 해도 해도 끝이 없는 업데이트
아마 대부분 사용자들이 자바랑 플래시 업데이트 창만 봐도 노이로제에 걸릴 지경일 것이다. 사실 패치 피곤증 대부분의 지분을 차지하는 것도 바로 이 둘이다. 그 이유는 이 두 제품이 다른 소프트웨어와 함께 ‘번들’로 사용되기 때문이다. 지금 환경에서 이 둘은 범용성이 지나치게 뛰어나 문제도 많이 발견되고 패치도 빈번하다고 볼 수 있다. 그렇지만 그걸 안다고 해서 패치가 갑자기 산뜻한 일로 바뀌지는 않는다. 게다가 여기저기 섞여 있기 때문에 어느 기기에 어떤 버전이 설치되었는지 헷갈린다. 즉, 패치 작업이 이 둘 때문에 더 꼬인다.
그럴 땐 이렇게 3
인벤토리 툴을 하나 마련하는 것이 가장 간단하고 효과적인 해결책이다. 기기마다 어떤 소프트웨어가 설치되어 있고, 어떤 버전인지 검사하고 이 정보를 저장해두면 패치 스케줄을 짜는 일도 수월해지고 시간 역시 절약된다. 방대한 패치 작업을 하다보면 버전을 일일이 맞추기가 귀찮아서 아무거나 깔다가 사고가 터지는데, 이런 일 역시 미연에 방지할 수 있다.
컴플레인 4 : 하지만 대기업들 패치 날짜는 정해져 있잖아?
MS는 패치 튜즈데이(Patch Tuesday)라는 걸 정해 달마다 두 번째 화요일에 패치를 배포한다. MS 제품은 대다수 기업에서 ‘필수’로 사용하고 있는 실정이기 때문에 이 패치를 해야만 하는데, 왜 하필 화요일인가? 이렇게 중요한 패치라면 다른 날에 하면 안 될까? 또, 왜 패치를 만드는 즉시 배포하면 안 되는 것일까? 애플은 간헐적으로 패치를 내주지 않는가?
그럴 땐 이렇게 4
중요한 건 ‘당신의 스케줄’이다. MS에 맞출 하등의 이유가 없다. 실제로 많은 IT 기업들은 패치 새터데이(Patch Saturday), 즉 토요일에 패치 작업을 한다. MS가 화요일에 한다고 같이 화요일에 패치를 할 필요가 없는 것이다. 다만, 이렇게 많은 기업들이 한 달에 한 번 패치를 발표하니, 기업들도 한 달에 한 번 날을 잡아 패치를 한 번씩 점검하고 필요한 패치를 적용하는 식으로 맞출 필요는 있다. 물론 조금 덜 중요한 시스템이나 기기의 패치는 미리미리 해두는 편이 좋다. 아무리 바빠도 최소 분기에 한 번은 패치하기를 권한다.
컴플레인 5 : 패치는 뭐고 취약점은 뭔가?
패치와 취약점이 뭔지는 알겠는데 실제 현장에서는 둘이 마치 동의어인 것처럼 사용된다. 또한 패치가 완료되었다고 해서 취약점이 반드시 사라진다는 법도 없다. 패치가 다루지 못했거나 완벽히 고치지 못한 취약점이 네트워크에 남아있을 가능성도 다분하다. 패치와 취약점에 대해 ‘단어의 해석’에서의 혼동이 아니라 ‘개념적’인 혼동을 할 때 시스템은 취약해진다. 복잡하다.
그럴 땐 이렇게 5
IT 네트워크 보안의 첫 걸음은 패치다. 패치는 보안의 기본이요 알파다. 하지만 그것이 곧 문제의 해결을 뜻하지는 않는다. 취약점이 어디에 존재하고 있는지 파악하는 것도 중요하지만, 파악한 후에 어떤 패치를 적용할 수 있는지, 그 패치가 얼마큼 문제를 해결하는지도 이해해야 한다. 그러나 모든 취약점을 다 파악하는 건 힘이 든다. 이럴 땐 제일 먼저 오래된 OS와 기기를 네트워크에서 가능한 한 많이 제하라. 이것 하나만 해도 보안이 엄청나게 강화된다.
글 : 애슐리 레오나드(Ashley Leonard)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
▲ 패치하다가, 세월 가는 줄도 몰랐다오...
지난 18년의 패치 역사를 정리한 2016년 IBM 보안 보고서에 의하면, 알려진 취약점은 10만개 이상으로 이는 한 해 평균 5천개 정도라고 대략적인 계산이 가능하다. 이걸 전부 패치한다고 생각해보라. (이상적으로는 다 패치해야 맞다.) 당연히 패치 작업이 많을 수밖에 없다. 365/5000=13.7... 하루에 13~14번 패치하지 않으면 안 되는 게 정상인 것이다.
또, 트립와이어(Tripwire)는 500개의 IT 전문가들을 대상으로 설문을 조사한 바 있는데, 주제는 역시 패치였다. 해당 설문을 통해 패치에 대한 가장 빈번한 ‘컴플레인’ 다섯 가지가 드러났는데, 다음과 같다. 해결법 혹은 제안도 병기했다.
컴플레인 1 : 시간이 너무 오래 걸린다
조직의 크기가 어떻든 한 달에 패치 스케줄만 계산해도 수백 시간은 너끈히 넘는다. 게다가 패치 중 시스템을 다시 시작해야 하는 경우가 꽤나 많은데, 만약 서버에 이런 패치가 적용되었다고 한다면 사업적으로 큰 손해가 발생할 가능성이 생긴다.
그럴 땐 이렇게 1
패치 스케줄을 주말이나 한밤 중 등 사업에 가장 영향이 적은 시간대로 잡고 패치를 자동으로 해주는 패치 관리 툴을 설치하고 사용한다. 스케줄 관리에 신경 쓰고, 자동 패치툴을 적용하는 것만으로도 자연스럽게 가장 패치가 시급한 부분이 드러나고, 덩달아 가장 취약한 곳도 어느 정도 파악이 가능하다.
컴플레인 2 : 마이크로소프트 관련 패치는 다 했는데?
일반적으로 패치라고 하면 여기 저기 컴퓨터마다 공통으로 보이는 윈도우나 여러 MS 관련 제품들을 먼저 그 대상으로 떠올리는데, 그게 다가 아니다. 이 프로그램들에 따라 붙는 써드파티 프로그램 혹은 플러그인들도 패치가 필요하다. 게다가 어도비, 오라클 등의 소프트웨어들도 꽤나 많이 사용되고, 사고도 자주 일으킨다. 문제는 이런 잡다한 프로그램들의 경우 패치가 불규칙적으로 제각각 나온다는 것. 보통 자바나 플래시 관련된 것들이 성가시고 머리가 아프다.
그럴 땐 이렇게 2
어지간한 자동 패치툴들은 MS뿐 아니라 어도비나 오라클과 같은 대형 기업들의 패치들도 관리한다. 중요한 건 지금 내가 사용하고 있는 시스템에 어떤 소프트웨어가 설치되어 있는지를 아는 것이다. 조직 단위로 보자면, 전체 네트워크에서 운영되고 있는 소프트웨어 전부를 파악해야 한다는 뜻이 된다. 이를 단순히 파악하는 걸 넘어, 부서별로 혹은 기능별로 묶어서 관리하면 패칭 시간과 노력이 줄어든다.
컴플레인 3 : 자바랑 플래시, 해도 해도 끝이 없는 업데이트
아마 대부분 사용자들이 자바랑 플래시 업데이트 창만 봐도 노이로제에 걸릴 지경일 것이다. 사실 패치 피곤증 대부분의 지분을 차지하는 것도 바로 이 둘이다. 그 이유는 이 두 제품이 다른 소프트웨어와 함께 ‘번들’로 사용되기 때문이다. 지금 환경에서 이 둘은 범용성이 지나치게 뛰어나 문제도 많이 발견되고 패치도 빈번하다고 볼 수 있다. 그렇지만 그걸 안다고 해서 패치가 갑자기 산뜻한 일로 바뀌지는 않는다. 게다가 여기저기 섞여 있기 때문에 어느 기기에 어떤 버전이 설치되었는지 헷갈린다. 즉, 패치 작업이 이 둘 때문에 더 꼬인다.
그럴 땐 이렇게 3
인벤토리 툴을 하나 마련하는 것이 가장 간단하고 효과적인 해결책이다. 기기마다 어떤 소프트웨어가 설치되어 있고, 어떤 버전인지 검사하고 이 정보를 저장해두면 패치 스케줄을 짜는 일도 수월해지고 시간 역시 절약된다. 방대한 패치 작업을 하다보면 버전을 일일이 맞추기가 귀찮아서 아무거나 깔다가 사고가 터지는데, 이런 일 역시 미연에 방지할 수 있다.
컴플레인 4 : 하지만 대기업들 패치 날짜는 정해져 있잖아?
MS는 패치 튜즈데이(Patch Tuesday)라는 걸 정해 달마다 두 번째 화요일에 패치를 배포한다. MS 제품은 대다수 기업에서 ‘필수’로 사용하고 있는 실정이기 때문에 이 패치를 해야만 하는데, 왜 하필 화요일인가? 이렇게 중요한 패치라면 다른 날에 하면 안 될까? 또, 왜 패치를 만드는 즉시 배포하면 안 되는 것일까? 애플은 간헐적으로 패치를 내주지 않는가?
그럴 땐 이렇게 4
중요한 건 ‘당신의 스케줄’이다. MS에 맞출 하등의 이유가 없다. 실제로 많은 IT 기업들은 패치 새터데이(Patch Saturday), 즉 토요일에 패치 작업을 한다. MS가 화요일에 한다고 같이 화요일에 패치를 할 필요가 없는 것이다. 다만, 이렇게 많은 기업들이 한 달에 한 번 패치를 발표하니, 기업들도 한 달에 한 번 날을 잡아 패치를 한 번씩 점검하고 필요한 패치를 적용하는 식으로 맞출 필요는 있다. 물론 조금 덜 중요한 시스템이나 기기의 패치는 미리미리 해두는 편이 좋다. 아무리 바빠도 최소 분기에 한 번은 패치하기를 권한다.
컴플레인 5 : 패치는 뭐고 취약점은 뭔가?
패치와 취약점이 뭔지는 알겠는데 실제 현장에서는 둘이 마치 동의어인 것처럼 사용된다. 또한 패치가 완료되었다고 해서 취약점이 반드시 사라진다는 법도 없다. 패치가 다루지 못했거나 완벽히 고치지 못한 취약점이 네트워크에 남아있을 가능성도 다분하다. 패치와 취약점에 대해 ‘단어의 해석’에서의 혼동이 아니라 ‘개념적’인 혼동을 할 때 시스템은 취약해진다. 복잡하다.
그럴 땐 이렇게 5
IT 네트워크 보안의 첫 걸음은 패치다. 패치는 보안의 기본이요 알파다. 하지만 그것이 곧 문제의 해결을 뜻하지는 않는다. 취약점이 어디에 존재하고 있는지 파악하는 것도 중요하지만, 파악한 후에 어떤 패치를 적용할 수 있는지, 그 패치가 얼마큼 문제를 해결하는지도 이해해야 한다. 그러나 모든 취약점을 다 파악하는 건 힘이 든다. 이럴 땐 제일 먼저 오래된 OS와 기기를 네트워크에서 가능한 한 많이 제하라. 이것 하나만 해도 보안이 엄청나게 강화된다.
글 : 애슐리 레오나드(Ashley Leonard)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-24] 
.jpg)
.jpg)
