[기사] 체크리스트의 폐단

출처 : http://www.dailysecu.com/news_view.php?article_id=7411

기술적 진단 관점에서 본 정보보호 컨설팅…변화가 필요한 시기

[황석훈 타이거팀 대표. 사진] 2001년 진대제 장관 시절 도입된 정보통신망이용촉진에관한법률(이하, 정보통신망법)은 당시 보안 유관 사업들에 큰 변화를 가져옵니다.
 
2001년 이전 1990년대 중후반의 모의해킹은 전통적인 모의해킹 서비스 또는 컨설팅이기 보다는 당시의 방화벽 등 보안솔루션을 판매하기 위한 하나의 장치로써 활용된 바가 많습니다. 하지만, 당시의 모의해킹은 시스템, 네트워크, 보안솔루션 등 전방위적인 해킹 공격 시나리오가 가능했고, 이에 대해서 특별한 이견이 없었습니다. 따라서 모의해커의 입장에서는 상대적으로 자유롭고 다양한 접근 방법을 이용한 해킹시도가 가능했었습니다.
 
2001년 정보통신망법이 도입되면서 많은 것들에 변화가 오기 시작합니다. 보안 관점에서 시급하게 해야 할 가장 큰 이슈는 관리체계 및 프로세스 수립이었습니다. 정보보호 활동에 대한 정의 자체가 없었기 때문에 이에 대한 정의가 선행되어야 했습니다. 따라서 자연스럽게 관리체계 분야에 종사하시던 분들이 프로젝트 PM 등을 많이 맡게 되었고 상대적으로 기술영역 분야는 비중에 낮게 보는 분위기가 형성되었습니다. 심지어 임원급 중에서 기술진단 출신이 거의 없다시피 할 정도였으니까요.
 
관리체계의 수립 과정에서 다양한 방법론과 노력들이 있었습니다. 가장 큰 이슈 중 하나였던 보안수준 지표에 대한 정량화의 노력은 필요한 노력이긴 했지만, 기술적 컨설팅 영역에 최선이자 최악의 상황을 만드는 계기가 되었다고 필자는 생각합니다.
 
이는 보안수준 재고를 위한 활동중 기술적 영역에 대한 평가를 위해서 체크리스트 기반의 평가 지표가 필요했습니다. 체크리스트라는 것은 정해진 항목에 대해서 가이드라인을 기반으로 안전한지, 안전하지 않은지에 대한 O X 평가 방식이었기 때문에 자산의 위치나 용도, 네트워크 환경 등에 대한 다양한 내역을 반영하지 않았습니다. 모든 자산의 동일한 기준을 놓고 평가를 하게 되었습니다. 이는 논리적, 물리적 아키텍처에 대한 고민이 부족했기 때문이라고 필자는 생각합니다. 결론적으로 모든 환경을 체크리스트 기준에 의거한 가이드라인으로 맞추기만 할 뿐, 상황에 반영한 전문가적인 의견이 반영될 요소가 사라진 것입니다.
 
또한 체크리스트를 보유하지 못한 장비의 경우에는 평가가 어렵고 특정 시스템의 경우 특정 환경에서 더 중요한 부분이 있을 수 있지만, 체크리스트에 없을 경우 검토 대상에서 포함되지 않는 문제들이 있었습니다. 따라서 이를 기반으로 한 보안수준 평가 점수는 사실상 큰 의미를 가지기 어려웠습니다. 따라서 보안수준이 90점이라도 하더라도 아무도 이에 대해서 안전하다 하지 않다라고 말하지 못했으며, 설령 100점을 받는다 하더라도 안전하다고 단언할 수는 없는 맹점이 존재해왔다고 봅니다.
 
그리고 이러한 체크리스트 기반으로 진단을 수행하는 인력들은 이를 자동화하기 위한 스크립트를 작성하기 시작하였고, 어느 순간에는 대상 시스템 및 스크립트나 가이드라인에 대한 이해도가 전무한 인력들이 수행 방법만 설명을 듣고 컨설팅을 수행하기도 했습니다. 이것은 기술적 보안컨설팅에 대한 낮은 이해 수준을 단적으로 보여주는 사례라고 볼 수 있겠습니다. 이러한 것은 자산의 다양한 입장이 반영되지 못한 체크리스트 기반과 점검의 효율성을 높이기 위해서 제작되었던 반자동화한 스크립트 진단 방식의 폐단이라 할 수 있겠습니다.
 
반면, 모의해킹 영역은 이 부분에 대해서 상대적으로 자유롭기는 했습니다. 모의해킹 영역은 체크리스트는 있었지만, 자동화된 방법이 불가능하여 거의 모든 인력들이 수작업을 통해서 수행했기 때문입니다. 즉 모의해킹을 할 줄 모르면 모의해킹 업무 자체를 수행할 수 없다는 것입니다.
 
하지만 아쉽게도 위에서 정해버린 체크리스트는 모의해킹에서도 발목을 잡게 됩니다. 체크리스트 이외의 항목을 점검하게 되면 문제가 되는 사례도 있었고, 취약점을 도출하여도 해당 내용을 삭제해야 하는 경우가 허다했습니다. 또한 점검항목이 웹 기반의 항목이 대다수다 보니 타종의 시스템에 즉시 적용이 어려운 면이 발생하기도 하였습니다. 그 이외에도 모의해킹은 실제 해커와 동일한 입장에서도 테스트를 해야 함에도 불구하고, 장소와 수행절차 등이 정형화되면서 실제 모의해킹이라기 보다는 단순히 취약 여부를 확인하는 반자동 프로그램처럼 업무를 수행하게 되는 등의 문제점이 생기게 되었습니다. (고객사에 맞는 운영체제를 설치해야 한다거나, 백신 및 보안프로그램 등으로 인하여 해킹 도구가 삭제 또는 비정상 동작되는 환경 등에서 작업을 수행해야 하는 상황들을 말합니다. 하지만 해커는 이렇게 하지 않는 것이 중요한 차이점이라고 볼 수 있겠습니다.)
 
이러한 체크리스트 기반은 모의해킹 인력의 상상력과 노력에 많은 제동을 걸게 되었고 실질적인 해킹 실력이 하향평준화를 만드는 계기가 되었던 것으로 보입니다.
 
즉 어느 쪽이 더 좋았을지 객관적으로 정량화하여 비교할 수는 없었겠지만, 2001년 이전의 모의해킹 실력이 지금보다 낳지 않았을까 하는 생각을 이런 근거로 해보게 됩니다.
 
하지만 누구도 이렇게 일부러 만들지는 않았다고 생각합니다. 모두 당시의 상황에서 최선을 다했다고 생각합니다. 그렇기 때문에 이제부터는 다시 한번 현실을 재조명하고 개선안을 찾아볼 때가 아닌가 생각합니다.
 
측정, 평가라는 단어에 매몰되어 컨설팅 방법론의 기술분야에 대한 충분한 다양성을 담지 못한 것이 작금의 상황이라고 생각합니다. 따라서 정보보호관리체계 및 다양한 프로세스가 정립된 작금의 상황에서 우리가 더욱 고민해 봐야 할 분야는 기술 영역을 어떻게 하면 더 효율적으로 반영할 수 있을지에 대한 성찰이 필요한 것이 아닌가 생각합니다.
 
저의 개인적인 의견을 말씀드리자면, 관리자 또는 방어자의 입장에서 기술 영역을 바라볼 것이 아니라 이제는 공격자 또는 해커의 입장에서 바라볼 필요가 있다고 생각합니다.
 
이에, 모의해킹 대상의 범주를 내부망/외부망, 서버/PC 이러한 관점의 벽을 허물고 공격의 대상이 되는 포인터를 정의하고 해당 포인터에 접근 가능한 공격 포인터를 발견하고 이에 대한 안전성을 점검하는 방식이 보다 현실적이고 타당한 방법이라고 생각합니다. 이 과정에서는 기존의 체크리스트는 당연히 적절하지 않으며, 고객사의 환경에 적합한 시나리오가 도출되어야 한다고 봅니다. 이렇게 하기 위해서는 기술적 컨설팅의 프로세스도 일부 변화가 필요합니다.
 
현재의 방식은 대상을 정해놓고 해당 시스템에 대해서만 취약점을 점검하는 방식이기 때문에 대상을 받자마자 바로 진행하는 매우 극단적인 방법을 취하고 있습니다. 하지만 앞으로는 고객사의 네트워크 상황과 서비스에 대한 충분한 이해를 선행하고 이를 기반으로 한 시나리오 수립이 반드시 선행될 필요가 있습니다.
 
두번째로는 오펜시브(Offensiv)한 모의해킹이 필요한 시기라 봅니다. 아무런 정보없이 실제로 해커와 동등한 입장에서 모의해킹을 진행할 필요가 있다고 봅니다. 지금까지 10년을 넘게 만들어온 관리적, 기술적 보호 장치가 충분히 잘 작동하는지, 문제 탐지시 해당 프로세스가 적절하게 동작하는지에 대한 체계적인 점검이 필요한 시기라고 봅니다. 아마도 이러한 점검 방식에 대해서 많은 보안 담당자 및 연관된 분들께서 부담을 가질 수는 있겠지만, 실제 사고를 예방하는 차원에서 본다면 더욱 현실적이고 도움이 되는 방법이라고 할 수 있겠습니다.
 
많은 아이디어와 대안이 있을 수 있습니다만 가장 쉽게 접근할 수 있고 일부 고객사에서 수행하고 있는 두 가지의 방법에 대해서 언급해 보았습니다.
 
막는 사람의 입장에서는 너무나 방대한 자산을 효과적이고 체계적으로 관리한다는 것은 매우 어려운 일일 것입니다. 때문에 보다 효과적인 방어를 하기 위해서는 보다 다양한 방법의 접근이 반대로 필요한 것이 아닌가 생각합니다.
 
[글. 황석훈 타이거팀 대표이사 / h9430@tigerteam.kr]