[보안맨] 보안 패치 관리

안녕하세요, 보안맨 입니다.

즐거운 추석 보내셨나요? :)

이번 기고글을 통해 다룰 주제는 '보안 패치 관리' 입니다.

필자는 외국계 회사에 근무하면서 Internal IT Audit, IT Penetration Test 등 다양한 IT 감사 또는 점검 업무를 대응 했습니다. 관련 점검 결과에 따라 Findings (결함)로 거론되는 부분은 패치에 관한 내용 이었습니다. 필수적으로 설치되어야 할 특정 패치가 누락되었거나, 혹은 장기간 패치가 진행되지 않는 소프트웨어 또는 EOS(End of Service) 운영체제 등 에 대해 엄중한 책임을 물었습니다.

보안 패치에 관련, 국내 '정보보호 관리체계' 인증 기준에서는 아래와 같이 정의하고 있습니다.

소프트웨어, 운영체제, 보안시스템 등의 취약점으로 인한 침해사고를 예방하기 위하여 최신 패치를 적용하여야 한다. 다만 서비스 영향을 검토하여 최신 패치 적용이 어려울 경우 별도의 보완대책을 마련하여 이행하여야 한다.

사실, 필자의 회사는 On-Premise (자체 설비 보유)를 기반으로 패치를 적용/관리하면서 서비스 Impact 등 다양한 이슈에 직면 했었습니다. 예를 들어, 패치 테스트 계획을 추진할 때, 미들웨어/운영체제/DB 등을 운영환경과 동일하게 구성하기에는 여러 측면 (e.g. 비용, 가상화 환경 구성 등)에서 한계가 있었습니다.

또한, 고객 서비스 연속성을 중요하게 다루는 금융권 회사이므로, 만약 패치를 진행하기 어려운 경우, 어떤 방식으로 위험을 관리할 지 고민 이었습니다. 결국, 실무진 협의 및 정보보호위원회 심의/의결 등 여러 내부 절차를 거쳐 일반론적인 위험 평가 방법론을 채택하기로 했습니다. - IT 위험 평가와 관련된 사항은 별도 기고글을 통해 상세히 다루도록 하겠습니다.

본론에서는 필자가 On-Premise 환경에서 보안 패치를 관리한 경험을 바탕으로, 아래 3가지 단계로 분리해 현업을 통해 고민했던 부분 등을 공유해 드리고 싶습니다.

1. 자산 식별 / 패치 정보 확인

2. 패치 적용 주기 / 수행 주체 / 테스트 / 적용 방법 등 확인

3. 미 적용 패치 관리 방안 마련

1. 자산 식별 / 패치 정보 확인

먼저, Security Patch 를 위한 IT Asset Inventory 를 확인해야 했습니다. 모든 IT 자산 (e.g. 전화기, 팩스 기기 등)이 패치의 대상은 아니기 때문에, 패치가 필요한 자산 목록 및 세부 계획안을 마련했습니다.

서버 / DBMS / PC / 네트워크 / 소프트웨어(또는 Application) 등 주기적으로 보안 취약점 이슈가 발표되는 자산군을 기반으로 정리했습니다.

Figure1. 패치 관리 대장

패치 정보는 크게 아래와 같은 sources 를 활용 했습니다.

- 벤더사 정기 유지보수 점검에 따른 최신 패치 정보

- Patch Managment System (패치 관리 시스템)

- 보안 관련 뉴스

- 본사에서 오는 Regular CERT Alert

- SOC(보안관제)로부터 오는 Regular CERT Alert

- 국내 정부 기관 (e.g. KISA, 금융감독원 등)

실무를 하면서 아쉬웠던 점은, 사실 패치 우선순위를 결정짓는 '중요도'를 정하는 부분 이었습니다. 패치 중요도 기준이 source 별로 상이하므로, 회사 고유의 패치 중요도 기준이 마련되어야 했지만, 타 업무 우선순위에 의해 밀려, 단순히 sources  내 중요도 정보를 활용하는 수준에 그쳤습니다.

2. 패치 적용 주기 / 수행 주체 / 테스트 / 적용 방법(계획) 등 확인

패치 적용 주기는 패치 중요도에 따라 아래와 같이 산정했습니다.

- High/Critical: 한달 이내

- Medium: 3개월 이내

- Low: 6개월 이내

수행 주체는 다양한 IT 자산을 관리하는 IT인프라팀을 Lead 로 하되, Application 또는 대외 서비스에 영향을 미치는 패치의 경우, 개발팀 등 타 부서의 업무 협조를 통해 긴 호흡을 갖고 계획을 마련했습니다.

사실 PC의 경우는, 마이크로소프트 운영체제 내 Rollback 패치 등 이 잘 갖춰져 있어 운영상 큰 문제는 없었지만, 서버 패치가 큰 걸림돌 이었습니다. 테스트 환경에서 충분히 패치 테스트를 진행해도 실제 운영환경에서는 서비스에 문제가 발생해 Rollback 을 진행하는 cases 가 많았기 때문입니다.

통상적으로 Linux 환경에서는 커널(운영체제의 기본 기능을 수행하는 부분) 에 영향을 미쳐, 타 회사에서는 보통 패치를 적용하지 않는데, 필자 회사의 경우, IT Audit F/U measures 에 따라 주기적인 패치 적용이 필요한 실정 이었습니다. 따라서, 최대한 패치 계획을 최대한 촘촘히 마련해 오류가 나는 경우를 배제하고, 시스템에 영향을 미치는 경우, 내부 의사결정, 위험평가 계획 등 을 통해 처리 되었습니다.

내부 네트워크 망에 위치한 IT자산의 경우, 수동방식의 패치가 이루어졌습니다. 따라서, 진행 도중 예기치 않은 오류가 많이 발생 했었습니다. 필자 회사의 경우, 오류가 발생하더라도 시도하는 것 자체가 의의가 있었기 때문에, 최대한 신속히 원인을 확인 (e.g. Vendor 문의 등)하고, 기간 내에 패치가 진행되도록 업무를 처리했습니다.

3. 미 적용 패치 관리 방안 마련

모든 패치를 기한 내에 또는 최대한 빨리 적용하면 Best 이겠지만 현실은 녹록치 않았습니다.  앞서 말씀드린 것과 같이, 예기치 않은 Errors, 서비스 영향도 고려, 유관부서 협조, Vendor 와의 communications 이슈 등 다양한 원인으로 적시에 패치를 적용하지 못한 케이스가 다수 존재했습니다.

주로, 리눅스 OS 관련 패치 이슈가 많았던 것 같습니다.

따라서, 패치 관리 대장 내에 별도 패치 위험 관리 sheet 를 구성/목록화 하여, 지속적으로 tracking, 보고될 수 있도록 하였습니다.

Figure2. 미 적용 패치 위험 관리 목록

추가적으로, 미 적용 패치가 적절히 관리/보고될 수 있도록 내부 절차서(Procedure)를 새로이 정립했습니다.

크게 아래와 같은 업무 Flow 가 정기적 (월 1회 또는 분기)으로 이루어지도록 하였습니다.

1. 자산 식별 / 패치 리스트 확인

2. 패치 계획 수립, 테스트 ※ 대고객 서비스 영향도가 우려되는 경우, 미 적용 패치 위험 관리 목록 내 포함

3. 패치 적용

4. 패치 결과 보고

다만, 절차서 및 위 미 적용 패치 위험 관리 목록은 주로 단기성 위험 관리에 국한 되었습니다. 따라서, 장기적인 패치관리 문제 및 효율화 방안에 대해서, 별도 IT 위험관리 지침서 내 하위 문서인 IT위험관리계획 내에 아래와 같이 장기 계획 형태로 검토/내부 승인을 득 하였습니다.

- 리눅스 서버 패치 이슈가 많이 발생하는 까닭에, 대고객 Linux OS (incl. EOS 포함)는 윈도우 OS 가상화 형태 Migration

- 상용 클라우드 서비스 이전

기고글이 조금이나마 도움이 되셨으면 좋겠습니다.

행복한 하루 되세요.

보안맨 드림