“투자하라, 그리하면 지키리라”
상태바
“투자하라, 그리하면 지키리라”
  • 데이터넷
  • 승인 2008.11.10 00:00
  • 댓글 0
이 기사를 공유합니다

능동적 보안(Positive Security)
적극적 보안에는 시스템에 대한 깊이 있는 지식이 필요하지만 이것으로 얻을 수 있는 이점은 실로 막대하다. 하지만 미래를 보장해 주는 이 방안도 관리가 제대로 되지 않으면 악몽으로 변할 수도 있다. <편집자>

액세스를 허용하기 이전에 전체 애플리케이션에서부터 특정 기능에 이르는 모든 것을 화이트리스팅하는 ‘능동적 보안(positive security)’은 환상적인 것처럼 들린다. 하지만 불행히도 우리가 알고 또 사랑하는 데스크톱 환경에서는 보안보다 사용의 편의를 우선시 해, 모두가 고통을 느끼고 있다.

애플리케이션 화이트리스팅 시장 확장 중
본지의 전략적 보안 설문조사에 따르면 절반 이상의 응답자가 올해 바이러스 침입을 받은 적이 있었으며, OS 취약성을 통해 공격을 당한 사람도 30%에 달했다. 능동적 보안으로 고려해 볼 수 있는 두 가지로 애플리케이션 화이트리스팅과 MAC(Mandatory Access Control)가 있다.

화이트리스팅은 모든 프로그램이 컴퓨터에서 돌아가는 것을 디폴트로 하고 장애를 일으킨 다음에야 못된 프로그램들을 중단시키려 하는 게 아니라 승인받은 애플리케이션만 돌아갈 수 있게 허용한다. 이 개념은 소프트웨어뿐만 아니라 애플리케이션이 수행하도록 허용받은 기능에도 적용될 수 있다. 이것은 복잡하며 모든 것을 중단시키지는 않겠지만 매일같이 더 많은 위협들이 온라인으로 들어오고 있는 지금 충분히 고려해 볼 만한 옵션이다.

한편 MAC에서는 오늘날의 데스크톱 운영 시스템을 보안하는 데 사용되는 DAC(discretionary access control) 방식보다 훨씬 강력하고 정밀한 제어가 가능하다. MAC는 DAC보다 복잡한데, DAC는 신원정보를 기반으로 액세스를 허용하거나 거부하는 것으로 가장 잘 요악된다. 사용자는 권한이 있는 계정으로 로그인 되거나 되지 않으며, 특정 그룹의 멤버이거나 멤버가 아니다.

MAC 환경에서는 사용자 계정이 사용자의 파일에 대한 전면적인 제어권을 갖지만 같은 사용자에 의해 돌아가는 메일 클라이언트에게는 허가 범위가 줄어든다. 일례로 읽고 쓸 수 있는 디렉토리에 대한 제한 등을 들 수 있다. 이런 식으로 생각해 보자. 만약 웹 브라우저가 일부 라이브러리나 플러그인을 실행하고, 파일을 다운로드 폴더에 저장하며 네트워크 접속을 만들기만해도 된다면 다른 바이너리를 실행하거나 다른 실행 애플리케이션의 메모리로 액세스할 수 있는 능력이 왜 필요하겠는가?

능동적 보안 모델을 구성 및 유지보수하는 데는 전통적인 자유 방임주의적 방식보다 많은 돈이 들지만 MAC와 애플리케이션 화이트리스팅의 이점은 이행 경비를 능가하기 시작했으며, 써드파티 보안 제품에서뿐만 아니라 운영 시스템에서도 능동적 보안 기능과 정책을 추구하는 동향이 늘어나고 있다. 본지에서 실시한 전략적 보안 설문조사에서, 소프트웨어 기능을 필수적인 것들로 축소시키는 프랙티스가 가장 효과적인 최약성 관리 프랙티스 여섯 가지 안에 포함되었다.

업체들도 또한 조심스레 발을 떼고 있는데, 일례로 카스퍼스키랩(Kaspersky Lab)은 자사 제품에 애플리케이션 화이트리스팅 업체인 비트나인(Bit9)의 데이터베이스를 추가시켰다. 카스퍼스키는 스캐닝 속도를 높이기 위한 첫 번째 확인 단계로 이 화이트리스팅을 사용하고 있다. 이것은 진정한 능동적 보안 모델이라고 할 수는 없지만 그 시작임은 분명하다.

대형 안티바이러스 업체들 가운데는 시만텍이 능동적 보안 모델로 마이그레이팅하겠다는 의사를 표현한 바 있으며, 실제로 새로운 프로그램을 금지하는 록다운(lockdown) 모드를 포함해 카스퍼스키와 유사한 기능들을 이행하기 시작했다. 애플리케이션 화이트리스팅 시장 또한 확장되고 있는 추세다.

완벽할 수는 없다
흔히 볼 수 있는 배치상의 장애들 외에도 능동적 보안이 해결할 수 없는 문제들도 있다. 우선 어떤 메커니즘들은 내부인의 위협에 맞서 싸우기 위해 능동적 보안 모델을 사용하기도 하지만 이런 시스템의 대다수는 트러스티드 종단지점(trusted endpoint)을 필요로 하며, 충분히 잘 알고 있는 로컬 사용자는 이런 시스템을 전복시킬 수 있다.

게다가 능동적 보안 모델은 취약성을 갖고 있는 승인된 애플리케이션들에 대해서는 안전하지 못하다. 이런 모델은 대부분의 악성 소프트웨어가 실행되는 것을 막고 손상되는 범위를 제한할 수 있지만, 멀웨어는 여전히 소프트웨어 취약성을 활용해서 시스템을 감염시킬 수 있다.

기억해야 할 한 가지는 기존 위협의 대다수가 애플리케이션 화이트리스팅이나 MAC가 있는 환경에서 떨어져 있다는 사실이다. 전략은 훌륭할 정도로 완벽할 필요는 없다.

능동적 보안의 최대 장애는 관리 비용이다. 약간의 표준 데스크톱 빌드와 비교적 정적인 애플리케이션 세트가 있는 사이트에서는 능동적 보안 전략이 효과를 볼 수 있다. 특히 서버는 몇 가지 특별한 기능을 수행하고 종단지점보다도 더 중요한 자원들로의 액세스를 갖고 있는 경향이 있다. 역으로 사용자가 자신의 소프트웨어를 설치하거나 계속해서 애플리케이션 설정을 변경해야 할 필요가 있을 때는 능동적 보안 프로그램을 이행하기 힘들다.
 
또 한 가지, 블랙리스트나 화이트리스트나 둘 다 정적이지는 않다는 사실에 주의해야 한다. 블랙리스트는 부정적 행동이나 객체 목록을 말하는데, 보통 ‘디폴트-허용’, ‘디폴트-허가’ 및 ‘최근 20년 가까이 안티바이러스 업계의 상태’라고도 알려져 있는 소극적 보안(negative security) 모델의 컴포넌트로 사용되고 있다. 소극적 보안 모델은 알려진 나쁜 행동이나 객체만 차단한다. 그 이점은 새롭고 좋은 객체들은 시스템을 변경시킬 필요가 없다는 것이다. 하지만 새로운 나쁜 객체를 차단하려면 빈번한 업데이트가 요구된다는 단점이 있다.

역으로, 화이트리스트는 가끔씩 바꿔 사용할 수 있는 경우가 있긴 하지만 능동적 보안 모델과 반드시 같은 의미로 사용되지는 않는다. 예를 들어 안티바이러스 애플리케이션에서 화이트리스트는 언제나 실행되도록 허용돼야 하는, 특별히 좋다고 알려진 애플리케이션을 말하겠지만, 그렇다고 해서 안티바이러스 제품이 언제나 디폴트로 거부 정책을 사용하는 것은 아니다. 애플리케이션이 화이트리스트를 사용한다고 해서 그것이 곧 능동적 보안 모델을 사용한다는 의미는 아닌것. 능동적 보안 모델에서는 일련의 좋은 행동이나 객체를 지정하고 다른 모든 것들은 디폴트로 차단한다.

세 가지 방법
현재 IT 부서는 능동적 보안을 채택하는 데 있어 세 가지 방법 중 하나를 선택할 수 있는데, 우선 주요 안티바이러스 업체들의 제품을 기다리는 방법이 있다. 이런 업체들은 현재 능동적 보안을 통합하는 다양한 단계에 있다. 그 외 특정 부분에 포커스를 둔 스탠드얼론 소프트웨어를 구입할 수 있고, 혹은 자체적으로 만들 수도 있다. 능동적 보안은 일상에서 사용하는 운영 시스템에 구축된 툴만 있으면 되는 경우가 많다.

리눅스에서 능동적 보안 모델을 이행하는 것 또한 당신이 생각하는 것보다 쉬울 것이다. 대부분의 인기 있는 메커니즘은 SE리눅스(SELinux)나 앱아머(AppAmor) 프로젝트를 통한다. 유분투(Ubuntu), 데비안(Debian), 페도라(Fedora) 및 오픈수세(OpenSUSE)의 최신 릴리즈들은 모두 둘 중 하나를 아웃 오브 더 박스(out of the box)로 바로 지원한다.

SE리눅스와 앱아머는 MAC 이행용으로 서로 다른 메커니즘을 제공하며, 각각의 지원자들은 자신들의 메커니즘을 칭송하고 있다. 대부분의 환경에서 이것을 결정짓는 요소는 자신들이 선택한 배포판에서 디폴트가 어떤 것인지가 될 것이다. 둘 다 순수 애플리케이션 화이트리스트나 추가 MAC 보안 기능 중 하나를 이행할 수 있는 능력은 기본으로 갖추고 있다.

이들 프로젝트 가운데 하나를 폭넓게 배치함으로써 제공받는 보호에는 관리 비용 증가라는 댓가가 따른다. 적절한 화이트리스트 정책을 개발하는 것은 잘해야 시간 소모적인 프로세스며, 강력한 변화 제어 방안이 없고 기반 구성들이 많은 곳에서는 유지 자체가 불가능할 수 있다. 단일 기능 서버(DNS, DHCP, SMTP를 생각하라)는 대부분 쉽게 프로파일링되고 보호되며, 앱아머나 SE리눅스의 첫 번째 타깃이 될 것이다.

윈도우 XP는 능동적 보안용으로 내장하고 있는 기능들이 최근 리눅스 배포판보다 적지만 보다 강력한 액세스 제어용 메커니즘을 제공한다. 예를 들어 NTFS는 전통적인 유닉스 허가에 비해 파일에 대해 보다 정밀한 제어를 제공한다. 소프트웨어 제한정책(Software Restriction Policies)은 바이너리나 라이브러리 실행용으로 디폴트 거부 정책을 지원할 수 있다. 보안성이 덜한 경로나 MD5 해시(hashes)에 따라, 혹은 승인된 애플리케이션 퍼블리셔 디지털 인증에 따라 예외적인 것이 지정될 것이다.

비스타는 XP의 이러한 기본 기능들 외에도 MIC(Man datory Integrity Control) 기능을 제공하는데, 이것은 인터넷 익스플로러에서 새로운 보호 모드(Protected Mode)를 지지해 준다.

맥 OS X 레오파드에서 애플은 트러스티드BSD MAC 프레임워크를 기반으로 하는 강제적 접근제어(mandatory access control)를 소개했다. 불행히도 우리는 첫 배치에서 어떠한 큰 용례에서보다도 내부 테스팅용으로 더 적합하다는 사실을 발견했다. 오리지널 트러스티드BSD 디자인의 중요한 모듈들 가운데 대부분이 빠져 있으며, 빌트인 애플리케이션용으로 포함된 정책은 잘해야 최소한이었다.

하지만 프레임워크는 제대로 자리를 잡고 있으며, 바라건대 앞으로 나올 릴리즈에서는 보다 강력한 정책이 적용되기를, 그리고 인터페이스 자체가 써드파티 개발자들에게도 공개적으로 되기를 희망한다.

정보보안 큰 역할 기대
하룻밤 만에 일어날 일은 아니겠지만 적극적 모델은 정보 보안의 미래에 있어 큰 역할을 하게 될 것이다. 애플리케이션 행동용으로나 승인된 애플리케이션용으로나 능동적 보안 모델을 처음 적용시키려다 보면 많은 비용이 들겠지만, 이 비용은 프로세를 수월하게 해주는 제품들이 늘어남에 따라 점차 줄어들 것이다. 게다가 소극적 보안 모델의 실패는 계속해서 IT 그룹에서 네트워크를 보호해 줄 더 강력한 툴을 요구하도록 유도할 것이다.

그리고 적극적 모델의 이점은 단순한 보안 그 이상이다. 어떤 소프트웨어가 워크스테이션에서 돌아갈 수 있는지를 제어함으로써 다양한 IT 정책들을 효과적으로 시행할 수 있기 때문이다. 이제 적극적으로 생각해야 할 때다.

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