|
|
|
|
보안 |
| Survivor's Guide To 2006 |
 |
2006년 04월 03일 00:00:00 |
|
 |
|
|
보안침해 사건으로 올해 대서특필되지 않으려면 규정을 준수하는 제품을 선택해야 한다. 어느 업체든 최소한 한 가지 규정을 만족시킨다고 주장하겠지만 이들의 과대 선전에 속아서는 안 된다.
안과 밖 모두를 완전하게 지켜라
조직들의 벽에 심심치 않게 붙어 있는 글귀가 있다. ‘조직과 개인은 보안 침해에 대한 책임을 져야한다’는 글귀다. 체크포인트(CheckPoint), 렉시스넥시스(Lexis-Nexis), 뱅크 오브 아메리카(Bank of America), 카드시스템즈(CardSystems), 그리고 기타 일군의 영리 및 비영리 조직들의 부주의한 PII(Personally Identifiable Information) 노출 사례는 시작에 불과하다. 고객들에게는 다행스럽게도 주 정부와 연방 정부의 입법자들은 노출 사례를 보고하도록 하는 규정을 만들었다. 누군가는 목이 잘리게 된다는 얘기다. 당신이 안 되도록 조심하라.
하지만 데이터 유실의 원인은 경우에 따라 다양하다. 일반적인 노출 경로는 분실하거나 도난당한 하드웨어와 백업 테이프, 내부자 소행, 그리고 보안 구멍이나 부주의한 노출로 연결되는 취약한 애플리케이션 배치 등이다. 그리고 이들은 언론에 보도되는 단순한 침해 사례에 불과하다. 명성을 복구하고, 벌금과 수수료를 물고, 손상된 시스템을 다시 구축하는 데 드는 경비는 수십, 수백만 달러까지 올라갈 수 있다. 비자(Visa)의 정책에 반해 신용카드 번호를 보유하고 있다가 사고를 당한 비자카드 처리업체인 카드시스템즈의 경우 페이바이터치(Pay by Touch)에서 회사를 인수할 때까지 거의 사업을 놓고 있는 실정이었다.
규정준수
두려움에 사로잡혀 펀딩을 확보하는 일은 장기적으로 좋은 솔루션이 못 된다. 약 40~50개의 조직들이 2005년에 공개된 노출 사례가 있었지만, 이것은 전체 미국 회사들을 감안할 때 소수에 불과하다. 비즈니스 매니저들이 이런 회사에는 다른 문제가 있으며, 자신들의 조직에서는 이런 사태가 발발하지 않으리라고 합리화하는 것도 일리가 있다.
보안 관리자는 보안 솔루션 구입에 대한 비즈니스 가치를 설득해야 한다. 물론 IPS(Intrusion Prevention System)의 비즈니스 이점을 명확히 설명하기는 힘든 일이지만, 신규 프로젝트 자금을 조성하는 일에서나 다른 IT 프로젝트에 보안 사양이 포함되도록 하는 데 있어 모두 규정 준수가 도움을 줄 수 있을 것이다. 산업 분야만 해당된다면 HIPAA(Health Insurance Portability and Accountability Act), 사베인즈 옥슬리(Sarbanes-Oxley), GLBA(Gramm-Leach-Bliley Act) 혹은 FISMA(Federal Information Security Management Act) 등과 같은 법률을 적용시킬 수 있다. 규정 준수에 실패할 경우 많은 벌금을 물어야 하는 일이 생길 수 있다.
하지만 이 북을 너무 세게 두들겨서는 안 된다. 규정 비준수로 인한 벌금이 제품을 구입해서 배치하는 데 드는 비용에 비해 얼마 되지 않을 수도 있기 때문이다. 예를 들어 HIPAA 규정을 모르고 위반했을 경우 벌금은 건당 최고액이 2만5천달러에 이른다.
하지만 프로세스 향상, 보호능력 강화 및 공격 위험 감소 등과 같은 다른 동기요소들과 더불어 규정준수 쪽을 부각시킨다면 설득력이 강화될 수 있으며, 회사에서 법적 소송에 휘말릴 경우에는 규정을 준수하고 있다는 사실을 입증하고 충분한 관심을 받고 있는 베스트 프랙티스를 보여줄 수 있다.
한편, 보안 제품 업체들은 너나 할 것 없이 관심과 돈을 모으기 위해 규정준수의 깃발을 흔들어대고 있다. 하지만 어떤 기술이 어떤 규정을 만족시킨단 말인가? HIPAA 같은 법률들은 일부 기술을 요구 및 권장하고 있지만, 기술은 변하기 마련이다. 법의 해석은 법정에서 관례가 만들어지기 전까지는 결정되지 않는다. 따라서 규정준수 문제를 처리할 때는 회사의 법률 고문과 함께 작업을 해야 한다.
그리고 규정준수가 순전히 제품에만 국한되는 문제도 아니다. 이것은 법률이나 규정을 준수하는 데 어떤 제어가 필요한지를 정하는 것에서부터 시작해, 이러한 제어가 어떻게 이행될 것인지를 문서화하고, 이것을 제공하고, 제어가 적절히 설정되었음을 입증하는 하나의 다단계 프로세스로 생각해야 한다.
HIPAA 5 CFR 164.312(d)는 PHI(Personal Health Information)에 액세스하는 사용자는 먼저 인증을 거치도록 요구하고 있다. 따라서 조직에서 이 법률을 준수해야 한다면 사용자 이름/패스워드, 토큰이나 생체인식 인증 시스템과 같은 제어 장치가 필요하다. 또한 인증 정책을 규정해주는 보안 정책 성명이 필요할 것이다. 그리고 모든 사용자가 패스워드를 갖고 있는지를 확인하는 프로세스를 문서화하는 작업도 또한 해야만 한다.
간단히 말해 감사를 하는 동안 당신이 이야기한 것을 조직에서 하고 있는지를 입증해야 하며, 여기에는 많은 비용이 들 수가 있다. 인증의 경우에는 다중 사용자 저장소를 감사할 필요가 있을 것이다. 규정 준수는 조직내에 배치된 많은 애플리케이션과 제품에 적용이 된다. 이 제품들은 필요조건을 충족시켜야 하며, 이들이 규정을 준수하고 있다는 사실을 입증할 수 있어야 한다. 신규 프로젝트를 시작하거나 기존의 프로세스를 재조정하면서 보안 이니셔티브를 만들 기회를 잡으라.
공급업체측에서 자사 제품이 규정준수를 도울 수 있다고 말할 때 가장 먼저 물어야 할 질문은 “특히 어떤 법안과 규정이냐”는 것이다. 업체측에서 이것을 확실히 말할 수 있다면 그 필요조건을 따라야 하는지를 결정해야 한다. 예를 들어 HIPAA 45 CFR 164.312(a) (2)(iii) 오토매틱 로그오프(Automatic Logoff)는 어드레서블(addressable) 기술적인 안전조치로, 이는 곧 반드시 이행돼야 하긴 하지만 그러지 못했을 경우에는 이유를 설명해야 한다는 의미다.
종단지점 액세스
IT 자원으로의 액세스 포인트는 많지만 모든 경우 액세스는 워크스테이션에 있는 사용자나 핸드헬드에서 시작된다. 워크스테이션에서의 문제는 액세스 권한이 너무 많은 사용자(랩톱 사용자들이 로컬 관리자 권한을 갖는 경우가 종종 있다)에서부터 트로이 목마, 웜 및 기타 멀웨어들의 무분별한 설치, 혹은 구성 변경 등에 이르기까지 없는 게 없다. 부적절한 보안 소프트웨어 업데이트에 의해 또 다른 액세스 포인트가 유발될 수도 있다.
전통적인 네트워크 주변경계 모델인 20/20 사후처리식(네트워크의 에지에 집중하는 방화벽, 침입탐지 시스템 및 안티바이러스 소프트웨어 등과 같은 보안 솔루션들 이용)은 이미 틈새가 있다고 보는 편이 안전하다. ‘겉은 딱딱하게, 안은 물렁하게’라는 상투적인 문구가 적용될 뿐만 아니라, 네트워크의 안과 밖을 돌아다니는 사용자들은 단순히 안과 밖에 있는 것만으로 경계를 바꾸게 된다. PDA를 포함해 컴퓨터가 없는 네트워크 안에 있다 하더라도 주변경계 모델의 경우 건물을 떠나면 웜이 내부에서 발발할 때 아킬레스건이 노출된다.
웜 발발에 대한 이상적인 대책은 패치가 발표되자마자 시스템을 패칭하는 것인데, 그 이유는 패치 통보에서 웜 발발까지 걸리는 시간이 이제 겨우 며칠밖에 되지 않기 때문이다. 비정상적인 네트워크 활동 탐지 기능과 원격 모바일 컴퓨터에 대한 타이트한 제어를 이용해 웜의 활동을 조기에 경고해 주는 출구 필터링(egree filtering)이라는 다면적인 방안은 이동 속도가 빠른 웜의 영향력을 줄여줄 수 있다.
네트워크 액세스 제어(호스트 및 사용자에 대한 지식과 네트워크 액세스를 허용하는 정책 애플리케이션의 결합)가 해답이 될 수 있을까? 아직 여기에 대해서는 확답을 할 수가 없다. 제품들이 너무 미성숙한 상태고 인프라 업체 이니시어티브들이 없긴 하지만, 네트워크 액세스 제어라는 개념 자체는 괜찮은 것 같다.
AAA(Authentication, Authorization, Auditing)는 오랫동안 컴퓨터 보안의 초석 역할을 해 왔다. 인증(authentication: 사용자가 자신이 이야기하는 사람이 맞는지 확인) 영역은 IT 환경 안에서 잘 정착이 되었다. 감사(auditing)는 전반적으로 취약하긴 하지만 이것은 대부분 IT 시스템에서 빠져 있는 기능들(이벤트 로그가 감사 로그는 아니다) 때문이라고 할 수 있다. 그리고 권한부여(authorization) 부분은 결정적으로 빠져 있는 조각이다.
인포익스프레스(InfoExpress), 사이게이트(Sygate) 및 존랩스(Zone Labs)와 같은 일부 비전을 좇는 업체들이 한동안 네트워크 액세스 솔루션을 제공해오긴 했지만, 이 모델들에는 보통 네트워크로의 액세스를 허용하는 다른 주변경계 장비가 필요할 것이다. 이는 곧 구입하고 관리하고 유지보수를 해야 할 장비가 한 가지 더 늘어난다는 얘기다. 크기는 작아지지만 더 많은 주변경계가 생기게 된다. 그러나 2006년에는 시스코, 엔터라시스 및 주니퍼 등과 같은 전통적인 인프라 업체들이 효과적인 네트워크 노드 밸리데이션(network-node validation) 제품들을 가지고 이 시장에 참여하고 있다.
인프라 모델에서는 업체들이 제품을 통합해야 하며, 대부분의 프로젝트와 마찬가지로 이런 것들을 네트워킹하는 것은 보통 API 및 컴포넌트를 지시하는 한 업체와의 일회성 관계가 될 것이다. 오픈(open)이라는 말이 사방에 돌아다니겠지만(시스코는 자사의 표준을 ‘오픈’하고 이들을 표준제작 기구에 제출할 예정이다) IEEE, IETF 및 ISO와 같은 표준화 기구들이 표준을 발표하고자 하는 업체들의 요청을 무턱대고 받아들이는 것은 아니다(IETF의 경우 시스코의 비전은 표준 트랙 문서가 아니라 정보 RFC로서 소개될 가능성이 높아 보인다).
이렇듯 다양한 배치 옵션들이 있다고 해서 네트워크를 완전히 다시 설계할 필요는 없다. 예를 들어 회사에서 지급한 장비만 네트워크에 연결되도록 하고 싶다면 802.1x를 선택하면 된다. 이것은 이미 인증을 시행하는 무선랜 배치에서 사용이 되고 있기 때문이다. 모바일 컴퓨터에 대한 제어가 더 필요하다면 스탠드얼론 시스템 배치에 타깃을 두고 출발하는 게 좋다. 그리고 이때는 확장성을 염두에 둬야 한다.
한편, TCG(Trusted Computing Group)의 TNC (Trusted Network Connect) 워크그룹에서는 부품, 클라이언트 컴포넌트, 권한부여 서버, 관련 백엔드 시스템, 그리고 시행 지점 등에 대한 표준 문서를 제작 중이다. TNC는 유사한 영역을 다루고 있고 꽤 많은 업체들이 여기에 동참하고 있지만, 시스코가 빠진 탓에 큰 구멍이 남게 됐다.
여러분이 원하는 것은 효과적이고 효율적으로 함께 작동하는 제품들이며, 이는 곧 파일로트 프로젝트와 처음 배치에서 업체들이 상호운용성을 보여줘야 한다는 얘기다. 약 80%의 커버리지는 충분치가 못하다.
IPS/IDS 동향
순수한 IPS는 이제 사라지고 있으며 대신 네트워크 방화벽의 일부가 되고 있는데, 이것은 그럴 만한 일이다. IPS 시스템은 처음 IDS 구성에서 정기적으로 배치가 된 다음 방어 서비스가 천천히 가동이 되는 방식이다.
침입 탐지에서 근본적인 문제는 폴스 포지티브(false positive)로, 이것은 경보를 유발하는 트래픽을 합법화한다. IDS 이벤트의 양은 보안 관리자를 압도할 만큼 많을 수 있다. 물론 수많은 호스트용의 IDS 서명을 튜닝, 가동 및 가동 중지시킴으로써 폴스 포지티브를 줄일 수도 있지만, 이를 위해서는 전문가가 IDS를 제대로 튜닝해야 한다. 보다 중요한 사실은 트래픽 흐름을 보호하고 있는 경우에 폴스 포지티브가 서비스 거부 공격(Denial of Service)이 된다는 것이다.
IDS/IPS 업체들은 IPS의 탐지 부문을 향상시킴으로써 폴스 포지티브 문제를 해결하려 노력하고 있으며, 지금까지는 서명 탐지만이 가능하다. 결국 IDP는 공격 가능성이 있다거나 성공했을 경우가 아니라 공격이 시도된 경우에만 통보를 해줄 수 있다. 사람들은 공격이 발생했을 때가 아니라 공격에 대해 걱정할 필요가 있는지 여부를 알고 싶어한다. 웹 서버 로그를 확인해 보라. 오래된 디렉토리 횡단 및 IIS 공격으로 가득차 있을 것이다.
이상 행동 탐지(비정상적인 행동을 기반으로 하는 트래픽 탐지)는 리칸(recon), 웜 및 정책 위반 탐지 등과 같은 특정 유형의 보안 문제보안 문제에서는 효과적이지만 타깃화된 성공적인 공격을 경고해주지 못한다.
여기서 한 발짝 진보한 것으로 서명 IDS에 능동 및 수동 취약성 분석을 결합하고, 이상행동 탐지를 추가하는 방안이 있는데, 그 목표는 탐지되는 공격 시도가 얼마나 위험한지를 파악할 수 있는 컨텍스트를 주자는 것이다. 소스파이어 네트워크 시큐리티(Sourcefire Network Security: 현재 체크포인트), 테너블 네트워크 시큐리티(Tenable Network Security) 및 NFR 시큐리티 제품 등 다중 탐지 능력을 이용하는 것들은 폴스 경보 수를 줄여주긴 하지만, ‘타깃 시스템에 대한 공격이 있고, 그 타깃 시스템이 공격 탐지 이후 비정상적 행동을 보일 경우 위급성 레벨을 올리고 경보를 보내라’는 식의 요청을 처리하는 데 필요한 상호연관성은 역시 표시하지 못한다. 이런 기능은 SIM(Security Information Management)의 영역이다.
다중 데이터 공급원과 몇 백 달러, 그리고 몇 개월 내지 일년의 시간이 있다면 SIM 툴을 이용해 실시간에 가깝게 데이터를 집합 및 프로세싱하고, 진행 중인 공격을 지적할 수 있는 사전 정의된 합성 조건을 검색할 수 있다. SIM은 보안 관리자의 정신적인 수고를 알고리즘적으로 최소화하고, 관심 있는 이벤트만을 표면에 띄움으로써 전체적인 작업 부담을 줄여준다.
하지만 SIM 셋업을 얻는 데만 쓰기에는 10만달러라는 액수가 너무 크다. 따라서 보다 적은 양의 보안 이벤트에 타깃을 둔 보다 작은 규모의 SIM으로는 IDS 및 취약성 관리 시스템에 있는 것과 같은 SIM 식의 기능들이 해답이 될 수 있을 것이다. 여기서는 이벤트를 실제 데이터로 바꾸는 게 목표다.
애플리케이션이 문제
웹 및 서버 애플리케이션 악용 사례가 늘어나고 있는 것은 아마도 서버 기반 취약성이라는 낮게 달린 열매가 따먹히거나, 혹은 취약성 조사자와 업체들이 보다 긴밀하게 움직이고 있기 때문일 것이다. 이유가 무엇이든 서버 레벨 취약성은 점점 보기 힘들어지고 있으며, 활동은 주로 애플리케이션 레벨에서 이뤄지고 있다.
PHP, 펄, ASP, SJP 등 애플리케이션 프레임워크를 이용해 조잡하게 코딩된 웹 애플리케이션들은 외부 사용자에게 내부 데이터베이스로 올 수 있는 데이터 경로를 제공한다. 그리고 이러한 경로는 공격자가 바라는 것보다 더 많은 액세스를 확보할 수 있는 기회를 마련 및 제공한다.
개발자에게 ‘더 안전한 코드를 만들라’고 말하기는 쉽지만 자신이 직접 개발하지 않는다면 실제로 이들이 얼마나 안전한지를 파악하기는 힘들다. 상용으로 만들어진 애플리케이션을 구입할 경우에는 이런 요구를 할 수도 없을 것이다. 보안 문제는 애플리케이션에서 처리되는 게 이상적이지만 그 대신 웹 애플리케이션 방화벽을 이용해 웹 트래픽을 다스릴 수 있다.
F5네트웍스, 임퍼바(Imperva) 및 라드웨어(Radware) 등과 같은 업체들의 웹 애플리케이션 방화벽은 성능 문제를 대폭 극복했으며, 애플리케이션 레벨의 공격을 방어하는 데 대한 합리적인 솔루션을 제공할 수 있다. 웹 서비스 호스트나 데이터 센터 에지의 전면에 배치된 웹 서비스 게이트웨이는 XML DoS, 데이터 조작 등과 같은 여러 가지 공격을 제한할 수 있다.
요점정리
·업체들은 최소한 한 가지 규정을 만족시킨다고 주장하는 제품들을 앞다퉈 내놓고 있다. 규정 준수는 기술적 문제가 아니라 비즈니스 프로세스지만 어떤 식으로든 선전이 될 것이다.
·네트워크 액세스 제어는 2006년에는 상호운용성 제한과 높은 복잡성으로 인해 널리 배치되지는 못할 것이다.
·대역폭이 수 기가비트 속도로 합쳐짐에 따라 속도와 피드가 향상되고 있다. IDS/IPS와 방화벽 업체들은 순전히 따라잡기 위해서라도 성능에 초점을 맞춰야 한다.
보안 기사를 마치며
지난 해 우리는 무선 영역에서 몇 가지 개발을 전망한 바 있는데, 이러한 전망들 가운데 실제로 실현이 된 것은 일부에 불과하다. 예를 들어 우리는 IPS가 2005년에 사용 가능해질 것이라고 말했다. 사실 IPS는 제한적으로 배치가 되고 있는 사양이 되어 가긴 하지만 아직 시그니처를 튜닝해야 하는 필요를 줄이지 못하고 있다.
지금은 NAP(Network Access Protection)와 NAC(Network Access Control)를 사용하는 파일럿 프로젝트를 시작하기 좋은 때다. 불행히도 이런 제품들은 심지어 아직 출하되지도 않은 상태긴 하지만 시스코는 최근 스위치에서의 지원을 발표한 바 있으며, 주니퍼도 인프라넷스위트(InfranetSuite)를 선전하고 있다.
SSO(Single Sign On)는 2005년에는 실현되지 못했다. 2006년에도 아마 힘들 것이다. 하지만 이것은 SSO가 아이덴티티 관리(identity management)의 일부기 때문이며, 이것은 HR과 총무부로 가야 할 게 IT로 판매되고 있다. 아이덴티티 관리는 내부 비즈니스 프로세스의 전반적인 재조정을 필요로 하는 비즈니스 프로세스다. SSO가 작동이 되려면 아이덴티티 저장소가 깨끗이 청소되고 조직화돼야 하며, 엄격한 네이밍 방안이 개발 및 시행돼야 한다. 이러한 핵심적인 조각들이 없이 SSO를 플랫폼을 가로질러 작동시키려면 서로 다른 네이밍 전환 방식을 이용해 어카운트를 연동시키는 수동 작업을 해야만 한다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
