2019.10.08

"위험 관리의 첫걸음" 패치 관리 정책에 구멍이 생기는 8가지 경우와 해결 방법

Roger A. Grimes | CSO
소프트웨어와 디바이스에 대한 적절한 패치의 실패는 30년째 조직이 해킹 당하는 가장 큰 이유가 되고 있다. 자바와 같은 패치되지 않는 애플리케이션 하나가 모든 사이버보안 사고 원인의 90%가 된 적도 있다. 패치되지 않은 소프트웨어 문제를 효과적으로 해결할 방법이 필요하다.
 
ⓒ Getty Images Bank 

대부분의 조직은 스스로는 패치 관리를 잘 하고 있다고 여기지만 실제로는 제대로 하지 못한다. 패치 관리 정책에 구멍이 생기는 8가지 일반적인 경우는 다음과 같다.


1. 적절한 대상을 패치하지 않음

가장 흔한 패치 문제는 가장 위험도가 높은 애플리케이션을 가장 먼저 패치하지 않는 것이다. 어느 환경에서나 패치가 필요한 대상은 수없이 많지만 이 가운데에서 가장 많은 공격이 집중되는 소프트웨어 프로그램의 유형은 소수다. 이런 소프트웨어 프로그램을 가장 먼저, 효과적으로, 신속하게 패치해야 한다.

클라이언트 워크스테이션에서 가장 많은 공격을 받는 4가지 소프트웨어 유형은 다음과 같다.
- 인터넷 브라우저 추가 기능
- 인터넷 브라우저
- 운영체제
- 생산성 애플리케이션(예: 오피스 프로그램)

서버에서 가장 많은 공격을 받는 4가지 소프트웨어 유형은 다음과 같다.
- 웹 서버 소프트웨어
- 데이터베이스 서버 소프트웨어
- 운영체제
- 원격 서버 관리 소프트웨어

전체 소프트웨어 취약점에서 이런 유형의 소프트웨어가 차지하는 비중은 5% 미만이며, 더 중요한 점은 현재 활동하는 익스플로잇이 없다면 걱정할 필요가 없다는 것이다. 수십년 동안 누적된 데이터를 보면 공개적인 익스플로잇 코드가 “나돌지” 않는 한 취약점이 악용될 가능성은 낮다. 공개적으로 발표된 취약점 중에서 실제 사용되는 비율은 약 2%에 불과하다.

- 해결책: 악용될 가능성이 가장 높은 소프트웨어를 가장 먼저, 가장 신속하게 패치한다.


2. 패치율에 너무 집착

필자가 방문한 고객 대부분은 99%와 같은 엄청나게 높은 패치율을 자랑했다(필자는 지금까지 수백 곳 넘게 방문했음). 그러나 하나의 디바이스를 완전하게 패치한 고객 사이트는 본 적이 없고, 스캔 결과 치명적인 취약점을 포함한 디바이스가 하나도 발견되지 않은 사이트도 없다. 이 커다란 모순의 이유는 무엇인가?

“99% 패치율”은 보통 디바이스에 설치된 마이크로소프트 애플리케이션의 99%를 패치한다는 의미이며, 이 말조차 사실인 경우는 거의 없다. 그렇게 말하는 곳에서 취약한 원격 관리 소프트웨어나 취약한 버전의 인터넷 브라우저 추가 프로그램이 있는지 확인해 보면 십중팔구는 있다. 동일한 프로그램의 5가지 버전이 하나같이 제대로 패치되지 않은 경우도 있다.

더 중요한 점은 패치되지 않은 1%가 가장 위험한 취약점을 의미할 수 있다는 것이다. 가장 악용될 가능성이 높은 부분에 대한 패치율이 거의 0%인 마당에 99%의 패치율은 전체적인 보안 위험 측면에서 무의미한 수치다. 사실 필자가 조사하는 대부분의 환경이 바로 이런 경우에 해당한다.

- 해결책: 전체 패치 성공률을 보고하는 데 집착하지 말고, 악용될 가능성이 가장 높은 취약점을 얼마나 잘 패치하는지를 파악하라.


3. 굼뜬 패치 속도

모든 규정 준수 가이드는 적시에 중요한 취약점을 패치할 것을 권한다. 여기서 적시라는 말은 2일, 아무리 길어도 일주일 이내에 패치해야 함을 의미한다. 많은 사람들이 발표된 패치에 심각한 버그가 있는지 여부를 확인하기 위해 1~3일 정도 기다리는 것은 이해하지만, 아예 정책에 패치 기한을 1개월 이내로 명시해둔 조직도 있다. 제정신이 아니다.

최신 패치가 불과 몇 분 이내에 웜 익스플로잇을 만드는 데 사용될 수 있는 시대에서 핵심 구성요소, 특히 가장 많은 공격을 받는 구성요소를 위한 패치를 한달 동안 기다릴 수는 없다. “인라인 패치”를 사용해 이렇게 패치되지 않은 취약점 악용을 차단하고 있는 경우 서명을 즉각 배포해야 한다.

- 해결책: 가장 공격받을 가능성이 높은 구성요소는 일주일 이내에 패치한다.


4. 불분명한 패치 책임자

한 사람 또는 한 팀이 모든 패치를 책임지도록 하는 조직은 드물다. 일반적으로는 한 사람이나 한 팀이 패치의 많은 부분을 책임지지만 디바이스 패치, 애플리케이션 서버 패치, 데이터베이스 서버 패치 담당자 등은 따로 있다.

드물지만 많은 수의 컴퓨터에 걸쳐 많은 패치를 누락하는 조직도 있는데, 이런 조직에 이유를 물어보면 대답은 “저는 사용자 워크스테이션 담당자라 서버는 모릅니다”, 또는 “서버는 제가 손을 댈 수 없습니다”, “DNS 관리자가 이런저런 문제로 인해 지금 패치하지 않기로 결정했습니다”와 같은 책임 회피로 이어진다. 변명도 난무한다. 여기서 문제는 단 하나, 누구도 패치에 대한 책임을 지지 않는 패치되지 않은 시스템이 많다는 것이다.

- 해결책: 한 사람/한 부서가 모든 패치를 책임지도록 한다.


5. 패치 배포에 앞서 테스트하지 않음

패치를 하면 작동하지 않는 부분이 발생하게 된다. 어느 모로 봐도 패치는 신속하게 하는 것이 맞지만, 패치로 디바이스가 다운되는 경우 그 패치를 배포한 사람은 영원히 비난의 대상이 된다. 원인이 보안 패치 설치라 해도 누구도 서버 다운을 옹호해 주지 않는다. 그러니까 테스트를 해야 한다는 것이다. 할 수 있는 뭐든 하라.

일반적 통념은 배포에 앞서 모든 패치를 폭넓은 디바이스와 구성에 걸쳐 테스트해야 한다는 것이다. 철저하고 완전한 테스트를 마친 이후에만 배포해야 한다. 말로는 쉽지만 실천을 해야 한다.

대부분의 기업은 전혀 테스트하지 않고 패치를 배포한다. 치명적인 실패를 자초하는 격이다. 패치 테스트를 이분법적으로 처리하지 말고(테스트를 하거나 하지 않거나), 대규모 배포에 앞서 최소한 일부 테스트라도 해야 한다.

실험 대상으로 사용할 비핵심 서버와 사용자 워크스테이션, 디바이스를 사전에 파악해두고 패치를 배포해야 할 때 활용한다. 패치가 나오면 하루이틀 후에 프로덕션 테스트 서버와 사용자에게 배포한다. 여기서 1~2일 기다리면서 문제가 발생하는지 확인하고, 문제가 없으면 배포 범위를 넓히면 된다. 단, 나머지 모든 부분을 한꺼번에 하지는 말아야 한다. 프로덕션 배포는 여러 날에 걸쳐 점진적으로 진행하되 일주일 내에 완료해야 한다. 작게 시작해서 넓혀 나가는 방법이다.

반복해서 말하지만 테스트를 이분법적으로 선택하지 않도록 한다. 완전하게 테스트하지 못한다면 적어도 일부라도 한다. 테스트에서 큰 문제가 발견되는 경우에 대비한 패치 취소 계획도 세워야 한다.

- 해결책: 대규모 프로덕션 배포에 앞서 패치를 테스트하고, 패치가 문제를 일으키는 경우에 대비한 취소 계획을 마련한다.


6. 패치 관리 팀에 권한이 없음

필자가 아는 모든 유능한 패치 관리 리더는 온갖 책임은 다 지는데(아직 패치하지 않은 부분에 공격이 이뤄지는 경우 등), 정작 디바이스의 이해 당사자를 대상으로 적절한 패치를 수행하도록 강제할 권한은 없다는 점을 불평한다. 

예를 들어 성공적인 웹 익스플로잇의 원인 중 90%가 패치되지 않은 썬/오라클 자바였던 당시, 대부분의 패치 관리자가 했던 말은 패치를 하면 너무 많은 정상 프로그램의 작동이 중단되기 때문에 패치를 할 수 없다는 것이었다. 여기에 자바가 운영체제 다음으로 가장 많이 설치된 프로그램이라는 사실이 더해져 해커의 주 공격 대상이 됐다.

공개된 익스플로잇 코드가 확인된 핵심 소프트웨어 프로그램을 패치되지 않은 상태로 방지하는 것은 용납되지 않는 일이다. 여러 선택지가 있지만 아무것도 하지 않는 것은 그 선택지에 포함되지 않는다. 새로운 패치로 인해 프로그램 작동이 중단되는 경우 대부분 이유는 프로그래머가 하지 말아야 할 일을 했기 때문이다. 회사(또는 공급업체) 개발자들이 나태함으로 인해 패치 관리 문제를 일으키지 않도록 해야 한다.

프로그램을 패치할 수 없는 경우 할 수 있는 일은 다음과 같다.
- 해당 프로그램이 필요 없는 경우 제거
- 가능한 경우 패치되지 않은 디바이스를 네트워크에서 제거하거나 강력히 격리함
- 소프트웨어를 사용해 패치되지 않은 취약점을 악용할 수 있는 모든 잠재적 위협 차단

- 해결책: 패치를 배포할 수 없는 상황이라면 대안을 사용해서 위험을 완화한다.


7. 취약점을 한 번 패치하고 방치함

패치는 설치한 다음 잊어도 되는 프로그램이 아니다. 패치 관리는 매번 완벽하게 패치해준다고 주장하는 제품을 구입하는 것도 아니다. 그런 패치 관리 제품은 존재하지도 않는다. 패치 관리는 효과적인 위험 관리이며 악용되는 것과 그렇지 않은 것을 면밀히 살피는 과정이다.

- 해결책: 패치 관리 프로그램을 총괄하는 숙련된 위험 관리자를 둔다.


8. 잘못된 패치 관리자 인센티브 기준

마지막으로, 대부분의 패치 관리 리더, 특히 패치 관리 성과에 대해 인센티브를 받는 리더는 적시에 패치한 소프트웨어 프로그램의 비율에 따라 평가된다. 그런데 어디서나 이 비율은 항상 99%다. 이 99%는 진정한 위험 관리 상황과는 무관하다.

그래서 가장 많은 공격을 받는 프로그램을 얼마나 철저히, 신속하게 패치하느냐를 기준으로 인센티브를 제공해야 한다. 특정 기간 동안 패치되지 않은, 악용된 소프트웨어 프로그램의 수가 이전 기간에 비해 감소하고 패치되지 않은 소프트웨어로 인해 발생한 치명적인 공격이 없었다면 그 기간의 패치를 성공으로 간주해야 한다. 필자라면 그 패치 관리 리더에게 경의를 표할 것이다. 이 외의 모든 이야기는 통계를 사용한 거짓말일 뿐이다.

- 해결책: 패치 관리자의 인센티브 기준을 의미없는 전체 패치 비율이 아닌 진정한 위험 감소에 둔다.

패치 관리의 핵심은 위험 관리다. 앞서 설명한 권장 사항에 따르면 적절한 대상을 더 신속하고 효과적으로 패치함으로써 사이버보안 위험을 줄일 수 있다. editor@itworld.co.kr 


2019.10.08

"위험 관리의 첫걸음" 패치 관리 정책에 구멍이 생기는 8가지 경우와 해결 방법

Roger A. Grimes | CSO
소프트웨어와 디바이스에 대한 적절한 패치의 실패는 30년째 조직이 해킹 당하는 가장 큰 이유가 되고 있다. 자바와 같은 패치되지 않는 애플리케이션 하나가 모든 사이버보안 사고 원인의 90%가 된 적도 있다. 패치되지 않은 소프트웨어 문제를 효과적으로 해결할 방법이 필요하다.
 
ⓒ Getty Images Bank 

대부분의 조직은 스스로는 패치 관리를 잘 하고 있다고 여기지만 실제로는 제대로 하지 못한다. 패치 관리 정책에 구멍이 생기는 8가지 일반적인 경우는 다음과 같다.


1. 적절한 대상을 패치하지 않음

가장 흔한 패치 문제는 가장 위험도가 높은 애플리케이션을 가장 먼저 패치하지 않는 것이다. 어느 환경에서나 패치가 필요한 대상은 수없이 많지만 이 가운데에서 가장 많은 공격이 집중되는 소프트웨어 프로그램의 유형은 소수다. 이런 소프트웨어 프로그램을 가장 먼저, 효과적으로, 신속하게 패치해야 한다.

클라이언트 워크스테이션에서 가장 많은 공격을 받는 4가지 소프트웨어 유형은 다음과 같다.
- 인터넷 브라우저 추가 기능
- 인터넷 브라우저
- 운영체제
- 생산성 애플리케이션(예: 오피스 프로그램)

서버에서 가장 많은 공격을 받는 4가지 소프트웨어 유형은 다음과 같다.
- 웹 서버 소프트웨어
- 데이터베이스 서버 소프트웨어
- 운영체제
- 원격 서버 관리 소프트웨어

전체 소프트웨어 취약점에서 이런 유형의 소프트웨어가 차지하는 비중은 5% 미만이며, 더 중요한 점은 현재 활동하는 익스플로잇이 없다면 걱정할 필요가 없다는 것이다. 수십년 동안 누적된 데이터를 보면 공개적인 익스플로잇 코드가 “나돌지” 않는 한 취약점이 악용될 가능성은 낮다. 공개적으로 발표된 취약점 중에서 실제 사용되는 비율은 약 2%에 불과하다.

- 해결책: 악용될 가능성이 가장 높은 소프트웨어를 가장 먼저, 가장 신속하게 패치한다.


2. 패치율에 너무 집착

필자가 방문한 고객 대부분은 99%와 같은 엄청나게 높은 패치율을 자랑했다(필자는 지금까지 수백 곳 넘게 방문했음). 그러나 하나의 디바이스를 완전하게 패치한 고객 사이트는 본 적이 없고, 스캔 결과 치명적인 취약점을 포함한 디바이스가 하나도 발견되지 않은 사이트도 없다. 이 커다란 모순의 이유는 무엇인가?

“99% 패치율”은 보통 디바이스에 설치된 마이크로소프트 애플리케이션의 99%를 패치한다는 의미이며, 이 말조차 사실인 경우는 거의 없다. 그렇게 말하는 곳에서 취약한 원격 관리 소프트웨어나 취약한 버전의 인터넷 브라우저 추가 프로그램이 있는지 확인해 보면 십중팔구는 있다. 동일한 프로그램의 5가지 버전이 하나같이 제대로 패치되지 않은 경우도 있다.

더 중요한 점은 패치되지 않은 1%가 가장 위험한 취약점을 의미할 수 있다는 것이다. 가장 악용될 가능성이 높은 부분에 대한 패치율이 거의 0%인 마당에 99%의 패치율은 전체적인 보안 위험 측면에서 무의미한 수치다. 사실 필자가 조사하는 대부분의 환경이 바로 이런 경우에 해당한다.

- 해결책: 전체 패치 성공률을 보고하는 데 집착하지 말고, 악용될 가능성이 가장 높은 취약점을 얼마나 잘 패치하는지를 파악하라.


3. 굼뜬 패치 속도

모든 규정 준수 가이드는 적시에 중요한 취약점을 패치할 것을 권한다. 여기서 적시라는 말은 2일, 아무리 길어도 일주일 이내에 패치해야 함을 의미한다. 많은 사람들이 발표된 패치에 심각한 버그가 있는지 여부를 확인하기 위해 1~3일 정도 기다리는 것은 이해하지만, 아예 정책에 패치 기한을 1개월 이내로 명시해둔 조직도 있다. 제정신이 아니다.

최신 패치가 불과 몇 분 이내에 웜 익스플로잇을 만드는 데 사용될 수 있는 시대에서 핵심 구성요소, 특히 가장 많은 공격을 받는 구성요소를 위한 패치를 한달 동안 기다릴 수는 없다. “인라인 패치”를 사용해 이렇게 패치되지 않은 취약점 악용을 차단하고 있는 경우 서명을 즉각 배포해야 한다.

- 해결책: 가장 공격받을 가능성이 높은 구성요소는 일주일 이내에 패치한다.


4. 불분명한 패치 책임자

한 사람 또는 한 팀이 모든 패치를 책임지도록 하는 조직은 드물다. 일반적으로는 한 사람이나 한 팀이 패치의 많은 부분을 책임지지만 디바이스 패치, 애플리케이션 서버 패치, 데이터베이스 서버 패치 담당자 등은 따로 있다.

드물지만 많은 수의 컴퓨터에 걸쳐 많은 패치를 누락하는 조직도 있는데, 이런 조직에 이유를 물어보면 대답은 “저는 사용자 워크스테이션 담당자라 서버는 모릅니다”, 또는 “서버는 제가 손을 댈 수 없습니다”, “DNS 관리자가 이런저런 문제로 인해 지금 패치하지 않기로 결정했습니다”와 같은 책임 회피로 이어진다. 변명도 난무한다. 여기서 문제는 단 하나, 누구도 패치에 대한 책임을 지지 않는 패치되지 않은 시스템이 많다는 것이다.

- 해결책: 한 사람/한 부서가 모든 패치를 책임지도록 한다.


5. 패치 배포에 앞서 테스트하지 않음

패치를 하면 작동하지 않는 부분이 발생하게 된다. 어느 모로 봐도 패치는 신속하게 하는 것이 맞지만, 패치로 디바이스가 다운되는 경우 그 패치를 배포한 사람은 영원히 비난의 대상이 된다. 원인이 보안 패치 설치라 해도 누구도 서버 다운을 옹호해 주지 않는다. 그러니까 테스트를 해야 한다는 것이다. 할 수 있는 뭐든 하라.

일반적 통념은 배포에 앞서 모든 패치를 폭넓은 디바이스와 구성에 걸쳐 테스트해야 한다는 것이다. 철저하고 완전한 테스트를 마친 이후에만 배포해야 한다. 말로는 쉽지만 실천을 해야 한다.

대부분의 기업은 전혀 테스트하지 않고 패치를 배포한다. 치명적인 실패를 자초하는 격이다. 패치 테스트를 이분법적으로 처리하지 말고(테스트를 하거나 하지 않거나), 대규모 배포에 앞서 최소한 일부 테스트라도 해야 한다.

실험 대상으로 사용할 비핵심 서버와 사용자 워크스테이션, 디바이스를 사전에 파악해두고 패치를 배포해야 할 때 활용한다. 패치가 나오면 하루이틀 후에 프로덕션 테스트 서버와 사용자에게 배포한다. 여기서 1~2일 기다리면서 문제가 발생하는지 확인하고, 문제가 없으면 배포 범위를 넓히면 된다. 단, 나머지 모든 부분을 한꺼번에 하지는 말아야 한다. 프로덕션 배포는 여러 날에 걸쳐 점진적으로 진행하되 일주일 내에 완료해야 한다. 작게 시작해서 넓혀 나가는 방법이다.

반복해서 말하지만 테스트를 이분법적으로 선택하지 않도록 한다. 완전하게 테스트하지 못한다면 적어도 일부라도 한다. 테스트에서 큰 문제가 발견되는 경우에 대비한 패치 취소 계획도 세워야 한다.

- 해결책: 대규모 프로덕션 배포에 앞서 패치를 테스트하고, 패치가 문제를 일으키는 경우에 대비한 취소 계획을 마련한다.


6. 패치 관리 팀에 권한이 없음

필자가 아는 모든 유능한 패치 관리 리더는 온갖 책임은 다 지는데(아직 패치하지 않은 부분에 공격이 이뤄지는 경우 등), 정작 디바이스의 이해 당사자를 대상으로 적절한 패치를 수행하도록 강제할 권한은 없다는 점을 불평한다. 

예를 들어 성공적인 웹 익스플로잇의 원인 중 90%가 패치되지 않은 썬/오라클 자바였던 당시, 대부분의 패치 관리자가 했던 말은 패치를 하면 너무 많은 정상 프로그램의 작동이 중단되기 때문에 패치를 할 수 없다는 것이었다. 여기에 자바가 운영체제 다음으로 가장 많이 설치된 프로그램이라는 사실이 더해져 해커의 주 공격 대상이 됐다.

공개된 익스플로잇 코드가 확인된 핵심 소프트웨어 프로그램을 패치되지 않은 상태로 방지하는 것은 용납되지 않는 일이다. 여러 선택지가 있지만 아무것도 하지 않는 것은 그 선택지에 포함되지 않는다. 새로운 패치로 인해 프로그램 작동이 중단되는 경우 대부분 이유는 프로그래머가 하지 말아야 할 일을 했기 때문이다. 회사(또는 공급업체) 개발자들이 나태함으로 인해 패치 관리 문제를 일으키지 않도록 해야 한다.

프로그램을 패치할 수 없는 경우 할 수 있는 일은 다음과 같다.
- 해당 프로그램이 필요 없는 경우 제거
- 가능한 경우 패치되지 않은 디바이스를 네트워크에서 제거하거나 강력히 격리함
- 소프트웨어를 사용해 패치되지 않은 취약점을 악용할 수 있는 모든 잠재적 위협 차단

- 해결책: 패치를 배포할 수 없는 상황이라면 대안을 사용해서 위험을 완화한다.


7. 취약점을 한 번 패치하고 방치함

패치는 설치한 다음 잊어도 되는 프로그램이 아니다. 패치 관리는 매번 완벽하게 패치해준다고 주장하는 제품을 구입하는 것도 아니다. 그런 패치 관리 제품은 존재하지도 않는다. 패치 관리는 효과적인 위험 관리이며 악용되는 것과 그렇지 않은 것을 면밀히 살피는 과정이다.

- 해결책: 패치 관리 프로그램을 총괄하는 숙련된 위험 관리자를 둔다.


8. 잘못된 패치 관리자 인센티브 기준

마지막으로, 대부분의 패치 관리 리더, 특히 패치 관리 성과에 대해 인센티브를 받는 리더는 적시에 패치한 소프트웨어 프로그램의 비율에 따라 평가된다. 그런데 어디서나 이 비율은 항상 99%다. 이 99%는 진정한 위험 관리 상황과는 무관하다.

그래서 가장 많은 공격을 받는 프로그램을 얼마나 철저히, 신속하게 패치하느냐를 기준으로 인센티브를 제공해야 한다. 특정 기간 동안 패치되지 않은, 악용된 소프트웨어 프로그램의 수가 이전 기간에 비해 감소하고 패치되지 않은 소프트웨어로 인해 발생한 치명적인 공격이 없었다면 그 기간의 패치를 성공으로 간주해야 한다. 필자라면 그 패치 관리 리더에게 경의를 표할 것이다. 이 외의 모든 이야기는 통계를 사용한 거짓말일 뿐이다.

- 해결책: 패치 관리자의 인센티브 기준을 의미없는 전체 패치 비율이 아닌 진정한 위험 감소에 둔다.

패치 관리의 핵심은 위험 관리다. 앞서 설명한 권장 사항에 따르면 적절한 대상을 더 신속하고 효과적으로 패치함으로써 사이버보안 위험을 줄일 수 있다. editor@itworld.co.kr 


X