기존 인프라 손 댈 필요 없이 ‘투명하게’
액세스 레이어 스위치와 분산, 혹은 코어 스위치 사이에 설치되는 인라인 NAC(In-Line Network Access Control)는 네트워크 서버와 서비스로의 액세스를 세밀하게 통제한다. 이번 랩테스트에서는 컨센트리의 ‘랜실드 컨트롤러’, 네비스의 ‘랜인포서’, 버니어의 ‘에지월’을 평가했다. 아쉽게도 에디터즈 초이스나 최고가치상으로 꼽을 만한 제품은 없었다. 하지만, NAC는 치열한 경쟁을 보이고 있기에 이른 시일 내에 보다 더 강화된 제품이 출시될 것으로 기대된다.
특별한 회사가 아니라면 코드 레드나 코드 그린, SQL 슬래머와 같이 급속히 번져가는 웜의 망령들로 무척이나 두려움을 느끼겠지만 그렇다고 인프라에 복잡하고 값비싼 대대적인 업그레이드를 할 정도로 충분히 겁을 먹지는 않을 것이다. 시스코시스템즈가 원래부터 갖고 있는 NAC에 대한 비전은 바로 이 점에 착안한 것이었다. 결국 네트워크로 접속된 모든 장비가 사양에 맞도록 보장하고 바이러스로부터 자유롭게 하기 위한 논리적 장소는 접속 지점이라는 것이다.
이같은 생각에는 확실히 일리가 있긴 하지만 많은 경쟁 업체들은 네트워크를 처음부터 끝까지 철저히 감시하는 데 따르는 엄청난 가격이 없이도 같은 이점을 제공할 수 있는 기회를 포착했다.
오늘날에는 전면적(full-on) 업그레이드에 대한 대안으로 호스트 기반(host-based), 인라인(in-line), 그리고 대역외(out-of-band) NAC 등 크게 세 집단이 경쟁을 벌이고 있다. NAC 이머션 센터에서 보다 심도 깊게 다루겠지만, 각 방안에는 나름의 장단점이 있으며, 제품의 아키텍처와는 별 관련이 없고 업체측의 핵심 경쟁력과 관련이 많은 것들도 있다.
각 집단에서 최고의 제품을 가려내기 위해 앞으로 몇 개월간 본지에서는 대역외와 호스트 기반 시스템에 대한 롤링 리뷰를 실시할 것이며, 우선은 대역내 NAC에 초점을 맞추기로 한다.
우리는 이런 방안들을 독립적으로 테스트했지만, 어떤 조직들은 다른 영역에서 한 가지 이상의 제품을 사용하고 싶을 수 있다. 그러나 네트워크의 같은 부분에는 한 가지 이상의 방법을 쓰지 말기를 바란다. 그렇지 않으면 다중 정책 세트로 인해 사용자가 곤란을 겪음으로써 헬프데스크 호출의 홍수 속에 잠겨버릴 수 있다.
이름에서 알 수 있듯이 인라인 NAC에서는 어플라이언스가 트래픽 흐름 안에, 언제나 에지와 디스트리뷰션 스위치 사이에 배치돼야 한다. 대신 대역내 어플라이언스는 데이터 센터 전면에 배치될 수 있는데, 이것은 TNT(Trusted Network Technologies) 같은 업체에서 선호하는 방식이다.
제품이 어디에 놓이든 간에 가장 중요하게 고려해야 할 것은 이것이 트래픽 흐름을 방해하지 않도록 하는 것이다. 이 시장에 진출한 대부분의 업체들은 용도에 맞게 제작된 ASIC(Application-Specific Integrated Circuit)을 이용해 최고의 성능을 제공하고 있긴 하지만, 트래픽 흐름을 처리하는 데 대한 규정이 복잡해지면서 ASIC에서 멀티코어의 범용 프로세서로 이러한 작업이 이동하고 있는 것도 사실이다. 선명치 못했던 라우터 전쟁 때와는 달리 인라인 NAC 업체들은 특히 막대한 패킷 프로세싱이 요구될 때 자사 시스템의 성능 한계에 대해 상당히 솔직한 편이다.
하지만 이들은 당신이 물어볼 경우에만 솔직할 뿐이다. 회선 속도로, 혹은 그에 가깝게 패킷을 옮길 수 있는 능력을 인라인 NAC 업체들의 핵심 경쟁력이라고 하기에는 아직 가야 할 길이 멀다.
투명한 설치
인라인 NAC가 실용적이 되기 위해서는 고성능 ASIC 디자인에서의 숙련도와 함께, 프로토콜 및 정책 프로세싱용의 멀티코어 엔진이 필요하다. 이러한 디자인의 이점은 모든 트래픽이 흐름별로 정책에 대한 평가를 받을 수 있다는 것이며, 이는 대역외 시스템에서는 불가능한 일이다.
아이러니컬하게도 대역내 NAC 시스템은 고도로 정밀한 수준으로 정책을 이행할 수 있는 능력을 갖고 있지만, 반면에 자신들의 정책 관리 시스템의 사용 편의성과 완전성을 기반으로 스스로를 차별화하고자 하는 곳은 대역외 업체들이다. 이러한 차이가 두 개 집단과 업체들을 어떻게 나누는지에 대해서는 이들 각 제품을 평가할 때 함께 분석해보기로 한다.
정밀한 정책 시행과 함께, 인라인 NAC는 투명에 가까운 설치를 제공한다. 기존 스위치를 교체하든, 혹은 새로운 레이어의 스위칭을 제공하든 관계없이 인라인 NAC 시스템은 네트워크에 단지 다른 또 하나의 스위치로 보여진다.
이와 대조적으로 다른 NAC 대안들은 802.1x 같은 네트워크 프로토콜이나 DHCP(Dynamic Host Configuration Protocol) 관리, 혹은 가상랜 조종 기법을 이용하며, 이들은 모두 기존 네트워크 동작의 변경을 필요로 한다. 그리고 이러한 시행 메커니즘들은 흐름당 기반이 아니고 전체 트래픽에 적용되는 둔감한 방식이기 때문에 대역외 시스템들은 전반적으로 액세스를 허용, 혹은 거부하거나, 치료나 재평가를 강행하는 것까지만 제한된다.
일부 인라인 제품들은 애플리케이션 레이어까지 도달하는 정책 시행을 주장하고 있다. 사용자의 액세스를 이들에게 사용이 허가된 시스템과 서비스까지로 제한하고자 하는 조직을 위해, 인라인 NAC는 이러한 보안 상태를 시행하는 데 필요한 메커니즘을 제공한다. 이러한 정책의 이점들은 너무도 확실한데, 이는 사용자나 호스트가 기능을 할 수 있는 데 필요한 네트워크 서비스로만 액세스를 허용하고, 다른 모든 액세스를 거부함으로써, 악의적 사용자나 감염된 컴퓨터로 인해 손해를 볼 가능성이 크게 줄어든다는 것이다.
| 인라인 NAC 롤링 리뷰 초대 롤링 리뷰에서는 액세스 레이어와 디스트리뷰션 레이어 스위치들간에 설치돼 NAC 정책을 평가하고 시행도 할 수 있는 NAC 제품에 초점을 둘 것이다. 우리는 대중에게 개방된 회의실, 관리되는 컴퓨터가 들어 있는 내부 네트워크 세그먼트, 그리고 원격 근로자 등과 같이 몇 가지 일반적인 상황들을 테스트할 계획이다. 테스트를 받는 대역내 NAC 제품은 802.1x, 가상랜(VLAN) 조종, DHCP 제어, ARP 제어, 혹은 인라인 차단 및 기타 적절한 메커니즘 등 어떠한 방안을 이용해서든 정책을 시행하게 된다. 회사들은 NAC를 내부 자원을 공격으로부터 보호하면서 동시에 사용자와 호스트가 네트워크에 수행할 수 있는 행동을 제한하기 위한 하나의 방편으로 보고 있다. 호스트의 상황을 기반으로 ‘온’이나 ‘오프’를 선택하는 바이너리 정책은 충분히 효과를 발휘할 수 있을 만큼 강력하지 못한 경우가 많다. 이보다도 정책은 사용자와 장비가 네트워크에서 상호작동할 수 있게 허용하면서 동시에 수용 가능한 호스트 상태를 유지할 수 있게 해주는 액세스 규정을 적용시킬 필요가 있다. 테스트에서 우리가 만드는 정책과 목표는 이러한 원칙을 반영하게 될 것이며, 우리는 제품이 지켜야 할 수용 가능한 상태를 지정할 것이다. 마찬가지로 시행 결정이 언제나 ‘허가’나 ‘거부’인 것은 아니다. 사용자에게 경고보내기, 백그라운드에서 업데이트 시작하기, 특정 자원으로의 액세스 제한하기, 혹은 호스트 검역하기 등 시행에 있어 다양한 선택이 가능할 것이다. 그리고 각각의 참가 제품이 얼마나 큰 유연성을 제공하는지 평가해 볼 생각이다.
참가 업체
테스트베드
약속 |
똑똑한 방화벽
인라인 NAC 어플라이언스를 방화벽이라고 부르는 것은 아인슈타인을 땜장이라고 하는 것과 같다. 즉 본질적으로는 맞는 말일지 모르지만 엄청나게 과소평가된 말이다. NAC 어플라이언스는 아주 똑똑한 방화벽이다. 예를 들어 이들은 침입 탐지 시스템으로 작동하면서 변칙적 행동 탐지와 정책 시행을 보강하고 알리는 다른 모니터링 기능들을 제공할 수 있다. 이와 대조적으로 일부 대역외 NAC 제품들은 네트워크 행동을 모니터링할 수 없기 때문에 공격을 전혀 탐지할 수 없다.
하지만 호스트를 액세스하는 프로세스는 여러 NAC 이행에서 문제의 지점이다. 보통 이 평가에는 시스템을 점검하고 이들의 상황에 대해 다시 보고해 주는 에이전트 설치가 필요하지만 인라인 구성에서는 에이전트가 불필요할 수 있다.
NAC 어플라이언스는 네트워크 트래픽을 모니터링하고, 인증된 사용자를 IP와 MAC 어드레스에 대조시키기 때문에, 좋은 데스크톱 관리 프랙티스가 있는 조직에서는 액세스를 제어하는 데 충분하다. 게다가 보너스로 인라인 기술은 프린터같이 에이전트를 돌릴 수 없는 시스템을 평가하는 데 사용될 수도 있다.
몰론 이 같은 모든 좋은 점은 인라인 어플라이언스를 어디에 배치해야 하는지에 대해 제대로 된 아키텍처적인 의사결정을 내리는 데 내포된다. 적절한 성능이 있다는 전제 하에 인라인 아키텍처는 네트워크 코어에 더 가깝게 사용되는 어플라이언스 수가 적을수록 더 간단하고 저렴해진다. 하지만 어플라이언스가 네트워크 에지에서 멀어지면 공격에 노출될 시스템 수도 늘어난다. 어플라이언스는 실제로 이것을 통과하는 트래픽을 제어할 수 있을 뿐이다. 악성이라 하더라도 세그먼트간 트래픽은 방해를 받지 않는다는 얘기다.
그리고 이러한 첫 수비는 전쟁의 절반에 지나지 않는다. 사용자나 시스템이 일단 네트워크로의 액세스를 허가받으면, 공격을 막기 위해 지속적인 모니터링이 필요하다. 인라인 시스템은 침입이나 네트워크 비정상 활동 탐지 및 감사 활동을 제공함으로써 이러한 문제에 대응한다.
침입 및 이상 활동 탐지 기능은 공격자를 발견하거나 비정상적 행동에 경보를 보낼 수 있지만, 이것은 단 이런 시스템이 포함된 트래픽을 실질적으로 볼 경우에 한정된다. 이런 모니터링이 목표라면 인라인 어플라이언스를 가능한 한 에지 스위치에 가깝게 배치하는 게 확실히 바람직하다. 게다가 규제가 심한 특정 업계에서는 네트워크 활동의 로깅 및 감사가 필요하며, 인라인 NAC 시스템은 리뷰용으로 포괄적인 로그 데이터를 제공할 수 있다.
호스트 평가 및 시행과 함께, 살펴봐야 할 몇 가지 핵심 요소들이 있어 짚어 보기로 한다.
구입에 앞서
>> 인라인으로 배치되는 어플라이언스는 어떤 것이든 네트워크 설계자에게 공포심을 주는 경향이 있다. 이것은 오류 지점이 될 가능성이 높고, 병목의 가능성도 많기 때문이다. 따라서 인라인 어플라이언스는 스위치들간에 종종 기가비트 업링크를 이용해 데이터 속도를 지원할 뿐만 아니라, 대기시간이나 지터 추가가 거의, 혹은 전혀 없이 회선 속도로 지원하는 게 중요하다.
앞서 언급한 것처럼 대부분의 NAC 어플라이언스는 패킷 처리용으로 고안된 특수 용도의 하드웨어를 사용하지만, 마케팅 자료에 있는 성능 주장들은 조심해야 한다. 이러한 수치들은 NAC 기능성 감소를 전제로 하거나, 혹은 실제의 네트워크 상황을 반영하지 않은 최적의 트래픽 조합을 기반으로 하는 경우가 많기 때문이다. 인라인 NAC 어플라이언스 대금을 지불하기 이전에, 이것을 라이브 네트워크에 배치해 보고 페이스 유지할 수 있을지 확인해야 한다.
>> 하드웨어 오류시 네트워크가 접속을 유지하도록 보장하는 데 있어 중복성은 필수다. 어플라이언스는 핫스왑이 가능한 N+1개의 팬과 전원공급기가 있어야 하며, 그렇지 않을 경우 최소한 오류시 패킷 흐름을 중단시키는 게 아니라 트래픽을 통과시킬 수 있도록 페일 오픈(fail open)에 대한 옵션이 있어야 한다. 물론 보호되지 않는 상태로 사용자의 생산성을 유지하는 게 나은지, 아니면 어플라이언스가 고쳐질 때까지 이들을 단절시키는 게 나은지를 결정해야 할 필요도 있 을 것이다.
| 인라인 NAC 인라인 NAC 벤더들은 자사의 제품이 아웃오브밴드 방식의 제품들보다 뛰어나다고 말한다. 그 이유는 이들이 어플라이언스를 통과하는 모든 트래픽을 모니터링하고 필터링까지 할 수 있으며, 케이블 재배치 이외의 다른 어떤 네트워크 변화도 필요로 하지 않기 때문이다. 네트워크를 볼 수 있다는 것은 웜, 스캔 및 DoS 공격같은 악성 트래픽에 대해 조처를 취할 수 있다는 뜻이기도 하다. 최상의 NAC 배치 스타일에 대한 논쟁은 근본적으로 두 가지 원칙에 의거하는데, 첫째는 평가가 언제 이뤄지는가, 그리고 액세스 제어가 어떻게 시행되는가 하는 것이다. 아웃오브밴드 NAC 제품들은 일반적으로 장비 상태를 기반으로 네트워크에 호스트를 두고 제한하는 반면, 인라인 NAC 장비는 다양한 범주를 기반으로 네트워크 장비로의 액세스를 제한하는 경향이 있다. 즉, 아웃오브밴드 제품과 달리 인라인 NAC 제품은 다양한 범주를 기반으로 네트워크 자원으로의 액세스를 세밀하게 제한한다. 쉽게 말해 인라인 NAC는 포트 기반 방화벽과 보다 유사하다고 생각하면 된다. 물론 인라인 NAC는 방화벽과 같다라고 말하는 것은 컴퓨터를 계산기라고 말하는 것처럼 지나친 평가절하가 될 것이다. |
‘랜실드 컨트롤러·랜인포서·에지월’주목
성공적인 공격에 꼭 필요한 한 가지를 꼽으라면? 바로 액세스다. 어떠한 보안 전문가나 침투 테스터든, 일단 네트워크에 들어온 사람이면 IT 시스템을 전복시키는 건 시간 문제라는 데는 이견이 없을 것이다.
공격자들에게 무선이 대단한 보물창고가 되는 것도 바로 이런 이유에서다. 즉, 네트워크 액세스가 더 이상 물리적 건물에 제한을 받지 않기 때문이다. 무선 암호화 같은 보안 방안들이 기밀 데이터의 기밀성을 지켜주긴 하지만, 가장 핵심이 되는 수단은 무선랜으로의 액세스를 허용하기 이전에 사용자와 시스템을 인증하는 것이다. 유선 네트워크에서도 마찬가지다. 회사들은 WEP의 약점 때문에 고민하면서도 하청업체, 컨설턴트 및 기타 게스트들에게 아무 생각없이 유선 네트워크로의 접근을 허용하고 있었다.
관리 인터페이스, 정책이 쉽게 표시돼야
이제 인라인 NAC(Network Access Control)의 세계로 들어가 보자. 액세스 레이어 스위치와 분산, 혹은 코어 스위치 사이에 설치되는 인라인 NAC는 네트워크에서 초크포인트(choke point)를 만들며, 검열을 통과하는 시스템만이 출입이 허용된다. 이것은 액세스 허용/액세스 거부의 이분법적 결정보다 한 발짝 더 나아간 것이다. 인라인 NAC 어플라이언스는 네트워크 서버와 서비스로의 액세스를 세밀하게 통제한다. 이것은 인증 전용의 액세스 제어 시스템을 괴롭혀 온 널리 개방된 출입 권한 문제를 덜어줄 수 있는 강력한 툴이다.
이번 롤링 리뷰용으로 테스트한 제품들, 즉 컨센트리네트웍스(ConSentry Networks)의 ‘랜실드컨트롤러(LANShield Controller)’, 네비스네트웍스(Nevis Networks)의 ‘랜인포서(LANenforce)’, 그리고 버니어네트웍스(Vernier Networks)의 ‘에지월(Edgewall)’ 등에서 액세스 제어는 컴퓨터가 네트워크에서 통신을 시작할 때 적용됐다.
전제 조건은 모든 호스트가 IP 구성용 DHCP, 이름 분해(name resolution)용 DNS, 그리고 윈도 환경에서 로그인과 등록용으로 도메인 컨트롤러(Doamin Controller) 같은 몇몇 서비스로의 액세스를 필요로 한다는 것이다.
다른 서비스들로의 보다 폭넓은 제어는 사용자 이름이나 그룹 멤버십, 호스트 조건 및 시간 등과 같은 조건을 기반으로 사용자에게 적용된다. 액세스 제어는 전통적인 방화벽 규정과 유사한데, 여기서는 소스와 목적지 IP 주소, 서비스 및 행동(허용, 거부, 혹은 방향조정 등)이 정의된다. 사용자나 컴퓨터의 상태 변화에 따라 시스템은 가장 잘 맞는 것을 기반으로 행동하게 된다.
모든 어플라이언스는 투명하게 설치됐으며, 네트워크 케이블을 꽂기만 하면 됐다. 버니어 에지월의 경우에는 하나의 단일 업링크에 많은 호스트 접속 링크를 모을 수 있게 해줬다. 인증 상태와 사용자 이름은 수동 인증 스누핑(snooping)을 통해 탐지됐으며, 사용자의 그룹 멤버십은 디렉토리로부터 풀링될 수 있었다. 시행(enforcement) 기능 덕분에 호스트와 서비스로의 액세스를 제어하고, 인증 오류나 호스트 평가(assessment)시 웹 포털로 사용자를 방향조정(redirect) 할 수 있었다.
각 제품들이 차이를 드러낸 부분은 정책 개발, 호스트 평가 능력, 접속 후 모니터링, 그리고 보고 및 장애관리였다. NAC는 이행하기가 복잡하기 때문에 관리 인터페이스는 반드시 정책이 쉽게 표시되도록 해야 하며, 반복을 줄이는 동시에 세밀한 액세스 제어 결정이 가능하도록 해야 한다. 제품들은 또한 관리자에게 동향 파악 및 분석을 위한 전반적 보고서뿐만 아니라 장애관리용으로 상세한 정보를 제공해야 한다.
규칙 만들기
단지 게스트에게 제한된 액세스를 주면서 기업 사용자로 하여금 네트워크를 전면적으로 돌릴 수 있게 하고 싶거나, 혹은 사용자 그룹을 기반으로 특정 서버로의 한정된 액세스를 허용하고 싶은 요구에 관계없이, 관리에 있어 가장 많은 시간을 들이게 되는 곳은 바로 정책 개발이다.
계층적 관리(hierarchal management)에서는 부모 역할에 적용되는 규칙(rule)이 자식 역할로 상속된다. 컨센트리의 관리자는 계층적 관리를 사용하는 반면, 네비스 관리자는 규칙 그룹을 사용한다. 버니어는 반복적인 정책 개발을 필요로 하는 구식 모델에 의존하고 있다.
에지월은 컴퓨터가 이들의 상태와 관계없이 액티브 디렉토리나 웹 포탈 같은 당신의 인증 시스템과 DHCP나 DNS 같은 기본 서비스로의 액세스를 필요로 한다. 계층적 관리의 경우, 이를 이용해 복잡한 정책을 단 1회 정의할 수 있으며, 이것은 다시 사용할 수도 있을 것이다. 이와 대조적으로 버니어 모델에서는 정책 구성 작업을 반복해야 했기 때문에 우리의 비교적 간단한 테스트 네트워크와 정책 세트로도 사용자의 네트워크 접속을 끊게 만들고 장애관리를 어렵게 하는 실수가 유발됐다. 더 복잡한 정책은 아마도 관리가 불가능할 것이며, 이것은 버니어에서 반드시 해결해야 할 문제다.
호스트 평가
그 가치에 대해 뜨겁게 논의가 되고 있는 호스트 평가에는 설치돼서 실행되고 있는(혹은 실행되고 있지 않는) 소프트웨어 확인에서부터 패치 구성, 그리고 정책이 적용되고 난 후의 네트워크 활동 모니터링에 이르기까지 모든 것이 포함된다. 네트워크 모니터링은 인라인 제품에서만 가능한 고유의 장점인데, 그 이유는 어플라이언스가 이것을 통과하는 모든 패킷을 볼 수 있기 때문이다.
컨센트리와 네비스의 호스트 평가 능력은 둘 다 부족했다. 컨센트리는 체크포인트의 ‘인티그리티 클라이언트리스 시큐리티(Integrity Cientless Security)’ 제품을 라이선스한 반면 네비스는 자사 고유의 액티브X 에이전트를 만들었지만 호스트 평가용으로 옵스와트(Opswat)의 라이브러리를 라이선스했다. 하나의 정책이 보편적으로 모든 호스트에 적용이 됐는데, 이 때문에 확인할 수 있는 조건과 평가를 기반으로 하여 만들 수 있는 액세스 의사결정이 제한을 받는다. 네비스의 에이전트에는 사용자가 도메인에 로그인을 했거나 로컬이거나 관계없이 컴퓨터에서 로그오프한 때를 파악할 수 있는 독특한 기능이 있다.
버니어의 장점을 보자면, 그 관리 시스템은 우리가 다중 호스트 평가 범주를 정의하고 이들을 역할에 적용시킬 수 있게 해준 유일한 시스템이었다. 컨센트리와 네비스는 호스트 평가를 글로벌 구성으로 간주해서 들어오는 모든 것들을 똑같이 대우했다. 컴퓨터마다 서로 다른 평가 필요조건이 있을 이유는 너무도 많다. 버니어는 자체적인 호스트 에이전트를 만들었지만 옵스와트의 평가용 라이브러리를 사용하고 있다.
버니어의 에지월은 또한 네서스(Nessus) 스캐너를 이용해 네트워크 기반의 평가를 할 수 있도록 지원한다는 점에서 두드러지는데, 이것은 에이전트가 설치되지 않은 곳에서 유용한 능력이다. 세 제품 모두가 악성 활동에 대해 네트워크 트래픽을 분석하지만, 탐지할 수 있는 행동 유형에서는 서로 다른 모습이다.
세 제품 모두 이상 행동(anomaly)을 탐지하지만 네비스 랜인포서만이 브라우저 기반의 익스플로이트(exploit) 같은 클라이언트 지향적 행동과 IM 같이 정책에 민감한 애플리케이션의 실행을 발견할 수 있다. 버니어는 클라이언트와 서버 기반의 보다 폭넓은 네트워크 공격을 모두 확인한다.
이상 행동 탐지는 특히 새로운 웜 발견과 네트워크 스캔용으로 유용한데, 그 이유는 둘 다 명확하고 쉽게 탐지가 가능한 시그니쳐를 남기기 때문이다. 물론 이상 행동 탐지는 폴스 포지티브(false positive)가 되기 쉽기 때문에 얼마간의 튜닝이 필요하다. 경보 전송에서부터 호스트 검역에 이르는 일련의 조처들은 이상 행동 탐지와 연결될 수 있으며, 일상적인 멀웨어들로부터 제대로 된 보호 기능을 제공할 수 있다.
더욱 조심해야 할 것은 보트(bot), 스파이웨어, 웜 및 트로이언 행동 같은 클라이언트 기반의 익스플로이트다. 네비스는 주로 이런 것들에 초점을 맞춘 반면 버니어는 클라이언트와 서버 문제를 둘 다 찾는다. 서버 익스플로이트 탐지는 악의적 침입자들의 공격을 발견하는 데 유용하다. 시그니처 정책은 필요에 따라 가동, 혹은 정지될 수 있으며, 두 회사 모두 서비스 계약이 유지되는 한 새로운 취약성과 멀웨어가 탐지될 때 업데이트를 발표하고 있다.
보고 능력
모든 보안 업체들은 ‘규정 준수 솔루션’을 선전하고 있으며, 컨센트리와 네비스 및 버니어 또한 예외가 아니다. 인라인 NAC 어플라이언스는 그 위치로 인해 네트워크에 있는 프로토콜, 애플리케이션 및 활동에 대한 고유의 뷰를 갖고 있다. 호스트 평가 작업 동안 어떠한 데이터가 수집되느냐에 따라 종단지점 구성에 대해서까지 보고가 가능하다. 포함된 보고서로 만족되는 준수 보고도 있겠지만, 전체적인 그림을 얻기 위해서는 이 데이터에 다른 네트워크 통계를 합할 필요가 있을 것이다.
보고는 일별, 주별, 혹은 큰 그림을 제공하는 월별 롤업(roll-up)이 포함돼 있다. 불행히도 버니어의 경우에는 롤업 보고 기능이 없어서 실시간 이벤트 보기나 시스로그(syslog)를 이용해 외장 서버로 데이터를 엑스포팅할 수밖에 없었다. NAC 제품에서 완전한 로그 분석 기능을 기대했던 것은 아니지만, 히스토리 동향 분석과 자동화된 보고는 기본적으로 있어야 하는 것들이다. 컨센트리와 네비스는 보다 심도 깊은 보고 기능을 제공했다.
컨센트리와 네비스의 관리 제품은 장기적인 동향 분석 및 보고용으로 유용하게 사용될 수 있는 스케줄 기능을 제공했다. 컨센트리의 보고 템플릿이 네비스 것보다 더 강력하고 구성이 용이했다. 게다가 네비스에는 보고 템플릿이 거의 없었으며, 맞춤 동향 보고서를 만드는 데는 크리스탈 리포트(Crystal Reports)에 의존했다.
네비스가 우월한 영역은 장애관리다. 네비스에서 제공한 툴을 이용해 접속 문제를 쉽게 발견하고 분석할 수 있었던 데 반해 컨센트리 제품에서는 더 많은 노력이 필요했다. 버니어의 장애 관리 툴은 아쉬운 부분이 상당히 많았다. 결국 에디터즈 초이스나 최고 가치상으로 꼽을 만한 제품은 하나도 없었다. 하지만 컨센트리의 랜실드와 네비스의 랜인포스는 모두 추천 제품 목록에는 오를 수 있었다.
실제로 승리자는 기업의 IT 그룹들이라 할 수 있다. 인라인 NAC 업체는 냉전시대 군비 경쟁과 같은 치열한 경쟁을 벌이고 있기 때문이다. 올해 1분기에 출시될 컨센트리의 최신 버전은 이미 강력한 성능이 한층 더 보강될 것이다. 버니어는 정책과 보고 쪽에서 개선해야 할 부분이 있지만, 컨센트리와 네비스는 버니어의 플레이북 내용을 가져 와서 자신들의 호스트 평가 기능을 강화할 수 있을 것이다. 이 부문은 앞으로도 계속 지켜볼 작정이다.
