Test Review 호스트 침입 방지 시스템
상태바
Test Review 호스트 침입 방지 시스템
  • 데이터넷
  • 승인 2007.03.19 00:00
  • 댓글 0
이 기사를 공유합니다

최강의 데스크톱 보호 솔루션으로 ‘유망’
안티바이러스 등에 대한 포괄적 대안 … 아직은 성숙 과정

나쁜 녀석들은 들어오고 싶어하고 당신은 이들을 막고 싶어한다. 호스트 침입 방지(Host Intrusion Prevention System) 기술은 방화벽, 안티바이러스, 안티멀웨어 및 네트워크 침입 방지를 대체할 수 있는 포괄적인 전략을 약속해 준다. 그러나 이것을 과연 신뢰할 수 있을까? 이 새로운 기술의 현황에 대해 검토해 보자.

HIPS(Host Intrusion Prevention System), 즉 호스트 침입 방지 시스템은 비교적 새로운 종단지점 보호 기술이지만, 이것은 대부분 기존의 보안 시스템을 기반으로 구축이 된다. 즉 HIPS는 안티바이러스 소프트웨어의 바이러스 보호를 계속 사용한다. 그리고 안티멀웨어 제품으로부터 멀웨어 스캐닝을 가져다 쓴다. 그리고 네트워크 침입 방지 툴에서는 네트워크 인터페이스 모니터링을 사용한다.
그렇다면 이런 모든 툴을 갖추고 있는 엔터프라이즈에서는 왜 또 하나의 레이어를 추가해야 하는지 의문이 생길 법도 하다. 하지만 HIPS는 부분을 합해 놓은 것보다도 더 많은 것을 가져다 준다.

가장 포괄적인 데스크톱 보호 제품
본지에서 실시한 테스팅과 분석을 통해 HIPS는 지금까지 나온 것들 가운데 가장 포괄적인 데스크톱 보호 제품 영역이 될 수 있는 가능성을 강력히 시사했다. 아무리 신용있는 업체도 업체도 제로 데이(zero-day) 공격을 100% 물리칠 수 있다고 장담을 못할 것이다. 하지만 HIPS 기술은 버퍼 범람(buffer-overflow)과 힙 악용(heap exploits)에 대해 메모리 보호를 사용하고, 공격자가 데이터 세그먼트에서 코드를 구축 및 실행하지 못하게 막아주는 보호 방안을 실행하며, 허가받지 않았거나 비일상적인 파일 액세스를 주시함으로써 이에 근접할 수 있다.
그리고 내부 네트워크의 상대적인 안정성에서 벗어나 있는 기계에 대해 공격 벡터들이 늘어나는 시점에서 HIPS는 IT에게 공격 소스를 식별 및 제한하고 취약 지점을 강화시켜주는 새로운 보호책까지 가져다 준다.
이 기술은 아직 계속 진화하고 있는 상태다. 예를 들어 지금 나와 있는 제품들로는 모든 유형의 장비를 커버할 수 없다. 일부 업체들이 PDA와 스마트폰에 대한 보호책을 모색하고 있긴 하지만, 아직 그 수준에 도달하지는 못했다. 그리고 몇 가지 의문점들도 여전히 존재한다. HIPS가 언제나 대행자(agent)를 필요로 할까? 이들은 침략적인 습성을 갖고 있는가? 그리고 HIPS는 어떻게 자기들의 주문을 외는 것일까?
우리는 이런 의문을 해결하기 위해 디터미나(Determina), ISS 및 맥아피(McAfee) 제품들을 테스트해 보았지만 사실 이 업체들은 다양한 백그라운드에서 출발했기 때문에 HIPS로 가는 한 가지 왕도는 없다고 해야 할 것이다. 한 가지 공통 분모가 있다면 이런 제품이 당신의 서버나 데스크톱에 제공하는 보호의 수준이 지금까지 가능했던 수준보다 낫다는 것이다.
조직에서 HIPS가 필요한지 여부를 아직 결정하지 못했다면 이런 상황을 가정해 보라. 새로운 멀웨어 조각이 방화벽을 통과하게 됐다고 하자. 즉 사용자가 이것을 다운로드했을 수 있다. 이제 이것이 안에 들어와 있으면 NIPS(Network Intrusion Prevention System)가 이것이 네트워크에 전파되지 못하도록 막아야 할 것이다. 하지만 멀웨어는 똑똑하다. 이것은 자신을 마치 정상적인 네트워크 트래픽인 것처럼 위장하고, 천천히 엔터프라이즈로 퍼지면서, 전체 조직의 패스워드에 대한 멋진 컬렉션을 만들어 내는 키로거(keylogger)를 설치한다.
그리고 이 정보를 HTTP를 통해 보고함으로써 컨텐츠 필터는 패스워드가 아니라 허용되는 프로토콜을 통해 빠져 나가는 엉뚱한 것들을 보게 된다. 더욱 나쁜 상황에서는 스크램블링된 고객의 신용카드 정보를 내보낼 수도 있다.
그러나 이러한 바이러스 기술은 벌써 존재하고 있다. 한 번의 잘못된 다운로드가 당신에게는 악몽을 불러올 수도 있는 일이다.

미래의 구멍
일상에서 고개를 들어 몇 년 앞을 내다보고 미래를 점쳐 보면 기술 개발에 있어 몇 가지 흥미로운 지점들이 눈에 띌 터인데, 우리에게 보이는 것은 바로 호스트 기반 침입 방지다.
안티바이러스 소프트웨어는 지난 5년, 혹은 10년 동안 기본적으로 같은 모습을 유지해 왔다. 물론 업체들은 서명을 최신으로 유지하고, 스캐닝 기능을 개선하는 데 투자를 했지만 혁신적인 큰 발전은 이루지 못했다. 즉 안티바이러스 소프트웨어는 여전히 명령에 따라(on command) 바이러스를 스캐닝하고 있다. 물론 일부 업체들은 파일이 디스크에 기록되거나 이메일을 통해 전송이 될 때 ‘온 커맨드’가 포함되도록 하기도 했지만, 이것은 단지 다르게 불러내는 것뿐이지 같은 맥락의 기술이다. 그리고 행동 방안(behavioral approach)을 채택한 곳들도 있긴 하지만 대부분 여전히 서명을 사용하고 있다.
이제 HIPS로 들어가 보자. 이 제품들은 일반적으로 AV 소프트웨어와 같은 단계를 수행하지만, 여기에 이들이 돌아갈 때 작동에 문제가 있는 애플리케이션을 탐지하고, 정상적인 IP 커뮤니케이션의 경계에서 벗어나 있는 시스템(서버나 데스크톱)에 들어오는 흐름을 찾으며, 멀웨어를 찾아내 죽일 수 있는 능력을 추가시켰다.
그렇다면 앞으로 5년 후 이 시장은 어디로 향하게 될까? 가정에서나 기업에서나 마찬가지겠지만 오늘날 우리가 알고 있는 안티바이러스 프로그램은 더 이상 존재하지 않을 것이다. 사용자들은 설치 및 유지보수해야 하는 소프트웨어가 적은 포괄적인 보호책을 원하고 있다. 주어진 HIPS가 추가된 기능성과 함께 동급의 AV의 역할을 해줄 수 있다면 더 생각할 필요도 없는 일이다.
버퍼 오버플로우 보호만으로도 HIPS는 AV에서 업그레이드 비용을 들일만한 가치가 충분하다. 개발자들은 가능한 모든 범람 상황을 점검할 수 없다. 따라서 오버플로우가 발생할 때 이것을 잡아낼 수 있는 자동 시스템을 두는 것이 기계가 공격을 당하고 난 뒤 대응을 하는 기존의 프로세스보다 훨씬 낫다.
물론, 이미 안티바이러스를 갖고 있을 것이며, 그것도 아마 저렴한 비용을 들이고 있을 것이다. 하지만 이것이 과연 돈의 문제일까, 아니면 최선의 보호책에 대한 문제일까. 개발자들은 실수를 하고 있고 앞으로도 계속 그럴 것이다. 효과적인 위험 관리를 위해서 기업은 반드시 이 점을 염두에 둬야 한다.

장애물
물론 지금 구입하는 데도 위험이 따른다. 모든 제품 부문은 성숙의 단계를 통과해야 하며, HIPS도 예외는 아니다.
우선 궁극적으로 HIPS를 구성하고 있는 것이 무엇이냐를 두고 의견이 나뉘어져 있다. 여기에 버퍼 범람 점검을 포함시켜야 하는가? 이것이 포트의 이상 행동을 주시하지 않는다 하더라도 여전이 HIPS일까, 아니면 단지 치장한 안티바이러스일까? 어떤 이들은 필수 네트워크 엘리먼트(포트, 스트림, 혹은 트래픽 스캐닝)가 있는 제품을 HIPS라 할 수 있다고 믿고 있다. 또한 많은 업체들은 특정 서버 소프트웨어용으로 전문화된 HIPS 소프트웨어를 갖고 있어 혼란을 더욱 가중시키고 있다.
HIPS 이행을 정당화하고자 하는 엔터프라이즈 IT 그룹에서 업체들의 비전에 의문을 제시하는 것도 놀라운 일은 아니다. 애플리케이션 보호를 목표로 하는 제품은 HIPS가 아니다. 이들은 주어진 애플리케이션에 대한 보호책이다. 내 SQL 서버를 보호한다는 것은 내게 멋진 서비스를 하고 있는 것이긴 하지만 호스트를 침입에서부터 보호하고 있는 것은 아니다.
이제 일부 업체에서는 애플리케이션 전용 보호에 진정한 HIPS 기능성을 결합시키고 있는데, 이것은 이 제품을 결정짓는 요소라기보다는 하나의 차별화 요소가 될 수 있다. 핵심 HIPS 기능성은 호스트 시스템을 보호해 주는데, 이러한 핵심 HIPS 기능들로는 포트 보호, 메모리 보호, 안티바이러스 및 파일/레지스트리 보호 등을 들 수 있다. 다른 모든 기능들은 부가적인 것이며, 업체가 발빠르게 움직일 경우 별도의 매출 흐름 창출에 이바지할 수도 있을 것이다.

HIPS는 거짓말을 하지 않는다
HIPS의 성능 영향에 대해서는 FUD(fear, uncertanty, doubt)가 무성하다. 업체들은 한 단계 더 나아가 인식이 잘못됐다는 것을 입증하거나, 혹은 문제를 깨끗이 인정하고 사용자들이 연관 비용을 이해할 수 있게 도와야 한다.
우리 테스팅을 근거로 할 때 성능 손상은 눈에 띄긴 했지만 과도한 수준은 아니었다. 우리가 봐야 하는 것은 실질적인 수치를 제시하는 업체들이다. 즉 60%의 서버 활용도에서 돌아가는 서버는 5%도 더 감당하기 힘들지만, 1~2%로 작동되는 데스크톱은 전혀 아무런 걱정 없이 HIPS를 감당할 수 있을 것이다.
업체측에 의해 철저히 다뤄져야 하는 또 한 가지 문제는 엔드유저로 하여금 정상적인 작업을 수행하지 못하게 한다는 두려움이다. 본지 독자 설문조사에서 HIPS를 사용하는 응답자들 가운데 거의 50%가 한 차례 이상 직원들의 불만을 들은 바 있다고 답했다.
HIPS가 하는 일 가운데 어떤 것은(특히 메모리 보호 영역에서) 치료 행위가 취해지고 있다는 것을 사용자에게 통보하지 않고 진행되기도 한다. 예를 들어 파일을 저장할 때 엑셀에서 다른 어떤 통보도 없이 “디스크에 기록할 수 없습니다”가 나올 수 있다. 이 파일이 만약 회사 예산 보고서라면 이것은 매우 기분 나쁜 소식이 될 것이다.
이것은 이름에 방어란 말을 달고 있는 제품이라면 언제나 끊임없이 따라다니는 문제다. 업체들은 단지 이 문제만으로 우리가 시스템 보호에 있어 다음 단계라고 생각하고 있는 기술의 성장이 지체되기 이전에 무엇이 잘못됐는지를 밝혀 내고 고쳐야 한다. 조직에 있는 모든 데스크톱에 이 침략적 기술을 배치하도록 요청을 받을 것이라는 사실만으로 이러한 상황이 개선될 수는 없는 일이다.
마지막으로, 그리고 아마도 HIPS에게는 가장 힘든 걸림돌이라고 할 수 있는 것은 프로세스가 중단됐다는 통보에 관한 것이다. HIPS가 학습 모드에 대립해 활성 모드로 설정돼 있고, 악성이라고 판단되는 코드 조각이나 스트림이 기계로 들어오는 것을 감지할 경우, HIPS는 그것을 잘라 낸다.
그리고 이런 제품들 가운데 일부 제품들이 하지 않는 일이 무엇인지 생각해 보라. 바로 사용자에게 통보하기다. 어떤 것들은 공격을 통보하고, 어떤 것들은 모든 것을 통보하지만 대부분은 정지된 쓰레드(thread)를 통보하지 않는다.
회사 네트워크의 아이어그램, CEO의 연간 보고서, 진급에 대한 상사의 추천장 등 이메일이나 파일을 저장하려는 요청이 예상대로 처리돼지 않았을 경우 사용자들이 알기를 바랄 것이다. 본지 리뷰 코스를 통해 우리는 사용자가 쓰레드나 프로세스를 죽이거나, 포트를 폐쇄하고 있다는 것을 HIPS에 의해 정상적으로 통보받지 못한다는 사실을 발견했다. 대신 HIPS는 오류를 통보하고 사용자에게 알리는 일을 애플리케이션에 의존한다.
우리는 이것이 결정적인 문제라고 생각한다. 물론 HIPS는 백그라운드에서 실행이 되고, 후프들을 통과해야만 자신이 중단시키고 있는 각각의 애플리케이션과 기능을 정확히 식별할 수 있을 것이다. 하지만 여전히 통보가 필요하다. IT나 엔드유저에게 기능 오류를 통보를 하기 위해 알지 못하는 애플리케이션에 의존한다는 것은 제품이나 기술을 당장에 죽일 수 있는 아주 멋진 방법이다.
HIPS 조사에 착수할 때는 통보 지원을 반드시 확인하라. 통보가 지원되지 않을 경우에는 작업이 거부되었을 때 사용자에게 일종의 안내가 제공되는지에 대해 업체측에서 갖고 있는 테스트된 애플리케이션을 목록을 요구하라. 없는 것보다는 이것이라도 있는 게 낫다. 여전히 인하우스의 목록에 없는 애플리케이션에 대해서는 걱정을 해야 하겠지만, 최소한 어떤 게 잘못될 것에 대한 감은 잡을 수 있기 때문이다.

학습 모드
일부 HIPS 기능성은 시스템이 무엇이 정상인지를 알아야만 얻을 수 있다. 이러한 학습은 네트워크와 기계에서 무슨 일이 발생하는지를 보고, 비정상적인 행동을 로깅하는 작업을 통해 이루어진다. 그런 다음 IT에서는 시스템에게 어떤 행동이 허용되는지를 수동으로 알리거나, 혹은 시스템이 어떤 행동을 허용해야 할지를 결정할 수 있게 해야 한다.
이것은 우리 시스템과 개발자들이 완벽하지 않다는 사실을 인정하는 것이며, IT에게 “포트 1337의 그 트래픽은 문제가 없다. 우리 개발자 중 한 사람이 문제였다”고 말할 수 있는 기회를 준다.
학습 모드는 좋은 아이디어긴 하지만 몇 가지 한계가 있다. 우선 업체들에게 중요한(혹은 사소한) 시스템 업데이트가 있은 후 재학습이 필요한지에 대해 물어보라. HIPS는 메모리, 포트 및 파일/레지스트리 액세스를 지켜보기 때문에, 심지어 애플리케이션 업그레이드 후에도(IE 패칭 등) 재학습이 요구될 수 있다.
빈번하게 변경을 하고, HIPS 재교육에 자원들을 다 쏟아 붇기를 원치 않는다면, 보다 후반응적이고 행동 데이터베이스에 덜 의존하는 제품이 적합하다고 판단할 수 있다. 아니면 첫 설치 후 학습 모드를 꺼버리고, 업그레이드를 검사할 때 테스트 환경에서의 설정을 그대로 유지하고 싶을 수도 있다.
우리는 배우는 것을 좋아하며, 재교육은 충분히 그만한 시간을 들일 가치가 있다고 생각한다. 이러한 정보를 수동으로 유지한다는 것은 에러 가능성이 높고 시간 소모적이다. 그보다는 시스템이 할 수 있는 알아내게 한 다음 결과를 조정하는 편이 더 낫다.

시스템 전체로
HIPS 스위트는 그 범위가 매우 넓어서, 네트워크 카드에서부터 메모리에서 실행되는 것까지 모든 것을 커버한다. 이는 곧 이들이 침략적(invasive)이라는 얘기다. 일단 네트워크 드라이버가 드라이버 체인에 삽입이 되고, HIPS가 스레드를 중단 및 시작할 수 있게 실행이 연결이 되면, 이제 애플리케이션에서 서비스로 선을 넘어온 셈이다.
그뿐 아니라 이런 제품들은 바로 실행 경로에 있으면서 범람에 대해, 그리고 데이터 세그먼트에서의 코드 구성에 대해 버퍼를 주시한다. 이들은 자신들이 보호하고 있는 OS와 깊숙이 연결돼 있다. 따라서 윈도를 업데이트하면 데스크톱이 보호 기능을 상실할 수도 있으며, 더욱 나쁜 경우에는 시스템 부팅이 않될 수도 있다.
우리가 언제 시스템 전반의 보호가 공짜로 얻을 수 있는 것이라고 말한 적이 있는가. 이 경우에는 업체측과 주요 시스템 업데이트를 맞추는 데(기본 OS 코드를 변경하는 어떤 것이든 포함), 혹은 문제를 야기한 변화를 찾아내기 위해 HIPS에 대조해 이들을 테스트하는 데 계속해서 수수료가 들어간다.
분명 HIPS 이행은 업그레이드 사이클의 속도를 떨어뜨릴 것이다. 하지만 우리는 이것을 그리 크게 염려하지 않는데, 그 이유는 HIPS가 제로 데이 취약성에 대해 우수한 보호 능력을 갖고 있기 때문이다. 이러한 판단은 실세계 결과를 기반으로 내린 것인데, 우리가 현장에서 만나본 본지 설문조사 응답자들은 모두가 HIPS가 제 역할을 하고 있다는 데 같은 의견이었다.
우리가 이야기해 본 모든 업체가 매우 공격적인 테스팅 스케줄을 갖고 있는 것으로 나타났는데, 그 이유는 이들이 이러한 잠재적인 문제를 인식하고 있기 때문이다. 모두가 주요 OS 업데이트를 확실히 처리하고, 비즈니스를 잃을 위험보다는 애플리케이션의 호환성을 파악하겠노라고 말했다. 그리고 그것이야말로 (부족한 OS 업데이트에 대해) 우리가 요구할 수 있는 최선의 것이기 때문에 이들의 태도는 문제가 없어 보인다.

집중식 관리 콘솔
폭넓은 엔터프라이즈 배치를 타깃으로 하는 어느 기술과 마찬가지로, 집중식 관리 콘솔은 성공적인 HIPS 배치를 위해 필수다. 대부분의 업체들이 일종의 집중식 관리를 갖고 있거나, 이것을 첫 HIPS 제품에 포함시켜 개발을 했다. 특별히 어떤 업체의 관리가 다른 업체보다 낫다고는 말하기 힘들다. 진정으로 중요한 사실은 집중식 관리 자체와 마찬가지로 이들 모두가 약점을 안고 있다는 사실이다.
맥아피나 ISS 제품 같은 제품에서는 기계 레벨을 제외한 회사 레벨에서 정책을 설정할 수 있다. 기능이 보다 떨어지는 관리 애플리케이션에서는 운영을 위한 중앙 서버가 필요하며, 기계가 언제나 회사 네트워크에 있어야 한다는 것을 전제로 하는데 이는 실제로 받아들이기 힘든 조건이다.
마지막으로 ISS 등 일부 업체들은 정립된 엔터프라이즈 기계 구성을 기반으로 하는 그룹 관리를 제공하기 위해 다양한 ID 관리 툴에 손을 대고 있는 반면에, 내부적으로 이러한 구분을 짓는 업체들도 있다. HIPS는 사용자 보고책이 아니라 기계 보호책이기 때문에 어떤 쪽이 특별히 낫다고 할 수는 없지만, 모든 기계가 하나의 ID 관리 서버안에 정의 및 그루핑돼 있는 조직이라면 다른 길로 가는 게 쉽지는 않을 것이다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.