ISMS-P 결함사례 고찰 #2.11. 사고 예방 및 대응

2.11.1 사고 예방 및 대응체계 구축

인증기준: 침해사고 및 개인정보 유출 등을 예방하고 사고 발생 시 신속하고 효과적으로 대응할 수 있도록 내·외부 침해시도의 탐지·대응·분석 및 공유를 위한 체계와 절차를 수립하고, 관련 외부기관 및 전문가들과 협조체계를 구축하여야 한다.

 

침해사례#1

침해사고에 대비한 침해사고 대응 조직 및 대응 절차를 명확히 정의하고 있지 않은 경우가 있다. 군대 시절에 훈련 때마다 위기조치반을 소집해서 대응하던 것들이 생각난다. 당시 나 같은 통신병이나 상황병들은 반드시 몇몇이 위기조치반에 소집되었는데, 나도 일병까지만 하더라도 내가 정확히 무슨 일을 해야 하는지 알 수 없었다. 그저 가만히 선임들과 앉아있으며 자리를 지키는 게 전부였다. 그러다 선임병 라인에 오르면서, 선임병인데도 위기조치반에 대해 잘 모르고 있다는 생각이 들어서 해당 내용을 공부했던 기억이 난다. 비단 나 뿐만 아니라, 대부분의 경우가 비슷했다. 통신이건, 상황이건, 메인 선임병이 업무를 거의 다 이끌어 가고, 후임병은 옆에서 앉아있기만 하는 구조였기 때문이다. 아무리 침해사고 대응 조직에 오랜 기간 들어가 있다 한들, 본인이 거기서 직접 수행하는 업무에 대한 인지와 이해가 없다면, 실제 대응을 해야 하는 상황에서 버벅일 수밖에 없다. 그래서 이에 대해 명확한 정의는 물론이거니와, 해당 직원에게 업무를 온전히 이해시키는 것이 뒤따라야 할 것이다. 그리고 이를 토대로 대응 절차를 실제로 연습해보는 사례도 주기적으로 필요할 것이다.

 

침해사례#2

내부 지침 및 절차에 침해사고 단계별(사고 전, 인지, 처리, 복구, 보고 등) 대응 절차를 수립하여 명시하고 있으나, 침해사고 발생 시 사고 유형 및 심각도에 따른 신고·통지 절차, 대응 및 복구 절차의 일부 또는 전부를 수립하고 있지 않은 경우가 있다. 이것도 #1과 비슷한데, 실제 대응 연습을 하지 않았기 때문에 이런 일이 발생하는 것이다. 실제로 지침을 따라 절차를 밟아 보면 무엇이 부족한지, 어떤 부분을 보완해야 하는지 알 수 있을 것이다.

 

침해사례#3

침해사고 대응 조직도 및 비상연락망 등을 현행화하지 않고 있거나, 담당자별 역할과 책임이 명확히 정의되어 있지 않은 경우가 있다. 이것도 역시나 #1, 2의 연장선으로 보이며, 실제 침해사고가 발생했을 때 어버버 하다가 사고를 키울 것이 아니라면 당장 이에 대해 조치를 취해야 한다.

 

침해사례#4

침해사고 신고·통지 및 대응 협조를 위한 대외기관 연락처에 기관명, 홈페이지, 연락처 등이 잘못 명시되어 있거나, 일부 기관 관련 정보가 누락 또는 현행화되지 않은 경우가 있다. 사실 이 대외기관은 그다지 변동이 크지 않을 수도 있기는 하지만, 오랜 기간 침해사고 지침을 두고 수정하지 않았다면 당연히 변동이 생길 수도 있다. 하다 못해, 전화번호도 바뀔 수 있는 것이고 말이다. 따라서 지침에 대해서는 주기적으로 해당 내용이 타당한지 점검할 필요가 있다.

 

침해사례#5

부 보안관제 전문업체 등 유관기관에 침해사고 탐지 및 대응을 위탁하여 운영하고 있으나, 침해사고 대응에 대한 상호 간 관련 역할 및 책임 범위가 계약서나 SLA에 명확하게 정의되지 않은 경우가 있다. 상호 간 관련 역할과 책임이 명확하지 않다면, 어느 누구도 책임을 다하려 들지 않을 것이다. 그 전문업체는 계약에 의해서 할 것만 하면 된다는 생각을 가지고 있을 수도 있고, 따라서 그 업체만 믿고 있다가는 낭패를 볼 수 있는 것이다. 확실한 행동은 책임감에 대해 인지를 하고 있을 때 나온다고 생각한다. 이에 대해 명확하게 정의할 필요가 있다. 이것은 외부 업체에만 해당하는 것이 아니고, 내부 직원들을 대상으로도 마찬가지로 적용되는 것이라고 본다.

 

침해사례#6

침해사고 대응절차를 수립하였으나, 개인정보 침해 신고 기준, 시점 등이 법적 요구사항을 준수하지 못하는 경우가 있다. 법의 내용도 매년 조금씩 개정이 일어나고 있다. 이 사고 예방 및 대응체계 구축에 대해서는 개인정보 보호법 34조와 정보통신망법 48조를 참고하는 것이 일반적인데, 따라서 해당 법률에 개정이 생길 때 기존의 절차와 지침이 합당한지 점검하고 수정할 필요가 있을 것이다.

 

2.11.2 취약점 점검 및 조치

인증기준: 정보시스템의 취약점이 노출되어 있는지를 확인하기 위하여 정기적으로 취약점 점검을 수행하고, 발견된 취약점에 대해서는 신속하게 조치하여야 한다. 또한 최신 보안취약점의 발생 여부를 지속적으로 파악하고, 정보시스템에 미치는 영향을 분석하여 조치하여야 한다.

 

침해사례#1

내부 규정에 연 1회 이상 주요 시스템에 대한 기술적 취약점 점검을 하도록 정하고 있으나, 주요 시스템 중 일부가 취약점 점검 대상에서 누락된 경우가 있다. 누락이 되면, 그 일부라는 부분에 취약점이 있었을 경우 그곳에서 문제가 발생할 가능성이 생길 수 있다. 그 부분을 실수로 누락했건, 아니면 예산이나 물리적 시간의 부족으로 인해 고의로 누락했건, 만약 공격자가 APT 공격을 통해 이를 인지하게 된다면 바로 타깃이 될 가능성이 높다. 점검 대상은 전체로 하는 것을 기본으로 삼아야 하며, 금전적이나 시간적으로 문제가 있는 경우에는 그래도 현재에 할 수 있는 최선의 조치를 취해야 할 것이다.

 

침해사례#2

취약점 점검에서 발견된 취약점에 대한 보완조치를 이행하지 않았거나, 단기간 내에 조치할 수 없는 취약점에 대한 타당성 검토 및 승인 이력이 없는 경우가 있다. 이것도 #1과 비슷한 부분이 있는데, 당장 조치하기에 무리가 있는 경우가 분명 있을 수 있다. 조직마다 각자 사정이 있는 법이니 마련이다. 그런데 취약 정도가 100인 취약점이 있다고 하면, 그것을 당장 0에 가깝에 완벽한 해결을 할 수는 없을 지언정, 50정도 까지는 줄이려는 노력을 해야 하고, 그게 안되더라도 그곳에 문제가 밠애했을 때의 대응조치에 대해 완벽하게 세팅을 해놓아야 한다. 그렇지 않고서는 취약점을 점검하는 이유가 없다.

 

2.11.3 이상행위 분석 및 모니터링

인증기준: 내·외부에 의한 침해시도, 개인정보유출 시도, 부정행위 등을 신속하게 탐지·대응할 수 있도록 네트워크 및 데이터 흐름 등을 수집하여 분석하며, 모니터링 및 점검 결과에 따른 사후조치는 적시에 이루어져야 한다.

 

침해사례#1

외부로부터의 서버, 네트워크, 데이터베이스, 보안시스템에 대한 침해 시도를 인지할 수 있도록 하는 상시 또는 정기적 모니터링 체계 및 절차를 마련하고 있지 않은 경우가 있다. 내부, 외부에 대한 침해 시도를 비롯한 각종 이상행위를 탐지할 수 있도록 모니터링 체계를 구축하는 것은 매우 중요하다. 시스템의 중요도가 높은 경우에는 24시간 실시간으로 하는 것도 고려해야 하고 말이다. 이것에 대한 모니터링 조차 되어있지 않다면, 실시간으로 대응하는 절차도 분명 문제가 생길 수밖에 없을 것이다. 일종의 1차 방어선을 날리는 것이나 다름 없으니 말이다.

 

침해사례#2

외부 보안관제 전문업체 등 외부 기관에 침해시도 모니터링 업무를 위탁하고 있으나, 위탁업체가 제공한 관련 보고서를 검토한 이력이 확인되지 않거나, 위탁 대상에서 제외된 시스템에 대한 자체 모니터링 체계를 갖추고 있지 않은 경우가 있다. 위탁업체와 계약을 맺었다 한들, 실제 사건이 발생했을 때 모든 것을 위탁업체가 처리하는 것은 당연히 아니다. 그런데 평상시 업무에서 위탁업체와의 연계를 제대로 수행하지 않고 있다면, 실제 사건이 터졌을 때 조직이 할 수 있는 일은 매우 제한적일 것이다. 확실한 연계를 통해 그저 맡기는 데에서 끝나지 말고, 위탁업체와의 상호작용을 통해 위기대응에 더욱 자신감을 키울 수 있도록 해야 할 것이다.

 

침해사례#3

내부적으로 정의한 임계치를 초과하는 이상 트래픽이 지속적으로 발견되고 있으나, 이에 대한 대응조치가 이루어지고 있지 않은 경우가 있다. 임계치를 정의는 했는데 이에 따라 후속 조치가 이뤄지지 않는다면 굳이 임계치를 정의한 이유가 무엇이 되겠는가. 특히 알려지지 않은 공격의 경우 임계치의 역할이 매우 중요해진다. 갈수록 제로데이 공격이 늘어나는 상황에서 임계치의 중요성은 더욱 커질 것이고, 후속 조치가 적시에 이루어지도록 체계를 갖추어야 할 것이다.

 

2.11.4 사고 대응 훈련 및 개선

인증기준: 침해사고 및 개인정보 유출사고 대응 절차를 임직원과 이해관계자가 숙지하도록 시나리오에 따른 모의훈련을 연 1회 이상 실시하고 훈련결과를 반영하여 대응체계를 개선하여야 한다.

 

침해사례#1

침해사고 모의훈련을 수행하지 않았거나 관련 계획서 및 결과보고서가 확인되지 않은 경우가 있다. 연 1회만 하면 되는 것을 수행하지 않았다면 이는 문제가 크다. 1년 마다 휙휙 바뀌는 것이 보안 영역이다. 관련 법이 바뀌었을 수도 있고, 새로운 취약점이 대두되었을 수도 있고, 조직 사이에 인사 이동이 많이 생겼을 수도 있다. 모의훈련은 일종의 자신감을 키워나가는 과정이라고 생각한다. 해봤자 1년에 1, 2번을 할 텐데, 그것조차 하지 않는다면 실제 사건이 터졌을 때 제대로 된 대응을 할 수는 없을 것이라 확신한다.

 

침해사례#2

연간 침해사고 모의훈련 계획을 수립하였으나 타당한 사유 또는 승인 없이 해당 기간 내에 실시하지 않은 경우가 있다. 이것 역시 마찬가지로 심각하게 여겨야 할 사안이다. 직접 해보지 않고서는 대처할 수 있을 리가 없다. 경험이 과거에 있다 한들, 매번 해봐야 그게 유지되는 것이지 않겠는가.

 

침해사례#3

모의훈련을 계획하여 실시하였으나, 관련 내부 지침에 정한 절차 및 서식에 따라 수행하지 않은 경우가 있다. 결국 약식으로 진행했다는 말이 되겠다. 그저 보여주기 위한 것으로, 기록을 남기기 위한 것으로 수행한다면 무슨 의미가 있을까. 모의훈련을 실시하는 이유가 자신감을 키우기 위한 것이라 하였는데, 나는 이렇게 수행한다면 자신감을 키울 수 없을 것 같다. 실제 환경을 제대로 구현해서 해야 하는데, 내부 지침에 정한 절차 조차 따르지 않는다면, 나는 그 절차는 과연 100% 확실한지에 대한 믿음도 가질 수 없을 것이다. 대충 훈련을 하는 조직에 신뢰가 어디 있겠냐는 말이다.

 

2.11.5 사고 대응 및 복구

인증기준: 침해사고 및 개인정보 유출 징후나 발생을 인지한 때에는 법적 통지 및 신고 의무를 준수하여야 하며, 절차에 따라 신속하게 대응 및 복구하고 사고분석 후 재발방지 대책을 수립하여 대응체계에 반영하여야 한다.

 

침해사례#1

내부 침해사고 대응지침에는 침해사고 발생 시 내부 정보보호위원회 및 이해관계 부서에게 보고하도록 정하고 있으나, 침해사고 발생 시 담당 부서에서 자체적으로 대응 조치 후 정보보호위원회 및 이해관계 부서에 보고하지 않은 경우가 있다. 보통 이런 경우는 뻔하다. 일을 키우기 싫으니까 그렇게 한 것이다. 그리고 이런 사건에는 물론 다 중요하기야 하다만, 정확히 어떤 침해 내용이 있고, 어떤 정보가 유출되었는지를 파악하는 것이 중요한데, 이런 사례를 만든 조직이라면 그것을 축소했을 가능성도 있겠다 싶다. 그리고 이렇게 침해사례로 뽑히는 것처럼, KISA를 비롯한 여러 기관이나 위원회가 생각보다 무능하지 않다. 숨긴다고 해서 숨겨지는 것이 아니기 때문에 법적 절차에 따라 명확한 대응을 해야 할 것이다.

 

침해사례#2

최근 DDoS 공격으로 의심되는 침해사고로 인하여 서비스 일부가 중단된 사례가 있으나, 이에 대한 원인분석 및 재발방지 대책이 수립되지 않은 경우가 있다. DDoS는 생각보다 일반인이 흔히 접할 수 있는 공격 중 하나라고 생각한다. 뉴스만 하더라도 심심하면 북한의 소행으로 보이는 DDoS 공격이 있었다는 보도가 나오곤 하니 말이다. 그런데 한 번 DDoS 공격이 되었다는 것은, 이미 공격자가 해당 타깃을 공격하는 것이 가치가 있는 일이라고 판단했다는 것이다. 그런데 원인분석이나 재발방지 대책이 수립되지 않았다는 것은 '다시 공격해주세요' 라는 말 밖에 해석이 되지 않을 것이다. 쌓아온 자산을 또 날리고 싶지 않다면 재발방지 대책을 수립하고 이행해야 한다.

 

침해사례#3

외부 해킹에 의해 개인정보 유출사고가 발생하였으나, 유출된 개인정보 건수가 소량이라는 이유로 72시간 이내에 통지 및 신고가 이루어지지 않은 경우가 있다. 이미 유출이 되었는데 그게 소량인지 대량인지는 중요치 않다. 소량이면 그 피해자들이 잘 모를 수도 있으니 조용히 넘어가는 것일까? 이는 명백히 범법행위이다. 그리고 내가 만약 공격자라면, 조직이 이런 잘못된 대처를 했을 때 그것을 사회 전반에 알리는 것을 빌미로 협박을 하지 않을까 싶다. 그렇게 되면 되돌릴 수 없을 정도로 큰 피해를 입게 되는 것이다.

 

침해사례#4

담당자의 실수에 의해 인터넷 홈페이지 게시판을 통해 1천명 이상 정보주체에 대한 개인정보 유출이 발생하였으나, 해당 정보주체에 대한 유출 통지가 이루어지지 않은 경우가 있다. 소수도 아니고 심지어 1천명 이상인데 유출 통지를 하지 않았다는 것은 욕을 먹기 싫다는 것 밖에는 다른 의도로 해석이 되지는 않는다. 특히나 절차에 따라 위원회를 비롯한 유관 기관에는 알리고 정작 피해자들에게는 알리지 않았다면 말이다. 법규에서 정말 상세하게 어떻게 통지를 해야하는지 하나하나 알려주고 있으니 몰랐다는 핑계도 불가할 것이다. 고객들은, 국민들은 바보가 아니다. 이런 정보 하나하나 모를 사람들이 아니라는 말이다. 괜히 통지하지 않았다가 더 큰 화를 입지 말고, 재발방지 대책에 대해서도 피해자들에게 상세하게 설명을 해드려야 할 것이다.