[EndPoint] DLP로부터 정보 유출 방지

※ 블로그 운영자의 개인적인 의견입니다. 팩트와 글의 내용이 다를 수 있습니다.

서론

DLP(Data Loss Prevention)은 '사내에서 사외, 사외에서 사내로 이동되는 모든 데이터의 이동을 모니터링하여 Client를 보호'하는 역할을 하고 있다. 그렇기에 사내 네트워크를 이용하는 모든 단말기에 반드시 설치해야하는 필수 S/W이다. 해당 S/W를 설치하면 단말기에 Agent가 설치되며 서버로 부터 Agent가 정책을 받아오고 해당 단말기에 정책을 배포한다. 데이터의 이동은 웹사이트, 특정 S/W, 클라우드, 메신저, USB, HD 등 다양한 곳에서 발생할 수 있다. 이러한 모든 데이터의 이동을 탐지하고 차단하기에 오탐도 많고 에러나 장애도 많이 유발한다. 또한 정책을 중앙서버에서 받아오는 방식이기에 서버의 과부하가 많이 발생하여 운영에 많은 이슈들이 있었다. 내가 직접 경험했던 DLP 운영과 이슈들에 대해 소개하겠다.

 

Part 1. DLP 인프라 구조 

[DLP 서버 구성도]

기본적인 구조는 Client가 단말기를 사내에서도 사용할 수 있고, 사외에서도 사용할 수 있는 구조이다. 사내에서 부여받는 정책과 사외에서 부여받는 정책은 별도의 정책으로 운영된다. (사용하는 솔루션 및 조직 인프라 구조에 따라 서버 구성도는 다를 수 있음)

1. Client가 단말기를 사외로 반출하여 사용 시
 → WAS(external)는 DMZ에 위치해 있어 사외에서 접근이 가능하며, WAS(external)을 통해 정책을 배포받을 수 있다.
 → DB가 DMZ에 위치해 사외에서 접근이 가능하다면, 보안리스크가 커지기에 DB(external)는 Trust Zone에 위치한다.
 → WAS(external)은 정책을 Client에 부여하고, DB(external)에 데이터를 저장한다.

2. Client가 단말기를 사내에서 사용 시
→ WAS(Internal)와 DB(Internal)를 통해 정책을 배포하고 업데이트한다.
→ WAS(Integration)를 통해 중앙 집중적으로 정책을 배포하고 관리할 수 있다.

 

Part 2. 통제 및 제어

Client PC에는 DLP Agent가 설치된다. DLP Agent는 서버로부터 정책을 배포받고 업데이트한다. DLP는 Data Loss(또는 정보 유출)라는 관점에서 Client PC를 통제해야 하며, 다양한 기능들을 항목에 따라 WhiteList 또는 BlackList 방식으로 통제 및 제어하고 있다.

통제항목

1. USB 또는 HardDisk 등 - WhiteList
2. WebSite - BlackList
3. Cloud - BlackList
4. Messenger Program - BlackList
5. 특정 S/W - BlackList
6. Mail - BlackList
7. Bluetooth - WhiteList
8. RS232 등 특정 Port - WhiteList

 

통제기술

1. WEB 접근 통제(80,443 Port) 통제
   1. 웹 접근 통제
   2. 파일 업로드 통제
2. S/W 통제
   1. 메일
   2. 메신저
   3. S/W
3. Bluetooth 통제
4. 매체제어 통제
   1. USB 및 HD
   2. RS232 등 특정 시리얼 포트 통제

그 외

1. 개인정보 탐지

 

(시간이 되면 그림으로 이쁘게 만들어 보겠다.)

 

Part 3. 운영 이슈

예외 정책 부여

조직의 특성상 구성원들은 서로 다른 업무를 하고 있다. 조직에서는 사용을 차단시켰지만, 누군가에게는 업무상 반드시 필요한 기능들이 있다. 그렇기에 DLP에서 차단하고 있는 기능들에 대해서도 예외처리가 필요한 특정인들 대상으로 정책 예외처리를 해주고 있다.

하지만, 보안팀에서는 예외처리 신청자가 어떤 업무를 하고 그 업무에 예외처리 기능이 반드시 필요한지 판단할 수 없다. 그렇기에 예외처리 근거를 남기기 위한 신청서가 필요하며, 신청서에는 팀장을 결재라인으로 지정하여 예외처리 승인에 대한 책임을 전가하였다. 그리고 예외처리 기능으로부터 어떤 작업을 했는지 보안팀에서 점검을 한다. 예외처리에 대한 기준이 명확하지 않다면 예외처리는 남발이 될것이며 조직의 보안홀로 되돌아 올것이다.

1. 신청서
 1) 사용자는 예외처리가 필요한 기능에 대해 사유 작성
 2) 사용 기간 작성

2. 결재 프로세스
 1) 해당 팀의 팀장 승인 후 보안팀 푸의 

3. 기록에 대한 점검
 1) 해당 기능을 통해 어떤 작업을 하였는지 점검 및 예외처리자에게 작업에 대한 증빙 요청

 

Client 정책 업데이트 실패

Client에는 Agent가 설치되어 있고, Agent가 서버로부터 정책을 배포 받아 PC의 접근을 통제한다. 가장 많이 발생하는 이슈 중 하나는 '보안담당자는 정상적으로 해당 계정에 예외처리 권한을 부여하였지만, Agent가 서버로부터 정책을 배포받지 못해 해당 PC에서 예외처리가 되지 않는 현상'이다. DLP 버전이 낮아서 그런것일까... 인프라 구조상의 에러일까... 잘 모르겠다면 업체에 문의해보자! Agent에는 '정책 업데이트'라는 기능이 있어서, 해당 기능을 통해 대부분 정책을 재 업데이트 하여 문제를 해결하고 있다.

 

특정 URL 차단

DLP는 URL 차단 기능이 있는데, 왜인지 모르겠지만 ISP 결제에 대한 URL들을 차단하고 있었다. 결제하면서 타고타고 들어가는 모든 URL들을 허용정책으로 바꾸어주니 해결되긴 했다. DLP 문제인지 제일 쉽게 확인하는 방법은 DLP를 임시로 삭제처리하고 에러가 발생하는 지 확인하는 것이다. 문제 없이 작업된다면... 거의 99% DLP 문제다.

 

Log 저장 에러

예외처리자는 예외처리 기능에 대한 로그를 해당 PC에 남기게 되고, 서버와 연동 시 해당 로그를 서버로 넘기게 된다. 서버로부터 로그를 모두 전달하면 로컬 PC에 저장되어 있는 로그는 삭제되는데... 서버로부터 로그를 넘기는 과정에 PC가 종료되면 데이터 전달이 멈추어 PC의 메모리가 가득차는 현상이 발생한다. 전달하는 로그가 클수록 많이 발생한다. '정책 업데이트'를 해주고 데이터가 서버로 넘어갈때까지 PC를 종료해서는 안된다.

 

URL 차단의 기준

대부분의 EndPoint 보안솔루션은 URL 차단기능을 탑재하고 있다. 그렇기에 각 솔루션마다 어떤 기준으로 URL을 차단하고 허용해주는지 정의해야 한다. 화자는 DLP를 '정보 유출 방지' 목적으로 운영하고 있다. 따라서 악성 URL은 백신에서 차단하고, 정보 유출이 일어날 수 있는 URL만 DLP에서 차단하고 있다. 운영을 하다보면 특정 사이트가 접속이 되지 않는다 라는 문의가 들어오는데, URL을 차단하는 보안솔루션 모두를 확인해야 하는 번거로움이 있다. SIEM 운영하면 조금은 달라질까..?

 

Part 4. 그 외 (개인적인 생각)

Client와 직접 소통하는 일이 제일 많다.

DLP를 계정별로 통제하고 있으며 계정 문제는 가장 많이 발생하는 이슈 중 하나이다. 그렇고 DLP는 많은 기능들이 탑재되어 있기에 대부분의 문의는 DLP일 것이다. 그리고 알 수 없는 문제들도 많이 발생하기에 재현이 필요하며, 재현을 하기 위해서는 원격으로 확인하는 방법이 제일 편하다. 따라서 화자가 운영하는 보안솔루션 중 제일 많은 문의가 들어오며 Client와 직접 소통하는 일이 제일 많다. 고객이라 생각하고 친절하게 대해주자^^

 

License 관리

DLP는 특정 S/W를 허용하고 차단하는 기능이 탑재되어 있다. License 문제가 있는 S/W를 DLP에서 차단하지 말자. 대부분 실행파일(PE)을 기준으로 통제하고 있을 것인데, 해당 S/W가 버전 업이되면 보안팀에서는 굉장히 번거로운 작업이 된다. 반드시... 보안적인 업무에 대해서만 통제하자.

 

보안 홀

DLP의 모든 정책은 Agent가 서버로부터 정책을 배포받아 통제하는 것이기에, 통제는 Local PC에서 일어난다. 사용자가 Local PC에 대해 Administrator 권한이 있다면 언제든 정책을 우회할 수 있다. 정책을 우회한다면 서버에는 기록이 남지 않아, 정보유출이 일어나도 책임추적이 되지 않아 보안홀로 작요된다. 화자는 정보유출 가능성이 있는 프로그램에 대해서 S/W만 차단하지 않고 해당 S/W와 통신하는 서버와 API등을 함께 차단했다. 당연하게도 사용자는 언제든 해당 정책들을 우회할 수 있지만, 그렇다고 아무 조치도 하지 않으면 안된다... 화자는 이러한 점에서 고민을 많이 했었고 지금도 늘 하고있다.

 

요약 

1. 사내/사외 정책에 대해서 분리해서 운영해야하며, 조직의 규모가 커질수록 정책관리가 번거로울 수 있다.
2. 하나의 솔루션에서 통제하는 항목이 많다보니 Client와 직접소통도 많으며, Client PC 과부하를 유발을 하기에 다양한 문제들로부터 컴플레인이 들어온다.
3. 정보 유출이라는 관점에서 보안 홀 관리를 어떻게 해야할지 늘 고민해야 한다.