ISMS-P 결함사례 고찰 #2.10. 시스템 및 서비스 보안관리

2.10.1 보안시스템 운영

인증기준: 보안시스템 유형별로 관리자 지정, 최신 정책 업데이트, 룰셋 변경, 이벤트 모니터링 등의 운영절차를 수립·이행하고 보안시스템별 정책적용 현황을 관리하여야 한다.

 

결함사례#1

침입차단시스템 보안정책에 대한 정기 검토가 수행되지 않아 불필요하거나 과도하게 허용된 정책이 다수 존재하는 경우가 있다. 보안정책에 대한 검토는 정기적으로 수행하며 각 정책의 타당성을 따지는 작업이 필요하다. 이게 참 신기하게도, 한 번 하고 끝나는 일이 될 수가 없다. 1월에는 타당했던 정책이 7월에는 타당하지 않을 수도 있다. 진짜로 그렇다. 법의 개정 때문일 수도 있고, 이유야 다양하다. 침입차단시스템만 그런 게 아니라, 정책, 지침, 프레임워크라는 것에 대해서는 주기적인 검토가 필요하다.

 

결함사례#2

보안시스템 보안정책의 신청, 변경, 삭제, 주기적 검토에 대한 절차 및 기준이 없거나, 절차는 있으나 이를 준수하지 않은 경우가 있다. 두 경우의 결론은 결국 제대로 된 검토를 하지 않았다는 것이다. 이렇게 될 경우 보안시스템 구성에 있어서 취약점이 발생하더라도 외면하게 될 가능성이 다분하다고 본다. 제대로 된 정책 검토를 하지도 않는데 위험평가는 오죽하겠냐는 말이다. 대부분의 업무가 그러하듯, 보안에서도 업무들은 대개 상호작용적이다. 어느 하나 완벽한 검토를 하고 있지 않다면, 그것이 영향을 끼치는 것을 고려해야 할 것이다.

 

결함사례#3

보안시스템의 관리자 지정 및 권한 부여 현황에 대한 관리감독이 적절히 이행되고 있지 않은 경우가 있다. 관리자를 지정하지 않는 것은.. 솔직히 상상하기 어렵고, 권한 부여 현황에 대한 관리감독은 제대로 이행되지 않는 경우가 종종 있을 것이다. 현황에 대해 관리하는 것도 매우 중요한데, 이 권한 부여라는 것도 제때에 맞게 수거하고 부여하는 것이 매우 중요하기 때문이다. 언제 장기 휴가가 발생할지, 언제 인사이동이나 퇴직이 발생할지 모르는 상황이니 이에 대해 현황을 제대로 파악하여 올바르게 관리하는 것이 중요하다.

 

결함사례#4

내부 지침에는 정보보호담당자가 보안시스템의 보안정책 변경 이력을 기록·보관하도록 정하고 있으나, 정책관리대장을 주기적으로 작성하지 않고 있거나 정책관리대장에 기록된 보안정책과 실제 운영 중인 시스템의 보안정책이 상이한 경우가 있다. 지침은 FM으로 했으나 실제 정책에 문제가 있는 것일 수도 있고, 실제 정책은 그럭저럭 제대로 하고 있는데 지침을 제대로 업데이트하지 않은 상황일 것이다. 무엇이 되었건, 둘이 맞지 않는다면 문제가 발생할 수밖에 없다. 지침과 실제 정책은 별개로 봐서는 안 된다. 올바른 지침을 통해 업무의 능률을 올릴 수 있는 것은 당연하기 때문에 이에 대한 관리도 철저해야 할 것이다.

 

2.10.2 클라우드 보안

인증기준: 클라우드 서비스 이용 시 서비스 유형(SaaS, PaaS, IaaS 등)에 따른 비인가 접근, 설정 오류 등에 따라 중요정보와 개인정보가 유·노출되지 않도록 관리자 접근 및 보안 설정 등에 대한 보호대책을 수립·이행하여야 한다.

 

결함사례#1

클라우드 서비스 계약서 내에 보안에 대한 책임 및 역할 등에 대한 사항이 포함되어 있지 않은 경우가 있다. 그 클라우드가 IaaS건, PaaS건, SaaS건, 그밖의 것이건, 보안에 대한 책임과 역할을 명시하는 것은 너무나도 필수적인 일이다. 아무리 서비스 구성과 특징이 다양한다고 한들, 그 원칙은 절대 깨져서는 안 된다. 책임소재가 분명하지 않을 때, 문제가 발생하면 책임지는 것은 누가 되냐는 말이다. 그리고 이전에도 밝힌 적이 있는데, 개인적으로 책임이 사람을 만든다고 생각한다. 서비스 제공자도 책임을 갖고 운영 및 관리를 해야 하고, 이용자도 책임 의식을 지니고 이용을 하는 것이 바람직하다.

 

결함사례#2

클라우드 서비스의 보안설정을 변경할 수 있는 권한이 업무상 반드시 필요하지 않은 직원들에게 과도하게 부여되어 있는 경우가 있다. 최소권한의 원칙이 깨지는 영역으로 상당히 흔한 사례이긴 하나, 이것이 문제가 될 수 있음을 적어도 담당자는 인지하고 있어야 한다.

 

결함사례#3

내부 지침에는 클라우드 내 사설 네트워크의 접근통제 룰(Rule) 변경 시 보안책임자 승인을 받도록 하고 있으나, 승인절차를 거치지 않고 등록·변경된 접근제어 룰이 다수 발견된 경우가 있다. 승인절차를 제대로 거치지 않고 접근제어 룰이 변경되었다면 그것에 대한 타당성은 어떻게 믿을 수 있을까. 책임자의 대리를 통해서라도 새로운 접근제어 룰의 적절성 및 적합성에 대한 평가가 필요할 것이다.

 

결함사례#4

클라우드 서비스의 보안설정 오류로 내부 로그 파일이 인터넷을 통하여 공개되어 있는 경우가 있다. 이는 클라우드 보안 아키텍처를 수립하여 오류에 대해 실제로 파악해볼 필요가 있다. 클라우드 서비스가 점점 보편화 되어가는 가운데에 이런 문제는 상당히 치명적인 결과로 돌아올 수 있음을 인지해야 할 것이다.

 

2.10.3 공개서버 보안

인증기준: 외부 네트워크에 공개되는 서버의 경우 내부 네트워크와 분리하고 취약점 점검, 접근통제, 인증, 정보 수집·저장·공개 절차 등 강화된 보호대책을 수립·이행하여야 한다.

 

결함사례#1

인터넷에 공개된 웹사이트의 취약점으로 인하여 구글 검색을 통하여 열람 권한이 없는 타인의 개인정보에 접근할 수 있는 경우가 있다. 이것은 수준이 매우 낮은, 해커라도 부르기도 무안한 해커들의 공격을 유발할 수 있다는 점에서 큰 문제가 된다. 컴퓨터랑 친한 사람 치고 구글링에 친숙하지 않은 사람이 몇이나 되겠는가. 공개서버를 토대로 웹사이트를 운영하는 경우에는 이런 취약점이 발견될 경우 즉시 조치를 취해야 한다.

 

결함사례#2

웹사이트에 개인정보를 게시하는 경우 승인 절차를 거치도록 내부 규정이 마련되어 있으나, 이를 준수하지 않고 개인정보가 게시된 사례가 다수 존재한 경우가 있다. 이것 역시 #1과 다를 바 없다. 개인정보에 쉽게 접근할 수 있는 사례가 실제로 많고, 이것은 분명 법을 위반하는 행위임을 인지해야 한다. 개인정보 안전성 확보 조치는 법으로 정해진 필수사항이다.

 

결함사례#3

게시판 등의 웹 응용프로그램에서 타인이 작성한 글을 임의로 수정·삭제하거나 비밀번호로 보호된 글을 열람할 수 있는 경우가 있다. 이는 보안 조치가 전혀 되지 않은 것으로, 이런 경우에는 법적 공방으로 이어질 수 있을 정도로 사건이 커질 수 있다. 한 번도 이런 경우를 간접적으로도 접해본 적이 없어 상상하기 어려우나, 그런 만큼 이런 사례는 다시는 없어야 할 것이다.

 

2.10.4 전자거래 및 핀테크 보안

인증기준: 전자거래 및 핀테크 서비스 제공 시 정보유출이나 데이터 조작·사기 등의 침해사고 예방을 위하여 인증·암호화 등의 보호대책을 수립하고, 결제시스템 등 외부 시스템과 연계할 경우 안전성을 점검하여야 한다.

 

결함사례#1

전자결제대행업체와 위탁 계약을 맺고 연계를 하였으나, 적절한 인증 및 접근제한 없이 특정 URL을 통하여 결제 관련 정보가 모두 평문으로 전송되는 경우가 있다. SET만 하더라도 결제 정보를 평문으로 전송한다는 것은 정말 상상하기 어렵다. 이는 거래의 안전성과 신뢰성을 모두 배반하는 상황이라 할 수 있다. 결제 정보가 평문으로 전송되는 업체를 어느 고객이 믿을 수 있을까 싶다. 솔직히 여기는 결함사례를 해결한다고 해도 만약 어디인지 알게된다면 이용하고 싶지 않을 정도이다.

 

결함사례#2

전자결제대행업체와 외부 연계 시스템이 전용망으로 연결되어 있으나, 해당 연계 시스템에서 내부 업무 시스템으로의 접근이 침입차단시스템 등으로 적절히 통제되지 않고 있는 경우가 있다. 전용망으로 되어있어도 접근이 통제되지 않는다면 무용지물이나 다름없다. 언제나 우회 여부와 접근통제에 관해서는 가장 기본적으로 다뤄야 할 것이다.

 

결함사례#3

내부 지침에는 외부 핀테크 서비스 연계 시 정보보호팀의 보안성 검토를 받도록 되어 있으나, 최근에 신규 핀테크 서비스를 연계하면서 일정상 이유로 보안성 검토를 수행하지 않은 경우가 있다. 이는 은근히 흔한 사유인데, 보안성 검토보다 당장의 가용성과 성능에 집중하는 경우가 많기 때문이다. 보안은 2순위여서는 안 된다. 앞의 가용성, 성능 등과 동등한 1순위에 속해야만 한다. 근본적인 마인드의 변화가 필요한 시점이다. 고객 입장에서 이걸 알게 된다면 과연 그 핀테크를 사용하려 들까? 보안을 뒤로 미루는 일은 결국 고객을 기망하는 일이라고 본다.

 

2.10.5 정보전송 보안

인증기준: 다른 조직에 개인정보 및 중요정보를 전송할 경우 안전한 전송 정책을 수립하고 조직 간 합의를 통하여 관리 책임, 전송방법, 개인정보 및 중요정보 보호를 위한 기술적 보호조치 등을 협약하고 이행하여야 한다.

 

결함사례#1

대외 기관과 연계 시 전용망 또는 VPN을 적용하고 중계서버와 인증서 적용 등을 통하여 안전하게 정보를 전송하고 있으나, 외부 기관별 연계 시기, 방식, 담당자 및 책임자, 연계 정보, 법적 근거 등에 대한 현황관리가 적절히 이루어지지 않고 있는 경우가 있다. 현황 관리는 꾸준히 상시 혹은 정기적으로 이뤄져야 한다. 업무에 있어서 변수는 매번 발생하기 마련이고, 담당자는 이에 대해 현황을 계속 관리하여 문제가 생기지 않도록 매번 즉각적인 처리를 해주어야 할 것이다.

 

결함사례#2

중계과정에서의 암호 해제 구간 또는 취약한 암호화 알고리즘(DES, 3DES) 사용 등에 대한 보안성 검토, 보안표준 및 조치방안 수립 등에 대한 협의가 이행되고 있지 않은 경우가 있다. 취약한 암호화 알고리즘인 DES, 3DES에 대해서는 이미 많이 알려져 있는데도 그것을 사용했다는 것은 암호화에 애초에 무관심했던 것이 아닐까 싶다. 예산 문제로 어쩔 수 없었더라도, 이후에라도 이에 관한 조치를 취했어야 한다.

 

2.10.6 업무용 단말기기 보안

인증기준: PC, 모바일 기기 등 단말기기를 업무 목적으로 네트워크에 연결할 경우 기기 인증 및 승인, 접근 범위, 기기 보안설정 등의 접근통제 대책을 수립하고 주기적으로 점검하여야 한다.

 

결함사례#1

업무적인 목적으로 노트북, 태블릿PC 등 모바일 기기를 사용하고 있으나, 업무용 모바일 기기에 대한 허용 기준, 사용 범위, 승인 절차, 인증 방법 등에 대한 정책이 수립되어 있지 않은 경우가 있다. 업무용 단말기에 대해서는 유출 등의 문제가 생기지 않도록 보안에 관한 정책을 수립해야 한다. 그래서 애플리케이션을 통해 이같은 통제를 하는 경우가 많다. 업무용 단말기로는 카메라 사용이 제한되는 것이 대표적인 예시 중 하나일 것이다. 기준이 없게 되면 언제나 '정도'와 '상식'을 벗어나서 업무용 단말기를 활용하는 경우가 생길 수밖에 없다. 따라서 이에 대해 정책을 수립하고 그것을 따르도록 강제하는 시스템을 만들어야 한다.

 

결함사례#2

모바일 기기 보안관리 지침에서는 모바일 기기의 업무용 사용을 원칙적으로 금지하고 필요시 승인 절차를 통하여 제한된 기간 동안 허가된 모바일 기기만 사용하도록 정하고 있으나, 허가된 모바일 기기가 식별·관리되지 않고 승인되지 않은 모바일 기기에서도 내부 정보시스템 접속이 가능한 경우가 있다. 승인되지 않은 모바일 기기에서도 내부 정보시스템 접속이 가능하다는 것은 정말 큰 취약점이라 할 수 있다. 접근통제가 제대로 이루어지고 있지 않다는 것을 뜻하며, 결국 공격자도 수월하게 접근을 할 수 있다는 것이니 말이다. 이에 대해서 즉각적인 조치를 취해야 한다.

 

결함사례#3

개인정보 처리업무에 이용되는 모바일 기기에 대하여 비밀번호 설정 등 도난·분실에 대한 보호대책이 적용되어 있지 않은 경우가 있다. 도난 및 분실에 대해서는 강력한 인증수단이나 원격 잠금, 원격 데이터 삭제, MDM 등의 대책을 취해야 한다. 그래서 분실을 했어도 문제가 생기지 않도록 해야 할 것이다.

 

결함사례#4

내부 규정에서는 업무용 단말기의 공유폴더 사용을 금지하고 있으나, 이에 대한 주기적인 점검이 이루어지고 있지 않아 다수의 업무용 단말기에서 과도하게 공유폴더를 설정하여 사용하고 있는 경우가 있다. 이런 경우는 정말이지 흔하다. 업무 상 공유폴더를 그냥 너무 말도 안되게 두는 것은 진짜 진짜 진짜 여러 사무실에서 볼 수 있는 모습이다. 공유폴더는 특히나 해당 업무와 관련이 없는 자도 보통 접근이 가능하게 세팅되어 있기 때문에 이에 대해 주기적인 점검을 하는 것은 정말이지 자주 있어야 한다고 여긴다.

 

2.10.7 보조저장매체 관리

인증기준: 보조저장매체를 통하여 개인정보 또는 중요정보의 유출이 발생하거나 악성코드가 감염되지 않도록 관리 절차를 수립·이행하고, 개인정보 또는 중요정보가 포함된 보조저장 매체는 안전한 장소에 보관하여야 한다.

 

결함사례#1

통제구역인 서버실에서의 보조저장매체 사용을 제한하는 정책을 수립하여 운영하고 있으나, 예외 승인 절차를 준수하지 않고 보조저장매체를 사용한 이력이 다수 확인되었으며, 보조저장매체 관리실태에 대한 주기적 점검이 실시되지 않아 보조저장매체 관리대장의 현행화가 미흡한 경우가 있다. 관리 실태에 대한 주기적 점검을 실시해야 어떤 오류가 있으며, 보호대책이 어떻게 적용이 잘 되고있는지 파악할 수 있다. 주기적 점검은 보안에서는 어느 세부 분야건 진행해야 하는 업무로 여겨야 한다.

 

결함사례#2

개인정보가 포함된 보조저장매체를 잠금장치가 있는 안전한 장소에 보관하지 않고 사무실 서랍 등에 방치하고 있는 경우가 있다. 귀찮으니까 그랬을 거다. 왔다갔다 하기 귀찮고, 절차를 밟기도 귀찮은데, 업무에는 빈번하게 쓰이니 말이다. 하지만 개인정보가 포함된 매체는 안전하지 않은 장소에 보관한다면 그냥 책상 위에 올려놓는 것과 다를 바가 없다. 이에 대해서는 크게 지적을 당해도 할 말이 없을 것이다.

 

결함사례#3

보조저장매체 통제 솔루션을 도입·운영하고 있으나, 일부 사용자에 대하여 적절한 승인 절차 없이 예외처리되어 쓰기 등이 허용된 경우가 있다. 일부 사용자에 대해 적절한 승인 절차가 없다면 그것은 솔루션이라고 부를 수 있을까? 예외가 있는 곳에서 사고가 터질 수 있는 법이다. 그 '일부' 사용자가 업무에 있어서 쓰기 등의 권한이 필요하다면 반드시 절차를 밟도록 해야 할 것이다.

 

결함사례#4

전산실에 위치한 일부 공용 PC 및 전산장비에서 일반 USB메모리에 대한 쓰기가 가능한 상황이나 매체 반입 및 사용 제한, 사용이력 기록 및 검토 등 통제가 적용되고 있지 않은 경우가 있다. 통제에 있어서 언제나 예외는 있어서는 안 된다. 모든 통제는 일괄적용을 원칙으로 삼아야 하고, 이렇게 예외가 있으면 또 문제가 되는 것이 있다. 직원들이 만일의 사태에 대비한 만능 PC로서 해당 PC를 사용하게 된다는 점이다. 향후 감사에서 문제가 될 만한 내용이 없도록 말이다. 그렇기에 반드시 모든 자산을 관리하며 예외는 없도록 해야 할 것이다. 

 

2.10.8 패치관리

인증기준: 소프트웨어, 운영체제, 보안시스템 등의 취약점으로 인한 침해사고를 예방하기 위하여 최신 패치를 적용하여야 한다. 다만 서비스 영향을 검토하여 최신 패치 적용이 어려울 경우 별도의 보완대책을 마련하여 이행하여야 한다.

 

결함사례#1

일부 시스템에서 타당한 사유나 책임자 승인 없이 OS패치가 장기간 적용되고 있지 않은 경우가 있다. 패치가 장기간 적용되고 있지 않다면, 취약점을 계속 노출하고 있는 것과 다름 없는 일이다. 워너크라이 사태를 언제나 떠올리며 이에 대한 경각심을 가져야 한다. 당시에는 마소에서 패치를 내놓았음에도 불구하고 패치를 적용하지 않아 털린 회사가 한 둘이 아니었다. 패치가 언제나 조직에게 옳은 방향으로 이끄는 것은 물론 아니지만, 패치를 적용하지 않을 때는 그에 대한 합당한 이유가 있어야 하며, 그로 인한 보안적 이슈에 대해 조치도 취해야 할 것이다.

 

결함사례#2

일부 시스템에 서비스 지원이 종료(EOS)된 OS버전을 사용 중이나, 이에 따른 대응계획이나 보완대책이 수립되어 있지 않은 경우가 있다. 이것도 취약점이 발생할 수 밖에 없는 상황이다. MS 윈도우를 쓰건, 리눅스를 쓰건, 솔라리스를 쓰건, HP-UX를 쓰건, 일반적으로 회사에서 쓰일 법한 OS의 대부분은 EOS 시점을 확인할 수 있는 사이트를 제공한다. 따라서 이를 통해 OS 버전에 대한 정보를 확인하 수 있으니, 별다른 대책 없이 EOS된 OS를 계속 쓰는 일은 없도록 해야 할 것이다.

 

결함사례#3

상용 소프트웨어 및 OS에 대해서는 최신 패치가 적용되고 있으나, 오픈소스 프로그램(openssl, openssh, Apache 등)에 대해서는 최신 패치를 확인하고 적용하는 절차 및 담당자가 지정되어 있지 않아 최신 보안패치가 적용되고 있지 않은 경우가 있다. 최신 패치에 관한 담당자도 배정하는 것이 필요하다. 오픈소스 프로그램이기에 최신 패치를 적용하는 것이 어찌보면 더욱 수월한 상황인데 그것을 합당한 이유없이 미루는 것은 말이 되지 않는다. OS건 오픈소스건, 패치라는 개념에 대해서는 일관적인 태도를 취해야 할 것이다.

 

2.10.9 악성코드 통제

인증기준: 바이러스·웜·트로이목마·랜섬웨어 등의 악성코드로부터 개인정보 및 중요정보, 정보시스템 및 업무용 단말기 등을 보호하기 위하여 악성코드 예방·탐지·대응 등의 보호대책을 수립· 이행하여야 한다

 

결함사례#1

일부 PC 및 서버에 백신이 설치되어 있지 않거나, 백신 엔진이 장기간 최신 버전으로 업데이트되지 않은 경우가 있다. 백신프로그램에 대해서는 내부 지침을 통해 설치 범위와 절차, 정책 등을 확립해야 한다. 백신을 통해 악성코드 예방도 가능한데, 이를 행하지 않는 일은 여러 방어겹 중 굳이 한 개를 버리는 일과 같을 것이다.

 

결함사례#2

백신 프로그램의 환경설정(실시간 검사, 예약검사, 업데이트 설정 등)을 이용자가 임의로 변경할 수 있음에도 그에 따른 추가 보호대책이 수립되어 있지 않은 경우가 있다. 이용자가 임의로 변경할 수 있게되면, 꼭 임의로 변경하는 사람이 나타나기 마련이다. 특히나 임의로 변경함으로써 편의성을 얻을 수 있는 상황이라면 더욱 그럴 가능성이 크고 말이다. 따라서 이에 대해 추가 보호대책은 반드시 수립해야 한다. 언제나 직원들에게도 선택권을 주어서는 안 된다. 보안에 있어서는 강제해야 한다면 강제하는 것이 옳다. 그리고 직원들을 설득하고 이해시키는 것이 그 다음 일이라고 생각한다.

 

결함사례#3

백신 중앙관리시스템에 접근통제 등 보호대책이 미비하여 중앙관리시스템을 통한 침해사고발생 가능성이 있는 경우 또는 백신 패턴에 대한 무결성 검증을 하지 않아 악의적인 사용자에 의한 악성코드 전파 가능성이 있는 경우가 있다. 백신을 설치했다고 끝나는 것이 아니라, 백신 소프트웨어가 최신의 상태로 유지는 되고 있는지, 업데이트 주기는 잘 지키고 있는지, 제대로 작동하고 있는지 점검하는 것도 필요한 일이다. 결국 사람이 하는 일인데 당연히 보호 대책이 미비한 영역이 있을 수 있지 않은가. 그래서 언제나 모든 영역에 대한 점검은 주기적으로 이뤄져야 한다.

 

결함사례#4

일부 내부망 PC 및 서버에서 다수의 악성코드 감염이력이 확인되었으나, 감염 현황, 감염 경로 및 원인 분석, 그에 따른 조치내역 등이 확인되지 않은 경우가 있다. 이는 감염 발견 시 대응 절차가 제대로 수립되어 있지 않은 상황일 것이다. 담당자는 감염 발견 시 악성코드 확산 및 피해 최소화를 위한 절차를 수립하고, 그 절차를 조직이 제대로 수행할 수 있는지도 수시 점검해야 한다. 감염이력이 있는데, 현황이나 원인, 조치내역 아무것도 알 수 없다면, 그게 대체 무슨 의미가 있을까 싶다. 병원에 갔는데 의사가 '병에 걸리셨네요. 그런데 무슨 병인지는 잘 모르겠고, 원인도 잘 모르겠어서, 조치를 하지 않겠습니다.'라고 답하면 황당하지 않을까? 이 사례가 딱 황당한 상황이다.