모든 request 를 처리하는데에는 비용(cost)이 발생하고, 이를 처리할 수 있는 자원(resource)이 필요하다. multitasking 을 위해서는 context switching 을 위해 overhead 가 생기기 마련이다. CPU가 task 를 처리하느라 바쁠 때에는 기다려라.
1. 이제 한숨 돌렸다면 현장을 생각해 주길.
불행히도 현장은 아직 일이 끝나지 않았다. 끝날 때까지는 끝난 것이 아니다.
침해사고대응 조직에 가장 괴로운 것은 무엇인지 아는가?
첫째, 기술적인 부분보다 오히려 수많은 자료 요구에 휩쓸려 정작 작업할 시간조차 없어지게 되는 것이다. 그리고 비슷한 자료를 비슷한 시기에 반복적으로 요청하는 수많은 상급기관의 bureaucratic men 들이 가장 큰 보안의 적(enemy)이 된다. 또 자신들이 기술적인 지식이 없기 때문에 자신들이 이해할때까지 반복적으로 설명을 요청하거나, 자신들의 보고서 template 에 맞게 반복적인 문서를 요청할 때이다. 이 담당자의 taste 를 만족시켰다고 해서 일이 또 끝나는게 아니라 그 담당자의 상급자의 taste 에 맞게 일이 연쇄업무반응이 일어나는 것 역시 괴로운 일이다.
지금 코드분석하고 시스템 점검하고 기술적인 대응을 하기에도 바쁜데, 수시로 진행상황을 보고하도록 요청이 오게 된다면, 가뜩이나 고양이 손이라도 빌려야 할 판인데, 현장에서 대응하고 모니터링하기에 바쁜 인원이 그 와중에 focus 를 잃고 보고서를 작성해서 올려야 한다.
게다가 시어머니까지 여럿 있는 조직이라면, 각 상급기관마다 요구하는 정보가 다 양식도 다르고, 원하는 듀데이트도 달라서 이 자료 저 자료 만드느라 정작 집중해야 할 침해사고 대응을 못하게 된다.
- 참고: 긴급상황에서 전파되는 bulletin 문서의 가장 권장되는 포맷은 txt 포맷이다. 절대 powerpoint 라든가 hwp 는 더더욱 아니다. 어느 시스템에서나 볼 수 있고 (심지어 더미 터미널에서도 열어볼 수 있다.), 신속한 작성과 배포가 가능하기 때문이다. 중요한 건 양식이 아니라 내용이다. bulletin 으로 정보를 받아서 정보를 받은 조직이 각자 자신 조직들의 내부 상황에 맞게 재가공하면 되는 것이다.
둘째, 경영진이 자신들의 현실을 모르는 채 압박만으로 확신을 (자기만족을) 얻으려는 것이다.
침해사고는 하루 이틀 안에 끝나는게 아니다. 해커와 머리싸움하며 대치상태로 몇달이 가는 경우도 비일비재하다. 하지만 경영진들의 인내심은 무척 적다. 일주일이면 정말로 많이 기다려 주었다고 생각하게 된다. 그리고 현장에 자신의 발언이 어떤 나비효과를 줄지 깨닫지 못하는 채 많은 압박(pressure)을 주게 된다.
자네만 믿네.
매일 수시로 보고하게.
밤을 새워서라도 내일까지 해킹을 막도록 하게.
사고가 발생한지 일주일이 지났네. 이제 더 이상의 해킹은 없다고 생각하면 되나?
어제 나에게 보고할 때에는 해킹당한 장비 복구가 완료되었다고 하지 않았나? 왜 이런 일이 며칠 사이에 또 벌어진건가? (내출혈이 있을 때 입으로 흘러나온 피를 닦아 내었다고 내부 출혈이 해결된게 아니지 말입니다...)침해사고대응을 해본 분들이라면 많이들 겪어보지 않았는가? 저런 압박과 더불어 공명심에 또는 어떻게든 성과를 보여야 한다는 생각에 사로 잡힌 매니져가 만나면 재앙이 되는 상황들.
또 기존에 열심히 현장에서 땀흘린 사람들을 *어쨌거나 보안에 실패한 사람*, *무능한 사람*으로 폄하해 버리는 경우도 생기게 된다.
이쯤에서 다시금 CMU 의 침해사고대응 핸드북 을 읽어보면 수많은 침해사고대응 경험을 토대로 많은 고민들과 이에 대한 해법이 담겨져서 나온 문서라는 것이 느껴진다. human error (긴박한 상황에서는 사람이니까 누구나 실수를 하지요...) 에 대해 어떻게 할 것이냐에 대한 policy 적인 고려사항도 언급되어 있고, liaison 기능에 대해서도 언급되어 있다.
정보보안조직이 고도화 되고 성숙하게 되면 liaison 기능을 별도로 두게 된다. 즉 신속하게 상황전파와 대외 커뮤니케이션 (대언론, 법적인 부분, 기술적인 상황전파, ...)을 맡는 기능은 분석과 대응을 하는 것과는 다른 종류의 기능인 것이다. 대개는 침해사고대응 조직의 장이 liaison 역할을 겸하여서 정보를 취합하고 대외 커뮤니케이션을 하거나, 대외 커뮤니케이션은 법무부서의 검토를 받은 뒤 대외협력을 담당하는 부서가 전담하게 된다.
이는 실제로 상황전파와 보고에 들어가는 노력만해도 전문성이 필요하고, 이 업무만으로도 상당한 노력이 필요하다는 배경에서 출발한 기능분화이다.
Liaison 역할을 할 사람들은 전문적인 분석인력은 아니지만, 기술적인 내용을 이해할 수 있으면서도 커뮤니케이션 능력이 좋은 인력을 배치해서, 분석에 투입되어야 하는 인원들은 온전히 분석과 대응업무에만 전념할 수 있도록 함이 맞다.
2. 슬프게도 지금 침해사고 대응 현장은...
인원이 없다. 인원이 없다. 인원이 절대 부족하다.
연말연시 휴가는 고사하고 이미 지옥이다.
현장에서 보안일 하는 분들도 가정이 있는 분들이고, 기계가 아닌지라 휴식도 필요하다. 격무에 시달리며 앞으로 몇달 더 달리게 되면 건강문제도 있을 것이다. 해킹사고를 심하게 겪은 조직의 보안담당자는 사실 PTSD 를 겪는다고 보아도 무방할 정도이다. 하지만 충원은 신속히 안된다. 민간기업에서 아무리 특채로 신속히 사람을 뽑는다고 하더라도 침해사고 났던 회사에서는 사람 모집이 더더욱 어려운데 (가시밭길로 누가 십자가를 지고 뛰어들 것인가.), 침해사고가 발생했던 공공기관에서 절차를 밟아가며 충원을 한다면 사고시점으로부터 1년 반 뒤에나 한 두명 뽑히게 될 것이다.
이때는 기술적 조치 하나에만 집중하도록 오버헤드를 줄여줘야 할때가 아닌가 싶다. 원래 침해사고라는 것이 기술적 조치에만 온전히 집중해도 해킹사고 재발 가능성을 없앴다고 쉽게 담보하기도 어렵다.
3. 하고 싶은 말
아직 해야할일이 산더미 처럼 남아 있는 침해사고 담당자들에게 힘을 주려면 다음을 지켜주기 바란다.
- 정보를 요청하라. 보고서를 요청하지 마라. 보고서는 전달받은 정보를 가지고 당신 조직의 용어와 언어로 당신이 써야 한다.
- 개별 요청을 하지 마라. 오버헤드를 일으키게 된다. 마찬가지로 침해사고대응중인 조직도 커뮤니케이션으로 인한 오버헤드를 줄이려면 개별 요청에 개별 응대하지 말고, 공통의 정보전달 채널을 만들어라.
- 본인의 상급자가 어짜피 몇번을 쉽게 설명해도 모른다면, 당신의 상급자는 사실 이 침해사고대응 프로세스에 loop 안에 들어올 이유가 없는 것이 맞다. (loop 안에 들어오는 순간 방해만 되는 분들이다. ) 십중팔구는 "need to know 권한이 없는데 bureaucratic mind 로 나도 보고 받고 싶어, 나도 알아야 하지 않겠나?" 하는 사람이다. 그런 분들께는 신문기사를 정성껏 칼라 프린트해서 제출드리는 것으로 충분하다. 그리고 그 분께 보고서를 올려야 하는 당신도 긴박한 상황에서 loop 에 안들어오는 것이 맞는 사람이다.
- 진전이 있다면 당연히 보고를 할 것이다. 보고가 올때까지 기다려라. 진척사항을 보고하라고 수시로 푸쉬하면 그것 때문에 압박을 느낀 담당자가 아직 결과가 나오지도 않았는데, 상황이 긍정적이라고 보고를 할 수도 있다. (침해사고대응 경험이 많지 않은 - 즉, 이러한 수시 요청사항을 적당히 흘리고 비켜서는 스킬이 충분히 쌓이지 않은- 담당자에게는 압박을 하면 할 수록 "거짓말과 허위보고와 개인의 주관적 생각의 미묘한 경계선에 있는 보고"를 올릴 확률이 높아지게 된다. 이런 왜곡된 정보는 그저 *살아있는 악마* 그 이상도 이하도 아니게 된다. 향후 있을 의사결정 프로세스에 지속적인 문제를 일으키는 요소가 된다.
4. 맺으며
갈길이 멀다. 사고는 일단락 되어도 현장은 여전히 고되다.
기왕 발생한 침해사고 대응도 마무리 지어야 하고, 새로 인원 충원도 해야 하고, 어쩌면 경우에 따라 민형사 이슈가 발생할 수도 있다.
지금 힘을 실어주고 조속히 보안강화를 하고 싶다면 (사실 이것이 정말 중요한 goal 아닐까?) 예산 배정, 보안강화에 필요한 후속조치가 신속히 이뤄지도록 절차를 간소화 시켜주는 것 (채용, 예산집행 등등), 그리고 침해사고 후속조치에만 집중할 수 있도록 관심은 끊임없이 가져주되 interrupt 는 주지 않도록 하는 것이라 생각된다.
댓글 없음:
댓글 쓰기