Forefront Codename "Stirling"을 통해 바라보는 Microsoft 통합 보안 전략

4월 8일 미국 RSA 컨퍼런스에서 Forefront의 다음 버전인 코드네임 Stirling의 첫번째 베타가 공개되었습니다. 내부적으로도 매우 높은 기밀 보안으로 진행되었던 프로젝트였기에, 저역시도 4월 8일에 공개되었을 때 처음으로 Stirling에 대한 모습을 살펴볼 수 있었습니다. 이 포스팅은 현재 베타 1인 Stirling을 기준으로 하였으므로, 차후 사항은 언제든지 변경될 수 있음을 양지하시기 바랍니다.

첫느낌을 한마디로 표현하면 매우 쿨하다는 것입니다. 지금까지의 Microsoft Forefront를 살펴보면 보안 자체적인 기술로는 매우 훌륭한 모습을 보였습니다만, 전체적인 제품간의 연계성 및 통합 보안으로서의 모습에는 2% 부족하다는 느낌을 강하게 받았습니다. 특히 클라이언트, 서버, 엣지단에 대한 Forefront는 제 영역을 벗어난 모습으로의 통합된 관리 및 보안 연계가 불명확해보였죠. 예를 들어...

사내의 꼬알라라는 사용자가 바이러스에 감염된 파일을 실행했습니다. 이 경우 Forefront Client Security가 이를 감지하게 되고, 이를 사용자에게 알리고, 이에 대한 제거 작업을 진행합니다. 이 경우... 이에 대한 보고서가 Microsoft Operation Manager 2005로 가게 되고, 관리자는 Client Security에 대한 관리 콘솔을 통해서 Client Security에 대한 중앙 관리만을 할 수 있었습니다. 해당 관리 도구에서는 서버군이나 엣지단에 대한 보고서나 정책 배포, 작업은 불가능했죠. 서버단에 대해서는 별도의 Forefront Server Management Console을 제공하였으며, ISA 2006, IAG 2007로 포진된 엣지에 대해서는 중앙 관리 도구가 없었습니다. 이러한 모습이 Stirling에서는 사라지게 되며, Stirling 관리 콘솔을 이용해서, 클라이언트, 서버, 엣지에 대한 중앙 모니터링 및 정책 배포가 가능해집니다. 아직까지 보안 벤더중 이러한 전체 통합 보안 패키지와 더불어 중앙 관리가 가능한 모습까지 제시하는 벤더는 없었다고 봅니다. 보안 기술은 나날이 발전해가고 있고, 각각의 분야별 기술로는 훌륭하지만, 인프라에서는 단순한 하나의 기술만 이용하는 것이 아니므로, 체계적인 통합 관리 방안이 이제 더욱 중요하게 어필될 것으로 보입니다.

위의 그림은 기본 관리 콘솔의 모습입니다. 클라이언트, 배포, Exchange, NAP, 보안 체크, Windows 방화벽까지 일괄 관리가 되는 모습을 보실 수 있고, 기존과 마찬가지로 Antimalware에 대한 엔진 정의 관리는 WSUS 3.0을 사용합니다. 특이할만한 점은 많은 난제로 여겨졌던 Forefront Client Security 클라이언트 모듈에 대해서도 WSUS내 하나의 패키지로 등록시켜 사용자들이 업데이트를 통해 설치되게 하는 모습을 볼 수 있습니다. 아직 베타 1이기 때문에 별도의 GUI 환경을 지원하지 않고 별도의 명령어를 통해서 이를 등록합니다. Stirling은 매우 빠르게 TechNet에서 많은 도움말을 제공하고 있고, 이에 대해 참고하시면 사내 환경에 구축을 시도해볼 수 있습니다.

클라이언트쪽에 배포된 Forefront는 v1때와는 달리, 사용자에게 직접 관리 옵션에 접근하는 것을 막아놓았습니다. 정확하게 표현하면 메뉴가 없습니다.

전체적인 설정은 Stirling 콘솔에서 관리자가 정책을 통해 설정하여야 하며, 정책을 만들고 부여하는 방식은 v1에서 사용한 모델이랑 흡사합니다. 정책을 생성하고 이에 대해 OU나 컴퓨터 단위로 부여할 수 있다는 의미입니다.

NAP에 대한 확장도 눈에 띄는 부분입니다. 현재 Windows Server 2008의 NAP을 이용한다면, 보안 센터에서 체크할 수 있는 4가지 + 업데이트 서버와의 교신 시간을 통한 격리가 가능합니다. Stirling을 가미하게 되면 Windows Server 2008 NPS에 SHV가 하나더 추가되게 되고, 시스템 옵션측면으로만 봐도 엄청나게 늘어난 요소들을 이용해서 NAP 인프라의 구현이 가능합니다.

이 NAP 인프라를 통해 추가적이로 클라이언트의 보안 컴플라이언스를 부여할 수 있는 부분은 베타 1이지만 매우 세밀합니다. 제가 거품을 물었던 측면을 하나 살펴보면, Internet Explorer내 시작 홈페이지에 대한 변경시 이를 NAP의 적용 요소로 가미할 수 있습니다. Stirling 관리 콘솔에서 정책을 생성할 수 있습니다. NAP 인프라의 현재 현황에 대해서 잘 정리해서 보여주는 Stirling 관리 콘솔의 리포팅 기능도 박수를 줄만 합니다. 기존에는 Windows Server 2008 이벤트 뷰어를 뒤지거나, 별도의 SQL 데이터베이스에 밀어넣고 이를 사용하는 웹 페이지 or 응용 프로그램을 개발했어야 하죠.

Stirling에서 클라이언트 및 서버를 확인할 수 있는 부분은 첫번째로 MBSA가 제공하는 모니터링 요소는 모두 확인할 수 있습니다. 또한 이 설정이 적절하지 못하다면, 다시 말해 보안 컴플라이언스를 따르지 않을 경우엔, 앞선 IE의 예처럼 NAP을 통해 격리할 수 있습니다. 이정도가 끝이 아닙니다. 사용자 계정, 보안 업데이트까지 원하시는 방향으로 보안 컴플라이언스를 잡아가실 수 있습니다. Forefront v1과 마찬가지로 시스템에 대한 보안 상태 평가를 하게 되고, 이에 따라 클라이언트의 컴퓨터가 보안상 어떤 모델을 적용받고 있는지도 살펴볼 수 있습니다.

이에 대한 Response도 선언이 가능합니다. 다시 예를 들면, 사용자가 바이러스에 감염되었을 경우, 이를 문제로 선언하고, 사용자의 컴퓨터내 Forefront에서 Quick Scan을 하도록 선언할 수도 있다는 의미입니다. 당연히 이는 Stirling의 관리 콘솔 & System Center Operation Manager 2007을 이용하겠다라고 무릎을 치신 분도 계시죠? SCOM는 ITIL/ITSM 적인 측면에서 Incident Management, Problem Management에 해당되는 기술입니다. 당연히 사내에 보안상의 문제가 발생되었다면, 이에 대해 자동으로 문제점에 대해 등록하는 작업이 필요하지만 이를 SCOM에서 알아서 해준다는 의미죠. 문제에 대한 평가 및 해결 과정을 진행하실 수 있습니다.

전반적인 방향성이 유기적인 보안 통합으로 흘러가고 있으므로, 사용자가 바이러스를 실행했을 때, 해당 바이러스의 출처도 매우 중요합니다. 해당 바이러스가 메일을 통해 들어왔는지, 사용자 하드 디스크에서 파일 기반에서 동작되었는지, 인터넷에서 사용자가 복사를 해왔는지... 이러한 사항에 대해서도 엣지, 서버에 대한 전체적인 모니터링을 하고 있기 때문에, 사용자가 악성 코드에 감염된 경로도 제시해줄 수 있습니다.

현재 베타 1에서는 Exchange Server만 모니터링할 수 있지만, 베타 2에서는 SharePoint에 대한 모니터링도 추가될 예정이라고 합니다. 이왕 이야기를 꺼낸 마당에 한가지만 더 팁을 드리면 현재 Stirling은 영문 플랫폼에 대해서만 환경을 제공합니다. 콘솔뿐만 아니라, Client Security에 대한 설치도 영문 플랫폼에서만 가능합니다. 차후엔 모든 언어를 지원하겠죠. 설치시 제가 고생한 부분은 영문 플랫폼에 로캘 정보를 한국으로 했더니, SQL 2005 영문 버전의 기본 캐릭터 셋 정보가 Korean으로 되어졌고, 설치시 이사항때문에 진행이 중단되는 사고(?)가 발생했습니다. Latin 캐릭터 셋으로 수동 설정을 하시던지, 아니면 로캘 정보를 속편하게 영문으로 하시고 설치하시면 됩니다.

Stirling 인프라에 대한 각종 명령은 GUI 뿐만 아니라, PowerShell을 기반으로도 가능합니다. Stirling에 관련된 스냅인을 제공하고, 이에 대해 PowerShell에서 이를 추가해줘야 하지만, 차후에는 이를 실행 기반으로 해줄 예정으로 보입니다.

ISA Server의 다음 버전인 TMG(Threat Management Gateway)의 변화도 주목할만 합니다. 아직 약속한 모든 기능이 다 구현되진 않았습니다만, HTTP 패킷에 대해서 맬웨어 엔진을 이용한 실시간 맬웨어 탐지 시스템이 눈에 띄며, 이에 대한 엔진 업데이트도 WSUS를 활용합니다. 설치 환경은 Windows Server 2008 x64 버전만을 지원한다고 되어져 있습니다. TMG와 Stirling과의 연동에 관련된 내용도 TechNet 도움말에서 확인하실 수 있습니다.

TMG의 코드네임은 내부적으로 Nitrogen입니다. WSUS의 HTTP 필터 엔진에 관련된 사항에 이를 명시해주고 있습니다.

TMG의 경우에도 시나리오에 맞는 서버군으로 나누어질 것으로 예상되며, 차후 이에 대해서도 확정되었을 경우, 별도의 포스팅을 하겠습니다.

전반적으로 잘 엮어지고 있다는 느낌을 강하게 받았습니다. 단순한 포인트별 보안 관리 및 기술 제공이 아닌, 통합 보안의 인프라로의 발전 방향에 대해 매우 강한 인상을 받았으며, 이는 당연히 통합 보안 기술에서는 매우 중요한 부분입니다. 개별 기술의 개별적 구현은 관리자에게는 피할 수 없는 관리의 부담을 안겨주게 되고, 부담이 많은 보안 관리는 차후, 보안 사고라는 극단적인 모습으로 되돌아 올 수 있습니다.

통합 보안 모델... 잘 짜여진 통합 관리가 필수적입니다~

Stirling에 대한 온라인 도움말은 TechNet을 통해 확인하실 수 있습니다.